- Cloud Run の 3 つの実行形態（サービス / ジョブ / worker pools）と Cloud Run functions の位置づけを説明できる
- リクエストベースのオートスケーリングと 2 つの課金モデルを理解し、要件に合わせて設定できる
- リビジョンとトラフィック分割で段階的ロールアウト・カナリア・ロールバックを実行できる
- Eventarc・Cloud Scheduler・Cloud Tasks でイベント駆動 / 非同期のアーキテクチャを組み立てられる
- Compute Engine・GKE・Cloud Run を要件から選び分けるデシジョンツリーを自分の言葉で再現できる
試験ガイド対応: セクション 1.3（コンピューティング リソースの設計）、セクション 6.2（デプロイとリリースの管理）
Cloud Run の全体像 — コンテナを URL に変える
Cloud Run は、コード・関数・コンテナを Google のインフラ上で実行するフルマネージドなアプリケーションプラットフォームです。第 6 章の GKE ではクラスタという「置き場」を自分で持ちましたが、Cloud Run にはクラスタもノードもありません。コンテナイメージを渡すと安定した HTTPS エンドポイントが発行され、リクエスト量に応じてインスタンスが自動で増減します。使われていないときは 0 台まで縮む（スケール to zero）ため、アイドル時のコンピューティング課金をゼロにできるのが、VM や GKE ノードとの決定的な違いです。
3 つの実行形態と functions の位置づけ
Cloud Run には性格の異なる 3 つのリソースタイプがあり、さらに「関数」を動かすための Cloud Run functions がサービスの一形態として乗ります。旧 Cloud Functions（2nd gen）は現在この Cloud Run functions に統合されており、PCA 試験でも現行名で捉え直しておくべき代表例です。
| リソース | 役割 | 起動のされ方 | 使いどころ |
|---|---|---|---|
| サービス | HTTP リクエストに応答するステートレスなインスタンス群 | 安定 URL への HTTP / イベント | Web アプリ・API・イベント受信 |
| ジョブ | 実行して完了したら終了するタスク（HTTP を待ち受けない） | 手動実行・スケジュール実行 | バッチ処理・データ変換 |
| worker pools | 常時稼働の pull 型バックグラウンド処理 | 自分でキューを購読 | Kafka / Pub/Sub pull / RabbitMQ のコンシューマ |
| functions | ソースコードから自動ビルドされ、サービスとしてデプロイされる関数 | HTTP または CloudEvents（イベント駆動） | 単機能のイベント処理・グルーコード |
Cloud Run functions は最大 4 vCPU / 16 GiB メモリ、インスタンスあたり最大 1,000 同時リクエストまで扱えます。1 リクエスト = 1 インスタンスだった Cloud Run functions（1st gen）とは別物で、イベント駆動関数は Cloud Audit Logs 経由の 90 種類超のイベントソースから起動できます。
デプロイの 2 経路 — コンテナからもソースからも
デプロイの入口は 2 つあります。ビルド済みコンテナイメージを渡す --image と、ソースコードから始める --source です。ソースデプロイでは Cloud Build が Google のビルドパック（Dockerfile があればそちらを優先）で言語を自動判別してコンテナ化し、Artifact Registry の cloud-run-source-deploy リポジトリ（無ければ自動作成）にイメージを保存してからデプロイします。Go / Node.js / Python / Java / .NET / Ruby / PHP などに対応しています。
デプロイ元にできるレジストリは Artifact Registry（推奨）のほか、Docker Hub や GitHub Container Registry の公開イメージも指定できます（Docker Hub イメージは最大 1 時間キャッシュされます）。コンテナ側の契約はシンプルで、環境変数 PORT（既定 8080）で渡されるポートを 0.0.0.0 で待ち受けることだけがサービスの必須要件です。
App Engine の現在の位置づけ
App Engine は Google Cloud 最初期からあるサーバーレスプラットフォームで、Standard / Flexible の 2 環境が今も稼働しています。ただし公式ドキュメントは Cloud Run を「Google Cloud サーバーレスの最新の進化形」と位置づけ、新規ユーザーには App Engine ではなく Cloud Run を推奨しています。試験対策としては「既存の App Engine アプリを運用し続けるのは妥当、新規設計で選ぶのは Cloud Run」と整理しておけば十分です。
サービスの心臓部 — スケーリング・課金・リビジョン
オートスケーリングとスケール to zero
Cloud Run サービスの各リビジョンは、リクエスト・イベント・CPU 使用率に応じて必要なインスタンス数へ自動スケールします。判断材料は 2 つで、CPU 使用率（目標値は既定 60%）とリクエストの同時実行数（同じく目標 60%）のうち、多くのインスタンスを必要とするほうが採用されます。急なスパイクで空きインスタンスが無いときは、リクエストを短時間キューに入れつつオンデマンドで即席のスケールアウトも行います。max-instances を明示しなくても既定で 1 リビジョンあたり最大 100 インスタンスまで拡張されますが、これはリージョンの CPU / メモリ割り当て（quota）を上限とした範囲内の話で、より大きく拡張したい場合は --max-instances を引き上げたうえで quota の引き上げをリクエストします。
スケール to zero は既定の動作で、しばらく使われないとインスタンスは解放されます（コールドスタート緩和のため最長 15 分、GPU は 10 分アイドル状態で保持されます）。min-instances を設定すればウォームなインスタンスを維持でき、逆に max-instances は上限として機能し、到達時に処理しきれないリクエストはキュー待ちの後 429 エラーになります。なおメンテナンスや急増時には、上限を一時的に超えるインスタンスが作られることがあります（15 分以内に破棄）。
同時実行数（concurrency）とタイムアウト
1 インスタンスが同時に受けるリクエスト数の上限が --concurrency です。コンソールからの作成では既定 80、gcloud CLI / Terraform では vCPU 数 × 80 が既定で、最大 1,000 まで上げられます。値を上げるほど同じトラフィックを少ないインスタンスでさばけてコストが下がり、スレッドセーフでないアプリや 1 リクエストで CPU / メモリを使い切る処理では 1 に絞ります（ただし concurrency=1 はスパイク時のスケールが著しく重くなります）。リクエストタイムアウトは既定 300 秒・最大 3,600 秒（60 分）で、--timeout で変更します。
課金の 2 モデル — リクエストベースとインスタンスベース
| 観点 | リクエストベース課金（既定） | インスタンスベース課金 |
|---|---|---|
| CPU 割り当て | リクエスト処理中のみ | インスタンスの生存中ずっと |
| 課金対象 | リクエスト処理・起動・終了の時間 + リクエスト数 | インスタンスの全生存時間（アイドル含む） |
| 向くトラフィック | 散発的・バースト的・スパイキー | 定常的・変動が緩やか |
| 旧称 | 「CPU をリクエスト処理中にのみ割り当てる」 | 「CPU を常に割り当てる」 |
切り替えは gcloud run services update SERVICE --no-cpu-throttling（インスタンスベース化）/ --cpu-throttling（リクエストベース化）です。ジョブは常にインスタンスベース課金で、この選択肢はサービス専用です。2026-08 時点の無料枠（us-central1 単価基準・請求先アカウント単位で月次リセット）は、リクエストベースが CPU 18 万 vCPU 秒 + メモリ 36 万 GiB 秒 + リクエスト 200 万件 / 月、インスタンスベースとジョブが CPU 24 万 vCPU 秒 + メモリ 45 万 GiB 秒 / 月です。常時稼働が見えているなら確約利用割引（CUD）があり、Compute Flexible CUD は GKE・Compute Engine・Cloud Run を横断して適用できます。
リビジョンとトラフィック分割 — 段階的ロールアウト
サービスをデプロイするたびに、その時点の設定とイメージを固めた不変のリビジョンが作られます。トラフィックはリビジョン単位でパーセント配分でき、これが段階的ロールアウト（試験セクション 6.2）の土台です。既定では新リビジョンが即座に 100% を受けますが、--no-traffic を付ければ「デプロイはするが配信ゼロ」で追加でき、--tag で付けたタグの専用 URL から本番トラフィックに触れずに動作検証できます。検証後は gcloud run services update-traffic の --to-revisions リビジョン名=割合 で少しずつ流し、最終的に --to-latest で全量を移します。
注意点が 2 つあります。第一に、トラフィックの切り替えは瞬時ではなく、処理中のリクエストは元のリビジョンで完了します。第二に、一度手動でトラフィックを割り当てると、その配分は以後のデプロイでも維持され、新リビジョンには自動で配信されません。--to-latest で「常に最新へ」の既定動作に戻します。
イベント駆動と非同期 — Eventarc・Cloud Scheduler・Cloud Tasks
サービスは HTTP を待つだけの存在ではありません。Google Cloud には Cloud Run を「イベントで」「定時に」「キュー経由で」起動するためのマネージドな仕掛けが 3 つあり、サーバーレスアーキテクチャの定番部品になっています。
Eventarc — イベントをサービスに配線する
Eventarc は、イベントソースから宛先へメッセージを疎結合にルーティングするフルマネージドのイベント基盤です。イベントは業界標準の CloudEvents 形式で宛先に届きます。シンプルに「プロバイダから宛先へ届ける」Eventarc Standard（最大イベントサイズ 512 KB）と、バス上で CEL によるメッセージ変換・プロジェクト横断配信・多対多ルーティングまで担う Eventarc Advanced（同 1 MB）の 2 階層があります。Standard の宛先は Cloud Run サービス / functions・Workflows・VPC 内の内部 HTTP エンドポイント・GKE サービスなどです。メッセージ基盤としての Pub/Sub そのものは第 11 章で扱います。
Cloud Scheduler — フルマネージド cron
Cloud Scheduler は unix-cron 形式で「定時の仕事」を定義するサービスで、ターゲットは HTTP/S エンドポイント・Pub/Sub トピック・App Engine アプリの 3 種類です。配信保証は at least once（少なくとも 1 回）で、失敗時は指数バックオフで再試行されるため、呼び出される側は冪等に作るのが鉄則です。料金は 1 ジョブ月額 $0.10 で、請求先アカウントごとに 3 ジョブまで無料です（2026-08 時点）。
Cloud Tasks — 明示的な非同期ディスパッチ
Cloud Tasks は「本流の処理から切り離せる仕事」をキューに積み、ワーカー（Cloud Run・GKE・Compute Engine・オンプレの HTTP エンドポイント）へ配信するサービスです。キュー単位でディスパッチレートと再試行を制御でき、ワーカーが 2xx を返すまでタスクを保持します（HTTP ターゲットの応答タイムアウトは既定 10 分・最大 30 分）。Pub/Sub との違いは試験でも問われる定番で、Pub/Sub は「発行者は誰が受け取るか知らない」暗黙的な分配、Cloud Tasks は「このエンドポイントに、このレートで届けよ」という明示的な呼び出しです。ユーザー応答を先に返して重い後処理を逃がす、外部 API のレート制限に合わせて流量を絞る、といった用途に向きます。
コンピューティングの選び方 — 試験最頻出のデシジョンツリー
ここまでで Compute Engine（第 4 章）・GKE（第 6 章）・Cloud Run が出揃いました。公式のホスティング比較では、この 3 つは「抽象度の順」に並べられています。制御を細かく持ちたいほど左（Compute Engine）へ、運用を Google に寄せたいほど右（Cloud Run）へ、が基本軸です。
| 観点 | Compute Engine | GKE | Cloud Run |
|---|---|---|---|
| デプロイ単位 | VM イメージ | コンテナ | コンテナ / ソース / 関数 |
| スケール to zero | 不可 | 不可（ノードが残る） | 可（既定） |
| リクエストタイムアウト | 制限なし | 制限なし | 最大 60 分 |
| 常駐バックグラウンド処理 | 可 | 可 | 不向き（worker pools を除く） |
| 永続ディスク | ネイティブ対応 | ボリュームマウントで対応 | 外部ストレージを使う |
| 得意領域 | レガシー移行・DB・OS 依存処理 | マイクロサービス群・K8s 資産の活用 | ステートレスな Web / API / イベント処理 |
第 1 章で作成した学習用プロジェクトと Cloud Shell を使います（ローカルの gcloud CLI でも同じです）。リージョンは asia-northeast1（東京）で統一します。
Google 提供のサンプルイメージを 1 コマンドで公開 URL に変えます。所要 10 分。費用はリクエストベース課金の無料枠（月 200 万リクエスト等）内で、この規模なら実質 0 円です。
- Cloud Run API を有効化します。
gcloud services enable run.googleapis.com - サンプルコンテナをデプロイします。
--allow-unauthenticatedは「未認証の公開アクセスを許可」（allUsers に roles/run.invoker を付与）の意味です。gcloud run deploy hello \ --image us-docker.pkg.dev/cloudrun/container/hello:latest \ --region asia-northeast1 \ --allow-unauthenticated - 出力される Service URL にアクセスして確認します。
curl -s -o /dev/null -w "%{http_code}\n" $(gcloud run services describe hello \ --region asia-northeast1 --format 'value(status.url)')200が返れば成功です。ブラウザで開くとデモページが表示されます。 - リビジョンとトラフィック配分を眺めておきます（次のハンズオンの主役です）。
gcloud run revisions list --service hello --region asia-northeast1 gcloud run services describe hello --region asia-northeast1
後片付け:
gcloud run services delete hello --region asia-northeast1 --quiet図 7-3 の流れを実際に手で回します。所要 15 分。無料枠内（min-instances を設定しない限りアイドル課金は発生しません）。
- v1 をデプロイします。
gcloud run deploy rollout-demo \ --image us-docker.pkg.dev/cloudrun/container/hello:latest \ --region asia-northeast1 \ --allow-unauthenticated \ --set-env-vars VERSION=v1 - v2 を「配信ゼロ + タグ付き」でデプロイします。
gcloud run deploy rollout-demo \ --image us-docker.pkg.dev/cloudrun/container/hello:latest \ --region asia-northeast1 \ --no-traffic \ --tag green \ --set-env-vars VERSION=v2 - トラフィック配分とタグ URL を確認します。
describeの traffic 欄に、旧リビジョン 100% と、greenタグの専用 URL（https://green---rollout-demo-…run.app形式）が並びます。タグ URL を curl して、本番トラフィックに触れずに v2 を検証できることを確かめてください。gcloud run services describe rollout-demo --region asia-northeast1 - リビジョン名を控えて、10% のカナリアを開始します（
REV_V1/REV_V2はrevisions listに表示された実名に置き換え）。gcloud run revisions list --service rollout-demo --region asia-northeast1 gcloud run services update-traffic rollout-demo \ --region asia-northeast1 \ --to-revisions REV_V2=10,REV_V1=90 - 問題なければ全量を最新リビジョンへ移行します。
gcloud run services update-traffic rollout-demo \ --region asia-northeast1 --to-latest - ロールバックも体験します。旧リビジョンへ 100% を戻すだけで、再デプロイは不要です。
gcloud run services update-traffic rollout-demo \ --region asia-northeast1 \ --to-revisions REV_V1=100
後片付け:
gcloud run services delete rollout-demo --region asia-northeast1 --quietrun-to-completion のジョブを並列タスクで実行し、cron スケジュールに載せます。所要 15 分。ジョブの実行は無料枠（月 24 万 vCPU 秒）内、Cloud Scheduler は請求先アカウントあたり 3 ジョブまで無料（超過分は 1 ジョブ月額 $0.10、2026-08 時点）です。
- API を有効化します。
gcloud services enable run.googleapis.com cloudscheduler.googleapis.com - サンプルのジョブ用イメージで、3 タスク並列のジョブを作成します。各タスクには環境変数
CLOUD_RUN_TASK_INDEX（0〜タスク数-1）とCLOUD_RUN_TASK_COUNTが渡され、担当範囲の割り振りに使えます。gcloud run jobs create report-job \ --image us-docker.pkg.dev/cloudrun/container/job:latest \ --region asia-northeast1 \ --tasks 3 \ --max-retries 1 - 手動で実行します。実行（execution）が作成され、全タスクが完了するとジョブ成功です。進捗はコンソールの Cloud Run → ジョブ → 実行履歴で確認できます。
gcloud run jobs execute report-job --region asia-northeast1 - スケジュール実行のため、Scheduler が使うサービスアカウントにジョブの起動権限（roles/run.invoker）を付与します。
PROJECT_ID=$(gcloud config get-value project) PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID \ --format 'value(projectNumber)') gcloud projects add-iam-policy-binding $PROJECT_ID \ --member serviceAccount:$PROJECT_NUMBER-compute@developer.gserviceaccount.com \ --role roles/run.invoker - 毎朝 7:00（JST）にジョブを叩く Scheduler ジョブを作成します。ターゲットは Cloud Run Admin API の実行エンドポイントです。
gcloud scheduler jobs create http report-job-daily \ --location asia-northeast1 \ --schedule "0 7 * * *" \ --time-zone "Asia/Tokyo" \ --uri "https://run.googleapis.com/v2/projects/$PROJECT_ID/locations/asia-northeast1/jobs/report-job:run" \ --http-method POST \ --oauth-service-account-email $PROJECT_NUMBER-compute@developer.gserviceaccount.com - 翌朝まで待たずに、その場で 1 回発火させて配線を検証します。実行履歴に新しい実行が増えれば成功です。
gcloud scheduler jobs run report-job-daily --location asia-northeast1
後片付け:（Scheduler ジョブは残すと課金対象に数えられます）
gcloud scheduler jobs delete report-job-daily --location asia-northeast1 --quiet
gcloud run jobs delete report-job --region asia-northeast1 --quiet
gcloud projects remove-iam-policy-binding $PROJECT_ID \
--member serviceAccount:$PROJECT_NUMBER-compute@developer.gserviceaccount.com \
--role roles/run.invokerつまずきポイント
gcloud run deploy すると、新リビジョンへ全量が即座に流れます。段階展開したいときは必ず --no-traffic を付けてから update-traffic で刻むこと。逆に、一度手動で配分を割り当てると以後のデプロイは配信 0% のまま追加され続けます。「デプロイしたのに反映されない」ときは配分が固定されていないかを疑い、--to-latest で既定動作に戻します。--no-cpu-throttling）へ切り替えるか、処理自体を Cloud Tasks / ジョブへ逃がして設計で解決します。X-CloudScheduler-ScheduleTime ヘッダーを付けてくれます。理解度チェック
Q1. Cloud Run のサービス・ジョブ・worker pools は、それぞれどんなワークロードの受け皿か？
サービスは HTTP リクエストやイベントに応答するステートレスな処理（Web / API）、ジョブは実行して完了したら終了するバッチ処理（HTTP を待ち受けない）、worker pools は Kafka や Pub/Sub pull などキューを自分で購読し続ける常時稼働のバックグラウンド処理です。
Q2. 同時実行数（concurrency）を上げる / 下げると、コストとスケーリングにどう影響するか？既定値は？
上げるほど同じトラフィックを少ないインスタンスで処理できコストが下がります。下げるとインスタンス数が増えてコストは上がりますが、並列処理に弱いアプリを守れます。1 にするとスパイク時のスケールが著しく重くなる点に注意。既定はコンソール作成で 80、gcloud / Terraform では vCPU 数 × 80、最大 1,000 です（2026-08 時点）。
Q3. Cloud Tasks と Pub/Sub の使い分けの軸は？
呼び出しの明示性です。Cloud Tasks は発行側が配信先エンドポイントとレートを明示的に指定するディスパッチで、レート制御・再試行つきの「宛先のある仕事の依頼」に向きます。Pub/Sub は発行者が受信者を知らない暗黙的な分配で、複数システムへのイベント伝搬に向きます。
Q4.（試験形式）EC サイトの API を Cloud Run で運用中。新バージョンを本番トラフィックに影響を与えずに検証し、その後 10% ずつ段階的に展開したい。最も適切な手順は？
A. 新しいサービスを作成し Cloud Load Balancing で新旧に振り分ける B. --no-traffic と --tag を付けてデプロイし、タグ URL で検証後に update-traffic で段階移行する C. 通常デプロイして問題が出たら直前リビジョンへロールバックする D. GKE へ移行して Ingress でカナリアを構成する
B。リビジョンのトラフィック分割は Cloud Run の組み込み機能で、タグ URL による事前検証と段階移行を追加コンポーネントなしで実現できます。A と D は Cloud Run 単体で足りる要件に対して過剰構成、C は「本番に影響を与えず検証」の要件を満たしません（デプロイの既定は即 100% 配信）。
Q5.（試験形式）夜間に 2 時間かかるデータ変換バッチをコンテナ化済み。HTTP は不要で、運用負荷を最小にしたい。最適な構成は？
A. Compute Engine の VM で cron 実行 B. GKE Standard クラスタの CronJob C. Cloud Run jobs + Cloud Scheduler D. Cloud Run サービス + Cloud Scheduler の HTTP 起動
C。run-to-completion のバッチは Cloud Run jobs の設計対象そのもので（タスクタイムアウトは最大 168 時間）、Cloud Scheduler から Admin API 経由で定期起動すればサーバー管理はゼロです。A は VM の常時運用が必要、B はバッチのためだけにクラスタを持つのは過剰、D はサービスのリクエストタイムアウト上限が 60 分のため 2 時間の処理を 1 リクエストで受けられません。
まとめと次章へ
- Cloud Run はコンテナ / ソース / 関数を URL に変えるフルマネージド基盤。サービス・ジョブ・worker pools の 3 形態があり、Cloud Run functions はサービスとして動く
- スケーリングは同時実行数と CPU 使用率が駆動し、既定でスケール to zero。min-instances でコールドスタートを抑え、max-instances で暴走を止める
- 課金はリクエストベース（既定・スパイキー向き）とインスタンスベース（定常向き・ジョブは常にこちら）の 2 モデル
- デプロイごとに不変のリビジョンが作られ、トラフィック分割・タグ URL・
--to-revisionsで段階的ロールアウトとロールバックを組み込みで実現できる（試験セクション 6.2） - イベント駆動は Eventarc（CloudEvents）、定時実行は Cloud Scheduler、レート制御つき非同期は Cloud Tasks。いずれも at least once 前提で冪等に作る
- コンピューティング選択は「Cloud Run から検討し、できない理由があれば GKE → Compute Engine へ降りる」。スケール to zero・60 分タイムアウト・常駐可否が判定キーワード
次章からはデータの置き場所に入ります。第 8 章では、ここまでのアプリケーションが読み書きするオブジェクトストレージ Cloud Storage を、ストレージクラスとライフサイクル設計を軸に学びます。
参考リンク: