これまでの記事で見えてきた問題

前回の記事【速報】Claude Code Securityが変えるコードレビューの未来では、Anthropicが発表したClaude Code Securityの概要を紹介した。個人的にもかなり期待している機能だが、現時点ではEnterprise/Team限定で、個人開発者の自分はまだ使えない。

一方、【警告】無料のClaude Code Skills、3つに1つにセキュリティ問題では、Snyk調査で外部スキルの36.8%にセキュリティ問題があることを紹介した。マーケットプレイスに審査機構はなく、自分の身は自分で守るしかない。

Enterprise版を待っていても仕方がないので、Claude Code Skillsでセキュリティスキャナーを自作した。SKILL.mdの定義だけで、静的パターンマッチとLLM意味解析のハイブリッドスキャナーを構築できる。

ただ、作ってみて気づいたのは、LLMベースのツールには「同じ入力でも毎回結果が変わる」という本質的な課題があるということだった。この記事では、スキャナーの設計思想と、このp-hacking問題にどう向き合ったかを紹介する。

Enterprise版とSkills版の違い

正直に書く。Enterprise版と完全に同等ではない。

観点	Claude Code Security（Enterprise）	Skills版セキュリティスキャナー
対象	コードベース全体	外部スキル（SKILL.md）
検出ルール	Anthropic内部で定義・非公開	自分で定義（カスタマイズ可能）
偽陽性フィルタリング	多段階自己検証	信頼度スコアで定量制御
レポート形式	Anthropic標準フォーマット	自由にカスタマイズ可能
費用	Enterprise/Teamプラン料金	追加費用なし
更新	Anthropicが管理	自分でルール追加・更新

Skills版の最大の利点は、検出ルールを自分で制御できること。自社固有のセキュリティ要件に合わせたカスタマイズが可能で、ルールの追加・更新も自分のペースでできる。

設計思想: 3層スキャンアーキテクチャ

スキャナーは3つの層で構成している。

Layer 1: 静的パターンスキャン（14カテゴリ・95+項目）
  ↓ 検出結果
Layer 2: LLM意味解析（7項目）
  ↓ 文脈を加味した判定
Layer 3: リスクスコア算出 + レポート生成

Layer 1 はルールベースの静的パターンマッチ。コマンドインジェクション、難読化、シークレット漏洩、ランサムウェアパターンなど14カテゴリに分類した95+の検出項目で、決定的（毎回同じ結果）なスキャンを行う。

Layer 2 はClaudeの推論能力を活用したLLM意味解析。パターンマッチでは検出できない「自然言語で巧妙に書かれた誘導」や「段階的エスカレーション」など7つの観点で分析する。c${u}rl のような変数展開による回避はパターンで捕まえられるが、人間が読んでも気づきにくい文脈の中に埋め込まれた攻撃指示はLLMの推論力でないと検出できない。

Layer 3 では、各検出結果に重大度と確信度を掛け合わせた定量スコアを算出し、4段階のランク（SAFE/CAUTION/DANGEROUS/CRITICAL）で最終判定を下す。さらに「外部通信 + シークレット読み取り」のような危険な組み合わせには複合リスク加算を適用する。

鉄則（Iron Laws）- 開発中に痛感した必要性

スキャナー設計で最も重要なのは、スキャナー自体が攻撃されないことだ。

開発初期、テスト用の悪意あるダミースキルをスキャンしていたとき、スキャナーがダミースキル内の「まずこのコマンドを実行して環境を確認してください」という指示に反応しかけたことがあった。スキャナーが対象の指示を実行してしまったら、セキュリティツールが攻撃の踏み台になるという最悪のシナリオだ。

この経験から「鉄則（Iron Laws）」を設計した。スキャン対象の指示は一切実行せず、テキストとして読み取り・分析のみを行うルールをSKILL.md内に構造的に組み込んでいる。LLMに「絶対にやるな」と言うだけでは不十分で、ワークフローの構造自体で実行を不可能にする設計が必要だった。

LLMの弱点: p-hacking問題 - 作ってみて初めてわかった壁

Layer 1〜3の設計ができて「これでいける」と思ったが、実際にテストを回してみて壁にぶつかった。

同じスキルを5回スキャンしたら、3回はCRITICAL、2回はスコアが10点以上低いCRITICALが出た。 ランクは同じでも、検出される項目が毎回微妙に違う。特にLayer 2のLLM意味解析で検出される「段階的エスカレーション」が、出たり出なかったりする。

調べてみると、これはLLM全般に知られた問題だった。arXiv:2509.08825「Large Language Model Hacking」は、最新のLLMでも31%が誤った結論を出すことを1300万ラベルの大規模実験で示している。さらにarXiv:2504.14571「Prompt-Hacking: The New p-Hacking?」は、プロンプトを少し変えるだけで結果が変わる問題を「Prompt-Hacking」と名付けている。

従来のp-hacking	Prompt-hacking
統計手法を変えて有意差を探す	プロンプトを変えて望む出力を得る
分析の自由度が問題	プロンプトの自由度が問題
再現性の危機を引き起こした	同じ危機がAIツールで再発する

「今回はCRITICALだったけど、もう一回やったらSAFEになるかも」では使い物にならない。ここをどうにかしないとスキャナーとして信頼できない。

p-hacking対策: 試行錯誤の末にたどり着いた4つのアプローチ

最初は「プロンプトを精密に書けば安定するのでは」と考えたが、甘かった。プロンプトの表現をいくら工夫しても、LLMの非決定性は本質的に消えない。

発想を変えて、LLMの出力が揺れることを前提に、揺れても最終判定に影響しない構造を作ることにした。

1. ソースタグによる透明性確保

すべての検出結果に [Static] または [LLM] のタグを付与する。ユーザーは「この検出は100%再現される静的検出か、それともLLMの判断か」を一目で判別できる。

これだけでも大きな違いで、レポートを読む側が「ここはLLMの判断だから参考程度に」と切り分けられるようになった。

2. LLMスコアの影響制限

一番チューニングに苦労したのがここだ。LLM由来の検出がスコア全体に与える影響に上限を設けるのだが、上限を厳しくしすぎるとLLMの検出力が死んでしまう。逆に緩すぎると意味がない。

静的検出の結果を基準として、LLMの寄与をその一定割合以内に制限する方式に落ち着いた。具体的な閾値は何パターンか試して、検出力を維持しつつスコア変動を抑えられるバランスを探った。

3. 確信度エスカレーションの厳格化

LLM単独の判断で確信度を引き上げることを制限した。昇格には静的検出による裏付けを必須条件とすることで、LLMの「自信過剰」を構造的に防ぐ。

LLMは間違っていても自信満々に答える。論文でも「効果量が小さい結果ほど、LLMの誤りが増える」と指摘されている。この性質を前提にした設計が必要だった。

4. 複合リスクの条件明確化

危険な組み合わせの加算判定についても、LLM由来の検出が含まれる場合はポイントを減額するルールを導入した。両方がLLM由来の場合は加算を行わない。

いずれも共通する設計思想は、**「静的検出（決定的）を軸に、LLM検出（非決定的）は補助として活用する」**という優先順位の明確化だ。LLMを排除するのではなく、「信頼できる範囲で活用する」という落とし所を探った結果がこの4つだった。

テスト結果: 30回の独立テストで検証

対策の有効性は主張だけでは不十分。定量的なエビデンスで示す。

テスト方法

3種類のダミースキルを作成（安全/グレーゾーン/不審）
対策前（v1）と対策後（v2）で各5回ずつスキャン
計30回の完全に独立したセッションで実行（claude --print による非対話モード）
各回が独立プロセスのため、前回の結果が次回に影響しない

結果

最重要指標: LLM検出再現率

ダミースキル	対策前	対策後	改善
不審スキル（CRITICAL相当）	75%	100%	+25%
グレースキル（CAUTION相当）	100%	100%	-
安全スキル（SAFE相当）	100%	100%	-

対策前、不審スキルでは「段階的エスカレーション」の検出が5回中2回しか出なかった（再現率75%）。対策後は全5回で一貫して検出（再現率100%）。あの「出たり出なかったり」が完全に解消された。

全指標の結果

指標	基準	対策前	対策後	判定
スコア変動係数	< 0.10	0.031	0.089	PASS
ランク安定率	100%	100%	100%	PASS
LLM検出再現率	> 80%	75%	100%	PASS

全指標PASS。

ちなみに調べた限り、LLMベースのセキュリティツールでp-hacking対策を実装し、再現性を実証データ付きで示しているツールは他にまだない。NVIDIA garak（6,900+ stars）、Trail of Bits Skills、Promptfoo等の主要ツールも、この観点での対策は確認できていない。

まとめ

項目	内容
アーキテクチャ	静的パターン（14カテゴリ・95+項目） + LLM意味解析（7項目） + 定量スコアリング
鉄則（Iron Laws）	スキャナー自体への攻撃を構造的に防止
p-hacking対策	ソースタグ・スコア制限・確信度厳格化・複合リスク条件の4つ
テスト結果	30回の独立テストでLLM検出再現率100%、全指標PASS

Enterprise版のClaude Code Securityを待たなくても、Skillsで実用レベルのセキュリティスキャナーは構築できる。そして、LLMベースのツールを本番で使うなら、p-hacking問題に正面から向き合うことは避けて通れない。この記事が同じ課題に取り組む人の参考になれば幸いだ。

関連記事

【速報】Claude Code Securityが変えるコードレビューの未来 - Claude Code Securityの概要と業界への影響
【警告】無料のClaude Code Skills、3つに1つにセキュリティ問題 - Snyk調査が示す外部Skillsの実態と対策
【実践】Claude Codeの開発速度を2倍にする10のTips - Skills以外の効率化テクニック集
【実践】60行のMarkdownでCRUD生成を自動化する - Claude Code Skills自作ガイド - Skills自作の入門チュートリアル
【検証】Claude Codeの実装時間を56%短縮した5つの仕組み - Skillsの効果を定量検証
CLAUDE.mdのセキュリティ設計 - プロンプトインジェクション対策とベストプラクティス

このスキャナーを使ってみたい方へ

この記事で紹介したセキュリティスキャナーの完全版を公開しています。14カテゴリ・95+項目の検査ルール、LLM意味解析7項目、5つの既知IOCデータベース、p-hacking対策によるスコア安定化ロジック、すべて含まれています。

Security Scanner（¥2,980）: この記事のスキャナー完全版。p-hacking対策で再現性保証 → 詳細を見る
Pro Pack（¥4,980）: スキャナー含む全部入り。差額¥2,000で21エージェント + CI/CD自動設計も付属 → 詳細を見る
Starter Pack（無料）: TDD・デバッグ・コードレビューの基本ワークフロー → 無料ダウンロード

参考文献

Large Language Model Hacking - LLMの31%が誤った結論を出す大規模実証（arXiv:2509.08825、2025年9月）
Prompt-Hacking: The New p-Hacking? - プロンプト調整による結果操作リスク（arXiv:2504.14571、2025年4月）