AIエージェントの脆弱性はモデルではなく設計にある

AIエージェントが「便利」になるほど、攻撃面が広がる理由

AIエージェントの強みは、メールを読み、コードを書き、外部のAPIやリポジトリにアクセスし、複数のタスクを自律的に実行できる点にある。だがその「自律性」は、攻撃者にとっても好都合だ。

大規模言語モデルは、ユーザーが与えた指示と、処理対象のメールや文書・コードに紛れ込んだ悪意ある指示を区別できない。これがプロンプトインジェクションの本質的な問題で、Ars Technicaはこの脆弱性をAIセキュリティ脅威のトップに位置づけている。AIエンジンの開発者自身が「信頼できる情報源と信頼できない情報源の境界を強制できない」と認めており、根本解決ではなくガードレールによる被害軽減にとどまっているのが現状だ。

エージェントが「便利」になるほど外部データへの接触が増え、接触が増えるほど悪意ある指示を踏む確率が上がる。この構造は、AIの能力向上と本質的にセットになっている。

「HalluSquatting」が変えた攻撃の常識

これまでのプロンプトインジェクションは「push型」が主流だった。攻撃者が個人のメールやカレンダー招待に悪意ある指示を仕込み、一人ひとりを狙う方式だ。各標的に個別に送り込む必要があるため、攻撃の規模には限界があった。

研究者が新たに考案した「HalluSquatting（adversarial hallucination squatting）」は、この限界を突破する。仕組みはシンプルで鋭い。LLMがコード補完やライブラリ提案の際に「幻覚」として挙げやすいパッケージ名やリソース識別子を予測し、攻撃者がその名前を先に登録してしまう。中身には逆シェルの導入やマルウェア取得の指示が仕込まれている。

AIコーディングツールは日常業務の中でリポジトリやレジストリからコードを取得する。そのタイミングで、何も知らないユーザーのデバイスが感染する。個別に標的を選ぶ必要がないため、大規模ボットネットの構築やDDoS攻撃への転用も理論上は成立するとされている。

報告によれば、この手法が機能すると確認されたツールはCursor、Cursor CLI、Gemini CLI、Windsurf、GitHub Copilot、Cline、OpenClaw、ZeroClaw、NanoClawの9製品。いずれも開発現場で広く使われているものばかりだ。

「安全なモデル」は存在しない——464人が証明した事実

モデルを変えれば解決するのか。464人の研究者・セキュリティ専門家が参加した大規模レッドチーミング競技が、その期待を否定する。

arxivに掲載された研究では、13のフロンティアモデルに対して272,000件の攻撃試行が行われ、41のシナリオで8,648件の成功攻撃が記録された。すべてのモデルが脆弱と判定されている。

攻撃成功率の幅は、Claude Opus 4.5の0.5%からGemini 2.5 Proの8.5%まで。数字だけ見ると差があるように映るが、Gemini 2.5 Proは高い能力と高い脆弱性を同時に示しており、「能力が高いほど安全」という直感は成立しない。研究はこの点を「能力とロバストネスは弱い相関しか示さない」と明記している。

攻撃戦略は41の挙動のうち21にまたがって複数のモデルファミリーへ転移する——つまり、あるモデルで通用した攻撃手法の半数以上が、別のモデルでも有効だということだ。

モデルの切り替えで脅威を回避しようとする発想には、この転移可能性が根本的な障壁になる。

企業が今すぐ見直すべき3つの設計原則

モデルに頼れないなら、設計で防ぐしかない。防御の核心は「AIが何に触れられるか」と「AIが何をできるか」を明示的に制限することだ。

外部データを「非信頼ゾーン」として扱う

メール、Slack、外部ドキュメント、Webコンテンツ——AIがこれらを処理する際は、その内容に含まれる指示を実行させない設計が必要になる。ユーザーの指示と外部データを処理の流れの中で分離し、外部データ由来のテキストがシステムの命令や実行コマンドに混入しない構造を作る。

ツールの権限を最小化する

AIエージェントにファイルの読み書き、コードの実行、外部APIの呼び出しをすべて許可するのは、管理者権限のアカウントを全社員に配るのと同じリスク構造だ。タスクごとに必要な権限だけを付与し、不要な操作は物理的に封じる。HalluSquattingへの直接的な対策としても、AIがパッケージを自動インストールする権限を持たせないことが有効になる。

人間の承認ステップを設ける

外部リソースの取得、コードの実行、データの送信など、取り消しのきかない操作の前には人間の確認を挟む。全操作に適用する必要はなく、「元に戻せない操作」に絞って設計すれば、自動化の恩恵を保ちながら致命的な誤作動を止める最後の砦になる。

GoogleはAmazon、Anthropic、Microsoft/GitHub、OpenAIと共同で合計1,250万ドルをオープンソースセキュリティに拠出すると発表しており、AI自身がセキュリティの穴を発見・修正するツール（Big Sleep、CodeMender）の開発も進んでいる。ただし、こうした業界の取り組みが実際の防御力として結実するまでには時間がかかる。自社の設計を見直す行動は、外部の支援を待たずに今日から始められる。

まとめ

AIエージェントのリスクはモデルの問題ではなく、設計の問題だ。「どのモデルが安全か」を調べる時間があるなら、「エージェントが触れる範囲と実行できる操作をどう絞るか」を設計する時間に使う方が実効性は高い。外部データの非信頼化、権限の最小化、人間の承認フロー——この三点を自社のAI活用ポリシーに組み込むことが、今取れる最も具体的な一手になる。