セキュリティ調査の指揮

リポジトリのソースコードを領域ごとにセキュリティ観点で調査し、レポートを揃える。ユーザーに依頼された時は、揃ったレポートの問題をトリアージし、問題を自動修正し、問題を直すpull requestの状態をページに反映する。 このsessionは指揮役になる。ユーザーと対話し、調査する領域を決め、subagentに作業を任せ、結果を確かめて記録する。調査する領域が1つでも同じである。

指揮役としての振る舞いは、kuden:orchestrator skillを読み込み、その基準に従う。指揮役は調査対象のコードを読まない。

作業は、以下のskillを実行するsubagentに任せる。

skill	作業	読む物
codepatrol-setup	調査対象リストと観点リストを生成・更新する	コード
codepatrol-report	1つの領域を調査してレポートを出力する	コード
codepatrol-triage	レポートの問題を分類し、トリアージページを作る	レポート
codepatrol-sync-state	問題を直すpull requestの状態を、ページに反映する	レポートとpull request
codepatrol-autofix	1つの問題を修正し、pull requestを仕上げる	レポートとコード
codepatrol-autofix-deploynote	デプロイの前後にやる事を、release pull requestのコメントにまとめる	pull request

subagentには、Opus以上のtierのmodelを指定する。

ファイル構成

.dev/codepatrol/
  config.md            ← レポートの書き出し先設定
  checklist.md         ← リポジトリ固有の機構と観点の補足。マスターのCHECKLIST.mdと一緒に読む
  targets.md           ← 調査対象リスト。各H2見出しが調査領域。関連リポジトリの一覧もヘッダにある
  {領域名}-{YYYY-MM-DD}.md  ← 領域ごとの調査レポート（書き出し先がローカルの場合）

関連リポジトリ

同じサービスを構成する複数のリポジトリは、1つの .dev/codepatrol/ と1つのhubページに束ねて調査する。設定を置くリポジトリは1つで、他のリポジトリは関連リポジトリとして targets.md のヘッダに一覧がある。領域名の接頭辞でリポジトリを区別する。関連リポジトリの側には .dev/codepatrol/ を作らず、起動は設定を置くリポジトリで行う。

関連リポジトリのcloneの場所は、開発者ごとに違うので targets.md には書かれていない。memoryにあればそれを使い、無ければユーザーに訊いて、次の起動で訊かずに済むようにmemoryに記録する。subagentには、リポジトリごとに絶対パスで伝える。

実行環境の確認

いずれかを満たさなければ、何も行わず、満たさない条件をユーザーに報告して停止する。トリアージと、状態同期だけを行う時は、条件2と条件3の確認は要らない:

1. 自分のmodelがOpus以上のtierである（Opus、Fable、Mythos等）。Sonnet・Haiku等の下位tierは問題の検出能力が足りない
2. Codex CLIがインストールされている。Bashツールで command -v codex を実行して確認する
3. CodexのmodelがSol以上のflagship（Sol、Astra等）で、reasoning effortがmedium以上である。短いプロンプトを作業ツリー外のファイルに書き、codex exec --ephemeral にstdinで渡して1回実行し、出力のヘッダから読む。Luna・Terra等の軽量tierと、Solより前の世代のmodelは相談相手として足りない

codex exec を直接実行するのはこの確認だけにする。Codexへの相談は、subagentがSkill toolで codex-consultation を呼び出して行う。

調査用の作業ツリー

調査と、リストの生成・更新は、調査用のbranchをcheckoutしたgit worktreeで行う。調査は長時間かかるので、その間もユーザーが自分のcheckoutで他の作業を続けられるようにする。

• 調査用のbranchは、最新のdefault branchから切る。前のsessionが作った調査用のworktreeが残っていれば、それを使い、最新のdefault branchに追従させる
• 関連リポジトリは読むだけで、変更を積まない。それぞれ最新のdefault branchの状態を、ユーザーのcheckoutを変えずに読める場所を用意する。古いコードで調査すると、default branchで既に直った箇所を問題として扱う
• ユーザーのcheckoutでは、branchの切り替えもファイルの変更もしない

.dev/codepatrol/ の置き場所は、リポジトリがこのディレクトリをgitで管理するかどうかで決まる。

• 管理するリポジトリでは、調査用のworktreeの中の物を使う。設定ファイルやレポートが、default branchではなく他のbranchやユーザーのcheckoutにある時は、調査用のbranchに引き継ぐ。引き継がないと、設定を作り直し、調査済みの領域を未調査として扱ってしまう
• gitignoreしている等、管理しないリポジトリでは、ユーザーのcheckoutの中の物を使う。worktreeには現れないためである。ユーザーのcheckoutで書き換えてよいのは、このディレクトリだけである。commitはしない

作業ツリーを用意したら、ユーザーに報告する。作業がどこで行われ、変更がどこに残るのかを、ユーザーが把握できるようにする。

• 調査用のworktreeの場所とbranchの名前。新しく作ったのか、前のsessionの物を使うのか
• .dev/codepatrol/ の場所
• 関連リポジトリを読む場所
• 設定ファイルやレポートを引き継いだ時は、引き継いだ元

subagentには、リポジトリごとのコードを読む場所と、.dev/codepatrol/ の場所を伝える。

セットアップ

.dev/codepatrol/ の3つの設定ファイルが揃っていなければ、無い物を用意する。

config.md

無ければ、レポートの書き出し先を決めて記録する。

1. AskUserQuestionツールで書き出し先をユーザーに確認する:
   • Cosenseに集約する — レポートをCosenseのページとして作成し、hubページに被リンクで集約する。チームでの共有・議論に向く
   • ローカルファイル — .dev/codepatrol/{領域名}-{YYYY-MM-DD}.md に書き出す
2. Cosenseの場合は、project URLとhubページ名（例: {プロダクト名} セキュリティレポート）をユーザーに確認する
3. config.mdに記録する。フォーマット:

# Codepatrol Report Destination

レポートの書き出し先設定。

- 書き出し先: {Cosense または ローカル}
- project URL: {https://scrapbox.io/プロジェクト名}
- hubページ: {hubページ名}
- レポートページのタイトル規則: `{hubページ名} {YYYY/M/D} ({領域名})`
  - 年月日はレポート作成時点、月と日はゼロ埋めなし（例: 2026/7/3）
- 前提: cosense CLI（`npm install -g @helpfeel/cosense-cli`）のインストールとログイン

ローカルの場合は「書き出し先: ローカル」だけを記録する。

既存のconfig.mdのタイトル規則がこの形と違う時は、ユーザーに伝える。config.mdの書き換えはユーザーが行う。

関連リポジトリの確認

targets.md が無い初回は、codepatrol-setupを任せる前に、同じサービスを構成する別のリポジトリが無いかをAskUserQuestionツールで1回確認する。インフラ設定、アップロードや配信を担う別のサーバー、課金サービス、スマホアプリやブラウザ拡張のようなクライアントが典型である。別のリポジトリにある問題は、そのリポジトリを束ねないと検出できない。

• 足す関連リポジトリごとに、名前とcloneの場所を確かめ、領域名の接頭辞をユーザーと決めて、codepatrol-setupへの指示に含める
• クライアントのリポジトリは、自動検出の対象外である。観点マスターもサーバー側を前提にしている。束ねる時は、領域をユーザーがtargets.mdに手動で足し、観点はリポジトリ固有の層で補う事を伝える

初回に限らず、codepatrol-setupの報告にある「関連リポジトリの候補」はユーザーに伝える。足すと決まった物は、同じように名前・場所・接頭辞を決めて、codepatrol-setupに両方のファイルの更新を任せる。

targets.md と checklist.md

次の場合に、codepatrol-setupを実行するsubagentを起動し、生成・更新を任せる。

• ファイルが無い
• ユーザーが更新を指示した
• ユーザーが関連リポジトリを足した、または外した。両方を更新させる
• Generated by の記録から、生成したmodelが「実行環境の確認」の条件1を満たすと確認できない。Sonnet・Haiku、Codex、記録なし等である。両方を作り直させる
• Generated by の記録から、レビューしたCodexが条件3を満たすと確認できない。「Codexレビュー未実施」の記録がある、Codexの実行環境が書かれていない、条件外のmodel等である。リストのレビューだけをやり直させる
• Format の記録が、codepatrol-setup の「設定ファイルの形式」が定める現在の値と違う、または無い。skillの更新で形式が変わった時である。両方を更新させる

codepatrol-setupでのCodexのレビューを経ていないリストで、調査を始めない。Codexが止まってレビューが完了しなかった時は、ユーザーに報告して判断を待つ。

調査を始める前に checklist.md を読み、checklistとレポートの責任境界 に合わない記述が入り込んでいないかを確かめる。問題の断定・深刻度・レポートの問題への言及があれば、調査の担当が読む前に取り除く。事実の記述に書き直すのにコードの確認が要る時は、codepatrol-setupを実行するsubagentに任せる。

subagentの報告から、targets.mdの領域の一覧をユーザーに伝える。領域の分割・統合は、ユーザーがtargets.mdを編集して行う。

調査する領域を決める

targets.md の領域と既存のレポートを突き合わせ、領域ごとに未調査か調査済みか、調査済みなら最後の調査時期を把握して、ユーザーに報告する。

• 書き出し先がCosenseの場合: hubページに集約された既存レポートのタイトルから把握する。hubページやレポートが無ければ、全領域を未調査として扱う
• 書き出し先がローカルの場合: .dev/codepatrol/ にレポートのファイルがある領域が調査済みである。調査時期は、ファイル名の日付から読む

進み具合の判定は、レポートの存在と調査時期だけで行う。コードの変更内容から再調査の要否を推定しない。

範囲が指定されていなければ、AskUserQuestionツールで1回だけ確認する。未調査の領域だけか、調査済みの領域の再調査も含めるか、領域を指定するか、である。 再調査を含める時は、いつより前のレポートしか無い領域を再調査するのか、境目の時期も確認する。中断した後に起動し直した時に、同じ境目から残りの領域を求められる。

順番は指揮役が決める。

• 未調査の領域を先にする。その中では、他の領域のレポートが主担当として名指しした領域と、認可・認証・外部通信に関わる領域を先にする
• 再調査は、最後の調査が古い領域から行う

中断した後に起動し直した時は、範囲と既存のレポートから残りの領域を求め直す。

調査をsubagentに任せる

レポート1本ごとに新しいsubagentを起動し、codepatrol-reportを実行させる。

指示に含める事

• 担当する領域の名前
• 再調査の場合は、前回として扱う既存レポートの場所
• リポジトリごとのコードを読む場所と、.dev/codepatrol/ の場所
• 作業用ディレクトリ。session用の一時ディレクトリの下に、領域ごとに分ける。Codexの出力や途中結果が、並走するsubagentの物と混ざらないようにする
• 問題の名前の一覧のファイル
• 並走している領域と、担当する領域とファイルが重なる領域

既存の問題の内容は、指示に含めない。

問題の名前の一覧

既存のレポートにある問題の名前を、レポートごとに並べたファイルである。領域をまたいで同じ問題に別の名前が付くのを防ぐ。

• 各領域の最新のレポートから、問題の深刻度・見出し・名前だけを拾う。問題の本文は入れない
• 最初のsubagentを起動する前に作り、レポートが1本できるたびに作り直す
• レポートを読んで一覧を作る作業も、subagentに任せてよい

並列に調査する

読むファイルが重ならない領域の組だけを、並列にする。近い領域を並列にすると、同じ問題に別の名前が付く。並列は3本までを目安にする。別のリポジトリの領域でも、対になる領域はファイルが重なる。targets.mdに書かれた対になる領域を、組を決める材料にする。

並列にした組が終わったら、各subagentの報告にある「他の領域と重なりそうな問題」を突き合わせる。同じ問題に別の名前が付いていたら、両方のレポートの該当する問題に、相手の問題への参照と、どちらの名前で1件として扱うかを、1行ずつ足す。

subagentの報告を確かめる

ユーザーに報告する前に、以下を自分で確かめる。

• レポートが、設定された書き出し先に出力されている
• Codexへの相談が最後まで完了している。作業用ディレクトリに残った出力で確かめる
• Codexへの相談が、codex-consultation skillの手順を通して行われている。subagentの実行の記録を読める時は記録で確かめ、読めない時はsubagentの報告に基づく内容として扱う

設定ファイルの変更を記録する

subagentは、作業の中で checklist.md と targets.md を編集する。subagentはcommitしない。指揮役が差分を確かめて、調査用のbranchにcommitする。.dev/codepatrol/ をgitで管理しないリポジトリでは、差分を確かめるだけで、commitはしない。

• セットアップが終わった時と、レポートが1本できるたびにcommitする。並列にした時は、1組が終わるたびにcommitする
• 書き出し先がローカルの場合は、レポートのファイルも一緒にcommitする
• commitの前に、差分を読む。checklist.md に、責任境界に合わない記述が入っていれば、commitせず、取り除く。checklistは調査の足場で、問題を書くと次の調査を誘導する
• subagentが報告した「足すべき観点・領域」は、自分では足さない。ユーザーに伝え、足すと決まった物は、codepatrol-setupを実行するsubagentに更新を任せる
• pushとpull requestの作成は、ユーザーの指示を待つ。作業を終える時に、調査用のbranchの名前と、積んだcommitをユーザーに報告する

進め方

最初の1本は単独で調査させ、結果をユーザーに報告して確認を待つ。レポートの形と手順に問題が無い事を確かめてから、残りの領域に進む。

それ以降は、1本または1組が終わるごとに短く報告し、承認を待たずに次へ進む。報告には、レポートの場所、問題の件数と深刻度の内訳、Highの問題の名前と要約、実環境の確認が要る項目の有無を含める。

止まってユーザーの判断を待つのは、次の場合である。

• Codexが止まり、subagentがレポートを出力せずに中断した。指揮役が自分で調査を代行する事も、Codexを使わない調査に切り替える事もしない
• レポートが、設定された書き出し先に出力されなかった。subagentが作業用ディレクトリに書き出したレポートを使い、指揮役が出力をやり直す。それでも出力できない時は、レポートの場所をユーザーに伝えて止まる。作業用ディレクトリはsessionが終わると残らず、次に起動した時にその領域が未調査として扱われる
• レポートの間に、指揮役では決められない食い違いがある

出力済みのレポートを消さない

出力済みのレポートは、他のレポートやpull requestから参照されている。手順の誤りが後から分かった時も、削除や作り直しをせず、ユーザーに報告して判断を待つ。

トリアージと、状態同期

どちらも、ユーザーに依頼された時に行う。調査のたびに行う作業ではない。

• レポートとトリアージページを読み書きするだけで、コードを読まず、設定ファイルも編集しない。調査用の作業ツリーは用意しない
• 書き出し先がCosenseの場合だけ行える。書き出し先とhubページは config.md から、問題を直すpull requestが作られるリポジトリは targets.md のヘッダの関連リポジトリから読む。読むのはヘッダだけである。どちらも、今の調査対象を表す物を読む。調査用のbranchやユーザーのcheckoutに、default branchより新しい物があれば、そちらである

トリアージ

レポートの問題が多い時に、どれを誰が直すかを決める材料を作る。codepatrol-triageを実行するsubagentを起動する。

指示に含める事:

• hubページ
• 載せる問題の条件。ユーザーの指示があった時だけ含める
• 前のトリアージページ。hubページにリンクしているページから探す

subagentの報告から、作成したページの場所、修正難度ごとの行の数、修正難度に迷った問題をユーザーに伝える。

前のトリアージページがある時は、新しいページを作る前に、前のページで状態同期をしておく。修正PRの行は、前のページの状態のまま引き継がれる。

状態同期

修正の作業が進むと、ページに書かれた状態が、pull requestの実際の状態からずれていく。codepatrol-sync-stateを実行するsubagentを起動し、ずれを直す。修正の作業が続いている間、繰り返し行う。

指示に含める事:

• 起点にするトリアージページ。無ければhubページ
• 問題を直すpull requestが作られるリポジトリ。設定を置くリポジトリと、関連リポジトリの全てである
• 前回の同期の時期。分かる時だけ含める

subagentは、判断が要る事を、ページを直さずに報告する。報告をユーザーに伝え、判断を待つ。

自動修正

ユーザーに依頼された時に行う。トリアージページの問題を、subagentに1つずつ修正させる。autofix.md を読み込み、それに従う。

関連スキル

• codepatrol-setup: 調査対象リストと観点リストを生成・更新するスキル。subagentが実行する
• codepatrol-report: 1つの領域を調査してレポートを出力するスキル。subagentが実行する
• codepatrol-triage: レポートの問題を分類し、トリアージページを作るスキル。subagentが実行する
• codepatrol-sync-state: 問題を直すpull requestの状態を、トリアージページとレポートに反映するスキル。subagentが実行する
• codepatrol-autofix: 1つの問題を修正し、pull requestをready for reviewまで仕上げるスキル。subagentが実行する
• codepatrol-autofix-deploynote: デプロイの前後に人間がやる事を、release pull requestのコメントにまとめるスキル。subagentが実行する
• codex-consultation: Codex CLIと相談するスキル。codepatrol-setupとcodepatrol-reportとcodepatrol-autofixが使用する。必須で、他のスキルや codex exec の直接実行で代替しない
• software-factory-mode-2026aki: 開発フローを定めるスキル。codepatrol-autofixが従う。自動修正に必須である
• sanity-review: pull requestのレビュー報告書を作成するスキル。自動修正の開発フローの中で使用する
• kuden:orchestrator: subagentに作業を任せる指揮役の心得。指揮役が従う
• kuden:github: GitHubでpull requestを作り、文章を書く時の心得。自動修正のrelease pull requestの組み方で使用する