Claude Codeでセキュリティ監査を実務化する方法

AIに丸投げしないセキュリティ監査

Claude Codeは、セキュリティ監査を速くする強い相棒になります。依存関係の確認、権限チェック、ログの見直し、危険な入力処理の探索、PR差分レビューなど、人間だけで見ると時間がかかる作業を短時間で整理できます。

ただし「このリポジトリのセキュリティを見て」とだけ頼むと、浅い一般論で終わりやすくなります。監査とは、脅威、資産、範囲、証跡、修正責任をそろえて、リスクを説明できる状態にする作業です。Claude Codeは判断を補助できますが、事業上の許容リスクや公開してはいけない攻撃手順を決めるのは人間です。

この記事では、Claude Codeを使って実務に耐えるセキュリティ監査を進める型をまとめます。対象はWebアプリ、SaaS、社内管理画面、API、AIが生成したPRです。公式の基準として OWASP Top 10、OWASP ASVS、NIST SSDF、GitHubの secret scanning も参照します。

まずスコープを固定する

最初にやることは、Claude Codeへ「何を見て、何を見ないか」を渡すことです。スコープが曖昧だと、AIは目についたコードだけをなぞり、決済、管理者権限、ログ、ジョブ、外部連携のような重要箇所を落とします。初心者ほど、監査の前に1枚のブリーフを書くほうが結果が安定します。

以下はそのまま貼れる監査ブリーフです。実案件では、対象URL、変更差分、デプロイ期限、触ってよいコマンドも追記します。

# セキュリティ監査ブリーフ

## 目的
- リリース前に重大な認証、権限、秘密情報、入力検証、ログ漏えいの問題を見つける
- 修正案だけでなく、確認した証跡と残リスクを残す

## 対象範囲
- 対象リポジトリ:
- 対象ブランチ/PR:
- 対象機能:
- 触ってよいディレクトリ:
- 触らないディレクトリ:

## 重点観点
- 認証とセッション
- 認可とロール
- 入力検証と出力エスケープ
- シークレットと環境変数
- 依存関係とライセンス
- ログ、PII、監査証跡
- CIで止めるべき条件

## 完了条件
- 発見事項をリスク登録表に記録する
- 再現に必要な最小情報だけを書く
- 危険な攻撃手順や実シークレットは記載しない
- 実行したコマンド、結果、未確認事項を証跡として残す

ブリーフを渡したあと、Claude Codeにはまずコードを読ませます。いきなり修正させるのではなく、「ルート、認証ミドルウェア、外部API、環境変数、ログ出力、CI設定を一覧化して」と依頼します。棚卸しを先に作ると、監査の漏れを人間が指摘しやすくなります。

資産棚卸しと脅威モデル

セキュリティ監査の出発点は「守るもの」を言語化することです。資産とは、ユーザーデータ、決済情報、APIキー、管理画面、監査ログ、学習データ、問い合わせ内容など、漏えい・改ざん・停止すると困るものです。脅威モデルとは、誰が、どの入口から、何を狙うかを考えるための簡単な地図です。

| 資産 | 保存場所 | 入口 | 想定される脅威 | 必須の防御 | 担当 |
| --- | --- | --- | --- | --- | --- |
| ユーザーのメールアドレス | users table | signup, admin | 不正閲覧、ログ漏えい | 認可、PIIマスク、監査ログ | backend |
| 請求ステータス | billing table, Stripe | webhook, admin | 改ざん、二重処理 | 署名検証、冪等性、ロール制御 | backend |
| APIキー | env, secret manager | CI, runtime | リポジトリ流出、ログ出力 | secret scanning、権限分離 | platform |
| 管理画面 | /admin | browser | 一般ユーザーの昇格 | MFA、admin role、操作ログ | product |

この表を作ったら、Claude Codeに「各資産について、入口、信頼境界、検証すべきテストを追加して」と頼みます。信頼境界とは、信用できる領域と信用できない領域の境目です。例として、ブラウザから来る値、Webhook、CSVアップロード、社外APIレスポンスは信用しない前提で扱います。

Claude Codeに見せるレビュー観点

依存関係レビューでは、package.json、lockfile、Dockerfile、GitHub Actions、ランタイムのバージョンを見ます。npm auditの結果だけで判断せず、到達可能性、代替パッケージ、破壊的変更、パッチ適用後のテスト結果をセットで確認します。NIST SSDFの考え方に寄せるなら、修正可能な脆弱性をCIとレビューで継続的に扱う運用が重要です。

認証とセッションでは、ログイン、ログアウト、パスワードリセット、MFA、OAuth、cookie属性、セッション期限、CSRF対策を見ます。特に「ログインしているか」と「その操作をしてよいか」は別です。管理者用API、他ユーザーのIDを受け取るAPI、Webhook再処理、ファイルダウンロードは、認可漏れが出やすい場所です。

シークレットレビューでは、.env、CI secrets、ログ、README、サンプル設定、テストデータを確認します。Claude Codeに実シークレットをチャットへ貼らせてはいけません。見つけた場合は値を伏せ、場所、種類、ローテーション要否だけを記録します。GitHubを使っているなら、secret scanningを有効にし、push protectionの運用も確認します。

入力検証では、フォーム、API body、query string、ファイル名、CSV、Markdown、HTML、Webhook payloadを見ます。SQLインジェクションやXSSのような名前だけを並べるより、「どの入力がどの出力に流れるか」を追うほうが現実的です。Claude Codeには危険な実攻撃文字列を書かせず、バリデーション、正規化、エスケープ、型チェック、テストケースを提案させます。

ログとPIIでは、メールアドレス、氏名、住所、トークン、cookie、認証ヘッダー、決済ID、問い合わせ本文が出ていないかを見ます。開発時のconsole.logが本番ログに残ると、あとから監査で困ります。ログは「障害調査に必要な最小情報」と「残してはいけない情報」を分けて設計します。

実務で使う4つのユースケース

1つ目は、リリース前のSaaS監査です。新しい課金、招待、管理者機能を出す前に、Claude CodeへPR差分、ルート一覧、DB migration、Webhook、テストを読ませます。完璧な診断を期待するのではなく、リリース判定会議で話せるリスク表を作るのが目的です。

2つ目は、GitHubリポジトリの引き継ぎ監査です。前任者から渡されたリポジトリでは、READMEよりもCI、secret、deploy script、環境変数、権限設定が重要です。Claude Codeに「初回引き継ぎで人間が確認すべき順番」を出させると、属人化した危険箇所を早く見つけられます。

3つ目は、インシデント後のフォローアップ監査です。障害や漏えい疑いのあとに、原因箇所だけを直して終わると再発します。Claude Codeには、類似箇所の検索、ログのPII確認、再発防止テスト、CIゲート、運用手順の更新まで洗い出させます。公開レポートを書く場合は、攻撃の詳細を広げすぎない配慮も必要です。

4つ目は、AI生成PRのセキュリティレビューです。AIが生成したコードは見た目が整っていても、認可、ログ、入力検証、エラー処理が薄いことがあります。通常のコードレビューに加えて、Claude Codeへ「この差分が攻撃面、権限、秘密情報、個人情報、CIに与える影響だけを見て」と狭く依頼すると、レビューの精度が上がります。

リスク登録表と証跡を残す

発見事項は、重要度だけでなく、根拠、影響、修正方針、確認結果を残します。AIの出力は流れやすいので、監査の最後にこの表へ集約するのが大事です。

| ID | リスク | 影響 | 根拠 | 推奨対応 | 優先度 | 状態 | 担当 |
| --- | --- | --- | --- | --- | --- | --- | --- |
| SEC-001 | 管理APIの認可確認が不足 | 他ユーザー情報の変更 | routes/admin.tsでrole確認なし | middleware追加とテスト | High | Open | backend |
| SEC-002 | Webhookログにメールが出る | PIIの不要保存 | logs/webhook-sample.txt | マスク処理とログ保持期間見直し | Medium | Open | platform |

証跡レシートは、監査を「やったつもり」で終わらせないための短い記録です。何を見たか、何を見ていないか、どのコマンドが通ったかを残すことで、後日のレビューと説明が楽になります。

# セキュリティ監査 証跡レシート

- 対象:
- 日付:
- 監査担当:
- Claude Codeに渡した範囲:
- 実行したコマンド:
- 確認したファイル/ディレクトリ:
- 発見した高リスク項目:
- 修正済み項目:
- 未確認/対象外:
- 人間レビューが必要な判断:
- リリース可否:

PRレビュー用チェックリスト

PRで使う場合は、毎回同じ観点を短く貼れる形にしておくと便利です。特にAI生成PRは、実装量が多く見えても、テストやログ方針が抜けていることがあります。

## Security PR Review

- [ ] Scope is clear and no unrelated files are changed
- [ ] Authenticated users cannot access another user's data
- [ ] Admin or billing actions require explicit authorization
- [ ] Inputs are validated at the boundary
- [ ] Outputs are escaped or rendered safely
- [ ] No secrets, tokens, cookies, or PII are printed to logs
- [ ] Dependency changes have a reason and test evidence
- [ ] Errors do not reveal internals
- [ ] CI includes lint, tests, typecheck, and security-relevant checks
- [ ] Risk register and evidence receipt are updated

コマンドチェックリスト

プロジェクトごとにコマンドは違いますが、最初の監査では次のような確認から始めます。Claude Codeには「実行前にコマンドの目的を説明し、失敗したら止まって原因を要約して」と伝えると安全です。

git status --short
npm ci
npm audit --audit-level=moderate
npm run lint
npm run typecheck
npm test
rg -n "TODO|FIXME|console\\.log|process\\.env|localStorage|innerHTML|dangerouslySetInnerHTML" src
git diff --check

rgで見つかった行は、すべてが脆弱性ではありません。process.envは正しい使い方でも出ますし、innerHTMLもサニタイズ済みなら許容される場合があります。Claude Codeには「危険と断定せず、根拠、前提、確認方法を分けて」と指示します。

よくある失敗と落とし穴

一番多い失敗は、AIに「セキュリティをチェックして」とだけ頼むことです。対象範囲、資産、変更差分、完了条件がないため、見た目のよい一般論が返ってきます。監査では、曖昧な安心感より、未確認事項が明記されたレポートのほうが価値があります。

次の失敗は、証跡を残さないことです。どのコマンドを実行したのか、どのファイルを見たのか、どこは対象外だったのかがないと、リリース前の判断に使えません。Claude Codeの回答をそのまま信用するのではなく、CI結果、テスト、差分、ログ、設定ファイルへ戻って確認します。

危険な失敗として、公開記事やIssueに攻撃手順を詳しく書きすぎることがあります。教育目的でも、再現に不要な攻撃文字列、実URL、実トークン、顧客データは出しません。発見事項は、影響と修正方針を中心に書き、詳細は権限のある場所へ分離します。

また、シークレットとログを軽く見ないことも重要です。コード本体に脆弱性がなくても、CIログ、デバッグログ、スクリーンショット、サンプル.envから漏れることがあります。最後に、高リスクな認証、決済、個人情報、管理画面の変更は、AIレビューだけで通さず、人間のレビューを必須にします。

CIゲートと社内運用に組み込む

監査を1回のイベントで終わらせると、次のPRで同じ問題が戻ります。最低限、lint、typecheck、test、dependency audit、secret scanning、ログ禁止ルール、危険APIの検索をCIに入れます。すべてをブロッキングにすると開発が止まるため、Highだけブロック、Mediumは期限付きチケット化、Lowは定期棚卸しに回すなど、運用ルールを決めます。

Claude Codeの権限設計は Claude Code権限ガイド と合わせて見直すと安全です。シークレットの扱いは Claude Codeシークレット管理、失敗例は Claude Codeセキュリティ失敗事例、レビュー運用は Claude Codeコードレビュー も参考になります。チームで監査ブリーフ、CIゲート、レビュー基準を整えたい場合は Claude Code研修・導入相談 で既存リポジトリを前提に相談できます。

まとめ

Claude Codeでセキュリティ監査を実務化するコツは、AIに答えを丸投げしないことです。スコープ、資産、脅威モデル、レビュー観点、証跡、CIゲートを先に決めると、Claude Codeは強力な調査役になります。逆に、範囲なし、証跡なし、人間レビューなしの監査は、きれいなレポートが残っても安全性の説明には使えません。

この記事で紹介した内容をMasaが実際にClaudeCodeLabの公開前レビューに当てはめた結果、効果が大きかったのは「リスク登録表」と「証跡レシート」でした。Claude Codeにルート、ログ、環境変数、CIを棚卸しさせてから人間が確認すると、単なる脆弱性探しよりも、リリース判断に必要な未確認事項が見えやすくなりました。