Claude に検証を任せる

テスト・期待出力・スクリーンショットを最初に渡して、Claude が自分で正解判定する仕組みを作る。

最終確認 2026年5月1日 所要時間 約12分 v 2.x 対応

公式ベストプラクティスは、これを「あなたができる最も高いレバレッジのこと」と呼ぶ。Claude に自分の仕事を検証する手段を与える ─ 本章ではその意味と具体的なやり方を扱う。

自分が唯一のフィードバックループになる罠

Claude に「ログイン処理を実装して」とだけ頼むと、もっともらしいコードが返ってくる。一見正しそうに見える。だが実際にはエッジケースで壊れる、テストが通らない、ビルドエラーが出る ── そういう状態でこちらに渡されることがある。

このとき何が起きているか。Claude は自分の出力が正しいかを判定する手段を持っていないので、「文法的にそれっぽい」「構造がプロジェクトに合っている」あたりで筆を止めてしまう。

その結果、こちらが唯一のフィードバックループになる。動かしてみる、エラーを見る、貼り付け直す、Claude に直させる ─ 全ての品質チェックが手作業の往復で発生する。これは持続しない。

逆に言うと、Claude が自分で正解判定できる手段を渡せば、勝手にそれを使って自己修正する。

❌ メールアドレスを検証する関数を実装して

✅ validateEmail 関数を書いて。テストケースは user@example.com → true、invalid → false、user@.com → false。実装したらテストを走らせて。

期待値があると、Claude はそれに合わせて実装し、合わなければ修正する。「テストを走らせて」と一言加えておくと、自動的に検証ループが回る。

バグ修正では、**「失敗するテストを書いてから直す」**順番が強い。

ユーザーがセッションタイムアウト後にログインに失敗するバグがある。
src/auth/ の認証フローを確認して、特にトークン更新を疑って。
問題を再現する失敗するテストを書いて、それから直して。

「再現テスト → 修正 → テストが通る」のサイクルが Claude の中で完結する。さらに、修正の証拠としてテストがリポジトリに残るので、リグレッションも防げる。

UI 作業では、画像が一番強い検証手段になる。

[デザイン案のスクリーンショットを貼り付け]
このデザインを実装して。実装できたら結果のスクリーンショットを撮って、
元のものと比較して、違いをリストアップして修正して。

「比較して、リストアップして、修正する」までセットで頼むと、Claude が自分で何往復か繰り返してくれる。ブラウザ操作までさせたい場合は Claude in Chrome という拡張があり、UI を実際に開いて検証させられる。

npm run lint、tsc --noEmit、cargo check のような既存コマンドを、検証手段として明示的に使わせる。

この変更を入れたら、最後に `npm run typecheck` と `npm test` を走らせて、
通ることを確認して。

CLAUDE.md に「変更後は型チェックを走らせる」と書いておけば毎回意識せずに済むが、特に大きな変更では明示的に頼む方が確実である。

検証手段を渡しても、Claude がエラーを握りつぶす方向に動くことがある。型エラーを as any で消す、テスト失敗を .skip でスキップする、try/catch で例外を飲み込む ─ これらは表面上「検証が通る」が、品質は下がる。

これを防ぐには、最初に態度を指定する。

✅ ビルドがこのエラーで失敗している: [エラーを貼り付け]。修正して、ビルドが成功することを確認して。根本原因に対処し、エラーを抑制しないこと。

「抑制するな」を明示するだけで、Claude の挙動はかなり変わる。チームのプロジェクトなら、この一文を CLAUDE.md に書いておくのも手である。

検証手段を整える ─ テストを書く、ビルドコマンドを整備する、CI を設定する ─ は最初は手間に見える。が、これはこちらの注意力を Claude に貸すための投資である。

検証が堅牢になればなるほど、Claude は自走できる範囲が広がる。逆に検証が薄いプロジェクトでは、Claude を使ってもこちらの手間はあまり減らない。「Claude を使うために、まず検証ループを整える」という順番で考えると、長期的には速い。

ここまでで Claude 自身に検証させる仕組みを作る話を扱った。次章では、そうして上がってきた変更をこちら側でどう深く読むか、レビューの目を掘り下げる。