Cloud Runはどこまで広がるのか

2026/05/18 に「Google Cloud Next 2026 Recap in ZOZO」で発表した登壇資料です。
https://zozotech-inc.connpass.com/event/393303/

株式会社ZOZO
データ・AIシステム本部 MA部 配信基盤ブロック
木野 智行

#GoogleCloudNext26Recap

Transcript

1. Google Cloud Next 2026 / Recap Cloud Runはどこまで広がるのか Google Cloud Next 2026 の新発表 Recap © ZOZO, Inc. 1
2. 自己紹介 株式会社ZOZO データ・AIシステム本部　MA部　配信基盤ブロック 木野 智行 ZOZOTOWN上の通知にまつわる部分を中心に開発 • Cloud Run / 配信基盤 / 非同期処理まわりを担当 • Google Cloud Nextで気になったCloud Runの変化を紹介 • © ZOZO, Inc. 2
3. Chapter 1 — セッション全体像 これは「What's new in Cloud Run」のRecap Google Cloud Next 2026 / Cloud Run Session 引用: What's new in Cloud Run (https://youtu.be/AoisAy_LGpI?si=m84HZXNK0HmDPs-8) © ZOZO, Inc. 3
4. Chapter 1 — セッション全体像 このセッションでは4つのカテゴリで語られていた Vibe Coded Apps • AI Agents • AI Models • Large Scale Apps • © ZOZO, Inc. 4
5. Chapter 1 — Vibe Coded Apps Vibe Coded Apps AIで作って、すぐ公開する 非エンジニアが思いついたアイデアを、す ぐアプリとして実装 • 実装したコードをそのままCloud Runにデ プロイし、すぐアプリ化 • 引用: What's new in Cloud Run (https://youtu.be/AoisAy_LGpI?si=m84HZXNK0HmDPs-8) 引用: What's new in Cloud Run (https://youtu.be/AoisAy_LGpI?si=m84HZXNK0HmDPs-8) © ZOZO, Inc. 5
6. Chapter 1 — セッション全体像 AI Agents AI developerやagentが動くための実行基盤 引用: What's new in Cloud Run (https://youtu.be/AoisAy_LGpI?si=m84HZXNK0HmDPs-8) AI agentが長時間動くための実行基盤 • dedicated instances / isolated sandboxes が追 加された • Cloud Runが、AI agentからも直接使われる基盤 に寄ってきた • © ZOZO, Inc. 6
7. Chapter 1 — セッション全体像 AI Models 推論や微調整もCloud Runで扱う 引用: What's new in Cloud Run (https://youtu.be/AoisAy_LGpI?si=m84HZXNK0HmDPs-8) on-demand GPUを使って推論や微調整ができる • pay-per-useで、小さく始めやすい • モデル実行基盤としてのCloud Runも強化されて いた • © ZOZO, Inc. 7
8. Chapter 1 — セッション全体像 Large Scale Apps 大量トラフィックをさばく本番基盤として強化 引用: What's new in Cloud Run (https://youtu.be/AoisAy_LGpI?si=m84HZXNK0HmDPs-8) fast-starting instancesでトラフィックスパイ クに対応 • worker poolsやcustom scaling controlsが追加 された • サーバー用途以外も含めた、より広い実行基盤へ • © ZOZO, Inc. 8
9. Chapter 1 — セッションの解釈 この4つの発表から見えてきた未来 エンジニアと非エンジニアの境界が薄くなる もうアプリを作るのは、エンジニアだけの特権ではなくなりつつある • Googleは、「作る・出す・直す」までの距離を、誰にとっても短くしようとしていた • © ZOZO, Inc. 9
10. Chapter 1 — セッションの解釈 Googleが見せていた未来 すぐ作って、すぐ公開して、すぐ直す アイデアを閃いた非エンジニア ↓ Google AI StudioでGeminiにアイデアを伝えてバイブコーディング ↓ ↓ Google AI StudioからUIでそのままCloud Runにデプロイ codex claudeからCloud Run MCPでデプロイ ↓ バグをCloud Run Instances / SSH / dev syncで手動 / codex claudeに修正させる 非エンジニアでも、小さなアプリをすぐ作って、すぐ公開して、すぐ直せる世界をGoogleは見せていた © ZOZO, Inc. 10
11. Chapter 1 それって僕らエンジニアに関係ある？ © ZOZO, Inc. 11
12. Chapter 1 — セッションの解釈 僕らが本当にほしいのは すぐ作ることだけではなく、壊さずに育てていけること 大きなシステムを壊さずに、安全にリプレイスしたり機能追加できること • 実サービス依存に近い状態で、複数リソースをまたぐ挙動を素早く検証できること • 常駐workerやpull consumerを、無理なく自然な形で置けること • © ZOZO, Inc. 12
13. Chapter 1 Googleの広い未来像の中で、 現場で「今」使えそうなものを見る © ZOZO, Inc. 13
14. Chapter 1 — セッションの解釈 気になったのはこの2つ Googleの広い未来像の中から、今日は実務に刺さりそうな2点だけを見る TOPIC 1 worker pools 常駐workerやpull consumerの自然な置き場にな りそう TOPIC 2 Cloud Run Instances / dev sync 実サービス依存に近い状態で検証・デバッグがで きそう © ZOZO, Inc. 14
15. CHAPTER 2 GA対応した Cloud Run worker pools 1年間、ずっと待ってました © ZOZO, Inc. 15
16. Chapter 2 — Worker pools そもそもworker poolsとは リソース 起動トリガー 向く用途 典型例 Cloud Run Service request request-driven API/Webhook HTTP API、Pub/Sub push Cloud Run Job schedule batch / one-shot処理 集計、migration Cloud Run Worker Pool queue / external / 常駐 continuous background pull consumer、runner © ZOZO, Inc. 16
17. Chapter 2 — Worker pools そもそもworker poolsとは BEFORE — CLOUD RUN SERVICE 常駐workerっぽく「無理に」使う func Serve() { go HandleMessages() http.HandleFunc("/health", HandleHealthcheck) go srv.ListenAndServe() } func HandleMessages() { sub := pubsubClient.Subscription("my-subscription") sub.Receive(ctx, handleMessage) } AFTER — CLOUD RUN WORKER POOL 常駐workerの自然な置き場 func Run() { HandleMessages() } © ZOZO, Inc. 17
18. Chapter 2 — Worker pools GitHub Actions runner / build runner / agent Self Hosted Runner Developer / PR GitHub Actions Secret Manager Artifact Registry Cloud Run Worker Pool GitHub App / API Workflow Job push / PR runs-on: self-hosted env inject pull image registration token execute job • PR時のCI/CD 高速化/低価格化/並列起動数増加の効果がSelf Hosted Runnerにはある...こともある © ZOZO, Inc. 18
19. CHAPTER 3 Cloud Run Instancesとdev syncによる 新たな可能性 © ZOZO, Inc. 19
20. Chapter 3 — dev syncの新たな可能性 Cloud Run Instances Private Preview CLI $ gcloud alpha run instances create \ --image alpine/openclaw:latest \ --port 18789 \ --memory 4Gi \ --default-url SDK import { InstancesClient } from '@google-cloud/run'; new InstancesClient().createInstance({ parent: 'projects/p/locations/europe-west9', instance: { containers: [{ image: '...' }] }, }); 個々のCloud Run instanceを直接扱える 新しい実行単位 • わずか数秒で起動可能 • 長時間動く非同期処理や専用環境に向く • 事前定義のresource typeに縛られない • © ZOZO, Inc. 20
21. Chapter 3 — dev syncの新たな可能性 Cloud Run Instances: dev sync Coming Soon $ gcloud run instances dev sync my-node-app \ --source . ✓ Starting Sync ✓ Generating sync rules... ✓ Fetching Project details... ✓ Establishing connection... Done. Watching for changes in: /home/me/my-node-app Syncing to "my-node-app": index.js...done. Cloud Run上でそのまま開発する • ホットリロードでリアルタイムデプロイ • ローカルフォルダとCloud Runを自動同期 • package.json のdev scriptをクラウド側で実行 • © ZOZO, Inc. 21
22. Chapter 3 — dev syncの新たな可能性 これは複数リソースをまたぐテストで 真価を発揮するのではないか 例えばこのような Cloud Run Pub/Sub Cloud Run © ZOZO, Inc. 22
23. Chapter 3 — dev syncの新たな可能性 これまでLocalでCloudをがんばって再現してきて AWS側 LocalStack 広く使われている GOOGLE CLOUD側 個別のemulator群 Pub/Sub / Datastoreなど © ZOZO, Inc. 23
24. Chapter 3 — dev syncの新たな可能性 それでもローカルでCloudを再現するのには限界があった 差分1 ローカルとdevの環境差分 仮serviceと実serviceの挙動のズレ 差分2 IAM / network / managed の差分 権限・経路・GCPマネージドの境界 差分3 本物の非同期経路を通してい ない retry / ordering / backoff © ZOZO, Inc. 24
25. Chapter 3 — dev syncの新たな可能性 ローカルとDev環境両方で動作確認するしかなかった これまで ローカルで実装 ↓ LocalStack / 個別emulator群 + mockで確認 ↓ Devブランチにpush ↓ Deploy Workflow待ち(トイレに行く/お茶を淹れるなど) ↓ Devで動作確認 ↓ PRではCIで lint / test / ローカル統合テスト © ZOZO, Inc. 25
26. Chapter 3 — dev syncの新たな可能性 でもこれからは... © ZOZO, Inc. 26
27. Chapter 3 — dev syncの新たな可能性 このdev syncがあれば 引用: What's new in Cloud Run (https://youtu.be/AoisAy_LGpI?si=m84HZXNK0HmDPs-8) local folderをCloud Run instanceにsync • dev scriptをクラウド側でそのまま実行 • © ZOZO, Inc. 27
28. Chapter 3 — dev syncの新たな可能性 PushしてDeployを待つ前に、Cloud Run上で即時検証 これまで ローカルで実装 ↓ 個別emulator群 + mockで確認 ↓ Devブランチにpush ↓ Deploy Workflow待ち ↓ Devで動作確認 ↓ PRではCIで lint / test / ローカル統合テスト これから ローカルで実装 個別emulator群 + mockで確認 ↓ dev sync ↓ 即時反映されたDevですぐ動作確認 ↓ 複数サービスまたぎもその場で検証 ↓ PRではCIで lint / test / ローカル統合テスト © ZOZO, Inc. 28
29. Chapter 3 — dev syncの新たな可能性 将来イメージ Developer → dev sync → Cloud Run instance service-a ↓ Cloud Tasks · Pub/Sub ↓ Cloud Run instance service-b ↔ dev環境の実サービス Cloud Tasks Pub/Sub Application DB Identity API Secret Manager 外部API sandbox (必要ならmock) 各開発者が自分用のCloud Run instanceを持ち、real cloudの依存に早く繋ぐ © ZOZO, Inc. 29
30. Chapter 4 まとめ 今回深掘りできなかったが、実務的に気になったもの Googleは、非エンジニアとエンジニアの境界を薄くしようとしている • 新しく発表された機能の多くは、AIに使われることを非常に意識している • 今、エンジニアである私たちにとってworker poolsやdev syncは役立ちそう • SSH support • 高度な調査・解析 ◦ Spend caps • AI Studioや小さな新規開発で、コスト暴発を防ぐガードレール ◦ Service bindings • よりシンプルなサービス間接続や構成 ◦ © ZOZO, Inc. 30
31. © ZOZO, Inc. 31