AIエージェントに開発を任せる際、実装からチェックまで1体のAIに任せていないでしょうか。当社も最初はそうでしたが、この構成には見落としに気づきにくいという弱点がありました。
そこで、指揮役のClaude Codeに加えて、別のAIであるCodex CLIを「部下」として組み合わせ、実装とレビューを分担する体制にしました。この記事では、その役割分担の設計と、安定して運用するために必要だったルールを紹介します。
背景・課題
Claude Codeにコードの実装や資料作成を任せる場面が増えるにつれ、「その成果物を誰がチェックするか」が課題になりました。実装したAI自身に確認までさせると、自分の書いたものを自分で採点する構図になります。
人間の開発チームであれば、書いた本人だけのレビューで本番に出すことは避け、別の人の目を通すのが一般的です。同じことがAIにも当てはまるはずだと考えました。
加えて、1体のAIに全工程を任せると作業が直列になります。実装が終わるまで検証もレビューも始められず、規模の大きい作業ほど待ち時間が積み上がります。
やったこと
そこで、AIの役割を2つに分けました。Claude Codeを指揮役とし、会話の文脈を持ち、設計判断・実装・最終判断を担わせます。Codex CLIを部下として、客観的なレビューや調査、画像生成など、切り出せる作業を請け負わせます。
役割を分けただけでは安定して動きません。運用の中で、頼み方に関する4つのルールが必要だと分かりました。
- 依頼文は自己完結で書き切る: 「さっきの修正」「他のファイルも見て」のように、会話の前提や曖昧な参照に頼った頼み方をしない。部下側のAIは会話の前提を持たないため、参照してほしいファイルのパスや範囲、判断基準まで、必要な情報をすべて依頼文自体に書く
- 「質問を返さず、前提を明記して続行する」と依頼文に明示する: 部下役のAIが判断に迷って質問を返そうとすると、その質問を中継する手段がなく処理が止まってしまう。事前に「不明点があっても前提を置いて進め、結果を直接出力する」と伝えておく
- 成果物はファイルで受け渡す: 依頼と結果をやり取りする経路をファイルにし、指揮役が実際に生成されたかを確認できるようにする
- 部下の指摘は鵜呑みにせず、指揮役が1件ずつ採否を判断する: レビューでの指摘がすべて正しいとは限らない。誤指摘や過剰な要求は却下し、採用するものだけ反映する
結果
人に見せる前に、実装したAIとは別のAIによる客観的な確認が入る流れが標準になりました。
実際に機能した例として、今回このブログのレイアウトを変更した際、部下役のCodex CLIによるレビューが、ボタンの配色がアクセシビリティの基準（WCAG AAのコントラスト比）を満たしていない点を指摘しました。
白文字だとコントラスト比が基準未達で、指摘を受けて文字色を修正してから公開しています。実装者とは別の目でレビューを入れる意味が、実際の場面で出た例です。
作業を切り出して並行して進められるようになったことで、待ち時間を減らせる場面も増えました。
また、部下に切り出せる作業はレビューに限りません。指揮役のClaude Codeは画像の生成能力を持ちませんが、Codex CLIには画像生成機能が組み込まれています。そのため、資料に載せるイラストなどの画像制作も、レビューと同じ呼び出しの型のままCodexに任せられます。
このときの違いは権限の指定だけです。レビューでは部下に「読み取りのみ」の権限を渡しますが、画像生成ではファイルを保存させる必要があるため、作業フォルダへの書き込みを許可して呼び出します。「成果物はファイルで受け渡す」というルールもここでそのまま機能し、指揮役が画像ファイルの生成を確認してから次の工程へ進めます。実測では、依頼から約1分でPNGファイルが保存されました。
つまずきと対処
運用の途中では、部下役のAIが応答しないまま止まる不具合を何度か経験しました。
1つ目は、当社の呼び出し方では、コマンドの標準入力がパイプになっていると追加の入力を待ち続けたまま止まってしまうことがあった点です。ツール全般の不具合かは切り分けていませんが、空の入力を明示的に渡す形にすることで回避できました。
2つ目は、部下役のAIが判断に迷い、ユーザーへの質問を返そうとするケースです。この質問を中継する手段がないため、そこで処理が止まってしまいます。依頼文を自己完結にし、「質問を返さず前提を置いて進める」ことを明記することで防いでいます。
それでもまれに応答が止まることがあるため、成果物ファイルが実際に生成されているかを指揮役が確認し、生成されていなければ同じ依頼を再度出す、という見張りの仕組みを組み込んでいます。
まとめ
万能な1体のAIを目指すよりも、得意分野の異なる2体を組み合わせ、頼み方を明確なルールとして設計する方が、実運用では安定して回しやすくなりました。ポイントは、AIの数を増やすことそのものではなく、役割と依頼のルールを設計することにあります。
なお、どの作業に確認を掛け、どの作業は省略してよいかという判断基準については、別の記事で詳しく扱っています。
AIエージェントを組み合わせた開発体制の設計については、受託開発サービスでご相談を承っています。気になる点があれば、お問い合わせからお気軽にご連絡ください。