モデルが賢くなっても、
実行層の壁は要らなくならない。
「プロンプトインジェクションはほぼ解決した」——そう読める報道が出た直後こそ危険です。数字の中身を見ると、モデル単体の防御はまだ穴だらけで、フレームワーク側のバグはモデルの賢さとは無関係に居座っています。
「0%」という見出しの
裏側を読む
THE DECODER の報道によれば、Anthropic の Opus 5 を「Auto Mode」——受信データの隠し命令を先に検知する層と、危険な操作を実行前に止める層、二枚のソフトウェア防御を重ねたモード——と組み合わせたところ、129件のブラウザエージェント攻撃シナリオでプロンプトインジェクション成功率0%を記録しました。見出しだけを読めば「攻防は終わった」と受け取れます。
しかし同じ記事は、その0%が Auto Mode などの追加ソフトウェア層をオンにした場合限定の数字だと明記しています。追加層なしの Opus 5 単体では成功率3.7%。セキュリティ企業 Gray Swan が15回の攻撃試行で計測した数値も、Opus 4.8 の5.5%から Opus 5 では2.0%へ改善しただけで、ゼロではありません。OpenAI も2025年12月、プロンプトインジェクションは「完全には解決されないかもしれない」と自ら認めています。モデルは着実に強くなっていますが、「賢くなった」を「対策が要らなくなった」と読み替えるのは早計です。
誰に、どう効くか
モデル層のベンチマークが改善しても、現場でやることは変わりません。
開発者・エンジニア
エージェントに与える権限は引き続き最小化し、ファイル書き込みや決済、シェル実行のような危険操作には人間の承認ゲートを残す。モデルの安全性向上は「追加層を外していい理由」にはなりません。Semantic Kernel・CrewAI・LangChain・MCP 実装など、自分たちが使うフレームワークのアップデートとパッチ状況は個別に確認が必要です。
PM・プロダクト責任者
モデルのベンチマークが良くなったことを理由に、セキュリティレビューの頻度や承認フローを緩めるべきではありません。0%という数字はAuto Mode前提の条件付きの数字であり、自社の実装がその条件を満たしているかは別問題です。レッドチーム演習の頻度を維持する判断は、依然としてPM側の責任です。
同じ「Opus 5」でも
測り方で数字は変わる
条件を揃えずに「0%」だけを持ち出すと、実態を見誤ります。
モデルが強くなったことと、
対策が要らなくなったことは、別の話。
攻撃面は、モデルの
外側にもある
プロンプトインジェクション対策がどれだけ進んでも、実行基盤そのものに穴があれば意味がありません。
Microsoft Security Blog は、Semantic Kernel・CrewAI・LangChain など主要なAIエージェントフレームワークとMCP実装に、プロンプトインジェクションが実際のシェル・コード実行にまで連鎖しうる重大なRCE（リモートコード実行）脆弱性を報告しています。これはモデルの安全性訓練とは無関係な、実行基盤側のバグです。賢いモデルが、脆弱なフレームワークを自動的に直してくれるわけではありません。
さらにDev.toで公開された監査レポートによれば、13のAIエージェントフレームワークで56件超の脆弱性（うち重大なRCE級が6件）が見つかったと報告されました。件数の細部は独立に検証できていませんが、モデル耐性が向上してもなお、実行層の権限最小化は必要という結論を裏づける傍証にはなります。Auto Modeの0%も、あくまでその条件が有効な場合に限られる数字であり、多くの実運用がその条件を満たしているとは限りません。
次に、何をすべきか
権限最小化を崩さない
モデルのベンチマークが改善しても、エージェントに与える実行権限（ファイル・決済・外部API）は最小限のまま。Auto Modeのような追加層があるかどうかを前提に設計する。
危険操作には承認ゲートを残す
取り消しの効かない操作・支払い・外部送信を伴う操作は、人間の承認を経由させる。0%はテスト条件下の数字であり、本番環境の保証ではない。
レッドチームとフレームワーク監査を続ける
Semantic Kernel・CrewAI・LangChain・MCP など、実際に使っているフレームワークのアップデートとRCE関連の修正情報を継続的に確認し、パッチを適用する。