Firebase Extensions の非推奨に関するよくある質問

Firebase Extensions を非推奨にする理由

基盤となる Google Cloud インフラストラクチャの今後の変更と非推奨により、マネージド Firebase Extensions サービスは廃止されます。

2027 年 3 月 31 日以降、デプロイ済みの既存の拡張機能は動作しなくなりますか？

いいえ。すでにデプロイされている拡張機能は、標準の Google Cloud インフラストラクチャ（Cloud Functions、Eventarc、Cloud Run、Cloud Tasks など）で直接実行され、無期限に実行が継続されます。

ただし、2027 年 3 月 31 日以降は、Firebase コンソールまたは CLI を介してこれらの拡張機能を更新、再構成、アンインストールできなくなります。また、関数キットへの移行に役立つ既存の拡張機能構成をダウンロードすることもできなくなります。2027 年 3 月 31 日までに拡張機能の構成を移行またはエクスポートすることを強くおすすめします。

ユーザーが何も行わなかった場合はどうなりますか？

ユーザーが何も操作しない場合、既存のデプロイ済み関数は標準アセットとして引き続き実行されます。ただし、2027 年 3 月 31 日以降は次のようになります。

1. 構成パラメータの変更や環境変数の更新はできません。
2. バグの修正、セキュリティ パッチ、依存関係のアップグレードを適用できません。
3. 拡張機能の構成をダウンロードして、交換用ファンクション キットを同じように構成することはできません。
4. 現在、ほとんどの拡張機能は以前の Cloud Functions v1 SDK 上に構築されており、古い Node.js ランタイムに関連付けられています。これらのレガシー ランタイムが Google Cloud によって完全に廃止されると、関数が実行を停止するか、無効になる可能性があります。ランタイム サポートをご覧ください。

Firebase Extensions の代わりになるものはありますか？

Cloud Functions には、拡張機能の代わりとなる多くの機能が追加されています。特に、npm を使用して配布できる関数キットを使用すると、1 つのプロジェクトに拡張機能を複数回インストールできるのと同様に、関数の複数のインスタンスをデプロイできます。

ただし、npm で公式の関数キットの代替を公開するかどうかは、各拡張機能のパブリッシャーが決定します。拡張機能はオープンソースであるため、パブリッシャーが公式の代替機能を作成しない場合でも、任意のデベロッパーがフォークして、Node SDK の第 2 世代 API を使用して Cloud Functions の非公式の代替機能を作成できます。

置き換えを希望するニュース メディアは、ニュース メディア向け移行ガイドの手順に沿って対応してください。

公式の交換用パッケージを利用したり、独自の交換用パッケージを作成したりする場合は、ユーザー向けの移行ガイドの手順に沿って操作してください。

拡張機能のユーザーとして、どのような対応をすればよいですか？

拡張機能のユーザーで、インストールした拡張機能を今後使用しない場合は、2027 年 3 月 31 日までにアンインストールしてください。

廃止後、Firebase コンソールの [アンインストール] ボタンと対応する CLI コマンドは削除されます。Google Cloud コンソールを使用して、個々の Cloud Functions、Secret Manager シークレット、Cloud Tasks キュー、カスタム IAM サービス アカウントなど、関連するすべての Google Cloud リソースを手動で削除する必要があります。

ただし、インストール済みの拡張機能を積極的に使用している場合は、関数キットへの移行を強くおすすめします。関数キットに移行するには、ユーザー向けの移行ガイドの手順に沿って操作します。

関数キットに移行しないこともできます。その場合は、すべての拡張機能を最新バージョンに更新し、最新の状態に保ち、後で移行する場合に備えて既存の拡張機能の構成をエクスポートすることを強くおすすめします。

拡張機能のパブリッシャーとして何をすべきですか？

公開済みの拡張機能を npm で公開されている関数キットに移行することをおすすめします。まず、拡張機能を第 2 世代の関数に移行します。これは、関数キットを作成するための前提条件です。これには、Cloud Functions v2 SDK を使用して拡張機能のロジックをパッケージ化することが含まれます。Cloud Functions v2 SDK を更新し、宣言型セキュリティやライフサイクル イベントなどの機能をサポートしました。既存の拡張機能コードを第 2 世代の関数に移行する際に、コア ビジネス ロジックの変更を最小限に抑えることができるようになりました。これらの関数は、npm パッケージを使用して公開できます。詳しくは、パブリッシャー向けの移行ガイドをご覧ください。

他に質問がある場合はどうすればよいですか？

ご不明な点がある場合は、ユーザー移行ガイドをご覧ください。このガイドを使用してもご不明な点がある場合は、Firebase サポートにお問い合わせください。

Firebase Extensions の移行方法についてご不明な点がある場合は、パブリッシャー向けの移行ガイドをご利用ください。このガイドでは、更新に関する最新情報を入手する方法や、公開済みの拡張機能の代替手段を提供するためのサポートを受ける方法について説明します。

利用可能な主な移行パスは何ですか？

2026 年 9 月より、Firebase は 2 つの主要な移行パスを正式にサポートします。

1. NPM 共有関数（「関数キット」）に移行する: Firestore から BigQuery へのストリーミングや、npm で利用可能になるその他の関数キットに推奨されます。コアロジックは、Cloud Functions v2 SDK を使用して標準の NPM ライブラリとしてパッケージ化されます。ユーザーは、標準の Cloud Functions コードベースを初期化し、パッケージをインストールして、関数を再エクスポートし、CLI を使用して個別にデプロイします。
2. フォークしてセルフマネージド: npm で利用可能な関数キットがないすべての拡張機能におすすめします。ユーザーは、オープンソース拡張機能のソースコードをコピーまたはフォークし、ベスト エフォートの AI 移行スキルまたは手動ガイドを使用して、トリガーを標準の Firebase v2 関数にリファクタリングし、コードベースとその継続的なメンテナンスの完全な所有権を取得します。

どの拡張機能が関数キットに移行されますか？

Firestore から BigQuery へのストリーミング拡張機能は、npm パッケージ @firebase-function-kits/firestore-bigquery-export として提供される関数キットに移行されました。

移行で Cloud Functions v1 から v2 へのアップグレードが必要なのはなぜですか？

Cloud Functions v1 の標準サポートは、Node.js 22 ランタイムで終了します。デベロッパーが Firebase Extensions から移行した後に、レガシー ランタイムのサポート終了時に 2 回目の手動リファクタリングを強制される「二重移行」を防ぐため、Firebase は、この移行中に移行されたすべての関数を v2 SDK に直ちにアップグレードすることを強く推奨します。これは関数キットで必須です。

拡張機能のユーザーは、ユーザー移行ガイドを使用して独自の関数キットを作成することもできます。

セルフマネージド Cloud Functions に移行すると、お客様の請求額は変わりますか？

通常は必要ありません。デプロイされた拡張機能では、Cloud Functions 呼び出し、Cloud Storage、BigQuery ストレージ、クエリなど、使用する基盤となる Google Cloud リソースに対してすでに料金が請求されています。ただし、移行期間中に、安全なカットオーバーを確保するために、以前の Firebase Extensions と新しくデプロイされた代替関数を並行して実行すると、一時的に追加費用が発生する可能性があります。

Mandiant や他の専門的なエンタープライズ アカウントの請求はどのように処理されますか？

この非推奨は、すべての Firebase プロジェクトと Google Cloud プロジェクトに影響するプラットフォーム全体の変更です。標準の請求とサブスクリプションの取り決めは影響を受けません。非推奨のダウンタイムが原因で SLA クレジットをリクエストされた場合や、複雑な請求例外が発生した場合は、通常の請求サポート チャネルを通じてケースを直接エスカレーションします。

移行中にデータ損失やサービス停止が発生するリスクはありますか？

マネージド リソースをセルフマネージド コードベースに移行すると、サービスの中断やイベントの損失のリスクがわずかに発生します。

• トリガーの中断: 新しいトリガーが有効になる前に古いトリガーが削除されると、イベント（Cloud Firestore ドキュメントの書き込みなど）が欠落して永久に失われるギャップが生じます。データ損失を防ぐため、拡張機能を削除する前に交換キットをデプロイして検証することをおすすめします。
• 権限のギャップ: 新しくデプロイされたコードベースに必要な IAM 権限がない場合、BigQuery への書き込みなどのオペレーションは、実行時にエラーを返さずに失敗するか、クラッシュします。関数の宣言型セキュリティを追加したため、ロールのクエリと設定を行い、サービス アカウントを生成できるアカウントによる最初のキットのデプロイで、この問題が軽減されるはずです。

重要な Cloud Firestore から BigQuery への Export 拡張機能のデータ損失を防ぐにはどうすればよいですか？

安全でデータ損失のない移行を実現するには、サポートはユーザーにギャップベースではなくオーバーラップベースのカットオーバーに従うようアドバイスする必要があります。キットへの移行のデフォルトは次のとおりです。

1. 拡張機能がインストールされて実行されている間に、置き換え関数キットをデプロイします。Eventarc が完全にプロビジョニングされるまで数分待ちます。
2. 監視対象の Cloud Firestore コレクションにテスト ドキュメントを書き込み、新しいセルフマネージド関数が対応する行を BigQuery 変更ログ テーブル（新しいイベント ID を含む）に正常に書き込むことを確認します。
3. 新しいデプロイが機能していることを確認したら、すぐに以前の拡張機能をアンインストールまたは無効にして、二重書き込みの動作を終了します。
4. 重複ウィンドウをできるだけ短くして、各書き込みの重複処理のコストと、未加工の BigQuery 変更ログ内の重複行の可能性を最小限に抑えます。
5. ほとんどの場合、Raw Changelog Table（*_raw_changelog）は insertID で重複除去されます。変更ログに重複する行がある場合でも、テーブルの最新のビュー（*_raw_latest）は正しいものになります。

この拡張機能の移行とデータ損失からの復元方法の詳細については、キットの README.md をご覧ください。

ライフサイクル プロビジョニング ステップが失敗した場合はどうすればよいですか？

マネージド サービスでは、設定タスク（BigQuery データセット、テーブル、ビューの作成など）が自動的に処理されていました。セルフマネージド NPM モデルでは、これらはライフサイクル タスクキュー関数を使用してトリガーされます。たとえば、firestore-bigquery-export では initBigQuerySync と呼ばれます。

この手順が失敗した場合、または自動的に実行されない場合:

1. Cloud Functions ランタイム サービス アカウントに必要な IAM ロールが付与されていることを確認します。たとえば、firestore-bigquery-export の場合、これには次のものが含まれます。

   • リソースを作成して行を挿入するには: roles/bigquery.dataEditor
   • ジョブを実行してビューを構築するには: roles/bigquery.user
   • プロビジョニング タスクをキューに登録するには: roles/cloudtasks.enqueuer

2. 呼び出し元に roles/cloudtasks.enqueuer 権限があることを確認します。

3. CLI を使用して、ライフサイクル初期化コマンドを手動で再実行します。

   firebase functions:lifecycle:run afterInstall KIT_INSTANCE_ID
   

4. トリガー関数とタスクキューの実行の両方の Cloud Logging ログを確認して、権限エラーや構成エラーを診断します。

Secret Manager 認証情報はどのように移行されますか？

マネージド モデルでは、Secret Manager リソースは拡張機能インスタンスに自動的にバインドされていました。ext:migrate コマンドまたは ext:export --mode functions コマンドを使用して拡張機能の構成を関数キットにエクスポートすると、拡張機能によるシークレットの管理が停止され、拡張機能がアンインストールされた後もシークレットがプロジェクトに残ります。これらのシークレットを後で削除する場合は、Google Cloud コンソールで手動で削除する必要があります。

移行した拡張機能の複数のインスタンスを実行したい場合はどうすればよいですか？

関数キットは、拡張機能の複数のバージョンを作成できるのと同様に、関数の複数のインスタンスをサポートする方法として導入されました。各キットには一意のキット インスタンス ID が割り当てられます。これはコードベースに似ており、CLI コマンドでコードベースと相互に使用できます。デプロイすると、キット インスタンス内のすべての関数に kit-<instance-id>- という接頭辞が付きます。これにより、拡張機能の ext-<extension-instance-id>- 接頭辞と同様に、すべての関数に一意の名前が付けられます。移行の一環として関数キットを使用する方法について詳しくは、ユーザー移行ガイドをご覧ください。

Kit のインストールでは npm が使用されます。Yarn やその他の Node 互換パッケージ マネージャーを使用したい場合はどうすればよいですか？

現時点では、Yarn やその他のパッケージ マネージャーをサポートする予定はありません。キットのインストールは、初回インストール時にキットのソースコードを設定する際に npm コマンドを直接実行することで機能します。

別の方法として、ソース ディレクトリを作成し、キット npm パッケージを自分でインストールして、適切なビルドとエクスポートで設定することもできます。 の TypeScript index-kit テンプレートを参照するか、 firebase-tools npm でインストールされたキットを例としてご覧ください。この操作を行うと、--package ではなく --directory を使用して、ローカルキットのようにインストールできます。今後は、ディレクトリまたは ID でキットを識別する必要がありますが、キット コマンドを使用してインスタンスを追加および削除できます。

拡張機能で Docker リポジトリまたは KMS 鍵の高度なシステム パラメータを使用しています。関数キットでこれを構成するにはどうすればよいですか？

現在、Firebase の Cloud Functions で Docker リポジトリまたは KMS 鍵を構成することはできません。これらのシステム パラメータが構成された拡張機能から移行し、この機能を維持する場合は、gcloud CLI を使用して、新しいキットの関数にパラメータを適用できます。

前提条件

1. 移行ガイドに沿って関数キットを最初にデプロイし、関数が Google Cloud に存在するようにします。

2. ターミナルで環境変数を定義します。

   export PROJECT_ID="YOUR_PROJECT_ID"
   export FUNCTION_REGION="YOUR_REGION"          # e.g. us-east1
   export KIT_NAME="YOUR_KIT_NAME"                # e.g. firestore-bigquery-export
   export SOURCE_DIR="YOUR_KIT_SOURCE_DIR"       # e.g. "./function-kits/${KIT_NAME}/source"
   export REPO_NAME="YOUR_DOCKER_REPO_NAME"
   export KEY_RING="YOUR_KMS_KEY_RING"
   export KEY_NAME="YOUR_KMS_KEY_NAME"
   
   # Retrieve Project Number automatically
   export PROJECT_NUMBER=$(gcloud projects describe "$PROJECT_ID" --format="value(projectNumber)")
   

3. キットのソースルートに .gcloudignore を事前に作成して、コンパイルされたビルドファイルが .gitignore によって無視されないようにします。

   cat << 'EOF' > "${SOURCE_DIR}/.gcloudignore"
   .gcloudignore
   .git
   .gitignore
   
   node_modules
   #!include:.gitignore
   !lib/**
   EOF
   

4. 必要な IAM 権限を付与します。

   • KMS 鍵の場合（サービス エージェントに復号アクセス権を付与します）:

     for SERVICE_ACCOUNT in \
       "service-${PROJECT_NUMBER}@serverless-robot-prod.iam.gserviceaccount.com" \
       "service-${PROJECT_NUMBER}@gcf-admin-robot.iam.gserviceaccount.com" \
       "service-${PROJECT_NUMBER}@gcp-sa-artifactregistry.iam.gserviceaccount.com"
     do
       gcloud kms keys add-iam-policy-binding "$KEY_NAME" \
         --keyring="$KEY_RING" \
         --location="$FUNCTION_REGION" \
         --project="$PROJECT_ID" \
         --member="serviceAccount:${SERVICE_ACCOUNT}" \
         --role="roles/cloudkms.cryptoKeyEncrypterDecrypter"
     done
     

   • Artifact Registry（Cloud Build への書き込みアクセス権と Cloud Run への読み取りアクセス権を付与します）の場合:

     # Grant the Cloud Build / Compute Service Account permission to write images to the repository
     gcloud artifacts repositories add-iam-policy-binding "$REPO_NAME" \
       --location="$FUNCTION_REGION" \
       --project="$PROJECT_ID" \
       --member="serviceAccount:${PROJECT_NUMBER}-compute@developer.gserviceaccount.com" \
       --role="roles/artifactregistry.writer"
     
     # Grant Cloud Run permission to pull images from the repository
     gcloud artifacts repositories add-iam-policy-binding "$REPO_NAME" \
       --location="$FUNCTION_REGION" \
       --project="$PROJECT_ID" \
       --member="serviceAccount:service-${PROJECT_NUMBER}@serverless-robot-prod.iam.gserviceaccount.com" \
       --role="roles/artifactregistry.reader"
     

gcloud CLI を使用して設定を適用する

キット内の各関数に対して gcloud functions deploy を実行します。

gcloud functions deploy FUNCTION_NAME \
  --project="$PROJECT_ID" \
  --region="$FUNCTION_REGION" \
  --source="./function-kits/${KIT_NAME}/source" \
  --docker-repository="projects/${PROJECT_ID}/locations/${FUNCTION_REGION}/repositories/${REPO_NAME}" \
  --kms-key="projects/${PROJECT_ID}/locations/${FUNCTION_REGION}/keyRings/${KEY_RING}/cryptoKeys/${KEY_NAME}"

この回避策は、次の条件では機能しません。

1. 新しいキット インスタンス: firebase.json にインスタンスを追加すると、デフォルトで Google 管理の鍵と gcf-artifacts を使用する新しい Cloud Functions v2 リソースが作成されます。新しいインスタンスごとに gcloud を実行する必要があります。
2. 関数の再作成: トリガー タイプ（HTTPS から Cloud Firestore トリガーなど）の変更、エントリ ポイントの変更、名前の変更を行うと、Firebase CLI は古い関数を削除して新しい関数を作成します。新しい関数は、gcloud を再度実行するまでこれらの設定を失います。
3. 構成のドリフト: Firebase CLI では、firebase functions:list または差分ログに KMS または Docker リポジトリのステータスが表示されないため、インフラストラクチャの監査が困難になります。

成功を確認する

リポジトリと暗号鍵が適用されたことを確認するには、次のコマンドを実行します。

gcloud functions describe FUNCTION_NAME \
  --region="$FUNCTION_REGION" \
  --project="$PROJECT_ID" \
  --format="yaml(state, buildConfig.dockerRepository, kmsKeyName)"