結論：Claude Code はセキュリティ業務の「下調べ・整理・たたき台づくり」を大幅に短縮できます。ただし、脆弱性の最終判断・修正の妥当性・本番反映は必ず人（セキュリティ専門家）が検証することが大前提です。2026年6月時点で、依存関係の棚卸し、セキュアコードレビューの一次スクリーニング、修正パッチのたたき台、チェックリスト整備、インシデント時のログ調査補助の5領域で効果が出ます。
- 要点1：AIに本物の認証情報・顧客データ・機密を渡さない。AIが出した指摘も修正案も、人がレビューしテストしてから採用する。
- 要点2：Claude Code はデフォルトで read-only。権限設定・サンドボックスを理解して使えば、調査用途は安全に回せる。
- 要点3：本記事は防御・修正の観点に徹する。攻撃の具体的な悪用手順は扱わない。
対象読者：セキュリティエンジニア／開発者でClaude Code を脆弱性対応に組み込みたい人。今日できること：下のプロンプト例をそのまま自社リポジトリで試し、依存関係の棚卸しから着手する。
セキュリティ業務は、調べる対象が広いわりに「結局、影響があるのはどこか」を絞り込む作業に時間が溶けます。依存関係のCVEを1件ずつ追い、コードのどこで使われているかを横断検索し、修正案を書き、テストを足し、報告書にまとめる──この一連の段取りのうち、機械的な整理の部分はClaude Code がかなり巻き取れます。一方で、「これは本当に悪用可能か」「この修正で別の機能が壊れないか」という判断は、最後まで人の仕事です。この記事では、その線引きを守りながら、現場で実際に使えるワークフローを5つに分けて、プロンプトとコード例つきで紹介します。
大前提：AIに任せていい範囲と、人が必ず検証する範囲
最初に線引きをはっきりさせます。ここを曖昧にすると、AIの「それっぽい」指摘を鵜呑みにして、存在しない脆弱性を直したり、逆に本物を見逃したりします。
| 工程 | Claude Code に任せてよい | 人が必ず検証する |
|---|---|---|
| 依存調査 | 依存ツリーの抽出・整理、CVE候補の一覧化 | そのCVEが自社の使い方で悪用可能か（到達可能性） |
| コードレビュー | 典型パターンの一次スクリーニング | 本当に脆弱か（誤検知・過検知の選別） |
| 修正 | 修正パッチのたたき台作成 | 修正の妥当性・副作用・回帰テスト結果 |
| テスト整備 | チェックリスト・テストケースの草案 | カバレッジの十分性、抜け漏れ |
| インシデント | ログの集計・時系列整理・仮説出し | 原因の確定、影響範囲、対外報告 |
Claude Code 公式ドキュメントも明言しているとおり、「Claude Code はあなたが与えた権限しか持たず、提案されたコードやコマンドの安全性を承認前にレビューする責任は利用者にある」（User responsibility）という設計思想です。AIは下調べを速くしてくれる相棒であって、判断を肩代わりする存在ではない、という前提を全工程で守ってください。
機密情報を入れないための運用ルール
- 本物のAPIキー・トークン・パスワード・顧客個人データはプロンプトにもリポジトリにも置かない。調査用には伏字・ダミー値を使う。
- 機密リポジトリでは
/permissionsでプロジェクト固有の権限設定を見直し、書き込み範囲を作業ディレクトリ内に限定する。 - 外部Webを取りに行くコマンド（
curl／wget等）はデフォルトでブロックされる挙動を活かし、調査は基本オフラインで回す。
領域1：依存関係・既知脆弱性の調査と影響範囲の把握
OWASP Top 10:2025 では「A03:2025 – Software Supply Chain Failures（ソフトウェアサプライチェーンの不具合）」が上位に入りました。依存ライブラリ経由の脆弱性は、もはや最優先カテゴリです。ここでClaude Code が効くのは「どのCVEが、自社コードのどこに、どう効いてくるか」の地図づくりです。
まず、調査の起点になる依存リストとアドバイザリを手元に集めます。ロックファイルや監査ツールの出力をそのまま読ませると、整理が一気に進みます。
# npm の場合：既知脆弱性のレポートを取得（防御側の標準作業）
npm audit --json > audit-report.json
# Python の場合：依存ツリーを固定化
pip freeze > requirements.lock
# 取得したレポートを Claude Code に読ませて整理する
そのうえで、影響範囲を「実際にそのコードパスが呼ばれているか（到達可能性）」の観点で絞り込ませます。CVEがあっても、その関数を一切使っていなければ実害は限定的、という判断材料を出させるのがポイントです。
プロンプト例：
audit-report.json を読み、検出された脆弱性を
「深刻度（critical/high/moderate/low）」で分類してください。
そのうえで、各パッケージが本リポジトリのどのファイル・
どの関数から import されているかを横断検索し、
「実際に到達し得るコードパスがあるか」を整理してください。
到達不能と思われるものは理由とともに別枠にしてください。
※最終的な悪用可能性の判断は人が行うので、断定はせず
根拠（呼び出し箇所・行番号）を必ず添えてください。
出力された一覧は、あくまで「人が確認するためのチェック表」です。Claude Code が「到達不能」と判定したものでも、動的importやリフレクション経由で呼ばれていないかは人が裏取りします。確認できなかったCVEの深刻度や日付は、CISAの Known Exploited Vulnerabilities Catalog やGitHub Advisory Database など一次ソースで突き合わせてください。詳しい権限の絞り込み方はClaude Codeサンドボックスで安全に自動実行する実践ガイドが参考になります。
領域2：セキュアコードレビューの一次スクリーニング
人手のコードレビューは、量が増えると典型パターンを見落としがちです。Claude Code に「よくある脆弱性パターンの洗い出し」を先に走らせ、人は絞られた候補を精査する、という分担にすると速くなります。洗い出しの観点は OWASP Top 10:2025 のカテゴリに沿わせるのが分かりやすいです。
| 観点（OWASP 2025 準拠） | 一次スクリーニングで探させるもの |
|---|---|
| A05 Injection | SQL/OSコマンド/LDAP 等での未サニタイズな文字列結合 |
| A07 Authentication Failures | 認証・セッション管理の甘さ、固定値の比較 |
| A04 Cryptographic Failures | 弱いハッシュ・平文保存・乱数の誤用 |
| A01 Broken Access Control | 認可チェック漏れ、権限昇格の余地 |
| 機密の扱い | ハードコードされた鍵・トークン・接続情報 |
下のプロンプトは「指摘の根拠と修正方針」をセットで出させる形にしています。根拠（ファイル・行・なぜ危険か）がないレビューは検証できないので、必ず添えさせます。
プロンプト例：
このディレクトリのコードを OWASP Top 10:2025 の観点で
一次レビューしてください。特に Injection・認証/認可・
機密情報の扱いに注目し、各指摘について
(1) 該当ファイルと行番号
(2) なぜ問題になり得るか
(3) 防御側の修正方針（安全なコードの書き方）
を表形式で出してください。
誤検知の可能性があるものは「要人手確認」と明記してください。
攻撃の具体的な悪用手順は書かないでください。
安全な書き換えの一例として、文字列結合のクエリをパラメータ化する「直し方」を示します。Claude Code にはこの方向（防御側）で修正案を出させます。
# ❌ 危険：ユーザー入力を直接連結（Injection の温床）
query = "SELECT * FROM users WHERE name = '" + user_input + "'"
# ⭕ 安全：プレースホルダでパラメータ化する
query = "SELECT * FROM users WHERE name = %s"
cursor.execute(query, (user_input,))
Claude Code には「Security guidance plugin」という公式機能もあり、これはセッション中にClaude 自身のコード変更をレビューして脆弱性を直させるためのものです。新規実装の自己点検に組み合わせると効果的です。
領域3：脆弱性の修正案作成とパッチのたたき台
一次レビューで「人が確認して、確かに直すべき」と確定したものについて、Claude Code に修正パッチのたたき台を作らせます。ここで重要なのは、AIが生成した修正もそのまま入れないことです。差分を読み、テストを通し、副作用を確認してから採用します。
Claude Code はデフォルトで read-only、ファイル編集やコマンド実行には都度承認を求める設計なので、修正の「提案」と「適用」の間に必ず人のレビューが挟まります。この承認ステップをスキップする --dangerously-skip-permissions は、セキュリティ調査の文脈では使わないのが無難です。
プロンプト例：
（人が確定した脆弱性に対して）
対象ファイルの該当箇所について、防御側の修正案を
差分（diff）形式で提案してください。
- 既存の挙動を壊さない最小変更にすること
- 入力検証・出力エスケープ・パラメータ化など
「安全な実装パターン」に沿うこと
- この修正で影響し得る他の箇所を併せて挙げること
適用はこちらで判断するので、まずは提案だけにしてください。
修正後は、必ず回帰テストとセキュリティ観点のテストを回します。テスト整備をAIに任せる方法は次の領域で扱います。バックエンドの修正で副作用を見落とさないコツはClaude CodeでバックエンドAPI開発を効率化する実践ガイドでも触れています。
領域4：セキュリティテスト・チェックリストの整備
脆弱性は「一度直して終わり」ではなく、再発させない仕組みが要ります。Claude Code にチェックリストとテストケースの草案を作らせ、人が抜け漏れを補完する流れが効率的です。OWASP のチートシートシリーズを参照させると、観点の網羅性が上がります。
- 対象機能の入力・出力・権限境界を洗い出させ、テスト観点の一覧を作らせる。
- 各観点について「正常系」「異常系（不正入力・境界値）」のテストケース草案を出させる。
- 人がカバレッジの十分性を判定し、足りない観点を追加する。
- CI に組み込み、依存の脆弱性スキャン（
npm audit等）を定期実行する設定にする。
プロンプト例：
このAPIエンドポイントについて、セキュリティ観点の
テストチェックリストを作ってください。
- 入力検証（型・長さ・文字種・境界値）
- 認証・認可の確認（権限のないユーザーでの試行）
- エラーメッセージから内部情報が漏れないか
OWASP の Injection / Access Control の観点を踏まえ、
正常系・異常系のテストケース草案も併記してください。
チェックリストはプロジェクトに固定化しておくと、次回以降のレビューが速くなります。プロジェクト共通のルールをAIに継続的に守らせる仕組みはCLAUDE.md設計・運用ガイドが参考になります。テスト整備の全体像はClaude Code 実践テクニック完全ガイドもあわせてどうぞ。
領域5：インシデント時のログ調査・原因切り分けの補助
インシデント発生時は、大量のログから「いつ・何が・どこで」を素早く組み立てる必要があります。OWASP Top 10:2025 にも「A09:2025 – Security Logging and Alerting Failures」が入っており、ログ整備と調査力は守りの要です。Claude Code は、ログの集計・時系列の整理・仮説出しの補助に向いています。
ここでの鉄則は、本物のアクセスログに含まれる個人情報・認証情報をそのまま渡さないこと。IPやトークンはマスキングし、調査に必要な構造だけを残してから読ませます。
# 調査前にログをマスキングしてから渡す（防御側の前処理）
# 例：トークンらしき長い英数字列を伏字化
sed -E 's/[A-Za-z0-9_-]{32,}/[REDACTED]/g' access.log > access.masked.log
# マスキング済みログを Claude Code に読ませる
プロンプト例：
このマスキング済みログ（access.masked.log）を読み、
- 異常なリクエストの急増やエラーレートの変化を時系列で整理
- 同一送信元からの連続した失敗パターンの有無
- 仮説（何が起きた可能性があるか）を複数挙げる
を出してください。
原因は断定せず、確認すべき次のログ・データを提案してください。
最終的な原因確定と対外報告は人が行います。
AIが出すのは「仮説」と「次に見るべき場所」までです。原因の確定、影響範囲の認定、顧客・規制当局への報告は、人の責任で行います。プロンプトインジェクション対策の観点では、Claude Code 自体が「ネットワークリクエストはデフォルトで承認が必要」「Web取得は別コンテキストで隔離」といった安全側の設計になっている点も、調査作業を安心して回す助けになります。
導入時に押さえる安全設定（2026年6月時点）
セキュリティ業務でClaude Code を使うなら、ツール自体の安全設定も最低限押さえておきます。公式ドキュメントで確認できる範囲をまとめます。
- read-only がデフォルト：編集・実行は都度承認。機密リポジトリでは
/permissionsで範囲を絞る。 - 書き込みは作業ディレクトリ内に限定：親ディレクトリは明示承認なしに変更できない。
- サンドボックス：
/sandboxでファイルシステム・ネットワークを隔離し、自律実行の境界を定義できる。 - Web取得コマンドはデフォルトでブロック：
curl／wget等は明示許可がない限り走らない。 - 許可した安全コマンドのallowlist化：頻用コマンドはユーザー／リポジトリ／組織単位で許可でき、過剰な承認疲れを防ぐ。
- 管理設定で組織標準を強制：チームでは managed settings と権限設定をバージョン管理で共有する。
これらは「Claude Code を安全に使う」ための設定で、本記事のテーマ「Claude Code を使ってセキュリティ業務をする」とは別軸ですが、土台として欠かせません。法人導入時の網羅的な確認はClaude Code法人導入セキュリティ完全チェックリストを参照してください。
よくある失敗と回避策
- ❌ AIの「脆弱性あり」をそのまま報告 → ⭕ 到達可能性とPoCの要否を人が確認してから報告する。
- ❌ 本物の認証情報を含むログをそのまま貼る → ⭕ マスキング・ダミー化してから渡す。
- ❌ AI生成の修正をテストなしでマージ → ⭕ 差分レビュー＋回帰テスト＋セキュリティテストを通す。
- ❌
--dangerously-skip-permissionsで調査を回す → ⭕ 承認ステップを残し、提案と適用を分ける。
著者プロフィール
佐藤傑（さとう・すぐる）。株式会社Uravation 代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援に携わる。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載を執筆。
