公式の Google Antigravity Agentドキュメント と Google DevelopersのMCP設定資料 では、MCP接続をローカルMCPとstreamable HTTP MCPの2系統として確認できます。したがって、Google Antigravity MCPのデプロイは、最初から全ツールを開放するのではなく、隔離したクラウドMacでリモートURL、最小のallowed_tools、個別の権限確認を順番に行う構成が適切です。
本週の推奨アクション： まず読み取り専用のMCPツールを1つだけ登録し、接続ログと権限結果を保存してください。実行、ファイル変更、外部サービスへの書き込みは、初回検証が終わるまで許可しない構成にします。
この手順は、Google Antigravityをローカル環境からクラウドMacへ移したい開発者向けです。チームでMCP、認証情報、Agentの実行権限を管理する担当者や、ローカルMacとリモート開発環境のどちらを採用するか比較している担当者にも適しています。
事前確認：実行範囲と接続方式
Google Antigravity CLI、Gemini APIを利用するAgent、MCP Serverは同じ役割ではありません。Antigravity側がAgentの作業を制御し、MCP Serverが外部データや操作機能をツールとして公開します。クラウドMacは、そのAgentやCLIを実行する作業環境です。
MCPには、ローカルプロセスを起動する方式と、URL経由で接続するstreamable HTTP方式があります。クラウドMacでは、プロセス管理や作業ディレクトリを自分で保てる場合はローカル方式、複数環境から同じServerへ接続する場合はリモート方式が候補になります。ただし、リモート方式ではURLの所有者、TLS、認証ヘッダー、ネットワーク出口を確認しなければなりません。
導入前に、次の確認を完了させます。
- [ ] クラウドMacの作業ディレクトリと実行ユーザーを決める
- [ ] MCP Serverの接続方式がローカルかstreamable HTTPか確認する
- [ ] 接続先URL、TLS証明書、許可するネットワーク出口を確認する
- [ ] APIキーやトークンをソースコード、設定ファイル、チャット本文に埋め込まない
- [ ] Antigravity、MCP Server、クラウドMacのログ保存先を分ける
- [ ] 実データではなく、読み取り専用の検証データを用意する
- [ ] ファイル、コマンド、外部システムの書き込みを初期状態で無効にする
特に、秘密情報を含むリポジトリ、決済処理、顧客データ、外部サービスへの更新処理は、動作確認の対象から外してください。接続できることと、安全に本番処理を任せられることは別の判定です。
初回登録：MCP Serverの最小構成
Google Antigravity MCPを登録する際は、MCP Server名、URL、認証用リクエストヘッダー、allowed_toolsを分けて管理します。公式の Antigravity Agent MCP資料 に記載されたフィールド名と現在の設定形式を照合し、過去のコミュニティ設定例をそのまま流用しないでください。
サーバー名は、環境と用途が分かる命名にします。たとえば開発用と本番用を同じ名前にすると、許可対象を誤る原因になるため、環境名と読み取り・書き込みの区別を含めます。URLは短縮URLやリダイレクト先ではなく、管理対象として確認できる正式な接続先を使います。
最小接続の流れは次のとおりです。
- AntigravityのMCP設定画面またはCLIで空のServer定義を作成します。
- MCP Server名と正式なURLを入力します。
- 必要な認証ヘッダーを環境変数から参照する形で設定します。
allowed_toolsには読み取り専用ツールを1つだけ指定します。- 設定を保存し、接続開始時のログを保存します。
- ツール一覧の取得後、固定データを読むだけの呼び出しを行います。
- レスポンス形式、エラー内容、セッション終了後の再接続を確認します。
接続に失敗した場合、URL、認証ヘッダー、MCPプロトコルの応答、クラウドMacのネットワーク出口を別々に確認します。認証エラーをAntigravityのモデル推論失敗と判断したり、接続タイムアウトをツール実装の不具合と決めつけたりすると、調査範囲が広がります。
注意： MCP Serverへ接続できても、ツールの安全性や権限分離が確認されたとは限りません。接続成功は疎通の判定であり、実行許可を広げる根拠にはしないでください。
初回呼び出し：読み取りから制御された書き込みへ
初回タスクは、複雑なAgentワークフローではなく、段階的に検証します。最初は固定データの読み取り、次に決まった形式への構造化抽出、その後に検証用ディレクトリ内だけで行う制御された書き込みという順序にします。
構造化抽出では、取得した値が想定したキーや型で返るかを確認します。値が空の場合、モデルの解釈問題なのか、MCP Serverのレスポンス問題なのかをログで分けて記録します。書き込みを試す場合も、対象パスを限定し、既存ファイルの上書きや削除を許可しない設計から始めます。
初回タスクの受け入れ条件は、次のように記録します。
- 接続開始と認証の結果がログに残っている
- 許可したツール以外が呼び出されていない
- ツールの戻り値が想定した構造で保存されている
- エラー発生時に再試行回数と最終結果が確認できる
- セッションを終了して再接続した後も設定が再現する
- Agentの推論、MCP Server、クラウドMacの障害を分類できる
ここで再接続に失敗する場合は、セッション情報の保存場所、環境変数の読み込み、アイドル停止、MCP Server側のセッション期限を確認します。クラウドMacの利用状況は、Vuncloudの ヘルプセンター にある環境案内とも照合し、接続設定だけでなく作業環境の状態を確認してください。
権限拡張：ファイル、コマンド、MCPの分離
Antigravity MCPの権限は、read_file、command、MCPツールの3領域に分けて考える必要があります。MCPツールを許可しただけで、クラウドMac上の全ファイルやシェルコマンドまで安全になるわけではありません。
Google Cloud MCPアクセス制御の公式資料 では、アクセス対象を明確に制御する考え方が示されています。全体に適用するワイルドカードは設定が簡単な一方、意図しないServerやツールをまとめて許可しやすいため、初期構成では避けます。
| 権限領域 | 初期状態の推奨 | 拡張条件 | 人間の確認 |
|---|---|---|---|
read_file |
検証用ディレクトリの読み取りだけ | 対象パスと秘密情報の除外を確認 | ソース全体や設定ファイルは必要 |
command |
原則として無効 | コマンド、引数、作業ディレクトリを固定 | インストール、削除、公開操作は必須 |
| MCPツール | 単一Serverの単一読み取りツール | 戻り値と副作用を確認 | 外部書き込み、決済、通知は必須 |
環境別には、開発では読み取りと限定的なコマンド、テストでは検証用データへの書き込み、本番では個別許可と人間の承認を基本にします。Google Cloudの MCP IAM権限資料 も参照し、MCP側の認可とクラウドMac側の実行権限が別々に管理されているか確認してください。
運用前確認：チーム利用に広げる条件
個人の検証が成功しても、チーム利用では設定の再現性と撤回手順が必要です。構成ファイルのバージョンを保存し、誰がどのServerとツールを追加したかを記録します。新しいMCP Serverを追加する際は、所有者、接続先、認証方式、データの流れ、副作用の有無を審査します。
| 確認対象 | 単一の検証環境 | チーム運用へ移す前 |
|---|---|---|
| 認証情報 | 環境変数や安全な保管先から読み込む | 期限、担当者、ローテーション方法を記録 |
| MCP設定 | 最小ツールだけを登録 | 変更履歴と承認者を保存 |
| ログ | 接続とツール結果を保存 | 個人情報や秘密情報を除外して保管 |
| Mac環境 | 作業ディレクトリを限定 | セッション分離、ディスク、停止条件を確認 |
| 障害対応 | 手動で再接続 | 失敗時の撤回、再試行、連絡経路を決める |
APIキーやアクセストークンは、担当者の異動や漏えいの疑いが生じた時点で交換します。不要になったツールは設定から削除し、Server側でもトークンを無効化します。権限を残したままツールだけ使わなくなる状態は、後日のAgent変更で意図せず呼び出されるリスクがあります。
クラウドMacの運用では、ログ容量、ディスク残量、同時セッション、アイドル時の停止、再起動後の環境変数を定期的に確認します。複数チームが同じMCP設定を共有し始め、監査ログや承認フローが必要になった時点では、単一Mac上の運用から集中管理されたAgent実行環境への移行を検討します。
Vuncloudの クラウドMac利用環境 を選ぶ場合も、必要な期間、接続方式、データの所在、停止後の扱いを先に整理してください。短期の検証や分離された開発作業には適していますが、物理インターフェースが必要な処理や、長期間にわたり高負荷を固定運用する用途では、専用設備や自社管理環境との比較が必要です。
FAQ：導入時の判断ポイント
Google AntigravityにMCP Serverを追加する手順は？
まず接続先のMCP Serverがローカル型かstreamable HTTP型かを確認し、サーバー名、URL、認証用ヘッダー、allowed_toolsを登録します。最初から複数ツールを許可せず、読み取り専用ツールを1つだけ選び、疎通、認証、レスポンス形式の順に確認すると切り分けやすくなります。
Antigravity MCPの権限はどのように設定すべきですか？
read_file、command、MCPツールの権限を別々に管理し、全体に適用するワイルドカードは避けます。開発環境でも単一Serverの単一ツールから始め、ソースコード、秘密情報、決済、外部システムへの書き込みには人間の確認を残してください。
クラウドMacでGoogle Antigravityを動かす際の注意点は？
MCPの設定だけでなく、ネットワーク出口、環境変数、認証情報、作業ディレクトリ、ログ保存先を事前に確認します。クラウドMacでは接続先の許可リスト、アイドル時の停止、ディスク残量、複数セッションの分離も確認し、実データを扱う前に隔離環境で検証してください。
Antigravity MCPのツール呼び出しが失敗した場合は？
最初にURL、次に認証ヘッダー、プロトコル応答、ネットワーク出口の順で確認します。MCP Serverからエラーが返る場合と、クラウドMac自体が停止・切断している場合を分け、Antigravityの推論失敗と同じ問題として扱わないことが重要です。
ローカルMacだけで試す構成は、物理ファイルや開発ツールへ直接アクセスしやすい反面、個人環境とチーム設定が混ざり、権限の再現性やセッション分離を保ちにくい場合があります。自前のMacを常時稼働させる方法も、電源、ネットワーク、外部公開、端末の占有が管理負担になります。
そのため、まず隔離された環境でGoogle Antigravity MCPを試し、最小権限とログを確認したい場合は、VuncloudのクラウドMacをレンタルする方が検証の切り替えを行いやすい選択肢です。長期の固定負荷や物理機器連携には別の構成を選び、短期のAgent検証、チーム用の再現環境、外部MCPとの接続確認に限定して使うと、用途とコストの不一致を避けられます。
導入前にさらに権限境界と環境の停止条件を整理する場合は、Vuncloudの サービス案内 とヘルプ情報を確認し、必要な期間とデータの扱いを決めてからクラウドMacを用意してください。
開発に適したMac環境を、Vuncloudで始めませんか
Vuncloudなら、クラウド上のMacに遠隔から接続し、場所を選ばず開発環境を整えられます。
必要な期間や用途に合わせてMacを利用できるため、検証からチーム開発まで柔軟に対応できます。