🏢

【Google Antigravity】実践ガイド Part 3 - チーム開発とガバナンス設計

に公開

はじめに

Part 2では、ワークフローとカスタムツールによる個人の生産性向上に焦点を当てました。

シリーズ最終回となる今回は、 「チーム開発」 でのAntigravity活用についてです。複数人でエージェントを使う場合、ルールがバラバラだとコードの品質やスタイルに不整合が生じます。

「みんなで同じルールを守る」「新人もベテランも同じ品質で開発する」ためのガバナンス設計を解説します。

https://zenn.dev/shineos/articles/google-antigravity-japanese-optimization
https://zenn.dev/shineos/articles/google-antigravity-workflow-automation

1. ルールの階層構造と共有

Antigravityのルール設定は、Gitリポジトリを通じてチーム全体で共有・同期することができます。

チームガバナンス
画像:共有ルールが各開発者に配布される仕組み

推奨されるディレクトリ構成

チームで運用する場合、専用の「ルールリポジトリ」を作るか、モノレポのルートに設定を置くのが一般的です。
基本的に .agent/ ディレクトリは Git にコミットして共有します(シークレットを除く)。

.agent/
├── rules/
│   ├── global.md       # 全プロジェクト共通の基本ルール (命名規則など)
│   ├── security.md     # セキュリティガイドライン
│   └── language/
│       ├── python.md   # Python固有のルール
│       └── typescript.md
├── workflows/          # チーム共通のワークフロー
│   ├── review.md
│   └── deploy.md
└── config.yaml         # ルールの適用設定

これらのファイルをGitで管理することで、 「PRでルールを変更し、マージされたら全員のエージェントが即座に新しいルールを学習する」 というサイクルが回せます。

✅ 共有すべきもの vs ❌ 共有すべきでないもの

設定ファイルの中には、チーム全体で統一すべきものと、セキュリティや個人の好みのために共有すべきでないものがあります。

✅ 共有すべきもの(Git管理対象)

  • .agent/rules/: 全員が守るべきコーディング規約
  • .agent/workflows/: チーム共通の自動化ワークフロー
  • .agent/config.yaml: プロジェクト全体の共通設定

❌ 共有すべきでないもの(.gitignore 対象)

  • .agent/secrets/: APIキーなどの機密情報(絶対コミットしない
  • .agent/local/: 個人ごとのエディタ設定や一時ファイル

2. レビューポリシーの設計

エージェントが生成したコードや実行内容を、どの程度人間がチェックするか? これはチームの習熟度やプロジェクトのフェーズによって異なります。

A. 全件レビュー (Strict Mode)

金融系や基幹システムなど、ミスが許されない場合。

  • 全てのコマンド実行、全てのファイル書き込みに対して、エージェントは人間の承認を待機します。
  • 速度は落ちますが、安全性は最大です。

B. 信頼ベース (Trusted Mode)

開発環境やプロトタイプ開発など。

  • 基本的に自動実行 (Auto モード)。
  • ただし、git pushDROP TABLE などの破壊的・不可逆な操作のみ deny リストに入れて承認必須にします。

C. ハイブリッド運用

おすすめは、ディレクトリやブランチによる使い分けです。

  • main ブランチ操作時は Strict。
  • feature/* ブランチ操作時は Trusted。
  • tests/ ディレクトリ内の変更は完全自動 (Turbo モード)。

3. ナレッジベースの共有

Antigravityのエージェントは、プロジェクト固有の情報を学んでいきますが、デフォルトではその記憶は個人のローカルに留まります。これをチーム資産にするには「ドキュメント駆動」を徹底します。

エージェントに口頭で教えるのではなく、 「ドキュメントを書いて、それをエージェントに読ませる」 のです。

  • オンボーディング資料 (docs/onboarding.md): プロジェクトの構成やセットアップ手順。
  • アーキテクチャ設計図 (docs/architecture.md): システム全体の構造。
  • トラブルシューティング (docs/troubleshooting.md): よくあるエラーと対処法。

これらが整備されていれば、新しいメンバー(人間もエージェントも!)が参加した際、即座にコンテキストを理解し、チームの作法に則ったコードを書けるようになります。

4. セキュリティと監査

企業での導入において最も重要なのがセキュリティです。

APIキーの管理

.env ファイルにAPIキーを保存するのが一般的ですが、Antigravityエージェントが誤ってこのファイルの中身をログに出力したり、外部に送信しないよう、.agentignore ファイルで厳密に除外設定を行います。

# .agentignore
.env
secrets/
*.pem

監査ログ (Audit Logs)

エンタープライズ版では、誰のエージェントが、いつ、どんなプロンプトで、何を実行したかのログを一元管理できます。不正なコード生成や、情報の持ち出しがないかを事後確認できるようにしておきましょう。

AI時代のTeam Topologiesへ

Google Antigravityをチーム導入することは、単にツールを変えるだけでなく開発プロセスそのものを見直す良い機会かと考えています。

Team Topologiesとは、認知負荷や依存関係を考慮しながら、チーム構造とインタラクションを設計することで、ソフトウェアデリバリーのスピードと品質を高める手法です。

  • 暗黙知を形式知(ルールファイル、ドキュメント)に変える。
  • 定型作業をワークフローとしてコード化する。
  • 権限と責任の範囲を明確にする。

これらは、AIがいなくても本来やるべき「良い開発チーム」の条件そのものです。Antigravityは、その実現を強力に後押ししてくれます。

全3回のガイドにお付き合いいただきありがとうございました🙌
ぜひ、始めてみてください🍺

Discussion