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

Cloud Runのシステム開発を発注するなら、Cloud Run単体ではなく、アプリケーション、データベース、認証、ネットワーク、監視、データ移行、運用までを含む業務システム全体の責任範囲を決めることが重要です。

Cloud Runはコンテナを実行する基盤であり、業務フローやデータの持ち方まで自動で決めてくれる製品ではありません。本記事では、発注形態の選び方、RFPと要件の整理、契約形態、費用相場、委託先の選定、見積書の比較方法を、発注者の実務に沿って解説します。

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

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

Cloud Runのシステムは、業務画面やAPIを動かすCloud Runサービス、定期処理や帳票生成を担うCloud Run Jobs、データを保存するCloud SQLやFirestore、ファイルを保管するCloud Storageなどを組み合わせて構成します。発注時に「Cloud Runで作ってください」とだけ伝えると、周辺の設計や運用が見積から抜けるため、システムの目的と責任分界を先に言語化します。

Cloud Runは、Dockerなどで用意したコンテナをGoogle Cloud上で実行するフルマネージドのアプリケーション基盤です。HTTPSのエンドポイントを公開し、リクエストに応じてインスタンスを増減させられますが、顧客マスタ、受注データ、権限、画面項目、承認ルールなどは発注者と開発会社が設計しなければなりません。

「サーバー管理が不要」という説明も、OSのパッチ適用やサーバー台数の調整を自社で行う場面が減るという意味です。データベースのバックアップ、IAMの設計、秘密情報の管理、監視通知、障害時の復旧、コンテナイメージの脆弱性対応まで不要になるわけではありません。この違いを発注前に理解すると、安すぎる見積もりを選んで後から追加費用が発生する事態を避けやすくなります。

業務画面やAPIのようにHTTPリクエストへ応答する処理はCloud Runサービス、夜間集計や請求書作成のように処理して終了する仕事はCloud Run Jobsに分けると、画面の応答性とバッチの実行条件を管理しやすくなります。大量のイベントを処理する場合はPub/Sub、分析はBigQuery、ファイルはCloud Storageというように、役割ごとにサービスを組み合わせます。

Google Cloudの公式ドキュメントも、Cloud RunをService、Job、Worker poolの3種類として整理しています（出典: Google Cloud「What is Cloud Run」、2026年確認）。この分類をRFPの構成図に反映し、「何をCloud Runへ載せるか」だけでなく「何を載せないか」も明記すると、開発会社ごとの提案を比較しやすくなります。

発注形態は何を基準に選べばよいですか？

発注形態は、社内に要件を決める人がいるか、既存システムとの連携が複雑か、運用を誰が担うか、初期段階で仕様を固められるかを基準に選びます。Cloud Runを採用するかどうかよりも、発注者側の意思決定能力とプロジェクトの不確実性のほうが、契約方式に強く影響します。

一括請負は、定めた仕様に基づいて開発会社が成果物を完成させ、検収を受ける発注形態です。管理画面の項目、APIの入出力、権限、テスト条件、納期などを発注前に具体化できる小規模な業務システムや、実証後に仕様が固まった本開発で選択しやすい方式です。

ただし、業務ルールが未整理のまま「一括で安く作ってほしい」と依頼すると、仕様変更が契約範囲外になりやすくなります。Cloud Runの構成やデータ移行の難易度が不明な段階では、要件定義だけを先行発注し、その成果物をもとに本開発の請負見積もりを取り直す二段階方式が安全です。

準委任や時間単価型は、稼働するエンジニアの役割と時間を定め、要件整理や設計、開発、改善を一定期間進める方式です。既存アプリのコンテナ化、段階的な移行、AI機能の検証、利用部門の意見を反映しながら進める社内システムでは、仕様を固定しすぎない利点があります。

一方で、作業時間が増えれば費用も増えるため、月ごとの稼働上限、担当者、成果物、定例会、課題管理、追加承認の条件を契約書や個別発注書に落とします。「準委任だから納品物は不要」と考えず、設計書、テスト結果、TerraformなどのIaC、ソースコード、運用手順書を月次の成果として定義することが重要です。

Cloud Runが既存アプリに適するか分からない場合は、2週間から2か月程度の技術検証を先に発注します。検証では、コンテナ化、Cloud SQLなどへの接続、認証、ログ出力、代表的な画面の応答、負荷、概算利用料、障害時の再実行を確認し、本番開発へ進む判断材料を作ります。

PoCを本番品質の完成版と誤認しないことも大切です。検証で作ったコードをそのまま本番へ移すのか、設計を見直して作り直すのか、PoCの成果物の権利と再利用範囲を発注書に書きます。小さく始めて、利用部門と一緒に業務要件を確認しながら段階的に拡張するほうが、要件定義不足による手戻りを抑えやすくなります。

RFPと要件整理では何を決めるべきですか？

RFPは、開発会社へ「何を、なぜ、どの条件で依頼したいか」を伝え、同じ前提で提案と見積もりを出してもらう文書です。技術用語を並べるより、利用者、業務上の課題、データ、連携先、品質条件、発注範囲を同じ粒度で書くほうが、見積もりの比較可能性が高まります。

最初に、誰が、いつ、何を入力し、誰が承認し、どのデータを次の業務へ渡すのかを整理します。営業担当、管理者、取引先、経理などの利用者ごとに、操作権限、利用時間、扱う個人情報、必要な帳票、例外処理を洗い出します。画面一覧だけでなく、業務フロー図と代表的なシナリオを添えると、開発会社が必要な機能とテスト条件を把握しやすくなります。

RFPには、現状の作業時間、件数、ピーク時間、月間データ量、連携する基幹システム、許容停止時間、目標復旧時間も記載します。たとえば「速い画面」ではなく「通常時は3秒以内、繁忙時間に同時100ユーザーでも業務を継続できる」と表現すると、性能試験と受入条件へつなげられます。

技術要件には、コンテナの実行環境、サービスとJobsの分け方、データベース、ファイル保存先、外部API、開発・検証・本番の環境、CI/CD、監視、バックアップ、ログ保存期間を記載します。Cloud Runのインスタンスは使い捨てを前提とし、ローカルファイルやメモリに業務データを残さず、永続データを外部サービスへ保存する設計を要求します。

セキュリティ要件では、公開範囲、Ingress、IAM、サービスアカウント、Secret Manager、暗号化、監査ログ、脆弱性スキャン、個人情報の保存場所とバックアップ場所を確認します。社内利用なら内部向けの経路に限定し、取引先へ公開するならロードバランサー、TLS、レート制限などを含めます。Google Cloudが提供する暗号化やデータレジデンシーだけで法令対応が完了するわけではないため、社内規程と個人情報保護委員会のガイドラインに沿って、委託先・再委託先の管理責任もRFPへ入れます。

業務システムの発注で見落とされやすいのが、既存マスタと履歴データの移行です。顧客、商品、部署、権限、取引先、コード体系のどれを移行し、どのデータを廃棄し、移行後に誰が件数と内容を照合するのかを決めます。発注者がデータの意味を確認し、開発会社が変換プログラムを作るなど、役割を分けて書かないと、移行直前に責任の押し付け合いになりやすくなります。

運用については、監視する時間帯、一次受付、障害の重大度、連絡経路、復旧目標、クラウド費用の支払い、軽微改修の範囲、定期的な脆弱性対応を明記します。開発会社が本番環境を操作する場合は、作業申請、承認、操作ログ、緊急時の事後報告まで決めます。これらを発注段階で合意すると、納品後に「そこまで保守に含まれると思っていた」という認識違いを防げます。

契約形態と納品物はどのように決めますか？

Cloud Runの発注では、開発費だけでなく、何を成果物とみなすか、仕様変更をどう扱うか、障害時に誰が対応するか、クラウドのアカウントとデータを誰が保有するかを契約で明確にします。契約形態の名称だけで安全性を判断せず、個別契約書、仕様書、見積書、検収条件、保守契約を一つの関係として確認します。

納品物には、要件定義書、画面・API仕様書、データモデル、テスト計画と結果、移行計画、運用設計書、障害対応手順、ソースコード、コンテナ定義、TerraformなどのIaC、CI/CD設定、監視設定を含めるか確認します。特にクラウドの構成をコードで再現できる状態にしておくと、将来の委託先変更や環境再構築に備えられます。

検収条件は「納品されたら検収」ではなく、主要業務シナリオを通過すること、重大な不具合がないこと、性能条件を満たすこと、移行後の件数照合が完了することなど、確認可能な基準にします。受入テストを発注者が行う場合は、テストデータの準備、参加部門、期間、修正後の再テストまで役割を決めます。

Google Cloudの請求先アカウントやプロジェクトを開発会社名義にすると、契約終了時に移管できない、料金の内訳を確認できない、アクセス権を外しにくいという問題が起きます。原則として発注者が本番プロジェクトとドメイン、データ、秘密情報を管理し、開発会社には必要な権限だけを付与する形を検討します。開発会社が用意する検証環境と本番環境の所有者も分けて確認します。

ソースコード、設計書、IaC、テスト成果物の著作権や利用許諾、第三者ライブラリのライセンス、生成AIを使ったコードの扱いも契約に入れます。再委託がある場合は、再委託先の所在、作業範囲、個人情報へのアクセス、秘密保持、事故時の責任を確認します。一次請け会社の説明だけでなく、実際にCloud Run、DB、ネットワークを担当する体制と担当者の経験を聞くことが重要です。

本番稼働後の保守には、問い合わせ対応、障害復旧、クラウド設定変更、脆弱性対応、軽微な画面修正、機能追加、データ修正など異なる作業が混在します。月額保守に含む作業と、別途見積もりになる作業を分類し、受付時間、初動時間、復旧目標、報告方法、対応除外を決めます。

Cloud Runの自動スケールを採用していても、データベースの容量不足、外部APIの停止、権限設定のミス、バッチの二重実行などは起こり得ます。障害時に誰がCloud LoggingとMonitoringを確認し、誰が利用部門へ連絡し、どの条件で切り戻すかを運用手順書に残します。24時間365日の対応が必要か、営業時間内でよいかによって、保守費用と体制は大きく変わります。

Cloud Runのシステム開発費用と月額相場はいくらですか？

Cloud Run単体の日本向け開発費を示す公的な統計は確認できないため、以下は業務システムの工程とCloud Run周辺の設計範囲から組み立てた編集用の推定レンジです。実際の費用は、画面数、権限、外部連携、データ移行、品質要件、運用時間、既存コードの状態で変わるため、相場をそのまま発注価格とみなさず、同じRFPで比較します。

技術検証や小規模PoCは100万〜300万円、簡易な管理画面とAPI、認証、Cloud SQLまたはFirestore、基本監視を含む小規模業務システムは300万〜800万円が検討レンジです。複数ロール、外部API、バッチ、データ移行、負荷試験、運用設計を含む中規模業務システムは800万〜2,000万円、ERPやWMSとの連携、大量データ、監査ログ、段階移行、24時間運用を含む高要件システムは2,000万〜5,000万円超となる場合があります。

このレンジは、Cloud Runだから安いという意味ではありません。OSパッチやサーバー台数管理を減らせる一方で、コンテナ化、IAM、ネットワーク、データ移行、監視、業務テストの工数は残ります。開発費の見積書では、要件定義、基本設計、詳細設計、製造、テスト、移行、教育、プロジェクト管理、保守準備がどの金額に含まれるかを確認します。

Cloud Runの公式料金は、CPU秒やメモリGiB秒などの利用量を基準に計算され、無料枠、選択したリージョン、リクエスト課金かインスタンス課金か、ネットワーク転送で変わります（出典: Google Cloud「Cloud Run pricing」、2026年8月確認）。公式料金表には、無料枠として月240,000 vCPU秒と450,000 GiB秒が示されていますが、Cloud SQL、ロードバランサー、Cloud Logging、Artifact Registry、VPC接続、バックアップなどの料金は別に確認が必要です。

1 vCPU・0.5GiBを連続稼働させる単純試算では、月間のCPU・メモリ使用量をもとに、Cloud Runのコンピュート部分が数千円程度になるケースがあります。しかし、これは比較用の理論値です。実務上の初期予算としては、低トラフィックの小規模構成で月2万〜10万円、中規模で月10万〜50万円、常時稼働・高可用性・大量連携で月50万〜150万円超を検討レンジとし、料金計算ツールで利用量を入れて再計算します。為替や仕様変更もあるため、円換算額を固定的に断定しません。

開発後の保守は、初期開発費の年10〜20%程度を目安に検討する考え方がありますが、これは一般的な検討目安であり、Cloud Run案件に一律適用できる統計ではありません。監視だけを委託するのか、障害復旧、脆弱性対応、クラウド設定、軽微改修、利用部門からの問い合わせまで依頼するのかで必要な体制が変わります。

見積書では、月額保守、クラウド利用料、ライセンス、外部SaaS、追加開発を別行にしてもらいます。月額が安くても、障害対応が時間外別料金、ログ保存が短い、データ復旧が対象外という場合があります。初年度だけでなく、3年間の総保有コストと、契約終了時に自社へ引き継ぐための費用まで確認すると、価格だけでは見えない差を比較できます。

Cloud Runの委託先と見積書はどう比較すればよいですか？

委託先は、Google Cloudの資格数や知名度だけでなく、業務理解、Cloud Run本番実績、コンテナ・DB・ネットワークの設計力、運用保守、見積もりの透明性で比較します。Cloud Runに詳しい会社でも、発注者の業務を理解できなければ、使われない画面や移行できないマスタが残るためです。

候補会社には、Cloud Runを使った本番事例を、匿名化できる範囲で説明してもらいます。確認する質問は、「サービスとJobsをどう分けたか」「DBとセッションをどう設計したか」「ピーク時の負荷試験をどう行ったか」「障害時にどのログとメトリクスを見るか」「Terraformやソースコードを納品したか」です。公開事例を読んだだけでなく、今回の案件を担当するエンジニアが同じ設計判断を説明できるかを見ます。

また、アプリ開発会社、クラウド基盤会社、総合SIerでは得意領域が異なります。既存アプリの移行ならコンテナ化とデータ移行、社内業務の新規開発なら業務設計と定着支援、高い可用性が必要ならネットワークと運用体制を重視します。候補を3〜5社程度に絞り、同じRFPと質問票で提案を受けると、会社ごとの強みと前提条件が見えやすくなります。

見積比較では、まず要件定義、設計、製造、テスト、移行、教育、管理、保守準備の項目がそろっているか確認します。次に、各項目の人日、単価、担当ロール、期間、成果物、含まれない作業を確認します。総額が低い会社ほど、データ移行、負荷試験、監視、運用引き継ぎ、外部サービス費が別見積もりになっていないかを確認します。

比較表には、Cloud Runサービス数、Jobs数、DBの種類とサイズ、環境数、外部連携数、ユーザー数、データ移行件数、テスト範囲、保守時間、クラウド費用の想定を並べます。前提が異なる見積もりを単純に安い順で並べると、実質的な追加費用を見落とします。価格差の理由を質問し、機能を削った差なのか、工数を見込んでいない差なのかを分けて判断します。

Cloud Runを採用する理由を業務課題と結び付けず、技術名だけを強調する会社には注意が必要です。また、要件定義をほぼ行わずに納期と総額だけを断定する、Cloud Runの利用料と周辺サービス費を説明しない、納品物やソースコードの話を避ける、再委託先と保守担当者が不明確という場合も、契約前に前提を確認します。

発注前には、「この要件でCloud Runを使わないほうがよい部分はどこですか」「GKEやCompute Engineと比較した判断理由は何ですか」「データ移行のうち当社が準備するものは何ですか」「障害時の責任分界はどこですか」「Cloud Runの料金が予算を超えた場合にどう検知しますか」「契約終了時に何を引き継げますか」と質問します。都合のよい回答だけでなく、採用しない選択肢やリスクを説明できる会社を選ぶことが大切です。

発注後はどのような流れで開発を進めますか？

発注後は、要件定義、設計、開発、テスト、移行、リリース、保守の順に進めます。ただし、Cloud Runのシステムでは早い段階で代表機能を動かし、認証、DB接続、ログ、デプロイ、費用見込みを確かめることが重要です。設計書だけで進めず、技術的な不確実性を小さな検証で減らします。

開発・ステージング・本番を分け、誰がどのプロジェクトを操作できるかを定めます。コンテナイメージをArtifact Registryへ保存し、Cloud BuildやGitHub Actionsなどでテストとデプロイを自動化し、承認なしに本番へ変更が入らない流れを作ります。設定値や秘密情報をソースコードへ直書きせず、環境ごとの値を安全に管理します。

データベースのスキーマ変更、バッチの再実行、外部APIのタイムアウト、同じ処理の二重実行、Cloud Runのスケール上限など、業務で問題になりやすい条件を設計段階から検証します。Cloud Runは自動スケールが便利ですが、DBの接続数や外部サービスの制限を超えると別の障害につながるため、アプリだけでなく周辺サービスを含めて性能を確認します。

テストは単体テストや結合テストだけでなく、利用部門による業務シナリオテスト、権限テスト、負荷テスト、障害・復旧テスト、バックアップからの復元テストを行います。Cloud Runのリビジョン切り替え、切り戻し、ログの確認、アラート通知を本番前に実施し、担当者が手順を再現できる状態にします。

データ移行は、移行前のバックアップ、変換、件数照合、エラー一覧、再移行、旧システムの参照期間を決めます。リリース当日にすべてを初めて試すのではなく、移行リハーサルを行い、切り替え時間と切り戻し条件を確認します。稼働後も、問い合わせを集めて小さく改善し、Cloud Runの構成や費用が業務量に合っているか定期的に見直します。

2026年のGoogle Cloud公式発表では、Cloud RunにAIエージェント、リモートMCP、GPU、フルスタックアプリなどの機能拡張が紹介されています（出典: Google Cloud Blog「What’s new for Cloud Run at Next ’26」、2026年4月）。新機能は将来の選択肢を広げますが、業務システムへ導入する際は、権限、監査ログ、データ品質、推論結果の確認、費用上限、障害時の代替手順を先に決めます。

たとえばAIで問い合わせを分類する場合は、Cloud Runへ推論処理を配置することより、誤分類時に誰が確認するか、個人情報をどこへ送るか、結果を業務データとして保存するかが重要です。Google Cloudのe5事例でも、Cloud Runを他サービスのAPIデータ取り込みに使い、DataformとBigQueryで整形しています（出典: Google Cloud「e5 case study」、2026年確認）。このように、単一サービスの採用ではなく、業務データの流れ全体から発注範囲を決めます。

よくある質問（FAQ）

Cloud Runのシステムを発注する際に、特に質問されやすい内容をまとめます。技術の適否だけでなく、費用、既存システム、発注先、契約の考え方を確認してから相談すると、初回打ち合わせを具体的に進められます。

小規模業務システムは、画面、API、認証、DB、基本監視、少数のデータ連携を含む前提で、300万〜800万円を推定レンジとして検討できます。ただし、データ移行や複雑な権限、外部連携、厳しい可用性要件が加わると増えるため、要件定義と見積もりを分けて確認します。

コンテナ化できるWebアプリやAPIであれば移行候補になりますが、そのまま移せるとは限りません。ローカルファイルへの保存、固定IP、常時接続、長時間処理、OS依存、セッションの保持などを確認し、Cloud Runサービス、Jobs、別のGoogle Cloudサービス、またはGKEやCompute Engineへ役割を分けます。

複数社から提案と見積もりを取るなら、簡易なRFPでも用意することをおすすめします。目的、利用者、業務フロー、データ、連携、希望時期、予算の考え方、セキュリティ、移行、運用、提案してほしい範囲をそろえると、会社ごとの見積もりを同じ条件で比較できます。

Web画面、API、イベント処理、定期バッチのように、コンテナを実行して自動スケールさせたい業務ならCloud Runを優先的に検討できます。一方で、複雑なクラスタ制御、特殊なネットワーク要件、常時稼働のワーカー、長時間処理などが中心ならGKEやCompute Engineが適する場合があります。発注先には、Cloud Runを使う理由だけでなく、使わない場合の比較も説明してもらいます。

まとめ

Cloud Runのシステムを発注するときは、Cloud Runという技術名だけを依頼するのではなく、業務画面、API、Jobs、データベース、認証、ネットワーク、監視、バックアップ、データ移行、運用までを一つのシステムとして整理します。まず発注者側で業務フローと利用者、データ、品質条件をまとめ、必要に応じてPoCや要件定義を先に依頼します。

発注前には、目的と業務フロー、利用者と権限、現行システム、データ移行、外部連携、ピーク時の利用量、RTO・RPO、セキュリティ、希望時期、予算、運用時間を整理します。開発会社には、Cloud RunサービスとJobsの分割理由、GKEやVMとの比較、周辺サービス費、担当体制、再委託、成果物、契約終了時の引き継ぎを質問します。

費用相場は、PoCが100万〜300万円、小規模業務システムが300万〜800万円、中規模が800万〜2,000万円という推定レンジを出発点にできますが、根拠のない総額を断定してはいけません。要件定義、データ移行、テスト、監視、保守、Cloud Run以外の利用料が見積もりに含まれているかを確認し、同一条件のRFPで3〜5社を比較してください。技術の採用だけでなく、業務の定着と契約終了後の運用まで見通せる委託先を選ぶことが、Cloud Runのシステム開発を成功させる近道です。

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

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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