消えた場面を、検査が 6 日待ち続けた。赤は出ていたが、見る人がいなかった
A test waited six days for a scene that had vanished: the red was there, but no one was looking
D27-3-T53-obsolete-test-finale・技術・日本語入力でプレイする仕組み
第一章の終わりの場面を、移動したときに流れる演出から、会話の中で出る形に作り替えました。
検査の期待の行だけが、消えた演出を待ち続けました。
その検査を通せば、毎回赤でした。
ただ最初の 2 日は、誰もその検査を通していませんでした。
直されたのは 6 日後でした。
この回の位置と、前後の回#
区切り: T50〜T57 失敗の名前（8 回のうち 4 回目）
先に読むとよい回: T37（台本の中に期待を書く）
次に読む回: T54（今の値に書き換える誘惑）
名前 — obsolete test#
- 呼び名
- obsolete test（陳腐化したテスト）・test rot（テストの腐り）
- 同じ現象の別の言い方
- test case drift・out-of-date tests
- 初出
- どの語も初出は確かめられませんでした（うちの名前の対照表が使っている呼び名です）
- 組で知っておく名前
- Fragile Test（T55）
obsolete test とは#
仕様が変わったのに、検査が追いついていない状態です。
検査は「前の仕様」を確かめ続けます。
形は 2 つあります。
一つ目は、落ち続ける形です。
新しい仕様では正しい挙動を、古い期待が「違う」と言う。
赤が消えないので、そのうち誰も赤を見なくなります。
監視の分野で言う alarm fatigue（鳴りすぎる警報は無視される）と同じことが、検査の結果の上で起きます。
落ち続ける検査は、隣で本物の回帰が起きても、同じ赤のまま見分けがつきません。
二つ目は、通り続ける形です。
仕様が変わって、検査が確かめている所がもう使われていない。
緑のまま、何も守っていない検査が残ります。
よく知られた対処は、検査を仕様と同じ変更の中で直すことです。
要求が変わったなら、古い要求のために書いた検査は消すか書き直す。
Roy Osherove は 2005 年に、新しい要求で古いテストが落ちたら、それは消すか新しい要求に合わせて書き直すべきだ、と書いています。
実務の記事では、仕様変更のたびに既存の検査への影響を洗い出さないことが、drift の原因として挙がります。
うちの検査の形#
第一章には、作品専用の検査（Game/adv/checks/verify.ps1）があります。
台本どおりに CLI で遊ばせ、出力の中に、期待する行が順番どおりに出るかを見ます。
$i = 0
foreach ($line in $out) {
if ($i -lt $expected.Count -and $line -match $expected[$i]) { $i++ }
}
if ($i -ne $expected.Count) {
Bail 'playthrough' "$($i+1) 番目の期待行が出ていない: $($expected[$i])"
}
期待の行は、聞き込みで着地した意図と、立った旗です。
港の佐伯にアリバイを聞く、番屋の女将に当夜の佐伯を聞く、係船柱を調べる、食い違いを突きつけて崩す。
そして 12 番目の行が、章末の演出（入場イベント）が流れたこと、でした。
うちで起きたこと — obsolete test#
2026-08-11 20:34（9ad8f87c）。
移動するたびに情景と、そこに誰がいるかを書くように直した commit です。
その中で、章末の場面の出し方を変えました。
防波堤に移動しただけで章末の対峙が自動で流れていたのを、会話の中で出る形に移しました。
台本の注記（Game/adv/scripts/events.json）には理由がこう書いてあります。
防波堤へ移動しただけで告白が自動再生され、章で一番重い情報がプレイヤーの発話ゼロで渡っていたため、会話へ移した。
直し方としては正しい変更です。
ただ、作品専用の検査の 12 番目の期待行は、消えた入場イベントのままでした。
その日から、この検査を流すと必ずこう出るようになりました。
FAIL playthrough 12番目の期待行が出ていない: [adv] play scripts/events.json#finale_ch1
この検査は、毎周のループ（adv-loop.ps1）には入っていません。
ループ・作品専用の検査 2 本・判定の 4 本を束ねるゲート（当時の adv-gate.ps1）から回る作りでした。
そして 08/11 から 2 日、ゲートを通した人がいませんでした。
毎周のループは全部緑だったので、そちらを見ている限り、赤は見えませんでした。
2026-08-13 18:33（e43333f5）。
AI 初見プレイの次の回の前に、ゲートが赤いことに気づいて調べた報告（Docs/Reports/2026/08/13/06）です。
題は「ゲートが 08/11 から赤い」。
この FAIL について、期待を書いた commit、前提を変えた commit、そして直し方まで書いています。
「実装が正しく、検査の期待が古い」。
「直し方（軽い）: 台本の末尾に会話の 2 手を足すか、この期待行を外して、章末は通し台本が見る、に一本化する。後者が筋だと思う」。
同じ報告は、落ちている検査が 6 件あること、そして毎周のループは全 PASS のままであることも書いています。
見落とされた理由の欄には「08/11 以降、誰も adv-gate.ps1 を通していない」。
赤い状態でプレイテストを回すと「赤い状態で測った緑」が台帳に残るので、その回は保留しました。
この報告を書いたセッションは、その日、画面のプログラムを直していて、作品データには触れていませんでした。
報告は「別セッター向け」の手順の表（1 番目が、この期待を外すこと・重さ「軽」）で終わっています。
直す順番は書かれ、直す人は決まっていませんでした。
2026-08-17 23:19（4cf9a0cb）。
作品依存のファイルを作品フォルダへ集める大きな整理の中で、ようやく直りました。
commit の本文の「直った検査」の欄にこうあります。
「08/11 に章末が入場イベントから会話へ移った時点で消えた finale_ch1 を、期待行がまだ待っていて永久 FAIL だった」。
ゲートの赤は 6 件から 5 件になりました。
直したこと・いまの仕組み — obsolete test#
直し方は、期待行を「消す」ではなく「外して、外した理由をその場に書く」でした。
いまの verify.ps1 の期待の並びの最後は、こうなっています（最後の期待行は省きます）。
...
# **finale_ch1 をここで待たない。** 08/11 に章末の対峙を入場イベントから
# saeki.confession（会話）へ移した時点で、この台本が踏む入場イベントは無くなった。
# 期待行だけが残って永久 FAIL になっていた（08/17 に発見）。
# 章末とクリアを見るのは adv-loop.ps1 の通し3本と、下の verdict 項目。
)
規約の言い方では「期待を消すときは、その場に理由を書く。落ち続けている検査を放置しない」（named-methods-explained G-3）。
注記には、消したものの代わりにどこが章末を見ているか、まで書いてあります。
守備範囲を外したのではなく、別の検査に渡したことが読めます。
検査の側にも、腐りを見つける仕掛けが 2 つあります。
一つは、台本の中の !known-fail の印です（T37）。
直っていない欠陥に印を付けておくと、その手が落ちても赤にしない。
そして、直ったのに印が残っていると、それを赤にします。
「直ったら落ちる」印なので、印のほうが古くなるのを検査が見つけます。
もう一つは、台本の棚卸し（inventory）です。
作品フォルダの台本のうち、どの検査からも回されていないものがあれば落とします。
2026-08-13 の報告の 6 件の赤のうち 1 件は、まさにこれでした（08/11 に足した台本が目録に無かった）。
2026-08-19 には、逆向きの腐りも見つけています（7767a381）。
岬蓮に、発見から通報までの 40 分の空白を認めさせたあと、発見の状況を聞くと、撤回したはずの「すぐ通報しました」が返り、手帳に新しい証言として積まれていた。
AI 初見プレイの 2 人が報告した欠陥です。
そして既存の台本の 1 本が、まさにその「撤回済みの返事が出る」ことを期待していました。
欠陥を仕様として固定していた、通り続ける形の腐りです。
このときは期待の値を変え、変えた理由を台本の中に書きました（T54 で続きを書きます）。
テスト計画（adv-test-plan.md）の §10 は、変更の種類ごとに何を再テストするかの表を持っています。
意図・旗・条件を変えたら、元の欠陥の確認テストと回帰テスト。
そこに「赤になった作品専用の検査は、同じ変更の中で直す」とまでは書いていません。
名前どおりでない所・まだ残っている弱さ — obsolete test#
名前どおりの obsolete test です。
仕様（章末の出し方）が変わり、検査（期待行）が追いつかず、6 日間落ち続けました。
落ち続ける形の test rot で、その間ほかの検査（毎周のループ）は緑でした。
ただし、alarm fatigue とは少し違います。
最初の 2 日は、赤が鳴りすぎて無視されたのではなく、赤を出す検査が回されていませんでした。
見つけたあとの 4 日は、赤は報告に書かれ、直し方まで決まっていて、手が付きませんでした。
鳴りすぎではなく、鳴る場所に人がいない、の方が近い形です。
記録の側に、小さなずれがあります。
対照表・解説書・verify.ps1 の注記は、どれも「08/17 に発見」と書いています。
けれど 08/13 の報告が、すでに原因と直し方を書いていました。
08/17 は直した日です。
見つけてから直すまでの 4 日が、記録から消えています。
test rot の話でいちばん大事な所は、まさにその「見えていたのに直らなかった」4 日です。
残っている弱さは 2 つです。
一つ目、期待の行は正規表現の文字列で、意図の名前と旗の名前を直書きしています。
意図や旗の名前を変えても、いまのところ lint はこの期待の並びを読みません。
期待が存在しない意図を指していても、実行して落ちるまで分かりません。
ここは確認テストの台本（!expect）とは違い、検査のスクリプトの中に期待が埋まっている形です。
二つ目、落ち続ける赤を「既知」として数える仕組みが、作品専用の検査には無いことです。
台本なら !known-fail で印を付け、件数がテストの集計（known-defects=）に出ます。
verify.ps1 の FAIL は、ただの FAIL です。
いまは作品専用の検査も、テストの集計（adv-test-summary.ps1）の回帰テストの中で毎回回ります。
集計は赤を 1 つでも見たら次の一手を「欠陥を直す」にするので、赤のまま次のプレイへ進む道は塞がっています。
それでも、集計を通さずに毎周のループだけを見ていれば、2026-08-11 と同じことはいまも起こせます。
検索語#
obsolete test cases requirements change
test rot
test case drift
alarm fatigue test failures
『霧走町 流氷に眠る』の第一章の終わりの場面は、移動では流れません。聞いて、ぶつけて、初めて出ます。ブラウザで、そこまでたどり着いてみてください。プロフィールのリンクから。