実践ワークフロー
Google Antigravityを使った実践的な開発パターンとハイブリッド運用戦略。日常の開発フローを最大限に効率化。
Planning Mode と Fast Mode
Antigravityには2つのエージェント実行モードがあり、タスクの規模に応じて使い分けることで、クォータの無駄遣いを防ぎつつ品質を確保できます。
| モード | 動作 | 推奨タスク | Work Done消費 |
|---|---|---|---|
| Planning Mode | まずPlan(計画)を提示し、承認後に実装 | 新機能開発、大規模リファクタリング、複雑なバグ修正 | 多い(計画+実装)が品質は高い |
| Fast Mode | 計画を省略し即座に実装 | タイポ修正、変数名変更、1ファイルの軽微な修正 | 少ない(即実行) |
Planning Modeでの開発は「Plan提出 → 差分(Diff)作成 → ブラウザ・テスト検証」の3ステップを繰り返すのが最も効果的です。計画→実装→検証のサイクルを回すことで、手戻りを最小限に抑えられます。
モード選択フローチャート
このタスクに Planning Mode は必要?
│
├─ ファイル数: 3つ以上に影響 → Planning Mode
├─ リスク: 本番環境に影響する → Planning Mode
├─ 依存関係: 他タスクとの調整が必要 → Planning Mode
├─ 変更規模: 100行以上の変更 → Planning Mode
│
└─ 上記すべてNoなら → Fast Mode
(タイポ修正、変数名変更、コメント追加など)カスタムWorkflows
/ コマンドで呼び出せるカスタムWorkflowを .agents/workflows/ に定義することで、繰り返しの開発パターンを型化できます。
---
name: generate-unit-tests
description: 指定ファイルのユニットテストを生成
---
# ユニットテスト生成ワークフロー
1. 対象ファイルの全エクスポート関数・クラスを特定
2. 各関数のInput/Output パターンを分析
3. 正常系・異常系・境界値のテストケースを設計
4. テストファイルを `__tests__/` または `*.test.ts` に生成
5. テストを実行し、全パスを確認
## ルール
- 既存テストがある場合は追加・補完のみ
- mockは最小限、実際のロジックをテスト
- テストカバレッジ80%以上を目標# エージェントチャットで:
/generate-unit-tests src/services/auth.tsWorkflowsはチーム全員で共有できます。.agents/workflows/ をGitにコミットすることで、チームの開発パターンを標準化できます。
動詞-目的語 形式を推奨。例: generate-unit-tests, deploy-staging, review-pr, create-migration。チーム共有時はREADME.mdを.agents/workflows/に追加し、各Workflowの用途と引数を説明しましょう。
日常開発ワークフロー
Antigravityを最大限に活用するための1日の開発フローです。朝のセットアップから夕方のクロージングまで、エージェントとの協働パターンを定型化することで、日々の生産性を安定させます。
朝: セットアップ(10分)
Antigravityを起動し、前日の作業状態を確認します。git status と git log で未マージのブランチやスタッシュを確認。今日のタスクを整理し、エージェントに1日の計画を共有します。
午前: 計画 & 設計(1-2時間)
Plan Modeでタスクの分析と設計を行います。大きなタスクは小さなサブタスクに分割し、並列実行可能なものを特定します。インターフェース定義やAPIスキーマを先に固めます。
午後: 並列実装(3-4時間)
設計に基づいて複数のエージェントを起動し、並列で実装を進めます。Manager Viewで進捗を監視しながら、承認リクエストに対応します。人間は全体のコーディネーションに集中します。
夕方前: レビュー & マージ(1時間)
各エージェントの成果をレビューします。Artifacts差分を確認し、問題があればフィードバックを送信。問題なければブランチをマージし、CIパイプラインの通過を確認します。
夕方: 振り返り & 記録(15分)
今日の学びをCLAUDE.mdやlessons.mdに追記します。繰り返し使ったプロンプトパターンはSkillとして定義し、翌日以降の効率化に繋げます。
「朝の計画に30分かける」ことで、午後の実装効率が劇的に向上します。計画なしの即興実装は、手戻りやエージェントの再実行でかえって時間がかかります。
機能開発パターン
新機能の開発をAntigravityで効率化するための標準パターンです。Issue受領からPR作成までの一連の流れを定型化しています。
-
Issue分析
GitHub/Jira等からIssueを取得し、エージェントに共有します。「このIssueの要件を分析し、影響範囲を特定して」と指示。エージェントが関連ファイル、依存関係、テスト範囲を洗い出します。 -
設計ドキュメント作成
Plan Modeで実装計画を策定します。「この機能の実装計画を、サブタスク・見積もり時間・リスク付きで作成して」と指示。出力をドキュメントとして保存し、チームレビューに回します。 -
ブランチ作成 & Worktree準備
git worktree addで隔離された作業ディレクトリを作成。並列実行が必要な場合は複数のWorktreeを準備します。 -
テスト先行(TDD)
まずテストを作成するエージェントを起動。「この機能のユニットテストとintegrationテストを、仕様に基づいて作成して」と指示。テストが先にあることで、実装の方向性が明確になります。 -
並列実装
テスト作成と並行して、実装エージェントを起動。フロントエンド・バックエンド・インフラを別々のエージェントに割り当てます。 -
統合テスト & PR作成
全てのサブタスクが完了したら、結合してテストを実行。通過したらエージェントにPRの説明文を作成させ、レビュー依頼を出します。
# Issue分析フェーズ
「Issue #234 の要件を分析してください。
- 影響を受けるファイルのリスト
- 必要なDB変更の有無
- 既存テストへの影響
- 推定実装時間
を整理してください。」
# 実装フェーズ
「以下の設計に基づいて実装してください。
- テストファーストで進めること
- 既存のコーディング規約に従うこと
- 完了条件: 全テストパス、lint error 0、型エラー 0」バグ修正パターン
バグ報告を受けてから修正・検証までのエージェント活用パターンです。エージェントの探索能力を活かし、人間が見落としがちな根本原因を特定します。
Phase 1: ログ分析・再現
まずエージェントにバグ報告とログを共有し、再現手順を確立します。
「以下のエラーログを分析してください。
[エラーログを貼り付け]
1. エラーの直接的な原因
2. 再現手順の推定
3. 関連するソースファイルの特定
4. 過去に似たバグがなかったか git log で調査
をお願いします。」Phase 2: 原因特定
エージェントがコードベースを探索し、根本原因を特定します。Plan Modeを使い、修正方針を複数案提示させます。
- 直接原因 — エラーが発生している箇所
- 根本原因 — なぜそのエラーが発生したか(設計上の問題、エッジケースの未処理など)
- 関連箇所 — 同じパターンが他にもないか(横展開チェック)
Phase 3: 修正 & 検証
修正エージェントとテストエージェントを並列で起動します。修正エージェントがコードを直し、テストエージェントがリグレッションテストを作成・実行します。
バグ修正では「修正によって新たなバグを生まないこと」が最重要です。必ずリグレッションテストを追加し、/compact 前に修正理由をコメントとして記録してください。
コードレビュー
エージェントをコードレビュアーとして活用するパターンです。人間のレビュー前にエージェントで事前チェックすることで、レビュー品質と速度を両立します。
事前レビュー(Pre-Review)
PRを出す前に、エージェントに自己レビューを実施させます。
「このブランチの変更を以下の観点でレビューしてください。
1. バグの可能性(null参照、境界値、型不一致)
2. セキュリティ(SQLインジェクション、XSS、認証チェック漏れ)
3. パフォーマンス(N+1クエリ、不要なループ、メモリリーク)
4. テストカバレッジ(未テストのブランチ、エッジケース)
5. コーディング規約の遵守
6. ドキュメント・コメントの適切性
問題があれば、ファイル名・行番号・修正案を具体的に示してください。」品質チェック自動化
定型的なチェック項目はSkillとして定義し、毎回のPRで自動実行します。
| チェック項目 | 自動化方法 | ブロッキング |
|---|---|---|
| リント・フォーマット | CI/CDパイプライン | Yes |
| 型チェック | CI/CDパイプライン | Yes |
| ユニットテスト | CI/CDパイプライン | Yes |
| セキュリティスキャン | エージェントSkill | Yes |
| パフォーマンス分析 | エージェントSkill | No(Warning) |
| ドキュメント充足度 | エージェントSkill | No(Info) |
エージェントによるレビューは人間のレビューの「代替」ではなく「補完」です。エージェントは機械的なチェックに強く、人間はビジネスロジックの妥当性やアーキテクチャ判断に強い。両方を組み合わせるのが最も効果的です。
ハイブリッド運用
Google Antigravityは単独で使うだけでなく、他のAIコーディングツールと組み合わせることで、さらに強力になります。各ツールの強みを活かしたハイブリッド運用戦略です。
ツール別の使い分け
| ツール | 最適なタスク | Antigravityとの併用パターン |
|---|---|---|
| Google Antigravity | 大規模タスク、並列実行、プロジェクト全体の変更 | メインツールとして使用 |
| Claude Code | ターミナル直結の操作、CLIベースのワークフロー | Antigravityが不得意な低レベル操作の補完 |
| OpenAI Codex | 非同期バッチ処理、大量ファイルの一括変更 | 夜間バッチや大規模リファクタリングを委任 |
| GitHub Copilot | リアルタイム補完、インライン提案 | 手動コーディング時のアシスト |
| Cursor | エディタ統合型の対話、ファイル単位の編集 | 特定ファイルの集中編集に使用 |
ハイブリッド運用の実践例
設計: Antigravity(Plan Mode)
プロジェクト全体を俯瞰した設計をAntigravityのPlan Modeで実施。1Mコンテキストで大規模プロジェクトも対応。
実装: Antigravity(並列Agent)
設計に基づいて複数のエージェントを並列実行。大きなタスクはAntigravityの並列能力を最大活用。
微調整: Copilot / Cursor
エージェントの出力を手動で微調整する際は、CopilotやCursorのインライン補完を活用。小さな修正に最適。
夜間バッチ: Codex
テスト網羅、ドキュメント生成、大規模リネームなどの時間のかかる作業はCodexに非同期で委任。翌朝レビュー。
ハイブリッド運用の鍵は「どのツールで何をするか」を事前に決めておくことです。ツール選択に迷う時間は純粋なロスです。チームでツール使い分けガイドラインを策定し、CLAUDE.mdに記載しておきましょう。
CI/CD連携
AntigravityをCI/CDパイプラインに統合することで、デプロイプロセスの自動化と品質保証を強化します。
GitHub Actions連携
GitHub Actionsからエージェントを呼び出し、PRの自動レビューやテスト生成を行います。
name: Agent Review
on:
pull_request:
types: [opened, synchronize]
jobs:
agent-review:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run Antigravity Review
uses: google/antigravity-action@v1
with:
task: "review"
model: "gemini-3.1-pro-high"
config: |
checks:
- security
- performance
- test-coverage
severity_threshold: "warning"
env:
ANTIGRAVITY_API_KEY: ${{ secrets.ANTIGRAVITY_API_KEY }}
- name: Post Review Comment
uses: google/antigravity-action@v1
with:
task: "comment"
target: "pr"GitHub Actions詳細設定例
ルールファイルやモデル指定を含む、より実践的なCI/CD統合の例です。
# .github/workflows/antigravity-review.yml
name: AI Code Review
on: [pull_request]
jobs:
review:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run Antigravity Review
uses: google/antigravity-action@v1
with:
mode: review
model: gemini-3-flash
rules: .agents/rules/
env:
ANTIGRAVITY_API_KEY: ${{ secrets.ANTIGRAVITY_API_KEY }}Cloud Build連携
Google Cloud Buildとの連携例です。ビルド失敗時にエージェントが自動的にエラー分析を行い、修正PRを提出します。
steps:
- name: 'node:20'
entrypoint: 'npm'
args: ['ci']
- name: 'node:20'
entrypoint: 'npm'
args: ['test']
# テスト失敗時にエージェントが分析
- name: 'gcr.io/antigravity/agent:latest'
entrypoint: 'antigravity'
args:
- 'analyze-failure'
- '--model=gemini-3-flash'
- '--output=cloudbuild-report'
waitFor: ['-']
allowFailure: trueデプロイ前チェック
デプロイパイプラインにエージェントによるチェックを組み込むことで、本番リリースの安全性を向上させます。
- マイグレーション検証 — DBマイグレーションの安全性をエージェントが事前チェック。ロールバック可能性の確認
- 設定ファイル差分 — 環境変数やシークレットの変更有無を検出し、必要な設定追加をアラート
- 依存関係の脆弱性 — 新しく追加されたパッケージの脆弱性スキャン
- パフォーマンス回帰 — ベンチマーク結果の比較と回帰検知
CI/CDパイプラインでのエージェント実行は、APIキーの管理に特に注意してください。必ずシークレットマネージャーを使用し、ログへのキー露出を防止してください。また、エージェントのCI実行には読み取り専用のリポジトリアクセス権限を付与するのが安全です。
CI/CD連携はAntigravityのAPI(ベータ版)を使用します。2026年Q2時点ではGitHub Actions用の公式Actionが提供されており、Cloud BuildやCircleCIへの対応も進行中です。