Claude Codeのセキュリティレビュー：ステップバイステップガイドと2026年版GitHub Action自動化

元の資料の著者は、自身の経験をこう述べています。「自分のvibeプロジェクトでsecurity-reviewを実行したところ、チームが4分で実際の問題をいくつか見つけ、すでに修正できました。」これは以前、外部コンサルタントに1日かかっていた作業です。

ツールの設定に関する追加資料は、Ailootのドキュメントにあります。

Claude Codeの/security-reviewとは？#

このコマンドには2つの実行モードがあります。ローカルでは、ターミナルで/security-reviewを実行すると、Claudeがリポジトリを読み込んでレポートを作成します。サーバー側では、同じエンジンをGitHub Actionとして設定し、すべてのPull Requestに自動でインラインコメントを付けられます。

従来のSASTスキャナー（Snyk Code、Semgrep、SonarQube）と異なり、/security-reviewは固定ルールに基づいて動作しません。実際のエンジニアのようにコードを読みます。データフローを追跡し、使用しているフレームワークや信頼境界の場所を理解して、ルールでは記述されていない脆弱性を検出します。

これは、/security-reviewが外部のペネトレーションテストやステージング環境での実地テストに取って代わるという意味ではありません。初期コードレビューの一部を自動化できますが、この記事では監査の網羅率は測っていません。以下では、正しい実行方法と、Claudeがプロジェクト内で見つけるものを説明します。

/security-reviewを5つのステップで実行するには？#

ステップ1. Claude Codeを更新します。 このコマンドは、2026年2月20日付のリリース以降で利用できます。

claude update

Claude Codeをnpm経由でインストールした場合は、次の方法でも更新できます。

npm install -g @anthropic-ai/claude-code@latest

/security-reviewが表示されていることを確認します。

claude /help | grep security

ステップ2. プロジェクトを開き、Claude Codeにサインインします。

cd ~/projects/my-vibe-project
claude

ステップ3. コマンドを実行します。 Claude Code内で、次を入力するだけです。

/security-review

Claudeは自動的に3段階の分析を行います。

1. リポジトリのコンテキスト調査 - 構造を読み取り、スタック、ルート、データベースクエリを特定します。
2. 比較分析 - 現状を、このスタックで一般的な脆弱性パターンと比較します。
3. 脆弱性評価 - 確信度を1〜10で示し、疑わしい点をすべて列挙します。確信度が8以上の検出結果のみがレポートに含まれます。

ステップ4. レポートを読みます。 出力はMarkdownの表形式です。Claudeは各問題について、次の情報を提示します。

• ファイルと行番号（例：src/auth/login.ts:42）
• 重大度（HIGH / MEDIUM / LOW）
• カテゴリ（sql_injection、xss、auth_bypass、insecure_storage）
• 説明 - 何が問題なのか
• 悪用シナリオ - 攻撃者がどう利用できるか
• 推奨事項 - 修正方法

ステップ5. 修正を適用するよう依頼します。 その後は、通常のエージェントのように作業できます。

「レポートにあるHIGHの修正を、PRの説明文を添えて1つずつ適用してください。」

Claudeは各ファイルを開いて変更案を提示し、あなたが確認します。実際のプロジェクトでは、予定していた3時間ではなく40分で5件の検出結果を解消しました。

/security-reviewはどのような脆弱性を見つけますか？#

デフォルトで分析対象に含まれる項目の全リストは、Anthropicの公式ドキュメントに記載されています。

さらに、このコマンドは自動スキャナーではほとんど扱われないカテゴリも対象にします。

• コマンドインジェクション - シェルでユーザー入力を実行する（child_process.exec(userInput)）
• パストラバーサル - ../../etc/passwdを使ってファイルを読み込む
• XXE - 外部エンティティを含むXML
• テンプレートインジェクション - Jinja/Handlebars/EJSでのSSTI
• NoSQLインジェクション - MongoDBクエリ内の$ne、$gt演算子
• 暗号処理の誤用 - MD5、ECBモード、固定IVの使用

Claudeは各検出結果に重大度を付けます。基準はシンプルです。

• HIGH - 認証なしのリモート悪用、全ユーザーに影響するデータ漏えい
• MEDIUM - 追加条件を伴う悪用（セッションが必要／特定の入力が必要）
• LOW - 潜在的な攻撃経路。現時点では重大ではありませんが、修正する価値があります

知っておくと便利な点として、標準設定ではClaudeはDoS、レート制限、メモリ枯渇、影響が証明されていないオープンリダイレクト、正規表現インジェクション／ReDoS、ログのなりすましを報告しません。ノイズが増えないよう、意図的にそうなっています。これらのカテゴリが重要なら、ルールを拡張してください（誤検知を除外する以下のセクションを参照）。

自動レビュー用GitHub Actionを設定するには？#

ステップ1. APIキーを取得します。 console.anthropic.comにアクセスし、APIキーを作成してコピーします。

ステップ2. リポジトリのシークレットにキーを登録します。 GitHubで、Settings → Secrets and variables → Actions → New repository secretを開きます。名前をCLAUDE_API_KEYにし、値にキーを設定します。

ステップ3. ワークフローファイルを作成します。 .github/workflows/security.ymlとして保存します。

name: Security Review

permissions:
  pull-requests: write
  contents: read

on:
  pull_request:

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha || github.sha }}
          fetch-depth: 2

      - uses: anthropics/claude-code-security-review@main
        with:
          comment-pr: true
          claude-api-key: ${{ secrets.CLAUDE_API_KEY }}

ステップ4. ブランチをmainにマージします。 次のPRからActionが自動的に実行されます。

Actionの動作:

• オープン中のPull Requestまたは同期のたびに実行されます。
• PRブランチとmainの差分を取得します。
• ローカルの/security-reviewと同じエンジンを実行します。
• 疑わしい箇所があるコード行にインラインコメントを直接投稿します。
• 完全なレポートをJob Summaryにも複製します。

permissionsの重要な詳細:

• pull-requests: write - インラインコメントの投稿に必要です。
• contents: read - コードの読み取りに必要です。writeはありません。Actionはコード自体を変更せず、レポートのみを作成します。

この権限設定でプライベートリポジトリには十分です。パブリックリポジトリで再利用可能なワークフローを使う場合は、actions: readを追加で指定できます。

誤検知を除外し、感度を変更するには？#

GitHub Actionの入力項目の全表（出典：リポジトリのREADME）：

誤検知フィルタリングの設定例。 .claude/security/false-positives.mdファイルを作成します。

# このプロジェクト向けの誤検知フィルタリングルール

- `src/lib/email/layout.ts` 内の `dangerouslySetInnerHTML` は安全です。
  HTMLは信頼できるテンプレートから組み立てられ、レンダリング時ではなく
  データベースへの書き込み時に `sanitize-html` を通ります。
- `__tests__/fixtures/*.ts` にあるハードコードされたテスト用APIキーは報告しないでください。
  すべてのキーは `sk-test-fake-` で始まります。
- `src/lib/admin/migrations.ts` 内のSQL文字列連結は許容されます。このファイルは
  rootとしてのみ実行され、入力データは環境変数から取得されます。

ワークフローでこのファイルを指定します。

- uses: anthropics/claude-code-security-review@main
  with:
    comment-pr: true
    claude-api-key: ${{ secrets.CLAUDE_API_KEY }}
    false-positive-filtering-instructions: .claude/security/false-positives.md

カスタムセキュリティスキャンの指示も同様です。プロジェクト固有の重要なルールを記載したファイルを作成します。

# このプロジェクト向けの追加チェック

- `/api/admin/*` 配下のすべてのエンドポイントでは、共有ラッパーを通じて
  管理者ロールを確認する必要があります。このラッパーがなければ、重大度はHIGHです。
- すべてのYooKassa / CloudPaymentsウェブフックでは、本文を解析する前に
  署名を検証する必要があります。これがなければ、重大度はHIGHです。
- マジックリンクのトークンは1回限りでなければなりません（最初の有効なリクエストの後に
  使用済みとして記録します）。再利用可能なトークンの重大度はMEDIUMです。

これはもはやAnthropicのプリセットではありません。Claudeが毎回適用するルールとして、プロジェクトに関する専門知識を移し替えるものです。これこそが「モデルより方法論」の本質です。

Claudeのコンテキスト手法について詳しくは、「CLAUDE.mdの設定方法」と「Claude CodeのSecond Brain」のガイドをご覧ください。

Claudeは何を検出できないのか、またその理由は？ 制限事項を率直に説明#

Anthropicは、デフォルトで無効になっている項目とその理由を明確に記載しています（出典：リポジトリのREADME）。

• サービス拒否 - ノイズが多く、ほとんどの場合影響が小さいため。
• レート制限に関する懸念 - コードではなく、インフラストラクチャ層で対処するため。
• メモリ／CPUの枯渇 - 同様です。
• 影響が証明されていない一般的な入力検証 - すべてのフィールドを検証すると、誤検知が大量に発生するため。
• オープンリダイレクト - 多くの場合、意図された動作であるため。

実行時や配備の証拠なしでは、コードレビューだけで十分に検証できないもの：

• 本番サーバーの設定。 NGINXヘッダー、CORSポリシー、TLS設定、リスニングポート。これらはステージング環境で手動確認する必要があります。
• 競合状態。 たとえば、返金リクエストが同時に行われた際の二重払いです。静的解析で疑わしいパターンを示せても、同時実行の挙動はテストが必要です。
• 決済のビジネスロジックの欠陥。 注文合計をクライアント側で計算して、そのまま決済事業者に送信する場合、重大度はHIGHです。しかし、決済の想定動作について明示的なコンテキストがないと、Claudeはこのパターンを常に検出できるとは限りません。
• データベースレベルのIDOR。 クエリSELECT * FROM orders WHERE id = $1にWHERE user_id = $session.userIdによる確認がない場合、Claudeはしばしば検出します。しかし、ORMミドルウェアで確認を実装していて、Claudeがデータフロー全体を追えない場合は見逃すことがあります。
• ソーシャルエンジニアリング／フィッシングへの耐性。 コードとは関係ありません。

/security-reviewを初期の静的レビューとして使い、ステージングでの動作、ロールと権限、適切なSAST、実際の配備設定の確認を続けます。測定された網羅率はありません。

外部評価の範囲と時期はシステムのリスクと変更から決めます。1コマンドも定期監査も、100%の安全網羅を証明しません。

元の資料の著者はvibeプロジェクトのセキュリティレビューをどう実行したか#

結果はどうだったか。平均的なvibeプロジェクトが「本番環境で動いているが、レビューはされていない」段階にあるときによく見られる状況でした。認証フロー、決済連携のウェブフック処理ロジック、ファイルアップロード処理に関する疑いがいくつかあり、レンダリング時のHTML処理についても具体的な指摘が2件ほどありました。詳細は公開しません。一部の推奨事項はすでに適用し、残りはまだPRにあります。この報告プロジェクトでは初期走査が速く有用でしたが、監査の網羅率や一般的な完了時間は示しません。

誤検知として除外したもの：

• 入力検証の正規表現によるDoSの検出結果 - 実際の負荷はその正規表現にかかりません。
• ハードコードされたAPIキーに関する検出結果が1件 - フィクスチャ内の、明示的にfake-接頭辞が付いたテスト用キーでした。

所要時間。実行自体は4分でした。レポートの確認に25分かかりました。テストを含む修正の適用には約1時間かかりました。合計では、「開始」から「すべてmainに入る」まで約1時間半です。同じ範囲の外部ペネトレーションテストには、暦日で1週間かかり、何十倍もの費用がかかります。

主なポイント。/security-reviewは外部のペネトレーションテストに取って代わるものではありません。筆者の4分の走査のように、有用なコード上の問題を見つける場合があります。修正を確認・テストし、実行時と配備設定は別に検証します。走査でプロジェクトの安全上のリスクがなくなるわけではありません。

/security-reviewをコミット前のルーチンに組み込むには？#

以前のgit_commit、--severity HIGH、--fail-on-findを使うフックは、文書化・動作確認した手順ではなく、安全ゲートに使わないでください。この記事に検証済みのローカル阻止フックはありません。上の公式ActionはPRへ指摘しますが、コメント投稿だけでコミット・マージを止めるとはいえません。

フックの詳しい説明は、「Claude Codeのフック」ガイドにあります。

ルーチンを使う方法もあります。/security-review + npm run build + npm run testを1つのコマンドで実行するpre-deploy-checkルーチンを作成します。追加資料はAilootのドキュメントにあります。

MCPサーバーを使っている場合は、/security-reviewの検出結果をインシデント管理システム（Sentry、Linear、Notion）と連携し、HIGHの検出結果が自動的にチケットになるようにできます。

/security-reviewに関するFAQ#

1回の実行にいくらかかりますか？ プロジェクトの規模によります。私の3万行のプロジェクトでは、1回の実行でAPI残高を約$0.30〜0.50使います。100万行の大規模なエンタープライズリポジトリでは、1回あたり最大$5〜8かかります。どのSaaSスキャナーのサブスクリプションよりも何十倍も安価です。

ローカルではどのくらいの頻度で実行すればよいですか？ 最低でも本番リリースの前に毎回実行します。重要なコミットやPRの前にも検討してください。この記事では自動的なコミット阻止フックを検証していません。

どのスタックに対応していますか？ Claudeが読めるものならどれでも対応します。著者の観察によると、これまでに確認したのはNext.js / Node.js、Python（Django、FastAPI）、Go、Rust、PHP（Laravel）、Ruby on Railsです。非常に珍しい言語（Erlang、Elixir、Clojure）では品質が低くなりますが、何かしら見つけてくれます。

実際には脆弱性ではないのに、Claudeが毎回同じ「脆弱性」を見つける場合はどうすればよいですか？ 「なぜ安全なのか」の説明を添えて、false-positive-filtering-instructionsに追加します。以後の実行ではClaudeが報告しなくなります。

特定のファイルだけを対象にできますか？ ローカルなら可能です。/security-review src/lib/auth/*.tsを実行するだけです。GitHub Actionでは現在のPRの差分だけがチェックされます。通常、「特定のファイル」とはこれを指します。

出典#

追加資料はAilootのドキュメントにあります。