95% は人のミスで起きる — エージェント ID という新しい主戦場
Telco × Agentic AI ／ 番外編（第 7.5 回）
2026 年 6 月 ／ 著：ヒキノ ヒロユキ
🎧 音声で聴きたい方はこちら
本文を読む前に、音声で全体像をつかみたい方はこちらからどうぞ。
再生ボタンを押すだけで聴けます。
本記事は個人としての見解であり、所属組織を代表するものではありません。
本稿で取り上げる統計・製品・取り組みは、いずれも公開情報に基づきます。
引用元については本文中に明記しています。
はじめに：いったん「実行層」から離れる
ここまでの連載では、自律ネットワーク（AN）の実行層を埋めるための 頭・手・統制 の 3 要素と、それを単一基盤として実装し始めた Windows 365 for Agents（W365A） を論じてきた。
2026 年 6 月の Microsoft Build 2026 で W365A が Windows Cloud の主要発表として正式に打ち出されたことで、この議論は「実行層が必要かどうか」ではなく、実行層が現れた後に何を統制するのかという問いに移り始めた。
第 7 回で W365A の統制（Governance）レイヤーを扱った際、私はこう書いた。
Microsoft Entra ID に参加した正規のアイデンティティ
Microsoft Intune によって管理された Cloud PC
セッションログと監視ツールによる完全な可観測性
これは「便利な機能セット」ではなく、業界が L4 自律運用に到達するための必然だ — というのが今回の主張である。
そしてその必然は、製品論ではなく 情報セキュリティの本質論 から導かれる。
そこで今回は、次回（第 8 回 Project Opal）に進む前に、いったん 「ID」という背骨 に焦点を当てたい。
きっかけは、ある場で受けた素朴な問いだった。
「セキュリティインシデントの 9 割以上は内部犯行だと聞いたことがあるけど、本当ですか？」
この問いを掘っていくと、現代の AI エージェント時代に直結する重要な論点に行き着く。
本稿はその記録である。
「9 割超は内部犯行」は本当か — 数字を整理する
まず、よく聞く「内部犯行 9 割超」という言説の出どころを整理したい。
結論から言うと、この数字は出どころによって 20% から 95% まで大きく振れる。
理由は、「内部」「犯行」「ヒューマンエラー」の 定義がバラバラ だからだ。
代表的な数字を 4 つ並べる。
① 日本：JNSA「情報セキュリティインシデントに関する調査」
JNSA（日本ネットワークセキュリティ協会）の「2015 年 情報セキュリティインシデントに関する調査報告書」では、個人情報漏えいインシデントの要因の 約 8 割が内部要因（誤操作・管理ミス・不正な持ち出し等）に分類されている。
この数字が、日本国内で「情報漏えいの 8 割は内部」という言い回しの源流になっている。
② 日本：IPA「組織における内部不正防止」関連調査
IPA（情報処理推進機構）が継続的に行っている内部不正に関する調査では、内部不正に関与した経験者のうち 約 6 割が「うっかり違反した」「ルールを知らずに違反した」 といった故意のない違反であり、明確に悪意ある意図的な犯行は 約 4 割 という結果が報告されている。
つまり「内部要因 8 割」のうちの大半は、メール誤送信・設定ミス・規程未理解といった ヒューマンエラー であり、悪意ある内部犯行はその一部にすぎない。
③ グローバル：Mimecast「State of Human Risk」等で広く引用される推計
グローバルでは、Mimecast の「State of Human Risk」レポート等で広く引用される推計として、データ侵害の最大 95% にヒューマンエラーが関与している という数字がある。
おそらく冒頭の「9 割超」という記憶は、この系統の数字が口伝てで丸められたものだろう。
④ グローバル：Verizon DBIR
Verizon の年次レポート「Data Breach Investigations Report（DBIR）」では、侵害事案の 6〜7 割程度に human element（人的要素）が関与 している一方、純粋な意味での 内部アクター（internal actor）起因は約 2 割 にとどまる、という整理が示されている（年度により変動）。
整理：数字は幅で読む
これらをまとめると、こうなる。
| 視点 | 数字 |
|---|---|
| 意図的な内部犯行（悪意） | 全体の 20〜30% |
| ヒューマンエラーを含む「人由来」 | 全体の 80〜95% |
「9 割超が内部犯行」は誇張だが、「9 割近くが人由来」は妥当な近似だ。
そして本稿で扱いたいのは、この後者 である。
ファイアウォールでは守れない、構造的な理由
ヒューマンエラー由来のインシデントは、なぜ厄介なのか。
それは、境界防御（Perimeter Defense）が原理的に効かない からだ。
攻撃の典型例を考えてみる。
フィッシングで盗まれた 正規のクレデンシャル が攻撃に使われる
退職者のアカウントが残っていて、そこから侵入される
設定ミスで本来非公開のはずのストレージが公開状態になる
「うっかり」共有設定でファイル全社公開になる
これらに共通するのは、攻撃や事故の入り口が「正規の認証情報」「正規の操作」である ことだ。
このとき、
ファイアウォールには「正規ログイン」に見える
EDR には「正常なユーザー行動」に見える
アラートは原理的にトリガーされない
なぜなら、認証は本物であり、権限も本物であり、操作も仕様通りだからだ。
キーボードの向こうにいる人間（あるいは意図）だけが違う。
ここに、境界防御の構造的限界がある。
私自身、前職の Cisco で長くネットワークセキュリティに関わってきた。
ZTNA（Zero Trust Network Access）／SASE／SSE といったキーワードが業界を覆ったのは、まさに 「脅威は外側ではなく内側にある」 という統計的事実を、業界全体が遅まきながら直視した結果だ。
結論はシンプルだ。
本質的な防御レイヤーは、ID（Identity）・IGA（Identity Governance and Administration）・内部統制である。
ファイアウォールや EDR を否定しているのではない。
それらは必要だが、それだけでは 9 割の入り口を塞げない という話だ。
同じ問題が、エージェントにも適用される
ここから先が、本稿の本題である。
「ヒューマンエラーが 9 割」「ID 管理が本質防御」という構造は、そのまま AI エージェントの世界に適用されつつある。
なぜか。
理由は 1 つ。
AI エージェントは、新しい「ユーザー」だからだ。
そして、今、業界では極めて危うい運用が常態化している。
「クレデンシャル又貸し」問題
エージェントを動かすために、現場では何が起きているか。
開発者の個人アカウントの API キーをエージェントに渡す
サービスアカウント 1 つを複数のエージェントで使い回す
LLM 経由のツール呼び出しで、人間用のトークンをそのまま流用する
エージェントが操作したログが、結局「人間 A の操作ログ」として記録される
つまり、人間の ID をエージェントに「又貸し」している 状態だ。
この状態だと、何が起きるか。
| 問題 | 帰結 |
|---|---|
| エージェントの行動が人間のミスと区別できない | 監査で原因切り分け不可能 |
| エージェントが暴走しても「人間の操作」として記録される | 責任の所在不明 |
| エージェント単位の権限制御ができない | 最小権限の原則が破綻 |
| エージェントを停止しても、別の経路で同じトークンが使われる | ライフサイクル管理不能 |
これは、第 4 回で論じた 「統制なき実行は本番に出せない」 という制約の、エージェント版そのものだ。
そして 1 つ厳しい事実を述べておきたい。
「エージェントが悪さしました、すみません」では済まない世の中になる。
通信業界で考えれば自明だ。
夜間メンテで AI エージェントが間違えてコア装置を停止した — その結果、緊急通報がつながらなくなった — このとき「エージェントのバグでした」では、規制当局も社会も納得しない。
誰の権限で、どのエージェントが、何を、なぜ実行したか — これが説明できない自律運用は、本番投入できない。
業界はもう動き出している
幸い、業界はこの問題に気づき、急速に動き始めている。
標準化レイヤーで起きていること
2026 年 4 月の RSA Conference（RSAC 2026） では、複数の ID／セキュリティベンダーが、AI エージェント向けの ID 管理（Agent Identity） をテーマにした発表を相次いで打ち出した。
ID 系の主要ベンダー、EDR 系の主要ベンダー、ネットワークセキュリティ系の主要ベンダー、ハイパースケーラー — それぞれが、これまで人間とサービスアカウントしかなかった ID モデルに、「エージェント」という第三のクラス を追加する方向に動いている。
業界調査では、現状のままで AI エージェントの ID を効果的に管理できると考えているセキュリティリーダーは 少数派にとどまる と報じられている。
全社的なエージェント ID 戦略を持っている組織は、ごく一部にすぎない。
つまり、業界の認識は 「やらねばならない」と「まだできていない」のギャップが極めて大きい 状態にある。
Gartner 等の予測
Gartner 等の調査会社は、今後数年のうちに、最小限の人間介入で自律的に動作する AI エージェントを本番展開する企業の比率が、急速に拡大する と予測している。
つまり、エージェント ID 管理は 「整備されてから本番投入」では間に合わない。
本番投入と並走しながら整備が走るフェーズに入っている。
Cisco 側のアプローチ
Cisco は、買収した Duo Security を起点に、エージェント向けの ID 管理プラットフォーム化を進めている。
公開されている情報の範囲では、エージェントを「ファーストクラスの ID オブジェクト」として登録し、独自のポリシー・認証・ライフサイクル管理を持たせる方向性が示されている。
また、AI ゲートウェイ という概念で、エージェントのトラフィックを集約し、認可判断をリアルタイムで行う設計が打ち出されている。
これは、Cisco の SSE／ZTNA の系譜の延長線として、極めて自然な進化だ。
Microsoft 側のアプローチ
一方の Microsoft は、Microsoft Entra 上に Microsoft Entra Agent ID という仕組みを設け、エージェントを人間・サービスアカウントとは区別された ID 基盤の上に位置付けている。
Entra Agent ID は、エージェントを Entra ID 上の独立した識別子（service principal）として扱い、固有の権限・ライフサイクル・監査の対象にする。
W365A における「エージェントが Entra ID 配下で動く」という設計も、この大きな流れの一部だ。
W365A は Entra ID と Intune の管理境界内でエージェントを動かす実行環境として位置付けられている。
連載第 7 回で扱った W365A の統制レイヤーが、Entra ID という背骨の上に乗っている ことの戦略的意味が、ここで初めて見えてくる。
さらに同じ時期に、Microsoft Scout というデスクトップ型の AI アプリケーション（Windows / macOS 向け）も Frontier preview として公開された。
Scout は、ファイル・シェル・ブラウザ・Microsoft 365 データに対して、自然言語の指示にもとづき「利用者の代わりに（on your behalf）」操作を実行するエージェントである。
ここで ID の観点から重要なのは、機能一覧そのものではなく、**Scout が「どの ID で動くか」**だ。
公式ドキュメントによれば、Scout は 利用者自身の Microsoft 365 ID で認証し（Windows では MSAL + WAM を使用）、その利用者に許可された権限の範囲内でのみ動作する。すなわち Scout は、エージェントが固有の ID を持つ「自律（own identity）」型ではなく、利用者の ID を委譲されて動く「委譲（delegated／on-behalf-of）」型のエージェントに相当する。
この対比こそが、本稿で論じてきたエージェント ID の核心である。
Microsoft Entra の整理でも、エージェントの動作パターンは大きく 2 つに分かれる。
自律（autonomous）型：エージェントが固有の IDを持ち、アプリケーション権限で動く（バックグラウンド処理・スケジュール実行など）
対話・委譲（interactive）型：エージェントが利用者の ID を委譲され、その利用者の権限の範囲で動く（利用者随伴のアシスタントなど）
Scout は後者（委譲型）の具体例であり、前者（固有 ID 型）は Microsoft Entra Agent ID が担う。
そして Microsoft は、このどちらの型も Entra・Intune・Purview・Microsoft 365 の統制境界の中に載せる構成を取っている。
これは、エージェント ID が抽象論ではなく、実際の製品設計の中心に入り始めたことを示している。
Cisco × Microsoft が同じ方向を向いた瞬間
私自身、元 Cisco のネットワークエンジニアから現 Microsoft という、やや珍しいキャリアを持っている。
両社の文化や製品観の違いはよく知っているつもりだ。
その私から見て、今回のエージェント ID というテーマは、両社が極めて似た方向に収束している 数少ない領域だ。
Cisco：ネットワーク／ID（Duo）／AI ゲートウェイの統合
Microsoft：Entra ID／Intune／W365A／Copilot の統合
入り口は違う（Cisco はネットワーク側から、Microsoft はモダンワーク側から）が、出口の構造は同じだ。
エージェントを、人間とサービスアカウントから区別された「第三の ID クラス」として扱う。
そのエージェントに、固有の ID、独自のポリシー、独自のライフサイクル、独自の監査ログを持たせる。
すべてのエージェント操作を ID 基盤の認可判断を経由させる。
この方向性が、両社で一致している。
そして、ID／セキュリティ系の他主要ベンダーも同じ方向に動いている。
これは事実上、業界デファクトが形成されつつあるということだ。
結びに：第 7 回 W365A の意味が変わる
ここで連載第 7 回に戻りたい。
W365A は、エージェントが Entra ID 配下で動き、Intune で管理され、セッションログで監査される。
Build 2026 後の文脈で読み直すと、これは「便利な統制機能の組み合わせ」ではなく、エージェントを本番環境で動かすための前提条件として見えてくる。
つまり、本稿の文脈では、意味が少し変わる。
ヒューマンエラー由来が 9 割という現実
境界防御では原理的に守れないという構造
それを克服する本質防御レイヤーが ID であるという業界合意
そして、その ID 論理がエージェントにも適用されるという必然
業界全体が「エージェント ID」というデファクトに向けて動き出している現状
これらをすべて踏まえた上で、W365A の Entra ID 統合は 「便利機能」ではなく必然 であり、自律ネットワーク L4 到達のための 欠かせない前提条件 である。
逆に言えば、エージェント ID 基盤を持たない実行基盤は、本番ネットワークでは使えない。
通信業界が L4 自律運用に向かうためには、
実行基盤（W365A 的なもの）
エージェント ID 基盤（Entra Agent ID／Cisco Duo 的なもの）
の 両輪 が必要になる。
経営層・CISO・運用責任者の方々へ — 「野良かどうか」で見直す
最後に、実務的なお願いを 1 つ。
通信業界の経営層・CISO・運用責任者の方々には、自社の AI エージェント導入計画を、「野良かどうか」という 1 軸 で総点検することをお勧めしたい。
判定基準はシンプルだ。次の 4 つの問いに、すべて「Yes」と即答できるか。
そのエージェントは、固有の ID を持っているか（人間や他エージェントと混ざっていないか）
そのエージェントの権限は、最小権限 で絞られているか（root 相当の包括権限を渡していないか）
そのエージェントの操作は、人間と区別された監査ログ に残っているか（「誰がやったか」が説明できるか）
そのエージェントは、停止・退役のライフサイクル管理下 にあるか（消し忘れトークンが本番に残っていないか）
どれか 1 つでも答えが「No」なら、それは 野良エージェント だ。
そして、本稿で見てきた通り、ヒューマンエラー 9 割の世界において、野良エージェントは 境界防御では検知も制御もできない。
規制対応上も、説明責任上も、経営判断上も、野良エージェントを本番ネットワークで動かすことは、もはや許容できない時代に入っている。
「野良エージェント、許容せず」 — これが、今後 1〜2 年で企業ガバナンスの常識になる。
そして、それを支える基盤は、すでに業界の主要ベンダーから出揃いつつある。
問いは「やるかどうか」ではなく、「いつ、どの順序で整備するか」に移っている。
次回：本筋に戻って Project Opal へ
番外編はここまで。
次回は、当初の予告通り、Project Opal — オーケストレーション層という未開拓地 に戻る。
実行層（W365A）の上で、エージェントがチームとして動く ための仕組み。
Ansible Playbook 的な「手順書ベースの自動化」とは、何が決定的に違うのか。
第 6 回までの抽象論が、また別の角度から具体製品で姿を現す回になる。
注意事項（再掲）
本記事は個人としての見解であり、所属組織を代表するものではありません。
本稿に登場する製品・取り組みは、すべて公開情報に基づきます。未公開情報・社内資料には触れていません。
引用統計は、公開レポート・公式発信・業界報道で確認できる範囲のものです。
JNSA「2015 年 情報セキュリティインシデントに関する調査報告書」
IPA「組織における内部不正防止」関連調査
Mimecast「State of Human Risk」等で引用される推計
Verizon「Data Breach Investigations Report」各年版
RSAC 2026 関連の各社公開発表・業界二次報道
Gartner 等の調査会社による AI エージェント関連予測
各社製品の具体仕様・ロードマップは、必ず公式情報源で最新の正確な情報をご確認ください。
参照（主な出典）
Microsoft 公式ドキュメント（Microsoft Learn）
Microsoft Scout（概要） — https://learn.microsoft.com/microsoft-scout/overview
Microsoft Scout の利用開始（サインイン／MSAL + WAM 認証） — https://learn.microsoft.com/microsoft-scout/get-started
Microsoft Scout 責任ある AI 概要 — https://learn.microsoft.com/microsoft-scout/microsoft-scout-responsible-ai-overview
エージェント ID アーキテクチャの計画（自律型／対話型パターンの比較） — https://learn.microsoft.com/entra/agent-id/how-to-plan-agent-identity-architecture
エージェント ID とは（Microsoft Entra Agent ID） — https://learn.microsoft.com/entra/agent-id/what-are-agent-identities
Windows 365 for Agents（概要） — https://learn.microsoft.com/windows-365/agents/introduction-windows-365-for-agents
注：Microsoft Scout は本稿執筆時点で Frontier preview、Microsoft Entra Agent ID も preview を含みます。一方 Windows 365 for Agents は Build 2026 で一般提供（GA）として打ち出されています。仕様・名称・提供範囲は変更され得ます。最新情報は各公式ページをご確認ください。
Cisco
Cisco の AI／エージェントセキュリティ（Duo・AI ゲートウェイ関連の公開情報）
引用統計の出典
JNSA「2015 年 情報セキュリティインシデントに関する調査報告書」
IPA「組織における内部不正防止」関連調査
Mimecast「State of Human Risk」等で引用される推計
Verizon「Data Breach Investigations Report」各年版
連載インデックス
第 1 回：自律運用の壁 — なぜ L3 で止まるのか
第 2 回：AN Level 4 への到達条件 — 観測・判断・実行の 3 層構造
第 3 回：実行層という空白 — なぜ業界全体が詰まっているのか
第 4 回：頭・手・統制 — 実行層に必要な 3 要素
第 5 回：3 要素マトリクス — 既存アプローチを再評価する
第 6 回：Agentic AI ランタイムという新しい地平
第 7 回：Windows 365 for Agent — 業界が待っていた「実行層の基盤」が姿を現した
番外編（第 7.5 回）：95% は人のミスで起きる — エージェント ID という新しい主戦場（本稿）
第 8 回：Project Opal — オーケストレーション層という未開拓地
第 9 回：Telco AN への適用① — 障害対応クローズドループ
第 10 回：Telco AN への適用② — サービス展開とベンダー GUI の壁
第 11 回：Telco AN への適用③ — 自己修復・自己最適化と Learning Loop
第 12 回：Why Microsoft — 構造的優位の理論
第 13 回：補論① — TM Forum AN フレームワークと本連載の接続
第 14 回：補論② — 統制の壁、その本当の高さ
第 15 回：補論③ — 観測の壁 — Substrate Observability から Outcome Observability へ
第 16 回：補論④ — 防御の壁 — 検知と構造防御は別の仕事である
第 17 回（最終回）：自律ネットワークの実行層、その先へ — Act 1 総括と、Act 2 への接続
本記事 約 4,800 字 / 読了 14 分
著者：ヒキノ ヒロユキ
通信業界 20 年。3G・4G・5G モバイルコアネットワーク設計 ／ 元 Cisco ネットワークエンジニア ／ 現 Microsoft（個人としての発信） ／ ディエスタデイ合同会社 代表
ご意見・ご質問は記事コメントまたは LinkedIn にて、お気軽にどうぞ。
もし本連載に共感いただけたら、ぜひ note のスキ・フォロー、LinkedIn でのリポストをお願いします。