READMEが攻撃の入り口になる — AIにセットアップを任せる前の自衛3点
「このプロジェクトを動かせるようにして」とAIに頼むと、AIがREADME(プロジェクトの説明書)を読み、必要な部品(パッケージ)を自分でインストールして、環境を整えてくれる。Claude CodeやCodexのようなAIコーディングエージェントの、いちばん便利な使い方のひとつです。
その「いちばん便利な部分」が攻撃の入り口になる、という研究が2026年7月16日に公開されました。タイトルは直訳すると「セットアップ完了、あなたはもう侵害されています」。説明書などのセットアップ用ファイルに細工した場合、AIが不正な取得元や名前、脆弱なバージョンをどこまで見抜けるかを、12のシナリオで検証した論文です(出典: arXiv 2607.15143、Bagmar & Saraf https://arxiv.org/abs/2607.15143 )。
この研究から読み取れるのは、①文字抜けのような明白な偽名は比較的見抜ける、②既知の脆弱バージョンは事前に検出できなかった、③同じモデルでも実行環境を替えると結果が逆転する、の3点です。なお、この論文は査読前のプレプリント(研究者が正式な審査の前に公開する原稿)であり、第三者による検証を経ていない「未確認情報」です。実験も研究者が管理された環境で行ったもので、実際の被害事件の報告ではありません。それでも取り上げるのは、悪用される前の「対策の先回り」にこそ価値があるからです。
手口: 説明書に書くだけで、AIがインストールしてくれる
従来のサプライチェーン攻撃(部品の供給経路に細工する攻撃)は、人間の開発者の「うっかり」を待つ必要がありました。たとえばタイポスクワッティングという古典的な手口は、「transformers」に対して「tranformers」のような紛らわしい名前の偽パッケージを登録しておき、誰かが打ち間違えるのを待ちます。
AIコーディングエージェントが相手なら、待つ必要がありません。READMEやrequirements.txt(必要な部品のリスト)やMakefile(作業手順のファイル)に、細工した指示を書いておくだけです。AIはセットアップ指示として受け取ると、名前・取得元・バージョンを十分に検証しないままインストールを実行することがあります。論文は、この細工を5つの型に整理しています。
名前の細工: 「tranformers」のような明白な打ち間違い名から、「azurecore」と「azure-core」のようなハイフン1本の違いまで、紛らわしい偽名を説明書に書いておく
取得元の細工: パッケージを取ってくる先(レジストリ=部品の配布所)を、正規のPyPIではなく攻撃者のサーバーに向ける1行を混ぜておく
バージョンの細工: パッケージの名前は本物のまま、既知の脆弱性(セキュリティ上の欠陥)が残った古いバージョンを指定しておく
設定の細工: Makefileの中で、インストールの設定ファイルそのものを書き換えさせ、以後の取得先を乗っ取る
エラー表示の細工: プログラムの偽のエラーメッセージに「このパッケージを入れれば直ります」という誘導を仕込む
いずれも、リポジトリ内のREADMEや設定・セットアップ用ファイルを変更するだけで成立する攻撃です。プログラムの脆弱性を突く必要がありません。
実験結果: AIは「明白な偽名」は見抜くが、「古い脆弱バージョン」は素通しだった
著者らは、代表的な4つの実行環境(Claude Code、Copilot CLI、Codex CLI、Cursor)と複数のAIモデルの組み合わせに対して、12シナリオを繰り返し試しました。結果は一様ではありません(以下いずれも同論文の報告です)。
・文字抜けや転置のような明白な偽名は、多くの構成が検出した。一方、「azure-core」と「azurecore」のような区切り文字だけの違いは、構成によって見逃しが増えた
・既知の脆弱バージョンの指定は、検証した全構成が素通しした。インストール前に止めた構成はゼロで、一部のモデルがインストール後に警告しただけだった
・取得元の細工は、実行環境によって結果が大きく割れた。同じClaude Opus 4.8・同じ攻撃用リポジトリでも、Claude Codeでは10回中10回検出した一方、Copilot CLIでは30回中9回の検出にとどまり、21回はインストールまで進んだ。ただし別の取得元攻撃では優劣が逆転しており、特定の実行環境が常に安全という結果ではない
3点目がこの論文の核心です。AIコーディングエージェントの安全性は、AIモデル単体の性能ではなく、「モデル×実行環境」の組み合わせで決まる。「賢いモデルを選んだから安全」とは言えない、ということです。
もうひとつ、示唆的な発見があります。脆弱バージョンを通常のセットアップ指示だけで検出できなかったモデルも、インストール前に「各バージョンを既知のCVE(公開されている脆弱性情報の一覧)と照合せよ」と明示的に指示すると、代表例では拒否率が10回中2回から10回中10回へ上がりました。著者らは、AIに知識が欠けているのではなく、通常のセットアップ作業ではその確認が起動していない可能性を指摘しています。
これは机上の話か
この論文自体は管理された実験ですが、同じ発想の実証は他からも出ています。CyberKendraは2026年7月、AI Now Instituteの研究者による別の実証として、READMEに指示を仕込んだ細工済みリポジトリをClaude CodeやCodexに調査させ、攻撃者のコードを実行させる事例を報じています(出典: CyberKendra https://www.cyberkendra.com/2026/07/researchers-turn-claude-code-and-codex.html )。また、人間の開発者を狙ったタイポスクワッティングは以前から実際に観測されている手口で、対策については日本語の技術解説も公開されています(対策例: Zenn「Python開発での包括的サプライチェーン攻撃対策」 https://zenn.dev/dajiaji/articles/47164ff27d2123 )。
つまり「説明書経由でだます」という手口の部品は、すでに現実に存在します。著者らは本論文を、AIエージェント相手にそれがどこまで通るかを複数の実行環境をまたいで初めて系統的に評価した研究だと位置づけています。
日本企業にとっての意味
日本でもAIコーディングエージェントの導入は「開発の生産性向上」の文脈で進んでいます。この研究が導入判断に投げかける問いは3つです。
何が重要か: 危ないのは「AIが書くコード」だけではなく、「AIが実行するセットアップ」も同じだという点です。多くの会社のAI利用ガイドラインは生成コードのレビューは定めていても、AIによるパッケージインストールを想定していません
どこが本質か: 安全性が「モデル×実行環境」の組み合わせで決まるなら、PoC(試験導入)でモデル名だけを比較しても安全性は評価できません。「どの環境で、どの設定で動かすか」まで含めて評価項目にする必要があります
どう応用するか: 幸い、この攻撃への対策の多くは、人間の開発者向けにすでに確立されたサプライチェーン対策の転用です。社内レジストリ、ロックファイル(取得する部品と版を固定する仕組み)、依存関係スキャンを「AIエージェント経由のインストール」にも適用すればよい、ということです
会社で使う前の自衛3点
インストールを自動承認にしない。多くのエージェントには、コマンド実行前に人間の確認を挟むモードと、確認なしで走る自動モードがあります。信頼できないコード(社外から持ち込んだOSSなど)を扱う作業では、確認モードを既定にしてください。論文では、実行前のチェックポイントが検出を助けた例が報告されています。ただし攻撃の型によっては別の実行環境の方が高い検出率となっており、確認画面の有無だけで安全性が決まるわけではありません。それでも、人間が不審なコマンドを止める機会を残すため、自動承認を避けることには実務上の意味があります
取得元と版を人間側で固定する。社内レジストリやロックファイルを使い、「AIが何をインストールするか」をAIの判断に委ねない構成にします。既存のサプライチェーン対策の多くを、AIエージェント経由のインストールにも適用できます
拾ってきたリポジトリは使い捨て環境で開く。出所の不確かなプロジェクトをAIにセットアップさせるときは、業務の認証情報が入っていないサンドボックス(隔離された使い捨て環境)で行います。だまされても、失うものがない場所でだまさせる、という発想です
ベンダーや製品を評価する立場の方は、「エージェントがインストールを実行する前に、パッケージの名前・取得元・脆弱性を検証する仕組みはあるか」を確認項目に加えてください。聞くべき質問のセットは記入式テンプレにまとめています → https://note.com/genten_kei/n/n7f8474f24bf6
用語集
・AIコーディングエージェント: 指示を受けて、コードの作成だけでなくコマンド実行やファイル操作まで自分で行うAI。Claude Code、Codex、Cursorなど
・サプライチェーン攻撃: ソフトウェアの「部品の供給経路」に細工して、利用者に悪意あるプログラムを届ける攻撃
・タイポスクワッティング: 有名なパッケージと紛らわしい名前の偽パッケージを登録しておく古典的な手口
・レジストリ: パッケージの配布所。Pythonなら PyPI、JavaScriptなら npm が代表
・ハーネス(実行環境): AIモデルを実際に動かす側の仕組み。同じモデルでも、どのハーネスで動かすかで挙動が変わる
・プレプリント: 査読(専門家による審査)前に公開される論文原稿。有益だが未確認情報として扱う
続きは
AIの解釈を操る攻撃(プロンプトインジェクション)の全体像 — 8つの構造的リスクと対策9項目、社内チェックリスト31項目 — は、NSAガイダンス17ページの完全読解記事にまとめています。→ https://note.com/genten_kei/n/nbfe402282a61
本記事はAI(Claude)を活用して執筆し、公開前に人間がレビューしています。
