🚒

Crashlytics × n8n × GitHub Issue × ClaudeでクラッシュをAIに直してもらう

に公開

株式会社GENDA エンジニアの前原です。
本記事は GENDA Advent Calendar 2025 シリーズ1 Day 2 の記事です。
https://qiita.com/advent-calendar/2025/genda

Crashの修正を定常的に行うための仕組み作り

クラッシュの修正は、プロダクト品質を守るうえでとても大切ですよね。
先日 FlutterKaigi で「エラーを自動で直すフローを構築している」という話を聞き、わたしたちのプロジェクトでも実際に試してみることにしました。
発表資料はこちらです:
https://speakerdeck.com/ostk0069/flutterapuriyun-yong-noxian-chang-deyi-li-tutajian-shi-tips-5xuan?slide=14

Firebase Crashlytics はクラッシュの収集には優れていますが、
クラッシュ検知 → 調査 → GitHub Issue化/修正
といった周辺作業はどうしても手作業が多くなりがちです。

実際の修正フローでは、多くの開発者が Crashlytics にある
Message / Stacktrace / blame されたファイル名 などの一次情報を頼りに原因調査を始めますよね。
そしてその情報をもとに人間が考えて修正案を作り、PR を出し、レビューしてマージ…という流れになります。

もしこの一連の流れを、
AI が一次情報を読み取り → 修正方針を提案し → Issue 化し →(可能なら)PR まで繋げる
という形で自動化できたらどうでしょうか。

この記事では、第一歩として、
「最新バージョンで発生した致命的クラッシュを自動収集し、GitHub Issue を生成し、Claude に一次調査を任せる」
という自動化ワークフローを紹介します。

実際にやってみた

ここからは、実際に構築したワークフローを解説していきます。

ワークフローの概要

Firebase Crashlytics

プロダクトではFirebase Crashlytics を利用しており、まずは Crashlytics のデータを元にクラッシュ検知の自動化に挑戦しました。
しかし後述するように、Crashlytics からのデータ取得方法は限られており、一筋縄ではいきません。

BigQuery

Crashlytics の生データを扱うためのデータベースとして BigQuery を使用します。

Crashlytics のデータをアプリケーション側から直接取得する API は存在せず、BigQuery へのエクスポートが必須 です。

参考:
https://firebase.google.com/docs/crashlytics/bigquery-export?hl=ja#dataset-schema-crashlytics

BigQuery へのエクスポートには

  • リアルタイムエクスポート
  • 1日ごとのバッチエクスポート

の2種類があるため、用途(即時性 / 過去データ分析)に応じて選択すると良いでしょう。

n8n

n8n とは、さまざまなアプリケーションやサービスをノーコード / ローコードで連携させ、ワークフローを自動化できるオープンソースのツールです。
GUI 上で「ノード」と呼ばれる処理単位をドラッグ&ドロップでつなぎ合わせることで、専門知識がなくても複雑な業務プロセスを構築・自動化できます。

セルフホスティング可能な無料版と、運用が簡単なクラウド版があります。
https://n8n.io/

今回のワークフローでは、BigQuery からデータを取得し、それを加工して後続の処理につなげる用途で n8n を利用しています。

実際に本格的に使ってみて、

  • GUI で触りやすく、開発・テストもしやすい
  • 他のプロジェクトやリポジトリへの横展開もしやすい

といった印象でした。

また、公式ドキュメントが充実していて構築の際にとても役立ちました。
デフォルトで用意されているノードも豊富で、かなり多くのことがノーコードで実現できます。

ソートノードのドキュメント
もちろん、JavaScript (または Python) を書いて複雑なロジックを実装することも可能です。
「こういうことやりたいんだけどいいノード用意されてないかな」となったときに、ドキュメントにある「Chat with the docs」という機能を使うと、AI が的確なノードや実装方法を教えてくれます。

Credential

Google Cloud, GitHub, Slack などの Credential 設定が必要になりますが、ドキュメントに沿って進めれば簡単に設定できました。この手の Integration は何かと手こずったりする印象もあるのでありがたいです。
https://docs.n8n.io/integrations/builtin/credentials/google/oauth-single-service/
https://docs.n8n.io/integrations/builtin/app-nodes/n8n-nodes-base.github/
https://docs.n8n.io/integrations/builtin/credentials/slack/#related-resources

n8nワークフロー

以下は実際に構築したワークフローのスクリーンショットです。

サマリーは以下のとおりです。

  • BigQuery:Crashlytics のリアルタイムテーブルから最新クラッシュを抽出
  • GitHub:Issue の生成/更新
  • Slack:新規 Issue 通知
  • JavaScript:既存 Issue の登録判定、Markdown 書き換え処理など、既存ノードだけでは難しいロジック

少し詳しく処理を追っていきます。

1. BigQuery ノード:Crashlytics のクラッシュを抽出

今回は以下のような処理を行っています。

  • 最新の display_version に限定
  • FATAL のみ対象
  • 24時間以内に発生したクラッシュのみ抽出
  • blamed な exception(例外の原因)を特定
  • blamed のスタックトレース上位20件をテキスト化
  • 各 issue_id ごとに
    • クラッシュ数
    • 影響ユーザー数
    • 最新の発生時刻

この段階で、Issue 化に必要なデータが整った状態で次のノードに渡されます。

2. クラッシュ管理用 GitHub Issue を取得し登録済み判定を付与

1で取得した内容とIssue 取得ノードで取得した内容をマージしてCode ノードに渡し

以下のような Markdown ブロックを解析します。

<!-- BEGIN CRASHLYTICS REGISTERED -->
- `abcd123` → #42
- `efgh456` → #43
<!-- END CRASHLYTICS REGISTERED -->

このブロックから

  • Crashlytics issue_id
  • 対応する GitHub Issue 番号(#xx)

を抽出します。
BigQuery から来た issue_id と突き合わせて、
alreadyRegistered: true/false をデータに追加します。

3. 新規クラッシュだけを Issue 化する処理

● Sort(影響の大きい順)
IF ノードで alreadyRegistered = false のクラッシュのみ通し、
Sort ノードで impacted_users の降順にソートします。

● Limit(1件だけ)
Limit ノードで 1 件に絞り込み。(運用上、毎回 1 件ずつトリアージしています。)

● GitHub Issue ノード:Issue の自動生成
Issue タイトル例:
[Crashlytics] NullPointerException (v1.2.3)
本文には次の情報を自動生成して埋め込みます。

  • Version
  • Issue ID
  • Events (24h)
  • Impacted Users
  • blame された file:line
  • Crashlytics の該当ページへのリンク
  • 例外タイプとメッセージ
  • スタックトレースのスニペット(上位20フレーム)

4.クラッシュ登録ブロックを自動更新

● Issueの登録リストを自動更新するbuildUpdatedRegistryBody というCode ノード
処理内容:

  1. 元の body から既存のエントリ(issue_id → GitHub Issue 番号)をパース
  2. 今回新しく生成した Issue のエントリを追加
  3. Issue 番号の降順(新しい順)で並べ替え
  4. Markdown のリストを作成
  5. <!-- BEGIN --><!-- END --> の間を置換

生成されるブロック例:

<!-- BEGIN CRASHLYTICS REGISTERED -->
- `abcd123` → #50
  ↳ [Crashlytics](https://console.firebase.google.com/...)
- `efgh456` → #43
  ↳ [Crashlytics](https://console.firebase.google.com/...)
<!-- END CRASHLYTICS REGISTERED -->

Editノードでは、不要なfieldを削除しています。

5.Slack Notification

Slack ノードが Issue の概要を投稿し、チームに通知します。ワークフローの処理を分岐してシュッと処理を増やせるのがn8nの強みですね。

6.ClaudeCodeActionへの依頼コメントの自動投稿

GitHub コメントノードが作成したIssueでclaudeにメンションし、指示を行います。
ClaudeCodeActionが動き、Issue内容を読んで修正案を提案してくれます。
人間が見て良さそうであればそのまま修正まで行います。

n8nのTips

Codeノードでログを出して確認したい

console.log のログが、ブラウザの開発者モードのconsoleに表示されます

毎回実行せず、値だけ返したいノードがある

例えばワークフロー作成中に Create GitHub Issue が何回も実行されるのはIssueが増えて嬉しくないですよね。ノードの出力をピン留めする機能があるので、それを使うと毎回実行せずとも、ピン留めされた出力を次のノードに渡すことができます。

まとめ

本記事では、
Firebase Crashlytics × GitHub × n8n × Claude
を組み合わせた Crashlytics 自動管理ワークフローを紹介しました。

クラッシュ対応業務はつい後回しになってしまいがちですが、このような自動化により素早く・継続的に日々の業務フローに組み込んでいくことができるようになりました。

GENDA

Discussion