検証ループとは?AIに「自分で確認」させる仕組み

「できました!」を信じすぎないための仕組み

Claude Codeに何か作業をお願いすると、たいてい最後に「実装が完了しました」と返ってきます。ここで正直、最初のうちは「そうか、終わったのか」とそのまま受け取ってしまうんですが、実際に動かしてみるとエラーで落ちる、ということが起こります。

なぜかというと、この「完了しました」はAI自身の自己申告だからです。人間だって、答案を提出したあとに見直しをしなければ間違いに気づけません。見直しの手段そのものを持っていなければ、なおさらです。

検証ループ(Verification loop) は、この状況を変えるための考え方です。Claude自身が実行できる「確認手段」をあらかじめ渡しておくことで、1回書いて終わりではなく、チェックが通るまで自分で直して試し直すサイクルを回させます。

料理を作るとき、味見をせずに出すのと、味見をしながら塩を足していくのとでは、出来上がりがまるで違います。

味見なしのパターンは「レシピどおりに作ったので、たぶん美味しいはずです」で終わります。これがAIの自己申告に頼った状態です。一方、味見ができれば「あ、薄いな」→塩を足す→また味見→「今度はいい」と、納得できるまで繰り返せます。

検証ループでやっていることは、まさにこの味見です。AIに味見の手段を渡す、というのが本質です。逆に言えば、味見の手段がない料理は、どれだけ優秀な料理人でも仕上がりを保証できません。

Claude Codeが自分で実行できるチェック手段としては、次のようなものが挙げられます。

ポイントは、どれもClaudeが自分で実行して、結果を自分で読めるということです。人間が目で見て「ここが変だよ」と伝えるしかない項目は、検証ループには組み込めません。逆に、コマンド一発で成否がはっきり出るものほど、ループに乗せやすくなります。

やり方はシンプルで、作業内容と一緒に「どうやって確認するか」を渡すだけです。

この機能を実装してください。
実装後に npm test を実行し、
テストが全部通るまで修正を続けてください。

こう伝えておくと、Claudeは実装 → テスト実行 → 失敗したら原因を読んで修正 → 再実行、という流れを自分で回します。人間がやっているのは「合格ラインの提示」だけで、その先の試行錯誤は任せられます。

チェック手段を渡さない場合、完了の判断はすべてClaudeの主観になります。すると、こんなことが起きます。

コードは書かれているけれど動かない。動くけれど既存の機能を壊している。見た目を直したはずなのに、実は別の画面が崩れている。どれも「実装した」という事実自体は嘘ではないので、報告としては成立してしまうのが厄介なところです。

そして最終的にそのズレを見つけるのは人間になります。テストを流して、エラーを読んで、また依頼して……という往復が発生します。検証ループを最初に用意しておくのは、この往復をClaude側に寄せる作業だと考えるとわかりやすいです。

いきなり完璧な検証環境を用意しようとすると腰が重くなるので、すでにあるものを使うのがおすすめです。プロジェクトにテストコマンドがあるなら、まずそれを伝えるだけで十分な効果があります。ビルドコマンドも同様です。

もしテストがまったくない状態なら、「この関数のテストを先に書いてから実装してください」とお願いしてしまう手もあります。合格条件が先に決まっていれば、そのあとの実装は検証ループに乗せられます。

要するに、検証ループを整えるというのは、AIに丸投げするための準備ではなく、AIが自力で正解に近づけるレールを敷く作業です。ここに時間をかけた分だけ、あとのやり取りが楽になります。

このページは役に立ちましたか？