Firebase CLIとは｜firebase-tools 15系の認証とデプロイ運用【2026年8月時点】

Firebase CLI は npm パッケージ firebase-tools として配布されるコマンドラインツールで、2026年8月時点の最新版は 15.27.0 です。この記事では、CLI が受け持つ操作の範囲、4つある認証方式の優先順位と選び分け、firebase use による環境の切り替え、firebase deploy の部分デプロイ、CI環境で認証が通らないときの切り分け手順までを、公式リポジトリの記述と実際の不具合報告に沿って整理します。インストールから初回デプロイまでの一本道は別記事で扱うため、ここでは日々の運用で判断が要る部分に絞ります。

まとめ：CLIの守備範囲とCI認証をサービスアカウントへ寄せる判断

Firebase CLI は「ローカルの設定ファイルを正とし、それをプロジェクトへ反映する」ための道具です。逆に、課金プランの変更やIAMの権限付与といった契約・権限まわりはコンソールと Google Cloud 側に残ります。この境界を先に決めておくと、自動化の範囲で迷いません。

認証は4方式あり、優先度の降順で User Token・Local Login・サービスアカウント・Application Default Credentials（ADC）です。このうち firebase login:ci が発行する User Token は公式READMEで非推奨と明記され、将来のメジャーバージョンで削除が予告されています。CI に組み込むなら、いま新規に選ぶべきは GOOGLE_APPLICATION_CREDENTIALS を使うサービスアカウント方式です。

もう一点。CLI は Node.js 上で動くため、Node 側の不具合がそのまま認証失敗として現れます。2026年6月には Node.js 24.17.0 の回帰が原因で認証エラーが多発しました。CI では Node と firebase-tools の両方の版を固定してください。

firebase-toolsが受け持つ操作範囲とコンソール・SDKとの境界

Firebase を扱う入口は、コンソール（GUI）、各言語のSDK（アプリ内から呼ぶ）、CLI（開発機とCIから叩く）の3つです。CLI の役目は3つ目、プロジェクトの外側からの操作に限られます。

CLIが受け持つデプロイ・初期化・エミュレータ・管理の4系統

コマンドは大きく4系統に分かれます。プロジェクトを現在のディレクトリに紐づける firebase init、成果物を反映する firebase deploy、ローカルで各プロダクトを再現する firebase emulators:start、そしてプロジェクトやアカウントを扱う firebase projects:list や firebase use などの管理系です。

プロジェクト固有のコマンドを実行するには、有効なエイリアスが設定されたプロジェクトディレクトリ内にいるか、-P <project_id> フラグで対象を明示するかのどちらかが必要です。CIのように作業ディレクトリが毎回作り直される環境では、後者を明示したほうが事故が減ります。なお、ローカルエミュレータの構成やテストデータの入出力は範囲が広く、本記事ではコマンドの位置づけまでにとどめ、既定ポートや--importによるテストデータの持ち回り、CIへの組み込みはFirebase Local Emulator Suiteの構成とCI組み込みを整理した記事で扱います。

npmの大域インストールとfirebase.toolsのバイナリの選び分け

導入経路は2つあります。ひとつは npm install -g firebase-tools による大域インストール、もうひとつは curl -sL firebase.tools | bash で依存関係のない実行ファイルを取得するスタンドアロン方式です。

npm 方式は Node.js 環境の版に依存します。15.27.0 の engines 指定は >=20.0.0 || >=22.0.0 || >=24.0.0 で、これを満たさない環境ではインストール時点で弾かれます。Node.js を持たない端末や、Node の版を別プロジェクトに合わせて頻繁に切り替える端末では、スタンドアロン方式のほうが取り回しが楽です。

プロジェクト作成からSDK導入、初回デプロイまでを順に追う手順はFirebaseの導入手順を工程別に整理した記事で扱っています。

firebase –helpで版ごとのコマンド差分を自分で確かめる手順

Firebase CLI は更新が速く、記事や書籍のコマンド例が現行版と食い違います。手元の版で何ができるかは firebase --help でコマンド一覧を、firebase <command> --help で個別の説明とフラグを見るのが確実です。特にフラグは版によって増減し、検証だけを走らせる firebase deploy --dry-run は古い記事には登場しません。作業前に firebase --version と対象コマンドのヘルプを通せば、そこで差分が判明します。

認証4方式の優先順位とlogin:ci廃止予定を前提にした選び分け

CLI の認証で詰まる原因の多くは、方式が複数あり優先順位があると知らないまま設定を重ねる点にあります。公式READMEは4方式を降順で並べており、上位の資格情報が見つかった時点で下位は参照されません。

User Token・Local Login・サービスアカウント・ADCの優先順位

優先度の高い順に並べると次のとおりです。上の方式が設定されていると、下の方式は無視されます。

表の環境変数は GOOGLE_APPLICATION_CREDENTIALS、ADCのローカル認証コマンドは gcloud auth application-default login です。優先順位を知っていれば切り分けが一手で済みます。サービスアカウントを設定したのに別アカウントの権限でエラーが出るなら、シェルに FIREBASE_TOKEN が残っているか、ローカルのログイン情報が先に拾われています。

login:ciのトークンが非推奨になった理由と移行先の決め方

firebase login:ci は長期間有効なユーザートークンを発行するコマンドです。READMEはこれを「将来のメジャーバージョンで削除される非推奨の方式」と明記したうえで、「極めて機密性が高く長寿命の資格情報であり、多くの場合に適した選択ではない」と注意しています。実体は個人に紐づくリフレッシュトークンで、発行者のアカウントが停止されればCIも止まります。

移行先はサービスアカウントです。Google Cloud でサービスアカウントを作り、JSON鍵をCIのシークレットへ格納し、実行時に GOOGLE_APPLICATION_CREDENTIALS でパスを渡します。権限はFirebase管理者のような広い役割から始めず、デプロイ対象のプロダクトに必要な範囲へ絞ってください。GitHub Actions 側のワークフロー定義とシークレット設定は、FirebaseとGitHub Actionsを連携させた自動デプロイの設定手順で具体的に扱っています。

login:addとlogin:useで複数アカウントの誤爆を防ぐ設定

受託開発では、自社の検証プロジェクトと顧客から招待されたプロジェクトを同じ端末で行き来します。firebase login は既定で全プロジェクト共通の1アカウントを設定するため、そのままでは顧客案件の作業中に自社アカウントで叩いてしまいます。

これを避けるのが複数アカウント機能です。追加のアカウントを認可するには firebase login:add、認可済みの一覧は firebase login:list を使います。そのうえで特定のプロジェクトディレクトリで使う既定アカウントを固定しておけば、案件ごとにディレクトリを分ける運用と噛み合い、指定漏れが起きません。

firebase useと.firebasercで環境の取り違えを止める運用

Firebase は開発・ステージング・本番を別プロジェクトとして分けるのが基本構成です。分けた瞬間、どのプロジェクトへ向いているかを常に意識する必要が出てきます。ここを人の注意力に任せると、いずれ本番へ検証中のコードが飛びます。

firebase useのエイリアス登録と-Pフラグを使う境界

firebase use はアクティブなプロジェクトの設定とエイリアス管理を担うコマンドです。firebase use --add で対象プロジェクトに dev や prod といった別名を付けると、その対応が .firebaserc に書き出されます。以後は firebase use prod のように短い名前で切り替えられます。

使い分けの境界は単純です。人が手で叩く開発機ではエイリアス、機械が叩くCIでは -P <project_id> による明示です。CIは前回の状態を引き継がない前提で組むべきで、アクティブなプロジェクトに依存させると、ジョブの実行順で向き先が変わる不具合が入り込みます。

本番プロジェクトへの誤デプロイを止める–dry-runと権限分離

防波堤は2枚用意します。1枚目は firebase deploy --dry-run です。変更の検証とコードのビルドまでを行い、プロジェクトへは何も反映しません。ただし検証精度を上げるため対象プロジェクトのAPIを有効化する場合がある、と公式のフラグ説明に注記があります。副作用が皆無ではない点は押さえてください。

2枚目は権限の分離です。本番へのデプロイ権限をCIのサービスアカウントだけに持たせ、開発者の個人アカウントからは外します。エイリアスの付け替えという手作業に頼らず、権限側で不可能にするほうが確実です。

firebase deployの部分デプロイと事故を減らすフラグの使い分け

firebase deploy は firebase.json の設定とローカルのフォルダ構成を頼りに、コードとアセットを反映します。フラグなしの実行は設定に書かれたすべてを対象にするため、実務ではまず対象を絞る癖をつけます。

–onlyのターゲット指定とfunctionsのコロン記法の書き分け

--only はカンマ区切りでデプロイ対象を限定します。--only hosting,storage のようにプロダクト単位で指定するのが基本形です。Cloud Functions ではさらに絞り込めます。

• 関数単位：--only functions:func1,functions:func2
• エクスポートのグループ単位（ドット区切り）：--only functions:group1.subgroup1
• コードベース単位（コロン区切り）：--only functions:codebase1:func1

逆に、一部だけを除いて反映したいときは --except database という指定です。関数の本数が増えるほど全体デプロイは時間がかかるため、変更した関数だけを指定する運用に切り替えると待ち時間が縮みます。Cloud Functions のデプロイには Blaze プランが要る点は、Firebaseの料金体系と無料枠の範囲をまとめた記事で整理しています。

–dry-runで検証だけ回す挙動と–forceが削除する対象

フラグの中で扱いに注意が要るのが --force です。公式の説明は「現在の作業ディレクトリに存在しない Cloud Functions を削除し、対話的な確認プロンプトを省略する」となっています。つまり、ローカルにソースが揃っていない状態で --force を付けて実行すると、既存の関数が消えます。

CIでは対話プロンプトを避けるために付けたくなるフラグですが、チェックアウトが浅い、あるいはビルドが途中で失敗しているときに走ると被害が出ます。関数を含むプロジェクトでは、--force の前段でビルド成功を必須の条件として並べてください。

-mのデプロイメッセージとHostingのリリース履歴の追跡

-m（--message）はデプロイに任意の説明を添えるフラグです。firebase deploy --only hosting -m "$(git rev-parse --short HEAD)" のようにコミットハッシュを渡しておくと、コンソールのリリース一覧から「どのコミットが今出ているか」を辿れます。

この記録が効くのは障害対応のときです。Hosting はデプロイのたびにリリースが積まれ、以前のリリースへ戻せます。どこへ戻すべきかを判断する材料が、この一行です。Firebase Hostingのバージョンとリリースとチャネルの関係は別記事で扱っています。

CIでの認証失敗を切り分ける手順とNode 24.17.0回帰の実例

CLI の障害は Firebase の設定ミスに見えて、実際には土台の Node.js が原因という場合があります。2026年6月に起きた事例は、その典型でした。

WIF構成で出たFailed to authenticateの実際の原因

firebase-tools の issue #10726（2026年6月26日起票・クローズ済）では、GitHub Actions で Workload Identity Federation により認証したうえで firebase deploy を実行すると Error: Failed to authenticate, have you run firebase login? が出る、と報告されました。報告者の環境では認証情報のパス指定は正しく、gcloud auth print-access-token も成功し、同じジョブ内の他のGCP APIは同じ資格情報で通っていました。

--debug を付けて初めて、握り潰されていた本当のエラーが現れます。Invalid response body while trying to fetch https://sts.googleapis.com/v1/token: Premature close。STSのトークン交換だけが失敗していたわけです。認証情報の設定ではなく、HTTP通信の層で切れていました。

Node 24.18.0への引き上げと15.22.3以降での解消

原因は Node.js 24.17.0 の回帰でした。2026年6月のセキュリティ修正に伴う変更が影響したもので、Node.js 側の issue として追跡されています。Firebase 側のメンテナも同じ見立てを示し、解消方法として Node.js 24.18.0 へ上げるか、firebase-tools を 15.22.3 以降へ上げるかのいずれかを案内しました。報告スレッドでは、CI の Node を 24.18.0 に固定して解決したという返信が複数付いています。

この一件から引ける教訓は明確です。認証エラーのメッセージを額面どおりに受け取らないこと。「firebase login を実行しましたか」と言われても、原因が認証情報にあるとは限りません。メンテナ自身も、資格情報まわりのエラー表示とログをADCを意識した内容へ改善する作業は別途対応と述べており、2026年8月時点でメッセージの分かりにくさは残っています。

–debugを先に付けるCI運用とfirebase-toolsの版固定

踏まえた運用は2つです。まず、CIのデプロイジョブには最初から --debug を付けておきます。失敗してから付け直して再実行するより、一度で真因のスタックトレースが残るほうが早く終わります。

次に版の固定です。CI で npm install -g firebase-tools を版指定なしに走らせると、実行日によって別の版が入ります。[email protected] のように版を明記し、Node.js もセットアップのステップでパッチ版まで指定してください。上げるときは意図して上げ、リリースノートを見てから反映します。

受託開発でFirebase CLIに寄せる条件と手作業を残す場面の判断

外部の開発会社として案件に入る立場での線引きを示します。CLI に寄せるほど再現性は上がりますが、寄せてはいけない領域もあります。

CLIへ寄せてよい作業とコンソール側に残す権限設定の切り分け

CLI へ寄せてよいのは、成果物とその設定です。Hosting の配信内容、Cloud Functions のコード、Firestore と Storage のセキュリティルール、インデックス定義。これらは firebase.json と付随ファイルとしてリポジトリに入り、レビューを通り、同じ手順で何度でも反映できます。

逆にコンソールと Google Cloud に残すのは、課金プランの変更、IAM でのロール付与、サービスアカウント鍵の発行と失効です。これらは契約と責任の所在に直結し、承認の記録が要ります。CLI から一発で変えられる状態にしておくと、事故が起きたときに誰がいつ変えたのかを追えません。自動化の範囲は技術的な可否ではなく、承認が要るかどうかで切るという判断です。

内製化で引き継ぐ.firebasercとfirebase.jsonの管理

納品後に顧客側の担当者が運用を引き継ぐ場合、引き渡すべき実体は .firebaserc のエイリアス定義、firebase.json の各プロダクト設定、CIのワークフロー定義とシークレットの棚卸し表です。この3点が揃えば、担当者が代わっても同じ手順でデプロイできます。

逆に、開発中に個人アカウントで firebase login したまま手元から本番へ流していた案件は、引き継ぎ時点で認証経路の作り直しが必要です。一創では、こうしたFirebase運用の引き継ぎとCIの再構成を含むシステムの保守運用と内製化支援を承っています。既存プロジェクトの認証方式の棚卸しから入る相談も受け付けています。

よくある質問

Firebase CLI の導入と運用でつまずきやすい点をまとめます。

Firebase CLIとfirebase-toolsは別のものですか？

同じものです。npm 上のパッケージ名が firebase-tools、インストール後に叩くコマンド名が firebase で、両者を合わせて Firebase CLI と呼びます。なお、アプリ側から使うクライアントSDKのパッケージ名は firebase という別物なので、依存関係を書くときに取り違えないよう注意してください。

ブラウザを開けないサーバーでfirebase loginはどうしますか？

firebase login はブラウザでのGoogleサインインを前提とするため、GUIのないサーバーやコンテナ内では完了できません。従来この用途に使われた firebase login:ci は非推奨となり、将来のメジャーバージョンでの削除が予告されています。新規に組むなら、サービスアカウントのJSON鍵を配置し、GOOGLE_APPLICATION_CREDENTIALS にパスを設定する方式を選んでください。鍵はリポジトリに置かず、CIのシークレットから実行時に展開します。

firebase deployで一部だけ更新することはできますか？

できます。--only にプロダクト名をカンマ区切りで渡すと、その範囲だけが反映されます。firebase deploy --only hosting なら Hosting のみ、--only functions:sendMail なら該当の関数のみです。逆に --except での除外指定もできます。関数が数十本ある案件では全体デプロイのたびに数分待つため、変更した範囲だけを指定するほうが現実的です。

Firebase CLIのバージョンはどこまで上げるべきですか？

開発機は新しい版へ追随してよいですが、CIは版を固定してください。更新が頻繁で、新しい版が既存のワークフローと噛み合わなくなる場合があります。一方、古すぎる版に留まると既知の不具合の修正を受け取れません。2026年6月のCI認証障害も firebase-tools 15.22.3 で修正されています。四半期に一度など間隔を決め、リリースノートを見てから上げる運用が扱いやすいです。

CIでFIREBASE_TOKENを使い続けても問題ありませんか？

現時点では動作する状態ですが、公式に非推奨と表明されており、将来のメジャーバージョンで削除されます。このトークンは発行した個人のアカウントに紐づく長寿命の資格情報で、漏洩時の影響範囲が広く、発行者のアカウント停止でCIも止まります。優先順位の面でも注意が必要です。FIREBASE_TOKEN が環境に残っていると、サービスアカウントを設定してもそちらが先に使われます。移行時は古い環境変数を消すところまで行ってください。

関連記事

• Firebaseの導入手順：プロジェクト作成からSDK導入、初回デプロイまでの工程を順に追う記事です。CLIを入れる前段はこちらで扱います。
• FirebaseとGitHub Actionsの連携で実現する自動デプロイ：本記事で扱ったサービスアカウント認証を、実際のワークフロー定義に落とす手順です。
• Firebase Hostingとは：firebase deploy --only hosting の反映先となる配信の仕組みとリリース管理を解説しています。
• Firebaseの料金：Cloud Functions のデプロイに要るBlazeプランの条件と、無料枠の範囲をまとめています。
• Firebase Studioとは：ブラウザ上の開発環境から、CLIを使ってローカルへコードを引き上げる経路を扱っています。