この記事で扱うこと
AIエージェントが業務システムに直接アクセスする時代、「間違った操作を実行される前に止める」 仕組みが不可欠です。本記事では、以下の3つの制御レイヤをシステム設計・API・権限・監査・運用の観点から解説します。
- ランタイムガードレール：入力・コンテキスト取得・ツール呼び出し・アクション実行・出力の5段階で動作を遮断する仕組み
- ポリシーエンジン：アクセス可否・承認要否を動的に判断するルール／分類器の実装パターン
- 人間承認ワークフロー：全件承認ではなくリスクベースで選択的に介入する設計
なぜ「出力フィルタ」だけでは不十分か
多くのチームが最初にハマる誤解は、「ガードレール＝モデルの出力をチェックするフィルタ」 という認識です。チャットボットならそれで十分かもしれません。しかし、エージェントがツールを呼び出し、データベースを更新し、外部APIに書き込みを行うシステムでは、出力フィルタだけでは手遅れです。
エージェントがすでに「見てはいけないドキュメントを取得した」「実行してはいけないツールを呼び出した」「元に戻せないトランザクションを確定した」——その後に出力をフィルタしても、被害は防げません。
実務では、以下の5つの制御ポイントを設計する必要があります。
1. 入力チェック
ユーザーやトリガーイベントの意図が、エージェントの利用範囲内かを判定します。たとえば購買発注のエージェントであれば、ユーザーが直接発注を作成しようとしているのか、それとも適切な稟議フローを経ているのかを確認します。
2. コンテキスト取得制御
エージェントが参照できるドキュメントやデータを制限します。財務エージェントは関連する会計基準を取得できますが、他部門の機密メモにはアクセスさせません。カスタマーサポートエージェントは現在の顧客のチケット履歴のみ取得可能で、類似度だけで他顧客データを引っ張ってこないようにします。
3. ツールアクセス制御
利用可能なツールを状況に応じて制限します。IT運用エージェントは診断ツールやチケット作成は許可しますが、本番環境の変更コマンドは実行させません。カスタマーオペレーションエージェントは権限確認や返金ドラフトは作成できますが、閾値を超える返金の実行はブロックします。
4. アクション実行制御（最重要）
ビジネス状態を変更する操作がここに該当します。仕入先登録、仕訳入力、与信限度額変更、支払ブロック解除、インシデントクローズ——これらはすべて「実行」の制御対象です。企業は「参照」「推奨」「ドラフト」「実行」を明確に区別し、実行には必ずガードをかけます。
5. 出力フィルタ
上記4つを通過した後の最終チェックです。データ漏洩防止、適切なトーン、根拠に基づく応答であることの確認を行います。ただし、これはあくまで最終防衛線であり、主要なガードレールではありません。
ポリシーエンジン：権限判断のランタイム中枢
ガードレールが制御ポイントだとすれば、ポリシーエンジンは各ポイントで「許可/拒否/エスカレーション/承認待ち」をリアルタイムに判断するコンポーネントです。
ポリシーエンジンがなければ、制御ロジックはプロンプト、アプリケーションコード、ツール設定、チームの慣習に散在し、一貫性と監査性を失います。
判断に必要なコンテキスト
- エージェントのロールと委任された権限
- ビジネスオブジェクトの種類（仕入先、請求書、発注、チケット、契約、従業員データ）
- トランザクション金額や重要度
- リスクレベル（取消可能か、複数システムに影響するか）
- 規制・コンプライアンス要件
実装パターン：決定論的ルール + モデルベース分類器
決定論的ルールは、明確で固定的な条件に適しています。
- 金額が閾値を超えたら拒否
- 特定の仕入先カテゴリは承認必須
- 深夜帯の本番変更は禁止
- 機密データへのアクセスは常に拒否
監査・テスト・説明が容易ですが、ビジネスコンテキストが多様な場合にルールが爆発します。
モデルベース分類器は、曖昧な状況判断に使います。
- リクエストの機密性スコア
- ケースのリスクレベル
- 不正の可能性
- ユーザー意図がスコープ外かどうか
柔軟ですが説明性に課題があり、定期的な評価と更新が必要です。高リスクアクションの唯一の制御にしてはいけません。
推奨パターンは組み合わせです。分類器でリスクシグナルを検出し、決定論的ルールで最終判断を下します。カスタマーオペレーションの例：
- 分類器がケースを「高リスク」または「紛争可能性あり」とフラグ
- 決定論的ルールが「高リスクケース or 金額¥50,000以上 → 承認必須」と判断
監査証跡の必須要件
すべてのポリシー判断は以下の情報を記録します。
- 評価したポリシー
- 判断に使ったコンテキスト
- 結果（許可/拒否/エスカレーション/承認待ち）
- 判断時刻
「システムが拒否したから」では監査に耐えません。「ポリシーXに基づき、金額¥1,200,000が閾値¥1,000,000を超過したため承認フローにエスカレーション」と説明できなければなりません。
人間承認：全件チェックは悪手
「人間がすべて確認する」のは、エージェント導入の価値を半減させます。必要なのはリスクベースの選択的承認です。
承認が必要なケース
- 重要度閾値を超えるトランザクション
- マスタデータの変更
- 従業員の権利に影響する判断
- 紛争リスクのある顧客対応
- 高リスクの本番変更
- 専門的判断を要する意思決定
承認ワークフローの設計ミス
最も多い失敗は、「エージェントがアクションXを推奨。承認しますか？」 という通知だけを送ることです。レビューアは困惑し、複数システムを開いて確認する羽目になり、結局疲弊して盲目的に承認します。
健全な承認ワークフローが提供すべき情報
- エージェントの推奨内容
- 判断に使ったエビデンス
- 関連ポリシー
- 主要リスク
- 信頼度またはエスカレーション理由
- 代替案（ある場合）
例：返金承認リクエストには、単なる金額だけでなく、顧客履歴、返金理由、適用可能な権利、類似ケースの発生頻度、不正シグナル、なぜ自動実行しなかったかの理由を含めます。
トレードオフ：承認過多の弊害
承認ケースが多すぎると、以下の問題が発生します。
- サイクルタイムの悪化
- 承認者がボトルネックに
- ユーザーの信頼低下
- エージェントが単なる「キュー生成マシン」に
リスク階層に基づいた設計が重要です。
| リスクレベル | 制御方式 |
|---|---|
| 低 | 自動実行＋モニタリング |
| 中 | 自動実行＋事後レビュー／サンプリング |
| 高 | 承認必須 |
| 最高 | 人間主導＋エージェント補助 |
エスカレーションとロールバック：止める勇気
優れたエージェントは「いつ行動するか」だけでなく「いつ止めるか」を知っています。以下の状況ではエスカレーションが必要です。
- 低信頼度
- データソース間の矛盾
- ポリシーの曖昧さ
- ツール結果の不整合
- 定義されたスコープ外の要求
このときの正しい振る舞いは「何度も試行して成功させる」ではなく、「停止し、理由を説明し、人間または別ワークフローに引き継ぐ」です。
ロールバック／補償パターン
アクションが誤っていた場合の回復手段も設計しておきます。
- ロールバック：システムが直接的な取消しをサポートしている場合（例：ステータス変更の巻き戻し）
- 補償アクション：直接取消しが不可能な場合の代替操作（例：誤った支払いに対する返金処理）
- 手動リカバリ：複雑なケース向けの明確な引き継ぎパス、インシデント記録、ポリシーへのフィードバックループ
ロールバック手段がないと、組織は「自律性を恐れて全く与えない」か「安全網なしで過信する」の両極端に陥ります。
実践的な自律性マトリックス
最後に、ユースケースごとに自律性レベルを定義するマトリックスを紹介します。
| レベル | 動作 | 適した領域 |
|---|---|---|
| Assist | コンテキスト提供、要約、インサイト提示のみ | 曖昧な領域、不安定なデータ、人間の判断が不可欠なプロセス |
| Draft | 推奨・ドキュメント・アクション案を作成するが、人間が実行 | 変革初期、高コントロール要求、実行権限なしで加速したい領域 |
| Execute with Approval | 承認後にアクションを実行 | 高額取引、規制対象、正式な証跡が必要な領域 |
| Execute with Monitoring | 明確なポリシー範囲内で自動実行＋監視・サンプリング | 高頻度・低〜中リスク・取消可能なアクション、ポリシーが成熟した領域 |
このマトリックスにより、「すぐに全自律性を与える」 と 「ずっとAssistモードに留める」 の両極端を避けられます。
まとめ：あなたのエージェントは誰が止めるのか
冒頭のシナリオに戻ります。財務エージェントが重要な調整仕訳を実行しようとしたとき、あなたのシステムはそれを止められますか？
- 入力チェックで意図を検証したか
- コンテキスト取得を適切に制限したか
- ツールアクセスを状況に応じて制御したか
- アクション実行前にポリシーエンジンが判断したか
- 必要な場合は人間承認を経由したか
- 誤った場合のロールバック手段はあるか
これらがすべて「Yes」なら、あなたのシステムは本番投入の準備ができています。