AIエージェントをエンタープライズシステムに組み込むプラクティス 【二重トラック検証】 💡 LLMの出力を「信じる」のではなく「検証する」。生成と検証を別トラックに分離することで、ハルシネーションを構造的に捕捉します。 🔥 解決する課題 - 事実と異なる情報がそのまま顧客や経営層に伝わる - 存在しない文書・条項・判例が引用される（捏造引用） - LLMが数値計算を誤り、財務レポートや見積もりに反映される - 出典が示されない根拠なき主張が信頼性を毀損する 🏗️ 提案パターン エージェントの「生成」とは独立した決定論的な検証トラックを設けます。数値検証では信頼ソース（DB/API）から再計算しエージェント出力と突合。引用検証では引用が実在すること、引用箇所が主張と一致することをプログラムで照合します。アクション検証ではパラメータをスキーマ＋ビジネスルールで事前チェック。不一致が検出された場合は棄却・再試行・人間エスカレーションのいずれかで対応します。 ✅ 選定条件 - 向き：数値・事実・引用の正確性が重要な業務（財務・法務・分析・サポート） - 不向き：創造的・主観的な出力で検証基準が定義できない領域 ⚠️ 落とし穴 - 検証器自体の精度が低いと偽陽性が多発し、業務フローが詰まる - 事前検証はレイテンシを増やすため、情報提供のみなら事後検証を検討する - 検証対象を「全出力」にすると処理コストが膨大になるため、リスクに応じた対象選定が重要 🛠️ 実装方針 1. 数値検証では、エージェント出力の数値をSalesforce API等の信頼ソースから再計算するPythonスクリプトを用意し、差分を自動突合します 2. 引用検証（grounding）には、RAGのチャンク検索結果と引用箇所の意味的一致をembedding類似度で照合する仕組みを構築します 3. アクション検証では、出力パラメータをJSONスキーマ＋ビジネスルールエンジン（OPA等）で事前バリデーションします 4. 不一致検出時のハンドリングを「棄却→再試行（最大2回）→人間エスカレーション」のフローとしてTemporalワークフローに組み込みます 5. 検証対象はリスクレベルで選別し、財務・法務は全件検証、情報提供はサンプリング検証とする運用ルールを設定します #AIエージェント# #エンタープライズアーキテクチャ#