# 「1 ページ ＝ 1 案件」ではなかった：1 つのフォームで 6 商品を受け付ける店の記事が、リンクが同じというだけで消されていた > リンクだけで重複と決めるジョブが、1 つの Google フォームで 6 商品を受け付ける店の記事 5 件を消していた。「リンク ＋ 商品」に直した。サーバが作った「応募枠」をアプリが一度も読んでいなかったことも見つかった。 - URL: https://koshinstudio.com/notes/one-page-many-cases/ - 公開: 2026-10-17 - 書いた人: Koshin（https://koshinstudio.com/about/） - サイト: Koshin Studio English version (https://koshinstudio.com/en/notes/one-page-many-cases/) トレカダッシュ 開発の記録 ／ 2026年8月 iOS アプリ「トレカダッシュ (https://koshinstudio.com/works/torecadash/)」で、「複数の商品を受け付けている抽選なのに、1 件しか記事が無い」という報告が、2 回、来ました。1 回目に直したつもりでしたが、2 回目が来ました。 この記事は、その真因と、同じ時期に見つけた、「作った項目を、アプリが一度も読んでいなかった」話の記録です。 この記事は、2026 年 8 月 25 日の作業の記録から書いています。 ## 真因：リンクだけで、重複と決めていた 1 回目の報告で、「リンクが同じだから、重複扱いされている」ところまでは、直しました。しかし、すでにある記事が、隠れたままだったので、同じ指摘を、また受けました。 犯人は、runHideDuplicateLinkArticles、つまり、リンクだけで、重複と判断するジョブでした。 実データは、こうでした。ある通販店は、1 つの Google フォームで、6 つの商品の抽選を受け付けています。6 件の記事は、全部、同じ URL です。このジョブが、そのうち 5 件を「重複」として、消していました。利用者からは、1 商品ぶんしか、見えません。 直し方は、まとめる単位を、リンクから、リンク ＋ 商品に変えることでした。同じリンクでも、商品が違えば、別の案件です。商品が分かっていない記事どうしは、区別する手がかりが無いので、これまでどおり、リンクだけで、重複とみなします。 「1 ページ ＝ 1 案件」という前提は、トレカの抽選では成り立ちません。1 つの申込みフォーム、1 つの告知のページで、複数の商品を受け付ける店は、普通にあります。 すでに隠されていた記事は、同じリンクの表示中の記事と、商品または題名が違うものに限って、表示に戻しました（7 件）。ある通販店の 5 件（6 商品すべてが表示される）、大手のゲーム店 1 件、別のチェーン 1 件です。 ## サーバが作った「応募枠」を、アプリが一度も読んでいなかった 8 月 23 日から、サーバーは、応募の条件を AI で読んで、「応募枠」（entryTiers）を取り出していました。「プレイヤーズクラブ：本人認証済みの枠と、未認証の枠」「A グループと B グループ」「ビックカメラの Suica カード会員限定」といったものです。実データにも、ちゃんと入っていました。 ところが、iOS のアプリが、この項目を、一度も読んでいませんでした。AI の費用だけを払って、利用者には、見えない状態です。アプリに、項目を足し、詳細の画面に、「応募枠」として表示するようにしました。 サーバーとアプリの項目の突き合わせは、コマンドで見つかります。アプリが読む項目を、ソースから機械的に抜き出し（grep）、Firestore の実データと比べます。 ## 商品の一覧に、告知文が混ざっていた 「ONE PIECE カードゲームコーナー【事前入店申込・抽選】8 月 31 日（月）JUMP SHOP 東京駅店」のような、イベントの告知が、商品として登録されていました。 言い回しを並べる方式は、追いつきません。そこで、具体的な日付という、一般的な規則で弾きました。トレカの商品名に、「8 月 31 日」のような暦の日付は入りません。「Vol.3」「第 2 弾」「2025 年 19 号」は日付ではないので、影響しません。10 個のパターンで試して、食い違いは 0 件でした。すでにある 6 件を削除しました。 ## 分かったこと > 前提を疑う。作ったものが、使われているかを確かめる。 - 「1 ページ ＝ 1 案件」を、前提にしない。1 つのフォームで、複数の商品を受け付ける店は、普通にあります。 - 直したら、すでにある記事も見る。入口だけを直しても、隠れた記事は戻りません。 - サーバが作った項目を、アプリが読んでいるか、突き合わせる。費用だけかかって、利用者に見えない、ということが起きます。 - 言い回しの一覧より、一般的な規則。具体的な日付が入っていれば、商品名ではない、のように。 この話に出てくるもの - トレカダッシュ (https://koshinstudio.com/works/torecadash/) — トレカの抽選・予約・先着の情報を集める iPhone アプリ - 「同じ応募ページ」なら「同じ店」と決めつけていた (https://koshinstudio.com/notes/same-page-not-same-store/) — 同じ形の、別の前提の間違い - 1 つの記事を商品ごとに分ける処理で起きた 3 つの取り違え (https://koshinstudio.com/notes/split-mixups/) — リンクと商品の取り違え - 関門を直しても、すでにあるデータは直らない (https://koshinstudio.com/notes/fix-the-existing-data/) — 直しても残る記事の話