巡回と監視の取りこぼしを減らした7つの記録：ページ送り・X 監視・カバー率の測り方・先着の順番待ち

English version

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

トレカダッシュ 開発の記録 ／ 7 件のまとめ

抽選や先着販売は、見逃したら終わりです。トレカダッシュは、店のサイトやまとめサイト、X を巡回して監視しています。ここには、その取りこぼしを数えて、減らした 7 つの記録をまとめました。測り方そのものが間違っていた話も入っています。

それぞれの節は、もとは別々に公開していた記録です（2026 年 10 月から）。数字と出典は、その時の作業の記録のままです。テーマごとに読めるよう、1 つの記事にまとめ直しました（2026 年 11 月 7 日）。

まとめサイトの巡回は、一覧の 1 ページ目しか見ていなかった：トレカの記事は 2〜4 ページ目にあり、本文も先頭 6,000 文字で切れていた

2026 年 10 月 17 日の記録。

iOS アプリ「トレカダッシュ」の情報源の 1 つに、入荷情報のまとめサイトがあります。抽選の記事を、まとめて載せているサイトです。この巡回に、「出るべきものが、出ていない」原因が、2 つ、ありました。

この記事は、2026 年 8 月 28 日の作業の記録から書いています。

原因 1：一覧の、1 ページ目しか見ていなかった

まとめサイトの、抽選の記事の一覧を読む処理（fetchNyukaNowChusenArticles）は、一覧の1 ページ目だけを読んでいました。1 ページ目の 11 件は、ゲーム機、たまごっち、ぬいぐるみなどが中心でした。トレーディングカードの記事は、後ろのページにありました。

既存の記事の多くは、あるポケモンカードのまとめ記事の由来なのに、その記事自体を、今は、読みに行っていませんでした。直し方は、12 ページまで、たどることでした。

原因 2：本文の、先頭 6,000 文字しか、AI に渡していなかった

ポケモンカードのまとめは、1 ページに、15 店以上が並びます。AI には、本文の先頭の 6,000 文字だけを渡していたので、後半の店が、まるごと落ちていました。読み取れる件数が、実行のたびに、48、39、40 件と、揺れていたのも、このためでした。

直し方は、5,000 文字ずつ、600 文字の重なりをつけて、全部を読むことでした。取り込みの本体も、同じ関数を使います。

同じ日に見つけた、年のない日付

まとめの表は、「8 月 30 日（日）」としか書きません。今日の日付を、AI に渡していなかったので、ポケモンカードの案件が、軒並み2020 年 8 月 30 日として返っていました。過去の締切は、入口の関門が弾くので、この経路のポケモンカードの案件は、まるごと取り込まれていませんでした。プロンプトに、今日の日付と、「今日より前の年を補ってはいけない」を入れたところ、受付中の案件は、0 件から 46 件読めるようになりました。（これは、別の記事にも書いた話です。）

分かったこと

取り込みの 3 つの「切れ目」：ページ、文字数、年。

• 一覧は、最後のページまで読む。1 ページ目に、欲しいものがあるとは限りません。
• AI に渡す文字数の上限で、後半が落ちていないか見る。読み取れる件数の揺れは、サインです。
• 全文を、重なりつきで、順に渡す。先頭だけを渡すと、後ろが落ちます。
• 年のない日付は、今日の日付を渡す。6 年前を補われます。
• 「既存の記事の由来を、今は読んでいない」は、取りこぼしの印。

X 監視の漏れ 4 つ：検索に出ない投稿、持ち主が変わるアカウント、店を探せない検索、止まった後の取り戻し

2026 年 10 月 17 日の記録。

iOS アプリ「トレカダッシュ」の情報源のうち、いちばん速く、いちばん漏れやすいのが、お店の X（旧 Twitter）の投稿です。お店は、抽選や先着の告知を、まず X に出します。アプリは、登録したお店のアカウントを、定期的に巡回して読んでいます。

2026 年 9 月 19 日の 1 日で、この監視の「漏れ」が 4 つ、続けて見つかりました。この記事は、その記録です。

数字は、2026 年 9 月 19〜20 日の作業の記録から書いています。個人のアカウントは、名前を出さずに書きます。

1. 検索に出てこない投稿がある

監視は、X の検索で投稿を探していました。ところが、4 つの店の抽選の告知が、言葉で絞らずに 751 件を取っても、出てきませんでした。1 店ずつでも出ませんでした。X の検索は、店の投稿の一部を、返さないことがあります。

タイムライン（その店の投稿の一覧）を直接読む方法（profileTweets）なら、取れました。

厄介なのは、記事が一度も作れない店は、「実績なし」のままになることです。巡回の優先度や、対策の対象は、実績を基準にしています。実績がないと、対象にもならない。見えない店は、見えないままになります（鶏と卵です）。

直し方は、検索に加えて、店のタイムラインも読むことでした。ただし、タイムラインは言葉で絞れず、読んだ件数の全部が課金されます。そこで、実績のある店は毎日、実績のない店は週に 1 回、1 店あたりの件数に上限（10 件と 8 件）を付けました。

費用は、店ごとの投稿数で大きく変わるので、見積もりは必ず実測で出します。月の使用額が $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 程度です。月ごとに付け替える仕組みは、入れ直しません。

分かったこと

見えない投稿は、見えないから、数えられない。

• 検索だけに頼らない。検索は、すべては返さない。見えないものは、苦情も出ません。
• 登録は、一度きりの確認にしない。持ち主は変わる。登録名と、今の表示名を、定期的に突き合わせます。
• 検索の言葉を変えたら、下見する。当たりが増えると、誤りも増えます。
• 止まったあとは、取り戻しの設計が別に要る。普段の順番制は、止まったあとには合いません。
• 費用の上限は、月ごとに付け替えない。戻し忘れ、戻し先の誤りで、全部が止まります。

競合サイトと突き合わせて、取りこぼしを数えた：最初の「カバー率 23%」は測り方の間違いで、本当は 49% だった

2026 年 10 月 17 日の記録。

iOS アプリ「トレカダッシュ」の目標の 1 つは、抽選販売の情報をもれなく出すことです。もれがあるかどうかを確かめるには、同じ情報を出している他のサイトと突き合わせて、「あちらにあって、こちらに無いもの」を数えるのが一番です。

2026 年 8 月 29 日の未明に、これをしました。最初に出た数字は「カバー率 23%」。ところが、それは測り方の間違いでした。この記事は、数字が 23% から 49%、そして 90% になるまでに見つけた、5 つの問題の記録です。

数字は、2026 年 8 月 29 日の作業の記録から書いています。他のサイトの名前は、出しません。

まず、全部の競合を調べた

「競合が出しているのに、このアプリが出していない記事を、無くしてほしい」という依頼でした。最初に、競合になりうるサイトを全部調べました。取り込めるかどうかは、robots.txt（機械による取得のお願い）と、利用規約を全部読んで決めました。

1 つのサイトは、robots.txt の冒頭に、日本語で禁止が書かれていました。機械的に取れるからといって、取って良いわけではありません。

突き合わせの相手は、こちらより細かかった

今回追加した相手（以下、A サイト）は、「店 × 商品 × 締切 × 応募リンク」を、1 つのページに 90 件並べていました。こちらの取り込み元は記事の単位でしたが、A サイトは案件の単位で、しかも応募のリンクが、外部の応募フォームそのもの（Google フォーム、LivePocket、抽選ロトボックス、店の公式 X）でした。数えるにも、埋めるにも、条件の良い相手でした。

問題 1：商品名の書き方が違うだけで、「取りこぼし」と数えていた

最初の数字はカバー率 23% でした。理由の 1 つ目は、商品名の書き方です。

相手   30th CELEBRATION BOX
こちら 拡張パック「30th CELEBRATION」

どちらも、もう一方を含んでいないので、素朴な「含んでいるか」では、永久に一致しません。60 件が、これで「取りこぼし」と数えられていました。

ここで、「含んでいれば同じ」にしては、いけません。「30th CELEBRATION」という名前は、「30th CELEBRATION プレミアムデッキセット」にも含まれます。別の商品を出しているのに「出せている」と数える方向の間違いです。穴が見えなくなる方向に間違えます。

直し方は、弾の呼び方（拡張パック、ハイクラスパック）と、数量の言い方（BOX、n 個セット、n 種）を落としたうえで、商品カタログの ID に結び付けることでした。決める順番は、「完全一致」、「相手の名前に含まれるカタログ名のうち、最も長いもの」、「逆向きで、1 件だけのとき」です。

問題 2：期限切れの記事を、「カバー済み」と数えていた

理由の 2 つ目は、5 件でした。ある店の、7 月 29 日が締切の記事を、相手の 8 月 30 日が締切の案件と対にして、「記事はあるのに非表示」と報告していました。前の回の別の抽選です。この 2 つの直しで、正しい数字は49% でした。

問題 3：穴埋めで作った記事が、別の商品になっていた

見つかった穴は、記事を作って埋めます。ところが、その記事を作るときに、相手の商品名を、そのまま AI に渡していました。AI は、「30th CELEBRATION BOX」を、定価 27,500 円の「30th CELEBRATION FUTURISTIC BOX」に結び付けました。10 件が、別の商品の記事になりました。

数える側は、すでにカタログの商品を 1 つに絞れていました。作る側にも、こちらのカタログの名前を渡すのが正しい直し方でした。「数える判断」と「作る判断」を、1 本にします。

この修復のときに、私自身がもう 1 つ間違えました。商品の ID を、先頭 10 文字に切り詰めた値で書いてしまい、存在しない ID の記事を 10 件作りました。点検の出力を、見やすいように slice(0, 10) で切っていて、その短い値を、そのまま処理に使ったのです。すぐ直しましたが、表示のために短くした ID を、処理に使わない、が決まりごとになりました。

問題 4：応募リンクが、t.co 以外だと、必ず捨てられていた

まとめ由来の記事に、応募のリンクを付ける処理は、店ごとの URL を、リンクを展開する関数に通していました。この関数は、t.co（X の短縮 URL）しか見ません。X の投稿のリンクは、必ず短縮されるからです。X 以外の取り込み元は、応募の URL を、短縮されていない普通の形で持っています。それを通すと、必ず 0 件になり、ウェブ検索に落ちていました。

A サイトから作った 32 件のうち、17 件が、応募先ではなく、取り込み元のサイトのページを指していました。取り込み元のサイトへ利用者を飛ばすのは、禁止にしていた状態です。

直し方は、短縮されていない普通の URL は、そのまま候補にする（採用するかの検査は、従来の検査を通す）ことでした。すでにできていた記事は、作り直せないので、突き合わせのたびに応募リンクを張り替える処理を入れ、16 件を張り替えました。

問題 5：「締切が無い」で隠した記事に、戻す道がなかった

締切が分からない、まとめ由来の記事を隠す処理がありました。この処理は隠すだけで、締切があとから分かっても、永久に隠れたままでした。直っても鳴り続ける警告と、同じ形の失敗です。相手が締切を書いている案件は、締切を入れて、表示に戻すようにしました（別の理由でも隠れている記事は、戻しません）。2 件を戻しました。

このとき、締切の時刻の扱いも直しました。読み取った日付を、「日本時間ずらし」の値のまま返していて、そのまま保存すると、9 時間ずれた締切になるところでした。日本時間の 23:59 は、協定世界時の 14:59 です。本当の時刻を返すようにしました。

結果

この作業で、記事を 32 件作り、応募リンクを 16 件張り替え、締切を入れて戻したものが 2 件ありました。

残った 9 件は、全部、理由が分かっています。

• ある店のプレミアムデッキセットは、応募ページに「対象は拡張パック 1 BOX」とだけ書いてあるので、意図して除外しています。この場合は、相手が間違っている側です。
• 「スターターセット ex 3 種」の 7 件は、相手もどの 3 種か書いていません。推測で 3 件作ると、別の商品の記事を並べることになるので、作りません。
• 残りは、最近見ていないために隠れている記事 1 件です。これにも「戻す道」が要るかもしれない、と課題に残しました。

分かったこと

数える道具の間違いは、数字を悪く見せるのではなく、穴を見えなくする。

• カバー率は、測り方を疑う。最初の 23% は、実際は 49% で、直して 90% でした。
• 「含んでいれば同じ」にしない。別の商品を、「出せている」と数えます。
• 相手の記事は、正しいとは限らない。相手が間違っている場合が、残りの中に 1 件ありました。
• 「数える判断」と「作る判断」は、1 本にする。別々だと、数えた商品と、作った商品が違います。
• 表示用に短くした値を、処理に使わない。
• 隠す処理には、戻す道を、一緒に作る。
• 取り込む前に、規約を読む。取れることと、取って良いことは、別です。

「1 分おき」の監視は、1 件あたり 10 分に 1 回だった：速くする前に、見直しの間隔と、通知が届いた数を数えた

2026 年 10 月 17 日の記録。

iOS アプリ「トレカダッシュ」の中でも、先着販売（在庫が数分で消える販売）の通知は、速さが勝負です。そこで、先着の監視は、「1 分おきに動く」ように作りました。

2026 年 9 月 7 日に、その反応速度を実際に測ってみると、設計の意図と実態が約 10 倍ずれていました。この記事は、そこから、さらに「速くした結果、別のものが遅くなった」ことまで見つかった記録です。

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

「1 分おき」は、1 件あたり 10 分に 1 回だった

「1 分おきに動く」と書いてあると、速いつもりになります。しかし、利用者が体感するのは、1 件あたり、何分に 1 回見に行くかです。63 件を、1 回に 4〜9 件しか見られないなら、1 周するのに約 10 分かかります。計算式は、対象の件数 ÷ 1 回に見られる件数 × 間隔です。この式を一度も出していなかったので、「動いているのに、勝てない」状態が続いていました。

原因：共有の外部 API の枠を、対等に奪い合っていた

在庫を見に行くときに使う、楽天の API は、1.5 秒に 1 回しか呼べません。この枠を、5 つのジョブが対等に奪い合っていました。いちばん急ぐ監視の取り分は、13%しかありませんでした。

直し方は、急ぐ処理が走っている間だけ、まとめて見る系の処理が、枠を取りに行かないようにすることでした。ここで、見つけた落とし穴があります。

• 譲る印を、1 回の呼び出しごとに立てて、下ろすと、呼び出しの合間に、奪い返されます。実測では、「1 回 4 件」の回が、20 回中 13 回、残りました。
• 印を、巡回のあいだ立てっぱなしにすると、1 回に見られる件数が、30〜33 件になりました。
• 譲る側には、必ず待ちの上限を置きます。置かないと、譲りっぱなしで飢えます。

速くしたら、いちばん速く見たいものが、遅くなった

同じ日に、先着の反応を上げようとして、いくつかのジョブの間隔を詰めました。Amazon の確認を 5 分おきにしたところ、今度は、楽天ブックスの瞬殺監視が遅くなりました。

原因は、Amazon の確認が 1 回 5〜8 分かかるのに、間隔を 5 分にしたことです。1 回の所要時間が、間隔以上になると、そのジョブは、同時に走れる枠（8 つ）の 1 つを、ずっと占有します。その分だけ、ほかのジョブが順番を待ちます。間隔を戻すと、元に戻りました。

もう 1 つ：「審査しない」ものには、通知が飛ばない

先着の通知は、出品が「定価より高い転売」ではないかを、価格で審査してから送ります。この審査は、単位が食い違って比べられないとき、「審査しない」として通り過ぎる作りでした。コメントには「推測しない、安全側」と書いてありました。

ところが、「審査しなかった出品」には、「価格が確認できていない」という印が付き、通知が止まります。直近 7 日間の先着 148 件を数えると、こうでした。

画面に出た 55 件のうち、45% に、通知が飛んでいませんでした。記事はフィードに出るので、監査にも映りません。苦情も出ません。検知を 10 分から 80 秒に速くしても、その先で、半分が静かに落ちていたのです。

しかも、「比べられない」は思い込みでした。カタログの定価 5,280 円を、1 箱のパック数 12 で割ると 440 円で、ちゃんとしたパック 1 つの値段です。つまり、その金額は、すでに 1 箱ぶんの値段で、掛けずに、そのまま比べればよかったのです。

分かったこと

「速くして」の答えは、たいてい「速くする」ではなく、「途中で落ちているものを見つける」。

• 間隔ではなく、1 件あたりの見直しの間隔を測る。対象の件数 ÷ 1 回の処理件数 × 間隔。
• 届いた数を数える。作った記事の数ではなく、通知まで届いた数です。
• 「判断できないとき」に、どちらへ倒れるかを書き出す。倒れた先が、利用者に届かない側なら、それは安全側ではありません。
• 速くするほど、ほかが遅くなることがある。同時に走れる枠は、有限です。
• 「比べられない」と書いてあるところは、実データで見直す。単位をそろえたら、比べられました。

全部を速く見られないとき、何を速くするか：427 弾のうち人気の 128 弾を速く回し、予算を超えたら自分から譲る

2026 年 10 月 17 日の記録。

iOS アプリ「トレカダッシュ」は、通販サイトを、弾（商品の発売の単位）ごとに検索して、先着や予約の情報を集めています。弾の数は全部で 427。これを全部、速く見たいところですが、取得にかかる費用にも、外部サービスの呼び出しの回数にも、上限があります。

2026 年 9 月 7 日の夜に、「人気のものだけを、速く見る」という方針を決めて、実装しました。この記事は、何を速くして、何をあきらめて、費用をどう守ったかの記録です。

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

方針：人気 3 ジャンルの、最新と直近 2 年だけ

決めた方針は、「ポケモンカード、ONE PIECE カード、ドラゴンボールの、最新の弾と、直近 2 年の弾を見れば足りる」でした。人気のジャンル 3 つ × 直近 24 か月で、128 弾です。全 427 弾の約 3 割です。

もともとの個別弾の検索は、全 427 弾を順に回る設計で、一巡にかかる時間が、サイトごとに違いました。

人気枠は、通常の枠とは別の続きの位置（カーソル）で回します。同じ位置を共有すると、人気枠の進みが、通常の枠を乱します。

2 つのサイト（あみあみとイオンスタイル）には、人気枠という考え方が当てはまりません。弾ごとに検索せず、一覧のページを丸ごと見る方式で、1 回で全部を見ているからです。絞る対象がありません。速くするには、間隔を詰めるしかなく、それは費用の話になります。

まとめて回したら、別の監視が止まった

入れた直後に、楽天で回帰（直したつもりが別の不具合を出すこと）を出して、その場で直しました。最初は、楽天も「1 時間おきに 128 弾をまとめて」見ていました。ところが、楽天の API は、1.5 秒に 1 回を、全部の処理で分け合ううえ、先着の瞬殺監視だけで、毎分 30 件、枠の 75% を常に使っています。まとめて回すと、1 回に 13 分以上かかり、その間、瞬殺監視まで、「前回がまだ実行中」と見送られました。

同じ「1 時間に 128 弾」でも、10 分おきに 22 弾ずつ、ばらして撒くと、山ができません。楽天ブックスの人気枠は毎時 3 分・13 分…、楽天市場の人気枠は毎時 8 分・18 分…と、時刻もずらしました。直後の実測では、瞬殺監視は、9 分で 8 回、見送り 0 回、平均 44.9 秒で、悪化はありませんでした。

最速枠：人気商品を、本当に 1 分おきに

さらに、「人気の商品は、1 分おきに状態を確認したい」という要望がありました。ここで、前に書いた「1 分おきに走る」と「1 件を 1 分ごとに見る」は別物、という話を、3 回目に確かめることになりました。

• 楽天ブックスの瞬殺監視：未通知の対象が 62〜92 件あり、1 回で見られるのは約 30 件、一巡 3 分でした。人気 3 ジャンルは、その中に18 件（ポケモン 9、ドラゴンボール 5、ワンピース 4）しかありません。毎回、先にこの 18 件を見れば、本当に 1 分おきになります。費用は、ゼロです。残りの 44 件は、約 3.7 分周期です。続きの位置は、持ち回りの分だけで進めます。人気を含めて進めると、位置がそこで止まり、ほかの商品に、永久に順番が回らなくなります。
• Amazon の最速枠：発売前、または発売から 60 日以内の、人気 3 ジャンルの28 弾を、1 分おきに 10 弾ずつ持ち回って、約 2.8 分で 1 周します。実測は、1 回 27.4 秒、見送り 0 回です。

「28 弾を毎分すべて」はできません。取得サービスは 1 日 40,320 件になり、月で 196 万件。契約の 125 万件を超えます。1 分に 10 弾なら、1 日 14,400 件です。その分、Amazon の人気枠（128 弾）は、30 分おきから 60 分おきに下げました。

できないことは、できないと書く

• 楽天市場：楽天 API の 1.5 秒の枠を、瞬殺監視が 75% 使っています。ここに 1 分おきを足すと、瞬殺監視が壊れます。人気枠（20 分おき）が上限です。
• Yahoo!：1 分おきだと 1 日 4 万回で、枠が桁違いに足りません。しかも、最近、新規の保存が 0 件でした。2 時間おきのままです。

最速枠は、予算のペースを超えたら、自分から譲る

Amazon は、先着競争の生命線なので、取得サービスの 1 日の枠の間引きを、無条件で素通りする優先ホストにしています。素通り自体は正しいのですが、1 分おきの最速枠まで素通りさせると、Amazon が枠を食い尽くして、ほかのサイトが全部間引かれます。

件数を、安全側に決め打ちするより、実際の消費を見て、自動で止まるほうが確かです。時刻に按分した予算のペースを超えていたら、その回を見送る判定（isScrapeDoOverPace()）を足しました。

実測は、2 分の窓で、55 リクエスト、55 クレジット、つまり 1 分に 27.5 クレジット（1 日約 39,600）。枠は、残量 1,147,389、リセットまで 23 日で、1 日 47,392 です。ここで、測る窓の長さに、1 つ落とし穴がありました。10 分の窓で測ると、1 分に 47.5 クレジット（1 日 68,400）に見えました。たまたま、3 時間おきの高額な処理（1 回 25 クレジット）が、その窓に入っただけでした。短い窓から外挿すると、間違えます。翌日の日次の実績で見る、と決めました。

分かったこと

全部を速くできないときは、何を速くするかを決め、速くしたぶん、何を遅くするかも決める。

• 対象を絞る。427 のうち、128。それでも、本当に 1 分おきにできるのは、さらに絞った 18 件や 28 弾です。
• まとめて回さず、ばらして撒く。同じ件数でも、山ができなければ、ほかを止めません。
• 共有の枠を使うなら、速くするほど、誰かが遅くなる。先に、守るものを決めます。
• 予算は、自分から譲る仕組みにする。件数の決め打ちより、実際の消費で止まるほうが確かです。
• 短い窓で測って、外挿しない。日次の実績で確かめます。

先着が始まった瞬間、サイトが順番待ちのページになる：8,000 バイトの関門を、15KB の案内ページがすり抜けた

2026 年 10 月 17 日の記録。

iOS アプリ「トレカダッシュ」は、通販サイトの販売ページを定期的に読んで、先着や抽選の情報を集めています。前に書いたとおり、「取れた」の判定に穴があり、案内ページを成功と読んでいた事件がありました。その判定を直したのと同じ日（2026 年 9 月 7 日）のうちに、同じ種類の穴が、別の形でもう 1 つ見つかりました。

しかも、それは、いちばん取りこぼしてはいけない瞬間に起きていました。

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

先着が始まった瞬間に、サイトが順番待ちのページになる

報告が来ました。「イオンスタイルオンラインにも、先着があるみたいだよ」「14 時ちょうどに、販売が始まったみたい」。そこで、その時刻に、実際に取得を試しました。

先着が始まった瞬間、サイト全体が、順番待ちのページになります。どの設定で取っても、返ってくるのは、同じ案内ページです。

8,000 バイトの関門を、15KB の案内ページがすり抜けた

この日の先に入れた「取れていない」の判定は、8,000 バイト未満の短いページの中の、JavaScript を求める案内を見るものでした。大きなページには、まっとうなページにも、同じ一文が常に入っているからです。

ところが、この順番待ちのページは約 15KB あります。関門をすり抜けて、「取得は成功。商品は 0 件」と読まれていました。いちばん取りこぼしてはいけない瞬間に、静かに取りこぼす状態です。

直し方は、ページの大きさではなく、題名（title）を見ることでした。題名に「アクセス集中」や「順番にご案内」が出ているときは、失敗として扱います。本文の一部に、その言葉が出ているだけの、まっとうなページを巻き込まないよう、見る場所を題名に限りました。

あわせて、頻度を 3 時間おきから 15 分おきにしました。1 回約 21 クレジットと高めですが、1 日に約 6,000 クレジットで、残量の 92% に収まります。

同じ日に見つけた、もう 2 つの「遅さ」

先着の速さを測っていて、別の原因も見つかりました。

Amazon の 13 分は、「取得」ではなく、「AI の審査」だった。Amazon の監視は 30 分おきで、1 回のスキャンに 13 分かかり、最悪で約 43 分の遅れがありました。計器で見ると、時間の使い道は、新しい出品の AI による審査（1 日 421 回、約 10 円）でした。取得そのものは、1 日 1,047 クレジットで安い。原因は、15 のジャンルを、1 つずつ直列に処理していたことでした。ジャンルどうしは独立なので、4 本を並列にして、間隔を 10 分、1 回を 8 分にしました。AI の審査は、新しい出品だけに走るので、巡回の回数が増えても、費用は増えません。

速く見つけても、17% は通知していなかった。見つけることが速くなっても、その先の通知が止まっていれば、意味がありません。通知が届いた数を数えたら、まだ穴がありました（通知の数を数えた話は、別の記事に書いています）。

分かったこと

判定の穴は、いちばん大事な瞬間に、いちばん広がる。

• 案内ページの形は、1 つではない。短い案内も、大きな順番待ちのページもあります。大きさでは、見分けられません。
• 見る場所を変えると、巻き込みが減る。本文ではなく題名にしたので、まっとうなページを巻き込みません。
• 報告を受けたら、その時刻に、その場で測る。「14 時に始まった」は、再現できる最後のチャンスでした。
• 遅い理由は、実際の時間の使い道で確かめる。Amazon の 13 分は、取得ではなく、直列の AI 審査でした。

「気づくだけでなく、そもそも起こさない」：報告だけの監視を、見つけてその場で埋める形に作り替えた

2026 年 10 月 17 日の記録。

iOS アプリ「トレカダッシュ」の目標は、抽選の情報を、もれなく出すことです。ユーザーからの指示は、「気づくだけじゃなくて、そもそも取りこぼしが起きないようにして」でした。

この記事は、2026 年 8 月 27 日に、監視を、「見つけて報告する」から、「見つけて、その場で埋める」に作り替えた記録です。

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

報告だけの監視は、人が気づくまで埋まらない

それまでの、取りこぼしの監視（reportCoverageGap）は、報告するだけでした。人が気づいて、手で流すまで、穴は埋まりません。見つけたその場で、記事を作る（埋める）ようにして、1 日 3 回（取り込みの後）に走らせました。

• 記事を作る経路は、すでにあるものを使います。重複は、既存の判定（hasExistingCoverageForStore）が防ぎます。
• 取り込み側が、正しく動いていれば、ここは 0 件で終わります。ここで記事が作られるのは、取り込み側に、まだ穴があるという意味です。件数は、「残っている穴の大きさ」として読みます。

黙って捨てる分岐に、ログを入れた

ある関数（touchLastSeenIfExists）の早期の return が、何も言わずに次へ行く、唯一の分岐でした。ほかの分岐は、全部ログを出すのに、ここだけが無言でした。そのせいで、「24 店が、同じ記事 ID になる」という、別の穴が、長く見つかりませんでした。無言で捨てる分岐は、見つからない穴の、住処です。

リンクが無い記事でも、「どう応募するか」は出す

応募リンクが分からない 32 件のうち、17 件は、相手の表にも、URL が無いものでした（店のアプリや、店頭の QR など）。ただ、相手は、「応募方法」や「応募条件」を、文章で書いています。それを取り込んで、応募方法を判定する処理に渡しました。「応募先が分かりません」と出すより、「アプリで応募」や「店頭の QR コードから応募」と出すほうが、役に立ちます。

修復の対象から、漏れていた記事

「応募リンクが分からない」という印が付いた記事でも、アプリ限定の店でも、行き先がまとめでもない場合は、修復の対象に、一度も入りませんでした。34 件のうち、対象は 15 件だけでした。印そのものを、対象の条件にしました。

最終の数字

ただし、100% は、1 つのサイトに対しての数字です。X のまとめの取りこぼしの調査では、3 店舗が出ましたが、保存された本文が 500 文字で切られていたので、これは下限です。X の監視が再開したあとで、測り直すことにしました。

分かったこと

気づく仕組みは、埋める仕組みまで、つなげる。

• 報告だけの監視は、人が気づくまで埋まらない。見つけたその場で、埋めます。
• 埋める件数は、「残っている穴の大きさ」。0 になるのが、本来の姿です。
• 黙って捨てる分岐に、ログを入れる。1 か所の無言が、穴を長く隠します。
• 応募リンクが無くても、応募方法は出せる。「分からない」より、「アプリで応募」。
• 修復の対象は、印そのもので決める。条件の組み合わせでは、漏れます。
• 100% は、測った範囲での数字。下限と書きます。

それぞれの要点

• まとめサイトの巡回は、一覧の 1 ページ目しか見ていなかった：入荷情報のまとめサイトの巡回は、一覧の 1 ページ目（ゲーム機中心）しか読まず、ポケカやガンダムは後ろのページにあった。本文も先頭 6,000 文字しか AI に渡さず、後半の店が落ちていた。12 ページまで辿り、重なりつきで全文を読む形に直した。
• X 監視の漏れ 4 つ：店の X 投稿を巡回する監視で、4 店の告知が検索に 751 件取っても出なかった、登録した店が個人になっていた、店の発掘が 63 店中 11 店だった、6 日止まった後 2 時間で 2,866 件中 185 件しか読めなかった。直し方と、費用の見積もり。
• 競合サイトと突き合わせて、取りこぼしを数えた：他のサイトが出している抽選を、こちらが出せているかを数えた。最初の 23% は、商品名の書き方の違いと期限切れの記事で歪んでいた。直して 49%、穴埋めの 5 つの問題を直して 90% に。規約で自動取得が禁止のサイトは取り込まなかった。
• 「1 分おき」の監視は、1 件あたり 10 分に 1 回だった：先着の監視は 63 件を 1 回に 4〜9 件しか見られず、1 件あたり約 10 分に 1 回。7 日間で捕まえたのは 3 回。間隔を詰めると別の監視が遅くなり、「審査しない」ことで先着の 45% に通知が飛んでいなかった。
• 全部を速く見られないとき、何を速くするか：先着や予約の監視で、全 427 弾の一巡は 4〜24 時間。人気 3 ジャンルの直近 2 年 128 弾を別枠で速く回し、人気商品は 1 分おきに見た。まとめて回すと別の監視が止まる、短い窓で測ると費用を見誤る、などの記録。
• 先着が始まった瞬間、サイトが順番待ちのページになる：イオンスタイルオンラインで先着が始まると、全体が「アクセス集中」の 15KB のページになった。同じ日の先に入れた 8,000 バイト未満の関門をすり抜け、「成功・商品 0 件」と読まれていた。題名で見る関門に直し、Amazon の 13 分が直列の AI 審査だったことも分かった。
• 「気づくだけでなく、そもそも起こさない」：取りこぼしの監視は報告するだけで、人が気づくまで埋まらなかった。見つけたその場で記事を作る形にし、黙って捨てる分岐にログを入れ、リンクが無い記事も応募方法を出した。カバー率は 92% から 100% に。

ほかの記録は、Notes の一覧から、テーマごとに読めます。トレカダッシュそのものは、作品ページに書いています。

ほかの記録

• 定期実行とサーバー運用で起きた9つのこと：タイムアウト・時間予算・配備のたびの再実行・VPS 移行 — 毎日・毎時動く処理と、それを載せるサーバーで起きた9つの記録。Cloud Functions から VPS への移行、3回直したタイムアウト、走っていなかった点検、配備のたびの再実行、ログの秘密。
• Xcode 15.2 で Firebase 12 が使えない（Swift 6.0 必須）：Firebase 11.4.0 と AdMob 11.5.0 に固定した理由 — 古い Mac の Xcode 15.2 では、Firebase 12 以降と 11.12.0 以降は Xcode 16.2 が必須、AdMob 11.6.0 以降は MarketplaceKit で Xcode 15.3 が必須。Exact Version で固定した記録。
• ITMS-91064「無効なバイナリ」：NSPrivacyTracking が true なのに NSPrivacyTrackingDomains が空だった — ビルドが Apple の自動審査で ITMS-91064 により却下された。NSPrivacyTracking が true で、NSPrivacyTrackingDomains が空の配列だったのが原因。ドメインを補った経緯と、確認できていないこと。

コメント

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

コメントを開く

押すと、giscus（giscus.app）と GitHub に接続します。押さなければ、接続しません。詳しくはプライバシーポリシーに書いています。