「AIエージェントに何を任せていいか」の線引き——リスク階層と承認ゲートで事故を防ぐ実務設計

実務ノウハウ・事例 のアイキャッチ

AIエージェントに業務を任せる範囲が広がるにつれ、「どこまで自動化してよいか」の線引きが現場の悩みになっている。海外では、行動のリスクに応じて自律度を4段階に分け、承認が必要な場面だけ人を挟む「リスク階層×承認ゲート」という設計が定着しつつある。航空会社の予約変更エージェントの事例やMCPの権限制御ツールを手がかりに、明日から使える考え方を整理する。

AIエージェントの権限管理と承認ゲートのイメージイラスト

なぜ今、「任せていい範囲」の設計が必要なのか

AIエージェントの導入企業を対象にしたAvePointの調査によれば、95.5%の組織がエージェント関連のセキュリティリスクを経験した後に対策を講じたという。人による監視を強めているのは「エージェントの性能が落ちたから」ではなく、逆に速く・賢くなりすぎて、ミスが誰にも気づかれないまま業務に伝播してしまうからだ。

一方で組織側の備えは追いついていない。Liminalのガバナンスガイドが引用するDeloitteの2026年調査では、成熟したガバナンス体制を持つ組織はわずか20%にとどまる。「現場のリスク」と「運用の備え」のギャップが、いまエージェント活用のボトルネックになっている。

4段階のリスク階層で自律度を決める

MindStudioが提案する4段階フレームワークやAWSの「Agentic AI Security Scoping Matrix」など、複数の実務フレームワークに共通するのは「行動そのものではなく、行動のリスクと結果の重大さで階層分けする」考え方だ。

階層 自律度 典型的な運用
Tier 1 完全監督下 出力はすべて人が確認してから実行(下書き作成、要約など)
Tier 2 制約付き自律 事前承認済みの行動だけ自動実行、範囲外はエスカレーション
Tier 3 広い自律 定義済みの境界内で自律実行、継続的モニタリングで担保
Tier 4 重要リスク 顧客データ変更・一定額以上の金銭コミットなど、承認ゲート必須

行動を階層に振り分ける際の物差しとして使われるのが「Risk-Reversibility-Impact(RRI)」、つまり危害のリスク・取り消しやすさ・事業インパクトの3軸だ。支払いや契約のような取り消せない行動は事前承認(human-in-the-loop)、件数が多く取り消し可能な定型作業は事後の非同期モニタリング(human-on-the-loop)というように、行動の性質によって人の関わり方を変える。

事例:航空会社の予約変更エージェントに見る3つの監督モデルの併存

ある航空会社の欠航対応エージェントの事例が分かりやすい。多くの乗客に対しては、エージェントが自律的に振替便を探し予約変更・確認通知まで完結させる(human-out-of-the-loop)。しかし国際線の乗り継ぎがあるファーストクラス会員など、規約の境界に触れる乗客を検知すると、エージェントは処理を止めて状況を上級担当者に引き継ぐ(human-in-the-loop)。全体としては人がログを事後確認する体制(human-on-the-loop)も並走する。Galileoの解説記事はこれを「3つの監督モデルが1つのワークフローに共存する」設計として紹介している。1つのエージェントに単一の承認ルールを適用するのではなく、行動ごとに監督の強さを変える発想が実務では有効だ。

サーバーラックが並ぶデータセンターの様子
Photo: Robert Scoble / CC BY 2.0(Openverse経由)

技術面の実装:3層のガードレールとMCPの権限制御

Atlanのガードレール・チェックリストは、実装を3層に分けて考えることを勧めている。

  • コンテキスト層:MCP(Model Context Protocol)サーバーにRBAC(ロールベースアクセス制御)を適用し、エージェントのコンテキストウィンドウに入るデータそのものを制限する
  • ツール呼び出し層:エージェントごとに呼び出せるツールの許可リストを明示し、レート制限とサンドボックスで実行範囲を絞る
  • 監査層:どのエージェントが・どのデータにアクセスし・何を出力したかをすべてログに残す

具体的なツールも増えてきた。MCP RBACの解説では、エージェントやAPIキー単位ではなく「ツール単位」の狭い許可リストに紐づける方式が紹介されている。またGitHubは2026年8月、管理者向けにallowedMcpServersとdeniedMcpServersという設定項目を追加し、組織内でCopilotクライアントが接続できるMCPサーバーを明示的に制御できるようにした。「まず何でも接続できる状態」から「まず全部遮断し、必要なものだけ許可する」方向への転換が進んでいる。

規制の後押し:EU AI Actの施行

2026年8月に施行されたEU AI Actは、医療・与信・雇用・重要インフラ領域で稼働するエージェント型AIを「高リスク」として扱い、来歴を追跡できる監査可能性と人間による監督を義務付けている。域外企業であっても、これらの領域でAIエージェントを使うなら無関係ではいられない。規制対応としてではなく、事故を未然に防ぐ実務上の必要性として、階層設計とログ整備に取り組む価値は大きい。

明日からできる3つの一歩

  1. 行動の棚卸し:いま社内のエージェントが実行できる行動を洗い出し、RRI(リスク・取り消し可能性・事業インパクト)で採点する
  2. 階層とゲートの対応付け:採点結果をTier1〜4に振り分け、Tier3以上には承認ゲートまたは事後監査ログを必須にする
  3. MCP接続の許可リスト化:エージェントが接続できるMCPサーバー・ツールを「デフォルト拒否・明示的に許可」の方針に切り替える

エージェントに「何でもできる」権限を渡すのではなく、行動のリスクに応じて監督のかけ方を変える——この設計思想は、ツールが増えるほど効いてくる基本原則になりそうだ。


主な情報源

各ツールは提供元の規約に従ってご利用ください。情報は各情報源の公開時点のものです。収集・要約はAI、公開判断は人。