# AIエージェントをエンタープライズシステムに組み込む意思決定ポイント # 事前 vs 事後検証｜Pre-verification vs Post-verification 🎯 ポイント エージェントの出力を「実行前にチェックする」か「実行後にチェックする」か、すべてに同じ方針を適用していませんか？ 不可逆な操作は事前検証が必須ですが、情報提供のみの操作にまで事前検証を課すとスループットが崩壊します。この分岐を副作用の可逆性と影響度で正しく設計しないと、安全性か速度のどちらかを不必要に犠牲にします🔑 📋 概要 事前検証は、エージェントの操作に不可逆な副作用がある場合に選びます。決済実行、契約締結、データ削除、本番デプロイなど、誤操作が金銭的損害・法的責任・ブランド毀損に直結するケースです。Workdayでの給与変更、Salesforceでの契約金額変更、Shopifyでの一括価格改定が典型例です。規制・コンプライアンスにより実行前承認が義務付けられている場合や、医療・金融・法律助言のように誤情報が許容されない場面でも事前検証は必須です。事後検証は、出力が情報提供のみで副作用がない場合、または副作用が可逆で取り消しが容易な場合に選びます。Slackでの情報要約、Notionでのドキュメント下書き生成、Jiraチケットの分類提案などが該当します📊 🔍 意思決定のポイント 判断フローは以下の通りです： 操作に副作用はあるか？ → なし（情報提供のみ）なら事後検証で十分 副作用は可逆か？ → 可逆なら事後検証＋自動ロールバックで対応可能 副作用は不可逆か？ → 不可逆なら事前検証が必須 影響範囲は？ → 1ユーザーに限定か全顧客に波及するかで事前検証の強度を調整 規制要件で事前承認が必須か？ → 金融取引・人事変更・医療関連は事前検証が義務 信頼度スコアを活用できるか？ → 閾値未満は事前検証、閾値以上は事後検証にルーティング⚡ 💡 要点と詳細 実務では事前と事後を組み合わせた二重トラック構成が標準的です： リスクレベルによる振り分け：操作のリスクを事前に分類し、高リスク操作（不可逆・高影響）は事前検証トラック、低リスク操作（情報提供・可逆）は事後検証トラックに自動ルーティングします。 段階的緩和：初期はすべての操作を事前検証し、信頼度が蓄積されたカテゴリから段階的に事後検証に移行します。品質を計測しながら閾値を調整するのがポイントです。 信頼度スコアの活用：エージェントの出力に信頼度スコアを付与し、閾値ベースで検証トラックを自動振り分けします。閾値は初期値を保守的に設定し、実測データで調整してください。 Zendeskの顧客対応を例にすると、回答ドラフトの生成は事後検証（サンプリングレビュー）、返金処理の実行は事前検証（人間の承認必須）という使い分けが合理的です🔄 ⚖️ トレードオフ 不可逆な操作を事後検証にするのは最も危険な設計ミスです。Shopifyで商品を一括削除した後に検証しても、復旧不能な事態からは戻れません😰 すべてを事前検証にするのも同様に問題です。情報検索の結果表示にまで人間の承認を求めると、エージェントの応答速度が数分に低下し、ユーザーが使わなくなります。 事後検証の仕組みが存在しないのも見落としがちです。事後検証トラックに振り分けたものの、実際にはレビューが行われず品質劣化に気づかないケース。サンプリング率と品質指標の閾値を必ず定義してください。 リスク分類が更新されないのも危険です。新たに追加された操作のリスクレベルが未定義のまま、デフォルト（事後検証）で動作してしまいます。新規ツール追加時にリスク分類を必須プロセスとしましょう⚠️ 🛠️ ユースケース カスタマーサポート（Zendesk）：顧客への回答ドラフト生成は事後検証（10%のサンプリングレビューで品質監視）。返金・クレジット処理は事前検証（金額に応じて承認者レベルを変動）。商品交換手配は事前検証（在庫確認→承認→実行の決定論ワークフロー）📚 人事システム（Workday）：従業員情報の検索・表示は事後検証（副作用なし）。給与変更・異動手続きは事前検証（規制要件により承認必須）。組織図変更は事前検証＋二重承認（影響範囲が広い）🛒 EC運営（Shopify）：商品情報の検索・分析は事後検証。在庫数量の微調整は事前検証（可逆だが即時影響あり）。一括価格変更・商品削除は事前検証＋ドライラン＋二重承認（不可逆・高影響）🔧 実践のコツ：「新しいツールやAPIを追加するたびにリスク分類を更新する」をチームの必須プロセスにしてください。分類されていない操作がデフォルトで事後検証に流れるのは、意図した設計ではなく単なる見落としです💪 #AIエージェント# #エンタープライズアーキテクチャ#