`raptor` ランチャーはセッションを開始するための推奨方法で、どのディレクトリからでも動作します。RAPTOR のインストール先を解決し、起動したディレクトリを記憶し（`/scan` などのコマンドがそのディレクトリをデフォルトにします）、事前のトラストチェックとプロジェクトチェックを実行し、カバレッジ追跡プラグインを読み込み、Claude Code に引き渡す前に環境をサニタイズします。また、オプションのターゲットパスや `--project`、`--continue`、`--model` などのフラグも受け付けます。詳細は `raptor --help` を参照してください。

リポジトリディレクトリ内から素の `claude` を実行しても動作します。Claude Code はチェックアウトから RAPTOR の設定を読み取りますが、上記のランチャーが行うすべての処理（事前チェック、カバレッジ追跡、および「実行したディレクトリ」をデフォルトとするコマンドの認識）はスキップされます。

**重要:** RAPTOR はリポジトリディレクトリから設定を読み込みます。他のディレクトリから `claude` を実行すると、RAPTOR ではなく素の Claude Code が起動します。`raptor` ランチャーはこの失敗モードを完全に回避します。

### オプション 2: コンテナ内で実行（推奨）

コンテナの使用は、エージェントがアクセスさせたくないファイルシステム領域へのアクセスを制限し、さらに（サプライチェーン攻撃などを通じて）実行される可能性のある悪意のあるコードの爆発半径を制限するための一般的なセキュリティ慣行です。イメージは大きめ（約 6 GB）です。Microsoft Python 3.12 devcontainer をベースにしており、静的解析、ファジング、ブラウザ自動化ツールが追加されています。

事前にビルドされたイメージをプルできます:```bash
docker pull danielcuthbert/raptor:latest

このイメージは、起動時にRAPTORフレームワーク（このリポジトリ）が`/workspaces/raptor`にマウントされることを想定しています。ローカル解析用にターゲットフォルダをオプションでマウントすることもできます。

コンテナを起動するには：```bash
docker run -it \
  -v "$(pwd):/workspaces/raptor" \
  raptor:latest

`--privileged` を追加すると、決定的デバッガ `rr` が必要な場合に使用できます。

VS Code の devcontainer もサポートされています。ターゲットフォルダをマウントするには、`.devcontainer/devcontainer.json` の `mounts` セクションに追加します:```jsonc
"mounts": [
  // ...existing entries...
  "source=/path/to/target-folder,target=/workspaces/target,type=bind,consistency=cached"
]

どちらにせよ、コンテナ内に入ったら、`raptor` を実行して開始します。

---

## 初回実行時に期待されること

最も簡単な操作は次のとおりです:```
/scan /path/to/code

これは完全なパイプラインを実行します:スキャン、重複排除、そして各発見事項を検証ステージ(A〜F)に通します。中規模のコードベースで約50件の発見がある場合、10〜30分と、分析レイヤーのLLMコストとして2〜8ドル(モデルに依存)を見込んでください。デフォルトのコスト上限は実行あたり10ドルで、`--max-cost-usd`で調整できます。

**コストに関する注意:** Claude CodeオーケストレーションレイヤーはClaudeサブスクリプションを使用します。分析ディスパッチレイヤーは、トークンごとに課金される別個のLLM API呼び出しを行います。分析モデルとしてClaude Codeのみを使用する場合(デフォルト)、サブスクリプション以外の追加コストは発生しません。外部モデル(OpenAI、Geminiなど)を設定した場合、それらのAPI呼び出しは各プロバイダーに請求されます。

---

## セキュリティモデル

RAPTORはLLM生成コードを実行し、信頼できないリポジトリを分析します。信頼できないコンテンツを扱うサブプロセスは、Linux名前空間、Landlock、seccompを使用してサンドボックス化されます。サンドボックスはネットワークアクセスをブロックし、ファイルシステムの可視性を制限し、リソース消費を制限します。完全な脅威モデルと設定については`docs/sandbox.md`を参照してください。

ランチャーチェーンにコードを注入する可能性のある環境変数は、起動時に除去されます(`core/security/_dangerous_env_strip.sh`)。スキャンされたリポジトリからのファイルパスがシェル文字列に補間されることは決してありません。すべてのサブプロセス呼び出しはリストベースの引数を使用します。

---

## RAPTORでできること

| コマンド | 機能 | ステータス |
|---------|-------------|--------|
| `/agentic` | 完全自律ワークフロー:スキャン、検証、エクスプロイト、パッチ | 安定版 |
| `/scan` | SemgrepとCodeQLによる静的解析 | 安定版 |
| `/understand` | 攻撃面のマッピング、データフローの追跡、脆弱性バリアントの探索 | 安定版 |
| `/binary` | ブラックボックスバイナリ調査、実行時エビデンス、グラフクエリとハンドオフ | ベータ版 |
| `/ghidra` | Ghidra REブリッジ:`.gpr`プロジェクトのアタッチ/インポート、クロスバージョン差分、発見事項のエクスポート | ベータ版 |
| `/audit` | 仮説駆動型、ツール基盤の体系的なコードレビュー | ベータ版 |
| `/review` | 監査状態のクエリ:発見事項、ギャップ、カバレッジ、オペレーターノート | 安定版 |
| `/annotate` | 関数ごとの自由形式の散文注釈を添付(オペレーターレビューノート) | 安定版 |
| `/validate` | 多段階の悪用可能性検証パイプライン(ステージ0〜F) | 安定版 |
| `/diagram` | `/understand`と`/validate`のJSON出力からのMermaidビジュアルマップ | ベータ版 |
| `/codeql` | SMTデータフロー事前スクリーニングを備えたCodeQLのみの深層解析 | 安定版 |
| `/analyze` | 再スキャンなしで、既存のSARIF発見事項をLLMで分析 | 安定版 |
| `/sca` | ソフトウェア構成分析:依存関係、アドバイザリ、サプライチェーンシグナル、SBOM、修正 | ベータ版 |
| `/cve-diff` | OSV、NVD、GitHub、GitLabにわたるCVEの修正コミットを発見して差分を取る | ベータ版 |
| `/cve-env` | CVEの影響を受けるアプリケーションをパッチ前バージョンで実行するDocker環境を構築・検証 | 実験版 |
| `/exploit` | 概念実証エクスプロイトコードの生成 | ベータ版 |
| `/patch` | 確認された脆弱性に対する安全なパッチの生成 | ベータ版 |
| `/fuzz` | AFL++によるバイナリファジングとクラッシュ分析 | 安定版 |
| `/crash-analysis` | C/C++クラッシュの自律的な根本原因分析 | 安定版 |
| `/oss-forensics` | GitHubリポジトリのエビデンスに基づくフォレンジック調査 | 安定版 |
| `/project` | 名前付きワークスペースで実行を整理し、時間経過に伴う発見事項を追跡 | 安定版 |
| `/describe` | ターゲットの説明:言語構成、ビルドシステム、ツールギャップ、コスト見積もり(読み取り専用) | 安定版 |
| `/threat-model` | プロジェクトごとの脅威モデルの作成、検査、維持 | 安定版 |
| `/sage` | 永続メモリレイヤー(保存、呼び出し、リンク、裏付け) | 安定版 |
| `/ask` | 設定済みの任意のLLMモデルに自由形式のプロンプトを送信 | 安定版 |
| `/scorecard` | 決定クラス全体にわたるモデルごとの信頼性を検査 | 安定版 |
| `/frida` | Fridaによる動的計装 | アルファ版 |
| `/web` | Webアプリケーションスキャン:クロール、ffuf/nuclei統合、オラクル検証済みインジェクション、ブラインドSSRFコールバック | ベータ版 |

---

## パイプラインの仕組み

まずプロジェクトを作成して、すべての実行が1か所にまとまるようにします:```
/project create myapp --target /path/to/code   # create a project first
/project use myapp                             # set it as active
/understand --map                              # map the attack surface
/agentic --threat-model --validate             # map, model, scan, validate
/project findings                              # review everything in one place

`/understand`は、スキャンが1行でも実行される前に、エントリポイント、信頼境界、シンクのコンテキストマップを構築します。次に`/agentic`がSemgrepとCodeQLを実行し、検出結果の重複を排除して、exploitation-validator手法を用いて検証するために各結果をディスパッチします:

`--threat-model`を指定すると、RAPTORはまずマップを実行し、プロジェクトにまだ`threat-model.json`と`THREAT_MODEL.md`が存在しない場合はこれらを作成してから、その簡潔版を`/understand`、自律分析、`/validate`に渡します。既存のプロジェクト脅威モデルは、`--threat-model-refresh`を渡さない限り保持されます。また、`--threat-model-use-stale`を明示的に渡さない限り、古いフォールバックマップは拒否されます。さらに、マッピングされた未チェックのフローを候補SARIFに変換するため、スキャナーの見逃しによって実行が停止することはありません。これはオペレーターが所有するコンテキストであり、魔法の証明ではありません。検出結果には依然としてコードの証拠またはオラクルによる確認が必要です。`docs/threat-model.md`を参照してください。

- ステージA: そのパターンは実際に脆弱性なのか、それともツールのパターンマッチングによるノイズなのか?
- ステージB: 攻撃者がそれに到達するには何が必要で、何が邪魔をするのか?
- ステージC: コードパスは実際に存在するのか? 外部から到達可能か?
- ステージD: 最終判断 -- これはテストコードか、非現実的な前提条件が必要か、モデルが曖昧にしているか?
- ステージE: バイナリ悪用の実現可能性(コンパイル済みアーティファクトが利用可能な場合)
- ステージF: 自己レビュー -- 以前のステージで曖昧にしたり、矛盾したりしていなかったか?

検証を通過した検出結果には、悪用PoCとパッチが生成されます。最後にクロスファインディング分析が実行され、共通の根本原因と攻撃チェーンが特定されます。

`/validate`は、以前のスキャンで検出結果がすでにある場合、この同じパイプラインをスタンドアロンのステップとして実行します。

コンパイル済みアーティファクトの場合、`/binary <path>`は、オペレーターに生のリバースエンジニアリングアーティファクトの山を吐き出すのではなく、証拠優先の調査を実行するようになりました。内部では、ファイルメタデータ、インポート、radare2のxrefから、SHA-256にバインドされたマニフェスト、証拠台帳、コンテキストマップ、チェックリスト、SQLiteグラフを引き続き構築します。Mach-Oアプリでは、スライスインベントリ、バンドルメタデータ、Objective-C / Swiftクラスセレクタも取得されます。高価値の擬似コードは、実行中に消えるのではなく保持されます。PE DLLエクスポート、Windowsドライバーディスパッチャ、Linuxカーネルモジュールのioctlハンドラーも、それぞれ独自のイングレス候補として処理され、PEアーキテクチャは推測ではなくCOFFヘッダーから読み取られます。調査レイヤーはその後、そのグラフをクエリし、一般的なシンクリードよりも外部イングレスを優先し、宣言されたヘルパー/兄弟バイナリを発見し、事実、構造的推論、未証明の仮説に分割された簡潔なレポートを作成します。Fridaの観察結果、ファズクラッシュの証人、明示的なZ3チェック、バイナリ差分は、後でより強力な証拠を追加できます。RAPTORはまた、境界のあるイングレスからパーサーへの候補を復元するために必要な内部コールグラフも保持するため、アプリのコールバックを、`XML_Parse`、`d2i_X509`、`jpeg_read_header`、または別の実際のパーサーサーフェスを実際に呼び出す内部関数に絞り込むことができます。これは、それが汚染の証明であると偽ることなく行われます。`/binary trace-parser <run-dir>`は明示的な動的フォローアップです。狭いFridaパーサートレースを実行し、同じコンテキストマップ、ハンドオフ、グラフ、調査レポートをその場で更新します。`/binary investigate --active`はまずマップを作成し、具体的なハーネス境界が存在する場合にのみ実際のファズキャンペーンを起動します。アプリ、DLL、ドライバーターゲットには、代わりにハーネスまたはスナップショットステップが用意されます。`/binary harness`は、選択されたイングレスに対して証拠に裏付けられたハーネス仕様を作成し、ABIまたはIOCTLコントラクトが明示的な場合にのみ候補ソースを出力します。`memcpy`が存在するからといって「これは悪用可能だ」とごまかすことはありません。インポート、セレクタ、コールエッジは、何か機械的なものがさらに証明するまで候補のままです。`docs/binary-analysis.md`を参照してください。

---

## ソフトウェア構成分析

`/sca`は、プロジェクトの依存関係とサプライチェーン側を分析します。これは単なるrequirementsファイルのCVE検索ではありません。RAPTORは、マニフェスト、ロックファイル、インラインインストールコマンド、ワークフロー依存関係、コンテナ/ベースイメージのパッケージソースを発見し、それらを単一の依存関係ビューに正規化します。

スキャンは、依存関係をOSVアドバイザリ、CISA KEV、EPSS、CISA Vulnrichment/SSVC、到達可能性、悪用証拠シグナル、ハイジーン(衛生)チェック、サプライチェーンヒューリスティック、ライセンスポリシーの検出結果、およびオプションのLLMレビュー/トリアージで強化します。RAPTORネイティブの検出結果に加えて、SBOMとCIフレンドリーな出力を生成します:

- `findings.json` - 標準的なRAPTOR検出結果
- `report.md` - 人間が読める要約
- `sbom.cdx.json` - VEXデータを含むCycloneDX SBOM
- `findings.sarif` - GitHub/GitLabコードスキャン出力

一般的なコマンド:```bash
python3 raptor.py sca --repo /path/to/project
python3 raptor.py sca --repo /path/to/project --no-llm
python3 raptor.py sca --repo /path/to/project --fail-on-severity high --fail-on-kev
python3 raptor.py sca --repo /path/to/project fix
python3 raptor.py sca check PyPI django 4.2.10

キャッシュが設定されると、スキャナはパックIDをローカルファイルに解決し、ネットワーク呼び出しは発生しません。キャッシュがない場合、RAPTORはスキャン時にsemgrep.devからレジストリパックを取得しようとします。オフラインの場合は、キャッシュされていないパックをグレースフルに破棄し、カスタムルールのみで実行します。

CodeQLは、初期セットアップ中にCLIとクエリパックをダウンロードするためにのみネットワークアクセスを必要とします。インストール後はオフラインで実行されます。

---

## カスタムルール

RAPTORには200以上のカスタム静的解析ルールが搭載されており、誤検知を排除するために敵対的にテストされています：

- **Semgrep（145ルール）** — Python、Go、Java、JS/TS向けのテイント追跡およびパターンルール。SQLi、XSS、SSRF、SSTI、コマンドインジェクション、デシリアライゼーション、XXE、LDAP/NoSQLインジェクション、パストラバーサル、オープンリダイレクト、ログ/ヘッダーインジェクション、evalインジェクション、ReDoS、プロトタイプ汚染、JWT設定ミス、弱い暗号化、安全でないTLS、ハードコードされたシークレットをカバーします。
- **Coccinelle（63ルール）** — C/C++向けの構造マッチング。メモリ安全性（二重解放、use-after-free、非ベースポインタの解放、スタック配列の解放、mmapされたメモリ、use-after-close）、整数バグ（オーバーフロー、符号拡張、二重sizeof）、リソースリーク（popen/fcloseの不一致、fdopendirの二重クローズ）、バッファ処理（NULなしのstrncpy、copy_userサイズ不一致、malloc/strlenのオフバイワン）、シグナルハンドラの安全性、APIの誤用（fcntlフラグドメイン、SIGKILL/SIGSTOP、二重バイトスワップ、inet_ntoa静的バッファ）、コンパイラのデッドストア除去、カーネルのIS_ERR/PTR_ERR混同、フォーマット文字列インジェクション、TOCTOU競合など。
- **CodeQL（8クエリ）** — C++（フォーマット文字列インジェクション、整数切り詰め、use-after-move、イテレータ無効化）およびJava（XXE、安全でないデシリアライゼーション、ログインジェクション、Spring SSRF）向けのプロシージャ間テイント追跡。

ルールを直接参照：`engine/semgrep/rules/`、`engine/coccinelle/rules/`、`engine/codeql/queries/`。これらはRAPTORが取り込むSemgrepレジストリパック（`p/security-audit`、`p/owasp-top-ten`、`p/secrets`は常時、ポリシーグループごとのパック（`p/command-injection`、`p/jwt`、`p/xss`など）は追加で）を補完します — 重複は最小限です。

---

## RAPTORが自分自身をチェックする方法

RAPTORは自社のセキュリティツールのかなりの部分をドッグフーディングしていますが、実際にPRをブロックするものと、単にバックグラウンドで実行されて誠実さを保つものについて正直に述べる価値があります。一部はハードゲートであり、一部はスケジュールされたチェックであり、一部は状況が悪化したことを検知するために保持している単なるベンチマークです。実際のパラメータやチェックの再現方法を含む詳細な内訳は、`docs/ci-controls.md`にあります。

| コントロール | チェック内容 | トリガー | 設定 / 証拠 |
|---|---|---|---|
| Ruff | Pythonの正確性リンティング（`F401`、`F811`、`F821`、`F841`） | PR差分ゲート、および毎週の全ツリー監査 | `pyproject.toml`、`.github/workflows/lint.yml` |
| Pytest | 高速なユニット/統合境界、サブシステム固有の階層（インポートグラフディスパッチ経由）、プロンプトエンベロープ監査 | PR、`main`へのプッシュ、マージキュー、スケジュールされた完全スイート | `pytest.ini`、`.github/workflows/tests.yml`、`.github/workflows/nightly.yml` |
| CodeQL Advanced | インポートグラフスコープの絞り込みによるPython、C/C++、GitHub Actionsのコードスキャン | PR、`main`へのプッシュ、マージキュー、毎週のスケジュール | `.github/workflows/codeql.yml`、`.github/codeql/codeql-config.yml` |
| ワークフローハードニング | SHAピン留めされたサードパーティActions、最小権限のパーミッション、コマンドメタデータのリンティング | すべてのワークフロー変更およびすべてのリント実行 | `.github/workflows/`、`.github/scripts/check_command_metadata.py` |
| コーパスラベルリント | コーパスラベルスキーマ検証とアップストリームピン検証の監査 | PR（変更されたラベル）、毎週の完全スイープ | `.github/workflows/corpus-labels.yml` |
| RAPTOR SCA PRゲート | PRによって導入された依存関係およびサプライチェーンの回帰 | マニフェスト / ロックファイル / ワークフロー変更 | `.github/workflows/sca-pr-gate.yml` |
| RAPTOR SCA自己バンプ | 機械的な依存関係のハードニングと安全なアップグレード提案 | 毎週のスケジュール、手動実行 | `.github/workflows/sca-self-bump.yml` |
| SCA侵害コーパス | 既知の依存関係侵害が期待されるシグナルを依然としてトリガーするかどうか | 毎週のスケジュール、関連するPR変更 | `test/data/sca-e2e/compromise-corpus/`、`.github/workflows/sca-compromise-check.yml` |
| 誤配線スキャン | デッドコード / 誤呼び出し検出、環境変数ドキュメントの乖離、語彙リストのガードレール、オプション依存インポートのリント | 毎日のスケジュール | `.github/workflows/miswiring-scan.yml`、`.github/scripts/*_baseline.json` |
| SCAキャリブレーション + ストレスコーパス | リスクスコアリングとパーサーカバレッジが時間とともにドリフトするかどうか | 毎週 / 毎月のスケジュールジョブ | `packages/sca/data/calibration/`、`.github/workflows/refresh-sca-calibration.yml`、`.github/workflows/sca-stress-sweep.yml` |
| データフローコーパス | バリデータ動作の精度 / 再現率 / FPカテゴリ追跡 | 開発者実行のベンチマークおよびコーパステスト | `core/dataflow/corpus/`、`core/dataflow/scripts/corpus-metrics` |
| CIコントロールドキュメントガード | 文書化されたパスが存在する、ruff設定が一致する、READMEがドキュメントにリンクしている | PR | `.github/tests/test_ci_controls_docs.py` |

現在強制されていないもの：`mypy`は`requirements-dev.txt`にインストールされていますが、何もブロックしません。Ruffフォーマットは強制されていません。SemgrepはRAPTORのスキャナーサーフェスの一部ですが、専用の「RAPTORでRAPTORをスキャンする」Semgrepワークフローはまだありません。

---

## 別のLLMを使用する

RAPTORには2つの独立したモデルレイヤーがあり、何かを変更する前に両方の仕組みを理解しておく価値があります。

**オーケストレーションレイヤー**は常にClaude Codeです。CLAUDE.md、スキル、コマンドはすべてClaude Codeの指示として実行されます。RAPTORをオーケストレーションするClaudeモデルを変更するには、Claude Codeの`--model`フラグまたはセッション内の`/model`コマンドを使用します。

**分析ディスパッチレイヤー**は、個々の脆弱性の発見を分析するLLMです。これはオーケストレーションレイヤーとは別であり、サポートされている任意のプロバイダーにすることができます。`~/.config/raptor/models.json`で設定します：```json
{
  "models": [
    {
      "provider": "anthropic",
      "model": "claude-opus-4-6",
      "api_key": "sk-ant-...",
      "role": "analysis"
    },
    {
      "provider": "openai",
      "model": "gpt-5.4",
      "api_key": "sk-...",
      "role": "analysis"
    },
    {
      "provider": "anthropic",
      "model": "claude-sonnet-4-6",
      "api_key": "sk-ant-...",
      "role": "aggregate"
    }
  ]
}

| ロール | 役割 |
|------|-------------|
| `analysis` | 各検出結果を検証・分析します（ステージA〜F） |
| `code` | エクスプロイトPoCとパッチコードを作成します |
| `consensus` | 真陽性に対するセカンドオピニオン投票を行います |
| `aggregate` | 任意。決定論的なマルチモデル相関の上にLLMによるナラティブ統合を書き、`aggregation.json`と最終的な`agentic-report.md`に出力します |
| `fallback` | プライマリモデルが失敗した場合やレート制限に達した場合に使用されます |

ロールが設定されていない場合、リスト内の最初のモデルがすべてを処理します。マルチモデル
ソースコード分析では、2つ以上の`analysis`モデルを設定してください。デフォルトで
決定論的な相関が得られます。`aggregate`ロールは任意で、その上に
LLMによる要約を追加します。```bash
python3 raptor.py agentic --repo /code \
  --model claude-opus-4-6 \
  --model gpt-5.4 \
  --aggregate claude-sonnet-4-6

Ollamaは分析には機能しますが、信頼性の低いエクスプロイトコードやパッチコードを生成します。コード生成タスクには、フロンティアモデルを使用してください。

### 高速ティアのショートサーキット + モデルスコアカード

分析ティアのモデルに、同じプロバイダーのより安価な兄弟モデルがある場合（Anthropic Opus → Haiku、OpenAI 5.x → 4o-mini、Gemini Pro → Flash-Lite、Mistral Large → Small）、RAPTORはそれをサブストレートに接続するコンシューマー（現在はcodeql、SCAやその他は今後追加予定）のプリフィルターとして使用します。安価なモデルは**確信度の高い誤検知**の場合にのみショートサーキットします。曖昧なケースと確信度の高い真陽性は常に完全な分析が実行されます。信頼度は`(model, decision_class)`セルごとに蓄積されます。RAPTORは安価なモデルと完全なモデルの一致を記録し、セルの見逃し率に対するWilson 95%上限が5%以下に達した場合にのみショートサーキットします。

モデルが何に優れているかを確認するには、`/scorecard`を使用します（または直接`libexec/raptor-llm-scorecard list`）。スコアカードはグローバル（教訓はプロジェクト間で引き継がれます）で、`out/llm_scorecard.json`に永続化されます。

---

## プロジェクト

プロジェクトがない場合、各実行は`out/`配下に独自のタイムスタンプ付きディレクトリを取得します。プロジェクトがある場合、すべてが1つの場所にまとめられ、マージされた検出結果、カバレッジ追跡、実行間の差分を取得できます。```bash
/project create myapp --target /path/to/code -d "Short description"
/project use myapp

/scan
/understand --map
/validate

/project status                # all runs, pass/fail, timestamps
/project findings              # merged findings across all runs
/project findings --detailed   # per-finding detail
/project coverage --detailed   # which files were reviewed
/project diff myapp run1 run2  # compare two runs
/project report                # full merged report
/project clean --keep 3        # remove old runs, keep the last 3
/project export myapp /tmp/myapp.zip
/project none                  # clear active project

分割により、PythonレイヤーをCIパイプラインから実行し（`python3 raptor.py scan --repo ...`）、Claude Codeなしで構造化されたSARIF出力を取得できます。また、完全なエージェント型ワークフローで対話的に実行することもできます。

---

## OSSフォレンジック

`/oss-forensics`は、複数のソースからの証拠を用いて公開GitHubリポジトリを調査します：GitHub API、GH Archive（BigQuery経由の不変イベント履歴）、Wayback Machine、およびローカルのgit履歴です。証拠収集から仮説形成、最終的なフォレンジックレポートまでの構造化されたパイプラインを実行します。

BigQueryアクセスには`GOOGLE_APPLICATION_CREDENTIALS`が必要です。詳細は`.claude/commands/oss-forensics.md`を参照してください。

---

## エキスパートペルソナ

7つのエキスパートペルソナがオンデマンドで利用可能です。調査結果や特定の技術について別の視点が必要な場合は、いずれかをロードしてください：```
Exploit Developer (Mark Dowd)                  Exploit PoC generation
Crash Analyst (Charlie Miller / Halvar Flake)  Crash analysis and exploitability assessment
Security Researcher                            General adversarial code review
Patch Engineer                                 Secure fix generation
Penetration Tester                             Realistic attack scenario assessment
Fuzzing Strategist                             Corpus design and triage
Binary Exploitation Specialist                 ROP, heap, and memory corruption