AI生成コードの脆弱性とは？なぜ危険なのかと対策方法を徹底解説

AI生成コードの脆弱性とは何か

生成コードは『動くこと』を優先しやすく、安全条件を自動では補完しません

AI生成コードの脆弱性を考えるとき、最初に押さえるべきなのは、モデルが悪意を持って insecure なコードを書くわけではないという点です。問題は、開発側が「画面を出す」「API をつなぐ」「フォームを送れるようにする」といった機能要求だけを渡したとき、モデルは動くことを優先した実装を返しやすいことです。認証、認可、入力検証、rate limit、ログの sanitization、公開禁止の route まで毎回明示していなければ、安全条件は抜けやすくなります。

Veracode 2025 GenAI Code Security Report↗は、この感覚をかなり明確に裏付けています。report では security-specific guidance を与えない条件で生成コードを評価し、secure code になったのは全体の 55% にとどまりました。つまり裏を返すと、45% では既知の security flaw が残ったことになります。これは「AI で書いたら必ず危険」という意味ではなく、機能面の精度ほど security quality が自動で上がらないことを示しています。

既存の Vibe Coding のセキュリティ でも触れたとおり、危険なのは AI を使うこと自体ではなく、速く書けるので review と公開前確認が薄くなることです。AI生成コードの記事では、そこからさらに一歩進めて、何が混ざりやすいのか、なぜ人間レビューが必要なのか を主役にします。

古い脆弱性が『新しい開発速度』の中で再生産されます

AI生成コードで入りやすい flaw は、未知のゼロデイよりも、実は古典的な実装ミスであることが多いです。prepared statement を使わない入力処理、認証なし endpoint、client-side に残る secret、緩い CORS、debug route の残置、危険な default 設定などは、いずれも昔から知られています。問題は、AI がそれらを「便利で手早い実装」として組み合わせやすく、人間も diff が大量だと見落としやすいことです。

そのため、AI生成コードの脆弱性は「AI特有の新型攻撃」として理解するより、既知の insecure template が高速に量産される問題として理解した方が実務では役立ちます。この切り口にすると、生成AIの利用是非ではなく、review、gate、公開後点検へ落とし込みやすくなります。

どんな危険な実装が混ざりやすいのか

『動けばよい仮実装』が本番まで残るのが危険です

AI生成コードのレビューで一番危ないのは、明らかな exploit よりも「開発中だけのつもりだった仮実装」が残ることです。たとえば一時的に認証を外した admin route、beta 用の host、test 向け CORS、社内確認用の Swagger/OpenAPI、内部 API の直叩きなどは、動作確認では便利です。しかし release 直前に消し込まれないと、そのまま公開面へ残ります。

既存の フロントエンドのAPIキー露出 や クライアントシークレット漏えい は、こうした「まず動かす」で混ざりやすい個別論点です。本記事ではそれらを単独論ではなく、AI生成コード全般で起きやすいパターンとして束ねています。

安全そうに見えるコードでも trust boundary が崩れていることがあります

AI生成コードは、見た目の整ったフレームワーク構成や lint の通るコードを返せます。そのため、読みやすいから安全だという錯覚が起きやすくなります。ですが本当に重要なのは、どこで認証するのか、どの値を browser に出してよいのか、どの service account がどこまで届くのかという trust boundary です。ここが曖昧なままだと、見た目がきれいでも危険な実装になります。

とくに AI は、library や framework の定番例に寄せる傾向があります。定番例は「最小サンプル」として有用ですが、そこには production 向けの権限分離、認証、監査、rate limit、secret management までは含まれていないことが多いです。だから sample code を本番品質だと誤認すると、安全そうに見える insecure code が残ります。

最新の研究は何を示しているのか

Veracode は『機能改善ほど security quality は上がっていない』と示しています

Veracode report の重要な点は、「モデルが高性能になれば secure code も自然に増える」とは限らないことです。report では、より新しいモデルほど機能面の正しさは改善しても、security-specific guidance がない限り、secure code 率は十分に伸びないことが示されています。読者がここで理解すべきなのは、モデル性能の向上と安全性の向上は別軸だという点です。

つまり企業が取るべき行動は、「もっと賢いモデルに変える」だけではありません。AI に渡す要件の書き方、review checklist、公開前の gate、公開後の外部観点での点検を整えない限り、動くが危ないコードは残り続けます。

2025年末から2026年の研究でも、secure code generation はまだ補助策が必要です

Is Vibe Coding Safe?↗は、real-world feature request ベースの benchmark で coding agent を評価し、機能的に正しくても secure とは限らないことを示しました。SWE-Agent with Claude 4 Sonnet では機能正答率が 61% だった一方、secure だったのは 10.5% にとどまったとされます。数値は task 設計に依存するものの、“動く” と “安全” の差が依然として大きいことを示すには十分です。

一方で GoodVibe↗ や RESCUE↗ のような研究は、security knowledge を明示的に与えたり、security-relevant reasoning を強化したりすることで改善余地があることも示しています。これは逆に言えば、素のままの生成コードでは十分でないことの裏返しです。

NCSC の guidance は『secure AI system development』を life cycle 全体で見ています

NCSC の Guidelines for secure AI system development↗は、AI 開発を単発の prompt 改善ではなく、design、development、deployment、operation を通した責任として整理しています。AI生成コードの記事でも同じで、問題はプロンプトの表現力だけではありません。どの security requirement を設計時に固定し、どの review を deployment 前に通し、どの公開接点を operation で追うかまで含めて設計しないと、安全性は安定しません。

この観点は、既存の サービスアカウントのセキュリティ や プロンプトインジェクション とも自然につながります。生成AIで実装した結果として、credential、権限、外部接点の粗さが残りやすいからです。

最近の事例はどこで事故が起きているのか

Wiz の調査は『生成コードの粗さがそのまま公開面へ出る』ことを示しています

AI生成コードの脆弱性を語るとき、研究だけではなく、実際にどんな露出が確認されているかも重要です。Wiz Research が 2025 年に公開した vibe-coded applications 調査↗ では、client-side に残った password、露出した API key、公開された Supabase table、認証なしの internal app など、生成コードと高速な公開の組み合わせで起きやすい露出が複数示されました。これは Vibe Coding の記事ともつながりますが、本記事で重要なのは、「危険な pattern は AI生成コード単体ではなく、公開された構成まで含めて現れる」という点です。

つまり release 前のコードレビューで「動いているからよい」と判断すると、client-side に置いてはいけない値、仮の admin route、緩い data access がそのまま internet-facing になります。AI生成コードの記事では、こうした事例を「モデルが危険」だからではなく、仮実装の消し込みと公開面 review が足りないから起きる問題として読むべきです。

platform 側の事故も『生成コードだけ見ても足りない』ことを補強しています

2025 年 7 月に Wiz が公開した Base44 の critical vulnerability↗ は、hidden registration URL から private app に unauthorized sign-up ができる問題を説明しました。これは開発者が一行まずいコードを書いたというより、生成コードを載せる platform 側の trust boundary が崩れたとき、private app 全体が巻き込まれ得ることを示した事例です。AI生成コードのリスクを code review だけで閉じると、こうした platform 依存の問題を見落とします。

だから本番前 review では、生成コードそのもの、依存先の package、利用している生成 platform、そして公開後に見える host / path / storage を分けて点検した方が安全です。AI生成コードの脆弱性とは、単にコード品質の問題ではなく、コード・platform・公開面が短いサイクルで一緒に変わることによって強くなるリスクだと考えると、必要な gate が見えやすくなります。

本番に出す前に、どこをレビューするべきか

AI生成コードの review で大切なのは、「コードとして整っているか」と「公開サービスとして安全か」を分けることです。前者では入力検証、認証、認可、error handling、dependency、logging を見ます。後者ではどの host、route、login page、preview URL、Swagger、staging、bucket、docs が外へ出るかを見ます。repo review だけで公開面は分からないので、ここを一つの checklist に押し込まず、二段構えの gate として設計した方が運用しやすくなります。

依存関係と scaffold の初期設定も review 対象に入れるべきです

AI生成コードの review では、どうしても controller や component の中身に目が向きます。しかし実際には、生成時に追加された package、starter template、scaffold の初期設定にも危険が残ります。便利なライブラリを自動で選んだ結果、来歴確認が弱い dependency が入ることもありますし、開発用の default 設定が production まで残ることもあります。だから review では、「どのコードが生成されたか」だけでなく、どの依存関係と初期設定が増えたかも一緒に見る必要があります。

ここは 悪意ある package registry の危険性 や Slopsquatting とも自然につながります。AI生成コードの記事で package hallucination を主役にし過ぎると別記事と競合しますが、release gate の一部として扱うと意味がはっきりします。生成コードを安全に使うには、コード本文、依存関係、初期設定 の 3 層をまとめて見る必要があります。

個別の security 記事へ深掘りリンクを送ると review が具体化します

broad に「AI生成コードは危険」と言うだけでは、現場のレビュー項目は増えません。むしろ、個別論点へ落とした方が実務的です。たとえば browser に値を置くべきかは APIキー露出、OAuth 実装境界は client secret 漏えい、機械IDは サービスアカウント管理、未承認 AI 利用は シャドーAI、外部から汚染される入力は プロンプトインジェクション へ送ると、review が具体化します。

つまり本記事は、「全部ここで説明する」ための記事ではありません。AI生成コードの危険性を親テーマとして整理し、その下にある実装ミスや運用論点へ自然に深掘りできるようにする記事です。こうすると、ユーザーの検索意図にも応えながら、チーム内の review 運用にも落とし込みやすくなります。

攻撃者視点で URL と docs を一度たどると、コード外の粗さが見えます

生成コードの review を repo の中だけで閉じると、最終的な公開状態との差が見えません。そこで release 前には、攻撃者視点で URL をたどる簡易点検を一度入れると効果があります。login page、preview host、公開 docs、Swagger/OpenAPI、古い staging、bucket の index などを外から順に見ていくと、コードレビューでは「仮のつもり」だった接点が、実際には internet-facing になっていることがあります。

これは大げさな penetration test を毎回やるという意味ではありません。むしろ、AI で速く作ったからこそ、外から見える接点を短時間で一周するだけでも価値があります。コードの中で secure に見えても、公開 state が雑なら exploit の入口は残るので、release gate では repo review と外部接点 review をセットで考える方が安全です。

AI生成コードで作ったサービスを ASM診断 PRO で点検するなら

ASM診断 PRO は、AI が書いたコードそのものを安全判定する製品ではありませんし、SAST や secure code review を置き換えるものでもありません。それでも AI生成コードの文脈で意味があるのは、コードレビューでは見えない公開面の粗さを拾えるからです。AI で速く組んだサービスでは、preview host、staging、login page、管理画面、Swagger/OpenAPI、古い subdomain、debug route などが残りやすく、repo review だけでは最終的な公開状態まで追い切れないことがあります。

生成コードの review を通した直後ほど、「もう十分確認した」という心理が働きます。しかし実際の利用者や攻撃者が触るのは repo ではなく、今 internet-facing になっている host と path です。AI生成コードの記事で強調したいのは、secure coding の問題と、公開状態の問題は分けて見るべきだということです。コードがきれいでも、公開面が雑なら attack surface は残るためです。

ASM診断 PRO を使うと、外から見える login page、preview host、staging、API docs、古い subdomain をまとめて洗い出し、どの接点が今も残っているかを整理しやすくなります。AI で速く作ったサービスは、開発チームの頭の中では「暫定」でも、公開面では本番同様に見えていることがあります。だから公開直前か直後に一度、外部から見た公開面の棚卸しを挟むと、生成コードの review だけでは抜ける箇所を早めに潰せます。

既存の 外部接続点の可視化 や 管理画面・開発環境の露出リスク とつなげて見ると、AI生成コードの危険性を「開発速度の話」で終わらせず、公開運用の課題として整理できます。生成AI で速く作ったサービスほど、無料で外部公開面を一度点検して、実際に見えている接点を棚卸しする流れに持ち込む価値があります。

よくある質問（FAQ）

AI生成コードは全部 insecure だと考えるべきですか

いいえ。問題は AI が書いたこと自体ではなく、機能要求だけで通し、security constraint と review gate を置かないことです。適切な要件化と人手 review を前提にすれば、AI生成コードは補助になります。

一番最初に review すべきなのはどこですか

browser に置いてはいけない値、認証なし route、入力検証、緩い CORS、debug 設定、依存関係追加です。とくに「とりあえず動かす」ために入った仮実装が残っていないかを優先して見てください。

SAST や lint が通れば十分ですか

十分ではありません。repo 上のコードが整っていても、実際に公開された login page、preview host、Swagger/OpenAPI、古い staging は別レーンで確認する必要があります。

AI生成コードと Vibe Coding の違いは何ですか

Vibe Coding は AI に大きな裁量を渡す開発スタイル全体を指し、本記事はその中でも生成されたコード自体にどんな insecure pattern が混ざりやすいかを主役にしています。

公開後も確認が必要なのはなぜですか

AI で速く作ったサービスは、preview host や管理画面のような公開接点が残りやすく、code review だけでは最終的な公開状態まで見切れないためです。公開後の外部観点での点検まで含めた方が安全です。

まとめ

AI生成コードの脆弱性とは、生成AIが特別に新しい攻撃を作ることよりも、昔からある insecure な実装ミスを、速い開発サイクルの中で再生産しやすいことです。Veracode report や recent research が示すように、機能面の改善ほど security quality は自動で上がりません。つまり「最新モデルなら安全だろう」という期待だけでは足りず、認証、入力検証、秘密情報の境界、dangerous default、依存関係、公開面確認を人間が先に固定する必要があります。

実務では、認証なし route、client-side の key / secret、緩い CORS、debug 設定、雑な package 追加、preview host や Swagger の残置が典型的な入口になります。どれも新しい話ではありませんが、AI で速く作れるようになったことで、短時間に複数が重なりやすくなっています。だから対策は「AI を禁止する」ことではなく、機能要求と security requirement を分けて書き、review を code と公開面の二段で回し、危険な仮実装が本番へ残らないようにすることです。AI生成コードを安全に使うとは、生成速度を落とすことではなく、速くても崩れない gate を置くことです。

そして公開サービスでは、コードレビューだけで終えないことが重要です。repo で見た実装と、実際に internet-facing になった host や path は必ずしも一致しません。AI で速く作ったサービスほど、公開後に外部から見た公開面の点検を入れ、どの login page、preview host、staging、docs、API が残っているかを棚卸しした方が安全です。AI生成コードの問題を「開発中の品質」だけで終わらせず、「公開後に何が見えるか」まで含めて管理するチームの方が、速さと安全性を両立しやすくなります。