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

English version

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

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

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 弾です。
• まとめて回さず、ばらして撒く。同じ件数でも、山ができなければ、ほかを止めません。
• 共有の枠を使うなら、速くするほど、誰かが遅くなる。先に、守るものを決めます。
• 予算は、自分から譲る仕組みにする。件数の決め打ちより、実際の消費で止まるほうが確かです。
• 短い窓で測って、外挿しない。日次の実績で確かめます。

この話に出てくるもの

• トレカダッシュ — トレカの抽選・予約・先着の情報を集める iPhone アプリ
• 「1 分おき」の監視は、1 件あたり 10 分に 1 回だった — 見直しの間隔の話
• 同時実行の枠を増やす前に見るもの — 枠の話
• 「しょうがない」を測り直したら、取得の費用は 8 分の 1 だった — 取得の費用の話

ほかの記録

• 表示中の記事のリンク先を、実際に開いて確かめた：約 60 件の間違いと、最初の点検が間違えた 3 つのこと — 表示中の記事のリンク先 1,000 件超を開いて、記事と突き合わせた。Amazon の招待リクエストが先着になっていた、休店中・売り切れが表示中、リンク先が別の店・別の商品、応募リンクがサイトのトップへ転送。最初の点検自体も 3 つ間違えていた。
• 商品のジャンルを、公式カタログで直した：下見を 3 回やって、13 件から 4 件に絞った — デュエル・マスターズの商品がポケモンカードとして登録されていた。公式カタログをジャンルの正解にしたところ、1 回目の下見では、正しいヴァイスの商品が 9 件も別のゲームに変わるところだった。3 回の下見で誤爆 0 件に。
• 監査 61 本を総点検して見つけた 4 つ：朝 4 時に 51 本が固まり、鍵の期限は 55 秒で、定価の補完は「入れない」と決めた — 1 日 1 回の処理が 4 時に 27 本・5 時に 24 本集まって枠を塞いでいた。楽天の巡回は 1 回 181〜480 秒で、鍵の期限は 55 秒しかなかった。数えても直せない異常を数えるのをやめ、定価を 1 店で埋める案は、測ったうえで入れなかった。

コメント

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

コメントを開く

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