公式の一覧から、「作品名だけの商品」が 393 件できていた：商品名の欄に、商品の形は入っていなかった

書いた人：Koshin（Web エンジニア・アプリエンジニア）　公開：2026-10-17

トレカダッシュ開発の記録／ 2026年9月

iOS アプリ「トレカダッシュ」の商品リストは、一部を、公式サイトの一覧から取り込んで作っています。ある日、この取り込みで作られた商品を日ごとに数えたら、この日だけで 502 件。ふだんは 1 日に 1〜10 件です。

中身を見ると、ヴァイスシュヴァルツが 379 件で、名前が、こうなっていました。

GA文庫
魔界戦記ディスガイア４
勝利の女神：NIKKE
ラブライブ！虹ヶ咲学園スクールアイドル同好会

どれも、作品の名前で、商品の名前ではありません。この記事は、その原因と、掃除のあとに起きた副作用の記録です。

数字は、2026 年 9 月 7 日の作業の記録から書いています。

原因：商品の「形」は、名前の外にあった

公式の一覧のページでは、商品名の欄（products__name）に、作品名だけが書かれています。商品の形（ブースターパック、トライアルデッキ）は、名前ではなく、カテゴリ（ページの URL の一部）で分かれていました。

カテゴリ	商品名の欄の実データ
booster-pack	「アズールレーン Vol.3」「ステラソラ」「anemoi」
trial-deck	「ガールズ＆パンツァー大洗女子学園」「GA文庫」

正しい商品名は、「トライアルデッキ GA文庫」のように、形が付いたものです。すでにある正しい商品（「ブースターパック D4DJ Groovy Mix」「トライアルデッキステラソラ」）と、形がそろいます。

直し方：入口と、すでにできた分

入口：カテゴリから、形を足すようにしました（trial-deck はトライアルデッキ、booster-pack はブースターパック、など）。形が決まらない「その他」は、足さず、作りません。

すでにできた分：掃除の道具を作りました。既定では下見だけで、delete=true を付けたときだけ実行します。消すのは、次の 4 つが全部当てはまるものだけです。

公式の一覧から作った商品である。
形を表す語が、名前に無い。
記事が 1 件も付いていない。
定価も画像も無い。

下見で 393 件。実行して、商品は 811 件から 418 件になりました。ただし、「【推しの子】Vol.3」は、記事が付いているので、残しました。消しすぎは、苦情が出ないので、条件を厳しくしておきます。

掃除のあと、公式の一覧を取り込み直して、ヴァイスシュヴァルツに 328 件を、正しい名前（「トライアルデッキご注文はうさぎですか？？」のように、形が付いたもの）で登録し直しました。形の語が無いものは、0 件です。

なぜ、監査で見つからなかったか

商品の名前を調べる監査は、「商品名として不自然」なものを探します。記号、改行、URL が混ざっているもの、などです。まっとうな日本語の作品名は、不自然に見えません。「ラブライブ！虹ヶ咲学園スクールアイドル同好会」は、立派な名前です。

もう 1 つの穴は、数える監査がなかったことです。「1 日に何件、商品が作られたか」を数えていれば、502 件は一目で異常でした。出ているものだけを見ていると、静かに増えるものは、見えません。

副作用：別表記のぶつかりが、0 組から 250 組になった

正しい名前の商品が、328 件増えたことで、新しい問題が出ました。商品には、別の呼び方（別表記）を登録しています。既存の商品の別表記「ブースターパック　ご注文はうさぎですか？？」が、新しくできた正式名の商品と、ぶつかりました。2 つ以上の商品が名乗る別表記を数える監査が、0 組から 250 組になりました。

監査が案内している修復の道具を、下見のあとに実行しました。判定は、「正式名を名乗っているほうを残す」で、外れるのは別の商品側だけです。253 件（商品 220 件）の曖昧な別表記を外し、監査は 0 組に戻りました。

分かったこと

カタログを増やす直しは、入れ直したあとに、もう一度、監査を流す。

取り込み元の「欄」の意味を、実データで確かめる。「商品名」の欄に、商品名が入っているとは限りません。
1 日に作られた数を、数える。502 件は、数えれば、すぐ分かりました。
消すときは、条件を全部そろえる。記事が付いているものは、残します。
名前が増えると、ぶつかりが増える。入口を直して終わりにすると、次の人が、0 のはずの監査に 250 を見ます。

この話に出てくるもの

トレカダッシュ — トレカの抽選・予約・先着の情報を集める iPhone アプリ
「9種セット」を中身ごとに分けて、偽の商品が80個できていた — 偽の商品ができた、別の経路
1 つの記事を商品ごとに分ける処理で起きた 3 つの取り違え — 名前が 2 つの商品のものになる話
「重複は実質ゼロ」と数えたのに、監査は 112 組を出していた — 監査の数字を疑った話

ほかの記録

「同じ応募ページ」なら「同じ店」と決めつけていた：店名が別の店になった記事 52 件 — 同じ応募ページの記事の店名を書き揃える処理が、仙台駅前店を「新宿南口店」にしていた。応募ページは 15 の別々の店が共有していた。「確かめられたときだけ揃える」に直し、52 件を、触っていない項目から復元した記録。
先着が始まった瞬間、サイトが順番待ちのページになる：8,000 バイトの関門を、15KB の案内ページがすり抜けた — イオンスタイルオンラインで先着が始まると、全体が「アクセス集中」の 15KB のページになった。同じ日の先に入れた 8,000 バイト未満の関門をすり抜け、「成功・商品 0 件」と読まれていた。題名で見る関門に直し、Amazon の 13 分が直列の AI 審査だったことも分かった。
同時実行の枠を増やす前に見るもの：2 コアのサーバーで、枠を 8 から 14 にした判断と、半分間違っていた前の結論 — 先着の監視を速くしようと間隔を詰めると、1 分おきの瞬殺監視が枠の順番待ちで遅くなった。枠を 8、11、14 と変えて測った。上限の正体は CPU ではなく、楽天 API の 1.5 秒待ちで枠を握る処理だった。

感想や、記事の間違いの指摘は、ここへ。書くには、GitHub のアカウントが要ります。

押すと、giscus（giscus.app）と GitHub に接続します。押さなければ、接続しません。詳しくはあつかいに書いています。