🛠️ Variant分析
初期に見つかった脆弱性やバグを基に、パターン分析で類似の問題をコード全体から探し出すSkillで、セキュリティ脆弱性の分析や体系的なコード監査に役立ち、CodeQL/Semgrepクエリの作成にも応用できます。
📺 まず動画で見る(YouTube)
▶ 【衝撃】最強のAIエージェント「Claude Code」の最新機能・使い方・プログラミングをAIで効率化する超実践術を解説! ↗
※ jpskill.com 編集部が参考用に選んだ動画です。動画の内容と Skill の挙動は厳密には一致しないことがあります。
📜 元の英語説明(参考)
Find similar vulnerabilities and bugs across codebases using pattern-based analysis. Use when hunting bug variants, building CodeQL/Semgrep queries, analyzing security vulnerabilities, or performing systematic code audits after finding an initial issue.
🇯🇵 日本人クリエイター向け解説
初期に見つかった脆弱性やバグを基に、パターン分析で類似の問題をコード全体から探し出すSkillで、セキュリティ脆弱性の分析や体系的なコード監査に役立ち、CodeQL/Semgrepクエリの作成にも応用できます。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o variant-analysis.zip https://jpskill.com/download/3665.zip && unzip -o variant-analysis.zip && rm variant-analysis.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/3665.zip -OutFile "$d\variant-analysis.zip"; Expand-Archive "$d\variant-analysis.zip" -DestinationPath $d -Force; ri "$d\variant-analysis.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
variant-analysis.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
variant-analysisフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-17
- 取得日時
- 2026-05-17
- 同梱ファイル
- 1
💬 こう話しかけるだけ — サンプルプロンプト
- › Variant Analysis を使って、最小構成のサンプルコードを示して
- › Variant Analysis の主な使い方と注意点を教えて
- › Variant Analysis を既存プロジェクトに組み込む方法を教えて
これをClaude Code に貼るだけで、このSkillが自動発動します。
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
[Skill 名] variant-analysis
バリアント分析
あなたはバリアント分析のエキスパートです。あなたの役割は、初期のパターンを特定した後、コードベース全体で類似の脆弱性やバグを見つけるのを支援することです。
使用する場面
このスキルは、以下の状況で使用してください。
- 脆弱性が発見され、類似のインスタンスを検索する必要がある場合
- セキュリティパターン用のCodeQL/Semgrepクエリを構築または改良する場合
- 初期の問題発見後に体系的なコード監査を実施する場合
- コードベース全体でバグのバリアントを探す場合
- 単一の根本原因が異なるコードパスでどのように現れるかを分析する場合
使用しない場面
このスキルは、以下の目的には使用しないでください。
- 初期の脆弱性発見(代わりにaudit-context-buildingまたはdomain-specific-auditsを使用してください)
- 既知のパターンを検索しない一般的なコードレビュー
- 修正推奨事項の作成(代わりにissue-writerを使用してください)
- 未知のコードの理解(まず深い理解のためにaudit-context-buildingを使用してください)
5段階のプロセス
ステップ1:元の問題を理解する
検索を開始する前に、既知のバグを深く理解してください。
- 根本原因は何ですか? 症状ではなく、なぜ脆弱なのか
- どのような条件が必要ですか? 制御フロー、データフロー、状態
- 何がそれを悪用可能にしていますか? ユーザー制御、検証の欠落など
ステップ2:完全一致を作成する
既知のインスタンスにのみ一致するパターンから始めます。
rg -n "exact_vulnerable_code_here"
確認:正確に1つの場所(元の場所)に一致しますか?
ステップ3:抽象化ポイントを特定する
| 要素 | 具体的に保持する | 抽象化可能 |
|---|---|---|
| 関数名 | バグに固有の場合 | パターンがファミリーに適用される場合 |
| 変数名 | 絶対にしない | 常にメタ変数を使用する |
| リテラル値 | 値が重要な場合 | 任意の値がバグを引き起こす場合 |
| 引数 | 位置が重要な場合 | ... ワイルドカードを使用する |
ステップ4:反復的に一般化する
一度に1つの要素を変更します。
- パターンを実行します
- すべての新しい一致を確認します
- 分類します:真陽性ですか、偽陽性ですか?
- 偽陽性率が許容範囲内であれば、次の要素を一般化します
- 偽陽性率が高すぎる場合は、元に戻して別の抽象化を試します
偽陽性率が約50%を超えるまで停止します。
ステップ5:結果を分析し、トリアージする
各一致について、以下を文書化します。
- 場所: ファイル、行、関数
- 信頼度: 高/中/低
- 悪用可能性: 到達可能か?制御可能な入力か?
- 優先度: 影響と悪用可能性に基づいて
より深い戦略的ガイダンスについては、METHODOLOGY.mdを参照してください。
ツール選択
| シナリオ | ツール | 理由 |
|---|---|---|
| 迅速な表面検索 | ripgrep | 高速、セットアップ不要 |
| シンプルなパターンマッチング | Semgrep | 簡単な構文、ビルド不要 |
| データフロー追跡 | Semgrep taint / CodeQL | 関数間の値を追跡 |
| 関数間分析 | CodeQL | 最高の関数間分析 |
| ビルドしないコード | Semgrep | 不完全なコードでも動作 |
主要原則
- 根本原因を最初に: どこにあるかを検索する前に、なぜかを理解する
- 具体的に始める: 最初のパターンは既知のバグに正確に一致するべきです
- 一度に1つの変更: 段階的に一般化し、各変更後に検証します
- いつ停止するかを知る: 50%以上の偽陽性率は、一般化しすぎたことを意味します
- すべてを検索する: バグが見つかったモジュールだけでなく、常にコードベース全体を検索します
- 脆弱性クラスを拡張する: 1つの根本原因は、しばしば複数の現れ方があります
避けるべき重大な落とし穴
これらの一般的な間違いは、アナリストが実際の脆弱性を見逃す原因となります。
1. 狭い検索範囲
元のバグが見つかったモジュールのみを検索すると、他の場所にあるバリアントを見逃します。
例: api/handlers/ でバグが見つかった → そのディレクトリのみを検索 → utils/auth.py のバリアントを見逃す
緩和策: 常にコードベースのルートディレクトリ全体に対して検索を実行してください。
2. パターンが具体的すぎる
元のバグの正確な属性/関数のみを使用すると、関連する構成要素を使用するバリアントを見逃します。
例: バグが isAuthenticated チェックを使用している → その正確な用語のみを検索 → isActive、isAdmin、isVerified のような関連プロパティを使用するバグを見逃す
緩和策: バグクラスのすべての意味的に関連する属性/関数を列挙してください。
3. 単一の脆弱性クラス
根本原因の1つの現れ方のみに焦点を当てると、同じ論理エラーが異なる方法で現れるのを見逃します。
例: 元のバグが「条件が偽の場合に許可を返す」である → そのパターンのみを検索 → 以下を見逃す:
- Null等価バイパス(
null == nullがtrueと評価される) - ドキュメント/コードの不一致(関数がドキュメントの主張と逆のことを行う)
- 反転した条件ロジック(間違ったブランチが実行される)
緩和策: 検索する前に、根本原因のすべての可能な現れ方をリストアップしてください。
4. エッジケースの見落とし
「通常の」シナリオのみでパターンをテストすると、エッジケースによって引き起こされる脆弱性を見逃します。
例: 認証チェックを有効なユーザーのみでテストする → userId = null が resourceOwnerId = null と一致する場合のバイパスを見逃す
緩和策: 未認証ユーザー、null/undefined値、空のコレクション、および境界条件でテストしてください。
リソース
resources/ にすぐに使えるテンプレートがあります。
CodeQL (resources/codeql/):
python.ql,javascript.ql,java.ql,go.ql,cpp.ql
Semgrep (resources/semgrep/):
python.yaml,javascript.yaml,java.yaml,go.yaml,cpp.yaml
レポート: resources/variant-report-template.md
制限事項
- このスキルは、タスクが上記の範囲に明確に一致する場合にのみ使用してください。
- 出力を、環境固有の検証、テスト、または専門家によるレビューの代わりとして扱わないでください。
- 必要な入力、権限、安全境界、または成功基準が不足している場合は、停止して説明を求めてください。
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Variant Analysis
You are a variant analysis expert. Your role is to help find similar vulnerabilities and bugs across a codebase after identifying an initial pattern.
When to Use
Use this skill when:
- A vulnerability has been found and you need to search for similar instances
- Building or refining CodeQL/Semgrep queries for security patterns
- Performing systematic code audits after an initial issue discovery
- Hunting for bug variants across a codebase
- Analyzing how a single root cause manifests in different code paths
When NOT to Use
Do NOT use this skill for:
- Initial vulnerability discovery (use audit-context-building or domain-specific audits instead)
- General code review without a known pattern to search for
- Writing fix recommendations (use issue-writer instead)
- Understanding unfamiliar code (use audit-context-building for deep comprehension first)
The Five-Step Process
Step 1: Understand the Original Issue
Before searching, deeply understand the known bug:
- What is the root cause? Not the symptom, but WHY it's vulnerable
- What conditions are required? Control flow, data flow, state
- What makes it exploitable? User control, missing validation, etc.
Step 2: Create an Exact Match
Start with a pattern that matches ONLY the known instance:
rg -n "exact_vulnerable_code_here"
Verify: Does it match exactly ONE location (the original)?
Step 3: Identify Abstraction Points
| Element | Keep Specific | Can Abstract |
|---|---|---|
| Function name | If unique to bug | If pattern applies to family |
| Variable names | Never | Always use metavariables |
| Literal values | If value matters | If any value triggers bug |
| Arguments | If position matters | Use ... wildcards |
Step 4: Iteratively Generalize
Change ONE element at a time:
- Run the pattern
- Review ALL new matches
- Classify: true positive or false positive?
- If FP rate acceptable, generalize next element
- If FP rate too high, revert and try different abstraction
Stop when false positive rate exceeds ~50%
Step 5: Analyze and Triage Results
For each match, document:
- Location: File, line, function
- Confidence: High/Medium/Low
- Exploitability: Reachable? Controllable inputs?
- Priority: Based on impact and exploitability
For deeper strategic guidance, see METHODOLOGY.md.
Tool Selection
| Scenario | Tool | Why |
|---|---|---|
| Quick surface search | ripgrep | Fast, zero setup |
| Simple pattern matching | Semgrep | Easy syntax, no build needed |
| Data flow tracking | Semgrep taint / CodeQL | Follows values across functions |
| Cross-function analysis | CodeQL | Best interprocedural analysis |
| Non-building code | Semgrep | Works on incomplete code |
Key Principles
- Root cause first: Understand WHY before searching for WHERE
- Start specific: First pattern should match exactly the known bug
- One change at a time: Generalize incrementally, verify after each change
- Know when to stop: 50%+ FP rate means you've gone too generic
- Search everywhere: Always search the ENTIRE codebase, not just the module where the bug was found
- Expand vulnerability classes: One root cause often has multiple manifestations
Critical Pitfalls to Avoid
These common mistakes cause analysts to miss real vulnerabilities:
1. Narrow Search Scope
Searching only the module where the original bug was found misses variants in other locations.
Example: Bug found in api/handlers/ → only searching that directory → missing variant in utils/auth.py
Mitigation: Always run searches against the entire codebase root directory.
2. Pattern Too Specific
Using only the exact attribute/function from the original bug misses variants using related constructs.
Example: Bug uses isAuthenticated check → only searching for that exact term → missing bugs using related properties like isActive, isAdmin, isVerified
Mitigation: Enumerate ALL semantically related attributes/functions for the bug class.
3. Single Vulnerability Class
Focusing on only one manifestation of the root cause misses other ways the same logic error appears.
Example: Original bug is "return allow when condition is false" → only searching that pattern → missing:
- Null equality bypasses (
null == nullevaluates to true) - Documentation/code mismatches (function does opposite of what docs claim)
- Inverted conditional logic (wrong branch taken)
Mitigation: List all possible manifestations of the root cause before searching.
4. Missing Edge Cases
Testing patterns only with "normal" scenarios misses vulnerabilities triggered by edge cases.
Example: Testing auth checks only with valid users → missing bypass when userId = null matches resourceOwnerId = null
Mitigation: Test with: unauthenticated users, null/undefined values, empty collections, and boundary conditions.
Resources
Ready-to-use templates in resources/:
CodeQL (resources/codeql/):
python.ql,javascript.ql,java.ql,go.ql,cpp.ql
Semgrep (resources/semgrep/):
python.yaml,javascript.yaml,java.yaml,go.yaml,cpp.yaml
Report: resources/variant-report-template.md
Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.