WHATISAI｜第3章

レバー②検証
── 推測を、決定論につなぐ

ここが、世界トップクラスとアマチュアを分ける核心です。モデルは"もっともらしいコード"を推測しますが、正しいかは保証しない。 その確率的な推測を、「テストが通った／通らない」という決定論に接続する ── それが検証レバー。そして、ひとつ厄介な事実があります。

本文の点線の専門用語は、タップすると意味が出ます。

なぜ検証が"自動化の上限"なのか検証できることしか、任せられない

Karpathy が Sequoia 2026 で言い切った原則です。

コーディングエージェントが優れているのは、「テスト合格／失敗、プログラム実行／クラッシュ」という明確なフィードバックがあるから。自動化できる範囲は「指定できること」から「検証できること」へ拡張された。 — Andrej Karpathy, Sequoia 2026（要約）

つまり ── 検証ループが作れるタスクほど、安心して Claude Code に任せられる。逆に検証が作れないタスク（正解が曖昧・テストが書けない）は、自律に任せると危ない。だから一流はまず問う:「これは、何をもって"できた"とするか？」

Claude Code での検証ループ
プロンプトに「実装してテストを実行、失敗なら直すを繰り返せ」と書く。これだけで、推測が検証に変わります。さらに で「テストが緑になるまで終わらせない」を強制できる。検証は「エビデンスを見せろ」形式で ── テスト出力・実行結果・スクリーンショットを必ず提示させる。

不都合な事実モデルは、自分の仕事を採点できない

「じゃあ Claude に自分でレビューさせればいい」── そう思いますよね。ところが Anthropic の発見はこうです。

エージェントは、自分が出した仕事を評価させると自信を持って高く評価しがち ── 人間の目には明らかに凡庸でも。自分の採点は、決まって甘い方へ偏る。 — Anthropic「Harness design for long-running application development」（要約）

理由は、これも"クセ"です。モデルは訓練で「自信を持って答える」パターンを学習している（説得力が好まれた結果＝ の裏面）。だから自分のバグにも自信満々。下で、自己採点と「分離」の差を体感してください。

触って確かめる：モデルは、自分の仕事を採点できない同じ5つの実装（うち3つに隠れたバグ）を、誰に検証させるかで切り替えてください。「生成者に自己採点」と「別の評価者に分離」で、見逃しが変わります。
  • 入力バリデーション⚠ バグ検出
  • 正常系のロジック問題なし
  • 認証チェック見逃し…
  • エラーハンドリング見逃し…
  • 表示の整形問題なし
1 / 3 件のバグを検出生成者は「自信」を学習しているので、自分のバグを見落とす。

※ 概形デモ。Anthropic は「エージェントは自分の仕事を自信を持って高く評価しがちで、自己採点は甘い方へ偏る」と報告。対策は GAN（生成器・識別器）にならった生成者と評価者の分離。Claude Code では、実装とは別セッション／別サブエージェントにレビューさせるのがこれ。

解決は、構造で生成者と評価者を、分ける

解は精神論ではなく構造です。 が生成器と識別器を分けるように、生成する主体と、評価する主体を、別の文脈にする。Claude Code での具体:

  • 別セッション／別サブエージェントにレビューさせる ── 実装した本人（同じ文脈）ではなく、新鮮な文脈の評価者に。「自分が書いたコードへのバイアス」が消える。
  • 検証専用サブエージェントを .claude/agents/ に常備（エラー処理・テスト網羅・セキュリティの3点確認役）。
  • hooks で機械的ゲート ── Stop hook やテストを、人格に頼らず仕組みで強制する。
まず予想してみる

Claude Code に大きめの機能を実装させた。レビューは誰にさせるのが筋が良い？

発展発展：検証の最前線 ── 検証しにくいものを、どう検証するか（最前線②）▼ 数式が苦手な方は飛ばしてOK

検証レバーには、底があります。検証ループは「検証できるタスク」にしか効かない。テストが書けるコードは天国ですが、世の中には検証しにくい仕事が山ほどある ── 長期の設計判断、価値観の絡む出力、"良い文章か" のような曖昧な基準。

ここが、いま研究と実務がせめぎ合う最も深い最前線です。「」と呼ばれ、アプローチは進化中:

  • RLHF → RLAIF：人の好みでの評価を、AIの評価で置き換え／補強する。
  • debate（討論）：2つのモデルに反論させ合い、人間は判定だけする。
  • 段階的な分解：検証しにくい大問題を、検証できる小問題に割る（第4章の分割と地続き）。

実務的な含意はシンプルです:検証ループが作れる仕事から、優先して自動化せよ。検証が曖昧な仕事は、自律に委ねきらず、人間ゲート（第5章）を厚くする。

⚠ 時点依存・議論中：scalable oversight は未解決の研究領域で、決定打はまだない（2026年なかば時点）。普遍なのは「検証可能性が、自動化の上限を決める」という構造。出典: Anthropic（モデルの自己評価バイアス）、Karpathy Sequoia 2026、Epsilla "Harness Engineering"。

第3章のひとこと

「できた」と言うのは、モデルではなく、あなたの検証ループ。
そして、採点者は別人にせよ。

── Claude の「できました！」を、額面で受け取らない。エビデンスを見せさせ、評価は分離する。これだけで、あなたの出荷物の信頼性は段違いになります。