AIレビューは何を見つけるのか｜誤帰属と数値ドリフトの実録

生成と検証を別コンテキストに分ける設計は、理屈ではよく語られる。では実際に何を捕まえるのか。筆者はハブ記事12本を Claude Code で制作し、書き手とは別のレビュアーに全本を通した結果、出た blocker は2件だった。どちらも参照した根拠には忠実でありながら誤っており、真偽を問う検証では素通りして、参照経路を変えた検証だけが止められた誤りである。本稿はその実録である。

前提 — 書いた本人に採点させない

本文を書くエージェントと、それを検査するエージェントは分けてある。分離の設計理由はサブエージェントの役割分担で扱ったので、ここでは判定の形だけ見ておく。レビュアーの定義ファイルは、役割と合否条件を frontmatter の1行に持つ。

# .claude/agents/article-reviewer.md（frontmatter の description 実物）
記事ゲートのレビュー担当。writer とは別コンテキストで /write-article から spawn される。指摘は blocker / should / nice の3段階。blocker ゼロが合格条件。

指摘は3段階だが、合否を決めるのは blocker だけである。should と nice は残っていても合格しうる。検査の対象には原稿だけでなく「割当素材ファイル」が含まれ、各項目は「該当箇所を引用して指摘する」ことが求められる。レビュアーは書き手の要約を採点するのではなく、自分で素材まで降りる。この一点が、以下の2件を分けた。

実例1 — 事実なのに間違っている

1件目はサブエージェントの記事で出た。委譲の実録を書いた箇所で、書き手は次の趣旨を記していた。サブエージェントの完了報告を鵜呑みにせず、親セッション側で pytest を回して裏を取り、修正の再委譲ゼロで完了した——と。そしてこの実績を、LLM パイプラインの委譲の話として書いた。

素材は公開ツールの開発記録で、書かれている事柄はどれも記録に実在した。メインセッションの検証も原文と突き合わせ、「一致」と判定している。見落としだった。

別コンテキストのレビュアーは同じ記録を2セッション分読み直し、blocker を1件返した。「一発完了・修正委譲ゼロ」を記録しているのは別の委譲——Web 公開モジュール一式を任せた回——であり、記事が指す LLM パイプラインの委譲では、実際には一部モジュールの修正を再委譲していた、と。

文そのものは事実である。出来事としては起きている。間違っていたのは帰属だった。「その出来事は本当に起きたか」を問う検証は、この種の誤りを素通りする。どの委譲の話なのかという単位で原文に戻って初めて、食い違いが表に出る。修正は帰属の書き直しで、Web 公開モジュール一式の委譲として書き改めた。現在公開されているサブエージェントの記事の該当箇所が、その結果である。再レビューで実録との一致を確認し、合格とした。

実例2 — 参照した資料が古くなっていた

2件目は自作スキルの記事である。10本のスキルを扱う回で、本文に SKILL.md の行数の幅を書いた。上限は「76行まで」としていた。

出典は、前日に走査して作った素材インベントリの記録値である。メインセッションの検証もそのインベントリと照合し、「一致」と判定した。数字は確かに一致していた。参照先が同じなのだから、当然である。

レビュアーは現物のファイルを測り直した。すると、レビュー観点をまとめたスキル review-phase が、前日の走査のあとに76行から78行へ増えていた。本文の「76行まで」は、記録値とは一致し、現物とは一致しない状態になっていた。blocker である。

修正では10本すべてを現物で測り直し、実測値「2026-07-16 の実測で42〜78行」を本文に記した。あわせて、古くなっていた素材インベントリ側も現物基準に更新した。原稿だけ直してインベントリを残せば、次の記事が同じ穴に落ちるからだ。検証ログには、こう教訓を記録した。

数値は中間成果物でなく常に現物と照合する

参照した資料は、作られた時点では正しかった。誤っていたのは資料ではなく、資料が現物と同期しているという前提のほうである。そして生成側と検証側が同じ資料を見ている以上、両方が同じ穴に落ちるのは避けられなかった。

2件に共通するもの

表面上、2件はまるで違う。片方は帰属の誤り、片方は数値のずれである。だが検出のされ方は同じ構造だった。どちらも、生成側がたどった参照経路をなぞる検証では見つからない。

1件目でメイン検証がなぞったのは、照合の単位だった。書き手と同じく事実項目ごとに原文と突き合わせたため、どの項目も実在するという理由で一致と判定してしまった。2件目でなぞったのは資料そのもので、書き手が見た記録値を同じように見に行った。生成側と同じ見方をした瞬間に、生成側と同じ死角を引き継いでいる。

レビュアーが捕まえられたのは、経路を変えたからである。原文を「どの委譲の話か」という別の単位で読み直し、記録値ではなく現物を測り直した。生成と検証を分ける価値は、コンテキストが独立していること自体ではない。独立したコンテキストだからこそ、検証の経路を別に引ける点にある。

2件目の教訓は検証ログに残し、記事制作コマンドの検証手順にも「数値は記録値でなく現物を測り直す」と反映した。ログと規約の両方に残したから、次の記事にも効く。

よくある質問

blocker ゼロが続くなら、レビューは無駄ではないか。 出たのは12本中2件、残る10本はレビュー段階の blocker ゼロで通っている。何も返さない状態が続くのはエスカレーション規約と同じく、発動頻度は価値の指標にならない。効いたのは2件とも公開前に止まった点で、公開後なら原稿・本文断片・配信メタをまとめて直すことになる。

まとめ

生成と検証を分けて実際に捕まったのは、事実として正しいのに帰属が違う文と、正しい資料に由来するのに現物とずれた数値だった。どちらも真偽を問う検証は通り抜け、原文に別の単位で戻り、現物を測り直したときにだけ止まった。検証の独立とは、担当を分けることではなく経路を分けることである。12本分の検証記録をどう残し何を次の手順へ還元したかは、検証ログを扱う別記事で整理する。