「GCPでこのアプリ、どこで動かすのが正解なんだろう」——Cloud Run、GKE、App Engine、Cloud Functions（今はCloud Run functions）、Compute Engine。選択肢が多すぎて、最初の一手で迷う。そして最初の選択を間違えると、後から乗り換えるコストが重い。これは発注する側にとっても、作る側にとっても、お金と時間に直結する意思決定です。
私は国内大手放送事業者の社内AIプラットフォームをGCP上に構築した際、専用VMもKubernetesクラスタも持たず、Cloud Run（サービス＋ジョブ）にマネージドを徹底的に寄せる設計を選びました。5つのAIサービス、認証ハブ、重いOCR/音声合成/マルウェアスキャンを、ノードのパッチ当てもクラスタ管理もせずに本番運用できたのは、この選定が効いたからです。
この記事は、Google Cloud公式ドキュメントに忠実に、各選択肢を「いつ・なぜ選ぶか」で整理し、意思決定フローチャートまで落とします。選んだ後の本番運用は Cloud Run 本番運用ガイド を参照してください。
結論を先に：2026年の既定解は「迷ったらCloud Run」
長い比較に入る前に、結論を出します。
新規のコンテナ／Webワークロードは、まず Cloud Run を検討する。 Kubernetes固有の機能が要る、あるいはコンテナ化できない明確な理由があるときだけ、GKEやCompute Engineに上がる。
これは私見ではなく、公式の方向性とも一致します。App Engineの移行ガイドはこう書いています。
Cloud Run is a fully managed, modern application hosting platform that provides access to advanced capabilities, such as GPUs, at lower prices. ... For new Google Cloud users, we recommend using Cloud Run as the preferred alternative over App Engine.（— Compare App Engine and Cloud Run）
そして、かつての「サーバーレス関数」の代表だった Cloud Functions も、Cloud Run の傘下に統合されました（後述）。GCPのサーバーレスは、いま Cloud Run を中心に再編されています。
選択肢の全体像：抽象度のグラデーション
GCPのコンピュートは「どこまでをGoogleに任せ、どこから自分で握るか」のグラデーションで並びます。
| 選択肢 | 抽象度 | あなたが管理するもの | スケールトゥゼロ |
|---|---|---|---|
| Cloud Run functions（旧Cloud Functions） | 最も高い | 関数のコードだけ | ○ |
| Cloud Run | 高い | コンテナイメージ | ○ |
| App Engine | 高い（旧来） | アプリ＋app.yaml | ○（standard） |
| GKE Autopilot | 中 | Podとマニフェスト（ノードは任せる） | △（Pod単位・実質ゼロにはしにくい） |
| GKE Standard | 低い | ノード＋K8sワークロード | × |
| Compute Engine | 最も低い | VM・OS・ランタイム全部 | × |
上に行くほど運用負荷とコスト（特にアイドル時）が下がり、下に行くほど制御の自由度が上がる。原則は「要件を満たす最も抽象度の高い選択肢を選ぶ」こと。理由なく下層を選ぶと、人件費という最大のコストを払い続けることになります。
Cloud Run：迷ったらここ
ステートレスなコンテナを、Kubernetesの運用なしで、トラフィックに応じて自動スケール（ゼロまで縮む）で動かす。 これがCloud Runの核です。
Cloud Runを選ぶべき場面：
- REST/GraphQL API、Webアプリ、Webhookハンドラ、BFF
- マイクロサービス群（サービスごとに独立デプロイ・独立スケール）
- イベント駆動処理（Eventarc / Pub/Sub 起点）
- バッチ・長時間ジョブ（Cloud Run Jobs）、常駐ワーカー（Worker Pools）
- 任意の言語・フレームワーク（コンテナ化できれば何でも動く）
Cloud Runの強み：
- スケールトゥゼロ：トラフィックが無ければ課金されない。散発的・スパイク的な負荷に圧倒的に強い。
- 運用負荷ゼロ：ノードもクラスタも無い。パッチもアップグレードも考えない。
- 言語非依存：コンテナ＝デプロイ単位。Go/Node/Python/Java/.NET/Ruby/Rust、何でも。
- gRPC・WebSocket・HTTP/2ストリーミング対応。
Cloud Runで「やりにくい」こと：
- Kubernetes固有の機能（DaemonSet・CRD・Operator・サービスメッシュ・ネットワークポリシー）。
- ノードレベルのアクセス、特権コンテナ。
- 「常に1リクエスト＝1インスタンス」を厳密に要求する設計（並行性1は可能だがスケール性能が落ちる）。
これらに該当しないなら——つまり大半のWeb/APIワークロードは——Cloud Runが正解です。
Cloud Run functions（旧Cloud Functions）：FaaSの入口
2024年、Cloud Functions（2nd gen）は「Cloud Run functions」に改名され、Cloud Runの傘下に統合されました。Cloud Functions（1st gen）は「Cloud Run functions（1st gen）」になっています。中身は「イベント駆動の関数モデル」を保ちつつ、Cloud Runの性能・スケール・セキュリティの調整つまみ（GPUを含む）が使えるようになりました。
Cloud Run functions を選ぶべき場面：
- 単一のトリガー（HTTP / Pub/Sub / Cloud Storage / Firestore イベント等）に応答する小さな関数。
- 「コンテナを意識せず、関数だけ書きたい」グルーコード・自動化・軽いWebhook。
Cloud Run（Service）との使い分け：
| Cloud Run functions | Cloud Run（Service） | |
|---|---|---|
| 単位 | 関数（ハンドラ） | コンテナ |
| 起点 | 単一トリガー中心 | 任意のHTTPルーティング・複数エンドポイント |
| 向く規模 | 小さい・単機能 | 中〜大・複数機能・フレームワーク |
| 移行性 | 複雑化したらServiceへ | — |
ポイントは、両者は同じCloud Run基盤の上にあるということ。「最初はfunctionsで小さく始め、ロジックが育ったらServiceへ地続きに移る」という移行が無理なくできます。FaaSの手軽さが欲しいときの入口として使い、肥大化したらコンテナサービスへ昇格させる——これが健全な進化です。
App Engine：新規は選ばない（が、知っておく）
App EngineはGCP最古のPaaSです。app.yaml を書いてソースをデプロイすれば動く手軽さがありましたが、Cloud Runがその役割を引き継ぎ、機能面でも上回っています。
公式比較から要点を抜き出すと——
| 項目 | App Engine standard | Cloud Run |
|---|---|---|
| デプロイ単位 | ソース＋app.yaml | コンテナ（またはソース→buildpacks） |
| 並行性 | 10 req/インスタンス | 80（最大1000） |
| リクエストタイムアウト | 自動スケールで10分 | 既定5分・最大60分 |
| 言語 | 限定（Python/Java/Go/PHP等） | 言語非依存（コンテナ） |
| WebSocket/gRPCストリーミング | × | ○ |
| GPU | × | ○ |
新規はCloud Run。既存のApp Engineアプリも、近代化のタイミングでCloud Runへの移行を検討する、というのが公式の推奨です。App Engineを積極的に選ぶ理由は、もはやほとんどありません。
GKE / GKE Autopilot：Kubernetesが「要る」とき
ここが選定で最も間違えやすいポイントです。「コンテナをたくさん動かす＝Kubernetes」ではありません。 Cloud Runでもマイクロサービスは普通に動きます。GKEを選ぶのは、Kubernetesそのものの制御面・エコシステムが必要なときだけです。
GKE（特にAutopilot）を選ぶべき場面：
- Kubernetes固有のプリミティブが要る：DaemonSet、CRD、Operator、ネットワークポリシー、サービスメッシュ（Istio等）、ノードへの特権アクセス。
- 既にKubernetesネイティブな資産・チームのスキルがある。
- 多数（目安10以上）のサービスを単一のK8sプラットフォーム上で統一して運用したい。
- ステートフルワークロード（StatefulSet）、複雑なバッチ（Kueue等）。
GKE Standard と Autopilot の違い：
| GKE Standard | GKE Autopilot | |
|---|---|---|
| ノード管理 | 自分でノードプールを設計・運用 | Googleがノードを管理（Pod単位の運用に集中） |
| 課金 | ノード（VM）単位 | Pod（リクエストしたリソース）単位 |
| 向く人 | ノードを細かく制御したい | K8sは使いたいが運用は軽くしたい |
Cloud Run と GKE Autopilot の決定的な差：
- Cloud Runはゼロまで縮み、使った分だけ課金。GKEは（Autopilotでも）最低限の常駐コストがかかりやすく、散発トラフィックでは割高になりがち。
- Cloud RunはK8s APIを公開しない。
kubectlもマニフェストも無い世界。逆に言えば、それらが必要ならGKE。
私が放送事業者向けプラットフォームでGKEではなくCloud Runを選んだのは、まさにこの判断でした。5つのAIサービスは独立デプロイ・独立スケールが要件でしたが、サービスメッシュもCRDも不要。ノード管理という常時の運用負荷を負うより、Cloud Runにマネージドを寄せて、平常時コストと運用工数を最小化するほうが、一人〜少人数の体制では圧倒的に合理的でした。
Compute Engine（VM）：最後の手段
コンテナ化できない（特殊なOS依存、レガシーなインストーラ型ソフト）、OSレベルの制御が要る、GPUを常時占有したい、といった場合の最終手段がVM（Compute Engine）です。自由度は最大ですが、OS・パッチ・スケール・可用性を全部自分で握ることになります。「VMでしか動かない明確な理由」が言語化できないなら、選ぶべきではありません。
意思決定フローチャート
上から順に、最初にYESになったところで止まるのが正解です。
1. コンテナ化できない / OSレベルの制御・GPU常駐が要る？
└─ YES → Compute Engine（VM）
2. Kubernetes固有の機能が要る？
（DaemonSet / CRD / Operator / サービスメッシュ / ネットワークポリシー / ノードアクセス）
└─ YES → GKE（運用を軽くしたいなら GKE Autopilot）
3. 単一トリガーに応答する小さな関数で十分？
└─ YES → Cloud Run functions（複雑化したら Cloud Run Service へ）
4. 上のどれでもない（＝大半のWeb/API/マイクロサービス/バッチ）
└─ → Cloud Run（Services / Jobs / Worker Pools）★既定解
（App Engine は新規では選ばない。既存資産は Cloud Run への移行を検討）
ほとんどのプロジェクトは 4番（Cloud Run） に着地します。1〜3で止まるのは「明確な理由があるとき」だけ。理由を言語化できないなら、Cloud Run。これが迷わないための原則です。
クロスクラウド対応表：AWS / Azure を知っているなら
すでにAWSやAzureの経験があるなら、対応関係で理解すると速いです。私は決済基盤・木材流通DXをAWS Fargateで、放送事業者プラットフォームをGCP Cloud Runで運用してきましたが、サーバーレスコンテナの勘所はクラウドをまたいで地続きです。
| 概念 | GCP | AWS | Azure |
|---|---|---|---|
| サーバーレスコンテナ | Cloud Run | App Runner / ECS on Fargate | Container Apps |
| マネージドK8s | GKE / GKE Autopilot | EKS / EKS Auto Mode | AKS |
| FaaS（関数） | Cloud Run functions | Lambda | Functions |
| 旧来PaaS | App Engine | Elastic Beanstalk | App Service |
| VM | Compute Engine | EC2 | Virtual Machines |
各クラウドの本番運用は個別記事にまとめています——AWS ECS on Fargate 本番運用、Azure Container Apps 本番運用、Fargate vs Lambda vs App Runner の選定、Azure Container Apps vs AWS Fargate 比較。「サーバーレスコンテナを選ぶ」という判断自体は、3クラウドでほぼ同じです。
まとめ：選定は「抽象度の最大化」
GCPのコンピュート選定は、突き詰めると一つの原則に集約されます——要件を満たす最も抽象度の高い選択肢を選び、理由があるときだけ下層に降りる。
- 大半のWeb/API/マイクロサービス/バッチ → Cloud Run（2026年の既定解）
- 小さな関数 → Cloud Run functions（地続きでServiceへ移れる）
- Kubernetes固有機能が要る → GKE / GKE Autopilot
- 新規でApp Engineを選ぶ理由は無い。VMは最後の手段。
選定が決まったら、本番運用の作り込みへ進みます。コンテナ契約・並行性・デプロイ・セキュリティは Cloud Run 本番運用ガイド、コストの詰め方は 並行性・オートスケール・課金ガイド へ。
技術選定の段階から伴走が必要なら、私は一人 × 生成AIで、要件定義から本番運用まで一気通貫で承っています。GCPでのコンテナ基盤構築の実績を踏まえ、御社の負荷特性・体制・予算に合う構成を一緒に決めましょう。