Firebase MCPサーバーの使い方 — Firestore・Authを自然言語で操作する
Firebase公式MCPサーバーの導入手順と、FirestoreやAuthをClaude Codeから安全に操作するための権限設計を解説します。
Firebase MCPサーバーとは何か
Firebase MCPサーバーは、Firebaseプロジェクトの操作をAIアシスタントに任せるためのGoogle公式MCPサーバーです。Firebase CLI(firebase-tools)に同梱されており、追加インストールなしでnpx firebase-tools@latest mcpから起動できます。
対応クライアントはClaude Code・Claude Desktop・Cursor・VS Code Copilot・Windsurf・Cline・Firebase Studio(2027年3月22日にsunset予定、2026年6月22日以降は新規ワークスペース作成・新規サインアップを停止済み)・Antigravityと幅広く、認証はいずれもFirebase CLIと同じ資格情報(ログイン済みユーザーまたはApplication Default Credentials)を使い回します。Firestore・Authentication・Cloud Storage・Crashlytics・Cloud Messaging・Remote Config・App Hostingという、Firebaseの主要プロダクトをほぼ横断してカバーしている点が最大の特徴です。
Claude Codeへの接続方法
Claude Codeでの導入は2通りあり、公式ドキュメントはプラグイン経由を推奨しています。手動設定より権限管理が明示的になるためです。
claude plugin marketplace add firebase/firebase-tools
claude plugin install firebase@firebase
claude plugin marketplace list手動で追加する場合は、次の1行でMCPサーバーが登録されます。
claude mcp add firebase npx -- -y firebase-tools@latest mcp
claude mcp listclaude mcp listの出力にfirebase: npx -y firebase-tools@latest mcp - ✓ Connectedと表示されれば接続完了です。Claude Desktopの場合はclaude_desktop_config.json(Claude>設定>Developerタブ>Edit Configから開く)に同じcommand/argsを書き込みます。
使えるツールの分類
Firebase MCPサーバーはツールをFeature Groupという単位で分類しています。Prompts(定型タスクのスラッシュコマンド)・Tools(LLMが自動呼び出しする操作)・Resources(公式ドキュメントの読み込み)の3種で構成され、coreグループの一部ツールは常に有効です。
| Feature Group | できること |
|---|---|
| core | できることプロジェクト管理・ログイン状態確認・セキュリティルール検証 |
| firestore | できることドキュメントの取得・クエリー・削除、コレクション一覧 |
| auth | できることユーザー検索・有効化無効化・SMSリージョンポリシー設定 |
| storage | できることオブジェクトのダウンロードURL取得 |
| crashlytics | できることクラッシュレポート取得・issueのノート追加・状態更新 |
| dataconnect | できることFirebase SQL Connectのスキーマ検証・GraphQLクエリー実行 |
| messaging / remoteconfig / apphosting | できることプッシュ通知送信・Remote Config更新・App Hostingログ取得 |
各グループの正確なツール名はnpx firebase-tools@latest mcp --generate-tool-listで自分の環境から直接確認できます。バージョンによってツールが増減するため、記事の一覧ではなくこのコマンドの出力を正とするのが安全です。同じ調子でプロンプト一覧もnpx firebase-tools@latest mcp --generate-prompt-listで確認できます。
Firebase以外のGoogleサービスをMCP経由でClaudeに繋ぐ手段もあり、Google Workspace側ならGoogle Drive MCPサーバー、Google Cloud側ならGoogle公式のBigQuery連携がそれぞれ別のMCP実装として存在します。Firebaseプロジェクトの裏側でBigQueryにイベントデータをエクスポートしている構成では、両方を併用して分析まで一気通貫でClaudeに任せる使い方もできます。
公開範囲を絞る --dir と --only
デフォルトではcore以外の全グループが有効になり、Claudeから見える操作の範囲が広くなりすぎがちです。これを絞る手段が--dirと--onlyの2つの起動オプションです。
--dir ABSOLUTE_DIR_PATH:firebase.jsonがあるディレクトリを指定し、MCPサーバーのプロジェクトコンテキストを固定する--only FEATURE_1,FEATURE_2: 有効にするFeature Groupをカンマ区切りで指定する(coreは常に有効)
npx firebase-tools@latest mcp --dir /Users/turing/my-project --only auth,firestore,storage--dirを指定しなかった場合は、get_project_directoryとset_project_directoryという2つのツールが自動的に有効になり、Claudeが対話の途中でプロジェクトディレクトリを切り替えられるようになります。複数のFirebaseプロジェクトを1つのMCP接続で行き来する運用では便利ですが、意図しないプロジェクトへの誤操作を避けたいなら--dirで固定してこの2ツール自体を無効化する方が安全です。同様にfirebase_get_environmentは現在アクティブなプロジェクトと認証ユーザーを確認するツールで、操作前に対象を取り違えていないか確認する用途に使えます。
Firestoreとユーザー管理を自然言語で操作する
セットアップ後は、コマンドを覚えなくても自然文の指示でFirebaseを操作できます。「usersコレクションのうち、statusがpendingのドキュメントを一覧して」と頼めばfirestore_query_collectionが呼ばれ、フィルタ付きでドキュメントが返ります。特定ユーザーのアカウントを無効化したいときは「メールアドレスx@example.comのユーザーを無効化して」と伝えるだけでauth_update_userが実行されます。
セキュリティルールの検証も定型プロンプトで扱えます。/firestore:generate_security_rulesを実行すると、現在のFirestoreデータ構造を踏まえたルール案とユニットテストが生成されます。生成された内容は必ず自分で読んでからfirebase_validate_security_rulesツールで構文チェックし、デプロイ前にレビューします。
Crashlyticsの障害調査に使う
Crashlyticsのfeature groupは、クラッシュ調査のワークフローをそのままツール化しています。「アプリで直近発生している未解決のissueを重大度順に見せて」と聞けばcrashlytics_get_reportで集計が返り、個別issueの詳細はcrashlytics_get_issueとcrashlytics_list_eventsで追えます。調査メモはcrashlytics_create_noteでissueに残せるため、原因調査の経過をClaudeとのやり取りの外にも残せます。
Realtime DatabaseとRemote Configも同じ流れで操作する
FirestoreだけでなくRealtime Databaseにも直接読み書きするツールがあります。「/status/onlineパスの値を取得して」と聞けばrealtimedatabase_get_dataが呼ばれ、「メンテナンスモードのフラグをtrueにして」と伝えるとrealtimedatabase_set_dataが該当パスにJSONを書き込みます。パス単位の操作なので、書き込み先を具体的に指定するほど誤操作のリスクが下がります。
Remote Configの操作も同様です。remoteconfig_get_templateで現在配信中のテンプレートを取得し、remoteconfig_update_templateで新しいテンプレートを公開するか、過去のバージョンにロールバックできます。App Hostingのバックエンド一覧やビルドログもapphosting_list_backends・apphosting_fetch_logsで参照可能で、デプロイ後の動作確認をClaudeに任せられます。
組織で使うときの権限管理
複数人の開発チームでFirebase MCPを導入する場合、個々の開発者が--onlyをどう設定するかはローカル任せになりがちです。Claude Code側で組織全体のMCPサーバー利用に制約をかけたい場合は、Managed MCPの許可リストで接続できるMCPサーバー自体を制限する構成と組み合わせると、Firebase MCP側の--only設定に頼りきらない二重の防御線になります。
SupabaseのMCPサーバーとの違い
Firebase MCPとSupabase MCPは、どちらも「バックエンドのフルマネージドサービスをAIアシスタントから操作する」という位置づけは同じですが、認証方式と権限の絞り方に明確な違いがあります。
| 観点 | Firebase MCP | Supabase MCP |
|---|---|---|
| データモデル | Firebase MCPFirestore(NoSQL)+ Realtime Database | Supabase MCPPostgreSQL(SQLリレーショナル) |
| 接続方式 | Firebase MCPローカルstdio(npxで起動) | Supabase MCPリモートHTTP(mcp.supabase.com)+ OAuth |
| 読み取り専用モード | Firebase MCP明示フラグなし(--onlyはグループ単位の絞り込み) | Supabase MCPread_only=trueで書き込み系ツールを除外 |
| 認証情報 | Firebase MCPFirebase CLIの資格情報を継承 | Supabase MCPブラウザ経由のOAuthでSupabaseアカウントに紐づく |
Firestoreを使うか、Postgresベースのバックエンドを使うかでどちらのMCPサーバーが候補になるかは決まりますが、権限設計の考え方は異なります。Firebase MCPには「読み取り専用」を宣言する単一フラグが無いため、書き込み系ツールを外すには--onlyでグループごと無効化する必要があります。
導入でつまずきやすいポイント
--onlyはグループ単位の絞り込みであって、読み取り専用化ではありません。firestoreグループを有効にするとfirestore_delete_documentも一緒に有効になります。本番データに接続する構成では、削除や更新を含むグループを常時有効にしないことが実質的な安全策になります。
Gemini in Firebaseを使う一部のツール(スキーマ生成やコンサルト系)は、公式ドキュメントが「もっともらしいが事実と異なる出力をすることがある」と明記しています。生成されたコードやスキーマを未検証のまま本番へ投入しないという注意書きは、Firebase MCP固有の落とし穴として押さえておく価値があります。
認証エラーが出た場合は、まずfirebase_loginツールでログイン状態を確認します。CI環境などブラウザ認証ができない場面では、Firebase CLI側でApplication Default Credentialsを事前に設定しておく必要があり、MCPサーバー単体では認証フローを完結できません。
まとめ
Firebase MCPサーバーは、FirestoreからCrashlyticsまでFirebaseの主要プロダクトを1つのMCP接続でカバーする公式ツールです。Claude Codeへはプラグイン経由の導入が推奨され、--dirと--onlyで公開範囲を絞るのが実運用の起点になります。読み取り専用の宣言フラグが無い点はSupabase MCPとの明確な違いなので、本番プロジェクトに接続する前に有効化するfeature groupを最小限に絞ることが安全な使い方です。
よくある質問
Firebase MCPサーバーとFirebase agent skillsは何が違うか
Firebase MCPサーバーはツール実行の窓口で、Firebase agent skillsは「AuthenticationやFirestoreをどう設定すべきか」という手順知識をAIに与えるものです。公式ドキュメントは両方を併用し、/firebase:initのような定型プロンプトの実行精度をagent skillsで底上げする構成を推奨しています。
Firebase Studioでも同じMCPサーバーを使えるか
既存ワークスペースであれば使えます。設定ファイルの場所が.idx/mcp.jsonになる点以外は、Claude Code向けの設定と同じcommand/args(npx -y firebase-tools@latest mcp)で動作します。ただしFirebase Studio自体は2027年3月22日にsunset予定で、2026年6月22日以降は新規ワークスペース作成・新規サインアップが停止済みです。これから新規に使い始めることはできないため、既存ワークスペースの移行期間中の利用に限られます。