朝のうちにダッシュボードを開く運用は半年ほど続けてきたのですが、AdMob と Crashlytics を別々の画面で確認していたせいで、片方の異常に気を取られて、もう片方の予兆を見落とす日が出てきました。フィルレートの低下を追いかけている間にクラッシュが急増していたり、その逆だったり。「収益面の異常と品質面の異常は、相関して起こりやすい」と頭ではわかっていたのに、運用の枠組みがそれを前提にできていなかったのです。
アーティスト・クリエイターの廣川政樹です。2014 年から iPhone / Android アプリを個人で作っていて、累計 5,000 万ダウンロードを超えるくらいになりました。今回は AdMob のフィルレートと Crashlytics のクラッシュ急増を別々に追っていた朝の点検を、Cowork のスケジュールタスクで一つの朝報にまとめた話を、2 週間運用してみた所感とあわせて残しておきます。
統合に踏み切った理由
5/8 の朝に、AdMob 側のフィルレートが 8 ポイント落ちている通知をきっかけに切り分けを始めたら、同じ時刻帯に Crashlytics 側で特定 SDK 版のクラッシュが急増していたことが、午後になってから判明した日がありました。広告 SDK の更新が片方の SDK 経路でクラッシュを誘発し、その影響でフィルレートも落ちていた、というのが事後の整理です。先に Crashlytics を見ていれば、原因の特定は半日早かったはずでした。
両家の祖父がともに宮大工で、「異常が出るところは、たいてい連れて出る」という言い方をよくしていたのを思い出します。屋根の歪みと柱の沈み、雨漏りと木材の収縮。単独で起きるように見えても、根っこを辿ると同じところに行き着く、という感覚です。アプリ運用にも同じ性質があって、収益の異常と品質の異常は、別々のダッシュボードで別々に見るのではなく、一つの視点でまとめて点検したほうが見落としが減ります。
Cowork スケジュールタスクの組み方
統合の枠組みは、Cowork のスケジュールタスクを 1 本立てて、その中から Claude in Chrome に AdMob と Crashlytics の両方を順に開かせる形にしました。以前は AdMob 用と Crashlytics 用で別の朝タスクを動かしていたのですが、別タスクのままだと出力先も別で、突き合わせる作業を私自身がやっていました。
タスクの中身は単純で、以下のような順番でプロンプトを組んでいます。
- AdMob のレポート画面を開き、前週同日との差分が −5 ポイント以上のアプリ × ネットワークを抽出する
- 続けて Firebase Crashlytics を開き、直近 24 時間で前週同日比 +30% 以上のクラッシュをアプリ別に抽出する
- 両者を時刻帯で重ねて、同じ時間帯に動いているものがあれば「相関の可能性あり」として注記する
- 何も検出されない場合は通知を送らず、検出された場合だけ Slack に短いサマリを書き込む
3 番目の「時刻帯で重ねる」だけは、当初は人間がやっていました。やってみると毎日 1 分の作業ですが、毎日 1 分のために朝の集中力を使うのは惜しかったので、プロンプトに組み込んでしまいました。
2 週間で見えた数値
5/13〜5/26 の 14 日間で、Slack に通知が来たのは合計 6 回でした。内訳は以下のとおりです。
- 5/14（水） AdMob フィルレート −7 ポイント、Crashlytics 変化なし。広告ネットワーク側の Geo フィルタ
- 5/16（金） Crashlytics +42%、AdMob 変化なし。Android 6 のみで再現する起動時クラッシュ
- 5/18（日） AdMob フィルレート −6 ポイント、Crashlytics +35%、相関ありの注記
- 5/22（木） Crashlytics +31%、AdMob 変化なし。特定の壁紙画像で発生していた解像度由来のクラッシュ
- 5/24（土） AdMob フィルレート −9 ポイント、Crashlytics 変化なし。一時的な配信停止
- 5/26（月） AdMob フィルレート −5 ポイント、Crashlytics +38%、相関ありの注記
このうち相関ありと注記された 5/18 と 5/26 の 2 件は、いずれも広告 SDK のアップデート直後でした。片方だけ見ていた以前の運用なら、原因を SDK の更新に絞り込むのに半日かかっていたところを、午前中の段階で当たりをつけられたので、対処への時間は実感として半分くらいに縮まっています。
具体的な数字では、5/18 のケースは午前 9:40 に対処に着手でき、5 月平均の eCPM 復元までに要した時間は約 90 分でした。同じパターンを単独運用で踏んだ 4 月の事例では、原因切り分けから対処完了まで約 4 時間かかっていたので、2 件分の損失で換算すると約 7,200 円のリカバリーになっています。月に均すと、現状の私の運用規模では 1.5 万円弱の差です。
ぶつかった壁
便利になったぶん、想定していなかった摩擦もありました。一番大きかったのは、Crashlytics と AdMob でセッション維持の挙動が違うことです。AdMob は数日でログインを要求してくる一方、Firebase コンソールは Google アカウントのセッションに乗るので、Workspace のポリシー次第で挙動が変わります。タスクが空振りした日が 14 日のうち 2 日あり、いずれも Firebase 側の認証エラーでした。
対処として、週に 1 度は手動で両方のコンソールにログインする時間を金曜の夕方に確保しました。これで認証エラーは出にくくなりましたが、完全には無くなりません。検知タスク自体は冪等に作ってあるので、空振りしてもサイレンスが続くだけで影響は小さいのですが、本番運用に乗せる前提なら、Firebase Admin SDK 経由で Crashlytics データを取りに行く方が安定すると感じています。
もう 1 つは、相関注記の偽陽性です。実際には別の原因で同時刻に起きていただけのケースも 2 週間で 1 件ありました。広告 SDK の更新と無関係な、たまたま同時刻のサーバ側障害だったのですが、相関ありの注記に引っ張られて広告 SDK の調査に半日使ってしまいました。「同時刻に起きている」ことと「相関している」ことは別なので、注記の文言を「同時刻に発生・要確認」に変えてからは、深追いを防げています。
任せる範囲と任せない範囲
2 週間運用してみて、線引きはかなり明確になりました。以下のように整理しています。
- 任せる: AdMob と Crashlytics のレポート取得、前週同日との差分計算、しきい値を超えたときの通知作成、時刻帯の重ね合わせ
- 任せない: 原因の最終判断、Crashlytics スタックトレースの確定的な解釈、ユーザー影響範囲の判断、Hotfix を出すか否かの判断
- 半々: 原因候補のリストアップと優先順位付け。挙げてもらった候補から、私が Firebase コンソールと AdMob 管理画面を見て決定する
17 歳の頃にあるオンラインのメンターから「芸術は全ての人に開かれた自然な言語だ」と教わったことがあり、私はそれをツールの選び方にもあてはめて考えるようになりました。Claude に何でも判断させる方向ではなく、私が判断するための材料を最短で揃えてくれる存在として置くと、長く付き合える気がしています。今回も、判断は手元に残したまま、材料の集め方と並べ方だけを変えた格好です。
次に試したいこと
ここから先は、3 つの方向で広げていきます。
- Crashlytics の急増しきい値を +30% から +20% に下げて、小さい兆候も拾うか試す
- Android 側の Google Play Console から ANR レートも同じ朝報に統合し、収益・クラッシュ・ANR の 3 軸で点検する
- 月に 1 度、Cowork のスケジュールタスクに「過去 30 日で相関注記が出た日」の一覧を出させ、リリースカレンダーと突き合わせる
朝の 10 分を点検に充てることで、午後の判断が速くなるサイクルは確かに回り始めています。アプリの数も SDK の数も増え続けているので、点検の組み立て直しはこれからも続けていくつもりです。