VPC Service Controls を利用してGoogle Antigravity CLI へアクセス制御を導入する
はじめに
こんにちは。
コンサルティング部の渡邉です。
Google Antigravity は、Google が提供する AI エージェント駆動の開発ツールです。デスクトップアプリのAntigravity 2.0や Antigravity CLI などを通じて、コード生成やタスクの自動化を実現することができます。エンタープライズ環境では Gemini Enterprise Agent Platform と統合して利用しますが、このとき機密データの漏洩リスクを低減するためや、特定のユーザやIPアドレスからのアクセスのみの利用を許可するために VPC Service Controls でアクセス制御を導入することが重要です。
Google Cloud で Google Antigravity CLI を使うための初期設定手順についてのブログは以下で公開しているので、是非ご覧いただければ幸いです。
本記事では、VPC Service Controls を利用して Antigravity CLI へのアクセス制御を導入する検証を行いました。
VPC Service Controls の概要
VPC Service Controls は、Google Cloud のマネージドサービスに対するセキュリティ境界（サービスペリメータ）を定義し、データの漏洩リスクを低減するサービスです。
主な機能は以下の通りです。
| 機能 | 説明 |
|---|---|
| サービスペリメータ | Google Cloud リソースを隔離する境界を作成し、境界外からのアクセスをブロックする主要機能 |
| アクセスレベル | 特定の条件（IP アドレス、ユーザー ID など）を満たすリクエストに例外的なアクセスを許可する |
| 上り（内向き）/下り（外向き）ルール | ペリメータを跨ぐアクセスをきめ細やかに制御する |
| ドライランモード | ペリメータの影響を事前にテストできる機能。実際のブロックは行わずCloud Loggingにログのみ記録する |
アーキテクチャ
Antigravity 2.0 や Antigravity CLI は開発者のローカルマシンで動作します。つまり、VPC Service Controls ペリメータの外側からアクセスすることになります。
デフォルトのペリメータを適用すると、Antigravity が利用する Agent Platform API（aiplatform.googleapis.com）へのペリメータ外からのアクセスはすべてブロックされます。そのため、正規の開発者を再許可するためのアクセスレベルの定義と、上り（内向き）ルールの設定が不可欠です。VPC Service Controls では、ペリメータに設定されたアクセスレベルと上り（内向き）ルールなどの条件を満たせばアクセスが許可されます。
以下の図は、VPC Service Controls による Antigravity のアクセス制御の全体像を示しています。
このアーキテクチャのポイントは以下の通りです。
- ペリメータ内に Agent Platform API を含めることで、未承認のクライアントからのアクセスをブロックします
- アクセスレベルと上り（内向き）ルールを設定することで、正規の開発者のみが Antigravity CLI を利用可能になります
- IAM による認可と組み合わせることで、多層防御（Defense in Depth）を実現します
Antigravity と VPC Service Controls
Antigravity のエンタープライズドキュメントでは、VPC Service Controls を利用する際に Agent Platform API（aiplatform.googleapis.com）をペリメータに追加することが案内されています。
Antigravity CLI は Agent Platform API を通じてモデル（Gemini）と通信するため、このサービスをペリメータの制限対象に追加し、上り（内向き）ルールで正規ユーザーのアクセスを許可する構成となります。
Agent Platform API の VPC Service Controls サポート状況は以下の通りです。
| 項目 | 内容 |
|---|---|
| ステータス | GA |
| サービス名 | aiplatform.googleapis.com |
| ペリメータで保護可能か | はい |
サポート状況は以下のgcloudコマンドで確認することができます。
gcloud access-context-manager supported-services describe \
aiplatform.googleapis.com
availableOnRestrictedVip: true
knownLimitations: true
name: aiplatform.googleapis.com
serviceSupportStage: GA
実際に試してみる
ここからは、VPC Service Controls を利用して Antigravity CLI へのアクセス制御を導入する手順を検証します。まずドライランモードでテストを行い、問題がないことを確認してから実際に適用する流れで進めます。
以下の図は検証手順の全体フローです。
前提条件
- Google Cloud プロジェクトが作成済みであること
gcloudCLI がインストール・認証済みであること- 組織（Organization）リソースが存在すること
- Antigravity 2.0 または Antigravity CLI がインストール済みで、Gemini Enterprise Agent Platform と連携済みであること
- 以下の IAM ロールが付与されていること
roles/accesscontextmanager.policyAdmin（Access Context Manager 管理者）roles/aiplatform.user（Agent Platform ユーザー）
ステップ 1: アクセスポリシーの確認
VPC Service Controls のサービスペリメータを作成するには、まず組織レベルのアクセスポリシーが必要です。
# アクセスポリシーの一覧を表示
gcloud access-context-manager policies list \
--organization=YOUR_ORGANIZATION_ID
NAME: XXXXXXXXXXXX
ORGANIZATION: XXXXXXXXXXXX
SCOPES:
TITLE: org-default-policy
ETAG: xxxxxxxxxxxxxx
ポリシー ID を環境変数に設定しておきます。
export POLICY_ID=$(gcloud access-context-manager policies list \
--organization=YOUR_ORGANIZATION_ID \
--format="value(name)")
ステップ 2: ドライランモードでサービスペリメータを作成
まずドライランモードでペリメータを作成し、影響を確認します。ドライランモードでは、ペリメータポリシーに違反するリクエストはブロックされず、ログに記録されるのみです。
# ドライランモードでペリメータを作成
gcloud access-context-manager perimeters dry-run create \
antigravity_perimeter \
--perimeter-title="Antigravity Perimeter" \
--perimeter-type="regular" \
--perimeter-resources="projects/$(gcloud projects describe my-antigravity-demo --format='value(projectNumber)')" \
--perimeter-restricted-services="aiplatform.googleapis.com" \
--policy=XXXXXXXXXXXX
Waiting for PATCH operation [accessPolicies/XXXXXXXXXXXX/servicePerimeters/antigravity_perimeter/update/1786448344794069]...done.
ペリメータの内容を確認します。
# ペリメータの詳細を確認
gcloud access-context-manager perimeters describe \
antigravity_perimeter \
--policy=XXXXXXXXXXXX
etag: xxxxxxxxx
name: accessPolicies/XXXXXXXXXXXX/servicePerimeters/antigravity_perimeter
spec:
resources:
- projects/XXXXXXXXXXXXX
restrictedServices:
- aiplatform.googleapis.com
title: Antigravity Perimeter
useExplicitDryRunSpec: true
ステップ 3: Antigravity CLI での動作確認（ドライランモード）
ドライランモードではリクエストはブロックされないため、Antigravity CLI を通常通り使用できます。この状態でAntigravity CLI からペリメータ内のプロジェクトにアクセスし、ドライランの違反ログが記録されることを確認します。
Antigravity CLI でペリメータ内のプロジェクトに接続して操作を行ってください。
$ agy
▄▀▀▄ Antigravity CLI 1.1.11
▀▀▀▀▀▀ user@example.com
▀▀▀▀▀▀▀▀ Gemini 3.6 Flash (High)
▄▀▀ ▀▀▄ ~/repo/my-workspace
▄▀▀ ▀▀▄
────────────────────────────────────────────────────────────
> Google CloudでのAntigravity CLIの利用方法について簡潔に説明して
▸ Thought for 3s, 150 tokens
Exploring agy CLI Usage
● Read(/home/username/.gemini/antigravity-cli/builtin/skills/antigravity_guide/SKILL.md)
● Read(/home/username/.gemini/antigravity-cli/builtin/skills/antigravity_guide/references/cli.md) (ctrl+o to expand)
▸ Thought for 2s
Exploring Google Cloud Antigravity CLI
Google Cloud環境で Antigravity CLI (agy) を利用する手順とポイントのまとめです。
──────
### 1. 動作環境とセットアップ
Google Cloud サービス（Cloud Shell, Compute Engine VM, Vertex AI Workbench など）の Linux 環境上で動作します。
# Antigravity CLI のインストール（または環境に合わせたバイナリの導入）
npm install -g @google/antigravity-cli
# CLI の起動
agy
──────
### 2. 認証（Google Cloud / IAM連携）
Google Cloud 上で Vertex AI や Google Cloud リソースと連携して利用する場合、Application Default Credentials (ADC) またはサービスアカウントを使用します。
• 個人の gcloud 認証:
gcloud auth application-default login
• サービスアカウントを利用する場合:
環境変数 GOOGLE_APPLICATION_CREDENTIALS にサービスアカウントキー（JSON）のパスを指定します。
export GOOGLE_APPLICATION_CREDENTIALS="/path/to/key.json"
──────
### 3. Google Cloud プロジェクトの設定
利用する GCP プロジェクトやリージョンは、環境変数または設定ファイルで指定します。
• 環境変数での指定:
export GOOGLE_CLOUD_PROJECT="your-gcp-project-id"
export GOOGLE_CLOUD_REGION="us-central1"
• 設定ファイルでのカスタマイズ:
~/.gemini/antigravity-cli/settings.json を編集してプロジェクトごとの設定を保持できます。
──────
### 4. 主なユースケース
1. Cloud Shell / Remote VM でのAIペアプログラミング
• ブラウザ上の Cloud Shell や SSH 接続した VM 内で agy を起動し、リモート環境のコードベースをAIエージェントに直接調査・修正させることができます。
2. ヘッドレス / スクリプトによる自動化
• CI/CD（Cloud Build）やバッチ処理の中で非対話モードで実行し、コードの事前チェックやリファクタリングを自動化できます。
通常通り、Antigravity CLIを起動して、実行することができました。
ステップ 4: 監査ログの確認
ドライランの違反ログは Cloud Audit Logs に記録されます。監査ログの metadata.dryRun フィールドが True のエントリが、ドライラン違反に該当します。
Cloud Logging で以下のフィルタを使用して確認できます。
resource.type="audited_resource"
protoPayload.metadata.dryRun=true
protoPayload.metadata.violationReason!=""
ドライランの違反ログの内容を確認してみます。
{
"protoPayload": {
"@type": "type.googleapis.com/google.cloud.audit.AuditLog",
"status": {
"code": 7,
"message": "Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier: yDEpx7Bpk2t0EcDIl2yhMi9qBLRbxr-pHAw9T0sKXGE50WMFAr1er_JoYdZ7DYAVtEc9h_XdqgENK8Leag",
"details": [
{
"@type": "type.googleapis.com/google.rpc.PreconditionFailure",
"violations": [
{
"type": "VPC_SERVICE_CONTROLS",
"description": "yDEpx7Bpk2t0EcDIl2yhMi9qBLRbxr-pHAw9T0sKXGE50WMFAr1er_JoYdZ7DYAVtEc9h_XdqgENK8Leag"
}
]
},
{
"@type": "type.googleapis.com/google.rpc.ErrorInfo",
"reason": "SECURITY_POLICY_VIOLATED",
"domain": "googleapis.com",
"metadata": {
"service": "aiplatform.googleapis.com",
"troubleshootToken": "Ab-f5IVi40VAAa7pMRqll6IyAggSF-amMgpuzdAam6OlrvvRT04PL6lWkNimBwZYg62lsFUyilxrd7ZkbhnybPMk18inF6NZt45-8tYoprXZegXAMat1o1WfuIbh1Vq3ciy0SDUuh9KWtxsvPjxLXBLkG5tsaekuL6DnR--sA0W6w7LEOEsJKlY4lxbNWJWqV_8rLbC7cw_ntP3rq8waHIV6L1Kbf8QKCZT5mmizQJyyKOWm0zv1qYLOXlM517MZ6RbM0Kj90PBmCaNVOz88kWBlUMgWiqLbvB4ihnvxzzvWX9Zkl1_irmQtbYlhsPd_htfn2Ra1VKvGwdf1eyBK11C9pDmh2cU4lrPCfv-Jw_LnWg266P0_IHCMAgCNdi0LiVl8ubdOzIufTaw77nmlSI84HI4JwwXbjOh0csSfJpYPtE13GgOn3AKkmvCAHjdqlwtAmYkdFEgjUWFVJ0CG-pbGdRVHGdkTu-_6-g",
"uid": "yDEpx7Bpk2t0EcDIl2yhMi9qBLRbxr-pHAw9T0sKXGE50WMFAr1er_JoYdZ7DYAVtEc9h_XdqgENK8Leag"
}
}
]
},
"authenticationInfo": {
"principalEmail": "user@example.com",
"oauthInfo": {
"oauthClientId": "XXXXXXXXXXXX-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.apps.googleusercontent.com"
}
},
"requestMetadata": {
"callerIp": "xxx.xxx.xxx.xxx",
"requestAttributes": {},
"destinationAttributes": {}
},
"serviceName": "aiplatform.googleapis.com",
"methodName": "google.cloud.aiplatform.v1.PredictionService.StreamGenerateContent",
"resourceName": "projects/XXXXXXXXXXXXX",
"metadata": {
"deviceState": "Unknown",
"securityPolicyInfo": {
"organizationId": "XXXXXXXXXXXX",
"servicePerimeterName": "accessPolicies/XXXXXXXXXXXX/servicePerimeters/antigravity_perimeter"
},
"violationReason": "NO_MATCHING_ACCESS_LEVEL",
"accessLevels": [
"accessPolicies/XXXXXXXXXXXX/accessLevels/allow_corp_ip",
"accessPolicies/XXXXXXXXXXXX/accessLevels/allow_public_ip"
],
"dryRun": true,
"resourceNames": [
"projects/my-antigravity-demo/locations/global/publishers/google/models/gemini-3.6-flash"
],
"@type": "type.googleapis.com/google.cloud.audit.VpcServiceControlAuditMetadata",
"ingressViolations": [
{
"targetResourcePermissions": [
"aiplatform.endpoints.predict"
],
"servicePerimeter": "accessPolicies/XXXXXXXXXXXX/servicePerimeters/antigravity_perimeter",
"targetResource": "projects/XXXXXXXXXXXXX"
}
],
"vpcServiceControlsUniqueId": "yDEpx7Bpk2t0EcDIl2yhMi9qBLRbxr-pHAw9T0sKXGE50WMFAr1er_JoYdZ7DYAVtEc9h_XdqgENK8Leag",
"vpcServiceControlsTroubleshootToken": "Ab-f5IVi40VAAa7pMRqll6IyAggSF-amMgpuzdAam6OlrvvRT04PL6lWkNimBwZYg62lsFUyilxrd7ZkbhnybPMk18inF6NZt45-8tYoprXZegXAMat1o1WfuIbh1Vq3ciy0SDUuh9KWtxsvPjxLXBLkG5tsaekuL6DnR--sA0W6w7LEOEsJKlY4lxbNWJWqV_8rLbC7cw_ntP3rq8waHIV6L1Kbf8QKCZT5mmizQJyyKOWm0zv1qYLOXlM517MZ6RbM0Kj90PBmCaNVOz88kWBlUMgWiqLbvB4ihnvxzzvWX9Zkl1_irmQtbYlhsPd_htfn2Ra1VKvGwdf1eyBK11C9pDmh2cU4lrPCfv-Jw_LnWg266P0_IHCMAgCNdi0LiVl8ubdOzIufTaw77nmlSI84HI4JwwXbjOh0csSfJpYPtE13GgOn3AKkmvCAHjdqlwtAmYkdFEgjUWFVJ0CG-pbGdRVHGdkTu-_6-g"
}
},
"insertId": "1aehoo4d9hfw",
"resource": {
"type": "audited_resource",
"labels": {
"service": "aiplatform.googleapis.com",
"method": "google.cloud.aiplatform.v1.PredictionService.StreamGenerateContent",
"project_id": "my-antigravity-demo"
}
},
"timestamp": "2026-08-11T11:42:37.940419478Z",
"severity": "ERROR",
"logName": "projects/my-antigravity-demo/logs/cloudaudit.googleapis.com%2Fpolicy",
"receiveTimestamp": "2026-08-11T11:42:38.932431574Z"
}
この監査ログから、以下の情報を読み取ることができます。
まず、metadata.dryRun が true であることから、これはドライランモードでの違反記録であり、実際のブロックは発生していないことが確認できます。
metadata.violationReason が NO_MATCHING_ACCESS_LEVEL となっており、リクエスト元がどのアクセスレベルの条件にも一致しなかったため、違反と判定されたことがわかります。
アクセスレベルの設計に直接役立つのが authenticationInfo.principalEmail と requestMetadata.callerIp です。それぞれリクエストを送信したユーザーのメールアドレスと送信元 IP アドレスが記録されており、次のステップで作成するアクセスレベルの members と ipSubnetworks に追加すべき値を特定できます。
また、methodName が StreamGenerateContent であることから、Antigravity CLI は Agent Platform API のストリーミング推論メソッドを呼び出していることがわかります。metadata.resourceNames からは使用しているモデル（Gemini 3.6 Flash）、metadata.ingressViolations の targetResourcePermissions からは違反が発生したパーミッションが推論リクエスト（aiplatform.endpoints.predict）であることも確認できます。
ステップ 5: アクセスレベルの作成
正規の開発者がペリメータ外から Antigravity にアクセスできるよう、アクセスレベルを作成します。ここではユーザー ID と IP アドレスの両方を条件に含めたアクセスレベルを作成する例を示します。
まず、アクセスレベルの定義ファイルを作成します。
# antigravity_access_level.yaml
- ipSubnetworks:
- xxx.xxx.xxx.xxx/32
members:
- user:user@example.com
アクセスレベルを作成します。
# アクセスレベルを作成
gcloud access-context-manager levels create \
antigravity_users_level \
--title="Antigravity Users Access Level" \
--basic-level-spec=antigravity_access_level.yaml \
--policy=XXXXXXXXXXXX
Create request issued for: [antigravity_users_level]
Created level [antigravity_users_level].
ステップ 6: 上り（内向き）ルールの設定とペリメータのエンフォース
上り（内向き）ルールを設定してエンフォースします。上り（内向き）ルールの中でアクセスレベルをソース条件として参照することで、アクセスレベルの条件を満たすユーザーのみが、指定したサービスにアクセスできるようになります。
まず、上り（内向き）ルールの YAML ファイルを作成します。
# ingress_rule.yaml
- ingressFrom:
identityType: ANY_IDENTITY
sources:
- accessLevel: accessPolicies/XXXXXXXXXXXX/accessLevels/antigravity_users_level
ingressTo:
operations:
- serviceName: aiplatform.googleapis.com
methodSelectors:
- method: "*"
resources:
- "*"
以下の図は、上り（内向き）ルールによるアクセス制御のフローです。
ドライランの設定を確認した上でエンフォースします。
# 上り（内向き）ルールをドライラン設定に追加
gcloud access-context-manager perimeters dry-run update \
antigravity_perimeter \
--set-ingress-policies=ingress_rule.yaml \
--policy=XXXXXXXXXXXX
Waiting for PATCH operation [accessPolicies/XXXXXXXXXXXX/servicePerimeters/antigravity_perimeter/update/1786449316993618]...done.
再度 Antigravity CLI で動作確認を行い、ドライランの違反ログが出なくなったことを確認した上で、エンフォースします。
# ドライラン設定をエンフォース（本番適用）
gcloud access-context-manager perimeters dry-run enforce \
antigravity_perimeter \
--policy=XXXXXXXXXXXX
Waiting for PATCH operation [accessPolicies/XXXXXXXXXXXX/servicePerimeters/antigravity_perimeter/update/1786449455999461]...done.
ステップ 7: アクセス制御の検証
ペリメータをエンフォースした後、正規ユーザーかつ許可されたIPアドレスからと、正規ユーザーかつ許可されていないIPアドレスからの両方でアクセスをテストします。
正規ユーザーかつ許可されたIPアドレスからのアクセス
正規ユーザーかつ許可されたIPアドレスからのアクセスのため、VPC Service Controlsの影響を受けることなくAntigravityとの会話を行うことができています。
▄▀▀▄ Antigravity CLI 1.1.11
▀▀▀▀▀▀ user@example.com
▀▀▀▀▀▀▀▀ Gemini 3.6 Flash (High)
▄▀▀ ▀▀▄ ~/repo/my-workspace
▄▀▀ ▀▀▄
────────────────────────────────────────────────────────────
> こんにちは
こんにちは！Antigravityです。
本日はどのようなお手伝いをいたしましょうか？コードの作成やデバッグ、リファクタリング、Webアプリケーションの開発など、お気軽にお申し付けください！
正規ユーザーかつ許可されていないIPアドレスからのアクセス
正規ユーザーかつ許可されていないIPアドレスからのアクセスのため、VPC Service Controlsの影響でAntigravityとの接続が拒否されました。
▄▀▀▄ Antigravity CLI 1.1.11
▀▀▀▀▀▀ user@example.com
▀▀▀▀▀▀▀▀ Gemini 3.6 Flash (High)
▄▀▀ ▀▀▄ ~/repo/my-workspace
▄▀▀ ▀▀▄
────────────────────────────────────────────────────────────
> こんにちは
⚠ Request is prohibited by organization's policy. vpcServiceControlsUniqueIdentifier: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Error ID: 13e7704d-1f00-4501-a439-68675280eef5-5
How's the CLI experience so far? Help us improve:
[1] Good [2] Fine [3] Bad [0] Skip
まとめ
本記事では、VPC Service Controls を利用して Google Antigravity へのアクセス制御を導入する方法をご紹介しました。
VPC Service Controls のサービスペリメータを作成し、Antigravity が利用する Agent Platform API（aiplatform.googleapis.com）を制限対象サービスに追加することで、ペリメータ外からの不正なアクセスをブロックできます。
Antigravity 2.0 / CLI は開発者のローカルマシンで動作するため、ペリメータの外側からアクセスする構成になります。そのため、上り（内向き）ルールによるアクセス許可の設定が不可欠です。上り（内向き）ルールの中でアクセスレベルをソース条件として参照することで、正規の開発者のみが Agent Platform API にアクセスできるよう、きめ細やかに制御できます。
今回は、Antigravity CLIで検証しましたが、Antigravity 2.0 でも同様の設定でアクセス制御を行うことができます。
また、導入時はドライランモードでのテストを強く推奨します。ドライランモードでは実際のブロックを行わずに監査ログで影響を確認できるため、既存のワークフローを中断することなく安全にペリメータ設計を検証できます。エンタープライズ環境で Antigravity を利用されている方は、VPC Service Controls によるアクセス制御の導入を検討してみてはいかがでしょうか。
この記事が誰かの助けになれば幸いです。
以上、コンサルティング部の渡邉でした！
