はじめに

AIに実装を任せたあと、とりあえずこう投げていませんか。

「あなたが実装した内容が問題ないか調査して」

このあと返ってくるのは、たいてい丁寧な報告です。

「確認しました。大きな問題は見当たりません」

安心してマージしたら、テスト環境や本番でエラーが発生...
こういう経験がある人は少なくないはずです。

この記事では、そもそもこの指示がどこまで有効なのかを、論文とAnthropic公式ドキュメントを手がかりに整理します。

結論：曖昧な「調査して」は空振りしやすく、信頼できる検証手段を渡すべし

先に要点をまとめます。

指示の出し方	AIがなりやすい行動	得られる根拠の強さ
「問題ないか調査して」だけ	自分のコードを読み直して感想を述べる。環境によっては、関連ファイルの検索やテスト実行まで行う場合もある	弱～中
「テストとビルドを実行して結果を見せて」	実際にコマンドを走らせて合否を確認する	強（ただしテストと仕様が正しい場合）
「別の視点で、この基準に沿ってレビューして」	基準に照らして指摘を出す	中～強

※いずれもモデル、ツール、プロンプトによって挙動は変わります。表は傾向を示したものです。

ポイントは、AIの「確認しました」という言葉ではなく、外から観測できる、信頼できる合否の信号があるかどうかです。

ここでいう「信頼できる」には注意が必要です。テストが仕様を取り違えていれば、誤った合格信号が出ます。この点は後半の「注意点とリスク」で改めて触れます。

「調査して」が空振りしやすい3つの理由

理由1　合格基準がない

「問題ない」とは、何を満たせば問題ないのでしょうか。

要件を満たすことでしょうか。
エラーが出ないことでしょうか。

基準が曖昧なまま頼むと、AIは自分で基準を決めて、その基準で合格を出しやすくなります。

理由2　自分の出力を自分で判定している

実装した本人が、同じ会話の中で、同じ前提を引きずったまま見直す構図です。

人間でも、自分が書いた文章の誤字は見落としやすいですよね。

AIにも似た事情があると考えられます。

理由3　実装と検証が混ざりやすい

AIエージェントに実装を任せる場合、「実装そのもの」と「検証」は分けて考える必要があります。

実装した内容を読み返すだけでは、実際に動くかどうかを確かめたことになりません。実行して確かめる工程を明示的に入れない限り、「できたように見える」状態で報告が終わる可能性があります。

これは実証結果というより、この記事の整理です。実際の挙動はツールやモデルによって異なります。

研究が示唆していること

ここからは、論文の話です。

ICLR 2024

論文「Large Language Models Cannot Self-Correct Reasoning Yet」は、ICLR 2024に採択されました。

この論文は、外部からのフィードバックなしにLLMが自分の回答を直す力を「内的な自己修正（intrinsic self-correction）」と呼び、その効果を検証しています。対象は主に推論タスクで、著者ら自身も検証範囲を推論（reasoning）に限定しています。

結果として、外部フィードバックなしでは、検証した推論タスクで自己修正がうまく働かず、かえって性能が下がる場合もあることが報告されました。

ここから、「もう一度よく見直して」と頼むだけの自己修正は、少なくとも推論タスクでは精度向上が保証されない、と読み取れます。コードレビューに同じことが当てはまるかは、この論文だけでは言えません。

TACL 2024

さらに、「When Can LLMs Actually Correct Their Own Mistakes?」というサーベイ論文では、自己修正が成功する条件が整理されています。

要旨を私なりにまとめると、次の3点です。

一般的なタスクでは、プロンプトで与えたLLM自身のフィードバックによる自己修正の成功を示した先行研究は見つかっていない（ただし、自己修正と相性のよい特定のタスクは例外として挙げられている）
信頼できる外部のフィードバックが使えるタスクでは、自己修正がうまくいく
大規模なファインチューニングを行えば、自己修正できるようになる

この結果を実装レビューに当てはめると、テストやコンパイラ、公式ドキュメントのような「外部の信頼できる信号」を使わせることが、効かせる鍵になりそうだと考えられます。

これらの論文が主に検証したのは、数学的な推論や質問応答などのタスクです。「コードレビュー」そのものを直接測った研究ではありません。また、実験に使われたモデルは2023年前後のものが中心です。

そのため、「今のAIは自己レビューが全く役に立たない」と言い切れるわけではありません。あくまで「自己評価だけに頼るのは根拠が弱い」という示唆として受け取ってください。

公式ドキュメントも「検証手段を渡す」方向を推している

では、実際のAIツール提供側はどう言っているのでしょうか。

Claude Codeのベストプラクティスでは、AIが自分の作業を検証できる手段を与えることが、主要な推奨事項の一つとして挙げられています。

テスト、ビルド、スクリーンショットの比較など、合格か不合格かを返してくれるものなら何でも構いません。

こうした検証手段があると、AIは作業し、チェックを実行し、結果を読み、通るまで繰り返すというループを自力で回せます。

また同じドキュメントには、次のような趣旨の記述もあります。

長時間AIに任せるほど、独立した確認の重要性が増す
新しいサブエージェントの文脈でレビューさせると、変更の差分と渡した基準だけを見て評価できる
検証できないものは出荷しない、という考え方が推奨されている

先ほどの論文から示唆される方向性と、おおむね一致しています。

上記は公式ドキュメントの記述を私が要約したものです。内容は更新されることがあるため、最新の表現は原文を確認してください。

「調査して」を「検証して」に変える5つの型

型1　何を動かすかを指定する

「調査して」を、具体的な実行に置き換えます。

既存のテストを全部実行する
ビルドとLintを通す
実際にコマンドやAPIを叩いて出力を見る

AIが動かせる環境なら、この一手で根拠の質が上がりやすくなります。

型2　合格基準を先に渡す

要件と、気にしてほしいエッジケースを列挙します。

たとえば「空配列」「null」「同時実行」「タイムゾーン」などです。

基準があれば、「何をもって問題ないとするか」をAIが勝手に決める余地が減ります。

型3　実装した文脈とは別の場所でレビューさせる

同じ会話で見直すより、新しいセッションやサブエージェントに、差分と基準だけを渡してレビューさせるほうが、独立した観点を作りやすくなります。

実装の経緯を知らない状態で読むため、思い込みに引きずられにくくなると期待できます。ただし、同じモデルが同じ癖で読むこと自体は変わらないため、万能ではありません。

型4　根拠を出させる

「問題ありません」という結論ではなく、実行したコマンド、終了コード、結果の要約を報告させます。

必要に応じて、失敗した箇所の出力だけを貼らせるのも有効です。巨大なログを全部貼らせると、かえって確認しづらくなります。

人間が短時間で真偽を確認できる形で出させるのがポイントです。

型5　参照可能な公式ドキュメントと照合させる

ライブラリやAPIの使い方が正しいかどうかは、AIの記憶ではなく一次情報で確認します。

参照可能な公式ドキュメントを指定し、「この仕様の該当箇所を確認して、食い違う点がないか照合する」よう頼みましょう。

ただし、URLを渡せばAIが常に正確に読めるとは限りません。どの記述を根拠にしたのか、該当箇所を示させると確認しやすくなります。

コピペで使える指示テンプレート

上の5つを組み合わせると、次のようなプロンプトになります。

直前の実装について、次の手順で検証してください。

## 実行すること
1. 既存のテストを全て実行し、実行したコマンド、終了コード、結果の要約を報告する（失敗があれば該当出力を貼る）
2. ビルドとLintを実行し、同様に結果を報告する
3. 既存のテストでカバーされていない今回の変更について、必要ならテストを追加し、実行結果を報告する

## 確認してほしい観点
- 要件（ここに要件を書く）を満たしているか
- 空入力、null、上限値、異常系の挙動
- 使用しているAPIが、参照可能な公式ドキュメント（URLを書く）の仕様と一致しているか。根拠とした該当箇所も示すこと

## ルール
- 既存のテストを削除、弱体化、スキップしないこと
- 実行していないことを「確認した」と書かないこと
- 確認できなかった項目は、確認できなかったと明記すること

短い変更なら、ここまで厳密にする必要はありません。

変更の大きさに合わせて、項目を削ってください。

注意点とリスク

「テストが通ること」と「正しいこと」は同じではありません。

AIが書いたテストが、AIが書いた実装をなぞっているだけなら、両方とも同じ勘違いをしている可能性があります。AI自身が追加したテストだけでは、検証の独立性が弱くなります。テストの中身は、人間が必ず目を通してください。

特に気をつけたい点を挙げます。

AIが、テストを通すために実装ではなくテスト側を書き換えることがある（DataCampの解説記事でも触れられています）
報告された「実行結果」が、実際に実行された本物の出力かどうかは、重要な変更なら人間が再実行して確かめる
認証、課金、データ移行のような影響の大きい変更は、AIの検証だけで完結させず、人間のレビューも通す

AIに検証させることは、人間のレビューを省く手段ではありません。

人間が見るべき箇所を、絞り込むための手段と考えるのが安全です。

「調査して」にも意味がある場面

ここまで厳しめに書きましたが、曖昧な指示が完全に無意味というわけではありません。

AIコーディングツールのようにファイル検索やコマンド実行ができる環境では、「調査して」という言葉がきっかけで、関連ファイルを読みに行ったり、テストを走らせたりすることがあります。

その場合、結果として外部の信号を取り込めます。

ただし、それが起きるかどうかはAI任せです。

だからこそ、やってほしい行動をこちらから明示するほうが確実です。

まとめ

「問題ないか調査して」だけでは、AIの自己評価にとどまる場合があり、根拠が弱くなりやすい
研究からは、外部フィードバックなしの自己修正は（少なくとも推論タスクでは）安定しないことが示唆されている
公式ドキュメントも、テストなどの検証手段を渡すことを主要な推奨事項として挙げている
効かせるには、実行対象、合格基準、別文脈でのレビュー、根拠の提示、一次情報との照合を指示に入れる
ただしAIの検証は人間のレビューの代わりにはならない

次にAIへ実装を頼むときは、「調査して」の一言で終わらせず、何を動かして、何をもって合格とするかを一行でも添えてみてください。

参考