Koshin StudioNotes
作りながら考えたことの記録。
勘で直す前に、まず測る——という話が多いです。
実際の作業の記録（コミットと、手元で測った数字）から書いています。作品ごとに、まとめました。
テーマ別に読む
本数が多いので、はじめての方は、次のテーマから選ぶと読みやすいです。
数えて、直した
勘で直す前に、まず数える。費用と監査の数字を疑って、測り直した記録。
- Firestore の費用を円で出したら、読み取りの 91% が 1 か所だった：キャッシュを入れても効かなかった理由
- Gemini の費用を削る前に、計器を疑った：単価・内訳・キャッシュの 3 つが壊れていて、キャッシュの条件は測り直すと変わっていた
- 「しょうがない」を測り直したら、取得の費用は8分の1だった
- 「重複は実質ゼロ」と数えたのに、監査は112組を出していた
- 監査 61 本を総点検して見つけた 4 つ：朝 4 時に 51 本が固まり、鍵の期限は 55 秒で、定価の補完は「入れない」と決めた
- 関門を直しても、すでにあるデータは直らない：「もう試した」印・URL の目印・対応表の 3 つの実例
- 「次回へ」と出続けていた 25 本の点検は、一度も走っていなかった：3 つの時間予算を、同じ開始時刻から数えていた
- 「減るはず」が、二度外れた：AIへの問い合わせを削る話
静かに壊れていた
エラーが出ないまま、本物が消えていた、または読めていなかった失敗の記録。
- 「取れた」と読んでいたのは、ただの案内ページだった：3日間、商品が0件
- 「確認済み」の印が付いていたのに、リンク先を一度も読めていなかった：t.co の中継ページ
- 「変な記事がめっちゃ増えてる」：作られた経路ごとに数えて入口を塞いだ。数え方も 2 回、間違えた
- 本物の抽選を、静かに捨てていた 4 つの実例：正規表現・年のない日付・まとめて聞く・null
- 候補は見つかっていたのに、答えを読む所で毎回落ちていた：200 トークンで切れた URL と、ハイフンで 400 になる検索
- 先着が始まった瞬間、サイトが順番待ちのページになる：8,000 バイトの関門を、15KB の案内ページがすり抜けた
- 通知は取り消せない：直近 72 時間の通知の 19% が誤通知で、関門が通知の「後」に効いていた
- 表示中の記事のリンク先を、実際に開いて確かめた：約 60 件の間違いと、最初の点検が間違えた 3 つのこと
名前と商品の取り違え
同じ名前、同じリンクが、別のものを指していた。商品と店の取り違えの記録。
- 1 つの記事を商品ごとに分ける処理で起きた 3 つの取り違え：子が親になり、共有リンクが別の店を指し、名前が 2 つの商品のものだった
- 「同じ応募ページ」なら「同じ店」と決めつけていた：店名が別の店になった記事 52 件
- 「ヤマダ電機」と「ヤマダデンキ」：表記ゆれと重複の原因は 3 つ重なっていた（包含だけの比較・59 秒の差・手動専用のジョブ）
- あいまいな店名で地図を引くと、日本の真ん中の静岡が返る：チェーン名を並べず、Google 自身の答えで判定した
- 「1 ページ ＝ 1 案件」ではなかった：1 つのフォームで 6 商品を受け付ける店の記事が、リンクが同じというだけで消されていた
- 英語表記とカタカナ表記は、1 文字も重ならない：正しい照合 42 件を、指紋の関門が却下していた
- 公式の一覧から、「作品名だけの商品」が 393 件できていた：商品名の欄に、商品の形は入っていなかった
- 商品のジャンルを、公式カタログで直した：下見を 3 回やって、13 件から 4 件に絞った
- 「これベイブレードじゃん」が、関門を入れても戻ってきた：弾いた値が、別の形で漏れた
- 「後から掃除するから大丈夫」が、入口の不具合を隠していた：商品が毎日 400 件そっくり作り直されていた
- 一度だけ生まれた誤字が、店ごとに増えていった：「30th SEREBRATION」の件
- 「9種セット」を中身ごとに分けて、偽の商品が80個できていた
監視と定期処理
先着の監視、同時実行の枠、配備と再実行。動き続ける処理の設計の記録。
- 「1 分おき」の監視は、1 件あたり 10 分に 1 回だった：速くする前に、見直しの間隔と、通知が届いた数を数えた
- 全部を速く見られないとき、何を速くするか：427 弾のうち人気の 128 弾を速く回し、予算を超えたら自分から譲る
- 同時実行の枠を増やす前に見るもの：2 コアのサーバーで、枠を 8 から 14 にした判断と、半分間違っていた前の結論
- タイムアウトを 3 回直しても止まらなかった：真犯人は、同じ鍵の中で動いていた 2 つ目の処理だった
- 配備のたびに、日次の処理が丸ごと走り直していた：48 時間で 477 回、その日の Gemini 費用の 46.6%
- 「自動化できるものは全部自動化して」：まず数えると、修復処理 66 個が一度も定期実行から呼ばれていなかった。全部は載せず、6 個だけ載せた
- X 監視の漏れ 4 つ：検索に出ない投稿、持ち主が変わるアカウント、店を探せない検索、止まった後の取り戻し
- まとめサイトの巡回は、一覧の 1 ページ目しか見ていなかった：トレカの記事は 2〜4 ページ目にあり、本文も先頭 6,000 文字で切れていた
- 競合サイトと突き合わせて、取りこぼしを数えた：最初の「カバー率 23%」は測り方の間違いで、本当は 49% だった
- 「気づくだけでなく、そもそも起こさない」：報告だけの監視を、見つけてその場で埋める形に作り替えた
- 「サーバーが落ちた。こちらからは復旧できない」は、誤りだった：止まっていたのは、SSH の受信だけだった
- 自分で作った仕組みが、自分を傷つけた 4 つの記録：要約が条件を捨て、1 つの未定義が保存を止め、点検が本番の IP を閉め出された
iOS アプリと基盤
サーバーの移行、iCloud、広告、審査、ビルド。アプリとその土台の、実際に起きたことの記録。
- Cloud Functions から月 4,300 円のサーバーへ移した：1 日 3,700 円の課金、EEA で全滅した Yahoo!、移行で踏んだ 5 つの罠
- ログに秘密のトークンが平文で残っていた：呼び忘れようがない唯一の出口で伏せる
- 「iCloud が新しければ取り込む」の関数が、何も比べていなかった：応募の記録が 20 件から 1 件になりうる
- 失敗を捨てると、画面は嘘をつく：「○件登録しました」と出て 1 件も入っていなかったカレンダー、固まる文字認識、店名を積み忘れた通知
- 同じ報告が 3 回目：SwiftUI のボタンが「文字の上でしか」反応しなかった。過去 2 回の「修正」は効いていなかった
- 広告が出ないと、実機チェックの 25 項目が止まった：開発者モードだけテスト広告を使い、賞品名を直書きしない
- iOS アプリが固まって強制終了される（0x8BADF00D）：SwiftUI の計算プロパティが毎回走っていた
- TestFlight にビルドが来ない：Xcode Cloud の月25時間を使い切っていた（最初の診断は誤りだった）
- ITMS-91064「無効なバイナリ」：NSPrivacyTracking が true なのに NSPrivacyTrackingDomains が空だった
- Xcode 15.2 で Firebase 12 が使えない（Swift 6.0 必須）：Firebase 11.4.0 と AdMob 11.5.0 に固定した理由
- App Store の審査で止まった四つ：iPad のスクショ、ITMS-91064、アカウント削除、投稿の通報
- App Store 審査で「Guideline 2.1 Information Needed」が届いた：求められた6つ
- Firebase Auth：アプリを完全に終了すると、匿名アカウントが量産された（currentUser の復元待ち）
ゲームの設計と測定
釣り合いを、AI 同士の対局や自動の試行で測って決めた記録。
- 寝返り将棋のルールを、AI 同士の対局で決めた：効いた 1 つの変更と、壊れた 6 つの案
- オンライン対戦は、端末の言うことを何も信用しない：手・持ち時間・勝敗を、サーバーが決める設計
- 穴子がデカすぎた話
- 「山は89%で落ち着く」は誤りだった：測定のほうが間違っていた話
- 10秒ピッタリのランキングを、公平にする：小数3桁・同着・書き込み回数
- 診断を12問にしたら、結果はどこまで変わるのか
公式の情報で比べた
値段・規約・上限を、公式の情報だけで比べた記事。確認できなかったことも書いてあります。
- 静的サイトを置く場所を、公式の規約で比べる：Cloudflare Pages・Netlify・Vercel・GitHub Pages・Firebase Hosting
- Claude API と Gemini API を、公式の数字で比べる：小さいモデルの値段・Web検索・上限・廃止予定
- iOS アプリの広告 SDK と Firebase を、公式の情報で比べる：AdMob・AppLovin MAX・LevelPlay・Supabase
- 静的サイトのコメント欄を、公式の情報で比べる：giscus・utterances・Disqus・Remark42 ほか
すし積む9本
-
すし積むの番付に載らなくなった：ゲームの数字を変えて、サーバーの検算を直し忘れていた（しかも二つ）
番付に、普通に遊んでも載らなくなった。ゲームの数字を変えて、サーバーの検算を直し忘れていた。金の桶の褒美（8,000→25,000）と、降るネタ（3種→5種）の二つ。注意書きでは守れず、同じ種で出題を比べる検査を足した。
-
押すものを六つから一つに絞った：初めての人は、どれを押せばいいか分からなかった
タイトル画面に押せるものが六つ並んでいた。初めての人に必要なのは最初の一歩だと考えて一つに絞った。iframeで保存が消える問題と、画面を離れたら止まる直しも含めた記録。
-
音は聴けないので、波形を測った：すし積むの和楽器を、WebAudioで作る
音声ファイルを使わず、箏・太鼓・拍子木・鉦をブラウザで合成した。聴けないので、波形のピークを測って音量を決めた。番付のしきい値も、自動プレイの実測で引き直した記録。
-
CrazyGames のプレビューで日本語が文字化け：ファイルは正しかった。原因は特定できず、ASCII 表記に逃がした
ゲームポータルのプレビューで「大連鎖！」の「連」だけが壊れた。ファイルのバイト列は正しく、原因は特定できなかった。ASCII 表記に逃がした経緯と、14言語の枠の検査の記録。
-
無料枠を半分しか使わない番付にした：呼び出し5回を2回に
番付サーバーが無料枠を使う量を半分にした。一人が遊ぶ一回の呼び出しは5回から2回、読んだ行は421から221へ。順位の数え方と、前置きの呼び出しをなくした経緯。
-
CrazyGames に落ちた：理由は書かれていなかったので、撮って探した
ゲームポータルの審査に「全体の品質が期待に達していない」とだけ書かれて落ちた。自分で画面を撮って見つけた四つの原因と、測って選んだ直し方の記録。
-
「山は89%で落ち着く」は誤りだった：測定のほうが間違っていた話
すし積むのバランスを測りなおしたら、前の測定が落下中のネタを数えていた。大きさの階段の逆行、縦穴の桶、床のすり抜け。三つの原因と直したあとの数字。
-
広告の間隔を、回数ではなく時間で測る
「5プレイに一本」をやめて「前の広告から7分」に変えた理由と、変えたあとの動きの記録。書きながら、一戦の長さが分かっていないことに気づいた。
-
穴子がデカすぎた話
落ち物パズルの最後の一手に、どうしても届かない。勘で直す前に、自動プレイで三百戦以上の統計を取って原因を突き止めた記録。
トレカダッシュ58本
-
トレカ抽選アプリを比較：トレカダッシュ・トレゲト・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回。数え直して見つかったことを、コミットの数字で書いた。
寝返り将棋2本
-
オンライン対戦は、端末の言うことを何も信用しない：手・持ち時間・勝敗を、サーバーが決める設計
ログイン無しのオンライン対戦を作った。手の検証をルールエンジンに通す、持ち時間をサーバーだけが持つ、切断は 30 秒待つ、署名つきトークンで名乗りを防ぐ、レーティングは対局前の相手の数字で計算する。コードの実際の値つき。
-
寝返り将棋のルールを、AI 同士の対局で決めた：効いた 1 つの変更と、壊れた 6 つの案
6×6 の盤で挟んで裏返す将棋。ルールの数値を勘で決めず、AI 同士の対局を 40〜100 局ずつ回して測った。反転が 2% から 81% に増えた変更、玉の守りを外すと 17 手で終わった実験、直せていない先後の差まで。
このサイト1本
Koshin Studio2本
-
Retina で canvas が2倍の大きさになる：inset:0 では広がらない（押すと弾けるロゴの不具合）
押して弾ける動きの粒が「変なところから出る」。原因は、Retina で canvas の CSS 上の大きさが2倍になること（inset:0 では広がらない）と、GSAP が位置を書き換えること。三段階で直した記録。
-
手元では動くのに、配ると壊れる：このサイトで起きた四つの事故
古いキャッシュ、組むたびに増えるパンくず、環境の中を指す symlink、手元にしか無い絵。サイトを配るときに続いた四つの事故と、検査を足してはじめて見つかった経緯。
ガチアニメ診断5本
-
16,177作から6,091作へ：診断のデータベースは、6割以上を落として作った
診断に使う作品は、Annict・Filmarks・手元の名作をまとめた16,177件のうち、手がかりが足りた6,091作だけ。落とした基準と、残った作品の出どころ・偏りを、数字で書いた記録。
-
配信ボタンは、見られない作品にも出ていた：診断の結果画面を「本当」に寄せる
診断の配信ボタンは、全作品に同じ2つだった。実際の配信状況と数え直すと、約29%でどちらかが外れ。配信状況で絞った経緯と、画像の食い違い（http、仮の絵、ロゴ混入）の記録。
-
「82%より80%が選ばれる」：診断の適合度%が、並び順と食い違っていた
診断の適合度%は、並び順とは別の物差しで作られていた。旧い表示では、回答者の35〜40%で上位3作の表示が逆転。作り物の回答者1,000人で測り直した記録。
-
Python の splitlines() で JSONL が壊れる：犯人は U+2028（見えない改行文字）
JSONL を splitlines() で読むと、あらすじ中の U+2028 で行が割れて JSON が壊れる。実データ（7,255行と7,247件、U+2028 は8個）で確かめて、split("\n") に直した記録。
-
診断を12問にしたら、結果はどこまで変わるのか
50問の診断を12問から始められるようにした。短くして結果は変わらないのか、作り物の回答者1,000人で測った記録。タイプはほぼ同じ、運命の1作はかなり変わる。