通知は取り消せない：直近 72 時間の通知の 19% が誤通知で、関門が通知の「後」に効いていた

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

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

iOS アプリ「トレカダッシュ」は、トレカの抽選販売の情報を集めて、新しい情報が見つかると、利用者のスマートフォンに通知します。集めた記事には、「本当に応募できる抽選か」を確かめる関門（フィルター）があります。当選者の発表、買取の告知、カード以外の商品、などを出さないための仕組みです。

ところが、2026 年 9 月 20 日の点検で、通知した記事の約 5 件に 1 件が、関門を通るべきではない記事だったと分かりました。関門はあったのに、通知は止まっていませんでした。

この記事は、2026 年 9 月 20 日の再点検の記録から書いています。

直近 72 時間の通知を、全部数えた

点検の方法は、単純です。直近 72 時間に通知した記事を全部取り出して、1 件ずつ「通知してよかったか」を判定し直しました。

通知した件数	誤通知	割合
644 件	122 件	19%

誤通知の内訳は、次のとおりです。

記事の関門は、あとから記事を「非表示」に下げる形でも働いていました。ところが、通知は、記事を保存した約 0.6 秒後に飛びます。関門が後から記事を下げても、通知は、もう送られています。

実際に、関門が後から非表示にした記事 30 件のうち、25 件は、すでにプッシュ通知が届いた後でした。画面からは消えても、スマートフォンに届いた通知は、取り消せません。

X の監視が止まっていた期間がありました。9 月 19 日 12:44 から、その分を取り戻す処理が動きました。このとき、9 月 13 日から 18 日の投稿が、新着として 367 件まとめて通知されました。

止まっていた間の投稿を取り込むのは正しいことです。しかし、「いつ見つけたか」ではなく、投稿の日付で見ないと、何日も前の投稿が、いま出たばかりの情報に見えてしまいます。

直し方は、「保存のときに効く関門」を増やすだけでは足りない、という点にありました。通知は取り消せないので、通知を送る関数の入口に、記事の関門と同じ判定を通すようにしました。

判定は、記事を保存する前の関門（screenArticleBeforeSave）に足す。通知を送る関数の入口も、同じ関数を通る。判定が 2 か所に別々に書かれて、食い違うことがない。
古い投稿は、保存した日ではなく、投稿日で見る。
取り戻しや再起動のあとは、通知を見送った理由の内訳を、必ず確認する。

取り消せないものは、出す前に止める。

この話に出てくるもの

ほかの記録

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 件は閉じたフォームだった。直し方と、誤った「確認済み」の印の外し方の記録。

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

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