1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@pythonista0328

【実装】Claude Code Skillsでセキュリティスキャナーを自作した - LLMの弱点「p-hacking」をどう克服したか

1
Last updated at Posted at 2026-02-23

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

前回の記事 【速報】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問題に正面から向き合うことは避けて通れない。この記事が同じ課題に取り組む人の参考になれば幸いだ。

関連記事

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

この記事で紹介したセキュリティスキャナーの完全版を公開しています。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・デバッグ・コードレビューの基本ワークフロー → 無料ダウンロード

参考文献

1
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?