Claude x Firebase MCPで、Crashlyticsのデータを整理してSlackに通知する

長島大和

開発

長島大和

最終更新日2025/12/12 投稿日2025/12/23

この記事はレコチョク Advent Calendar 2025の23日目の記事です。

はじめに

こんにちは、株式会社レコチョクの長島です。iOSアプリの開発などをしています。現在はプロダクト開発第2グループに所属しております。今年はPorter RobinsonのSMILE! :D World Tourに参加したり、渋谷で開かれていたNIGHT HIKEというサーキット型フェスイベントに参加したりしました。どちらも大変に楽しかったです。ライブハウスなりクラブで聞く大きな音でしか得られない栄養素を感じますね。

さて、Crashlyticsには公式のアラート機能がありますが、Slack通知が1アプリにつき1チャンネルしか設定できないなど、カスタマイズ性に欠ける部分がありました。本記事ではFirebase MCPを活用してCrashlyticsのクラッシュデータを取得し、Slackに通知する仕組みを検証した結果を紹介します。

課題

Crashlyticsには公式のアラート機能があり、次の画像のように新しいクラッシュや増加傾向にある問題をメールやSlackに通知できます。

しかし、Slack通知は1アプリにつき1チャンネルしか設定できません。同じ内容を複数のチャンネルへ同時に通知できませんし、新規のクラッシュと非致命的な問題を別々のチャンネルに通知する、といった使い方もできません。

こうしたカスタマイズ性の課題があり、公式のアラート機能だけでは要件を満たせなかったため、Crashlyticsのコンソールを開いてデータを手動で確認する運用になっていました。しかし、手動確認では見る人によって判定の軸にブレが出たり、見落としが発生したりするリスクもあります。

そこで注目したのがFirebase MCPでした。

Firebase MCPとは

Firebase MCPは、2025年10月に正式リリースされた、AIアシスタントがFirebaseの各種機能にアクセスするためのModel Context Protocol（MCP）サーバーです。公式ページの手順で導入することで、Firebase CLIの認証情報を用いてAIが様々なツールを使えるようになります。

Firebase CLIにはCrashlyticsのデータを直接取得するコマンドはありませんが、このMCP経由であれば情報を取得できそうでした。ドキュメントには次のようなツールが記載されています。

ツール	説明
`crashlytics_get_top_issues`	イベント数でグループ化された上位の問題を取得
`crashlytics_get_issue`	特定のクラッシュの詳細データを取得
`crashlytics_list_events`	最近のクラッシュイベントをリスト化

これを活用すれば手動確認を自動化できると考え、検証することにしました。

検証

カスタムコマンドの設計

Claude Codeのカスタムコマンド機能を使い、「新規クラッシュ」と「増加傾向のクラッシュ」を取得してSlackに通知する仕組みを作成することにしました。処理の流れは次の通りです。

Firebase MCPでCrashlyticsのデータを取得
AIが取得したデータを抽出し整形
Slackに送信

新規クラッシュの検出は、次の画像のようにFirebaseコンソール上で「新しい問題」としてラベル付けされるものを抽出することにしました。MCPツールを使った場合、こうした問題にはSIGNAL_FRESHが返却値に含まれるため、それを条件としてコマンドを設計しました。

増加傾向のクラッシュは、公式のベロシティアラートの「最小ユーザ数」と「増加率」の設定を参考にしました。直近24時間と前日の24時間を比較し、100件以上のエラー、かつ前の区間から25%以上増加しているものを対象としました。

Slack通知の仕組みとしては、標準入力されたテキストをSlackへ送信するPythonスクリプトを作成し、AIから渡す形としました。こうすることでWebhook URLをAIに読み込ませない形としています。

import sys
import os
import json
import urllib.request

webhook_url = os.environ.get('SLACK_WEBHOOK_URL')
if not webhook_url:
    print("Error: SLACK_WEBHOOK_URLが設定されていません", file=sys.stderr)
    sys.exit(1)

message = sys.stdin.read()
if not message.strip():
    print("Error: メッセージが空です", file=sys.stderr)
    sys.exit(0)

req = urllib.request.Request(
    webhook_url,
    data=json.dumps({"text": message}).encode('utf-8'),
    headers={'Content-Type': 'application/json'}
)
urllib.request.urlopen(req)
print("メッセージ送信済み")

定義したカスタムコマンドは次の通りです。

iOSアプリのCrashlyticsデータを取得し、その結果を解析したいです。
そのため、現在時刻（例: 2025-12-08T15:30:00Z）を取得し、その時刻を基準として次のデータを取得する必要があります。
- SIGNAL_FRESHが付いているデータ
- 「現在時刻から24時間前まで」と「現在時刻の24時間前から48時間前まで」の間のデータの中で、前者のうち25%以上回数が増加しているデータ

この時、次の条件を守ってください。
- Firebase MCPで利用可能なツール一覧を読み取り、その中から適切なツール（例：`mcp__firebase__crashlytics_get_top_issues`）を使い、迂回手段は使わないこと。MCPが読み取れない場合報告し、処理を中断すること。
- FATAL、かつ発生回数が最低100件以上のクラッシュのみを抽出すること
- PageSizeは20件程度とすること

取得したら、結果を次のフォーマットを参考に `crashlytics_report.txt` に出力してください。

新規：0件
増加傾向：1件
- <[クラッシュ詳細へのURL]|[取得した問題の概要まとめ（15文字以内）]> [発生回数]

出力後、以下のコマンドを実行してください。
cat crashlytics_report.txt | python send_slack.py

動作確認

Claude Code上で/mcpコマンドを叩くことで、Firebase MCPが正常に動作するか確認できます。

実際にカスタムコマンドを実行すると、MCPツールを何度か呼び出してデータを取得していく様子が確認できます。

取得したデータが整形され、Slackに送信されました。なお、画像は閾値を意図的に下げて動作確認していたものになります。

結果

得られた知見

Firebase MCPを経由し、Crashlyticsのデータを整理して、Slackに通知する動作を確認できました。自然言語でコマンドを調整するだけでここまでできたので、かなり楽に実装ができました。信頼が置ける情報を扱えて、なおかつ将来的に必要な情報を気軽に追加しやすいのは大きなメリットだと感じました。

一方で、作っている途中、指示のブレが出ないようにカスタムコマンドの調整が必要でした。調整するまでは次のような思いがけない動作をすることがありました。

MCPツールを使わずにFirebase CLIの存在しないコマンドを使おうとする
現在時刻を取得せず適当な時刻でデータを取得しようとする
SlackのWebhook URLを勝手に読み込んで直接送信しようとする

LLMの持つ多彩すぎる柔軟性を制限するため、カスタムコマンドの指示をより明確にしていく作業が必要でした。今後も継続して安定性を見ていく必要がありますね。

今後の可能性

今回の検証はローカルでの手動実行までで、定期実行による自動化には至っていません。今後、Claude Code GitHub Actionsなどを用いて定期実行できれば、カスタマイズ性の課題を解消できそうです。引き続き検証を進めて導入していく予定です。

また、Firebase MCPではクラッシュのスタックトレースなども取得できます。これとGitHub MCPを組み合わせることで、クラッシュ原因の調査や自動修正まで発展させられる可能性があると感じました。実際、Firebase MCP × Claude Code Action で実現する Crashlytics エラーの自動修正ワークフローではこうした事例が紹介されています。

これにより、早期検知だけではなく早期修正までを一気に完了できる可能性があるため、次はこちらも検証していきたいと考えています。

まとめ

Firebase MCPを活用してCrashlyticsのクラッシュデータを取得し、Slackに通知する仕組みを検証しました。当初の「公式のアラート機能ではカスタマイズ性に欠ける」という課題を解決できそうな手応えを感じました。

また、この検証を通じて、カスタムコマンドを調整しなければ予想不可能な動きをするリスクを認知できました。さらに、早期検知だけでなく早期修正へ発展できる可能性も認識でき、良い経験になりました。

この記事が参考になりましたら幸いです。

最後になりますが、株式会社レコチョクでは新卒・中途採用を募集しています。興味のある方は、採用サイトをご覧ください。

明日のレコチョク Advent Calendar 2025 は24日目「非圧縮WAV音源を再生出来るWEBプレイヤーを実装してみた」です。お楽しみに！

RecoChoku Engineering Blog

目次