2026年7月13日

GCPのCloud Runでコンテナをサーバーレスで動かす方法（デプロイから設定・注意点まで）

VPS・クラウド

Google Cloud の Cloud Run は、コンテナイメージを渡すだけで HTTPS の URL を持つサービスとして公開でき、リクエストの量に合わせてインスタンス数が自動で増減するサーバーレスの実行環境です。この記事では、小さな Web アプリをコンテナにして Cloud Run にデプロイし、環境変数・シークレット・スケールの設定を行い、つまずきやすい点を確認するところまでを順に説明します。

Cloud Runの特徴と向いている用途

Cloud Run の主な特徴は次のとおりです。

サーバーの OS やクラスタを管理せず、コンテナイメージ単位でデプロイできる
リクエストがなければインスタンスを0まで減らせる（最小インスタンス数を0にした場合）
1つのインスタンスが複数のリクエストを同時に処理できる（同時実行数を設定できる）
HTTPS の URL が自動で発行され、証明書の管理が要らない

Web API、管理用の小さな Web アプリ、ヘッドレス CMS のフロントエンド、Webhook の受け口などに向いています。HTTP リクエストを受けるサービスのほかに、処理が終わったら終了するバッチ用の「ジョブ」もあります。

一方で、インスタンスは入れ替わる前提なので、ローカルのファイルに状態を保存するアプリはそのままでは動きません。WordPress を載せることも技術的には可能ですが、データベースを Cloud SQL に分け、メディアを Cloud Storage に逃がし、プラグインの更新はイメージの再ビルドで行うといった設計が必要です。管理画面からプラグインを入れる普段の運用をしたいなら、Compute Engine などの仮想マシンのほうが素直です。

コンテナが守るべき約束事

Cloud Run で動かすコンテナには、次の前提があります。

環境変数 PORT（既定値は8080）で指定されたポートで、0.0.0.0 に対して待ち受ける
リクエストに応答できる状態になるまでの起動時間を短くする（起動が遅いとデプロイやスケール時に失敗しやすい）
ファイルシステムへの書き込みはメモリ上に置かれ、インスタンス終了で消える。書き込んだ分はメモリの割り当てを消費する

localhost や 127.0.0.1 にだけ待ち受けていると、デプロイ時に「コンテナが指定ポートで応答しない」というエラーになります。初めてのデプロイで最も多い失敗なので、最初に確認してください。

事前準備

Google Cloud のプロジェクトを作成し、課金アカウントを紐づけたうえで、手元の PC に Google Cloud CLI（gcloud）をインストールします。以下はコマンド例です。your-project-id は自分のプロジェクト ID に置き換えてください。

gcloud auth login
gcloud config set project your-project-id
gcloud config set run/region asia-northeast1

gcloud services enable run.googleapis.com \
  artifactregistry.googleapis.com \
  cloudbuild.googleapis.com

asia-northeast1 は東京リージョンです。リージョンを既定値として設定しておくと、以降のコマンドで毎回指定する手間が省けます。あわせて、想定外の課金を防ぐために、課金アカウントに予算アラートを設定しておくことをおすすめします。

サンプルアプリとDockerfile

依存パッケージのない最小の Node.js アプリを例にします。

// server.js
const http = require('http');

const port = process.env.PORT || 8080;

http.createServer((req, res) => {
  res.writeHead(200, { 'Content-Type': 'text/plain; charset=utf-8' });
  res.end('Hello from Cloud Run\n');
}).listen(port, '0.0.0.0', () => {
  console.log(`listening on ${port}`);
});

FROM node:22-slim
WORKDIR /app
COPY server.js .
ENV NODE_ENV=production
USER node
CMD ["node", "server.js"]

ベースイメージのバージョンは、利用時点でサポート期間中のものを選んでください。USER node で root 以外のユーザーで実行させると、万一アプリに脆弱性があったときの影響を抑えられます。

Artifact Registryにイメージを置いてデプロイする

イメージの保存先として Artifact Registry にリポジトリを作り、Cloud Build でビルドして登録します。

gcloud artifacts repositories create my-repo \
  --repository-format=docker \
  --location=asia-northeast1

gcloud builds submit \
  --tag asia-northeast1-docker.pkg.dev/your-project-id/my-repo/hello:v1

gcloud run deploy hello \
  --image asia-northeast1-docker.pkg.dev/your-project-id/my-repo/hello:v1 \
  --allow-unauthenticated

デプロイが終わると、https:// で始まるサービスの URL が表示されます。ブラウザで開いて「Hello from Cloud Run」と表示されれば成功です。

--allow-unauthenticated は誰でもアクセスできる公開サービスにする指定です。社内向けや他サービスからだけ呼ぶ API なら付けずにデプロイし、IAM で呼び出し元を限定します。組織のポリシーによっては、公開設定そのものが禁止されていてエラーになることがあります。

Dockerfile を書かずにソースコードのディレクトリから直接デプロイする gcloud run deploy --source . という方法もあり、言語によってはビルド方法を自動判定してくれます。

主な設定項目

よく使う設定は、デプロイ時のオプションで指定できます。

gcloud run deploy hello \
  --image asia-northeast1-docker.pkg.dev/your-project-id/my-repo/hello:v1 \
  --memory 512Mi \
  --cpu 1 \
  --concurrency 80 \
  --min-instances 0 \
  --max-instances 5 \
  --timeout 60 \
  --set-env-vars APP_ENV=production \
  --set-secrets API_KEY=my-api-key:latest

--concurrency：1インスタンスが同時に受け付けるリクエスト数。処理が重いアプリは小さくするとレスポンスが安定する
--min-instances：1以上にすると常に待機するインスタンスが残り、初回リクエストの遅延（コールドスタート）を減らせる。その分、待機中も課金対象になる
--max-instances：アクセス急増時や攻撃時に、費用と接続先のデータベースへの負荷が青天井にならないよう上限を決める
--timeout：1リクエストの処理時間の上限（秒）
--set-secrets：Secret Manager に保存した値を環境変数として渡す。API キーなどの秘密情報は --set-env-vars やイメージに直接書かず、こちらを使う

Secret Manager を使う場合は、Cloud Run が使うサービスアカウントにシークレットの読み取り権限が必要です。サービスごとに権限を絞った専用のサービスアカウントを作り、--service-account で指定すると、権限の範囲を管理しやすくなります。

課金の方式（リクエスト処理中だけ CPU を割り当てるか、常に割り当てるか）も選べます。バックグラウンドで処理を続けるアプリでは、この設定によって動作が変わります。料金体系や設定画面の表記は変更されることがあるため、公式の料金ページとドキュメントで確認してください（2026年10月現在）。

つまずきやすい点と確認方法

デプロイが失敗する

まず Cloud Logging でコンテナのログを確認します。Google Cloud コンソールの Cloud Run のサービス画面からログを開くのが手軽です。よくある原因は次の順です。

PORT で待ち受けていない、または 127.0.0.1 に待ち受けている
起動時にエラーで終了している（環境変数の不足、依存パッケージの不足など）
Apple シリコンの Mac などでビルドしたイメージが linux/amd64 向けになっていない（Cloud Build でビルドすれば避けられる）

ビルドで権限エラーが出る

プロジェクトの作成時期などにより、Cloud Build が使う既定のサービスアカウントが異なり、Artifact Registry への書き込みや Cloud Run へのデプロイで権限エラーになることがあります。エラーメッセージに表示されるサービスアカウントと不足しているロールを確認し、必要な権限だけを付与してください。

独自ドメインを使いたい

Cloud Run の URL ではなく独自ドメインで公開したい場合は、外部アプリケーションロードバランサーを前段に置く方法や、Firebase Hosting と組み合わせる方法があります。Cloud Run 自体のドメインマッピング機能もありますが、提供状況や対応リージョンに制限があるため、公式ドキュメントで現在の状況を確認してから選んでください。

まとめ

Cloud Run はコンテナイメージを渡すだけで HTTPS のサービスとして公開でき、リクエスト量に応じて自動で増減する
コンテナは PORT 環境変数のポートで 0.0.0.0 に待ち受け、状態はローカルに保存しない
Artifact Registry と Cloud Build でイメージを用意し、gcloud run deploy で公開する
最大インスタンス数で費用と負荷の上限を決め、秘密情報は Secret Manager で渡す
公開範囲（--allow-unauthenticated の有無）と、専用サービスアカウントによる権限の絞り込みを最初に決める