Koshin Studio関門を直しても、すでにあるデータは直らない：「もう試した」印・URL の目印・対応表の 3 つの実例
トレカダッシュ 開発の記録 ／ 2026年8月〜9月
iOS アプリ「トレカダッシュ」の開発では、「直したのに、直っていない」という報告が、何度も、同じ形で来ました。コードを直す。テストも通る。ところが、画面には、まだ間違いが残っている。
理由は、コードを直しても、すでに保存されているデータは、書き換わらないことです。この記事では、その 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 回来たら、出口を疑う。入口の直しだけでは、足りていません。
この話に出てくるもの
- トレカダッシュ — トレカの抽選・予約・先着の情報を集める iPhone アプリ
- 監査 61 本を総点検して見つけた 4 つ — 同じ日の点検の記録
- 「確認済み」の印が付いていたのに、リンク先を一度も読めていなかった — 誤った印を外した話
- 1 つの記事を商品ごとに分ける処理で起きた 3 つの取り違え — 分割の子の話
ほかの記録
- 全部を速く見られないとき、何を速くするか：427 弾のうち人気の 128 弾を速く回し、予算を超えたら自分から譲る — 先着や予約の監視で、全 427 弾の一巡は 4〜24 時間。人気 3 ジャンルの直近 2 年 128 弾を別枠で速く回し、人気商品は 1 分おきに見た。まとめて回すと別の監視が止まる、短い窓で測ると費用を見誤る、などの記録。
- 表示中の記事のリンク先を、実際に開いて確かめた：約 60 件の間違いと、最初の点検が間違えた 3 つのこと — 表示中の記事のリンク先 1,000 件超を開いて、記事と突き合わせた。Amazon の招待リクエストが先着になっていた、休店中・売り切れが表示中、リンク先が別の店・別の商品、応募リンクがサイトのトップへ転送。最初の点検自体も 3 つ間違えていた。
- 商品のジャンルを、公式カタログで直した：下見を 3 回やって、13 件から 4 件に絞った — デュエル・マスターズの商品がポケモンカードとして登録されていた。公式カタログをジャンルの正解にしたところ、1 回目の下見では、正しいヴァイスの商品が 9 件も別のゲームに変わるところだった。3 回の下見で誤爆 0 件に。
コメント
感想や、記事の間違いの指摘は、ここへ。書くには、GitHub のアカウントが要ります。
押すと、giscus（giscus.app）と GitHub に接続します。押さなければ、接続しません。詳しくはあつかいに書いています。