夕方の打ち合わせのあとにダッシュボードを開いて、フィルレートが朝から下がっていたことに気づく日が続いていました。一日の半分が過ぎてから対処を始めるので、その日の売上は取り戻しようがなく、原因切り分けの記録も曖昧になりがちです。地味に効くダメージで、しばらく我慢していたのですが、いよいよ朝のうちに気づける運用に切り替えたほうがよさそうだと思い至りました。
アーティスト・クリエイターの廣川政樹です。2014 年から個人でアプリを作っていて、累計 5,000 万ダウンロードを超えるくらいになりました。普段は壁紙アプリと癒し系アプリを中心に運用しています。今回は、毎朝 Claude in Chrome に AdMob のレポートを読ませてフィルレート低下を察知する運用に切り替え、2 週間続けてみた所感をまとめます。
切り替えた動機
直前まで、AdMob ダッシュボードは「気になったときに見に行く場所」でした。リリース直後やフロアプライスを動かした日は朝から張り付くものの、安定運用に入ると週に 2〜3 回しか開かなくなります。その結果、フィルレートが 80% 台から 60% 台に落ちていても、夕方にようやく気づくサイクルが定着していました。
朝に察知できないと困る理由は、主に 3 つあります。
- 時差で被害が広がる — 北米時間のセッションが進む間に、メディエーションのウォーターフォールが想定外の挙動を続けてしまう
- 原因切り分けの粒度が荒くなる — ネットワーク別の落ち込みは、午前と午後でログを分けて見ないと特定しづらい
- 再現可能な記録が残らない — 夕方の対処は急ぎ仕事になり、何をどう判断したかメモが残らない
両家の祖父がともに宮大工だったので、「丁寧に組み上げたものは何十年も保つ」という感覚が幼少から身についています。コードも運用も同じで、毎日の点検をサボると見えないところで歪んできます。朝の点検を仕組み化してしまうほうが、長く運用するアプリには合っていると感じました。
運用の組み方
Claude in Chrome に AdMob のダッシュボードを毎朝開かせ、前日と前週同日のフィルレート差分を読み上げてもらう構成にしています。やりたいことは「異常値の早期発見」だけなので、最小限のステップに絞りました。
具体的には、Cowork のスケジュールタスクから Claude in Chrome を 7:10 JST に起動し、AdMob レポートの URL を順に開かせています。アプリ別・ネットワーク別のフィルレートを CSV としてエクスポートさせ、その場で前週同日との差分を計算してもらう流れです。差分が一定値（私は −5 ポイント）を超えていた場合だけ、Slack に短いサマリを書き込む設定にしました。
ここで意外と効いたのが、「異常値が無かった日は何も通知しない」というルールです。最初は毎日サマリを受け取っていたのですが、3 日もすると朝の Slack が情報過多になり、肝心の異常通知に気づきにくくなりました。サイレンス・イズ・ノー・ニュースとして扱う方針に切り替えてから、異常があった日の朝だけ集中して動けるようになっています。
2 週間で見えた数値
5/12〜5/24 の 14 日間で、フィルレート低下の通知が来たのは合計 4 回でした。内訳は以下のとおりです。
- 5/14（火） Liftoff 側で 12 ポイント低下、特定 SDK 版で配信停止
- 5/16（木） InMobi 側で 8 ポイント低下、Geo フィルタの再設定漏れ
- 5/20（月） Unity Ads 側で 6 ポイント低下、入札ロジックの更新と推測
- 5/23（木） AppLovin MAX 側で 7 ポイント低下、SDK アップデート直後の挙動
4 件すべて、午前 10 時までに対処に着手できました。以前の運用では同じトラブルを 3〜4 回見つけられていたかどうかすら怪しかったので、検知率の向上は確かに感じています。eCPM への影響としては、4 件合計で約 18,400 円の損失で済んでおり、月換算 4 万円弱のリカバリーになっている計算です。
ただし、Claude in Chrome が直接の原因を当てたのは 4 件のうち 2 件だけでした。残り 2 件は「数値の差分は正しく拾えたが、原因の推測が外れていた」ケースで、結局は手動で AdMob と各社管理画面を行き来して切り分けています。原因推定はまだ伴走者の役割で、判断は人間が持つほうが現実的だと感じました。
ぶつかった壁
便利になったぶん、想定していなかった摩擦もありました。一番大きかったのは、Claude in Chrome 側でログイン状態が切れる頻度です。AdMob のセッションは数日で再認証を要求してくることがあり、その日はスケジュールタスクが空振りしました。
対処として、週に 1 度は手動で Chrome を立ち上げ、AdMob のダッシュボードに自分でログインしておく時間を作りました。これで再認証の頻度はだいぶ落ち着きましたが、完全には無くなりません。本番運用に乗せる前提なら、複数アカウントで二重化するか、API 経由に切り替える検討も必要そうです。
もう 1 つは、CSV エクスポートの待ち時間です。アプリ別・ネットワーク別の細かい粒度でレポートを取ろうとすると、20 秒近く待たされることがあります。Claude in Chrome は待機中も人間の操作待ちと判別しづらく、フリーズしているように見えた日が何度かありました。タイムアウトを明示的に伸ばすプロンプトを足すことで、ある程度落ち着いています。
同じことを Claude Code でやろうとしてみた話
途中で、Claude Code から AdMob API を叩いて同じことができないか試した日もありました。結論としては「やればできるが、私の運用規模だと割に合わない」でした。
API キーの管理、OAuth リフレッシュ、レポートの粒度指定など、最初の設定だけで半日以上かかります。私は 4 アプリ × 4 ネットワーク程度しか抱えていないので、ダッシュボードを目視で確認しても 5 分しかかからない規模です。10 アプリ以上を運用していたり、複数の AdMob アカウントを持っているなら API 化の意義は大きいと思いますが、個人開発の中規模までなら Claude in Chrome のほうが立ち上がりが速いと判断しました。
どこに線を引くか
2 週間運用してみて、線引きはかなり明確になりました。
- 任せる: AdMob ダッシュボードのレポート取得、前週同日との差分計算、しきい値を超えたときの通知作成
- 任せない: 原因の最終判断、フロアプライスの調整指示、メディエーション順序の入れ替え
- 半々: 原因候補のリストアップ。挙げてもらった候補から、私が AdMob/AppLovin/Liftoff の管理画面を見て決定する
17 歳の頃にあるオンラインのメンターから「芸術は全ての人に開かれた自然な言語だ」と教わったことがあり、私はそれをツールの選び方にもあてはめて考えるようになりました。AI に何でも任せる方向ではなく、自分が判断するための材料を最短で揃えてくれる存在として置くと、長く付き合える気がしています。今回の Claude in Chrome の使い方も、判断は手元に残したまま、材料の整え方だけを変えた格好です。
次に試したいこと
ここから先は、3 つの方向で広げていきます。
- 検知のしきい値を −5 ポイントから −3 ポイントに下げて、小さい揺らぎも拾うか試す
- Crashlytics の急増もあわせて朝の点検に組み込み、収益面とアプリ品質を同じビューで見る
- 月 1 回、Claude in Chrome に「過去 30 日でしきい値を超えた日」を一覧で出させて、季節性のパターンを確認する
朝の 5 分を整えるだけで、夕方の打ち合わせから戻ったときに「今日も静かに回っていた」と判断できる安心感は予想以上でした。同じように個人で運用しているかたの参考になれば嬉しいです。お読みいただきありがとうございました。