第2章 フェーズ別ツール選定ガイド
開発は6つのフェーズを辿ります。各フェーズでの最適ツール選定を解説します。
Phase 0: 企画・要件定義（Week 1-2）
優先度: 1位 Antigravity、2位 Cursor
要件が曖昧な段階で、スペックを素早く確定する必要があります。
Antigravity を選ぶ理由
マルチエージェント で観点漏れなし — Backend Architect は「APIエンドポイント」、Frontend Builder は「UI流」、Security Auditor は「認可」を同時に考える。1つの LLM では気づかない交差点を検出
スペック駆動 で要件を固める — 「次のフェーズへ進んでよいか」の判定が明確
1M トークン で全プロジェクト把握 — 過去のドメイン知識（同じ業界の過去プロジェクト等）を学習させて、ベストプラクティス提案
Antigravity指示例:
「新しいe-commerce プラットフォームの要件定義をしてほしい。
過去のオンライン販売システム3件の AGENTS.md を参考にしながら、
このプロジェクト用の Specification v1.0 を作成してください。
観点:
- フロントエンド：購入フロー、決済、アカウント管理
- バックエンド：在庫管理、決済連携、レコメンドエンジン
- セキュリティ：PCI DSS 準拠、3D-Secure
- インフラ：スケーラビリティ（Black Friday対応）
成果物: 50-100ページの Specification + AGENTS.md v1.0」
所要時間: 2-3時間
出力: Specification v1.0（決定版、変更不可）
Cursor を補助的に使う場面
スペック案の「具体的なコード例」を素早く示したい
既存プロダクトのコードを参考に「こういう実装パターンはどう？」と相談
Phase 1: アーキテクチャ・スケルトン構築（Week 3-4）
優先度: 1位 Antigravity、2位 Claude Code
Specification に基づき、プロジェクトの骨組みを作ります。
Antigravity をフル活用
Backend Architect + Frontend Builder + DevOps Engineer を同時に動かします。
Antigravity指示例:
「Specification v1.0 に基づいて、以下を並列で進めてください：
L1: Project Coordinator
├ L2: Backend Architect
│ 作業: OpenAPI 3.0 仕様書生成、データベーススキーマ
│ 納期: Day 2
│
├ L2: Frontend Builder
│ 作業: コンポーネント設計書、Storybook setup
│ 納期: Day 2
│
└ L2: DevOps Engineer
作業: Kubernetes マニフェスト、Docker setup
納期: Day 2
全て完了したら、統合テスト用テンプレート作成してください」
所要時間: 1-2日（3エージェント並列）
出力: API仕様書、UI Component 一覧、デプロイメント構成
Claude Code で Terraform/Ansible 設定自動生成
スケルトン作成後、「インフラコードを Git に commit したい」という場面で Claude Code の「ターミナルネイティブ」が活躍します。
Claude Code指示例:
「AWS 上で、以下を構成する Terraform を生成してください：
- VPC, Subnet, Security Group
- ECS cluster (Fargate), RDS (Postgres), ElastiCache (Redis)
- CloudFront CDN + S3 origin
- CloudWatch monitoring + SNS alerts
生成後、直ちに `terraform plan` を実行して出力を確認」
所要時間: 30分
実行結果: Terraform apply 可能な状態
Phase 2: 機能実装（Week 5-12）
優先度: 1位 Cursor、2位 Claude Code、3位 Antigravity
このフェーズが最長で、フェーズごとの特性が顕著に現れます。
Cursor: メイン開発マシン
パターン A：「既存コードへの機能追加」
例: 会員登録画面に「OAuthログイン」ボタンを追加
Cursor指示:
「src/pages/signup.tsx の、
<form> セクションの直後に
OAuth ログインボタンを追加。
使うコンポーネント: OAuthButton (既にimportされている)
デザイン: 既存のボタンと同じ Tailwind style
変更: signup.tsx だけ」
所要時間: 30秒～1分
修正行数: 3-5行
Cursor の @-mention で対象ファイルを明示すれば、LLM は余計な変更を加えません。既存の形式・スタイル・依存関係を自動で推測して、「割り込み感なし」の追加実装ができます。
パターン B：「新規モジュール実装」
例: 「ユーザーの購買履歴を集計するモジュール」
Cursor指示:
「新しいモジュール src/services/purchaseAnalytics.ts を作成。
要件:
- 関数 getPurchaseStats(userId: string): Promise<PurchaseStats>
- 直近3ヶ月のデータを集計
- キャッシュは Redis で1時間
- error handling: ユーザー不在の場合は null
参考: 既存の src/services/userService.ts のパターン」
所要時間: 2-3分
コード行数: 30-50行
テスト: 別途 Claude Code で自動化
Cursor は 「小単位の実装」「修正」「リファクタ」 に最適です。機能追加の90%をこれで片付けます。
Claude Code: テスト・自動化・デプロイ
各機能実装の傍らで、CI/CD パイプラインを並列構築します。
Claude Code指示:
「Cursor で実装された purchaseAnalytics.ts に対する
テストスイートを作成してください（Jest）。
テストケース:
1. 正常系：ユーザーの3ヶ月分の購買データ取得
2. キャッシュ：2回目の呼び出しは Redis から
3. エラー：ユーザーが存在しない場合は null
4. エラー：Redis接続失敗時はフォールバック
実装後、直ちに `npm test` を実行」
所要時間: 3-5分
テスト行数: 40-60行
カバレッジ: 90%以上
さらに、GitHub Actions のワークフローファイル .github/workflows/ci.yml を生成・更新：
Claude Code指示:
「GitHub Actions ワークフローを更新してください：
1. Push 時に自動 test + lint
2. Pull Request に coverage comment
3. Main branch へのマージ後、自動デプロイ (Staging)
実装: Node.js 20.x, Postgres test DB, 実行時間 < 5分」
所要時間: 2-3分
メンテナンス性: 高（Infrastructure as Code）
Antigravity: 困った時の「全体ビュー」
実装フェーズでの Antigravity の活躍シーンは「意思決定が必要な時」です。
例: 「このAPIの仕様を変更するべきか」という判断が必要な場合
Antigravity指示:
「現在のプロジェクト状況:
- Backend: payment API 実装中 (80% 完)
- Frontend: 決済画面の UI 実装中 (60% 完)
- Security: PCI DSS compliance check で API 仕様に問題指摘
問題: API response の フィールド追加が必要だが、
Frontend は既に response の型定義を完了している。
判断が必要:
1. API 仕様変更 → Frontend の型定義も変更 → 両者1日遅延
2. 現仕様で compliance 要件を別の方法で満たす？
AGENTS.md と Specification v1.0 を踏まえて、最適案を提案」
所要時間: 3-5分
出力: Architecture Decision Record（何を選んで、なぜか）
Phase 3: 統合テスト・品質向上（Week 13-14）
優先度: 1位 Claude Code、2位 Cursor、3位 Antigravity
複数の機能が揃ったので、それらが調和して動くか確認します。
Claude Code: テスト自動化の核
Claude Code指示:
「E2E テスト（Playwright）を作成。以下のユーザーフロー：
1. ユーザー登録
2. ログイン
3. 商品検索
4. カートに追加
5. 決済
6. 注文確認メール受信
条件:
- Staging 環境で実行
- スクリーンショット自動取得（失敗時）
- 実行時間制限: 3分以内
- 毎 Pull Request 時に自動実行
実装後、`npm run test:e2e` で実行してレポート表示」
所要時間: 10-15分
テスト行数: 100-150行
信頼度: 95%以上（人間のテスターを補完）
並列で、パフォーマンス計測スクリプト：
Claude Code指示:
「Google Lighthouse API を使った自動パフォーマンス計測を実装。
毎日 Staging 環境で実行し、結果を JSON で保存。
測定項目:
- LCP（最大コンテンツペイント）
- FID（初回入力遅延）
- CLS（累積レイアウトシフト）
- Performance Score
前日との差分を Slack に通知」
所要時間: 5分
継続効果: 毎日のパフォーマンス可視化
ROI: 極めて高（数行の変更でも影響を即座に発見）
Cursor: パフォーマンス最適化
Cursor指示:
「src/components/ProductList.tsx が遅い。
以下を実装してください：
1. React.memo で不要な再レンダリング防止
2. useCallback で event handlers の安定化
3. 必要に応じて useMemo で計算結果キャッシュ
変更前後で Lighthouse Performance Score を比較」
所要時間: 2-3分
改善後: LCP -0.5秒, FID -30ms 等を測定
Phase 4: セキュリティ監査・コンプライアンス（Week 15）
優先度: 1位 Antigravity、2位 Claude Code
本番リリース前に、Security Auditor と Compliance Officer に全体チェックを任せます。
Antigravity指示:
「Production リリース前のセキュリティレビュー。
対象:
- 全 backend API
- 全 frontend コンポーネント
- インフラ構成（Terraform）
チェック項目（AGENTS.md より）:
- OWASP Top 10
- 依存関係の脆弱性スキャン
- 環境変数の管理（.env.example vs 実値）
- GDPR / 個人情報保護方針準拠
- 暗号化（トランジット＋アットレスト）
各項目でこのプロジェクトの状況を診断し、
修正すべき項目を Priority レベル付きで列挙」
所要時間: 30分～1時間
出力: Security Review Report（修正項目 + Timeline）
修正の実装は Cursor で：
Cursor指示:
「Security Review の Priority-1 項目（3件）を修正：
1. src/api/auth.ts: Bearer Token の validation を厳格化
2. src/db/queries.ts: Prepared Statement への完全移行
3. .env.example: 全環境変数を型付けで定義
参考: AGENTS.md の Security Guidelines セクション」
所要時間: 15-20分
Phase 5: 本番デプロイメント・モニタリング（Week 16）
優先度: 1位 Claude Code、2位 Antigravity
Claude Code指示:
「本番デプロイメントパイプラインを構築：
ステップ:
1. Git tag v1.0.0 を付与
2. Docker image ビルド + ECR push
3. Kubernetes manifest に新 image tag を適用
4. kubectl apply で Staging 環境にデプロイ
5. Smoke test 実行（Staging で疎通確認）
6. Production へ Canary deploy (5% → 25% → 100%)
7. CloudWatch alarm 監視 (error rate > 1% でロールバック)
実装後、ドキュメント を README に追記」
所要時間: 20-30分
再利用性: 毎回のリリースで実行（コスト 2-3分）
信頼度: 自動化により人的ミス 0 化
さらに、アラート・ダッシュボード：
Claude Code指示:
「CloudWatch + Grafana で本番モニタリングダッシュボード：
メトリクス:
- API レスポンスタイム (P99)
- Error rate (5xx)
- Database connections
- Redis hit rate
- User signup funnel drop rate
ウィーク単位での傾向分析スクリプトも作成」
所要時間: 10-15分
継続効果: 24/7 可視性
アラート: Slack + PagerDuty 統合
第3章 AGENTS.md による 3ツール統一
複数ツール運用で最大の課題は「ツール間の不一致」です。「Antigravity では Python」「Cursor では JavaScript」みたいにバラバラになると、後で統合コストが大きくなります。
これを防ぐ唯一の方法が AGENTS.md です。
AGENTS.md の「ツール別定義」セクション
# AGENTS.md — Team Development Standards
## 言語・フレームワーク（全ツール共通） - Frontend: TypeScript 5.x + React 18 + Tailwind CSS 3.x - Backend: TypeScript 5.x + Node.js 20 LTS + Express 4.x - Database: PostgreSQL 15 - Infrastructure: Terraform 1.6.x
## コード品質基準（全ツール共通） - ESLint preset: eslint-config-next (frontend) / eslint-config-node (backend) - Type checking: TypeScript strict mode - Test coverage: >= 80% - Formatting: Prettier (line width 100)
## ツール別の利用シーン
### Antigravity - 用途: 要件定義、大規模アーキテクチャ設計、複数エージェント統合 - 対象タスク: Specification 作成、Phase 0-1 - 成果物: Markdown ドキュメント、Architecture Decision Records
### Cursor - 用途: 機能実装、サージカル編集、リファクタ、コードレビュー対応 - 対象タスク: Phase 2（メイン開発） - プリセット: VSCode settings.json, .eslintrc.json の共通化
### Claude Code - 用途: テスト自動化、CI/CD構築、スクリプト生成、パフォーマンス計測 - 対象タスク: Phase 3-5（自動化・デプロイ） - 成果物: Bash/Python スクリプト, GitHub Actions YAML
## クロスツール検証
Cursor で実装 → Claude Code で テスト生成 → Antigravity でアーキテクチャ無矛盾を確認、 このフローが回るためには、全ツール共通の「型」「命名規則」「依存関係」を AGENTS.md で定義する AGENTS.md 同期のワークフロー
Week 0（プロジェクト開始）:
Antigravity で Specification v1.0 + AGENTS.md v1.0 作成
Week 1-16（開発進行中）:
変更が生じたら:
1. AGENTS.md に記載 (例: 「ESLint rule を追加」)
2. 全ツール（Cursor, Claude Code）に周知
3. 既存コードの修正は段階的（新規コードから適用）
Week 16（リリース直前）:
AGENTS.md Final Review
- TypeScript strict mode で完全対応？
- テスト coverage >= 80%？
- 依存関係スキャン Critical = 0？
→ これが本番リリースの Gate
第4章 実践的なクロスツール開発フロー
ここまで「各ツール何をするのか」を解説しました。実際のワークフローを見てみましょう。
ユースケース: 「推薦エンジン」機能の実装例
Day 1: Antigravity で要件定義
Manager: 「推薦エンジン機能を追加したい。
- ユーザーの過去購買データから関連商品を推薦
- リアルタイムのバッチ処理（毎時間）
- Mobile + Web 両対応
スペックを固めてくれ」
Antigravity タスク:
L1: Backend Architect + Frontend Builder (共同執筆)
- API スペック（GET /recommendations/{userId}）
- レスポンス型（商品ID + スコア）
- キャッシュ戦略（TTL 1時間）
- エラーハンドリング
L2: Database Engineer
- テーブル設計（user_interactions, product_recommendations）
- インデックス（user_id, created_at）
- パーティショニング（月単位で分割）
L3: DevOps Engineer
- バッチ処理スケジュール（Kubernetes CronJob）
- リソース使用量見積もり（CPU, メモリ）
所要時間: 3-4時間
成果物: Specification v1.0（API仕様書 + DB 設計書 + インフラ構成）
確認: 全エージェント内での無矛盾
Day 2: Claude Code で バッチスクリプト実装
Antigravity の成果物が揃ったので、バックグラウンドで実行するバッチ処理を実装。
Claude Code 指示:
「推薦エンジンのバッチ処理を実装。
流れ:
1. PostgreSQL から user_interactions テーブルを読み込み
2. Collaborative Filtering (簡易版) で類似度計算
3. 上位 10 商品を product_recommendations に保存
4. 実行ログを CloudWatch へ送信
要件:
-実行時間: < 30分 (毎時間実行のため)
- メモリ使用量: < 512MB
- エラー時の automatic retry: 3回
実装後、ローカルで完全テスト。全ユーザー100万人のシミュレーションデータで実行」
所要時間: 2-3時間
言語: Python + PostgreSQL
コード行数: 100-150行
テスト: CSV dump から検証
Day 3: Cursor で Frontend 実装
Cursor 指示:
「ProductCard コンポーネントに、推薦タグを追加。
変更対象: src/components/ProductCard.tsx
要件:
- 推薦スコア 0-100 を「推薦度」ゲージで表示
- スコア 70+ なら背景色を light blue で目立たせる
- クリックで詳細を「なぜこれが推薦されたか」ページへ
デザイン参考: Figma の ProductCard component」
所要時間: 5-10分
修正行数: 15-20行
テスト: 既存の Storybook で確認
同時に、推薦 API の呼び出しロジック：
Cursor 指示:
「新しい Hook を作成: useRecommendations(userId)
要件:
- GET /api/recommendations/{userId} を呼び出し
- Loading 状態を管理
- Error handling（API失敗時は空配列）
- キャッシュ: 同一ユーザーへの再呼び出しは1分内キャッシュ
使用例:
const { recommendations, isLoading, error } = useRecommendations(userId);
実装後、ProductPage コンポーネントで使用」
所要時間: 3-5分
Hook コード行数: 30-40行
Day 4: Claude Code で テスト・デプロイ
Claude Code 指示:
「推薦エンジン機能の E2E テストを実装（Playwright）。
テストシーン:
1. ホーム画面で推薦商品が表示される
2. 推薦商品をクリックして詳細ページへ遷移
3. 「なぜ推薦？」の説明ポップアップが表示される
4. 推薦商品が実際に購買フローに進むまで
テストデータ: test_user_001（過去購買100件）
実行後、Staging 環境で `npm run test:e2e:recommendations`」
所要時間: 20分
テストコード行数: 60-80行
カバレッジ: 全主要フロー
バッチジョブの監視スクリプト：
Claude Code 指示:
「推薦バッチジョブの監視スクリプトを実装。
定期実行: 毎時間 (UTC 0, 1, 2, ... 23)
監視項目:
- ジョブ実行時間（前回との差が 50% 以上なら alert）
- メモリ使用量（peak が 512MB 超過で alert）
- エラーレート（1% 以上なら alert）
- 推薦件数の統計（平均, min, max）
実装: Python + boto3 (CloudWatch へ query)
出力: Slack 通知 + Grafana ダッシュボード更新」
所要時間: 15-20分
継続効果: 24/7 監視
Day 5: Antigravity で 全体動作確認
Antigravity 指示:
「推薦エンジン機能の全体統合テスト。
確認項目:
1. バッチスクリプト（Claude Code）が期待通り動作
2. Frontend（Cursor）が推薦データを正しく表示
3. API response time が SLA 内（< 500ms）
4. データベース query が index 活用できているか
各エージェントからのレポートを集約し、
本番デプロイ前の Gate チェック（go/no-go 判定）を実行」
所要時間: 1-2時間
成果物: Integration Test Report + Go/No-go Decision
結果
所要時間 : 5日（従来のシングルツール運用だと 10-12日）品質 : バグ 0 件、Lighthouse Performance Score 改善 5ポイントコスト : 全ツール利用で月額 ¥30-40k（人件費削減率 30%）スケーラビリティ : このパターンをテンプレート化できたため、次回の機能追加はさらに高速化
第5章 コスト分析と投資対効果
3ツール並行利用は「割高」に見えます。実際のコストを計算してみましょう。
月額コスト比較
シナリオ 1: シングルツール（Cursor のみ）
Cursor Pro: ¥2,000/月（無制限）
開発 1 機能（5日）での工数配分:
- Cursor で実装: 4日
- 手動テスト: 0.5日
- デプロイ・監視スクリプト手作成: 0.5日
─────────────────────
合計: 5日（給与換算 ¥100k/5days = ¥20k）
月 1 機能ペース: Cursor ¥2k + 人件費 ¥20k = **¥22k/月**
シナリオ 2: 3ツール併用
Antigravity Pro: ¥5,000/月
Cursor Pro: ¥2,000/月
Claude Code: ¥3,000/月（API利用）
合計: ¥10,000/月
同じ 1 機能（5日）での工数配分:
- Antigravity で設計・スペック: 0.5日（マルチエージェント並列）
- Cursor で実装: 2日（集中度 UP、修正少ない）
- Claude Code でテスト自動化: 1日（以後の回帰テストで工数 50% 削減）
- デプロイ・監視: 0.5日（自動化スクリプトで時間短縮）
─────────────────────
合計: 4.5日（給与換算 ¥100k/4.5days = ¥18k）
月 1 機能ペース: ツール ¥10k + 人件費 ¥18k = **¥28k/月**
見た目: ¥6k コスト増加 ← 間違った見方
実は効果が大きい部分
翌月以降の回帰テスト :
シングルツール（Cursor）:
新機能開発: 5日
既存機能の回帰テスト（手動）: 3日
─────────────
計 8日/月
3ツール併用:
新機能開発: 4.5日
既存機能の回帰テスト（自動化済み CI/CD）: 0.5日 ← Claude Code で自動化
─────────────
計 5日/月
**削減: 3日/月 ≈ ¥60k相当**
6ヶ月間のコスト比較
シングルツール（Cursor）:
ツール: ¥2k × 6 = ¥12k
人件費: ¥20k/月 × 6 = ¥120k
合計: ¥132k
3ツール併用:
ツール: ¥10k × 6 = ¥60k
人件費: ¥18k/月 (月1) + ¥12k/月 (月2-6, テスト自動化効果) × 5 = ¥138k
合計: ¥198k
見た目: ¥66k コスト増加 ← 誤った分析
実際には:
新機能リリース速度: 月1個 → 月1.2個（20% UP）
バグ率: 3% → 0.8%（自動テスト効果）
開発者 burn out: 高 → 低（自動化で退屈業務削減）
収益面での効果（月1.2個 × 単価）は ¥66k を十分にカバー
第6章 実装チェックリスト
3ツール運用を開始する際の確認項目。
プロジェクト開始時（Day 0）
[ ] AGENTS.md v1.0 を作成（言語、フレームワーク、ツール別運用ルール）
[ ] 3ツール全てで有効なアカウントを用意（Antigravity Pro, Cursor Pro, Claude Code API key）
[ ] Git + GitHub 、CI/CD パイプライン（GitHub Actions）をセットアップ
[ ] Cursor, Claude Code の設定ファイル（.eslintrc.json, prettier.config.js 等）を Repo に commit
Phase 1（設計フェーズ）確認
[ ] Antigravity で Specification v1.0 が完成（変更不可の状態）
[ ] AGENTS.md が技術スタック確定
[ ] 各ツール（Cursor, Claude Code）の担当タスクが明確化
Phase 2-3（実装フェーズ）確認
[ ] Cursor での実装が AGENTS.md に準拠（ESLint, TypeScript strict)
[ ] Claude Code でテスト自動化が並列進行（カバレッジ >= 80%）
[ ] GitHub Actions の CI/CD が全 PR で自動実行（merge block の仕組み）
Phase 4-5（QA・本番フェーズ）確認
[ ] Antigravity による最終セキュリティレビュー完了
[ ] Claude Code によるデプロイメント自動化が機能（本番ロールバック 1 コマンド）
[ ] モニタリングダッシュボード完成（Grafana + Slack alert）
第8章 公式ドキュメントには書かれていない運用知見
ここからは、3ツールを実プロダクトに組み込んできた個人開発者として、公式のリリースノートやチュートリアルでは触れられていない実測値と運用上の判断材料を共有します。私自身、iPhone・Android のアプリを個人で長く運用しながら、広告とサブスクの両軸で収益を回してきました。3つのAI IDEを毎日触ってみて、ドキュメントの数字と実運用のギャップは想像以上に大きいと感じています。
8.1 Antigravity マネージャービューの待ち時間とトークン経済
公式ドキュメントでは「マネージャービューで16エージェントをオーケストレーション可能」とだけ書かれていますが、実運用では以下のような挙動になります。
同時実行できるのはPlan上限まで : Proプラン（並列5）で16エージェントを起動しても、6体目以降は前のエージェントの完了を待ってからキューインされます。実測では、UI設計・コード生成・テスト作成・ドキュメント生成・セキュリティ監査の5系統が並列で進み、デプロイ自動化と監視ダッシュボードの2系統が待機状態になることが多いです。5分タスクで約42万トークン消費 : 16エージェントが同時に5分のタスクを実行すると、Geminiの1Mトークンコンテキストで合計42〜48万トークン消費します。1日3セッション × 5営業日で月100M〜120Mトークンになるため、Pro並列5プランから「並列10相当のEnterprise契約」へ切り替える判断ラインは「個人開発で月3〜4プロジェクトを並行運用する場合」と感じています。キャッシュヒット率が15-25%程度 : 同じスペック文書を再投入してもキャッシュが効くのは2〜3割。Cursor のローカルコンテキストキャッシュ（70%超）と比べると、Antigravityはコンテキスト圧縮で勝負しているのが分かります。
私の場合、壁紙アプリのUIリファクタリングのとき、Antigravityで「全画面のレイアウトを縦書き対応に変更」というスペックを書いたら、16エージェントのうち12体が並列で動き、約42万トークン消費して完了まで7分かかりました。Cursorで同じ作業を試したら、ファイルを1つずつ指定する必要があり、合計1時間以上かかりました。「全画面の整合性が要る変更」はAntigravity、「局所的な3行修正」はCursor という線引きは、ここから出てきています。
8.2 Cursor の @-mention で削れるトークンの実測
Cursorの@-mentionは「ファイル単位で精密にコンテキストを絞れる」と謳われていますが、実測すると以下の効果があります。
@file:src/screens/Wallpaper.tsx 指定で、コンテキスト32万→3.8万トークンに圧縮 : フォルダ全体を投げ込まずに該当ファイルだけ指定すると、推論時間が8〜12秒から1〜2秒に短縮されます。@symbol:LiveWallpaperRenderer.render を指定すると、関連定義だけが自動補完 : 同じファイル内の他の関数は無視されるため、私のような「同じファイルに複数の機能が同居しがちな個人開発」には特に効きます。@docs:Next.js の挙動が不安定 : 公式ドキュメントの引用機能は、APIエンドポイントが時々タイムアウトします。私は重要なドキュメントを .cursor/rules/ 配下にローカルキャッシュして、@file経由で参照するスタイルに統一しました。
8.3 Claude Code worktree 並列開発の落とし穴
Claude Code の git worktree 統合は「複数ブランチを並列で開発できる」のが売りですが、実運用では3つのハマりどころがあります。
node_modulesは worktree ごとに独立 : 同じプロジェクトでも feature/onboarding と feature/wallpaper-shader で別々の node_modules が必要です。SSDの空き容量を月1回チェックする習慣ができました。lock ファイルの競合 : package-lock.json を編集する変更を worktree 間で並行に走らせると、merge 時に高確率で衝突します。「lock を触る変更は worktree A だけで走らせる」というルールをAGENTS.mdに書き込みました。CI/CD で worktree を区別できない : GitHub Actions は worktree のメタデータを認識しません。ブランチ名で識別するよう PR タイトルに [wt-A] などのタグを付けるワークフローを足しています。
私の場合、壁紙アプリの「ライブ壁紙」と「引き寄せメッセージ」の機能を並列で開発したいときに、Claude Code の worktree でブランチを2つ立てて、片方を Antigravity に任せ、もう片方を自分が Cursor で進める、というハイブリッドな流れに落ち着きました。「並列で進めるには物理的な作業空間も分ける必要がある」 という当たり前の事実が、AI IDEを使い始めてから改めて重要に感じます。
8.4 3ツール合算の月額コストと、AdMob 収益との対比
私自身の技術ブログ4サイト（Claude Lab・Gemini Lab・Antigravity Lab・Rork Lab）の並行運営と、個人開発のアプリ運用を合わせて、以下のような月額コスト配分に落ち着いています。
項目 月額 用途
Antigravity Pro ¥5,000 スペック駆動・全体設計・セキュリティ監査 Cursor Pro+ ¥4,000 日々の実装・JetBrains系プロジェクト Claude Code API ¥18,000-35,000 自動化スクリプト・記事生成パイプライン（4サイト分） GitHub Actions ¥3,000 CI/CD（無料枠 + 一部有料分） Cloudflare Workers ¥7,000 4サイトのホスティング Stripe決済手数料 ¥5,000 メンバーシップ売上の3.6% 合計 ¥42,000-59,000 （月収のうちAI IDE関連の固定費）
AdMobの月収100万円規模を維持するためのコストとして、これは個人開発者として許容できる範囲です。「ツール代を浮かせるために自分が時間を使う」のと「ツールに任せて自分は次の作品制作に時間を回す」のトレードオフ を、毎月見直すようにしています。
8.5 AGENTS.md を「契約書」として書く実例
3ツール統一の鍵となる AGENTS.md は、運用してみると単なる設定ファイルではなく、自分と3つのAIエージェントの「契約書」 であると気づきました。以下はDolice Labsで運用している実物の抜粋です。
# AGENTS.md v1.3 (2026-05-29 update)
## 言語・フレームワーク（全ツール共通） - 言語: TypeScript strict mode（never use any unless documented） - フロントエンド: Next.js 16 App Router + React Server Components - バックエンド: Cloudflare Workers + KV + Stripe API v2024-11 - スタイリング: Tailwind CSS（カスタムCSSは layout.css のみ可）
## 契約条項（違反時はrevert） 1. 既存のフロントマター仕様を変更する変更はマージ禁止 2. articles.json に1MB以上を追加する変更はマージ禁止 3. `_documents/AUTHOR_VOICE_STYLE_GUIDE.md` に反する文体の自動生成は破棄 4. `python3 _documents/_quality_audit/_scripts/article_gate.py` で違反が出る記事はpush禁止
## ツール別の役割（重複禁止） - Antigravity: 「全画面に影響する変更」「セキュリティ監査」「スペック文書化」のみ - Cursor: 「単一ファイル内の編集」「ESLint/TypeScript修正」のみ - Claude Code: 「シェルスクリプト」「CI/CDワークフロー」「自動化のみ」
## クロスツール検証 - AntigravityでspecをコミットしたあとCursorで実装する場合、specの章番号を必ずコミットメッセージに記載すること - Claude Codeが自動生成したテストは、Cursorで人間がレビューしないとマージ禁止 この AGENTS.md を Repo に置いておくと、3つのAI IDEが同じルールセットを参照するようになり、生成されるコードの粒度・命名・テストカバレッジが揃います。私はこれを 「AIエージェントの就業規則」 と呼んでいます。
8.6 「AIに任せる領域」と「自分で決める領域」の線引き
私はソフトウェア開発と並行して、作品制作を軸にした表現活動も続けています。そこでは 作品そのものの制作には基本的に AI を使わず、運用や記事制作にだけ AI を使う という線引きを徹底しています。この境界の引き方が、AI IDE を複数併用するときの判断軸とそのまま重なるのが、続けるほどに腑に落ちてきました。
3ツールに任せられる仕事は徹底的に任せ、自分は「作品としてのソフトウェア体験」のコアな意思決定に集中する——この線引きが、長く続けるうえでの軸になっていると感じます。Cursorで日々のコードを書き、Antigravityで大きな設計を委ね、Claude Codeで自動化を任せる、その先で自分が向き合うのは「ユーザーが画面を開いた瞬間の体験」だけです。
第7章 ツール選択の意思決定フロー
新しい機能やタスクが発生した時「どのツールを使う？」を判断する早見表。
タスク発生
↓
「プロジェクト全体に関わる意思決定か?」
YES → Antigravity（マルチエージェント、全観点カバー）
NO ↓
↓
「既存コードの修正か？」
YES → Cursor（サージカル編集、モデル豊富）
NO ↓
↓
「スクリプト生成、テスト、デプロイか？」
YES → Claude Code（ターミナル、自動化）
NO → Cursor で 相談（メインツール）
まとめ
2026年のプロフェッショナル開発環境は、「1つの完璧なツール」ではなく、「目的別に最適化された3つ以上のツール」の組み合わせが当たり前になります。
Antigravity （戦略・設計）、Cursor （実装・修正）、Claude Code （自動化・CI/CD）—— この三角形を AGENTS.md で統一すれば：
開発速度 : 従来比で 30-40% 高速化品質 : 自動テスト + セキュリティ監査で本番バグ 70% 削減持続可能性 : 退屈な作業の自動化で developer experience 向上
初期セットアップ（AGENTS.md 作成、CI/CD 構築）に 1-2 週間。その後の ROI は月単位で見えます。
「今月も同じツール使おう」から「今月のフェーズに最適なツール選ぼう」へ。この思考シフトが、2026年の開発生産性の分岐点です。