Koshin StudioX 監視の漏れ 4 つ：検索に出ない投稿、持ち主が変わるアカウント、店を探せない検索、止まった後の取り戻し
トレカダッシュ 開発の記録 ／ 2026年9月
iOS アプリ「トレカダッシュ」の情報源のうち、いちばん速く、いちばん漏れやすいのが、お店の X（旧 Twitter）の投稿です。お店は、抽選や先着の告知を、まず X に出します。アプリは、登録したお店のアカウントを、定期的に巡回して読んでいます。
2026 年 9 月 19 日の 1 日で、この監視の「漏れ」が 4 つ、続けて見つかりました。この記事は、その記録です。
数字は、2026 年 9 月 19〜20 日の作業の記録から書いています。個人のアカウントは、名前を出さずに書きます。
1. 検索に出てこない投稿がある
監視は、X の検索で投稿を探していました。ところが、4 つの店の抽選の告知が、言葉で絞らずに 751 件を取っても、出てきませんでした。1 店ずつでも出ませんでした。X の検索は、店の投稿の一部を、返さないことがあります。
タイムライン（その店の投稿の一覧）を直接読む方法（profileTweets）なら、取れました。
厄介なのは、記事が一度も作れない店は、「実績なし」のままになることです。巡回の優先度や、対策の対象は、実績を基準にしています。実績がないと、対象にもならない。見えない店は、見えないままになります（鶏と卵です）。
直し方は、検索に加えて、店のタイムラインも読むことでした。ただし、タイムラインは言葉で絞れず、読んだ件数の全部が課金されます。そこで、実績のある店は毎日、実績のない店は週に 1 回、1 店あたりの件数に上限（10 件と 8 件）を付けました。
| 見積もり | 値 |
|---|---|
| 実績のある店の投稿数 | 1 日 13.5 件 |
| 無作為に選んだ店の投稿数 | 1 日 4.5 件 |
| 追加後の月の見込み費用 | 約 $51（プランに含まれる枠は $39） |
費用は、店ごとの投稿数で大きく変わるので、見積もりは必ず実測で出します。月の使用額が $62 を超えたら自動で止まるようにし、残りの予算で全店を毎日読めるかを自動で見積もって、足りなければ読む店を絞る仕組みも入れました。
2. 登録した店が、いつのまにか店ではなくなっていた
監視の一覧に「店」として登録していた 2 つのアカウントが、今は店ではありませんでした。1 つは、8 月に中古店の支店として登録したアカウントで、今は個人の雑談になっていました。もう 1 つは、5 月に登録したアカウントで、情報発信の個人の「【PR】抽選販売」の投稿が、店の抽選として記事になっていました。
記事は、「店の一次情報」として出ます。誤った情報が、そのまま通知されます。
監視の一覧は、登録した時点の確認しかしていませんでした。その後、アカウントの持ち主や使い方が変わっても、気づく仕組みがなかったのです。
確かめ方は、一覧のコメントに書いた店名と、直近 30 日の記事の表示名を、2 文字の重なりで突き合わせることでした。828 件のうち、食い違いを目で 1 件ずつ見て、個人化していたのは 2 件でした。「不明」で登録したものが、そのまま正式名になっているだけ、という食い違いが大半だったので、機械では決めず、目で見ました。
3. 店を探す検索が、63 店中 11 店しか見つけていなかった
新しい店の X アカウントは、検索で探します。当時の検索は、「店名 ジャンル名 抽選 site:x.com」で、上位 5 件までを見ていました。63 店を試して、X を見つけられたのは11 店だけでした。上位には、まとめアカウントや、客の抽選の投稿が来て、店名の照合で弾かれていたのです。
X のアカウントが分かっている 8 店で比べると、旧しくみは 5 店、「店名 site:x.com」に変えると 7 店（全部 1 位）でした。
ところが、言葉を広げた直後の下見で、個人や無関係のアカウントを拾いました。検索結果の題名には、投稿の本文が入っていて、本文に書かれた店名で一致していたからです。題名から表示名の部分だけを取り出して照合するように直しました。検索の当たりを増やすと、同時に誤りも増えます。言葉を変えたら、動かす前に必ず下見をして、拾ったものを 1 件ずつ見ます。
4. 止まった後の取り戻しに、半日かかる
データ取得サービス（Apify）の予算が切れて、X の監視が 6 日間止まっていました。再開したところ、2 時間で読めたのは、2,866 件のうち 185 件でした。
巡回は、「実績のある店は 3 時間、ない店は 12 時間で一周」の順番制です。順番制は、全員がだいたい同じだけ遅れている普段の状態に合わせた作りでした。止まった後は、遅れが一様ではありません。取り戻しに半日以上かかり、翌日が締切の抽選は、読む前に終わる状態でした。
同じ理由で、検索で新しく見つけたアカウントも、「実績なし」の列の途中に入り、最長 12 時間、読まれませんでした。
直し方は、順番制の巡回に、「長く読めていないものを、古い順に上乗せして読む」枠を付けることでした。失敗し続けるものが枠を占領しないよう、試した印は別に持ちます。再開した直後は、手で取り戻しも走らせました。
おまけ：予算の「今月だけ」が、全停止を 2 回起こした
この取り戻しの原因だった、予算切れの話です。以前は、「今月だけ上限 $44」「9 月 6 日に $29 へ自動で戻す」のように、月ごとに上限を付け替えていました。戻した先の値が、その月の使用額より小さいと、サイクルの開始と同時に、X の監視が全部止まります。これを 2 回（8 月 28 日と 9 月 13 日）起こしました。
9 月 19 日に決めたのは、月の上限は $70 の 1 本だけ。間隔は月によって変えない（6 時間で全アカウントを一巡）でした。実測の月の費用は、$10〜18 程度です。月ごとに付け替える仕組みは、入れ直しません。
分かったこと
見えない投稿は、見えないから、数えられない。
- 検索だけに頼らない。検索は、すべては返さない。見えないものは、苦情も出ません。
- 登録は、一度きりの確認にしない。持ち主は変わる。登録名と、今の表示名を、定期的に突き合わせます。
- 検索の言葉を変えたら、下見する。当たりが増えると、誤りも増えます。
- 止まったあとは、取り戻しの設計が別に要る。普段の順番制は、止まったあとには合いません。
- 費用の上限は、月ごとに付け替えない。戻し忘れ、戻し先の誤りで、全部が止まります。
この話に出てくるもの
- トレカダッシュ — トレカの抽選・予約・先着の情報を集める iPhone アプリ
- 「1 分おき」の監視は、1 件あたり 10 分に 1 回だった — 別の監視の、見直しの間隔の話
- 本物の抽選を、静かに捨てていた 4 つの実例 — 画面に出ない失敗の実例
ほかの記録
- 「1 分おき」の監視は、1 件あたり 10 分に 1 回だった：速くする前に、見直しの間隔と、通知が届いた数を数えた — 先着の監視は 63 件を 1 回に 4〜9 件しか見られず、1 件あたり約 10 分に 1 回。7 日間で捕まえたのは 3 回。間隔を詰めると別の監視が遅くなり、「審査しない」ことで先着の 45% に通知が飛んでいなかった。
- 1 つの記事を商品ごとに分ける処理で起きた 3 つの取り違え：子が親になり、共有リンクが別の店を指し、名前が 2 つの商品のものだった — 分けた「子」の記事に親向けの処理をもう一度かけて、締切当日の抽選 60 件（23 店）が消えた。13 店が共有するリンクで別の店の親を引いた。2 つの商品が名乗る名前が 267 組あった。画面に何も出ないまま、本物が消える失敗の記録。
- 本物の抽選を、静かに捨てていた 4 つの実例：正規表現・年のない日付・まとめて聞く・null — 「x.com」が「e-starbox.com」に一致して応募リンクが一度も採用されなかった、年のない日付が 6 年前と読まれてポケカ案件が 0 件だった、まとめ判定の数がずれた、「決められない」が「無い」と読まれ 129 件を伏せかけた。捨てる判定の失敗の記録。
コメント
感想や、記事の間違いの指摘は、ここへ。書くには、GitHub のアカウントが要ります。
押すと、giscus（giscus.app）と GitHub に接続します。押さなければ、接続しません。詳しくはあつかいに書いています。