トレカダッシュ

English version

抽選、予約、先着。
追いかけるのが大変な販売情報を、まとめて通知する。

Other languages: English

iPhone のアプリです。App Store で配信中です（無料。Pro は有料）。

App Store で開く

どんなアプリか

トレーディングカードの「抽選」「予約」「先着販売」の情報は、販売店ごとの告知や、X の投稿に散らばっています。気づいたときには、締切が過ぎている。トレカダッシュは、全国の販売店やオンラインストアの告知を集めて、応募・購入できるページへすぐ移動できる形で、お届けするアプリです。

主な機能

フィード

受付中の抽選・予約・先着販売を、ジャンルや販売形式で絞り込んで確認できます。

通知

フォローした商品やジャンルに、新しい情報が出たら、すぐにお知らせします。

締切カレンダー

抽選の締切や、結果の発表日を、日付ごとに一覧できます。応募漏れを防ぐための画面です。

応募管理

応募した抽選の結果や、購入を記録できます。

マップ

店頭の入荷や抽選の情報を、利用者どうしで共有できます。

今日の運試し

毎日、無料で挑戦できるおみくじです。購入や課金は要りません。

対応しているジャンル

ポケモンカードゲーム、遊戯王、ONE PIECE カードゲーム、ユニオンアリーナ、ロルカナ、デュエル・マスターズ、ドラゴンボール、ガンダム、マジック：ザ・ギャザリング、ヴァイスシュヴァルツ、名探偵コナン、ホロライブ、デジモン、ハイキュー!! バボカ!!、パルワールドの 15 ジャンルです。

トレカダッシュ Pro（有料）

基本の機能は、無料で使えます。Pro では、次のことができるようになります。

• 商品フォロー、キーワードアラート、除外キーワードが、無制限になる。
• 先着・ゲリラ販売の通知が、いちばん早く届く（無料版は、約 15 分遅れ）。
• 現在地から近い店舗に、絞り込める。
• 通知履歴の全期間の閲覧、応募の統計、カレンダーの書き出し、CSV の出力。
• 購入の記録から、資産評価額と損益を、グラフで管理する。
• 広告を表示しない。

作りについて

画面は SwiftUI で作っています。情報を集める側は、Firebase（Cloud Functions と Firestore）と、自前のサーバーで動いています。販売ページを定期的に取得して、記事が「どの商品の話か」を照合して（AI を一部に使っています）、出品価格が妥当かを審査する。この流れを、毎日、回しています。

作る途中で測ったことや、間違えたことは、Notes に書いています。下の「この作品の記録」から、読めます。

よくある質問

どこで手に入りますか？

App Store で配信している iPhone 向けのアプリです。このページの「App Store で開く」から入れます。

ログインは必要ですか？

フィード、通知、カレンダーなどの主な機能は、サインインなしで使えます。Apple でサインインが要るのは、マップへの投稿と「今日の運試し」だけです。

公式のアプリですか？

いいえ。各カードゲームの権利者や販売店とは関係のない、個人が開発した非公式のアプリです。掲載している情報は、各販売店の公開情報をもとにしています。応募・購入の前に、必ず各販売店の公式ページで最新の内容を確認してください。

無料で使えますか？

基本機能は無料です。商品フォローの数や通知の速さなどを広げる、有料の Pro もあります。

ご注意

• 掲載している情報は、各販売店の公開情報をもとにしています。応募・購入の前に、必ず、各販売店の公式ページで最新の内容を確認してください。
• 各カードゲームの権利者や、販売店とは関係のない、個人が開発した非公式のアプリです。

アプリのサポート・利用規約・プライバシーポリシー：サポート ／ 利用規約 ／ プライバシーポリシー（アプリ専用のページです）

この作品の記録

• トレカ抽選アプリを比較：トレカダッシュ・トレゲト・NowPokeca・Pokeka Tracker・トレカの地図のメリットとデメリット — トレカの抽選・予約・再販を追うアプリ・サイトを、ジャンル数・通知・地図・料金で比較。作者（トレカダッシュの開発者）による比較で、トレカダッシュの弱いところも書いた。
• まとめサイトの巡回は、一覧の 1 ページ目しか見ていなかった：トレカの記事は 2〜4 ページ目にあり、本文も先頭 6,000 文字で切れていた — 入荷情報のまとめサイトの巡回は、一覧の 1 ページ目（ゲーム機中心）しか読まず、ポケカやガンダムは後ろのページにあった。本文も先頭 6,000 文字しか AI に渡さず、後半の店が落ちていた。12 ページまで辿り、重なりつきで全文を読む形に直した。
• 「サーバーが落ちた。こちらからは復旧できない」は、誤りだった：止まっていたのは、SSH の受信だけだった — 午前 3 時 10 分からサーバーに接続できなくなり、私は「止まった」と判断した。実際は、プロセスは 7 日以上動き続け、定期実行 192 本も正常で、遮断されていたのは SSH の受信だけだった。
• 「変な記事がめっちゃ増えてる」：作られた経路ごとに数えて入口を塞いだ。数え方も 2 回、間違えた — 表示中の抽選 252 件を経路ごとに数えた。まとめの表に残る終わった回を毎日取り込んで締切が空になっていた（33 件）ほか、応募リンクが検索結果やトップ、締切が自分の店の行と食い違うものを、入口で塞いだ。
• 「自動化できるものは全部自動化して」：まず数えると、修復処理 66 個が一度も定期実行から呼ばれていなかった。全部は載せず、6 個だけ載せた — HTTP の 319 個と定期実行の 184 個を呼び出しで突き合わせると、66 個が手で叩かないと動かなかった。継続的なものだけを、下見のあとで 6 個載せた。キューに積む処理が順番待ちを見ておらず、待ち行列が伸び続けていたことも直した。
• 「気づくだけでなく、そもそも起こさない」：報告だけの監視を、見つけてその場で埋める形に作り替えた — 取りこぼしの監視は報告するだけで、人が気づくまで埋まらなかった。見つけたその場で記事を作る形にし、黙って捨てる分岐にログを入れ、リンクが無い記事も応募方法を出した。カバー率は 92% から 100% に。
• 同じ報告が 3 回目：SwiftUI のボタンが「文字の上でしか」反応しなかった。過去 2 回の「修正」は効いていなかった — 「当選」「落選」ボタンが文字の上しか反応しない報告は 3 回目。過去 2 回は修飾子の順序を直しても効かず、ButtonStyle の中で見た目を組み立てて、6 か所を差し替えた。同じ日の「郵送なのに位置情報」も同じ根っこだった。
• 「ヤマダ電機」と「ヤマダデンキ」：表記ゆれと重複の原因は 3 つ重なっていた（包含だけの比較・59 秒の差・手動専用のジョブ） — 店名を「含んでいるか」だけで比べ、締切を 59 秒の差で別と判定し、重複整理が手動専用だった。言い換えの表は作らず一般則で直し、1 時間おきの定期実行にした。表記ゆれ 2 件、重複 7 組が 0 に。
• あいまいな店名で地図を引くと、日本の真ん中の静岡が返る：チェーン名を並べず、Google 自身の答えで判定した — 店名を Google の地図検索に渡すと、あいまいな名前では日本全体の矩形の真ん中（静岡・愛知）が返った。ヤマダデンキが浜松、サンエーが掛川の工場に。チェーン名の一覧は作らず、答え自身で信用できるかを 4 つの規則で判定した。
• 「1 ページ ＝ 1 案件」ではなかった：1 つのフォームで 6 商品を受け付ける店の記事が、リンクが同じというだけで消されていた — リンクだけで重複と決めるジョブが、1 つの Google フォームで 6 商品を受け付ける店の記事 5 件を消していた。「リンク ＋ 商品」に直した。サーバが作った「応募枠」をアプリが一度も読んでいなかったことも見つかった。
• 英語表記とカタカナ表記は、1 文字も重ならない：正しい照合 42 件を、指紋の関門が却下していた — 相場の紐付け率が 39% に低下。相場のサイトに商品はあったが、自社の英語表記とカタカナ表記では指紋が一致せず、26 時間で 42 件が却下されていた。関門は弱めず、この照合だけに狭い 2 つ目の判定を足した。
• タイムアウトを 3 回直しても止まらなかった：真犯人は、同じ鍵の中で動いていた 2 つ目の処理だった — 楽天ブックスの在庫チェックが 1 日 17 回タイムアウトした。取得の上限、1 件ぶんの上限と 2 回直しても止まらず、3 回目で、同じ鍵の中の別の処理（全件を取り直し、上限なし）が真犯人と分かった。
• ログに秘密のトークンが平文で残っていた：呼び忘れようがない唯一の出口で伏せる — 通信の部品のエラーメッセージに URL がそのまま入り、取得サービスのトークンがログに出ていた。前に作った伏字の関数は、明示的に呼ぶ場所にしか効かず、呼び元は 50 か所以上。ログの唯一の出口で伏せる形に直した。
• 失敗を捨てると、画面は嘘をつく：「○件登録しました」と出て 1 件も入っていなかったカレンダー、固まる文字認識、店名を積み忘れた通知 — try? で失敗を捨てていたため、カレンダーに 0 件なのに「登録しました」と出て二度と登録できなくなった。文字認識の失敗で画面が固まった。通知バッファに店名を積み忘れて「店名なし」になった。
• 候補は見つかっていたのに、答えを読む所で毎回落ちていた：200 トークンで切れた URL と、ハイフンで 400 になる検索 — 公式の告知ページを選ぶ AI の返事が 200 トークンで途中で切れて毎回失敗していた。直しても 0 件だったのは、店の告知が個別の商品名を書かないため、AI が指示に忠実に拒否していたから。楽天の検索は、ハイフンの位置で 400 になった。
• 「iCloud が新しければ取り込む」の関数が、何も比べていなかった：応募の記録が 20 件から 1 件になりうる — iCloud 同期の関数は、名前に反して新しいかを見ず、変更があると丸ごと置き換えていた。新しい端末の空の状態で保存すると、別の端末の 20 件が 1 件に上書きされうる。更新時刻を比べ、空では上書きしないようにした。
• 「後から掃除するから大丈夫」が、入口の不具合を隠していた：商品が毎日 400 件そっくり作り直されていた — カタログからの商品登録が名前の完全一致でしか探さず、括弧・空白・全角の違いで毎日そっくりな商品を作り直し、この日だけで 437 件（410 件は記事なし）。統合の掃除が後から片付けていたため気づけなかった。
• Cloud Functions から月 4,300 円のサーバーへ移した：1 日 3,700 円の課金、EEA で全滅した Yahoo!、移行で踏んだ 5 つの罠 — 無料のお試しが終わると 1 日約 3,700 円（月約 10.6 万円）かかった。待ち時間にも課金される構造が原因で、コードをほぼ書き換えずにシンガポールの VPS（月約 4,300 円）へ移した。ヘルシンキでは Yahoo! が全滅、秘密の値は 5 本でなく 15 本だった。
• 広告が出ないと、実機チェックの 25 項目が止まった：開発者モードだけテスト広告を使い、賞品名を直書きしない — 配信前は広告の在庫が無く、実機チェックリスト 163 項目のうち 25 項目が確認できなかった。開発者モードのときだけ、Google のテスト用の広告枠に切り替えた。賞品名は 1 つの設定から読み、チェックリストにも直書きしない。
• 「これベイブレードじゃん」が、関門を入れても戻ってきた：弾いた値が、別の形で漏れた — 「商品名に玩具の名前があれば作らない」関門を入れても、AI が返す商品名から玩具の名前が消えて、すり抜けた。判定を告知の本文に移し、「カードゲームの語が 1 つも無いときだけ」弾く条件にした。
• 「次回へ」と出続けていた 25 本の点検は、一度も走っていなかった：3 つの時間予算を、同じ開始時刻から数えていた — 点検の処理は 3 段構えで、予算が同じ開始時刻から数えられていたため、持ち回りの 25 本は毎回 0 本だった。ログの「18 件を次回へ」は全部の意味だった。制限時間から割り付ける形に直し、各ステップの所要時間をログに出した。
• 関門を直しても、すでにあるデータは直らない：「もう試した」印・URL の目印・対応表の 3 つの実例 — 判定を直したのに既存の 32 件のうち 12 件が直らなかった（印が 7 日残る）、URL に載せた目印が張り替えで失われて 111 件が再分割された、対応表から外しても書かれた値が残った。同じ形の報告が 5 件だった監査の記録。
• 全部を速く見られないとき、何を速くするか：427 弾のうち人気の 128 弾を速く回し、予算を超えたら自分から譲る — 先着や予約の監視で、全 427 弾の一巡は 4〜24 時間。人気 3 ジャンルの直近 2 年 128 弾を別枠で速く回し、人気商品は 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 店で埋める案は、測ったうえで入れなかった。
• 公式の一覧から、「作品名だけの商品」が 393 件できていた：商品名の欄に、商品の形は入っていなかった — 公式サイトの一覧を取り込むと、この日だけで商品が 502 件できた（ふだんは 1〜10 件）。商品名の欄は作品名だけで、形はカテゴリ側にあった。393 件を掃除し、328 件を正しい名前で入れ直すと、別表記のぶつかりが 0 組から 250 組になった。
• 「同じ応募ページ」なら「同じ店」と決めつけていた：店名が別の店になった記事 52 件 — 同じ応募ページの記事の店名を書き揃える処理が、仙台駅前店を「新宿南口店」にしていた。応募ページは 15 の別々の店が共有していた。「確かめられたときだけ揃える」に直し、52 件を、触っていない項目から復元した記録。
• 先着が始まった瞬間、サイトが順番待ちのページになる：8,000 バイトの関門を、15KB の案内ページがすり抜けた — イオンスタイルオンラインで先着が始まると、全体が「アクセス集中」の 15KB のページになった。同じ日の先に入れた 8,000 バイト未満の関門をすり抜け、「成功・商品 0 件」と読まれていた。題名で見る関門に直し、Amazon の 13 分が直列の AI 審査だったことも分かった。
• 同時実行の枠を増やす前に見るもの：2 コアのサーバーで、枠を 8 から 14 にした判断と、半分間違っていた前の結論 — 先着の監視を速くしようと間隔を詰めると、1 分おきの瞬殺監視が枠の順番待ちで遅くなった。枠を 8、11、14 と変えて測った。上限の正体は CPU ではなく、楽天 API の 1.5 秒待ちで枠を握る処理だった。
• 競合サイトと突き合わせて、取りこぼしを数えた：最初の「カバー率 23%」は測り方の間違いで、本当は 49% だった — 他のサイトが出している抽選を、こちらが出せているかを数えた。最初の 23% は、商品名の書き方の違いと期限切れの記事で歪んでいた。直して 49%、穴埋めの 5 つの問題を直して 90% に。規約で自動取得が禁止のサイトは取り込まなかった。
• 自分で作った仕組みが、自分を傷つけた 4 つの記録：要約が条件を捨て、1 つの未定義が保存を止め、点検が本番の IP を閉め出された — 「15 文字程度」の指示で応募の条件が 671 件の点検で抜けていた、undefined が 1 つで保存が全部失敗し 1 日の消費の 41% を溶かした、点検の 6 並列で本番と同じ IP が拒否された、直っても鳴り続ける警告を作った。
• X 監視の漏れ 4 つ：検索に出ない投稿、持ち主が変わるアカウント、店を探せない検索、止まった後の取り戻し — 店の X 投稿を巡回する監視で、4 店の告知が検索に 751 件取っても出なかった、登録した店が個人になっていた、店の発掘が 63 店中 11 店だった、6 日止まった後 2 時間で 2,866 件中 185 件しか読めなかった。直し方と、費用の見積もり。
• 「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 件を伏せかけた。捨てる判定の失敗の記録。
• 配備のたびに、日次の処理が丸ごと走り直していた：48 時間で 477 回、その日の Gemini 費用の 46.6% — 1 日 1 回のはずの処理が 43 回走り、Gemini の費用の 46.6% を占めていた。タイムアウトした回は最終実行時刻が書かれず、再起動のたびに取りこぼし扱いされていた。逆に、配備が 8 時に重なって、ダイジェストが 1 通も届かなかった問題も。
• 通知は取り消せない：直近 72 時間の通知の 19% が誤通知で、関門が通知の「後」に効いていた — 直近 72 時間に通知した 644 件のうち 122 件（19%）が誤通知だった。記事の関門は後から記事を下げるが、通知は保存の約 0.6 秒後に飛ぶ。下げた 30 件のうち 25 件はもう通知済みだった。通知を送る側の入口に同じ関門を通した記録。
• Gemini の費用を削る前に、計器を疑った：単価・内訳・キャッシュの 3 つが壊れていて、キャッシュの条件は測り直すと変わっていた — Gemini の費用の計測は 3 か所とも壊れていた（単価は 1/2.6 の過小表示、31 の用途が 1 つに潰れ、キャッシュ未計上）。キャッシュが効く条件は 9 月は約 8,000、10 月は約 4,000 トークンと食い違った。指示文を水増しすると判定が 9% ずれた。
• Firestore の費用を円で出したら、読み取りの 91% が 1 か所だった：キャッシュを入れても効かなかった理由 — Firestore を初めて円で見たら、月 1.3 万円で Gemini とほぼ同額だった。読み取りの 91% は商品一覧の読み直し。60 秒キャッシュが効かなかったのは、32 件が同時に動いていたから。「読み込み中の約束」を覚えて直した記録。
• 「確認済み」の印が付いていたのに、リンク先を一度も読めていなかった：t.co の中継ページ — X の告知の応募リンクを、ブラウザの名乗りを付けて開くと、t.co は転送せず中継ページを返した。表示中の 220 件が全部読めておらず、9 件は閉じたフォームだった。直し方と、誤った「確認済み」の印の外し方の記録。
• Claude API から Gemini API（gemini-3.1-flash-lite）へ移行した：16 か所の呼び出しを 1 つの関数にまとめた — Anthropic の利用上限で予定外の課金が出たため Gemini へ移行。モデルの選び方（廃止予定日）、呼び出しの一本化、Web 検索の回数上限が無い問題への回路遮断器、止めるスイッチの記録。
• 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 が空の配列だったのが原因。ドメインを補った経緯と、確認できていないこと。
• 一括処理が「全記事」に当たった：書く前に数える、テストは壊して確かめる — 記事の状態をまとめて直す処理が、全記事に当たり、18件が誤って表示に戻った。履歴から戻した経緯と、テストが効くかを、規則を1つずつ外して確かめた記録。
• 「9種セット」を中身ごとに分けて、偽の商品が80個できていた — ポケモンカードの9種セットは1つの商品なのに、中身ごとに分けて、実在しない商品が80個できていた。入口を止め、親22件を戻し、子190件を外し、偽の商品を消した記録。
• Firebase Auth：アプリを完全に終了すると、匿名アカウントが量産された（currentUser の復元待ち） — 「アプリを落とすと、また Apple のサインインを求められる」。管理画面を開くと、19人中17人が使い捨ての匿名アカウント。起動直後に currentUser を同期チェックしていた競争を、addStateDidChangeListener で直した記録。
• 「重複は実質ゼロ」と数えたのに、監査は112組を出していた — 重複を統合する処理が、毎晩、先頭のジャンルの途中で時間切れになっていた。「ゼロ」と数えた自分の測り方が間違っていた。持ち回りに直して112組を0組にした記録。
• 「取れた」と読んでいたのは、ただの案内ページだった：3日間、商品が0件 — ポケモンセンターの取得が3日間ずっと商品0件だった。安い設定が返した2,410バイトの「JavaScriptを有効に」ページを、成功と読んでいた。判定を1か所に集めた記録。
• 確認できなかったときに、通していた：「fail-open」が転売品を招いた話 — 「定価を確認できなかったら通す」という設計に、検索の1日上限という盲点があった。「知らなかった」と「調べられなかった」を区別して直した記録。
• 一度だけ生まれた誤字が、店ごとに増えていった：「30th SEREBRATION」の件 — 誤字の商品が一度作られると、既存の商品として再利用され、店ごとに増える。13記事を直し、短い見出しを完全一致で拾う予防を入れ、保険のチェックの限界まで確かめた記録。
• 「しょうがない」を測り直したら、取得の費用は8分の1だった — 「イオンとあみあみは費用が重くて縮められない」は、古い単価に基づく思い込みだった。3つの取得設定で同じページを比べて、描画が丸ごと無駄だと分かった記録。
• App Store 審査で「Guideline 2.1 Information Needed」が届いた：求められた6つ — 初めての審査で届いたのは、不合格ではなく Guideline 2.1「Information Needed」だった。求められた六つ（実機の画面収録、目的、外部サービスの一覧など）と、前に直したこととのつながり。
• App Store の審査で止まった四つ：iPad のスクショ、ITMS-91064、アカウント削除、投稿の通報 — iPad スクリーンショットの要求、自動検査の ITMS-91064（NSPrivacyTrackingDomains が空）、アカウント削除（5.1.1(v)）、投稿の通報（1.2）。審査に出す手前で止まった四つと、その直し方。
• 「9種セット」の正体は御三家9商品だった：同じ商品なのに、決して一致しなかった — 他のまとめサイトと突き合わせたら、抽選の表示は54%だった。商品の取り違え、比べ方の左右非対称、記事IDの穴。カバー率を91%にした記録。
• iOS アプリが固まって強制終了される（0x8BADF00D）：SwiftUI の計算プロパティが毎回走っていた — 実機のログにあった 0x8BADF00D（watchdog）。951件の記事を、画面を描き直すたびにメインスレッドで数え直していた。原因の特定と、バックグラウンドで計算する形に直した記録。
• TestFlight にビルドが来ない：Xcode Cloud の月25時間を使い切っていた（最初の診断は誤りだった） — 「[ci skip] が原因」という最初の診断は、時系列が合わず誤りだった。Xcode Cloud の無料枠（月25時間）を使い切った本当の原因と、開始条件を絞る直し方の記録。
• 「減るはず」が、二度外れた：AIへの問い合わせを削る話 — トレカ情報アプリで、AI への問い合わせを減らそうとした記録。45%減るはずが4.5%、配備したのに束ねが0回。数え直して見つかったことを、コミットの数字で書いた。