# 関門を直しても、すでにあるデータは直らない：「もう試した」印・URL の目印・対応表の 3 つの実例 > 判定を直したのに既存の 32 件のうち 12 件が直らなかった（印が 7 日残る）、URL に載せた目印が張り替えで失われて 111 件が再分割された、対応表から外しても書かれた値が残った。同じ形の報告が 5 件だった監査の記録。 - URL: https://koshinstudio.com/notes/fix-the-existing-data/ - 公開: 2026-10-17 - 書いた人: Koshin（https://koshinstudio.com/about/） - サイト: Koshin Studio English version (https://koshinstudio.com/en/notes/fix-the-existing-data/) トレカダッシュ 開発の記録 ／ 2026年8月〜9月 iOS アプリ「トレカダッシュ (https://koshinstudio.com/works/torecadash/)」の開発では、「直したのに、直っていない」という報告が、何度も、同じ形で来ました。コードを直す。テストも通る。ところが、画面には、まだ間違いが残っている。 理由は、コードを直しても、すでに保存されているデータは、書き換わらないことです。この記事では、その 3 つの形を、実例で書きます。 数字は、2026 年 8 月 26 日、9 月 3 日、9 月 8 日の作業の記録から書いています。 ## 1. 関門をゆるめたのに、「もう試した」印が残っていた（9 月 3 日） 商品の照合の判定（関門）に、直すべき間違いがありました。直して、配備しました。ところが、すでにある記事 32 件のうち、12 件が直らないままでした。 理由は、「見送りの印」でした。関門が一度、「この組み合わせは違う」と見送ると、その記事には、「もう試した」という印が付き、7 日間は再挑戦しません。判定を直しても、印のあいだは、見直されません。しかも、その 12 件の中に、締切が 9 月 5 日と 6 日の、受付中の抽選が 4 件ありました。抽選は数日で締め切るので、印の期限を待っていると、そのまま消えます。同じ日に、同じ形（複数の商品に分割する処理の、14 日間のクールダウン）が、もう 1 つ見つかりました。 直し方は、印を見て「見送る」前に、いまの判定で、もう一度確かめることでした。判定を、AI も外部も使わない、純粋な関数に切り出せば、費用は増えません。あわせて、「そのとき、どの材料で判断したか」（画像を見たか、など）を印に残しておくと、材料が増えたときだけ、再挑戦できます。 ## 2. 状態の目印を、URL に載せていた（9 月 3 日） 分割して作った記事（子）には、「分割済み」の目印が必要です。当時は、その目印を、URL の一部（?_product=商品名）に置いていました。「この印が付いていたら、二度と分割しない」。 ところが、このプロジェクトは、応募先の URL を、あとから店の公式のページに張り替えます。同じ日に、その張り替えを全件に回すようにしました。すると、URL に載せた情報は、必ず失われます。子の記事 832 件のうち、111 件が、目印を失いました。目印がなくなった子は、「まだ分割していない親」に見え、再び分割されました。自分自身を「代わりの記事」として指す、壊れた記事が、30 分で 8 件から 14 件に増えていました。過去にも、同じ経路で、1 件が 18 件に増えた事故がありました。 直し方は、判定を、書き換わらない項目（splitFromArticleId のように、記事に残る項目）で行うことでした。もう 1 つの教訓は、「今まで一部にしか当たっていなかった処理を、全件に回す」直しを入れた日は、その処理が書き換える項目に頼っている所を、必ず洗うことです。 ## 3. 対応表からキーを外しても、書かれた値は消えない（8 月 26 日） ある店のチェーンを、「いちばん近い支店を探す」対応表から外しました。コードの表からは消えました。ところが、記事に書かれた「近い支店の鍵」は、そのまま残っていました。アプリは、「鍵があるから、距離を出そう」と判断して、準備だけして、答えが返ってきません（サーバーは、解決できない鍵に 400 を返します）。永久に埋まらない記事が、3 件ありました。 表の変更は、コードの変更で、データの移行までは自動で起きません。表から何かを外すときは、既存のデータの掃除も、セットで入れます。これは、「新しい非表示の印を足したのに、元に戻す処理に足し忘れる」ミスと、対になる型です。あちらが足す側の漏れで、こちらが引く側の漏れです。 掃除を入れると、監査に新しい異常が出ることがあります。それは、隠れていた本物の穴が、見えただけです。鍵を戻して、隠さないことにしました。 ## 同じ形の、5 つの報告（9 月 8 日） 9 月 8 日に、監査 61 本を流して見つけた 7 件のうち、5 件が、同じ形でした。「直す仕組みはあるのに、対象に届いていない、または順番が回らない」。 症状 | 根っこ 店名に営業日が混ざる（報告 4 回目） | 直す側と関門が、別の関数。コメントの「同じ物差し」が、嘘になっていた 通知を押しても、記事が無い（322 件） | 埋める処理の対象に、その印（分割済み）が、入っていなかった 公式イベントが表示されたまま | 弾く関門は、あるのに、当て直しの順番が回っていなかった 定価の目安の単位ずれ（24 件） | 直しが、25 本の持ち回りに埋もれて、一巡 2.5 日 「時間予算のため 19 件を次回へ」 | 安い直しが、重い直しと、同じ予算・同じ持ち回りに入っていた 関門は、新しい記事しか守りません。すでにある記事を直すのは、別の処理です。そこが動いていないと、「直したのに、直っていない」が、延々と繰り返します。同じ形の報告が何度も来るなら、たいてい、入口を直して、出口（すでにあるデータ）を直していません。 共通の解決策は、関門そのものである「保存の関門を、すでにある記事にも当て直す処理」を、持ち回りから外して、毎回走らせることでした。中身は、記事を 1 回読んで関門に通すだけです（AI も外部も使わず、1 回 20 件と印 50 件の上限つき）。 ## 分かったこと > 入口を直したら、出口（すでにあるデータ）も直す。 - 関門を足したら、当て直しが毎回走るかを確かめる。関門は、新しい記事しか守りません。 - 「もう試した」印は、いまの判定で確かめ直す。期限を待つと、抽選は終わっています。 - 状態の目印は、書き換わらない項目に置く。URL は、あとから張り替わります。 - 表から外したら、データも掃除する。コードの変更では、データは動きません。 - 同じ報告が 2 回来たら、出口を疑う。入口の直しだけでは、足りていません。 この話に出てくるもの - トレカダッシュ (https://koshinstudio.com/works/torecadash/) — トレカの抽選・予約・先着の情報を集める iPhone アプリ - 監査 61 本を総点検して見つけた 4 つ (https://koshinstudio.com/notes/audit-sweep-61/) — 同じ日の点検の記録 - 「確認済み」の印が付いていたのに、リンク先を一度も読めていなかった (https://koshinstudio.com/notes/tco-relay/) — 誤った印を外した話 - 1 つの記事を商品ごとに分ける処理で起きた 3 つの取り違え (https://koshinstudio.com/notes/split-mixups/) — 分割の子の話