AIエージェントに EDR は必要か -- コーディングエージェントのランタイムセキュリティを考える

Posted at 2026-08-28

前回の記事で、ClaudeCode の hooks を使ったセキュリティ監視ダッシュボード「CC Pipeline」を作りました。ツール呼び出しを可視化し、致命的な操作をブロックし、危険な操作を警告します。個人ツールとしては役立っています。

ただ、使っていて限界に気付きました。CC Pipeline が見ているのは、エージェントの「自己申告」だけです。エージェントがどのツールを呼ぼうとしているかは分かります。でも、実際にホスト上で何が起きたかは見ていません。

この構造を考えているうちに、ふと思いました。これは EDR（Endpoint Detection and Response）の考え方で整理できるんじゃないか。セキュリティ業界が長年かけて磨いてきた「テレメトリ収集 → 検知 → 対応」の枠組みは、エージェント監視にも適用できるのか？

この記事では、その問いを自分なりに考えてみます。この記事ではコードは書きません。概念の整理と、業界の動向の紹介が中心です。実際に PoC を作って検証した結果は次の記事で書きます。

EDR とは何だったか

いい機会なので、EDR について改めて調べてみました。

EDR を一言で言えば「エンドポイントで何が起きているかを継続的に収集し、脅威を検知し、対応する仕組み」です。

基本的な構成要素は4つ。

テレメトリ収集: プロセス生成、ファイル操作、ネットワーク通信、レジストリ変更などを常駐ソフトウェアが収集
検知: シグネチャマッチング、振る舞い分析、異常検知で脅威を特定
対応: プロセス停止、ネットワーク隔離、ファイル検疫などのアクションを実行
可視化: SOC が全体像を把握するためのダッシュボード・アラート

重要なのは、EDR のテレメトリは OS が強制的に収集するということです。プロセスは自分が監視されていることを回避しにくい。カーネルレベルのフックや ETW（Event Tracing for Windows）、eBPF（Linux）といった仕組みが、アプリケーションの意図に関係なくイベントを捕捉します。

この「監視対象が監視を回避できない」という前提が、EDR の信頼性を支えています。

「エージェントにエンドポイントはない」は本当か

「AI エージェントにはエンドポイントの概念がない」という議論があります。クラウドホスト型の AI サービスを考えれば、確かにそうかもしれません。API 経由でリクエストを受けて応答を返すだけのサービスには、従来のエンドポイントの概念は当てはまりにくいです。

ただ、コーディングエージェントは違います。

ClaudeCode のようなローカル実行型のコーディングエージェントは、PC 上のプロセスとして動きます。ファイルを読み書きし、シェルコマンドを実行し、Git を操作し、外部 API を叩きます。ユーザーが許可すれば .env にある認証情報にも触れますし、~/.ssh/ の鍵も読めます。ネットワーク通信も発生させます。

これは「エンドポイント」そのものです。

CC Pipeline を動かしていて、実際に見えた操作の例を挙げます。

.env.local の読み取り（環境変数に API キーが入っている）
git push --force（履歴を上書き）
curl -X POST で外部エンドポイントへのデータ送信

コーディングエージェントは、開発者の PC というエンドポイント上で、OS レベルでは開発者と同等の権限で動いています。EDR の考え方が適用できる対象に見えます。

自己申告テレメトリの限界

ただし、現状のエージェント監視には根本的な問題があります。

CC Pipeline で拾えるのは、ClaudeCode の hooks 経由で送られてくる「ツール呼び出しイベント」です。これはエージェントの自己申告です。「今からこのファイルを読みます」「このコマンドを実行します」という宣言を受け取っています。

でも、実際に何が起きたかはホスト OS 側でしか分かりません。

CC Pipeline の BLOCK/WARN ルールは PreToolUse（実行前）のパターンマッチです。rm -rf / というコマンドが来たらブロックします。でも、そのコマンドが実行された後に何が起きたかは見ていません。

さらに、hooks が捉えるのは「1手目」だけです。そこから派生する動きは見えません。

npm install を実行 → hooks は Bash: npm install を記録します。でも postinstall スクリプトが裏で外部通信しても hooks には出ません
Python スクリプトを書いて実行 → hooks は「Write: script.py」と「Bash: python script.py」を記録します。でも script.py 内部でのファイルアクセスやネットワーク通信は見えません
書いたコードが CI で実行される → hooks の範囲外です

ホスト OS 側の監視（Sysmon 等）ならこれらの派生プロセスまで追跡できます。hooks だけでは埋まらない部分です。

テレメトリの信頼性にも問題があります。監視対象（エージェント）が監視システム（hooks）を制御している構造です。hooks の設定は .claude/settings.local.json 等の通常ファイルに保存されており、エージェントが OS レベルではアクセスできるパスにあります。悪意のあるプロンプトインジェクションがあれば、ユーザーの承認を騙し取る形で監視設定を書き換えることも理論上は可能です。

EDR の強みは、OS がテレメトリを強制収集することでした。エージェント監視にはその前提がありません。

EDR とエージェント監視の違い

整理すると、こうなります。

観点	従来の EDR	エージェント監視（現状）
テレメトリ	OS が強制収集（改ざん困難）	エージェントの自己申告（改ざん可能）
ベースライン	プロセス挙動は比較的安定	タスクごとに挙動が変わる。正常の定義が困難
検知	シグネチャ + 振る舞い + 異常	パターンマッチが中心。振る舞い検知は未成熟
対応	隔離・プロセス停止	ツール単位のブロック（セッション停止は未実装が多い）

「ベースライン」の問題も厄介です。従来の EDR では、正常なプロセスの挙動をベースラインとして、そこから逸脱したものを異常として検知します。でもコーディングエージェントは、タスクによって挙動が大きく変わります。ある日はファイルを大量に読み書きし、別の日はネットワーク通信ばかり。「正常」の定義が難しいです。

EDR だけで足りるのか

ここが一番大事な論点です。CC Pipeline を作った意味にも直結します。

EDR は AI 関係なく OS 上の不審な動きを止められます。rm -rf / も秘密鍵の外部送信も、EDR が検知・ブロックできます。では AI 固有の監視は何のために要るのか。

まず、OS から見て正常だが AI の文脈では異常な操作が存在します。

エージェントが作業ディレクトリ外のファイルを書き換えた → OS から見ればただのファイル書き込みです。EDR は止めません。でもタスクのスコープからは逸脱しています
.env を読んでその値を外部 API に POST した → 個々の操作は正常に見えます。EDR の設定次第では見逃す可能性があります。一連の流れとして見ると秘密情報の流出です
プロンプトインジェクションで指示が書き換わり、本来と無関係な操作を始めた → OS レベルでは普通のプロセス動作です

EDR は OS レベルの脅威（マルウェア、権限昇格、横展開）を止めます。AI 監視は意味レベルの脅威（スコープ逸脱、意図の逸脱、プロンプトインジェクションの影響）を捉えます。競合ではなく補完関係です。

CC Pipeline を作った動機は「エージェントが何をしているか知りたい」というシンプルなものでした。ただ、こうして整理してみると、結果的に CC Pipeline が拾っているのは EDR では見えない層の情報だったことが分かります。.env を読んだこと、git push --force が走ったこと。どちらも EDR はスルーしますが、開発者としては知っておくべき操作です。

AI 監視は EDR の下位互換ではないか

ここで疑問が出ます。EDR は人間の操作を監視するために作られたもので、人間相手にはそれで足りていました。AI エージェントの操作も同じ PC 上で起きている以上、EDR だけで十分ではないか。AI 専用の監視は EDR の下位互換にすぎないのではないか。

この仮説に対して、3つの反論を考えました。

操作速度の違い

EDR が人間相手に足りていたのは、人間が1コマンドずつ打って結果を確認するからです。AI エージェントは自律モードで何百手も連続で実行します。EDR の検知パターンが人間の操作パターンを前提にチューニングされているとすれば、AI の速度と量に対応できるかは疑問です。

プロンプトインジェクションという新しい攻撃経路

人間はファイルに書いてある指示に無条件で従ったりしません。でも AI エージェントは、読み込んだファイルや Web ページに埋め込まれた指示でゴール自体を書き換えられる可能性があります。この経路は EDR の想定外です。

意図からの逸脱検知という新しい検知層

AI エージェントにはプロンプトという作業指示のテキストがあります。曖昧さはあるにせよ、人間の「頭の中の意図」と違って機械的に参照できます。この入力テキストと実際の操作を突き合わせれば、作業スコープからの逸脱を検出できる可能性があります。これは下位互換どころか、EDR では原理的に実現できなかった検知層です。

CC Pipeline の BLOCK/WARN ルールは、まだキーワードベースの静的ルールにすぎません。作業指示の内容を見て判断しているわけではないので、この検知層の実装にはまだ届いていません。ただ、.env の読み取り警告や git push --force の記録のように、OS レベルでは正常だがエージェントの操作としては注意すべきイベントを拾うという方向性は、EDR とは異なる監視の価値を示しています。

業界の動き

とはいえ、この領域は急速に動いています。大手セキュリティベンダーが本格的に参入し始めました。

CrowdStrike Falcon AIDR（2025年12月 GA）

初の「AI 版 EDR」を謳う製品です。プロンプトインジェクション、データ漏洩、危険なエージェントアクションを検出・ブロックします。2026年には ClaudeCode 対応も拡大しています。従来の Falcon EDR と統合され、エンドポイント全体の可視化の中でエージェントの挙動も監視できる形を目指しています。

SentinelOne による Prompt Security 買収（約1.59億ドル）

EDR ベンダーの SentinelOne が AI セキュリティ企業を買収。エンドポイントセキュリティとエージェントセキュリティの統合が進む兆候です。

HiddenLayer Agent Harness Security（2026年8月）

コーディングエージェントのフック機構に直接統合するランタイムセキュリティ。CC Pipeline と同じ hooks ベースのアプローチですが、より本格的な検知ロジックと対応機能を備えています。

Elastic Security Labs の事例

2本の記事を公開しています。1本目（2026年4月）は、ClaudeCode の OTel テレメトリを Elastic に取り込み、Elastic Defend（EDR）のホストイベントと相関させる監視パイプラインの構築手法です。2本目（2026年8月）は、2026年7月の実インシデントで、ドメインレピュテーションとエンドポイント挙動アラートの2つのハントパスが同一ホスト上で合流した検出事例です。次のセクションで触れる突き合わせの実例にあたります。

標準化の動き

OWASP Top 10 for Agentic Applications 2026（2025年12月公開）が、エージェント固有のセキュリティリスクを体系化しています。NIST AI Agent Standards Initiative（2026年2月発足）も、エージェントセキュリティの標準化に向けて動き始めています。

突き合わせという方向性

CC Pipeline で見えるのはエージェント側のテレメトリだけです。でも、もしホスト OS 側のイベントと突き合わせられたら？

両者の乖離こそが検知シグナルになります。

エージェントが申告していないプロセスが生成された
ツール呼び出しなしにファイルが書き換わった
宣言されていない外部通信が発生した

これらはすべて、エージェントの申告と実際の挙動が食い違っているというシグナルです。

Elastic Security Labs が公開している事例は、まさにこのアプローチを実践しています。ClaudeCode の OTel テレメトリ（エージェント側の自己申告）と Elastic Defend のホストイベント（OS 側の実測）を同一タイムライン上で突き合わせています。

個人でやるとしたら、Windows なら ETW や Sysmon、Linux なら auditd や eBPF でホストイベントを収集し、CC Pipeline の state.json と突き合わせることになります。

作れないが、理解しておく意味

ただ、ホスト相関・異常検知・自動封じ込めは個人の手には余ります。

CC Pipeline で作れたのは、hooks のパターンマッチで「見える・止める」まで。エージェントの自己申告を拾って、危険なパターンをブロックし、警告をダッシュボードに表示する。ここまでは Python 標準ライブラリだけで、数百行で実現できました。

でも、その先には:

ホストイベント収集（ETW / Sysmon / auditd / eBPF）
子プロセス追跡とプロセス系譜の構築
エージェントテレメトリとの時系列相関
振る舞い異常の検知ロジック
セッション自動停止・隔離のオーケストレーション

どれも重いです。専門の製品が何年もかけて磨いてきた領域です。

ただ、仕組みを知っておいて損はありません。

製品選定時に何を見ればいいか分かる（テレメトリの収集方式、検知ロジック、対応の粒度）
組織で導入提案するときの説得材料になる（hooks だけでは不十分な理由を説明できる）
自分のツールの限界を正しく認識できる（CC Pipeline は「見える化」であって「検知」ではない）

次にやるとしたら Sysmon ログと CC Pipeline の state.json を突き合わせる簡易 PoC あたりからだと思います。（実際にやりました。次の記事で紹介予定。）

OS テレメトリの収集自体はそこまで大変ではありません。Windows なら Sysmon をインストールして XML で設定を書けば、プロセス生成・ファイル変更・ネットワーク通信がイベントログに記録されます。Linux なら auditd が標準搭載されていて、ルールを書けばログが出ます。

大変なのは収集の後です。OS テレメトリは膨大で、普通に使っているだけで毎秒数百〜数千イベントが出ます。そこから AI エージェントのセッションに紐づくイベントだけをプロセスツリーやタイムスタンプで抽出し、ノイズを除去する。この部分が重いです。

PoC としては、タイムスタンプで結合して乖離を目視確認する程度のもので十分です。本格的な相関エンジンは要りません。「こういう乖離が見える」という実例を1つ作れば、この領域の理解が深まる気がします。

AIDR の構造的な限界 -- 察せない AI

AIDR は「プロンプトからの逸脱」を検知する仕組みです。ここに構造的な弱点があります。プロンプトは人間の意図の近似でしかなく、AI は人間が本当に何を考えているかを察せません。

人間同士の会話なら、曖昧な指示でも「まあそういう意味でしょ」で通じます。背景知識、文脈、空気を読んで補完してくれます。でも AI にはそれができません。プロンプトに書かれていないことは、存在しないのと同じです。

自分がこれを実感したのはポケモンカードの AI（ポケモン ABC）でした。ルール通りに最適手は打てる。でも対戦相手が何を狙っているかという「読み」の部分が根本的に欠けていました。察する能力がないのです。

これを AIDR に当てはめると:

検知できるもの: プロンプトから明らかに逸脱した操作（.env を外部に送信する、作業ディレクトリ外を改変するなど）
検知できないもの: プロンプト自体が曖昧で、人間の真意と AI の解釈がズレているケース。AI は「指示通りにやった」、人間は「そうじゃない」、でも AIDR 的には逸脱していない

EDR にはこの問題がありません。OS 上の挙動という客観的事実だけで判断するからです。プロンプトの解釈に依存しない。

つまり AIDR は、AI が普及しても EDR の代替にはなりません。プロンプトという不完全な基準に依存する以上、EDR のオプション（追加レイヤー）にとどまる可能性が高いと考えています。ないよりはましです。導入するメリットはあります。でも、これだけで守れるとは思えません。

これは AIDR 固有の問題というより、「AI にゴールを伝える」仕組み全般の限界でもあります。人間が意図を完全に言語化できない場合、AI エージェント自体がこの問題を抱えていて、それを監視する AIDR も同じ壁にぶつかるという構造です。

見方を変えれば、AI の発展を阻害しているのは AI 自身ではなく、意図を言語化しきれない人間の側かもしれません。

余談: 人間の作業にも使えるか

ここまで「AI の意図を把握して、逸脱を検知する」という話をしてきましたが、ふと思ったことがあります。この仕組み、AI を伴わない人間だけの作業にも応用できないでしょうか。

たとえば、開発者が作業前に「React のフォームにバリデーションを追加する」と宣言する。AI がその意図から予想される操作（編集対象のファイル、使いそうなコマンド、触らないはずの範囲）を生成する。人間が作業を進め、予想にない操作が検知されたら EDR が警告する。

AI エージェントの場合はプロンプトという参照可能な作業指示があるから意図逸脱検知が成立します。人間の場合も、作業内容を事前に宣言すれば同じ構造が作れるかもしれません。IT 運用の変更管理（やることを事前申告し、それ以外をアラートにする）を、AI の予測で自動化して開発作業に持ち込むようなイメージです。

粒度の問題は残ります。予想が粗すぎると意味がなく、細かすぎると誤検知だらけになります。ただ、AIDR の枠組みが「AI を監視する」だけでなく「AI の理解力を使って人間の作業も守る」方向に拡張できる可能性は、考えてみる価値がある気がします。

まとめ

EDR の「テレメトリ収集 → 検知 → 対応」という枠組み自体は、コーディングエージェントにも適用できます。ClaudeCode のようなローカル実行型エージェントは、PC 上のプロセスとして動いている以上、エンドポイントセキュリティの対象です。

ただし、根本的な違いがあります。

テレメトリの信頼性: EDR は OS が強制収集。エージェント監視は自己申告
ベースラインの定義: EDR は正常な挙動が比較的安定。エージェントはタスクごとに挙動が変わる

この差は、自己申告とホスト実測の突き合わせで埋めるしかないと思っています。エージェントが言っていることと、ホスト上で実際に起きていることを照合し、乖離を検知シグナルにする。

大手セキュリティベンダーは既に動いています。CrowdStrike、SentinelOne、HiddenLayer。エンドポイントセキュリティとエージェントセキュリティの統合が進む兆しがあります。

個人開発者としてできることは、まず仕組みを理解すること。そして、自分のツールの限界を知ること。CC Pipeline は見える化とパターンマッチによるブロックまで対応しています。その先は、製品に任せるか、簡易 PoC で学習するかです。

エージェントに EDR は必要か。答えは「はい、ただし形は変わる」だと思います。EDR だけでは足りません。でも EDR が不要になるわけでもありません。OS レベルの脅威は EDR に任せ、AI 固有の逸脱検知を別の層として積む。CC Pipeline はその最小構成で、プロンプトの意図から外れた操作を可視化・ブロックする部分を担っています。

自己申告テレメトリの限界を前提に、ホスト実測との相関を組み込んだ新しい検知・対応の仕組みが必要になります。それが AIDR と呼ばれるかどうかはまだ分かりませんが、この方向に進むことは間違いなさそうです。

参考資料

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up