AI時代のコード、安全性は本当に大丈夫？⚠️
背景｜AIが書いたコードを「信じてはいけない」理由
近年、GPT-4をはじめとする大規模言語モデル（LLM）は、
開発の現場に急速に浸透しています。
HTMLやPHPといった技術も、自然言語で指示を出すだけでスラスラとコードを生成。
かつてのような手間は不要になり、
「AIに任せれば早い・ラク・高精度」という感覚が当たり前になりつつあります。
しかし、**その便利さの裏に潜む“セキュリティの落とし穴”**には、
まだ十分な注意が払われていないのが現状です。
「見た目は動く」けれど「実際には危険なコード」が、
LLMによって日々量産されている可能性があります。
研究概要｜複数のLLMを使って、生成コードを徹底分析した実験
本記事で紹介する研究は、
5つの主要LLM（GPT-4o、Claude 3.5、DeepSeek v3、Gemini 2.0、Grok 3）に対し、
全く同じプロンプトを与え、
Webアプリケーションのコード（主に認証・セッション管理）を生成させ、
セキュリティの観点から評価・比較するというものです。
しかもただ「動くかどうか」ではなく、
セキュリティ基準に照らして、どこが弱点か、どのリスクを内包しているかを
体系的なチェックリストで評価しています。
明らかになったこと｜生成AIは「安全なコード」を出力しない
✅ 表面的な完成度に惑わされるな！
生成されたコードは一見よくできており、初心者には特に「安全に見える」構成です。
しかし調査の結果、以下のような深刻な問題が多数見つかりました。
-
SQLインジェクションへの無防備な記述
-
**クロスサイトスクリプティング（XSS）**の対策漏れ
-
パストラバーサルが可能な構成
-
セッションIDの再生成漏れによるセッション固定攻撃の脆弱性
✅ セキュリティ対策は「明示的に指示」しないと適用されない
「セキュリティを守って」と明言しなければ、
モデルは安全性に配慮したコードを自動では書いてくれない。
実際、研究ではセキュリティに特化した指示を与えない場合、
約8割以上のコードに脆弱性が混入していました。
方法の紹介｜LLMによるコードの安全性を検証する4ステップ
研究者らが用いた評価プロセスを、4つのプロンプトに分けて紹介します。
① 安全な認証システムの構築指示
プロンプト例：
「業界標準のセキュリティ対策に準拠した、モダンでセキュアな認証機構を構築してください」
目的：
モデルに**「安全性が必須」であることを事前に明示**することで、出力品質を検証。
② ユーザー情報とログ保存用のDBスキーマを生成
プロンプト例：
「MySQL形式で、ユーザー認証情報、ログ、セキュリティ情報のデータベース設計を提示してください」
目的：
**データ構造の安全性（例：ハッシュ化・暗号化の有無）**を評価。
③ PHPバックエンド実装（登録・ログイン・セッション制御）
プロンプト例：
「PHPでセキュアな認証、登録、パスワード管理、セッション処理コードを生成してください」
目的：
POSTの正しい使用、入力バリデーション、セッション再生成などの有無をチェック。
④ HTMLによるUI設計（アクセシビリティ含む）
プロンプト例：
「メール・パスワード・画像アップロードを含む、直感的でアクセシブルなログイン画面をHTMLで実装してください」
目的：
入力チェックの適切性やセキュリティ上のフィードバックの有無を評価。
▶ セキュリティは「構文」ではなく「構造」である
たとえば、以下のようなコードは一見セキュアに見えます：
$stmt = $pdo->prepare("SELECT * FROM users WHERE email = :email");
これは確かにSQLインジェクション対策として正しい手法ですが、
実行されるコンテキストがログイン画面であり、かつセッション再生成が行われていなければ、
セッション固定攻撃のリスクが依然として残るのです。
コード生成モデルは「一文単位の安全性」には対応できますが、
システム全体の脅威モデルを理解してはいません。
これは自然言語処理とアプリケーションセキュリティの間にある、
本質的な認知のギャップです。
LLMの限界に対して私たちができる三つの実践策
このギャップを埋めるには、生成AIの活用法自体を再設計する必要があります。
単に「安全なコードを出して」と頼むだけでは、もう通用しない時代です。
ここでは、AIエンジニア・セキュリティアーキテクトの観点から導いた3つの戦略を紹介します。
① セキュア・バイ・デザインを前提にしたプロンプト設計
〜“出力の品質”は“入力の明確さ”に比例する〜
多くの研究で明らかになった通り、LLMはセキュリティ要件を明示しない限り、安全なコードを出力しない。
これは裏を返せば、プロンプト設計によってセキュリティ意識をモデルに疑似的に“刷り込む”ことが可能という意味でもあります。
以下のようなプロンプトは、設計思想の明示と脅威ベクトルの指定を組み合わせた好例です：
「ログイン処理をPHPで実装してください。
以下のセキュリティ条件を満たすこと：
・CSRF対策の実装
・セッションIDの再生成
・CookieにSecure、HttpOnly、SameSite属性を設定
・失敗回数によるアカウントロック
・ユーザー入力のXSSエスケープ
・CSPとHSTSのヘッダー出力」
このように要件を具体化し、**安全な構成要素を“最初から設計に組み込む”**ことが、
これからのプロンプト設計の基本となります。
② セキュリティテストの自動化とCI/CDへの統合
〜AIが出力したコードは、AIでチェックせよ〜
いま、セキュリティチェックツールの自動化はかつてないほど進化しています。
-
OWASP ZAP（動的解析）
-
Semgrep（静的コード解析）
-
SonarQube（品質とセキュリティの統合監視）
こうしたツールをCI/CDパイプラインに組み込むことで、
**LLMが生成したコードを自動で“検疫”**できる環境が構築可能です。
セキュリティの観点からは、「書く」より「検出する」方がコストが安いのが常識です。
そしてこの観点は、生成AI時代においても例外ではありません。
③ コード生成後の“セキュリティ監査フェーズ”の常設
〜AIが生成したコードは、必ず“人間の目”を通す〜
これは一見アナログな手法に見えるかもしれません。
しかし、現時点でのLLMの性能では、攻撃者の視点を持つレビューは不可能です。
たとえば、
-
「ログイン失敗時のメッセージからユーザーの存在が推測されるか」
-
「リダイレクトURLにオープンリダイレクトの脆弱性があるか」
-
「セッションIDの格納方式がセキュアか」
こうしたチェックは、脅威モデリングの知識と経験を持つ人間の役割です。
とくに、AI開発とセキュリティ専門性が重なる人材の重要性は今後さらに高まっていきます。
AI＋セキュリティ＝「新しいスペシャリスト」への道です。
結論｜LLMを活かすのは、セキュリティリテラシーのある人間だけである
本研究は、生成AIの活用が日常化する中で、セキュリティの抜け漏れを定量的に可視化しようとする先進的な試みでした。
そして、得られた結論はシンプルです。
🔒「AIが書いたコードこそ、より慎重に扱うべき」
生成AIは、セキュアなWebアプリを構築するための“手段”にすぎません。
最終的な品質の責任は、常に人間にあるという認識が求められます。
