顧客が「返金について確認したいです」と入力した。問い合わせAIは注文を特定し、返金処理用の refund_order Toolも使える。引数のorder_idも金額も正しい。IAM上の権限チェックも通る。
それでも、このToolを実行してはいけない。顧客が求めたのは返金状況の確認であって、新しい返金処理ではないからだ。ここで起きるのは権限不足でも入力エラーでもない。「技術的には実行可能だが、今この場面で実行する根拠がない」という失敗である。
Agentに業務Toolを渡すとき、Identityと最小権限だけで設計を閉じると、この差を拾えない。必要なのは、AgentがActionを提案した後、実際の副作用が発生する前に置くRuntime Policy Gateだ。
「呼べる」と「今、呼ぶべき」は別の判定
認可が答えるのは、「この主体はrefund_orderを呼び出せるか」だ。一方、Runtime Governanceが答えるのは、「観測された顧客意図、注文状態、確認の有無、直前までの行動を踏まえて、この呼び出しを今許すか」である。前者は比較的静的だが、後者は毎回変わる。
返金Toolなら、少なくとも要求意図が status_inquiry ではなく refund_request であること、対象注文が返金可能であること、顧客が金額と対象を明示的に確認したことを突き合わせたい。モデルが「返金だと思う」と答えた確信度だけを根拠にせず、業務側が読めるPolicyとして外に出す。
Policy Gateに渡したい最小のDecision Envelope
Agentの自由文の推論をそのまま判定材料にするより、実行候補と根拠を構造化して渡す方が扱いやすい。例えば次の形なら、なぜ止まったかも後から説明できる。
{
"proposed_action": "refund_order",
"observed_intent": "refund_status_inquiry",
"intent_evidence": ["返金について確認したい"],
"resource_state": "REFUND_PENDING",
"confirmation": "none",
"policy": {
"required_intent": "refund_request",
"explicit_confirmation": true
},
"decision": "BLOCK_AND_CLARIFY"
}
ここでのdecisionは、ALLOW / REQUIRE_CONFIRMATION / BLOCK / ESCALATE程度から始められる。大切なのは、Policy GateがToolの外側にあり、Agent自身が「問題ない」と判断しただけでは迂回できないことだ。Policyのバージョンも記録しておけば、ルール変更後に同じ事象を再検証できる。
単発では正常でも、連続すると異常になる
もう一つ見落としやすいのが行動の並びだ。1回の住所変更、1回の注文照会、1回の返金は、それぞれ許可されていても、短時間に同じ顧客へ書き込みが集中したり、複数回の少額返金が積み上がったりすれば止めるべきかもしれない。
そのためRuntime Checkは単発のTool Callだけでなく、一定時間内の呼び出し回数、同一Entityへの書き込み速度、累積金額、通常と異なるAction列も見る。異常検知はPolicy Gateの代わりではなく、個々の合法な操作から生まれる不自然なパターンを補う役割になる。
Google Developers Blogが2026年9月15日に公開したZero-Trust Agentの実装例でも、Tool Callを顧客意図と業務ルールに照合するSemantic Governanceと、複数Turnにまたがる異常行動の監視を分けている。ポイントは製品名より、実行直前の判断をAgentコードの外側で強制するという構造だと思う。
設計上の境界
すべての処理を重い審査に通す必要はない。読み取り専用の配送状況照会は軽い検査、住所変更は明示確認、返金は金額と理由に応じて承認、人にしか認めない操作は常にBLOCK、とリスク別にGateを変える。Runtime Governanceを一つの万能判定モデルにすると、そこが新しい不透明点になる。決定的に書ける上限額や状態条件はコードで、曖昧な意図対応は意味的判定で、人が必要な境界は承認に残す方が実装しやすい。
最小権限だけでは、安全な実行にならない
Agentの能力が上がるほど、設計の中心は「Toolを持たせるか」から「その瞬間の意図と文脈で実行を許すか」へ移る。Udeskに関わる企業カスタマーサポートの現場でも、AIがToolを呼べることより、いつ、何を根拠に呼ぶかを制御できることの方が実運用では重要になる。
AgentがすでにTool権限を持っている場合、皆さんは認可だけで実行させますか。それとも「現在の意図がこのActionを十分に支持しているか」を別レイヤーで確認しますか。