対象上級者

達成目標本番運用環境の構築

前提知識Ch.1-9完了

所要時間25分

プロフェッショナル環境構築

本番運用に耐えるAntigravity環境の構築。セキュリティ、サンドボックス、チーム運用の設計。

サンドボックス設計

本番環境でAntigravityを安全に運用するには、OS固有のサンドボックス機構を深く理解し、適切に設定する必要があります。

macOS Seatbelt

macOSでは sandbox-exec を使用したSeatbeltプロファイルでファイルシステムアクセスを制限します。Antigravityはデフォルトで以下のプロファイルを適用します。

Seatbelt プロファイル例

(version 1)
(deny default)
(allow file-read* (subpath "/Users/dev/project"))
(allow file-write* (subpath "/Users/dev/project"))
(allow file-read* (subpath "/usr/local"))
(allow process-exec)
(allow network-outbound (remote tcp "*:443"))

カスタムプロファイルを作成することで、特定のディレクトリだけにアクセスを許可できます。

読み取り専用パス — /usr/local、/opt/homebrew など、ツールチェーンのパスを読み取り専用で許可
書き込み許可パス — プロジェクトディレクトリと /tmp のみに書き込みを限定
ネットワーク — HTTPS (443) のみ許可し、HTTP や他のポートはブロック

Linux nsjail

Linuxではnsjailを使用したカーネルレベルの名前空間分離が計画されています（v1.20.5時点ではベータ段階で、一部環境でバグが報告されています）。安定稼働を確認してから本番利用してください。プロセス、ネットワーク、ファイルシステムを完全に隔離できます。

nsjail 設定例

{
  "mount": [
    { "src": "/project", "dst": "/workspace", "is_bind": true, "rw": true },
    { "src": "/usr", "dst": "/usr", "is_bind": true, "rw": false },
    { "src": "/tmp", "dst": "/tmp", "is_bind": true, "rw": true }
  ],
  "clone_newnet": true,
  "clone_newpid": true,
  "rlimit_as": 4096,
  "time_limit": 300
}

PID名前空間 — エージェントプロセスが他のプロセスを参照・操作できないよう分離
ネットワーク名前空間 — 外部ネットワークへのアクセスを完全に遮断（必要時のみホワイトリストで許可）
リソース制限 — メモリ4GB、CPU時間300秒の制限でリソース枯渇を防止

⚠️ Warning

Docker内でnsjailを動作させるには、ホストカーネルの user_namespaces サポートが必要です。--privileged フラグなしで動作させるには、seccompプロファイルのカスタマイズが必要になる場合があります。

テンプレートの共有と標準化

サンドボックス設定ファイルをGitHub Gistやリポジトリで共有することで、チーム全体で一貫したセキュリティレベルを維持できます。リポジトリの .antigravity/sandbox/ ディレクトリに設定ファイルを配置し、用途に応じて使い分けることを推奨します。

設定セット	ファイルアクセス	ネットワーク	プロセス	用途
最小セット	PJディレクトリのみ R/W	HTTPS (443)のみ	制限なし	個人開発
標準セット	PJ + /tmp R/W、/usr R	HTTPS + SSH	PID分離	チーム開発
厳格セット	PJ R/W のみ	ホワイトリスト	完全分離	本番CI/CD

4ツールのセキュリティアプローチ比較

自律型AIエージェントの安全性は、各ツールで根本的に異なるアプローチを採用しています。

機能	Antigravity	Claude Code	Cursor	VS Code Copilot
実行隔離	Strict Mode + OS Sandbox (Seatbelt/nsjail)	パーミッションモード（3段階）	Privacy Mode	Workspace Trust
ターミナル制御	Request Review / Auto / Turbo	承認 / 自動承認設定	ユーザー手動実行	Agent Mode内で承認
ブラウザ制御	browserAllowlist.txt	MCP経由	なし	なし
ファイルアクセス	Allow/Deny設定	.claudeignore	.cursorignore	.copilotignore
ネットワーク制限	Sandbox設定で制御	なし（API経由）	サーバー経由のみ	GitHub経由のみ

📝 Note

Antigravityはブラウザ操作機能を持つ唯一のツールであるため、browserAllowlist.txt によるURLホワイトリストが重要なセキュリティ境界となります。

browserAllowlist.txt の設定

外部サイトからの悪意あるコード読み込みやプロンプトインジェクションを防ぐため、信頼できるドメインのみを許可します。

~/.gemini/antigravity/browserAllowlist.txt

# 開発用
localhost
127.0.0.1

# 公式ドキュメント
developer.mozilla.org
docs.github.com
antigravity.google
cloud.google.com
reactjs.org

# 社内ツール（必要に応じて追加）
# internal.company.com

⚠️ Warning

本番環境のURLはAllowlistに含めないでください。エージェントが本番サイトを操作・スクレイピングするリスクがあります。ステージング環境のURLを使用しましょう。

拡張比較: モデル選択・拡張性・企業サポート

観点	Antigravity	Claude Code	Cursor	VS Code Copilot
マルチモデル	✅ 6モデル切替	❌ Claudeのみ	✅ 複数対応	✅ 複数対応
拡張機能	VS Code互換	プラグイン/Skills	独自拡張	VS Code拡張
企業SSO	❌ 未対応	✅ 対応	✅ 対応	✅ GitHub連携
SOC 2準拠	❌ 未取得	✅ 取得済	✅ 取得済	✅ GitHub準拠
オンプレミス	❌	❌	❌	✅ GHES対応

セキュリティポリシー

本番環境でのAntigravity運用には、明確なセキュリティポリシーの策定と実装が不可欠です。

承認ポリシーの設計

settings.json - 本番用セキュリティ設定

{
  "permissions": {
    "allow": [
      "Read(*.ts)",
      "Read(*.tsx)",
      "Read(*.json)",
      "Write(src/**)",
      "Write(tests/**)"
    ],
    "deny": [
      "Write(.env*)",
      "Write(*.pem)",
      "Write(*.key)",
      "Bash(rm -rf *)",
      "Bash(git push --force*)",
      "Bash(curl * | bash)",
      "Bash(DROP TABLE*)",
      "Bash(DELETE FROM * WHERE 1=1)"
    ]
  }
}

ファイルシステムアクセス制限

最小権限の原則
エージェントがアクセスできるディレクトリを src/、tests/、docs/ に限定します。設定ファイル（.env、credentials.json）へのアクセスは明示的に拒否します。
書き込み制限のレイヤー化
読み取りは広く許可し、書き込みは特定のディレクトリのみに制限。node_modules/ や .git/ への書き込みは常にブロックします。
機密ファイルの検出
PreToolUseフックで、書き込み対象ファイルに機密情報パターン（APIキー、パスワード、トークン）が含まれないかスキャンします。

ネットワーク制限

アウトバウンド制限 — npmレジストリ、GitHub API、Google Cloud APIのみ許可し、他の外部アクセスをブロック
インバウンド制限 — ローカル開発サーバー（localhost:3000等）のみ許可
DNS制限 — 許可されたドメインのみ名前解決を許可（DNSトンネリングの防止）

📝 Note

セキュリティポリシーはチーム全体で共有し、.antigravity/security-policy.json としてリポジトリにコミットしましょう。新メンバーが参加した際に自動的に適用されます。

チーム運用設計

チームでAntigravityを使う場合、個人設定とチーム共通設定を明確に分離し、一貫性のある開発体験を提供する設計が重要です。

共有GEMINI.mdの設計

ルートGEMINI.md（チーム共通）

プロジェクト全体のルール、コーディング規約、禁止パターンを記述。リポジトリにコミットし、PRレビューの対象にします。全メンバーが同じ基準でエージェントを使えるようにします。

ディレクトリ別GEMINI.md

src/frontend/GEMINI.md、src/backend/GEMINI.md のように、ドメイン固有のルールを分離。フロントエンドチームとバックエンドチームが独立してメンテナンスできます。

個人設定（.gitignore対象）

.antigravity/personal/ ディレクトリに個人の好みの設定（モデル選択、ショートカット設定等）を保存。.gitignore に追加してリポジトリから除外します。

チーム共通Skillsの管理

デプロイSkill — ステージング/本番デプロイ手順をSkill化し、手順の属人化を防止
コードレビューSkill — チームのコーディング規約に基づくレビューチェックリストをSkill化
テスト実行Skill — ユニットテスト、E2Eテスト、リント実行をワンコマンドで実行
リリースノートSkill — コミット履歴からリリースノートを自動生成

コーディング規約の統一

GEMINI.md - チーム規約セクション例

# コーディング規約
- TypeScript strict modeを常に使用
- 関数は30行以内、ファイルは300行以内
- テストカバレッジ80%以上を維持
- コミットメッセージはConventional Commits形式
- PRは1機能=1PR、レビュー前にセルフレビュー必須

# 禁止パターン
- any型の使用禁止（unknown + 型ガードを使用）
- console.logの本番コード混入禁止
- マジックナンバーの使用禁止（定数化すること）
- 直接的なDOM操作禁止（React/Vueのリアクティブシステムを使用）

CI/CD統合

GitHub ActionsやCloud BuildでAntigravityをCI/CDパイプラインに組み込み、コードレビューやテスト生成を自動化できます。

GitHub Actions統合

.github/workflows/antigravity-review.yml

name: Antigravity Code Review
on:
  pull_request:
    types: [opened, synchronize]

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Antigravity
        run: |
          curl -fsSL https://antigravity.dev/install.sh | bash
          echo "GOOGLE_API_KEY=${{ secrets.GOOGLE_API_KEY }}" >> $GITHUB_ENV

      - name: Run Code Review
        run: |
          antigravity review \
            --model gemini-2.5-flash \
            --diff "$(git diff origin/main...HEAD)" \
            --output review-comments.json

      - name: Post Review Comments
        uses: actions/github-script@v7
        with:
          script: |
            const comments = require('./review-comments.json');
            for (const c of comments) {
              await github.rest.pulls.createReviewComment({
                owner: context.repo.owner,
                repo: context.repo.repo,
                pull_number: context.issue.number,
                body: c.body,
                path: c.path,
                line: c.line
              });
            }

Cloud Build統合

cloudbuild.yaml

steps:
  - name: 'gcr.io/cloud-builders/npm'
    args: ['install']

  - name: 'antigravity-builder'
    args:
      - 'test-generate'
      - '--coverage-target=80'
      - '--model=gemini-2.5-flash'
    env:
      - 'GOOGLE_API_KEY=${_GOOGLE_API_KEY}'

  - name: 'gcr.io/cloud-builders/npm'
    args: ['test']

CI/CDでの活用パターン

パイプライン段階	Antigravityタスク	推奨モデル
PR作成時	自動コードレビュー	gemini-2.5-flash
テスト実行前	不足テストの自動生成	gemini-2.5-pro
マージ後	リリースノート生成	gemini-2.5-flash
デプロイ前	セキュリティスキャン	gemini-2.5-pro

✅ Tip

CI/CDでのAntigravity利用では、必ず --non-interactive フラグを使用してください。対話的な確認プロンプトが表示されるとパイプラインがハングします。

監視とログ

本番運用では、エージェントの活動ログ、コスト推移、品質メトリクスを継続的に監視する仕組みが必要です。

エージェント活動ログ

Antigravityのセッションログは ~/.antigravity/logs/ に自動保存されます。以下の情報が記録されます。

セッションID — 各セッションの一意識別子
ツール呼び出し履歴 — 実行されたすべてのツール（ファイル読み書き、コマンド実行）の記録
トークン消費量 — 入力/出力トークン数と推定コスト
エラーログ — サンドボックス違反、権限エラー、API制限到達の記録

コスト監視

コスト監視スクリプト例

#!/bin/bash
# 日次コストレポート生成
antigravity logs --format json --since "24h" | \
  jq '{
    total_sessions: length,
    total_tokens: [.[].tokens] | add,
    estimated_cost: ([.[].cost] | add),
    models_used: [.[].model] | unique
  }'

品質メトリクス

メトリクス	目標値	計測方法
テストカバレッジ変化率	+5% / 週	CI/CDレポートの差分
エージェント生成コードのバグ率	< 5%	PR後のバグ修正コミット数
セッションあたりの平均コスト	< $2	ログ集計
タスク完了率	> 80%	セッション中の手動介入回数

📝 Note

Google Cloud Monitoringやdatadog等のAPMツールと統合することで、エージェントのパフォーマンスをダッシュボードで可視化できます。異常検知アラートを設定し、コスト急増やエラー率上昇を早期に検知しましょう。

外部監視ツールとの統合

Datadog — Antigravityのログをdd-agentで収集し、カスタムメトリクス（Work Done消費率、エラー率）をダッシュボード化。タグでセッション単位の分析が可能
Prometheus — エージェント活動ログをexporterで公開し、Grafanaで可視化。アラートルールでコスト閾値超過やエラー率上昇を即時通知

.antigravity/monitoring.yml - 監視設定例

# .antigravity/monitoring.yml
logging:
  level: info
  export:
    format: jsonl
    path: ~/.antigravity/logs/agent-activity.jsonl
metrics:
  enabled: true
  endpoint: http://localhost:9090/metrics

障害対策

エージェントが予期しない動作をした場合のリカバリー手順を事前に準備しておくことが重要です。

エージェント暴走時の対処

即時停止
Ctrl+C を2回連続で入力してセッションを強制終了します。Always Proceedモードでも Ctrl+C は常に有効です。ターミナルが応答しない場合は、プロセスIDを特定して kill -9 で強制終了します。
変更の確認
git diff と git status で、エージェントが行ったすべての変更を確認します。意図しない変更がないか、ファイルの作成・削除・変更を1つずつ検証します。
選択的ロールバック
問題のある変更のみを git checkout -- <file> で元に戻します。全体をロールバックする場合は git stash で現在の変更を退避してから検討します。
原因分析
セッションログ（~/.antigravity/logs/）を確認し、暴走の原因を特定します。GEMINI.mdの指示の曖昧さ、権限設定の不備、モデルの誤選択が主な原因です。

ロールバック手順

段階的ロールバック

# 1. 現在の変更を退避
git stash

# 2. 直前のコミット状態を確認
git log --oneline -5

# 3. 特定のコミットまで戻す（ソフトリセット）
git reset --soft HEAD~1

# 4. 変更内容を確認してから再コミット
git diff --staged

# 5. 問題がなければ退避した変更を適用
git stash pop

予防策チェックリスト

定期的なコミット — エージェントに「10分ごとに進捗をコミットせよ」と指示し、ロールバックポイントを確保
ブランチ戦略 — mainブランチでの直接作業を禁止し、常にfeatureブランチで作業
バックアップ — 重要なファイルは作業前にコピーを取っておく（cp -r src/ src.bak/）
テスト実行 — 変更適用前に必ずテストスイートを実行し、既存機能の破壊がないことを確認

⚠️ Warning

エージェントによる git push --force は絶対に許可しないでください。リモートリポジトリの履歴が破壊されると、チーム全体に影響します。deny リストに必ず追加しましょう。

← 前のページ

よくある落とし穴

上級テクニック集