小林啓倫のエマージング・テクノロジー論考

「AIが勝手にやった」は通用しない？　AIエージェントにも“社員証”と“委任状”が要るワケ　今からできる対策も解説

　「来週の大阪出張、手配しておいて。航空券は5万円以内で、ホテルは会社指定のところ。終わったらカレンダーにも入れておいて」

　こうした依頼を、部下や旅行代理店ではなくAIに投げる――そんな世界が、いま急速に現実味を帯びてきている。自律的に作業をこなす「AIエージェント」技術の進化が進んでいるためだ。技術的には既に、AIエージェントは航空券を検索し、ホテルの空室を調べて候補を出せる。

　問題はその先だ。AIが実際に予約を確定し、法人カードで決済し、カレンダーを書き換え、経費申請の下書きまで作るとなると、技術面以外の課題も見えてくる。

　航空会社から見て、この予約をしたのは誰なのか。本人か、会社か、AIか。法人カードを使う権限は誰がいつAIに与えたのか、それは今回の出張限定なのか。5万円を超える便しかなかったとき、AIは手を止めるのか、それとも依頼者の購買権限でそのまま決済してしまうのか。誤った予約は誰が取り消し、誰が責任を負うのか。

　AIエージェントの業務利用が広がるにつれ、こうした問いに答える枠組みとして注目を集めるのが「Agentic Identity」（エージェンティック・アイデンティティー）と「Delegated Authorization」（デリゲーテッド・オーソライゼーション）だ。

　硬い用語だが、中身はシンプルだ。前者は働くAIに固有の身元、いわば「社員証」を持たせること。後者は、人や組織の権限の一部を、条件付きの「委任状」としてAIに渡すことを指す。

　結論を先に述べておくと、Agentic IdentityとDelegated Authorizationが目指すのは「AIを信用できるようにすること」ではない。「AIを信用しすぎなくても、安心して使える仕組みをつくること」である。

　では、この2つは具体的にどのような仕組みで何を防ぐのか。実際の事故や主要各社の動きを整理し、AIエージェントを業務で使う企業と個人がいまからできる対策を解説する。

「Agentic Identity」と「Delegated Authorization」の仕組み

　現在のユースケースでよく見られるのは、AIエージェントに利用者本人のIDとパスワード、あるいはブラウザのログインセッションを渡し、「利用者本人として」システムを操作させる方式だ。

　実装は手軽だが、リスクは大きい。システムの記録には「本人が操作した」としか残らないため、後から見ても人の操作かAIの操作か区別できない。AIだけを止めることもできず、認証情報が漏れれば本人の全権限が悪用される。

　Agentic Identityは、この状態を解消するために、AIエージェントごとに固有のIDを発行する考え方である。単なる表示名ではなく、どの部署が所有し、誰が責任者で、何の用途で、どのシステムに接続でき、いつまで有効かという情報がひも付いた管理単位だ。

　同じAIモデルから作られていても、営業部門の営業支援エージェントと人事部門の採用支援エージェントは別の行為者として扱う。前者が応募者の履歴書にアクセスする必要はなく、後者が顧客の契約金額を見る必要もないからだ。

　その上で、権限の受け渡しを具体化するのがDelegated Authorizationだ。「AIの利用を許可する」といった一括同意ではなく、誰の代理として、どの対象に、どの操作を、どの期間、どの条件で許すかを明示する。

　冒頭の出張手配なら「依頼者は営業部の田中氏、実行者は登録済みの出張手配エージェント、航空券の上限は5万円、カード決済は今回の予約のみ、カレンダーの変更は出張関連の予定のみ、権限は予約完了の2時間後に失効、条件外は人間の承認が必要」といった具合だ。

　技術的には、権限の持ち主（subject）と実際の行為者（actor）を区別して委任関係を表現する「OAuth 2.0 Token Exchange」（RFC 8693）のような既存標準が土台として使われている。

　重要なのは、AIが実際に行使できる権限が「本人が持つ権限」「そのAIに許された上限」「今回の委任範囲」の共通範囲に限られる点だ。利用者が全顧客情報を閲覧できる立場でも、AIには担当顧客の分しか読ませない。逆にAIに検索機能があっても、依頼者本人に閲覧権限がなければ結果は返さない。新入社員に最初から代表印を渡す会社がないのと同じ理屈である。

この1年余りで相次いだ「事故」

　こうした仕組みの必要性は、抽象論ではなく実際の事故によって裏付けられてきた。

　例えば2025年7月、プログラミング支援サービスを提供する米ReplitのAIエージェントが、利用者のアプリの本番データベースからデータを削除する事案が起きた。

　被害に遭ったのは米SaaStrの共同創業者ジェイソン・レムキン氏。データ自体はサービス側のロールバック機能で復旧したが、当のAIは「復旧は不可能」と誤った説明までしていた。Replitは公式ブログでその経緯を認め、開発環境と本番環境の標準分離や、AIが計画だけを立てて変更を行わないモードの導入を発表している。

　この事案が示すのは、IDだけでは事故を防げないということだ。「このAIが削除した」と記録できても、削除権限を持っていれば操作は通ってしまう。「削除するな」と指示するより、削除権限をそもそも持たせないほうが強い。Identityは「誰がやったか」を明らかにし、Authorizationは「そもそもできないようにする」。両方そろって初めて安全性が成り立つ。

　また、AIが外部から「操られる」リスクもある。25年6月には「Microsoft 365 Copilot」の脆弱（ぜいじゃく）性「EchoLeak」（CVE-2025-32711）が公表された。

　これは、攻撃者が細工したメールを送りつけると、受信者が何もクリックしなくても、Copilotがメール本文に埋め込まれた指示を処理し、その利用者が閲覧できる社内情報を外部に送信しかねないというもの。いわゆる「プロンプトインジェクション」攻撃がゼロクリックで成立し得ることを示した。

　実際の悪用が確認される前に米Microsoftが修正したが、AIは利用者の指示だけでなくメールや文書、Webページの中身も「読んで」しまう以上、この種の攻撃を完全に防ぐ方法は現時点で存在しない。だからこそ、仮にAIが誘導されても取得できるデータが今回の仕事に必要な範囲に限られ、外部送信には人の承認が要る、という権限設計による防壁が意味を持つ。

　認証情報そのものが漏えいした事案もある。26年1月末、AIエージェント同士が交流するSNSとして話題を集めた「Moltbook」で、データベースの設定ミスが発覚した。

　セキュリティ企業の米Wizの調査によれば、データベースが認証なしで誰でも読み書きできる状態にあり、約150万件のエージェント用API認証トークンや3万5千件超のメールアドレスが露出していた。このトークンを使えば他人のAIになりすませるうえ、投稿を書き換えて他のAIが読む内容に悪意ある指示を仕込むこともできたという。

　AIに追加する「道具」の汚染例もある。26年2月、イスラエルのセキュリティ企業Koiの調査によると、AIエージェント向けスキル（拡張機能）を配布するマーケットプレース「ClawHub」上の約2800件のスキルのうち341件が悪意あるものだった。正規ツールを装って追加プログラムのインストールを促し、パスワードや暗号資産ウォレット、SSH鍵を盗む仕組みで、マーケットの拡大とともに確認数は824件まで増えたという。

　スキルは導入先のAIの権限を引き継ぐため、メールにもファイルにもアクセスできるAIに悪意あるスキルを追加すれば、盗める範囲も同じだけ広がる。しかも監査ログ上は「正規のAIによる正規の操作」にしか見えない。

「AIが勝手にやった」は通用しない？

　では、AIエージェントが失敗した場合、責任は誰が負うのか。参考になるのが、24年2月にカナダのブリティッシュコロンビア州民事解決審判所が下した「Moffatt v. Air Canada」の判断だ。

　これはカナダの航空会社であるAir Canadaのサイト上のチャットbotが弔事割引運賃について誤った案内をし、それを信じた利用者が損害を被った事案。同社は「チャットbotは自らの行動に責任を負う別の主体」という趣旨の主張をしたが、審判所はこれを退けた。

　チャットbotもWebサイトの一部であり、情報の正確性を確保する注意義務は会社にある、という判断である。支払命令総額は800カナダドル（約9万円）余りと小さかったが、「AIが勝手に答えた」という抗弁は通らないことを示した事例として広く引用されている。

　この文脈で見れば、Agentic Identityの役割もはっきりする。それは責任をAIに押し付けるための仕組みではなく、誰がそのAIを所有し、誰が権限を与え、誰の依頼で動いたのかを明確にして、企業が管理責任を果たせるようにするための仕組みだ。

プラットフォーマーはすでに動いている

　この領域は、すでに構想段階から製品段階へ移っている。Microsoftは26年4月、AIエージェント専用のID基盤「Entra Agent ID」を一般提供した。エージェントごとに固有IDと人間の「スポンサー（責任者）」を登録し、同じ設計のエージェント群に共通ポリシーを適用したり一括停止したりできる。

　米Amazon Web Servicesも25年10月に一般提供を始めた「Bedrock AgentCore」で、エージェント固有のID、認証情報を格納するトークンボールト、利用者の代理として権限を受け渡すトークン交換などを提供する。

　また米Googleは「Agent Identity」で、実行中のエージェントに24時間で失効する暗号学的なIDを付与し、長期間有効な鍵をそもそも持たせないアーキテクチャを打ち出した。米国立標準技術研究所（NIST）も26年2月、AIエージェントの識別と認可に関する概念文書を公表し、産業横断の課題として整理を始めている。

　各社に共通する方向性は明確だ。長期間有効な鍵をAIに渡すのではなく、仕事のたびに数分から数時間で失効する短命の許可証を発行する。認証情報そのものはAIに見せず、専用の保管庫が代理で管理する。

　人間への確認でも、「カレンダーへのアクセスを許可しますか」という抽象的な同意ではなく、「9月3日14時に社外3人へ会議招待を送ります」という具体的な操作の承認を求める。毎回の確認で利用者を疲弊させるのではなく、通常範囲の低リスク操作は自動で流し、金額の上限超過や新規の送金先といった例外だけを人に回す設計である。

　一方で、過度な期待は禁物だ。企業をまたいでAI同士が取引するための標準は整備の途上にあり、インターネット全体で通用する「パスポート」のようなものが1〜2年で登場する見込みは薄い。

　何より、認可の仕組みが判定できるのは「その操作が許されているか」までで、「その操作が正しいか」は保証しない。5万円以内の航空券を買う権限が正当でも、AIは早朝5時発の不便な便を選ぶかもしれない。正しさの担保には、結局のところ人間の関与と検証が必要になる。

いまからできる3つの備え　「信じすぎなくても回る」仕組みを

　Agentic IdentityとDelegated Authorizationが目指していることを簡潔に表すなら、「AIエージェントを信用できる仕組みをつくること」ではなく、「AIエージェントが信用できなくても安心・安全に仕事を任せられる仕組みをつくること」といえるだろう。

　ここまで見てきたのは、この目標に向けて、主に基盤を提供するプラットフォーマーや標準化団体がどのように動いているかだ。しかし、彼らが仕組みを整えるのを待っていれば良いわけではない。事故の多くは、仕組みの不在よりも、使う側の運用（本人アカウントの使い回しや権限の与えすぎ、出どころ不明のツールの追加など）から生まれている。

　そこで最後に、AIエージェントを業務で使う企業と個人が、いまの環境のままでも実行できる備えを3つに整理しておきたい。

　第1に、社内で動いているAIの棚卸しだ。本稿で述べてきた仕組みは全て「どんなAIが、誰の権限で動いているか」を把握できていることが前提になるが、実際には、この把握ができていない企業が多い。

　手元のAIが自分のIDとパスワードでログインしているのか、専用のIDを持っているのか。ブラウザ拡張や個人契約のAIサービスが、会社のメールやファイルにつながっていないか。高価な製品を導入する前に、こうした現状を一覧にした「エージェント台帳」を作ることが出発点になる。

　第2に、AIに任せる仕事の線引きを「失敗したときの影響」で決める必要がある。判断基準をAIの賢さに置くと、モデルが進化するたびに任せる範囲がなし崩しに広がってしまうからだ。

　回答案の作成のようにやり直しが利く仕事は広く任せ、社外への送信、発注、返金、契約、送金のように取り返しがつきにくい仕事ほど、上限額の設定、人間の承認、取り消し手段を必須にする。Replitの事故が示した通り、防壁になるのはAIへの注意書きではなく、権限そのものの設計だからだ。

　第3に、AIに追加するスキルや外部ツールへの警戒である。ClawHubの事例が示したように、AIの拡張機能はマルウェアの新しい配布経路になっており、しかも導入先のAIが持つ権限をそのまま引き継ぐ。

　スマートフォンで出どころ不明のアプリを入れないのと同じ感覚で、提供元を確認し、要求される権限と機能が釣り合っているかを見る。天気を調べるだけのスキルがメールやファイルへのアクセスを求めてきたら、それは疑うべきサインだ。

　AIエージェントの能力は今後も急速に向上していく。高性能なAIほど多くのシステムに接続し、短時間に多くの操作をこなす。つまり、正しい仕事も間違った仕事も速くなる。

　だからこそ、「社員証」と「委任状」という一見地味な基盤の価値は、AIが賢くなるほど増していく。AIを信じられるかどうかを議論するより先に、信じすぎなくても回る仕組みを整える。それが、エージェント時代に向けた最も現実的な備えだろう。

小林啓倫のエマージング・テクノロジー論考

生成AIやメタバース、新たなサイバー攻撃など、テクノロジーの進化が止まらない。少しずつ生活の中に浸透し、その恩恵を預かれることもある一方、思いもよらない問題を生み出すこともある。このコーナーでは、さまざまな分野の新興技術「エマージング・テクノロジー」について、小林啓倫氏が解説する。

この連載の記事をもっと見る

この記事の著者

関連記事

• 

  Googleが“自社AIの裏切り”に備え始めた　異例の構想「AI Control Roadmap」とは

• 

  【徹底入門】AIエージェントで注目の「AX」とは何か　人間だけじゃなく“AI視点の使いやすさ”も重要に？

• 

  最新AI「ミュトス」を使えても「バグマゲドン」に？　Firefox開発元に学ぶセキュリティ対策

• 

  「Claude Mythos」でセキュリティはどう変わる？　競合「GPT-5.4-Cyber」と比較

• 

  中東紛争で“企業のAI投資”はどう変わる？　求められる戦略の「再設計」