経産省が策定を始めたAIエージェント利用企業向けセキュリティガイドライン。第1回資料は自律性×行動範囲を基本の二軸に置くが、「エージェント」という主体から入ったことで分析の単位がズレている。EchoLeakとReplitを手がかりに、機能（何を読み、何に触れ、どこへ出られるか）から入る見方を提案する。
2026年9月18日、経済産業省の産業サイバーセキュリティ研究会の下に、「事業者におけるAIエージェントの安全な利活用に関するサブワーキンググループ」が発足し、第1回会合が開かれました。
目指しているのは、AIエージェントを利用する企業向けのセキュリティガイドラインです。事務局資料（資料4）は、既存のガイドラインが開発者・提供者向けが中心で、利用企業が参照できる実務的な文書がない、という問題意識から出発しています。公表は令和8年度中の予定です。完成形を目指すのではなく、令和9年度以降も見直していく「リビングドキュメント」として運用する前提も明記されています。
資料5（事務局説明資料、NTTデータ経営研究所作成）が示す現時点の案の骨格は、次のとおりです。
先に評価すべき点を書いておきます。
リスク要因と被害（保護目的）を分けて整理した点は明快です。R10「人間の監督・承認の形骸化」、R11「責任分界の複雑化」、R12「乱立による統制困難化」を、モデルの性質ではなく利用企業側の統制の問題として横断的要因に立てた点も的確です。
ヒアリングで拾った声も生々しいものです。「権限内での意図しない自律行動は機械的な検知が困難」（金融B社）。「SaaS付随機能やローカル型を含め、横断的な把握・監視が困難」（製造A社）。これらは現場の実感そのものでしょう。
気になるのは、議論の入口です。
資料5は、エージェントの定義をAI事業者ガイドラインから準用する予定としています。「特定の目標を達成するために、環境を感知し自律的に行動するAIシステム」という定義です。これは広く、何がエージェントで何がそうでないかの線を引くには向きません。
実は、同じ資料の定義比較表には、線を引ける定義が並んでいます。AISIやNIST/CAISIの定義は、「ツール利用・行動実行の機能を持ち、現実のシステムや環境に影響を及ぼす」ことを要件にしています。
さらに根本的な問題は、分析の単位を「エージェント」という主体に置いたことです。主体として見ると、まず「どれだけ自律的か」を問いたくなります。しかし実際のリスクは、自律性の高低よりも、何につながり、何を読み、何ができる構成かで大きく変わります。
しかも今、「エージェント」はマーケティング用語です。RAG付きのチャット、ワークフロー、APIを1本呼ぶだけの機能にも、この名前が付いています。名前から入ると、そのインフレをそのまま引き継ぎます。
公平のために付け加えると、資料5も接続先や権限、データの重要度を考慮要素に挙げています。ここで問題にしたいのは、それらを見ているかどうかではありません。自律性×行動範囲を基本の二軸として先に置いた、検討の順序です。
資料5は、2025年〜2026年7月のAIエージェント関連インシデント45件を、OECDのデータベースを基に集計したとしています。一方、その直後に示す代表事例には、2024年のAir CanadaとDPDのチャットボット事案が含まれています。
少なくとも公開情報上、この2件が外部システムを操作するAIエージェントだったとは確認できません。DPDの件は、典型的なサイバーセキュリティ被害というより、出力制御やブランドリスクの事例です。また、「顧客向けプロダクトに組み込まれるエージェントは対象外」という現時点のスコープ案とも噛み合いません。
45件の集計そのものとは分けて考える必要があります。ただ、「AIエージェントのセキュリティ」を説明する代表事例の選び方にも、定義の広さが表れています。
行動範囲の最下段E1は、「参照できるが状態を変更しない」と定義されています。操作対象は限定しません。
しかし、資料自身が事例①に挙げたMicrosoft 365 Copilotの0-click流出は、「読む」ことを起点に起きた事案です。悪意ある指示を埋め込んだメールをCopilotが参照し、利用者がアクセス可能な社内機密を外部へ流出させ得る状態になりました。外部リソースの取得や画像レンダリングが許されていれば、「参照」に見える処理でも、それが外部への出口になり得ます。
外部の入力を読む、機密に触れる、外への経路がある。この3つが揃えば、状態を一切変更しなくても漏えいは起き得ます。「変更できるか」だけで段階を切ると、機密性の軸が抜けます。
コーディング支援系は、「SaaS/PaaS/IaaSを横断する開発支援ツール」としてスコープ外を想定し、「AI駆動開発は別途検討」としています。
ところが資料4が背景の筆頭に挙げたのは、GitHub MCP連携で開発者のエージェントを乗っ取り、ソースコードや暗号鍵を窃取する脆弱性でした。資料5の事例④、Replitの本番DB全削除も、コーディングエージェントの事案です。
シェルを叩き、認証情報を持ち、MCPでツールを足していく。こうした機能を広く備えて現場で動いているのが、コーディングエージェントです。製品カテゴリで線を引くと、機能面で高いリスクを持ち得るものが外れます。
L2「人間協働」は、「主要な工程で人間の承認を受ける」と定義されています。一方で資料は、R10「承認の形骸化」をヒアリングでも被害例でも重要な論点に挙げています。宛先も添付も見ずに押される承認が、それにあたります。
形だけの承認でもL2と判定されるなら、実効的な自律性を実態より低く見積もることになります。承認工程はあるからL2でも、人間が実質的に見ていなければ、挙動としてはL3に近いということです。レベル判定には、承認者が差分・宛先・送信内容を見て判断できる状態かどうか、という条件が要ります。
Replitの事例は、AISIの分類でR-12「目標からの逸脱」、R-15「ツールの誤用」、R-16「予測不可能性」に整理されています。これらが誤りというわけではありません。資料の対策欄にも、権限最小化やHITLが挙げられています。
ただ、公開情報から見える構図はもっと単純です。開発作業をするエージェントが、本番DBを変更できる構成になっていました。Replitはその後、開発用と本番用のDBを分離し、開発中にエージェントが本番DBを変更できない仕組みに改めています。
資料5が本文で新たに整理した分類でいえば、R4「ツール・権限の不備／悪用」の観点からも捉えられる事案です。モデルが予測不能だったかどうかより先に、予測を外しても本番を壊せない権限境界だったかを問う方が、再発防止には直結します。同じ事案でも、構成と権限を単位にすると、対策が先に見えてきます。
入口を「これはエージェントか」から、「この構成は何ができるか」に変えると、問いは次のようになります。
この問いなら、チャットボットもSaaS付属のAI機能もコーディングエージェントも、同じ物差しで測れます。「エージェントかどうか」の議論に時間を使う必要がなくなり、導入形態でスコープを切る必要もなくなります。モデルやツールが変わるたびに再評価する運用（金融B社が課題に挙げた点）にも、そのままつながります。
振り返れば、セキュリティは昔から、資産・経路・権限で物事を見てきました。新しい名前の主体が現れたとき、その名前から考え始めると、この基本に戻り損ねます。技術の問題というより、検討の順序、つまりガバナンス設計の問題です。
第2・3回（10月中下旬〜11月中旬）では、対策の方向性が議論される予定です。資料5自身も、自律性と行動範囲に加えて、セキュリティリスクに影響を与える要素を整理するとしています。その際に、次の3点が加わることを期待します。
ガイドラインを待つ必要はありません。社内のAI利用を、製品名や「エージェントかどうか」ではなく、上の6つの問いで棚卸ししてみてください。Copilot、Copilot Studioで作ったもの、difyのワークフロー、開発者の端末で動くClaude CodeやCodexを、同じ表に並べることになります。「読むだけだから安全」と思っていたものの中に、3条件が揃っている構成が見つかるかもしれません。
参考資料
Aikido Community Japan
公開日: 2026/9/26
最終更新: 2026/9/26
セキュリティの最新情報をお届けします。