【ITニュース解説】91% Passed, 25% Safe: Why Your Coding Agent Ships Code That Works and Gets You Hacked

AIコーディングエージェントは、ソフトウェア開発の現場に革新をもたらすと期待されている。しかし、これらのエージェントが生成するコードには、機能性と安全性という二つの重要な側面において、見過ごされがちな大きなギャップがあることが最新の研究で明らかになった。「Last Secure Code Benchmark (LSCBench)」と呼ばれるこの新しいベンチマークは、AIが書くコードが「意図通りに動作する」ことと「攻撃に対して安全である」ことは別物であると強く警鐘を鳴らしている。

LSCBenchは、シンガポール国立大学とアリババグループの研究者によって開発され、実際の150種類の脆弱性に基づいた450のコード生成タスクを用いて、最先端の6つのAIエージェントを評価した。このベンチマークの重要な特徴は、タスクのプロンプトに「セキュリティ」に関する指示を一切含まないことだ。これは、開発者が通常、AIに機能要件だけを伝える現実的な状況を再現している。評価は、機能テストと、元の脆弱性を再現するセキュリティテストの両方がパスした場合にのみ「成功」と見なされるという厳格な基準で行われた。

この評価の結果は衝撃的だった。最も性能の高いエージェントでさえ、生成したコードの機能テストパス率は91%と高かったが、セキュリティテストをパスし、安全であると判断されたコードはわずか25%程度に過ぎなかったのだ。全体の実行の66%は、機能的には動作するものの、依然として脆弱性を抱えたコードだった。これは、機能テストがすべて「グリーン」（合格）であっても、そのコードが製品として出荷できるほど安全であるとは限らないという事実を明確に示している。

例えば、Javaの設定インポーターを実装するタスクでは、あるエージェント（Kimi-K3）が機能テストをすべてパスするコードを生成した。しかし、そのコードは脆弱なYaml()コンストラクタを使用しており、信頼できないYAMLファイルに含まれる悪意のあるクラスをロードする可能性のある「デシリアライゼーションの脆弱性」を含んでいた。一方、別のエージェント（Claude Fable 5やGPT-5.6-Sol）は、より安全なSafeConstructorを選択し、機能とセキュリティの両方のテストをパスした。この事例は、AIが「機能要件を満たす」という目標に対し、セキュリティリスクの高い、より直接的な手段を選びがちであることを示している。AIは、提示された仕様にない「セキュリティ」という側面を自律的に考慮する能力が不足していると言える。

さらに、LSCBenchは、AIが特に苦手とする脆弱性の種類があることを示した。メモリ安全性の問題は比較的修正されやすく、安全なコードとして生成される割合が高かった。しかし、SSRF（サーバーサイドリクエストフォージェリ）や情報漏洩といった脆弱性に関しては、安全なコードの生成率は極めて低く、それぞれ3%、1%程度であった。

なぜこれらの脆弱性がAIにとって特に難しいのか。それは、SSRFや情報漏洩が、コードの特定の箇所を修正するだけでは解決せず、システム全体の構造、データフロー、他のコンポーネントとの連携といった、より広範な文脈を理解し、モデル化する必要があるためだ。例えば、SSRFでは「このURL入力がシステム内でどこまで到達しうるか」、情報漏洩では「この設定情報がどこに出力され、誰に読まれる可能性があるか」といった全体像の把握が求められる。AIエージェントは、与えられた機能の実装に集中するあまり、こうしたシステム全体の振る舞いや潜在的なセキュリティリスクを見落とす傾向がある。実際に、Go言語のSSRFタスクでは、あるエージェントがfile://URLを含む任意のパスを読み取る関数を生成し、危険なファイルアクセスを許してしまった。また、情報漏洩タスクでは、全モデルが機密情報（認証パスワードなど）を設定ダンプや出力ファイルに含んでしまうコードを生成した事例も報告されている。これらは、人間であればレビューで容易に発見できるはずの初歩的な脆弱性であるが、AIエージェントはそれを「見落としていた」のである。

この問題に対し、研究者たちは簡単な対策を試みた。プロンプトの最後に「機能要件を満たしつつ、同時に安全であること」という一文を追加したのだ。このわずか一文で、一部のエージェントでは安全なコードの生成率が大幅に向上した。例えば、GPT-5.6-Solでは24.7%から46.2%へと約2倍近く改善された。これは、AIエージェントがセキュリティに関する知識を内部に持っているものの、それを「引き出す」ためのトリガーが不足していることを示唆している。しかし、SSRFや情報漏洩といった複雑な問題については、この一文だけでは改善効果がほとんど見られなかった。

この研究は、システムエンジニアを目指す初心者にとって重要な教訓をいくつも提示している。第一に、AIが生成したコードを鵜呑みにせず、常に批判的な視点を持つべきだということだ。機能テストが合格しても、そのコードは攻撃に対して脆弱である可能性が高い。そのため、機能テストだけでなく、攻撃シナリオを想定した「セキュリティテスト」を必ず実施し、AIのコードを多角的に検証する体制が必要となる。

第二に、AIの失敗は「間違い」というより「見落とし」であるという点を理解することだ。AIは安全な実装方法を知っていても、明示的な指示がなければそれを選択しないことがある。そのため、開発者はプロンプトを設計する際に、「安全であること」を明示的に、かつ具体的に指示することが重要となる。例えば、入力値の検証、安全なAPIの選択、アクセス権限の適切な設定など、セキュリティに関する具体的な制約をプロンプトに含めることで、AIがより安全なコードを生成する手助けができる可能性がある。

AIは強力な開発ツールとなり得るが、その出力を最終的に責任を持ってリリースするのは人間のシステムエンジニアである。AIが生成するコードの潜在的なリスクを理解し、機能性と安全性の両面から厳しく評価し、必要な修正や追加の対策を講じる能力こそが、これからのシステムエンジニアに求められる不可欠なスキルとなるだろう。