AIコーディングエージェントを狙う「きれいなリポジトリ」攻撃。開発現場の新しい供給網リスク
AIコーディングエージェントの普及で、開発者の作業速度は大きく上がりました。リポジトリを読ませ、セットアップさせ、テストを走らせ、修正案まで出してもらう。ここまでは便利です。ただし、その便利さは新しい攻撃面にもなっています。
BleepingComputerは2026年6月27日、一見すると安全に見えるGitHubリポジトリをAIコーディングエージェントに扱わせることで、マルウェア実行につながりうる手法を報じました。MozillaのZero Day Investigative Network、通称0DINの研究では、明確な悪性コードや目立つ警告がない状態でも、エージェントのセットアップ手順を通じて攻撃が成立する可能性が示されています。
これは「怪しいファイルを実行しない」という従来の防御だけでは足りない、という話です。AIエージェントは、README、設定ファイル、フック、MCP設定、ツール固有のルールを「作業に必要な指示」として読みに行きます。攻撃者はそこを狙います。
なぜ海外で話題なのか
Hacker Newsやセキュリティ系コミュニティでは、AIコーディングツールの便利さと危うさが同時に議論されています。特に問題なのは、攻撃が従来のマルウェアの形を取らないことです。
Mitigaの調査では、偽の採用課題リポジトリに隠された指示によって、AIアシスタントがAWS認証情報を探し、クラウド環境やKubernetes環境を調べ、外部へ送信するまでを短時間で実行した事例が説明されています。SafeDepも、Miasma wormの一部がGitHubリポジトリ側に入り込み、Claude Code、Gemini CLI、Cursor、VS Codeなどの設定を悪用して自動実行される流れを報告しています。
つまり攻撃者は、開発者本人をだますだけではなく、開発者が信頼しているAIエージェントをだますようになっています。
注目ポイント
第一に、AIエージェントは「読むだけ」の存在ではありません。多くのツールは、依存関係のインストール、テスト実行、シェルコマンド、ファイル編集、外部APIアクセスまで行います。読み込んだ指示が悪意あるものであれば、エージェントは攻撃者の作業員になってしまいます。
第二に、危険な場所がソースコード本体だけではなくなっています。CLAUDE.md、AGENTS.md、.cursor/rules、.claude/settings.json、MCP設定、VS Codeタスク、package.jsonのスクリプトなど、エージェントが参照する周辺ファイルが攻撃面になります。人間のコードレビューでは見落としやすい場所です。
第三に、認証情報の被害が深くなります。ローカルPC上の秘密鍵やクラウド認証情報、CI/CDの長期トークンが盗まれると、端末を掃除しても被害は残ります。攻撃者はその認証情報を使って、開発環境の外側にあるクラウドや本番環境へ移れます。
日本の読者が見るべきポイント
日本の開発現場でも、AIエディタやClaude Code、Gemini CLI、Copilot系エージェントの利用は広がっています。個人開発だけでなく、受託開発、スタートアップ、社内DXでも「とりあえずAIに読ませて動かす」場面は増えています。
ここで危ないのは、外部リポジトリをそのままAIに開かせる運用です。採用課題、OSS検証、サンプルプロジェクト、ライブラリのデモ、取引先から渡されたコード。これらは見た目が普通でも、AI向けの指示ファイルや自動実行設定を含んでいる可能性があります。
実務では、AIエージェント用の権限を人間の開発者より狭くするべきです。まず読み取り専用で確認する。未知のリポジトリは隔離環境で開く。クラウド認証情報や本番トークンを持つ端末で、外部コードをAIに操作させない。こうした基本が重要になります。
すぐできる対策
未知のリポジトリを開く前に、エージェント向け設定ファイルを確認します。AGENTS.md、CLAUDE.md、.cursor、.claude、.gemini、MCP設定、VS Codeタスク、postinstallやtestスクリプトは重点的に見るべきです。
次に、AIエージェントの自動実行を切ります。少なくとも初回読み込み時に、コマンド実行、依存関係インストール、外部通信を自動承認しない設定にする。承認ダイアログが出ても、内容を読まずに許可しない。
さらに、短命の認証情報を使います。長期のAWSキー、GitHub PAT、本番DBの接続情報を開発端末に置いたまま、AIエージェントに外部リポジトリを触らせるのは危険です。盗まれて困る鍵は、そもそも作業環境に置かない設計が必要です。
注意点
AIエージェントを禁止すれば安全になる、という単純な話ではありません。開発効率のメリットは大きく、セキュリティレビューやテスト生成にも役立ちます。問題は、エージェントを「信頼済みの同僚」として扱いすぎることです。
AIエージェントは、悪意ある指示と正当な指示を常に正確に区別できるわけではありません。だから、モデルの賢さだけに頼らず、権限、隔離、ログ、承認、秘密情報管理で守る必要があります。これはAIの問題というより、開発プロセス全体の設計問題です。
まとめ
AIコーディングエージェントの時代には、リポジトリは単なるコードの置き場ではなく、エージェントへの命令セットにもなります。攻撃者はそこを理解し始めています。
これからの開発現場では、「このコードは安全か」だけでなく、「このリポジトリをAIに読ませたとき、何が実行されるか」を確認する必要があります。AIを使うほど、開発者はコードレビューだけでなく、エージェント運用レビューも持つことになります。
出典メモ: Hacker Newsで共有されていたAIコーディングエージェント攻撃の話題、BleepingComputer、SafeDep、Mitiga Labsの公開調査をトレンド確認に使用しました。