F-9: インライン検証（block）vs 事後・標本検証¶

この相反は何か¶

エージェントの出力を検証するタイミングとして、出力が生成された直後にリアルタイムで全件検証し、不適格ならブロックする（インライン検証）か、出力をまず通過させ、事後に標本抽出して検証する（事後・標本検証）かという二者択一です。これは品質保証とレイテンシのトレードオフに関する根本的な設計判断です。

この選択が排他的として扱われる理由は、検証のタイミングがシステムの応答性と安全性を正反対の方向に引っ張るためです。インライン検証は出力が利用者に届く前に不適格なものを遮断できますが、検証処理分のレイテンシが加算されます。事後検証はレイテンシに影響しませんが、不適格な出力がそのまま利用者に届きます。この違いは [failure_cost]（悪い出力が届くコスト）と [latency_budget]（許容レイテンシ）のどちらを優先するかに帰着します。

AIエージェント固有の事情として、LLMの出力は確率的で非決定論的（F3）であり、ハルシネーション（F4）を含みえます。従来のAPIでは出力のスキーマ検証だけで品質を担保できましたが、エージェントの出力は意味的な正しさ（事実性、有害性、ポリシー準拠）まで検証する必要があり、検証自体がLLM呼び出しを含む高コスト処理になりえます。検証のコストとレイテンシが無視できないため、この相反がアーキテクチャレベルの判断として浮上します。

選択肢A：インライン検証（block）¶

エージェントの出力が生成されるたびに、即座に検証を実行します。検証に失敗した出力はブロックされ、利用者には届きません。代わりにリトライ、フォールバック応答、または人間へのエスカレーションが行われます。

インライン検証の最大の利点は安全性の保証です。不適格な出力（有害コンテンツ、個人情報の漏洩、事実誤認、ポリシー違反）が利用者に届くことがありません。[failure_cost] が高い環境（金融アドバイス、医療情報、法務文書、外部公開コンテンツ）では、この保証が不可欠です。

検証の種類は段階的に構成されます。

構造的検証（低コスト・低レイテンシ）：JSONスキーマ検証、値域チェック、正規表現によるPII検出。概ね数ミリ秒で完了します。
ルールベース検証（中コスト）：ポリシーエンジン（OPA/Rego等）によるビジネスルールチェック。概ね10〜50ミリ秒で完了します。
意味的検証（高コスト・高レイテンシ）：別のLLMによる事実性チェック・有害性判定。数百ミリ秒〜数秒を要します。

弱点はレイテンシの加算です。特に意味的検証を含む場合、検証だけでLLM呼び出し1回分のコストとレイテンシが加算されます。[latency_budget] が厳しい環境では、インライン検証が許容できないケースがあります。また、検証の偽陽性（正常な出力をブロックしてしまう）が高いと、リトライの連鎖やフォールバックの多発でUXが悪化します。

選択肢B：事後・標本検証¶

出力はまず利用者に届けられ、検証は事後にバッチ処理または標本抽出で行います。全件をリアルタイムで検証する代わりに、一定割合（概ね5〜10%）の標本を抽出して品質を監視します。問題が検出されたらアラートを発火し、根本原因の修正（プロンプト調整、ガードレール追加）を行います。

事後検証の最大の利点はレイテンシへの影響ゼロです。出力の返却パスに検証処理が挟まらないため、[latency_budget] が厳しい環境でも品質監視を維持できます。検証処理をオフピーク時のバッチで実行すれば、計算リソースの効率も高くなります。

もう一つの利点は検証の深さです。リアルタイムの制約がないため、時間をかけた詳細な検証（複数のLLM Judgeによるクロスチェック、人間レビュー、外部データソースとの照合）が可能です。標本に対して徹底的に検証することで、問題のパターンを発見し、プロンプトやガードレールの改善にフィードバックできます。

弱点は不適格な出力が届くリスクです。検証は事後であるため、ハルシネーション、有害コンテンツ、ポリシー違反を含む出力が利用者に表示される期間が存在します。[failure_cost] が高い場合、この「漏洩期間」が許容できません。また、標本抽出では全件をカバーしないため、低頻度だが高インパクトな問題を見逃すリスクがあります。

事後検証で問題を検出しても、すでに届いた出力を取り消すことが困難な場合があります（メール送信、外部API呼び出し、ユーザーへの表示済みコンテンツ）。

選定基準¶

選定は [failure_cost] と [latency_budget] の2つの駆動変数で判定します。

[failure_cost]（悪い出力が届くコスト）が第一の判定軸です。

failure_cost	判定
高：法的リスク、金銭損失、安全上の問題、信頼毀損	インライン検証
中：UX悪化、手動修正のコスト	高リスク経路のみインライン、他は事後
低：内部ツール、ドラフト生成、探索的出力	事後・標本検証

[latency_budget]（許容レイテンシ）が第二の判定軸です。

latency_budget	判定
極めて短い（概ね200ms以下）	インライン検証は構造的検証のみ、意味的検証は事後
標準（1〜10秒）	インライン検証の全層を適用可能
緩い（30秒以上、バッチ）	インライン検証を全件適用し、さらに事後で深い検証を追加

判定マトリクス：

	latency_budget 短い	latency_budget 標準	latency_budget 緩い
failure_cost 高	構造的検証のみインライン＋即時事後検証	全層インライン	全層インライン＋事後深堀
failure_cost 中	事後・標本	高リスク経路のみインライン	インライン
failure_cost 低	事後・標本	事後・標本	事後・標本

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

デフォルト：高リスク経路はインライン、低リスク経路は事後・標本です。すべての出力を同じ厳格さで検証するのではなく、経路ごとの [failure_cost] に応じて検証の深さとタイミングを変えます。外部公開コンテンツや副作用を伴う操作の出力はインライン、内部ツールやドラフト生成の出力は標本検証で十分です。

ハイブリッド：インライン（構造的＋ルールベース）＋事後（意味的深堀）の二層構造が定石です。構造的検証とルールベース検証はレイテンシへの影響が小さいため、全件インラインで実行します。意味的検証（事実性チェック、LLM Judge）はコストとレイテンシが大きいため、高リスク経路のみインライン、他は事後の標本検証で実行します。E3 入出力ガードレールがこの二層構造を具体化したパターンです。

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

インライン検証を選ぶべきだったのに事後検証を選んだ場合：

ハルシネーションを含む回答が顧客に届き、信頼性が毀損されます。特に金融・医療・法務の領域で深刻です。
個人情報を含む出力がフィルタリングされずに外部に漏洩し、コンプライアンス違反が発生します。
ポリシー違反の出力が発見されるのが事後のバッチ処理時であり、発見までに数時間〜数日のラグがあります。
標本抽出の対象外だった出力に重大な問題が含まれており、ユーザーからの苦情で初めて発覚します。

事後検証を選ぶべきだったのにインライン検証を選んだ場合：

検証レイテンシにより、ユーザー体験が「もっさり」します。特に意味的検証を全件に適用した場合に顕著です。
検証の偽陽性が高く、正常な出力がブロックされてリトライが頻発し、ユーザーへの応答が大幅に遅延します。
検証にLLMを使っている場合、検証自体のコストが本体のLLM呼び出しに匹敵し、コストが実質2倍になります。
[failure_cost] が低い内部ツールの出力にまで全件検証が適用され、開発者のイテレーション速度が低下します。