AIコーディングエージェントを全社に配る前に決める8つの統制｜Antigravity企業向け拡張から読む

起きたこと

開発向けエージェント環境であるAntigravityについて、Google Cloudは2026年8月21日に企業向け提供の拡張を発表しました。公式の記載によれば、対象となるGemini Enterpriseのアプリケーションサブスクリプションの一部として提供され、管理者向けの管理機能と支出管理があらかじめ組み込まれています。

利用できる環境としては、新しいIDE拡張により開発者が好みの開発環境で使えるようになったとされ、Visual Studio Code、Visual Studio（プレビュー）、JetBrains（プレビュー）、Zed（プレビュー）が挙げられています。加えて、Antigravity 2.0のデスクトップアプリとCLIも示されています。

企業向けの管理機能として、公式が挙げているのは次のとおりです。

なお、有効化の対象は「対象となる」Gemini Enterprise Standard、Plus、Standard Emerging Marketのライセンスを持つ利用者と記載されています。すべてのGoogle Cloud利用者が無条件に使えるという発表ではありません。IDE拡張のうち複数はプレビュー段階と明記されています。また、支出の管理については、月次のプロジェクト単位の予算上限に加えて、利用者単位・チーム単位の支出制御が年内に順次提供されると記載されています。

支出上限そのものにも条件があります。 Google Cloudの公式ドキュメントによれば、この予算上限はプレビュー段階の機能です。適用の単位はプロジェクトと対象サービスがそれぞれ1つずつで、サブスクリプションに基づく費用は範囲外とされています。停止は即座に効くわけではなく、上限を超えて発生した利用料は請求されます。「上限を設定したから使いすぎは止まる」とは読まないでください。現時点で使える機能と、これから提供される機能、そして条件付きの機能を分けて整理する必要があります。

製品の話として読むと、判断を誤る

この発表を「Googleの開発ツールが便利になった」と読むと、自社の意思決定には使えません。読み替えるべきは、企業がコーディングエージェントを配布するときに、管理者が持つべき制御の一覧が具体化されたという点です。

ここで挙げられている管理項目は、そのままGXOが発注支援の場で確認している論点と重なります。製品を評価する前に、経営が決めるべきことがあるという意味です。すなわち「自社ではエージェントに何をさせ、何をさせないか」です。ここが決まっていないと、どの製品を選んでも設定値の議論に降りられません。

全社配布の前に決める8つの統制

以下は、製品を問わず決めておくべき項目です。決定は情報システム部門だけでは完結しません。ソースコードと本番環境の扱いは、経営の判断事項です。

1. 誰のアカウントで動かすか 個人アカウント、企業アカウント、サービスアカウントを分けます。個人アカウントでの利用を放置すると、退職時に何が残るか追えなくなります。企業IDとの連携を前提にするかどうかを最初に決めてください。

2. ソースコードの扱い どのリポジトリを対象にするか、対象外にするコードはあるか、秘密情報がコードやコメントに含まれていないかを確認します。契約上の制約があるコード（顧客から預かったもの、共同開発のもの）は、特に切り分けが必要です。

3. 実行できる操作の範囲 サンドボックスの中で完結させるのか、開発者の端末の任意のコマンドを実行できるのかは、リスクが大きく違います。ファイルの削除、パッケージのインストール、外部への通信をどこまで許すかを決めます。

4. 外部ツールへの接続 MCPのようなプロトコルで外部ツールへ接続できる場合、接続先を許可制にするか自由にするかを決めます。許可制にするなら、誰が追加を承認するかまで決めてください。

5. ブラウザ操作 エージェントがブラウザを操作できる場合、ログイン済みのサービスを操作できてしまう可能性があります。購入、設定変更、送信といった操作を許すかどうかは、開発の話ではなく統制の話です。

6. 記録 何を記録するか、どこに保存するか、誰が閲覧できるか、どれだけ保持するかを決めます。プロンプトと応答を記録する場合、そこに機密情報が入る可能性があるため、記録自体の保護も設計対象になります。

7. 人の承認が必要な操作 本番データベースへの操作、インフラ構成の変更、デプロイ、削除については、人の承認を挟むかを決めます。ここを空欄のまま配布すると、事故が起きてから決めることになります。

8. 費用の上限と配分 月次の上限を誰が設定し、超えたときに何が起きるかを決めます。部門別・案件別に費用を割り振るなら、その集計方法も先に決めます。

「使わせない」ではなく「条件付きで使わせる」

上の8項目を提示すると、現場からは「制限が多すぎて使えない」という反応が出ます。ここで全面禁止に振れるのも、無条件に開放するのも、どちらも実務的ではありません。

現実的なのは、対象を分けることです。

この3区分を決めておけば、新しい依頼が来たときに「どの区分か」を判定するだけで済みます。毎回ゼロから議論する状態から抜けられます。

開発の受け入れ側で変わること

エージェントが書いたコードが増えると、レビューの意味が変わります。従来のレビューは「書いた人の意図を確認する」作業でしたが、生成されたコードでは意図が言語化されていない場合があります。

そこで、受け入れ条件を先に決めておくことが有効です。

• テストが付いているか（誰がそのテストを書いたか）
• 変更範囲が説明できるか
• 外部ライブラリの追加があるか、そのライセンスは確認済みか
• 秘密情報がコードや設定に含まれていないか
• 動作確認の記録があるか

これらは外部の開発会社へ発注する場合も同じです。発注先がAIを使うかどうかは、秘密情報の取り扱いや第三者の権利との関係を含めて確認すべき事項であり、そのうえで契約と検収の条件に、使ったかどうかとどこまで人が確認したかを書いておく必要があります。

費用と成果をどう見るか

利用量や費用の可視化そのものは、今回の発表でも管理機能として挙げられています。ただし、可視化された数字をどう評価するかは別の設計が必要です。トークン消費量や利用者数は活動量であって、成果ではありません。何を測って全社展開・限定継続・停止を判断するかについては、AIコーディングを全社配布する前の計測設計で9項目に整理しています。本記事の統制設計と合わせて使ってください。

導入判断の進め方

社内にAI開発の専任がいない場合、次の順で進めるのが現実的です。

1. 上の8項目について、現時点の方針を1枚にまとめる（空欄があってよい）
2. 検証・標準・制限の3区分に、実際の案件を当てはめてみる
3. 制限区分に該当する案件があるかを確認する
4. 製品の候補を、8項目のうち何を設定で実現できるかで比較する
5. 期間を区切って試行し、記録の取得状況を確認する

8項目の方針をどこまで社内規程に落とすかという相談はAI開発・生成AI活用の発注前相談で扱っています。対象業務の見極めがまだであればAI導入可否アセスメント、開発体制そのものの設計を含むならDX・システム開発の範囲です。

導入形態ごとに変わる論点

コーディングエージェントの導入形態は3つに分かれ、それぞれ論点が異なります。自社がどれに当たるかで、優先して詰める項目が変わります。

3つ目は、開発を専門としない部門でも扱える環境が増えたことで生じている形態です。業務部門の担当者が自分の業務を効率化するために簡易なツールを作る場合、動くものはできますが、保守の担当者が決まりません。作った人が異動した後、そのツールを誰が直すのかを決めていないと、数年後に困ります。

対策は難しくありません。作ったものを登録する場所を決め、業務で常用するものと使い捨てのものを区別するだけです。区別ができていれば、常用するものだけを情報システム部門の管理下に移せます。

費用の見積りが外れる原因

導入前の試算と実際の費用が乖離する場面では、次のような要因が重なります。

要因1：利用が一部の人に偏る 全社の平均で試算すると外れることがあります。利用量が利用者ごとに大きく異なる場合、平均値だけでは実態を表しません。試算では平均値に加えて、利用量の多い層がどれだけ使うかを別に見積もってください。試行期間中に実際の分布を測り、その値で置き換えるのが確実です。

要因2：試行錯誤の回数が想定より多い 一度で目的の結果が得られることは多くありません。同じ作業を何度も指示し直す過程で、消費量が積み上がります。

要因3：大きな入力が発生する 大きなコードベース全体を対象にした指示は、消費量が跳ね上がります。対象範囲を限定する運用ルールがあるかどうかで、費用は大きく変わります。

対策としては、部門ごとまたはプロジェクトごとに上限を設けることです。ただし、上限の機能が何を対象とし、超過分がどう扱われるかは製品によって異なります。前述のとおり、対象が1プロジェクトの1サービスに限られる場合もあります。上限に近づいた段階で誰がそれを知るのか、上限に達したときに停止するのか承認を得て継続するのかを、使える設定の範囲を確認したうえで決めておいてください。

品質をどう担保するか

エージェントが生成したコードを本番で使う場合、確認の工程を省略しないことが前提になります。実務上、次の3層で見ます。

層1：機械的な確認 テストの実行、型の検査、依存関係の脆弱性検査、秘密情報の混入検査。これらは自動で回す仕組みに入れます。人が毎回見るものではありません。

層2：人によるレビュー 変更の意図が説明されているか、既存の設計と矛盾しないか、必要以上に広い範囲を変更していないか。ここは人が見ます。

層3：業務での確認 実際の業務手順で期待どおりに動くか。開発側だけで完結させず、業務側の確認を挟みます。

層1が整っていない状態でエージェントの利用を広げると、層2の負荷が跳ね上がります。レビューする人が足りなくなり、結果として確認が形骸化します。導入の順序としては、層1の自動化を先に整えるほうが安全です。

外部委託先がAIを使う場合の契約条項

開発を委託している場合、次の項目を契約または覚書で明確にしてください。

• 委託業務においてAIを利用することの可否と、利用する場合の範囲
• 当社が提供した資料・ソースコードを外部のサービスへ入力することの可否
• 生成された成果物の権利の帰属
• 第三者の権利を侵害しないことの確認方法
• 秘密情報の取り扱い（再委託先を含む）
• 成果物にAIを利用した箇所がある場合の申告の要否

2番目は特に確認しておきたい項目です。ここを定めていないと、自社の資料が意図しない形で外部サービスへ渡る可能性があります。権利の帰属は発注側が一方的に決められるものではなく、契約と適用される法令によって定まります。禁止するかどうかを含め、法務の確認を経たうえで書面に残してください。

FAQ

Q1. Antigravityは誰でも使えますか

公式の記載では、対象となるGemini Enterpriseのアプリケーションサブスクリプションの一部として提供され、有効化の対象は対象ライセンスを持つ利用者とされています。利用条件は契約内容によるため、自社の契約で使えるかは個別に確認が必要です。

Q2. IDEの拡張はすぐ本番の開発で使えますか

Visual Studio、JetBrains、Zed向けはプレビューと記載されています。プレビュー段階の機能を本番の開発プロセスに組み込む場合は、仕様変更や提供終了の可能性を織り込んだうえで判断してください。

Q3. 監査ログを有効にすればコンプライアンス対応は完了しますか

記録は必要条件ですが十分条件ではありません。何を記録し、誰が確認し、どのくらい保持し、問題を見つけたときに誰が判断するかまで決めて、初めて運用になります。

Q4. MCPの接続先はどこまで絞るべきですか

用途によります。まずは許可制から始め、実際に必要になった接続先を承認して追加する運用が安全です。最初から自由にすると、後から絞るときに業務が止まります。

Q5. 開発会社に発注している場合、こちらで統制する必要はありますか

あります。成果物の権利、秘密情報の扱い、AIの利用範囲、検収時の確認内容は、契約と適用される法令に基づいて双方で取り決める事項です。発注先の社内ルールに委ねたままにすると、納品後に確認する根拠がなくなります。

参考情報

• Google Cloud Blog Expanding Google Antigravity for enterprise customers（2026年8月21日）
• Google Cloud Manage spend cap budgets（支出上限の条件）
• GXO AI開発・生成AI活用 発注前相談
• GXO AI導入可否アセスメント

機能名と提供条件は、同日付のGoogle Cloud公式ブログに書かれている内容をそのまま参照しています。プレビュー表記のある機能は提供条件が変わる可能性があります。自社の契約でどの機能が使えるかは、契約書および公式ドキュメントで確認してください。