Cloud Runのシステム開発の完全ガイド

Cloud Runのシステムとは、コンテナ化したWeb画面やAPI、バッチをCloud Run上で動かし、データベースや認証などを組み合わせた業務システムです。

Cloud Runはサーバーを個別に構築・管理する負担を抑えながら、社内申請、顧客向けポータル、業務API、データ連携基盤などを作れる実行基盤です。ただし、Cloud Runだけで業務システムが完成するわけではありません。データの保存先、権限、ネットワーク、監視、バックアップ、障害時の復旧方法まで設計して初めて、業務で安心して使えるシステムになります。この記事では、Cloud Runのシステムの全体像、種類、開発の進め方、費用相場、開発会社やベンダーの選び方、運用とFAQまでをまとめます。

Cloud Runのシステムとは何ですか？

Cloud Runのシステムは、Cloud Runをアプリケーションの実行場所として使い、周辺のマネージドサービスと組み合わせて構築するシステムです。業務システム製品の固有名詞ではなく、クラウド上の構成パターンを指す言葉として理解すると、採用可否を判断しやすくなります。

Cloud Runは業務システムそのものではなく実行基盤です

Cloud RunはDockerなどで作成したコンテナを実行するフルマネージドのアプリケーション基盤です。Go、Node.js、Python、Java、.NET、Rubyなど、コンテナイメージを作れる言語やフレームワークを利用できます。利用者が操作する画面、外部サービスから呼び出されるAPI、社内の管理画面をそれぞれサービスとしてデプロイできるため、既存アプリを段階的に移行する構成にも向いています。

一方で、Cloud Runには業務データを保存するデータベースや、ユーザー・組織・権限を管理する仕組みが標準で含まれるわけではありません。たとえばCloud SQLやFirestoreをデータ保存に使い、Cloud Storageをファイル保存に使い、Secret Managerで接続情報を管理するように、役割の異なるサービスを組み合わせます。Cloud Runだけを見て「安いサーバー」と考えると、後から必要な費用と設計作業が増えやすくなります。

基本構成は画面・API・データ・監視の組み合わせです

代表的な構成は、利用者からのアクセスをロードバランサーや認証で受け、Cloud Runのサービスが画面やAPIを返し、Cloud SQLまたはFirestoreへデータを保存する形です。画像や帳票はCloud Storageへ置き、時間のかかる処理はPub/Subなどで受け付けてCloud Run Jobsへ渡します。ログとメトリクスはCloud LoggingやCloud Monitoringへ集約し、エラー率、応答時間、インスタンス数、データベース接続数を監視します。

この構成のポイントは、画面の応答と重い処理を分けることです。たとえば月末の請求書作成を画面リクエストの中で実行すると、タイムアウトや二重実行が起きやすくなります。画面側は受付結果だけを返し、バックグラウンドで帳票を生成して完了通知を送る設計にすると、利用者の待ち時間と障害の影響範囲を抑えられます。

向いている業務システムと注意が必要なシステム

Cloud Runは、アクセス量が時間帯によって変わる業務ポータル、取引先向けAPI、申請・承認画面、イベント駆動のデータ連携、短時間で完了するバッチ処理に向いています。リクエストが少ない時間帯にインスタンスを減らすスケール・トゥ・ゼロを利用できるため、常時大量のアクセスがないシステムでは、サーバーを固定台数で稼働させるより運用を簡素化できる場合があります。

ただし、常時接続を前提とする処理、複雑なネットワーク制御、長時間の常駐プロセス、特殊なOS要件が中心なら、GKEや仮想マシンを含めて比較します。Cloud Runを採用することが目的になると、アプリケーションの制約を後から補うことになり、結果的に開発費や運用費が膨らむためです。

Cloud Runの種類と他の実行基盤の使い分け

Cloud Runには、HTTPリクエストを処理するService、処理完了まで実行するJob、常時稼働型のバックグラウンド処理に使うWorker poolという考え方があります。Google Cloud公式ドキュメントでも、この3種類をCloud Run上でコードを動かす主要なリソースとして整理しています（出典: Google Cloud公式「What is Cloud Run」、2026年8月確認）。業務フローのどこをどの実行形態に置くかを先に決めると、構成と見積もりが具体的になります。

Service・Job・Worker poolを業務の性質で分けます

Serviceは、管理画面やAPIのようにHTTPリクエストへ応答する処理に使います。自動スケールで急なアクセス増加に対応できますが、インスタンスはステートレスです。ユーザーのセッションや編集中のデータをコンテナ内のメモリやローカルファイルだけに置かず、データベースや外部ストレージへ保存します。

Jobは、夜間集計、データ変換、帳票生成、データ移行、定期的な請求処理のように、開始して終了する仕事に適しています。処理を複数タスクへ分割できる場合は並列化して時間を短縮できます。Worker poolは、キューを常時監視するような処理に向く選択肢です。Pub/Subなどのイベントを受けて短い処理を起動するだけなら、Serviceとメッセージングの組み合わせの方が運用しやすい場合もあります。

Cloud Run・GKE・仮想マシンの境界を見極めます

Cloud Runは、コンテナを動かしたいが、クラスタやOSの保守をできるだけ減らしたい場合に適しています。GKEは、複数のコンテナを細かく制御したい、独自のネットワークやスケジューリングが必要、常時稼働のワークロードを一つの基盤に集約したい場合に候補になります。仮想マシンは、既存OSへの依存が強いアプリケーション、特殊なミドルウェア、コンテナ化が難しいパッケージを移行するときに検討します。

比較では、開発者の好みではなく、RTOとRPO、ピーク時の同時利用者数、処理時間、常時稼働の要否、ネットワーク経路、運用担当者のスキルを並べます。Cloud RunのServiceは大規模なアクセスにもスケールできますが、接続先のデータベースが先に限界に達することがあります。アプリケーションだけでなく、データベースの接続プールや最大インスタンス数まで一緒に設計することが大切です。

パッケージ連携・移行・スクラッチを使い分けます

選択肢は、既存のSaaSやパッケージを使い、Cloud Runを連携APIや拡張機能に限定する方法、マネージドサービス中心に新規システムを作る方法、既存アプリをコンテナ化して移行する方法、独自業務だけをスクラッチ開発する方法に分けられます。すべてを新規開発する必要はありません。競争力に直結しない機能は既存サービスで済ませ、独自の承認ルールやデータ連携だけを作ると、納期と費用を抑えやすくなります。

既存アプリを移行するときは、まずコンテナで起動するかを確認します。ローカルファイルへ書き込む処理、固定IPを前提にした連携、セッションをメモリに持つ実装、長時間のバッチ、管理者権限で動く処理は、そのまま移すと問題になりやすい部分です。小さな機能を選んでPoCを行い、修正量と性能を確かめてから本番移行の範囲を決めます。

Cloud Runのシステム開発の進め方

Cloud Runの開発は、画面を先に作るよりも、業務フローと非機能要件を整理してから構成を決める方が安全です。特にデータ移行、権限、障害時の復旧、費用上限は、後から変更すると影響範囲が大きくなります。一般的には、要件定義、PoC、設計・開発、テスト・移行、リリース・運用引き継ぎの順に進めます。

▶ 詳細はこちら：Cloud Runのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

要件定義とPoCでCloud Runの適性を確かめます

最初に、誰が、どの業務で、どのデータを使い、何分以内に処理を終える必要があるかを整理します。利用者の役割、承認経路、同時利用者数、ピーク時間、外部連携先、個人情報の有無、保存期間、監査ログの要否を一覧化します。さらにRTOは「障害から何時間以内に復旧するか」、RPOは「どの時点までのデータを復元できればよいか」と定義します。

PoCは、2〜6週間程度で一つの業務シナリオに絞ると効果的です。コンテナのビルドとデプロイ、認証、データベース接続、ファイル保存、ログ出力、負荷、概算料金を確認します。見た目の画面だけを作るのではなく、失敗時に再実行できるか、権限のないユーザーがデータを見られないか、インスタンスが増えたときにデータベースが耐えられるかまで検証します。

環境・データ・権限を設計して開発します

設計では、開発・ステージング・本番を分け、設定値と秘密情報を環境ごとに管理します。Artifact Registryへコンテナイメージを保存し、CI/CDツールなどでテスト、脆弱性チェック、承認、本番デプロイを自動化します。TerraformなどのIaCを使えば、手作業で作った設定に依存せず、環境の再構築や担当者の引き継ぎがしやすくなります。

権限は、アプリケーションごとに専用サービスアカウントを用意し、必要最小限のIAM権限だけを付与します。利用者の権限一覧と、サービスがデータベースやストレージへアクセスする権限を混同しないことが重要です。外部公開する画面はロードバランサー、TLS、レート制限、必要に応じたWAF相当の防御を組み合わせ、社内専用の画面は内部Ingressや認証でアクセス経路を限定します。

テスト・移行・切り戻し条件を決めてリリースします

テストは、機能テストだけでは足りません。業務シナリオテスト、権限テスト、外部連携テスト、負荷テスト、障害テスト、バックアップからの復旧テストを行います。Cloud Runは自動スケールしますが、下流のデータベースや外部APIの制限を超えればエラーになります。ピーク時の利用者数と連携回数を想定し、最大インスタンス数、タイムアウト、リトライ、重複実行への対策を確認します。

データ移行では、項目対応表、不要データの扱い、文字コード、日付形式、重複ルール、移行件数の確認方法、業務部門の検証担当を決めます。本番移行の前にリハーサルを行い、移行時間と差分反映の手順を把握します。リリース後に問題が起きた場合の切り戻し条件、連絡先、判断者、復旧手順を運用手順書に明記し、実際に訓練しておくと安心です。

Cloud Runのシステム開発費用と月額の相場

Cloud Runの費用は、開発費とクラウド利用料を分けて考えます。Cloud Run単体の日本向け開発費を示す公的な統計は確認できないため、以下は業務システムの一般的な工数とCloud Runの構成要素から組み立てた編集上の推定レンジです。実際の金額は画面数、権限の複雑さ、外部連携、データ移行、テスト要件、運用時間によって変わります。

▶ 詳細はこちら：Cloud Runのシステム開発の見積相場や費用/コスト/値段について

規模別の開発費と期間の目安

技術検証や小規模PoCは100万〜300万円、期間は2週間〜2か月が一つの目安です。1サービス、簡易認証、ログ、最低限のCI/CDでCloud Runの適性を確認する規模です。小規模業務システムは300万〜800万円、2〜4か月程度で、管理画面、API、Cloud SQLまたはFirestore、権限、基本監視、1〜2本のデータ連携などを含みます。

中規模業務システムは800万〜2,000万円、4〜8か月程度が目安です。複数の利用者ロール、外部API、バッチ、データ移行、負荷試験、冗長化、運用設計まで含めると、この範囲を検討します。基幹連携、大量データ、監査ログ、複数リージョン、段階移行、24時間運用が必要な場合は2,000万〜5,000万円超、8〜18か月となることもあります。これらは相場の断定ではなく、要件の抜けを防ぐための予算検討用の数字です。

見積書の内訳は、要件定義10〜15%、設計25〜35%、製造・単体テスト30〜40%、結合・総合テスト15〜20%、移行・教育5〜10%程度に分けて確認します。要件定義を削りすぎると、後工程の仕様変更やデータ移行のやり直しで費用が増えます。画面の製造費だけでなく、非機能要件、運用設計、ドキュメント、引き継ぎを含めて比較します。

Cloud Runと周辺サービスの月額利用料

Cloud Runは、設定した課金方式に応じてCPU秒、メモリGiB秒、リクエスト、ネットワーク転送などを基に課金されます。公式料金表では、サービスの無料枠としてCPU 240,000 vCPU秒、メモリ450,000 GiB秒が月単位で示されています。課金単位、リージョン、無料枠、通信費は変更される可能性があるため、契約前は料金計算ツールで再計算します（出典: Google Cloud公式「Cloud Run pricing」、2026年8月確認）。

1 vCPU・0.5GiBのインスタンスが常時稼働すると仮定した単純試算では、1か月のCPU・メモリ使用量は約259.2万vCPU秒・129.6万GiB秒です。2026年8月時点の東京リージョンの標準単価を使い、無料枠を差し引くと、Cloud RunのCPU・メモリ部分だけでおおむね月27〜30米ドル、1ドル150円換算で約4,000〜4,500円程度となる計算です。ただし、これは比較用の理論値であり、実際にはCloud SQL、ロードバランサー、Cloud Logging、Artifact Registry、VPC接続、外向き通信、バックアップが加わります。

初期予算の検討では、低トラフィックの小規模構成で月2万〜10万円、中規模で月10万〜50万円、常時稼働・高可用性・大量データ連携で月50万〜150万円超を仮置きし、想定リクエスト数とデータ量で見直します。保守費は、初期開発費の年10〜20%程度を目安にする考え方がありますが、監視、障害対応、脆弱性対応、軽微改修、クラウド費を契約上分けると、不要な作業まで固定費化するリスクを抑えられます。

Cloud Runの開発会社・ベンダーの選び方

Cloud Runの開発会社は、資格数や知名度だけでなく、Cloud Runを使った本番運用、コンテナ・データベース・ネットワークの設計、業務理解、保守体制、見積もりの透明性で比較します。Google Cloudの知識があっても、マスタ移行や承認業務、現場の例外処理を整理できなければ、業務システムは定着しません。

Cloud Runの本番実績と担当体制を確認します

実績は「Google Cloudの導入経験」だけでなく、「Cloud Runで何を動かし、どの程度の利用量で、誰が運用しているか」まで聞きます。匿名化された事例でも、ServiceとJobの分け方、Cloud SQLの接続設計、最大インスタンス数、監視項目、障害時の復旧時間を説明できるかで、経験の深さが見えます。提案段階で営業担当だけでなく、要件定義と設計を担当するエンジニアに参加してもらうことも重要です。

担当者の経験が個人に閉じていないかも確認します。主担当と副担当、レビュー体制、再委託の範囲、退職や交代時の引き継ぎ方法、問い合わせの受付時間、障害時の連絡経路を質問票に入れます。大規模な会社でもCloud Run部分を別の会社へ再委託している可能性があるため、契約上の責任分界を曖昧にしないことが大切です。

見積書・契約書・納品物の粒度をそろえます

相見積もりでは、同じRFPと質問票を渡し、要件定義、基本設計、アプリ開発、インフラ設定、データ移行、テスト、教育、保守を分けて記載してもらいます。「一式」だけでは安く見えても、監視設定や移行リハーサルが別料金になり、最終金額が比較できません。人日、単価、期間、前提条件、対象外の作業、追加変更の計算方法まで確認します。

納品物には、要件定義書、画面・API仕様書、データモデル、権限一覧、テスト仕様書と結果、運用手順書、障害対応手順、TerraformなどのIaC、コンテナのソースコード、CI/CD設定、ログとアラートの一覧を含めます。ソースコードとクラウド環境の所有権、アカウント管理者、請求先、退去時のデータ返却、将来の内製化支援も契約で決めます。

提案前に聞くべき質問を標準化します

候補先には、次のような質問を同じ順番で投げます。「本番のCloud Runで採用した構成と規模は何か」「データベースの接続上限とスケール設計をどうするか」「個人情報を扱う場合のリージョン、バックアップ、ログの扱いはどうするか」「障害時に誰が何分以内に判断するか」「IaCとソースコードをどの形式で納品するか」「クラウド利用料の上限と異常検知をどう設定するか」と聞くと、提案の差が明確になります。

契約後に発注者が準備する作業も確認します。業務フロー、現行データ、マスタ、アカウント一覧、社内規程、テスト担当者、移行日の業務停止時間を発注者が用意する場合があります。ここを「開発会社がすべて準備する」と誤解すると、データ移行が遅れたり、追加費用が発生したりします。受発注双方の作業分担表を作り、完了条件まで合意しておくと安全です。

▶ 詳細はこちら：Cloud Runのシステム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：Cloud Runのシステム開発の発注/外注/依頼/委託方法について

Cloud Runのシステムで必要なセキュリティと運用設計

Cloud Runを使うとOSのパッチ適用やサーバー台数の調整を減らせますが、セキュリティと運用の責任がなくなるわけではありません。アプリケーションの脆弱性、過剰な権限、誤った公開設定、データのバックアップ不足、異常な課金を検知する仕組みを別途用意します。

ステートレス性とデータ保護を前提にします

Cloud Runのインスタンスは使い捨て前提で、終了するとインスタンス内の状態は失われます。公式のセキュリティ設計でも、状態を持つデータはCloud SQLやMemorystoreなどの外部サービスへ保存し、秘密情報はSecret Managerなどで管理するよう説明されています（出典: Google Cloud公式「Security design overview」、2026年7月更新）。セッション、アップロードファイル、処理済みフラグをローカルディスクだけに保存しないことが基本です。

個人情報を扱う場合は、保存先とバックアップ先のリージョン、暗号化、アクセスログ、保存期間、削除手順を確認します。データレジデンシーや暗号化の機能があることだけで、社内規程や法令への対応が完了するわけではありません。委託先や再委託先の監督、海外での取り扱い、業界固有のガイドラインを、法務・情報システム・現場部門と一緒に確認します。

監視・バックアップ・復旧を運用に組み込みます

最低限、エラー率、レイテンシ、リクエスト数、インスタンス数、CPU・メモリ使用量、Jobの失敗数、データベース接続数、外部APIのエラーを監視します。アラートは多すぎると無視されるため、業務影響につながる条件に絞り、通知先と対応時間を決めます。ログにはユーザーのパスワードやアクセストークンを出さず、問い合わせに必要なリクエストIDや処理IDを残します。

バックアップは取得するだけでなく、復元できることを検証します。月1回の復旧テスト、四半期ごとの障害訓練など、システムの重要度に応じて頻度を決めます。Cloud Runのリビジョン切り替えだけではデータベースの不整合を戻せないため、アプリケーション、データベース、ストレージ、外部連携の復旧順序を一つの手順にまとめます。

2026年のAI活用と新機能は業務要件から判断します

2026年4月の公式発表では、Cloud RunについてAIエージェント、GPU推論、リモートMCPサーバー、フルスタックアプリなどの機能拡張が発表されました（出典: Google Cloud公式ブログ「What’s new for Cloud Run at Next ’26」、2026年4月）。そのため、AIの推論APIや非同期エージェント処理をCloud Runに置く選択肢は広がっています。ただし、発表時点で一般提供かプレビューかは機能ごとに異なるため、本番採用では提供状況、サポート範囲、費用、データの取り扱いを確認します。

AIを業務システムへ組み込む場合は、生成結果の正しさだけでなく、誰がどのデータを参照できるか、操作履歴を監査できるか、誤った処理を人が差し戻せるかを先に決めます。AIエージェントに業務APIを直接操作させるなら、権限分離、承認ステップ、レート制限、費用上限、監査ログを設けます。新機能を使うことではなく、業務上の待ち時間や手作業を減らすことを導入効果として測定します。

Cloud Runのシステムに関するよくある質問

Cloud Runを業務システムへ使うときは、料金、既存システムとの互換性、サーバー管理の範囲について疑問が生じます。ここでは、導入前に多く聞かれる質問へ直接回答します。

Cloud Runのシステム開発にDockerの知識は必要ですか？

必ずしもアプリケーション担当者全員がDockerを深く理解する必要はありませんが、コンテナの起動、ポート、環境変数、ログ、イメージ管理の知識は必要です。対応言語やフレームワークによってはソースコードからコンテナをビルドする方法もあります。発注する場合は、コンテナ化とCI/CDを誰が担当し、設定ファイルやソースコードをどの形で引き継ぐかを確認します。

オンプレミスの既存業務システムをCloud Runへ移行できますか？

移行できる可能性はありますが、アプリケーションをそのまま移すのではなく、コンテナで動かせるかを確認します。ローカルファイル、固定IP、常時接続、OS依存、長時間処理、メモリ上のセッションがある場合は、外部ストレージ、ネットワーク、データベース、Jobsなどへ置き換える設計が必要です。小さな機能でPoCを行い、修正量、性能、移行停止時間を把握してから全体計画を立てます。

Cloud Runのシステムは月額いくらかかりますか？

Cloud Runだけの料金は、CPU・メモリ・リクエスト・通信量などの利用量で決まり、低トラフィックなら少額に収まる場合があります。しかし、業務システムではデータベース、ログ、ロードバランサー、バックアップ、ネットワーク接続などの費用が加わります。小規模構成は月2万〜10万円、中規模は月10万〜50万円を仮置きし、実際のリクエスト数、データ量、可用性要件を料金計算ツールへ入力して確認するのが安全です。

個人情報を扱うシステムでもCloud Runを使えますか？

使える可能性はありますが、Cloud Runを使うだけで法令や社内規程への対応が完了するわけではありません。リージョン、保存先、バックアップ、アクセス権限、監査ログ、暗号化、委託先・再委託先の管理、削除手順を要件として整理します。社内利用ならIngressを内部向けに限定し、外部利用なら認証やロードバランサーを組み合わせ、誰がどの経路から何を操作できるかを記録できる状態にします。

開発会社へ相談する前に何を準備すればよいですか？

業務フロー、利用者と権限、画面や帳票の一覧、既存システムとの連携先、データ件数、ピーク時間、個人情報の有無、希望納期、予算の上限を整理します。すべての仕様が決まっていなくても、現場の困りごとと優先順位が分かれば提案を比較できます。加えて、ソースコード、IaC、運用手順書、テスト結果を納品物に含めたいこと、保守の受付時間、クラウド請求の管理者を事前に伝えると、見積もりの前提がそろいやすくなります。

まとめ

Cloud Runのシステムは、コンテナ化したアプリケーションを実行するCloud Runと、データベース、ストレージ、認証、ネットワーク、監視を組み合わせて作る業務システムです。Serviceは画面やAPI、Jobは定期処理やデータ変換、Worker poolは常時稼働型のバックグラウンド処理というように、業務の性質で実行形態を分けます。Cloud Run単体の安さだけではなく、周辺サービス、開発工数、移行、保守を含む総保有コストで判断します。

導入前に押さえる3つの要点

第一に、Cloud Runは業務システムではなく実行基盤なので、データの永続化、権限、監視、バックアップまでを一つの設計として考えます。第二に、PoCでコンテナ化、認証、データベース接続、負荷、費用を確かめ、サービスとJobの境界を決めます。第三に、見積書と契約書でデータ移行の役割、ソースコードとIaCの納品、障害時の責任分界、クラウド請求の上限を明確にします。

次に準備する資料

最初の相談や相見積もりに向けて、業務フロー、利用者・権限一覧、既存システム構成、連携先、データ件数、ピーク時間、RTO・RPO、個人情報の分類、希望納期、予算をまとめます。候補先へ同じ資料を渡し、Cloud Runの本番実績だけでなく、データベース、ネットワーク、セキュリティ、移行、運用まで説明できるかを比較します。業務上の目的と測定指標が明確なら、Cloud Runが適切かどうかも含めて、無理のない構成を選びやすくなります。