結論:AIエージェント起因のセキュリティインシデントは、もはや「一部の先進企業の珍しい事故」ではありません。Cloud Security Alliance(CSA)が2026年4月に公表した調査(回答418件)では、65%の組織が過去12ヶ月以内にAIエージェント関連のインシデントを経験していました。
- 要点1:82%の組織が、セキュリティ部門やIT部門の把握していない「シャドーエージェント」を発見している
- 要点2:インシデントの内訳は機微データ露出61%・業務停止44%・意図しない操作41%と、実害を伴うものが中心
- 要点4:エージェントの正式な廃止(decommissioning)プロセスを持つ組織は21%のみ。「作る仕組み」はあっても「消す仕組み」がない
この記事の対象読者:AIエージェント導入を進めている、または検討中の中小〜中堅企業の経営者・情報システム・DX推進担当者
今日やること:自社で動いているAIエージェント(自動化スクリプト・LLM連携ツール・SaaSの自動化機能を含む)を1枚のリストに書き出してみる。リストが作れない時点で、この調査の「82%」側にいる可能性が高いです。
「うちはまだAIエージェントを本格導入していないから関係ない」と思った方、ちょっと待ってください。企業のAI活用支援の現場でよくあるのが、情シスが把握していないところで、現場の担当者がすでにLLM連携の自動化ツールを動かしているケースなんです。本人に悪気はまったくなく、むしろ業務改善の優等生だったりします。
2026年4月21日、Cloud Security Alliance(CSA)がまさにこの問題を数字で裏付けるレポート『Autonomous but Not Controlled: AI Agent Incidents Now Common in Enterprises』を公表しました。タイトルを直訳すると「自律的、しかし制御されていない:AIエージェントのインシデントは企業で日常化している」。かなり踏み込んだタイトルです。
ただ、この手の調査レポートは「65%が事故!」という見出しだけが独り歩きしがちです。実際には、調査の設計・回答者の属性・委託元の立場まで見ないと、正しく読めません。この記事では一次情報(CSA公式)にあたった上で、数字の中身と限界、そして日本の中小企業が実務に落とすなら何をすべきかまで解説します。
正直、この調査でいちばん怖いのは65%という見出しの数字ではなく、「廃止プロセスを持つ組織が21%しかない」という地味な数字だと私は考えています。その理由も後半で説明します。
CSA調査の概要|誰が・いつ・どうやって調べたのか
まず調査の基本情報を押さえておきましょう。ここを飛ばして数字だけ引用すると、社内説明で足をすくわれます。
| 項目 | 内容 |
|---|---|
| レポート名 | Autonomous but Not Controlled: AI Agent Incidents Now Common in Enterprises |
| 発行元 | Cloud Security Alliance(CSA) |
| 委託元 | Token Security(AIエージェント・マシンアイデンティティ管理ベンダー) |
| 調査時期 | 2026年1月(オンライン調査) |
| 回答数 | 418件(ITおよびセキュリティの実務者) |
| 公表日 | 2026年4月21日 |
CSAはクラウドセキュリティ分野の国際的な業界団体で、CCSK・CCM(Cloud Controls Matrix)などの資格・フレームワークで知られています。調査自体はToken Securityの委託ですが、データ分析と解釈はCSAのリサーチアナリストが実施したと公式に明記されています。
ここで1つ注意点。回答418件は「418社」と等価ではありません。回答者はITおよびセキュリティの実務者個人であり、同一企業から複数回答が含まれる可能性は否定できません。社内資料で引用する際は「IT・セキュリティ実務者418名への調査」と書くのが正確です。
数字の中身|65%の「インシデント」とは何を指すのか
過去12ヶ月で65%がAIエージェント関連インシデントを経験
調査の中心となる数字がこれです。回答組織の65%が、過去12ヶ月以内に少なくとも1件のAIエージェント関連セキュリティインシデントを経験したと回答しています。
重要なのはその内訳です。インシデントを経験した組織が報告した影響は次の通りでした(複数回答)。
| インシデントの影響 | 割合 |
|---|---|
| 機微データの露出・不適切な取り扱い | 61% |
| 業務停止(オペレーションの中断) | 44% |
| 意図しない操作・誤った操作の実行 | 41% |
| 金銭的損失(直接・間接) | 45% |
| サービス遅延(顧客向け・社内向け) | 41% |
CSAのプレスリリースによれば、インシデントを経験した組織のうち「実質的なビジネス影響がゼロだった」と回答した組織は皆無でした。つまり、AIエージェントの事故は「ヒヤリハットで済んだ」ではなく、データ露出や業務停止という形で実害につながっているということです。
「AIエージェント」の範囲は思ったより広い
ここで押さえておきたいのが、この調査における「AIエージェント」の範囲です。CSAの調査は、クラウドプラットフォーム・SaaSアプリケーション・社内システム・LLM連携ワークフローにまたがるエージェント全般を対象にしています。
つまり「AutoGPTのような自律エージェントを本格導入している企業」だけの話ではありません。SaaSに組み込まれた自動化機能、開発者が作った社内ワークフロー、LLMプラットフォーム上のカスタムツールやプラグインまで含みます。この広い定義を前提にすると、「うちにはAIエージェントはない」と言い切れる企業のほうが少ないはずなんです。
シャドーエージェント82%|「見えているつもり」の落とし穴
68%が「可視性に自信あり」なのに82%が「未知のエージェント」を発見
この調査で私がいちばん現場感があると感じたのが、この矛盾です。
- 68%の組織が「自社環境のAIエージェントに対する可視性は高い」と自己評価している
- 一方で、82%の組織が過去1年以内に、セキュリティ・IT・ガバナンス部門の把握していないAIエージェント(シャドーエージェント)を実際に発見している
- しかも41%は「複数回」発見している
「見えているつもりだったが、実際に探したら知らないものが出てきた」という構図です。これはかつてのシャドーIT問題(無許可のクラウドサービス利用)とまったく同じパターンで、対象がSaaSからエージェントに変わっただけとも言えます。
シャドーエージェントはどこに潜んでいるのか
調査では、未知のエージェントが発見された場所も聞いています。
| 発見場所 | 割合 |
|---|---|
| 社内の自動化・スクリプト実行環境 | 51% |
| LLMプラットフォーム(カスタムツール・アシスタント・プラグイン) | 47% |
| 自動化機能を内蔵したSaaSツール | 40% |
| 開発者が作成したワークフロー | 40% |
注目すべきは1位が「社内の自動化・スクリプト環境」であることです。派手な自律エージェントではなく、昔からあるスクリプトや自動化基盤にLLMが組み込まれ、いつの間にか「判断して動くもの」に進化しているケースが最多なんですね。研修の現場でも「そういえばあのバッチ、去年からAI連携させたけど誰が管理してるんだっけ」という会話は本当によく聞きます。
いちばん怖い数字は「廃止プロセス21%」だと考える理由
作る仕組みはあるのに、消す仕組みがない
冒頭で予告した通り、私がこの調査で最も深刻だと考えるのは次の数字です。
- AIエージェントの正式な廃止(decommissioning)プロセスを持つ組織は21%のみ
- 「エージェントが完全に退役した」と確信できると答えた組織は19%にとどまる
- リアルタイムの継続的モニタリングを実装している組織は16%のみ
なぜこれが怖いのか。人間の従業員なら、退職時にアカウント削除・権限剥奪・貸与物返却という「オフボーディング」の型が多くの企業にあります。ところがAIエージェントには、その型がまだ存在しないんです。
具体的にはこういうことが起きます。
- 担当者が退職したが、その人が作ったエージェントはAPIキーを持ったまま動き続けている
- PoC(実証実験)が終了した案件のエージェントが、本番データへのアクセス権を持ったまま放置されている
- SaaSを解約したのに、そのSaaSと連携していた自動化フローの認証情報が残っている
人間と違ってエージェントは「辞めます」と言いません。文句も言わず、静かに、権限を持ったまま残り続けます。65%のインシデント率は「起きた事故」の数字ですが、21%の廃止プロセス保有率は「これから起きる事故の在庫」を示す数字です。だからこちらのほうが怖いと私は読んでいます。
自律性のレベルはまだ低い。だからこそ今が設計のタイミング
一方で、調査は過度に悲観的な状況ばかりを示しているわけではありません。エージェントの自律性レベルについては次の結果でした。
- 54%:低リスク業務に限定して自律動作させている
- 24%:大半のタスクで人間の承認(human-in-the-loop)を挟んでいる
- 14%:完全自律で運用している
また、66%はエージェントの行動範囲に明確なガードレールを設けており、79%は「コンテキストを踏まえたアクセス制御(context-aware controls)」を重要と認識しています。つまり多くの組織は問題意識自体は持っていて、自律性も慎重に絞っている。ただ、棚卸し・監視・廃止という運用の足腰が追いついていない、というのがこの調査の全体像です。
この調査の限界|引用する前に知っておくべき4点
社内資料や稟議でこの調査を引用するなら、限界も併記しておくのがフェアですし、むしろ説得力が上がります。
1. サンプルは418件で、自己申告ベース
回答418件は業界調査として極端に少なくはありませんが、全企業を代表する規模でもありません。またオンラインの自己申告調査なので、「インシデント」の定義や深刻度の判断は回答者の主観に依存します。軽微なヒヤリハットをインシデントと数えた回答者もいれば、逆に検知できていない事故はそもそもカウントされていません。65%は「上振れ・下振れ両方の可能性がある数字」として扱うべきです。
2. 委託元はAIエージェントのID管理を売るベンダー
調査の委託元であるToken Securityは、マシンアイデンティティ・AIエージェントのID管理を事業とする企業です。「シャドーエージェントが危ない」という調査結果は、同社の事業と利害が一致します。だからといって数字が捏造されているという話ではなく(分析はCSAのアナリストが実施)、「課題を可視化するインセンティブを持つ主体が資金を出した調査である」という前提は頭に置いておくべき、ということです。
4. 回答者はIT・セキュリティ実務者に偏っている
回答者はITおよびセキュリティの専門家です。この層はそもそもリスクに敏感で、インシデントを認知しやすい立場にいます。経営層や事業部門に同じ質問をしたら、認知率はもっと低く出た可能性があります。逆に言えば、「現場のセキュリティ担当が見えている範囲ですら65%」という読み方もできます。
日本企業の実務に落とす|明日から着手できる4つのアクション
調査の読み解きはここまでにして、実務の話をします。100社以上のAI研修・導入支援で見てきた肌感覚として、日本の中堅・中小企業がこの調査から持ち帰るべきは次の4点です。
アクション1:エージェント台帳を作る(まず1枚のリストから)
いきなり専用ツールを入れる必要はありません。最初はスプレッドシート1枚で十分です。項目は次の7つを推奨します。
- エージェント/自動化フローの名称
- 何をするものか(1行で)
- 接続先(どのシステム・データにアクセスするか)
- 認証情報の種類(APIキー・OAuth・サービスアカウント等)と保管場所
- オーナー(人名。部署名だけにしない)
- 作成日と最終見直し日
- 停止手順(誰が・どこで・どう止めるか)
ポイントは「オーナーを個人名で書く」ことです。部署名オーナーは、異動と退職で簡単に無主物になります。調査で82%が発見した「シャドーエージェント」の多くは、最初からシャドーだったのではなく、オーナー不在化によってシャドー化したものと考えるのが自然です。
アクション2:棚卸しの担当と頻度を決める(推奨は情シス主管・四半期ごと)
台帳は作った瞬間から腐り始めます。「誰が・いつ・何を見て更新するか」をセットで決めてください。現実的な落とし所は、情報システム部門(または兼務のDX担当)が主管し、四半期に1回、各部門に棚卸しを依頼する形です。人事の入退社リストと突き合わせて「退職者がオーナーのエージェントが残っていないか」を確認する工程を必ず入れましょう。ガバナンス体制の作り方全般は、AIエージェントのガバナンスチェックリスト45項目で詳しく解説しています。
アクション4:権限を「人間のアルバイト」基準まで絞る
エージェントに与える権限は、「同じ業務を新人アルバイトに任せるとしたら、どこまでのアクセス権を渡すか」で考えると判断を誤りにくいです。調査で最多だった被害が「機微データの露出(61%)」であることを思い出してください。読み取り専用で足りるなら書き込み権限を与えない、全社データでなく特定フォルダに限定する、本番環境でなく検証環境から始める。この最小権限の原則は、AIエージェントのセキュリティ対策完全ガイドで設計手順まで踏み込んで解説しています。
アクション4:「作る手順」より先に「消す手順」を文書化する
調査が示した最大のギャップ(廃止プロセス保有率21%)への直接の対策です。新しいエージェントの導入承認フローに、次の4点の記載を必須にしてください。
- 停止条件(いつ・どうなったら止めるか。例:PoC終了時、オーナー退職時、90日間未実行時)
- 停止手順(認証情報の失効・アクセス権の剥奪・ログの保全を含む具体的な手順)
- 停止確認の責任者(「止めたつもり」を防ぐため、実行者と確認者を分ける)
「消す手順が書けない自動化は導入しない」というルールにするだけで、将来のシャドーエージェント在庫を大幅に減らせます。また、止めるべきかどうかを判断するには稼働状況が見えている必要があるので、ログ収集・監視の設計はAIエージェントのオブザーバビリティ完全ガイドを参考にしてください。
補足:既存の社内AI利用規定に「エージェント条項」を足す
すでに生成AIの利用ガイドラインを整備済みの企業も多いと思いますが、その多くは「人間がチャットで使う」場面を想定した文面になっています。エージェント(人間の操作を介さず自動で動くもの)は前提が異なるので、既存規定に次の4条項を追記することをおすすめします。
- 登録義務:外部システム・社内データに接続する自動化フローは、稼働前にエージェント台帳への登録を義務付ける
- 認証情報の管理:エージェント用のAPIキー・サービスアカウントは個人のアカウントと分離し、発行・失効の記録を残す
- 定期見直し:台帳記載のエージェントは四半期ごとにオーナーが継続要否を申告し、申告のないものは停止候補とする
4つ目の「申告のないものは停止候補」という運用は、放置されたエージェントを能動的に探すのではなく、生存申告がないものを自動的にあぶり出す仕組みです。棚卸しの負担を現場に分散できるので、専任のセキュリティ担当を置けない中小企業でも回しやすい方式です。
【要注意】この調査の引用でやりがちな失敗パターン
❌ 失敗1:「418社の65%」と書いてしまう
⭕ 正しくは「IT・セキュリティ実務者418名(件)への調査で65%」。回答単位は組織所属の個人であり、社数ベースの調査ではありません。稟議で数字の出典を突っ込まれた時に信頼を失うのはここです。
❌ 失敗2:「AIエージェントは危険だから禁止」という結論に飛ぶ
⭕ 調査が示しているのは「エージェントが危険」ではなく「管理されていないエージェントが危険」です。禁止すれば現場は申請せずに使うだけで、シャドー化がむしろ進みます。82%のシャドーエージェント発見率は、禁止アプローチの限界を示す数字でもあります。
❌ 失敗4:ツール導入だけで解決しようとする
⭕ 発見ツールを入れても、オーナー不在のエージェントを「誰が止める判断をするか」は組織の問題です。台帳・棚卸し頻度・廃止手順という運用設計が先、ツールは後です。
❌ 失敗4:一度棚卸しして満足する
⭕ 調査では41%が未知のエージェントを「複数回」発見しています。エージェントは日々増えるので、棚卸しは一度きりのイベントではなく、四半期ごとの定常プロセスにする必要があります。
インシデントの多くは把握外のエージェントから起きます。「シャドーAIの棚卸し手順」もあわせてご覧ください。
よくある質問
Q. この調査は日本企業にもあてはまりますか?
回答者の国別内訳は公表資料からは確認できないため、「日本企業の65%が事故を起こしている」とは言えません。ただし、構造的な問題(シャドー化・オーナー不在・廃止プロセスの欠如)は国に依存しない組織課題であり、日本ではむしろ兼務情シスが多いぶん棚卸しリソースが薄く、同様のリスクを抱えやすいと考えるべきです。
Q. まだエージェントを導入していない企業は何をすべきですか?
導入前が最大のチャンスです。「消す手順のない自動化は導入しない」というルールを最初から入れられるからです。すでに動いているものを後から台帳化するのは大変ですが、最初から台帳登録を導入フローに組み込めばコストはほぼゼロです。
Q. インシデントの65%という数字はそのまま信じていいですか?
「オンライン自己申告・回答418件・IT/セキュリティ実務者対象・ID管理ベンダー委託」という条件付きの数字として扱ってください。正確な母集団推計というより、「管理されていないエージェントの事故が例外事象ではなくなった」という傾向を示すデータとして引用するのが適切です。
まとめ|「65%」より「21%」を見る
CSAの調査『Autonomous but Not Controlled』のポイントを整理します。
- 65%の組織が過去12ヶ月にAIエージェント関連インシデントを経験。被害は機微データ露出61%・業務停止44%・意図しない操作41%・金銭的損失45%・サービス遅延41%と実害中心
- 82%がシャドーエージェントを発見。「可視性に自信あり68%」との矛盾は、シャドーIT問題の再来を示す
- 正式な廃止プロセスを持つのは21%のみ。「これから起きる事故の在庫」がここに積み上がっている
- ただし回答418件・自己申告・ベンダー委託調査という限界があり、引用時は条件を併記すべき
- 実務の第一歩はエージェント台帳・個人名オーナー・四半期棚卸し・「消す手順」の文書化
見出しの65%に驚くだけで終わらせず、21%というギャップを自社で埋めにいく。それがこの調査のいちばん実践的な読み方だと思います。まずは今日、自社で動いている自動化を1枚のリストに書き出すところから始めてみてください。
参考・出典
- Cloud Security Alliance: New Cloud Security Alliance Survey Reveals 82% of Enterprises Have Unknown AI Agents in Their Environments(2026年4月21日・参照日2026年7月29日)
- Cloud Security Alliance: Autonomous but Not Controlled: AI Agent Incidents Now Common in Enterprises(レポート本体・参照日2026年7月29日)
- Token Security: Autonomous, But Not Controlled: The Illusion of AI Agent Governance(参照日2026年7月29日)
次のアクション
- 自社のAIエージェント・自動化フローを本記事の7項目でリスト化してみる
- ガバナンスチェックリスト45項目で自社の運用体制を自己診断する
- エージェント運用体制の設計に外部の視点が欲しい場合は、Uravationの研修・導入支援もご検討ください
関連記事: AIエージェントの権限設計|最小権限3段階と停止手順の実務【2026年】
AIエージェント実装、設計から運用まで伴走します
PoCで終わらせない。マルチエージェント設計・MCP統合・運用体制まで、貴社の業務プロセスに合わせて構築します。
- マルチエージェント実装の実戦経験
- 初回30分無料・即日返信
お問い合わせフォームから24時間以内にUravation担当者がご返信します。



