Cloud Runのソースコードからの直接デプロイを試してみる

2025.12.25
 はじめにデータ事業本部のkobayashiです。
Cloud Runはコンテナ化されたアプリケーションを手軽に実行できるGoogle Cloudのサーバーレスプラットフォームです。Cloud Runへのデプロイ方法は複数用意されており、状況に応じた使い分けが重要になります。
今回は最近プレビューとなったソースコードから直接Cloud Runにデプロイする方法を試して見たいと思います。
Cloud Run release notes | Google Cloud
Cloud Run | Google Cloud
 Cloud Runのデプロイ方法一覧Cloud Runへのデプロイ方法として、主に以下のものがあります。それぞれ特徴が異なるため、開発フェーズやチーム体制、運用要件に応じて適切な方法を選択することが重要です。
 1. コンテナイメージからデプロイgcloud run deploy --imageコマンドを使用して、事前にビルドしたコンテナイメージからデプロイする方法です。ローカルまたはCI/CDでビルドしたイメージをArtifact Registryにプッシュしてからデプロイします。
Deploying container images
 2. Cloud Buildトリガーによる継続的デプロイGitHubなどのリポジトリと連携し、コードのプッシュ時に自動的にビルドとデプロイを実行する方法です。cloudbuild.yamlでビルドパイプラインを定義します。
Continuous deployment with Cloud Build
 3. ソースコードから直接デプロイgcloud run deploy --sourceコマンドを使用して、ソースコードから直接デプロイする方法です。Dockerfileがあればそれを使用し、なければGoogle Cloud Buildpacksが自動的にコンテナイメージを構築します。
Deploying from source code
 4. 宣言的デプロイ（YAML/Terraform）YAMLファイルやTerraformを使用してCloud Runサービスの設定を宣言的に管理する方法です。gcloud run services replaceコマンドでYAMLを適用したり、Terraformでインフラをコード管理できます。
 5. Cloud Run ComposeDocker Compose形式のファイル（compose.yaml）を使用してCloud Runにデプロイする方法です。ローカル開発環境とクラウド環境で同じ設定ファイルを使用できるため、開発から本番への移行が簡素化されます。gcloud beta run compose upコマンドでデプロイします。現在プレビュー段階の機能です。
Deploy services using Compose
 6. Cloud Run functions関数単位でデプロイする方法で、イベント駆動型の処理に適しています。gcloud run deploy --functionコマンドで関数をデプロイできます。
Deploying functions
 ソースコードから直接デプロイを試すここからは実際にソースコードから直接Cloud Runにデプロイしてみます。
 前提条件以下の環境が整っていることを前提とします。
gcloud CLIがインストール・初期化済み
Google Cloudプロジェクトが作成済み、課金が有効
必要なAPIの有効化
必要なAPIを有効化します。
gcloud services enable run.googleapis.com cloudbuild.googleapis.com artifactregistry.googleapis.com
また、実行ユーザーには以下の権限が必要です。
roles/run.admin（Cloud Run管理者）
roles/iam.serviceAccountUser（サービスアカウントユーザー）
Cloud Buildのサービスアカウントにはroles/artifactregistry.writerとroles/run.admin相当の権限
 サンプルアプリケーションの準備FastAPIを使った簡単なAPIアプリケーションを用意します。
├── main.py
└── requirements.txt
 main.py
from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def read_root():
    return {"message": "Hello from Cloud Run!"}

@app.get("/health")
def health_check():
    return {"status": "healthy"}
 requirements.txt
fastapi
uvicorn[standard]
Cloud Runはデフォルトで環境変数PORTで指定されたポートでリクエストを受け付けます。FastAPIの場合、Buildpacksが自動的に適切な設定を行ってくれます。
 デプロイコマンドの実行ソースコードのディレクトリで以下のコマンドを実行します。
$ gcloud run deploy fastapi-sample \
    --source . \
    --region asia-northeast1 \
    --project your-project-id \
    --allow-unauthenticated
fastapi-sample: サービス名
--source .: カレントディレクトリのソースコードを使用
--region asia-northeast1: デプロイ先リージョン（東京）
--project your-project-id: プロジェクトID（プロジェクト番号ではなくIDを指定）
--allow-unauthenticated: 認証なしでのアクセスを許可（テスト用）
実行すると、以下のような流れで処理が進みます。
ソースコードがCloud Buildにアップロードされる
Cloud Buildがコンテナイメージをビルド（Dockerfile未定義ならBuildpacksを使用）
ビルドされたイメージがArtifact Registryに保存される
Cloud Runサービスがデプロイされる
Building using Buildpacks and deploying container to Cloud Run service [fastapi-sample] in project [kobayashi-masahiro] region [asia-northeast1]
✓ Building and deploying new service... Done.
  ✓ Validating Service...
  ✓ Uploading sources... 
  ✓ Building Container... Logs are available at [https://console.cloud.google.com/cloud-build/builds;region=asia-northeast1/67fccc06-571f-483e-b7a1-cb2f0acfdfe6?project=xxxxxxxxxxx].     
  ✓ Creating Revision... 
  ✓ Routing traffic...   
  ✓ Setting IAM Policy...
Done.                    
Service [fastapi-sample] revision [fastapi-sample-00001-tj6] has been deployed and is serving 100 percent of traffic.
Service URL: https://fastapi-sample-xxxxxxxxxxx.asia-northeast1.run.app
コンソールから確認するとデプロイタイプもソースコードとなっています。
 動作確認デプロイが完了したら、出力されたService URLにアクセスして動作を確認します。
$ curl https://fastapi-sample-xxxxxxxxxxx.asia-northeast1.run.app/
{"message":"Hello from Cloud Run!"}

$ curl https://fastapi-sample-xxxxxxxxxxx.asia-northeast1.run.app/health
{"status":"healthy"}
問題なくレスポンスが返ってきました。
 ベースイメージの自動更新ソースデプロイでは、ランタイムのベースイメージを自動更新するように構成できます。これにより、セキュリティパッチやランタイムの更新が自動的に適用されます。
gcloud run deploy fastapi-sample \
    --source . \
    --region asia-northeast1 \
    --project your-project-id \
    --base-image python312 \
    --automatic-updates \
    --allow-unauthenticated
--base-image: 使用するベースイメージを指定（python312、nodejs22など）
--automatic-updates: ベースイメージの自動更新を有効化
サポートされている言語ランタイムについては公式ドキュメントを参照してください。
サポートされている言語ランタイムとベースイメージ  |  Cloud Run  |  Google Cloud
 FastAPI使用時の注意点--base-imageを指定した場合、BuildpacksはデフォルトでGunicorn（WSGIサーバー）を使用します。しかしFastAPIはASGIアプリケーションのため、そのままではエラーになります。
TypeError: FastAPI.__call__() missing 1 required positional argument: 'send'
この問題を解決するには、Procfileを作成してUvicornをエントリーポイントとして指定する必要があります。
 Procfile
web: uvicorn main:app --host 0.0.0.0 --port $PORT
ディレクトリ構成は以下のようになります。
├── main.py
├── requirements.txt
└── Procfile
 他のデプロイ方法との違いと優位点最後にCloud Runのソースデプロイと他のデプロイ方法との違いとソースデプロイの優位点をまとめます。
ソースデプロイの強み
セットアップが最小限: Dockerfileを用意する必要がなく、Buildpacksが自動的にコンテナイメージを構築してくれます
Docker知識不要: コンテナの知識がなくてもデプロイ可能です
開発中の動作確認に最適: コードを変更してすぐにデプロイして動作確認できます
1コマンドで完結: ビルドからデプロイまで1コマンドで実行できます
トレードオフ
再現性の課題: Dockerfileやcloudbuild.yamlに比べてビルドプロセスが暗黙的です
チーム開発には不向き: ビルド定義がコードで管理されないため、チーム開発では明示的な定義が推奨されます
デプロイ速度: 毎回ビルドが走るため、イメージデプロイと比べて時間がかかります
 まとめCloud Runへのソースコードからの直接デプロイを試してみました。

gcloud run deploy --sourceコマンドを使うことで、Dockerfileを用意することなく1コマンドでCloud Runにデプロイできます。特に開発中の動作確認やプロトタイプ作成において、その手軽さは大きな強みです。一方で、本番環境やチーム開発では、Cloud Buildトリガーによる継続的デプロイやTerraformによるインフラ管理など、より再現性・管理性の高い方法を検討することをおすすめします。
状況に応じて適切なデプロイ方法を選択し、効率的なCloud Run運用を目指しましょう。
最後まで読んで頂いてありがとうございました。
Cloud Runのソースコードからの直接デプロイを試してみる

はじめに

Cloud Runのデプロイ方法一覧

1. コンテナイメージからデプロイ

2. Cloud Buildトリガーによる継続的デプロイ

3. ソースコードから直接デプロイ

4. 宣言的デプロイ（YAML/Terraform）

5. Cloud Run Compose

6. Cloud Run functions

ソースコードから直接デプロイを試す

前提条件

サンプルアプリケーションの準備

デプロイコマンドの実行

動作確認

ベースイメージの自動更新

FastAPI使用時の注意点

他のデプロイ方法との違いと優位点

まとめ

関連記事

AWSで探す

注目のテーマ

プロダクトやサービスで探す

特集やシリーズから探す

EVENTS
