コーディングエージェントにGoogle Cloudの構築やデプロイを手伝わせると、古いSDKの書き方を使う、gcloud の存在しない引数を推測で書く、権限の足りない操作を試す、といった失敗が起こり得ます。さらに困るのは、課金のあるAPIの有効化やリソースの作成を、確認なしに進めてしまうおそれがあることです。Google Cloudの公式ブログも、この点を課題に挙げています。
Google Cloudは2026年11月3日、Googleのエージェント型の開発環境Antigravity向けに、こうした問題を減らすプラグイン「google-cloud-developer」を、Antigravity Marketplaceの「Build with Google」で公開したと公式ブログで発表しました。この記事では、プラグインに含まれるものと、ガードレールの中身、チームで入れる前に決めておくことを整理します。
プラグインに含まれるもの
ブログによると、プラグインは、基本のスキル、ルーティングの規則、Developer KnowledgeのMCPサーバーを1つにまとめたものです。目的として、次の3つを挙げています。
- 最新の文書にもとづく回答: エージェントが、Google Cloudの公式の文書をストリーミングのHTTPで問い合わせる
- 安全と費用のガードレール: 最小権限のIAMの型に沿わせ、課金のあるAPIの有効化やインフラの変更の前に、利用者の同意を求める
- 環境の把握: ローカルの環境と既存のCLIの設定を調べ、コマンドを実行する前に安全な実行の計画を立てる
同梱されるスキルは5つです。
| スキル | 役割（ブログの記載） |
|---|---|
finding-google-skills | GitHubの google/skills のリポジトリから、必要なスキルを見つけて必要なときに読み込む |
retrieving-developer-knowledge | Google Cloud、Firebase、Android、Web、Geminiの公式の文書にもとづく回答とコード例を返す |
gcloud | gcloud のコマンドの文法を確かめ、安全の確認をかける。誤って行う破壊的な操作を止める |
google-cloud-recipe-auth | サービスのIDとApplication Default Credentials（ADC）を使う認証へ誘導し、サービスアカウントのJSONの鍵のダウンロードのような危険な方法を止める |
google-cloud-recipe-onboarding | プロジェクトの初期の設定、アカウントの準備、請求の確認を案内する。サービスを有効にする前にプロジェクトの状態を確かめる |
GitHubの google/skills にあるプラグインの本体（2026年11月6日の時点で版1.1.17）でも、同梱のスキルはこの5つでした。同じプラグインは、Claude CodeやCodex CLIにも入れられます。
ほかに、google-cloud-discovery.md というルーティングの規則が入っています。依頼が専門的な話題に触れると、この規則と finding-google-skills が組み合わさり、公開のカタログから関係するスキルを取りに行きます。数十の専門のスキルを最初から読み込まずに済むため、コンテキストを圧迫しにくい、とブログは説明しています。
入れ方と、MCPサーバーの認可
入れ方は、Antigravity MarketplaceのUIか、ターミナルの1行のコマンドです。
agy plugin install google-cloud-developerブログによると、CLIはスキルを登録し、Developer KnowledgeのMCPサーバーにすぐ接続します。通常、MCPサーバーを足すにはAPIキーの扱いが要りますが、Marketplaceの「Build with Google」のカタログからは、このMCPサーバーが事前に認可されており、認証はAntigravityが管理します。APIキー、OAuthのトークン、設定ファイルの編集は要らないとしています。
これは、資格情報を使わないという意味ではありません。Antigravity向けの設定は authProviderType: google_credentials で、Developer Knowledgeのドキュメントも、Antigravityは利用者の有効なGoogleの資格情報で接続すると説明しています。Claude CodeとCodex CLIでは、APIの有効化とAPIキーの設定の手順がリポジトリのREADMEに載っています。「キーが要らない」のは、Antigravityから使う場合の話です。
入れたあとは、特別な書き方をしなくても、エージェントが回答の根拠に最新の文書を使うとしています。ブログの例は「文書にもとづくと、GKEとCloud Runの主な違いは何か。どちらをいつ使うべきか」という問いです。
スキルの本文で確かめたガードレール
ブログの「止める（blocks）」が何を指すのかを、リポジトリのスキルの本文で確かめました。ガードレールは、エージェントへの指示として書かれています。
gcloud: 「自律的に実行しない」一覧に、IAMのポリシー・ロール・バインディングの変更、APIの有効化、gcloud * delete、gcloud billing *、gcloud organizations *、gcloud kms *、gcloud infra-manager deployments applyを挙げ、利用者の明示の承認を求めているgoogle-cloud-recipe-onboarding: プロジェクトの作成と請求先の紐づけの前に、内容の表を示して同意を待つよう指示している。個人の開発者の最初の設定を想定したスキルで、Google WorkspaceやCloud Identityの組織に属するアカウントでは、このスキルの実行を止めてGoogle Cloud Setupの案内へ誘導するgoogle-cloud-recipe-auth: ブログは鍵のダウンロードを「止める」と書いているが、スキルの本文は、鍵をローカルで使おうとする利用者に「強く思いとどまらせ、なりすまし（impersonation）を勧める」という書き方になっている
もう1つ、gcloud のスキルは、実行するコマンドのすべてに --quiet を付けるよう指示しています。エージェントの実行環境では確認の入力を待てないためです。--quiet を付けると、gcloud は確認を待たず、既定の選択で進むか、必須の値がなければエラーで止まります。そのため、gcloud 自身の確認の画面は歯止めになりません。止められるかどうかは、エージェントが指示に従うかどうかと、Antigravity側の実行の許可の設定で決まります。読んだ範囲のスキルの本文に、コマンドの実行を技術的に遮断する仕組みは書かれていません。
編集部の提案：チームで入れる前に決めること
ここまでのとおり、ガードレールは、エージェントに読み込ませるスキルと規則による振る舞いです。ブログもこれをIAMの権限の制限の代わりとは書いていません。チームの開発環境に入れる前に、次の点を決めておくことを提案します。
エージェントに渡す認証情報の範囲は、IAMで絞る。 スキルが同意を求めても、エージェントが使う資格情報に広い権限があれば、同意の操作1つで大きな変更ができます。開発用のプロジェクトを分け、エージェントの資格情報には必要なロールだけを付けます。サービスアカウントの鍵を配らない構成は、鍵レスのWorkload Identity連携の記事で扱いました。
取りに行くスキルの出どころを把握する。 専門のスキルは、GitHubの google/skills のリポジトリの main ブランチから、必要なときに取得されます。finding-google-skills が読むカタログ（index.json）の186件の参照先は、2026年11月6日の時点ですべて main でした。プラグインに同梱の部分は入れた版で固定されますが、取得したスキルはその時点の内容で、規則の説明ではセッションの終わりに消えます。リポジトリの内容が更新されれば、エージェントの振る舞いも変わり得ます。スキルの本文と規則に、特定の版へ固定する手順は書かれていません。どの版が使われたかを後から確かめたいチームは、記録の方法を別に考える必要があります。社内のプロキシの内側で使う場合は、raw.githubusercontent.com、api.github.com、developerknowledge.googleapis.com などへの通信の許可も要ります。google/skills についてはGoogle公式Agent Skillsリポジトリの記事、Google Cloudの別のスキル群の権限の考え方はIAM Helperの記事も参照してください。
同意の操作の担当を決める。 課金のあるAPIの有効化やインフラの変更に同意するのは、エージェントを操作している開発者です。どの操作を開発者の判断で許し、どの操作を別の担当の承認にするかを決めておきます。リポジトリの案内は、gcloud projects create、gcloud billing projects link、gcloud services enable などの状態を変えるコマンドを、自動の許可に入れず、確認（Ask）を挟むか手で実行するよう書いています。
文書のMCPサーバーへ送られる内容を確かめる。 回答のために、エージェントの問い合わせが developerknowledge.googleapis.com へ送られます。ブログとリポジトリは、問い合わせに何が含まれ、どう保持されるかには触れていません。なお、11月5日の版（1.1.17）で、MCPの設定に、プラグインの名前と版を示すヘッダーが加わりました。gcloud のコマンドにも利用の集計のタグを付けるよう指示されています。このタグについて、スキルの説明は、スキルと版だけを示し、利用者のデータは含まないとしています。
Antigravityの利用規約を確かめる。 Antigravityの追加の利用規約は、利用の記録（Interactions）を保存し、製品や機械学習の改善に使うこと、Googleの担当者が見る場合があることを書き、機密の情報を送らないよう求めています。使われ方は設定で変えられます。Gemini EnterpriseやGoogle Workspaceの契約などで使う場合は、管理者が合意した規約が適用されます。ただし同じ規約に、企業向けなどの契約の条件はAntigravity Marketplaceの利用には適用されない、とも書かれています。社外秘のコードや設定を扱うプロジェクトでは、Marketplaceからプラグインを入れる前に、法務と情シスで確かめてください。
確認した範囲
2026年11月6日に、Google Cloud公式ブログの記事「Google Cloud Developer plugin now available in Antigravity Marketplace」（2026年11月3日）、GitHubの
google/skillsのプラグインの本体（版1.1.17のスキルの本文、規則、設定、README）、AntigravityのMarketplaceのドキュメントと追加の利用規約、Developer Knowledge MCPのドキュメントを開いて照合しました（資料調査）。プラグインを入れての検証はしていないため、スキルの指示どおりにエージェントが動くかは未確認です。Antigravityのプラン別の料金、MCPサーバーへ送られた問い合わせの保持と扱いも未確認です。
AIのエージェントを開発の流れに入れるときの権限の設計は、開発・AI・自動化のご相談からお問い合わせください。
