import { ArticleImage } from "@/components/ArticleImage";
アーティスト・クリエイターの廣川政樹です。
2014 年から iOS / Android アプリを運営してきて、AdMob のダッシュボードを毎日開くのが「当たり前の朝の儀式」になっていました。5,000 万 DL を支えてきた広告収益ですから、見ない方がおかしいくらいの感覚です。それを今年の春に、思い切って「毎日見ない運用」に切り替えました。代わりに Slack 通知を 4 階層に分けて、必要なときだけ手が動く仕組みに作り直しています。Rork で更新している壁紙アプリ群を題材に組み直してから 2 ヶ月、悪くない手応えなので、ここでは判断の経緯と失敗例を残しておきます。
なぜ「毎日見る」をやめたかったのか
正直、AdMob のグラフは中毒性があります。前日比 ±10% で一喜一憂し、eCPM が落ちると数十分ぶん思考が止まり、原因を探って結局「広告主側の波」だと納得して終わる、という日が積み重なっていました。
きっかけは、離れて暮らす子どもたちと話していたときの何気ない一言です。「お父さん最近、画面ばっかり見てるね」と笑われて、半分は冗談でも、半分は刺さりました。私にとってアプリは生計の道具であると同時に、子どもたちに「手を動かして作ること」を残すための仕事でもあります。グラフを眺めて反応するだけの時間が、その目的から少しずつずれてきている気がしたのです。
宮大工だった両祖父の手仕事を間近で見て育った身としては、「素材の癖に逆らわず、必要なときに必要な手を入れる」という感覚に立ち戻りたかった、というのも大きい動機でした。広告指標も「素材」だと思えば、毎日触る必要はないはずです。
Slack 通知を 4 階層に分けた
毎日見ない代わりに、「これは絶対に手を入れる」「気にはなる」「翌週まとめて見る」「無視してよい」を機械的に区別する仕組みが要ります。最終的に Slack の 4 チャンネルに振り分けました。
#admob-p0 には、収益の崩落シグナルだけが入ります。具体的には「日次収益が直近 14 日中央値から ‑40% 以上下振れ」「フィル率が 24 時間平均で 70% を下回る」「impressions が前日同時刻比で ‑60% 以上」のいずれか。これが鳴ったら、その場で手を止めて確認します。2 ヶ月で 3 回、いずれも実害ありの通知でした。
#admob-p1 には、eCPM の急変と単位日収益の異常値が入ります。「eCPM が 7 日平均から ±25% を超える」「特定の広告ユニットが急に impressions ゼロ」あたりがここ。鳴ったら 1 日以内に見ます。期待値は週 2〜3 件です。
#admob-p2 には、ベースラインのドリフトが入ります。「7 日平均が直前 28 日と比較して ‑15% 以上」「Android / iOS の収益比が大きくずれた」など。ここは週に 1 度、金曜の朝にまとめて見るルールにしました。
#admob-noise には、上記の閾値を満たさない細かい変動が静かに流れます。基本見ません。ただし「全く流れない週」があると検知器が壊れている可能性があるので、ここはむしろ静か過ぎる方を警戒します。
階層を分けて 2 ヶ月、#admob-p0 の 3 件以外は、ほぼ手が動かなくて済みました。逆に言うと、これまでの「毎日見る」運用の 9 割以上は、本当は見なくて良かったということです。
失敗例 3 つ
仕組みは最初からうまく行ったわけではありません。むしろ最初の 3 週間は誤検知と過剰通知に何度も苦しみました。
ひとつめ。「#admob-p0 の閾値を厳しくし過ぎた」失敗です。当初は ‑20% を閾値にしていたら、金曜日の広告主側予算消化サイクルで毎週鳴ってしまい、Slack を見るのが憂鬱になりました。「これは本当に手を入れるべきか？」を基準に閾値を緩めることで落ち着きました。
ふたつめ。「同じ事象を 3 チャンネルにまたいで通知してしまう」失敗。たとえば eCPM が ‑30% 下振れすると、#admob-p1（eCPM 急変）と #admob-p2（7 日平均ドリフト）と #admob-noise の全部で発火していました。下位チャンネルでは上位チャンネルと重複しているシグナルを抑制するロジックを足して解消しています。
みっつめ。「タイムゾーンを揃え忘れた」失敗。Rork アプリで使っている AdMob レポート API は UTC 基準ですが、Slack に流す時刻は JST、私の感覚は JST 朝、という三重のずれが起きて、「昨日の数値」が何を指しているのか曖昧になりました。すべて JST に統一するか、本文に「UTC 基準」と明示するかの 2 択で、私は前者を選びました。
「Claude in Chrome で巡回を任せる」流れに繋がった
毎日見ない運用に切り替えてから、自然に次の手が見えてきました。それが、Claude in Chrome で AdMob のダッシュボード巡回そのものを自動化する流れです。
通知だけだと、どうしても「数値の文脈」が落ちます。たとえば「インタースティシャルの eCPM が ‑18% 下振れた」と通知が来ても、それが「インドの広告単価が一時的に下がっただけ」なのか「他フォーマットへ移行すべきサイン」なのかは、結局ダッシュボードに入って見ないと分かりません。
そこで今は、Claude in Chrome に毎週 1 回、特定の AdMob レポートを巡回してもらって、サマリーを Markdown で残す試みを進めています。私が見るのは、その Markdown と #admob-p0〜#admob-p2 の通知だけ。素人考えで言えば、これでも見過ぎなくらいですが、まずは「毎日ダッシュボードを開かない」習慣を定着させるのが優先です。
詳細な仕組みはまだ調整中ですが、ひとつ言えるのは、AI に巡回を任せる前提が「自分は毎日見ない」という心構えだということです。順番が逆だと、ただ確認作業が二重になります。
数字に出てきた変化
体感だけで判断するのも気持ち悪いので、いくつか数字を見ています。
ひとつ、AdMob ダッシュボードを開いた回数。Chrome の履歴で雑に数えたところ、切り替え前は週 28 回前後、切り替え後の 2 ヶ月平均で週 4 回まで落ちました。#admob-p2 を見る金曜の朝と、#admob-p0 が鳴った 3 回ぶんの確認、あと月初の振り返り、というおおよその内訳です。
ふたつ、収益への影響。前年同月比でほぼ横ばい、月によって ±3% の範囲で動いています。少なくとも「ダッシュボードを毎日開かないと収益が落ちる」という相関は出ませんでした。むしろ慌てて広告ユニットをいじって悪化させていた時期より、今の方が指標は安定しています。
みっつ、作業時間の置き換え先。浮いた時間は壁紙アプリの素材更新と、Rork でのプロトタイピングに回しました。これも「子どもたちに作る背中を残す」という当初の目的に近い使い方になっていると思います。
個人開発者として、これから取り組みたいこと
ここまで書いてきて、結局のところ「監視は感度の問題」だと感じています。毎日見るのが正解の指標もあれば、月に 1 度で十分な指標もあります。AdMob の日次変動は、私にとっては後者でした。
これから取り組みたいのは、同じ感覚を Crashlytics や App Store のレビュー監視にも広げていくことです。クラッシュは Slack の #crashlytics-p0 が今のところ機能しているので、レビューの方をどう仕組みにするかが次の宿題です。ここも素人考えではなく、Claude in Chrome に毎日 1 回見てもらうところから組み立てる予定でいます。
仕組みを丁寧に作ってから一歩引く、というのは、宮大工だった祖父たちの仕事ぶりに通じる気がしています。手を入れる前に、まず「触らなくていいところ」を見極めること。広告指標も同じだと、2 ヶ月の運用でようやく腑に落ちました。
同じく個人で AdMob を回している方が、「毎日見る習慣」を一度疑ってみる気持ちで参考にしてくれたら嬉しいです。お読みいただきありがとうございました。