「自動化できるものは全部自動化して」：まず数えると、修復処理 66 個が一度も定期実行から呼ばれていなかった。全部は載せず、6 個だけ載せた

English version

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

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

iOS アプリ「トレカダッシュ」の開発で、ユーザーから、「自動化できるものは、全部自動化して」という指示がありました。

2026 年 8 月 28 日、まず、数えました。すると、直すための処理が 66 個、定期実行から一度も呼ばれていませんでした。この記事は、その数え方と、66 個を「全部は載せなかった」理由の記録です。

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

数えた：66 個が、「手で URL を叩かないと動かない」状態だった

HTTP のエンドポイント 319 個と、定期実行 184 個を、名前ではなく、関数の呼び出しで突き合わせました。名前が違っても、定期のジョブから呼ばれていることがあるからです。

結果、66 個が、手で URL を叩かないと動かない状態でした。人が「そろそろ回すか」と思い出すまで、直せるはずの記事が、直りません。

66 個を、一度に定期実行にはしなかった

66 個は、3 つに分かれました。

1. 継続的に必要なもの（新しいデータが来るたびに要る）→ 定期実行に載せる。
2. 一度きりの移行（backfill*、reclassify* など）→ 載せない。毎日走らせても無駄で、事故の余地が増えるだけ。
3. 破壊的なもの、人の判断が要るもの（孤立した商品の削除、手動の紐付け直し など）→ 載せない。

新しい定期ジョブは、配備した瞬間に、一度走ります。載せる前に、全部、書き込まない下見（ドライラン）で、当たりを確かめました。

載せた 6 個

時刻は、ばらしました。同時に走らせると、同時実行の枠を食い合って、待ち行列が伸びるからです。定期実行は、184 個から 190 個になりました。

残りの候補（締切の修復、壊れた商品画像の修復、楽天のアフィリエイトリンクの修復）は、実行に 2 分以上かかり、下見が時間内に終わらなかったので、見送りました。確認せずに、載せません。

商品カタログは、すでに、全自動だった

「商品カタログも、自動にできるよね」という問いへの答えは、「もう、なっている」でした。15 ジャンルすべてに、公式カタログの取り込みがあり、1 時間前に更新されていました。記事と商品の紐付けも自動で、実測 1,415 件中 1,406 件が、紐付け済みでした。残りは、「公式サイトに、まだ載っていない、新しい弾」で、公式が出せば、自動で入ります。

待ち行列が、伸び続けていた

もう 1 つ、数えている途中で、見つけたことがあります。待ち行列が、81、86、91 と、45 秒で増え続けていました。

原因は、ジョブを積む処理（enqueue）が、「実行中か」しか見ておらず、キューで順番待ちしている分を、見ていなかったことでした。同時実行の上限に達している間に、「1 分おき」のジョブの時刻が、何度も来ると、同じジョブが、何重にも積まれます。

順番待ちの名前も覚えて、二重に積まないようにしました。待ち行列は、0 のままになりました。

分かったこと

自動化は、全部を載せることではない。数えて、仕分けて、確かめて、載せる。

• まず、数える。66 個が、一度も呼ばれていませんでした。名前ではなく、呼び出しで突き合わせます。
• 仕分ける。継続的なものだけを載せます。一度きりの移行と、破壊的なものは、載せません。
• 載せる前に、下見で当たりを確かめる。新しい定期ジョブは、載せた瞬間に走ります。
• 時刻を、ばらす。同時に走らせると、待ち行列が伸びます。
• キューに積む前は、「待っているか」も見る。実行中だけを見ると、何重にも積まれます。

この話に出てくるもの

• トレカダッシュ — トレカの抽選・予約・先着の情報を集める iPhone アプリ
• 同時実行の枠を増やす前に見るもの — 待ち行列と枠の話
• 配備のたびに、日次の処理が丸ごと走り直していた — 定期処理の別の失敗
• 監査 61 本を総点検して見つけた 4 つ — 総点検の別の話

ほかの記録

• 「気づくだけでなく、そもそも起こさない」：報告だけの監視を、見つけてその場で埋める形に作り替えた — 取りこぼしの監視は報告するだけで、人が気づくまで埋まらなかった。見つけたその場で記事を作る形にし、黙って捨てる分岐にログを入れ、リンクが無い記事も応募方法を出した。カバー率は 92% から 100% に。
• 同じ報告が 3 回目：SwiftUI のボタンが「文字の上でしか」反応しなかった。過去 2 回の「修正」は効いていなかった — 「当選」「落選」ボタンが文字の上しか反応しない報告は 3 回目。過去 2 回は修飾子の順序を直しても効かず、ButtonStyle の中で見た目を組み立てて、6 か所を差し替えた。同じ日の「郵送なのに位置情報」も同じ根っこだった。
• 「ヤマダ電機」と「ヤマダデンキ」：表記ゆれと重複の原因は 3 つ重なっていた（包含だけの比較・59 秒の差・手動専用のジョブ） — 店名を「含んでいるか」だけで比べ、締切を 59 秒の差で別と判定し、重複整理が手動専用だった。言い換えの表は作らず一般則で直し、1 時間おきの定期実行にした。表記ゆれ 2 件、重複 7 組が 0 に。

コメント

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

コメントを開く

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