Firebase MCPサーバーとは｜ツール群の絞り込みと本番接続の判断【2026年8月時点】

Firebase MCPサーバーは独立した製品ではなく、Firebase CLI（firebase-tools）に同梱されたサブコマンドです。npx -y firebase-tools@latest mcp で立ち上がり、CursorやClaude CodeからFirestoreの読み書きやCrashlyticsのイベント取得をAIに任せられます。扱うのは、コア15本と11の機能グループというツールの内訳、クライアントごとに違う設定の書き方、--only とIAMロールによる権限の絞り込み、本番プロジェクトへ接続してよい条件。版番号と仕様は2026年8月時点の実測値です。

まとめ：開発用プロジェクトに限定し、onlyオプションで露出面を絞る

導入自体は10分で終わります。難所はどこまで触らせるかの線引きです。MCPサーバーはFirebase CLIと同じ認証情報で動くため、そのマシンで firebase login しているアカウントの権限がそのまま射程になる。個人アカウントのままの端末に繋げば、firebase_list_projects で全プロジェクトが見え、コアツールの firebase_create_project でプロジェクト作成まで通ります。

置くべき既定値は2つ。接続先を開発用・ステージング用に限ること、そして --only で機能グループを明示し、書き込みや送信を伴うグループを必要になるまで外すことです。この2つを外して本番へ繋ぐ構成は、承認の押し間違い1回でデータが消える距離にある。逆に読み取り専用のサービスアカウントでログ調査だけを任せるなら、監査ログが取れている組織では本番でも成立します。

Firebase CLIに同梱されたMCPサーバーという提供形態と起動の仕組み

押さえたいのは、Firebase専用に別途配布されるバイナリではない点です。

2025年5月の実験的公開からmcpサブコマンドへ移った提供の変遷

Firebase公式ブログでMCPサーバーが紹介されたのは2025年5月20日です。当時の記事には「The Firebase MCP Server is considered ‘experimental’.」と明記され、起動引数は experimental:mcp、ツール数は30以上。2026年8月現在の公式ドキュメントは mcp を案内し、実験的という記載も消えています。

厄介なのは、日本語の導入記事の多くが公開当時のまま experimental:mcp を載せていることで、設定をコピーするとサブコマンド名が古いまま貼り付きます。プロトコル側の仕組みはAIと外部ツールをつなぐ標準規格としてのMCPの解説にまとめました。公式ドキュメントも日本語版は最終更新が2026年3月30日で、8月13日更新の英語版とずれています。細部は英語版で確認してください。

npxでfirebase-tools 15系を起動するstdio接続の実行モデル

MCPクライアントはこのサブコマンドを子プロセスとして起動し、標準入出力（stdio）で通信します。HTTPサーバーを別途立てる必要はありません。npm registryを2026年8月18日に確認したところ、firebase-tools のlatestは 15.27.0、engines は Node.js 20 以上でした。

設定例に並ぶ firebase-tools@latest には副作用があります。起動のたびにバージョン解決が走るぶん立ち上がりが遅く、チーム内で人ごとに動く版が違う状態も生まれる。安定させたいなら [email protected] のように固定してください。firebase-tools 15系の認証とデプロイ運用をまとめた記事で扱う firebase login の状態が、そのままMCPサーバーの権限になります。

プロンプトとツールとリソースという3カテゴリで見た機能の内訳

MCPの仕様にはツール（呼び出す関数）、プロンプト（定型の指示）、リソース（読ませる資料）の3カテゴリがあり、Firebase MCPサーバーは3つをすべて提供します。プロンプトには firebase:init、firebase:deploy、firestore:generate_security_rules、crashlytics:connect などがあり、ルール記述を自然文から起こして firebase_validate_security_rules で検証する流れが一本で通る。クライアントが未対応だとツールしか見えないため、--generate-prompt-list で中身を確認してください。

機能グループ別に整理した提供ツール群とコアツールが担う守備範囲

ツールは「常に有効なコア」と「機能グループ単位で有効化するもの」の2層構造です。

常時有効なコアツール15本が担う認証とプロジェクト操作の守備範囲

公式ドキュメントが挙げるコアツールは15本です。

• 認証とプロジェクト：firebase_login、firebase_get_project、firebase_list_projects、firebase_create_project ほか
• アプリ登録：firebase_list_apps、firebase_create_app、firebase_get_sdk_config ほか
• 環境と初期化：firebase_get_environment、firebase_update_environment、firebase_init
• ルールと資料：firebase_get_security_rules、firebase_validate_security_rules、firebase_read_resources

目を引くのは firebase_create_project がここに入っている点です。--only をどう絞ってもプロジェクトの新規作成は封じられません。firebase_update_environment も同様で、会話の途中で対象プロジェクトや作業ディレクトリが切り替わる。「起動時に開発用を指定したから安全」という前提は成り立ちません。

firestoreとauthとstorageというデータ面の機能グループ

アプリのデータに直接届くのがこの3グループで、危険度はかなり違います。

firestore は読み取り系の firestore_query_collection だけでなく firestore_delete_database までを同じグループに抱えます。読み取りしか使わない場合でも、有効にした時点で削除系が選択肢に並ぶ設計です。auth は auth_get_users、auth_update_user ほか3本でカスタムクレーム付与も含む。storage は storage_get_object_download_url の1本のみで、削除や上書きの手段はありません。

crashlyticsとfunctionsなど運用面に寄る機能グループの用途

残る機能グループは運用フェーズで効きます。crashlytics が8本と最も厚く、crashlytics_list_events や crashlytics_get_report に crashlytics_update_issue とノート操作が加わる。クラッシュのスタックトレースをAIに読ませて原因を絞るのがこのグループの主戦場です。functions と apphosting は各2本で読み取りのみ、realtimedatabase は取得と書き込みの2本です。

dataconnect は dataconnect_build、dataconnect_list_services、dataconnect_execute の3本。2026年4月にSQL Connectへ改称したData Connectの実装判断のとおり製品名は変わりましたが、接頭辞は dataconnect_ のまま残っています。別扱いにしたいのは messaging と remoteconfig で、前者は実際の端末へ通知を飛ばし、後者は配信中のアプリの挙動を書き換える。どちらも利用者に直接届く操作です。

developerknowledgeが担う公式ドキュメント参照の別系統

性格が違うのが developerknowledge グループです。developerknowledge_search_documents など3本で、参照先はFirebaseの公式ドキュメント。利用者のプロジェクトには触れません。ここだけ有効にした構成には実用性があります。生成モデルは学習時点の仕様でコードを書くため、SQL Connectへの改称やFirebase Studioの終了といった直近の動きを知らず、古い書き方を出してくる。--only developerknowledge なら書き込みリスクをゼロにしたまま仕様の鮮度を引き上げられます。導入の第1段はこの構成から始め、必要な機能グループを足す進め方を勧めます。

MCPクライアント別の設定ファイル記述と起動確認までの導入手順

設定ファイルの場所とキー名がクライアントごとに違います。

Node.js 20以上とFirebase CLIのログインという前提条件

接続前に確認する項目は3つだけです。

1. Node.js が 20 以上か（firebase-tools 15.27.0 の engines 要件）
2. firebase login 済みか、ADCが設定済みか
3. 接続対象がどのプロジェクトか（開発用かを先に決める）

認証について公式ドキュメントは「Firebase CLI を認証するのと同じユーザー認証情報を使用します」と書いています。MCPサーバー専用の認証は存在しません。CLIをまだ触っていないなら、プロジェクト作成からSDK導入と初回デプロイまでの手順を先に通してください。

CursorとVS Code CopilotとClaude Codeの設定の差

同じサーバーを繋ぐのに、設定ファイルのパスとトップレベルのキー名が揃っていません。

VS Code Copilot だけキーが servers で、各エントリに type として stdio の指定も要ります。Cursorの例をそのまま貼って動かない場合、ほぼこの差が原因です。Claude Code は claude mcp add firebase npx -- -y firebase-tools@latest mcp の1行で登録できる。Antigravity、Gemini CLI、Cline、Windsurf も対応クライアントです。4行目のFirebase Studioは非推奨の表記が付き、2027年3月の終了までの移行判断をまとめた記事のとおり提供が終わるため、Studio前提の運用を新規に組むのは見送る局面です。

–dirでプロジェクトディレクトリを固定する場合としない場合

フラグは --dir と --only の2つだけ。--dir は firebase.json のあるディレクトリを絶対パスで渡し、そのプロジェクトを文脈として固定します。渡さなければ起動時のカレントディレクトリが使われ、代わりに get_project_directory と set_project_directory の2ツールが追加で生えてくる仕様です。

つまり省略すると、作業ディレクトリの切り替えがモデル側の判断に委ねられる。複数のFirebaseプロジェクトを1つのエディタで開いているときは事故の芽になります。設定ファイルをリポジトリ内へ置き、--dir を明示してください。

generate-tool-listで露出中のツールを数え上げる確認手順

--only を省いたときに何が有効になるのか、公式ドキュメントの記述は版によって食い違います。英語版は機能グループを「--only で公開するもの」と説明し、日本語版は「使用している機能のみに制限できます」と書く。既定の露出範囲は明示されていません。

推測で埋めず npx firebase-tools@latest mcp --generate-tool-list を叩いてください。露出中のツール名が出るので、--only の有無で差分を取れば効き方が確定します。この一手間で「絞ったつもりで firestore_delete_database が生きていた」を避けられます。

onlyオプションとIAMロールで組む破壊的ツールの二段構えの権限設計

権限は、ツールを見せるかと実行主体に何ができるかの2層で決まります。

–onlyで露出面を絞り込む第一段の防御と機能グループの選び方

第一段は --only firestore,developerknowledge のように使うグループを明示することです。書かなかったグループのツールは選択肢に現れず、誤った呼び出しが構造的に起きなくなる。基準は「そのセッションで実際に触る対象か」の一点。Firestoreの構造を相談したいだけの場面で messaging を有効にする理由はありません。

他社製サーバーも同じ設計で、Terraform MCP Serverのtoolset単位の権限設計やBigQuery MCPサーバーの6ツールの権限分離は露出面の限定を前提に組まれています。全グループを有効にするとツールは50本を超え、定義がリクエストごとに送られるぶんトークン消費と選択精度にも響く。露出は5本から15本に収めてください。ただしコア15本は対象外で、firebase_create_project が残る以上、第一段だけを防御と見なすのは無理があります。

実行アカウント側のIAMロールで縛る第二段の防御と権限の絞り方

第二段は認証主体そのものを弱くすることです。ツールを絞っても、認証しているアカウントがオーナー権限を持っていれば権限は残ります。手当てはApplication Default Credentialsを目的別のサービスアカウントへ差し替え、最小限のIAMロールだけを付けること。こうすればモデルが削除ツールを呼んでもAPI側が権限エラーで弾く。ツール定義の制限は行儀の問題、IAMは強制力の問題という切り分けです。

避けたいのは、開発者個人のGoogleアカウントでログインしたままのCLIを繋ぐ構成。firebase_list_projects は参照できるプロジェクトをすべて返すため、担当外の顧客プロジェクトまで会話の射程に入ります。受託開発で複数社を扱うなら取らない構成です。

削除系と更新系のツールが混ざる機能グループの危険度と切り分け方

危険度の高いツールを名指ししておきます。firestore_delete_database、firestore_delete_document、realtimedatabase_set_data、auth_update_user、remoteconfig_update_template、messaging_send_message。実行された時点で元に戻せないか、戻すのに相応の手間がかかります。

MCPクライアントの承認ダイアログを最後の砦にする発想は勧めません。長い作業を任せているとき、人は承認を連打します。10回目の承認が firestore_delete_document だったと気づくのは消えたあとです。読み取りだけに落としたいなら機能グループ単位では実現できず、担保する手段はIAM側にしかない。App Checkのプロバイダ選定と強制への移行のような仕組みでも、管理者側の経路を通るMCPサーバーには判定が入りません。

本番プロジェクトへ接続してよい条件と接続を見送るべき具体的な場面

ここが判断の本体です。条件を切って結論を書きます。

開発用とステージング用のプロジェクトに限定して接続する運用の型

既定はこれです。Firebaseはプロジェクト単位で環境を分ける設計で、開発用を別に持つ現場が大半でしょう。接続先をそこへ固定し、本番の認証情報を同じマシンに置かない。これだけで想定される事故の大半は起きなくなります。

もう一歩踏み込むなら、接続先をローカルのエミュレータに向ける手があります。ローカル再現の構成とCI組み込みをまとめた記事で扱うLocal Emulator Suiteを起動しておけば、クラウド側のデータには届きません。スキーマ設計やルールの試行錯誤をAIに任せる用途なら、この構成で十分に回る。Firebase前提のバックエンド設計や生成AIを組み込む体制の相談先を探しているなら、生成AI開発・AI受託開発の相談窓口で構成の妥当性から詰められます。

本番プロジェクトへの接続を見送るべき構成と起きやすい権限事故の型

次の3条件のうち1つでも当てはまるなら、本番プロジェクトへは繋がないでください。

• 個人のGoogleアカウントでCLIにログインしている
• IAMで権限を落としていない（--only だけでは削除を止められない）
• messaging または remoteconfig を有効にしている

典型的な失敗の形も挙げます。「テスト用に入れたデータを消して」の一文が、条件の解釈違いでコレクション全体の削除に化けるパターン。Remote Configの更新で既存パラメータごと上書きされ、配信中のアプリの挙動が変わるパターン。どちらもモデルの誤動作というより、権限を渡しすぎた構成の問題です。

監査ログとレビュー体制が揃った組織にだけ認める例外的な接続条件

例外を1つだけ認めます。本番の障害調査に読み取り専用で繋ぐ用途です。crashlytics_list_events で実イベントを取り、functions_get_logs で該当時刻のログを引き当てて原因の当たりをつける。本番データでなければ意味がありません。

条件は3つ揃うこと。読み取り権限しか持たないサービスアカウントで動かす、--only crashlytics,functions のように書き込み系を外す、監査ログで誰がいつ何を読んだか追える。1つでも欠けるなら、追跡不能な操作経路を1本増やすだけです。揃わない組織は、本番データを開発用プロジェクトへ流して調べる遠回りを選んでください。

よくある質問

導入検討で問い合わせの多い5点です。

Firebase MCPサーバーの利用に追加費用はかかりますか？

MCPサーバー自体はFirebase CLIに同梱された機能で、起動への課金はありません。ただしツール経由で呼ぶ先はFirebaseの各サービスなので、Firestoreの読み取り件数などの従量課金は発生します。AIエージェントに探索的なクエリを繰り返させると件数が伸びやすく、無料枠の開発用プロジェクトでも消費量に目を配ってください。

設定は experimental:mcp と mcp のどちらで書くべきですか？

2026年8月時点の公式ドキュメントは mcp を案内しています。experimental:mcp は2025年5月の公開当初の書き方で、Web上の解説記事にはこの形が数多く残る。新規に設定するなら mcp を使ってください。古い記述のまま動いている環境も、firebase-tools を更新したうえで書き換えておくと以降のバージョンで動かなくなるリスクを避けられます。

–only を省略するとすべてのツールが有効になりますか？

公式ドキュメントは既定の露出範囲を明示しておらず、英語版と日本語版で書きぶりも揃っていません。確実なのは、コアツール15本が指定に関わらず常に有効だという点だけ。実際の露出は npx firebase-tools@latest mcp --generate-tool-list で一覧化して確認し、使う機能グループは省略せず明示的に指定してください。

セキュリティルールはMCPサーバー経由の操作にも適用されますか？

適用されません。FirestoreやCloud Storageのセキュリティルールは、クライアントSDKからのアクセスを判定する仕組みです。MCPサーバーはFirebase CLIと同じ認証情報を使う管理者側の経路で動くため、ルールの記述内容に関わらず読み書きが通る。操作を制限したいなら、実行しているアカウントのIAMロールを絞ってください。

Firebase Studio上で使う設定は今後も使えますか？

Firebase Studio はプロジェクト内の設定ファイルにMCPサーバーを記述する方式へ対応していますが、公式ドキュメントで非推奨の表記が付き、2027年3月に提供が終了します。新しく開発環境を組むなら、CursorやVS Code Copilot、Claude Codeなど継続提供されるクライアント側に設定を置いてください。既にStudioで運用しているなら、終了時期から逆算して移行先を決める段階です。

関連記事

• Firebaseの導入手順：接続の前提になるプロジェクト作成とCLI認証です。
• Firebaseの料金：ツール経由の読み取りが積み上がる先の無料枠です。
• GitHub MCPサーバーとは：toolset単位で権限を切る同型の設計例です。
• Figma MCPサーバーとは：対応クライアントと料金体系の比較の参照先です。
• Firebase AI Logicとは：生成AIをFirebase側へ組み込む構成の違いです。