監訳: 安部 聡
あなたの会社のどこかで、今この瞬間、誰にも承認されず、誰にも監視されないまま、AIエージェントが何らかの業務を進めているかもしれない。最近の事例は、こうした状況がいかに短期間で統制上の問題に発展し得るかを示している。米オープンAI、米アンソロピック、英国AI安全研究所（UK AISI）はいずれも、エージェントが与えられた任務を遂行しながら、評価試験で設定された制約を越えた事例を報告している。オーストラリアでは、あるジムでクラスの予約を依頼されたAIアシスタントが、予約システムの脆弱性を突いて通常は予約できない時間帯の枠を確保し、さらに別の顧客をキャンセル待ちリストから外す、という事例があった。いずれの場合も、エージェントは与えられた目標を達成しようと動いていた。
これまでAIエージェントをめぐる懸念の多くは、誤った判断を下し、それを完全な自信をもって実行するエージェントに向けられてきた。しかし、統制上のより難しい課題は、正しい目標を不適切な手段で達成してしまうエージェントにある。エージェントは指示と権限の範囲内で動きながら、従業員なら試みない形で、また、従来のアプリケーションでは想定されていなかった組み合わせで、顧客記録へのアクセスや資金移動を行ったり、会社を代表するような発言をしたりしてしまうことがある。AIエージェントの導入はすでに本格化している。BCGとMIT スローン・マネジメント・レビューの調査では、組織の35％がエージェント型AIを本番環境で運用し、44％が導入を計画している。また、3分の1を超える組織が、3年以内にエージェントに独立した意思決定権を持たせると見込んでいる。
すべてのCEOは、以下の4つの問いに答えられる必要がある。1）自社の環境ではどのエージェントが稼働しているのか。2）何を行う権限が与えられているのか。3）その権限を誰が委譲したのか。そして、4）不適切な方法で目標を追求するエージェントを誰が止めるのか。しかし、多くのCEOはこれらに明確に答えられない。本稿では、従来の権限管理の仕組みではなぜAIエージェントを十分に統制できないのかを考察し、「目的」と「行動規範」に基づく認可を中核に、人・アプリケーション・エージェントを横断する統一的な統制レイヤーを提示する。
従来の統制ではAIエージェントに対応できない
企業では、AIエージェントに実務を担わせる動きが広がっている。カスタマーサービスのエージェントは問い合わせに対応し、返金処理を行う。調達エージェントは仕入先を比較して発注する。コーディングエージェントはソフトウェアのプログラムを作成し、本番環境に反映する。財務エージェントは複数のシステムにまたがる勘定を照合する。こうしたエージェントが業務を遂行するには、各種システムへのアクセス権が必要になる。企業は現在、その権限を、人や従来のソフトウェア向けに設計されたアクセス制御の仕組みを通じて付与している。しかし、AIエージェントが行為主体になると、どちらの仕組みも十分に機能しない。しかも、その理由はそれぞれ異なる。
人向けのアクセス制御は判断力を前提としている
企業は従業員に幅広いアクセス権を与え、その適切な利用を人間の判断力に委ねてきた。カスタマーサービス担当者はアカウント履歴を閲覧し、会社名義のメールを送れる。技術的には顧客リストを出力し、全員に一斉送信することもできる。しかし、通常はそのような行動を取らない人間が利用することを前提としてきたため、そうした行為を個別に禁止するルールまでは設けられてこなかった。安全を支えているのは、本人の判断力だけではない。不適切な行動を起こした担当者は解雇され、訴えられ、あるいは刑事訴追されることもある。AIエージェントに対しては、こうした抑止は働かない。
AIカスタマーサービスエージェントに従業員と同じ認証情報を与え、同じログイン経路を使わせることもできる。しかし、その場合、企業はアクセス権がどのように使われたかを、かなり時間がたってからでなければ詳細に把握できず、リアルタイムに制御することも難しいことがある。エージェントの実際の行動が与えられた業務の範囲内かどうかを検証する仕組みがないためだ。たとえば、エージェントが1件のアカウントに関する問い合わせに対応するなかで、1万件のデータを取得し、従業員が一度も行ったことのない方法で顧客ファイルとメールシステムを組み合わせることを、1分足らずで実行したとしても、統制の仕組みがまったく作動しないことがあり得る。
単一のエージェントに幅広いアクセス権を与えると、企業が長年依拠してきた統制の仕組みも機能しなくなる。リスクの高い業務では、担当者が一人で一連の処理を完結できないよう、複数の担当者に役割を分けるのが一般的である。たとえば買掛金業務では、請求書を入力する担当者と、支払いを承認する担当者を分ける。こうした職務分掌が機能するのは、別の担当者が独立した立場で確認するからである。ところが、単一のエージェントに幅広いアクセス権を与えると、この職務分掌を実質的に迂回し、請求書の入力から支払いの承認までを単独で行えてしまう。別のエージェントにチェックを担わせることもできるが、それが有効なのは、各エージェントの独立性が仕組みによって担保されている場合に限られる。しかし、現在のアクセス制御の仕組みは、こうした独立性を担保するようには設計されていない。
従来のアプリケーションと異なり、AIエージェントの行動は固定できない
AIエージェントもソフトウェアの一種であるため、セキュリティ部門は、従来のアプリケーション間のアクセス制御をそのまま適用できると考えがちである。しかし、従来のアプリケーションは、コードによって実行できる動作の範囲が限定されている。たとえば、給与システムは人事データベースから情報を取得し、請求システムはCRMと連携する。しかし、こうした連携を比較的安全に管理できるのは、アプリケーションがあらかじめプログラムされた動作しかしないためである。請求ソフトウェアが、自らの判断で顧客へのメール送信を始めることはない。電子署名ツールが、自ら人事ファイルにアクセスし始めることもない。想定される振る舞いが限定的なため、付与する権限の範囲も管理しやすい。
一方、AIエージェントの行動は決まっていない。たとえば、仕入先コストの削減を指示された調達エージェントは、アクセス可能なシステムを使いながら、目標達成までの手順を自ら組み立てる。同じ目標でも、翌月には導入時とは異なる手順を取る可能性がある。さらに、問題が起きても、問い合わせ先となるベンダーがいないことも多い。多くのエージェントは社内で開発されているほか、オープンソースのコンポーネントを組み合わせて構築されたり、事業部門のユーザーによりAPIキー（外部サービスに接続するための認証情報）を用いて設定されたりしている。そのため、エージェントの振る舞いに対する説明責任を、社外のベンダーに求められないケースも多い。
エージェント専用の枠組みだけでは、領域をまたぐ行動を統制できない
こうしたガバナンス上の課題を受け、業界ではAIエージェント専用の統制の枠組みを整備する動きが進んでいる。主要なID管理ベンダーや新たな標準では、人やアプリケーション向けの仕組みとは別に、エージェント専用のID種別、認証情報のライフサイクル管理、ポリシーレイヤーを設定・提供し始めている。
専用の枠組みの構築は必要ではあるが、それで解決できるのは問題の一部にすぎない。エージェント自身の行動は統制できても、その出力が人や他のシステムを通じて何を引き起こすかまでは統制できない。今年初め、ある大手テクノロジー企業で起きた事例を考えてみよう。文書を読み、承認済みのチャネルに回答を投稿することだけを許可された社内サポート・エージェントが、その１つであるエンジニア向けフォーラムに技術的に誤った案内を投稿した。あるエンジニアがその投稿を信じて行動した結果、機密情報が2時間にわたり露出した。エージェント側の統制はすべて守られ、エージェントは権限を一度も逸脱していない。問題は、その回答を信じた人が行動したことで生じた。
こうしたことが起こりうるため、エージェントIDを独立した枠組みで管理するだけでは不十分である。エージェントは、人、アプリケーション、エージェントの3つの領域をまたいで動く。目標を達成しようとする過程で、結果として最も統制の弱い部分を特定し、通る可能性がある。エージェントを統制するには、人、アプリケーション、エージェントの3領域すべての統制を強化するとともに、共通の認可モデルで横断的に統制する必要がある。そうすれば、連鎖のどこで問題が顕在化しても、その起点となったエージェントまでさかのぼれる（図表1）。米国国立標準技術研究所も2026年2月のコンセプトペーパーで同様の方向性を示し、企業のID管理システムにおいて、人に適用するのと同等の厳格さでエージェントIDを管理することを提案している。
「目的と行動規範に基づく認可」により、エージェントの権限に明確な境界を設ける
AIエージェントに何を行う権限を与えるかを決める前に、企業はまず、エージェントに何をさせてもよいのか、また、その目的をどのような方法で達成することを認めるのかを定める必要がある。これらは、個別の事業・機能部門だけで答えられる問いではない。リスク部門は、許容するリスクの範囲とエスカレーションの基準を定める。セキュリティ部門は、それらを実効性あるものにする統制を設計する。対象業務の責任者は、各エージェントに担わせる仕事と、その遂行方法に対する制約を定義する。こうした判断から生まれる枠組みを、本稿では「目的と行動規範に基づく認可」と呼ぶ。「目的」は、エージェントに何を達成する権限を与えるかを定めるものだ。「行動規範」は、利用規約、第三者の権利、他者への影響を含め、どのように目標を追求してもよいかに境界を設ける（図表2）。この枠組みは、次の5つの問いに答えられるようにするものだ。
誰が行動しているのか、その権限の出所を特定できるか
エージェントが行動するとき、システムはエージェントのID、そのエージェントが誰のために、またはどの事業・機能部門のために行動しているのか、そしてどのような目的のためにその権限が委譲されたのかを認識できるべきである。現在、多くのシステムが記録するのは認証情報のみなので、従業員のログインを使うエージェントは、すべてのログ上で当該従業員として表示される。その結果、問題が起きた際、ログ上では実際に操作していない従業員が実行者として記録されてしまう。
顧客からの苦情を分析するという業務上の権限を与えられたエージェントが、別のツールを呼び出した際に、当初認められていた範囲を超えてシステムやデータにアクセスできるようにしてはならない。また、元となる業務上の権限が取り消された場合は、その権限を基にエージェントやツールが進めている処理もすべて停止する必要がある。こうした仕組みを実現するには、統合されたID基盤が必要になる。エージェントは企業のID管理システム内で独立して識別可能な行為主体として表現され、その権限が、誰によって、どのプロセス、またはガバナンス組織によって委譲されたのかまで追跡できなければならない。
権限を目的と行動規範にひも付けられるか
実際の認可リクエストには、エージェントの目的、行動規範上の制約、関連するコンテキスト（文脈）を含めるべきである。債権回収エージェントは、延滞口座の解消を支援するために支払履歴を必要とするかもしれない。しかし、そのアクセス権によって、同じデータからマーケティングリストを作成したり、顧客の脆弱性を推測したり、未承認のチャネルで顧客へ連絡したり、第三者サービスをその利用規約に反する方法で利用できてはならない。したがってシステムは、権限がどの目的に資するかと、エージェントがそれをどのように使うかに対する制約の両方を評価しなければならない。先ほどのジム予約の例は、その違いを端的に示す。エージェントにはクラスを予約する権限があったが、その実行にあたり予約システムの弱点を突き、別の顧客をキャンセル待ちから外した。つまり、目的自体は認められていても、その達成手段まで許されていたわけではない。
したがって、システムは、承認された業務とその範囲、利用するデータ、ワークフローの状態、顧客や従業員への影響、エージェントのリスク区分などに照らして、エージェントの行動を評価する必要がある。技術部門がエージェントにこれらの条件を守らせるには、Policy as Code（統制ルールをコードとして定義し、自動的に適用する仕組み）、目的・行動規範の構造化仕様、実行時ポリシーエンジン、バージョン管理されたルールなどが必要になる。事業上のニーズやワークフローに応じてエージェントの役割が変わる場合、そのエージェントの目的と行動規範も定期的に見直して妥当性を再確認する必要がある。これは、金融モデルを定期的に再検証するのと同じ考え方である。さらに、モデルの更新によってエージェントの行動は変わり得るため、こうした見直しは比較的高い頻度で行う必要があるだろう。
エージェントの行動を実行時に検証できるか
適切に識別され、目的と行動規範に基づいたエージェントであっても、誤って行動する可能性はある。したがって統制は実行時にも働く必要がある。エージェントの行動が設定された境界内に収まっているかをAIで判定するベンダーもあり、この方法は影響の小さい業務では有効である。しかし、誤りが生じた場合の影響が大きい業務では、統制は決定論的に、固定ルールに基づくかたちで設定するべきだ。つまり、判断にばらつきがあり得るAIシステムを、別のAIシステムに監視させるのではなく、毎回必ず作動するルールを使う。たとえば支払いエージェントには、一定額を超える処理では必ず人の承認を求める、という絶対的なルールを設ける必要がある。その推論がどれほど妥当に見えても、例外は認めない。
人の関与を求める基準は、ワークフローによって異なる。社内調査エージェントには広い自律性を認めることが妥当だ。一方、資金を移動し、顧客の利用権限を変更し、本番システムを更新し、または社外へ発信するエージェントには、あらかじめ定めたポイントで、人による確認や承認を求める必要がある。その審査は、担当者が拒否できるように設計しなければならない。エージェントが難しい作業を終えた後で曖昧な依頼だけを受け取る担当者は、形式的な追認に陥りやすい。担当者には、必要に応じて拒否できるだけの十分な情報、権限、時間が必要である。
誰が責任を負うのかを明確にできるか
企業は、エージェントの認可について、誰が一貫して責任を負うのかを明確にする必要がある。複数の部門が互いに責任を押し付け合うような状態では、実質的に責任主体は存在しない。責任の所在は、エージェントの導入を承認した担当者、目的と制約を定めた担当者、アクセス権を付与した担当者まで追跡できる必要がある。運用モデルでは、誰がエージェントを停止できるかも定めるべきである。キルスイッチやサーキットブレーカー、アクセス権の取り消しといった仕組みも、それを実行する権限を持つ責任者が明確でなければ機能しない。
何が起きたのかを後から再現できるか
現在の多くの監査システムには、APIを呼び出した際に使われた認証情報しか記録されない。たとえば、3段階の権限委譲を経て始まったワークフローの47番目の処理をエージェントが実行している、というような場合、その処理でAPIを呼び出した認証情報だけを記録しても一連の処理の起点や権限委譲の経緯までは把握できない。
有用な監査証跡（誰が、いつ、どの権限で何をしたかをたどれる記録）は、インシデント後に経営者が実務的な問いへ答えられるものでなければならない。エージェントは何をしようとしていたのか。その行動は承認された目的の範囲内だったか。目的を追求する方法に課された制約を守ったか。どのデータに触れたか。どのツールを呼び出したか。どの統制が作動したか。誰に通知されたか。停止権限は誰にあったか。こうした記録がなければ、組織は何かが起きたことは把握できても、なぜ起きたのか、誰が認可したのか、再発をどう防ぐのかを説明できない。
規制も、本対応の必要性を後押しする方向
規制当局は「エージェントの認可」という言葉を使わないかもしれない。しかし、既存の多くの規制はすでにAIエージェントにも適切な権限管理と統制を求める方向にある。金融機関をはじめとする規制対象企業には、ID管理、管理者権限の管理、監査証跡の確保、職務分掌、人による監督に関する義務がある。AIエージェントの導入によって、こうした要件への対応はさらに難しくなる。
エージェントが従業員の認証情報を使って動作すれば、監査証跡には実際に処理を行ったシステムではなく従業員が記録される可能性がある。エージェントが複数のシステムを呼び出す場合、単一のアプリケーションログだけではワークフロー全体を把握できないことがある。エージェント同士が協働したり、互いを起動したりすれば、組織が、権限委譲の経路を後から説明することが難しくなる可能性がある。
EUのデジタル・オペレーショナル・レジリエンス法 (DORA) は、金融機関に対し、Need-to-Know（業務上必要な範囲に限定したアクセス）、最小権限、強固な認証、職務分掌といった原則に従ってテクノロジーへのアクセスを管理するよう求めている。エージェントが規制対象システムへ到達し、顧客データを取得し、ワークフローを起動し、または高い権限を持つ認証情報を使って動作することを認める金融機関は、それらの行動をどのように制御したか説明できなければならない。他の主要な国・地域でも、説明責任、AIシステムの台帳整備、リスクに応じた監督を重視する方向で制度整備が進んでいる。
ただし、企業が対応を進めるべき理由は、規制への対応だけではない。規制当局は、AIエージェントをはじめとする人以外の行為主体が自社環境でどのように稼働しているのか、それらに何ができるのか、その権限がどう制約され、行動について誰が責任を負うのかを、企業が把握していることを期待する。
経営者が次の四半期に取り組むべきこと
企業は、正式なガイドラインの策定や標準化の進展を待つ必要はない。すでに社内システムで稼働しているエージェントと、問題が起きた場合の影響が大きいワークフローから着手できる。
- 今後30日以内に、すべてのエージェントを洗い出し、目的と行動規範上の制約を明確にする。現在稼働中または開発中のエージェントを一覧化する。それぞれについて、責任者、利用するシステムとデータ、認証情報、導入を認可した担当者、文書化されている目的と運用上の制約を確認する。試験導入、社内開発、ベンダー製ツール、事業部門主導の導入も含める。多くのCIO（最高情報責任者）は、エージェントの数が想定以上に多く、管理も分散していることに気づくだろう。
- 今後60日以内に、認可された範囲を逸脱する(いわゆる「ドリフト」）可能性と、その際の影響度に基づいて、すべてのエージェントのリスクを評価・優先順位付けする。エージェントのアクセス経路と、その先に及ぶ影響を3つの層に分けて可視化する。すなわち、エージェントが直接アクセスできるシステム、連携するツールや他のエージェントを介してアクセスできるシステム、さらにそこから生じうる二次的な影響である。こうした経路のどこで、承認された目的や行動規範を逸脱する行動が可能になるのかを特定する。さらに、問題が生じた場合の損失・影響の大きさという観点から、リスクを定量化する。顧客データ、規制対象情報、社外への発信、資金移動、実務で稼働している本番システムに到達できるエージェントを優先する。
- 今後90日以内に、最もリスクの高いエージェントを対象に、統制の仕組みを試行導入する。エージェントの目的外のシステムへのアクセスを制限し、承認された範囲を逸脱する行動につながり得る経路を制限する。残るワークフローでは、影響が小さい場面では明示された目的と行動規範に照らした自動チェックを使い、影響が大きい場面では決定論的なルールと人の承認を用いて、目的と行動規範に基づく認可を試行する。エスカレーション基準、キルスイッチを使う権限、監査要件、権限の定期レビューの頻度を定める。同時に、責任主体も決めるべきだ。CRO（最高リスク責任者）、CISO（最高情報セキュリティ責任者）、CIO、事業責任者、法務、コンプライアンス、モデルリスクの各部門には、それぞれ役割がある。しかし企業としては、インシデント時に最も重要となる「誰がこのエージェントに権限を与えたのか」という問いに、一つの答えを用意しなければならない。
当然のことながら、目的と行動規範に基づく認可だけで、すべてのリスクを抑制できるわけではない。明確なID、限定された目的、明示的な行動上の制約、責任者が定められたエージェントでも、誤った回答を出すことはあり、人がそれを信じて行動することもある。統制、重大な影響を及ぼし得る出力の人による審査、その出力がAIエージェントによるものであることを明示する表示は、なお重要である。こうした対策は、アクセス認可とは別個に設けるのではなく、その上に重ねて機能させる必要がある。
コンテンツに対するこの統制レイヤーがなければ、他のどの対策も成立しない。今この瞬間に社内で動いているエージェントは、求められたとおりに行動しているかもしれない。重要なのは、誰がそのエージェントに権限を与えたのか、何をすることを認めたのか、どのような方法で目的を追求することを許したのか、そしてその権限がどこまでなのかを把握し、自信をもって答えられることである。
原典: The Authorization Gap: Why Yesterday’s Controls Won’t Work with Today’s Agents