「完成＝10 項目 PASS」と手順書に書いた 43 分後、本物の合格条件を開いた
43 minutes after writing "done = 10 items PASS" into the procedure, I opened the real pass criteria
D26-3-T51-surrogation-ten-items・技術・日本語入力でプレイする仕組み
道具の通過条件を、完成の定義として手順書に書きました。
それを的にして進めているあいだ、本物の合格条件は別の文書にずっと書いてありました。
誰もずるをしていません。
善意のまま、代わりの指標が目的に入れ替わっていました。
この回の位置と、前後の回#
区切り: T50〜T57 失敗の名前（8 回のうち 2 回目）
先に読むとよい回: T50（通じ率 23% が 100% になった日）
次に読む回: T52（古い焼き物が回帰を隠す）・T56（作り込みすぎと終わりの基準）
名前 — surrogation#
- 正式名
- surrogation
- 日本語
- 代理指標と目的の取り違え（定まった訳語は見当たりません。英語のまま検索してください）
- 初出
- Jongwoon (Willie) Choi, Gary Hecht, William B. Tayler, "Lost in Translation: The Effects of Incentive Compensation on Strategy Surrogation", The Accounting Review 87(4), pp. 1135–1164, 2012
- 近い名前
- Goodhart's law（T50）
surrogation とは#
surrogation（代理指標と目的の取り違え）とは、管理者が戦略の代わりに置いた指標を、戦略そのものとして扱ってしまう傾向のことです。
管理会計の言葉です。
会社には戦略があり、戦略は直接は測れないので、指標を置きます。
顧客満足を上げる、という戦略に、満足度調査の点数を置く、というように。
指標は戦略の代わり（surrogate）です。
Choi・Hecht・Tayler は、管理者がこの「代わり」を戦略そのものとして扱ってしまう傾向に名前を付けました。
指標を最大にする選択が、戦略に反するときでもそうする。
理屈の下敷きは、Kahneman と Frederick の attribute substitution（答えにくい問いを、答えやすい問いに置き換えて答えてしまう）です。
2 つの実験で、指標 1 つで報酬を払うとこの傾向が強まり、指標を複数にすると弱まることを示しました。
語の着想は、会計学者の Yuji Ijiri の仕事から来ている、と紹介されています。
Goodhart's law との違いは、向きと動機です。
Goodhart's law は、指標に圧力がかかると指標と目的の関係が壊れる、という観察でした。
圧力をかける側には、多くの場合、指標を上げたい動機があります。
surrogation は、その手前で起きる認知の滑りです。
不正をしようとも、手を抜こうとも思っていない人が、指標を見ているうちに「指標が目的だ」と思い込む。
うちの解説書（named-methods-explained G-2）は、これを「Goodhart 則の静かな版」と書いています。
よく挙がる例は、営業の成約件数を指標にしたら、顧客の満足が下がる成約まで追いかけるようになった、というものです。
ソフトウェアでは、カバレッジの率を品質そのものと読むのが、いちばん身近な形でしょう。
既にある対処は、論文の結果そのものです。
指標を 1 つにしない。
そして、戦略（目的）を指標とは別の場所に、言葉で置いておき、ときどき指標の方から戻って読む。
うちで起きたこと — surrogation#
2026-08-17、作品を量産する工程を作っていた日です。
時刻つきで追います（どれも git の commit の時刻）。
10:22（4e2e1d68）
作品 1 本ぶんの検査をまとめた Scripts/adv-verify-work.ps1 を作りました。
lint・reach・clearpath・最短経路・1 手抜いたらクリアしないこと・設計と実測の手数・寄り道・手帳・情景の探りなど。
あわせて 10 項目を PASS／FAIL で出します。
21:54（73660ebf）
散らばっていた手引き 4 本を、作業手順書 1 本（adv-playbook.md）にまとめました。
収束しない原因を考えて、§0 に書いたのがこれです。
- 検査の集合を凍結する
- 完成の定義: verify-work の 10 項目 PASS。それだけ。
- 検査できないもの（文章の質・通じ率）は完成条件に入れない。入れると永久に終わらない
理屈は通っています。
作品を作るあいだに検査を増やすと、ゴールが逃げる。だから検査を凍結して、凍結した検査を完成の定義にする。
ただ、この時点で、完成の定義はすでに別の文書にありました。
2026-08-05 に書いた「完成のゴール」の仕様（Docs/Reports/2026/08/05/05）です。
その受け入れ条件 1 は「言い回し違い・順序違いの通し台本を 3 本、全本で clear=yes / LEAK=0 / MISS=0」。
手順書は、その文書を指していませんでした。
22:37（444e6105）
その受け入れ条件 1 を開いて、測ろうとしました。
commit の本文はこう始まります。
「受け入れ条件（08/05/05）の条件1は……だが、その台本が存在していなかったことが分かった」。
新しく通し台本を 1 本書いて流すと、clear=yes・MISS=0 で、LEAK（入力が話題の語を含まないのに推理が進んだ手）が 1 件。
ある証言の段が、材料を突きつけずに「あの晩、ほかに誰か見かけませんでしたか」だけで開いていました。
本文の最後の一言はこうです。
「数日ぶんの『完成』が、実は自分で作った別の的に当てていただけだった、と分かった日の最後のコミット。ゴールの文書は最初から正しかった」。
23:19（4cf9a0cb）
LEAK を直しました（材料の条件に入っていた語を、その意図の話題の語にも足した）。
そして手順書の冒頭を差し替えました。
完成の定義は 05 が正で、手順書の「10 項目 PASS」「70 手」は道具の通過条件だ、と明記しました。
23:57（3804e270）
この失敗に surrogation と名前を付けて、名前の対照表に入れました。
直したこと・いまの仕組み — surrogation#
規約は「ゴールの文書を 1 つに固定し、手順書の冒頭でそこを指す。手順書はゴールを定義しない」です。
いまの手順書の §0 は、この形です（adv-playbook.md から）。
合格条件の正は Docs/Guides/Decisions/adv-test-plan.md（1か所）。
この手順書に書いてある数値（10項目・70手）は道具の通過条件であって、
完成の定義ではない。両者を混ぜない。
その下に、手順書の数値と本当の意味の対照表があります。
- adv-verify-work.ps1 の 10 項目 PASS → 作品データとして成立していることの判定。テスト計画の前提であって、それそのものではない
- 目標手数 70 手 → 見積の目安
- lint・P0〜P9 → 作品データと企画の健全性
さらに、手順書には「現況をここに書かない」という節があります。
表に○×を並べると、次に読む人がそれを現況として読むからです。
2026-08-20 に、3 日前の記録を今の状態と読み、要らない改善案を 4 件立てたことがありました。
いまどうなっているかは、テストの集計（adv-test-summary.ps1）の出力と、作品の台帳だけが正です。
プロジェクトの規約（CLAUDE.md）の入口の表にも、テスト計画の行に「これ 1 か所が正」と書いてあります。
旧い 08/05/05 は「履歴」と明記して、正の座から下ろしました。
原則の 6 番目は「一つの契約は一か所で定義する。変えるときは旧文を置き換える（例外を追記しない）」です。
名前どおりでない所・まだ残っている弱さ — surrogation#
surrogation は、名前どおりに起きました。
目的（受け入れ条件）は言葉で書いてあり、代わり（10 項目）は自分で作ったもので、代わりの方を目的として読んだ。
報酬の話ではないので、論文の実験の条件（報酬の払い方）とは違います。
指標を 1 つにすると強まる、という所だけは同じ形でした。
その日、見ていた数字は「10 項目」の一つだけでした。
ただ、記録を読み直すと、話は記録の言い方ほどきれいではありません。
一つ目、「数日」は git の履歴と合いません。
手順書と解説書は「この手順書の完成＝10 項目 PASS を的にして数日進めた」と書いています。
けれど 10 項目の検査ができたのは同じ日の朝で、完成の定義として手順書に書いたのは夜の 21:54。
43 分後には受け入れ条件を開いています。
その前の数日、量産の工程を作っていたあいだに「道具が通れば完成」と考えていた、という意味かもしれません。
それは記録からは決められません。
二つ目、「通し台本が存在していなかった」は、42 分後に本人が訂正しています。
4cf9a0cb の本文は「通し 3 本は前から存在していて、前から通っていた（adv-loop.ps1 が回している）」。
実際、2026-08-05 の bbc7c8d6 で 2 本を足し、3 本ともループに常設していました。
22:37 の調べ方は、古い名前の台本 3 本だけを見て、別の名前の 2 本を見落としていたのです。
それでも、新しい 1 本は本物の LEAK を見つけました。
3 本の通し台本は通っていたが、漏れていた一文を含んでいなかった。
4cf9a0cb は、その一文を通し台本の 1 本に入れて、再発を捕まえるようにしています。
ところが手順書のいまの文は「05 の条件1（通し台本3本）が一度も測られていなかった」のままです。
訂正の方が、正の文書に入っていません。
surrogation を戒める注記そのものが、記録の古い方を写している形です。
三つ目、同じ失敗を 2 度目に踏みました。
2026-09-22 の調査（09/22/01）の結論は「合格条件は定義されていた。守っていなかったのは私（Claude Code）である」。
完成の定義の文書を、そのセッションで一度も開かず、別のスクリプトの出力を完成条件として扱いました。
規約に「迷ったらテスト計画を読む」と書いてあっても、読まなければ効きません。
この 2 度目は向きが逆で、緑の判定を感想で赤に戻して仕事を作り続けた話でした（T56 で書きます）。
規約は人と AI が読むものです。
読んだかどうかは、いまも機械では確かめていません。
いま機械にあるのは、テストの集計が次の一手（next=）を 1 つだけ出す仕組みです。
次に何をするかを、読み手の解釈に任せない方向の対処です。
検索語#
surrogation
strategy surrogation Choi Hecht Tayler
attribute substitution Kahneman Frederick
Goodhart's law surrogation
『霧走町 流氷に眠る』の第一章は「3 手で進める」「通し台本 3 本」の数字のためではなく、読んで解くために作っています。ブラウザで、第一章の終わりまで読んでみてください。プロフィールのリンクから。