Cloud Runサービスの作成方法 3パターンを解説！あなたのコードはどこから？

Cloud Runで新しいサービスを作成する際、最初のステップとして「どこからコードを持ってくるか」を選択する場面に遭遇します。Google Cloud ConsoleのUIには、主に3つのオプションが提示されますが、それぞれが異なる開発ワークフローとユースケースに対応しています。

Cloud Runサービス作成時のソースオプション

Cloud Runサービスを作成する際の「ソース」の選択肢は、アプリケーションのデプロイ方法を決定します。

このオプションは、すでにビルド済みでコンテナレジストリ（例: Artifact Registry, Docker Hub）に存在するコンテナイメージをCloud Runにデプロイする場合に選択します。

指定したコンテナイメージのパス（例: gcr.io/my-project/my-app:latest）をCloud Runに伝え、そのイメージを使って新しいリビジョンを作成し、デプロイします。
ビルドは行われません。イメージはすでに外部でビルドされていることが前提です。

高速なデプロイ: コードのビルドが不要なため、デプロイプロセスが高速です。
柔軟なビルドプロセス: Cloud Build以外のCI/CDツール（例: Jenkins, GitLab CI/CD, GitHub Actionsなど）でビルドしたイメージを使用できます。
安定した運用: 一度ビルドされたイメージは不変であるため、デプロイの再現性が高いです。

成熟したCI/CDパイプライン: 外部のCI/CDツールでコンテナイメージのビルドとテストを自動化しており、その成果物をCloud Runにデプロイしたい場合。
ローカルで開発・ビルド済み: ローカル環境でDockerコンテナをビルドし、テストが完了したイメージをCloud Runに手動でデプロイしたい場合。
異なるレジストリからのデプロイ: Artifact Registry以外のコンテナレジストリに保存されているイメージを使用したい場合。

このオプションは、ソースコードリポジトリ（例: GitHub, Cloud Source Repositories）からCloud Buildと連携して、コンテナイメージのビルドとデプロイを自動化したい場合に選択します。

一般的なWebアプリケーションやAPIの開発: コードの変更頻度が高く、継続的なデプロイを必要とするサービス。
CI/CDを初めて構築する場合: GCPの統合されたツールを活用して、簡単にCI/CDパイプラインを構築したい場合。
ソースコードから直接デプロイしたい場合: Dockerfileを自分で書きたくない場合でも、Buildpacksがサポートする言語であれば自動ビルドが可能です。

このオプションは、非常にシンプルな、単一ファイルの関数をCloud Runにデプロイする場合に選択します。
これは、実質的にCloud Functionsのような、HTTPトリガーの「関数」をCloud Runの柔軟な環境で実行したい場合に利用できます。