リファレンス削減監査

プロジェクト内の参照資料に蓄積した重複、失効した説明、過剰な詳細を整理し、現在の判断に必要な文脈を少ない読み込みで理解できるようにする。削除・統合・縮約候補を積極的に列挙し、判断の中心は 「この資料を削除すると、どんな現実的な判断ミス・再調査・知識の喪失が起こるか」 とする。「念のため」、資料数、網羅性、過去に作成した労力だけを残す理由にしない。削減量も目標にせず、候補がなければその根拠を示す。

範囲と調査

• 指定がなければ現在のrepositoryのdocs/REFERENCEと、それに相当する参照資料ディレクトリを対象にする。対象の文書と付属画像・PDF・データを一覧化し、確認済み／未確認を追跡する。
• 製品仕様、Story、PLAN、EVIDENCE、AGENTS.md、Skillは、参照関係や正本を確認するために必要な範囲で読む。自動的に削減対象へ広げない。.reference等の参照実装・submodule自体の整理は、利用者が対象として指定した場合に扱う。
• 適用される開発契約、文書の優先順位、既存差分を確認する。ファイル名や配置だけで「参考情報だから削除可能」と判断しない。REFERENCEに現行の製品判断、運用手順、providerや費用の契約が置かれている場合もある。
• 本文と引用元、関連する実装・consumer・testを読み、どの判断を支える資料か確認する。索引、相対リンク、anchor、ファイル名、特徴的な概念名をrepository内で検索し、参照元と利用箇所を調べる。リンクがないことと利用価値がないことを同一視しない。
• 古さやコードとの不一致だけで失効としない。後継の決定、対象version、適用期間、採否を確認する。コードが契約から逸脱している可能性と、資料が更新されていない可能性を区別する。
• 外部情報の現行性が採否を左右する場合だけ、該当する一次情報を確認する。到達不能なURLや未読の画像・PDFの内容を推測しない。過去時点の証拠としての価値と、現在の案内としての価値を分ける。

全対象を領域ごとに確認し、目立つ数件の抽出で終了しない。途中終了時は未確認範囲を明記し、全件精査済みと報告しない。

削除・統合・縮約の観点

対象	判断の要点
コード・設定・公式文書のコピー	容易に再取得できる内容を転記しただけか。project固有の適用条件、落とし穴、選定理由があれば、その差分と出典を残す形へ縮約できるか。
他資料との重複	同じ判断を同じ前提で説明しているか。正本・統合先を一つ決め、固有の根拠だけ移せるか。似た題名だけで重複としない。
古い・失効した情報	旧構成や廃止機能の説明が現行の案内として残っていないか。現行箇所と歴史的記録を分け、必要な経緯だけ残せるか。
不採用案・終了した調査	採否が確定した探索の全文が必要か。不採用理由が同じ検討の繰り返しを防ぐなら、結論・制約・出典へ縮約できるか。
利用先のない資料	現行の開発・運用・判断に使う具体的な場面があるか。参照検索の結果だけでなく、障害復旧など低頻度でも必要な用途を確認する。
過剰な詳細・実行ログ	調査途中の会話、試行ログ、同じ結論の反復、細かすぎる手順が判断を埋もれさせていないか。再現に必要な条件・revision・結果を残して縮約できるか。
付属素材・参照実装	画像、動画、PDF、データや、明示対象の参照コードに固有の根拠があるか。文書を消しても別のconsumerが使う素材を巻き込まない。

ライセンス・帰属表示、出典とrevision、意思決定の理由、外部で再取得できない証拠は、実際の保持要件と利用価値を確認する。外部URL、別repository、参照submodule、Git履歴に同じ内容があることや、byte単位の一致だけでは、プロジェクト内資料の削除根拠にならない。原本への到達性と、日常の開発で判断文脈を理解できることを分けて評価する。

参照元の全文から絞り込む場合は、通常の判断に必要な採否・理由・制約・根拠画像等をプロジェクト内の資料に残し、原本は詳細の確認先とする。既存のローカル資料が同じ文脈を十分に担っているか、移設・縮約後の具体的な内容で確認する。リンクだけへの置換で毎回原本の探索や判断の再構築が必要になるなら、整理として採用しない。

候補の採否

各候補について、次を説明する。

1. 失う知識: 削除で困る利用者・作業・判断を具体化する。固有の価値を確認できなければその旨と調査根拠を示し、漠然と将来使う可能性だけで残さない。
2. 残る根拠: プロジェクト内に残す資料のpath・見出しと、原本・出典を区別して示す。同じ条件の情報に加え、何を採用し、なぜそう判断したかを残る資料から理解できるか確認する。代替がない場合も明記する。重要な根拠は移し先と残す内容を決め、単に「別の文書に統合」としない。
3. 費用対効果: 誤った案内、探索時間、重複読み込み、更新漏れ、保管容量などの負担と、判断の価値・再調査コストを比較する。測定値と推定を区別し、ファイルサイズだけで読み込みtoken数や利用頻度を断定しない。
4. 最小の整理: ファイル全体、節、表、添付素材のどこを削るか指定する。統合では残す文書と移す固有情報、縮約では残す結論・適用条件・根拠を示す。無関係な資料を巨大な一枚にまとめない。

重複資料は集合として評価し、互いを代替扱いしてすべて削除しない。移動・統合で変わる参照元とanchorも洗い出し、候補を同時適用しても必要な情報へ到達できることを確認する。

履歴保持の必要が具体的にある場合は、失効状態と現行資料への案内を付けて保存する案も認める。ただしarchiveへの移動だけを情報量の削減として報告しない。正本の衝突や利用条件が未確認なら、不足する証拠を示して「要確認」とし、確認可能なものは調査中に解消する。

出力と完了

結果は日本語で、次の順にまとめる。優先順位はプロジェクト内の判断・読み込みをどれだけ改善するかで決め、複製ファイル数や容量削減だけを主成果にしない。候補が多い場合も上位数件だけに省略せず、必要なら利用者指定の出力先に全件を保存する。

• 確認範囲: 対象、確認済み範囲、除外・未確認範囲。文書、添付素材、参照実装を区別する。
• 整理候補一覧: 各行にpath・見出しまたはline、判定（削除／統合／縮約／条件付き）、該当観点と根拠、削除で失う知識、残す資料・出典、削減できる負担を記載する。条件付き候補には具体的な条件を付ける。
• 整理後の姿: グループごとの残す文書、移す固有情報、修正するリンク・索引、付属素材への影響。候補を同時適用した際の情報の所在を示す。
• 残す判断・要確認: 候補に見えたが固有の価値があるものと、不足する証拠を簡潔に示す。全保持資料の長い解説は不要。

既定は監査と候補提示までとし、資料を編集しない。利用者が実施も依頼している場合は、根拠が揃った候補を整理し、移した内容の意味・適用条件・出典と参照リンクを確認する。文書を入力にする生成処理などがあれば、そのconsumerも必要な範囲で検証する。文書だけの変更にアプリ全体のテストや文言一致テストを追加しない。

全対象の確認と候補間の整合確認が終わったら完了する。通常の棚卸しにStory、PLAN、専用台帳、独立レビュー、サブエージェントを自動追加しない。