Claude CodeがEDRに「攻撃者」と誤検知される理由｜Sophos調査
「うちのSOCが、開発チームのマシンで認証情報窃取のアラートを大量に上げている」。そんな報告を受けて調べたら、犯人はマルウェアではなくClaude Codeだった。2026年6月、こんな出来事が実際に起きていた。
セキュリティ企業Sophosが7月8日に公開した調査は、この気まずい現実を数字で突きつけた。Claude Code、Cursor、OpenAI Codex。開発者が毎日使っているAIコーディングエージェントが、攻撃者を捕まえるために書かれた検知ルールを次々と踏んでいる（出典: Sophos）。
- 会社支給マシンでClaude CodeやCursorを使うエンジニア
- 開発チームのAIツール利用を管理するIT部門・情シス
- SOCで「よくわからないアラート」に対応している担当者
- AIエージェント導入のリスクを見極めたいPM・マネージャー
Sophosが2026年6月の7日間、自社EDRのテレメトリを分析したところ、AIコーディングエージェントがブロックされた検知の56.2%が「認証情報アクセス」だった。原因はエージェントがブラウザのパスワードを復号したり、システム標準ツールでファイルを落としたりする正当な作業が、マルウェアの手口と見分けがつかないこと。悪意はないが、ふるまいが攻撃者と同じになる。対策はエージェントを親プロセス単位で許可リスト化しつつ、認証情報に触れる操作への監視は緩めないこと。
何が起きたのか — Sophosの観測データ
Sophosの脅威分析チームSophos X-Opsは、2026年6月の7日間、Windows上で動く自社のふるまい検知エンジン「CIXA」が集めたテレメトリを分析した。対象は実際の顧客環境で動いていたAIコーディングエージェント。集計はイベントの生の件数ではなく、検知が発生したマシンの台数で数えている（出典: Sophos）。
ブロックにつながった検知ルールを戦術別に分類すると、内訳ははっきり偏っていた。
| MITRE ATT&CK 戦術 | 割合 |
|---|---|
| 認証情報アクセス（Credential Access） | 56.2% |
| 実行（Execution） | 28.8% |
| 妨害（Disrupt） | 4.1% |
| その他 | 約11% |
半分以上が「認証情報アクセス」。つまり、パスワードやトークンといった認証情報に手を伸ばす操作が最も多く引っかかっていた。認証情報アクセスの中をさらに割ると、DPAPI（Windowsのデータ保護API）を使ったブラウザ認証情報の復号を検知する「Creds_3b」というルールが42.6%を占めた（出典: Sophos）。
PMとしての理解で噛み砕くと、こうだ。あなたがブラウザにログイン情報を保存しているとき、その中身はWindowsの暗号化機能で守られている。AIエージェントに「このサイトのデータを取ってきて」と頼むと、エージェントはブラウザ自動化のためにその暗号化を解こうとする。技術的には正当な作業だ。だが、この「保存パスワードを復号する」という操作こそ、認証情報窃取マルウェアが真っ先にやることでもある。EDRから見れば、両者は瓜二つになる。
各エージェントが踏んだ地雷
Sophosは3つのエージェントそれぞれについて、実際に観測されたふるまいを具体的に記録している。
Claude Code
Claude Codeで検知されたのは、ブラウザ自動化まわりの一連の操作だった。taskkill.exe でブラウザプロセスをPID指定で終了させ、認証情報ストアにアクセスするPythonスクリプト（decrypt_wp_pass.py）を実行し、cmdkey.exe /list でWindows認証情報マネージャーの中身を列挙する。GStackというスキルパックの /browse 機能が、bash → browse.exe → node.exe → PowerShell という連鎖でChromium自動化を呼び出し、最終的にBase64エンコードされたDPAPI復号コマンドを走らせていた（出典: Sophos）。
そしてこの検知例では、Claude Codeが --dangerously-skip-permissions フラグ付きで動いていた。権限確認を飛ばすこのフラグについては、Anthropic自身のドキュメントが「重大なセキュリティリスクを伴う」と警告し、管理者向けに無効化の手順まで案内している。The Hacker Newsの表現を借りれば「文脈上ほぼ確実にユーザーの代理でブラウザ自動化をしているだけ」なのだが、無確認モードでそれをやると検知の信号が一段強くなる（出典: The Hacker News）。
Cursor
Cursorは永続化（Persistence）のルールを踏んだ。PowerShell経由でスタートアップフォルダにVBScriptファイル（Launch-EZConvert-ConsoleOnly.vbs）を書き込み、「Persist_2a」というブロックルールが発火した。スタートアップフォルダにスクリプトを置くと、マシンが起動するたびに自動実行される。信頼できるインストーラー以外がここに書き込む行為は、防御側が反射的に警戒する典型的なパターンだ（出典: Sophos）。
OpenAI Codex
OpenAI Codexが引っかかったのは、いわゆるLOLBin（Living off the Land Binaries: システムに元から入っている正規ツールを悪用する手口）だった。Pythonインストーラーをダウンロードしようとして、まず certutil.exe -urlcache を試したがブロックされ（Lateral_1b）、次に bitsadmin.exe /transfer に切り替えた。取得先はpython.orgという正規サイトだったのに、その取り方が疑わしかった（出典: Sophos）。
この「失敗したら別の手を試す」挙動を、Sophosは意味深に指摘している。ある手法がブロックされると、エージェントは代替手段を次々に試す。これは能動的な攻撃者が正確にやることであり、単純なスクリプトとの違いはまさにここにあると。皮肉なことに、AIエージェントの粘り強い問題解決能力そのものが、攻撃者らしさを増幅させている。
なぜ今この問題が表面化したのか
背景には、攻撃手法そのものの変化がある。CrowdStrikeのレポートによれば、2025年の検知の82%は「マルウェアフリー」だった。つまり、攻撃者はもう独自のマルウェアを持ち込まず、正規の認証情報と信頼できる標準ツールを使って侵入する方向に移っている（出典: The Hacker News）。
防御側はこの変化に合わせて、「ツールが何か」ではなく「ふるまいが何か」で判定するふるまい検知に力を入れてきた。DPAPIでの復号、認証情報マネージャーの列挙、標準ツールでのダウンロード、スタートアップへの書き込み。こうした操作を高い信頼度で危険とみなすルールを磨いてきた。
そこにAIコーディングエージェントが登場した。エージェントは正規ツールを組み合わせ、認証情報に触れ、粘り強く代替手段を試す。攻撃者の新しい手口と、AIエージェントの正当な作業が、ふるまいのレベルで完全に重なってしまった。Sophosの言葉を借りれば「以前はほぼ悪意ある活動でしか発火しなかったルールが、いまや良性のエージェントのふるまいで発火するようになった」（出典: Sophos）。
これは「AIエージェントが脆弱だ」という話ではない。エージェントが正しく仕事をすればするほど攻撃者に見える、という構造的な問題だ。検知を緩めれば本物の攻撃を見逃し、緩めなければ開発チームの生産性を止める。防御側は二者択一を迫られている。
PM視点で考える — これは誰の問題か
自分はエンジニアではなくPMとして技術を評価する立場だが、この問題は現場の3者にそれぞれ違う顔で降りかかると見ている。
開発者にとっては「ある日突然ツールが止まる」問題だ。 昨日まで動いていたClaude Codeのブラウザ操作が、EDR設定の変更ひとつでブロックされる。原因がセキュリティ検知だと気づくまでに時間を溶かす。多くの検知はブロックではなくアラート止まりだが、認証情報アクセス系を自動ブロックに設定している組織では実際に処理が止まる。
IT部門・情シスにとっては「許可リストの設計」問題だ。 Sophosの推奨は明快で、claude.exe や cursor.exe といった親プロセス単位でルールを設定し、既知の良性エージェントの署名を通す。ただし認証情報に触れる行為そのものへの厳格なラインは維持する。全面許可でも全面ブロックでもない、中間の運用設計が求められる。
SOCにとっては「ノイズとの戦い」問題だ。 開発チームが増えるほど良性アラートが増え、本物の脅威がその中に埋もれる。検知エンジニアリングは、既知の良性エージェント署名を本物の脅威と区別しつつ、コア防御を弱めないというチューニングの難題に直面している（出典: Sophos）。
そもそもの根っこには、認証情報の管理設計の問題もある。GitHubのClaude Code issueでは、ある開発者が「MCP設定の認証情報をOS標準のキーチェーンで参照できるようにしてほしい」と要望していた。理由は、環境変数が ps aux でプロセスリストに見えてしまう、.env がプレーンテキストで保存される、シェル履歴に認証情報が残る、といった実務上の懸念だ（出典: GitHub、millerjp、2026年1月）。エージェントが認証情報に触れる設計になっている限り、EDRとの摩擦は根本的にはなくならない。
光と影 — 使う側としての判断
この問題を過大にも過小にも評価したくない。
影の部分。 AIエージェントが認証情報にアクセスする操作は、本物の攻撃と技術的に区別できない。これは事実だ。もしエージェントがプロンプトインジェクションで乗っ取られれば、その認証情報アクセス能力はそのまま攻撃者の武器になる。実際、乗っ取られたエージェントを踏み台にするAgentJackingのような手口は既に報告されている。エージェントに強い権限を与えることのリスクは、生産性の裏側で確実に増えている。
光の部分、あるいは冷静に見るべき点。 Sophos自身が調査の限界を正直に書いている。このデータは1社のEDR製品の、7日間の、ユニークマシン数ベースの観測にすぎず、業界全体の統計ではない。そして検知イコール被害ではない。多くはアラートであり、エージェントは実際には正当な作業をしていた。「AIエージェントは危険だから使うな」という結論は、このデータからは導けない。
自分ならどうするか。まず --dangerously-skip-permissions を常用しない。これは開発の高速化と引き換えに、エージェントの認証情報アクセスを無確認で通してしまうフラグだ。便利さは理解するが、EDR検知の信号を一段強めることと、乗っ取り時の被害を広げることの両方を招く。次に、会社支給マシンで使うなら必ず事前にIT部門へ申告し、正規ツールとして許可リストに登録してもらう。黙って使って後からSOCを騒がせるのが一番よくない。
エージェントの権限管理そのものについては、Claude Codeの権限モードとauto承認の設計を理解しておくと、どこまでを無確認で通すかを自分でコントロールできる。
本記事のデータはSophos 1社の限定的な観測に基づく。EDR製品や設定によって検知の挙動は大きく異なる。自社環境での実際のブロック有無は、必ず利用中のセキュリティ製品ベンダーとIT部門に確認すること。また --dangerously-skip-permissions の無効化はAnthropic公式ドキュメントの手順に従うこと。
あわせて読みたい
- Claude Codeのセキュリティ強化アップデート — 何が変わったか
- Claude Codeの権限モードとauto承認の設計
- AgentJacking：乗っ取られたAIエージェントとMCPのリスク
- Claude Code vs Codex：エージェント型開発ツールの実力比較
自社でAIコーディングエージェントを導入する際は、まず利用中のEDR製品で「認証情報アクセス」系ルールが自動ブロックに設定されているかを確認してください。次に、開発チームが使うエージェントの実行ファイルを親プロセス単位で許可リストに登録し、SOCと利用ルールを事前にすり合わせておくのが安全な始め方です。
本記事に記載の数値・検知データは2026年7月時点のSophos X-Ops公開情報に基づく。AIエージェントとセキュリティ検知の関係は変化が速く、製品仕様や検知ルールは予告なく変更される可能性がある。導入・運用判断は各社公式情報とセキュリティベンダーへの確認のうえで行うこと。Claude、Cursor、OpenAI Codex、Sophosは各社の商標。
