# 自分で作った仕組みが、自分を傷つけた 4 つの記録：要約が条件を捨て、1 つの未定義が保存を止め、点検が本番の IP を閉め出された > 「15 文字程度」の指示で応募の条件が 671 件の点検で抜けていた、undefined が 1 つで保存が全部失敗し 1 日の消費の 41% を溶かした、点検の 6 並列で本番と同じ IP が拒否された、直っても鳴り続ける警告を作った。 - URL: https://koshinstudio.com/notes/self-inflicted/ - 公開: 2026-10-17 - 書いた人: Koshin（https://koshinstudio.com/about/） - サイト: Koshin Studio English version (https://koshinstudio.com/en/notes/self-inflicted/) トレカダッシュ 開発の記録 ／ 2026年8月〜9月 iOS アプリ「トレカダッシュ (https://koshinstudio.com/works/torecadash/)」の開発では、外から来る不具合のほかに、自分で作った仕組みや、自分でした点検が、自分に被害を出したことが何度かありました。この記事は、そのうちの 4 つの記録です。どれも、数字で見えたあとに、直しました。 数字と日付は、2026 年 8 月 28 日〜9 月 15 日の作業の記録から書いています。 ## 1. 「15 文字程度」の指示が、応募の条件を捨てていた（9 月 14 日） アプリは、抽選の応募の条件（フォローとリポストが必要、会員証が必要、など）を、AI に短くまとめさせて画面に出しています。表示中の抽選 671 件を、元の告知（X の投稿の本文と画像）と、AI で突き合わせて点検しました。 食い違いより、「抜け」が多く見つかりました。 抜けていた条件 | 件数 リポスト | 23 会員 | 20 アプリ | 13 LivePocket（応募サービス） | 13 原因は、AI への指示文でした。要約を「15 文字程度」と指定していたので、AI は条件を 1〜2 個に削っていました。さらに、「受け取りや購入の条件は書かない」という規則を、「購入時に会員証を確認」まで広げて捨てていました。会員証は、持っていないと買えないので、応募の条件です。 文字数の制約は、AI に「どれを捨てるか」を選ばせます。捨てる規則を書くと、境界にある条件まで捨てられます。直し方は、「全部、上限は何文字」と頼み、必ず残す要素を並べることでした。点検でも、AI の判定を数えるだけで終わらず、代表例を元の画像で確かめてから直しました。AI の検品は、うるさい（誤って指摘する）ことがあるからです。 ## 2. 1 つの値が「未定義」だと、保存が全部失敗した（8 月 28 日） データを、まとめて書き戻す処理がありました。取得サービス（Scrape.do）の設定の記録を、全体を 1 つの塊として書き込みます。ある日、この書き込みが、毎回、こういうエラーで失敗していました。 Cannot use "undefined" as a Firestore value (found in field "domains.`www.yamada-denkiweb.com`.super") 1 つのサイトの項目に、undefined（値が定義されていない）が 1 つ混ざっていただけで、その後、どのサイトの保存も失敗し続けました。 被害は、別のサイトに出ました。「どの設定でも取得できないサイトを、6 時間休止する」という記録が、保存できなかったのです。あるサイトを、巡回のたびに 3 つの設定（1 + 10 + 25 = 36 クレジット）で叩き続け、1 日 13,183 クレジット、その日の全消費の 41% を溶かしていました。取得サービスは、日次の予算を時刻で按分するので、1 つのサイトがその日の 41% を使うと、ほかのサイトに回せる分が、その分だけ減ります。 教訓は、まとめて書き戻す形の処理は、1 つの汚れが全体の保存を壊すことです。値を書く前に、undefined を取り除く。そして、保存が失敗したら、黙らず、目立つ形で知らせます。 ## 3. 点検のために、本番と同じ IP を閉め出された（9 月 15 日） 在庫の点検のスクリプトを、本番と同じサーバーから動かしました。通販サイト（Yahoo!ショッピング）の商品ページ 501 件を、6 並列で、素のリクエストで読みました。数分で、そのサーバーの IP アドレスごと、HTTP 489（アクセスを拒否する応答）が返ってくるようになりました。数時間たっても解けませんでした。 本番の取り込みも、在庫の再検証も、同じ IP から Yahoo! を読んでいます。点検の都合で、本番の目を潰してしまったのです。しかも、点検側は、読めなかったページを取得サービスへ回すので、そのクレジットも無駄に使い始めていました。 直し方（というより、決まりごと）は、本番と同じサーバーから通販サイトをまとめて読むときは、1 並列、1 件ごとに間を空けることです。最初に数件だけ流して、応答が 200 のままかを見てから、広げます。在庫は、まずページの中の構造化データ（在庫の有無が書かれた部分）を、少数で確かめ、全件の確認は、本番の再検証の処理に任せます。 ## 4. 直っても鳴り続ける警告を、一晩に 4 つ作った（8 月 29 日） 異常を知らせる警告を、たくさん入れてきました。2026 年 8 月 29 日の 1 晩で、直す道があるのに鳴り続ける警告を 3 つ直し、自分で 4 つ目を作りました。4 つ目は、AI の利用残高が切れたときの印で、入金して復旧しても、24 時間、消えない作りでした。 同じ形は、前にも出ています。 - データ取得の費用の警告が、「月末には必ず 8 割を超える」。 - 取得サービスの残りの警告が、「月末には必ず残りが 2 割になる」。 - 「0 件」が正常な状態なのに、0 件で警告が鳴る。 - 取り消した定価が、翌朝、元に書き戻される往復。 消えない警告は、本物の異常を埋もれさせます。それ以来、警告を書くときは、鳴る条件と同時に消える条件を作ります。自分に聞く質問は 3 つです。 - 問題が直ったとき、この警告は、誰が消すのか。 - 月末や月初など、時間がたつだけで、必ず鳴る指標になっていないか。 - 0 件や低い値が、正常な状態ではないか。 消す人がいない警告は、作りません。成功したときに印を消す処理を、警告と同じ変更に入れます。 ## 分かったこと > 自分の道具は、自分にも効く。 - 制約は、捨てるものを選ばせる。文字数の上限を付けるなら、残すものを書く。 - まとめて書く処理は、1 つの汚れで全体が止まる。書く前に、取り除く。 - 点検は、本番の邪魔をしない。同じ IP、同じ上限を使う処理は、控えめに。 - 警告は、消える条件とセットで作る。 この話に出てくるもの - トレカダッシュ (https://koshinstudio.com/works/torecadash/) — トレカの抽選・予約・先着の情報を集める iPhone アプリ - 「しょうがない」を測り直したら、取得の費用は8分の1だった (https://koshinstudio.com/notes/scrape-cost/) — 取得の費用の、別の記録 - 配備のたびに、日次の処理が丸ごと走り直していた (https://koshinstudio.com/notes/rerun-on-deploy/) — 自分の変更が、費用を溶かした別の例 - 本物の抽選を、静かに捨てていた 4 つの実例 (https://koshinstudio.com/notes/silent-discard/) — 画面に出ない失敗