この記事で扱うこと

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」なら、あなたのシステムは本番投入の準備ができています。

参考

元記事: Your AI Agent Just Changed a Financial Record. Who Stopped It?