Cloud Runは、コンテナ化したアプリケーションやジョブをサーバーレスで実行できるGoogle Cloudの基盤です。HTTPサービス、イベント駆動処理、バッチジョブ、バックグラウンド処理、AI推論まで幅広く使え、インスタンス数は需要に応じて自動調整されます。2026年版では、GPU、ジョブ、サイドカー、最小インスタンス、セキュリティ、CI/CDを含めて設計することが重要です。
Cloud Runとは？サーバーレス開発のメリットを解説
Cloud Runは、コンテナイメージをデプロイするだけで、リクエスト受付、スケーリング、HTTPS、リビジョン管理、ログ出力を扱えるマネージド実行環境です。Kubernetesの柔軟性とサーバーレスの手軽さの中間にあり、インフラ運用を抑えながら本番アプリを動かせます。
メリットは、言語やフレームワークを選ばないこと、トラフィックがないときにスケールダウンできること、リビジョン単位でロールバックやトラフィック分割ができることです。Node.js、Python、Go、Java、Rust、PHPなど、HTTPを受けられるコンテナなら基本的に動かせます。
Cloud Run servicesはWeb APIやWebアプリ、Cloud Run jobsはバッチ処理や定期処理に向いています。jobsでは並列実行やタスク分割ができるため、データ変換、ファイル処理、MLバッチ推論などに使いやすいです。
2026年時点では、GPU付き実行、サイドカー構成、Cloud SQLやSecret Manager連携、VPC接続、Eventarc連携など、従来より本格的なワークロードを載せやすくなっています。ただし、すべてをCloud Runに寄せるのではなく、状態を持つ処理、長時間接続、特殊なネットワーク要件は別サービスも比較しましょう。
2026年時点では、生成AI、リアルタイム分析、セキュリティ統制、FinOpsを同時に考えるケースが増えています。単に機能を使うだけでなく、IAM、監査ログ、リージョン、コスト上限、IaC、CI/CDを合わせて設計すると、後からの作り直しを減らせます。
Cloud Runの基本設定：初めてのデプロイ手順
最初のデプロイでは、アプリをコンテナ化し、Artifact Registryにイメージを置き、Cloud Run serviceとして公開します。gcloud CLIなら、ソースからビルドしてデプロイする方法と、事前に作ったコンテナイメージを指定する方法があります。どちらの場合も、リージョン、サービスアカウント、認証要否、環境変数を明示します。
コンテナは、PORT環境変数で指定されたポートを待ち受け、起動時間を短く保つことが重要です。起動が遅いアプリでは、最小インスタンスやCPU割り当て、軽量なベースイメージ、依存関係の削減を検討します。ヘルスチェックに相当する起動プローブやログの整備も、本番運用では欠かせません。
設定項目では、CPU、メモリ、同時実行数、タイムアウト、最大インスタンス数、最小インスタンス数を調整します。APIサーバーなら同時実行数を高めに、重い推論や画像処理なら同時実行数を低めにするなど、処理特性に合わせます。
環境変数に秘密情報を直接書くのは避け、Secret Managerを使います。Cloud SQL、Firestore、Cloud Storage、Pub/Subと接続する場合も、サービスアカウントに必要最小限の権限を付与し、開発・本番で別プロジェクトや別サービスアカウントを使うと安全です。
デプロイ直後は、Cloud Logging、Cloud Monitoring、Error Reportingで起動エラー、5xx、レイテンシ、メモリ不足を確認します。小さなサービスでも、ログ構造とアラートを最初に整えると、障害時の調査が速くなります。
Cloud Deployを用いた昇格プロセス
Cloud Deployを使うと、開発、ステージング、本番のような複数環境に対して、承認付きの昇格プロセスを作れます。Cloud Runのリビジョンを環境ごとに管理し、検証が終わった成果物だけを本番へ進める流れを標準化できます。
実務では、Cloud Buildでテストとコンテナビルドを行い、Artifact Registryにイメージを保存し、Cloud Deployでステージング、本番へ進める構成が扱いやすいです。Skaffoldを使う場合は、マニフェストやデプロイ定義をコード管理し、レビュー可能にします。
昇格プロセスでは、同じイメージを環境ごとに再ビルドしないことが大切です。ステージングで検証したものと本番に出すものが違うと、原因追跡が難しくなります。タグではなくダイジェストでイメージを固定すると、再現性が高まります。
承認フローは重すぎても軽すぎても失敗します。社内ツールや小規模APIは自動昇格、本番顧客に影響するサービスは手動承認、データ破壊を伴う変更は追加レビューなど、リスクに応じて段階を分けましょう。
ロールバックの設計も同時に必要です。Cloud Runはリビジョンごとのトラフィック配分ができるため、問題があれば前のリビジョンへ戻せます。ただし、DBマイグレーションや外部API仕様変更は単純に戻せないため、後方互換性を保つ設計が重要です。
セキュリティ対策：Cloud Runで安全なアプリを運用する方法
Cloud Runのセキュリティは、認証、IAM、ネットワーク、秘密情報、コンテナ、ログの6つに分けて考えると整理しやすいです。公開APIならCloud ArmorやAPI Gateway、社内向けならIdentity-Aware Proxyや認証必須設定を検討します。
サービスアカウントには、必要なリソースだけにアクセスできる権限を付けます。デフォルトの広い権限を使い続けると、脆弱性や誤設定があったときの影響範囲が広がります。Cloud Runサービスごとに役割を分け、読み取り専用と書き込み権限を明確にしましょう。
ネットワークでは、Ingress設定、VPCコネクタ、Private Service Connect、Cloud SQL接続などを整理します。外部公開が不要なサービスは内部向けにし、外部から直接叩かせる必要がある場合も、認証、レート制限、監査ログを組み合わせます。
コンテナイメージは、最小限のベースイメージ、脆弱性スキャン、署名、依存関係の更新を標準化します。CI/CDにスキャンを組み込むことで、既知脆弱性を含むイメージが本番へ出るリスクを下げられます。
ログには個人情報やシークレットを出さないようにします。リクエストID、ユーザーIDのハッシュ、処理時間、エラーコードなど、調査に必要な情報だけを構造化して出力すると、セキュリティと運用性の両方を守れます。
本番環境へのデプロイ戦略：CI/CDを活用した自動化のポイント
本番運用では、手元のPCから直接デプロイするのではなく、GitHub Actions、Cloud Build、Cloud DeployなどのCI/CDから一貫して実行する構成が望ましいです。誰が、いつ、どのコミットを、どの環境に出したのかを追跡できるようにします。
Cloud Runのリビジョン機能を使うと、カナリアリリースや段階的なトラフィック移行ができます。最初は1%や5%だけ新リビジョンへ流し、エラー率やレイテンシを確認してから100%へ移すと、変更のリスクを抑えられます。
自動テストは、ユニットテスト、コンテナ起動テスト、API統合テスト、セキュリティスキャンを最低限にすると効果的です。デプロイ後にはスモークテストを実行し、重要エンドポイントが正常に応答するか確認します。
AI推論や画像処理のようにGPUや大きなメモリを使う処理では、コールドスタート、同時実行数、最大インスタンス、タイムアウト、キューイングを必ず検証します。Cloud Runは便利ですが、負荷特性を理解せずに公開すると、遅延やコスト増につながります。
運用指標は、リクエスト数、エラー率、P95/P99レイテンシ、CPU、メモリ、インスタンス数、コストを見ます。SLOを決め、アラートを絞ることで、通知疲れを避けながら重要な異常に気づけます。
まとめ：Cloud Runを実務で使いこなすポイント
自社データ基盤やAI活用に合わせた設計・実装を相談したい場合は、HelloCraftAIの お問い合わせ からご相談ください。要件整理からPoC、運用設計まで現実的な進め方を一緒に組み立てます。
