回帰テストは全部緑だった。それでも AI 初見プレイを 21 回まわして、直し続けた
All regression tests were green, yet we ran 21 blind AI playthroughs and kept fixing
D28-4-T56-gold-plating-exit-criteria・技術・日本語入力でプレイする仕組み
合格の判定は緑でした。
それでも、AI のプレイヤーが感想に書いた不満を見つけるたびに直し、直したらまた遊ばせました。
2 週間で 21 回です。
回すたびに、次の仕事が 1 つ生まれました。
この回の位置と、前後の回#
区切り: T50〜T57 失敗の名前（8 回のうち 7 回目）
先に読むとよい回: T48（AI に初見で遊ばせる）・T51（代わりの指標を目的と取り違える）
次に読む回: T57（一つの契約は一か所で）
名前 — gold plating#
- 正式名
- gold plating（作り込みすぎ）
- 出てくる場所
- プロジェクト管理（PMBOK・PRINCE2 の文脈で説明される。PMI の用語集の定義と初出は確かめられませんでした）
- 止める側の名前
- exit criteria（終了基準。ISTQB の用語集の語。completion criteria と同義で、こちらが優先の語）
- 止め時の観察
- saturation effect（Aditya P. Mathur, "Foundations of Software Testing", Pearson, 第 1 章 1.19 節の題）
- 組で使った名前
- suspension criteria（中断基準）、surrogation（T51）の逆向き
gold plating とは#
合意した範囲を超えて、頼まれていない作り込みを足すことです。
PMBOK の文脈では「範囲の計画に無い機能を足す」、PRINCE2 では「製品の記述に無いものを足す」と説明されます。
足す側に悪意はありません。
「もっと良くしたい」「ついでに直しておこう」という善意から起きます。
それでも、足したものは試験・文書・費用・期間の危険を増やします。
変えるなら、変更の手続き（範囲を変えると決めてから変える）を通す、というのが定番の対処です。
ソフトウェアのテストでは、これが「いつ止めるか」の問題として現れます。
テストは、続ければ何かが見つかります。
見つかったものを直せば、直した所をもう一度確かめる必要が出ます。
止める条件を先に決めておかないと、テストは自分で仕事を作り続けます。
ISTQB の用語では、その条件を exit criteria（終了基準）と呼びます。
テストの活動を正式に終えてよい条件の集合です。
網羅の度合い、未解決の重大な欠陥の数、合否の率などで書きます。
Mathur の教科書は、第 1 章の終わりに「The saturation effect」という節を置いています。
同じやり方で検査を増やしていくと、見つかるものは次第に減り、ある所から先はほとんど増えない。
多くの商用の開発組織で観察される、と紹介されています。
ランダムテストの研究でも、網羅の伸びが止まった点（saturation point）で打ち切る規則が提案されています。
飽和したやり方で続けても、新しい欠陥は出にくい。
続けるなら、やり方を変えるか、止めるか、です。
うちで起きたこと — gold plating#
2026-09-08 から 09-22 まで、AI に初見で遊ばせる探索的テスト（T48）を回していました。
1 回は 3 人のプレイヤー役で、その回の記録は 21 個あります（Docs/PlayLogs の記録。番号の上では第 21 回〜第 40 回で、第 27 回の番号が 2 回使われています）。
その間、合格の判定はどうだったか。
09-22 の調査（Docs/Reports/2026/09/22/01）が、当時の完成の定義（2026-08-05 の仕様）の受け入れ条件に照らしています。
- 通し台本 3 本で clear=yes・LEAK=0・MISS=0 → 満たしている
- 雑談の封印プローブ 60% 以上・連続 2 以下 → 満たしている（84.0%・88.5%・92.3%）
- AI 初見プレイの 6 性質の判定 → 26 項目すべて PASS
- 残りは UE の実機と人のスモークテストで、どちらも AI 初見プレイでは進まない
それでも直し続けた理由を、同じ調査はこう書いています。
「緑と出ている判定を、散文で赤に戻した — これが核心」。
判定は緑なのに、プレイヤー役の感想（「焦点が親切すぎる」「掘れる底が浅い」）を根拠に問題を立て、作業を作り続けた。
散文で合格を書いたのではなく、散文で不合格を書いた。
向きは逆でも、合否をスクリプトから人の読解へ戻した点で同じ違反だ、と。
直したことは、無駄だったわけではありません。
通じなかった手の率は 4.4% から 0.8%、0.3% へ下がっています。
ただ、悪化させたものもありました。
詰まりを減らすために、常に見えている焦点の文に「どこで言うか・誰に聞くか」を 17 件書き足した。
焦点のうち人名か場所名を含む割合は、09-05〜09-21 のあいだ 24〜27% で安定していたのが、この 1 回で 26.6% から 32.9% へ。
そして「焦点が親切すぎる」という不満が最初に書かれたのは 09-08、その時点の割合は 25.7% でした。
2 週間かけて、最初の不満を自分で悪化させたことになります。
同じ 09-08 に判定に入れた「代弁」の指標は、上限を置かず記録だけにしたので、21 回のあいだ一度も動きませんでした。
さらに 09-22 の当日、条件の外の変更（入室の描写に変種を足した）が、条件の内側の検査（手帳の不変条件 N8）を壊していました。
別の AI（Codex）の監査（Docs/CodexReports/2026/09/22/08）は、合格の線が動いていたかを調べています。
期間内の 19 の commit で、プレイの合格の 9 規則と判定の 27 の設定値はどれも変わっていない。
閾値を毎回厳しくしていたのではありません。
変わっていたのは、直す対象の集合と、評価の標本（AI の行動は回ごとに違う）でした。
そして終わり方の規則が競合していた。
「AI 初見プレイは 2 回で止める」という手順と、当時の規約の原則 2「気づいたら、その場で直し切る」と、「変更したら遊び直す」が、一つの順番になっていませんでした。
直したこと・いまの仕組み — gold plating#
2026-09-22 の夜、テスト計画を一か所に決めました（Docs/Guides/Decisions/adv-test-plan.md。32f977bd・40032ea6）。
冒頭の一文は「これが正。テスト対象・テストレベル・合格基準・開始基準・終了基準・中断基準・欠陥管理・リリース判定は、ここ以外に定義しない」。
構成は IEEE 829／ISO/IEC/IEEE 29119-3 のテスト計画の項目に合わせ、用語は ISTQB に合わせました。
決めたことのうち、この回に関わるものを 4 つ挙げます。
一つ目、合格基準とメトリクスを分けた。
合格基準は「1 つでも赤ならそのレベルは終わらない」。
メトリクスは「測って残す。合否に入れない」。
赤でも止まらず、直したければ欠陥管理の「非ブロッカー」へ。
合格基準へ上げるには、テスト計画を改定する。
二つ目、終了基準を機械が判定する。
L1（CLI のシステムテスト）の終了は L1=MET だけ。
次に何をするかは、テストの集計が next= で 1 つだけ出します。
探索的テストを回すのは next=RUN-EXPLORATORY のときだけで、メトリクスの赤・感想・「念のため」では回さない（§11）。
その判定はスクリプトの純粋な関数で、試験の表と一緒に置いてあります（Scripts/adv-test-decision.ps1）。
elseif ($S.Suspended -or ([int]$S.FailedAttempts -ge $max)) { $next = "SUSPENDED($([int]$S.FailedAttempts))" }
elseif (-not $regOk -or $known -gt 0) { $next = 'FIX-DEFECTS' }
elseif ($dirty -gt 0) { $next = 'COMMIT' }
elseif ($firstRun) { $next = 'RUN-EXPLORATORY' }
elseif ($S.Exploratory -in 'NOT-RUN', 'UNMEASURED') { $next = 'RUN-EXPLORATORY' }
三つ目、中断基準を置いた。
数える単位は「統合試行」（コミットした版が終端の結果に達したこと）。
未達が連続 3 試行に達したら SUSPENDED。新しい修正もプレイも始めない。
再開はユーザーが判断し、理由を書いて記録する。
AI が自分で再開してはいけない。
テスト計画の §7 の末尾に、経緯が一行あります。
「2026-09-08〜22 に 21 サイクル回して終わらなかった（見つかったものを全部直す × 直したら必ず回す）」。
四つ目、欠陥の重要度を 2 段にした。
ブロッカーは、読了できない・必須の事実が食い違う・保存が壊れる・入力や表示ができない、など。
言い方を変えれば進める詰まり、同じ返事の再生、より自然にしたい、メトリクスの赤、感想は非ブロッカーで、直さず報告書に 1 行残す。
欠陥が複数あれば、まとめて直して確認テストと回帰テストを通してから、全編の評価に戻る。1 件直すたびに探索的テストへ戻らない（§10）。
規約（CLAUDE.md）の原則も書き換えました。
原則 2 はいまこうです。
「着手した修正は直し切る。発見を自動で仕事にしない。……新しく気づいたものは、テスト計画 §8 の欠陥管理で『ブロッカー』に当たるときだけ直す。当たらないものは『未採用の改善』として報告書に 1 行残す（2026-09-22: 発見を全件その場で直した結果、AI 初見プレイ 21 回が終わらなかった）」。
原則 4 は「合否を感想で上書きしない」で始まります。
その後#
統合試行の台帳（Game/adv/test-attempts.json）は、2026-09-22 22:13 の第 41 回から始まります。
今日までに 52 行。試行が 46（未達 36・達成 5・記録の異常 5）、ユーザーによる再開が 6。
最初の L1-MET は、翌日 09-23 18:29 の第 44 回でした。
再開の 6 件の理由は、どれも「ユーザーが再開を明示」「ユーザー判断」「ユーザー指示」で始まります。
探索的テストは、いまも回しています。
ただ、回すか止まるかを決めるのは、プレイヤー役の感想でも開発の AI の判断でもなく、終了基準と中断基準と、ユーザーの再開の記録です。
名前どおりでない所・まだ残っている弱さ — gold plating#
gold plating は、ほぼ名前どおりです。
合意した範囲（受け入れ条件）を満たしたあとに、範囲の外の改善を足し続けました。
ただ、うちの改善は機能を足すことではなく、感想に応えることでした。
名前の対照表はこれを「surrogation の逆向き（散文で機械の判定を上書きする）」と並べています。
T51 は代わりの指標を目的と読んだ話で、こちらは目的を測る指標の緑を、指標ではない散文で覆した話です。
exit criteria は、無かったのではありません。
当時の完成の定義には受け入れ条件があり、雑談には「打ち止め」とまで書いてありました。
09-22 の調査の言葉では「合格条件は定義されていた。守っていなかったのは私（Claude Code）である」。
その文書を、そのセッションで一度も開いていませんでした。
無かったのは、終了基準を読む手順の方です。
いまの next= は、そこを人や AI の読解から外した対処です。
saturation effect は、名前を借りているだけです。
うちは「新しく見つかる欠陥の数が飽和したか」を測っていません。
名前の対照表は、指標として defect escape rate（後の工程で見つかった欠陥の率）を挙げていますが、それも数えていません。
止めているのは飽和の測定ではなく、未達の連続回数という、もっと素朴な線です。
残っている弱さは 2 つです。
一つ目、L1=MET は終わりではありません。
台帳の達成 5 回は、達成したあとにまた作業が入り、未達に戻ったことを意味します。
テスト計画は「L1=MET をリリース可と言わない」と書き、L2〜L4（UE 実機・人・Steam）を別に持ちます。
終了基準はレベルごとにあり、製品の完成はその先にあります。
二つ目、中断から抜けるのはユーザーの一言です。
再開の理由はいつも記録に残りますが、再開するかどうかの判断は、機械の外にあります。
そして、テスト計画そのものを改定すれば、合格基準もメトリクスも動かせます。
2026-09-23 には実際に、ユーザーの指示で合格基準を読了に絞りました。
止まる仕組みは、止まる理由を書く場所を一か所に集めた、というところまでです。
検索語#
gold plating project management
exit criteria ISTQB
saturation effect software testing Mathur
when to stop testing
全三章の製品版は、Steam でウィッシュリストに入れられます。『霧走町 流氷に眠る』の第一章はブラウザで無料です。どちらもプロフィールのリンクから。