AI同士でレビューを往復させる【相互レビューのキャッチボール・実例つき】

前回、「作るAIとチェックするAIを分ける」という話をしました。今回はその続きで、実際にAI同士がレビューを往復させた記録をお見せします。監査するAIが「ここが危ない」と止め、実装するAIが直し、もう一度見せたら通った——この4回のキャッチボールの実例を通して、AIを安全に使う実践的なコツを解説します。

⚠️ この記事は2026年6月時点の情報です。お金が関わるシステムを例に出しますが、個人の体験談であり、投資推奨ではありません。また、セキュリティに関わる話が出てきますが、悪用を防ぐため、具体的な攻撃手法や再現方法は一切書きません。考え方の部分だけを解説します。

💡 この記事は、実装AIと監査AIを分ける仕組みの続編です。先にそちらを読むと、より分かりやすいです。

まず、身近なたとえで：本の「赤入れ」
「投げっぱなし」にしないのがポイント
実例：4回のキャッチボールで「却下」が「合格」になるまで
なぜ「記録に残す」のか
非エンジニアが、今日から使える教訓
まとめ：ボールを往復させ、最後は人が決める

まず、身近なたとえで：本の「赤入れ」

図：レビューのキャッチボール

例によって、誰でも分かる例から。**本の原稿の「赤入れ(校正)」**を思い浮かべてください。

校正者が原稿を読み、「ここは事実が怪しい」「表現を直して」と赤を入れて返す
著者が赤入れを見て書き直し、「直しました」と再提出する
校正者がもう一度読んで、直っていればOK、まだ気になればまた赤を入れる
これをOKが出るまで何度か往復し、最後に編集長(人間)が「これで出版」と決める

校正者が一度赤を入れただけで本を出すのではなく、著者と校正者が何度かボールを往復させ、人が最後に判を押す。この当たり前の段取りを、AIの開発レビューに当てはめたのが、今日紹介する「相互レビューのキャッチボール」です。

「投げっぱなし」にしないのがポイント

前回の記事で「監査するAI」を紹介しましたが、ここには落とし穴があります。監査AIが一度指摘して終わりだと、こうなりがちです。

監査AIが「ここがダメ」と言う → そこで終了
でも——本当に直ったのか? 直し方は適切だったのか? が確認されないままになる

これは「投げっぱなし」のチェックです。指摘しただけで、その指摘が対応されたかを誰も見届けない。これでは「直したつもりで直っていない」を防げません。

そこで、往復させます。

監査AIが指摘する → 実装AIが直して「直しました」と返す → 監査AIがもう一度見て合否を出す → 必要ならまた往復…を、決着するまで繰り返す

ボールを投げっぱなしにせず、受け取って投げ返す。だから「キャッチボール」。「指摘 → 修正 → 再確認」を、合格が出るまでループさせるのが、相互レビューです。

実例：4回のキャッチボールで「却下」が「合格」になるまで

図：4往復で却下→合格

ここからが本題です。私のシステムに残っている、実際の往復記録を一つ紹介します。合計4ラウンド(監査AIが2回、実装AIが2回)で決着しました。

⚠️ この例では、監査AIが「安全上の問題」を見つけました。ただし、その問題の具体的な中身(どう攻撃できるか)は、悪用を防ぐため書きません。「どんな種類の問題で、どう解決したか」の流れだけをお伝えします。

🔴 1回目：監査AIが「却下(BLOCK)」

監査AIが、実装された変更を安全の観点で点検しました。そして、ある安全上の懸念を見つけ、**却下(BLOCK)**しました。

問題の種類を、差し障りのない範囲で言うと——「想定外の保存先を指定されないようにする防御が不足していた」(不正なファイルパスを使われる恐れ)というものでした。あわせて、テストが足りないこと、説明文と実装にズレがあることも指摘しました。

💡 ここで監査AIは、ただ「ダメ」と言うだけでなく、何が・なぜ問題かを具体的に示しています。これが次のラウンドで実装AIが的確に直せる理由です。

2回目：実装AIが指摘を受け入れる

却下を受けて、実装AIは指摘を妥当と認め、対策の方針を示しました。「許可された範囲の外を指定できないように封じ込めます」という方向性です。ここではまだ直し始めで、「こう直します」という宣言の段階です。

3回目：実装AIが修正＋テスト追加

実装AIが、宣言した方針どおり修正を実施しました。そして重要なのは——修正しただけでなく、それを検証するテストを追加したこと。さらに、ズレていた説明文も実装に合わせて直し、「直したので再点検してください」と監査AIに投げ返しました。

💡 「直しました」だけでなく「直ったことを確かめるテストも付けました」というのがポイント。これで、後から見ても「本当に直ったか」が分かります。

🟢 4回目：監査AIが「合格(PASS)」

監査AIが、修正後の変更をもう一度点検しました。各観点で問題がないことを確認し、**合格(PASS)**へ。最初は却下だったものが、修正と追加テストを経て、問題なしに収束したのです。

ただし——ここでも監査AIは大事なことを明記しています。**「これは”この変更が安全である”という確認であって、本番への最終ゴーサインではない」**と。つまり、最後の取り込み判断は、やはり人間に残されているのです。

なぜ「記録に残す」のか

このやり取りは、あとから読める形で全文が保存されています。誰が・いつ・何を指摘し・どう直したか。これが地味に、でも決定的に重要です。

「言った/言わない」にならない：指摘も対応も最終判定も文章で残るので、水掛け論が起きない
追跡できる：「なぜこの変更を通したのか」「どんな懸念をどう解消したのか」を後からたどれる
学びが蓄積する：過去の往復が資産になり、次に似た変更をするとき何に気をつけるか分かる
判断の根拠が残る：人間が最終承認するとき、「一度却下され、修正後に合格した」経緯ごと見て決められる

口頭やチャットで流れて消えるのではなく、判断の履歴がそのまま証拠として残る。これが、この仕組みのいちばんの価値です。

非エンジニアが、今日から使える教訓

専門知識がなくても応用できる教訓は、とてもシンプルです。

AIに何かをチェックさせるときは、一度きりで終わらせず「指摘 → 修正 → 再確認」と往復させると、精度が上がる。

日常のAI活用での、具体的な真似のしかたを挙げます。

文章添削：「直して」で終わらせず、直った文をもう一度AIに見せて「指摘した点が反映されているか確認して」と再チェックさせる
採点で残す：「OK / 要修正 / ダメ」のようにはっきり判定させると、進み具合が見える
やり取りを残す：チャット履歴やメモを残すと、「なぜこう直したか」を後で見返せる

ポイントは、「直したつもり」を信じず、もう一度確認させること。たったこれだけで、AIの仕上がりが目に見えて安定します。難しいシステムは要りません。あなたがChatGPTやClaudeを使うときにも、今日から実践できる習慣です。

まとめ：ボールを往復させ、最後は人が決める

監査AIの指摘を「投げっぱなし」にせず、「指摘→修正→再確認」を往復させる
実例では、🔴却下 → 修正＋テスト追加 → 🟢合格、と4回のキャッチボールで決着した
直すだけでなく「直ったことを確かめるテスト」を付けるのが肝
やり取りを記録に残すと、追跡でき、学びが貯まる
そして——最後に判を押すのは、いつも人間
非エンジニアも「直したつもりを信じず、もう一度確認させる」習慣が応用できる

3回にわたってお伝えしてきた「複数のAIを安全に使う」話は、これで一区切りです。AGENTS.mdで共通ルールを定め(①の記事)、作る役と見る役を分け(②の記事)、レビューを往復させて、最後は人が決める。 この一連の段取りが、AIに安心して仕事を任せるための、私なりの答えです。

コードが書けなくても、この「考え方」は誰でも使えます。一つのAIを盲信せず、チェックを重ね、最後は自分の目で確かめる。AIと上手に付き合う鍵は、案外こうした”昔ながらの段取り”にあるのかもしれません。

<!– 内部リンク：第2期①②・記事1（公開済み）。第2期完結 –>

無料テンプレート配布のお知らせ

Claude Codeを安全・便利に使うための設定テンプレート（CLAUDE.md）を無料配布しています。メールアドレスをご登録いただくと、すぐにダウンロードリンクをお送りします。

免責事項

本記事は執筆時点（2026年6月）の情報に基づく、筆者個人の体験の記録です。記事中の自動売買システムに関する記述は、特定の投資手法や自動売買の利用を推奨するものではありません。投資には元本割れのリスクがあり、最終的な判断はご自身の責任で行ってください。また、本記事ではセキュリティに関わる話題に触れていますが、悪用防止の観点から、具体的な脆弱性や攻撃手法の詳細は記載していません。AIツールの仕様は予告なく変更される場合があります。最新情報は各公式ドキュメントをご確認ください。本記事の内容を用いて生じたいかなる損害についても、筆者は責任を負いかねます。