相談する

Cloud Runのシステム開発の発注/外注/依頼/委託方法について

Cloud Runのシステムを発注するときは、業務要件と責任範囲を整理したうえで、契約と納品の条件を発注者と開発会社で合意します。さらに、技術検証と段階的な開発を経ると、要件の手戻りを抑えやすくなります。

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

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

Cloud Runのシステムを発注するときの全体像

Cloud Runのシステムは、画面やAPIを動かすサービスと、定期処理用のJobsを組み合わせて構成します。さらに、Cloud SQLやFirestore、Cloud Storageなども併せて使います。

「Cloud Runで作る」と決めたままだと、周辺の設計や運用が見積もりから抜けてしまいます。そのため、発注の前に、目的と、どこまでを誰が受け持つかを言葉にしておきます。

Cloud Runと業務システム全体の範囲

Cloud Runは、DockerなどのコンテナをGoogle Cloud上で実行するフルマネージド基盤です。また、HTTPSで公開でき、リクエストに応じてインスタンスを増減できます。

一方で、顧客マスタ、受注データ、権限、画面項目、承認ルールは、発注者と開発会社が設計します。「サーバー管理が不要」であっても、OSの更新や台数調整以外の作業は残ります。

特に、DBのバックアップ、IAM、秘密情報、監視通知、障害復旧、コンテナの脆弱性対応は必要です。これらを理解して発注すると、安い見積もりの後に追加費用が生じる事態を避けやすくなります。

サービス、Jobs、周辺サービスの分け方

処理の役割に応じて、Cloud RunのサービスやJobs、周辺サービスを分けて考えます。

  • Cloud Runサービス：HTTP応答が必要な画面やAPIを動かす役割です。
  • Cloud Run Jobs：夜間集計や帳票生成など、処理を行って終了する仕事を担います。
  • 周辺サービス：大量のイベントはPub/Sub、分析はBigQuery、ファイルはCloud Storageが受け持ちます。

なお、公式資料でもCloud RunはService、Job、Worker poolの3種類に整理されています（出典: Google Cloud「What is Cloud Run」、2026年確認）。この分類をRFPの構成図に反映し、Cloud Runへ載せるものと載せないものを明記すると、提案を比べやすくなります。

発注形態の選び方

発注形態は、要件を決める社内担当者がいるかどうかや、初期段階で仕様を固められるかで選びます。また、既存システムとの連携の複雑さや、運用を担う人も判断材料になります。

Cloud Runを採用するかどうかより、発注者の意思決定力と案件の不確実性が契約方式に影響します。

一括請負が向く案件

一括請負は、決めた仕様に基づいて開発会社が成果物を完成させ、検収を受ける方式です。画面項目、API入出力、権限を具体化できる案件に向きます。テスト条件や納期まで決められるなら、この方式に合います。

小規模な業務システムや、実証の後に仕様が固まった本開発で選びやすい方式です。業務ルールが未整理のままだと、仕様変更が契約の範囲外になりやすくなります。

構成や移行の難易度が不明な場合は、要件定義だけを先に発注します。その成果物をもとに、本開発の請負見積もりを取り直す二段階方式が安全です。

準委任・時間単価型が向く案件

準委任や時間単価型は、役割と稼働時間を定め、要件整理、設計、開発、改善を一定期間進める方式です。

既存アプリのコンテナ化や段階的な移行、AI機能の検証がある案件では、この方式が使いやすいです。利用部門の意見を取り入れながら改善していく社内システムにも使えます。

  • 契約条件：稼働時間に応じて費用が増えるため、月ごとの上限と追加承認を定めます。担当者と定例会、課題管理の方法も決めておきます。
  • 月次成果：準委任でも納品物は必要で、設計書、テスト結果、TerraformなどのIaC、ソースコード、運用手順書を定義します。

PoCと段階発注による採用リスクの抑え方

既存アプリへの適合が分からない場合は、2週間から2か月程度の技術検証を先に発注します。

  1. コンテナ化、Cloud SQLなどへの接続、認証、ログ、代表画面の応答を確かめます。
  2. 負荷、概算利用料、障害時の再実行を確かめ、本番開発の判断材料にします。PoCは本番品質の完成版ではありません。
  3. 検証コードを本番へ移すか作り直すかを決め、成果物の権利と再利用範囲を発注書に定めます。
  4. 利用部門と要件を確認しながら段階的に拡張し、要件不足による手戻りを抑えます。

ポイント

仕様を決めきれる案件は一括請負、固まらない案件は準委任や段階発注を選びます。不確実性が大きいときは、技術検証を先に発注して判断材料をそろえます。

RFPと要件整理の内容

RFPに記載する業務要件、技術環境、セキュリティ、データ移行と運用分担を4枚のカードで示した図。
4領域をそろえると各社の提案条件を合わせやすくなります。

RFPは、何を、なぜ、どの条件で依頼するかを伝え、同じ前提で提案と見積もりを受けるための文書です。

技術用語だけでなく、利用者、業務課題、データ、連携先を業務の側面から書きます。さらに、品質条件や発注範囲も同じ細かさで記すと、見積もりを比べやすくなります。

利用者と業務フローから始める業務要件

業務要件は、誰が、いつ、何を入力し、誰が承認し、どのデータを次の業務へ渡すかを整理するところから始めます。そのうえで、利用者ごとに権限や利用時間を洗い出し、個人情報、帳票、例外処理も書き出します。

画面一覧に業務フロー図と代表シナリオを添えると、必要な機能とテスト条件が相手に伝わります。また、現状の作業時間、件数、ピーク時間、月間データ量も、RFPに記します。

連携先、許容停止時間、目標復旧時間も明記します。性能は、たとえば「通常時は3秒以内、繁忙時に同時100ユーザーでも継続」のように書きます。数値で示すと、性能試験と受入条件につながります。

Cloud Runとセキュリティの要件の分け方

RFPでは、技術要件とセキュリティ要件を分けて具体化します。

  • 技術環境：実行環境、サービスとJobs、DB、ファイル保存先、外部API、開発・検証・本番を記します。
  • 運用・データ：CI/CD、監視、バックアップ、ログ保存期間を定め、インスタンスに業務データを残さず外部保存します。
  • セキュリティ：公開範囲、Ingress、IAM、サービスアカウントを定めます。Secret Manager、暗号化、監査ログ、脆弱性スキャンも含めます。
  • 公開と法令：個人情報とバックアップの保存場所を確かめたうえで、社内向けは内部経路、取引先向けはロードバランサー、TLS、レート制限などを検討します。

法令への対応は、Google Cloudの暗号化やデータレジデンシーに加えて、社内規程と個人情報保護委員会のガイドラインに沿って進めます。また、委託先と再委託先の管理責任も、RFPに含めます。

RFPで定めるデータ移行と運用分担

移行対象と移行後の照合担当を決め、運用分担と本番操作の手続きもRFPに記載します。

  • 移行範囲：顧客、商品、部署、権限、取引先、コード体系から、移行するデータと廃棄するデータを決めます。
  • 移行の役割：発注者がデータの意味を確認し、開発会社が変換プログラムを作るなど、件数や内容の照合者も定めます。
  • 運用分担：監視時間、一次受付、障害の重大度、連絡経路、復旧目標を記します。費用負担、軽微な改修、脆弱性対応も含めます。
  • 本番操作：作業の申請と承認、操作ログ、緊急時の事後報告を決め、保守範囲の認識違いを防ぎます。

ポイント

RFPには、業務要件から技術、セキュリティ、データ移行と運用分担までを具体的に書きます。各社の提案と見積もりを同じ前提で比べるためです。

契約形態と納品物の決め方

開発費だけでなく、成果物や仕様変更、障害対応の扱いを契約で明確にします。また、クラウドアカウントとデータの保有者も、あらかじめ決めておきます。

契約名で判断せず、個別契約書、仕様書、見積書、検収条件、保守契約を一体として確認します。

納品物と検収条件の具体化

納品物の一覧と、受入時に確認できる検収条件を契約に記載します。

  • 設計・運用資料：要件定義書、画面・API仕様、データモデル、移行計画、運用設計、障害対応手順を納品対象にします。
  • 実装・テスト成果：テスト計画と結果、ソースコード、コンテナ定義、TerraformなどのIaC、CI/CD、監視設定を含めます。
  • 検収基準：主要業務シナリオ、重大不具合、性能条件、移行後の件数照合などを、確認できる形で定めます。
  • 受入テスト：発注者が行う場合は、テストデータ、参加部門、期間、修正後の再テストの役割を決めます。

構成をコードで再現できれば、将来の委託先変更や環境再構築に備えられます。

アカウント、知的財産権、再委託の条件

アカウントの所有者、成果物の権利、再委託先と実装担当者を、契約前に確認します。

  • アカウント：発注者が本番プロジェクト、ドメイン、データ、秘密情報を管理し、必要な権限だけを付与します。
  • 所有と移管：開発会社名義のままだと、移管や料金確認、権限解除が難しい場合があります。そのため、検証環境と本番の所有者も確かめます。
  • 知的財産権：ソースコード、設計書、IaC、テスト成果物、第三者ライブラリ、生成AIコードの権利や利用許諾を定めます。
  • 再委託：再委託先の所在、作業範囲、個人情報へのアクセス、秘密保持、事故時の責任、実担当者の経験を見ておきます。

SLAと保守範囲の切り分け

保守の対象範囲と対応時間を決め、障害時の役割を手順書に残します。

  • 保守対象：問い合わせ、障害復旧、クラウド設定、脆弱性対応を含めます。軽微修正、機能追加、データ修正は、区別して書きます。
  • 対応条件：月額内と別見積もりを分け、受付・初動・復旧目標、報告方法、対象外作業を定めます。
  • 障害対応：DB容量不足、API停止、権限ミス、バッチ二重実行時のログ確認、連絡、切り戻しを決めます。

24時間365日対応か営業時間内かで、保守費用と体制は大きく変わります。

ポイント

契約では、開発費に加えて成果物、障害対応、アカウントとデータの保有者を決めておきます。契約名で判断せず、関連書類を一体で読み比べます。

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

Cloud Runシステムの技術検証から高要件まで、開発費の推定レンジを4本の横棒で示した図。
規模ごとの機能や運用条件をそろえて見積もりを比べます。

Cloud Run単体の日本向け開発費を示す公的統計は確認できません。ここでの金額は、工程と周辺設計の範囲から組み立てた編集用の推定レンジです。

画面数や権限、外部連携、データ移行によって費用は変わります。また、品質要件、運用時間、既存コードの状態も影響します。そのため、同じRFPで各社を比べ、相場を発注価格とみなさないようにします。

規模別の開発費の推定レンジ

規模と含まれる機能によって、推定レンジは異なります。各規模の前提と費用を、見積もりを比べる観点にします。

  • PoC・小規模：技術検証は100万〜300万円、小規模は300万〜800万円です。小規模の範囲には、簡易画面、API、認証、DB、基本監視が含まれます。
  • 中規模：複数ロール、外部API、バッチ、移行、負荷試験、運用設計を含み、800万〜2,000万円です。
  • 高要件：ERP・WMS連携、大量データ、監査ログ、段階移行、24時間運用を含み、2,000万〜5,000万円超の場合があります。

Cloud Runを使っても、コンテナ化、IAM、ネットワーク、移行、監視、業務テストの工数は残ります。OS更新やサーバー台数の管理が減っても、それだけで開発費全体が安くなるとは限りません。

見積もりには、要件定義、基本・詳細設計、製造、テストが入っているかを確かめます。そのほか、移行、教育、管理、保守準備も含まれるかを見ます。

Cloud Runの利用料と周辺サービス費の内訳

利用料は課金方式や利用量で変わり、周辺サービス費も別にかかります。そのため、試算の条件を分けて確認します。

  • 料金の決まり方：無料枠、リージョン、リクエスト課金かインスタンス課金か、転送量で変わります。
  • 無料枠と周辺費：無料枠は月240,000 vCPU秒・450,000 GiB秒と示されています。周辺料金は、別途確かめます。
  • 単純試算：1 vCPU・0.5GiBの連続稼働では、コンピュート部分が月数千円程度の場合があります。比較用の理論値です。
  • 月額の検討幅：小規模は月2万〜10万円、中規模は月10万〜50万円、高要件は月50万〜150万円超です。

公式料金は、CPU秒やメモリGiB秒などの利用量を基準に計算されます（出典: Google Cloud「Cloud Run pricing」、2026年8月確認）。

周辺費には、Cloud SQL、ロードバランサー、Cloud Logging、Artifact Registry、VPC接続、バックアップがあります。そのうえで、利用量を料金計算ツールに入れ、為替や仕様変更も踏まえて再計算します。

保守費と追加改修費の切り分け

保守費は範囲と体制によって変わるため、初期開発費と分けて検討します。

  • 目安：初期開発費の年10〜20%程度とする考え方がありますが、一律の統計ではありません。
  • 保守範囲：監視、障害復旧、脆弱性、クラウド設定、軽微改修、問い合わせの有無で体制が変わります。
  • 費目の分離：月額保守、クラウド費、ライセンス、外部SaaS、追加開発を分け、時間外対応などの対象外も確かめます。
  • 長期費用：初年度だけでなく3年間の総保有コストと、契約終了時の引き継ぎ費用も比べます。

ポイント

費用は規模や機能、運用条件で変わるため、同じRFPで各社の見積もりを比べます。利用料、周辺サービス費、保守費は、開発費と分けて検討します。

Cloud Runの委託先と見積書の比較方法

Cloud Run委託先を業務理解、本番実績、保守運用、見積もりの透明性の4観点で示したパネル図。
同じRFPと質問票を使うと、各社の強みと前提を見比べられます。

委託先は、資格数や知名度だけでなく、業務理解と本番実績を見て比べます。そのほか、コンテナやDB、ネットワークの設計、保守運用、見積もりの透明性も確かめます。

技術に詳しくても業務を理解していなければ、使われない画面や移行できないマスタが残ってしまいます。

本番事例と実装担当者の確認

本番事例と実際の担当者を見て、案件に合う得意分野かを見極めます。

  • 実績と設計：匿名化した事例で、サービスとJobs、DBとセッション、ピーク負荷試験を尋ねます。
  • 運用と成果物：障害時のログや指標、Terraformやソースコードの納品実績を確認します。
  • 担当者：今回のエンジニアが、事例と同じ設計判断を説明できるかどうかを見ます。
  • 得意領域：既存移行はコンテナ化、新規開発は業務設計、高可用性はネットワークと運用を重視します。

アプリ会社、クラウド基盤会社、総合SIerでは、得意分野が異なります。そこで、候補を3〜5社程度に絞り、同じRFPと質問票で提案を受けます。強みと前提条件を並べて見られます。

見積書の前提と工数の比べ方

見積もりは、項目、工数、対象範囲、システム前提をそろえて比較します。

  • 費用項目：要件定義、設計、製造、テストを照合します。移行、教育、管理、保守準備も、そろっているか見ます。
  • 工数と範囲：人日、単価、担当ロール、期間、成果物、対象外作業を確認します。
  • システム前提：サービス・Jobs数、DBの種類とサイズ、環境・連携・ユーザー数、移行件数をそろえます。
  • 追加費用：テスト範囲、保守時間、クラウド費を比べ、移行や監視などが別見積もりか確認します。

前提の違う見積もりを価格順に並べると、追加費用を見落とします。そのため、価格差が機能削減によるものか、工数不足によるものかを質問します。

避けたい委託先と発注前の質問

技術選定の理由だけでなく、費用、体制、責任の範囲を具体的に質問します。

  • 提案の妥当性：「Cloud Runを使わないほうがよい要件は何か」「GKEやCompute Engineとの比較理由は何か」と尋ねます。
  • 見積もりと成果物：納期・総額の根拠、利用料と周辺費用、納品物やソースコードを確認します。
  • 体制と責任：再委託先と保守担当、移行時に自社が準備するもの、障害時の責任の範囲を聞きます。
  • 運用終了時：料金超過の検知方法と、契約終了時に引き継ぐものを尋ねます。

業務課題と結び付けず技術名だけを強調する会社や、要件を詰めずに納期と総額を断定する会社には注意します。また、採用しない選択肢やリスクも説明できる会社を選びます。

ポイント

委託先は、業務理解や本番実績、設計、保守運用、見積もりの透明性で比べます。見積書は金額だけでなく、前提と工数をそろえて見ます。

発注後の開発の流れ

発注後は、要件定義と設計を経て開発に入ります。テストと移行は、開発のあとに行います。リリースを経て、保守に移ります。また、早い段階で代表機能を動かし、不確実性を小さく検証します。

設計書の確認に加えて、認証、DB接続、ログ、デプロイ、費用見込みを実際に動かして確かめます。技術上のリスクを減らすためです。

設計と開発での環境と責任の範囲

環境ごとの権限とデプロイの経路を定め、周辺サービスも含めて性能を確かめます。

  • 環境と権限：開発・ステージング・本番を分け、操作担当を定め、イメージをArtifact Registryへ保存します。
  • デプロイ：Cloud BuildやGitHub Actionsでテストとデプロイを自動化し、本番変更には承認を設けます。
  • 設定管理：秘密情報や設定値をソースに直接書かず、環境ごとに管理します。
  • 性能条件：DBスキーマ、バッチの再実行、APIタイムアウト、二重実行、スケール上限と接続数を検証します。

Cloud Runの自動スケールでは、DB接続数や外部サービスの上限を超える可能性があります。そのため、アプリと周辺サービスを含めて性能を確認します。

テスト、移行、リリースの計画

テスト、移行、リリース後の確認項目を順に決め、業務への影響を抑えます。

  1. まず、業務シナリオ、権限、負荷、障害と復旧、バックアップ復元をテストします。
  2. 本番前にリビジョン切替、切り戻し、ログ、アラートを確認し、担当者が手順を再現します。
  3. バックアップ、変換、件数照合、エラー一覧、再移行、旧システムの参照期間を決め、移行リハーサルで切替時間と条件を確かめます。
  4. 稼働後は問い合わせを集めて改善し、構成と費用が業務量に合うかを定期的に見直します。

最新機能を採用するかどうかは、業務目的と運用上の確認事項を照らし合わせて判断します。

  • 機能の選択肢：Cloud Runの機能拡張も候補になります。
  • 導入前の確認：権限、監査ログ、データ品質、推論結果、費用上限、障害時の代替手順を決めます。
  • AI利用例：推論処理の配置より、誤分類の確認担当、個人情報の送信先、結果を業務データとして保存するかを優先して決めます。
  • データ連携例：e5事例は、連携構成を検討する際の参考になります。

2026年の公式発表では、AIエージェント、リモートMCP、GPU、フルスタックアプリなどが紹介されています（出典: Google Cloud Blog「What’s new for Cloud Run at Next ’26」、2026年4月）。

Google Cloudのe5事例では、Cloud Runで他サービスのAPIデータを取り込み、DataformとBigQueryで整形しています（出典: Google Cloud「e5 case study」、2026年確認）。

単一のサービスだけでなく、業務データの流れ全体から発注範囲を決めます。

よくある質問（FAQ）

費用、既存システム、発注先、契約について、相談前に確認されやすい質問をまとめます。

Cloud Runのシステム開発は小規模ならいくらですか？

画面、API、認証、DB、基本監視、少数のデータ連携を含む小規模業務システムは、300万〜800万円を推定レンジとして検討できます。

データ移行、複雑な権限、外部連携、厳しい可用性要件が加われば費用は増えます。要件定義と見積もりは、分けて確認します。

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

コンテナ化できるWebアプリやAPIは移行候補です。ただし、そのまま移せるとは限りません。ローカルファイル、固定IP、常時接続、長時間処理、OS依存、セッション保持の有無を確かめます。

移行後の役割は、Cloud RunのサービスやJobs、他のGoogle Cloudサービス、GKE、Compute Engineに分けて考えます。

開発会社へ依頼する前にRFPは必要ですか？

複数社から提案と見積もりを取るなら、簡易なRFPも用意することをおすすめします。目的、利用者、業務フロー、データ、連携を書き、希望時期と予算の考え方も示します。

RFPにセキュリティ、移行、運用、提案範囲も記すと、各社の見積もりを同じ条件で比べられます。

Cloud RunとGKEはどちらを選べばよいですか？

Web画面、API、イベント処理、定期バッチなど、コンテナを実行して自動スケールさせたい業務では、Cloud Runを検討できます。

複雑なクラスタ制御、特殊なネットワーク、常時稼働ワーカー、長時間処理が中心であれば、GKEやCompute Engineが適する場合があります。

発注先には、Cloud Runを使う理由と、使わない場合の比較も説明してもらいます。

まとめ

発注時は、Cloud Runだけでなく画面やAPI、Jobs、DBも含めて考えます。そのうえで、認証、ネットワーク、監視、バックアップ、移行、運用まで、一つのシステムとして整理します。

業務フロー、利用者、データ、品質条件をまとめ、必要に応じてPoCや要件定義を先に依頼します。

発注前にそろえる情報

発注前には、目的と業務フロー、利用者を整理します。そのうえで、利用者ごとの権限と現行システムを書き出します。連携先と移行の範囲も確かめておきます。ピーク利用量は数値で、セキュリティは条件で書いておきます。RTOとRPOで、障害時の目標も示します。また、時期、予算、運用時間も整理しておきます。

開発会社には、Cloud RunサービスとJobsの分割理由や、GKEやVMとの比較を質問します。さらに、周辺費用、体制、再委託、成果物、契約終了時の引き継ぎも確かめておきます。

相見積もりの前提のそろえ方

費用の推定レンジと見積もり条件をそろえ、契約後の運用も見通して委託先を選びます。

  • 費用レンジ：PoCは100万〜300万円、小規模は300万〜800万円、中規模は800万〜2,000万円です。
  • 見積もり条件：要件定義、移行、テスト、監視、保守、Cloud Run以外の利用料を確認します。
  • 委託先：同一条件のRFPで3〜5社を比べ、業務定着と契約終了後の運用まで見通せる会社を選びます。

ここに挙げた金額は推定レンジです。そのため、根拠のない総額を断定せず、同じ条件で比べます。

▼全体ガイドの記事
・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を創業。