AIエージェントに「自分の鍵」を渡していますか
僕は毎日、AIエージェント（Claude Code）に実際の作業をさせています。ファイルを読ませ、書かせ、コマンドを走らせています。だからこの調査記事は、遠い企業の話としてではなく、同じ舟に乗っている当事者の報告として読みました。
元になったのは、VentureBeatが自社で行った企業向けアンケート調査（2026年6月・107社）です。タイトルはこうでした——「企業の54%はすでにAIエージェントのセキュリティ事故を経験しており、それでもなお多くが認証情報を使い回させている」。
まず、この記事が何を言っているのかを丁寧にほどいていきます。そのうえで、僕が「これは鵜呑みにできない」と思った点と、逆に「これは効く」と唸った一点を書きます。最後に、個人として毎日エージェントを動かしている立場からの実感を置きます。
記事の骨格：「権限だけ先に渡して、閉じ込める仕組みが追いついていない」
VentureBeatはこの状況に「agent security gap（エージェント・セキュリティの穴）」という名前をつけました。意味はシンプルで、
AIエージェントに与えている「自由（自律性）」の大きさと、それを万一のとき閉じ込める「仕組み」の間に開いた距離。
エージェントは急速に増えているのに、それを管理する仕組みだけが遅れている、という話です。
記事の主張は、3つの数字に集約されます。
数字①：54%がすでに”事故”を経験している
半分以上の企業が、AIエージェントがらみのセキュリティ事故を経験しています。
ただし、ここは正確に分解しておきたいところです。この54%は2つの足し算です。
- 確認された実害：18%（本当に事故が起きた）
- ニアミス：36%（被害が出る前に食い止めた）
つまり「本当に事故った」のは5社に1社弱。残りは「危なかったが間に合った」です。VentureBeat自身も、この点を重く見ています——ニアミスが実害の倍もあるということは、企業は問題を「ギリギリの縁で」捕まえている、という意味だからです。今回はたまたま間に合った。次も間に合う保証はありません。
数字②：固有IDを全エージェントに与えているのは32%だけ
ここが記事のいちばんの核心です。
AIエージェントを動かすには、システムにアクセスするための「鍵」（認証情報＝クレデンシャル）が要ります。理想は、エージェント1体ごとに専用の鍵を発行することです。これを「scoped identity（用途を絞った固有ID）」と呼びます。
ところが、それをやっている企業は3社に1社（32%）しかいません。残りは何をしているか——鍵を使い回しているのです。共有のAPIキーだったり、ひどい場合は人間や別システムの鍵をエージェントに借りて使わせています。重複回答を含めると、107社中74社（69%）が、どこかしらで鍵を使い回しているという結果でした。
なぜこれがまずいのか。理由は2つあります。
- 被害が広がる。 1本の鍵を複数のエージェントで共有していると、そのうち1体が乗っ取られた瞬間、その鍵で開くすべてのドアが開いてしまいます。1体の事故が、共有範囲すべてに波及します。
- 犯人が特定できない。 全員が同じ鍵を使っていると、事故のあとに「どのエージェントが何をしたのか」を追えません。監視カメラはあるのに、全員が同じ制服を着ているようなものです。
VentureBeatはこれを「企業のエージェント・セキュリティで最も大きな、まだ手つかずのピース」と表現しています。
ここで一つ注意です。記事は「固有IDがないから事故が起きる」と因果を証明しているわけではありません。証明できているのは相関だけです（後述します）。ただ、比喩としての説得力は高い。「全員に合鍵を配って、誰が入ったか記録していない」オフィスが危ういのは、直感的にわかります。
数字③：高リスクなエージェントを”隔離”しているのは30%だけ
セキュリティには3段階ある、と記事は整理しています。
- 観察（Observe）：エージェントの動きを監視・記録する → 47%が実施
- 強制（Enforce）：権限を絞って、実行時に守らせる → 49%が実施
- 隔離（Isolate）：危険なエージェントを”箱”（サンドボックス）に閉じ込め、万一暴走しても被害範囲を限定する → 30%しか実施していない
VentureBeatはここで鋭いことを言います——この順番は逆だ、と。
観察は「起きたこと」を教えてくれるだけ。強制は「防ごう」とするだけ。そして防御が破られたとき、実際に被害を止めるのは隔離です。なのに、その最後の砦がいちばん採用されていない。火災報知器と消火の努力はあるのに、防火壁だけがない家、というわけです。
その穴の中で、企業はなぜか”くつろいでいる”
ここからが、この記事のいちばん皮肉の効いた部分です。
使っているのは「借り物」のセキュリティ
企業がエージェントを守るのに使っているツールは、圧倒的にモデル提供元やクラウド事業者にオマケでついてきたものでした。
- OpenAIのガードレール：51%
- Googleのクラウド機能：36%
- MicrosoftのAzure：35%
- Anthropicの管理機能：29%
一方、この問題（固有IDや隔離）を専門に解決するために作られた専業ベンダーは、軒並み一桁前半しか使われていません。82%が「主に使っているセキュリティ層」として、この”バンドル品”を挙げました。
要するに、みんな「モデルやクラウドに最初からついてきたやつ」をそのまま使っています。わざわざ専用のものを買い足してはいません。
満足度は高い。なのに、入れ替える予定
そして決定打です。このツールへの満足度は5点満点で4.2——記事いわく、この調査シリーズの中でも高い方だそうです。
ところが同じ企業の59%が、1年以内にツールを入れ替える・買い足す予定だといいます。予算も薄く（46%がセキュリティ予算の6〜10%、34%は5%以下しか割いていません）、「自分たちの防御はAIを使う攻撃者より先行している」と自信を持って答えたのは、たった35%でした。
VentureBeatはこれを「満足していると言いながら、同じ口で置き換えを準備している」と皮肉ります。快適さは、実際に守れている実績ではなく、“最初からついてきて楽だから”に乗っているだけではないか、と。
この記事を読むときに、疑っておきたいところ
……と、ここまでが記事の骨格です。よくできた記事だと思います。ただ、この手のアンケート調査の記事は、いくつか気をつけて読んだほうがいいポイントがあります。数字がひとり歩きしやすいからです。せっかくなので、その「気をつけどころ」も一緒に見ていきます。
1. 見出しの「54%」は足し算の結果です。 実害18%＋ニアミス36%。ニアミスを「事故」に数えるかは、読み手の判断です。見出しの数字だけを取り出すと、少し大げさに伝わってしまいます。
2. サンプルが弱いです。 回答は107社、自己選択（自分から答えたい人が答えた）で、確率標本ではありません。しかも従業員251〜1,000人が42%、101〜250人が25%と、中堅企業に大きく偏っています。VentureBeat自身が「これは精密な測定ではなく、方向感を示すもの」と何度も注記しています。この誠実さは信頼できますが、逆に言えば、僕たちも同じ慎重さで読むべきです。
ちなみに「中堅企業が主役」という意味ではありません。むしろ記事は「大企業ほどエージェントを多く動かし、被害も多い（1,000人超で被害率63%）」と書いています。単に回答者がたまたま中堅中心だっただけです。
3. いちばん美味しい相関が、いちばん脆いです。 記事は「鍵を共有している企業の被害率63.5% vs 固有IDを与えている企業40.9%」という数字を出します。差は歴然に見えます。ですが、後者の母数は22社中9社。少なすぎます。しかも交絡（別の原因が両方を引き起こしている可能性）が明白です——エージェントをたくさん動かす会社ほど、鍵も共有しがちで、かつ事故の機会も多い。「鍵の共有が原因で事故る」のか「規模が大きいから両方起きる」のかを、この調査は切り分けられていません。VentureBeat自身も「相関であって因果ではない」と認めています。
4. ベンダーのシェアは信じすぎないほうがいいです。 4〜5月の調査ではOpenAI 26%だったものが、6月には51%。1か月で倍増したのではなく、設問の文言が違っただけだとVentureBeatが明かしています。個々の%は緩く読み、大きなパターン（＝バンドル品が優勢）だけを信じるのが正しい読み方です。
そして、いちばん”効く”一点
疑いどころを並べましたが、逆に僕が「これはこの記事でいちばん強い」と唸った数字があります。
エージェント専用のID製品を「検討リスト」に入れている企業は、わずか12%。しかも、すでに鍵を共有していて事故った企業に絞っても、その割合は10社に1社程度でほとんど変わりません。
つまりこういうことです。事故は起きている。事故が起きると企業は動く（事故った企業の59%がツールを買い替える）。でも、動く先が間違っている。
インシデントのデータが「ここが問題だ」と最も名指ししているコントロール——固有IDと隔離——が、まさにその買い物リストからすっぽり抜け落ちています。火事に懲りて設備投資はするのに、買うのは新しい火災報知器で、防火壁は相変わらず建てない。
「対応していない」より、「対応しているのに、直すべき場所を直していない」ほうが、ずっと根が深いです。この記事の本当の発見はここだと思います。
個人として、この記事をどう受け取ったか
ここまで企業の話をしてきましたが、最後に、毎日エージェントを動かしている一人として感じたことを書きます。
僕は基本的に、エージェントには都度確認をさせています。重要なファイル操作や、課金が発生しそうな場面では、必ず声をかけてから進めるように指示しています。企業でいえば「観察」と「強制」は、個人なりにやっているつもりでした。
でも、この記事を読んで気づいたことがあります。許可を求められても、そのエージェントが今どんな作業をしていて、なぜ確認してきたのかを、僕自身が理解できていない場面がほとんどなのです。「これを実行していいですか？」と聞かれて「はい」と押している。でも、その一手が全体のどこにあたるのかは、正直わかっていない。確認しているようで、実は中身を見ずにハンコを押しているのに近い。
ヒヤッとした事故はまだありません。ただ直近で、少し焦ったことがありました。エージェントに作らせた、GitHubに保存するファイルの中に、自分のメールアドレスがそのまま入っていたのです。実害はありません。でも、プライバシーの観点で「これ、そのまま公開されるところだった」と手が止まりました。記事でいう「ニアミス36%」の、ごく個人版だと思います。
そこで気づくのは、AIエージェントの怖さは、性能そのものではなく、その「見えなさ」にあるということです。指示したその先で、実際にどんな作業をしているのか。個人情報のようなセンシティブなデータを、どう扱っているのか。それが見えないまま、出来上がったものでしか判断できない。便利さと引き換えに、僕たちは過程を手放しています。
企業が抱える「固有IDがない」「隔離していない」という穴は、規模こそ違え、個人にもそっくり当てはまります。エージェントごとに鍵を分けるどころか、そもそも「鍵を渡している」という自覚すら、個人にはありません。企業の「サンドボックス隔離30%」問題は、個人が権限確認をなんとなく素通りさせているのと、本質的には同じ構図です。
この記事を読んで、明日から変えられる一手があるとすれば、それは新しいツールを買うことではなく、「はい」を押す前に、なぜ確認されたのかを一度だけ立ち止まって考えることなのかもしれません。
まとめ
中堅企業を中心に、AIエージェントに実際の権限を渡す動きが先行しています。すでに半数以上が事故かニアミスを経験。その根には「エージェントごとに固有IDを与える土台がない（鍵を使い回している）」という構造的な弱さがある——とVentureBeatは見ています。ただし因果は証明されておらず、あくまで相関です。
数字は割り引いて読むべきですが、方向は明快です。エージェントの普及が、エージェントの安全対策を追い抜いています。 そして、いざ何かが壊れたときに最も効くコントロール（固有IDと隔離）こそ、企業がいちばん作れていない。
この穴は、プロバイダのオマケ機能が勝手に埋めてくれるものではありません。埋めるのは、企業が意図的に動くか——さもなければ、次の”確認された事故”が代わりに埋めてくれるのを待つか、どちらかです。
そしてそれは、たぶん、毎日エージェントを動かしている僕たち個人にとっても、まったく他人事ではありません。
出典：VentureBeat “The agent security gap”（VB Staff, 2026年7月16日）／VentureBeat Pulse Research、2026年6月・107社（従業員100人超）による単一ウェーブ調査。自己選択サンプルで中堅企業に偏るため、精密な測定ではなく方向感として読むべき、と原記事が注記しています。