Google公式「google/skills」徹底解説——107スキル固定検証+追加2本、16プラグイン、GA4実機検証

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくんです。
Google公式のAgent Skillが出た。
そう聞いて一覧を開くと、英語の名前がずらーっと並んでいます。
うん、分からん。
アプリなのか。AIへ追加する知識なのか。それとも、Googleのサービスを勝手に動かす仕組みなのか。名前だけ追っても、仕事で使う姿が見えてこないんだよね。
だったら、一個ずつ見るしかない。
Google公式のgoogle/skillsを全件調べました。数を数えただけではありません。何ができるのか、どんな仕事で使うのか、実データへ触るものなのか。107本を同じ物差しで見直した。
で、一覧表を作って終わるのも違う。
Google Analytics 4(GA4)用Skillを、実際のai-kidou.jpの環境で動かしました。直近7日と、その前の7日を比べ、取れた数字を次の判断へどうつなぐかまで試した。
この記事で持ち帰ってほしいのは、次の3つです。
google/skillsは何で、一般的なAIツールと何が違うのか- 107スキル・16プラグイン・追加7系統で何ができるのか
- 自分の仕事でどう活用し、何を人間が判断すればよいのか
先に、いちばん面白かった結果を言います。
追加ログインなし。約6秒。GA4への書き込みは0。
その条件で実データを取得できました。そして、直近7日と前の7日を比べると、セッション減少の中心は検索流入ではなくDirectだった。
ただ数字を取ったのではありません。
最初は「サイト全体が落ちてるな…」としか見えません。でも内訳を見ると、「まずDirectの前週要因や計測分類を確認しよう」と、見る場所が一気に細くなった。
ここが大事だよね。
でね、107本を暗記する必要はありません。
あなたの仕事に関係するところだけ拾えばいい。ここからは、機能名の羅列ではなく「何を任せたいか」からほどいていきます。
この記事の目次
google/skillsとは何か- Skill・Script・Plugin・MCPの違い
- 固定検証した107スキルの全機能
- 16プラグインの全体像と主な機能
- 追加エコシステム7系統
- 導入方法と安全な頼み方
- 仕事別の活用法
- 公式Skillと自作Skillの組み合わせ
- GA4公式Skillの実機検証
- GA4 7日差分パルスへの実装
- 導入前の注意点
- 自分の仕事で始める手順
- よくある質問
- まとめ
更新注記——107本は2026年8月13日の検証固定値
この記事の107スキル、16プラグイン、追加7系統は、Google公式リポジトリのコミットc4591645(2026年8月13日)を全件走査した固定値です。
2026年8月16日の公式mainはコミット8f57a0dへ進み、直接選べるSkillは109本になっています。追加された2本は、記事末の補遺へ。
google/skillsは開発中のカタログです。導入時は、公式リポジトリの最新版も確認してください。

公式SkillでGoogleの手順をそろえ、自作Skillで目的・判断・週次運用を重ねる。
1.Google公式google/skillsとは何か
Agent Skillは、AIに専門的な仕事の進め方を教える手順書
Agent Skillは、AIへ仕事の進め方を渡す仕組み。
中心になるのはSKILL.mdという文書です。中には、次のような内容が書かれています。
- どんな依頼で使うか
- 正しいAPIやCLIの扱い方
- どこで失敗しやすいか
- 実行後に何を検証するか
- 使わない方がよい場面はどこか
AIは一般知識だけで「たぶんこうだろう」と進めず、その専門手順を読んでから動けるようになる。
あ、そうだ。手順書が増えるだけでなく、判断のよりどころが増える——ここが普通のPrompt集との違いです。
料理でいえば、食材でも調理器具でもありません。プロが残したレシピと、「ここで焦がすなよ」という注意書き。そんな感じかな。
google/skillsはGoogle製品に特化した公式Skill集
google/skillsは、Googleが公開しているAgent Skillのカタログです。
中心領域はGoogle Cloud。Gemini、Agent Platform、GKE、BigQuery、データベース、監視、セキュリティ、Google Ads、Google Analyticsなどを扱います。
ただね、Googleの全サービスをまとめて操作する万能AIではありません。
調査時点の本体107本には、Gmailの送受信、Google Driveの一般的なファイル操作、Calendarの予定操作、Docs・Sheets・Slidesの一般編集、YouTube Studioの操作は含まれていない。
「Google公式」と聞くと何でもできそうに見える。でも、入っていないものは入っていない。ここは期待で補わず、実際の収録範囲を見た方がいいよ。
一般知識で答えるAIと、公式手順を持つAIの違い
一般知識だけのAIは、学習済みの記憶から操作方法を組み立てる。製品の更新が入ると、古いコマンドや廃止された方法を提案することがある。
公式Skillを読んだAIは、そのSkillに書かれた現在の手順、注意点、確認方法を土台に動く。
もちろん、公式Skillがあれば結果が自動的に正しくなるわけではありません。認証、権限、対象プロジェクト、実データ、実行後の確認は別に必要だ。
それでも「何となく知っているAI」から、「Googleの専門手順を参照して進めるAI」へ変わる意味は大きい。
正直、派手な魔法ではありません。でも、実務ではこの差が効くんだよね…。
どの環境から利用できるのか
公式READMEでは、Agent Skillsに対応する環境からSkillを追加できます。製品プラグインの案内先は、Claude Code、Codex、Antigravity CLI。
ただし、Skillを読めることと、Googleの実データへ接続できることは別です。
実行には、対象に応じてGoogleアカウント、Google Cloud CLI、Application Default Credentials、APIの有効化、対象サービスの権限などが必要になります。
2.Skill・Script・Plugin・MCPはどう違うのか
ここ、私は最初に引っかかりました。
Skill、Plugin、MCP。似た言葉が並ぶので、全部同じ箱に見えるんです。役割で分けると、かなりスッキリします。
| 要素 | 役割 | 単体で外部操作するか |
|---|---|---|
| Skill | AIへ専門知識、手順、注意点、検証方法を教える | 原則として手順書。既存ツールを使う判断は変える |
| Script付きSkill | API呼び出し、診断、生成、評価などを補助する | Scriptの内容と権限によって外部作用がある |
| Plugin | Skill、Script、MCP設定などを製品別にまとめる | 接続先と権限によって作成・更新・削除まで起こり得る |
| MCP | AIと実際のサービスをつなぐ操作口 | 接続したToolと認証権限の範囲で外部操作できる |
| API | サービスの機能をプログラムから呼び出す窓口 | 呼び出す機能に応じて読み書きが発生する |
| CLI | コマンドでサービスを操作する道具 | 実行コマンドと権限に応じて外部作用がある |
Skillは新しい権限を与えるものではない
Skillを追加しただけで、Googleアカウントの権限が増えるわけではありません。
ただしね、AIが既存のCLIやAPIを正しく使えるようになると、今ある権限を使い切れる範囲は広がります。
だから、安全性はSkillの名前だけでは決まらない。
「どの認証情報を見せるか」「どの権限で実行するか」「読み取りか書き込みか」まで含めて考える必要があります。
Pluginは実務機能をまとめた製品別パッケージ
Pluginは、Skillだけでなく、MCPやScriptをまとめて導入できる形だ。
たとえばデータベース系Pluginなら、接続、SQL実行、スキーマ確認、データ更新まで一つの製品単位で扱える。そのぶん便利だが、実データや課金資源へ届く可能性も高くなる。
まず仕組みを知るならSkill。実環境へ接続して操作するなら、PluginやMCPの外部作用まで確認する。
この分け方なら迷いにくいよ。
3.本体107スキルの全機能
さて、ここから107本です。
正直、全部を頭から読むのはしんどい。なので、コミットc4591645で直接選べた107本を15分類に分けました。
表は「Skill名」「対象サービス」「できること」「想定業務」の順です。英語名ではなく、今任せたい仕事に近い分類から見てみよう。
まず15分類で、自分に関係する場所を見つける
| 分類 | 本数 | 主な仕事 |
|---|---|---|
| AI・機械学習 | 18 | Gemini、Agent、RAG、Model管理・評価 |
| BigQuery・Data分析 | 6 | 集計、分析、Data Lineage、Airflow |
| Infrastructure設計・CLI・端末 | 4 | Cloud設計、gcloud、遠隔端末、Agent開発環境 |
| Log・監視・Cost・障害対応 | 14 | Logging、Monitoring、SLO、Cost、障害診断 |
| GKE・Container | 17 | Cluster、配備、伸縮、Security、信頼性 |
| Database | 4 | AlloyDB、Bigtable、Cloud SQL、Spanner |
| Google Cloud開始・組織基盤 | 3 | 認証、Onboarding、Landing Zone |
| Google Ads・広告SDK | 12 | Ads API、Audience、Conversion、App広告 |
| Google Analytics | 2 | GA4のData取得と設定管理 |
| 複数製品Solution | 9 | Agent、RAG、Lakehouse、Cloud全体設計 |
| Network | 3 | GKE Network、Service公開、Global Frontend |
| Security | 3 | SecOps検知、GKE Platform・Workload防御 |
| Serverless・Firebase | 2 | Cloud Run、Firebase |
| Storage・Backup | 4 | GKE Backup、Storage、Filestore、Cloud Storage |
| Well-Architected Framework | 6 | Cost、運用、性能、信頼性、Security、環境負荷 |
全部を順番に読む必要はありません。広告をやっているならGoogle Ads、サイト運営ならAnalytics。まず自分の仕事に近い表だけ拾ってください。
A.AI・機械学習(18)全機能を見る
| Skill名 | 対象サービス | できること | 想定業務 |
|---|---|---|---|
agent-platform-alert-configuration |
Agent Platform・Cloud Monitoring | 遅延、エラー、トークン、品質、安全性のアラートをTerraformで生成 | AIエージェントの運用監視 |
agent-platform-deploy |
Agent Platform・Model Garden | モデルを配備し、状態確認、配備解除、削除を行う | 推論モデルの本番配備 |
agent-platform-endpoint-management |
Agent Platform | 配信エンドポイントを作成、一覧、更新、削除 | AI APIの公開先管理 |
agent-platform-eval-flywheel |
Agent Platform Evaluation | 評価データ、指標、LLM審査、失敗分析、修正前後比較を回す | AI品質の継続改善 |
agent-platform-inference |
Agent Platform Inference | Geminiやオープンモデルで推論し、認証・429エラーを診断 | 複数モデルの推論実行 |
agent-platform-migrate-from-ai-studio |
AI Studio・Agent Platform | AI Studio版Gemini APIから企業向け環境へ移行 | 試作AIの業務環境移行 |
agent-platform-model-registry |
Model Registry | モデルと版を登録、一覧、説明、更新、削除 | モデル資産の版管理 |
agent-platform-prompt-management |
Prompt Management | プロンプトを登録、取得、版管理、削除 | 業務プロンプトの管理 |
agent-platform-rag-engine-management |
RAG Engine | コーパスとファイルを管理し、根拠取得とRAG回答を行う | 社内検索・根拠付き回答 |
agent-platform-skill-registry |
Skill Registry | Skillを登録、検索する | 組織内Skillの共有 |
agent-platform-troubleshooting |
Agent Platform周辺基盤 | Gateway、Registry、Identity、Policyなどの403・500障害を診断 | AI基盤の障害対応 |
agent-platform-tuning |
Agent Platform Tuning | Geminiやオープンモデルを調整する | 専門モデルの作成 |
agent-platform-tuning-management |
Tuning Jobs | 調整ジョブを一覧、取得、キャンセル | 学習ジョブの運用管理 |
bigquery-ai-ml |
BigQuery ML・生成AI | 予測、異常検知、要因分析、検索、分類、要約、翻訳をSQLで実行 | データ分析とAI処理の統合 |
gemini-agents-api |
Gemini Enterprise Agents API | 管理型Agentを作成、設定、更新、削除し、File・Skill・Toolを搭載 | 業務Agentの構築 |
gemini-api |
Google Cloud版Gemini API | マルチモーダル、Tool、生成、Cache、Batch、Live APIを扱う | Gemini組み込み開発 |
gemini-interactions-api |
Gemini Interactions API | 状態保持会話、非同期実行、Streaming、構造化出力、関数呼び出し | 対話型AIアプリ開発 |
gemini-live-api |
Gemini Live API | 双方向WebSocket、Session再開、Token更新を備えたClientを作る | 音声・映像のリアルタイムAI |
B.BigQuery・データ分析(6)全機能を見る
| Skill名 | 対象サービス | できること | 想定業務 |
|---|---|---|---|
bigquery-basics |
BigQuery | Dataset、Table、View、Job、SQL、データ投入を管理 | 分析基盤の基本運用 |
bigquery-bigframes |
BigQuery・BigFrames | pandasやscikit-learn風のPython分析・MLをBigQuery上で実行 | 大規模データのPython分析 |
datalineage-bigquery-asset-impact-analysis |
BigQuery・Data Lineage | 変更や削除で影響を受ける下流資産を特定 | データ変更前の影響調査 |
datalineage-summary |
BigQuery・Cloud Storage | データの上流・下流関係をMarkdownで要約 | データ来歴の説明資料作成 |
managed-airflow-dag-authoring |
Managed Airflow | DAGを作成・拡張し、Airflow 2・3互換性を検証 | データ処理の定期実行設計 |
managed-airflow-migrations |
Managed Airflow | Airflow 2.11.1や3への移行と破壊的変更を検査 | Airflow更新対応 |
C.インフラ設計・CLI・端末(4)全機能を見る
| Skill名 | 対象サービス | できること | 想定業務 |
|---|---|---|---|
design-deploy |
Google Cloud・Terraform | インフラ設計、HCL検証、配備、障害診断 | クラウド基盤の設計・構築 |
developer-device-platform-basics |
Developer Device Platform | 遠隔Android端末の予約、接続、延長、キャンセル | 実機テスト環境の利用 |
gcloud |
Google Cloud CLI | 末端Helpを確認し、破壊操作を見分けながらコマンドを提案・実行 | Google Cloudの横断操作 |
google-agents-cli-onboarding |
Google Agents CLI | CLIの導入と初期設定 | Agent開発環境の準備 |
D.ログ・監視・コスト・障害対応(14)全機能を見る
| Skill名 | 対象サービス | できること | 想定業務 |
|---|---|---|---|
cloud-logging-configuration-basics |
Cloud Logging | Log Bucket、Sink、View、IAM、指標、除外を設定 | 単一Projectのログ基盤構築 |
cloud-logging-cross-project-configuration |
Cloud Logging | 複数Projectのログを集約し、配送障害を診断 | 組織横断のログ管理 |
cloud-logging-query-generation |
Cloud Logging | 自然文からLogging Query Languageを生成 | 障害ログの検索 |
cloud-monitoring-chart-generation |
Cloud Monitoring | Dashboard用Chartのtextprotoを生成 | 監視画面の作成 |
cloud-monitoring-metric-selection |
Cloud Monitoring | 資源に合うMetric Descriptorを検索・選定 | 監視指標の設計 |
gke-ai-troubleshooting-handle-disruption-gpu-tpu |
GKE・GPU・TPU | 保守や中断を予測、診断、緩和 | AI計算基盤の中断対応 |
gke-ai-troubleshooting-tpu-vbar-oom |
GKE・TPU v6e | vbarクラッシュ、OOM、初期化失敗を診断 | TPU障害の原因調査 |
gke-cost-analysis |
GKE・BigQuery Billing Export | 請求とCluster指標から費用を分析 | GKE費用の見える化 |
gke-cost-optimization |
GKE | Rightsizing、Spot VM、CUD、Quotaを最適化 | GKE費用の改善 |
gke-observability |
GKE・Logging・Monitoring | Logging、Monitoring、Managed Prometheusを設定 | GKE監視基盤の整備 |
gke-tpu-metrics-monitoring |
GKE・TPU | 稼働率、Memory、Node状態、中断、MTTR・MTBIを監視 | TPU運用品質の把握 |
google-cloud-networking-observability |
VPC・NAT・Firewall | Flow Log、遅延、帯域、Connectivity Testを分析 | Network障害の調査 |
google-cloud-slo-alert-configuration |
Cloud Monitoring・SLO | PromQLベースのSLO AlertをTerraformで生成 | 信頼性目標の監視 |
workload-manager-basics |
Workload Manager | 評価、Rule、違反、BigQuery Export、自動化を管理 | Workloadの継続評価 |
E.GKE・コンテナ(17)全機能を見る
| Skill名 | 対象サービス | できること | 想定業務 |
|---|---|---|---|
gke-ai-troubleshooting-jobset-interruption |
GKE JobSet | 再起動、Spot中断、Node障害、Coordinator障害を診断 | 分散AI Jobの復旧 |
gke-app-onboarding |
GKE | アプリをContainer化し、初回配備・移行 | 既存アプリのGKE移行 |
gke-basics |
GKE | Cluster作成、認証、方式選択、基本配備 | GKEの導入 |
gke-batch-hpc |
GKE Batch・HPC | Job、Queue、並列処理を構成 | Batch・科学計算処理 |
gke-cluster-autoscaler |
GKE Autoscaling | Node自動作成とScale条件を設計・診断 | Cluster容量の自動調整 |
gke-cluster-creation |
GKE | 要件に合うCluster作成コマンドと構成を生成 | 新規Cluster構築 |
gke-compute-classes |
GKE ComputeClasses | Machine系列、GPU・TPU、優先順位、Fallbackを設計 | Workload別の計算資源設計 |
gke-golden-path |
GKE | 組織標準構成と開発者向け導線を設計 | Platform Engineering |
gke-inference |
GKE・AI推論 | オープンモデルなどの推論Workloadを配備 | 自社推論基盤の構築 |
gke-manifest-generation |
Kubernetes | Deployment、Service、JobなどのManifestを生成 | Kubernetes設定作成 |
gke-multitenancy |
GKE・IAM・RBAC | Namespace、RBAC、QuotaでTeamを分離 | 複数Teamの共同利用 |
gke-productionize |
GKE | 試作を可用性、運用、Securityを備えた構成へ強化 | 本番化レビュー |
gke-reliability |
GKE | 冗長化、PDB、障害耐性、DRを設計・評価 | 可用性改善 |
gke-tpu-dynamic-slices-monitoring |
GKE・TPU | Dynamic Slicesの状態、容量、障害を監視・管理 | TPU資源の運用 |
gke-upgrades |
GKE | Control Plane、Node Pool、Release Channelの更新計画と実行 | Cluster更新 |
gke-workload-scaling |
GKE・HPA・VPA | Podを需要に応じて拡縮 | アプリ容量の自動調整 |
gke-workload-troubleshooting |
GKE | Pod、Deployment、Service、Nodeの障害を診断 | 一般的なGKE障害対応 |
F.データベース(4)全機能を見る
| Skill名 | 対象サービス | できること | 想定業務 |
|---|---|---|---|
alloydb-basics |
AlloyDB | Cluster、Instance、Backup、MCP連携を管理 | PostgreSQL互換DBの運用 |
bigtable-basics |
Bigtable | Instance、Table、Schema、データ、性能を扱う | 大規模Key-Value DB運用 |
cloud-sql-basics |
Cloud SQL | Instance、DB、User、接続、Backup、HAを管理 | 業務DBの構築・保守 |
spanner-basics |
Spanner | Instance、DB、Schema、SQL、性能を扱う | 分散DBの設計・運用 |
G.Google Cloud開始・組織基盤(3)全機能を見る
| Skill名 | 対象サービス | できること | 想定業務 |
|---|---|---|---|
google-cloud-recipe-auth |
Google Cloud IAM・ADC | 人、Service Identity、ADC、権限、Impersonationを整理 | 認証方式の設計 |
google-cloud-recipe-foundation-builder |
Google Cloud組織基盤 | 組織階層、Billing、Policy、集中監視を備えた基盤を作る | 企業用Landing Zone構築 |
google-cloud-recipe-onboarding |
Google Cloud | Account、Billing、Project、最初のResourceまで案内 | 初めてのCloud導入 |
H.Google Ads・広告SDK(12)全機能を見る
| Skill名 | 対象サービス | できること | 想定業務 |
|---|---|---|---|
data-manager-api-audience-ingestion |
Data Manager API | Customer MatchなどのAudienceを追加、削除、全置換 | 広告Audience管理 |
data-manager-api-event-ingestion |
Data Manager API | Offline Conversion、拡張Conversion、Click、GA Eventを投入 | 広告成果データ連携 |
data-manager-api-setup |
Data Manager API | Client Library、認証、権限を設定 | Data Manager導入 |
google-ads-api-account-diagnostics |
Google Ads API | Conversion減、Lead不足、表示機会、Bid、Budget原因を診断 | 広告Account改善 |
google-ads-api-mcp-setup |
Google Ads・MCP | 公式MCPを導入し、自然文でCampaignや指標を取得 | AIによる広告分析環境構築 |
google-ads-api-quickstart |
Google Ads API | Token、OAuth、Library・RESTを設定しCampaignを取得 | Ads APIの初期接続 |
google-mobile-ads-android-migrate-to-next-gen |
Google Mobile Ads SDK | Androidの旧SDKを次世代版へ移行 | 広告SDK更新 |
google-mobile-ads-banner |
AdMob・Ad Manager | Android、iOS、UnityへBanner広告を実装 | アプリ広告掲載 |
google-mobile-ads-get-started |
AdMob・Ad Manager | Android、iOS、Unityへ広告SDKを導入 | モバイル広告の初期設定 |
google-mobile-ads-interstitial |
Google Mobile Ads | Android、iOSへ全画面広告を実装 | Interstitial広告掲載 |
google-mobile-ads-rewarded |
Google Mobile Ads | Android、iOSへRewarded広告を実装 | 報酬型広告掲載 |
ima-sdk-client-side |
Interactive Media Ads SDK | Web、App、TVへVAST・VMAP動画広告を実装 | Client側の動画広告配信 |
I.Google Analytics(2)全機能を見る
| Skill名 | 対象サービス | できること | 想定業務 |
|---|---|---|---|
google-analytics-admin-api-basics |
Google Analytics Admin API | Account、Property、Data Stream、Custom Dimension、Conversion、連携を管理 | GA4設定の構築・変更 |
google-analytics-data-api-basics |
Google Analytics Data API | User、Page View、日付、地域などを問い合わせ、Reportを生成 | GA4の定例分析 |
J.複数製品を組み合わせる設計(9)全機能を見る
| Skill名 | 対象サービス | できること | 想定業務 |
|---|---|---|---|
google-cloud-solution-agentic-ai-bidirectional-streaming |
Gemini・Streaming基盤 | 音声・映像を連続処理する双方向Multi-Agent基盤を設計 | Real-time対話Service設計 |
google-cloud-solution-agentic-ai-borderless-data-lakehouse |
Google Cloud・外部Cloud | Multi-cloud・On-premのLakehouseとAI Agentを統合 | 横断Data基盤設計 |
google-cloud-solution-agentic-ai-data-science-workflow |
Google Cloud Data・AI製品 | Agentを使うData Science・ML基盤を設計 | 分析開発Workflow構築 |
google-cloud-solution-agentic-analytics-spark-knowledge-catalog |
Spark・Knowledge Catalog | 外部Cloudを横断するAgentic Analyticsを設計 | 大規模分析基盤設計 |
google-cloud-solution-architecture |
Google Cloud全般 | 要件収集からEnd-to-end Architectureを設計・検証 | Cloud全体設計 |
google-cloud-solution-build-deploy-agents |
Agent Platform・Google Cloud | AI Agent・Multi-Agentを要件定義、構築、配備 | Agent Service開発 |
google-cloud-solution-guided-gke-ai-migration |
GKE・AI Workloads | Cloud Run、Gemini、VMなどの推論をGKEへ移行 | AI基盤移行 |
google-cloud-solution-n-tier-serverless-web-app |
Serverless・Network・DB | Private Tierを持つ安全なn-tier Web Appを設計 | 業務Web System設計 |
google-cloud-solution-rag-enterprise-search-gke-sqldb |
GKE・SQL DB・RAG | Open ModelとVector対応SQL DBで社内検索を設計 | Enterprise RAG構築 |
K.Networking(3)全機能を見る
| Skill名 | 対象サービス | できること | 想定業務 |
|---|---|---|---|
gke-networking |
GKE・VPC | Private Cluster、DNS、NAT、Egress、IPを設計 | Cluster Network構築 |
gke-service-networking |
GKE・Load Balancing | Gateway、Ingress、NEG、Cloud Armor、PSC、SSLを設定 | Service公開と防御 |
google-cloud-global-frontend-configuration |
Global Load Balancer・CDN | Global Frontend、CDN、Cloud Armorを設計・配備しDriftを検知 | Global Web配信基盤構築 |
L.Security(3)全機能を見る
| Skill名 | 対象サービス | できること | 想定業務 |
|---|---|---|---|
detection-engineering-coverage-evaluation |
Google SecOps | 脅威から検知機会、疑似Event、Coverage、YARA-L Ruleを作る | 検知Ruleの設計・評価 |
gke-platform-security |
GKE・IAM | RBAC、Binary Authorization、Shielded Nodes、Sandboxを強化 | Cluster Security監査 |
gke-workload-security |
GKE Workloads | Workload Identity、Network Policy、Pod Security、Secretを設定・監査 | Application Security強化 |
M.Serverless・Firebase(2)全機能を見る
| Skill名 | 対象サービス | できること | 想定業務 |
|---|---|---|---|
cloud-run-basics |
Cloud Run | HTTP Service、Job、Worker Poolを作成、配備、管理 | Web API・Batchの公開 |
firebase-basics |
Firebase | CLI導入、Login、Project作成・切替、App設定取得 | Firebase利用準備 |
N.Storage・Backup(4)全機能を見る
| Skill名 | 対象サービス | できること | 想定業務 |
|---|---|---|---|
gke-backup-dr |
Backup for GKE | Backup Plan、Restore、DR手順を構成 | Clusterの災害対策 |
gke-storage |
GKE Storage | PVC・PV、Filestore、Cloud Storage FUSEなどを構成 | Containerの永続Storage |
google-cloud-filestore-autoscale |
Filestore | 空き容量と費用条件で容量を拡大・縮小 | File Server容量管理 |
google-cloud-storage-basics |
Cloud Storage | Bucket、Object、IAM、Lifecycle、Retention、暗号化などを管理 | File保管・配信・保護 |
O.Well-Architected Framework(6)全機能を見る
| Skill名 | 対象サービス | できること | 想定業務 |
|---|---|---|---|
google-cloud-waf-cost-optimization |
Well-Architected Framework | 費用要件を評価し、削減・適正化案を出す | Cloud費用Review |
google-cloud-waf-operational-excellence |
Well-Architected Framework | 配備、監視、障害対応などの運用品質を評価 | 運用体制Review |
google-cloud-waf-performance-optimization |
Well-Architected Framework | 資源配分、伸縮性、構成の性能を評価 | 性能改善Review |
google-cloud-waf-reliability |
Well-Architected Framework | 可用性、冗長化、耐障害性、DRを評価 | 信頼性Review |
google-cloud-waf-security |
Well-Architected Framework | IAM、Network、Data保護、運用Securityを評価 | Security Review |
google-cloud-waf-sustainability |
Well-Architected Framework | 環境負荷とResource効率を評価 | Sustainability Review |
ここまでが、本体107スキルです。
長いよね。私も途中で「まだあるのか」となりました。
でも、全部並べたから見えたことがあります。これは「Googleに関係する日常業務ぜんぶ」ではない。Google Cloudを中心に、開発・データ・AI・広告・分析を深く扱う専門カタログです。
4.製品Plugin 16件の全体像と主な機能
Pluginは、製品ごとのSkill、Script、MCP設定などをまとめた実務パッケージです。
Skillが「進め方を教えるもの」なら、Pluginは「進め方と接続口をまとめた道具箱」に近い。
接続先によっては、実データの変更、クラウド資源の作成、費用の発生まで起こり得る。機能と外部作用を一緒に見てください。
16プラグインの全機能を見る開く
| Plugin名 | 対象製品 | 主な機能 | 起こり得る外部作用 |
|---|---|---|---|
alloydb |
AlloyDB | Cluster・Instance・User・SQL・健康診断・監視・最適化・複製 | DB作成、任意SQL、設定変更、費用発生 |
alloydb-omni |
AlloyDB Omni | 自社管理環境での構築、接続、データ操作 | Local・Server上のDBとデータ変更 |
bigtable |
Bigtable | 接続、Query、Table・Data操作 | 本番TableやDataの変更 |
cloud-sql-mysql |
Cloud SQL for MySQL | DB接続と操作 | 本番DBへの読み書き |
cloud-sql-postgresql |
Cloud SQL for PostgreSQL | Instance作成、接続、操作 | Resource作成、費用発生、Data変更 |
cloud-sql-sqlserver |
Cloud SQL for SQL Server | DB接続と操作 | 本番DBへの到達とData操作 |
firestore-native |
Firestore Native | 接続、Document・Data操作 | 本番Documentの作成・更新・削除 |
data-agent-kit-starter-pack |
BigQuery・dbt・Sparkなど | Notebook、Data Pipeline、分析基盤を横断支援 | 広い範囲のData基盤操作と計算費用 |
google-cloud-storage |
Cloud Storage | Bucket・Object・Transfer・IAM・Lifecycle・FUSE・Terraform | Upload、Delete、IAM・Retention変更 |
looker |
Looker | Model、Query、分析 | 組織のBI Dataへの接続とQuery実行 |
oracledb |
Oracle Database | DB接続、Query、Data操作 | Google製品外のDBにも読み書き |
spanner |
Spanner | 接続、Schema、Query、Data操作 | Resource・Schema・Data変更 |
knowledge-catalog |
Knowledge Catalog | 組織Knowledgeの検索と利用 | 組織内Knowledgeへの到達 |
dataproc |
Dataproc・Spark | JobとClusterの操作 | Compute Resource作成と費用発生 |
bigquery |
BigQuery | 自然文による分析、SQL、Data操作 | Query費用とData変更 |
db-context-engineering |
Database・NL-to-SQL | Template、Facet、Value Search、Context Set生成 | DB Schemaや値の読み取り |
データベース系Pluginは、接続後の影響が大きい
たとえばalloydb Pluginは、さらに管理、権限、データ、健康診断、監視、最適化、複製という7領域へ分かれる。
任意SQLを実行できるため、分析だけでなく変更も可能です。認証情報を環境ファイルから探す設計もある。
これは便利。
でも、ぶっちゃけ「つながった!」と喜んでいる時がいちばん危ないかもしれません。大事なのは、その接続で何を読めて、何を変えられるのか。
だからこそ、どの作業フォルダを見せるか、どの認証情報を渡すか、どこまで書き込みを許すかを先に決めます。
Skill単体で足りる仕事と、Plugin・MCPが向く仕事
用語を理解したい。設計案を作りたい。正しいコマンドや確認手順を知りたい。
その段階なら、Skill単体で役立つ場面が多いです。
一方で、実際のDBへ接続してQueryを回す、Cloud StorageのObjectを操作する、実資源の状態を取得するといった仕事では、PluginやMCPが力を発揮する。
要するに、「知る・設計する」と「つなぐ・動かす」の違い。
包丁の使い方を教わるのがSkill。実際に包丁を持って厨房へ入るのがPluginやMCP。厨房へ入るなら、どこまで切っていいかも決めておこう、という話です。
5.公式READMEが案内する追加エコシステム7系統
公式READMEには、本体とは別のリポジトリで更新されるGoogle関連Skillも案内されています。
本体107本とは別枠だ。導入元と更新時期が異なるため、同じものとして数えないようにしてください。
追加7系統の機能を見る開く
| 追加系統 | 主な対象 | できること |
|---|---|---|
| Advanced Google Cloud Storage | Cloud Storage | 基本操作、FUSE、403診断、Security評価、IAM、Retention、Lifecycle、Terraform、MCP |
| Agent Development Kit・Google Agents CLI | ADK・Agent開発 | Code作成、ひな型生成、評価、配備、Agentの運用Life Cycle |
| Android Skills | Android | AGP更新、CameraX、端末AI、Compose、Media3、Navigation、R8、Security、Test、TV、Wear、XRなど |
| Dart Skills | Dart | Unit Test、CLI App、Coverageなどの開発Workflow |
| Firestore Skills | Firestore | Schema、Security Rule、Query、Application連携 |
| Flutter Agent Plugins | Flutter・Dart | Skill、Rule、MCPをまとめたFlutter開発Workflow |
| Genkit Skills | Genkit | JavaScript・TypeScript、Dart、Go、PythonでGenkit Appを開発 |
この追加系統まで見ると、Google Cloudの運用だけでなく、AndroidやFlutterの開発まで一気に広がる。
ただし、GmailやCalendarなどの一般的なGoogle Workspace操作が、この本体カタログへ網羅されているわけではありません。
6.google/skillsを実際に使うには
1.カタログをAIエージェントへ追加する
Agent Skillsに対応する環境では、公式READMEの導入コマンドから始めます。
npx skills add google/skills
この操作で、カタログから利用するSkillを選べます。
Claude Codeで製品Pluginを使う場合は、Marketplaceを登録し、目的のPluginを指定する。
claude plugin marketplace add google/skills
claude plugin install <plugin-name>@google-plugins
CodexではPlugin Marketplaceへgoogle/skillsを追加し、Plugin画面から選ぶ。Antigravity CLIにも、PluginのPathを指定する導入方法がある。
コマンドや画面は更新される可能性がある。実行時は公式READMEを確認してください。
2.認証・API・権限を確認する
Skillを追加しただけでは、Googleの実データは取得できません。
対象に応じて、次を確認します。
- 利用するGoogleアカウント
- 対象のGoogle Cloud ProjectやGA4 Property
- Google Cloud CLIやApplication Default Credentials
- 必要なAPIが有効か
- 読み取り、作成、更新、削除のどこまで許可されているか
認証エラーは、Skillの不具合とは限りません。対象Projectの違い、API未有効、権限不足でも止まります。
3.自然な日本語で、目的と境界を伝える
Skill名をそのまま入力しなくても、対応するAIエージェントが依頼内容からSkillを選ぶ設計です。
ただ、「GA4を見て」だけだと、AIも困る。
どの期間を、何と比べて、どこまで触っていいのか。人へ頼む時と同じで、仕事の境界を渡した方がうまくいきます。
たとえば、次のように頼みます。
GA4の直近7日と、その前の7日を同じ条件で比較してください。ユーザー、セッション、ページビュー、流入チャネル、増減上位ページを読み取り専用で取得してください。書き込みは行わず、取得時刻と未確認事項も分けて報告してください。
これなら、目的、対象期間、指標、読み取り専用、報告形式がそろう。単なる質問ではなく、仕事として渡せるんだよね。
4.外部作用に合わせて確認を変える
読み取りと、作成・更新・削除では、確認の重さが違います。
- 読み取り:対象Account、対象期間、取得件数、Dataの鮮度
- 作成:作成先、Resource名、費用、公開範囲
- 更新:変更前後、対象件数、戻し方
- 削除:対象の特定、復旧可能性、最終承認
AIへ仕事を委ねることと、確認を手放すことは同じではありません。
7.仕事別・google/skills活用ガイド
107本の名前を覚える必要はありません。
先に「何を判断したいか」「どの仕事を進めたいか」から見てみよう。
| 仕事 | 主な候補 | 活用例 | 人間が決めること |
|---|---|---|---|
| 経営・サイト運営 | Analytics Data API | 7日比較、流入変化、増減Pageの把握 | 何を改善するか、どこへ資源を使うか |
| Marketing | Analytics、Google Ads、Data Manager | 広告成果、流入、Conversion減少の診断 | 訴求、予算、顧客との関係 |
| Data活用 | BigQuery、BigFrames、Data Lineage | 集計、予測、異常検知、変更影響調査 | どの数字を信じ、何を判断するか |
| AI Service開発 | Gemini API、Agent Platform、RAG | 対話AI、社内検索、Model評価・配備 | 利用目的、品質基準、責任範囲 |
| Web・App開発 | Cloud Run、Firebase、GKE | 構築、公開、拡張、監視 | 顧客価値、公開条件、運用方針 |
| Infrastructure運用 | GKE、Logging、Monitoring、WAF | 障害対応、費用・性能・信頼性改善 | 許容Risk、予算、優先順位 |
| Security | GKE Security、SecOps | 設定監査、検知範囲評価、Rule案作成 | 承認、例外、事業Riskの受容 |
| Cloud導入 | Onboarding、Auth、Foundation Builder | Accountから組織基盤までの設計 | 組織構造、権限、統制方針 |
経営・サイト運営——数字を判断材料へ変える
小規模事業で入り口にしやすいのは、すでに持っているデータを読む仕事。
GA4の7日比較なら、売上や集客を直接変更せず、現状を見られます。毎週同じ条件で取れば、「なんとなく悪そう」だけで会議を始めずに済むんだよね。
ただし、数字が出た瞬間に結論を決めないこと。
増減を見つけるのはAIに任せやすい。
でも「先週はLIVEを休んだ」「メルマガを出した」「計測設定を変えた」という現場の出来事は、人間の側にあります。数字と出来事がつながって、初めて判断になる。
Marketing——分析と実行を分ける
Google Ads系には、Account診断、API接続、AudienceやEventの投入、Mobile広告の実装まであります。
同じ「広告」の中でも、指標を読む仕事と、AudienceやConversion Dataを書き込む仕事は影響が違います。
分析は読み取り権限で始める。配信設定やData投入は、対象Accountと変更内容を確認してから進める。
同じ広告の仕事でも、見るのと書き換えるのは別物。ここは混ぜない方がいい。
Data・AI・Infrastructure——専門家の手順を共有する
BigQuery、GKE、Agent Platformなどは、製品ごとの概念が多く、設定の組み合わせも複雑です。
公式Skillの価値は、単にコマンドを生成することではない。認証、設計、失敗しやすい点、検証方法まで同じ流れで扱えることです。
担当者の頭の中だけにあった進め方をAIと共有できれば、調査や初動を横に広げられます。
そして人間は、設計の意図、顧客への影響、例外判断を深く考える。
8.公式Skillと自作Skillをどう組み合わせるか
公式Skillと自作Skillは、どちらか一つを選ぶものではありません。
私も最初は「公式があるなら、自作はいらないのでは?」と思った。でも、実際にGA4で動かすと役割が違ったんです。
| 層 | 担当すること |
|---|---|
| Google公式Skill | Google製品のAPI・CLI・認証・設計・失敗回避・検証方法 |
| Plugin・MCP | 実際のGoogle Resource、DB、Dataへ接続する操作口 |
| 自作Skill | 自社の目的、判断基準、報告形式、運用周期、承認境界 |
| 人間 | 意味づけ、優先順位、例外、責任を伴う最終判断 |
Googleの専門手順に、自分の仕事のルールを重ねる
たとえば、Google公式のAnalytics Skillは、GA4 Data APIを正しく呼ぶ方法を担当する。
でも、「毎週どの数字を見るか」「何%変化したら調べるか」「どの会議へ渡すか」「Dataが古い時はどう止めるか」は、その会社の仕事です。
そこは自作Skillで決めます。
公式Skillが専門部品。自作Skillが、うちの仕事に合わせた設計図。
この組み合わせで、便利なToolが自分たちの仕事へなじんでいきます。
小さなSkillをつなぎ、再現できるWorkflowへ
私が大切にしているのは、一度うまくいった作業を、その場のまぐれで終わらせないことです。
取得、整理、判断材料の作成、確認。それぞれの役割を分け、順番につなぎます。
AIは横に広げるのが得意です。
人間は縦に掘る。
「なぜこの数字を見るのか」「この変化はお客様に何を意味するのか」。ここを掘るのは、私たちの仕事なんだよね。
9.実践検証——GA4の公式Skillを実際に使ってみた
一覧を眺めているだけでは、結局「使えそう」で止まります。
なので——動かしてみた。
今回選んだのはgoogle-analytics-data-api-basics。
GA4の指標やDimensionを指定し、独自Reportを取得するための公式Skillです。
検証環境
| 確認項目 | 実測結果 |
|---|---|
| Google Cloud CLI | 導入済み、Version 565.0.0 |
| Active Account | 1 |
| Active Project | bunshin-ai |
| 閲覧可能Project | 25 |
| Analytics Data API | 有効 |
| GA4用OAuth | 既存認証を利用、追加Loginなし |
| 実行時間 | 約6秒 |
| GA4への書き込み | 0 |
対象は、このブログai-kidou.jpのGA4。サンプルデータではありません。
今期を2026年8月7日から13日、前期を7月31日から8月6日として、同じ7日間で比較しました。
主要指標はいずれも約28〜30%減少
| 指標 | 今期 | 前期 | 前期比 |
|---|---|---|---|
| Active users | 653 | 927 | -29.6% |
| Sessions | 790 | 1,122 | -29.6% |
| Page views | 921 | 1,279 | -28.0% |
ここだけ見ると、「うわ、サイト全体の集客が落ちてる」と感じます。
でも、原因はまだ分からない。
そこで流入チャネルを分けました。
セッション減少の中心はDirectだった
| 流入Channel | 今期Sessions | 前期Sessions | Sessions差分 |
|---|---|---|---|
| Direct | 323 | 574 | -251 |
| Organic Search | 403 | 435 | -32 |
| Organic Social | 39 | 70 | -31 |
| AI Assistant | 7 | 18 | -11 |
最大の減少はDirectの-251。
検索じゃない。
Organic Searchの減少は-32でした。
つまり、「セッションが落ちた。SEOが崩れたのかも」と走り出す前に、Directの前週要因、計測分類、配信導線を見た方がいい。
これは実測値から導いた確認方針。Directが減った原因そのものを特定したわけではありません。
減少したページ
| Page | 今期PV | 前期PV | 差分 |
|---|---|---|---|
/ |
108 | 165 | -57 |
/graph-engineering-guide/ |
22 | 64 | -42 |
/blog/ |
16 | 56 | -40 |
/genspark-6-japanese-review/ |
3 | 18 | -15 |
/datsu-chatgpt-claude-code-5things/ |
4 | 19 | -15 |
増加したページ
| Page | 今期PV | 前期PV | 差分 |
|---|---|---|---|
/ai-voice-mode-comparison-2026/ |
60 | 17 | +43 |
/gemini-notebook-notebooklm-update/ |
23 | 0 | +23 |
/lm-studio-bionic-local-llm-privacy-ai/ |
20 | 3 | +17 |
/ainews-20260812/ |
16 | 0 | +16 |
/chatgpt-profile-poster/ |
11 | 0 | +11 |
下がったページがある一方で、伸びたページもあります。
全体平均だけでは、この動きは見えません。
約6秒。
その短い取得で、全体、流入、ページという3つの深さまで見られた。速さより、「次にどこを見るか」が変わったことの方が、私には大きかったです。
10.GA4の検証結果を、実際にどう活用したのか
ここで終わると、「AIで数字が取れました」という実演です。
それだけでは、来週また同じ作業をすることになる。仕事はあまり変わりません…。
今回の取得項目を「GA4 7日差分パルス」という週次の判断材料へつなげました。
毎回、同じ条件で次を出します。
- Active users、Sessions、Page viewsの直近7日と前7日
- 増加・減少したPage
- 流入Channelの差分
- 取得時刻、認証状態、書き込み0の記録
- 取得失敗時の
BLOCKED
なので、構想だけで終わらせず、この形式を週次処理へ実装しました。
別の取得時点で、2026年8月8日〜14日と8月1日〜7日を比較した結果は、Active users 688、Sessions 826、Page views 970。GA4パルスの検証テストは10件すべて通過し、実機確認を含む24回のrunReportも読み取り専用、Analyticsへの書き込み0だった。
一度取れた数字を自慢したかったわけではありません。
同じ条件で取り直せる。失敗したら、古い数字で話を進めず止まる。そこまで含めて、やっと仕事で使える仕組みになったと思っています。
「主要指標が落ちた」から「どこを確認するか」へ
この形式なら、会議を「何となく悪そう」で始めなくて済みます。
まず事実をそろえる。変化が大きい場所を見る。
それから、配信、記事公開、キャンペーン、計測変更など、現場の出来事と照らす。
今回なら、最初の確認先はSEO全体ではなくDirectです。
AIが答えを決めるのではなく、人間が掘る場所を絞る。これが7日差分パルスの役割です。
事実・推論・未解決を分ける
| 区分 | 今回の内容 |
|---|---|
| 確認できた事実 | 3指標が減少し、Channel別Sessions差分ではDirectの減少が最大 |
| 次の確認方針 | Directの前週要因、計測分類、配信導線から確認する |
| まだ分からないこと | Direct減少の原因、長期傾向、計測変更の影響 |
ここを混ぜると、AIの推測が「原因だった話」に化けます。
事実は事実。次に見る場所は仮説。まだ分からないことは、分からないまま残す。地味だけど、この分け方が効くんだよね。
Google Search ConsoleのBLOCKEDは別問題
GA4の取得は成功した。
一方、既存のGoogle Search Console側のDataは、初回確認で122.4時間前、後続確認では144.0時間前だった。鮮度上限26時間を超えているため、こちらはBLOCKEDのままです。
GA4が動いたからといって、Google Search Consoleまで正常になったことにはしません。
一つ動いたから、全部動いたことにしない。
これも、AIを実務で使う時の約束です。
11.導入・利用前に知っておきたい注意点
Skillを追加しても、認証や権限は自動で増えない
接続できなければ、アカウント、プロジェクト、API、権限を確認します。
逆に、強い権限ですでにログインしている場合は、その権限で届く範囲が広いことにも注意が必要です。
読み取り・書き込み・削除を分ける
同じ製品でも、データ取得と設定変更では影響が違います。
GA4ならData APIはReport取得、Admin APIはPropertyやConversionなどの管理を扱う。
名前が近くても役割は同じではありません。
公式でも、結果の照合は必要
公式Skillは、公式手順へ寄せるための大切な材料です。
でも、対象Projectを取り違える、期間条件を間違える、権限不足で一部しか取れない、といったことは起こり得ます。
実行後に見るのは、対象、件数、期間、変更数、エラー。
開発中のカタログとして扱う
Google公式READMEにも、開発中だと明記されています。
Skill名も内容も、Pluginのバージョンも変わる。この記事を作っている間にも、直接Skillは107本から109本へ増えました。
だから導入時は、コミットや取得日を残しておく。あとから「いつの手順だった?」を追いやすくなります。
認証情報を見せる範囲を決める
一部Pluginは環境ファイルを探し、そこから認証情報を利用する設計です。
作業フォルダ、認証情報、アカウントを分ける。必要なプロジェクトだけに権限を絞る。書き込みが不要なら読み取り権限にする。
便利さより前に、ここを決めておこう。ブレーキのない車を速くしても、安心して乗れないからね。
12.自分の仕事でgoogle/skillsを活用する手順
1.Google製品を使っている定型業務を書き出す
毎週見ている数字、定期的な障害確認、データ集計、クラウド設定の見直しなどを書き出します。
製品名より、「何を判断するための仕事か」を先に言葉にします。
2.107スキルと16プラグインから対応機能を探す
この記事の15分類と仕事別表から候補を探します。
手順を知りたいのか。実データへ接続したいのか。作成や更新まで任せたいのか。
ここでSkillとPluginを分けます。
3.認証・CLI・API・権限を確認する
対象アカウント、プロジェクト、APIの有効化、認証情報、読み書き範囲を確認します。
課金されるリソースを作る可能性がある場合は、費用と停止方法も先に決めます。
4.実データで機能と結果を確かめる
説明を読んだだけで終わらせず、実環境で結果を確認します。
実行時間、取得件数、変更件数、エラー、データの鮮度を記録します。
5.自分の判断基準と日常業務へつなげる
一度の成功を、同じ条件で再現できる形にします。
誰が見るか。どの周期で動かすか。失敗したらどう止めるか。次に何を判断するか。
ここを自作Skillで補う。
あ、最初から大きな自動化を作らなくて大丈夫。私も今回、まずは7日比較を一回動かすところから始めました。その一回で「毎週同じ形にしたい」が見えたんです。
公式SkillはGoogle部分の専門手順。
自作Skillは自分たちの目的と判断。
この役割分担ができると、AIは単発の便利機能ではなく、仕事を一緒に進める分身へ近づきます。
13.よくある質問
プログラミングができなくても使えるのか
自然な日本語で依頼できる部分は多い。
ただし、Google Cloudの認証、API、権限、費用、障害対応には技術知識が必要な場面があります。特にResource作成やData更新を行う時は、結果を確認できる人と進めてください。
Googleアカウントがあれば、すぐ使えるのか
Accountだけでは足りない場合もある。
対象Serviceの利用状態、Project、APIの有効化、OAuthやADC、IAM権限などが必要です。GA4の検証では既存OAuthを使えたため、追加Loginなしで動きました。
SkillとPluginは、どちらを使えばよいのか
まず専門手順や設計を使いたいならSkill。
実際の製品へ接続し、QueryやResource操作まで行いたいならPluginやMCPが候補です。
その場合は、外部作用と認証権限も一緒に確認します。
会社のDataをAIに扱わせても大丈夫なのか
扱うData、利用するAI環境、保存先、契約、権限によって判断が変わる。
まずData分類を行い、必要な範囲だけを渡してください。Credentialや顧客情報を広いDirectoryへ置いたまま使うのは避けます。
自社専用のSkillへ発展させられるのか
答えは、できる。
Google公式Skillが取得・操作の専門手順を担当し、自作Skillに自社のKPI、判断条件、報告形式、承認境界を持たせます。
GA4 7日差分パルスが、その一例です。
14.まとめ——全機能を知り、仕事に合わせて活用する
107本を見終えて、いちばん強く感じたこと。
google/skillsは、Googleの全サービスを自動化してくれる万能AIではありません。
でも、それでいいんです。
Google Cloud、Gemini、Agent Platform、GKE、データ基盤、広告、Analytics。こうした専門分野で、AIが思いつきではなく公式の手順を読んで動ける。そこに価値がある。
2026年8月13日の固定調査では、直接Skillが107本、製品Pluginが16件、追加エコシステムが7系統。
数字だけ見ると、大きなカタログです。
でも私にとっての収穫は、107という数ではありません。GA4 Skillを約6秒、書き込み0で動かし、「全体が落ちた」から「まずDirectを見よう」へ、次の行動が変わった。そこです。
さらに、その一回を「GA4 7日差分パルス」へつないだ。毎週同じ条件で取り、失敗したら古い数字でごまかさず止まる。ここまで来て、ようやく便利な機能が仕事になりました。
AIは横に広げる。
人間は縦に掘る。
公式Skillには、Googleの専門手順を任せる。
自作Skillには、私たちの目的と判断基準を入れる。
この二つが噛み合うと、AIは「詳しいことを答える人」から、同じ現場で一緒に働く分身へ変わっていきます。
まずは、毎週くり返しているGoogleの仕事を一つだけ書き出してみてください。
GA4を見る。広告の数字を確認する。BigQueryの集計をする。何でもいい。
一個でいいんです。
そこから一緒に始めよう。
補遺——2026年8月16日に追加された2スキル
コミットc4591645から8f57a0dまでに、直接Skillが2本追加されました。
| Skill名 | 対象サービス | できること | 想定業務 |
|---|---|---|---|
ima-dai-sdk |
Interactive Media Ads Dynamic Ad Insertion SDK | DAI方式の動画広告を組み込むための専門手順 | Live・On-demand動画へのServer-side広告挿入対応 |
cloud-monitoring-list-time-series-request |
Cloud Monitoring API | Metricと条件に合うListTimeSeries Requestを組み立てる |
時系列Metric取得のQuery作成 |
この2本を加えた2026年8月16日時点の公式mainは、直接Skill 109本です。
参考資料
本記事の107スキル固定調査とGA4実機検証の数値・実行回数は、2026年8月13日〜15日の検証ログに基づきます。公開記事から開けない内部URLや識別子は掲載していません。