この記事は「ビギナーズ Advent Calendar 2025」の1日目の記事です。
はじめに
こんにちは！株式会社NTTデータグループでSmart AI Agent®︎のエンジニアをしている岸川です。
今回は、Claude 4.5 Opusを「頭脳」、GPT-5.1を「実行役」として協調させ、マルチエージェントとしてゲーム開発という本格的なタスクを試してみました。
本記事では今回行ったゲーム開発を読者の皆様が再現できるよう詳細にその手順と結果を紹介していきます。
また、作ったゲームはGitHub上で公開中ですのでそちらが気になる方は是非クローンして使ってみてください！READMEに起動手順が書いてあります。
以下は完成した3Dシューティングゲームのプレイ画面です
マルチエージェント協調という発想
Anthropic社ではClaudeを並列実行してタスクをこなしているらしい
AI駆動開発Conference Autumn 2025のYouTube録画を見ていたとき、AnthropicのJason Kim氏が「Anthropic本社では、複雑タスクに4～10体のClaudeを並列実行し、各AIが役割分担・自律連携する運用をしています」と話していました。
これを聞いて「自分でも試してみたい」と思いました。モデルごとに得意分野があるので、複数のモデルに得意分野を分担させた方が良い結果が出るのでは？という仮説です。
Claude 4.5 Opus × GPT-5.1にした理由
AIモデルには、それぞれ得意分野があります。2025年11月25日時点のベンチマークデータを見てみましょう。
| ベンチマーク | Claude 4.5 Opus | GPT-5.1 Codex | Gemini 3.0 Pro |
|---|---|---|---|
| SWE-bench Verified[1] | 80.9% | 76.3% | - |
| コンテキスト長 | 200K | 200K | 1000K |
| API価格（入力/出力）[2][3][4] | $5 / $25 | $1.25 / $10 | $2 / $12 |
この特性を踏まえ、以下のように役割分担しました：
| エージェント | 役割 | 根拠 |
|---|---|---|
| Claude 4.5 Opus | 戦略立案、企画、コードレビュー | SWE-bench最高スコア、複雑な推論に強い |
| GPT-5.1 Codex | 実装、リファクタリング、テスト実行 | 実装向けに最適化、出力コストが2.5分の1 |
「頭脳」と「手足」の分離により、高性能だが高コストなClaude 4.5 Opusのトークン消費を最小化しつつ、GPT-5.1 Codexの安価かつ高性能にコードを生成できるというそれぞれの強みを最大化できます。
cccc：マルチエージェント協調ツール
ccccとは
複数のコーディングエージェントを並列実行させること自体は難しくありません。VSCodeならタブを複数開く、CLIならtmuxを使えばできます。
しかし、お互いを協調させるとなると話は別です。そこで見つけたのがccccというツールです。
cccc v0.3.17の設定画面。PeerA=Claude、PeerB=Codex、Aux=Claudeを設定。tmuxで各エージェントを並列起動する。
ccccは、複数のコーディングエージェント（Claude Code、Codex CLIなど）を協調させるためのオーケストレーターツールです。
今回の構成
ccccでは以下のロールを設定できます：
| ロール | 必須 | 説明 |
|---|---|---|
| PeerA | ✅ | メイン実行者の1人、PeerBと対等に協力 |
| PeerB | ✅ | メイン実行者の1人、PeerAと対等に協力 |
| Aux | ❌ | 補助ロール、オンデマンドで呼び出し |
| Foreman | ❌ | 定期実行される監視役（品質チェック、リマインド） |
今回は以下の構成で使用しました：
| ロール | エージェント | 責務 |
|---|---|---|
| PeerA（頭脳） | Claude 4.5 Opus | 戦略立案、企画をAuxと壁打ち、コードレビュー、意思決定 |
| PeerB（実行役） | GPT-5.1 Codex | 実装、テスト実行、ファイル操作（コスト効率重視） |
| Aux（壁打ち相手） | Claude 4.5 Opus | PeerAの企画・設計の壁打ち相手、アイデア出し |
ccccのインストール
# 前提条件: Python 3.9以上、tmux
# macOS
brew install tmux
# Ubuntu/Debian
sudo apt install tmux
# ccccのインストール（pipx推奨）
pipx install cccc-pair
# または pip
pip install cccc-pair
プロジェクトの初期化
cd your-project
# 初期化（.cccc/ディレクトリと設定ファイルを作成）
cccc init
# 起動
cccc run
必要な設定ファイル
ccccを効果的に使うには、以下のファイルを準備します：
1. PROJECT.md（リポジトリルート）
PeerA/PeerBのシステムプロンプトに自動注入されます。プロジェクト概要、役割分担、コーディング規約を記載します。
2. docs/por/POR.md（戦略ボード）
進捗管理と重要な判断事項を記録します。「Plan of Record」の略で、現在の状況と次のタスクを明確にします。
これらのファイルの具体例は後述の「実践」セクションで紹介します。
TUIでの操作
起動後、以下のコマンドで操作します：
| コマンド | 機能 |
|---|---|
/a <メッセージ> |
PeerA（Claude 4.5 Opus）に送信 |
/b <メッセージ> |
PeerB（GPT-5.1）に送信 |
/both <メッセージ> |
両方に同時送信 |
/aux <プロンプト> |
Aux（Claude 4.5 Opus）を呼び出し |
/pause / /resume
|
ループの一時停止/再開 |
実践：シューティングゲーム開発
ゲームコンセプト
- 3Dシューティング: Three.jsを使用した本格的な3D空間
- 成長システム: ポイントを貯めてパーツを獲得、機体を強化
設定ファイルの準備（長いので読み飛ばしOKです）
まず、cccc用の設定ファイルを準備しました。
PROJECT.md（リポジトリルート）
# Project: 3Dシューティングゲーム開発
## Mission
ブラウザで動作する3Dシューティングゲームを、2つのAIエージェント（Claude 4.5 Opus × GPT-5.1）の協調により開発する。
## Goal
Three.js + TypeScriptで3Dシューティングゲームを実装し、成長システム・ボス戦を含む完成版をリリースする。
## Target Repository
https://github.com/hayato-kishikawa/3d-shooting-game
## Success Criteria
1. [ ] 3D空間で自機がWASD+マウスで操作できる
2. [ ] スペースキーまたはクリックで弾が発射される
3. [ ] 敵が出現し、撃墜でポイント獲得
4. [ ] パーツショップでポイント消費→機体強化
5. [ ] 5段階の強化システム（最終段階はボスドロップ素材必要）
6. [ ] ステージボスを撃破できる
7. [ ] ゲームオーバー/クリア画面
8. [ ] `npm run build` が通る
9. [ ] 基本的なテストが通る
## ゲームコンセプト
- **ジャンル**: 3Dシューティング（縦スクロール風の視点）
- **成長システム**: 敵を倒してポイント獲得 → パーツ購入 → 機体強化
- **ボス戦**: 各ステージ終盤に強力なボス出現
- **目標**: 強化を重ねて最終ボスを撃破
## パーツ・強化システム
| カテゴリ | パーツ例 | 効果 |
|---------|---------|------|
| 武器 | ツインキャノン、レーザー | 攻撃力UP、連射速度UP |
| 防御 | シールドジェネレーター | 耐久力UP、被ダメ軽減 |
| 機動 | ブースター、サイドスラスター | 移動速度UP、回避性能UP |
| 特殊 | ホーミングミサイル、ボム | 必殺技、範囲攻撃 |
## 技術スタック
- **言語**: TypeScript (strict mode)
- **3D描画**: Three.js
- **ビルド**: Vite
- **テスト**: Vitest
## Agent Roles
### PeerA (Claude 4.5 Opus) - Strategic Leader（トークン節約モード）
**責務：**
- ゲームデザイン（バランス調整、パーツ設計、ボス設計）
- **実装方針の決定**（どのライブラリを使うか、どう設計するか）
- **アーキテクチャ設計**（クラス構成、モジュール分割）
- 企画の壁打ち（迷ったらAuxを呼んでアイデア出し）
- コードレビュー（構造、品質）
**行動指針（トークン節約 - あなたは高コストです）：**
- **簡潔に**: レビューは≤3箇条、回答は≤3行
- **方針は明確に**: 実装方針・設計判断は具体的に伝える
- **委譲**: 実装作業自体はPeerBに任せる（方針だけ伝える）
- **良いものは即承認**: 問題なければ「LGTM」だけでOK
- **Aux活用**: 企画・設計で迷ったら `/aux` で壁打ち
**やらないこと（PeerBに委譲）：**
- ❌ コード実装（方針を伝えてPeerBに書かせる）
- ❌ テストコード作成（レビューのみ）
- ❌ ファイル操作
### PeerB (GPT-5.1) - Implementation Peer
**責務：**
- ゲームロジック実装（core/配下）
- 3D描画実装（graphics/配下）
- テストケース作成・実行
- PeerAの企画方針をドキュメント化
- git commit/push
**行動指針：**
- 実装は小さく分割（≤200行/commit）
- 実装後は必ずテストを実行
- PeerAのレビュー指摘には迅速に対応
- コミット前に `npm run build` を確認
- 報告は簡潔に（完了/変更/次のフォーマット）
**報告フォーマット：**
完了: [タスク名]
変更: [ファイル名]
次: [次のタスク]
### Aux (Claude 4.5 Opus) - Brainstorming Partner
**責務：**
- PeerAからの企画相談に応じる
- ゲームバランス、パーツアイデアのブレスト
- 設計の壁打ち相手
**起動条件：**
- `/aux` で呼び出し時のみ起動
- **⚠️ PeerAのみが使用可能（PeerBは使用禁止）**
- PeerAが企画・設計で迷った時に積極的に活用すること
## Git運用（必須）
- **リポジトリ**: https://github.com/hayato-kishikawa/3d-shooting-game
- **作業開始時**: `git clone` してから開発開始
- **実装完了ごと**: `git add . && git commit -m "メッセージ" && git push`
- **コミット単位**: 機能単位で小さく（≤200行）
- **コミットメッセージ**: 日本語OK、変更内容を簡潔に
## Guardrails（禁止事項）
1. ❌ テスト未実施でのcommit
2. ❌ `npm run build` が通らない状態でのpush
3. ❌ 200行超の巨大commit（分割すること）
4. ❌ PeerAによる実装作業（必ずPeerBに委譲）
5. ❌ エビデンスなしの「完了」報告
6. ❌ 外部ライブラリの無断追加（PeerAに確認）
7. ❌ **PeerBによるAux呼び出し（Auxを使えるのはPeerAのみ）**
8. ❌ git commit/pushなしでの作業継続（必ずバージョン管理すること）
## Review Flow
### PeerBのレビュー依頼
実装完了後、PeerBは以下の形式でPeerAにレビューを依頼：
レビュー依頼: [タスク名]
変更: [ファイル名]
確認してほしい点: [特に見てほしいポイント]
テスト結果: PASS / 追加したテスト数
### PeerAのレビュー観点
- **設計**: アーキテクチャ方針に沿っているか
- **品質**: 可読性、保守性、エッジケース考慮
- **ゲーム性**: 面白さ、バランス（該当する場合）
### レビュー結果
- ✅ **LGTM** → 次タスクへ進む
- 🔄 **要修正** → 具体的な改善指示（≤3点）を出す
要修正:
1. [修正点1]
2. [修正点2]
### 修正後の再レビュー
PeerBは修正後、再度レビュー依頼。PeerAは差分のみ確認。
## Workflow
### Phase 1: 基盤構築
1. PeerB: Vite + TypeScript + Three.js環境構築
2. PeerB: 基本的な3Dシーン表示
3. PeerB: ゲームループ実装
4. PeerA: カメラアングル・操作感の方針決定（Auxと壁打ち可）
### Phase 2: 自機・敵の実装
1. PeerB: Player.ts実装（移動、弾発射）
2. PeerA: レビュー
3. PeerB: Enemy.ts実装（出現パターン）
4. PeerB: Collision.ts実装（3D衝突判定）
### Phase 3: 成長システム
1. PeerA + Aux: パーツバランス設計（壁打ち）
2. PeerB: Shop.ts実装
3. PeerB: Upgrade.ts実装
4. PeerA: バランスレビュー
### Phase 4: ボス戦
1. PeerA + Aux: ボス攻撃パターン設計（壁打ち）
2. PeerB: Boss.ts実装
3. PeerB: ステージクリア処理
### Phase 5: 仕上げ
1. PeerB: UI/UX改善
2. PeerB: パフォーマンス最適化
3. PeerA: 最終レビュー
4. PeerB: リリース準備
## アーキテクチャ
src/
core/ # ゲームロジック（PeerB担当）
Game.ts # ゲームループ、状態管理
Player.ts # 自機、装備管理
Enemy.ts # 敵AI、ボスロジック
Bullet.ts # 弾道計算
Collision.ts # 3D衝突判定
Shop.ts # パーツショップ
Upgrade.ts # 強化システム
graphics/ # 3D描画（PeerB担当）
Renderer.ts # Three.jsセットアップ
Models.ts # 3Dモデル管理
Effects.ts # パーティクル、爆発
Camera.ts # カメラワーク
ui/ # UI
HUD.ts # スコア、HP表示
ShopUI.ts # パーツ購入画面
GameOver.ts # ゲームオーバー画面
main.ts # エントリーポイント
docs/por/POR.md（進捗管理）
# POR - Strategic Board
- North Star: **3Dシューティングゲームの完成とリリース**（成長システム・ボス戦を含む）; Guardrails: テスト通過必須, `npm run build`成功必須, 200行以下/commit, PeerAは実装禁止
- Non-Goals / Boundaries: モバイル対応は後回し。外部ゲームライブラリ（Phaser等）不使用。3Dモデルは基本図形で代用（アセット作成しない）。
## Deliverables (top-level)
- Phase 1: 基盤構築 - Vite + Three.js環境、ゲームループ - PeerB lead, PeerA review
- Phase 2: 自機・敵実装 - Player.ts, Enemy.ts, Collision.ts - PeerB lead, PeerA review
- Phase 3: 成長システム - Shop.ts, Upgrade.ts, パーツバランス - PeerB lead, PeerA + Aux 企画
- Phase 4: ボス戦 - Boss攻撃パターン、ステージクリア - PeerB lead, PeerA + Aux 企画
- Phase 5: 仕上げ - UI/UX改善、パフォーマンス最適化 - PeerB lead, PeerA final review
## Bets & Assumptions
- 🔄 Bet 1 (VALIDATING): Three.jsで十分なパフォーマンスが出る | Probe: Phase 1でFPS計測 | Window: Phase 2開始まで
- 🔄 Bet 2 (VALIDATING): 基本図形でも面白いゲームが作れる | Probe: Phase 2で操作感テスト | Window: Phase 3開始まで
- 🔄 Bet 3 (VALIDATING): PeerA + Aux壁打ちでバランス調整が効率化 | Probe: Phase 3でパーツ設計 | Window: Phase 4完了まで
## Roadmap (Now/Next/Later)
- Now (Phase 1): 🔄 ← 現在ここ
- [ ] Vite + TypeScript + Three.js環境構築
- [ ] 基本的な3Dシーン表示
- [ ] ゲームループの実装
- [ ] 操作感の方針決定（PeerA + Aux壁打ち）
- [ ] カメラアングルの決定（PeerA + Aux壁打ち）
- Next (Phase 2-3):
- [ ] Player.ts - WASD+マウス操作、弾発射
- [ ] Enemy.ts - 通常敵出現パターン
- [ ] Collision.ts - 3D衝突判定（球vs球、球vsボックス）
- [ ] Shop.ts - パーツショップUI
- [ ] Upgrade.ts - 装備・強化ロジック
- Later (Phase 4-5):
- [ ] Boss.ts - 攻撃パターン複数、弱点システム
- [ ] ステージクリア処理
- [ ] UI/UX改善（HUD、ゲームオーバー画面）
- [ ] パフォーマンス最適化
## Decision & Pivot Log (recent 5)
- ⏳ 待機中 | Phase 1開始待ち
## Risk Radar & Mitigations
| リスク | 影響 | 確率 | 対策 |
|--------|------|------|------|
| R1: Three.js学習コスト | 高 | 中 | 公式ドキュメント参照、シンプルな実装から開始 |
| R2: パフォーマンス問題 | 中 | 中 | オブジェクト数制限、LOD検討、早期FPS計測 |
| R3: バランス調整難航 | 中 | 中 | Auxとの壁打ちで早期に詰める |
| R4: 衝突判定の複雑化 | 中 | 低 | 球vsボックスのシンプルな判定に限定 |
## Portfolio Health
| Phase | Title | Owner | Stage | Latest evidence |
|-------|-------|-------|-------|-----------------|
| 1 | 基盤構築 | PeerB | 🔄 進行中 | 開始待ち |
| 2 | 自機・敵実装 | PeerB | ⏳ 待機 | - |
| 3 | 成長システム | PeerB | ⏳ 待機 | - |
| 4 | ボス戦 | PeerB | ⏳ 待機 | - |
| 5 | 仕上げ | PeerB | ⏳ 待機 | - |
## Operating Principles
- **エビデンス駆動**: テスト結果・ビルド成功なしの「完了」は無効
- **小さく分割**: 200行以下/commit、段階的実装
- **相互レビュー**: PeerB実装 → PeerAレビュー必須
- **壁打ち活用**: 企画・バランスで迷ったらAuxに相談
- **Done = tested + reviewed + committed**
## Maintenance & Change Log
- ⏳ 開始待ち | プロジェクト初期化
## Aux Delegations（PeerAからの壁打ち依頼）
- [ ] 操作感の方針（キーボードvsマウス）
- [ ] カメラアングル（見下ろし型 vs TPS視点）
- [ ] パーツバランス設計（強化段階数、各パーツの効果）
- [ ] ボス攻撃パターン設計
イニシャルプロンプト
ccccを起動後、/bothコマンドで以下のプロンプトを送信しました：
イニシャルプロンプト
/both 3Dシューティングゲーム開発プロジェクトを開始します。
【必読ファイル】
- PROJECT.md（プロジェクト概要、役割分担、アーキテクチャ）
- docs/por/POR.md（現在の進捗、次のタスク）
【PeerA（Claude 4.5 Opus）へ】
あなたは企画・戦略リーダーです。
🎯 担当:
✓ ゲームデザイン（パーツ設計、ボス設計、バランス）
✓ 企画で迷ったら `/aux` で壁打ち相手を呼んでアイデア出し
✓ コードレビュー、アーキテクチャ判断
⚠️ トークン節約（あなたは高コストです）:
✓ 実装作業は絶対にPeerBへ委譲
✓ レビューは「LGTM」か箇条書き3点以内
✓ 長文禁止。判断と指示だけ
✓ 企画ドキュメントもPeerBに書かせる（あなたは方針だけ伝える）
【PeerB（GPT-5.1）へ】
あなたは実装リーダーです。
🎯 担当:
✓ core/, graphics/ 配下の全実装
✓ テスト作成・実行
✓ PeerAの企画方針をドキュメント化
✓ 実装完了したらPeerAに簡潔に報告
**📝 報告フォーマット：**
完了: [タスク名]
変更: [ファイル名]
次: [次のタスク]
【最初のタスク】
POR.mdを確認して、Phase 1の基盤構築から始めてください。
まずPeerAは操作感とカメラアングルの方針を決めて、PeerBは環境構築を開始。
理解したら作業を開始してください。
途中から再開するプロンプト
ターミナルがクラッシュしたり途中でPCがスリープしたら以下のようにプロンプトを送って再開しました：
途中から再開するプロンプト
/both 作業を再開します。
【現状確認（両者必須）】
1. POR.mdを読んで、現在のPhaseと未完了タスクを確認
2. `git status` で未コミットの変更を確認
3. `git log --oneline -5` で最近のコミットを確認
【PeerA】
✓ 前回のレビュー指摘が残っていれば、PeerBに伝える
✓ 次の実装方針を簡潔に指示
【PeerB】
✓ 未コミットの変更があれば、テスト実行→コミット→プッシュ
✓ POR.mdの未完了タスクから再開
では続きをお願いします。
エージェントたちの協調動作
指示を出した後、PeerA（Claude 4.5 Opus）とPeerB（GPT-5.1）が自律的に協調し始めました：
開発中の画面。左側でPeerA（Claude）が「LGTM」とレビュー承認、右側でPeerB（Codex）がPlayer.tsの実装を進めている。メールボックス経由でメッセージが飛び交う。
エージェント間通信の実例
ccccは.cccc/ledger.jsonlにエージェント間のやりとりを記録します。実際のログからやりとりを紹介します。
1. PeerBからPeerAへのレビュー依頼
{"from": "PeerB", "kind": "event-ask", "tag": "phase1",
"text": "`/aux`で操作感/カメラアングル方針（俯瞰角度・追従速度）を決め共有いただけますか？",
"to": "peerA"}
PeerBが環境構築を終えた後、カメラの方針決定をPeerAに依頼しています。
2. PeerAによるP0バグの指摘
{"from": "PeerA", "kind": "event-risk", "tag": "p0.fix", "sev": "high",
"text": "`Player.ts:92` - `new Vector3()` が毎フレーム呼ばれている"}
PeerA（Claude 4.5 Opus）がコードレビュー中にパフォーマンス問題を発見。具体的な行番号と問題点を指摘しています。
3. 戦略的なロードマップ変更
{"from": "PeerA", "kind": "event-counter", "tag": "roadmap.pivot", "strength": "high",
"text": "Phase 3のShop/Upgradeは複雑。まずゲームループ（撃つ→スコア→死ぬ→リスタート）を完成させる。"}
PeerAが計画の優先順位を変更。複雑な成長システムより先に、基本的なゲームループの完成を優先する判断を下しています。
4. Guardrail違反の検出と是正
{"from": "PeerA", "kind": "event-counter", "tag": "unblock.tests",
"text": "手順違反=7h未コミット & Phase 2先行実装。品質良好だが今後は即コミット必須。",
"strength": "normal"}
PeerBが長時間コミットせずに作業を続けていたことをPeerAが指摘。PROJECT.mdで定めたGuardrail（ルール）を遵守するよう是正しています。
結果
私が書いたコードは0行！
指示を送って待っていたらエージェントたちが協力してゲームを完成させてくれました。
実際にできたものを触ってみましたが、最初のボスを倒したらゲームが終わってしまうことや自分の機体を強化しても見た目が変わらないなど、改善したい部分もありましたが叩きとしてはそこそこのものが作れたのではないかと思います。指示を工夫してみたり、以降はバイブコーディング的にブラッシュアップすればもっと良くなりそうです。
ボス「DREADNOUGHT」との戦闘。画面上部に赤いHPバーが表示され、巨大な赤いボスが弾を発射してくる。自機（青）で攻撃を避けながら撃破を目指す。
ボス「DREADNOUGHT」の撃破画面
パーツショップ画面。
おわりに
この記事では、Claude 4.5 Opusを頭脳、GPT-5.1を実行役としたマルチコーディングエージェント協調の実践例を紹介しました。
エージェントを協調させることで、コストを削減しつつ複雑なタスクを実行できることを示せたかと思います。
実際にやってみて、エージェントがメッセージを投げ合って協力したり開発をしているところは見ていて面白かったです。
この記事を読んで真似してみたとか、良い使い方を思いついたら是非教えてほしいです！
最後までお読みいただきありがとうございました！
参考リンク:
cccc:
今回作成したゲーム
NTT DATA公式アカウントです。 技術を愛するNTT DATAの技術者が、気軽に楽しく発信していきます。 当社のサービスなどについてのお問い合わせは、 お問い合わせフォーム nttdata.com/jp/ja/contact-us/ へお願いします。