# AIエージェント開発の意思決定ポイント 🎯 ポイント エージェントの出力、全件チェックしてから返すか、まず返してから抜き取り検査するか？ 「安全のために全部チェックしよう」は理想的ですが、LLMで意味検証すると1リクエストあたりのコストとレイテンシが実質2倍になります。逆に「事後で十分」と判断した結果、ハルシネーションがユーザーに届いてインシデントになることも。このバランスの取り方を整理しましょう。 📋 概要 AIエージェントの出力を検証するタイミングに関する設計判断です。インライン検証は出力が生成された直後にリアルタイムで全件検証し、不適格ならブロックします。事後・標本検証は出力をまず通過させ、事後にバッチまたは標本抽出で検証します。品質保証とレイテンシのトレードオフであり、「悪い出力が届くコスト」と「許容レイテンシ」のどちらを優先するかに帰着します。 🔍 意思決定のポイント 第一の判定軸は「悪い出力が届いたときのコスト」です。 📌 法的リスク・金銭損失・安全上の問題がある → インライン検証必須。金融アドバイス、医療情報、法務文書、外部公開コンテンツなど、不適格な出力が届くことが許されない場面では全件ブロック型が不可欠。 📌 UX悪化や手動修正が必要になる程度 → 高リスク経路のみインライン、残りは事後。すべてを同じ厳格さで検証する必要はありません。 📌 内部ツール、ドラフト生成、探索的出力 → 事後・標本検証で十分。5〜10%の標本を抽出して品質を監視し、問題パターンを発見してプロンプト改善にフィードバック。 第二の判定軸は「許容レイテンシ」です。 📌 200ms以下の応答が必要 → インライン検証は構造的検証（スキーマ検証、値域チェック）のみ。意味的検証は事後に回す。 📌 1〜10秒の標準的なレイテンシ → インライン検証の全層（構造的＋ルールベース＋意味的）を適用可能。 📌 30秒以上のバッチ処理 → インラインで全件検証し、さらに事後で深い検証を追加する余裕あり。 💡 要点と詳細 🔹 インライン検証は3段階で構成するのが実務的です。第1層：構造的検証（JSONスキーマ、PII検出）は数ミリ秒。第2層：ルールベース検証（ポリシーエンジン）は10〜50ミリ秒。第3層：意味的検証（別LLMによる事実性チェック）は数百ミリ秒〜数秒。すべての経路に第3層まで適用する必要はありません。 🔹 事後検証の隠れた強みは「検証の深さ」です。リアルタイムの制約がないため、複数のLLM Judgeによるクロスチェック、人間レビュー、外部データソースとの照合など、時間をかけた徹底的な検証が可能。標本から問題パターンを発見し、ガードレールの改善に繋げるフィードバックループが本当の価値です。 🔹 事後検証の致命的な弱点：不適格な出力が届いた後では取り消せない場合がある。メール送信、外部API呼び出し、ユーザーへの表示済みコンテンツは巻き戻せません。 ⚖️ トレードオフ インライン検証は安全性を保証する代わりにレイテンシとコストが加算されます。意味的検証まで全件に適用するとコストが実質2倍に。偽陽性（正常な出力のブロック）が高いとリトライの連鎖でUXも悪化します。事後検証はレイテンシ影響ゼロで深い検証が可能な代わりに、問題のある出力がユーザーに届く「漏洩期間」が存在します。 🏆 定石は「高リスク経路はインライン、低リスク経路は事後・標本」のハイブリッド。さらに実務では「インライン（構造的＋ルールベース）＋事後（意味的深堀）」の二層構造が効果的。構造的検証はレイテンシ影響が小さいため全件インラインで実行し、コストの高い意味的検証は高リスク経路のみインライン、残りは事後標本で対応します。 🛠️ ユースケース 🏥 医療情報チャットボット → 全件インライン検証。事実性チェック（別LLM）を含む3層すべてを適用。ハルシネーションが患者に届くコストは検証レイテンシの比ではない。 💬 社内Slackボット → 事後・標本検証。内部利用で多少の誤りは許容される。標本から問題パターンを発見してプロンプトを改善するサイクルが重要。 🛒 ECサイトの商品説明生成 → ハイブリッド。構造的検証（価格の値域、必須項目の存在）はインライン、表現の適切性は事後検証。 📧 自動メール返信 → インライン検証。送信済みメールは取り消せない不可逆な副作用。PII漏洩やポリシー違反の検出は送信前に行う。 #AIエージェント# #ソフトウェアアーキテクチャ#