ChatGPT、GitHub Copilot、Cursor、Claude Codeなど、AIコーディング支援ツールの普及は目覚ましいものがあります。「一晩でAPIを構築した」「ゼロから業務アプリを1週間で完成させた」といった体験談がSNSに溢れ、開発の常識が塗り替わりつつあります。

 

この便利さの裏側で、セキュリティの脆弱性が静かに、確実に増え続けています。「なぜAI生成コードに脆弱性が生まれるのか」という問いに対して、多くの解説は技術的な欠陥パターンを列挙しますが、その問題の全貌は見えません。

 

脆弱性が増える本当の理由は、コードそのものの問題だけでなく、AIを使う人間の心理・組織の文化・責任の構造にも深く根ざしています。

 

本記事では、技術的な原因と人間的・組織的な原因の両面から、AI生成コードの脆弱性が増える理由を徹底解説します。

 

AIが脆弱なコードを生み出す4つの技術的な理由

 

まず前提として押さえておきたいのは、AIは安全なコードを理解して書いているわけではないという事実です。AIが行っているのは「学習データの中で最もそれっぽいパターンを予測して出力する」ことであり、セキュリティの善悪を判断しているわけではありません。

 

AIは脆弱なコードも大量に学習している

AIコーディングツールの学習データの多くは、GitHubなどインターネット上で公開されているコードです。そこには、セキュリティ的に問題のある古いコードや手抜きの実装も大量に含まれています。

 

AIはそれらを区別なく学習しますが、以下のような危険なパターンが普通のコードとして出力されることがあります。

• SQLインジェクション：ユーザー入力をそのままSQLクエリに連結する実装
• ハードコードされた秘密情報：APIキーやパスワードをソースコードに直書き
• 古い暗号化手法：すでに危殆化したMD5ハッシュの使用

 

AIは動くコードを優先して出力します。セキュリティが多少犠牲になっても、見た目がきれいで動作するコードが選ばれてしまうのです。

 

AIはシステム全体を理解していない

AIはコード生成や補完は得意ですが、システム全体の設計まで理解しているわけではありません。

 

特に、以下の複雑な設計が苦手です。

• 認証・認可
• 権限管理
• テナント分離
• サービス連携

 

例えば、AIに権限チェックを依頼すると、以下のような単純なコードを生成することがあります。

 

if user.role == “admin”:

    allow_access()

 

一見問題なさそうですが、実際の業務システムでは部署・ロール継承・例外権限など、複雑な条件が存在します。そのため、「コード単体では正しく見えるが、システム全体では認可漏れが起きる」という問題につながります。

 

AI生成コードは完成度が高く見えるため、人間側のレビューやセキュリティ確認が欠かせません。

 

セキュリティ要件を書かなければ考慮されない

AIは言われたことしかやらない存在です。プロンプトに「ログイン機能を作って」とだけ書けば、AIは最もシンプルな実装を返します。

 

そのコードには多くの場合、以下が欠けています。

• 入力値のバリデーション
• レート制限（ブルートフォース対策）
• CSRF対策
• パスワードの適切なハッシュ化
• セッション保護の設定

 

AIは「短く・動く・きれいなコード」を優先するため、セキュリティ実装や例外処理は省かれやすいのです。

 

AIのハルシネーションが新しい攻撃経路になる

生成AIは、ときどき実在しないライブラリ名やAPIを、存在するかのように生成することがあります。これは「ハルシネーション」と呼ばれる現象です。

 

一見ただの誤情報に見えますが、近年ではセキュリティ上の新たなリスクとして問題視されています。

 

例えば、AIが架空のnpmパッケージ名を生成した場合、開発者は以下のような行動を取ることがあります。

• AIが提案したパッケージを検索する
• パッケージが存在しないことに気づく
• 「未公開なのかも」と思い込む
• そのままインストールや利用を試みる

 

この流れを悪用する攻撃が報告されています。攻撃者は、AIが生成しそうな架空のパッケージ名を事前に登録し、そこへ悪意あるコードを仕込んでおくのです。

 

その結果、以下につながる危険があります。

• マルウェアの混入
• 情報漏えい
• 認証情報の窃取
• バックドア設置

 

これはAI時代の新しいサプライチェーン攻撃として、セキュリティ研究者から特に警戒されています。AIが生成したライブラリ名や依存関係は、そのまま信用せず、公式ドキュメントや実在性を必ず確認することが重要です。

 

なぜ熟練エンジニアでも見抜けないのか

 

技術的な問題があるとわかっていても、なぜエンジニアはAI生成コードの脆弱性を見逃してしまうのでしょうか。そこには人間の心理的なメカニズムが大きく関わっています。

 

自動化バイアスがコードレビューを形骸化させる

人間には、機械や自動システムの出した結果を正しいと信じやすい傾向があります。これは「自動化バイアス」と呼ばれる心理現象です。

 

AI生成コードを見ると、「AIが作ったなら正しそう」「大きな問題はないだろう」という無意識の信頼が生まれやすくなります。

 

結果として以下のように見逃しやすくなる傾向があります。

• セキュリティの抜け漏れ
• 権限チェック不足
• ロジックミス

 

本来のコードレビューは問題を探す作業です。AI生成コードでは、「問題がないことを確認するだけ」の受け身なレビューになりやすい点が危険です。

 

「動く・テストが通る・きれいな見た目」の三重の安心感

セキュリティ脆弱性は、通常の動作テストだけでは発見できないケースが多くあります。例えば、「SQLインジェクション」「XSS（クロスサイトスクリプティング）」「 認可漏れ」などは、コードが正常に動いている間は問題が見えません。

 

AI生成コードは、以下のように完成度の高い状態でプルリクエストに現れます。

• コンパイルが通る
• テストが成功する
• コードも整理されて見える

 

レビュー側に、「問題なさそう」「ちゃんと動いている」「細かく見なくても大丈夫そう」という安心感が生まれやすくなります。そのまま深いレビューが行われず、脆弱性が見逃される危険があります。

 

AI依存で失われる「セキュリティの勘」

セキュリティへの感覚は、自分で危ないコードを書いて失敗した経験や、先輩から「この書き方は危険だ」と叩き込まれた体験から育まれます。

 

AIが実装を肩代わりするほど、この経験から生まれる勘が失われていきます。特に深刻なのは、AIツールが当たり前の環境でキャリアをスタートした若手エンジニアへの影響です。

 

AIなしでゼロから安全なコードを書く基礎体力が育たないまま、AIのミスを見抜く役割を担わなければならない状況が生まれています。

 

速さ優先の組織文化と責任の曖昧化が招く悪循環

 

AI生成コードの脆弱性問題は、技術・心理だけでなく、組織の文化と責任構造にも深く根ざしています。

 

AIが速さの圧力をさらに増大させる逆説

AIツールを導入すると、経営陣や管理職は以前より速く開発できるはずと考えます。締め切りは短縮され、エンジニアはより速いアウトプットを求められます。

 

これは一見、生産性向上に見えますが、実態はセキュリティレビューに使える時間が削られることを意味します。本来なら脆弱性を発見できたはずのレビュー工程が、スケジュールの圧力で省略・短縮されていきます。

 

「動けばリリース」という文化が定着すると、脆弱なコードが次々と本番環境に送り込まれます。脆弱性の修正コストは、開発時点の最大100倍になるという研究データもあります。速さの追求が、後に莫大なコストとして返ってくるのです。

 

AIが書いたからという責任感の希薄化

もう一つの深刻な問題が、責任の所在の曖昧化です。脆弱性が発覚したとき、「AIが生成したコードだから」という意識が、エンジニアの責任感を無意識に希薄にすることがあります。

 

自分で考えて書いたコードではないという感覚が、「このコードで本当に大丈夫か」と深く問い直すモチベーションを削ぎます。「AIが書いたから」は決して免罪符にはなりません。

 

ユーザーや社会に対する法的・倫理的な責任は、AIベンダーではなく、そのコードを本番に導入した組織と開発者にあります。

 

AIがAIをレビューする構造的な矛盾

さらに問題を複雑にするのが、コードレビューをする側のエンジニアも、AIを使って「このコードは安全ですか」と確認するケースが増えていることです。

 

AIがAIのコードをチェックするこの構造では、同じ種類の盲点が繰り返し見逃されます。AIは学習したパターンの範囲内でしか問題を指摘できないため、未知の脆弱性パターンや文脈依存の問題は素通りしてしまいます。

 

AI生成コードを安全に使う3つの実践アプローチ

 

ここまで問題を見てきましたが、AIを使うこと自体が悪いわけではありません。AIの限界を正しく理解し、人間がセキュリティの責任を持ち続けることが重要です。

 

セキュリティ要件を最初からプロンプトに書く

AIは言われたことしかやりません。だからこそ、依頼の時点でセキュリティ要件を明示することが最も効果的な対策の一つです。

 

悪い例

ログイン機能を作ってください。

 

良い例 

ログイン機能を作ってください。

要件： – JWT認証を使用し、有効期限は1時間

パスワードはbcrypt（コスト係数12以上）でハッシュ化

ブルートフォース対策としてレート制限（5回/分）を実装

SQLインジェクション対策としてプリペアドステートメントを使用 – CSRF対策を含めること

 

セキュリティ要件を具体的に指定するだけで、AI生成コードの品質は大幅に向上します。

 

SASTツールをCIパイプラインに必ず組み込む

人間の目だけに頼らず、静的解析ツール（SAST）を自動化することが不可欠です。AI生成コードが増えるほど、この自動チェックの重要性は高まります。

 

• SonarQube：多言語対応の総合コード品質・セキュリティ解析
• Semgrep：カスタムルール定義が可能な軽量SAST
• CodeQL：GitHubと連携するセマンティック解析ツール

 

プルリクエスト時にSASTが自動実行される環境を構築することで、脆弱なコードがmainブランチに入る前にブロックできます。

 

組織としてセキュリティ文化を育てる

個人の努力だけでは限界があります。「セキュリティは開発速度より優先される」という文化をマネジメント層から発信することが、最も根本的な対策です。

• セキュリティレビューの時間をスケジュールに組み込み、省略を禁止する
• 脆弱性の発見を「失敗」ではなく「チームへの貢献」として評価する仕組みを作る
• AI生成コードに関する明確なレビューガイドラインを策定・全員に共有する
• 定期的なセキュリティ研修と、若手エンジニア向けのAIなしで書く訓練を取り入れる

 

また、「自分で内容を説明できないコードは、本番環境に投入しない」ことがAI時代の鉄則です。

 

コードレビュー時に「このコードは何をしているか、なぜこの書き方なのか」を自分の言葉で説明できるか確認する習慣をつけましょう。説明できなければ、AIにもう一度質問して理解してから使う、あるいは別のアプローチを取るべきです。

 

まとめ

AI生成コードの最大のリスクは、AIが書いた綺麗なコードを人間が無条件に信頼することです。脆弱性が増える原因は、脆弱な学習データ・コンテキスト不足・セキュリティ要件の省略・ハルシネーション・人間の過信が複雑に絡み合って生まれています。テクノロジーは進化し続け、AIはますます高性能になるでしょう。

 

AI時代に必要なのは、「AIを使わない」ことではなく「AIを正しく疑うこと」です。AIを賢い補助ツールとして活用しながら、セキュリティの最終判断は人間が下す姿勢を個人・チーム・組織の三つのレベルで定着させることが、これからの開発者に求められる最も重要なスキルです。まずは「このコードを自分の言葉で説明できるか？」という一つの問いから始めてみてください。

 

3inkでは、最先端のAI技術やトレンドをいち早く開発現場に取り入れつつ、CI/CDパイプラインへのSAST（静的解析ツール）の組み込みや、ガバナンスの効いた安全な開発体制・セキュリティ環境の構築コンサルティングまで幅広く柔軟に対応しております。

 

「自社の開発プロセスに自動セキュリティ運用の仕組みを組み込みたい」「AIを活用しつつも、堅牢で安全なシステム・アプリを構築したい」など、システム開発やセキュリティ体制に関するご要望・ご相談がございましたら、いつでもお気軽にお問い合わせください。