F-10: 生成と検証を同一 vs 別系統¶

この相反は何か¶

AI エージェントが何かを生成した後、その出力を検証する工程が必要になります。このとき「生成した系統（モデル・プロンプト・コンテキスト）と同じ系統で検証するか、それとも独立した別の系統で検証するか」という二択が F-10 の相反です。

この選択が二者択一になる理由は、検証系統の独立性が「ある／ない」で質的に異なるためです。同一 LLM が自分の出力を振り返る self-reflection は、生成時と同じバイアス・知識の限界・ハルシネーション傾向をそのまま引き継ぎます。一方、別系統（別モデル、別プロンプト、決定論的コード検証など）で検証すれば、生成時のバイアスから構造的に切り離されます。中間はありません---検証系統が生成系統と同じ重みを共有しているか否かは、0 か 1 かの区分です。

AI エージェント特有の問題として、LLM は自分の生成物に対して肯定的に評価する自己確認バイアスを持つことが知られています。従来のソフトウェアにおける「テストコードは実装者と別の人が書く」という原則と同根ですが、LLM の場合はバイアスがより体系的で予測困難であるため、この選択の影響がより大きくなります。

選択肢A：同一系統で検証¶

同一系統検証とは、生成に使った LLM（同一モデル・同一プロンプトチェーン）にそのまま「この出力は正しいか」「改善できるか」と問いかける方式です。いわゆる self-reflection や chain-of-thought による自己検証がこれに当たります。

この方式の最大の強みは実装の単純さとコストの低さです。追加のモデルデプロイや別プロンプトの設計が不要で、元のコンテキストをそのまま活用できるため、検証に必要な情報を再度与える手間がかかりません。レイテンシの追加も最小限です。

また、生成コンテキストの全体を把握しているため、「なぜこう生成したか」の理由を踏まえた検証が可能です。別系統に検証を委ねると、生成時のコンテキストを完全に伝達するのが難しい場合があります。

ただし、致命的な弱点があります。LLM は自分の出力を「正しい」と判断する傾向が強く、特にハルシネーション（事実と異なる内容の生成）は生成時に「正しい」と確信して出力しているため、同じモデルに確認させても見抜けません。これは人間が自分の文章を校正するときにタイプミスを見落としやすいのと似ていますが、LLM の場合はより体系的にこの盲点が現れます。

選択肢B：別系統で検証¶

別系統検証とは、生成系とは異なるモデル、異なるプロンプト、あるいは決定論的なコード（正規表現、スキーマ検証、ルールエンジン、外部 API への事実照合など）で出力を検証する方式です。

この方式の最大の強みは自己確認バイアスの構造的排除です。生成モデルが持つバイアスと検証モデルのバイアスは独立しているため、両方が同じ方向に誤る確率は単独の誤り確率より大幅に低くなります。特に決定論的コードによる検証（JSON スキーマ検証、数値範囲チェック、外部データベースとの照合など）は確率的な誤りがゼロであり、最も信頼性が高い検証手段です。

また、検証専用に最適化できるという利点があります。生成には創造性や柔軟性が求められますが、検証には正確性と厳格性が求められます。これらは相反する要件であり、同一システムで両立させるよりも専用に設計する方が品質が上がります。たとえば、検証用モデルは temperature を極めて低く設定し、検証用プロンプトは「誤りを見つける」という批判的な姿勢に特化できます。

一方、コストとレイテンシが増加します。別モデルの推論コスト、あるいは決定論的検証コードの開発・保守コストが上乗せされます。また、生成時のコンテキスト全体を検証系統に渡す必要があるため、コンテキスト窓の消費量も増えます。さらに、検証系統自体の設計・運用が新たな複雑性を生みます。

選定基準¶

この相反の選定は主に [failure_cost] で決まります。

別系統を選ぶべき条件：

[failure_cost] が高い場合（金融、医療、法務、安全に関わる出力）。誤った出力がそのまま下流に流れると取り返しがつかない損害が生じるため、構造的にバイアスを排除する別系統検証が必要です。
事実性の検証が求められる場合。ハルシネーションの検出は同一モデルでは困難であり、外部知識ソースや決定論的コードとの照合が不可欠です。
[accountability] が高い場合。「なぜこの出力を正しいと判断したか」を第三者に説明する際、同一モデルの self-reflection では根拠として弱く、独立した検証系統の結果の方が説得力を持ちます。

同一系統で十分な条件：

[failure_cost] が低いカジュアルな対話やドラフト生成。多少の誤りが許容される場合、別系統検証のコストは見合いません。
[latency_budget] が極めて短い場合。別系統検証の追加レイテンシが許容できなければ、同一系統での簡易チェックに留めます。
[cost_sensitivity] が高く、検証にかけられるトークン予算が限られる場合。

デフォルトとハイブリッド¶

デフォルト：[failure_cost] が高い経路では別系統を選択します。低リスクな経路では同一系統の self-reflection で十分です。判断に迷ったら、出力が直接ユーザーに表示されるのか、下流のシステムに渡されるのかを基準にします。下流システムに渡る場合は別系統を推奨します。

ハイブリッド：同一系統で一次検証（self-reflection で明らかな誤りを修正）を行い、その後に別系統で最終検証を行う二段構成が実用的です。一次検証でフォーマットや論理的整合性の粗い問題を取り除き、別系統検証のコストを下げることができます。これは B6 Critic/Judge & Sampling-Aggregation パターンが体系化している構成です。

判断を誤ったときの症状¶

同一系統を選んだが別系統が必要だった場合の症状：

ハルシネーションが検証をすり抜けて本番に到達する。事後監査で「検証したはずなのに事実誤認が通過している」事例が繰り返し見つかります。
ユーザーや下流システムからのエラー報告が、エージェント内部の検証ログでは「正常」と記録されている不一致が増えます。
特定のカテゴリのエラー（数値の誤り、存在しないエンティティの参照など）が検証で一切検出されていないことに気づきます。

別系統を選んだが同一系統で十分だった場合の症状：

検証系統の運用コスト（モデル推論費用、検証コードの保守工数）が全体コストの大部分を占め、検出された実際のエラー数と見合っていません。
別系統検証の追加レイテンシにより、ユーザー体験が劣化しています。
検証系統と生成系統のコンテキスト伝達の不整合により、正しい出力が誤検知で棄却される割合が高くなっています。