改訂を測って採る（Measuring Revisions Before Adopting Them）

命令ファイルへの改訂は、書いた本人の手応えで残る。効いたかを測る場所を持たないかぎり、悪化させた改訂も残り、次の改訂の土台になる。

問題

命令ファイルや手順文書は育つ。育て方はたいてい同じである — 期待と違う結果が出た、原因らしきものに見当が付いた、一行書き足す。次も違った、また書き足す。

この改訂に採否の判定が無い。 書いた本人が「良くなったはずだ」と感じたかどうかで、その一行は残る。

判定が無いことに気づきにくい理由が3つある。

第一に、改訂の効果は同じ入力を二度流さないと見えない。 改訂した後に流すのは、たいてい次の依頼である。前の依頼をもう一度流して比べることは、まずしない。比べていないので、良くなったかどうかは体感でしか言えない。

第二に、出力は毎回違う。 一度うまくいったことは、改訂が効いた証拠にならない。改訂せずに二度目を流しても、うまくいったかもしれない。一度の成功と一度の失敗を、改訂の効果と読み違える余地が常にある。

第三に、改訂は積み上がる。 悪化させた一行は、その後の改訂が乗る土台になる。土台が傾いていることに誰も気づかないまま、その上で微調整が続く。

結果として、文書は太る。太った文書のどの行が効いているかを、誰も言えない。棚卸しをしようにも、消してよい根拠が無い — 効いていないと示せた行が一つも無いからである。

コンテキスト

適用する条件:

• 命令文書が育ち続けている — 改訂が積み上がり、初期の版から何度も書き換わっている
• 同じ形の仕事を繰り返している — 過去の依頼を取り置いて、判定に使い回せる
• 成否を自分で判定できる — テストが通る、期待した形式で出る、指定した手順を踏んだ、といった形で表せる
• 改訂の代償が大きい — その文書が多くの仕事に効いており、悪化させたときの被害が広い

適用しないケース:

• 一度きりの仕事。 測る対象が次に来ない
• 命令が短く、全体を見渡せるとき。 傾いた土台が隠れる余地が無い
• 成否を判定できない仕事。 好みの問題や、正解の定義できない仕事に、この型は置けない。測れないものにゲートは置けない
• 機械で止められる失敗を扱っているとき。 それは命令の改訂ではなく機械ゲートの仕事である

隣接パターンとの境界:

• 失敗の制度記憶化 — 最も近い。同パターンは失敗を書き残すとき何を書くかのふるいであり、書く前に掛かる。本パターンは書いた後に効いたかをどう判定するかであり、書いた後に掛かる。同パターンが自ら「これは測定ではなく判断である」と但し書きしている箇所こそ、本パターンが埋めようとする穴である
• 常駐物の棚卸し — 減らす契機が違う。同パターンの契機は総量、本パターンの契機は成績である。⚠ 文書の総量と、1回の改訂の差分量は別の話である — 混同すると「短くしたから測った」ことになってしまう
• 検証対象の明示 — 同パターンは1回の作業で何を検証させるかを扱う。本パターンは命令文書の版どうしを比べる。検証の対象が、成果物か命令かで分かれる
• 機械ゲートと意味ゲートの分離 — ゲートが掛かる先が違う。同パターンのゲートは成果物（コード・文書）に掛かり、本パターンのゲートは命令そのものに掛かる
• 記録した判断を後から監査させる — 捨てた改訂とその理由は、判断記録の一種である。同パターンは記録を残して後から見直させ、本パターンはその記録を次の改訂の入力にする

解決

改訂を、書いた時点では採用しない。 候補として置き、測ってから採否を決める。

部品は4つである。

1. 判定用の事例を、改訂を書くときには見ない。 これが要である。改訂は、見た事例に合わせて書ける。見た事例で良くなることは、改訂が効いた証拠にならない — 答えを見て書いたのだから、良くなって当たり前である。判定に使う事例は、書くときに見ていないものでなければならない。

2. 基準線は「直前の版」に置く。 絶対的な良し悪しは要らない。問うのは「前より良いか」だけである。この置き方なら、文書がどれだけ育っても比較の形は変わらない。

3. 上回らなければ捨てる。 既定を「捨てる」側に置き、残すほうに挙証責任を負わせる。この非対称が本パターンの効き所である。「悪くはなさそうだから残す」を許すと、判定が無い状態に戻る。

4. 捨てた改訂と、その理由を残す。 捨てた記録が無いと、半年後に同じ改訂を思いつき、同じ費用を払って同じ結論に至る。記録は次の改訂への負のフィードバックになる。

補助的な規律が2つある。

• 一度に変える量に上限を置く。 大きく書き換えると、上回らなかったときにどの変更が悪かったのかを切り分けられない。上限は判定の解像度のためにある。⚠ これは文書の総量の話ではなく、1回の差分量の話である
• 改訂の材料は複数の実行から取る。 一件の失敗に当て込んだ改訂は、その一件でしか効かない。複数の実行に共通して現れた失敗だけを、手順に折り返す

なぜ効くのか

理由は道具の機能ではなく、命令文書が持つ構造の非対称にある。

追加には動機がある。失敗が見えた瞬間に、書き足す理由が生まれる。ところが削除と撤回には動機が無い — 誰も「この行が無ければうまくいっていた」とは気づかない。効いていない行は、失敗として現れないからである。

この非対称は、放っておけば必ず片側に積む。文書は単調に増え、増えた分だけ他の記述が薄まる。測る場所は、追加の側にだけ費用を課してこの非対称を打ち消す装置である。 「良くなった気がする」を通さないことが目的であり、精度の高い測定を得ることが目的ではない。

⚠ 本カタログは、この型を人が手で運用したときの効果を測っていない。 根拠がどこまで届いているかは具体例節に書く。

トレードオフ

取り置きの課題集を維持する費用が要る。 事例は集め、保ち、陳腐化したら入れ替えなければならない。文書そのものより手間が掛かることもある。

改訂の回転が遅くなる。 一行直すたびに複数回の実行が要るなら、軽い改訂は割に合わなくなる。これは損とは限らない — 割に合わない改訂を止めることこそ狙いだからである。ただし「気づいたときに直す」という良い習慣も一緒に止まるため、軽い改訂には測定を求めない、という線引きを先に決めておく。

取り置きが小さいと、そこにだけ効く改訂が通る。 判定を通った改訂が、判定に使った事例でしか良くならない。事例の数と多様性が、そのまま判定の信用になる。

測れない良さは落ちる。 読みやすさ、後任にとっての分かりやすさ、将来の保守しやすさは、成績に出ない。成績に出ないものを「価値が無い」と読み替えないこと。 この型が言えるのは「効いたと示せなかった」までであり、「無価値である」ではない。

出力の揺らぎを改訂の効果と取り違える。 一度の実行で採否を決めると、モデルの非決定性をそのまま判定に通してしまう。複数回流すか、揺らぎの幅より大きい差だけを採るか、どちらかが要る。

最も軽い運用は、測定と呼べないほど小さい。 全部を揃えるのは重い。変える前に、同じ依頼を一度流して結果を残しておくだけでも、比べる相手ができる。非対称は完全には消えないが、少しは崩れる。

GitHub Copilot での具体例

弱い形 — 「試して、結果を見て直せ」— は両ベンダーの一次資料にある。 以下はいずれも 2026-07-27 に curl で生の本文を取得し、全文に対して検索した結果である。バイト数は全文を取得したことの記録であり、同一性の証明ではない。

VS Code 面 — prompt file を試して直す 公式

出典: Prompt files（80,378 バイト。HTML をタグ除去して検索）。

Use the editor play button to test your prompts and refine them based on the results.

〔訳〕エディタの再生ボタンで prompt を試し、その結果に基づいて改良する

This option is useful for quickly testing and iterating on your prompt files.

〔訳〕この方法は、prompt file を素早く試して反復するのに役立つ

github.com 面 — カスタムエージェントを複製して更新を試す 公式

出典: Testing and releasing custom agents（4,876 バイト）。

You can create a net-new profile or duplicate an existing profile to test potential updates.

〔訳〕新規の設定を作るか、既存の設定を複製して、変更候補を試すことができる

Continue making changes and testing your custom agent as needed until you are satisfied with its performance.

〔訳〕満足のいく性能になるまで、必要に応じて変更とテストを続ける

本パターンとの差はここに現れる。 公式が述べているのは「満足するまで」であり、何をもって満足とするかは書き手に委ねられている。 直前の版との比較も、下回った改訂を捨てる条件も無い。

Anthropic 側の対応物 — 最も近い一文 公式

出典: Claude Code の Best practices（39,582 バイト）。

Treat CLAUDE.md like code: review it when things go wrong, prune it regularly, and test changes by observing whether Claude's behavior actually shifts.

〔訳〕CLAUDE.md をコードのように扱う — うまくいかなかったときに見直し、定期的に刈り込み、挙動が実際に変わるかを観察して変更を試す

確認した範囲で、命令文書の改訂そのものを試せと明示している記述はこれが最も近い。 ただし言っているのは「挙動が変わったかを観察せよ」までであり、変わった方向が良いかを取り置きの事例で測れとは言っていない。

同じ資料は、判定を機械に閉じさせる価値のほうは明確に述べている。

Claude does the work, runs the check, reads the result, and iterates until the check passes.

〔訳〕Claude は作業し、チェックを走らせ、結果を読み、チェックが通るまで反復する

⚠ これは成果物に対する検証であって、命令文書の改訂に対する検証ではない。 対象を取り違えないこと（境界は機械ゲートと意味ゲートの分離）。

取り置き集合の語は、別の文脈で使われている 公式

出典: Anthropic の Create strong empirical evaluations（137,547 バイト）。

Our sentiment analysis model should achieve an F1 score of at least 0.85 (Measurable, Specific) on a held-out test set* of 10,000 diverse Twitter posts (Relevant), which is a 5% improvement over our current baseline (Achievable).

〔訳〕感情分析モデルは、1万件の多様な投稿からなる取り置きのテスト集合で F1 スコア 0.85 以上（測定可能・具体的）を達成すべきであり、これは現在の基準線に対する 5% の改善である（達成可能）

Design evals that mirror your real-world task distribution. Don't forget to factor in edge cases!

〔訳〕実世界のタスク分布を映す評価を設計する。境界事例を織り込むことを忘れないように

⚠ 射程が違う。 ここで測られているのはアプリケーションの性能であって、命令文書の改訂の採否ではない。取り置き集合と基準線という語が両方出てくるため、本パターンの根拠として引きたくなるが、同じ語が同じ用途で使われているわけではない。 本パターンは、この考え方を命令文書の改訂に向けた場合の型である。

不在確認 — 強い形は、確認した範囲のどこにも無い

上記4資料に加え、github.com のリポジトリ向けカスタム命令（22,848 バイト）、最初の prompt file（3,087 バイト）、出力のレビュー（2,472 バイト）、VS Code のカスタム命令（114,884 バイト）とエージェント概要（64,541 バイト）、Anthropic の Agent Skills のベストプラクティス（41,420 バイト）を加えた計11資料の本文全体を対象に検索した。取得と検証は、素材を取り込んだ主体とは別の主体が独立に行っている。

探した記述	主な検索語	結果
取り置き集合で直前の版と比べ、上回るときだけ採る	held-out test set / baseline / earlier version	該当なし（語はあるが、対象が命令の改訂ではない）
捨てた改訂と理由を残して次に使う	reject / rejected / discard / negative feedback	該当なし（対象がエージェントの出力、または変更提案の却下）
1回の改訂量に上限を置く	bounded / limit / one change	該当なし
複数の実行から共通する失敗を抽出する	multiple / common / diverse / edge cases	該当なし（評価集合の多様性・複数モデルでの試験の話）
改訂時に費用を払い、配備時は追加の呼び出しを要さない	static / additional model / deploy	該当なし

「一次資料に無い」は「存在しない」ではない。 確認した範囲の外にあるかもしれない。ここで言えるのは、上記11資料の全文にはこの形の記述が無い、ということだけである。

量の目安は「総量」であって「差分量」ではない 公式

出典: Adding repository custom instructions（github.com 面、22,848 バイト）。

Instructions must be no longer than 2 pages.

〔訳〕命令は2ページを超えてはならない

⚠ これは文書の総量の上限であり、本パターンが言う「1回の改訂量の上限」ではない。 総量の目安は常駐物の棚卸しと命令の階層化と適用範囲の限定が扱う。同じ「上限」という語で二つを混ぜないこと。

研究 — 強い形を測った資料は、確認した範囲で1本だけである

arXiv:2605.23904（v2、2026-05-25 更新、PDF 879,864 バイト、2026-07-27 取得）は、手順文書を凍結したモデルの外部状態として反復改訂する手法を提案し、取り置き集合での採否ゲート・棄却した改訂の再利用・改訂量の上限・複数実行からの抽出を、いずれも安定化のための装置として置いている。著者には Microsoft と複数の大学が含まれる。

⚠ 限定を3つとも外さないこと。

• これはベンダーの製品文書ではない。 学術 preprint であり、査読状況の記載は原文に無い。著者に Microsoft が含まれることは、Copilot の公式記述であることを意味しない — 論文は VS Code / github.com / Copilot CLI / cloud agent のいずれの面も記述していない
• 測られたのは自動最適化器の性能であって、人手の改訂ではない。 「人が自分の命令ファイルを測って直せば良くなる」は、この論文の射程の外にある
• 本カタログは同論文の改善幅の数値を引かない。 自動最適化器どうしを比べた値であり、人が改訂したときの値ではない。採るのは向きだけである

別名

呼称	出典
改訂を測って採る / Measuring Revisions Before Adopting Them	記述 — 本カタログの記述的呼称であり、一次資料に出典は無い
プロンプト最適化 / prompt optimization	通説 — 主に自動化の文脈で使われる語であり、人が改訂の採否を決める実践の名ではない
回帰テスト	通説 — コードの文脈で確立した語。命令文書に適用した用例の一次出典は確認できていない

素材となった研究には手法の固有名があるが、本カタログはそれをパターン名に使わない。 手法名を型の名前にすると、「その手法を使っている＝この型が成立している」という誤解を生む。実際には、手法を使わずにこの型を満たすことも、手法を使いながら判定用の事例を分けそこねることもできる。

関連

• 失敗の制度記憶化 — 書く前のふるいが同パターン、書いた後のゲートが本パターンである。同パターンが「これは測定ではなく判断である」と留保した箇所が、本パターンの出発点になる
• 常駐物の棚卸し — 減らす契機が総量か成績かで分かれる。⚠ 文書の総量と1回の差分量を同じ「上限」で語らないこと
• 検証対象の明示 — 1回の作業の検証対象が同パターン、命令文書の版どうしの比較が本パターンである
• 機械ゲートと意味ゲートの分離 — ゲートが掛かる先が、成果物か命令そのものかで分かれる。成果物で止まる失敗を命令の改訂で直そうとしない
• 記録した判断を後から監査させる — 捨てた改訂と理由は判断記録の一種であり、後から見直す対象になる
• 命令の正本を一つにする — 正本が割れていると、どの版を測ったのかが定まらない。測る前提として効く