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

Google Cloudのシステム発注は、業務の整理、要件定義、委託先の選定の順に進めます。この順で進めると、条件に合う構成と費用を比べて判断できます。発注形態から契約、費用、委託先の選び方まで、各段階で決めることを順に説明します。

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

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

Google Cloudのシステムを発注・外注する前に知るべき全体像

Google Cloudのシステムは、業務アプリやデータベースを中心に、認証やデータ連携、監視、バックアップも組み合わせて作ります。Google Cloud自体は販売管理のような完成パッケージではないため、「何を作るか」と「どのサービスで動かすか」を分けて考える必要があります。

Google Cloudのシステムは組み合わせで作る構成

業務システムでは、実行基盤、データ保存、分析連携、運用管理の各サービスを組み合わせ、役割ごとに業務の性質に合うサービスを選びます。

• 実行基盤：Web画面やAPIにはCloud Run、細かな制御にはGoogle Kubernetes Engineが候補です。
• 既存アプリ：仮想マシンに近い形で移すなら、Compute Engineが候補になります。
• 業務データ：Cloud SQLや、グローバル分散・高可用性向けのSpannerが選択肢です。
• 保存先：柔軟なNoSQLならFirestore、ファイルやバックアップならCloud Storageを使えます。
• 分析・連携：分析にBigQuery、リアルタイム連携にPub/SubやDataflow、ERP・会計連携にAPI GatewayやApigeeを検討します。

運用には、IAMやSecret Manager、Cloud KMSといった権限と鍵の仕組みが必要です。Cloud LoggingとCloud Monitoringも欠かせません。こうした要素を含めて構成を組めるよう、業務要件から逆算できる会社を選びます。

クラウド化の前の業務とデータの標準化

発注前に、紙やExcel、メールでやり取りしている業務を洗い出します。FAXや経験に依存する例外処理も含めます。これは、現行業務をそのまま画面にすると、不要な承認や重複入力まで固定されてしまうからです。

• 残す業務：現行業務から継続するものを決めます。
• 標準化する業務：例外処理や手順を整理する対象です。
• 廃止する業務：不要な作業を、システム化の前に取り除きます。

顧客と商品、社員、拠点、勘定科目のマスタは、定義を確かめます。あわせて、重複、欠損、表記ゆれを点検する必要があります。

個別対応で費用が2,000万円から4,200万円へ増えた例もあります。この例は自社の見積にそのまま当てはめず、追加要望や修正費を防ぐ教訓として使います。

Google Cloudのシステム発注形態の選び方

発注形態は、内製力と業務の独自性を踏まえて選びます。既存システムの複雑さや運用担当も、判断の材料になります。また、業務領域ごとに方式を分ける方法もあります。

SaaS・パッケージを中心に連携する方式

連携方式を選ぶには、標準機能をどこまで使うかと、Google Cloud側で担う役割を先に分けておきます。

• 向く領域：会計、勤怠、CRM、販売管理などが該当します。
• Google Cloudの役割：データ連携、分析、認証の基盤として使います。
• 確認事項：API制限、データ所有権、解約時の出力。

SaaS側の設定やデータ整備は、誰が担うかを決めます。また、追加ライセンスや業務変更への追従性も確認します。

SaaSを導入しても、Excel運用が残る場合があります。そのため、業務手順や権限を発注範囲に含めます。移行データと教育も、あわせて対象にします。

マネージドサービス中心の業務アプリ開発方式

独自性のある業務アプリでは、対応する業務と構成の特徴を確かめます。

• 対象例：社内ポータル、予約、受発注、現場報告などが対象になります。
• 構成例：Cloud Run、Cloud SQL、Cloud Storageの組み合わせです。
• 特徴：サーバー構築やパッチ適用を減らし、利用量に応じて拡張できます。

サービスが増えるほど、権限と監視の設計が要ります。障害切り分け、転送、バックアップの設計も欠かせません。

ベンダーには、採用理由、拡張条件、移行できるデータ形式を確認します。構成は、必要な可用性と業務量を基に段階的に決めます。

既存システムの移行・連携方式

既存資産を活かす移行では、移行先と接続方法、改善する対象を決めます。

• 移行先：Compute EngineやGKEへ、段階的に移せます。
• 接続方法：オンプレミスとの接続は、Cloud VPNやCloud Interconnectを使います。
• 改善対象：バックアップ、可用性、開発環境、データ分析が対象です。

京セラドキュメントソリューションズの公式事例では、開発基盤の移行で、維持コスト3割削減、ビルド時間約20％短縮、BCP強化が紹介されています。

移行では、文字コード、データ型、バッチ時刻を検証します。外部連携、性能、障害時の切戻しの検証も欠かせません。

発注書には、対象・対象外データ、リハーサル回数、照合方法を記します。並行稼働期間と旧環境の停止条件も書き添えます。加えて、現行担当者の暗黙知を要件にできる会社かどうかも確認します。

RFPと要件整理の進め方

RFPは委託先に提案を依頼する文書です。IPAの資料では、業務フローや要件一覧を補足資料にする考え方が示されています。課題一覧や現行構成図などもこの対象です。

画面仕様を細かく決めすぎず、業務課題と達成指標、制約、提案範囲をそろえます。そうすると、各社の提案を同じ条件で比べられます。

業務要件と達成したい成果の整理

提案依頼に業務要件を反映させるため、業務の流れと期待する成果を具体化します。

• 業務フロー：誰が、いつ、何を使い、何を判断するかの記録。
• 例外と承認：受発注の場合は、見積から返品までを確認します。
• 成果指標：二重作業をなくし、締め処理を翌営業日の午前中までに終えるなど、達成状態を示します。

利用者数や拠点数、月間取引件数を書きます。同時接続数、保持年数、既存データ件数も書き添えます。

未確定の値は、現時点の推定だと明記します。そのうえで、確認方法をベンダーに提案してもらいます。

料金と性能は、データ量や通信量によっても左右されます。特に、前提が曖昧だと、安い見積が後から高くなることがあります。

RFPへの非機能要件の明記

構成や費用を見積もるには、稼働条件と安全管理の基準を事前に定めておく必要があります。

• 性能と稼働：応答時間、稼働時間、計画停止を定義します。
• 復旧条件：RTO、RPO、バックアップ世代を定めます。
• 安全管理：監査ログの保存期間、脆弱性、所在地、権限、個人情報の扱い。

稼働条件は、平日業務時間の月間稼働率や計画停止の扱いで定めます。「24時間365日絶対に止めない」のような表現は、この定め方に置き換えます。また、重大障害は何時間以内に復旧を開始するかも決めます。

IAMの最小権限とMFAを確認します。さらに、特権ID記録やログ権限を確かめ、Secret Managerや鍵の管理者、本番アクセス方法も確認します。

2026年3月公表の経済産業省などのガイドラインは、ソフトウェアの開発・提供・運用を担う事業者と顧客が、サプライチェーン全体の責任を確認する考え方を示しています。そのため、安全対策をベンダーに任せきりにせず、どこまでを誰が受け持つかをRFPに書き込みます。

提案依頼の範囲と納品物の定義

提案依頼では、委託範囲と評価条件をそろえて、各社の提案を比較します。

• 依頼範囲：企画・要件定義だけか、運用までかを示します。
• 納品物：設計書、コード、Terraform、テスト・移行計画を含めます。
• 評価軸：同業・同規模の実績、Google Cloudの認定・専門性、要件定義の内容で比べます。

評価では、データ移行の経験と運用体制を確認します。セキュリティや内製化支援、提案の前提条件も、あわせて見ます。

納品物は、要件定義書、基本・詳細設計書、データモデル、ソースコードのように、種類ごとに書き分けます。TerraformなどのInfrastructure as Code、テスト仕様書、移行・運用・障害対応の手順も、納品物として挙げておきます。

コードだけを受け取ると、構成コードや運用情報が残らず、他社へ移行しにくくなります。評価点を社内で共有しておけば、知名度や営業資料だけで決めるリスクを抑えられます。

契約形態と発注者・委託先の責任分担

契約は、成果物の完成を重視する工程と、専門家が調査・改善する工程で分けて考えます。経済産業省やIPAのモデル資料では、企画や要件が未確定な段階には準委任がなじみやすいとされています。

開発段階では、成果物や進め方に応じて、請負と準委任のどちらもあり得ます。そのため、契約名だけでなく、成果物と責任を確かめます。報酬や変更手順も、あわせて確認します。

請負契約の成果物・検収・変更条件の具体化

請負で成果を確認するには、仕様、検収条件、変更手続きを契約前に具体化しておく必要があります。

• 仕様：画面数、処理、帳票、連携、性能、エラー動作、対応ブラウザを定めます。
• 検収：テストの合格条件と検収期限を決めます。
• 変更管理：費用・納期への影響を合意してから着手します。

Cloud Runへの配置だけを成果物にすると、範囲が曖昧になります。検収範囲には、アプリや環境構成、権限を記します。監視、バックアップ、手順書も、あわせて書きます。

変更時は、影響範囲、追加工数、納期を記録します。費用と承認者も残しておきます。口頭で要望を積み上げると、費用や検収条件がずれるおそれがあります。

準委任契約の作業範囲・体制・報告の明確化

準委任では専門家に業務の遂行を頼むため、作業範囲、体制、報告内容を定めます。

• 対象業務：要件調査、技術検証、アジャイル開発、運用改善です。
• 体制：役割、稼働時間、意思決定期限を決めます。
• 報告：月ごとの作業内容と成果報告の取り決め。

完成物の引渡しだけを期待すると、作業は行われていても機能は完成していないという認識差が生じます。

PoCでは、Cloud RunとCloud SQLの性能や料金を試し、その結果を設計に反映できます。成功条件は、想定負荷での応答時間、一定範囲内の月額費用、移行データの品質などで定めます。

知的財産・データ・運用の責任の契約への明記

将来の移行と継続運用に備えて、権利、自社の管理範囲、運用分担を契約で定めます。

• 権利とデータ：成果物、OSSのライセンス、解約時のデータ返却形式を確認します。
• 自社管理：アカウント、リポジトリ、請求先の管理者を決めます。
• 運用分担：障害、復旧、脆弱性、再委託の条件を定めます。

権利の確認範囲は、コードや設計書、Terraformです。テストデータ、ログ、AI成果物にも及び、テンプレートや第三者ライブラリの利用範囲も確かめます。

また、ドメインや証明書、秘密情報の管理主体も決めます。運用の細目では、一次受付と時間外対応、重大度別の連絡時間を定めます。

復旧目標と復元テスト、脆弱性修正を定めます。料金アラートや月次報告も定義し、本番アクセスの承認方法も決めます。

発注者は、データの正確性と業務ルールの承認に協力します。受入テストや利用者教育にも、あわせて関わります。

Google Cloudのシステム発注費用・相場の目安

費用は、開発・移行と、Google Cloud利用料に分けて考えます。保守・監視や外部サービスの費用も、別の枠で見ておきます。

Google Cloudには、システム一式の公式な定額相場がありません。費用は、利用者数やデータ量、可用性によって変わります。

連携や移行難度、委託体制も影響します。以下の数字は、業務システム相場と構成要素をもとにした概算で、確定価格ではありません。

開発・移行費の300万円から数億円までの幅

開発費は、対象規模や連携範囲によって変わります。PoC・小規模の金額は、認証と数画面を含み、Cloud RunまたはFirestore・Cloud SQLを使う場合の概算です。簡易APIと検証用データも、この範囲に含みます。

• PoC・小規模：初期費用300万〜800万円程度です。
• 中小企業向け：受発注・顧客・在庫などの業務システムで、権限、帳票、SaaS連携、移行、運用設計を含む場合、800万〜3,000万円程度が比較の起点です。
• 分析・連携案件：BigQueryやAI、複数連携、監査ログ、移行を含み、1,500万〜5,000万円程度です。
• 基幹刷新・全社展開：3,000万円から数億円まで広がる可能性があります。

金額は要件と対象範囲で大きく変わる推定レンジです。工程別の比較目安は、要件定義10〜15％、基本設計15〜20％、詳細設計10〜15％、開発30〜40％、テスト15〜20％、移行・導入5〜10％です。事例ごとに変動します。

Google Cloud利用料の月額0.5万円から500万円以上までの変動

Google Cloud利用料は環境や負荷で変わるため、用途別の月額レンジを押さえておきます。

• 開発・検証環境：月0.5万〜5万円程度です。
• 小規模な本番：月3万〜15万円程度が概算の起点です。
• 高可用性・分析連携：月20万〜100万円以上になることもあります。
• 大規模・高トラフィック・AI処理：月100万〜500万円以上になる可能性があります。

推定には、CPUやメモリ、DBを含みます。ストレージ、通信、ログ、バックアップも加えています。この金額は、Google Cloud公式の定額表ではありません。

Cloud RunはCPUやメモリなどの利用量に応じて課金されます。無料枠、リージョン、通信条件によっても、料金は変わります。

試算には、Cloud SQLやBigQuery、転送の費用を加えます。ロードバランサや監視、バックアップも対象です。サポートと運用費も加えます。そのため、TCOの安さは、実行単価を見るだけでなく、これらの費用を合わせて判断します。

保守・監視費と初期費用以外のTCOの区分

総費用を把握するには、導入後も続く支出を初期費用と分けて見ます。

• 初期費用：開発、移行、追加開発に分けます。
• 月額費用：クラウド利用料と、監視・運用費を別々に数えます。
• 年次費用：診断、証明書、ライセンス、保管費の確認。

保守費は、初期開発費の年10〜20％程度を見込む場合があります。たとえば、初期開発費が3,000万円なら、年300万〜600万円程度が目安です。

保守費は、有人監視、24時間対応、SLAの有無で変わります。診断、データ修正、機能追加の範囲によっても変わります。月額にまとめた見積でも、内訳を開示してもらいます。

予算管理では、請求先とラベル、予算アラートを決めます。開発環境の自動停止、ログ保持、バックアップ世代数も定めます。FinOpsの定例も発注範囲に含められます。

委託先の選定と見積比較で確認すべきポイント

資格者数だけで決めないよう、実績と責任分担を確認します。移行と定着、セキュリティも見ます。

運用も確かめたうえで、同じ前提と成果物で見積を比べます。

担当工程と成果で見る実績の確認

実績を選定材料にするなら、事例が自社に当てはまるかと、実際の担当体制を確かめます。

• 事例の目的：導入目的と利用サービスを聞きます。
• 規模と成果：データ規模や得られた効果を確認します。
• 担当体制：再委託や責任者の交代、担当工程の確認。

公式事例の維持コスト3割削減やビルド時間約20％短縮は、開発基盤の成果です。そのため、販売管理の費用削減にそのまま当てはめることはできません。

自社に近い業務や利用者数の事例を優先します。規制や既存環境が近い事例も、あわせて選びます。

要件定義とデータ整備、受入テストの担当は、提案書で見ます。教育や問い合わせ対応の担当も、提案書で確かめます。

提案会社の社員が作業する範囲を確認します。再委託や海外拠点の有無、責任者が稼働中も変わらないかも確かめます。

見積の工程・工数・前提条件の横並び比較

見積の金額差を判断するため、工程と作業条件を同じ項目で並べます。

• 工程：要件定義から保守まで、項目をそろえます。
• 工数と成果物：人数、期間、単価、検収条件の確認。
• 対象外作業：「別途」の作業と品質条件を確認します。

データ整備や帳票、権限が含まれるかを確認します。監査ログや負荷試験の有無も見ます。脆弱性診断と切戻しリハーサルも確かめます。

金額差が大きいときは、対象範囲や品質条件が異なる可能性があります。そのうえで、同じ質問をして、同じ前提で再見積を依頼します。

精度が低い段階では、要件定義を準委任で先行させ、その成果をもとに開発費を決める段階契約も選べます。

提案書によるセキュリティとデータ管理の評価

情報の種類によって確認範囲が変わるため、保護条件を分野ごとに整理します。

• アクセスと保存：所在地、運用者、サポート時の扱いを確認します。
• 委託関係：再委託先と契約上の安全管理を確かめます。
• 決済・AI：カード非保持、トークン化、AIの誤出力時の担当などを決めます。

国内リージョンを選んでも、それだけで解決するとは限りません。個人情報保護委員会のFAQは、外国事業者が保存データを扱う場合、国内サーバーでも外国第三者への提供に該当し得ると説明しています。そのため、法務・情報システム部門も委託先の提案確認に加わります。

EC・決済では、経済産業省の2025年3月改訂ガイドラインも確認します。カード非保持、トークン化、EMV 3-Dセキュアを整理します。

脆弱性対策と不正ログイン対策も、あわせて整理します。PCI DSS対応や診断実績も確認します。

生成AIでは、機密区分とログ保存、モデル利用を要件にします。人の承認も、あわせて要件に入れます。

Google Cloudのシステム発注でよくある質問

技術選定だけでなく、発注前の業務整理と契約条件も成果を左右します。

Google Cloudは業務システムのパッケージですか？

いいえ。Google Cloudは業務アプリを動かす基盤であり、販売管理などの完成パッケージではありません。

SaaS連携、独自アプリ開発、既存システム移行のなかから、要件に合う方式を選びます。

Google Cloudのシステム開発費用はどのくらいですか？

PoC・小規模業務アプリは300万〜800万円程度、中小企業向けは800万〜3,000万円程度が比べる際の目安です。

分析・AI連携は1,500万〜5,000万円程度、基幹刷新は3,000万円から数億円まで広がる可能性があります。要件等に基づく推定で、公式価格や確定見積ではありません。

Google Cloudの外注先は資格者数だけで選べばよいですか？

資格やランクだけで決めるのは避け、同業・同規模の実績、要件定義、移行、運用を比べます。見積と設計書、IaCの納品を確かめます。内製化支援や障害時の責任も、比較の対象に含めます。

営業担当に加え、実際のプロジェクト責任者と技術担当者にも提案内容を説明してもらいます。

個人情報をGoogle Cloudに保存しても問題ありませんか？

判断は、情報の種類や利用目的、契約によって分かれます。アクセスや委託先、社内規程も踏まえます。国内リージョンの利用は、確認の一部にすぎません。

FAQを踏まえ、所在地、国外アクセス、再委託を法務・セキュリティ担当と確認します。ログやバックアップも、同じ場で確かめます。

必要に応じて、匿名化や最小権限を設計します。鍵の分離と保存期間の制限も、設計に含めます。

まとめ

発注前には、業務と成果、利用者数を整理します。データや非機能要件も、あわせて整えます。SaaS連携、独自アプリ、既存システム移行を比べたうえで、RFPに範囲と評価軸を記載します。

発注前に決める業務・要件・責任分担

未確定の企画・検証は準委任、成果物と検収条件を定められる開発は請負または準委任と、工程に合う契約を選びます。費用は、開発・移行と利用料に分けます。保守や外部サービスの費用も、別に把握します。

成果物では、コードや設計書、IaC、データの条件を残します。アカウントや運用の条件も記録します。知的財産や再委託の条件も残し、変更と障害対応の条件も、記録しておきます。

最初の一歩となる現行業務とデータの洗い出し

業務フローやマスタ、データ量を一覧にします。権限、連携、ピーク、例外処理も、あわせて書き出します。同じRFPを2〜3社へ提示し、提案内容を比べます。体制や工程別費用に加えて、運用とセキュリティも同じ項目で見ます。

発注条件が整うほど、技術選定と費用の妥当性を判断しやすくなります。

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

▼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を創業。