firebase-cli

firebase-cli — Firebase プラットフォーム運用担当

キーワード：firebase · firebase deploy · firebase init · firebase emulators

CLI を通じた Firebase プラットフォーム／プロジェクトの運用が中心となる場合に、このスキルを使用します。

このスキルを使用する場合

• firebase-tools をインストールまたは更新し、認証方法を選択して、CLI で対象プロジェクトを操作できることを確認する
• firebase init、.firebaserc、エイリアス、ターゲット、デプロイ対象を使って、リポジトリに Firebase の設定を初期化する
• ローカル開発、永続化、テスト実行のために Firebase Emulator Suite を実行する
• CLI を通じて Hosting、Functions、ルール、Remote Config、Extensions、App Hosting をデプロイまたは昇格する
• Firebase の操作に使用するプレビューチャネル、プロジェクトエイリアス、選択的なデプロイ、CI/CD 認証を管理する
• 認証のインポート／エクスポート、App Distribution、Remote Config のロールバック、拡張機能の管理など、Firebase の管理／データタスクを実行する

このスキルを使用しない場合

• 主な作業が、Firebase／Google AI 製品内でのバックエンド AI ワークフローのオーケストレーション、ツール、フロー、RAG、評価、オブザーバビリティである場合 → genkit を使用します
• 主な作業が、Gemini を活用したアプリ内機能のアプリ／クライアント SDK の直接的な統合である場合 → genkit（client-ai-logic モード）を使用します
• 主な作業が、Firebase CLI の実行ではなく、認証スタックの選択と製品の認証アーキテクチャである場合 → authentication-setup を使用します
• 主な作業が、Firebase CLI コマンドではなく、スキーマ／インデックスの設計である場合 → database-schema-design を使用します
• 主な作業が、Firebase 固有の運用コマンドではなく、プロバイダーをまたいだ汎用的なロールアウト戦略である場合 → deployment-automation を使用します

手順

ステップ 1：運用モードを選択する

まず、リクエストを次のいずれかのモードに振り分けます。

モード	使用する状況	主なサポート
インストール／認証	CLI がない、古い、または認証情報が原因で使用できない	scripts/install.sh、references/install-auth-and-bootstrap.md
初期化／設定	firebase init、エイリアス、ターゲット、リポジトリの設定構成が必要	references/install-auth-and-bootstrap.md
ローカルエミュレーター	ローカルの Firebase ランタイム、永続化、テストハーネスが必要	scripts/emulators.sh、references/emulator-and-release-workflows.md
デプロイ／リリース	対象を限定したデプロイ、プレビューチャネル、App Hosting のロールアウト、CI 実行が必要	scripts/deploy.sh、references/emulator-and-release-workflows.md
管理／データ運用	認証のインポート／エクスポート、Remote Config、App Distribution、Extensions、Data Connect のコマンドが必要	references/admin-and-data-operations.md
不明／複合的な作業	Firebase CLI の作業か、関連領域の作業か判断する必要がある	references/modes-and-routing.md

ステップ 2：変更を加える前に前提条件を確認する

1. CLI が存在することを確認し、バージョンを記録します：firebase --version
2. 現在の firebase-tools リリースに対応できるだけの新しいランタイムであることを確認します：
   • npm によるインストールには Node.js 20+ が必要です
   • スタンドアロンインストーラーは macOS/Linux のみで使用できます
3. 認証方法を確認します：
   • ローカルでの対話型作業 → firebase login
   • CI／非対話型作業 → GOOGLE_APPLICATION_CREDENTIALS によるサービスアカウント認証情報
4. デプロイやエミュレーターの作業を行う前に、プロジェクト設定を確認します：
   • firebase.json
   • .firebaserc
   • 対象固有のディレクトリ（functions/、Hosting の出力ディレクトリ、ルール／インデックスファイル）

ステップ 3：リクエストに答えるための最小限のワークフローを実行する

モード A — インストール／認証

• bash scripts/install.sh でインストールまたは更新します
• Node.js 20+ を使用できる場合は、npm でのインストールを推奨します：npm install -g firebase-tools
• ローカルでは firebase login を使ってブラウザー OAuth を使用します
• CI では、非推奨の --token／FIREBASE_TOKEN ではなく、サービスアカウントの認証情報を推奨します

モード B — 初期設定／構成

• すべてを無計画に有効化するのではなく、必要な対象を正確に指定して firebase init を使用します
• firebase use と firebase use --add でエイリアスを設定／確認します
• Hosting サイト、DB インスタンス、またはバケットが複数ある場合は、デプロイターゲットを使用します
• このリポジトリに含める Firebase の機能と、隣接するスキルに含める機能を記録します

モード C — ローカルエミュレーター

• ローカルデータを保持するには bash scripts/emulators.sh --persistent を使用します
• 1 回限りのテスト実行には firebase emulators:exec "<test command>" を使用します
• --only auth,firestore,functions を指定して、必要なエミュレーターだけを起動します
• エミュレーターの構成とシードデータの要件をリポジトリ内で明示します

モード D — デプロイ／リリース

• --only または --except を指定してデプロイ対象を絞ります
• 本番デプロイの前に、レビュー可能な Hosting の変更にはプレビューチャネルを優先します
• App Hosting では、バックエンドの作成／ロールアウトを一般的なウェブデプロイの簡易手段ではなく、オペレーターのワークフローとして扱います
• CI では --non-interactive と明示的な認証情報を使用します
• コマンドの終了コードだけで成功を判断せず、デプロイ後に変更内容を確認します

モード E — 管理／データ運用

• CLI を使用して、認証のインポート／エクスポート、Remote Config のバージョン管理／ロールバック、App Distribution、Extensions、および対象を絞ったクリーンアップタスクを実行します
• firestore:delete --recursive --force のような破壊的なコマンドは、明示的に扱います
• 大規模なジョブやインポートに影響するジョブでは、実行前にハッシュ／構成／バージョンの各パラメーターを正確に記録します

ステップ 4：作業の性質が変わったら、積極的に適切なスキルへ引き継ぎます

firebase-cli をオペレーター向けの軸として使用しつつ、作業の実態が以下に該当する場合は引き継ぎます。

• アプリ／クライアントの Gemini SDK 機能の組み込み → genkit（client-ai-logic モード）
• フロー／ツール／RAG／評価のオーケストレーション → genkit
• 認証モデルに関するプロダクト上の判断 → authentication-setup
• スキーマ／インデックスのモデリング → database-schema-design
• プロバイダーに依存しないロールアウト戦略 → deployment-automation

ステップ 5：結果を検証します

すべてのモードで、事実を最小限かつ正確に示す成果物を検証します。

• インストール／認証 → firebase --version、firebase login:list、または認証済みコマンドの正常な実行
• 初期設定／構成 → firebase.json、.firebaserc、ターゲットのマッピング
• エミュレーター → 起動中のポート、インポート／エクスポートしたデータディレクトリ、テストの正常な実行
• デプロイ／リリース → デプロイしたターゲットの一覧、プレビュー URL、またはデプロイ後のスモークテスト
• 管理／データ運用 → エクスポート／インポートしたファイル、バージョンのロールバック確認、テスター／グループの更新、または拡張機能のステータス

例

例 1：Firebase リポジトリを適切に初期設定する

Prompt: "Set up Firebase in this repo for Hosting + Functions + preview channels"

Mode:
- Bootstrap / config

Likely actions:
- bash scripts/install.sh
- firebase login
- firebase init hosting functions
- firebase use --add
- firebase target:apply ...   # if multi-site is needed

例 2：データを保持するローカルエミュレーターのワークフロー

Prompt: "Run auth + firestore emulators locally and keep the data between runs"

Mode:
- Local emulators

Likely actions:
- bash scripts/emulators.sh --only auth,firestore --persistent
- or firebase emulators:start --only auth,firestore --import ./emulator-data --export-on-exit

例 3：Firebase のリリース／プレビューフロー

Prompt: "Deploy Hosting to a reviewable staging channel, then ship production after approval"

Mode:
- Deploy / release

Likely actions:
- bash scripts/deploy.sh --channel staging --expires 7d
- firebase hosting:channel:open staging
- firebase deploy --only hosting

例 4：AI ワークフローの作業をこのスキルから適切なスキルへ引き継ぐ

Prompt: "Build a Firebase RAG flow with tools, evals, and observability"

Decision:
- Route to `genkit`
- Keep `firebase-cli` only for operator tasks like local setup or deploy wiring if needed

ベストプラクティス

1. コマンドを羅列するのではなく、ワークフローを選択します — まずモードを選び、その後でコマンドを選択します
2. CI ではサービスアカウントを使用します — --token／FIREBASE_TOKEN はデフォルトの方法ではなく、非推奨の代替手段として扱います
3. デプロイ対象を厳密に絞ります — --only とプレビューチャネルにより、意図しない影響範囲を抑えられます
4. リポジトリの構成を明示します — firebase.json、.firebaserc、ターゲットのマッピングは、リポジトリで実際にデプロイする対象と一致させます
5. エミュレーターの作業では、意図的にデータを保持します — インポート／エクスポート用のディレクトリにより、ローカルでのデバッグとテストを再現可能にできます
6. Firebase のオペレーター作業とアプリ／AI ロジックの作業を分離します — CLI が主な作業ではなくなったら、genkit（client-ai-logic モード）または genkit へ引き継ぎます
7. 破壊的な管理コマンドは高リスクとして扱います — 削除／ロールバック／インポート操作の前に、パス、バージョン、リソース ID を確認します

参考資料

• モードの選択とルート振り分け
• インストール、認証、ブートストラップガイド
• エミュレーターとリリースのワークフロー
• 管理とデータ操作
• コマンドの完全なリファレンス
• スクリプト — install.sh、deploy.sh、emulators.sh
• Firebase CLI リファレンス
• firebase-tools GitHub