はじめに こんにちは。開発本部でデリッシュキッチンの Android アプリ開発を担当している岡田です。 アプリを運用していると、リリースのたびに Crashlytics とにらめっこする時間が必ず発生します。クラッシュの一覧を眺めて、優先度を決めて、スタックトレースを読んで、該当コードを探して、原因を考えて、直す。やること自体は明確なのですが、ダッシュボードとエディタを行き来する手作業が地味に重く、件数が増えると後回しになりがちでした。 本記事では、公式の Firebase MCP サーバー が提供する Crashlytics ツールを Claude Code から使い、この一連の流れ（トリアージ → 原因分析 → 該当コード特定 → 修正 PR のドラフト作成）を半自動化した話を紹介します。特定の社内事例に依存しない、誰でも再現できる手順としてまとめました。Android / iOS で Crashlytics を使っていて、AI コーディングツールを業務に取り込みたい方の参考になればうれしいです。 目次 はじめに 背景：クラッシュ対応のどこが手間か Firebase Crashlytics MCP とは セットアップ 前提 Claude Code への MCP 登録 クラッシュ対応フロー：半自動化の中身 1. トリアージ：上位クラッシュを一覧する 2. 深掘り：スタックトレースと発生状況を取得 3. 突き合わせ：原因仮説と該当コードの特定 4. 修正と PR ドラフト作成 運用ノウハウ / つまづきポイント ツールは --only crashlytics で絞る CI / サービスアカウント認証では 404 に注意 プラットフォームによってツールが出ないことがある Experimental ゆえのバージョン固定 どこまで任せるか（“半” の線引き） まとめ 参考リンク 背景：クラッシュ対応のどこが手間か クラッシュ対応そのものは難しい作業ばかりではありません。むしろ「手間」の多くは、判断と判断のあいだにある移動コストでした。具体的には次のようなところです。 ツールの往復 ：Crashlytics（ブラウザ）でクラッシュを確認し、エディタに戻って該当箇所を探し、また Crashlytics に戻って影響範囲を見る、という往復が多い。 スタックトレースとコードの突き合わせ ：難読化されたスタックトレースから当たりをつけ、リポジトリの該当コードまで辿るのは、慣れていても地味に時間がかかる。 トリアージの属人性 ：「どのクラッシュから手を付けるか」の判断が、見る人によってブレる。影響端末・OS バージョン・発生数を毎回手で確認するのも面倒。 この「往復」と「突き合わせ」を AI に任せられれば、人間は 原因の判断と最終レビュー に集中できます。そこで MCP の出番です。 Firebase Crashlytics MCP とは MCP（Model Context Protocol） は、AI クライアントに外部ツールやデータソースを接続するための共通規格です。Firebase は公式に Firebase MCP サーバー を提供しており、その中に Crashlytics 用のツール群が含まれています。 このサーバーを AI クライアントに繋ぐと、ダッシュボードを開かなくても、AI との対話の中でクラッシュデータを取得・更新できるようになります。対応クライアントは Claude Code / Claude Desktop / Gemini CLI / Cursor / VS Code Copilot など幅広く、本記事では Claude Code を使います。 公式ドキュメント時点で提供されている主な Crashlytics ツールは以下のとおりです。 ツール名 役割 crashlytics_get_report 期間や条件を指定してクラッシュレポート（上位 issue など）を取得 crashlytics_get_issue 特定の issue の詳細を取得 crashlytics_list_events issue に紐づくイベント（スタックトレース等）を一覧取得 crashlytics_batch_get_events 複数イベントをまとめて取得 crashlytics_update_issue issue の状態（クローズ等）を更新 crashlytics_list_notes / crashlytics_create_note / crashlytics_delete_note issue へのメモの参照・追加・削除 加えて、 crashlytics:connect という対話的なガイド付きワークフローも用意されており、「どのクラッシュを優先すべきか」といった相談ベースの使い方もできます。Google I/O 2026 では、これらを束ねた Crashlytics の Agent Skills も発表され、IDE から離れずにデバッグ支援を受けられる方向に進んでいます。 ⚠ 注意 ：Crashlytics の MCP 機能は Experimental（実験的） です。SLA や非推奨ポリシーの対象外で、ツール名や挙動が変わる可能性があります。本記事の内容も執筆時点（2026 年 6 月）のものです。 セットアップ 前提 Node.js / npm（Firebase CLI のインストールに使用） Firebase CLI をインストールし、認証済みであること。Firebase MCP サーバーは Firebase CLI と同じ認証情報 を使います。未導入なら以下を実行します。 # Firebase CLI をインストール（未導入の場合） npm install -g firebase-tools # バージョン確認 firebase --version # ログイン（MCP サーバーはこの認証情報を使う） firebase login Claude Code への MCP 登録 インストール済みの Firebase CLI なら、MCP サーバーは次のコマンドで起動します。 firebase mcp --dir /path/to/your/project Claude Code には .mcp.json （プロジェクト直下）で登録するのが手軽です。クラッシュ対応用途であれば、後述の理由から --only crashlytics でツールを絞る のがおすすめです。 { "mcpServers": { "firebase": { "command": "firebase", "args": [ "mcp", "--only", "crashlytics", "--dir", "/path/to/your/project" ] } } } CLI から登録する場合は次の形でも同じことができます。 claude mcp add firebase -- firebase mcp --only crashlytics グローバルインストールを避けたい場合は、公式ドキュメントのとおり npx -y firebase-tools@latest mcp ... （ command を npx 、先頭の args に -y firebase-tools@latest ）でも起動できます。 登録後、Claude Code で /mcp を実行し、 firebase サーバーと crashlytics_* ツールが認識されていれば準備完了です。 クラッシュ対応フロー：半自動化の中身 ここからが本題です。Claude Code に自然言語で依頼するだけで、ツール呼び出し → 分析 → コード修正 → PR ドラフトまでを通しでやってもらいます。フロー全体は次のイメージです。 1. トリアージ：上位クラッシュを一覧する まずは「今いちばん効くクラッシュ」を洗い出します。 直近 7 日間で発生数が多いクラッシュを上位 5 件、影響ユーザー数と OS バージョン分布つきで一覧にして。優先度の高い順に並べて。 Claude は crashlytics_get_report を呼び、結果を表にまとめてくれます。発生数だけでなく影響ユーザー数や端末分布まで一度に並ぶので、「まず何から直すか」をその場で判断できます。 2. 深掘り：スタックトレースと発生状況を取得 優先度の高い issue を 1 件選び、詳細を取りに行きます。 1 件目の issue の詳細を取得して、代表的なスタックトレースと、発生している端末・OS・アプリバージョンの傾向を教えて。 ここでは crashlytics_get_issue と crashlytics_list_events （必要に応じて crashlytics_batch_get_events ）が呼ばれます。「特定 OS バージョンだけで起きている」「特定の画面遷移直後に多い」といった、原因の当たりをつけるための材料が揃います。 3. 突き合わせ：原因仮説と該当コードの特定 ここが手作業でいちばん面倒だった部分です。Claude Code はリポジトリのコードも読めるので、スタックトレースとソースを突き合わせてもらいます。 このスタックトレースに対応するコードをリポジトリから特定して、クラッシュの原因仮説を立てて。null 安全や lifecycle 周りの問題があれば指摘して。 スタックトレースの該当クラス・メソッドからソースの行まで辿り、「ここで nullable な値を !! で参照していて、特定条件で null になりうる」といった粒度で原因仮説を出してくれます。 4. 修正と PR ドラフト作成 原因に納得できたら、修正と PR まで一気に依頼します。 原因仮説に沿って修正案を作って。修正したらブランチを切って、変更内容と原因・対応を説明した PR をドラフトで作成して。 Claude Code がコードを修正し、 gh pr create --draft でドラフト PR まで作ってくれます。PR 本文には「どのクラッシュに対応したか」「原因」「修正内容」が整理された状態で入るので、レビュー依頼の手前まで一気に進みます。 運用ノウハウ / つまづきポイント 実際に動かすと、いくつか引っかかりやすい点があります。先に共有しておきます。 ツールは --only crashlytics で絞る Firebase MCP サーバーは Crashlytics 以外にも多くのツールを持っています。プロジェクトのデータ量が多いと、起動時のツール一覧取得（ tools/list ）でタイムアウトやメモリ不足が起きることが報告されています（ firebase-tools #9663 ）。クラッシュ対応に用途を絞るなら、最初から --only crashlytics を付けてツールを限定しておくのが安全です。動作も軽くなります。 CI / サービスアカウント認証では 404 に注意 ローカルの firebase login では問題なく動くのに、CI 環境でサービスアカウントや Workload Identity Federation（WIF）を使うと、 crashlytics_get_report が「HTTP 404, Method not found」で失敗するという報告があります（ #10310 / #10004 ）。同じ環境でも firebase login:ci で取得したトークンなら通る、という回避策が共有されています。CI に組み込む前提なら、認証方式の検証は早めにやっておくとよいです。 プラットフォームによってツールが出ないことがある 過去には iOS プロジェクトで Crashlytics ツールが認識されないケースも報告されています（ #9495 ）。ツールが見当たらないときは、 --dir で正しいプロジェクトを指していること、firebase-tools が最新であることをまず確認してください。 Experimental ゆえのバージョン固定 前述のとおり Crashlytics MCP は Experimental です。常に最新の firebase-tools を使っていると、ある日ツール名や引数が変わって手順が動かなくなる可能性があります。チームで共有するなら、 npm install -g firebase-tools@<version> のように firebase-tools のバージョンを固定して運用するほうが安定します。 どこまで任せるか（“半” の線引き） あくまで「半」自動化にとどめているのには理由があります。クラッシュの原因仮説は説得力があっても間違っていることがありますし、修正がほかの挙動に影響しないかの最終判断は人間の責任です。 今回の運用では、 Claude は提案者、人間は承認者 という役割分担を崩していません。PR をドラフトで作るところまでを AI に任せ、レビューとマージは必ず人が行います。トリアージと突き合わせという「重いけれど判断の少ない作業」を肩代わりしてもらい、人は判断に集中する——この線引きが、いまのところいちばん心地よく回っています。 まとめ 公式の Firebase MCP サーバーと Claude Code を組み合わせることで、クラッシュ対応のトリアージから原因分析、該当コードの特定、修正 PR ドラフト作成までを通しで半自動化できました。ダッシュボードとエディタの往復が減り、後回しにしがちだったクラッシュ対応の腰が軽くなったのが一番の効果です。 まだ Experimental な機能なので過信は禁物ですが、上位クラッシュの定期トリアージを仕組み化するなど、伸ばせる余地はまだまだありそうです。同じように Crashlytics 運用に手間を感じている方は、まず --only crashlytics で繋いでみるところから試してみてください。 最後まで読んでいただきありがとうございました！ 参考リンク firebase.google.com firebase.google.com firebase.blog firebase.blog modelcontextprotocol.io

フロントエンドもアーキテクチャに向き合う！ こんにちは！フロントエンドエンジニアの浅川です！ この記事では、社内向け管理画面（以降「社内システム」と呼びます）を段階的に整えながら、今の形へたどり着くまでの考え方を、時系列でまとめてみたいと思います。 この記事でまとめること 各レイヤーの責務と、ディレクトリ構造 「どこに何を置くか」の分割の目安 前提：社内システムの構成 まず、社内システムの技術スタックを簡単に紹介します。 フレームワーク: Vue 3 + Nuxt 4（SPA、SSR なし） バックエンド: Firebase（Firestore / Cloud St

こんにちは！「 SHIFTグループ技術ブログ 」編集部です。 お役立ち記事を発信していますので、ぜひご注目ください！！ 本ブログは、IT技術だけでなくSHIFTグループのあらゆる知見やノウハウを広義の“技術”とし、入社歴や部署の垣根を超えて従業員が公式ブロガーとして記事を執筆しています。