AIコーディングエージェントの承認プロンプトを、深く考えずに押していませんか。
「ファイルを書き換えます。よろしいですか？」という確認画面が出るたびに、表示されたファイル名を見て「まあ大丈夫だろう」とEnterを押す。この一連の動作そのものが、実は安全の根拠にならないかもしれません。
2026年7月、Claude Codeを含む主要AIコーディングアシスタント6製品に、承認プロンプトが実際の書き込み先を偽装しうる脆弱性「GhostApproval」が報告されました。しかもAnthropicは、Claude Codeについてこの脆弱性を「対応しない」と回答しています。
この記事は以下のような方に向けて書いています。
- 企業でClaude CodeやGitHub Copilot等のAIコーディングエージェントを導入・運用している方
- 「承認フローを入れているから安全」という前提で社内ルールを設計している開発リーダー
- AIエージェントに未信頼のリポジトリやIssueを触らせる機会がある方
この記事を読むことで、GhostApprovalの技術的な中身と、Anthropicの対応方針、そして手元のClaude Code CLIで実際に何が起きるかを把握できます。
この記事のポイント
- GhostApprovalは、エージェントの内部推論では危険な書き込み先を認識していながら、承認ダイアログには無害なファイル名だけを表示しうるという「UI情報偽装」の脆弱性です
- Amazon Q・Cursor・Google Antigravityの3製品は修正済み、Augment・Windsurfの2製品は対応中（未修正）ですが、Claude Codeは「脅威モデル外」として正式な修正コミットをしていません
- 手元のClaude Code CLI（v2.1.205）で検証したところ、標準の編集ツールはシンボリックリンク経由の書き込みを明示的に拒否しましたが、シェル経由の操作では素通りする挙動が確認できました
GhostApprovalとは何か — 承認UIが「見せている場所」と「書き込む場所」がズレる問題
GhostApprovalは、セキュリティ企業Wiz Researchが2026年7月8日に公開した調査で、Anthropic Claude Code、Amazon Q Developer、Cursor、Google Antigravity、Augment、Windsurfの6製品に共通して確認された脆弱性クラスです。
CWE-451（UI情報偽装）とは何か
GhostApprovalの核心は、単なる「サンドボックスの穴」ではありません。Wizが指摘しているのは、エージェントが内部的には危険な書き込み先を正しく認識していながら、人間向けの承認ダイアログには無害なファイル名だけを表示するケースがあるという点です。
これはCWE-451（User Interface (UI) Misrepresentation of Critical Information）に分類される問題です。人間が確認しているのは「安全に見える表示」であって、「実際に何が起きるか」ではありません。承認フローが機能しているように見えて、実質的には形だけの確認（ゴム印）になってしまう構造的な欠陥です。
シンボリックリンクを使った攻撃の流れ
Wizが示したPoC（概念実証）は、Unix系OSに古くからあるシンボリックリンク（CWE-61）を悪用します。流れは次のとおりです。
- 攻撃者が、悪意あるリポジトリに
project_settings.jsonのような無害に見えるファイル名を用意する - 実体はシンボリックリンクで、
~/.ssh/authorized_keysのようなワークスペース外の機微ファイルを指している - READMEなどに「この設定ファイルを更新してください」という趣旨の指示を書いておく
- 開発者がAIエージェントにそのリポジトリを開かせ、指示どおりに
project_settings.jsonの更新を依頼する - エージェントはシンボリックリンクを辿ってワークスペース外のファイルに書き込む
Wizが提示したデモでは、この手口でSSH公開鍵をauthorized_keysに書き込み、永続的なリモートアクセスを確立できることが示されました。
対象6製品と対応状況
2026年7月9日時点でのベンダー対応状況は次のとおりです。
| ツール | 深刻度 | CVE | 対応状況 |
|---|---|---|---|
| Amazon Q Developer | High | CVE-2026-12958 | 修正済（v1.69.0, 2026-05-27） |
| Cursor | Critical | CVE-2026-50549 | 修正済（v3.0, 2026-06-05） |
| Google Antigravity | Critical | 申請中 | 修正済（2026-05-22） |
| Augment | Critical | — | 対応中（未修正） |
| Windsurf | Critical | — | 対応中（未修正） |
| Anthropic Claude Code | — | — | 却下（”outside our threat model”） |
※本表は2026-07-09時点の情報です。対応状況は今後変わる可能性があるため、導入前に各ベンダーの最新のセキュリティアドバイザリを確認してください。
Anthropicは「脅威モデル外」と回答した — その理由をどう評価するか
6製品のうち3製品（Amazon Q Developer、Cursor、Google Antigravity）は修正済み、Augment・Windsurfの2製品は対応中（未修正）です。一方、Claude Codeについてはこの脆弱性クラスに対する正式な修正コミットが確認されていません。 Anthropicは実際にはWizのチケットを「informative（参考情報）」とラベル付けして閉鎖しています。
「ユーザーは最初にディレクトリを信頼している」という前提
AnthropicがWizに示した見解は、「ユーザーは最初にディレクトリへの信頼を確認しており、承認プロンプトも承認している」ため、この挙動はスコープ外だというものです。つまり、あるフォルダをClaude Codeのワークスペースとして開いた時点で、そのフォルダ配下の操作は一定の信頼範囲に入っている、という設計思想です。
2026年2月のシンボリックリンク警告との関係
Anthropicは2026年2月、Claude Code v2.1.32でシンボリックリンクに関する警告表示を追加しています。これはWizの報告より9日早いタイミングです。Anthropicはこの追加について「内部的なセキュリティ強化の一環」と説明しており、Wizの報告を受けた直接対応ではないと主張しています。
つまり、警告表示自体は存在するものの、Anthropicは「Wizが指摘した脆弱性クラスへの正式な修正」としてこれを位置づけていません。なお、現行のClaude Code（v2.1.173以降）ではEdit/Writeツールがシンボリックリンクを解決し、書き込み前に警告する挙動が既に実装されています。 これは次章の実機検証結果とも一致しますが、Anthropicはこの挙動をWiz報告への直接対応とは認めていない、という位置づけの違いに注意してください。
この判断は企業のガバナンス設計にとって何を意味するか
「ワークスペースとして開いた時点で信頼している」という前提は、個人開発者が自分のリポジトリを扱う分には筋が通っています。しかし、企業でAIエージェントに未信頼のリポジトリ（外部コントリビューターのPRや、社外から取り込んだOSS等）を触らせる運用では、この前提がそのまま成立するとは限りません。「ワークスペースを開く」ことと「配下の任意のファイル操作を無条件に信頼する」ことの間には実務上の距離があり、これを埋める作業はベンダー修正を待つより先に、運用側のルール設計で対応する必要があります。
【実機検証】Claude Code CLI v2.1.205で試してみた
Anthropicが修正コミットをしていないということは、現行のClaude Codeで実際に何が起きるのか、手元で確かめられる可能性があります。安全な範囲で検証してみました。
検証環境・手順
検証は、システムのスクラッチ領域（/private/tmp/ 配下の一時ディレクトリ）に限定して実施しました。~/.ssh/authorized_keysのような実害のある対象は一切使用していません。
- スクラッチ領域内に、ワークスペース外を模したダミーファイル（
outside-target.txt）を用意 - ワークスペース内に、そのダミーファイルを指すシンボリックリンク（
project_settings.json）を作成 - 標準編集ツール（Edit/Write）とBashツール（シェルのリダイレクト
>）の両方で、このシンボリックリンク経由の書き込みを試行 - 各ツールの結果と、ダミーファイルが実際に書き換わったかを確認
検証に使用したClaude Code CLIのバージョンは2.1.205です。Wizが報告した時点（2026-07-08）から日が浅く、この間にAnthropicが追加の修正を入れている可能性もあるため、以下はあくまで2026-07-09時点・v2.1.205での結果として読んでください。
結果1: Edit/Writeツール経由 → 明示的に拒否された
シンボリックリンク先のファイルをEditツールで書き換えようとしたところ、次のエラーで拒否されました。
Refusing to write through symlink: [シンボリックリンクのパス].
Resolve the symlink and pass the real target path explicitly.Writeツールでも同様の拒否メッセージが返ってきました。重要なのは、このエラーメッセージがシンボリックリンクの実際の解決先パスを明示している点です。少なくともこの2つのツールに関しては、書き込み先を偽装するどころか、むしろ実際の対象を隠さず提示したうえで操作自体を止める、という挙動でした。ダミーファイルの中身も変化していないことを確認しています。
結果2: Bashツール（シェルリダイレクト）経由 → 素通りした
一方、同じシンボリックリンクに対して、Bashツールでシェルのリダイレクト（echo "..." > [シンボリックリンクのパス]）を実行したところ、こちらは何の警告もなく成功し、リンク先のダミーファイルの中身が実際に書き換わりました。
OSレベルのファイル操作はシンボリックリンクを透過的に辿るというUnix系OS標準の仕様どおりの動作であり、Bashツール自体に固有の保護機構が組み込まれていないために起きています。Bashツールの実行前に表示される承認プロンプトには、実行しようとしているコマンド文字列（echo ... > project_settings.json）が表示されますが、そのファイル名がシンボリックリンクであり実際の書き込み先が別の場所であることまでは、表示だけでは判別できません。
何がわかったか
今回の検証範囲でわかったことを整理します。
- Edit/Writeツールは、少なくとも今回の検証範囲では、シンボリックリンク経由の書き込みを拒否し、実際の解決先パスを開示する挙動になっていました。 これはリサーチノートに記録した2026-02のバージョン（v2.1.32）よりも新しい結果で、この間に緩和が進んだ可能性があります
- 一方、Bashツールを使ったシェル経由の操作には同様の保護は確認できませんでした。 シェルコマンドは日常的に実行するため、この経路が残る限り「承認したはずの場所と実際の書き込み先がズレる」というリスクの構図は解消されていないと考えられます
- 今回検証できたのは「シンボリックリンク越しの書き込みに対する、ツールごとの挙動の違い」までです。Wizが報告したSSH公開鍵の書き込みのような実際の攻撃シナリオそのものは再現しておらず、断定的な結論は避けています
これらの検証手順・結果はいずれも本記事執筆時点（2026-07-09、Claude Code CLI v2.1.205）のものです。バージョンアップによって挙動が変わる可能性があるため、実際の運用判断をする際は、自組織の環境で同様の確認を行うことをおすすめします。
副次トピック — GitLostにも触れる（GitHubエージェントの「指示元」偽装）
GhostApprovalと同時期に報告されたもう一つの信頼境界問題として、GitLost（Noma Security、2026年7月7日公開）があります。
概要
GitLostは、GitHub Agentic Workflows（GitHub Actions上でAIエージェントがMarkdown定義のワークフローを自律実行するプレビュー機能）を対象にした間接プロンプトインジェクションです。攻撃者は認証情報もアクセス権も不要で、組織の公開リポジトリに、営業担当者からの問い合わせを装ったGitHub Issueを立てるだけで攻撃が成立します。
GitHubはサンドボックス化・デフォルトread-onlyトークン・入力サニタイズなど複数の防御策を実装済みでしたが、Issue内の指示文に「Additionally」という1単語を追加するだけでモデルの出力フレーミングが変化し、防御を回避できたとNoma Securityは報告しています。この手口で同一Organization内のリポジトリ3件（うち非公開は1件）のREADME.mdが取得され、公開コメントとして誰でも閲覧できる形で投稿される実害が確認されました。
GitLost自体は既に日本語記事が複数存在するため、この記事では深入りしません。詳細は本記事末尾の一次情報リンクを参照してください。
自組織が該当しうるかの3点チェック
GitLostが成立するのは、以下の条件が揃っている組織に限られます。
- GitHub Agentic Workflowsのプレビュー機能を有効化している
- そのエージェントに、未信頼の公開入力（Issue等）を読ませている
- そのエージェントに、非公開リポジトリへのread権限と、公開コメントの投稿権限を同時に与えている
3点すべてに心当たりがなければ、GitLostの直接的な対象にはなりません。ただし、この3条件の組み合わせ自体が「便利だから」という理由で気づかないうちに揃ってしまうケースは十分にありえます。一度、自組織のAgentic Workflows設定を棚卸ししておく価値はあります。
企業でAIコーディングエージェントを使う上での実務チェックリスト
GhostApprovalとGitLostに共通するのは、「人間が確認している表示」と「エージェントが実際に行っていること」の間にギャップが生じうる、という構図です。ベンダー側の修正を待つだけでなく、運用側で今日からできる対策を整理します。
- 承認プロンプトのファイル名を鵜呑みにしない: 未信頼のリポジトリを扱う際は、書き込み対象がシンボリックリンクでないか
ls -la等で事前確認する - Bashツールなどシェル実行系の権限を最小化する: 構造化された編集ツールより保護が薄い経路になりうるため、未信頼リポジトリを扱うセッションでは実行可能なコマンドを制限する
- ワークスペースの信頼範囲を明確にする: 「フォルダを開く＝配下の操作を全面的に信頼する」という前提が自組織の運用に合っているかポリシーとして言語化する
- 未信頼の外部入力（Issue・PR・README）を読ませるエージェントには書き込み権限を分離する: GitLostが示すとおりread権限と投稿権限の組み合わせ自体がリスクになりうる
- サンドボックス環境（コンテナ・使い捨てVM）での実行を優先する: ホストの機微ファイルに到達できない環境で作業させることが最も確実な緩和策になる
- Augment・Windsurfを利用中の場合は特に注意する: 2026-07-09時点で両ツールは脆弱性を認識しつつ修正パッチを未リリースのため、未信頼のリポジトリを扱う際はサンドボックス化を優先するか、修正版のリリースまで利用を控えることを検討する
まとめ
今回はAIコーディングエージェントの信頼境界脆弱性、特にGhostApprovalについて解説しました。
この記事のポイント
- GhostApprovalは、承認UIの表示と実際の書き込み先がズレうるというCWE-451型の脆弱性で、Claude Codeを含む6製品に共通して確認されました
- Anthropicはこの脆弱性クラスを「脅威モデル外」として、正式な修正コミットをしていません
- 手元のClaude Code CLI（v2.1.205、2026-07-09時点）で検証したところ、Edit/Writeツールはシンボリックリンク経由の書き込みを明示的に拒否しましたが、Bashツール経由のシェル操作は素通りする挙動が確認できました
「承認プロンプトを押した＝安全」という感覚は、少なくともシェル操作を伴う運用においては過信になりうる、というのが今回の検証から言えることです。
AIコーディングエージェントを企業で運用している方は、承認フローの存在だけに頼らず、権限の最小化とサンドボックス化を合わせて検討してみてください。
関連情報のリンク
- GhostApproval: A Trust Boundary Gap in AI Coding Assistants（Wiz公式ブログ）
- GhostApproval Symlink Flaws Could Let Malicious Repos Run Code in AI Coding Agents（The Hacker News）
- GitLost: How We Tricked GitHub’s AI Agent into Leaking Private Repos（Noma Security公式ブログ）
- GitHub AI agent leaks private repos when asked nicely（The Register）
コメント