9月12日、Techstrong AIが「Your AI Agent Is Turning Exceptions Into Policy」と題した記事を公開した。この記事では、AIエージェントが過去の例外対応を誤ってポリシーとして解釈・適用してしまうリスクと、その設計上の対策について詳しく紹介されている。以下に、その内容を紹介する。
「例外の承認」が「ルール」に化ける瞬間
記事の冒頭で示される事例が問題の本質を端的に突いている。
決済システムの障害で顧客が締め切りに間に合わなかった。担当マネージャーは理由をケース履歴に記録したうえで、一度限りの例外として期限延長を承認した。
数ヶ月後、類似のリクエストを処理しているAIエージェントがそのレコードを見つける。エージェントの回答はこうだ：「弊社では期限の延長を認めています。」
記録された事実はすべて正しい。しかし答えは間違っている。
マネージャーが承認したのは例外だ。エージェントはそれをポリシーに変換した。
これはエンタープライズAIにおいて見落とされがちなリスクだと記事は指摘する。組織はエージェントが「どの文書を読めるか」「どのシステムを使えるか」に多くの時間を割く。しかしエージェントが見つけた判断をどう解釈すべきかにはほとんど注意が払われていない。
過去の業務記録には、正式なポリシーだけでなく、その場しのぎの回避策、好意的な対応、緊急承認、権限の異なる人物による判断が混在している。エージェントがすべての過去の行動を「再利用可能な判断」として同等に扱えば、組織は機械の速度で一貫して間違いを犯し続けることになる。
「取得できる」と「権限がある」は別物だ
記事が強調する原則はシンプルだ：ある判断を取得できることは、それを一般化する権限をエージェントに与えない。
人間であれば、トーンや人間関係、組織的な文脈から例外と通常運用を区別できる。「あの承認は停電時の対応だった」「あの料金免除は特定の交渉でのみ適用された」といった判断は、ベテランのオペレーターには暗黙知として存在する。
AIエージェントはそうした背景抜きに、「成功した結果を持つ関連レコード」を見つける。文脈が明示されていない限り、例外は有用な先例に見える。
4種類のコンテキスト分類が対策の起点
エージェントが業務履歴を安全に扱うために、記事は判断を以下の4種類に分類するよう提案する：
- Policy（ポリシー）：定められたスコープ内で適用可能な承認済みルール
- Procedure（手順）：そのポリシーを適用するための現行の方法
- Exception（例外）：特定の理由・ケース・期間に限り承認された逸脱
- Anecdote（事例）：背景情報にはなりえるが、権限を生まない過去の行動
デフォルトで再利用可能なのは Policy と現行の Procedure だけだ。Exception はエージェントが人間に確認を求める際の材料になりえる。Anecdote はケースの背景説明に使える。どちらも黙って意思決定のルールになってはいけない。
この分類はシステム全体の再構築を必要としない。顧客へのコミットメント、支払い変更、アクセス判断、契約解釈、安全措置、サービスレベルの例外など、重大な業務に影響しやすいレコードにメタデータを付与するところから始められる。
例外レコードに「封筒」を付ける
記事は例外レコードが保持すべき情報として「例外封筒（exception envelope）」という概念を提示する。封筒には以下を含める：
- 適用したケースまたはトランザクション
- 逸脱した元のポリシー
- 承認した人物または役割
- 逸脱の理由
- スコープ内のシステム・顧客・資産
- 開始条件と失効条件
- 類似ケースに新たな承認が必要かどうか
これによりエージェントは「類似の例外が支払いシステム障害時に承認されましたが、このケースには新たな判断が必要です」と応答できる。古い承認をポリシーとして提示する代わりに、確認を求める判断ができる。
特にエージェントが業務システムへの書き戻しを行う場合、この設計が重要になる。ラベルの不適切な例外が取得・実行され、「成功したケース」として記録されれば、繰り返しによって誤った先例がより強固に見えるようになるという悪循環が生まれる。
「正しく見える間違い」をテストする
記事は通常のAIテストが見落とす問題を指摘する。多くのテストは明らかな失敗（ハルシネーション、ツール呼び出しの破損、誤分類）を探す。しかし危険なのは「流暢で、実在するレコードに基づいていて、しかし権限のない回答」だ。
記事が推奨するテストケースはこうだ：
- 古い例外と現在のポリシーが矛盾する
- 異なる権限を持つ人物が類似ケースを承認している
- 緊急の回避策が良い結果を生んだ
- 繰り返すべきでない顧客への譲歩が存在する
- ローカルな慣行とエンタープライズのルールが衝突する
測定指標として、「未承認先例率」（過去の例外を再利用可能なルールとして扱ったテストケースの割合）と「ポリシーソース比率」（重要な回答が業務履歴だけでなく現行の権威あるソースに基づいている割合）を使うよう提案する。
これらの指標は、一般的な精度スコアが隠してしまう問題を表面化させる。
記事は最後にNIST AIリスク管理フレームワークを引き合いに出し、「コンテキストとはレコードが何を述べているかだけでなく、そのレコードが今どんな権限を持っているかである」と締める。エージェントは何が起きたかを記憶すべきだが、一度起きたことが次も起きるべきことだと仮定してはならない。
詳細はYour AI Agent Is Turning Exceptions Into Policyを参照していただきたい。
