【検出率100%】セキュリティ診断、Claude Codeに全部やらせる時代が来た
はじめに
前回の記事で /security-scan を作った後、こんな気持ちになりました。
「これ、デプロイ前の静的解析と、デプロイ後の動的テストが混ざってないか?🤔」
そのとおりで、1スキルに詰め込みすぎていました。
今回は 3スキルに分割してOSSとして公開、さらに テストハーネスで精度を客観測定 するところまでやりました。
まず費用対効果だけ見てください
| 従来手段 | claude-security-scan(3スキル) | |
|---|---|---|
| 静的解析ツール(Snyk等) | $98/月〜 | — |
| セキュリティコンサル | $200〜500/時間 | — |
| 3スキル合計 | — | 約$0.8〜1.2/月 |
| 検出率(テストハーネス実測) | — | 100% |
3スキル体制になりました
開発ライフサイクルに沿って、3つのスキルを使い分ける 構成にしました。

[claude-security-scan の3スキル使い分けフロー]
| タイミング | スキル | 対象 | 1回のコスト |
|---|---|---|---|
| PR 作成時 | /security-review |
git diff のみ | 約$0.02 |
| リリース前 | /full-scan |
全ファイル + 依存関係 CVE | 約$0.18〜0.72 |
| デプロイ後 | /security-scan |
ランタイム挙動・HTTP 動的テスト | 約$0.05 |
「全部1スキルでやれば楽では?」と思っていたんですが、実際に使っていると問題が出てきました。
- PR のたびに全ファイルを解析するのはコスト的にムダ
- 動的テストはサーバーが起動していないと意味がない
- 「静的に問題なし」と「動的に問題なし」は別の話
3つに分けることで、それぞれの目的にフォーカスしつつコストも最小化できる ようになりました。
インストール(gh skill で1コマンド)
GitHub 公式の gh skill コマンドに対応しているので、1行で導入できます。
gh skill install sabakan0123/claude-security-skills
実行すると、対話プロンプトでインストール先のエージェント(Claude Code /
Cursor / Codex 等)とスコープ(ユーザー全体 /
プロジェクト単位)を聞かれます。Claude Code の場合は ~/.claude/skills/
配下に3つのスキルが配置されます。
中身を確認してから入れたい人へ
セキュリティ系のスキルを「中身も見ずに」入れるのは正直オススメできないので
、preview で先に確認するのを推奨します。
SKILL.md の中身を表示するだけ(インストールはされない)
gh skill preview sabakan0123/claude-security-skills
バージョンを固定したい場合
CI/CD に組み込む場合は --pin でタグを固定してください。
gh skill install sabakan0123/claude-security-skills --pin v0.2.0
gh skill update でも勝手に更新されなくなります。
アップデート
gh skill update --dry-run # 何が更新されるか先に確認
gh skill update # 実行
バージョンを固定したい場合
CI/CD に組み込む場合は --pin でタグを固定してください。
gh skill install sabakan0123/claude-security-scan --pin v0.2.0
gh skill update でも勝手に更新されなくなります。
アップデート
gh skill update --dry-run # 何が更新されるか先に確認
gh skill update # 実行
/security-review — 差分だけ見る($0.02/回)
PR を作るたびに全ファイルを解析するのはムダなので、git diff の変更分だけを対象にします。
/security-review
検出対象:
- インジェクション(SQL / NoSQL / コマンド)
- 認証・認可の欠陥(JWT 誤実装・認可バイパス)
- ハードコードされた認証情報・API キー
-
dangerouslySetInnerHTML等による XSS - PII・トークンのログ出力
ポイントは 「信頼度 0.8 以上のみ報告」 する設計にしたこと。
最初は「疑わしければ全部報告」にしていたんですが、偽陽性が多すぎてレビューが埋まり、本当の問題を見逃すようになりました。絞った結果、実際にブロックすべき問題だけが上がってくるようになりました。
/full-scan — リリース前に全部チェックする
差分ではなく、プロジェクト全体を対象にします。
/full-scan
特徴は 言語・フレームワーク非依存の自動検出。
package.json / Cargo.toml / go.mod 等を自動検出して、適切なスキャナーを選んで走らせます。
検出: Next.js (frontend) + Express (backend)
→ frontend サブエージェント
→ backend サブエージェント } 並列実行
→ パッケージスキャンエージェント
コンテキスト上限に達したら黙って無視するのではなく、必ず「PARTIAL SCAN」として未解析ファイルを全件報告 するようにしました。サイレントな見落としが一番怖いので。
/full-scan のコストを実測した
コストは「読み込んだコードの文字数」にほぼ比例します。実際に小・中・大規模のコードベースで計測しました。
| プロジェクト規模 | 読み込み文字数 | 消費トークン | 1回のコスト |
|---|---|---|---|
| 小規模(〜2,000行相当) | 〜32,000文字 | 〜33,000 | 〜$0.18 |
| 中規模(〜20,000行相当) | 〜800,000文字 | 〜134,000 | 〜$0.72 |
| 大規模(20,000行超・優先スキャン) | 〜140,000文字 | 〜90,000 | 〜$0.49 |
/security-scan — デプロイ後に動的テスト($0.05/回)
前回から引き続きの動的テストスキルです。ステージング環境のサーバーを実際に叩きます。
詳細は前回の記事をどうぞ。
テストハーネスを作って精度を測った
「精度が高い」と言いたいけど、感覚で言っても説得力がない。
なので フィクスチャと採点基準を用意して、スキルを評価できる仕組み を作りました。
tests/security-skills/
├── expected.json ← 模範解答(何が脆弱で何が安全か)
└── fixtures/
├── vuln/ ← Easy: 基本的な脆弱性
├── safe/ ← Easy: 安全なパターン(偽陽性テスト)
├── hard-vuln/ ← Hard: 一見安全に見える脆弱性
├── hard-safe/ ← Hard: 一見危険に見える安全なコード
├── attacker/ ← 実攻撃者レベルのパターン
├── attacker-safe/ ← 難しい安全パターン
├── no-comment-vuln/ ← コメントなし脆弱コード
├── no-comment-safe/ ← コメントなし安全コード
├── deep-chain/ ← 6ファイル深連鎖(JWT署名検証なし)
├── framework-bypass/ ← Next.js middleware バイパス
└── infra-combo/ ← CSP設定 + XSS 組み合わせ
難しいのは 「難しいフィクスチャ」を作ること でした。
たとえば hard-vuln/fake-escape.ts は、エスケープ処理が入っているように見えて、テンプレートリテラルで直接展開しているコードです。deep-chain/ は6ファイルにまたがる JWT 署名検証なしのバグで、1ファイルだけ見ても問題が分からない設計にしました。
実測スコア
/full-scan をテストハーネスに対して実行した結果です。
| 難易度 | Recall | FP Rate |
|---|---|---|
| Easy | 100% | 0% |
| Hard | 100% | 0% |
| Attacker-level | 100% | 0% |
| No-Comment | 100% | 0% |
| 深連鎖(6ファイル) | 100% | 0% |
| フレームワーク挙動依存 | 100% | 0% |
| インフラ設定組み合わせ | 100% | 0% |
全問正解でした。
正直「Hard 以降は何問か落とすだろうな」と思っていたので、少し意外でした。特に deep-chain/ は人間でもファイルを全部開かないと気づけない構造にしたので不安でしたが、問題なく検出しました。
カバレッジの正直な話
3スキルを使えばすべての脆弱性が検出できる、というわけではありません。
| 領域 | カバレッジ |
|---|---|
| コードパターン系(injection, XSS, hardcoded key) | 約 90% |
| 依存関係 CVE | 約 85% |
| HTTP 設定ミス | 約 75% |
| OWASP Top 10 全体 | 約 65〜70% |
| ビジネスロジックの欠陥 | ペネトレーションテスト(人手)が必要 |
AIでカバーできる範囲を自動化して、人間がビジネスロジックのレビューに集中する という役割分担が現実的だと思っています。
最後に
今回やったことをまとめると:
- 1スキルを3スキルに分割して、目的ごとに使い分けられるようにした
- テストハーネスを作って、感覚ではなく数値でスキルの精度を評価できるようにした
- コストを実際に計測して、規模別の目安を出した
-
gh skill対応で1行インストールできるようにした
月$0.8〜1.2で回せるセキュリティ体制として、個人開発や小規模チームでの選択肢になれば嬉しいです。
gh skill install sabakan0123/claude-security-skills
フィクスチャを増やしてくれる PR も歓迎しています。
Discussion