毎朝 Firebase Crashlytics を開く習慣を、2014 年に個人開発を始めてから一度も外していませんでした。新規クラッシュが赤く目立つあの画面を、コーヒーを淹れる前にざっと眺める。安全な朝なら 30 秒、嫌な予感がする朝は 30 分。累計 5,000 万 DL を超えるあたりから、この 30 秒と 30 分の差が読めなくなり、生活のリズムが少しずつ削れていくのを感じていました。
2026 年 5 月に入って、Claude in Chrome を開発機の片隅で動かし始めたとき、最初に任せてみたのがこの「朝のダッシュボード確認」でした。完全自動化ではなく、週に一度まとめて Claude in Chrome に Crashlytics を見せ、自分は人間が判断すべき部分だけに集中します。そういう緩い分業を 2 週間続けた結果、思っていたよりも生活の手触りが変わったので、所感として残しておきます。
なぜ「毎朝確認」から「週次レビュー」に切り替えたかったか
毎朝の確認には、合理性と非合理性が同居していました。リリース直後の 48 時間は、致命的なクラッシュを発見するチャンスを最大化する意味で本当に意味があります。一方、リリースから数日経過したアプリの場合、新規クラッシュの 7 割は古い OS バージョンや極めて狭いデバイス組み合わせで起きる、即座の対応が不要なものでした。
私が個人開発で扱っているのは、Beautiful HD Wallpapers シリーズや癒し系アプリ、引き寄せ系アプリなど合計十数本です。毎朝すべてのアプリを横断的に確認していると、確認時間自体は短くても「気が散る時間」が無視できない量になっていきます。アーティスト活動と並行して個人開発を続けるうえで、この「気が散る時間」を圧縮したい、というのが今回の検証の発端でした。
Claude in Chrome に任せる範囲、自分で見る範囲
最初に意識したのは、Claude in Chrome は「監督者」ではなく「アシスタント」だという線引きです。Crashlytics の判断には、過去の修正履歴やアプリ固有の事情、ユーザーから直接届いた声などの暗黙知が大量に絡みます。これを全部 AI に任せようとした瞬間、判断品質は落ちますし、何より自分がアプリの状態を把握できなくなります。
そこで分業は次のようにしました。
Claude in Chrome に任せる側は、ダッシュボード巡回の手数を減らす方向に振りました。具体的には、複数アプリの Crashlytics 画面を順番に開いて、新規クラッシュの件数・影響ユーザー数・関連スタックトレースの先頭 5 行をスクレイプして、Markdown の一覧表にまとめてもらう作業です。週に 1 回、土曜日の朝に走らせます。
自分で見る側は、その一覧表を見ながら「これは今すぐ対処すべきか、次回リリースで一緒にやるか、見送ってよいか」を判断する作業に絞りました。Claude in Chrome に判断まで委ねるのではなく、判断材料を整える役割だけ任せる、というイメージです。
2 週間運用して見えた 3 つの変化
最初の週は、Claude in Chrome の挙動に慣れる時間と、自分が「毎朝確認」をやめる心理的な抵抗を解す時間でした。2 週間続けた段階で、はっきり手触りが変わった部分が 3 つあります。
1 つめは、判断の質が上がったことです。毎朝バラバラに見ていたときは、無意識のうちに「昨日と比べてどうか」という近視眼的な比較をしていました。週次レビューに切り替えると、7 日間の累積データを一度に見るので「このクラッシュは 1 週間で何件発生したか」という分母感覚が自然に身につきました。
2 つめは、対応の優先順位がぶれにくくなったことです。毎朝の確認では、その日に目に入った新しいクラッシュにつられて、本当に深刻なクラッシュより先に手を動かしてしまうことがありました。週次レビューだと、Claude in Chrome が並べてくれた一覧の中で、影響ユーザー数が多い順に上から処理できます。
3 つめは、アート活動と個人開発の切り替えが楽になったことです。1997 年に独学でプログラミングを始めた頃から、私にとって技術と表現は地続きの活動でした。けれど現実問題として、Crashlytics の画面を開いた瞬間は完全に「個人開発者の頭」に切り替わります。毎朝それを起動していると、創作のための静かな時間に入る前に頭が一度技術側へ振られてしまう。週 1 回だけ切り替えればよいことになって、創作のための朝が戻ってきました。
失敗ポイントと、後から修正したこと
ここまで書くと順調な検証に見えますが、実際には 1 週目で何度か「これは戻したほうがいいか」と迷いました。
特に大きかったのは、リリース直後の 48 時間ルールを最初に忘れてしまっていたことです。週次レビューに切り替えた直後にリリースしたアプリで、Android 14 の特定機種だけで起きるクラッシュを 2 日近く見逃しました。幸い影響ユーザー数は 10 人未満でしたが、本来なら翌朝に気づけるはずの問題でした。
そこから運用ルールを次のように整理しました。
- リリース直後 48 時間は、Claude in Chrome に任せず、これまで通り毎朝の目視確認を維持します。
- リリースから 48 時間を過ぎたアプリは、週次レビューの対象に組み入れる。
- 「Crash-free Users 99.7%」を下回るアプリが出た場合は、週次レビューを待たずに Claude in Chrome に即時アラートを送らせる。
3 つめのアラートは、Claude in Chrome の定期実行と Slack 通知を組み合わせる軽い仕組みです。詳細実装は別の記事に譲りますが、判断は自分、検知は AI、という分業の原則は崩していません。
「ブラウザを開かせる」という選択肢の手触り
API で Crashlytics のデータを取りに行けば、もっと整った形でデータを扱えるのは事実です。ただ、私が今回あえて Claude in Chrome に「画面を開かせる」運用にしたのは、人間がいつでも横から覗ける状態を保ちたかったからでした。
宮大工だった両祖父から受け取った感覚で、私は「手の届く範囲で確かめながら作業する」ことを大切にしたいと感じています。完全自動化されたパイプラインの中身は、後から覗き込もうとしてもどこを見ればよいか分からなくなりがちです。Chrome のタブとして残っていれば、いつでも自分の目で同じ画面に戻れます。
この「いつでも戻れる」という安心感は、定量化しにくいのですが、運用を続ける気力に確かに効いています。アート活動と個人開発を 12 年並行してきた中で身に染みた感覚として、自分が触れない仕組みは長持ちしません。
これから取り組むこと
週次レビューに移行した段階で、まだ手が回っていない領域がいくつか残っています。直近では次の 2 つを進める予定です。
1 つは、AdMob のレポートとの突き合わせです。クラッシュが多発した日と eCPM が落ち込んだ日が一致しているかを、Claude in Chrome に週次でクロスチェックしてもらえば、収益への影響を早めに掴めます。AdMob 媒介の比較記事を以前まとめましたが、運用面ではまだやれることが残っています。
もう 1 つは、英語圏のサポートメッセージとの突き合わせです。Crashlytics で兆候が出ていても、ユーザーから報告が届かないケースが大半です。逆に、ユーザーから先にメッセージが届いて、後から Crashlytics に集計が反映されるケースもあります。両方のデータソースを Claude in Chrome に並べてもらえば、見落としが減るはずです。
毎朝の習慣を 12 年続けてきた身としては、それを手放すのに勇気が要りました。2 週間続けてみて、今のところは戻したいとは思っていません。同じように、ダッシュボードを開く朝の時間を少し別のことに使いたいと感じている個人開発者の方の参考になれば幸いです。お読みいただきありがとうございました。