LSCBench公開、AIのコードは安全と動作の両立が最良25%
AIコーディングエージェントが書いたコードは、動くかどうかだけでなく、安全かどうかでも測られ始めました。この記事では、10月に公開された「Last Secure Code Benchmark（LSCBench）」の内容と結果を、公開されているページをもとに整理します。あわせて、新規事業のシステム開発で何を決めておくとよいかを、私たちの見方として書きます。
10月に公開された、AIのコードの「安全さ」を測る試験
LSCBenchは、コーディングエージェントが「頼まれていない安全性」まで満たすコードを書けるかを測るベンチマーク（性能を比べるための共通の試験）です。セキュリティについて誰も指示しない状況で、安全なコードを書くかどうかを測る設計になっています。
公開の時期は次のとおりです。
- GitHubのリリース（v1.0）は10月9日付
- 論文はarXivへ10月10日に投稿されたと報じられている
GitHubのリポジトリは alibaba の名前で公開されています。リーダーボードの元になった2,700回分の実行記録（6モデル×450課題）も一緒に公開されています。結果を自分たちで確かめられる形になっている点は、この種の発表では大事なところです。
公式ページで確認できた測り方と結果
測り方：脆弱性のあったコードを消して、作り直させる
課題は、実在のプロジェクトから、かつて脆弱性があった部分のコードを取り除き、仕様書をもとにエージェントに作り直させる形です。課題の文面にセキュリティへの言及はありません。
採点は2回行われます。機能テストで動作を確かめ、セキュリティテストでは、実行中のプログラムに元の攻撃手順を再現します。
課題の規模と範囲は次のとおりです。
- 150の脆弱性シナリオから450課題を作り、それぞれを関数・ファイル・リポジトリの3つの粒度で用意
- 7つのプログラミング言語と24種類の弱点分類（CWE）にまたがり、2025年のCWE上位25のうち21を含む
- シナリオのうち115は実在のCVE（公開されている脆弱性）から、35は専門家が書いたJavaアプリ
結果：動くコードは多いが、安全との両立は少ない
6つのエージェントで、機能テストの通過率は73.6〜91.3%。ただし最も良い結果でも、機能と安全の両方を満たしたのは課題の25.1%で、他は16.4〜24.7%でした。論文の要旨で名前が挙がっているのは、最も良かったClaude Fable 5だけです。モデルごとの内訳は、プロジェクトのページで見られます。
そのほかに、公開ページや論文から確認できた点を挙げます。
- 2,700回の実行のうち66%は、動くものの脆弱性が残るコードで終わった
- 最良のモデルでも、3つの粒度すべてで両方を満たせたシナリオは12%
- 150シナリオのうち57は、どのモデルでも安全にならなかった
- 動くコードのうち安全だった割合は、情報の露出で1%、サーバー側リクエスト偽造（SSRF）で3%、入力の検証と制限で17%、アクセス制御で20%
最後の分類別の数字は、シナリオ数が少ない分類も含みます（情報の露出は8、SSRFは7）。細かな差を読み取りすぎないほうがよさそうです。
この数字から言えることと、言えないこと
ここまでは公開されている事実です。数字の読み方について、私たちが注意したい点を挙げます。
- 「安全を頼んだ場合」は測っていない。 課題の仕様に安全性は書かれていません。仕様に書けば結果が変わるのかは、この結果だけでは分かりません。
- 作り直しの課題である。 既存プロジェクトから一部を消して作り直させる形式です。ゼロから事業のシステムを作る場面と、同じ条件ではありません。
- 6モデルの結果である。 今後のモデルや、他のエージェントの組み合わせで同じになるとは限りません。
- 安全でないコードが実害になるかは、使い方次第。 テストは既知の攻撃手順の再現で判定しています。実際の被害は、公開範囲や扱うデータで変わります。
一方で、「機能テストの通過率が高くても、安全の指標は別に動く」という点は、課題の作りそのものから読み取れます。
新規事業の開発で変わること（編集部の見方）
ここからは事実ではなく、私たちの見方です。
「動いた」と「安全」は、別々に確かめる項目になる
AIに頼むと、画面が動くところまでが速く進みます。動いている実物を見ると、完成に近いような感覚になりやすいものです。ただ今回の結果は、動作の確認と安全の確認が別の作業であることを数字で示しています。
実物を見て判断するやり方は、事業の方向性を確かめるうえで有効です。そのときも、「動く」ことが確かめられたのであって、「安全」が確かめられたわけではない、と分けて考えておくのが落ち着いた捉え方だと思います。
事業が扱うデータによって、確認の重さが変わる
分類別の結果では、情報の露出やアクセス制御の数字が低めでした。会員情報、取引情報、他社のデータなどを扱う新規事業では、ここが事業の信頼に直結します。
扱うデータが少ない試作段階と、実際のお客様に公開する段階とでは、確認の深さを変えるほうが現実的です。確認の考え方は、AI生成コードのセキュリティ｜確認点と人の役割でも整理しています。
安全に関することは、要件として言葉にしておく
課題の仕様に安全性が書かれていない、という条件は、実際の開発でも起こりえます。発注側が機能だけを伝えると、安全に関する要件が抜けたまま進みます。
誰がどのデータを見られるのか、外部のURLへ接続する機能があるのか。こうした点は、機能の要件と並べて決めておく項目です。進め方は要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方で扱っています。AI任せの進め方との違いは、バイブコーディングとは｜AI駆動開発との違いと事業での使い方にまとめました。
確認の目を複数持つ意味が、数字に表れている
論文には、モデルごとに安全にできた課題の集合が違う、という結果もあります。6モデルを合わせると450課題のうち198（44.0%）は少なくとも1つのモデルで安全になり、最良の単独モデルは113（25.1%）。6モデルすべてが安全にできたのは19課題だけでした。
これはレビューの効果を測った結果ではありません。そのため、複数のAIを重ねれば解決する、とまでは言えません。ただ、1つのAIの出力だけで判断せず、確認の視点を複数持つことには意味がありそうです。最終的な品質判断を人が担う理由は、AI開発でも品質には人の確認が必要な理由に書いています。
なお、開発に使うAIツール自体の弱点は別の話です。10月の競技会での実演はPwn2OwnでCodexとLiteLLMの脆弱性を実演で取り上げました。
まとめ
LSCBenchは、AIコーディングエージェントのコードが動くかどうかと、安全かどうかを別々に採点した試験です。公開された結果では、機能テストの通過率は73.6〜91.3%でした。一方で、機能と安全の両方を満たしたのは、最良でも450課題の25.1%でした。
この数字は、特定の課題形式と6モデルの結果です。AIのコード全般に当てはめるものではありません。ただ、「動いた」だけで判断しない、安全に関わる要件を言葉にしておく、確認の場所を決めておく、という基本の大切さは変わりません。
JustFitは、株式会社LEGAREAが運営する受託開発サービスです。AIを活用した独自の開発基盤「LAF」では、要件定義・設計・DB設計・実装・テスト・レビューの専門AIがチームとして開発を進め、人は「何を作るか」を決めることと「品質の最終判断」を担います。今回のような結果は、AIと人の分担をどう置くかを考える材料になります。詳しくはJustFitのサービス紹介をご覧ください。