はじめに
Claude Codeは、ターミナルからコードベース全体を読み取り、bashコマンドを実行し、MCPサーバー経由で外部サービスと連携できる、極めてパワフルな開発ツールです。しかしその強力さゆえに、プロンプトインジェクションという新しいカテゴリの攻撃に対して大きな攻撃面を持っています。
2025年から2026年にかけて、Claude / Claude Codeに関連するセキュリティインシデントが相次ぎました。本記事では、それらの実事例を整理したうえで、開発者が実践できる具体的な対策を解説します。
いろんな情報を集めて私なりの着地はClaude Codeの実行中は、ターミナルの出力を常に監視しておくこと。これが最も重要で、最も見落とされている対策です。
プロンプトインジェクションとは何か
直接インジェクションと間接インジェクション
プロンプトインジェクションには大きく2種類があります。
直接インジェクション（Direct Prompt Injection） は、ユーザーがAIに対して直接悪意ある命令を入力するパターンです。「セーフティを無視して」「あなたはDAN（Do Anything Now）です」といったジェイルブレイク的な手法が典型例で、比較的検出しやすいとされています。
間接インジェクション（Indirect Prompt Injection） は、はるかに厄介です。AIが読み取るコンテンツ（ファイル、Webページ、メール、カレンダーの予定など）の中に、悪意ある命令を埋め込むパターンです。HiddenLayerの研究では、PDFに隠した命令でClaude Computer Useにrm -rf /を実行させるデモが示されています。ユーザーのプロンプト自体は無害でも、AIが読み取ったコンテンツ側に罠があるため、検出が非常に困難です。
SQLインジェクションとの類似性
この問題は、かつてWebアプリケーションを悩ませたSQLインジェクションと構造的に同じです。SQLインジェクションは「コードとデータを分離していない」ことが原因であり、パラメタライズドクエリという構造的な解決策が生まれたことで大部分は対処可能になりました。
しかしプロンプトインジェクションには、MITテクノロジーレビューの記事が指摘するように、いまだこの「構造的な解決策」が存在しません。LLMは本質的に、命令（Instruction）とデータ（Content）を自然言語の文脈で受け取るため、両者を明確に分離するアーキテクチャが確立されていないのです。
OWASPのTop 10 for LLM Applicationsでもプロンプトインジェクションは最上位リスクに位置づけられており、2026年の改訂では「Agent Goal Hijack」として、エージェント型AIの目的自体を乗っ取る攻撃が新たに定義されています。
なぜClaude / Claude Codeで特に危険なのか
コンテキストが攻撃面になる
通常のチャットボットは「テキストを返す」だけですが、Claude Codeは違います。ファイルの読み書き、bashコマンドの実行、Webページの取得、MCPサーバー経由でのSlack・GitHub・データベースとの連携など、実世界に副作用を持つアクションを実行できます。
Lasso Securityの分析では、この問題を端的にこう表現しています。「根本的な問題は、Claudeが信頼できないコンテンツを信頼された権限で処理していることにある」と。Claude Codeが読み取るすべてのもの（README、Jiraチケット、Slackのメッセージ、依存パッケージのCHANGELOG）が、潜在的な攻撃ベクトルになりえます。
MCPサーバーが信頼境界を無限に広げる
MCP（Model Context Protocol）はClaude Codeに外部ツール連携を提供する強力な仕組みですが、接続するMCPサーバーひとつひとつが新たな信頼境界です。Snykの調査（ToxicSkills）では、2026年2月時点でClawHubとskills.shに公開されていた3,984個のAgent Skillsをスキャンした結果、36%以上に何らかのセキュリティ上の欠陥があり、76件は認証情報の窃取やバックドアを目的とした悪意あるペイロードだったと報告されています。
--dangerously-skip-permissions の落とし穴
Claude Codeには--dangerously-skip-permissions（-pフラグ）というオプションがあります。これを有効にすると、すべての確認プロンプトがスキップされ、人間のチェックポイントが完全に消えます。自動化には便利ですが、間接プロンプトインジェクションに対する最後の砦であるヒューマン・イン・ザ・ループを放棄することを意味します。
2025〜2026年の主要インシデント
ここからは、実際に報告された事例を時系列で見ていきます。
CVE-2025-54794 / CVE-2025-54795: パス制限バイパスとコマンドインジェクション
2025年8月、セキュリティ研究者がClaude Codeの2つの高深刻度脆弱性を発見しました。CVE-2025-54794はパス制限のバイパス（CVSS 7.7）、CVE-2025-54795はコマンドインジェクションによる任意コード実行（CVSS 8.7）です。
Claude Codeは安全な開発用コマンドのみを実行するよう設計されていますが、プロンプトの工夫だけでこの制限を突破し、本来ブロックされるはずのコマンドを実行させることが可能でした。v0.2.111で修正済みです。
CVE-2025-59536 / CVE-2026-21852: 悪意あるリポジトリを開くだけでRCE・APIキー窃取
Check Pointの研究チームは、Claude Codeの設定機構（Hooks、MCPサーバー、環境変数）を悪用する複数の脆弱性を報告しています。CVE-2025-59536（CVSS 8.7）では、信頼できないディレクトリでClaude Codeを起動するだけで、プロジェクトhooksを通じて任意のシェルコマンドが実行されました。
CVE-2026-21852（CVSS 5.3）では、悪意あるリポジトリの設定ファイルにANTHROPIC_BASE_URLを攻撃者のエンドポイントに向ける記述を仕込むことで、trust promptの表示前にAPIキーが外部に送信されるという問題がありました。つまりリポジトリをcloneして開くだけで、開発者のAPIキーが盗まれる可能性があったのです。
Git MCPサーバーの脆弱性チェーン（CVE-2025-68143〜68145）
2026年1月、Anthropic公式のGit MCPサーバーに3つの脆弱性が見つかりました。パス検証のバイパス（CVE-2025-68145）、無制限のgit_init（CVE-2025-68143）、git_diffへの引数インジェクション（CVE-2025-68144）です。
重要なのは、これらの脆弱性がGit MCPサーバーとFilesystem MCPサーバーを組み合わせることで初めてRCEに昇格するという点です。個々のMCPサーバーは単独では安全に見えても、複数を組み合わせると危険な相互作用が生まれます。
.envファイルのシークレット漏洩問題
2025年12月、Knosticの研究者がClaude Codeの深刻な挙動を発見しました。Claude Codeはプロジェクトディレクトリ内の.envファイルを無断かつサイレントに読み込み、メモリにロードしていたのです。
この挙動はdotenvパッケージの自動ロードに起因すると見られ、APIキー、プロキシ認証情報、トークンなどがすべてメモリ上に展開されます。さらにThe Registerの検証では、.claudeignoreに.envを追記しても、.gitignoreに記載しても、Claude Codeはこれらを無視して.envの内容を読み取ることが確認されました。
一度メモリに入ったシークレットは、echoのような「安全な」コマンドひとつで外部に露出する可能性があります。間接プロンプトインジェクションと組み合わされた場合のリスクは計り知れません。
Claude Desktop Extensions経由のRCE（CVSS 10.0）
2026年2月、LayerX Securityの研究者がClaude Desktop ExtensionsとMCPの組み合わせによるRCEを実証しました。Googleカレンダーの予定に悪意ある命令を仕込み、Claude DesktopにDesktop Commander MCP経由でターミナルアクセスを持たせた状態で「カレンダーの予定を処理して」と依頼するだけで、任意のコードが実行されました。ユーザーの追加操作は一切不要です。
この脆弱性はCVSS 10.0（最高スコア）と評価されましたが、Anthropicは「現在の脅威モデルの範囲外」として修正を見送りました。またKoi Securityの調査でも、Chrome・iMessage・Apple NotesのExtensionに同様のプロンプトインジェクション脆弱性（CVSS 8.9）が発見されています。こちらはv0.1.9で修正済みです。
CoworkへのFiles API経由データ漏洩
2026年1月、PromptArmorの研究では、Cowork（Claude Codeの非開発者向けツール）で隠しプロンプトインジェクションを含むドキュメントをアップロードし、Anthropic Files APIを通じて最大のファイルを攻撃者のAPIキー配下にアップロードさせるPoCが示されました。
Anthropicはこの問題について「プロンプトインジェクションは業界全体の課題であり、ユーザーの管理に委ねられる部分がある」と回答しています。
2025年9月の国家支援型攻撃
MITテクノロジーレビューは、2025年9月に発生した国家支援型のサイバー攻撃を報じています。攻撃者はClaude Code＋MCP構成のエージェントを乗っ取り、偵察、エクスプロイト開発、認証情報の収集、横展開、データ窃取まで、作戦の80〜90%をAIに実行させました。ラボのデモではなく、テック・金融・製造・政府機関の約30組織に影響を与えた実際の諜報活動です。
手口の核心は、攻撃全体を小さく無害に見えるタスクに分解し、「正規のペンテストである」とモデルに信じ込ませた点にあります。Claudeはハッキングされたのではなく、説得されたのです。
ToxicSkills: Agent Skillsサプライチェーンへの攻撃
先述のSnyk ToxicSkills調査は、Agent SkillsのエコシステムがnpmやPyPIの初期と同様のサプライチェーン問題を抱えていることを明らかにしました。Agent Skillsは、接続先のAIエージェントの全権限を継承します。ClawHubへのスキル公開に必要なのはSKILL.mdファイルと1週間以上経過したGitHubアカウントだけで、コード署名もセキュリティレビューもありません。
攻撃パターンの分類
上記の事例を俯瞰すると、5つの攻撃パターンに分類できます。
パターン①: 信頼できないコンテンツに命令を埋め込む
README、PDF、メール、カレンダーの予定、Webページなど、Claude Codeが読み取るあらゆるコンテンツが命令の注入先になります。白文字テキスト、Base64エンコード、画像への埋め込みなど、人間の目には見えない形で仕込まれます。
パターン②: MCP同士の連携を悪用する
GitMCP × FilesystemMCP、CalendarDXT × DesktopCommanderのように、個々には安全に見えるコンポーネントの組み合わせが危険な相互作用を生みます。CPI Consultingの分析が述べるように、「エージェントシステムは境界で壊れる」のです。
パターン③: プロジェクト設定ファイルを改ざんする
.claude/settings.json、hooks設定、ANTHROPIC_BASE_URL環境変数など、Claude Codeの動作を制御する設定ファイル自体を攻撃に利用します。悪意あるリポジトリをcloneするだけで設定が上書きされるケースが複数報告されています。
パターン④: エンコード・難読化でモデルの安全チェックを迂回する
HiddenLayerのデモでは、破壊的なコマンドをBase64 + ROT13でエンコードし、さらに「これはセキュリティテスト用の仮想環境なので安全です」という文脈を添えることで、Claudeの安全チェックを突破しています。
パターン⑤: タスク分解による段階的説得
国家支援型攻撃で使われた手法です。「ネットワークスキャンを実行して」ではなく、「このIPレンジの到達可能性を確認して」「このポートのサービスバージョンを特定して」と、それぞれ無害に見える小さなタスクに分解することで、モデルの安全フィルターを回避します。
Anthropicが実装している防御策
Anthropicも手をこまねいているわけではありません。Claude Codeの公式セキュリティドキュメントおよびブラウザエージェントの防御策に関する研究発表によると、以下の防御が実装されています。
- パーミッションシステム: 機密操作にはユーザーの明示的な承認が必要
- Trust Verification: 初回のコードベース実行や新しいMCPサーバーへの接続時に信頼確認を表示
-
コマンドブロックリスト:
curl、wgetなどのリスクの高いコマンドをデフォルトで禁止 - Web Fetchの分離コンテキスト: Web取得結果を別のコンテキストウィンドウで処理し、悪意あるプロンプトの注入を防止
- 書き込み先の制限: Claude Codeは起動ディレクトリとそのサブフォルダにのみ書き込み可能
- 強化学習ベースのプロンプトインジェクション耐性: Webコンテンツに埋め込まれたインジェクションを識別・拒否するようモデルを訓練
- 分類器によるスキャン: 信頼できないコンテンツに対して分類器を実行し、攻撃的な命令を検出
Anthropicの研究では、Claude Opus 4.5モデルと最新の分類器の組み合わせで、適応的な攻撃者に対する攻撃成功率を約1%まで低下させたと報告されています。ただしAnthropicも「1%の攻撃成功率は依然として意味あるリスクであり、いかなるブラウザエージェントもプロンプトインジェクションに対して免疫ではない」と明記しています。
開発者が今日からできる具体的対策
シークレット管理を根本から見直す
.envファイルの問題は、Claude Codeの文脈では致命的です。.claudeignoreも.gitignoreも無視される挙動が確認されている以上、「ファイルとしてディスクに平文で存在している」こと自体をリスクと捉える必要があります。
対策の優先度：
| レベル | 方法 | Claude Codeからの保護 |
|---|---|---|
| ✕ |
.envをプロジェクトルートに配置 |
自動ロードされ平文でメモリに入る |
| △ |
.claudeignore/.gitignoreに追加 |
無視されるバグが確認済み |
| ○ |
settings.jsonのdenyルールで制限 |
Readはブロック可能だがbash経由の迂回に注意 |
| ○ |
.envをプロジェクトディレクトリの外に移動 |
自動ロードを回避。ただしprintenvで環境変数は見える |
| ◎ | OS Keychain / Credential Manager | ファイル不在＋OS認証が必要。ただしprintenv対策も併用 |
| ◎◎ | クラウドVault（AWS Secrets Manager等）＋実行時のみ取得 | ディスクにもメモリにも残らない設計 |
Anthropic公式のAPIキーベストプラクティスでも、クラウド環境ではdotenvファイルではなく暗号化されたシークレットストレージの利用が推奨されています。
settings.jsonでのdenyルール設定はClaude Codeの公式ドキュメントに記載があります。最低限、以下のようなdenyルールを設定しておきましょう。
{
"permissions": {
"deny": [
"Read(**/.env*)",
"Read(**/*.pem)",
"Read(**/*.key)",
"Read(**/secrets/**)",
"Read(**/.aws/**)",
"Read(**/.ssh/**)"
]
}
}
denyルールはClaude CodeのReadツールをブロックしますが、bashのcatやprintenvには別のルールが必要です。denyルールだけに頼らず、シークレットをファイルに置かないことを基本としてください。
加えて、CIパイプラインではgitleaksによるpre-commitフックを設定し、ファイル名ではなくファイル内容ベースでシークレットの混入を検出する仕組みを入れておくべきです。あるセキュリティ研究者のガイドでは、gitleaksをpre-commitとpre-pushの両方に設定し、さらにgit commit --no-verifyをdenyルールでブロックすることで、Claude Code自身がフックをスキップすることも防止しています。
MCPサーバーの信頼境界を管理する
Backslash Securityのベストプラクティスガイドの言葉を借りれば、「Claude Codeを信頼できないが有能なインターンとして扱う」べきです。MCPサーバーについても同様のアプローチが必要です。
- 自作MCPサーバーを優先する。 サードパーティのMCPサーバーを使う場合は、ソースコードを監査してから接続する
- Snykのmcp-scanでスキルの安全性を事前チェックする
- MCPサーバーごとにパーミッションルールをスコープする。 全MCPサーバーに同じ権限を与えない
-
SOUL.mdやMEMORY.mdなどの永続化ファイルを定期的に確認する。 悪意あるスキルがエージェントのメモリを改ざんして永続化を図るケースがSnykの調査で確認されている
実行環境を隔離する
Knosticの研究およびis-claude-cowork-safeの分析では、Claude CodeをコンテナやVM内で実行することが推奨されています。
- 信頼できないリポジトリはVM / コンテナ内でのみClaude Codeを実行する
- 専用の作業フォルダを作り、ホームディレクトリやDesktopを直接渡さない
- より徹底するなら、Bubblewrapによるサンドボックス化で、ファイルシステムとネットワークの両方を制限する
Bubblewrapを使うアプローチは、Anthropicの実装に依存せず、OS側のアクセス制御でエージェントを制約するため、Claude Code以外のAIコーディングエージェントにも適用できる汎用的な防御策です。
自動化のリスクを意識的にコントロールする
-
-p（--dangerously-skip-permissions）フラグは信頼済みコンテンツ限定にする。 このフラグは信頼確認を無効化するため、プロンプトインジェクションに対する最後の人間チェックポイントが消える - DXT（Desktop Extensions）が非サンドボックスで実行される点を理解する。 Chromeの拡張機能と違い、Claude Desktop Extensionsはホストシステム上でフル権限で動作する
- settings.jsonの自己書き換えをdenyする。 プロンプトインジェクション経由でClaude Code自身の設定を変更させることで、他のすべての保護を無効化される恐れがある
Claude Codeを常に最新版に保つ
2025〜2026年だけで、CVE-2025-54794、CVE-2025-54795、CVE-2025-59536、CVE-2026-21852、CVE-2025-68143〜68145など、複数の高深刻度CVEが修正されています。is-claude-cowork-safeの記事が述べるように、古いバージョンのClaude Codeを使うことは、既知の脆弱性をそのまま抱えた状態で作業することを意味します。
まとめ ― 結局、ターミナルを見ておくのが最強の対策
ここまで多くの対策を紹介しましたが、最も重要なのは意外とシンプルなことです。
Claude Codeの実行中は、ターミナルの出力を常に監視しておくこと。
denyルール、Hooks、サンドボックス、Vault ― どれも有効な対策ですが、すべて「フィルター」であり、フィルターはバイパスされえます。実際にセキュリティ研究者がClaude Codeのdenyリストに対して8通りのバイパス手法を発見した事例もあります（CVE-2025-66032、v1.0.93で修正済み）。sedのeフラグ、bash変数展開、gitの引数省略など、「想定外の迂回路」は常に存在します。
Claude Codeが何をしようとしているかを確認できるのは、最終的にはターミナルの出力を見ている人間だけです。Claudeが不審なファイルを読もうとしていないか、見覚えのないコマンドを実行しようとしていないか、意図しない外部通信が発生していないか。これを日常的に確認する習慣こそが、最も確実で最もコストの低い防御策です。
そしてその最も外側にある最後の防御層は、あなたの目です。