GCP導入をベンダーに発注する際は、RFP（提案依頼書）と要件定義書の質が成否を左右します。
要件を整理し、役割と構成を定めたうえでPoCで確かめると、手戻りを防ぎやすくなります。全体像はGCP導入・構築の完全ガイドもご覧ください。
▼全体ガイドの記事
・GCP導入・構築の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
非機能要件の固め方（可用性・性能・コスト・セキュリティ）
GCP導入のRFPでは、機能要件以上に非機能要件が重要になりがちです。非機能要件は機能ではなく、システムの品質を定める項目です。非機能要件には、可用性、性能、コスト上限、セキュリティなどが含まれます。ここが曖昧なまま発注すると、過剰な仕様の見積もりになるか、最小構成で安く見せた後に追加費用が発生するかのどちらかになり、発注側が損をします。
可用性と性能の数値目標
可用性は、システムがどの程度止まらないかを稼働率（SLA）で定めます。性能と合わせると、数値の目安は次のように整理できます。
- 稼働率99.9%：年間の停止許容時間は約8.8時間です。
- 稼働率99.99%：年間の停止許容時間は約53分です。
- 性能目標：同時アクセス数、応答時間、処理データ量の数値目標です。
可用性を高めるほど、複数ゾーンや複数リージョンによる冗長構成が必要になり、コストも上がります。そこで、システムごとに業務への影響を見て目標を設定します。
24時間365日の停止が許されない業務か、夜間の数時間の停止を許容できるかを、RFPで明確にします。
性能は、「ピーク時に同時1,000ユーザー」「主要画面の応答は2秒以内」のように数字で書きます。さらに、日次の処理データが数百万件といった量まで示せば、ベンダーは必要なリソースを見積もれます。
性能要件が曖昧だと、本番の負荷に耐えられず、リリース後に増強が必要になることがあります。なお、現行システムの実測値があれば、将来の伸びを見込んだ現実的な目標を立てられます。
コスト上限とセキュリティ要件の明記
コストとセキュリティは、予算超過や後からの作り直しを防ぐために、RFPに条件を書いておきます。
- コスト：初期構築費と月額ランニング費の上限。
- セキュリティ：扱うデータの機密性に応じた対策の水準。
- 業界要件：法令やガイドラインへの準拠条件。
クラウドは従量課金のため、構成によってランニングコストが大きく変わります。一次データでは、GCP仮想サーバー（Linux 2コア／約8GB）は、n1-standard-2で月62.3ドルです。一方、同条件の3年契約は月40ドル前後で、インフラ月額は中規模で3万〜10万円が目安とされています。
そのため、相場を踏まえて月額のインフラ費の上限を書いておくと、予算内の構成を提案してもらいやすくなります。
個人情報や決済情報を扱う場合は、暗号化とアクセス制御を具体的に書き、監査ログと脆弱性対策も条件に含めます。さらに、金融の安全対策基準や医療の関連ガイドラインのように、業界固有の要件も明示します。
対策をベンダー任せにすると、後から大きな作り直しが発生し、費用と期間が膨らみやすくなります。そのため、セキュリティ要件は構築の前提として、早い段階で固めておきます。
バックアップ・災害対策の目標値
非機能要件で見落とされやすいのが、バックアップと災害対策（DR）です。復旧の目標を数値で決めておくことが欠かせません。
- 目標復旧時点：どのくらい前の状態まで戻すか。
- 目標復旧時間：障害発生から何時間で戻すか。
- 費用との釣り合い：停止時の影響額と対策費から見た妥当な水準。要件定義の要点です。
高い目標値を求めるほど、頻繁なバックアップや別リージョンの待機系が必要になり、コストも上がります。バックアップやDRは、平常時には見えにくい投資です。一方で、データ消失やリージョン障害のときの事業継続を左右します。
GCPには自動バックアップやレプリケーションの機能があり、設定次第で一定水準のDRを実現できます。RFPに復旧目標を示せば、ベンダーが構成を提案でき、想定より復旧に時間がかかる事態を避けられます。
責任共有モデルと役割分担の明確化
責任共有モデルでは、クラウド事業者と利用者の責任範囲を分けて定めます。GCPの場合、物理インフラやハードウェアは事業者が管理し、アプリケーション、データ、権限設定は利用者側が担います。境界が曖昧なままだと、トラブルの際に責任の所在が分からず、対応が遅れるおそれがあります。
クラウド事業者・ベンダー・自社の三者の役割
三者の役割は、各フェーズで誰が何を担うのかを、RFPと契約に書いておきます。
- Google：インフラの物理層を担います。
- ベンダー：システムの構築と設定。
- 自社：運用時の意思決定と承認。
構築後の運用担当と障害時の一次対応者は、契約段階で決めておきます。役割を設計するときは、内製と委託のバランスも大切です。すべてを委託すれば自社の負担は減りますが、一方でノウハウが社内に残らず、運用や改修で外部への依存が続きます。
一次データでは、クラウド開発費の約80%が人件費で、シニアやアーキテクトは月65万〜120万円以上です。委託を続けるほど運用費が膨らむため、スキルトランスファーを契約条件に含めます。また、定常運用を段階的に内製化する設計にすると、中長期のコストを抑えやすくなります。
RFPでの運用・保守スコープの明記
運用・保守は、相場を踏まえて範囲と費用を最初の見積もりに含めたうえで、RFPに分担を書いておきます。
- 監視・障害対応：担当者と対応範囲。
- バックアップ・パッチ：実施する担当と内容。
- 費用面の調整：定期的な見直しを誰が担うか。
一次データでは、保守運用費は年間で開発費の10〜20%が目安です。たとえば開発費が500万円なら、年50万〜100万円、月4万〜8万円が目安とされています。また、監視と障害の一次対応を行う運用代行は、初期費・月額ともに数万円程度とされています。
範囲を曖昧にすると、リリース後に契約外とされ、追加費用や対応の遅れにつながります。クラウドは構築後も監視や費用の見直しを続けることで価値が出ます。
RFPでは、対応時間、復旧目標、報告頻度などのサービスレベルを決めておきます。特に、構築から運用まで任せられる体制かを確かめることが、安定稼働につながります。
構成パターンの選定基準
非機能要件と役割分担が固まったら、要件に合う構成パターンを選びます。GCPには仮想サーバー、サーバーレス、コンテナ基盤などがあり、どれが適しているかは要件によって変わります。そこで、RFPでは自社が想定する構成の方向性を示し、最適案を引き出せるよう要件を整理します。
仮想サーバー・サーバーレス・コンテナの選定軸
構成パターンは、ワークロードの性質に合わせて選びます。
- 仮想サーバー（Compute Engine）：常時高負荷や特殊なミドルウェアに適します。
- サーバーレス（Cloud Run、Cloud Functions）：断続的な処理に有利です。
- コンテナ基盤（GKE）：複数サービスを組み合わせる複雑なシステム向けです。
サーバーレスは処理が動くときだけ稼働するので、アイドルコストが発生しません。システムの要素ごとに適したパターンを切り分け、すべてを一つの構成に当てはめないことが大切です。
実際のシステムは、常時稼働する基盤の部分と断続的に動く処理が混在するのが一般的です。そのため、常時稼働の部分には確約利用割引付きの仮想サーバーを使い、断続処理はサーバーレスにすると、費用と性能を両立できます。
RFPで構成を一つに決め打ちせず、ワークロードごとの振り分けを提案できるベンダーを選びます。
ベンダーロックイン回避の観点
長く使うことを見据えて、ベンダーロックインを避ける点も構成要件に含めます。
- 移行可能性：コンテナ技術の活用で担保。
- 標準技術：広く使われている方式を優先する方針を示す。
- マルチクラウド：統合監視とセキュリティ管理の整理。
GCP独自のサービスは便利ですが、使いすぎると、他のクラウドへ移す際の作り直し費用が増えます。独自サービスの利便性とロックインのリスクはトレードオフの関係にあり、どこまで許容するかは自社の方針次第です。RFPで観点を示しておくと、提案に構成の理由やロックインリスクへの考え方が含まれ、提案の質を見極めやすくなります。
ロックイン回避は、コストや可用性ほど目立ちにくいものの、長く使うシステムの柔軟性に直結します。また、複数のクラウドを併用する場合は、統合的な監視やセキュリティ管理も要件に含めます。そのうえで、構成は短期の構築費と中長期の選択肢の両方を踏まえて選びます。
PoCの評価軸とベンダー選定
PoC（概念実証）は、大規模投資の前に小さく試し、実現性を確かめる方法です。GCPは無料枠が手厚いため、PoCの費用を抑えやすく、本格構築の前に要件を検証するのに適しています。ただし、「とりあえず動かす」で終わらせないために、何をどこまで検証し、何をもって合格とするかを事前に決めておきます。
PoCの合格基準と検証期間
検証項目と合格基準を具体的に決めると、PoCを判断材料として使える検証になります。
- 性能：ピーク負荷時の応答時間が目標内か。
- データ連携：既存システムとつないで正しく動くか。
- コスト：想定費用が予算内に収まるか。
各項目には数値の合格ラインを置き、検証期間にも数週間などの区切りを設けておきます。基準が曖昧だと「動いたから本番化」となり、本番で問題が出るリスクが残ります。さらに、CPU使用率やネットワークI/Oも見ながら、本番を想定した負荷でも無理なく動くかを確かめます。
PoCは、ベンダーが自社の要件を理解し、的確に検証を進められるかを見極める機会にもなります。そのときは、コミュニケーションや文書の丁寧さ、想定外の事態への対応力も見ておきます。
課題の原因をどう切り分け、どんな代替案を示すかを見れば、本番での対応力も推し量れます。PoCを発注先の判断材料に含めれば、契約後のミスマッチを減らせます。小さく試してから大きく投資する段階的な進め方が、GCP導入のリスクを抑えます。
相見積もりと技術力・セキュリティの確認
ベンダー選定では、複数社から相見積もりを取り、金額に加えて技術と安全面も確かめます。
- 見積もり条件：同じRFPと作業範囲に基づいているか。
- 技術力：認定資格、構築実績、業界経験。
- セキュリティ：自社基準を守る方法と体制、過去の実績。
構築相場は規模によって幅があり、同じGCP構築でも前提が違えば金額も変わります。ただし、安い見積もりには、必要な作業が含まれていない可能性もあります。そのため、RFPの条件を揃えておくと、各社の前提が同じになり、公平に比べられます。
セキュリティは価格とは切り離して考え、自社基準をどう守るかを確かめます。また、構築後の運用や改修まで継続して支えられる体制かどうかも、事前に把握しておきます。
RFPと要件定義書を起点に、PoCで実力を確かめ、相見積もりで条件を比べます。この一連の流れが、GCP導入を成功させるうえで欠かせません。発注ドキュメントへの投資は、構築後の手戻りを防ぐうえで、もっとも確実なリスク対策です。
まとめ
GCP導入では、可用性、性能、コスト上限、セキュリティを数値で定め、三者の役割と運用の範囲を明確にします。ワークロードに合う構成を選び、PoCで実力を確かめてから本契約に進みます。
仮想サーバーとサーバーレスを使い分け、PoCの合格基準を事前に定めます。これらを丁寧に進めると、過剰でも過少でもない自社に最適な構築につながります。
ベンダーに任せきりにせず、自社の要件を起点に判断の基準を持つことが大切です。明確なRFPは公平な相見積もりを可能にし、構築後の手戻りを防ぎます。
riplaはフルスクラッチ受託と国内開発の立場から、要件整理、PoC、構築、運用を支援します。要件定義を全体像とあわせて確認したい方は、完全ガイドをご活用ください。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。