Firebaseの導入手順｜プロジェクト作成からSDK導入と初回デプロイまで

Firebase の導入は、コンソールでプロジェクトを作り、アプリを登録し、SDK を初期化し、CLI からデプロイするという4工程で完了します。詰まるのは工程そのものではなく、版番号と設定ファイルの置き場所です。この記事では Web・iOS・Android の3プラットフォーム分の手順を、2026年8月17日時点の公式ドキュメントと npm レジストリの実測値つきで通します。古い入門記事を写経すると動かなくなる箇所も扱います。

まとめ：プロジェクト作成からSDK初期化とデプロイまでの4工程と実測版番号

• 工程は4つ。プロジェクト作成、プラットフォーム別のアプリ登録、SDK の初期化、Firebase CLI からのデプロイ。
• Firebase プロジェクトの実体は Google Cloud プロジェクトで、IAM 権限・課金・リソース階層を共有します。
• Web は npm install firebase で 12.17.1 を入れ、initializeApp を起動時に1回だけ呼びます。
• Android は BoM 34.17.0 と google-services 4.5.0、iOS は Swift Package Manager で firebase-ios-sdk 12.17.0。
• CLI は firebase-tools 15.27.0 で Node.js 20 以上が必要。firebase init が firebase.json を生成します。
• 予約URLの init.js はSDK v8以前限定で12.x系では動かず、環境分けはプロジェクト単位で行います。

導入前に押さえるFirebaseプロジェクトの単位と3種類の識別子の扱い

手を動かす前に決めるのは、プロジェクトをいくつ作るかと識別子の命名です。どちらも後から直せない部分を含みます。

Firebaseプロジェクトの実体がGoogle Cloudプロジェクトである構造

公式ドキュメントは、新しい Firebase プロジェクトを作成すると裏側では Google Cloud プロジェクトを作成していると説明しています。別サービスではなく、同じプロジェクトに Firebase 側の構成が有効化された状態です。

帰結は3つ。どちらのコンソールからも同じプロジェクトに触れること、IAM 権限・課金・リソース階層が共有されること、削除すると両方から消えること。すでに Google Cloud でインフラを組んでいる組織なら、新規作成ではなく既存プロジェクトへ Firebase を追加してください。権限設計と請求先が二重化しません。

プロジェクトIDとプロジェクト番号とアプリIDの変更可否の境界

識別子は3種類あり、役割も変更可否も異なります。混同したまま命名すると、直せない文字列が公開URLに残ります。

公式はプロジェクトIDを、Firebase と Google Cloud の全体で一意な識別子で公開リソースURLに現れると記載しています。デプロイ後のURLが PROJECT_ID.web.app の形になるため、社外に出るサービスならこの時点で公開名を確定させてください。

firebaseConfigが公開情報である前提とSecurity Rulesの役割

Web アプリ登録で受け取る firebaseConfig には apiKey が含まれます。ここで手が止まる担当者は多いのですが、公式は構成ファイルまたはオブジェクトの内容を公開情報とみなすと明記しています。クライアントに配布される前提の値です。

守る仕組みは別にあります。Realtime Database・Cloud Firestore・Cloud Storage へのアクセス制御は Firebase Security Rules が担い、APIキーの秘匿には依存しません。firebaseConfig を隠す工数より、Rules を書く時間を確保してください。サーバー側は逆で、サービスアカウントの秘密鍵は明確な機密です。クライアントSDKは Rules で制限され、Admin SDK は Rules を迂回する。権限モデルが逆になります。

コンソールでのプロジェクト作成とWeb・iOS・Androidのアプリ登録手順

ここまではコンソール上の操作だけで、コードは書きません。作成時に聞かれる Google Analytics の有効化は任意ですが、有効化前のイベントは遡れないため、計測要件が未確定でも有効にしておくほうが損は小さくなります。

Webアプリ登録で受け取るfirebaseConfigの各キーと保管場所の決め方

プロジェクト概要ページのウェブアイコンをクリックし、アプリのニックネームを入力して「Register app」を押します。ニックネームは社内の識別用で、利用者には表示されません。

Analytics を有効にしたプロジェクトでは measurementId も返ります。公開情報である以上ソース直書きでも成立しますが、環境ごとに値が変わるためビルド時の環境変数へ逃がすほうが運用は楽です。秘匿ではなく切り替えのために外へ出す、と整理してください。

バンドルIDとパッケージ名が登録後に変更できない制約への備え

iOS アプリの登録ではバンドルIDを入力します。公式は、この値が大文字と小文字を区別すること、Firebase プロジェクトに登録した後は変更できないことを明記しています。Android のパッケージ名も同じく同一性の基準です。

受託開発で踏みやすいのが、検証用に com.example.app.dev のような接尾辞つきIDで始めてから本番IDへ寄せようとする流れ。IDが違えば別アプリとして登録し直しになります。分ける方針なら、最初から2つのアプリとして登録してください。

Web向けSDK 12.x系のモジュラー構成とinitializeAppでの初期化

ここからコードです。Web の SDK は 2026年8月17日時点で npm レジストリ上の最新が 12.17.1 で、9系以降のモジュラーAPIが標準になっています。

firebase/appのinitializeAppで受け取るアプリインスタンス

導入は npm install firebase の1行です。パッケージ名は firebase 単体で、機能ごとに別パッケージを入れる必要はありません。

初期化は firebase/app から initializeApp をインポートし、コンソールで受け取った firebaseConfig を渡すだけ。戻り値のアプリインスタンスを、Firestore なら getFirestore、認証なら getAuth といった取得関数へ渡していきます。呼び出しは起動時に1回。コンポーネントごとに呼ぶ設計にすると、2回目以降が既定アプリの重複としてエラーになります。

モジュラーAPIのツリーシェイキングとcompat版を選ばない条件

公式ドキュメントは、Firebase SDK がモジュールバンドラと組み合わせて未使用コードを削る設計だと説明し、本番アプリではこの方式を強く推奨すると記載しています。Angular CLI・Next.js・Vue CLI・Create React App といったフレームワークのCLIは、この処理を自動で行います。

もう1つの選択肢が compat 版です。名前空間形式の旧APIを維持したまま新SDKへ載せ替えるための移行用で、新規導入で選ぶ理由はありません。compat のまま運用を続けると、ツリーシェイキングが効かずバンドルサイズが落ちない状態が固定されます。

予約URLのinit.jsがSDK v8以前に限られるという制限

ここが古い入門記事の写経で最も壊れる箇所です。Firebase Hosting は /__ 名前空間を予約しており、その配下の init.js を読み込むと稼働中のプロジェクトの設定値でSDKが自動構成されます。

ただし公式は、予約ホスティングURLがサポートするのは Firebase JavaScript SDK のバージョン8以前だけで、9以降は npm パッケージを使う必要があると明記しています。12.x系で init.js を script タグで貼っても機能しない。環境ごとの設定切り替えは、.firebaserc のエイリアスとビルド時の環境変数で行います。

AndroidのBoM 34.x系とiOSのSPM導入で分かれる設定ファイル配置

モバイルは Web と違い、設定ファイルを決まった場所へ物理的に置く工程が入ります。1階層間違えるだけでビルドが通りません。

google-services.jsonのapp直下配置とBoMとプラグインの版対応

Android の手順は次の順序で進みます。

1. コンソールで Android アプリを登録し、パッケージ名を入力する
2. 設定JSONをダウンロードし、モジュール（アプリレベル）のルートディレクトリへ移動する
3. ルートの build.gradle に google-services プラグインを宣言する
4. アプリレベルの build.gradle で BoM を導入し、使うライブラリを版指定なしで追加する

2026年8月17日時点の公式ドキュメントが示す版番号は、Firebase Android BoM が 34.17.0、com.google.gms:google-services プラグインが 4.5.0 です。BoM を挟むと各ライブラリに個別の版番号を書かずに済み、整合はBoM側が持ちます。個別指定とBoMを混在させると、BoMが解決した版が上書きされて不整合の原因になります。

GoogleService-Info.plistの配置とSwiftUIでの初期化の作法

iOS は Swift Package Manager で firebase-ios-sdk のリポジトリURLを追加します。版は既定の最新が推奨で、GitHub 上の最新リリースは 12.17.0（2026年7月28日公開）でした。設定plistは Xcode プロジェクトのルートへ移動し、プロンプトが出たら全ターゲットに追加します。

初期化は import FirebaseCore のうえで FirebaseApp.configure() を呼ぶだけで、UIKit なら AppDelegate の起動時処理に置きます。SwiftUI には一手間が要り、公式はアプリデリゲートを UIApplicationDelegateAdaptor 経由で App 構造体にアタッチし、swizzling を無効化する手順を示しました。この接続を省くと configure が呼ばれないまま起動します。

API 23とiOS 15とXcode 26.2という最低要件の充足確認

既存アプリへ後付けする場合、実作業より先に要件の引き上げが発生することがあります。2026年8月17日時点の公式記載は次のとおりです。

minSdk を 21 に据えたままの既存アプリでは、Firebase の導入自体より引き上げに伴う動作確認のほうが工数を食います。見積もり時に見落とすと、SDK導入は半日でも検証で数日かかる。着手前に現在値を確認してください。

Firebase CLIの導入からfirebase.json設定と初回デプロイまでの流れ

ホスティングを使わない案件でも、エミュレータとデプロイ管理のためにCLIは入れておく前提で構成します。検証環境をクラウドに作らず手元で再現する選択肢は、Firebase Local Emulator Suiteの構成とCI組み込みを整理した記事で扱っています。

npmの大域インストールとスタンドアロンバイナリの選び分けの基準

標準手順は npm install -g firebase-tools です。2026年8月17日時点の npm レジストリ上の firebase-tools は 15.27.0 で、engines フィールドは Node.js 20 以上（20系・22系・24系）を要求しています。Node 18 のまま止まっている開発機では、まずランタイムの更新が先に来ます。

Node を入れたくない環境向けにスタンドアロンバイナリも配布されています。macOS と Linux は curl -sL firebase.tools | bash、更新は upgrade フラグを付けて同じ形。開発機は npm、Node ランタイムを持たないCIコンテナはバイナリという基準で、両方入れると解決先が揺れます。導入後の認証方式の選定やプロジェクト切替を含む運用はFirebase CLIのコマンド体系とCI認証を整理した記事で扱っています。

firebase initが生成する4ファイルとSPAリライトの選択

firebase login を実行するとブラウザが開き、Google アカウントで認証します。続いて firebase init hosting を実行すると、接続する Firebase プロジェクトの選択、公開ルートディレクトリの指定（既定は public）、シングルページアプリのリライト構成という順で質問が並びます。

完了すると firebase.json、.firebaserc、public 配下の index.html と 404.html が生成されます。hosting セクションの主要キーは public、ignore、rewrites、redirects、headers。ignore の既定値は firebase.json 本体、ドット始まりの隠しファイル、node_modules 配下です。

SPA を選ぶと、rewrites に source を **、destination を /index.html とする1件が入ります。React Router や Vue Router では、この設定がないとリロード時に404になる。Vite や Next.js の出力を配信するなら public の値を dist 等へ書き換えます。

firebase deployのonlyフラグで払い出される2つのURL

デプロイは firebase deploy --only hosting です。only フラグを外すと firebase.json に定義された全プロダクトが対象になるため、Functions や Firestore Rules を巻き込みたくない初回は付けておくほうが安全です。

成功すると PROJECT_ID.web.app と PROJECT_ID.firebaseapp.com の2つのURLが払い出されます。どちらも追加費用なし、既定でSSL配信、グローバルCDN経由という条件。キャッシュ制御やリライトの詳細な設計はFirebase Hostingの配信構成とApp Hostingとの選定基準で扱っています。ブラウザだけで環境を組む経路として使われていたFirebase Studioは新規登録が停止済みのため、現時点の導入はローカル環境とCLIを前提に組みます。

dev/staging/prodの分離方針と受託開発でFirebaseを選ばない条件

手順どおり動かすところまでは誰がやっても同じで、案件の質が分かれるのは環境設計と採用可否の見極めにあります。

環境ごとにプロジェクトを分ける構成とビルドフレーバーの設定手順

結論を先に置きます。dev・staging・prod は Firebase プロジェクト単位で分けてください。1プロジェクト内でコレクション名に接頭辞を付けて回す構成は勧めません。Security Rules が全環境で共通になり、検証用の書き込みが本番の無料枠を消費し、請求の内訳も分離できないためです。課金の起点はFirebaseの無料枠とBlaze超過単価で整理しています。

設定ファイルの切り替えは、公式が推奨するビルド時の分岐に寄せます。Android はビルドフレーバーごとのディレクトリを app モジュールのルート配下に作り、それぞれに設定JSONを配置。Apple 側は Xcode のターゲットメンバーシップで切り替えるか、GoogleService-Info-Free.plist のように一意な名前を付けて読み分けます。CLI 側は .firebaserc のエイリアスで向き先が切り替わります。

Firebaseを選ばず別基盤へ寄せる3つの条件と判断の分かれ目

Firebase を採用しない条件を3つ、玉虫色にせず挙げます。

• 結合と集計が要件の中心にある案件。Cloud Firestore は結合を持たず非正規化と複数クエリで代替するため、基幹系の帳票要件と噛み合いません。
• データの所在地と監査要件が契約で縛られている案件。ロケーションはプロジェクト作成時に決まり、後から移せません。
• 読み取り回数が事前に読めない大量トラフィック案件。ドキュメント単位の従量課金は、一覧画面の設計次第で請求が跳ねます。

逆に採用条件も明確です。認証・プッシュ通知・ホスティングをまとめて短期に立ち上げる、クライアント主導の読み書きが中心、想定トラフィックが読める。この3つが揃うなら他の選択肢より速い。比較軸はSupabaseとFirebaseの料金と認証の違いに整理してあります。

導入時に踏みやすい既定アプリ限定のAnalytics計測と課金の見落とし

実装が終わってから気づく失敗パターンを2つ挙げます。どちらも手順書には出てきません。

1つ目が Analytics の計測範囲です。公式は、Android と Apple プラットフォームでは Analytics が既定アプリでのみログされると注記しています。1つのプロジェクトに iOS と Android の両アプリを登録し、両方の計測が取れると想定していると片側が欠測する。この制約を前提に設計してください。

2つ目が課金の発生源です。SDK の導入自体は無料でも、App Hosting のような一部の統合には Cloud Billing アカウントが必要になり、プロジェクトが従量課金の Blaze プランへ切り替わります。管理画面が無料表示のままでも、裏で従量課金が動く構造。請求アラートはプロジェクト作成の直後に設定してください。プッシュ通知を後から足す場合はFCMの仕組みと送信の実装が参照先です。導入から環境設計、iOS・Android 両対応のアプリ実装までまとめて任せたい場合は、スマホアプリ開発の受託としてご相談いただけます。

よくある質問

Firebase の導入手順について、実装現場で問い合わせの多い5点をまとめました。

Firebaseの導入に費用はかかりますか？

SDK の導入とプロジェクト作成そのものに費用はかかりません。無料枠の範囲で認証・Firestore・Hosting を動かせます。ただし App Hosting などの一部統合には Cloud Billing アカウントが必要で、紐づけた時点で従量課金の Blaze プランへ切り替わり、無料枠を超えた分が請求されます。コストは利用量にのみ連動する構造です。

firebase.jsonは手で書く必要がありますか？

手書きは不要です。firebase init を実行すると、質問への回答にもとづいて firebase.json が自動生成され、同時に .firebaserc と public 配下の初期ファイルも作られます。後から編集するのは、公開ディレクトリをビルド出力先へ変える場合と、rewrites や headers を足す場合です。

initializeAppはどこで呼べばよいですか？

アプリの起動時に1回だけ呼びます。Web ならエントリーポイントで firebaseConfig を渡して実行し、戻り値のインスタンスを各機能の取得関数へ渡す形。コンポーネントのマウントごとに呼ぶ設計にすると、既定アプリの重複でエラーになります。iOS は FirebaseApp.configure()、Android は google-services プラグインが初期化を担うため、明示的な呼び出しは基本的に不要です。

Firebase CLIのインストールでエラーが出る場合はどうしますか？

まず Node.js の版を確認してください。2026年8月17日時点の firebase-tools 15.27.0 は Node.js 20 以上を要求しており、18系以前では導入時点で失敗します。権限エラーで大域インストールが通らない環境では、Node を持たなくても動くスタンドアロンバイナリが選択肢になります。

iOSとAndroidのSDKは同じ手順で入りますか？

大枠は同じでも、依存管理と設定ファイルの置き場所が違います。Android は google-services 4.5.0 と BoM 34.17.0 を Gradle で入れ、設定JSONをアプリレベルのモジュールルートへ配置。iOS は Swift Package Manager で firebase-ios-sdk を追加し、設定plistをプロジェクトのルートへ置いて全ターゲットに追加します。最低要件も API 23 と iOS 15 で別々です。

関連記事

• Firebaseの料金｜無料枠とBlaze超過単価の実額：導入後に発生する課金の内訳を実額で確認できます
• Firebase Hostingとは｜静的とSPA配信の仕組みとApp Hostingとの選定基準：初回デプロイの先にある配信構成を扱っています
• Firebase Admin SDKとは？導入・初期化・ユーザー管理の使い方：サーバー側SDKの初期化と逆向きの権限モデルの解説です
• FCM（Firebase Cloud Messaging）とは｜プッシュ通知の仕組みと使い方：導入後にプッシュ通知を足す場合の実装手順です
• Firebase Studioとは｜2027年3月終了までの移行判断と引き上げ手順：ブラウザ完結の開発環境の終了経緯と移行先です