【AI×セキュリティ】AIが書いたコードの脆弱性｜「動くけれど安全とは限らない」バイブコーディングを解く

【AI×セキュリティ】AIが書いたコードの脆弱性｜「動くけれど安全とは限らない」バイブコーディングを解く AIセキュリティ

「制作会社から、最近は AI を使って開発しているので早く安く作れますと言われた」「社内でも、ちょっとした集計ツールや問い合わせフォームを AI に書かせて動かしている」。そんな話を聞く機会が、ここ 1〜2 年でぐっと増えました。

画面のとおりに動いて、テストで入力した値も正しく処理される。それなら問題ないように思えます。でも、セキュリティの弱点は「普通に使っている限りは見えない」ところに潜むものです。AI が書いたコードは、本当に安全と言えるのでしょうか？

この記事では、AI にほぼ任せきりでコードを書かせる「バイブコーディング」のリスクを、公的な資料と最近の研究 3 本から整理します。そのうえで、開発を外部に頼む側・社内で AI を使う側が何を確認すればよいかをまとめます。コードの書き方そのものより、「発注と運用で何を聞き、何を仕組みにするか」に焦点を当てます。

バイブコーディングとは：OWASP も「次点のリスク」に挙げた

バイブコーディング（vibe coding）は、人がやりたいことを言葉で伝え、細かい中身は確かめないまま AI が書いたコードを採用していく開発スタイルを指す言葉です。ウェブアプリのセキュリティで定番の資料である OWASP Top 10 の 2025 年版は、10 位以内には入らなかったものの注目すべき次点の項目として、「X03:2025 AI が生成したコードへの不適切な信頼（バイブコーディング）」を挙げています。

OWASP はこの項目で、ほぼ人の目を通さずにコードが書かれ、取り込まれる開発が広がっていると指摘しています。そして対策として、AI が書いたものでも提出する人がすべてのコードを読んで理解できること、取り込んだコードには自分が責任を持つこと、脆弱性がないかを自分の目と静的解析などのツールの両方で確かめることを求めています（OWASP Top 10:2025「Next Steps」）。

オープンソースのセキュリティ向上に取り組む OpenSSF も、AI コーディング支援ツール向けの指針を公開しています。要点として最初に挙げているのは「開発者が主で、AI は補助」という考え方です。コードが引き起こす害の責任は開発者にあり、AI のコードも同僚が書いたコードと同じように批判的に確認すること。そして、AI のコードだからといってコードレビュー・テスト・静的解析などの工程を省いてよいわけではない、と明記しています（OpenSSF「Security-Focused Guide for AI Code Assistant Instructions」）。

どちらの資料も、言っていることはシンプルです。「AI が書いたかどうかに関係なく、確かめる工程を残す」。では、確かめないと実際に何が起きるのか。研究の結果を見ていきましょう！

📄 論文: 「動く」と「安全」はこれだけ違う

Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks（Songwen Zhao ほか、2025年12月、arXiv:2512.03262）は、ICML 2026 採録の論文です。

研究チームは、実在するオープンソースのプロジェクトから、過去に人間の開発者が脆弱な実装をしてしまった機能追加の課題を 186 件集めました。それを AI のコーディングエージェント（指示を受けて自分でファイルを読み書きし、コードを完成させる AI）に解かせ、「機能として正しく動くか」と「脆弱性がないか」を別々に判定しています。主要なモデルを組み合わせた 12 通りの構成で試したところ、どの構成もセキュリティの面では成績が振るいませんでした。

ここで使われた課題は、実際に人間の開発者も脆弱な実装をしてしまった「落とし穴のある」機能追加です。現実に起きた失敗をもとにした課題を、AI にも解かせたことになります。ただし、脆弱な実装が実際に起きた課題を選んで集めたベンチマークなので、一般的な開発全体の平均を表すものではない点には注意が必要です。

象徴的なのが、ある代表的な構成の結果です。全課題のうち、機能のテストに通った解答は 57% あったのに、機能と安全性の両方のテストに通った解答は 11.8% にとどまりました。つまり「ちゃんと動く」コードの多くが、安全ではなかったことになります。さらに、課題ごとに「この機能にはこういう脆弱性が入りやすい」という情報を与えて避けるよう指示すると、機能と安全性の両方を満たす解答はわずかに増えました。しかし、機能のテストに通る割合はかえって下がり、研究チームは問題を十分に解消するものではないと結論づけています。

運営者にとっての意味は、「動作確認に合格した」ことは安全の証明にならない、という点です。そして「安全に書いて」と AI に頼むだけでは足りないことも示しています。安全性は、出来上がったものを別の工程で確かめるしかありません。

📄 論文: AI が作る「存在しないパッケージ名」と乗っ取り

いまのソフトウェアは、公開されている部品（パッケージ）を組み合わせて作るのが普通です。AI はコードを書くときに「このパッケージを入れてください」と提案してきますが、そのなかに実在しない名前が混じることがあります。攻撃者がその名前で悪意あるパッケージを先に登録しておけば、提案どおりにインストールした人のところへ悪いコードが届いてしまいます。この手口は「スロップスクワッティング（slopsquatting）」と呼ばれ、OpenSSF の指針でも注意が促されています。

The Range Shrinks, the Threat Remains: Re-evaluating LLM Package Hallucinations on the 2026 Frontier-Model Cohort（Aleksandr Churilov、2026年5月、arXiv:2605.17062）は、この問題を 2026 年の主要モデルで測り直した研究です。単著の査読前の論文（プレプリント）で、セキュリティの国際会議 USENIX Security 2025 で発表された先行研究の追試として位置づけられています。

2025 年 10 月〜2026 年 3 月に公開された 5 つのモデルに、Python と JavaScript の約 20 万組の依頼を出し、提案されたパッケージ名が公式の登録簿（PyPI と npm）に実在するかを照合しました。存在しない名前を出す割合は 4.62〜6.10% で、先行研究のころに比べてモデル間の差は大きく縮まっていました。それでも、5 つのモデルがそろって同じ架空の名前を作り出すケースが見つかりました。登録簿の運営者と調整して開示した後も、そのうち 53 件は各登録簿の既存の防御をくぐって攻撃者が登録できる状態だったと報告されています。

運営者にとっての意味は、「新しいモデルなら大丈夫」とは言えないことです。AI が提案した部品は、入れる前に実在するか・いつから公開されているか・どれだけ使われているかを確かめる。この確認を担当者の注意力に任せず、手順として決めておくことが大切です。使ってよい部品の一覧を作る、組織で決めた取得元からだけ入れる、といった仕組みにするとより確実です。

📄 論文: 実際のソフトウェアで AI のコードはどう広がっているか

AI Code in the Wild: Measuring Security Risks and Ecosystem Shifts of AI-Generated Code in Modern Software（Bin Wang ほか、2025年12月、arXiv:2512.18567）は、査読前の論文（プレプリント）です。

研究チームは、AI が書いたコードと人が書いたコードを見分ける仕組みを作りました。それを、GitHub のスター数で選んだ上位 1,000 のオープンソースのリポジトリの開発履歴（2022 年 1 月〜2025 年半ば）と、既知の脆弱性（CVE）に関係するコード変更 7,000 件超に当てはめ、AI のコードがどこに使われ、脆弱性とどう関わっているかを追跡しています。

結果からは三つの傾向が見えてきました。まず、AI のコードは既に新しいコードのかなりの割合を占めていますが、使われ方には偏りがあります。部品同士をつなぐコード・テスト・ドキュメントなどの定型的な部分に多く、中核のロジックやセキュリティ上重要な設定は今のところ人が書いていることが多い。次に、一部の種類の脆弱性は AI のコードに多く現れ、ほぼ同じ脆弱なひな形が、互いに無関係なプロジェクトに繰り返し出てきました。研究チームは、開発者同士のつながりではなく共通の AI モデルを通じて同じ欠陥が広まった可能性を示唆しています（原因が確定したわけではありません）。そして、AI が大量の変更を持ち込み、人がセキュリティの門番を務めるという分担のなかで、人のレビューが浅いと、AI が持ち込んだ欠陥は長く残り、外部からアクセスできる部分に置かれたまま、より多くのファイルやプロジェクトに広がっていました。

運営者にとっての意味は、AI のコードのリスクを左右するのは「人のレビューがきちんと門番として働いているか」だという点です。AI を使うこと自体より、レビューを省くことの方が危ないと言えます。

発注・運用でやること

3 本の論文と公的な資料を合わせると、運営者が押さえるべき点は「AI を使うかどうか」ではなく、「AI を使っても確かめる工程が残っているか」に集約されます。コードレビューやテストの進め方全般は コード生成エージェントの記事 でも扱っているので、ここではセキュリティに絞ります。

制作会社に頼むとき：レビューの方法を確認する

  • 開発に AI を使っているかどうかを、責める調子でなく普通に聞く。使っていること自体は問題ではありません
  • 使っている場合、AI が書いたコードを人がどうレビューしているか、誰が責任を持つかを確認する。OWASP の言う「提出する人がすべてを理解している」状態かどうかがポイントです
  • 静的解析（ソースコードを機械的に調べて脆弱性の候補を見つけるツール）や脆弱性診断を、納品前のどの段階で行うかを確認する
  • ログイン・決済・問い合わせフォーム・管理画面など、外部から触れられる部分は特に重点的に確認してもらう

AI を使うと開発が速くなる分、レビューにかける時間が相対的に削られがちです。見積もりの段階で、レビューや診断の工程が費用に含まれているかを確認しておくと、納品後に「そこは対象外でした」となるのを防げます。

依存パッケージを確認する

  • 新しく追加されたパッケージの一覧を納品物に含めてもらう。OpenSSF の指針も、ソフトウェア部品表（SBOM）の作成を勧めています
  • 見慣れない名前の部品は、公式の登録簿に実在するか、公開から十分な期間がたっているか、利用実績があるかを確認する
  • 使う部品の版を固定し、定期的に更新する運用にする。依存関係の脆弱性チェックを自動化する

社内で AI に書かせるとき

  • 小さなツールでも、インターネットに公開するものは「試作品」と「公開してよいもの」を分ける。公開前に、詳しい人か外部の目を一度通す
  • パスワードや API キー（外部サービスを使うための合言葉）をコードに直接書かせない。OpenSSF の指針も、秘密情報をコードに含めないよう求めています
  • AI に渡す指示書に、セキュリティの要件をあらかじめ書いておく。OpenSSF は、AI コーディング支援ツールに読ませる指示の例を公開しています。ただし、脆弱性の情報を与えても改善がわずかだった研究結果のとおり、指示書は「確かめる工程」の代わりにはなりません

「AI に自己チェックさせる」の位置づけ

OpenSSF の指針は、AI に自分の答えを見直させ、改善させる手法も有効だとしています。手軽なので試す価値はありますが、最後に責任を持つのは人です。自己チェックは、人のレビューやツールによる確認の「前段」として使うのがよいでしょう。

AIが書いたコードと付き合う鍵は次の3点です

  1. 「動く」と「安全」を分けて確かめる
    動作確認に合格しても安全とは限りません。機能のテストとは別に、静的解析や診断でセキュリティを確認する工程を設けましょう。
  2. 人のレビューを門番として残す
    AI のコードのリスクは、レビューが浅いと長く残り広がります。誰がどう確認し、誰が責任を持つかを発注時に確かめましょう。
  3. AI が提案した部品は、入れる前に実在を確認する
    存在しない名前の部品は最新のモデルでも提案されます。部品の一覧を残し、見慣れない名前は実在と実績を確認してから使いましょう。

まとめ：AIのコードは「確かめる工程」とセットで使おう！

AI でコードを書くこと自体は、開発を速く、安くしてくれる心強い手段です。問題は AI そのものではなく、「動いたから大丈夫」と確かめる工程を省いてしまうことにあります。研究が示したのは、動くコードの多くが安全ではなかったこと、存在しない部品の提案が今も続いていること、そして人のレビューが浅いと欠陥が長く残ることでした。

制作会社と話すときは、まず「AI を使っていますか？使っているなら、どうレビューしていますか？」と聞いてみましょう。その答えが、安心して任せられるかどうかを見極める一番の手がかりになるはずです！

参考文献

タイトルとURLをコピーしました