コードは正しかった — 14日間ゼロだった広告の記録は、管理画面のスイッチ1つで死んでいた — 制作日誌 #12

自作アプリでは、広告が1回表示されるたびに「いくらの収益が発生したか」という通知を受け取って、記録している。用途は2つある。

1. 自分のダッシュボードに広告の収益を出す
2. 無料で使っている人に、広告を見たぶんだけ見返り（AIの提案が使える回数）を返す

2つめはストアの説明文にも書いている約束だ。ところが、この通知の記録が14日間・2つのアプリで合計0件だった。

広告の管理画面のほうでは、同じ期間に表示も収益も発生している。出ているのに、受け取れていない。

コードを4層に分けて全部見た

原因を探すとき、私は関わる層をすべて書き出して、上から順に潰した。

「インプレッション単位の広告収益」という項目がある。これが既定でオフで、オフのあいだは1表示ごとの通知そのものが送られてこない。

コードは最初から正しかった。正しいコードを4回読み返しても、正しいという結論しか出てこない。 ここに気づくまで、私はアプリ側を疑い続けていた。

一番痛かったのは記録ではなく約束のほう

ダッシュボードの数字が欠けるのは、あとから埋め合わせもできるし、困るのは私だけだ。実害が大きかったのはもう一方だった。

広告を見たぶん、AIの提案が使える回数が増えます

この見返りは、1表示ごとの収益通知が来たタイミングで付与する作りにしていた。通知が来なければ、付与も走らない。つまり提供を開始してからずっと、広告を見た人に何も返していなかった。

ストアの説明文に書いてあることが動いていない、というのは機能の不具合より重い。しかも、使う人からは「増えていない」ことに気づきにくい（増えるはずの回数を知らないため）ので、苦情という形では絶対に上がってこない種類の壊れ方だった。

この設定にはAPIから触れない

もう一つ引っかかった点がある。私は広告の数字をスクリプトで自動取得しているが、この設定項目はAPIからは見えないし、変えられない。手元の鍵はレポートの読み取り専用で、設定系は権限がない。

結果として、ブラウザで管理画面を開くこと自体が唯一の確認手段になる。しかも管理画面は画面遷移で描画する作りなので、直接URLを叩いても中身が出ないことがある。サイドバーの「設定」を押して、タブを押して、はじめて表示される。

自動化を進めるほど、こういう「自動化できない一画面」が盲点になる。自動で見られる数字が増えるほど、手で見に行く回数は減るからだ。

直したあとに確認したこと

• オンにしても過去にはさかのぼらない。通知が飛び始めるのは、オンにした時点以降の表示から
• コードの変更は不要だった（配線は元から正しい）。直った証拠は、記録が0件から増え始めることでしか取れない
• 見返りの付与と収益の計上は、別々の経路にしておいた。片方が死んでももう片方は生きる。今回は収益の計上だけが無事だった

「ゼロ件」を見張る仕組みを足した

同じ壊れ方を二度としないために、記録の側に見張りを足した。考え方は単純で、「あるはずのものが無い」を検知するというものだ。

• 広告の表示は記録できている（読み込めた時点で自分で記録する処理を分けて持たせた）
• 広告の収益通知は外部から来る
• したがって「表示はあるのに収益通知が0件」という状態は、構造的にありえない組み合わせになる

このありえない組み合わせが一定期間続いたら異常、と判定できる。今回の14日間は、まさにこの形をしていた。片方だけを見ていたら永久に気づけないが、2つ並べると矛盾が見える。

もう一つ変えたのは、記録の分離だ。それまでは「収益通知が来たら表示も1回と数える」という作りで、通知が止まると表示回数まで一緒にゼロになっていた。つまり壊れたときに、壊れたこと自体が見えなくなる作りだった。

障害の検知は、監視を足すよりも先に、「壊れたときに何が残るか」を設計しておくほうが効くというのが、この件で一番腹に落ちたことだった。

教訓として残したこと

• 「コードが正しい」は原因が無いことの証明ではない。 正しいコードが動かないなら、原因はコードの外にある
• 外部サービスを使う機能は、設定画面のスクリーンショットを1枚、記録として残す。既定値は黙って変わることがあるし、そもそも既定値を確認した記憶が残らない
• 「一度も発生していない」は最優先で疑う。 たまに失敗するのは実装の問題だが、ゼロ件は設定かスイッチの問題であることが多い。件数が0か1かで、疑う場所が変わる
• ユーザーとの約束（説明文に書いたこと）は、動いていることを定期的に自分で確かめる。壊れても苦情が来ない約束ほど、長期間放置される