AIコード生成で8割が脆弱性を含有｜Vibe Codingの現実と対策

最新研究でAI生成コードの83%がセキュリティ的に脆弱であることが判明。実際の開発現場で必要な対策と検証方法を詳しく解説します。

「AIでコード書かせれば大丈夫」は危険な思い込みかもしれません

「開発スピードアップのためにAIを活用したいけど、品質は大丈夫？」「ChatGPTやCopilotで生成したコードをそのまま使っても問題ない？」「セキュリティ面での懸念はないの？」

弊社でも最近、クライアントからこうした相談を頂く機会が増えました。確かにAIによるコード生成は開発効率を飛躍的に向上させる魅力的な技術です。

しかし、2024年12月に発表されたarXiv論文「Is Vibe Coding Safe?」が衝撃的な事実を明らかにしました。AIが生成した機能的に正しいコードの83%がセキュリティ的に脆弱だったのです。

実際の開発プロジェクトで20年以上経験を積んできた私たちの視点から、この研究結果の詳細と、現場で今すぐ実践できる対策をお伝えします。

論文が示した衝撃的な数値

機能は正しくてもセキュリティは不安

スタンフォード大学などの研究チームが行った調査では、以下の結果が報告されています：

特に注目すべきは、最も優秀とされるSWE-Agent + Claude 4 Sonnetでも、機能的に正しいコードの83%がセキュリティホールを含んでいたという点です。

「セキュリティに気をつけて」は効果なし

更に興味深いのは、プロンプトに「セキュリティに注意してください」という指示を追加しても：

セキュリティ改善：0%
機能正確性：むしろ6%低下

という結果でした。単純な指示だけでは改善されないことが明確になっています。

実際に見つかった脆弱性の種類

弊社でも過去にクライアントから「AIで生成したコードを見て欲しい」という依頼を受けた際、似たような問題を確認しています。

1. タイミング攻撃の脆弱性

問題のあるコード例：

// AI生成コードによくあるパターン
function authenticateUser($username, $password) {
    $user = getUserFromDB($username);
    
    // 危険：文字列比較で処理時間に差が生じる
    if ($user && $user['password'] === hash('sha256', $password)) {
        return true;
    }
    return false;
}

改善されたコード：

function authenticateUser($username, $password) {
    $user = getUserFromDB($username);
    
    if ($user) {
        $expected = $user['password'];
        $actual = hash('sha256', $password);
        // タイミング攻撃を防ぐ定数時間比較
        return hash_equals($expected, $actual);
    }
    
    // ユーザーが存在しない場合もダミー処理で時間を一定に
    hash('sha256', $password);
    return false;
}

2. XSSの脆弱性

問題のあるコード例：

// AI生成でよく見られる不適切な実装
function redirect(url) {
    // 危険：javascript:スキームが検証されていない
    window.location.href = url;
}

改善されたコード：

function redirect(url) {
    try {
        const urlObj = new URL(url);
        
        // 危険なプロトコルを排除
        if (!['http:', 'https:'].includes(urlObj.protocol)) {
            throw new Error('Invalid protocol');
        }
        
        // 許可されたドメインのチェック（必要に応じて）
        const allowedDomains = ['example.com', 'subdomain.example.com'];
        if (allowedDomains.length > 0 && !allowedDomains.includes(urlObj.hostname)) {
            throw new Error('Domain not allowed');
        }
        
        window.location.href = url;
    } catch (error) {
        console.error('Redirect failed:', error);
        // デフォルトページにリダイレクト
        window.location.href = '/home';
    }
}

3. ハードコードされた認証情報

論文では、実際に2万のアプリケーションでsupersecretkeyがハードコードされているケースが報告されています。

問題のあるコード例：

// AI生成でよくある危険なパターン
class JWTHandler {
    private $secret = 'supersecretkey'; // 危険！
    
    public function generateToken($payload) {
        return JWT::encode($payload, $this->secret, 'HS256');
    }
}

改善されたコード：

class JWTHandler {
    private $secret;
    
    public function __construct() {
        $this->secret = $_ENV['JWT_SECRET'] ?? null;
        
        if (!$this->secret) {
            throw new Exception('JWT_SECRET environment variable is required');
        }
        
        // 最低限の強度チェック
        if (strlen($this->secret) < 32) {
            throw new Exception('JWT_SECRET must be at least 32 characters');
        }
    }
    
    public function generateToken($payload) {
        return JWT::encode($payload, $this->secret, 'HS256');
    }
}

実務で今すぐ実践できる5つの対策

弊社の開発チームが実際に導入している対策をご紹介します。

1. SASTツールのCI/CD統合

推奨ツール：

# .github/workflows/security.yml
name: Security Scan
on: [push, pull_request]

jobs:
  semgrep:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: returntocorp/semgrep-action@v1
        with:
          config: >-
            p/security-audit
            p/secrets
            p/owasp-top-ten

# .github/workflows/snyk.yml
name: Snyk Security
on: [push, pull_request]

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Run Snyk to check for vulnerabilities
        uses: snyk/actions/php@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          args: --severity-threshold=medium

2. セキュリティ強化プロンプトテンプレート

単純な「セキュリティに注意」では効果がないため、より具体的な指示が必要です：

以下の要件でセキュアなコードを生成してください：

【必須セキュリティ要件】
1. 入力値は全て検証・サニタイズする
2. SQLインジェクション対策（プリペアードステートメント必須）
3. XSS対策（出力時のエスケープ必須）
4. CSRF保護を実装
5. 認証情報のハードコードは禁止
6. エラーメッセージに機密情報を含めない
7. 適切なHTTPヘッダーを設定

【実装内容】
[具体的な機能要件を記述]

【使用技術】
PHP 8.1, Laravel 10

【追加指示】
コメントで各セキュリティ対策の理由も記述してください。

3. 危険パターンの事前学習

開発チーム全体で共有している「AIコード生成で注意すべきパターン」：

- `$_GET`、`$_POST`、`$_REQUEST`の直接使用
- `file_get_contents()`での外部URL指定
- 正規表現での入力検証の不備

- `echo`での直接出力
- JSONレスポンスでのエスケープ漏れ
- HTMLメール生成時の未処理

- セッション管理の脆弱性
- 権限チェックの漏れ
- JWTの不適切な実装

- 動的SQL文の構築
- 権限過多なDB接続
- バックアップファイルの暴露リスク

4. 段階的コードレビュープロセス

弊社で実施している、AI生成コードに特化したレビュープロセス：

flowchart TD
    A[AI生成コード] --> B[自動チェック<br/>SAST/Linter]
    B --> C{基本品質OK?}
    C -->|No| D[修正・再生成]
    C -->|Yes| E[シニア開発者<br/>セキュリティレビュー]
    E --> F{セキュリティOK?}
    F -->|No| G[修正指示]
    F -->|Yes| H[機能テスト]
    H --> I[DAST実行]
    I --> J[本番デプロイ]
    D --> B
    G --> E

5. DAST（動的解析）の実装

#!/bin/bash
# 自動化されたDASTスクリプト例

# OWASP ZAPを使用した動的スキャン
docker run -t owasp/zap2docker-stable zap-baseline.py \
  -t http://localhost:8080 \
  -r zap_report.html \
  -x zap_report.xml

# 脆弱性が見つかった場合はデプロイ停止
if grep -q "High Risk" zap_report.xml; then
    echo "High risk vulnerabilities found. Deployment cancelled."
    exit 1
fi

よくある失敗パターンと対処法

失敗パターン1：「AI生成だから完璧」という過信

実例： あるクライアントのプロジェクトで、ChatGPTで生成したログイン機能をそのまま実装したところ、パスワードが平文でログファイルに出力されていました。

対処法： AIは「動くコード」を生成するのは得意ですが、「セキュアなコード」を生成するのは苦手です。必ず人間による検証を行ってください。

失敗パターン2：表面的なチェックのみ実施

実例： 「SQLインジェクション対策はできているから大丈夫」と判断したものの、実際は一部のクエリでプリペアードステートメントが使われていませんでした。

対処法： チェックリストを作成し、全ての入力ポイント、出力ポイントを網羅的に確認する体制を構築しましょう。

失敗パターン3：ツールに依存しすぎる

実例： SASTツールで「問題なし」と出力されたため安心していたところ、ビジネスロジック固有の認可漏れが発生しました。

対処法： ツールは補助手段として活用し、最終的には経験豊富な開発者による手動レビューを必ず実施してください。

セキュリティ対策の効果測定

実際に対策を導入した弊社プロジェクトでの改善効果：

まとめ：AIと共存するための現実的なアプローチ

AIコード生成は確かに強力なツールですが、「動くコード」と「セキュアなコード」は全く別物だということが今回の研究で明確になりました。

弊社では、AIを「開発の加速装置」として活用しながらも、セキュリティ面では人間による厳格なチェック体制を維持しています。この両輪があって初めて、品質と効率を両立できるのです。

重要なのは、AIを敵視するのではなく、適切な距離感で付き合うこと。技術の進歩を取り入れつつ、責任を持って品質を保証する体制作りが求められています。

今日から始められるアクションプラン

現在使用中のAI生成コードの脆弱性チェックを実施

SASTツール（Semgrep等）をプロジェクトに導入

セキュリティ強化プロンプトテンプレートを作成

開発チーム向けの危険パターン学習会を開催

コードレビュープロセスにセキュリティチェックを組み込み

DAST環境を構築してテスト自動化を実施

月次でのセキュリティ状況レビューミーティング設定

参考文献・出典

Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks - arXiv (2024)
Security risks of vibe coding and LLM assistants for developers - Kaspersky
LLM Security in 2025: Risks, Examples, and Best Practices - Oligo Security

もしAIを活用した開発で不安を感じている、または既存システムのセキュリティ状況を確認したいという場合は、お気軽にご相談ください。20年以上の開発実績を持つ弊社チームが、現実的で実装可能な改善案をご提案いたします。

無料相談受付中

お気軽にご相談ください（初回無料）

詳しく見る

【追記】当サイトで実際に導入したセキュリティ対策

この記事を書いた後、「自社サイトでも対策できることはあるか？」と考え、実際に2つの対策を導入しました。

1. GitHub ActionsでSAST自動実行

CI/CDパイプラインにセキュリティチェックを組み込みました。

これにより、mainブランチへのプッシュ・PRごとに自動的にセキュリティチェックが走ります。

2. CSP（Content-Security-Policy）ヘッダーの導入

XSS対策の要となるCSPヘッダーを全ページに適用しました。

CSPの効果:

許可されていないドメインからのスクリプト実行をブロック
インラインスクリプトの制御（将来的にはnonce対応も検討）
クリックジャッキング対策（frame-ancestors）

対策前後の比較

項目	対策前	対策後
SAST自動実行	❌ 手動	✅ CI/CD統合
CSPヘッダー	❌ なし	✅ 全ページ適用
X-Frame-Options	❌ なし	✅ SAMEORIGIN
Permissions-Policy	❌ なし	✅ 不要機能を無効化

論文を読んで終わりではなく、実際にアクションを起こすことが重要です。完璧を目指すより、まずできることから始めましょう。

AIコード生成で8割が脆弱性を含有｜Vibe Codingの現実と対策

「AIでコード書かせれば大丈夫」は危険な思い込みかもしれません

論文が示した衝撃的な数値

機能は正しくてもセキュリティは不安

「セキュリティに気をつけて」は効果なし

実際に見つかった脆弱性の種類

1. タイミング攻撃の脆弱性

2. XSSの脆弱性

3. ハードコードされた認証情報

実務で今すぐ実践できる5つの対策

1. SASTツールのCI/CD統合

2. セキュリティ強化プロンプトテンプレート

3. 危険パターンの事前学習

4. 段階的コードレビュープロセス

5. DAST（動的解析）の実装

よくある失敗パターンと対処法

失敗パターン1：「AI生成だから完璧」という過信

失敗パターン2：表面的なチェックのみ実施

失敗パターン3：ツールに依存しすぎる

セキュリティ対策の効果測定

まとめ：AIと共存するための現実的なアプローチ

今日から始められるアクションプラン

参考文献・出典

【追記】当サイトで実際に導入したセキュリティ対策

1. GitHub ActionsでSAST自動実行

2. CSP（Content-Security-Policy）ヘッダーの導入

対策前後の比較

関連記事

JavaScriptで問い合わせフォームを実装する完全ガイド

カジノゲームの数学 - プログラミングで解き明かすギャンブルの確率論

二分探索木（BST）完全解説｜効率的な探索・挿入・削除を実現

二部グラフ判定完全解説 - 2彩色アルゴリズム実装ガイド

トポロジカルソート完全解説 - DAGの順序付けアルゴリズム

KMP法完全解説 - 高速パターンマッチングで検索性能を劇的改善

無料でご相談いただけます

関連サービスのご案内