audit-full

コードベース全体の監査

Opus 5.5の拡張コンテキストウィンドウを活用した、プロジェクト全体を一度に分析する手法です。コードベース全体（約50K LOC）をコンテキストに読み込み、ファイルをまたいだ脆弱性の検出、アーキテクチャのレビュー、依存関係の分析を行います。

クイックスタート

audit-full                          # Full audit (all modes)
audit-full security                 # Security-focused audit
audit-full architecture             # Architecture review
audit-full dependencies             # Dependency audit

Opus 5.5：コードベース全体を対象に拡張思考を行うため、complexity: maxを使用します。Opus 5.5のコンテキストは100万トークン（デフォルトかつ最大）で、チャンク分割方式では見落とされるファイル横断の推論が可能になります。effortは明示的に設定してください。Opus 5.5自体のデフォルトはmedium（Opus 5のhighより1段階低い値）であり、CC 2.1.280以降では、新しくリリースされたモデルは以前に保存された/effortレベルではなく、モデルのデフォルトで開始します。監査はhighで実行してください。最も難しいコードベースでは、ファイル横断パターンを追加で1回精査するためにxhighを使用します。

100万トークンのコンテキストが必要です： CLAUDE_CODE_DISABLE_1M_CONTEXTが設定されている場合、audit-fullはコードベース全体の分析を実行できません。echo $CLAUDE_CODE_DISABLE_1M_CONTEXTで確認してください。空でない場合は、設定を解除する（unset CLAUDE_CODE_DISABLE_1M_CONTEXT）か、代わりにチャンク分割分析を行うverifyを使用してください。

Effort（CC 2.1.111以降）： xhighでは2回目のパスを追加し、1回目のパスで見慣れたものとして見過ごされたパターンを探すため、モジュール間の境界を再確認します。xhighは最も難しいコードベースに限って使用してください（デフォルトについては上記のOpus 5.5に関する注記を参照）。他のモデルでは警告なしにhighへフォールバックし、doctorが不一致を警告します。

Opusへの切り替え（CC 2.1.144以降）： /modelは現在のセッションにのみ適用されるようになったため、この監査ではOpusを選択しても、その設定が引き継がれることはありません。新しいセッションのデフォルトにも設定したい場合に限り、ピッカーでdを押してください。

---

STEP 0：AskUserQuestionでユーザーの意図を確認する

タスクを作成する前に、対話型ダイアログを使って監査範囲を明確にしてください。

読み込み：モードの選択肢（Full/Security/Architecture/Dependencies）と範囲の選択肢（コードベース全体/特定のディレクトリ/変更されたファイル）を含む、AskUserQuestionの完全なダイアログについては、Read("references/audit-scope-dialog.md")を参照してください。

---

重要：タスク管理は必須です

# 1. Create main task IMMEDIATELY
TaskCreate(
  subject="Full-codebase audit",
  description="Single-pass audit using extended context",
  activeForm="Running full-codebase audit"
)

# 2. Create subtasks for each phase
TaskCreate(subject="Estimate token budget and plan loading", activeForm="Estimating token budget")  # id=2
TaskCreate(subject="Load codebase into context", activeForm="Loading codebase")                    # id=3
TaskCreate(subject="Run audit analysis", activeForm="Analyzing codebase")                          # id=4
TaskCreate(subject="Generate audit report", activeForm="Generating report")                        # id=5

# 3. Set dependencies for sequential phases
TaskUpdate(taskId="3", addBlockedBy=["2"])  # Loading needs budget estimate
TaskUpdate(taskId="4", addBlockedBy=["3"])  # Analysis needs codebase loaded
TaskUpdate(taskId="5", addBlockedBy=["4"])  # Report needs analysis done

# 4. Update status as you progress
TaskUpdate(taskId="2", status="in_progress")  # When starting
TaskUpdate(taskId="2", status="completed")    # When done — repeat for each subtask

---

STEP 1：トークン予算を見積もる

ファイルを読み込む前に、コードベースがコンテキストに収まるかどうかを見積もってください。

読み込み：見積もりルール（ファイルの種類ごとの1行あたりのトークン数）、予算配分表、自動除外リスト、コードベースが予算を超えた場合のフォールバックダイアログについては、Read("references/token-budget-planning.md")を参照してください。

見積もりを実行：bash ${CLAUDE_SKILL_DIR}/scripts/estimate-tokens.sh /path/to/project

2つのティア — 見積もりに応じて選択

audit-fullには2つの実行ティアがあります。どちらを使うかは見積もりで決まります。

見積もりと予算の比較	ティア	パス
予算内（約≤125K LOC／≤100万トークン）	シングルコンテキスト（デフォルト — このスキルの強みである、1つのウィンドウ内でのコードベース全体にわたるファイル横断推論）	STEP 2へ進む
予算超過	マップリデュース（スケールティア — シャード分割 → シャードごとの監査 → シャード間境界の統合 → 反証）	以下のワークフローを実行し、STEP 2〜3.5はその内部で実行する

予算超過時 → マップリデュースのワークフローを実行する（中断したり、読み込みを黙って切り詰めたりしないでください）。

# Derive shards from STEP 1 (top-level modules/dirs by size: src, apps/api, apps/web, packages/*).
Workflow({
  "scriptPath": "${CLAUDE_SKILL_DIR}/workflows/audit-full-mapreduce.js",
  "args": { "shards": ["<repo-relative dirs>"], "mode": "<full|security|architecture|dependencies>", "effort": "<high|xhigh>" }
})

この方法では各シャード内のファイル横断推論を維持し、専用の統合パスでシャードをまたぐ関係（モジュール間にまたがるtaint/auth/dep-direction）を見つけたうえで、同じSTEP 3.5の敵対的反証を行います。その結果（統合された検出結果と反証台帳）をSTEP 4に渡します。リポジトリが予算内に収まる場合、シングルコンテキストティアはより低コストで、境界を見落とさないため、引き続きデフォルトです。マップリデュースは、実際に予算を超える場合にのみ使用してください。

**ファンアウトのルール：**選択されたモードが全範囲の網羅である場合、予算超過のリポジトリに対して単一パスをフォールバックとして使うことはできません。マップリデュースのWorkflow呼び出しが実行されなかった場合は、実行をBLOCKEDとして終了し、その理由を伝えてください。切り詰めた読み込みで監査を行ってはなりません。ディレクトリの範囲指定や優先読み込みなど、意図的に読み込み範囲を狭めるモードをユーザーが選んだ場合、それは明示された範囲の縮小であり、読み込みの切り詰めではありません。

ステップ 2：コードベースをコンテキストに読み込む

読み込み戦略、言語別（TS/JS、Python、Config）の対象パターン、バッチ読み込みパターンについて、Read("references/report-structure.md") を読み込みます。

---

ステップ 3：監査分析

コードベースを読み込んだら、選択した監査モードを実行します。

セキュリティ監査

チェックリスト全体について、Read("references/security-audit-guide.md") を読み込みます。

ファイルをまたぐ分析の主なパターン：

1. データフローの追跡：エントリポイント → 処理 → 保存の順にユーザー入力を追跡します
2. 認証境界の検証：保護されたすべてのルートで認証が確認されることを確かめます
3. シークレットの検出：ハードコードされた認証情報、API キー、トークンをスキャンします
4. インジェクションの攻撃対象面：ファイル境界をまたいで SQL、コマンド、テンプレートのインジェクションを調べます
5. OWASP Top 10 へのマッピング：検出事項を OWASP カテゴリに分類します

アーキテクチャレビュー

ガイド全体について、Read("references/architecture-review-guide.md") を読み込みます。

主な分析パターン：

1. 依存関係の方向性：インポートが内側へ向かっていること（クリーンアーキテクチャ）を確認します
2. 循環依存：モジュール間のインポートサイクルを検出します
3. レイヤー違反：コントローラー内のビジネスロジック、ルート内の DB 処理などを検出します
4. パターンの一貫性：コードベース内で同じ問題が異なる方法で解決されていないか確認します
5. 結合度の分析：モジュール間のインポート数を数え、密結合を特定します

依存関係の監査

ガイド全体について、Read("references/dependency-audit-guide.md") を読み込みます。

主な分析パターン：

1. 既知の CVE：バージョンを既知の脆弱性と照合します
2. ライセンスコンプライアンス：プロプライエタリコードに含まれるコピーレフトライセンスを特定します
3. バージョンの最新性：大幅に古い依存関係にフラグを立てます
4. 推移的リスク：深い依存関係チェーンを特定します
5. 未使用の依存関係：インストールされているものの、一度もインポートされていないパッケージを検出します

段階的な出力（CC 2.1.76）

各監査モードが完了するたびに、検出事項を段階的に出力します。レポートが完成するまでまとめて出力しないでください。

1. セキュリティの検出事項を最初に出力 — 重大度が Critical または High の脆弱性をすぐに示し、アーキテクチャレビューを待たないでください
2. アーキテクチャの検出事項 — 依存関係の方向性違反や循環依存を、見つかり次第示します
3. 依存関係の検出事項 — CVE との一致やライセンスコンプライアンスの問題を示します

複数モードの監査（Full）では、各モードの検出事項を完了次第出力します。これにより、アーキテクチャ分析の実行中でも、ユーザーは重大なセキュリティの検出事項に対応できます。

---

ステップ 3.5：敵対的反証（労力に応じて実施）

レポート作成前に、別のブラインド反証者が CRITICAL/HIGH の検出事項を検証します。これは、自己優遇バイアス（単一コンテキストの処理が自身の検出事項を採点すると、独自の推論に引きずられること）を構造的に修正するためのものです。low/medium ではこの手順を省略し、high では単一の助言型反証者を実行し、xhigh ではエンジンの定足数（CRITICAL には 3、HIGH には 2）を実行します。

プロトコルと audit-full バインディングを読み込みます：Read("references/adversarial-refutation.md")（共有エンジン ${CLAUDE_PLUGIN_ROOT}/shared/rules/adversarial-refutation.md を読み込みます）。

これらの反証者は、audit-full で起動する唯一のサブエージェントです（生成側は単一コンテキストです）。常に team_name を指定せず、独立した Agent(...) として起動し、中立的な主張（カテゴリ + file:line）のみを渡します。決定論的なグラウンドトゥルースは対象外です。CVE/CVSS の一致、ビルド／テストの失敗、型エラーは反証の対象になりません。反証されるのは、CVE に加えられた到達可能性の主張のみです。反証者が限定された範囲から再現できないファイル横断の検出事項は、UPHELD のままです（エンジン §5）。反証によって CRITICAL が黙って削除されることはありません。台帳（refutation-ledger.json）には、維持／棄却／格下げが記録されます。また、レポートから CRITICAL/HIGH を削除するにはユーザーの確認が必要です。

---

ステップ 4：レポートを生成

レポートテンプレートを読み込みます：Read("assets/audit-report-template.md")。

レポートの構成と重大度の分類については、検出事項テーブルの形式、重大度の内訳（CRITICAL/HIGH/MEDIUM/LOW と対応期限）、アーキテクチャ図の規則を確認するため、Read("references/report-structure.md") を読み込みます。

重大度マトリックス：分類基準について、Read("assets/severity-matrix.md") を読み込みます。

完了チェックリスト

レポートを確定する前に、Read("checklists/audit-completion.md") で確認してください。

完了時の PushNotification（CC 2.1.110 以降）

コードベース全体を対象とする 1M コンテキストの監査は、中規模のプロジェクトで通常 15〜60 分かかり、大規模なプロジェクトではそれ以上になることがあります。レポートファイルを書き込み、完了チェックリストに合格したら、PushNotification を呼び出してください。ユーザーが席を外していても、検出件数が確認できます。

PushNotification(
  message=f"ork:audit-full complete — {SCOPE}: {critical}C/{high}H/{medium}M/{low}L · {report_path}",
  status="proactive"
)

詳細ルール：Read("${CLAUDE_PLUGIN_ROOT}/skills/chain-patterns/rules/push-notification-on-completion.md")。

---

使用しない場合

状況	代わりに使用
小規模で対象を絞った確認（1〜5 ファイル）	直接 Read + 分析
CI/CD による自動スキャン	security-scanning スキル
複数エージェントによる段階評価付き検証	verify
不慣れなコードベースの調査	explore
コードベースが 125K LOC を超える（1M を超過）	ここで続けてください — STEP 1 で map-reduce の段階（workflows/audit-full-mapreduce.js）に進みます。監査の代わりに複数エージェントによる段階評価付き検証を行いたい場合に限り、verify を使用してください

---

コードベース全体を対象とする監査についての注意事項

サイズの大きい読み込み（CC 2.1.144 以降）： 大きなファイルを読み込む際、ファイル全体を読み取るとトークン制限を超える場合、Read は重大なエラーを返す代わりに、先頭ページを切り詰めた [PARTIAL view] を返します。この通知を確認し、明示的な offset／limit を指定して再読み込みし、残りを順に確認してください。部分的な読み込みでは、監査で見落としてはならないコードが通知なしに省略されます。

コンテキストがいっぱいになった場合（CC 2.1.141 以降）： 監査をやり直すのではなく、巻き戻しメニューの「ここまでを要約」を使って、直近の検出結果を残したまま、それ以前のターンを圧縮してください。リアクティブな圧縮（CC 2.1.142 以降）では、最初の要約のサイズが実際の超過量に合わせて調整されるため、ターンの途中で無駄な 2 回目の処理が発生することはまれになりました。

---

/goal を使用した無人実行

/goal（CC 2.1.139 以降）で完了条件を設定すると、このスキルは条件が満たされるまでターンをまたいで動作し続けます。インタラクティブモード、-p、Remote Control で動作します。オーバーレイパネルには経過時間、ターン数、トークン数がリアルタイムで表示されます。

このスキルの完了条件の例：

/goal until findings.critical == 0 OR no_new_critical_for_3_turns, or stop after 30 turns

次の場合に停止します：3 回連続のパスで重大な問題が 0 件になる、または構造上のアンチパターンの上限に達する。claude.ai Remote Control での実行にも対応しています。

---

関連スキル

• security-scanning — 自動スキャナーとの統合（npm audit、Semgrep など）
• ork:security-patterns — セキュリティアーキテクチャのパターンと OWASP 脆弱性の分類
• ork:architecture-patterns — アーキテクチャパターンのリファレンス
• ork:quality-gates — 品質評価基準
• ork:verify — 複数エージェントによる検証（1M コンテキストを超えるコードベース向けの代替手段）

リファレンス

Read("references/<file>") で必要に応じて読み込んでください：

ファイル	内容
references/security-audit-guide.md	ファイルをまたぐ脆弱性パターン
references/architecture-review-guide.md	パターンと結合度の分析
references/dependency-audit-guide.md	CVE、ライセンス、最新性の確認
references/adversarial-refutation.md	ブラインド反証者のバインディング（STEP 3.5）— 共有エンジンを読み込みます
references/token-estimation.md	ファイル種別ごとの比率と予算計画
assets/audit-report-template.md	構造化された出力形式
assets/severity-matrix.md	検出事項の分類基準
checklists/audit-completion.md	レポート作成前の確認
scripts/estimate-tokens.sh	LOC からトークン数を自動推定
workflows/audit-full-mapreduce.js	スケール段階 — 1M コンテキストを超えるリポジトリ向けの分割→監査→統合→反証（Workflow ツールから実行）