5月の連休明けに、壁紙アプリの Crashlytics 管理画面が朝の通知で1日5〜6回鳴る日が続きました。クラッシュ率は0.4%前後で致命傷ではないのですが、Velocity Alert（短時間でクラッシュ件数が急増したときに飛ぶアラート）が立て続けに来ると、いつものように iPhone から見て放置するか、Mac に向かい直して掘り下げるか、判断が鈍ります。アーティスト・クリエイターの廣川政樹です。試しに Claude in Chrome に Firebase コンソールを開かせ、Velocity Alert のトリアージだけ任せる運用を3週間続けてみました。実装ノウハウというより、運用フローを変えてみての所感をまとめます。
なぜ「全部自動化」ではなく「トリアージだけ」にしたか
最初は「Crashlytics の通知が来たら Claude in Chrome で原因まで特定して、Slack に修正案を流す」というところまで作ろうとしました。実際に1日試して、すぐにやめました。Crashlytics のスタックトレースは、同じシグネチャに見えても呼び出し元のシナリオが違うことが多く、AI に最終判断まで任せると、無関係な過去の Issue にひもづけて「これは既知の問題です」と返してくる回数が多くなったからです。
3週間運用してみて、ちょうどよかった責任分界は以下のような形でした。Claude in Chrome は「Firebase コンソールを開き、Velocity Alert に紐づく Issue を確認し、過去24時間と過去7日間の発生数・端末・OS 分布・新規かどうかを箇条書きで報告する」までを担う。私はその箇条書きを iPhone で読み、修正に着手するか、しばらく様子を見るか、ダッシュボードを開き直して詳細を見るかを決める。判断と修正は人間が握り、収集と整理だけ AI に渡すという切り分けです。
個人開発で複数アプリ（私の場合は12年で50本超）を回していると、Crashlytics の通知に対して「すぐ見るかどうか」の判定だけでもけっこうな時間を取られます。そこを薄く削ったのは、想像していたよりも効きました。
実際に Claude in Chrome に渡しているプロンプトの骨子
毎朝の運用で渡しているプロンプトは、ほぼ固定の3段構成にしています。Firebase コンソールにログインさせ、対象アプリ（iOS / Android それぞれ）の Crashlytics → Issues タブを開かせる、Velocity Alert がついているものだけを抜き出させる、最後に各 Issue を以下のフォーマットで報告させる、という流れです。
- Issue タイトル（最初のクラスとメソッド）
- 影響ユーザー数: 24h / 7d
- 影響端末: 上位3機種と OS バージョン
- 初回発生: いつ（新規 / 既存）
- スタックトレース最上段3行
- 私が次に確認すべきこと（1行・推測ではなく事実ベースで）「私が次に確認すべきこと」のところに、つい「修正方法」を書かせたくなりますが、ここは事実だけにしています。たとえば「同じ Issue が iOS 18.4 でのみ増えている」「直近のリリース v2.14 以降にのみ出ている」といった、ダッシュボードを見れば分かることを言語化するだけ。修正方針は、自分でスタックトレースを開いてから決めます。
3週間で見えた、楽になったこと
一番大きいのは、朝の30分が他のことに使えるようになったことでした。これまでは、コーヒーをいれながら iPhone で Firebase アプリを開き、Velocity Alert ごとに Issue を開いて、影響端末を見て、メモを起こして、対応するかどうか決める、という流れを5アプリ分やっていました。それを Claude in Chrome に Mac で先に走らせておくと、自分が起きたときには整理された箇条書きが手元にあります。
副次的な効果として、「同じ Issue が複数アプリで同時に上がっているかどうか」が見えやすくなりました。たとえば AdMob SDK 起因と思われる NullPointerException が、壁紙アプリと癒し系アプリの両方で同じタイミングで増えていたことが、箇条書きを並べた瞬間に分かったケースがあります。今までは1アプリずつ確認していたので、横断的なパターンに気づくのが遅れがちでした。
もうひとつ、判断ログが残ることも地味に効いています。Claude in Chrome に投げた箇条書きと、私が下した判断（対応する / 様子見 / 既知）を1つのドキュメントにまとめておくと、1週間後に「あのとき様子見にした Issue は今どうなった？」と振り返るのが速くなります。これは人間だけでやっていると、後回しになりがちな部分でした。
楽にならなかったこと、むしろ手間が増えたこと
正直にいうと、最初の1週間は「これ、本当に楽になっているか？」と疑いながら使っていました。プロンプトが甘いと、Velocity Alert が付いていない通常の Issue まで報告してきたり、過去24時間の数字を間違えたりするので、生のダッシュボードと突き合わせる二度手間が発生していました。
特に間違いやすかったのが、Issue の「新規 / 既存」の判定です。Crashlytics のダッシュボードは初回発生日を表示してくれますが、Claude in Chrome の解釈は「7日以内の発生なら新規」と勝手に判定してしまうことがあり、その都度プロンプトを修正しました。最終的に「Firebase が New ラベルを付けているものだけを新規として扱うこと。それ以外は既存」と明示することで安定しました。
それから、Android の難読化シンボルが解けないクラッシュは、Claude in Chrome に渡しても何も出てきません。ProGuard のマッピングファイルが Crashlytics 側に正しく上がっていない状態だと、スタックトレースが a.b.c.d のような形でしか見えないので、AI でも人間でも判定不能になります。これは AI の問題ではなく、自分の運用の穴でした。マッピングのアップロードを自動化するきっかけになったので、結果的にはありがたい気づきです。
Sentry / Bugsnag を併用している人にも当てはまりそうな話
私自身は Firebase Crashlytics を使っていますが、似たような Velocity Alert の概念は Sentry の「Issue alerts → trigger when events exceed threshold」や、Bugsnag の「Spike detection」にも存在します。Claude in Chrome 経由で対応している箇条書きの骨子はほとんど同じで使えるはずです。
ただし、Sentry の方が UI 上で「リリースごとの初回発生」を扱う粒度が細かいので、Claude in Chrome に投げるプロンプトでも「Release 順に並べて、最新2リリースで急増しているものだけを抜き出す」と書きやすい印象があります。Crashlytics でリリース単位の集計を取りたいときは、Issue を一つひとつ開いて手で「バージョン別」を見る必要があるので、Claude in Chrome に開かせるとそこそこ時間がかかります。ここはツール選択の問題で、AI の問題ではありません。
個人開発者の運用として、何を残し、何を捨てたか
3週間の運用で、最終的に残したルールは3つだけになりました。
第一に、Velocity Alert に紐づく Issue だけ Claude in Chrome に整理させる。普段の Crashlytics ダッシュボードを丸ごと開かせるのは、トークンも時間も無駄になりやすいので諦めました。
第二に、判断と修正は人間が握る。AI に修正方針を書かせると、もっともらしいけれど見当違いな提案が混ざりやすく、それを検証する時間で結局トータルは遅くなります。Claude on Xcode 側で修正パッチを試すフェーズは別に分けています。
第三に、毎週1回、AI が出した箇条書きと自分の判断のログを見直す。同じ Issue を毎週「様子見」にしていたら、それは「修正すべきもの」を先送りしているサインです。AI が淡々と並べてくれるので、見直しのときに人間の感情が入りにくく、これは思っていたよりもありがたい副作用でした。
逆に捨てたのは、「全 Crashlytics Issue の自動分類」と「Slack への自動投稿」です。前者は AI の判定誤差が積み重なって信用できなくなり、後者は通知過多で自分が見なくなりました。AI に渡すのは観測のごく一部に絞り、判断と通知設計は人間側で持つというのが、3週間後に残った形です。
次に取り組むこと
直近で試したいのは、Claude in Chrome に Firebase Crashlytics と AdMob のダッシュボードを横並びで開かせ、「クラッシュ急増と eCPM 急落が同時に起きたら知らせる」という運用です。これは AdMob のメディエーション最適化（別記事で書いている題材）の続きにあたります。1997年頃にインターネットで独学を始めたときから、私は新しいツールの取り入れ方を「最小限から少しずつ」にしてきました。Claude in Chrome についても、同じやり方で広げていきたいと考えています。
お読みいただきありがとうございました。Crashlytics と AI の組み合わせに同じく悩んでいる個人開発者の方の参考になれば嬉しく思います。