コードを書き終えて PR を出す前、「セキュリティ的に問題ないよな？」と自問したことは誰でもあると思います。
自分の書いたコードの脆弱性を自分で洗い出すのは難しいし、レビュアーに頼っても、セキュリティ観点はどうしても後回しにされがちです。
Cloudflare が公開した cloudflare/security-audit-skill は、その問題に対してひとつの実践的な答えを示しています。
Claude Code にこのスキルを追加するだけで、エージェントが自律的に6フェーズの監査を走らせ、根拠のあるファインディングを JSON と Markdown で出力してくれます。
スキルの構造・セットアップ・コードレビュー前段への組み込み方・Semgrep との役割分担——その順で掘り下げます。
Claude Code はすでに日常的に使っている前提なので、エージェント自体の導入手順には触れません。
security-audit-skill とは何か——静的解析ツールを「追加する」のとは根本的に違う話
cloudflare/security-audit-skill は、Cloudflare が社内の脆弱性発見ハーネスのシードとして開発し、その後 OSS 公開したものです。
GitHub リポジトリには「This is the skill that seeded Cloudflare's vulnerability discovery harness. The harness grew into a multi-stage, fleet-wide system; this skill is the single-repo starting point it evolved from.」と記されています。
「Semgrep のルールを追加する」とは根本的にやっていることが違います。
ルールベースのツールは、あらかじめ定義されたパターンにマッチするコードを拾います。
このスキルがやるのは エージェントの振る舞いそのものを「セキュリティ監査者」に変える ことです。
スキルを追加すると、Claude Code は特定のトリガーワードを検出した瞬間に自動で監査モードに入ります。
「security audit」「find vulnerabilities」「pen-test the code」などがトリガーとして機能します。
モードは2つあって、コードベース全体への直接監査要求であれば full audit mode が起動し、特定の脆弱性クラスへの質問や focused な調査は guidance mode で応答します。
レポートアーティファクトを明示的に要求しない限り、guidance mode はレポートを生成しません。
ここで重要なのが、 機械可読な出力と独立検証 という設計思想です。
ファインディングは JSON スキーマに沿った構造で出力されるため、チケット起票・他ツールとの連携がしやすい形になっています。
さらに、最終レポートに載るファインディングは「独立したエージェントによる再検証を通過したもの」に限定されます。
あるエージェントが見つけた脆弱性候補を、別のエージェントが「本当にそうか？」と反証しようとして、それでも生き残ったものだけが最終的なファインディングになる——この構造が偽陽性を減らす仕組みになっています。
6フェーズ監査の中身——「ファインディングが反証を生き延びる」まで
full audit mode で走らせると、エージェントは次の6フェーズを自律的に順番に実行します。
- Recon（偵察）: コードベースの構造・依存関係・技術スタックを把握し、監査範囲のマップを作る。
- Hunting（探索）: カバレッジ台帳に基づいて脆弱性候補を探す。メモリ安全性・認証バイパス・プロンプトインジェクション・サプライチェーンリスクなど複数クラスにわたって洗い出す。
- Validation（検証）: 候補ファインディングに adversarial な反証を試みる。「本当に悪用可能か？」「コンテキストを見落としていないか？」という観点で潰しにかかり、反証できなかったものだけを次に送る。
- Reporting（レポート生成）: Markdown 形式のレポートを生成する。各ファインディングに severity と再現手順が付く。
- Structured Output（構造化出力）: JSON スキーマに沿った機械可読なファインディングを出力する。
- Independent Verification（独立検証）: 最終記録を別エージェントが再確認し、出力の一貫性と誤記をチェックする。
注目すべきは、各フェーズを 孤立した別のサブエージェント が担当する点です。
フェーズごとに担当を分けることで、前フェーズの思い込みが次フェーズに伝染するのを防いでいます。
Validation フェーズで反証を試みるエージェントは、Hunting フェーズで候補を見つけたエージェントとは独立して動いているわけです。
adversarial validation はペネトレーションテストの世界では普通の発想ですが、それをエージェントのアーキテクチャとして実装している点がこのスキルの肝です。
「見つけた」だけで終わらず「本当に問題か？」を自分で証明させる構造が、最終レポートの信頼性を底上げしています。
Claude Code へのセットアップと最初の監査実行
スキルの追加は、プロジェクトの .claude/skills/ ディレクトリにスキルファイルを配置するだけです。
# GitHub からクローンして手動配置する例
git clone https://github.com/cloudflare/security-audit-skill.git /tmp/security-audit-skill
mkdir -p .claude/skills
cp /tmp/security-audit-skill/SKILL.md .claude/skills/security-audit.md
Claude Code のセッション内でインストールコマンドを使う場合はこちらです。
/install-skill https://github.com/cloudflare/security-audit-skill
配置後、英語でトリガーワードを含むプロンプトを投げると監査が始まります。
Security audit this codebase. Full audit mode. Output report to ./audit-results/
出力先はデフォルトで ~/security-audit-＜タイムスタンプ＞/ ディレクトリになります。
生成されるファイルは2つです。
~/security-audit-20260917-143022/
├── findings.json # 機械可読なファインディング（severity・再現手順付き）
└── audit-report.md # Markdown レポート（フェーズごとの要約付き）
初回実行前に確認しておくべき点が2つあります。
1つ目は 監査スコープの明示。
「このリポジトリ全体」か「src/ 以下のアプリケーションコードだけ」かを伝えないと、テストコードや自動生成ファイルまで含む膨大なスコープで走ります。
2つ目は LLM コストへの覚悟。
エージェントが6フェーズを回すため、小規模なリポジトリでも preflight が重くなります。
類似のエージェント型セキュリティ CLI の実測では、小規模ターゲットへの低コスト設定で途中終了するケースが報告されています。
初回は小さなスコープで試してから広げるのが安全です。
コードレビュー前段への組み込み方——どのタイミングで呼ぶと一番効くか
フローに組み込む方法は大きく2つあります。
「PR 作成前に開発者自身が走らせる」使い方と「レビュー依頼後にレビュアーが走らせる」使い方です。
前者を強く推します。
ファインディングを修正するコストがまったく違うからです。
PR を出す前なら自分のローカルで修正してからプッシュすればいい。
レビュー後に「実はこういう脆弱性があった」となると、差し戻しのコミュニケーションコストが乗ってきます。
運用のイメージはシンプルです。
機能開発が一段落したら、PR を作る前に Claude Code に監査を走らせます。
audit-report.md を見て Critical や High があれば修正する。
Medium 以下は自分のコンテキストで悪用可能性を判断した上で対応を決める。
findings.json か audit-report.md のサマリーを PR description に貼っておけば、レビュアーへの情報共有にもなります。
「レビュアーがゼロからセキュリティを探す」のではなく「エージェントのファインディングを起点に深掘りする」状態が作れると、レビューの質が変わります。
ひとつ注意しておくと、ファインディングの盲信は禁物です。
adversarial validation があるとはいえ、エージェントはコードの外側（インフラ設定・デプロイ環境・ランタイム挙動）を知りません。
「このコードパスは実際には到達不能」といった文脈は、エージェントには見えないことがあります。
ファインディングは「調査の補助線」として使い、最終的な判断は人間が下す——その役割分担を最初に決めておくと、チームへの導入説明もしやすくなります。
Semgrep などの静的解析との役割分担——何を任せて何を任せないか
「Semgrep は要らなくなるのか？」という疑問が出てきます。
答えはノーで、むしろ両方置くのが現実的です。
Semgrep が得意なのは、パターンマッチで拾える既知の脆弱性パターンへの高速な対応です。
数十秒前後のスキャンで CI の PR ごとに実行でき、Community Edition の範囲ではコストもかかりません。
ルールが YAML で書かれているので「何を見ているか」が人間にも読める透明性も利点です。
エージェント監査が得意なのは、複数ファイルをまたぐロジックの連鎖から来るリスクや、設計レベルの問題（認証フロー全体の穴・権限チェックの抜け漏れ）です。
Semgrep Community Edition は単一関数内の解析に留まるため、関数をまたいだデータフローに起因する脆弱性は拾いにくいという制約があります。
ルールが存在しない新しい脆弱性クラスも文脈から推論できる点も、エージェント監査ならではの強みです。
どちらも苦手な領域も存在します。
ランタイム挙動・インフラ設定・実際の exploitability 検証は、両ツールとも完全にはカバーできません。
「本当にこの経路が攻撃可能か」を確かめるには、最終的には手動のペネトレーションテストや実環境での確認が必要です。
実務的には二層構成にするのが現実的です。
# .github/workflows/semgrep.yml（CI 層：PR ごとに高速パターンチェック）
name: Semgrep Scan
on: [pull_request]
jobs:
semgrep:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: semgrep/semgrep-action@v1
with:
config: auto # 言語を自動判別してルールセットを適用
# ローカル PR 前フェーズ（エージェント監査層）
# 認証・外部 API 連携に触れた変更のタイミングで優先的に実行する
Security audit the src/ directory. Full audit mode. Output to ./audit-results/
CI に Semgrep を置いて高速なパターンチェックを常時走らせ、ローカルでは PR 前に security-audit-skill を呼んで文脈込みの深い監査をかける——これがひとつの現実解です。
Semgrep が拾う「パターン的に危ない」とエージェントが見つける「ロジック的に危ない」は補完関係にあり、どちらかだけでは片手落ちになります。
正直なところ、エージェント監査には実行コストと時間がかかるので、毎 PR で回すのは現実的でないことも多いです。
「大きな機能追加のタイミング」「外部 API 連携を追加したとき」「認証周りに触れたとき」など、リスクの高い変更に絞って使うのが最初のステップとして現実的だと思います。
security-audit-skill は、静的解析では拾えないが人間のレビューでも見落とされがちな領域を、エージェントが多フェーズで体系的に洗い出す仕組みです。
adversarial validation でファインディングの質を担保しつつ、機械可読な出力で後続の作業に接続しやすくなっているのが設計として面白い。
「コードレビュー前段でエージェントが先に洗い出す」という層を一枚加えるだけで、見落としのリスクは確実に下がります。
株式会社ホコサキは、山口県宇部を拠点に Web 制作・業務システム開発・AI 活用支援を手がけています。
コーディングエージェントを使った開発フロー設計や、セキュリティレビューの自動化についてご相談があれば、お問い合わせページ からお気軽にどうぞ。