先に結論
AI Coding Agentを複数使うとき、大事なのは「どのAIが優秀か」より、役割を混ぜないことだと思います。
今回、no.1-production-ready-nl2sql を対象に、次の分担を試しました。
- Claude Code：コードをレビューし、bugをGitHub Issueとして登録する
- 人間：Issueの「問題・症状・原因・修正方針」をレビューする
- ChatGPT Codex：承認されたIssueを1件ずつ修正し、PRを作成する
ポイントは、Claude Codeにはコードを一切変更させないことです。
Claude Codeは問題を見つける側、Codexは修正する側に固定します。
この分担にすると、2つのAIが同時にコードを変更して衝突することを避けながら、長時間の自律実行とGitHub上の追跡可能性を両立できました。
なぜAI同士の役割を分けたのか
AI Coding Agentは、レビューも実装もできます。
そのため、最初は1つのAIに「問題を探して、そのまま直して」と頼みたくなります。
ただ、実際には次の問題が起きやすいです。
- 調査中にコードが変更され、最初の状態が分からなくなる
- 複数の問題が1つの大きな変更に混ざる
- 別のAIが同じファイルを変更し、競合する
- なぜ修正したのかが後から追いにくい
- AIの判断を人間が確認する前に実装が進む
特に長時間AIを動かす場合、変更量よりも「判断を追跡できること」の方が重要になります。
そこで今回は、分析と修正の間にGitHub Issueを置きました。
1. Claude Codeはreviewだけを行う
最初にClaude Codeへ、リポジトリ全体を確認して潜在的なbugを探すよう依頼します。
ただし、権限と役割は明確に制限します。
コードの調査とレビューのみ行う。
ファイルの変更、commit、修正PRの作成は行わない。
問題を発見した場合は、1件ずつGitHub Issueとして登録する。
Issueには、最低でも次の4項目を含めます。
## 問題
何が問題なのか。
## 症状
どのような入力や条件で、何が起きるのか。
## 原因
どのコードや設計が原因だと考えられるか。
## 修正方針
どこを、どのような考え方で修正するか。
可能であれば、影響範囲、再現手順、関連ファイル、必要なテストも追加します。
ここでClaude Codeに求めるのは、修正コードではありません。
次の担当者が迷わず作業を始められる、説明可能なIssueを作ることです。
2. 人間はIssueの判断部分をreviewする
Claude Codeが作成したIssueを、そのままCodexへ渡すわけではありません。
人間が確認するのは、主に次の4点です。
- 本当に問題なのか
- 記載された症状は正しいか
- 原因の推定に飛躍がないか
- 修正方針が適切か
AIの分析は、それらしく見えても前提が間違っていることがあります。
特に「原因」と「修正方針」が間違っていると、Codexは間違ったGoalに向かって正しく作業してしまいます。
そのため、人間はコードを細かく書き直すのではなく、問題設定と方向性をレビューします。
この段階が、分析AIと実装AIの間にある品質ゲートになります。
3. CodexにはIssueを1件ずつ修正させる
人間がIssueを確認した後、ChatGPT CodexにGoalを設定します。
例えば、次のようなGoalです。
Open状態のbug Issueを優先度順に確認する。
1回の作業では1件だけを対象にする。
Issueの内容を検証してから修正し、必要なテストを追加する。
テスト成功後にPRを作成し、Issueと関連付ける。
完了後、次のIssueへ進む。
重要なのは「1件ずつ」です。
複数のIssueをまとめて修正すると、差分が大きくなり、失敗したときの切り戻しや原因調査が難しくなります。
一方、IssueとPRを1対1に近い粒度で管理すると、次のことが分かりやすくなります。
- 何のための変更か
- どのファイルが変更されたか
- どのテストで確認したか
- どの判断に基づいて修正したか
- 問題が再発したとき、どこまで戻ればよいか
CodexはGoalを明確に設定しておけば、人が途中で細かい指示を繰り返さなくても、まとまった時間作業を継続させやすくなります。
4. Claude CodeとCodexが競合しない
今回の分担はかなり単純です。
| 担当 | 読み取り | Issue作成 | コード変更 | PR作成 |
|---|---|---|---|---|
| Claude Code | ○ | ○ | × | × |
| 人間 | ○ | レビュー | × | レビュー |
| Codex | ○ | 参照 | ○ | ○ |
Claude Codeはコードを書き換えません。
そのため、Codexが修正作業をしている間に、Claude Codeの変更と衝突することがありません。
また、両者のやり取りを直接つなげず、Issueを境界にしている点も重要です。
Issueが、AI同士の共通インターフェースになります。
5. 後から問題を追いやすくなる
この運用の一番大きなメリットは、履歴が残ることでした。
修正後に別の問題が発生しても、IssueとPRを見れば、
- 最初にどの症状が報告されたか
- Claude Codeが何を原因と判断したか
- 人間がどの方針を承認したか
- Codexがどのコードを変更したか
- どのテストを実行したか
を追跡できます。
必要であれば、Claude CodeやCodexに過去のIssueとPRを読ませて、当時の判断まで含めて再調査させることもできます。
AIに記憶を期待するのではなく、GitHubに判断履歴を残し、必要なときに読み直させる形です。
まとめ
今回試したのは、2つのAIを同じ開発者として動かす方法ではありません。
- Claude Codeは、問題を発見してIssueにする
- 人間は、問題・症状・原因・修正方針を判断する
- Codexは、承認されたIssueを1件ずつ修正する
- GitHubは、すべての判断と変更を記録する
という役割分担です。
AIに長時間作業させるほど、重要になるのは自律性だけではありません。
止められること。
レビューできること。
後から理由を追えること。
別のAIへ引き継げること。
個人的には、AI Coding Agentを安定して使うために必要なのは、さらに強いモデルを待つことよりも、AI同士が衝突しない開発プロセスを先に作ることだと感じました。
Claude Codeは直さない。
CodexはIssueに書かれたことだけを、1件ずつ直す。
この単純な境界が、長時間のAI開発をかなり管理しやすくしてくれます。