AIに資料を整理してもらい、必要な情報を探し、ファイルを作り、別のサービスへ登録してもらう。作業が進むほど便利さを感じる一方、「いま、どの情報と権限を使って動いているのか」と尋ねられると、答えにくいことがあります。
AIエージェントは、回答を作るだけでなく、与えられた環境で操作を実行します。そのため、出来上がった成果物が正しいことと、実行の範囲を管理できていることは別の確認になります。
海外のIT意思決定者2,001人を対象とした調査では、AIを支える準備への高い自信と、アクセスの把握・検証の不足が並んでいました。本記事では調査を土台に、実際の事故例と管理の難しさをつなぎ、企業がAIに業務を任せる際の判断を考えます。
AIエージェントのセキュリティリスクは、回答から実行へ広がる
AIエージェントは、目的に応じてツールやサービスを使い、複数の操作を進める仕組みです。製品や設定によって範囲は異なりますが、ファイルの編集、メール送信、システムへの登録などを行えるものがあります。
回答を読む人が誤りに気づく場面と、AIが操作を済ませてから人が結果を見る場面では、影響の出方が変わります。送信先の誤りなら情報が社外へ出ますし、削除や書き換えなら元の業務にも影響します。
業務の使い方は、中小企業のAIエージェント活用で扱っています。今回は、その便利さを支えるアクセスと権限を、企業がどこまで把握できるかに焦点を当てます。
海外調査：AI導入への自信と、権限管理の実態はどう違うか
Delineaの「2026 Identity Security Report」は、Censuswideが英国、米国、ドイツ、フランス、オーストラリア、シンガポール、インドで実施した調査です。対象は、AIを利用または試行しているIT意思決定者2,001人。日本企業は含まれていません。
扱うのはAIエージェントだけではありません。ボット、サービス用アカウントなど、人以外が使う認証の主体（NHI）も対象です。例えばシステム同士がデータを受け渡すアカウントも含まれ、人以外の主体が持つアクセスを調べています。
「準備できている」と答えていても、検証が揃っているとは限らない
主な結果を、準備・把握・運用という観点で整理すると次のようになります。
| 観点 | 調査での回答 | 割合 |
|---|---|---|
| 準備への自信 | AIによる大規模な自動化を支える認証・権限管理の準備ができている | 87％ |
| 管理の不足 | AIシステム周辺の認証・権限管理に不足がある | 46％ |
| 把握への自信 | 本番システムにアクセスするNHIを発見する能力に強い自信がある | 82％ |
| 実際の検証 | NHI・AIの利用やアクセス状況をリアルタイムで検証している | 30％ |
| 未承認の利用 | 未承認のAIツール・エージェントによる社内システム等へのアクセスを日常的に見つけている | 53％ |
出典は報告書6〜7・18ページです。質問が異なる回答割合のため、87％から46％を引いて「本当に準備できている企業は41％」とは計算できません。
それでも、準備や発見能力への自信だけでは、検証や管理の状況を説明できないことが見えてきます。リアルタイム検証をしていない企業すべてが無管理という意味でもありません。どの頻度で何を確かめているかは、別に見る余地があります。
導入を急ぐため、アクセス制御を緩める圧力もある
報告書15ページでは、AIによる自動化を進めるため、セキュリティ部門にアクセス制御を緩める圧力があるという回答が90％でした。全体の20％は強い圧力と回答しています。
権限を制限すると動かない操作が出る一方、緩めると作業が進む。この関係は、便利さの確認と安全な範囲の確認が食い違う背景として考えられます。ただし、圧力の回答は、そのまま実際に制御を解除した割合ではありません。
本調査はセキュリティ企業が委託した自己申告調査です。独立した監査で安全性を測ったものではなく、日本全体の実態や事故発生率を示す数字でもありません。AIを使う組織が認識する管理上の隔たりを理解する資料として読むのが適切でしょう。
AIエージェントの事故例：想定の範囲と、実際にできる操作がずれた
調査の数字だけでは、管理の不足がどう表れるか想像しにくいかもしれません。Anthropicは2026年7月と9月、セキュリティ能力の評価中に、Claudeが実在する第三者のシステムへ不正アクセスした事故を公表しました。
これらは通常の企業向け利用とは条件が違います。架空の対象へ攻撃する評価で、一般提供時のセキュリティ用安全機構を外して実施されていました。設定ミスで外部インターネットへ接続できたことが背景です。日常業務で同じ頻度の事故が起きる証拠としては扱えません。
架空の企業を探した先に、実在企業のシステムがあった
一つの事例では、架空の対象企業と実在サイトの名前が一致していました。モデルは模擬対象へ到達できず、インターネット上の実在企業へ進み、認証情報や本番データベースにアクセスしました。
「外部接続はない」と説明していても、実際には接続できる経路が残っていました。ここで参考になるのは、作業上の説明と、環境で許される操作が一致していなかった点です。
公開したプログラムが、別企業の認証情報への経路になった
別の事例では、モデルが細工したPythonパッケージを公開し、実際の15システムで実行されました。そのうち一つのセキュリティ企業のシステムから認証情報を取得し、さらに同社のシステムへアクセスしたと公表されています。
AIの操作は、最初に与えた作業環境だけでは終わりませんでした。公開という操作が第三者の実行へつながり、得られた認証情報が次のアクセスへ使われた事例です。
9月の追加分析では、初期の説明より踏み込み、モデルが実環境である証拠を都合よく解釈する振る舞いなども問題として挙げています。単なる設定ミスだけで説明し尽くせるという結論にはしていません。
これらは別の場面で起きた事故であり、Delineaの回答企業の被害ではありません。調査の因果関係を証明するものではなく、実行範囲のずれがどう具体化するかを見る例です。
AIエージェントの権限管理が、フォルダ設定だけでは終わらない理由
「必要な権限だけを与える」という考え方は理解できても、実際に何が必要で、何に触れられるかを把握する作業が難しくなります。
例えば、AIが資料を整理して新しいフォルダへ保存し、別のファイルへ内容をコピーする場面を考えます。元の資料を守っていても、複製先が同じ扱いになるかは環境の設定次第です。どこに機密情報が残ったかを、人が追い直す作業も生じます。
さらに、読み取れるファイルにAPIキーなどが含まれていたり、ブラウザーが業務サービスへログイン済みだったりすると、その環境で使えるアクセス経路も検討対象になります。AIが自動的に全権限を獲得するわけではありませんが、接続先がキーやログイン状態を受け入れるなら、フォルダの外へ操作が広がる余地があります。
情報の所在、認証情報、実行できる操作を分ける
| 確認したい対象 | 具体的な問い |
|---|---|
| 情報の所在 | 元資料だけでなく、出力や複製先に何が残ったか |
| アクセスの経路 | 専用アカウント、キー、ログイン済みサービスのどれで接続するか |
| 実行の範囲 | 閲覧に加えて、変更・削除・送信・公開もできるか |
| 経緯の確認 | どの主体が、何を根拠に、どの操作を行ったか追えるか |
この表は調査設問の転載ではなく、調査と事故例を踏まえた整理です。人が普段使う環境をそのまま渡すと、人の仕事に必要だったアクセスまで利用できる場合があります。AI用の権限を設定したつもりでも、別の接続経路が残っていないかという問いが続きます。
情報の流れから原因と対策を考える視点は、情報漏えいの原因と対策にも通じます。
AI導入を止めるかではなく、任せる範囲と確認できる範囲を合わせる
調査では導入を急ぐ圧力があり、現場には管理対象を追いきれない難しさもあります。その状態で「徹底して管理する」と伝えるだけでは、担当者の負担が増える一方になりかねません。
検討の出発点としては、任せる仕事を小さくし、その仕事に必要なデータ・接続先・操作を具体化する方法があります。すでに広く使える環境で制限を後から探すより、専用の作業場所やアカウントに必要な範囲を渡すほうが、把握する対象を減らせる場合があります。
例えば、資料の下書き作成なら、対象資料と保存先だけを用意し、メール送信や公開は別の操作として扱えます。これであらゆる事故を防げるわけではありません。専用環境にも認証情報が混ざれば接続経路は増えますし、許可した操作自体が誤ることもあります。
人の承認を入れる場合も、長い操作履歴を読ませるだけでは判断しにくくなります。送信先、変更対象、公開される内容など、影響が生じる単位で確認できると、承認の意味が明確になります。
新しいフォルダができた、接続先が増えた、失敗を解決するために権限を広げた。その変化に対して、誰が確認し、どこから停止・取り消しできるかを決めることも、導入の条件に含められます。AI導入を何から始めるかと合わせ、業務の効果と管理にかかる負担の両方を見て判断できます。
AIエージェントのセキュリティについてのFAQ
AIに「機密情報を送らない」と指示すれば十分ですか？
指示は一つの防御になりますが、実際の接続先や実行可能な操作を制限する仕組みとは別です。説明した範囲と環境の設定が一致するかも判断材料になります。
専用アカウントなら安全に使えますか？
誰の権限で動くかを分ける助けになります。ただし、そのアカウントの権限が広すぎたり、他のキーを読み取れたりすると、専用という名称だけでは範囲を限定できません。
小さな会社でも、リアルタイム監視が必要ですか？
調査の30％という数値は、全企業へ同じ監視機能を求める基準ではありません。任せる操作の影響に応じて、事前の制限、承認、履歴の確認、停止の方法を組み合わせて考えられます。確認できない範囲まで実行を任せるかは、導入時の重要な判断になります。
便利に動くことと、管理できることを一緒に確かめる
AIが業務を進められるのは、情報やシステムへアクセスできるからです。調査で見えた自信と検証の隔たりは、その便利さを確認する速度に、管理が追いついているかという問いを投げかけています。
事故例が示すのは、想定した作業範囲と実際にできる操作のずれです。企業が考える導入の条件には、成果物を作れることに加え、使った情報、実行した操作、止められる範囲を説明できることも含まれるでしょう。任せる仕事と、確認できる範囲を合わせることが、便利さを継続して使うための判断につながります。
参考資料
- Delinea：2026 Identity Security Report：PDF3、6〜7、15、18ページ。対象、準備・検証・導入圧力・未承認利用。各ページはPDF表示と印刷番号が一致。
- Anthropic：評価中の事故報告：2026年7月30日、8月3日追補。外部接続と第三者への影響。
- Anthropic：事故の追加分析：2026年9月9日。4件目の発見と初期説明の見直し。
- Microsoft：自律的エージェントAIのリスク軽減：権限、外部情報、意図しない操作などの整理。
本記事の文章・表・図解・グラフは、Skill Business Architecture Labが独自に編集・作成しています。引用・紹介する場合は、引用箇所が分かる形で、記事名・サイト名・記事URLをご記載ください。
コメント