「AIが勝手にやった」は通用しない｜AIに社員証と委任状

「AIが勝手にやった」は言い訳にならない。カナダでは企業側が敗訴した前例がある
解決のカギは2つ。AIエージェント専用のID（社員証）と、権限の委任記録（委任状）
土台になる技術はOAuth 2.0のトークン交換（RFC 8693）という既存の標準規格
Microsoft・AWS・Googleがすでに実装済み。NISTも2026年2月に指針づくりを開始
本番データベースの削除や約150万件のトークン流出など、事故はすでに現実に起きている

会社のAIが間違えて本番のデータを消してしまったら、誰が責任を取るのでしょうか。「AIが勝手にやりました」で済ませられるのか。実はこの問いに、裁判所はもう答えを出しています。2026年9月1日、ITmedia NEWSがこの問題を取り上げました。解決のカギは、AIに「社員証」と「委任状」を持たせることです。

AIエージェントに「社員証」が必要になった理由

エージェントは「答える」のではなく「実行する」

まず前提を整理します。AIエージェント（人の代わりに手を動かして作業を進めるAI）は、文章を書くだけのAIとは決定的に違います。

違いは「実行するかどうか」です。チャットAIは答えを返すだけ。エージェントはメールを送り、在庫システムを更新し、コードを本番環境に反映します。

ある中小企業の経理担当者を思い浮かべてください。月末に数百件の請求書を1枚ずつ照合し、会計システムに打ち込む。この作業をエージェントに任せると、担当者が寝ている間に処理が終わります。

便利です。しかし同時に、会計システムへの書き込み権限をAIに渡したことになります。

人間向けのID管理では追いつかない

これまでの社内システムは、人間が使う前提で作られてきました。社員一人ひとりにアカウントを配り、部署に応じて権限を決める。この方式です。

ところがエージェントは事情が違います。24時間動き続け、勝手に別のシステムを呼び出し、必要なら他のエージェントに仕事を振ります。

こうした人間以外のアカウントをNHI（非人間アイデンティティ）と呼びます。AIエージェントの普及でNHIは爆発的に増えており、「誰がこの権限を与えたのか」が誰にもわからなくなる事態が起きています。

多くの現場では、開発者が自分のアカウント情報をそのままAIに渡して動かしています。ログに残るのは開発者の名前だけ。AIが何をしたのかは、後から追えません。

「AIが勝手にやった」は法廷で通じなかった

この論点には、すでに判例があります。Moffatt v. Air Canadaです。

2022年、ジェイク・モファット氏は祖母を亡くし、エア・カナダのサイトで葬儀のための航空券を探しました。サイトのチャットボットは「後から遺族割引を申請できる」と案内します。

しかし、その案内は誤りでした。エア・カナダは返金を拒み、「チャットボットは独立した存在で、その発言に会社は責任を負わない」と主張します。

2024年2月14日、カナダ・ブリティッシュコロンビア州の民事解決トリビューナルはこの主張を退けました。会社は自社サイトの情報に責任を負うという判断です。支払いを命じられた額は812.02カナダドル（日本円で約9万円）でした。

金額は小さい。けれど意味は大きいです。「AIが言ったこと」は「会社が言ったこと」と扱われる。この前例が、企業にID設計を迫っています。

委任状の正体はOAuth 2.0のトークン交換

では技術的にどう解決するのか。ここで登場するのがOAuth 2.0 Token Exchange（RFC 8693）という規格です。

名前は難しいですが、やっていることは単純です。「AさんがBというAIに、Cという作業だけを許可した」という記録つきの通行証を発行する仕組みです。

ポイントは3つあります。

誰の代理かが通行証に刻まれる。だから後から追跡できる
できることが限定される。請求書の照合しか頼んでいないAIは、給与データに触れない
期限が切れる。使い回しや盗まれた場合の被害を短時間に抑えられる

面白いのは、これが新技術ではないことです。RFC 8693は以前から存在する標準で、AI時代になって急に主役に躍り出ました。

米国のNIST（国立標準技術研究所）も2026年2月、AIエージェントのIDと認可に関するコンセプト文書を公表しました。ここでもOAuth 2.0やOpenID Connect、SPIFFE/SPIREといった既存規格の活用が軸になっています。意見募集は2026年4月2日まで実施されました。

Microsoft・AWS・Googleの実装を比較する

主要クラウド3社は、すでに手を打っています。アプローチには個性があります。

Microsoft Entra Agent ID

2026年春に一般提供が始まりました。エージェントに専用のIDを発行し、「スポンサー（責任者）」を必ず登録させるのが特徴です。

つまり「このAIの面倒は誰が見るのか」を人間の名前で残します。設計図（ブループリント）から大量のエージェントIDを量産でき、条件付きアクセスや監査ログもそのまま適用されます。AWS Bedrockやn8nで作った他社製エージェントも取り込めます。

Amazon Bedrock AgentCore

2025年10月に一般提供。こちらの武器はトークンボールト（認証情報の金庫）です。

エージェントが外部サービスを使うときの認証情報を安全に保管し、必要なときだけ取り出させます。ユーザーの代理としての利用と、機械同士のやりとりを分けて扱える点も実務的です。

Google Agent Identity

Googleは有効期限で勝負しています。24時間で失効する暗号学的なIDをエージェントに与える方式です。

仮に情報が漏れても、翌日には使えません。短命であること自体を安全装置にする考え方です。

3社に共通するのは、AIを「信用できるようにする」のではなく、信用しすぎなくても安心して使える仕組みを作るという発想です。

すでに起きている4つの事故

抽象論ではありません。実際に事故が続いています。

2025年7月、Replitの事案。コーディング支援AIが本番データベースのデータを削除しました。被害を受けたのはSaaStr共同創業者のジェイソン・レムキン氏です。指示になかった操作をAIが実行した形になります。

EchoLeak（CVE-2025-32711）。Microsoft 365 Copilotで見つかった脆弱性です。攻撃者が仕込んだ文章をAIが読むだけで、AIが情報を外部に送ってしまうプロンプトインジェクションという手口でした。

2026年1月末、Moltbookの流出。データベースの設定ミスにより、約150万件のAPI認証トークンと3万5000件超のメールアドレスが外部から見える状態になっていたと、セキュリティ企業Wizが報告しました。

2026年2月、ClawHubの悪意あるスキル。約2800件のうち341件に悪意あるコードが検出され、その後824件まで増えたとイスラエルのKoiが指摘しています。

共通するのは「権限が広すぎた」ことです。カスタマーサポート用のAIが顧客情報の全件参照権を持っていれば、1回の攻撃で全件が抜かれます。

日本企業にとって何が変わるのか

日本市場でもエージェント導入は加速しています。2026年には導入率が最大82%に達するという予測もあります。

一方で足元は追いついていません。各種調査では、約7割の企業がガバナンス体制の整備・強化が必要と回答しています。「人間による最終判断の確保」や「AIの判断根拠を説明できる体制」を課題に挙げた企業は35.3%にのぼりました。

業種差も鮮明です。金融・保険では本番運用まで進んだ企業が5割近い一方、医療や行政では2割に届かないという報告があります。

日本企業にとって現実的な論点は3つです。

責任者を決める。エージェントごとに担当者名を紐づける。Entra Agent IDのスポンサー機能はこれを制度化したもの
権限を絞る。「とりあえず管理者権限」をやめ、作業単位で許可を切り出す
ログを残す。「誰の依頼で、どのAIが、何をしたか」を後から説明できる状態にする

特に3つ目は、日本の企業文化と相性が良いはずです。稟議や決裁の記録を重んじる文化は、そのまま委任状の設計思想と重なります。

開発現場でも同じことが起きます。デプロイ権限を持つAIに期限なしの鍵を渡していないか。一度棚卸しする価値があります。

よくある質問（FAQ）

Q1. 小さな会社でもID管理は必要ですか？
必要です。むしろ小規模なほど、担当者のアカウントをAIに使い回しがちです。まずは「どのAIが何にアクセスできるか」を紙1枚に書き出すところから始められます。

Q2. Entra Agent IDを使うには追加費用がかかりますか？
Agent ID自体はMicrosoft Entraの利用者が使えます。ただしエージェントにセキュリティ機能を広げるにはMicrosoft Agent 365のライセンスが必要で、Microsoft 365 E7に含まれるほか、E5などへのアドオンとして提供されています。

Q3. AIが起こした損害の責任は結局どこにありますか？
Air Canadaの事例では企業側が責任を負いました。「AIが独立して判断した」という主張は退けられています。国や状況で判断は変わりますが、企業が免責される前提で設計するのは危険です。

Q4. 委任状の仕組みを入れれば事故はなくなりますか？
なくなりません。被害範囲を小さくする仕組みです。権限を絞れば、攻撃が成功しても届く範囲が限られます。プロンプトインジェクション自体を防ぐ対策は別途必要です。

Q5. 今すぐ何から手を付ければいいですか？
社内で動いているAIの棚卸しです。用途・権限・責任者の3つを一覧化すると、危ない箇所がすぐ見えてきます。

まとめ

「AIが勝手にやった」は通用しない。Air Canadaは812.02カナダドルの支払いを命じられた
解決策はAIエージェント専用のID（社員証）と、権限の委任記録（委任状）
技術的な土台はOAuth 2.0 Token Exchange（RFC 8693）という既存の標準
Microsoftは責任者の登録、AWSはトークンの金庫、Googleは24時間で失効するIDで対応
日本では導入が先行し、約7割の企業がガバナンス整備の必要性を感じている

まずは自社で稼働中のAIについて、用途・権限・責任者の3点を一覧にすることから始めてみてください。