App Hosting にデプロイする他の方法

ほとんどの場合、 自動ロールアウトまたは 手動トリガーによるロールアウト をFirebaseコンソールから使用することをおすすめします。ただし、よりカスタマイズされたデプロイ フローが必要になる場合もあります。App Hosting には、カスタム デプロイ用のオプションが複数用意されています。

ソースからのデプロイ

ソースからデプロイすると、永続的な GitHub 接続を必要とせずに、アプリケーションのソースコードと 構成を App Hosting に直接 push できます。

ソースからデプロイする場合、App Hosting はソースコードを Google Cloud Storage バケットにアップロードし、 Cloud Build でフレームワークのビルドコマンドを実行して、コンパイルされたアーティファクトを Cloud Run と Cloud CDN にデプロイします。ローカル ソースのデプロイと GitHub のデプロイでは、同じビルドプロセスが使用されます。プロジェクトに .gitignore ファイルがある場合、そのファイルにリストされているファイルとフォルダはデプロイから除外されます。

ローカル ソースからデプロイするには、Firebase CLI または Firebase コンソール を使用します。

必要な IAM 権限とインフラストラクチャの設定

Firebase CLI と Firebase コンソールはどちらも同じ バックエンド インフラストラクチャを使用してソース アーカイブを保存してビルドするため、どちらのデプロイ方法にも同じ IAM 権限の要件が適用されます。

正確な要件は、特定のロケーション（リージョン）に初めてデプロイするかどうかによって異なります。権限の詳細については、 Firebase IAM の概要と特定の Firebase App Hosting 権限をご覧ください。

初期オンボーディングの権限（ロケーションへの最初のデプロイ）

プロジェクト ロケーションでローカル ソースのデプロイが初めて開始されると、Hosting はアーカイブを保存する GCS バケットをプロビジョニングし、Hosting サービス エージェントにアクセス権を付与する必要があります。これらはプロジェクト レベルの管理タスクであるため、プロジェクト オーナーまたは IAM 管理者の権限が必要です 。基本的な編集者または閲覧者のロールを持つユーザーは、この初期設定を行うことができず、ブロックされます。

前提条件となる設定権限は次のとおりです。

• Storage API を有効にする: serviceusage.services.enable
• ソースバケットを作成する: storage.buckets.create と storage.buckets.list
• サービス エージェントを構成する: resourcemanager.projects.setIamPolicy を使用して Hosting に読み取りアクセス権（roles/storage.objectViewer）を付与し、ビルド中にアップロードされたコードを取得できるようにします。

最初のデプロイでは、GCS バケットは 30 日間のライフサイクルで作成され、その後削除されます。ただし、この期間は Cloud コンソールの [Cloud Storage] -> [バケット] -> [ライフサイクル] -> [ルール] で管理できます。 オブジェクトのライフサイクルを管理するをご覧ください。

後続のデプロイの権限（ロケーションの初期化後）

ロケーションのソースバケットとロール バインディングが初期化されると （最初の CLI デプロイまたはコンソール設定によって）、通常のデベロッパー、 編集者、または App Hosting 管理者 が更新をデプロイできます。ルーチン デプロイには、プロジェクト レベルの管理権限は必要ありません。

アクティブなデプロイ権限は次のとおりです。

• バケットを確認する: storage.buckets.list
• ソース アーカイブをアップロードする: storage.objects.create
• ビルドとロールアウトをトリガーする: 標準の Hosting 権限（apphosting.builds.create と apphosting.rollouts.create）

Firebase CLI を使用してソースからデプロイする

Firebase CLI v14.4.0 以降では、アプリのソースコードと構成をローカルマシンから Firebase に直接 push できます。他の Firebase デプロイ（セキュリティ ルールや関数など）をすでに管理していて、ウェブアプリとバックエンド サービスを 1 つの CLI コマンドで一緒にデプロイする場合に便利です。

前提条件

• プロジェクトが従量課金プラン である必要があります。
• firebase-tools バージョン 14.4.0 以降を実行している必要があります。

デプロイ手順

1. ローカル プロジェクト ディレクトリで firebase init apphosting を実行します。
2. プロンプトが表示されたら、[既存のプロジェクトを使用する] を選択し、ターゲットの Firebase プロジェクトを選択します。
3. デプロイ先の新しいバックエンドまたは既存のバックエンドを選択します。このステップでは、ローカル ディレクトリの Hosting デプロイを設定し、構成の詳細を入力するように求められます:
   • デプロイ先のバックエンドの ID
   • 新しいバックエンドを作成する場合は、デプロイ先のリージョン
   • アプリケーション コードのルート ディレクトリへのパス
   • 優先するNode.js ランタイム 。バージョン管理されたランタイムを選択すると、 自動ベースイメージ更新（ABIU） が有効になり、基盤となる環境にセキュリティ パッチが自動的に適用されます。
4. App Hosting は、デプロイ設定を firebase.json に保存します。 このファイルが存在しない場合は、ローカル プロジェクトに作成されます。初期化が正常に完了したら、firebase deploy を実行してソースコードをデプロイします。

注: インタラクティブ プロンプトをバイパスする場合（CI/CD スクリプトなど）、 コマンドライン フラグ --runtime（たとえば、--runtime nodejs22）を使用して ABIU とランタイムの設定を管理できます。複数のバックエンドにローカル ソースのデプロイを設定している場合（firebase.json に複数の backendId エントリがある場合）、firebase deploy はそれらの各バックエンドにデプロイされます。特定のバックエンドにデプロイするには、firebase deploy --only apphosting:backendId を使用します。

firebase.json の例

{
  "apphosting": [
    {
      "backendId": "my-backend",
      // rootDir specifies the directory containing the app to deploy, but the entire
      // parent directory of firebase.json will be zipped and uploaded to ensure that
      // dependencies outside of the app directory will be available at build time.
      "rootDir": "./my-app",
      "ignore": [
        "node_modules",
        ".git",
        "firebase-debug.log",
        "firebase-debug.*.log",
        "functions"
      ]
    }
  ]
}

Firebase コンソールでデプロイする（ZIP アップロード）

The Firebase コンソール には、圧縮されたソース アーカイブを直接アップロードしてアプリケーションをデプロイするためのグラフィカル インターフェースが用意されています。これは、GitHub を使用しない場合や、別の CI/CD 設定を使用する場合に、GitHub 接続フローの代替手段として使用できます。

アーカイブのアップロードは、最初のバックエンドの作成 時、または既存のバックエンドで 手動ロールアウトを作成 するときに実行できます。これには、 Firebase CLI を使用して最初にデプロイされたバックエンドも含まれます。

サポートされている形式

コンソール アップローダーは、次の 2 つの圧縮アーカイブ形式をネイティブで検証して受け入れます。

• .zip
• .tgz

これらの形式は、ファイル アップローダーの説明テキストに明示的に表示されます。

デプロイ手順

オプション A: 最初のバックエンドのオンボーディング時

1. [ソースを選択する]: バックエンド作成ウィザードの [アプリのインポート方法] ステップで、[ZIP をアップロード] を選択します。
2. オンボーディングの準備: [次へ] をクリックすると、バックグラウンドの準備フローがトリガーされ、Storage API が順番に有効になり、正しいロールが設定され、バケットが upsert されます。UI に、動的なステータス メッセージ（ 「API を有効にしています...」"、「権限を確認しています...」、および「バケットを準備しています...」）が表示されます。
   • エラー処理とガードレール: 準備ステップが失敗した場合（オーナー以外のユーザーが IAM 権限が不足しているため 403 PERMISSION_DENIED を受け取った場合など）、UI に専用の警告が表示され、プロジェクト オーナーに連絡するように指示されます。 ステップ ナビゲーションは厳密にロックされ、問題が解決するまで [次へ] ボタンと最後の [完了してデプロイ] は無効になります。
3. ファイルをアップロードする: 準備が正常に完了したら、 アーカイブ ファイルを選択するか、ファイル アップローダー コンポーネントにドラッグします。

4. 設定を構成する: アプリのルート ディレクトリ を指定します（デフォルトは /）。

   注: 入力した値は、デプロイするアプリを含むディレクトリを指定します。ビルド時間に使用できるように、プロジェクト ルート ディレクトリ全体（アプリ ディレクトリ外の共有依存関係や構成ファイルを含む）を圧縮してアップロードしてください。

5. [完了してデプロイ] をクリックします。アーカイブのアップロードは 1 回限りの操作であり、機能するバックエンドを確保するためにすぐにデプロイする必要があるため、 ZIP アップロードではスタンドアロンの [完了] ボタンは無効になっています。

オプション B: 手動ロールアウトを作成する

1. ダイアログを開く: Hosting ダッシュボードで [ロールアウトを作成] をクリックします。
2. ソースを選択する: ダイアログのステップで [ZIP をアップロード] を選択します。バックエンドに既存の GitHub 接続がない場合、[GitHub] オプションは無効になります。
3. 準備とアップロード: 選択すると、同じバックグラウンド 準備フロー（「API を有効にしています...」、「権限を確認しています...」、および 「バケットを準備しています...」）がトリガーされます。成功したら、アップローダーを使用してアーカイブ ファイルをドラッグまたは選択し、**アプリのルート ディレクトリ** を指定して [**デプロイ**] をクリックし、ビルドとロールアウトをトリガーします。

Terraform を使用したデプロイ

ビルドプロセスとデプロイされた環境をより詳細に制御する必要がある場合は、Terraform を使用してデプロイできます。Terraform を使用すると、宣言型構成ファイルを使用して App Hosting リソースを定義して管理できます。また、 独自の事前構築済みコンテナ イメージを App Hosting に直接デプロイできます。これは、App Hosting がソース コードからビルドするのではなく、

Terraform を初めて使用する場合は、 Terraform と Firebase を使ってみるをご覧ください。 Terraform に精通している場合は、サンプル構成ファイルやその他の App Hosting リソースから始めることができます。

CI/CD 用に GitHub 接続を設定する

Firebaseコンソールの バックエンド設定の [デプロイ] タブで、 GitHub リポジトリをいつでも接続できます。これにより、ローカル環境からアプリのプロトタイプをデプロイし、準備ができたら自動化された CI/CD パイプラインに移行できます。

AI ツールを使用してデプロイする

Firebase Studio は、Firebase Studio2027 年 3 月 22 日に提供を終了します。 App Hosting バックエンドには影響しませんが、[公開] ボタンは Firebase Studio 廃止されます。URL を変更せずに更新の公開を続行するには、プロジェクトを移行してください。 移行手順の詳細。