はじめに
どうも、@Yo19920508です。
第1部では、
「AIにコードを書かせる」から「AIに開発を任せる」
ために、ai-dev-orchestrator を作った話を書きました。
で、第2部です。
今回は、
Claude Code、Codex、Geminiをどう役割分担させたのか
について書きます。
最初に言っておくと、
優秀なAIを3人集めたら、勝手に最強チームになるわけではありません。
これは人間と一緒です。
優秀なエンジニア3人を会議室に放り込んで、
「ほな、いい感じに開発しといて」
と言っても、
たぶん最初に始まるのは開発ではありません。
役割分担の相談です。
AIも同じでした。
AIを3人集めても、第7班にはならない
Claude Code。
Codex。
Gemini。
全員強いです。
ただし、
強い = チームとして機能する
ではありません。
NARUTOでいうと、
ナルト、サスケ、サクラを同じ場所に置いただけです。
任務もない。
担当もない。
誰が何をやるのかも決まってない。
開始5分で、
ナルト「俺がやるってばよ」
サスケ「お前に任せたら余計なところまで壊すだろ」
サクラ「ちょっと待って、テスト通ってないんだけど」
みたいな感じになります。
そこにカカシ先生も来て、
「そもそも、その作戦で本当に大丈夫？」
と別の角度から見てくる。
ようやく第7班っぽくなってきます。
AI開発でも同じです。
例えば、
Claude Codeにも実装させる。
Codexにも実装させる。
Geminiにも実装案を考えさせる。
次に、
Claude Codeにもレビューさせる。
Codexにもレビューさせる。
Geminiにもレビューさせる。
すると何が起きるか。
全員が同じファイルを読んで、全員が同じことを考える。
Tokenが溶けます。
しかも意見が割れたら、
最後は私が、
「で、誰が正しいん？」
と判断することになります。
いや。
また私が働いてるやん。
それでは意味がありません。
なので最初にやったのは、
AIを増やすことではなく、AIの仕事を減らすこと
でした。
全員にかめはめ波を撃たせる必要はない
例えば地球が危機になったとして、
悟空が戦う。
ベジータも戦う。
ここまでは分かります。
でも、
ブルマにも戦わせて、
ピッコロにもカプセルコーポレーションのシステムを設計させて、
亀仙人にもCIを書かせて、
全員に、
「とりあえず、かめはめ波撃っといて」
とはならんわけです。
それぞれ得意分野があります。
AIも同じです。
私は最終的に、ざっくりこう分けました。
| AI / システム | 主な役割 |
|---|---|
| Claude Code | 実装・修正 |
| Codex | 厳しめのコードレビュー・設計確認 |
| Gemini | 別視点・Edge Case・見落とし確認 |
| GitHub | Issue・PR・状態管理 |
| CI | 最終的な品質判定 |
| Orchestrator | 誰をいつ動かすか決める |
ポイントは、
全員に何でもやらせない
ことです。
Claude Codeはナルト
まずClaude Code。
私の構成では、基本的に
実装・修正の中心
です。
ナルトです。
任務が来たら、とりあえず現場へ行く。
実装する。
テストを書く。
失敗したら直す。
レビュー指摘が来たら、また直す。
つまり、
手を動かす係
です。
例えばIssueに、
ログイン画面にパスワードリセット機能を追加する
と書かれていたら、
Claude Codeが必要なコードを確認して、
実装する。
テストを追加する。
ローカルで確認する。
PRへ反映する。
ここまで持っていきます。
Claude Codeの強みは、
単発の回答というより、
実際のRepoを見ながら継続して作業するところ
にあります。
なので、
レビューだけさせるより、
実装側へ寄せた方が私の構成ではハマりました。
言ってしまえば、
「とりあえず俺がやるってばよ」
の担当です。
ただし、
そのまま突っ込ませると危ない。
そこで次に出てくるのがCodexです。
Codexはサスケ
次にCodex。
これは私の中では、
完全にサスケです。
Claude Code（ナルト）が、
「実装できたってばよ！」
と言ってきても、
Codexは横から、
「フンッ 甘い。ウスラトンカチが」
と言う係です。
かなり重要です。
実装した本人に、
「この実装どう？」
と聞くと、
基本的には自分の設計思想の中でチェックします。
人間でもそうです。
自分で書いたコードって、
どうしても自分の前提を引きずります。
そこで、
別のモデルにレビューさせる
意味が出てきます。
Codexには主に、
- ロジックの破綻がないか
- 仕様を満たしているか
- Security上の問題がないか
- 既存設計を壊していないか
- テストが不足していないか
- 保守しづらい実装になっていないか
あたりを見てもらいます。
Claude Codeが、
「動きました！」
と言ったときに、
Codexが、
「動けばいいって話じゃないだろ」
と返す。
だいたいサスケです。
ナルトが勢いで前に進むなら、
サスケは横から冷静に、
「その作り方、あとで詰むぞ」
と言ってくる。
たまに腹立つけど、
だいたい必要なことを言ってます。
Geminiはカカシ先生
Geminiは少し違います。
Codexと同じレビュー担当ではありますが、
同じ観点のレビューを2回やらせる意味はあまりない
と思っています。
なのでGeminiには、
少し視点をズラします。
例えば、
- 想定外の入力
- Edge Case
- UX上の違和感
- 別の実装方法
- 将来的に壊れそうなポイント
- Codexが見落としていそうな部分
を中心に見てもらいます。
カカシ先生みたいな立ち位置です。
ナルトが正面から突っ込んで、
サスケが、
「そのやり方は甘い」
と言ってる横で、
カカシ先生が、
「そもそも後ろから敵来てるけど」
と教えてくれる。
そんな感じです。
実際の開発でも、
バグって正面だけから来ません。
例えば実装自体は正しくても、
ユーザーが二重クリックしたら？
APIが3秒遅れたら？
同じイベントが2回来たら？
途中でプロセスが落ちたら？
みたいなところから壊れます。
なので、
同じレビューを複数AIにさせるのではなく、レビュー観点を分ける
ようにしました。
CIはサクラ
ここで忘れてはいけないのがCIです。
サクラです。
ナルトが、
「できたってばよ！」
と言っても、
テストが落ちてたら、
「どこができてんのよ！しゃーんなろー」
と止める担当です。
型エラー。
テスト失敗。
Lintエラー。
Build失敗。
この辺を全部見ます。
実装側が、
「たぶん大丈夫」
と言ってても関係ありません。
通ってないもんは通ってない。
強い。
地味に強い。
しかも、
このサクラがいないと普通に事故ります。
レビューで問題なし。
実装もそれっぽい。
でもBuildしたら落ちる。
そんなことは普通にあります。
なのでCIは、
最後に感情を挟まず殴ってくる品質担当
です。
かなりサクラです。
「3人ともレビュー」は意外と無駄
最初に考えがちなのが、
「AI3つあるなら、3つ全部にレビューさせたら最強では？」
です。
私も思いました。
でも実際にやると、
意外と効率が悪いです。
なぜなら、
同じdiffを、
Claude Code、
Codex、
Gemini、
全員に読ませることになります。
さらに関連ファイルも全部渡す。
Repo全体まで読ませ始める。
すると、
Token界の元気玉
が出来始まります。
世界中のTokenを集めて、
レビュー1回にぶち込む。
強そうですが、
請求額もスーパーサイヤ人になります。
なので私は、
AIの数を増やすより、
「このAIは何を見るのか」
を明確にする方が重要やと思っています。
Contextは「全部渡す」より「必要なものだけ」
ここも結構重要でした。
AIにレビューさせるとき、
最初は、
「Repo全部見てもらった方が正確やろ」
と思います。
確かに情報は増えます。
でも同時に、
ノイズも増えます。
例えば、
ログイン機能を1ファイル修正しただけなのに、
画像生成処理も、
バッチ処理も、
READMEも、
CSSも、
過去のマイグレーションも、
全部AIに読ませる。
人間に例えると、
レビューをお願いしたら、
会社の創業史から説明される
ようなもんです。
いや。
そこまで知らんでええ。
なので基本は、
PR diff
+
変更に関係するファイル
+
必要な仕様
+
レビュー観点
ぐらいに絞ります。
例えば、
レビュー対象:
- src/auth/resetPassword.ts
- src/auth/resetPassword.test.ts
確認観点:
- 認証漏れ
- Token有効期限
- 二重使用
- Error Handling
みたいにします。
これならAIも、
何を見たらいいのか
が分かります。
ただし絞りすぎると事故る
ここでまた罠があります。
Contextを減らしすぎると、
今度は、
「その関数、実は別ファイルから呼ばれてます」
みたいなことが起きます。
これはサイヤ人編の悟空（ベジータがまだ敵の時）に
「フリーザ倒してきて」
だけ伝えて、
悟空が、
「フリーザって誰だ？」
ってなってる状態です。
そら無理です。
相手が誰で、
何をしていて、
どこにいて、
何が問題なのか。
そこまで分からないと動けません。
AIも同じです。
なので、
「Contextを最小限にする」
と
「必要な情報まで削る」
は別物です。
私が意識しているのは、
必要最小限
です。
ここは結構大事です。
レビュー結果はそのままClaudeへ投げない
もうひとつ重要なのが、
レビュー結果の扱い
です。
例えばCodexが、
この実装には競合状態の可能性があります。
と言ったとします。
Geminiが、
このケースでは二重実行の可能性があります。
と言ったとします。
じゃあ、その文章を全部Claudeへ投げて、
「全部直して」
でいいか。
私はあまり良くないと思っています。
なぜなら、
AIレビューにも間違いがあるからです。
それに、
同じ問題を別表現で指摘していることもあります。
例えば、
Codex：
「二重実行対策が必要」
Gemini：
「Idempotencyが不足」
実は同じ話かもしれません。
これを2件としてClaudeへ渡すと、
Claude側が必要以上に設計を変える可能性があります。
なのでOrchestrator側では、
レビュー結果を、
- 同じ指摘か
- 本当に修正が必要か
- 既存仕様と矛盾していないか
- 修正範囲を広げすぎていないか
をある程度整理してから、
修正タスクへ変換します。
つまり、
レビューコメント ≠ そのまま修正命令
です。
Review → Repair → CI
最終的な流れはこんな感じです。
Issue
↓
Claude Code
↓
Implementation
↓
Codex Review
+
Gemini Review
↓
Review Aggregation
↓
修正必要？
├─ YES → Claude Code Repair
│ ↓
│ 再レビュー
│
└─ NO
↓
CI
↓
CI成功？
├─ NO → Claude Code Repair
│
└─ YES
↓
READY FOR HUMAN
ここで一番重要なのは、
修正できる問題なら人間へ戻さない
ことです。
例えばCIで、
TypeScript Error
が出た。
人間へ、
「型エラー出ました」
と通知する必要はありません。
Claudeに直させます。
テストが1件失敗した。
Claudeへ戻します。
レビューで修正要求が出た。
Claudeへ戻します。
これを繰り返します。
中忍試験で1問間違えたら火影呼ばんやろ
中忍試験でナルトが問題を1問間違えるたびに、
「三代目火影様、どうしましょう？」
って呼びに行ってたら、
試験が永遠に終わりません。
現場で解決できる問題は、
現場で解決する。
AI開発でも同じです。
私が呼ばれるべきなのは、
例えば、
- 仕様が2通り考えられる
- 本番データを消す可能性がある
- 外部サービスへの課金が発生する
- Mergeしてよいか
- セキュリティ上、人間判断が必要
みたいなときです。
型エラーごときで私を呼ばないでください。
私にも生活があります。
じゃあOrchestratorは誰なん？
ここまで読むと、
「Claudeがナルト、Codexがサスケ、Geminiがカカシ先生、CIがサクラならOrchestrator誰やねん」
となります。
これが難しい。
NARUTOでいうなら、
火影 + 任務受付所 + 作戦本部
みたいな存在です。
誰に任務を振るか決める。
今どこまで進んでるか見る。
問題が起きたら、次に誰を動かすか決める。
でも自分では螺旋丸も千鳥も打ちません。
ドラゴンボールでいうなら、
界王様 + ブルマ + 神龍の受付係
ぐらい混ざってます。
もう誰やねん。
なのでキャラクターに例えるのは諦めます。
OrchestratorはOrchestratorです。
仕事は、
「今どの状態で、次に誰を動かすべきか」
を判断すること。
例えば、
IMPLEMENTING
ならClaudeを動かす。
REVIEWING
ならCodexとGeminiを動かす。
REPAIR_REQUIRED
ならClaudeへ戻す。
CI_FAILED
ならCI結果を持ってClaudeへ戻す。
READY_FOR_HUMAN
なら私を呼ぶ。
この状態遷移を持っていることが、
複数AIをただ並べるのと、
AIチームとして動かす
ことの違いです。
AIは賢さより「役割」が大事だった
ここまで作ってきて感じたのは、
AIモデルの性能だけ比較しても、AI開発全体はあまり良くならない
ということです。
もちろん、
どのモデルがコードを書くのが強いとか、
どのモデルがレビューに向いてるとか、
差はあります。
でも実際に自動化すると、
もっと大事なのは、
- 誰が実装するか
- 誰がレビューするか
- 誰が再実行するか
- 失敗したら誰へ戻すか
- どこで人間を呼ぶか
- どのContextを誰へ渡すか
です。
つまり、
AIモデル選びより、組織設計の問題に近くなってきます。
戦闘力100万のキャラを10人集めても、
全員が好き勝手に動いてたら、
作戦としては弱い。
忍術が強い忍者だけ集めて、
全員好き勝手に突っ込んだら、
たぶん任務失敗します。
逆に、
役割が明確なら、
それぞれの強みを使えます。
第2部まとめ
今回のポイントは、
AIを複数使うなら、同じことをさせるのではなく、役割を分ける
です。
私の構成では、
Claude Code
実装・修正。
Codex
厳しめの技術レビュー。
Gemini
別視点・Edge Case。
CI
最終品質確認。
Orchestrator
全体の状態管理と進行。
という形になっています。
Claude Codeがナルト。
前に進む実装担当。
「俺がやるってばよ」
で手を動かす。
Codexがサスケ。
横から冷静に、
「フンッ。甘い。ウスラトンカチが」
と見る担当。
Geminiがカカシ先生。
少し離れた視点から、
「そこ以外にも問題あるぞ」
と見る担当。
CIがサクラ。
ナルトが、
「できたってばよ！」
と言っても、
テストが落ちていたら、
「どこができてんのよ！」
と止める担当。
そして、
Orchestratorが火影 + 任務受付所 + 作戦本部。
この第7班に、
誰が次に動くのか。
誰が修正するのか。
いつ人間を呼ぶのか。
を指示します。
無理やりまとめると、
| AI / システム | NARUTOでいうと | 役割 |
|---|---|---|
| Claude Code | ナルト | 実装・修正 |
| Codex | サスケ | 厳しめの技術レビュー |
| Gemini | カカシ先生 | Edge Case・別視点 |
| CI | サクラ | テスト・品質確認 |
| Orchestrator | 火影 + 作戦本部 | 全体の進行管理 |
サクラもちゃんといました。
しかも思ってたより重要なポジションに。
ただし、
このメンバーを集めただけでは、
まだ本当に自律して動くチームにはなりません。
役割があって、
任務があって、
進行を管理する仕組みがあって、
さらに、
途中で勝手に止まらない仕組み
が必要です。
そして次に問題になるのが、
「じゃあ、どうやったらこのチームを止まらず動かせるのか」
です。
レビューで止まる。
CIで止まる。
GitHubで止まる。
Agentが判断を求めて止まる。
ここを潰さないと、
結局人間がずっと見張ることになります。
次回
第3部：AI開発を本当に自律化するために必要だった「止まらない設計」
次回は、
- AIが勝手に止まる問題
- 人間を呼んでいい条件
- CI失敗からの自動復旧
- Review指摘からの自動修正
- 無限ループを防ぐ仕組み
- GitHub上で安全に動かすための制約
- 「人間は最終承認だけ」にするまでに必要だった設計
について書きます。
第1部で勇者を集めて、
第2部でパーティを作りました。
第3部では、
こいつらを放置しても冒険を続けるようにします。
そろそろ私は、
コントローラーを置きたい。