Cloud Runのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

Cloud Runのシステム開発は、要件整理から定着まで6フェーズを順に進めます。

この順で各フェーズの決め事を積み上げると、予算と納期の不確実性を抑えられます。

▼全体ガイドの記事
・Cloud Runのシステム開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

Cloud Runのシステムの全体像

Cloud Runのシステムは、業務アプリをコンテナ化し、Google Cloudのマネージド基盤で実行する構成です。Cloud Run自体は、Web画面やAPI、バッチ、データ連携を動かす実行基盤であり、業務システムの製品そのものではありません。

Web・API・バッチの役割別構成

処理の役割に応じて、Cloud RunサービスとJobsを使い分けます。顧客情報はコンテナ内に残さず、データやログは外部サービスに保存する設計にします。

• Web画面・外部公開API：HTTPリクエストやイベントを受けるCloud Runサービスに配置します。
• 請求書作成・夜間集計：処理完了後に停止するCloud Run Jobsに分けます。
• 保存・連携・分析：役割に応じて、Cloud SQL、Firestore、Cloud Storage、Pub/Sub、BigQueryを使い分けます。
• ログ・メトリクス：Cloud LoggingとCloud Monitoringで管理します。

Google Cloudの公式資料でも、サービスはHTTPリクエストやイベントを受ける用途、Jobsは処理を完了して終了する用途と整理されています（出典: Google Cloud「What is Cloud Run」、2026年8月確認）。

Cloud Runのインスタンスは使い捨てのため、ローカルファイルやメモリに顧客情報を保存し続ける設計は避けます。

Cloud Runに向く業務と慎重に判断したい業務

Cloud Runが合うかどうかは、アクセスの変動と処理要件で見極めます。

• アクセス量が変動する業務：ポータル、顧客・代理店向けAPI、社内申請、イベント連携が挙げられます。
• 変動する負荷：自動スケールで低トラフィック時にインスタンスを減らせるため、常時確保の負担を抑えられます。
• 別基盤も検討する業務：複雑なネットワーク制御、長時間接続、特殊なOS設定があるときは、GKEやCompute Engineが適する場合があります。

採用時は、処理時間や同時接続数、データ量を基準に選びます。障害復旧の目標と運用体制も合わせて考えます。

業務要件に応じたサービス・Jobs・GKE・VMの使い分け

実行基盤を比べる起点は、製品の新しさより処理の性質です。次のように選びます。

• 短時間のHTTP応答：Cloud Runサービスが候補です。
• 定時実行・データ変換：Jobsが候補になります。
• 常時稼働ワーカー：Kafkaなどを扱うWorker poolやGKEが候補になります。
• OS・ネットワークの細かな管理：Compute Engineが候補です。

たとえば販売管理では、画面とAPIをCloud Runサービス、夜間集計をJobsに分ける構成が考えられます。ファイルはCloud Storage、取引データはCloud SQLに保存します。

この構成なら、画面の応答と夜間処理の負荷を切り離せます。さらに、機能ごとに分けてデプロイできます。

Cloud Runのシステム開発の進め方と6フェーズ

Cloud Runの開発では、コンテナの作成とデプロイに加えて、業務の正しさ、データの安全、障害復旧、運用の引き継ぎまでを計画に含めます。

全体は6フェーズに分けて進めます。要件整理と選定を先に行い、設計・開発とテストを経て、稼働と定着へ進みます。

フェーズ1：要件整理での業務と非機能要件の決定

最初に、誰がいつどのデータを使い、どの業務判断をするシステムなのかを整理します。そのうえで、利用者の役割や承認経路、締め時間、外部連携の方向も書き出します。

個人情報の種類と保存期間も決めておきます。また、画面や機能の一覧だけでなく、現行業務の情報も集めます。

非機能要件では、ピーク時の同時利用者数や1時間あたりのリクエスト数、許容レスポンスタイムを決めます。RTOとRPO、稼働時間、監視通知の宛先も決めておきます。

要件定義では、次の5項目を確認します。

• ピーク負荷：想定する利用量の大きさ。
• 障害時の切り戻し：戻す先と手順を決めておきます。
• バックアップと復元：データの取得方法と、戻すときの手順を決めます。
• 権限・監査・個人情報：アクセス権限、監査ログ、個人データの保管場所を確認します。
• 運用時間：対応する時間帯と、監視通知の宛先を決めます。

要件定義を省くと、想定外の権限やマスタ移行の責任者が後から判明し、設計変更と追加費用につながります。そのため、発注者は現行帳票やマスタ一覧、業務フロー、サンプルデータ、利用部門の担当者を早めに準備します。

フェーズ2：選定でのCloud Runを使う範囲の決定

選定では、まず構成と移行性を確かめ、そのあとに認証・ネットワークと技術リスクを確認します。

1. 独自性の低い業務はSaaSに任せ、独自フローや連携だけを開発する案も比べます。
2. 既存アプリのOS依存、ローカルファイル、セッション、バッチ実行の方法を洗い出します。
3. 各サービスの責任範囲と、必要な認証方式を決めます。
4. 社内利用は内部Ingress、取引先向けはロードバランサーやCloud Armorを含めて検討します。
5. 選定前に2〜6週間程度のPoCを行い、コンテナ、認証、DB接続を検証します。業務シナリオ、負荷、ログ、概算料金も確かめます。

Cloud RunサービスとJobsの責任範囲を図にします。Pub/SubやCloud SQL、Cloud Storage、BigQueryなどの周辺サービスも、同じように図で示します。

認証は、IAMだけで足りるか、社内向けのIdentity-Aware ProxyやアプリのOIDC/OAuthが必要かを判断します。

PoCの目的は、採用判断に必要な技術リスクと不確実性を減らすことです。本番機能まで作り込む場ではありません。

フェーズ3：設計・開発での再現性と安全性の作り込み

まず、開発、ステージング、本番の環境を分けておきます。そのうえで、Artifact Registry、Cloud BuildまたはGitHub Actions、Terraformなどを使い、デプロイを同じ手順で再現できるようにします。

障害時に同じ状態へ戻せるよう、環境変数、IAM、ネットワークを可能な範囲でコード化し、監視設定も含めます。本番の設定を手作業だけで変える状態は避けます。

設計・開発では、データ保存と認証情報の扱いを分けて管理します。インスタンスは終了時に状態が破棄されるため、状態は外部ストレージへ保存します（出典: Google Cloud「Security design overview」、2026年8月確認）。

• 業務データ：Cloud SQLやFirestoreに保存します。
• ファイル：置き場所はCloud Storageです。
• 秘密情報：APIキーやパスワードはSecret Managerで管理します。
• 実行権限：サービスごとに専用サービスアカウントを割り当てます。

開発は、画面やAPI、データ連携などの単位で小さく区切ります。権限や監査ログも含め、各単位に受け入れ条件を定めます。プルリクエスト、レビュー、自動テスト、ステージング確認を通った単位を本番候補にします。

AI機能や外部APIを追加する場合は、先に権限と、個人情報を入力できる範囲を決めます。ログへの記録方法と利用料の上限も、あわせて決めておきます。

フェーズ4：テストでの業務・負荷・復旧の確認

本番移行の判断には、業務、負荷、障害復旧のテスト結果を使います。

• 業務：単体・結合・総合テストに加え、権限別の操作、入力異常、重複登録を確認します。
• 締め処理：請求、在庫、給与があれば、実際の締め日を想定したデータで試します。
• 負荷：同時リクエスト、起動時間、DB接続数、タイムアウト、最大インスタンス数を測ります。
• 障害・復旧：外部API停止、DB接続エラー、誤デプロイ、権限不足、Pub/Sub再送を試します。

Cloud SQLが先に上限へ達すると、Cloud Runだけが増えてエラーも増える場合があります。そのため、アプリとDBを一体で測ります。

切り戻しの時間や担当者、判断者、連絡手段は、手順書に記載しておきます。バックアップからの復元とデータ整合性も確かめます。

テストの結果は、不具合一覧にとどめず、本番移行の判断材料として残します。

フェーズ5：稼働での移行と切り戻しの管理

本番稼働は、移行、リリース、初期監視の順に進めます。

1. マスタや過去データの移行、アカウント、権限、外部接続の切り替えを一覧にします。
2. 対象、件数、形式、変換ルール、確認担当、完了条件を表にまとめます。リハーサルでは、時間とエラー件数を確認します。
3. 開始条件、担当者、手順、確認点、停止時間、切り戻し条件を決めます。
4. 段階的なトラフィック移行やリビジョン管理を使い、旧環境へ戻せる状態を保ちます。
5. 稼働直後はエラー率、応答時間、インスタンス数、Cloud SQL接続数、連携成功件数、問い合わせを確認します。

データ品質や移行元データの抽出は、発注者側の協力事項になることもあります。並行稼働をする場合は、二重登録や不一致を防ぐルールを書面に残します。

監視通知は本番前に試しておき、一次対応者と対応までの時間を決めます。稼働直後は、安定運用へ移るための検証期間にあたります。

フェーズ6：定着での運用と改善の仕組み化

定着させるには、利用者支援、運用設計、定期的な振り返りが欠かせません。

• 利用者支援：部門別の操作説明、問い合わせ窓口、エラー対処、権限申請を用意します。
• 運用設計：監視、バックアップ頻度、脆弱性・リビジョン・ライブラリ対応、障害連絡先を決めます。
• 資料の引き継ぎ：構成図、権限一覧、データ定義、テスト結果、復旧手順を納品物に含めます。
• 定期確認：月次または四半期ごとに利用率、処理時間、エラー、費用、問い合わせ、要望を振り返ります。

利用状況や入力ミスをもとに、改善を重ねます。現場の担当者を運用メンバーに加えると、開発会社への依存を減らしやすくなります。

費用の面では、低頻度機能のスケール・トゥ・ゼロやログ保存期間を見直すと、品質とコストの両方を改善できます。

契約が終わった後も、自社で運用の判断を続けられる資料がそろっているかを確認します。

Cloud Runのシステム開発費用相場とコストの内訳

Cloud Runの費用は、開発費とクラウド利用料に分けて考えます。開発費は、業務要件や画面数、連携数で変わります。データ移行やセキュリティ、テスト、運用設計の範囲によっても変わります。

Cloud Runを使えば費用が一律に安くなるわけではないため、目安として読んでください。以下の金額は、リサーチノートと類似する業務システムの相場をもとにした編集用の推定で、公的な案件統計や個別の見積もりではありません。

規模別の開発費の幅（100万円台から5,000万円超）

規模別の開発費と期間は、機能や移行の範囲によって幅があります。次に示す金額と期間は、検討用のレンジです。

• 技術検証・小規模PoC：100万〜300万円です。
• 簡易な管理画面とAPI：小規模業務システムで300万〜800万円です。
• 複数ロール・外部API・バッチ・移行・負荷試験：中規模で800万〜2,000万円です。
• ERP・WMS連携、大量データ、監査ログ、段階移行：高要件で2,000万〜5,000万円超です。

期間の目安は、PoCで2週間〜2か月、小規模で2〜4か月、中規模で4〜8か月、高要件で8〜18か月程度です。その期間は、要件の確定の速さや発注者のレビュー体制、データ品質、外部会社との調整によって変わります。

費用だけでなく、いつまでにどの業務を使えるようにするかを基準に、段階的な導入を検討します。

見積内訳での工程と周辺サービスの分け方

開発費の工程配分とクラウド利用料は、別々の前提で確認します。工程配分は、案件の条件によって変わる検討の起点です。

• 要件定義：開発費の10〜15%程度です。
• 設計：25〜35%程度です。
• 製造・単体テスト：30〜40%程度です。
• 結合・総合テスト：15〜20%程度です。
• 移行・教育：5〜10%程度です。

これは一般的な工程配分を、Cloud Run案件に当てはめた推定です。

画面より連携や移行が多い案件では、設計とテストの割合が上がります（出典: リサーチノート「Cloud Runのシステム」、2026年8月作成）。

クラウド利用料は、CPU秒とメモリGiB秒、リクエスト数で変わります。転送量、リージョン、課金方式によっても変わります。

料金ページには、従量課金や無料枠、リージョン別料金、同一リージョン内の転送の扱いが示されています（出典: Google Cloud「Cloud Run pricing」、2026年8月確認）。

単純な試算として、1 vCPU、0.5GiBのインスタンスを1か月連続で稼働させると、無料枠を差し引いたCPUとメモリ分は月27〜30米ドル程度です。

1ドル=150円と仮定すると約4,000〜4,500円になりますが、これは比較用の計算にすぎません。

実際には、Cloud SQLやロードバランサー、Cloud Logging、Artifact Registryの費用が加わります。加えて、VPC接続やバックアップ、外向き通信の費用もかかります。

月額インフラ費と保守費の予算の分け方

月額インフラ費は、稼働の形態と可用性で大きく変わります。自社の想定に近い構成のレンジを見て、予算の幅を決めます。

• 小規模・低トラフィック：月2万〜10万円です。
• 中規模：月10万〜50万円です。
• 常時稼働・高可用性・大量連携：月50万〜150万円超です。

正式な予算化では、料金計算ツールにリクエスト数やCPU、メモリを入力します。転送量やデータベース容量も入力します。上記の金額は、Cloud Run単体ではなく、周辺サービスを含む推定です。

保守費は、初期開発費の年10〜20%程度を目安にする考え方があります。監視、障害・脆弱性対応、軽微改修、クラウド利用料は、一括りにせず分けて見ます。

平日営業時間のみの問い合わせ対応と、24時間365日の障害対応では、体制も費用も変わります。見積書は、初期費用と月額利用料、保守契約、追加改修を分けて出してもらいます。

Cloud Runのシステム開発で見積もりを取るポイント

機能数だけで見積もりを比べると、判断を誤るおそれがあります。そのため、要件定義とクラウド設計、開発、移行の範囲をそろえて、複数社へ依頼します。テストや教育、運用も、範囲をそろえて比べます。

移行や監視が別料金になっていれば、安く見えても総額は変わります。含まれる作業と除外条件を、同じ前提で確認します。

見積依頼書に書く業務・データ・非機能の前提

見積依頼書には、対象範囲と業務条件を記載します。Cloud Runに載せる機能と、既存システムやSaaSに残す機能は、図で示します。

• 業務・利用者：対象業務と利用者数を記載します。
• 機能・連携：画面、API、外部連携先を示します。
• データ：件数、移行対象期間、個人情報の有無。
• 稼働条件：リージョン、稼働時間、目標応答時間を記載します。

開発・ステージング・本番の環境数も、見積対象に含めます。CI/CDとTerraformも対象です。監視、アラート、バックアップ、脆弱性スキャン、障害訓練も含めます。

認証方式、Ingress、VPC、サービスアカウント、Secret Manager、ログ保存期間は、後から加えると設計変更になりやすい項目です。

契約前に確認する成果物と責任分界

納品物には、ソースコードのほかにも資料があります。契約前に、次の資料と権利の扱いを確認します。

• 実装・構成：Dockerfile、イメージ管理方法、TerraformなどのIaC、構成図。
• 仕様・検証：API仕様、データ項目定義、テスト結果。
• 運用：操作マニュアル、障害復旧手順。
• 所有・利用：ソースコードとクラウドアカウントの所有者、ライセンス、再利用範囲。

マスタや過去データについては、抽出、変換、正しさの承認を誰が担うかを分けて記載します。障害時に開発会社が担当する範囲も、アプリやCloud Run、Cloud SQL、ネットワーク、外部APIごとに明確にします。

復旧目標や連絡可能な時間帯、再委託先、クラウド請求の支払い主体も確認します。責任範囲を先に合意しておくと、稼働後の認識違いを防ぐ助けになります。

Cloud Run以外の設計力を含めた開発会社の比較

開発会社は、資格数やパートナー表示を参考にしながら、実績、周辺設計、移行、テスト、引き継ぎへの対応力を確認します。

• 本番実績：Cloud Runの事例を匿名でも説明できるか。
• 周辺設計：Cloud SQLやネットワークを自社で設計できるか。
• 移行・テスト：データ移行と業務テストを担当できるか。
• 運用引き継ぎ：稼働後の受け渡しを用意できるか。

提案時には、サービスとJobsの分割理由、最大インスタンス数、障害時の切り戻し方法を質問します。回答の具体性から、技術力の差が見えてきます。

相見積もりでは、機能、納期、初期費用、クラウド費、保守費を並べて比べます。担当体制、納品物、リスクも比べます。あわせて、不明点への回答の速さや質問の深さも評価します。

要件の曖昧さを残したまま安価に見せる会社より、追加条件と変動要因を示す会社のほうが、最終予算を管理しやすい傾向があります。

Cloud Runのシステム開発でよくある質問

Cloud RunはWebアプリやAPIのほか、データ連携や業務バッチにも使えます。用途によって、必要なサービスや費用、運用方法が異なります。

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

本番運用では、コンテナイメージやポート、環境変数、ログ、プロセス終了、依存ライブラリの理解が必要です。すべてを自社で習得する必要はありません。

開発会社やGoogle Cloudのビルドサービスを利用する方法もあります。その場合でも、発注者はDockerfileやイメージの更新方法、脆弱性対応の担当者を確認しておきます。

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

移行できる可能性はありますが、アプリをコンテナで動く状態へ改修する必要があります。ローカルディスク保存、固定IP接続、常時稼働プロセス、OS依存ライブラリ、共有セッションは、それぞれの特性に合わせて変更します。

移行前にアプリの構成を洗い出し、PoCを行います。移行対象と既存環境に残す対象を分けるのが、安全な進め方です。

Cloud Runのシステムは月数千円で運用できますか？

CPUとメモリの費用だけなら、低負荷でスケール・トゥ・ゼロを使う構成は小さく始められる場合があります。ただし、業務システムでは周辺サービスの費用も発生します。

Cloud SQL、ログ、バックアップ、ネットワーク、認証、監視などの費用が加わります。月2万〜10万円の小規模レンジを検討する場合でも、利用者数とデータ量をもとに、料金計算ツールで再計算します。

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

使える可能性はありますが、Cloud Runを採用するだけで法令対応が済むわけではありません。データの種類や保存先、リージョン、バックアップ先を確認します。さらに、権限や監査ログ、委託先と再委託先、社内規程も確認します。

Google Cloudの暗号化やIAMに加えて、個人情報保護法や業界ガイドラインに沿った運用を設計します。契約前に、責任の範囲も合意しておきます。

Cloud Runのシステム開発の段階的な進め方

開発は、コンテナのデプロイ方法より先に、業務目的と非機能要件の整理から始めます。要件整理では、業務やデータ、権限、復旧目標を決めます。

選定でCloud Runの範囲を定めたうえで、設計・開発にステートレス、CI/CD、IAM、Secret Manager、監視を組み込みます。

6フェーズの一つの計画へのまとめ

6フェーズごとに、責任者と完了条件を置きます。特に、データ移行、負荷・復旧テスト、監視通知、運用引き継ぎは、見積もりから外さないことが大切です。

小さなPoCで効果とリスクを確かめてから本開発へ進むと、予算と納期の不確実性を抑えられます。

発注前に確認するチェック項目

見積書と契約書では、対象業務、機能範囲、利用料の前提、データ移行担当、ソースコードとIaCの納品を確認します。

監視時間、障害時のSLA、再委託、クラウドアカウントの所有者も確認します。自社で運用の判断ができるかまで評価しておくと、長く使いやすいシステムになります。

▼全体ガイドの記事
・Cloud Runのシステム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。