Claude Code Security Review(claude code security review)は、AnthropicがGitHub Actions向けに公式配布する、AIコードレビュー セキュリティに特化したActionだ。Claude Code GitHub Actionの1機能として、PR作成のたびに自動でセキュリティ診断を行う。

Claude Code全体の使い方・設定・内部アーキテクチャは Claude Code|2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引き を参照してください。本記事はその中の1機能、Claude Code GitHub Action版のセキュリティレビューを単体で深掘りします。

Claude Codeには2つのセキュリティレビュー手段がある。ターミナルで対話的に実行する/security-reviewスラッシュコマンドと、PR作成時に自動で走るclaude-code-security-review GitHub Actionだ。後者は当サイト内でも「Claude Code Routines」記事の比較表で1行触れられているだけで、単体で深掘りした日本語記事はまだ無い。本記事はAnthropic公式リポジトリのREADME.mdaction.ymlを一次ソースに、GitHub Action版だけに絞って導入手順・検出カテゴリ・誤検知フィルタリングの仕組みを実測する。

claude-code-security-reviewの処理フロー。PR作成からcheckout、Claudeによる差分解析、誤検知フィルタリング、PRコメント投稿までの5段階
claude-code-security-reviewの処理フロー(出典: anthropics/claude-code-security-review の action.yml を実測して図解)
30秒でわかる claude code security review(2026年9月時点)
  • 正体:Anthropic公式のGitHub Action。PR作成時にClaudeがコード差分を解析し脆弱性をPRコメントで指摘する
  • 実測:⭐5,912・🍴642(2026-08-18時点)・MIT・リリースタグ運用は0本
  • 何ができる:インジェクション・認証不備・秘密情報のハードコード・RCEなど10カテゴリの脆弱性を検出し、重大度と修正提案つきでコメント
  • 何を代替できる:人力の初期セキュリティレビューの一次スクリーニング。従来SASTの完全な代替ではない(誤検知の質が違うだけ)
  • 注意:最終コミットは2026-02-11で本稿執筆時点(9/16)で約7ヶ月更新なし。プロンプトインジェクション対策済みではなく「信頼できるPRのみ」が公式の前提

Claude Code Security Reviewとは:/security-reviewとの違い

anthropics/claude-code-security-reviewは、GitHub Actionsのワークフロー内でClaudeにセキュリティレビューをさせるための複合Action(composite action)だ。READMEは目的をこう説明する。

“An AI-powered security review GitHub Action using Claude to analyze code changes for security vulnerabilities.”

Claude Codeには元々、CLIで/security-reviewと打てば手元の変更を即座にレビューしてくれるスラッシュコマンドが標準搭載されている。GitHub Action版はこれと同じ解析能力を、PRイベントに対して自動起動する形にパッケージし直したものだ。Anthropic公式Help Centerの記事は両者をこう整理している。

項目 /security-reviewスラッシュコマンド claude-code-security-review GitHub Action
実行タイミング ターミナルでオンデマンド PR作成時に自動
対象プラン Pro/Max/API/Console/Enterprise全プラン 全プラン(API課金)
出力先 CLIセッション内 PRへのインラインコメント
カスタマイズ .claude/commands/security-review.mdを編集 false-positive-filtering-instructions等のinput

CLIコマンドは「今書いているコードをその場で確認したい」ときに向き、GitHub Action版は「チーム全員のPRに漏れなく網をかけたい」場合に向く。両方を併用しても矛盾しない、という位置づけだ。つまりClaude Code セキュリティレビューという機能自体は1つで、入口が2つあると理解するのが正確だ。

なお本Actionは2025年8月6日公開のAnthropic公式ブログ「Automate security reviews with Claude Code」で紹介された機能で、執筆時点(2026年9月)で約1年が経過している。新機能ではなく、公式が継続案内している既存機能の深掘りという位置づけで読んでほしい。

導入手順:Claude Code Security ReviewをGitHub Actionsに追加する

README「Quick Start」に掲載されている構成は次の通り(.github/workflows/security.ymlに配置する)。

name: Security Review

permissions:
  pull-requests: write  # PRコメントを残すために必要
  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 }}

ポイントはclaude-api-keyという入力キーの名前が固定であること。action.ymlを直接読むとrequired: trueと定義されており、これを渡さないとワークフローがエラーで停止する。渡す側のGitHub Secrets名自体は任意で、README公式サンプルはCLAUDE_API_KEYという名前を使っているが、ANTHROPIC_API_KEYという名前で作ったSecretsでも、claude-api-key: ${{ secrets.ANTHROPIC_API_KEY }}と正しく参照していれば同様に動く。当サイトの別記事(Claude Code Routines)はAnthropicのGitHub App Action文脈でANTHROPIC_API_KEYという名前に言及しているが、これは別のActionの話であり、本Actionの入力キー名が変わるわけではない。

action.ymlで確認できるもう一つの注意点
`claude-model`という任意入力のデフォルト値は、README上`claude-opus-4-1-20250805`(Opus 4.1)のままになっている(最終コミット2026-02-11時点のコード)。2026年9月時点でAnthropicの主力モデルはより新しい世代に切り替わっているため、コスト・精度を意識するなら`claude-model`入力で明示的に上書きするのが安全。既定値を鵜呑みにしない。

fork先で実際に動かす前に、入力名を自分の手元で確認したい場合は次のコマンドでaction.ymlの実体を直接読める。

git clone --depth 1 https://github.com/anthropics/claude-code-security-review.git
grep -A3 "claude-api-key:" claude-code-security-review/action.yml
読者の3つの問いへの答え
何ができる:`.github/workflows/`に1ファイル足すだけでPR自動セキュリティレビューが始まる ② 何を解決する:人力レビューが脆弱性を見落とす一次スクリーニングの穴 ③ 何を代替する:レビュアーの初見チェックの一部(最終判断は人間が残す)

検出できる脆弱性カテゴリ全リスト

READMEの「Types of Vulnerabilities Detected」に列挙されているカテゴリは10種類ある。

claude-code-security-reviewが検出する脆弱性カテゴリ6種のアイコン一覧
検出カテゴリの一部(出典: anthropics/claude-code-security-review README「Types of Vulnerabilities Detected」)

インジェクション攻撃:SQL・コマンド・LDAP・XPath・NoSQLインジェクション、XXE
認証・認可の不備:認証破り、権限昇格、安全でない直接オブジェクト参照(IDOR)、バイパスロジック、セッション不備
データ露出:ハードコードされた秘密情報、機密情報のログ出力、情報漏洩、PII取り扱い違反
暗号の不備:弱いアルゴリズム、鍵管理の不適切さ、安全でない乱数生成
入力検証:検証の欠落、不適切なサニタイズ、バッファオーバーフロー
ビジネスロジックの欠陥:レースコンディション、TOCTOU(time-of-check-time-of-use)
設定のセキュリティ:安全でないデフォルト、セキュリティヘッダーの欠落、緩すぎるCORS
サプライチェーン:脆弱な依存関係、タイポスクワッティングのリスク
コード実行:デシリアライズ経由のRCE、pickleインジェクション、evalインジェクション
XSS:反射型・格納型・DOMベースのクロスサイトスクリプティング

パターンマッチではなく「差分をClaudeに読ませて判断させる」方式のため、この一覧は固定ルールセットというよりClaudeが重点的に注意を向けるよう指示されている観点のリストと捉えるのが正確だ。

誤検知フィルタリングの仕組みとカスタマイズ

READMEは「False Positive Filtering」として、デフォルトで次を除外すると明記している。

・サービス拒否(DoS)系の指摘
・レート制限に関する指摘
・メモリ/CPU枯渇系の指摘
・実害が証明されていない汎用的な入力検証の指摘
・オープンリダイレクトの指摘

これらはセキュリティ的に「ゼロではないが、PRコメントの雑音になりやすい」カテゴリだ。加えて、false-positive-filtering-instructionsというinputにテキストファイルのパスを渡すと、組織固有の事情を反映したフィルタ基準に差し替えられる。公式ドキュメント(docs/custom-filtering-instructions.md)によれば、このファイルは3セクション構成が想定されている。

# .github/workflows/security.yml に1行追加するだけ
- uses: anthropics/claude-code-security-review@main
  with:
    comment-pr: true
    claude-api-key: ${{ secrets.CLAUDE_API_KEY }}
    false-positive-filtering-instructions: .github/security-filtering.txt

.github/security-filtering.txt側は次の3セクションで書く決まりだ。

HARD EXCLUSIONS:自動的に除外すべきパターンの列挙
SIGNAL QUALITY CRITERIA:本物の脆弱性かどうかを判定するための質問リスト
PRECEDENTS:自組織でよくあるセキュリティパターンへの個別ガイダンス

例えば「認証はAWS Cognitoに全面委任している」「k8sのリソース制限がDoSを事実上防いでいる」といった前提をここに書いておくと、その前提を踏まえた誤検知を減らせる、とドキュメントは説明している。カスタム設定なしでも「デフォルトの除外基準」は最初から効いている点は覚えておきたい。

誤検知を「減らす」方向のカスタマイズがfalse-positive-filtering-instructionsなら、検出カテゴリを「増やす」方向のカスタマイズがcustom-security-scan-instructionsだ。公式ドキュメント(docs/custom-security-scan-instructions.md)によれば、このinputで渡したテキストはデフォルトの「Data Exposure」カテゴリの直後に追記される形で監査プロンプトに組み込まれる。つまりデフォルトのカテゴリを置き換えるのではなく拡張する仕組みだ。想定用途として例示されているのは、GraphQLのクエリ深度攻撃やフィールド単位の認可バイパスといった技術スタック固有のチェック、GDPR・HIPAA・PCI DSSのようなコンプライアンス要件、決済処理特有のリプレイ攻撃など業務ロジック固有の脆弱性で、いずれも標準の10カテゴリではカバーしきれない領域を補う位置づけだ。ドキュメント上、検出された各所見にはHIGH/MEDIUM/LOWの重大度が付与される、という記述もある。

従来SASTとの違い(Anthropicの主張)

READMEの「Benefits Over Traditional SAST」は、この4点を優位性として挙げている。

従来のパターンマッチ型SASTとclaude-code-security-reviewの違いを比較した図
README「Benefits Over Traditional SAST」の主張を図解(第三者による独立比較検証ではない)

Contextual Understanding:パターンだけでなくコードの意味・意図を理解する
Lower False Positives:コードが実際に脆弱かどうかを理解した上で判定するため誤検知が減る
Detailed Explanations:なぜ脆弱なのか・どう直すべきかを明確に説明する
Adaptive Learning:組織固有のセキュリティ要件に合わせてカスタマイズできる

これらはAnthropic自身の主張であり、独立した第三者機関によるベンチマーク結果ではない。README内に具体的な競合SASTツール名や比較指標は示されていないため、本記事でも特定製品名を挙げた優劣比較はしない。「誤検知フィルタリングのロジックが実装として存在する」という事実と、「その効果がどの程度か」は別の話だ、と区別して読むのが安全だ。

releases 0本・タグ運用なしは「バージョン管理を放棄している」ではなく「セマンティックバージョニングでの配布をしていないだけ」。READMEの案内自体はGA相当の完成度で書かれており、実験的機能を示す明記は見当たらない。

実際にPRへコメントが投稿される仕組みと確認方法

action.ymlを読むと、PRコメントが投稿されるまでの内部フローが分かる。Mermaidで整理するとこうなる。

flowchart TD A["PRを作成/更新"] --> B["actions/checkout
fetch-depth: 2"] B --> C{"同じSHAで実行済み?
(.claudecode-marker キャッシュ)"} C -- はい --> D["スキップ
(重複解析による誤検知増を防止)"] C -- いいえ --> E["Claudeが差分を解析
github_action_audit.py"] E --> F["誤検知フィルタリング
findings_filter.py"] F --> G{"comment-pr: true?"} G -- はい --> H["PRにインラインコメント投稿"] G -- いいえ --> I["結果JSONをartifactとして保存"]

run-every-commitをtrueにしない限り、同一PR・同一SHAでは2回目以降の実行はキャッシュ判定でスキップされる。これは「同じコードを何度も解析して誤検知が増える」事態を防ぐための設計だ。

さらにaction.ymlを読むと、解析を始める前に.claudecode-markerというファイルへ実行予約(reservation)を書き込み、actions/cache/saveで即座に保存するステップがある。コメントには「to prevent race conditions」と明記されており、同じPRに対して複数のワークフロー実行が同時に走った場合でも、解析の重複実行を防ぐ設計になっていることが読み取れる。地味だが、CI環境で同一PRへの再push・再実行が頻発する運用では効いてくる作りだ。

未検証(本稿執筆時点)
実際にテスト用リポジトリへこのActionを設定し、意図的に脆弱なコードを含むPRを作成してPRコメントが投稿されるまでの時間・重大度表記の実例・誤検知フィルタリングが実際にどこまで効くかを実機で確認する計画だったが、本記事を書いた環境にAnthropic Claude APIキーが用意できず、ライブ実行はできなかった。上記のフローは`action.yml`のコード(composite stepsの条件分岐)を読んで再構成したものであり、実際のPRコメントの文面・応答時間は未検証として扱ってほしい。導入する際は、まず自分のテストリポジトリで1件PRを作って実際の挙動を確認することを勧める。

PRコメント以外の出力経路も用意されている。upload-results(既定true)を有効にしておくと、findings.jsonclaudecode-results.jsonclaudecode-error.logがGitHub Actionsのartifactとして7日間保存される。またAction自体はfindings-count(検出件数)とresults-file(結果JSONのパス)という2つのoutputを公開しており、これを後続ジョブで参照すれば「重大な脆弱性が1件でもあればマージをブロックする」といったゲート処理を自前で組める。PRコメントはあくまで人間向けの通知経路で、CI上の自動判定はoutputs側を使う、という役割分担だ。

README「Security Considerations」には、もう1つ重要な注意書きがある。

“This action is not hardened against prompt injection attacks and should only be used to review trusted PRs.”

つまりプロンプトインジェクション対策は施されていない。外部コントリビューターからのPRをそのまま解析させるなら、GitHubの「Require approval for all external contributors」設定でワークフロー実行前に必ずメンテナーの承認を挟むことを、README自身が推奨している。

まとめ:導入前に確認すべきこと

claude code security reviewは、.github/workflows/に1ファイル足すだけでPRの一次セキュリティスクリーニングを自動化できるAnthropic公式Actionだ。ただし導入前に次の3点は押さえておきたい。

・入力キー名はclaude-api-key固定(Secrets名自体は任意)
claude-modelの既定値はREADME記載の時点でOpus 4.1のまま。最新モデルを使いたいなら明示的に上書きする
・最終コミットは2026-02-11で本稿執筆時点(2026-09-16)で約7ヶ月更新なし。停止ではなく「安定期」と読めるかは、公式の継続案内(Help Centerに現行掲載中)と合わせて判断する

Routines機能全般(schedule/API/GitHub eventの3トリガーで非同期タスクを自動化する仕組み)については Claude Code Routines完全解説|Claudeが自分でClaude Codeを起動する非同期自動化 で扱っている。並列ワークツリーや--bare最適化などClaude Code全般の運用Tipsは Claude Codeベストプラクティス2026|Boris直伝25 Tips・並列ワークツリー・–bare最適化、カスタムコマンドの仕組みは Claude Skillsとは|「スキル=フォルダ」の仕組みと作り方・使い方を徹底解説 を参照してほしい。

参照ソース

anthropics/claude-code-security-review(公式リポジトリ・README・action.yml) — Quick Start・検出カテゴリ・action.ymlのinputs定義・LICENSE原文を取得
Automate security reviews with Claude Code(Anthropic公式ブログ, 2025-08-06) — 公式の位置づけ・仕組みの説明を取得
Automated Security Reviews in Claude Code(Anthropic Help Center)/security-reviewコマンドとGitHub Action版の使い分け・対応プランを取得