0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@AI-SKILL-LAB(AI ISO)

Vibe Codingの光と影：AIコーディングエージェントのPR87%に脆弱性、3エージェント比較と今日からできる対策

0
Posted at

はじめに — ちょっと気になる数字の話

「AIに任せたら一瞬でコードが書けた。」

そんな体験を持つエンジニアが増えていて、なんかそれは本当に素晴らしいことだと思うんです。実際、自分もClaude Codeを使いながら、以前は半日かかっていた機能の実装が1〜2時間で完成する感覚を何度も味わってきました。

ただ、2026年3月11日に公開されたあるレポートを読んで、少し立ち止まって考える必要があるな、と感じました。

「30件のプルリクエストのうち、87%に少なくとも1件の脆弱性が含まれていた。」

これは、セキュリティ企業DryRun Securityが実施した調査の結果です。Claude Code、OpenAI Codex、Google Gemini の3つのAIコーディングエージェントを使って、実際に2つのアプリケーションをゼロから構築させた実験でした。

Vibe Codingが普及した今だからこそ、この数字が何を意味するのか、正直に向き合ってみたいと思います。

第1章：DryRun Securityの研究を読む — 何を、どうやって調べたのか

実験の設計

この研究で面白いのは、「わかりやすい脆弱性を意図的に混ぜたテスト」ではなく、リアルな開発プロセスを忠実に再現した点です。

2つのアプリケーションを作らせました。

一つ目は 「FaMerAgen」 — 子どものアレルギーや家族の連絡先を管理するWebアプリ。医療情報を扱うため、認証やデータ保護が重要になります。

二つ目は 「Road Fury」 — ブラウザベースのレーシングゲーム。バックエンドAPI、ハイスコアシステム、マルチプレイヤー機能を含みます。スコアの改ざんや不正アクセスが起きうる設計です。

どちらも「セキュリティを意識したプロンプト」は一切使わず、普通のプロダクト仕様書だけを渡しました。これが重要な点で、実際の開発現場でAIが使われる状況と同じ条件です。

スキャンの方法

各エージェントはプルリクエストを通じて機能を追加していきました。DryRunは毎回のPRを提出時にリアルタイムでスキャン。さらに開発開始前と全機能マージ後にもフルスキャンを実施。

合計38回のスキャンで、30件のPRをカバー。見えてきたのは、「どのエージェントも、同じような場所でつまずく」 という事実でした。

第2章：AIエージェントが繰り返す10種類のセキュリティミス

DryRunの研究で最も印象的だったのは、「10種類の脆弱性カテゴリが全エージェントに共通して現れた」という発見です。特定のAIが弱い、という話じゃなくて、AIコーディング全体の構造的な問題として認識するべきだと思います。

1. 壊れたアクセス制御（Broken Access Control）

全3エージェント、両アプリケーションに共通して現れた最も普遍的な問題。認証されていないエンドポイントが、破壊的・機密的な操作に対して開いたままになっているパターンです。

「ログインしてなくてもこのAPIを叩けてしまう」という状態、わかりますよね。AIは「機能として動く」コードを書くのは得意ですが、「このAPIには誰がアクセスできるべきか」を考える習慣がないんです。

2. ビジネスロジックの失敗

ゲームアプリで全3エージェントに出現しました。スコア、残高、アンロック状態がクライアントからサーバー側の検証なしに受け入れられる状態です。

「クライアントが送ってきた値を信用しない」というセキュリティの基本原則、AIはなかなか実装しないんですよね。なんでかというと、「動くこと」を優先するからです。サーバー側検証を追加すると、コードが複雑になる。AIはシンプルに動くコードに傾きやすい。

3. OAuth実装の失敗

Webアプリで全3エージェントに発生。stateパラメータの欠如と安全でないアカウントリンクが、ソーシャルログイン実装のたびに現れました。

OAuth2のflowは複雑で、正しく実装するのは人間でも難しい。AIが学習したコード例の中に、古い・不完全な実装パターンが多いため、そのまま再現してしまうんでしょう。

4. WebSocket認証の欠落

これが個人的に一番「なるほど」と思った発見です。全エージェントの最終コードで、WebSocket接続に認証がかかっていませんでした。

面白いのは、REST APIの認証ミドルウェアは正しく実装していたんです。でも、WebSocketのアップグレードハンドラにそれを接続しなかった。「HTTPは認証した。WebSocketは別のものだから認証不要」という、AIの認知の断絶を感じます。

5. Rate Limitingの不接続

Rate limiting（レート制限）のミドルウェアは全コードベースで定義されていました。でも、アプリケーションに接続したエージェントは一つもなかった。

「定義したが使わなかった」というのは、人間のエンジニアだったら絶対に気づくはずの問題です。AIは「実装した」という行為で満足してしまって、「実際に機能しているか」を確認しない傾向があるかもしれません。

6. JWTシークレット管理の甘さ

ゲームアプリで全3エージェントに発生。ハードコードされたフォールバックシークレットが存在し、攻撃者はこれを使って有効なトークンを偽造できる状態でした。

環境変数からシークレットを読む実装は正しくできていたのに、「環境変数がない場合のフォールバック」としてハードコードを挿入してしまう。開発の利便性を優先した結果です。

7. セッション管理の問題

セッションの固定化（session fixation）、不適切なセッション無効化、期限切れトークンの扱い漏れ。これも人間が「テストしながら気づく」タイプの問題ですが、AIは「コードを書いてテストする」というサイクルを回さないので見落とします。

8. ユーザー列挙の脆弱性

「このメールアドレスは登録済みです」「このユーザー名は使用中です」という具体的なエラーメッセージ。ユーザーにとっては親切なんですが、攻撃者にとっては「どのアカウントが存在するか」を調べるための情報源になってしまいます。

9. クライアントサイド信頼の問題

クライアントから送られてきたデータをそのまま信用する実装。フロントエンドはあくまでユーザーの手元にあり、改ざん可能です。AIは「フロントとバックがセットで動く」と考えがちで、その境界のセキュリティを忘れます。

10. インジェクション・入力バリデーション

SQLインジェクション、XSS、コマンドインジェクション。これは最も古典的な脆弱性ですが、2026年になってもAIは繰り返します。「動くコード」と「安全なコード」は違うという証拠です。

第3章：Claude / Codex / Gemini それぞれの「傾向と対策」

3エージェントを比較すると、興味深い個性の違いが見えてきます。「どれが一番安全」という話ではなく、「それぞれの癖を理解して使う」という視点で見てほしいです。

OpenAI Codex（GPT-5.2）の傾向

最終スコア: Webアプリ8件（ベースラインより1件少ない）、ゲームアプリ6件

両アプリケーションで最もクリーンな最終結果でした。ただし、一時的なトークンバイパスが最終コードに残存。

Codexは「問題を発見して修正していく」サイクルを比較的うまく回す印象があります。ただし、設計段階での根本的な問題を後から修正するアプローチなので、「最初から安全に設計する」という意識は他と同様に薄いと言えます。

Anthropic Claude（Sonnet 4.6）の傾向

最終スコア: Webアプリ13件、ゲームアプリ8件

最も多くの問題が残りましたが、注目すべきは「他のエージェントには見られない問題」を導入した点です。2FA無効化バイパスというClaudeにしか出なかった脆弱性がありました。

これは「Claude が独自のアプローチをとる」という表れでもあって、一概に悪いことではないんですが、その独自性が予期しない形でセキュリティに影響することがある、ということです。普段Claude Codeを使っている自分としては、少し引っかかる数字ですね。

Google Gemini（2.5 Pro）の傾向

最終スコア: Webアプリ11件、ゲームアプリ7件

OAuth CSRFと招待バイパスの問題が最終スキャンまで残存。認証フロー周りの問題が特に顕著でした。

Geminiはコード生成の速度と質が高い評価を受けていますが、認証・認可という繊細な部分での取りこぼしが目立つ傾向があります。

3エージェント共通の教訓

どのエージェントを選んでも「セキュアなコードが自動的に生成される」とは期待できません。そして、「どのエージェントが一番安全か」を気にするより、「AIが書いたコードをどうレビューするか」を考える方が建設的です。

第4章：なぜAIはセキュリティを考えないのか — 根本原因を掘り下げる

これは単純な「AIが下手」という話ではないと思っています。もう少し構造的な問題があります。

「動くこと」を学習している

AIは大量のコードから学習しています。そのコードの多くは「機能として動く」コードです。GitHubには何億件ものコードがありますが、「セキュアに動く」コードと「ただ動く」コードは外見上見分けがつきにくい。

学習データの中に「セキュリティを意識したコード」は確かにあります。でも「なぜそのコードがセキュアなのか」という文脈の学習は、テキスト予測ベースのLLMには難しい。

セキュリティは「文脈」が必要

「このAPIは管理者しかアクセスできない」「このデータは外部から書き換えられるべきでない」という判断は、ビジネスロジックへの深い理解が必要です。

AIに仕様書を渡しても、「この要件の裏にどんなセキュリティ前提があるか」は明示されていないことが多い。人間のエンジニアは経験からそれを読み取りますが、AIはプロンプトに書いてあることしか考えられません。

テストサイクルがない

人間が書くコードはたいてい、動作確認しながら書き進めます。「あれ、このエンドポイントに認証かけるの忘れてた」という気づきが生まれる。

AIは一度にまとめてコードを書いて、「完了」とします。WebSocketの認証が欠落していても、REST APIが動いていれば「動作する」と判定してしまいます。

プロンプトへの忠実性

AIは「プロンプトに書いていないことを補完する」のが苦手です。「ユーザー認証機能を実装して」と言えば、認証を実装します。でも「認証済みユーザーだけがこのAPIにアクセスできるようにして」と明示しなければ、APIにガードをかけません。

この「言外の意図を読み取る能力」のギャップが、セキュリティ上の欠落につながっています。

CodeRabbitの分析が示す数字

2025年12月のCodeRabbit社の分析によると、AIが共同執筆したコードは：

  • 設定ミスが75%多い
  • セキュリティ脆弱性が2.74倍多い
  • 依存関係の誤り、フロー制御の欠陥も増加

これは「AIを使うな」ということではなく、「AIが書いたコードには人間の目が特に必要」というメッセージだと受け取っています。

第5章：今日からできる実践的な防衛策

「じゃあどうすればいいの」というのが一番気になるところですよね。具体的に、明日から変えられることを整理します。

プロンプトにセキュリティ要件を明示する

AIはプロンプトに書いてあることを実装します。逆に言えば、セキュリティ要件をプロンプトに書けば対応してくれる確率が上がります。

# セキュリティ要件を明示するプロンプト例

以下の要件でAPIエンドポイントを実装してください。

【機能要件】
- ユーザーのプロフィール更新機能

【セキュリティ要件（必須）】
- 認証済みユーザーのみアクセス可能（JWT検証）
- 自分のプロフィールのみ更新可能（user_id の一致確認）
- Rate Limiting: 1分間に5回まで
- 入力バリデーション: XSS対策、最大文字数制限
- レスポンスに認証情報を含まない

「セキュリティを意識してください」という曖昧な指示よりも、具体的な要件リストの方がはるかに効果的です。

実装後の自動スキャンを必ず入れる

AIが書いたコードをそのままマージするのは避けたい。少なくとも、静的解析ツールをCI/CDに組み込むことを推奨します。

# GitHub Actions での例
name: Security Scan

on: [pull_request]

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      # Semgrep による静的解析
      - name: Run Semgrep
        uses: semgrep/semgrep-action@v1
        with:
          config: p/security-audit
          
      # npm audit (Node.js の場合)
      - name: npm audit
        run: npm audit --audit-level=high
        
      # Trivy によるコンテナスキャン（必要な場合）
      - name: Run Trivy
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'fs'
          security-checks: 'vuln,secret'

「AI生成コードレビューチェックリスト」を作る

AIが書いたコードをレビューする際に、特に注意すべきポイントをチェックリスト化しておくのは効果があります。

## AI生成コードのセキュリティレビューチェックリスト

### 認証・認可
- [ ] 全APIエンドポイントに認証チェックがあるか
- [ ] ユーザーは自分のリソースのみアクセスできるか（IDOR対策）
- [ ] 管理者専用機能に権限チェックがあるか
- [ ] WebSocket接続にも認証があるか（REST APIだけでなく）

### 入力バリデーション
- [ ] ユーザー入力がDBに渡る前にサニタイズされているか
- [ ] クライアントから送られる値をサーバー側で再検証しているか
- [ ] ファイルアップロードの拡張子・サイズチェックがあるか

### シークレット管理
- [ ] APIキー・シークレットがハードコードされていないか
- [ ] JWTシークレットは環境変数から読んでいるか
- [ ] フォールバック値にシークレットが使われていないか

### Rate Limiting
- [ ] Rate limitingミドルウェアが実際にルートに適用されているか
- [ ] 認証エンドポイント（ログイン等）に特に厳しいRate Limitがあるか

### エラーハンドリング
- [ ] エラーメッセージにユーザー列挙の情報が含まれていないか
- [ ] スタックトレースが外部に漏れていないか

### 依存関係
- [ ] 追加したnpmパッケージに既知の脆弱性がないか（npm audit）
- [ ] バージョンは最新の安定版か

「セキュリティレビュー専用エージェント」を設定する

Claude Codeのサブエージェント機能を使って、セキュリティレビュー専用のエージェントを設定する方法も効果的です。

---
name: security-reviewer
description: セキュリティレビュー専門エージェント。コード変更後に積極的に使用。
tools: Read, Glob, Grep
model: claude-sonnet-4-6
maxTurns: 20
---

あなたはシニアセキュリティエンジニアです。
以下の観点でコードを徹底的にレビューしてください。

## 必ずチェックする観点

1. **認証・認可**: 全エンドポイントに認証チェックがあるか、IDOR脆弱性がないか
2. **入力バリデーション**: SQLインジェクション、XSS、コマンドインジェクションのリスク
3. **シークレット管理**: ハードコードされた認証情報、環境変数の正しい使用
4. **Rate Limiting**: ブルートフォース攻撃への耐性
5. **WebSocket/リアルタイム通信**: 認証がREST APIと同様に適用されているか
6. **ビジネスロジック**: クライアントから受け取った値の信頼度
7. **エラーハンドリング**: 情報漏洩につながるエラーメッセージ
8. **依存関係**: 使用しているライブラリの脆弱性

問題を発見した場合は、必ず修正コードのサンプルも示してください。

「説明を求める」文化を作る

AIが書いたコードを自分で理解せずにマージする「理解負債」は危険です。わからない部分があれば、必ずAIに説明を求める習慣をつけましょう。

# このコードのセキュリティ上の考慮点を教えて

実装してくれた認証部分について:
1. このJWT検証はどんな攻撃を防いでいるの？
2. Rate limitingが効いているか、どうテストすればいい？
3. このコードで想定していないセキュリティリスクがあれば教えて

「AIが書いたから正しい」ではなく、「AIが書いたコードを自分が理解している」という状態を目指すことが大切です。

第6章：業界の反応 — Claude Code Security と Codex Security が生まれた意味

興味深いことに、このDryRunのレポートが話題になっている同じ時期に、AnthropicとOpenAIはそれぞれセキュリティ専用のAIツールを発表しています。

Claude Code Security（2026年2月20日）

Anthropicが発表した「Claude Code Security」は、コードベースをスキャンして脆弱性を検出するツールです。従来のパターンマッチング型の静的解析ツール（SAST）とは異なり、AIがコードを「人間のセキュリティ研究者のように」読み解きます。

数値で言うと、Claude Code Securityは複数のOSSプロジェクト（Outline、WooCommerce、Rocket.Chatなど）で500件以上の脆弱性を発見。権限昇格やパスワード認証バイパスといった重大な問題を検出し、従来ツールが見落としていたロジックバグを見つけることに強みがあります。

Codex Security（2026年3月6日）

OpenAIが発表した「Codex Security」は、GPT-5.4を使ってプロジェクトを解析、脅威モデルを自動生成し、重大度の高い問題を抽出して修正案を提示するエージェントです。1ヶ月間は無料で試せます。

これが意味すること

「AIがコードを書く」と「AIがセキュリティをチェックする」という2つの役割が生まれました。これは健全な進化だと思います。

コードを書くAIと、レビューするAIを分ける。開発速度を上げるAIと、安全性を担保するAIを組み合わせる。これは人間のソフトウェア開発チームにおける「開発者とセキュリティエンジニアの分業」と同じ考え方です。

AI同士が「作る」と「確認する」のチェックをかけ合う構造が当たり前になる時代が近づいている気がします。

終章：それでもVibe Codingは続く — 正しい付き合い方

今回のレポートを読んで、「AIコーディングはやめよう」とは全く思いませんでした。むしろ逆で、「問題を正確に理解した上で使い続けよう」という気持ちが強くなりました。

数字を正しく読む

「87%のPRに脆弱性がある」という数字は衝撃的ですが、文脈も大切です。人間が書いたコードのPRにも脆弱性は含まれます（業界平均で見ると、人間のコードにも相当数の脆弱性が存在する）。AIが「特別に危険」というより、「AIの脆弱性パターンを理解して対処できていない」ことが今の課題です。

速度と安全性は両立できる

「Vibe Codingは速い。でも危ない。」

これは半分しか正しくないと思っています。「Vibe Coding + セキュリティスキャン + レビュープロセス = 速くて安全な開発」という組み合わせは十分に実現可能です。

大切なのは、AIが書いたコードを「完成品」ではなく「草稿」として扱うことかもしれません。人間の編集者が草稿を磨くように、セキュリティの目線でAIの草稿を磨く。そういうワークフローを作ることです。

「理解負債」を積まない

一番危険なのは、「AIが書いたから大丈夫だろう」という盲信です。自分が理解できないコードを本番に出すことのリスクは、AIコーディング以前からある話ですが、Vibe Codingの速度感の中でそれが起きやすくなっています。

「速く書けた」の後に「ちゃんと理解した」という確認ステップを入れることを、自分自身への約束にしています。

AIと一緒にセキュリティを学ぶ

ある意味で、今はセキュリティを深く学ぶ最高の時代だと思っています。「なぜこの実装は危ないの？」「どう直せばいい？」をAIに聞きながら学べる。Claude Code Securityが見つけた脆弱性の解説を読みながら、自分のセキュリティ知識が深まる。

AIがコーディングを民主化したように、AIがセキュリティ知識の習得も民主化しようとしている。そういう可能性を感じています。

今週、世界中でこの話題が盛り上がっている中で、「問題を直視しながらも前向きに」という視点でまとめてみました。

Vibe Codingの速度感は本物です。ただ、セキュリティという「地味で大切なもの」を忘れないようにしながら使っていきたいと、改めて思っています。

DryRun Securityのレポートへのリンクは参考文献に置いておきます。英語ですが、数字と表が豊富で読みやすいので、ぜひ一次情報も確認してみてください。

参考文献

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?