1つのAIに作らせて同じAIに確認させると、どうしても採点が甘くなります。作る係（Claude Code）と見直す係（Codex）を分け、指摘→修正→再確認を往復させる設計を、たとえ話でやさしく解説します。
⚠️ この記事は2026年7月時点の情報です。Claude CodeやCodexの仕様やサービスは変わる場合があるため、最新かつ正確な情報は各公式ドキュメント・公式サイトもご確認ください。あわせてAI同士でレビューを往復させるもどうぞ。
「AIに作ってもらったものを、そのままAI自身に『これで合ってる？』と聞いても、たいてい『バッチリです！』と返ってくる」——そんな経験はありませんか。人間でも、自分の書いた文章の誤字は見つけにくいものです。AIも同じで、自分が作ったものを自分で採点すると、どうしても点が甘くなります。
この記事では、作る係（Claude Code）と見直す係（Codex）という、2つの別々のAIを協働させる仕組みを紹介します。読み終えるころには、「2人のAIに議論させて、人間である自分は最後にOKを出すだけ」という感覚がつかめるはずです。コードが書けなくても大丈夫。むしろ、コードを書かない人こそ、この”審判役”に向いています。
以前の記事「AI同士でレビューを往復させる」の姉妹編として、今回は役割分担の設計そのものに一歩踏み込みます。なお、私が実際に運用しているのは、株の値動きを観測・研究する（observe / research）ためのシステムで、実際の売買（発注）はしない設計です。この記事もその前提で、あくまで「AIの使い方」の話をします。
なぜ「作った本人が自分で承認しない」のか
ソフトウェア開発の世界には、昔からコードレビュー（code review＝他人が書いたものを見直す作業）という文化があります。作った人と、確認する人を分ける。当たり前のようですが、これには深い理由があります。
作った本人は、頭の中に「こう動くはず」という思い込みがあります。だから、その思い込みどおりに動かない可能性を見落としがちです。学校のテストで、自分の答案を自分で採点したら満点をつけたくなる——あの感覚に近いです。
ここで大事な考え方が、自己承認しない（no self-approval＝作った本人が自分でOKを出さない）という原則です。これはAIに限らず、多くの現場でルールになっています。作る人と承認する人が同一だと、チェックが形だけになりやすいからです。
| やり方 | 起きやすいこと |
|---|---|
| 1つのAIが作って、同じAIが確認 | 「問題ありません」と甘い自己採点になりがち |
| 作る係と見直す係を別のAIに分ける | 別の視点で粗が見つかり、品質が安定する |
つまり狙いはシンプルです。視点を1つ増やすこと。人間のチームで「一人で抱え込まず、もう一人に見てもらおう」と言うのと、まったく同じ発想です。
2つのAIに、それぞれ違う役を割り当てる
今回の主役は2つのAIです。名前は違っても、やることは「工事現場の職人」と「検査員」の関係だと思ってください。
作る係：Claude Code
Claude Codeは、実際に手を動かして作る係です。指示を受けて、ファイルを書いたり直したり、動作を試したりします。現場でトンカチを振るう職人さんのイメージです。仕事は速く、たくさん作れますが、自分の作ったものには当然、愛着と思い込みがあります。
見直す係：Codex（別のAI）
Codexは、別会社の別のAIです。今回は「作らない」代わりに「作られたものを厳しく見る」検査員の役を担います。大事なのは、作っていない他人だからこそ、遠慮なく指摘できるという点です。同じ現場の身内ではないので、「ここ、危なくないですか？」とはっきり言えます。
役割を固定するのがコツです。「今日は作る係」「今日は見直す係」とふらふら変えず、それぞれの持ち場を決めておく。そうすると、見直す係は「粗探しが仕事」と割り切れて、遠慮のない指摘が出やすくなります。
| 役割 | 担当AI | たとえると | 主な仕事 |
|---|---|---|---|
| 作る係 | Claude Code | 現場の職人 | 作る・直す・試す |
| 見直す係 | Codex | 検査員 | 粗探し・指摘・合否判定 |
| 最終承認 | あなた（人間） | 現場監督 | 説明を聞いてOK/待ったを出す |
キャッチボール：指摘→修正→再確認を往復させる
この2つのAIを、一度きりで終わらせないのが肝心です。キャッチボール（往復のやりとり）を回します。流れはこうです。
- 作る係が作る：Claude Codeが指示どおりに作ります。
- 見直す係が指摘する：Codexが「ここが甘い」「この場合どうなる？」と粗を挙げます。指摘には合否バッジ（PASS＝合格 / HOLD＝保留 / BLOCK＝止める）のような、一目で分かる印をつけてもらうと便利です。
- 作る係が直す：指摘をClaude Codeに戻し、修正させます。
- 見直す係がもう一度見る：直った版をCodexが再確認します。ここで「まだ足りない」と言われたら、また3に戻ります。
- 合格したら、あなたが最終OK：見直す係が「合格」と言ってはじめて、人間が最後の承認をします。
この往復を、私は普段2〜3回ほど回します。1回で終わることはめったにありません。むしろ、1回で「完璧です」と返ってきたら、少し疑ったほうがいいくらいです。往復するたびに、最初は見えなかった弱点がひとつずつ潰れていきます。
大事なのは、見直す係の指摘を、そのまま作る係に渡すだけという点です。人間が指摘の中身を技術的に理解している必要はありません。「Codexがこう言ってるから直して」と橋渡しするだけ。翻訳者を挟んで、2人の職人に話し合ってもらうイメージです。
人間の役割は「最後にOKを出す審判」
ここが、非エンジニアにとって一番うれしいところです。あなたの仕事は、コードを読むことでも、直すことでもありません。審判（judge）として、最後に判断を下すことです。
具体的には、こんな進め方になります。
- 作る係に「作って」と頼む：やりたいことを普通の日本語で伝えます。
- 見直す係に「見て」と頼む：作られたものを、別のAIに渡してチェックしてもらいます。
- 指摘を作る係に戻す：出てきた指摘を、そのまま作る係へ。
- 合格が出たら、あなたがOKする：見直す係が「合格」と言ったものだけ、最終的に採用します。
審判として気をつけるのは、たった一つ。作る係が「できました！」と言っても、それだけで信じないことです。必ず見直す係の「合格」を経由させる。この一手間があるかないかで、品質はまるで変わります。人間が全部を理解できなくても、「2人のAIが合意したもの」というフィルターを通すだけで、安心感がぐっと増します。
安全を絶対に譲らないために
もう一つ、審判として守るべき線引きがあります。本当に大事な判断は、AI任せにしないことです。私のシステムでいえば、「実際に売買する」ような領域は、そもそもAIに実行させない設計にしています。AIはあくまで観測・研究し、提案するところまで。最終的に触れてはいけない一線は、人間が固く守ります。
見直す係のCodexも、あくまで「見直す」係であって、勝手に本番へ反映する権限は持たせません。作る係も見直す係も、最後の承認ボタンには手が届かない——そういう配線にしておくのが、安心して任せるコツです。
まとめ：次の一歩
今回のポイントを、もう一度整理します。
- 1つのAIの自己採点は甘くなりがち。だから作る係と見直す係を別のAIに分ける。
- 自己承認しない（no self-approval）を原則にして、作った本人にはOKを出させない。
- 指摘→修正→再確認のキャッチボールを2〜3回まわすと、品質が安定する。
- 人間の役割は最後にOKを出す審判。技術を全部理解する必要はなく、橋渡しと最終判断に集中する。
- 本当に大事な一線（発注など）は、そもそもAIに実行させない設計で守る。
次の一歩としておすすめしたいのは、とても小さなことで一度試してみることです。いきなり大きな仕組みで始めなくて大丈夫。たとえば「短い文章を作る係に書かせて、見直す係に直しどころを挙げてもらう」だけでも、往復の感覚がつかめます。慣れてきたら、指摘に合否バッジ（PASS / HOLD / BLOCK）をつけてもらうと、審判としての判断がぐっと楽になります。
「2人のAIに議論させて、自分は最後にうなずくだけ」。この感覚さえ手に入れば、コードが書けなくても、一人では作れなかったものが少しずつ形になっていきます。まずは小さな往復から、ぜひ始めてみてください。
関連記事
無料テンプレート配布のお知らせ
Claude Codeを安全・便利に使うための設定テンプレート（CLAUDE.md）を無料配布しています。メールアドレスをご登録いただくと、すぐにダウンロードリンクをお送りします。
免責事項
本記事は執筆時点（2026年7月）の情報に基づいています。Claude Code・Codex・各種AIツールの仕様は予告なく変更される場合があります。最新かつ正確な情報は各公式ドキュメント・公式サイトをご確認ください。本記事の内容を用いて生じたいかなる損害についても、筆者は責任を負いかねます。
コメント