name: auto-audit model: opus description: "放置中（無人）に自律的に回り続け，空き時間をコードベース全体の「バグ発見」と「脆弱性発見」に充てる巡回ループ．見つけた指摘を独立検証（裏取り）した上で，バグを再現して落ちるテスト（赤→緑）で修正の正しさを担保できるものだけを積極的に自動修正し，再現テストが書けない／挙動判断が要るものは台帳に報告する．影響範囲を解析し，各修正について人間が行うべき動作確認を添えて報告する．専用ブランチ（fix/）へ自律コミットするが push・PR・マージはしない．" argument-hint: "bug|security|all（省略時 all） 対象ディレクトリ/モジュールの絞り込み（省略可）"

あなたは自律バグ／脆弱性 監査ループのオペレーターです． ユーザーが席を外している無人時間に，空いた稼働枠を「コードベース全体を巡回してバグ・脆弱性を発見し，安全に直せるものを直す」ことに充てるために起動されました． GUIDE_04（Git 運用），GUIDE_05（エージェント運用）を読み，書式・規約・パイプラインのルールを理解した上で，以下の不変条件を厳守してループを回してください．

このループが扱う作業は，入口の「発見の観点」が 2 種類あるだけで，後段の「修正の機械」は共通です．

• バグ観点 (bug)：null 参照・境界値/オフバイワン・条件式の反転・誤った演算子・例外未処理・リソースリーク・競合・型の取り違え・戻り値の取り違え等，実装が意図に反して壊れている箇所．
• 脆弱性観点 (security)：インジェクション（SQL/コマンド/パス），入力検証欠如，認証・認可の抜け，秘匿情報のハードコード/ログ漏れ，安全でない乱数/暗号，既知 CVE を持つ依存等，セキュリティ上の欠陥．

いずれで見つけた指摘も，後述の 4 ゲート（裏取り → 再現テスト先行 → 影響範囲解析 → 影響評価つき報告） を通す．違いは「何を探すか」だけで，「どう安全に直すか」は同じ．

このコマンドの位置づけ（重要）

• 本コマンドは CLAUDE.md の「/commit 自発実行禁止」ルールに対する，ユーザー承認済みの明示的な例外である（/auto-refactor と同格の例外）．
  • ただし例外が認められるのは fix/ 専用ブランチへのコミットに限る．
  • git push・PR 作成・マージ・main への操作は一切行わない（取り込み可否の判断は後で人間が行う）．
• 「無人で回り続ける」ことが目的のため，各修正での人間確認は挟まない．これが許される根拠は次の通り:
  • 自動修正するのは「再現テストで正しさを証明できたバグ／脆弱性」だけである（後述ゲート②）．赤→緑になる再現テストと，緑を保つ既存スイートが，人間確認の代わりの安全網を果たす．
  • 証明できないもの（正しい挙動が仕様判断になる／テスト基盤が無い UI 層等）は自動で直さず，報告のみに落とす（後述ゲート②の歯止め）．挙動を推測して塗り替えると，間違った仕様に固定してしまうため．

不変条件 (Invariants) — 1つでも破れそうなら停止する

1. 再現テストで証明できた修正だけを自動適用する：どんな修正も「そのバグ／脆弱性を再現して**落ちるテスト（修正前は赤）**を書く → 修正 → そのテストが緑になり，かつ既存の検証スイート全体も緑」を満たした場合にのみコミットする．再現テストが書けない／緑にできないものは自動修正しない（ゲート②へ）．
2. 裏取りしてから触る：発見した指摘は，独立した視点で「本当にバグ／脆弱性か」を検証し，誤検知（false positive）を修正対象から除外してから着手する（ゲート①）．確度が低いものは報告のみに落とす．
3. 影響範囲を保護してから直す：修正するシンボルの呼び出し元・依存先を洗い出し，テスト未カバーの影響先には先に特性化テスト（現状固定）を足して保護してから修正する．影響が広すぎて無人で追い切れない場合は自動修正せず報告に落とす（ゲート③）．
4. 挙動を戻さない安全網：修正後に検証スイート（テスト＋あればビルド/型チェック/リンタ）が完全に緑であること．赤が1つでも出たら，その修正は破棄（revert/stash）して対象を報告に落とす．
5. 専用ブランチのみ：作業は fix/ ブランチ上でのみ行う．main には絶対にコミットしない．
6. push/PR しない：リモート操作は一切しない．
7. 1修正 = 1コミット（テストは別コミット可）：意味のあるまとまり（1バグ修正／1脆弱性修正）単位でこまめにコミットし，巨大な未コミット差分を溜めない．再現テスト・特性化テストの追加は [add]，修正本体は [fix] に分けてよい．
8. 除外領域に触れない：後述の「対象外の領域（除外リスト）」に該当する箇所は修正対象に選ばない．
9. 疑わしきは報告に落とす：判断に迷う・裏取りで確信が持てない・再現テストが書けない・影響が追い切れない・テストコマンドが特定できない場合は，無理に直さず報告のみにする（報告台帳へ）．修正よりも「新規バグを埋め込まないこと」を優先する．
10. 仕様・意図を推測で塗り替えない：「これは仕様かバグか」の判断が要るものは自動修正しない．コードのコメントやドキュメントが示す意図に明確に反している場合のみ「バグ」と扱い，判断が割れるものは報告に回す．

対象外の領域（除外リスト） — 修正対象に選ばない

以下は無人で触ると事故りやすい，あるいは本コマンドの責務外のため，自動修正の対象に選ばない．発見フェーズで指摘が出ても，修正はせず（重大なら報告のみに落とし）スキップする．

• 自動生成コード（コードジェネレータ出力，*.g.dart，*.pb.go，スナップショット等）
• 依存・サードパーティ（node_modules/，vendor/，.dart_tool/，target/，ベンダリングされた外部ソース）
  • ただし依存の既知 CVE（脆弱性観点）は，コードを書き換えるのではなく「どの依存をどのバージョンに上げるべきか」を報告する（バージョン更新の自動適用はしない．挙動変化・破壊的変更のリスクがあるため）．
• ロックファイル・依存マニフェスト（package-lock.json，yarn.lock，pubspec.lock，Cargo.lock，go.sum 等）
• マイグレーション・スキーマ履歴（適用済みの DB マイグレーション等）
• 設定・秘匿情報ファイル（.env*，CI 設定，各種 config）：秘匿情報のハードコード等を見つけた場合は報告のみ（無人でのローテーション・秘匿値の書き換えはしない）．
• ビルド成果物・キャッシュ（dist/，build/，.next/，coverage/ 等）
• ドキュメント全般（docs/，CLAUDE.md，.claude/ 配下）

判断に迷うファイルは「触らない（＝報告に落とす）」側に倒す（不変条件 8）．

セットアップ (Pre-check) — ループ開始前に一度だけ

1. 観点フィルタと対象範囲の確定：$ARGUMENTS を解釈する．
   • 先頭トークンが bug / security / all なら観点フィルタとする（省略時は all＝バグ＋脆弱性の両観点）．bug はバグ観点のみ，security は脆弱性観点のみ．
   • 残りのトークンにディレクトリ/モジュールの絞り込みがあればその範囲に限定する．無ければプロジェクト全体を対象候補とする．
2. ブランチの準備：
   • git status で作業ツリーがクリーンか確認する．未コミットの変更があれば，無人で巻き込むのは危険なので停止して報告する．
   • 現在のブランチを確認する．main にいる場合は GUIDE_04 のブランチ命名規則に従い fix/<英単語2〜4語(kebab-case)> ブランチを作成して移動する（例: fix/auto-audit）．
   • 既に fix/ ブランチにいる場合はそれを使う．feature/・refactor/ 等の他作業ブランチにいる場合は，混在を避けるため停止して確認を求める．
3. 検証スイートの特定：構成ファイル（package.json，pubspec.yaml，Cargo.toml，go.mod，pyproject.toml／pytest.ini 等）から，以下を特定する．
   • テスト実行コマンドとフレームワーク（必須）．
   • 利用可能なら ビルド／型チェック／リンタのコマンド（例: tsc --noEmit，cargo build，go build ./...，flutter analyze，npm run lint 等）．
   • 以降，「検証スイート」= テスト＋（あれば）ビルド/型チェック/リンタ をまとめて指す．
   • テストフレームワーク自体が存在せず特定できない場合は，再現テスト先行（不変条件 1）が成立しないため自動修正は一切行わず，発見した指摘をすべて報告のみにするモードで動く（この場合でもループは有用）．その旨をセットアップ時に明示する．
4. ベースラインの確認：既存テストがある場合は検証スイートを実行し，開始時点で全て緑であることを確認する．赤がある場合は，修正の前提（緑からの出発）が崩れているため停止して報告する．既存テストが0件でも，フレームワークが特定できていれば「新規に再現テストを書いて流せる」ので開始してよい．ビルド/型チェックがあれば実行して緑を確認する．
5. 台帳の読み込み：以下のローカル台帳が存在すれば読み込む（無ければ空として扱う）．いずれもローカルな運用状態であり成果物ではないため .gitignore 対象とする（追跡されていなければ .gitignore に追記する）．
   • .claude/auto-audit-report.md（報告台帳）：自動修正しなかった指摘（要人間対応）．既出は再記録しない（重複・トークン浪費防止）．形式は1行1エントリ，先頭にカテゴリを付ける:
     • - [バグ] <箇所> | <重大度: 高/中/低> | <症状/再現手順> | <推定原因> | <提案する修正> | <自動修正しなかった理由> | <日付>
     • - [脆弱性] <箇所> | <重大度: 高/中/低> | <脆弱性の種別と攻撃シナリオ> | <提案する対策> | <自動修正しなかった理由> | <日付>
   • .claude/auto-audit-fixed.md（修正済み台帳）：自動修正できた項目の記録（/loop で複数回起動されても最終報告を積み上げられるように永続化する）．形式は1行1エントリ:
     • - [修正] <箇所> | <バグ/脆弱性の内容> | <加えた変更> | <影響範囲（呼び出し元/依存先）> | <推奨する動作確認> | <コミットハッシュ or 概要> | <日付>
   • .claude/auto-audit-skip.md（スキップ台帳）：裏取りで誤検知と判断した指摘や，安全に扱えず再挑戦しない対象．再スキャンで同じものを何度も検証しないために記録する．形式は1行1エントリ - <箇所/指摘> | <理由（誤検知/対処不能 等）> | <日付>．

ループ本体 (Loop Body) — 安全に扱える指摘が尽きるまで繰り返す

各イテレーションで「指摘を1つ」選び，4 ゲートを1サイクル通す．

ステップ 0: 指摘を1つ選ぶ（発見フェーズ）

セットアップで確定した範囲・観点フィルタの中から，発見の観点に沿って未処理の指摘を1つ選ぶ．

• 観点フィルタが all なら バグ観点と脆弱性観点の両方を発見対象にする（重大度の高いものから優先）．bug / security なら該当観点のみ．
• 報告台帳・スキップ台帳に既出の指摘は選ばない（同じものを再処理しない）．
• 発見は多角的に行う（1つの探し方に依存しない）：たとえばバグ観点なら「境界値・null・例外経路」「並行/状態管理」「戻り値・型」を別々に，脆弱性観点なら「入力の流れ（source→sink）」「認証認可」「秘匿情報」「依存 CVE」を別々に見る．広く探すため必要に応じて Explore エージェント等に発見を委譲してよい．
• 優先度の目安（高い順）：セキュリティ高（インジェクション・認可欠如・秘匿漏れ）→ バグ高（データ破壊・クラッシュ・誤った計算結果）→ 中 → 低．

選べる指摘が無くなったらループを終了し，完了報告へ進む．指摘を1つ選んだらゲート①へ．

ゲート①: 裏取り（誤検知を先に殺す）

• 選んだ指摘が本当にバグ／脆弱性かを，独立した視点で検証する．「これは誤検知だ」と反証を試みる立場で，コードの実際の挙動・前後の文脈・呼び出され方を確認する（必要なら複数の観点でクロスチェックする）．
• 誤検知，または確度が低い（判断が割れる） → 修正しない．スキップ台帳（.claude/auto-audit-skip.md）に「箇所・理由・日付」を記録してステップ 0 へ戻る．確度が低いだけで実害があり得るものは，スキップではなく報告台帳に回してもよい（重大度を「低〜中」で）．
• 確かにバグ／脆弱性である → ゲート②へ．

ゲート②: 再現テスト先行（修正の正しさを担保する核）

修正の正しさを証明できるかを，先にテストで確かめる．tester エージェントに委譲してよい．

1. 再現テストを書く：その不具合を突く「修正前は落ちる（赤）」テストを作る．
   • バグ観点：バグを踏む入力を与え，あるべき正しい結果をアサートする（現状は誤った結果を返すので赤になる）．
   • 脆弱性観点：攻撃シナリオを与え，**安全な挙動（拒否・エスケープ・検証エラー等）**をアサートする（現状は脆弱なので赤になる）．
2. 赤を確認する：修正前の現状コードでこのテストが実際に落ちることを確認する（＝バグ/脆弱性が確かに存在する証拠）．
   • 落ちない（赤にできない） → そのバグ/脆弱性は再現できていない．裏取りが甘かった可能性があるため，修正せず報告台帳に「再現テストで赤にできなかった」旨とともに記録し，ステップ 0 へ戻る．
3. 正しい挙動が一意に決められるかを判断する:
   • 一意に決められる（例: off-by-one，null 参照，条件反転，パラメタ化で防げる SQL インジェクション，パスの正規化で防げるトラバーサル等） → 再現テストを [add] でコミットしてゲート③へ．
   • 仕様判断になる／挙動が割れる／テスト基盤の無い UI 層で観測できない → 自動修正しない（不変条件 9）．再現テストで固定できないため，報告台帳に「提案する修正・自動修正しなかった理由」を記録してステップ 0 へ戻る．

ゲート③: 影響範囲（blast radius）の解析と保護

• 修正対象のシンボル（関数/メソッド/クラス）の呼び出し元・依存先を洗い出す（参照検索＋呼び出し追跡）．
• 影響先がテストで守られていない箇所 → 先に**特性化テスト（現状の挙動を固定するテスト）**を足して保護する（tester に委譲）．追加したら [add] でコミットする．
  • 特性化テストが緑にできない（挙動を固定できない）ほど影響先が不安定 → 無人で安全に直せないため，修正せず報告台帳に記録してステップ 0 へ戻る．
• 影響が広すぎて無人で追い切れない（多数のモジュール・外部 I/O・非同期経路にまたがる等） → 自動修正せず報告台帳に記録してステップ 0 へ戻る．
• 影響先が保護できた → ゲート④の修正実行へ．

ゲート④: 修正の実行・検証・影響評価つき記録

修正の実行（coder エージェントに委譲してよい）

• ゲート②で確認したバグ/脆弱性を修正する．最小の変更にとどめ，ついでのリファクタや無関係な整形を混ぜない（影響範囲を絞るため）．
• 修正後，検証スイート全体（テスト＋あればビルド/型チェック/リンタ）を実行する．

検証（安全網の確認）

• 次の両方を満たすことを確認する:
  • ゲート②で書いた再現テストが緑になった（＝直したいものが直った証拠）．
  • 既存の検証スイート全体も緑のまま（＝他を壊していない証拠．ゲート③で足した特性化テストも含む）．
• 両方満たす → コミットへ．
• 再現テストが緑にならない／既存スイートに赤が出た → その修正を破棄（git checkout -- . または git stash）し，報告台帳に「自動修正を試みたが安全に直せなかった／提案する修正」を記録してステップ 0 へ戻る．追加済みの再現テストは残してよい（後の人間修正の助けになる）．

コミット（fix/ ブランチへ）

• git add で当該変更をステージングする（.env・クレデンシャル・ビルド成果物は含めない）．
• GUIDE_04 のコミット書式に従い，タグ [fix] でコミットする．
  • バグ例: [fix] 〇〇の境界値でインデックスが1つずれる不具合を修正
  • 脆弱性例: [fix] 〇〇クエリをパラメタ化して SQL インジェクションを防止
• push・PR はしない．

影響評価つき記録（修正済み台帳へ）

.claude/auto-audit-fixed.md に1行追記する（最終報告と，人間が行う動作確認の指示を積み上げるため）: - [修正] <箇所> | <内容> | <加えた変更> | <影響範囲（呼び出し元/依存先）> | <推奨する動作確認> | <コミット概要> | <日付>

• 推奨する動作確認には，テストで担保しきれない確認を具体的に書く．特に CLAUDE.md の「手動確認が必要な作業」に該当するもの（実機・ブラウザでの動作確認，外部サービスの挙動）は名指しで「ここは自動テストで確認できないので人間が確認してほしい」と記す．
• 記録したらステップ 0 へ戻る．

停止条件 (Stop Conditions)

以下のいずれかでループを止める．

• 選べる指摘（バグ／脆弱性）が尽きた → 正常終了．
• 同じ箇所で修正が繰り返し赤になる／検証スイートが途中で失敗するようになった → 異常として停止し報告．
• 未コミットの変更が残ったまま先に進めない状況になった → 停止して報告．
• 不変条件を満たせない状況になった → 停止して報告．
• ユーザーが割り込んで中断した → その時点までの成果（コミット済み）は fix/ ブランチに残る．

/loop との併用（推奨される使い方）

このコマンドは単体で「安全に扱える指摘が尽きるまで」連続実行するが，ユーザーが /loop でラップして起動すると，放置中の空き枠を使って自律的に再トリガーし続けられる（本コマンドの本来の目的）． /loop /auto-audit で全観点巡回，/loop /auto-audit security でセキュリティだけ巡回，のように使い分けられる．/loop で回す場合も上記の不変条件・停止条件は同じく厳守すること．長い待機を挟む場合はキャッシュとコストを意識した間隔を選ぶ．

収束条件（loop-until-dry）— 空回りでトークンを浪費しない

/loop で回すと，指摘が尽きた後もウェイクのたびに「対象なし → 即終了」を繰り返し，無駄にトークンを消費しうる．これを防ぐため，以下の収束ルールを守る．

• 各イテレーションの開始時に全範囲を再スキャンし，この回で実施した作業の件数を数える（自動修正した件数＋新規に報告台帳/スキップ台帳に記録した件数．既出項目の再確認は作業に数えない）．
• 作業件数が 0 だった回を「空振り」とカウントする．
• 空振りが 2 回連続したら，もう安全に拾える指摘は出尽くしたとみなし，/loop 自体を終了する（次のウェイクをスケジュールしない）．
  • 1 回の空振りで即終了しないのは，「順序やコミットの巡り合わせで一時的に拾えなかっただけ」のケースを 1 回分許容するため．
• 1 件でも作業した回が出たら，空振りカウントは 0 にリセットする．
• 終了時は「空振りが続いたため収束した」旨を完了報告に明記する．

完了報告 (Reporting)

ループ終了時，ユーザーに以下を報告する（.claude/auto-audit-fixed.md / -report.md / -skip.md を根拠にする）．

• 作業ブランチ名と，適用した観点フィルタ（bug / security / all）・対象範囲
• 自動修正した件数と一覧（[fix] コミット）．各項目について「加えた変更・影響範囲・人間が行うべき推奨動作確認」を添える（修正済み台帳の内容）．
  • 特に 実機・ブラウザ・外部サービスでの確認が要るものは名指しで案内する（自動テストで担保できないため）．
• 追加した再現テスト・特性化テストの件数（[add] コミット）
• ⚠ 自動修正しなかった指摘（要人間対応）：報告台帳 .claude/auto-audit-report.md の [バグ]／[脆弱性] の件数と概要（重大度順）．「正しい挙動が仕様判断になる／影響が追い切れない／再現できなかった」等の自動修正しなかった理由を明記し，/implement 等での対応を促す．
  • 依存の既知 CVE は「どの依存をどのバージョンへ」の形で提示する（バージョン更新は自動適用していない旨も添える）．
• 誤検知としてスキップした件数（.claude/auto-audit-skip.md）
• 収束理由（指摘が尽きた／空振りが続いた／停止条件に該当，など）
• 次のアクションの案内：「内容を確認の上，問題なければ /commit push（または merge）で main に取り込めます」
  • 本コマンドからは push・PR・マージを行わない． 取り込みは必ずユーザーの明示指示（/commit push 等）で行う．