記事一覧に戻る
セキュリティ2026年7月10日6分で読めます

AIに守らせたら、そこが入口になった — Friendly Fire が示した防御AIの落とし穴

AI Now InstituteのPoC「Friendly Fire」は、Claude CodeやCodexに未信頼ライブラリのレビューを頼む行為そのものが、ローカル環境でのコード実行の入口になり得ることを示した。攻撃はAIの判断を突く。対策はAIを賢くすることではなく、騙されても被害が箱の中で止まる環境──「隔離して捨てる」哲学をローカルにも持ち込むことだ。

セキュリティレビューは、本来「攻撃を見つける」ための作業だ。

しかし AI Now Institute が公開した PoC「Friendly Fire」は、そのレビュー行為そのものが攻撃の入口になり得ることを示した。

構図は単純だ。

Claude Code や Codex に、未信頼のOSSライブラリをレビューさせる。すると、ライブラリ内の README やスクリプトに埋め込まれたプロンプトインジェクションが、AIエージェントを誘導する。

エージェントは、それを「レビューに必要な手順」だと解釈し、ローカル環境でコマンドを実行してしまう。

つまり攻撃者は、脆弱性を突くのではない。

AIの「防御らしい振る舞い」を突く。

ここが新しい。

問題は、AIの中ではなくローカルで起きる

ここで重要なのは、コードが「AIの中」で実行されるわけではないことだ。

Claude Code や Codex CLI は、開発者のローカル環境、または CI/CD の作業環境で動く。

つまり、AIが騙されてコマンドを実行した場合、その影響はAIベンダーのクラウドではなく、ユーザー側の環境に出る。

そこに SSH鍵、GitHubトークン、.env、クラウド認証情報、社内ネットワークへの到達性があれば、RCEの被害範囲は一気に広がる。

怖いのは「AIが騙された」ことではない。

騙されたAIが、どの権限を持った場所で動いていたかだ。

これは「悪いコードを実行した人」の話ではない

従来のマルウェアなら、実行した人間が問題になる。

しかし今回は違う。

人間は「このOSSをレビューして」と頼んだだけだ。

AIエージェントは、README を読み、スクリプトを見て、セキュリティ確認に必要そうだと判断し、実行する。

攻撃者は、人間を直接だますのではない。

AIの判断をだます。

だから、AIに「安全かどうか判断して実行して」と任せる設計そのものが危ない。

未信頼コードを読んだAIは、承認者にしてはいけない。 提案者にとどめるべきだ。

対策は、AIを賢くすることではない

この問題を「モデルがもっと賢くなれば直る」と見るのは危うい。

もちろんモデル改善は必要だ。だが本質はそこではない。

本当に必要なのは、AIが騙されても被害が広がらない環境を作ることだ。

ここで参考になるのが、Aikido の設計思想だ。

Aikido が説明している設計思想は、ユーザーのコードを恒久的に保存して解析するのではなく、リポジトリごとに一時的な解析環境を立て、必要な範囲だけを読み取り、解析後に環境を破棄する、というものだ。

コードは保存しない。 不要な認証情報を持たせない。 解析環境は使い回さない。 終わったら捨てる。

これは単なる実装ではない。

未信頼コードを扱うためのセキュリティ哲学だ。

ローカルAIにも同じ哲学が必要になる

Claude Code や Codex を、普段使いのMacや社内ネットワークに直結した開発PCでそのまま動かすのは危ない。

ローカルには、秘密が多すぎる。

SSH鍵。 GitHubトークン。 npm や PyPI の認証情報。 AWS や Azure のキー。 .env。 他のリポジトリ。 社内VPN。

AIエージェントが一度騙されれば、それらに触れる可能性がある。

だから、ローカルでも Aikido と同じ考え方を持ち込むべきだ。

対象リポジトリだけを渡す。 認証情報は渡さない。 ネットワークは絞る。 必要なら read-only にする。 実行はコンテナやVMの中に閉じ込める。 終わったら捨てる。

AIを信じるのではない。

AIが騙されても困らない場所で働かせる。

決定論的チェックを主、AIを補助にする

もう一つ重要なのは、役割分担だ。

依存関係、SBOM、既知CVE、署名、hash、到達可能性、許可されたコマンドかどうか。 こうしたものは、AIに判断させるより、機械的に確認した方がいい。

AIが得意なのは、説明、要約、仮説、修正案、優先順位付けだ。

つまり、こういう関係が正しい。

決定論的チェックが主。 AIは補助。

逆にしてはいけない。

AIを主にして、AIが「これは安全そう」と判断して実行する。 Friendly Fire が突いたのは、まさにその信頼境界の欠落だった。

結論

問題は、AIをセキュリティに使うことではない。

問題は、未信頼コードを読ませたAIに、実行権限、認証情報、ネットワーク到達性を同時に渡すことだ。

Aikido が一時コンテナでコードを解析し、終わったら丸ごと捨てるように、ローカルのAIエージェントにも同じ発想が必要になる。

防御AIに必要なのは、より賢いモデルだけではない。

必要なのは、捨てられる実行環境だ。

AIを信じるのではなく、AIが騙されても困らない場所で働かせる。

Friendly Fire が示した教訓は、そこにある。


本稿は AI Now Institute の PoC「Friendly Fire」、および Anthropic / OpenAI / Aikido の公開情報に基づく。現時点では PoC 段階であり、実環境での悪用報告は確認されていない。攻撃の再現手順には踏み込まず、構造と対策に焦点を当てている。

A

Aikido Community Japan

公開日: 2026/7/10

最終更新: 2026/7/9

シェア:

ニュースを購読

セキュリティの最新情報をお届けします。

Aikido Community Japan からのお知らせの受信に同意します。詳しくはプライバシーポリシーをご確認ください。