Claude Code セキュリティ監査：実践的な 2026 年ワークフロー

本記事のコマンド名やプラグイン名は Anthropic の公式ドキュメント（2026 年 8 月取得）に基づいています。Claude Code は頻繁に更新されるため、監査の前に /plugin マーケットプレイスを再確認してください。

Claude Code のセキュリティ監査とは？

Claude Code のセキュリティ監査とは、Claude Code を「AI セキュリティレビュアー」として使い、従来のリンターのようにパターン照合するだけでなく、コードの意味を読み取って脆弱性を見つける手法です。モデルはデータフローや関数の意図を理解するため、正規表現ベースのツールが取りこぼしがちな問題も検出します。たとえば、ユーザー入力が連結された SQL 文字列に流れ込んでいる箇所、認可チェックが抜けているエンドポイント、ソースに直接埋め込まれた API キーなどです。

Claude Code が検出しやすい脆弱性の種類には、インジェクション（SQL、コマンド、NoSQL、XXE）、認証・認可の不備（IDOR、権限昇格、脆弱なセッション）、データ露出（ハードコードされたシークレット、ログ内の PII）、弱い暗号（不十分な RNG、不適切な鍵管理）、設定ミス（CORS、セキュリティヘッダー）、サプライチェーンのリスク（既知の CVE を持つ依存関係）などがあります。

本ガイドでは 4 つのアプローチを取り上げます。

• ネイティブの /security-review — Claude Code に組み込まれたコマンドと、Anthropic 公式の GitHub Action（2025 年 8 月公開、anthropics/claude-code-security-review、2026 年 8 月アクセス）です。保留中の変更をレビューし、深刻度を採点し、修正案を提示します。誤検知フィルターも組み込まれています。
• claude-security プラグイン — /plugin install claude-security@claude-plugins-official でインストールすると /claude-security コマンドが追加され、マルチエージェントによる深いスキャンのメニューが開きます（単純なスキャンコマンドではありません）。アーキテクチャをマッピング → 脅威モデルを構築 → 脆弱性を探索 → 独立したエージェントが報告前に検証、という流れです。無料（プランの利用量として消費されます）で、dynamic workflows が必要です。詳しくは後述の専用セクションをご覧ください。
• security-guidance プラグイン — Claude が書いたばかりのコードを 3 層で自動レビューします（即時のパターン照合、ターン終了時のバックグラウンドレビュー、コミット／プッシュ時の深いレビュー）。継続的な監視レイヤーとして定期的な監査を補完します。詳しくはセキュリティのベストプラクティスの記事をご覧ください。
• あらかじめ用意された ak-security スキル — STRIDE + OWASP A01〜A10、スタックを考慮した依存関係の監査、複数ペルソナによるレッドチーミング、--fix モードを網羅したプロンプトのパッケージで、長いプロンプトを自分で書く必要がありません。有料で、AgentKit Engineer Kit の一部です。

Claude Code のセキュリティモデルに関する公式ドキュメントは code.claude.com/docs/en/security（2026 年 8 月アクセス）にあります。リポジトリ内でコマンドを実行する権限を AI に与える前に読んでおく価値があります。

監査の前に：セットアップ

3 分の準備で、セッションをクリーンかつ元に戻せる状態に保てます。

• Claude Code をインストールしてサインイン済みであること。まだの場合は Claude Code のインストールガイドに従ってください。
• クリーンな Git の作業ツリー（git status に保留中の変更が何も表示されない状態）。AI が提案する内容を見分けるために明確な差分が必要ですし、パッチが何かを壊した場合は git restore で元に戻せます。
• スコープを最初に決める。単一のフォルダ（src/api/**）、今変更しているファイル、あるいはリポジトリ全体のいずれかです。スコープが狭いほど速く、トークンも節約できます。
• 信頼できるコードだけを監査する。これは早めに伝えておくべき重要な警告です。見知らぬ人のリポジトリや PR のコードを AI に読ませると、そのコード内の悪意ある内容が指示を注入（プロンプトインジェクション）してモデルを欺くことがあります。信頼できないコードは手動でレビューするか、隔離された環境で実行してください。
• 見知らぬ／信頼できないリポジトリを監査する場合は、サンドボックスで実行する。よく知らないリポジトリを監査せざるを得ないときは、OS レベルの隔離のために /sandbox（macOS では Seatbelt、Linux/WSL2 では bubblewrap+socat）の中で Claude Code を実行してください。通常の権限モードより強力なレイヤーです。Claude Code のサンドボックス化をご覧ください。
• コマンドの権限を確認する。Claude Code の権限と安全な実行を確認し、スキャン中に AI が破壊的なコマンドを勝手に実行できないようにしてください。2026 年 8 月時点では、auto モードが Pro/Max/Team のデフォルトの開始モードです。監査が提案しうる危険なコマンド（たとえば npm install を実行する --fix など）は、毎回手動で確認を求められる代わりに分類器を通ります。そのため開始前に allowlist を確認しておきましょう。

Claude Code 監査の 6 ステップのワークフロー

これはセッション全体の骨格です。結果を読みやすく保ち、無駄にトークンを消費しないよう、狭い範囲から広い範囲へ順番に進めてください。

ステップ 1 — スコープを定義する

まず、レビューしてほしい対象を正確に指定するところから始めます。小さな変更なら Claude に差分だけに集中させ、大きなリポジトリなら機微な領域（認証、決済、アップロード、公開 API）にディレクトリの glob で範囲を絞ります。Claude には分析の前にスコープ内のすべてのファイルを読むよう指示してください。そうしないとモデルは関数名から推測しがちです。最初のプロンプト例です。

Read all files in src/api/ and src/auth/ first.
Do not change anything yet. Just list the areas with an attack
surface (external input, DB access, auth handling) so I can pick a scope.

ステップ 2 — 保留中の変更に対して /security-review を実行する

これからコミットしようとしている変更に対して、Claude Code のセッション内でネイティブコマンドを実行します。

/security-review

これは保留中の差分をレビューし、深刻度を分類し、検出結果ごとに修正案を提示します。利用可能な最も強力な Claude モデル（設定可能）で動作し、人間が見る前に PR を読むセキュリティレビュアーだと考えてください。ここが最も速く「シフトレフト」できる場所です。コードがまだ新鮮で、メインブランチに乗る前に問題をつかまえられます。

ステップ 3 — STRIDE + OWASP でリポジトリ全体をスキャンする

差分よりも深く掘り下げるには、構造化された脅威モデリングのプロンプトを Claude に与えます。STRIDE は OWASP Top 10 にかなりきれいに対応します。コピー＆ペースト用のテンプレートです。

Audit all in-scope code across the 6 STRIDE categories, mapped to the OWASP Top 10:
- Spoofing -> A07 (identification/authentication failures)
- Tampering -> A03 (injection), A08 (data/software integrity)
- Repudiation -> A09 (missing logging/monitoring)
- Info Disclosure -> A02 (crypto), A01 (access control)
- Denial of Service -> note it, but only report with clear impact
- Elevation of Priv -> A01 (broken access control)

For each finding, record: severity, category, file:line, a short description,
and a concrete fix. Do not report theoretical issues you cannot tie to real impact.

ステップ 4 — 依存関係を監査する

脆弱性は、自分が書いたコードよりも取り込んだライブラリの中に潜んでいることがよくあります。スタックに合ったツールを実行し、その結果を Claude にまとめて優先順位付けさせましょう。

npm audit # Node.js
pip-audit # Python
govulncheck ./... # Go
bundle audit # Ruby

次に出力を Claude に貼り付けます。「これらの CVE を、私のプロジェクトでの実際の悪用可能性で順位付けし、devDependencies にしか存在せず本番に到達しないものは除外して」。Claude はノイズを減らす手助けをしてくれます。すべての CVE が実際の実行経路上にあるわけではありません。

ステップ 5 — ハードコードされたシークレットを探す

ソースや設定ファイルに直接埋め込まれた API キー、パスワード、トークン、秘密鍵をスキャンするよう Claude に依頼します。認証情報の取り扱いについての注意です。報告する際は、レポートをログに残したりコミットしたりする前に、実際の値を <REDACTED_TOKEN> にマスクしてください。シークレットを監査するそのファイルから、シークレットが漏れてしまわないようにするためです。

Scan the whole repo for hardcoded secrets (api keys, passwords, tokens,
private keys, DB connection strings). For each finding, record only file:line
and the TYPE of secret, and mask the value to <REDACTED>. Do not print real values.

ステップ 6 — 深刻度を分類してレポートを書き出す

すべての検出結果を深刻度ごとに 1 つのテーブルにまとめ、明確な対応の基準を付けるよう Claude に依頼します。

結果を残すには、先頭に深刻度の件数サマリー（「重大 2 件、高 3 件…」）を付けた Markdown レポートを書き出すよう Claude に依頼します。この形式なら、課題トラッカーやリードへのレビューにそのまま流し込めます。監査を定期的に行うなら、日付付きのレポートを security/ フォルダに保管し（機微な部分は gitignore する）、実行結果を比較して、どの脆弱性が再発したりレビューをすり抜けたりしているかを見つけられるようにしましょう。

実際の監査セッション：検出結果の読み方

ここが、ほとんどの競合がほぼ完全に飛ばしている部分です。機能の説明ではなく、実際の検出結果テーブルです。以下は、出力がどのようなものか分かるように、サンプルの Node/TypeScript プロジェクト（API + 認証）から作った例示的な結果です。自分のテーブルを得るには、ご自身のリポジトリで実行してください。

読み方です。深刻度の高い順に上から下へ進めます。検出結果 #1 はリリースを止めます。ここに異論はありません。#2 と #3 はそのままスプリントへ。#4（IDOR）は過小評価されがちですが、非常によくあるアクセス権限昇格の欠陥です。各行について、正確な file:line を開き、問題が本物であること（誤検知でないこと）を確認し、そのうえで初めて修正します。レポートを鵜呑みにして無闇に修正しないでください。

修正前の手早い検証テクニックとして、Claude に問い返してみましょう。「検出結果 #4 が悪用可能であることを証明して。ユーザー A がユーザー B の注文を読むために使う具体的なリクエストを書いて」。モデルが具体的な悪用シナリオを組み立てられるなら、それは本物の脆弱性です。曖昧にごまかしたり非現実的な条件を仮定しなければならなかったりする場合は、おそらく誤検知なので優先度を下げられます。この敵対的なステップはノイズを取り除き、抽象的な専門用語ではなく具体的な攻撃者の言葉で、チームの他のメンバーにリスクを説明するのにも役立ちます。

脆弱性の修正 — 実際のビフォー／アフター

検出結果 #1（重大、SQL インジェクション）を例にします。間違えやすいのは、こういうコードです。

// BEFORE - vulnerable to SQL injection
export async function getUser(id: string) {
 const sql = "SELECT * FROM users WHERE id = '" + id + "'";
 return db.query(sql); // the id input flows straight into the SQL string
}

そして、パラメータ化クエリで修正した後です。

// AFTER - parameterized, the driver escapes it
export async function getUser(id: string) {
 const sql = "SELECT * FROM users WHERE id = $1";
 return db.query(sql, [id]); // the id value travels through the parameter channel, not the SQL string
}

なぜ安全かというと、2 番目のバージョンでは id がもはや SQL 文字列に連結されず、別のパラメータチャネルを通って渡されるからです。データベースドライバはそれをコマンドではなくデータとして扱います。そのため ' OR '1'='1 のような文字列がクエリの構造を変えることはできなくなります。

自動化されたフローでは、あらかじめ用意されたスキルが --fix を提供します。検出結果を 1 件ずつ修正し、各パッチの後にリグレッションを防ぐガードテストを実行し、修正ごとに個別にコミットします。ただしマージ前には必ず差分をレビューしてください。パッチがテストを壊した場合は、当て推量をせず、代わりに テストを壊す修正を AI でデバッグする方法で本当の原因を突き止めましょう。

自動化：すべてのプルリクエストでセキュリティレビュー

すべての PR を自動でスキャンするには、公式の GitHub Action を使います。.github/workflows/security.yml ファイルを追加します。

name: Security Review
on: [pull_request]
jobs:
 review:
 runs-on: ubuntu-latest
 permissions:
 pull-requests: write
 contents: read
 steps:
 - uses: actions/checkout@v4
 - uses: anthropics/claude-code-security-review@main
 with:
 claude-api-key: ${{ secrets.ANTHROPIC_API_KEY }}

この Action は検出結果を PR に直接コメントするため、レビュアーはすぐに確認できます。

必須の注意点：Anthropic によると、この Action はまだプロンプトインジェクションに対して堅牢化されていません。信頼できる PR に対してのみ実行し、Actions の設定で「すべての外部コントリビューターに承認を必須にする」を有効にしてください。そうしないと、見知らぬ人からの悪意ある PR が指示を注入し、レビュープロセスを欺くおそれがあります。

防御レイヤーを仕上げるために、Claude Code による安全な Git ワークフローと組み合わせ、コードがリモートに届く前にシークレットをスキャンする pre-commit hook の追加も検討してください。

claude-security プラグインによる無料の深いスキャン

これは無料の公式マルチエージェント深層スキャンレイヤーで、1 回のモデル呼び出しで 1 つの差分をレビューするステップ 2 の /security-review とはかなり異なります。claude-security はセッション内でエージェントのチーム全体を動かします。1 つがリポジトリのアーキテクチャをマッピングし、1 つがそこから脅威モデルを構築し、あるグループが脅威モデルに照らして脆弱性を探索し、そして最終レポートに載る前に独立したエージェントが検証します。この独立検証のステップこそが、単一のスキャンより報告を信頼できるものにしています。

要件です。有料プランの Claude Code v2.1.154 以降、エージェントをオーケストレーションするための dynamic workflows（Pro では /config の「Dynamic workflows」の行から自分で有効化する必要があります）、PATH 上に python3 として利用できる Python 3.9.6 以降（プラグインのツールは標準ライブラリしか使わず、追加インストールはありません）、そして変更のスキャンとパッチの書き出しのための Git（リポジトリ全体のスキャンは Git がなくても動作します）です。

インストールして実行します。

/plugin install claude-security@claude-plugins-official
/claude-security # opens the menu: Scan codebase / Scan changes / Suggest patches
/claude-security scan my branch # or call a job directly in plain language

プラグインはまずリポジトリを読み込み、その後で全体スキャンか特定領域に絞ったスキャンかを、それぞれのコスト見積もり付きで提示します。全体スキャンはかなりの量のトークンを使うことがあり、完了まで Claude Code を開いたままにする必要があるため、大きなリポジトリで役立ちます。あなたが確認するまで何も実行されません。

結果は、リポジトリ内のタイムスタンプ付きディレクトリ CLAUDE-SECURITY-<timestamp>/ に格納されます。中身は、CLAUDE-SECURITY-RESULTS.md（読みやすいレポートで、各検出結果に F1 のような ID と深刻度、確度、悪用シナリオが付きます）、機械可読な .jsonl 版、そしてリビジョンスタンプです。リビジョンスタンプは、どのコミットが、どれだけ徹底的にスキャンされ、未コミットの変更が含まれていたかを正確に記録するファイルで、レポートが常に、それが説明する当のコードに結び付くようにします。このディレクトリは独自の .gitignore を持つため、うっかりした git add でコミットに紛れ込むことはありません。

修正するには、もう一度 /claude-security を実行し、「Suggest patches」を選び、対応する検出結果を選びます。各パッチは、それを書いたエージェントとは独立したエージェントによって、提供される前にレビューされ、自動的に適用されることは決してありません。パッチは patches/F<n>.patch に格納され、レビューした後に自分で git apply を実行します。

ak-security スキルとの比較：この 2 つは今や実際に重なっており、それをごまかす意味はありません。claude-security の強み：無料で、別のエージェントによる独立検証があり、すぐに git apply できるパッチが得られること。ak-security の強み：STRIDE + OWASP + 4 ペルソナのレッドチーム + シークレットスキャンのフレームワークを 1 つのすっきりしたコマンドにパッケージしており、すでに他の用途で AgentKit を使っているなら馴染みやすいこと。どちらも完全に相手を置き換えるわけではありません。まだ AgentKit を持っていないなら、claude-security は無料で始めるのに十分強力です。

上級レッドチーム：4 つの攻撃者ペルソナから監査する

STRIDE を 1 回通すのも良いですが、本物の脆弱性は、特定の攻撃者になりきって考えたときに表面化しがちです。4 つの異なる視点から監査を実行すると、明確に得られる情報が増えます。

• セキュリティ攻撃者 — 認証バイパス、インジェクションの亜種、IDOR を探します。「一般アカウントでログインしたら、他人のデータを読んだり編集したりできるか？」
• サプライチェーン — 既知の CVE を持つ依存関係、汚染された CI/CD、パッケージのタイポスクワッティング。
• 内部者 — 水平／垂直の権限昇格、大量データのエクスポート、内部アカウントの権限の悪用。
• インフラ — SSRF、環境変数からのシークレット漏洩、設定を誤ったコンテナ／ネットワーク設定。

4 つのペルソナをすべて手書きするのは大変な作業です。それぞれの視点に独自のプロンプト一式とチェックリストが必要だからです。まさにここで、あらかじめ用意された構造化された脅威モデリングが、何時間ものプロンプト作成を省いてくれます。

4 つのペルソナを実行するのは、定期的な深層スキャンのパスです。次の監査を待たずに、Claude がコードを書いた瞬間に問題をつかまえる継続的なレイヤーについては、セキュリティのベストプラクティスの記事にある security-guidance プラグインをご覧ください。この 2 つのレイヤーは互いを補完するもので、置き換えるものではありません。

あらかじめ用意された ak-security スキルを使う（プロンプト作成を省く）

STRIDE プロンプト、4 つのレッドチームペルソナ、--fix フローを毎回手書きする代わりに、AgentKit バンドル（現在 $149、元は $198）がそのすべてを ak-security スキルにパッケージしています（Engineer Kit の一部、$99。サイトには返金保証と生涯アップデートが記載されており、継続課金の記載はありません）。使い方です。

/ak:security src/api/**/*.ts # scan a narrow scope
/ak:security full --red-team --fix # whole repo, 4 personas, auto-patch

これは STRIDE + OWASP A01〜A10、スタックを考慮した依存関係の監査、シークレット検出、深刻度の採点、ガードテスト付きの逐次パッチをまとめています。ご自身のニーズと照らし合わせるには、Engineer Kit に含まれるセキュリティスキルをご覧ください。

正直に言うと：このスキルは今や、上で挙げた無料の claude-security プラグインと実際に重なっています。ネイティブのプラグイン以上に「AI をペンテスターに変える」ことを期待しないでください。ak-security の強み：STRIDE + OWASP + 4 ペルソナのレッドチーム + シークレット／依存関係のスキャンを 1 つのすっきりしたコマンドにまとめており、すでに他所で AgentKit を使っているなら馴染みやすいこと。claude-security の強み：別のエージェントによる独立検証と、すぐに git apply できるパッチが無料で得られること。どちらも完全に相手を置き換えるわけではありません。このキットは「本質的に強力だから」ではなく、すでに AgentKit を持っていて 1 つのエコシステムにとどまりたいときに価値があります。

混同を避けるために一言：ここでの AgentKit は Claude Code 用のキット（agentkit.best、ak CLI）であり、OpenAI の AgentKit（Agent Builder/ChatKit）ではありません。

本当の限界、そして AI を信頼すべきでないとき

セキュリティは YMYL の領域に近く、誇張よりも限界について正直であることの方が重要です。

• プロンプトインジェクション。よく知らないコードを無闇に監査しないでください。信頼できないコードは、脆弱性を無視させたり意図しないコマンドを実行させたりするようモデルを誘導する指示を注入することがあります。
• 誤検知と検知漏れ。デフォルトでは /security-review は、実証可能な影響に結び付けられない DoS、レート制限、リソース枯渇、オープンリダイレクト、入力検証の各クラスを除外します。そのため「スキャンでクリーン」は「完全に安全」を意味しません。逆に、AI は依然として微妙なビジネスロジックの欠陥（競合状態、TOCTOU、複雑な認可ロジック）を見逃します。
• 専門家のペネトレーションテストの代わりにはなりません。これは問題を早く安く見つけるためのシフトレフトのツールであって、セキュリティ認証ではありません。重要なシステムには依然として SAST/DAST と手動のペネトレーションテストが必要です。
• トークンコスト。大きなリポジトリのスキャンにはそれなりのトークンと時間がかかります。毎回 full を実行するのではなく、機微なディレクトリにスコープを絞ってください。

よくある質問（FAQ）

/security-review コマンドは無料ですか？

コマンドと GitHub Action は Anthropic によるオープンソースなので、利用するための別料金はありません。実際のコストは、加入しているプラン（Pro、Max、またはトークン従量課金の API）での Claude Code のトークン／利用量です。

Claude Code の監査は従来の SAST とどう違いますか？

SAST は主に固定のパターンやルールを照合するため、ノイズが多くなりがちです。Claude Code は意味とデータフローを読むため、パターン照合が見逃す文脈依存の問題（IDOR や認可ロジックなど）を検出します。その代わり、決定論的ではなく、人間による確認が必要になります。

AI は専門家のペネトレーションテストの代わりになりますか？

いいえ。これは問題を早く安く見つけるためのシフトレフトのレイヤーであって、認証ではありません。重要なシステムには、パイプライン内の SAST/DAST と並んで、依然として手動のペネトレーションテストが必要です。

他人のコードを監査しても安全ですか？

プロンプトインジェクションのリスクがあります。信頼できないコードは、モデルを誤導する指示を注入することがあります。信頼できるコードだけを監査するか、外部コントリビューターに対して手動承認を有効にした隔離環境で実行してください。

監査にはどれくらいのトークンと時間がかかりますか？

スコープ次第です。小さな差分のレビューは数分と少しのトークンで済みますが、大きなリポジトリのスキャンははるかに多くのトークンがかかり、目に見えて長くなります。節約するには機微なディレクトリにスコープを絞ってください。

ak-security スキルは自分でプロンプトを書くのとどう違いますか？

これは STRIDE + OWASP、4 つのレッドチームペルソナ、ガードテスト済みの --fix フローを 1 つのコマンドにパッケージし、プロンプト作成の手間を省きます。検出能力の点では、自分で良いプロンプトを書くのとほぼ同等です。違いは利便性と一貫性であって、「本質的に強力」ということではありません。

claude-security プラグインは ak-security スキルとどう違いますか？

この 2 つは今や実際に重なっています。claude-security は無料で、独立検証のステップ付きでマルチエージェントを動かし、すぐに git apply できるパッチを書き出します。ak-security は有料（AgentKit の一部）で、STRIDE + OWASP + 4 ペルソナ + シークレット／依存関係スキャンのフレームワークを 1 つのコマンドに詰め込んでいます。どちらも完全に相手を置き換えるわけではありません。すでに AgentKit を持っているか、無料と最もコンパクトなオプションのどちらを望むかで選んでください。

security-guidance プラグインは定期的な監査の代わりになりますか？

いいえ。security-guidance は、Claude がコードを書いた瞬間に動作する継続的なポイントチェックのレイヤーです（即時のパターン照合、ターン終了時のバックグラウンドレビュー、コミット／プッシュ時の深いレビュー）。問題を早くつかまえますが、claude-security や上記の 6 ステップのワークフローのような包括的で定期的またはオンデマンドの監査の代わりにはなりません。この 2 つのレイヤーは互いを補完します。

まとめと次のステップ

Claude Code のセキュリティ監査は専門家の代わりにはなりませんが、脆弱性探しを安く速い習慣に変えてくれます。リリースのたびに /security-review を実行し、定期的な STRIDE スキャンを行うか、無料の深層スキャンとして claude-security を実行し、書きながらの継続的レビューのために security-guidance を有効にし、信頼できる PR で自動化しましょう。次に、包括的な AI コードレビューへと広げ、Claude Code のセキュリティのベストプラクティスで土台を固めてください。そして忘れないでください。リリースごとの定期的な監査は、一度やって忘れてしまう深層スキャンに勝ります。