補論④ — 防御の壁 — 検知と構造防御は別の仕事である

Telco × Agentic AI ／ 第 16 回
2026 年 8 月 ／ 著：ヒキノ ヒロユキ

🎧 音声で聴きたい方はこちら
本文を読む前に、音声で全体像をつかみたい方はこちらからどうぞ。
再生ボタンを押すだけで聴けます。

はじめに：壁シリーズの 3 本目を入れる理由

ここまで Act 1 の補論として、TM Forum との接続（第 13 回）、統制の壁（第 14 回）、観測の壁（第 15 回）を扱ってきた。

業界読者の方々と議論を重ねる中で、もう一つ、必ず同じ重さで返ってくる問いがある。

これは、第 14 回で論じた統制と、第 15 回で論じた観測と、深いところで繋がりつつ、しかし軸が違う問いである。
ここを正面から整理しておかないと、エンタープライズの設計議論では必ずどこかでつまずく。

本稿では、この問いを 「防御の壁」 と名付け、Defense in Depth（多層防御）の正しい組み方として整理する。

誤解の正体 — 検知と構造防御を、同じ層だと思っている

お客さん側の発想を分解すると、こうなる。

この前提が間違っている。
Defender / Purview と Ephemeral は、競合する役割ではなく、層が違う。
同じ層の話だと思った瞬間に「冗長」に見えるが、実際は全く別の階層で、全く別の脅威を担っている。

ここを丁寧に分けないと、議論が前に進まない。

5 層防御スタックでの位置整理

エージェントを守るセキュリティ層を、業界一般の Defense in Depth フレームに沿って整理すると、次のようになる。

ここで重要なのは、Defender や Purview は L4-L5（統制・検知） を担っており、Ephemeral は L1（アーキテクチャ） を担っている、ということだ。
両者は全く違う層で、全く違う脅威に対応している。

そして、各層は独立に必要である。
どれか一つが他を代替することはできない。
これが Defense in Depth の原則であり、エージェント時代にも全く同じ形で当てはまる。

なぜ「検知」だけでは足りないのか — Confused Deputy 問題

ここがセキュリティ的に本質的な論点である。

エージェント時代の最も厄介な攻撃の一つが、プロンプトインジェクションである。
プロンプトインジェクションの致命的な性質は、次の一点に集約される。

という、完全に正常に見える振る舞いとして現れるということだ。

検知ベースの製品（Defender / Purview）の視点から見ると、こう映る。

これは情報セキュリティの古典的問題、Confused Deputy（混乱した代理人） そのものである。
正規の権限を持った主体が、悪意ある指示で正規の権限を悪用する。
パターン認識や振る舞い分析を中心とする検知層は、構造的にこのクラスの攻撃に弱い。

ここに、検知層以外の防御層 — つまりアーキテクチャ層が必要になる理由がある。

同じ攻撃を、永続環境と Ephemeral で時系列比較する

仮想シナリオで具体的に並べてみたい。

シナリオ： プロンプトインジェクションされたエージェントが、機密データを外部送信しようとする。

永続環境（検知層のみ）

Ephemeral 環境（検知層 + アーキテクチャ層）

→ 同じアラート、同じ Defender、同じ Purview。
違いは、被害継続時間が 30 分以上 vs 0 分。

これが、L1（アーキテクチャ層）の存在意義である。
検知層は「気づく」役割、アーキテクチャ層は「気づくまでの間に被害を出させない」役割。
両者は別の仕事を担っている。

Defender / Purview は Ephemeral 環境内でも動く

ここで、お客さんの「こいつらも一緒に立ち上がるんじゃないのか」という問いに、正面から答えておきたい。

事実としては、その通りである。
W365 for Agent の各エフェメラルインスタンスには、Defender for Endpoint も Purview も統合される。
これは並列対立ではなく、直列協調の関係である。

それぞれの役割を明確に並べると、こうなる。

比喩で言うなら、Defender が「警備員と監視カメラ」、Purview が「金庫の中身のラベルと施錠」、Ephemeral が「会議が終わると部屋自体が蒸発する設計」である。
3 つは置換関係ではなく、補完関係にある。

銀行金庫の時限ロックの比喩

業界読者の方々と話す時、この比喩が一番通じる。

銀行の金庫には、警備員も、監視カメラも、警報装置も備わっている。
にもかかわらず、金庫自体には時限ロックがかかっていて、営業時間外は誰の権限でも開かない設計になっている。

なぜか。

これが、検知層と構造防御層の関係である。

エージェントの世界における時限ロックが、Ephemeral 実行環境である。
Defender も Purview も極めて重要な役割を担うが、それらは検知・対応層に属する。
Ephemeral は構造で勝負する別の層であり、両方あって初めて、ゼロトラスト設計が完成する。

検知ベースの限界を、率直に明示する

ここまで読んで、なお Defender / Purview だけで十分ではないか、と思う読者のために、検知層の限界を整理しておきたい。

これは Defender / Purview を否定するためではなく、検知層が単独では担えない領域を明示するためである。

1. 未知の攻撃パターンには弱い

   • Defender はパターンマッチングと AI 異常検知の組合せだが、新規のエージェント固有攻撃手法（OWASP Agentic AI Top 10 として編纂中）は学習データがまだ少ない

2. アラート発火と封じ込めには時差がある

   • アラートから SOC 対応までの MTTR（Mean Time To Respond）は、業界平均で 30 分〜数時間

   • この時間の間、被害は広がり続ける

3. 正規振る舞いに偽装された攻撃に弱い

   • 前述の Confused Deputy 問題

4. 横断攻撃は事後的にしか見えない

   • 複数エージェントが協調した攻撃は、Sentinel 等で相関分析するが、それは多くの場合、事後分析である

これらの限界をすべて埋めるのが、「事故が起きても被害が広がらない構造」、すなわち Ephemeral 実行環境である。

検知層と構造防御層は、それぞれが他方では埋められない弱点を持っている。
だからこそ、両方を同時に揃える必要がある。

「起動に時間がかかるんじゃないか」への補足

Ephemeral を本格的に導入する議論になると、もう一つ必ず出る問いがある。

これも、防御の壁の議論と地続きなので、ここで触れておきたい。

数字の現実

業界で Ephemeral 実行基盤を本番運用する場合、Warm Pool（予熱プール） の採用が当然の前提となる。

毎回フルコールドから起動する Ephemeral 基盤は、本番運用では存在しない。
ここを誤解したまま議論すると、Ephemeral は不利に見える。

MTTR 全体の中での位置

通信業界の障害対応 MTTR を分解すると、起動時間は全体のごく一部でしかない。

Spin-up は、AI を組み込んだ後の MTTR 全体の中でも、ごく一部を占めるに過ぎない。
本当のボトルネックは検知と切り分けであり、ここを桁で短縮することが AI の本当の価値である。

永続環境は「最悪値が読めない」

ここが反転攻勢のポイントである。
永続 Agent VM を運用する場合、平均起動時間は速いが、最悪値が予測できない。

• 設定ドリフト（config rot）により、復旧スクリプトが本番では動かない

• 認証トークンの期限切れで、復旧操作自体が認証エラーになる

• メモリリーク・ハンドル枯渇で、必要な時に限ってプロセスが落ちている

• 計画停止やパッチ適用のために、復旧能力に空白時間が発生する

Ephemeral は、毎回ゴールデンイメージから起動するため、実行時間が決定的（deterministic）である。
通信業界の SLA は平均値ではなく最悪値で評価されることを考えれば、確実性こそが選定基準になる。

ゼロトラスト原則と Ephemeral

最後に、防御の壁の議論をゼロトラスト原則の文脈に置きたい。

ゼロトラストは「Never trust, always verify（決して信頼するな、常に検証せよ）」と要約されることが多い。
しかし、エージェント時代には、もう一つの軸が加わる。

これは、Ephemeral の原則そのものである。
過去の正当性が、現在の信頼を生まない。
タスクごとに認証を切り直し、環境を切り直し、状態を持ち越さない。

これは、検知層では実現できない性質である。
検知層は「現時点で異常か」を判定する。
構造防御層は「過去の汚染が現在に伝播しない構造」を保証する。

両者を組み合わせて初めて、ゼロトラスト設計はエージェント時代に実装可能になる。

エフェメラル原則の精緻化 — 「では起動する者は誰なのか」

ここまでエフェメラルの構造的価値を強調してきた。
業界読者の方々と議論を進めると、ここで必ず次の問いが返ってくる。

この問いは、エフェメラル原則の最も重要な精緻化を要求する。
結論を先に述べたい。

二種類のエージェント — 層オーケストレーターとワーカー

エンタープライズで実装可能なエージェント基盤を分解すると、必ず次の二種類が現れる。

層オーケストレーター（業界の現場では便宜上「親玉エージェント」と呼ばれることもある、＊私だけかもしれませんが。。。）は、業務処理を直接行わない。顧客データを読まない、外部 API を直接叩かない、永続的な状態も持たない。
役割は「今このタスクに必要なワーカーを、必要な権限だけで、必要な時間だけ起動する」ことに限定される。
権限が極小であるため、仮に侵害されても被害は限定的であり、かつ常駐していても監査・パッチ・冗長化の対象として安定運用できる。

ワーカーエージェントが、実際に顧客データを読み、外部 API を叩き、コードや設定変更を行う。
ここに権限が集中するが、ここはエフェメラルである。
タスク完了の瞬間に環境ごと消滅し、トークン・キャッシュ・状態はすべて揮発する。

ここで、前出の「永続環境は最悪値が読めない」の議論と矛盾しないことに注意したい。
最悪値が読めなくなるのは、業務処理を直接行う層を常駐させた場合である。
層オーケストレーターは業務を行わず、ワーカーを起動するだけの層であり、攻撃面が桁で小さい。
両者は「常駐」という言葉は共通でも、設計上はまったく別の存在である。

Kubernetes Control Plane と Pod の関係

この構造は、コンテナ運用の業界読者には一発で通じる比喩がある。

Kubernetes における Control Plane（kube-apiserver、scheduler、controller-manager） は常駐し、Pod はエフェメラルである。
Control Plane は業務ロジックを実行しないが、Pod の生死を管理する。
業界がコンテナ運用 10 年で到達した「常駐 + エフェメラルの分業」と、エージェント基盤がこれから到達する構造は、本質的に同じ形である。
新しい原則ではなく、業界が既に学習した原則の再適用である。

L3 と L4 の技術的境界

エフェメラル原則を上記の通り精緻化すると、TM Forum AN の Maturity Level の境界も、技術的に明確になる。

L3 までは、観測・判断・実行の全体ループは閉じている。
しかし、各層内部で障害やワーカー異常が起きた時に、それを起動し直す・差し替える存在がいないため、人間が介入せざるを得ない。

L4 は、各層内に層オーケストレーターが常駐し、ワーカーの起動・監視・差し替えを自律的に行う。
人間の介在位置は、層内処理から層間例外と高ブラスト半径判断に引き上がる。

つまり、層オーケストレーターの存在は、防御の壁の議論であると同時に、L3 → L4 を技術的に成立させる条件でもある。

このより広い構造論 — メタオーケストレーター・各層の層オーケストレーター・ワーカーエージェントが三段で並ぶ多段アーキテクチャ — は、本連載の Act 2 でより精密に扱う予定である。
本稿（防御の壁）では、エフェメラル原則の中に常駐層が必要であること、そしてそれが攻撃面を増やすのではなくむしろ整理する設計であることを明示するに留めたい。

統制の壁・観測の壁・防御の壁 — 三つの壁の関係

ここまで補論として、3 つの壁を順に扱ってきた。
これらは独立した議論ではなく、深いところで繋がっている。

三つの壁は、同じ実行ごとに、同じ粒度で、同じタイミングで統合されていなければならない。
別々の製品・別々のベンダーで層を組むと、層と層のつなぎ目から事故が漏れる。
これが、第 12 回の「5 条件を同一ベンダーで揃える」が、統制・観測・防御の三軸で同時に効いてくる理由である。

次回予告：最終回 — Act 1 の総括と Act 2 への接続

ここまでで、Act 1 の議論はすべて出揃った。
理論（第 1 〜 12 回）、補論①（TM Forum・第 13 回）、補論②（統制の壁・第 14 回）、補論③（観測の壁・第 15 回）、補論④（防御の壁・本稿）。

次回（第 17 回）は、Act 1 の最終回として、これらを 1 枚の構造図に圧縮する。
そして、本連載が続く Act 2 — Agentic AI Runtime という、より大きな方法論の議論 — への接続を行う。

実行層・統制層・観測層・防御層 — これらは、業界が今後 10 年向き合う新しいインフラレイヤーの構成要素である。
その全体像をどう描き直すかが、最終回のテーマとなる。

注意事項（再掲）

• 本記事は個人としての見解であり、所属組織を代表するものではありません。

• NIST、OWASP、CSA 等の標準・フレームワークについては、各団体の公式資料が最新かつ正確な情報源です。

• セキュリティ製品（Defender、Purview、Sentinel、Entra 等）の具体的な機能・仕様は、各製品の公式ドキュメントをご参照ください。

• 各国規制（GDPR、APPI、電気通信事業法等）の具体的な解釈・適用は、各組織の法務・コンプライアンス部門および規制当局の判断に従ってください。

連載インデックス

• 第 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 への接続

本記事 約 6,800 字 / 読了 20 分

著者：ヒキノ ヒロユキ
通信業界 20 年。3G・4G・5G モバイルコアネットワーク設計 ／ 元 Cisco ネットワークエンジニア ／ 現 Microsoft（個人としての発信） ／ ディエスタデイ合同会社 代表

ご意見・ご質問は記事コメントまたは LinkedIn にて、お気軽にどうぞ。

もし本連載に共感いただけたら、ぜひ note のスキ・フォロー、LinkedIn でのリポストをお願いします。