同じ文脈は、同じ間違いを見逃す — 検証を別のセッションに出す

記事執筆時、執筆者が Claude に「次の段落を書いて」と依頼し、モデルが生成したテキストを同じセッション内で「間違いがないか確認して」と再度投げる。返ってくるのは「問題ありません」。それを信じて公開する。数日後、別の記事を書いている最中に矛盾に気づく。こういう失敗は、検証の丁寧さの問題ではない。セッションのコンテキストを共有している検証者には、内容の正誤以前に「検出できない誤りの類型」が存在する、というだけの話だ。

同じセッションにいると見落としやすい誤りは 4 つの類型に分かれる。第 1 は「別の成果物との横断矛盾」だ。記事 A で「利用上限は分かれている」と書き、同時期に書いた記事 B で「利用上限は 1 つのプール」と説明する。単体では筋が通るが、並べると反対のことを言っている。矛盾という事実は記事 A の外にしかないので、記事 A を何度読ませても到達しない。第 2 は「例示データに根拠がない」例だ。「検査ログ入力例として 37 パターン」と書いたが、この数字は実測に対応していない。同じセッションには「ここは例示」という了解が残っているので違和感が出ない。本文だけを持つ読者には実績値にしか読めない。第 3 は「前提が変わったのに前半が追随していない」ケースで、執筆途中に設計を精密化したとき、後半の新しい理解で前半の旧い表現を読み返さない。第 4 は「対象とする読者のリテラシーズレ」で、書き手にとって自明な用語が読者には自明でない。

解決策は検証を別セッションに出すことだ。渡すのは成果物と判定基準だけにして、作成経緯や著者の意図は渡さない。文脈を持たない検証者は、文脈を持つ者が見落とす矛盾を機械的に拾える。それは眼力の差ではなく、入力される情報の差であり、したがって事前に設計可能だ。中小企業が複数人で記事や営業資料を作るとき、最後の確認を別の人間、別のセッションに任せることの意味は、ここにある。ひとりでまわしている会社なら、別セッションはコスト無視で立てられる。