【登壇レポート】DevelopersIO 2026 Tokyo に「コンテナサービスは ECS だけじゃない！Google Cloud の Cloud Runの魅力」というタイトルで登壇しました #devio2026
はじめに
こんにちは、すらぼです。2026/10/24 に、 DeveloperIO 2026 Tokyo にて、「コンテナサービスは ECS だけじゃない！Google Cloud の Cloud Run の魅力」というタイトルで登壇しました。
本イベントは AWS のセッションが多く、参加者の方も AWS をメインで扱う方が多く参加されていました。そんな方向けに、Google Cloud のサービスの中でも自分が好きなサービスである Cloud Run を少しでも知ってもらいたく、 ECS との比較などを通じて Cloud Run の魅力を発表しました。
登壇資料
登壇内容
今回の発表のゴールは「Cloud Run を試してみたいと思ってもらうこと」です。
そのために、まず ECS との共通点を確認し、次に Cloud Run の便利な点を3つ紹介して、最後にデモを行うという流れで発表しました。
なお、Cloud Run には「サービス」「ジョブ」「Worker pools」「Cloud Run functions」といった種類がありますが、今回は ECS サービスと比較しやすい Cloud Run サービスに絞って紹介しています。
ECS との共通点
ECS の概念が Cloud Run ではどれに当たるのかを、対応表で紹介しました。
| 機能 | ECS / AWS | Cloud Run / Google Cloud |
|---|---|---|
| アプリ単位 | ECS サービス | Cloud Run サービス |
| 設定の版 | タスク定義のリビジョン | リビジョン（デプロイごとに自動で作られる） |
| 実行単位 | タスク | インスタンス |
| 複数コンテナ | マルチコンテナのタスク定義 | サイドカー（マルチコンテナ） |
| スケーリング | Application Auto Scaling | 組み込みのオートスケール（最小 0 から） |
| HTTPS 公開 | ALB + ACM（HTTPS エンドポイント） | 標準で付く *.run.app の HTTPS URL |
アプリの単位やリビジョン、スケーリングなど、基本的な概念は ECS とだいたい一緒です。ECS を触ったことがある方なら、Cloud Run もすぐに理解できると思います。
大きな違いは、AWS は ALB や ACM などの部品を組み合わせて構成するのに対して、Cloud Run はそれらがひとまとまりのサービスとして提供されている点です。
とはいえ、「似ているなら慣れている AWS を使えばいいのでは？」と思う方もいると思います。そこで、ここからは Cloud Run ならではの便利な点を紹介しました。
Cloud Run の便利な点
紹介したのは以下の3つです。
- VPC や LB なしで HTTPS の URL が付く
- 0 までスケールインでき、課金モデルも選べる
- IAP で Google アカウント認証をかけられる
VPC や LB なしで HTTPS の URL が付く
Cloud Run は、デプロイすると *.run.app の HTTPS URL が自動で払い出されます。VPC やロードバランサ、証明書を自分で用意しなくても、すぐにアプリを公開できます。
これにより、以下のようなことが手軽にできるようになります。
- デプロイ後すぐに API を呼べる
- OAuth やブラウザ API など、HTTPS が必須の機能を動かしやすい
- 本番に近い Cookie の挙動を確認できる
- モックや PoC を気軽に作れる
また、本番運用で必要になる機能は、後から追加できます。
- 外部 Application Load Balancer 経由での独自ドメイン、パスベースルーティング
- Cloud Armor（AWS WAF 相当）
- Cloud CDN（CloudFront 相当）
- Certificate Manager（ACM 相当）
最初は URL ひとつで小さく始めて、必要になったタイミングで構成を拡張していけるのが Cloud Run の良いところです。
0 までスケールインでき、課金モデルも選べる
Cloud Run は最小インスタンス数を 0 に設定すると、リクエストがないときに 0 台までスケールインします。
課金モデルは、以下の2種類から選べます。
| 課金モデル | 課金対象 | 向いているケース |
|---|---|---|
| リクエストベース（デフォルト） | リクエスト処理中と、インスタンスの起動・停止時 | アクセスがまばら、または波がある |
| インスタンスベース | インスタンスの稼働時間全体 | トラフィックが安定している、バックグラウンド処理がある |
0 スケールとリクエストベース課金を組み合わせれば、使っていないときの費用をゼロに抑えられます。開発環境を本番環境と同じ構成にしても、ランニングコストを抑えやすいのが嬉しいポイントです。
ただ、開発環境での利便性をアピールしていると、本番環境のような大規模トラフィックが想定されるユースケースに耐えうるのかが気になる方もいらっしゃるかと思います。
そこで、大規模で利用されている事例についても触れました。
発表では、Google Cloud Next '26 で紹介された Anthropic の事例を紹介しました。リクエスト系のコンポーネントで 10k〜20k、推論系のコンポーネントで 4k〜7k インスタンス規模で動いており、最大時には約 27K インスタンスまでスケールしているそうです。
※ なお、インスタンス数のデフォルト上限は 100 台なので、ここまでスケールさせるにはクォータの引き上げが前提になります。
IAP で Google アカウント認証をかけられる
Cloud Run サービスには、IAP（Identity-Aware Proxy）を直接設定できます。管理コンソールの操作だけで設定でき、アプリ側に認証のコードを書かなくても、Google アカウントでアクセスを制御できます。
Google のユーザーやグループ単位でアクセス権を付与できるので、以下のようなユースケースに向いています。
- 社内向けにアプリを公開したい
- パートナー企業やグループ企業（特定のドメイン）向けにアプリを公開したい
- 社内の特定のグループにだけ公開したい
IAP の設定方法については、以下のブログで詳しく解説されています。
デモ
最後に、ここまで紹介した内容をデモで確認しました。
- サンプルイメージ（
us-docker.pkg.dev/cloudrun/container/hello）をデプロイ - 払い出された URL にアクセスし、サービス名・リビジョン・プロジェクト・リージョンが表示されることを確認
- IAP を有効化
- IAP に追加したメールアドレスの Google アカウントでログインできることを確認
デプロイしてすぐに HTTPS の URL でアクセスでき、コンソールの操作だけで認証までかけられるところを、実際に見てもらいました。
その他の機能・AWS 側の動き
AWS 側にも、Cloud Run に近い選択肢が出てきています。
- ECS Express Mode（2025年11月発表）
- コマンド1つで
servicename.ecs.region.on.awsの URL が払い出される - デフォルト VPC に ALB が作成され、Fargate と ALB の料金がかかる
- コマンド1つで
- Lambda Web Functions（2026年10月12日発表）
- HTTP サーバーとして待ち受けるコードを動かせ、1つの実行環境で複数のリクエストを同時に処理できる
- アクティブな CPU 時間とメモリに対して課金される
- 現時点のランタイムは Node.js、リージョンは東京を含む5つ
そのほか、Cloud Run 側にも、今回紹介しきれなかった機能がまだまだあります。
- インスタンスに SSH で接続できる（Preview）
- GPU インスタンスを使って、推論用のエンドポイントを作れる
- 利用上限を設定して、使いすぎを防げる（特に GPU と相性が良い）
- NFS や GCS（S3 相当）をボリュームとしてマウントできる
まとめ
今回の発表のポイントは以下の通りです。
- Cloud Run の基本的な部分は ECS と似ている
- VPC や LB なしで始められ、必要に応じて拡張できる
- 検証から本番規模まで対応できる
- 0 スケールと課金モデルの選択で、開発コストを抑えやすい
- IAP でコードを書かずに認証をかけられる
ECS に慣れている方なら、Cloud Run の概念はすぐに掴めると思います。URL ひとつで手軽に始められるので、ぜひ皆さんも Cloud Run を触ってみてください。
登壇レポートは以上になります。
当日は雨の中、たくさんの方にご来場いただきありがとうございました。
本セッションを通じて、少しでも Cloud Run の魅力を知り、「触ってみよう」と思ってもらえていたら嬉しいです。
以上、すらぼでした！
