/prompt-budget — プロンプト面の計測つき整理

プロンプト変更は計測なしで完了しない。効果は「送信バイト数」と「挙動不変」の2点で示す。

計測対象の全体像（census）

モデルへ実際に送られるテキストは4層ある。層を分けて数えること:

層	内容	頻度
system prompt	ベース指示 + role + プロジェクト指示 + per-model 注記	毎リクエスト
注入ブロック	transform_context / middleware が毎回追記する索引・ヘッダ	毎リクエスト
tool surface	各ツールの name + description + JSON スキーマ（TypeBox 等）	毎リクエスト
副プロンプト	judge / verifier / compaction / 要約などの一回きり指示	呼出ごと一回

「文字列を削る」だけでなく inline 埋め込み文字列を名前付き定数にすることが整理の主眼 — 名前がない文面は計測対象にすら載らず、重複・ドリフトの温床になる。

手順

1. baseline: node scripts/prompt-budget.ts --json > /tmp/baseline.json のような計測スクリプトで現状を JSON 記録する。スクリプトがなければ作る（下記「計測スクリプトの作り方」）。必ず実データで計測 — 目分量の概算は禁止。
2. 整理: 下記「整理の基準」に従って編集。
3. 描画同一性の検証: 純粋な整理（dedup・定数化）では、変更前後でレンダリング結果が同一であることを機械的に確かめる。git show HEAD:<file> の旧版と新版を同じ抽出器に通し、解決済み文字列を SAME/DIFF/NEW/GONE で突き合わせる。DIFF があったら意図した文面差か確認する。
4. after: 同じスクリプトで再計測し、baseline と差分を報告する（総量だけでなく項目ごと）。
5. 挙動検証: 描画が同一なら既存テストで足りる。文面を変えた場合は、その文面が担っている振る舞い（tool 選択・denial 応答・要約品質）を検証する経路を選ぶ — live bench は文面差があるときだけ。

整理の基準

やる:

• 同一文面・同一 bullet の繰り返しを共有定数へ（描画結果を変えない）
• inline の ## ヘッダ / 注入ブロックを名前付き定数へ（計測可能にする）
• 同一文中の重複語・回りくどい言い換え（意味不変の範囲）

やらない:

• 運用上の警告を省く — 「この引数を小さくすると worker が死ぬ」系の記述は長くても削らない。弱いモデルほど具体例つき警告が効く
• SDK/外部ライブラリ側の tool description — 自前の面だけが対象。それらは計測するが編集しない
• 減らした bytes 自体を成果にする — 副プロンプトの重複解消は一貫性のためであって、毎リクエストの token 節約ではない。効果の大きい層（毎リクエスト層）を優先

計測スクリプトの作り方（無い場合）

scripts/prompt-budget.ts（Node/TS プロジェクト想定）:

• prompt blocks: src/ を走査し const NAME = \...` | '...'（NAME に PROMPT/BLOCK を含む）を抽出。${NAME}` 補間は全定数から再帰解決（WORKER_PROMPT ⊃ BASE_PROMPT 型の入れ子に対応）。エントリポイントが import で main を実行する場合は ソース抽出で回避
• tools: 実際の tool factory を lazy なスタブ deps で構築し、name + description + JSON.stringify(parameters) のサイズを計る
• 出力は表 + --json（前後 diff 用）。トークン推定は chars/4 でよい — 目的は同じ物差しでの比較であり、絶対精度ではない

報告

• before/after の総量と、変化した項目の一覧（SAME/DIFF/NEW/GONE）
• 「描画同一」を機械検証した旨と、文面差があればその意図
• 挙動検証に使ったコマンドと結果