「セキュリティ観点のレビュー、後回しにしてませんか」

機能は動く。テストも通る。レビューも「ロジックは合ってそう」でApprove。
…でも、その差分にこんなものが混ざっていないと言い切れますか。

ユーザー入力をそのままSQL文字列に連結している
管理者向けエンドポイントに権限チェックを足し忘れている
デバッグ中に書いたAPIキーがコミットに残っている
新しく入れた依存パッケージに既知のCVEがある

機能のバグはテストやレビューで気づきやすい一方、セキュリティの欠陥は「動いてしまう」ぶん見逃されがちです。専任のセキュリティレビュアーがいない個人開発・小規模チームほど、ここがすっぽり抜けます。

Claude Code には、この「セキュリティ観点のセルフ点検」を毎回の作業に組み込むための機能が用意されています。この記事では、公式ドキュメントで確認できる機能だけを使い、PR前のセルフ点検フローとして定着させる方法をまとめます。

本記事の機能仕様は Claude Code 公式ドキュメント（security / security-guidance / commands / permissions）で確認した内容に基づきます。バージョンや今後の更新で挙動が変わる可能性があるため、最終的には自分の環境の /help と公式ドキュメントで確認してください。

Claude Code のセキュリティレビューは「3つの層」で考える

Claude Code でコードのセキュリティを見る手段は、タイミングごとに分かれています。役割を混同しないことが大事です。

タイミング	手段	何を見るか
コードを書いている最中	security-guidance プラグイン	Claude 自身が書いた差分を自動レビューし、その場で直す
区切りで手動実行	`/security-review`	現在のブランチの保留中の変更を一回スキャン
PR時	Code Review（Team / Enterprise プラン）	コードベース全体の文脈込みで多エージェントレビュー
CI	既存の静的解析・依存スキャナ	言語固有ルール・サプライチェーン・ポリシー

公式ドキュメントでも、これらは「多層防御（defense in depth）」の各層と位置づけられています。どれか1つで完結はしません。本記事は、個人・小規模で今日から使える /security-review と security-guidance プラグイン を中心に扱います。

まず使う：`/security-review`

/security-review は、Claude Code に組み込まれているコマンドです。公式ドキュメントの説明はこうです。

Analyze pending changes on the current branch for security vulnerabilities. Reviews the git diff and identifies risks like injection, auth issues, and data exposure
（現在のブランチの保留中の変更をセキュリティ脆弱性の観点で分析する。git diff をレビューし、インジェクション・認証関連の問題・データ露出などのリスクを特定する）

つまり、今のブランチの差分（git diff）に絞った、読み取り専用のセキュリティ点検です。コミット前・PRを出す前に走らせる用途に向いています。

使い方はシンプルで、セッション内で次を打つだけです。

/security-review

ポイント:

差分ベースなので、巨大なコードベース全体ではなく「今回触ったところ」に集中して見てくれる
レビュー系コマンドなので、勝手にコードを書き換えるのが主目的ではない（修正は内容を確認してから依頼する）
git の状態を見るため、git リポジトリ内で実行する前提

/review も同様に差分の読み取り専用パスを提供しますが、/security-review は名前のとおりセキュリティ観点に寄せたものです。

「Claude が書いた端からチェックさせる」：security-guidance プラグイン

/security-review が「区切りで手動実行」なのに対し、書いている最中に自動でチェックさせるのが security-guidance プラグインです。インストールすると自動で動き、呼び出すコマンドはありません。

公式ドキュメントによると、前提は以下です。

Claude Code CLI 2.1.144 以降
PATH 上に Python 3.8 以降
作業ディレクトリが git リポジトリであること（差分を取るため）

インストールは公式マーケットプレイスから。

/plugin install security-guidance@claude-plugins-official

マーケットプレイスが見つからないと言われたら、先に登録してから再実行します。

/plugin marketplace add anthropics/claude-plugins-official

その後、現在のセッションに反映するには /reload-plugins を実行します。クラウドセッションやチーム共有では、プロジェクトの .claude/settings.json に書いて配布できます。

{
  "enabledPlugins": {
    "security-guidance@claude-plugins-official": true
  }
}

このプラグインは 3段階でチェックします（公式ドキュメント記載）。

ファイル編集ごと：危険なパターンの高速な文字列マッチ（モデル呼び出しなし＝コストゼロ）
ターンの終わりごと：そのターンで変わった差分をバックグラウンドでモデルレビュー
Claude がコミット/プッシュするたび：周辺コードまで読むより深いエージェント的レビュー

1で見ているパターンの例（公式ドキュメントより）:

動的コード実行：eval(、new Function、os.system、child_process.exec
安全でないデシリアライズ：pickle
DOM インジェクション：dangerouslySetInnerHTML、.innerHTML =、document.write
ワークフローファイル：.github/workflows/ 配下の編集（リポジトリ権限を与えうるため）

2・3で見ているもの（文字列マッチでは拾えない種類）:

認可バイパス（authorization bypass）
安全でない直接オブジェクト参照（IDOR）
インジェクション
SSRF（サーバサイドリクエストフォージェリ）
弱い暗号

重要な注意：このプラグインのモデルレビューは追加のモデル利用としてコストに計上されます（編集ごとのパターンマッチは無料）。また、書き込みやコミットをブロックはしません。指摘は Claude への指示として渡り、Claude が会話の中で対処します。あくまで多層防御の1層であり、これだけで安全になるわけではありません。

レビューにのせるべき「観点チェックリスト」

/security-review や、後述の「自分でレビューを依頼する」手順で、Claude に見てほしい観点を言語化しておくと精度が安定します。差分レビューで毎回見てほしい代表的な観点を、Claude Code 公式が脆弱性カテゴリとして挙げているものを軸に整理しました。

インジェクション：SQL / OS コマンド / テンプレート / NoSQL。ユーザー入力が文字列連結でクエリやコマンドに入っていないか。パラメータ化されているか
認証・認可：新しいエンドポイント / 操作に権限チェックがあるか。他人のリソースIDを渡して触れてしまわないか（IDOR）
機密情報のハードコード：APIキー・トークン・パスワード・接続文字列が直書きされていないか。環境変数 / シークレットマネージャ経由か
安全でないデフォルト：CORS が *、デバッグモードON、検証スキップ、平文通信、過剰な権限などが既定値で混ざっていないか
依存の既知脆弱性：今回追加・更新したパッケージにCVEがないか（最終確認は専用スキャナ。Claude には「怪しい依存追加がないか」をレビュー観点として渡す）
データ露出：ログやレスポンスに個人情報・トークン・スタックトレースが漏れていないか
弱い暗号 / 比較：MD5やSHA1での認証、トークンの === 比較（タイミング攻撃）など

重大度（Severity）を付けて出させる

「気になる点がいくつかあります」では動けません。重大度と修正案をセットで出させると、対応の優先順位が即決まります。/security-review の後や、差分を直接レビュー依頼するときに、出力フォーマットを指定します。

依頼プロンプトの例:

この差分をセキュリティ観点でレビューしてください。
インジェクション / 認証・認可 / 機密情報のハードコード /
安全でないデフォルト / 依存の既知脆弱性 を重点的に見てください。

各指摘は次の形式で:
- 重大度: Critical / High / Medium / Low
- 箇所: ファイル:行
- 何が問題か（1〜2文）
- 攻撃シナリオ（あれば）
- 推奨修正（コード断片）

最後に Critical/High 件数のサマリを付けてください。
推測の指摘には「未確認」と明記してください。

出力イメージ（Before/After）:

Before（フォーマット指定なし）

いくつか気になる点があります。ユーザー入力の扱いや認可周りを確認したほうがよさそうです。

→ 何から直せばいいか分からない。

After（重大度フォーマット指定あり）

[Critical] src/db/users.py:42
 ユーザー入力 name を SQL に文字列連結（SQLインジェクション）
 修正: パラメータ化クエリ cursor.execute(sql, (name,)) に変更

[High] src/api/admin.py:18
 /admin/delete に権限チェックなし。任意ユーザーが削除可能
 修正: ハンドラ冒頭で require_role("admin") を呼ぶ

[Low] src/config.py:7
 CORS allow_origins=["*"]。本番では発行元を限定推奨

サマリ: Critical 1 / High 1 / Medium 0 / Low 1

→ 上から潰せばいい。レビューが「タスク」になります。

注意：AI の指摘には**誤検知（false positive）も見逃し（false negative）**もあります。「Critical と言われたから直す」ではなく、自分で該当箇所を読んで裏を取ること。判断を AI に丸投げしないのが安全側です。

PR前のセルフ点検フロー（コピペで習慣化）

毎回ゼロから考えないために、ブランチを上げる前の定型フローにしてしまいます。

1. 機能ブランチで実装・テストが通る状態にする
2. /security-review を実行（差分のセキュリティ点検）
   └ Critical/High が出たら、自分で該当行を確認 → 修正を依頼 → 再度 /security-review
3. 上のチェックリスト観点で気になる箇所を追加レビュー依頼
4. 機密情報の混入を確認（git diff に鍵・トークンがないか目視 + 後述の deny ルール）
5. 依存を追加した回は、専用スキャナ（npm audit / pip-audit 等）も併走
6. クリーンになってから PR を作成

security-guidance プラグインを入れている場合は、1〜2の「書いている最中」の取りこぼしを自動で減らしてくれるので、/security-review で残りを拾う、という二段構えになります。

CLAUDE.md に方針を1行書いておくと、毎回プロンプトに貼らずに済みます（CLAUDE.md は「やろうとすること」を形成するもので、強制ではない点に注意）。

## セキュリティ
- PRを出す前に /security-review を実行する
- 重大度(Critical/High/Medium/Low)を付けて報告する
- 機密情報の直書き・認可漏れ・インジェクションを最優先で見る

機密情報を「読ませない・出させない」

セキュリティ点検をさせるつもりが、逆に .env や鍵ファイルを Claude に読ませてしまっては本末転倒です。Claude Code の**権限（permissions）**で、読み取り自体を拒否できます。

permissions.deny に Read ルールを書くと、Claude の組み込みファイルツール（および cat / head / tail / sed など Claude Code が認識する Bash のファイル操作）からのアクセスをブロックできます。.claude/settings.json の例:

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

仕様の要点（公式ドキュメント）:

Read / Edit ルールは gitignore のパターン仕様に従う。Read(.env) は Read(**/.env) と等価で、配下のどの階層の .env にもマッチする
パターンのアンカーに注意：/path はプロジェクトルート相対、./path や path はカレント相対、//path が絶対パス、~/path がホーム相対
評価順は deny → ask → allow。一度 deny にマッチしたら、他のスコープの allow では上書きできない（deny が常に勝つ）

ただし、ここには限界があります。公式ドキュメントが明記しているとおり、Read/Edit の deny ルールは「Python や Node のスクリプトがファイルを開く」ような任意のサブプロセスには効きません。OS レベルで全プロセスからのアクセスを止めたい場合はサンドボックスを併用します。

さらに、うっかり防止の基本動作も押さえておきましょう。

Claude Code は既定で読み取り専用権限。ファイル編集や Bash 実行は明示承認が必要
書き込みは起動ディレクトリとその配下に限定される（親ディレクトリは明示許可なしには変更不可）
curl / wget などネットワーク取得系は既定で自動承認されない

これらを踏まえ、機密ファイルは deny で読ませない・コミット前に diff を目視・シークレットは環境変数/シークレットマネージャに置く、を基本線にします。

やりがちな失敗と対策

失敗	なぜ危ないか	対策
レビューをコードベース全体に依頼	文脈が薄まり指摘が雑になる/コスト増	`/security-review` で差分に絞る
AIの「Critical」を鵜呑みで修正	誤検知・見当違いの修正混入	該当行を自分で読んで裏取り
機密ファイルを deny せず作業	鍵を読ませる/出力に漏れる	`permissions.deny` の Read ルール
プラグインだけで安心	ブロックはしない・見逃しあり	`/security-review`＋専用スキャナ＋人の目
依存追加回にスキャンなし	既知CVEを取り込む	`npm audit` / `pip-audit` 等を併走

まとめ

Claude Code のセキュリティ点検は 「書いている最中（プラグイン）」「区切りで手動（/security-review）」「PR時（Code Review）」 の多層で考える
/security-review は現在のブランチの差分を、インジェクション・認証/認可・データ露出などの観点でスキャンする組み込みコマンド
security-guidance プラグイン（CLI 2.1.144以降・Python 3.8以降・gitリポジトリ）は、書いている端から自動でチェックする。ただしブロックはしない
指摘は重大度（Critical/High/Medium/Low）＋修正案で出させ、自分で裏を取る
機密情報は permissions.deny の Read ルールで読ませない。ただしサブプロセスには効かないので、必要ならサンドボックス併用
どれも単体では完結しない。多層防御として組み合わせ、PR前のセルフ点検を「毎回の定型作業」にするのが狙い

セキュリティレビューは、才能ではなく習慣です。/security-review を打つ1行を、PRを出す前のルーティンに足すところから始めてみてください。

無料リポで関連スキルも配布中（CC BY 4.0）

本記事で紹介した手順はそのままコピペして使えます。あわせて無料リポ claude-code-skills-starter では、実用スキル4本（claude-md-architecture / piv-development-loop / ai-commit-strategy / agile-prompt-template）＋ CLAUDE.md テンプレート＋ pre-commit hook を配布しています。

リポを開く → https://github.com/noguso245-jpg/claude-code-skills-starter
skills/ja/ の該当スキル .md をコピーして自分のプロジェクトで使う
役立ったら ⭐ Star を（同じように探している人に見つけてもらいやすくなります。更新を追うなら Watch）