AIコーディングツールはハッキングされている——御社の開発チームは安全ですか？

問題点

READMEファイルに埋め込まれた隠し指示によって、GitHub Copilotはシェルコマンドの実行、マルウェアのダウンロード、ボットネット構築の権限を自らに付与するよう仕向けられました。これは仮定の話ではありません。2025年8月、セキュリティ研究者らがCVE-2025-53773を公表した際に実際に起きたのです——深刻度スケール10点満点中7.8のクリティカルな脆弱性でした。

この事案を恐ろしいものにしているのは次の点です。開発者はCopilotに「コードをレビューして」あるいは「プロジェクトを説明して」と頼んだだけです。AIはプロジェクトファイルに隠された汚染された指示を読み込み、研究者たちが「YOLOモード」と呼んだものを有効化するために設定ファイルを密かに書き換えました。このモードでは、AIは人間の承認ゼロで開発者のマシン上でコマンドを実行できました。マルウェアをダウンロードできます。認証情報を盗めます。ワークステーションをボットネットのノードに変えることも可能でした。

これだけが侵入事例ではありません。同じ年、マイクロソフトのBingキャッシュが16,000を超える組織（IBM、Google、PayPalを含む）のプライベートリポジトリを晒してしまいました。さらに、ハッカーが95万件以上インストールされていたAmazon Q公式VS Code拡張機能に破壊的なコマンドを注入しました。3つの別個のインシデント。3つの異なる攻撃手法。共通する糸は1本——御社のAIツールは思っている以上の権限を持っており、攻撃者はその悪用方法を知っている、ということです。

なぜ御社のビジネスにとって重要なのか

これらは研究論文に埋もれた理論上のリスクではありません。実際の本番システム、現実の企業、現場の開発者を直撃しました。数字が物語ることは次のとおりです：

• 16,000以上の組織が、Microsoft CopilotのBingキャッシュ経由でプライベートなコードリポジトリを晒されました。独自のソースコードや内部ドキュメントも含まれています。
• 300以上のプライベートトークンとAPIキーが抽出されました——AWS、Google Cloud、OpenAI、Hugging Face環境へのアクセスを解錠する鍵です。
• 950,000人以上の開発者が、悪意のあるコードが発見される前に、危殆化したAmazon Q拡張機能をインストールしていました。
• 20,000以上のリポジトリが、組織がプライベートなアーカイブだと信じていた場所から引き出されました。

御社の会社のコードリポジトリに今この瞬間何が入っているか考えてください。データベースの認証情報。APIキー。内部アーキテクチャ文書。顧客データ処理ロジック。開発者が外部サービスに接続するAIコーディングアシスタントを使っていれば、すでに晒されているかもしれません。

規制面の状況は事態をいっそう悪くします。2025年版OWASP Top 10 for Large Language Model Applicationsは現在、「過剰なエージェント性（Excessive Agency）」と「サプライチェーン」攻撃を最上位のリスクに挙げています。監査人と規制当局は急速に追いついてきています。AIツールが人間の承認なしにコマンドを実行できるなら、それは取締役会が知るべきコンプライアンスギャップです。そして、削除した後のデータがサードパーティのキャッシュに現れた場合、存在すら知り得なかったデータ保護違反に直面しかねません。

実際に何が起きているのか——内部の仕組み

核心の問題は単純です。ほとんどのAIコーディングツールは、汎用言語モデルの上に築かれた薄いラッパーにすぎません。パターンに基づいて次にくる確率の高い語を予測しています。真実を理解しない——もっともらしさを理解するのです。しかも、御社のシステムへのアクセス権が広すぎます。

例えるなら、あらゆる言語を流暢に話すが判断力のない、非常に熱心なインターンを雇うようなものです。管理者資格情報を渡し、「手伝ってくれ」と言う。彼らは誰から頼まれようが何でもやります——インターンの読み物の山に誰かがメモを紛れ込ませたら、それも実行します。

Copilot脆弱性で起きたのはまさにこれです。AIは開発者の全権限を継承しました。コードコメントやREADMEテキストに偽装した隠しプロンプトインジェクション——一連の指示——が、AIに自身の設定ファイルの変更を命じたのです。そのスイッチが切り替わった瞬間、マシン上の任意のコマンドを実行できました。従来のアクセス制御が無力だったのは、AIがユーザー「の代わりに」動いていたからです。

Bingキャッシュ問題は仕組みこそ違いますが、根因は同じです。AIツールが文脈のために外部検索エンジンに依存すると、データライフサイクルの制御を失います。Bingは公開リポジトリをクロールしました。御社は非公開にしました。キャッシュされたコピーは残ったままです。AIは尋ねる誰に対してもそのコピーを提供し続けました。ホワイトペーパーはこれを「Zombie Data（ゾンビデータ）」と呼んでいます——破壊したつもりの情報が、AI検索システム内で生き続ける現象です。

どちらのケースでも、脆弱性はアーキテクチャそのものです。「安全に」とAIに言い聞かせる言葉をいくら積み重ねても、ハードな境界を前提に設計されていないシステムは修正されません。

機能する対策（と、しない対策）

まず、失敗する対策から見ていきます。

AIに注意するよう指示すること。 今日のAI安全性の大部分は言語的指示に依存しており、要するにモデルに「有益で無害であれ」と頼んでいるだけです。2025年の侵入事例は、攻撃者がプロンプトインジェクションと脱獄（jailbreaking）でこうした指示を迂回できることを証明しました。言葉ではコード実行を止められません。

従来型のアクセス制御に頼ること。 ファイアウォールやロールベースの権限は、ユーザー権限を継承するAIエージェント向けに設計されていません。Copilotの悪用はファイアウォールを突破しませんでした。AIを説得して自身の設定ファイルを書き換えさせたのです。

データをサードパーティAIプロバイダーに預けること。 AIが外部の検索キャッシュやサードパーティAPIに依存すると、データライフサイクルの制御を手放すことになります。Zombie Data危機が示したのは、削除されたデータが制御下にないシステム内で無期限に残留しうるという現実です。

では、何が本当に機能するのでしょうか。必要なのはアーキテクチャ的ガードレール——プロンプト内の指示ではなく、システムのランタイムに焼き込まれたハードな制限です。

1. 入力の分離。 AIが読むすべてのプロンプト——READMEファイル、コードコメント、プロジェクトドキュメントを含む——を潜在的に敵対的な入力として扱います。AIが読めるものと実行できるものの間に厳格な境界を強制します。特定の設定ファイルやシステムコールは、プロンプトが何と言おうと、AIエンジンから物理的にアクセス不能であるべきです。

2. 決定論的ロジックゲート。 言語モデルを、チェックポイントとして機能するルールベースのシステムと組み合わせます。AIがアクションを提案し、別個のロジックエンジンがハードコードされたルール——「人間の承認なしにシェルコマンドを実行しない」「本番環境のリソースを削除しない」など——に対してそのアクションを検証します。ルールに違反していれば、システムは実行前に拒否します。これがニューロシンボリックアプローチの中核です——AIの言語能力と、御社のルールを強制する独立した推論システムを組み合わせます。

3. クローズドループのデータ取得。 AIモデルを完全に自社環境内に配備します。コンテキスト取得には外部の検索キャッシュもサードパーティAPIも一切使用しません。もし データ取得システムを自社インフラ上で稼働させていれば、Zombie Dataによる情報露出は技術的に発生し得ません。どの外部システムもデータに一切触れないからです。

監査証跡の優位性は、コンプライアンスチームにとって最も重要です。すべてのAIアクションが決定論的ロジックゲートを通過すれば、AIが何を、なぜ行ったのかの完全で検証可能な記録が得られます。提案されたすべてのアクション、すべてのルールチェック、すべての拒否——すべてがログに記録されます。そして御社の セキュリティ評価・ハードニングプロセス にこのアーキテクチャが組み込まれていれば、AIがどのように意思決定を行っているかを規制当局や監査人に正確に示せます。それが、AIが適切に振る舞うことを願うだけの状態と、それを証明できる状態との違いです。

2025年の侵入サイクルは、プロンプトファイルが新たな攻撃対象領域であることも証明しました。組織はプロンプトテンプレートを実行可能コードとして扱うべきです。つまり、暗号署名、バージョン管理、そしてプロンプトテンプレートがAIエージェントの動作に影響を与える前のセキュリティレビューが必要です。Amazon Qの危殆化が成功したのは、「cleaner.md」という名前の悪意あるプロンプトファイルがソースツリーに直接コミットされ、出荷前に誰一人捕捉できなかったからです。影響を受けたのは 約100万人の開発者。

AIツールは御社の味方として働くべきであり、敵として働くべきではありません。しかし、そのためには後付けの安全対策ではなく、最初から安全性を前提に設計されたアーキテクチャが必要です。

詳細な技術分析を読む ことで、各侵入事例とそれを防ぐ具体的なアーキテクチャパターンについて深く掘り下げられます。また、 インタラクティブ版を開く ことで、ガイド付きのウォークスルーを体験できます。