【2026年版】Claude Code セキュリティプロンプト集｜OWASP Top 10対応・コピペで使える脆弱性レビュー20選

AI生成コードの15〜25%に脆弱性が含まれるという調査結果があります。開発速度が上がるほど、セキュリティレビューがボトルネックになる構造は避けられません。本記事では、Claude Codeに投げるだけで脆弱性を洗い出せるプロンプトを、OWASP Top 10:2025のカテゴリ別にまとめました。すべてコピペで使えます。

なぜAIコーディングエージェントにセキュリティレビューを任せるのか

「書くAI」と「レビューするAI」を分離する

Claude CodeなどのAIコーディングエージェントは、コードを書く速度を劇的に向上させます。しかしその副作用として、「コードを書いたAI自身」にレビューを依頼すると、自分の誤りに気づきにくいという問題があります。実際の開発現場では、コード生成と脆弱性検出を別のプロンプト・別のコンテキストで行うことがベストプラクティスとして定着しています。

人間のレビューが見落としやすい3つのポイント

セキュリティレビューにAIを組み込む理由は、速度だけではありません。人間のレビューには構造的な限界があります。

認可チェックの"抜け"：正常系しか確認しないため、user_idを書き換えた際の挙動を見落としやすい
差分レビューの盲点：変更ファイルしか見ないため、横断的なアクセス制御の問題を発見できない
疲労によるチェックリストの形骸化：繰り返し作業でチェックが形式的になる

AIは疲れません。観点を明示すれば、毎回同じ精度でスキャンします。

前提知識：OWASP Top 10:2025 カテゴリ一覧

プロンプト設計の軸にOWASPを使う理由は、観点の網羅性が保証されるからです。以下の10カテゴリをカバーすれば、主要な脆弱性クラスをほぼ網羅できます。

#	カテゴリ	代表的な脆弱性
A01	アクセス制御の不備	IDOR、BOLA、権限昇格
A02	セキュリティ設定ミス	CORS、CSP、デバッグモード
A03	ソフトウェアサプライチェーンの不備	依存パッケージの脆弱性
A04	暗号化の失敗	平文保存、弱いハッシュ
A05	インジェクション	SQLi、XSS、テンプレートインジェクション
A06	安全でない設計	レート制限なし、MFAなし
A07	認証の失敗	JWT検証不備、セッション固定
A08	データ整合性の不具合	署名なし更新、安全でないデシリアライズ
A09	ログ＆アラートの不備	監査ログの欠落、機密情報のログ出力
A10	例外的な状況への不適切な対応	エラー時の権限緩和、スタックトレース露出

2021年版からA03（サプライチェーン）の範囲が拡張され、A10が新設されています。プロンプト設計時はこの2カテゴリに特に注意が必要です。

標準コマンド `/security-review` の使い方と限界

基本動作

Claude Codeには/security-reviewという標準コマンドが搭載されており、直近の変更差分に対してSQLインジェクション・XSS・認証バイパスを自動検出し、修正パッチまで提示してくれます。

/security-review

これだけで動きます。日常的な差分チェックにはこれで十分です。

`/security-review` が苦手なこと

標準コマンドには明確な限界があります。

ビジネスロジック依存の認可漏れ：「このユーザーがこの操作をしていいか」という文脈はコードだけから判断できない
設計レベルの問題：レート制限がそもそも存在しないといった、アーキテクチャの問題は差分に現れない
横断的なテナント境界：マルチテナントの整合性は、変更ファイルだけを見ていても検出できない

日常の差分チェックには/security-review、リリース前・設計レビューにはカテゴリ別カスタムプロンプトという使い分けがベストプラクティスです。

効果的なセキュリティプロンプト設計の3原則

原則1：観点を具体的に列挙する

❌ NG例

このコードにセキュリティ的な問題がないか確認してください。

✅ OK例

SQLインジェクション・認可漏れ・機密情報漏洩・CORS設定ミス・
トークン有効期限の検証を確認し、それぞれ問題あり/防御済み/
該当なし/未確認 の4値で報告してください。

「問題ないか見て」では、何を見たかが不明確で再現性がありません。観点を列挙することで、毎回同じ基準でレビューできます。

原則2：「該当なし」を強制する

全カテゴリについて必ず回答させる設計が重要です。AIは問題がないカテゴリを黙ってスキップする傾向があります。「沈黙＝安全」ではありません。

各カテゴリについて必ず回答してください。
問題が見つからない場合は「該当なし（理由：〜）」と明記してください。

原則3：攻撃シナリオ形式で出力させる

問題を発見した場合、以下の形式で報告してください：
- 脆弱性名：
- 該当コード（ファイル名・行番号）：
- 攻撃シナリオ（例：このパラメータにX値を渡すと〜できる）：
- 修正コード：

再現手順まで書かせることで、ハルシネーション（幻覚）を大幅に減らせます。「攻撃できると言ったが、実際には不可能だった」という誤報を防ぐ効果があります。

【本編】脆弱性カテゴリ別プロンプト集

A01：アクセス制御の不備（IDOR・BOLA検出）

URL・クエリパラメータ・リクエストボディに含まれる
user_id / tenant_id / project_id / account_id を
別のユーザーの値に書き換えることで、他者のデータを
取得・変更・削除できないか確認してください（BOLA/IDOR）。

マルチテナント環境の場合、テナント間の境界が
すべてのAPIエンドポイントで正しく検証されているかも確認してください。

問題あり/防御済み/該当なし/未確認 の4値で、
リスクレベル（High/Medium/Low）とともに報告してください。

使うタイミング：新規APIエンドポイントの追加時、マルチテナント機能のリリース前

A02：セキュリティ設定ミス検出

以下の設定を確認してください：
- CORSの許可オリジン（ワイルドカード使用の有無）
- CSP（Content Security Policy）ヘッダーの設定
- デバッグモード・詳細エラーの本番環境での有効化
- デフォルト認証情報の残存
- 不要なHTTPメソッドの許可

各項目について 問題あり/防御済み/該当なし/未確認 で報告してください。

A03：依存パッケージのサプライチェーン点検

package.json（またはrequirements.txt / go.mod）を確認し、
以下を報告してください：
- 既知の脆弱性が報告されているパッケージ（CVE番号があれば記載）
- メンテナンスが停止しているパッケージ
- ロックファイル（package-lock.json / yarn.lock）との整合性
- 過度に広い権限を持つパッケージ

A04：暗号化の失敗

以下の暗号化実装を確認してください：
- パスワードのハッシュアルゴリズム（bcrypt/Argon2以外は要注意）
- 平文での機密情報保存
- HTTP通信の強制（HTTPSリダイレクトの有無）
- 暗号学的に安全な乱数生成（Math.random()などの使用）
- AES-ECBなど脆弱な暗号モードの使用

問題が見つかった場合は修正コードも提示してください。

A05：インジェクション全系統の棚卸し

外部入力（クエリパラメータ・リクエストボディ・HTTPヘッダー・
ファイル名・外部APIレスポンス）が以下に流れ込む箇所をすべて列挙してください：

- SQL / NoSQLクエリ
- HTMLテンプレート
- シェルコマンド
- ログ出力
- CSVエクスポート
- メールヘッダー

各箇所について、パラメータ化クエリ・エスケープ・
サニタイズが正しく実装されているか確認し、
問題がある箇所は修正コードを提示してください。

A07：認証の失敗（3点セット監査）

以下の3つの認証フローを監査してください：

1. サインアップ：メールアドレス列挙攻撃の可能性、
   確認なしアカウント作成の悪用

2. ログイン：ブルートフォース対策（レート制限・アカウントロック）、
   タイミング攻撃の可能性

3. パスワードリセット：トークンの有効期限・使い捨て性・
   推測可能性、古いトークンの無効化

JWTを使用している場合：署名アルゴリズム（none攻撃）・
有効期限検証・失効リストの実装も確認してください。

A09：ログ＆アラートの点検（両面チェック）

ログ実装を両面から確認してください：

【欠落チェック】
以下のイベントが監査ログに記録されているか：
- 認証の成功・失敗
- 権限変更・ロール付与
- 機密データへのアクセス
- 設定変更

【過剰チェック】
ログにパスワード・APIキー・個人情報・
セッショントークンが混入していないか。

横断テーマ：シークレット漏洩検出

以下の機密情報がコード・設定ファイル・コメントに
ハードコードされていないか確認してください：

- APIキー・アクセストークン
- データベース接続文字列・パスワード
- 秘密鍵・証明書
- 内部IPアドレス・エンドポイント

発見した場合は、環境変数または Secret Manager への
移行方法を具体的なコードで示してください。

LLM／AIエージェント特有のリスクへの対応

AIを使ったシステムを開発している場合、通常のOWASPに加えてLLM固有のリスクに対応するプロンプトも必要です。

プロンプトインジェクション対策

ユーザーからの入力がシステムプロンプトまたはLLMへの
プロンプトに直接連結される箇所を特定してください。

「以下のシステムプロンプトを無視して〜」といった
インジェクションが成功する構造になっていないか確認し、
入力の無害化・構造的分離の方法を提案してください。

AIエージェントの過剰権限チェック

AIエージェントに付与されているツール実行権限・
外部API呼び出し範囲を確認し、最小権限原則に従っているか検証してください。

特に以下を確認してください：
- ファイルシステムへのアクセス範囲
- 外部API呼び出しの許可リスト
- データベースへの書き込み権限
- 人間の承認なしに実行できる不可逆な操作

出力フォーマットを設計して"使えるレポート"にする

プロンプトに以下のフォーマット指定を追加することで、そのままIssueに貼り付けられるレポートが生成されます。

## セキュリティレビュー結果フォーマット

各脆弱性カテゴリについて以下の形式で回答してください：

### [カテゴリ名]
- **判定**：問題あり / 防御済み / 該当なし / 未確認
- **リスクレベル**：High / Medium / Low / N/A
- **該当箇所**：ファイル名・行番号
- **攻撃シナリオ**：（問題ありの場合）具体的にどう悪用できるか
- **修正方針**：

「未確認」の場合は確認に必要な追加情報を明記してください。
問題がないカテゴリも「該当なし（理由：〜）」と必ず記載してください。

4値分類のポイント：「未確認」という選択肢を用意することが、レビュー品質を大きく左右します。AIが確認できなかった箇所を明示することで、人間のフォローアップが必要な範囲が可視化されます。

運用ルール：安全にAIセキュリティレビューを回すために

機密ファイルを読ませない設定（必須）

.claude/settings.jsonに以下を設定し、.env系ファイルへのアクセスをブロックします。

{
  "permissions": {
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(**/*.pem)",
      "Read(**/*.key)",
      "Read(**/secrets/**)"
    ]
  }
}

「検出はAI、判断は人間」の線引き

AIが提案した修正コードを自動適用してはいけません。AIは正しい脆弱性を指摘しながら、誤った修正を提案することがあります。検出と優先度付けはAI、最終的な修正判断は必ず人間が行うという運用ルールを徹底してください。

プロンプトをリポジトリ管理する

プロンプトを毎回手入力するのは非効率であり、レビュー品質のばらつきにもつながります。.claude/配下にプロンプトファイルを置き、Gitで管理することをお勧めします。

.claude/
  security-prompts/
    a01-access-control.md
    a05-injection.md
    secrets-detection.md
    full-review.md

導入効果：手動レビューとの比較

実際の開発現場での計測データです。

指標	手動レビューのみ	AI併用後
検出精度	約60%	約95%（+35%）
1回あたりの作業時間	2〜3時間	約30分（85%削減）
月間の見逃し件数	3〜5件	0〜1件

ただし、AIセキュリティレビューには過信してはいけない領域があります。設計そのものの妥当性（権限モデルが正しいかどうか）とサードパーティ側の問題については、AIは判断できません。AIはコードに書かれていることを検証しますが、「そもそも設計が間違っている」は人間が判断する必要があります。

よくある失敗と対処法

「問題ありません」しか返ってこないとき

コンテキストが不足しています。対象ファイルを明示的に指定し、「全カテゴリを必ず回答せよ」という強制指示を追加してください。また、「問題なし」の根拠も書かせる設計にすることで、本当に確認したかどうかを検証できます。

指摘が抽象的すぎて修正に使えないとき

攻撃シナリオの具体化を要求してください。「〜の可能性があります」という表現は、ファイル名・行番号・具体的なペイロード例まで書かせることで実用的になります。

コンテキスト超過で精度が落ちるとき

大規模リポジトリでは、1回のプロンプトで全体をレビューしようとしないことが重要です。レイヤー別（API層・ビジネスロジック層・データアクセス層）または機能別に分割し、複数回に分けて実施してください。

まとめ：まず試す3つのプロンプト

本記事で紹介したプロンプトの中から、今日から使える最小セットを選ぶとすれば以下の3つです。

シークレット検出プロンプト：実施コストが最も低く、発見した場合のリスクが最も高い
IDOR検出プロンプト（A01）：見落としが多く、影響範囲が広い
インジェクション棚卸しプロンプト（A05）：外部入力の流れを可視化することで、他の脆弱性発見にもつながる

段階的に理解を深めていきましょう。まずこの3つを現在進行中のプロジェクトに適用し、出力結果を確認することから始めることをお勧めします。慣れてきたら出力フォーマットを設計し、プロンプトをリポジトリに保存してチームで共有するフローへと発展させてください。

FAQ

Q. /security-reviewだけで十分ではないですか？

日常的な差分チェックには十分ですが、リリース前の総合レビューやビジネスロジック依存の認可問題には不十分です。本記事のカスタムプロンプトと組み合わせて使うことで、検出精度が大幅に向上します。

Q. 本番コードをAIに読ませても安全ですか？

Claude Codeはローカル環境で動作するため、コードが外部サーバーに送信されることへの懸念は正当です。機密情報が含まれるファイルはpermissions.denyでブロックし、シークレットが含まれる.env系ファイルは絶対に読ませないよう設定してください。

Q. 専門的なペネトレーションテストの代わりになりますか？

なりません。AIセキュリティレビューは「コードベースの脆弱性パターン検出」に特化しており、動的な攻撃シミュレーション・ネットワーク層の検査・ビジネスロジックの妥当性検証はペネトレーションテスト専門家にしかできません。AIを使っても、定期的な専門家によるペネトレーションテストは必要です。

Q. 他のAIコーディングエージェントでも使えますか？

本記事のプロンプトはClaude Code向けに最適化していますが、観点の明示・4値分類・攻撃シナリオ形式という設計原則はGitHub CopilotやCursorなど他のエージェントでも有効です。