クラウド開発・構築では、RFP（提案依頼書）と要件定義書の質が成否をもっとも左右します。非機能要件、責任分界、評価軸を明確にすると、相見積もりを比べやすくなり、手戻りも減らせます。また、移行後に転送量や仕様変更の追加費用が次々に発生するなど、想定外のコストとトラブルに悩まされることになります。
全体像をまだ把握していない方は、まずクラウド開発/構築の完全ガイドからお読みください。
▼全体ガイドの記事
・クラウド開発/構築の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
クラウド特有の非機能要件の定め方
クラウド開発・構築のRFPでまず押さえたいのは、非機能要件です。何の機能を作るかという機能要件以上に、「どれくらいの可用性で、どれくらいの性能で、いくらまでのコストで」動かすかが、クラウドの構成と費用を決定づけます。
ここが曖昧なままだと、ベンダーごとに前提がばらばらになります。そのため、相見積もりの比較が成り立たなくなります。
可用性と性能の数値目標
可用性は「稼働率99.9%」のように数値で示すのが基本です。求める可用性が高いほど、マルチAZ構成や冗長化が必要になり、そのぶん構築費用も上がります。
一次データの相場では、EC2・RDSを各1台にしたシングル構成が20万〜30万円です。一方、各2台にWAFやELBを加えた高可用性構成は50万〜60万円が目安です。「24時間365日絶対に止めてはいけない」のか、「夜間メンテナンスは許容できる」のかで、構成も費用も変わります。
性能要件も、数値の指標で定義します。ここを定義しておけば、ベンダーは自動スケーリングの設計やインスタンスのサイズを根拠をもって提案でき、過剰スペックも過小スペックも防げます。
RFPに非機能の目標値を書いておくことは、見積もりの妥当性を発注側が検証するための、最低限の準備です。
- 稼働率の目標値：可用性を示す数値と、その根拠
- 性能の指標：同時アクセス数、レスポンスタイム、ピーク時の処理件数
コスト上限と運用費を含めた要件
クラウドのRFPで見落とされがちなのが、初期構築費だけでなく、月額のインフラ費と保守運用費まで含めたコスト要件です。構築費の安さだけで選ぶと、運用フェーズで割高になることがあるため、要件の段階で織り込んでおくべきです。
一次データでは、インフラの月額は小規模で数千円〜1万円、中規模で3万〜10万円、大規模エンタープライズで数十万〜100万円以上が目安です。保守運用費は、年間で開発費の10〜20%が相場です。たとえば開発500万円なら、年50万〜100万円、月4万〜8万円程度になります。
クラウドは初期費用が安く見えても、運用が長期化するほど月額が積み上がります。そのため、トータルコスト・オブ・オーナーシップ（TCO）で評価する姿勢が欠かせません。RFPには、「月額のインフラ費と保守費を、想定アクセス量を前提に試算して提示すること」を明記しておくと、ランニングコストの不意打ちを避けられます。
- 月額のインフラ費：運用が長期化したときの月々の金額
- 保守運用費：保守と運用の作業をどこまで含めるか
セキュリティ非機能要件の具体的な項目
セキュリティは、可用性・性能・コストと並ぶ非機能要件の柱です。クラウドの責任共有モデルでは、OSやアプリの設定、アクセス権限、データの暗号化といった上位レイヤーの責任が利用者側に残るためです。
RFPには、具体的な項目で定めたうえで、ベンダーにその実装方法を提案させます。
近年は、こうした要件をゼロトラストアーキテクチャの考え方で整理するアプローチも広がっています。境界の内側を信頼する従来型に対して、すべてのアクセスを検証する前提で、認証・認可・監視を設計する考え方です。
RFPでセキュリティ非機能を曖昧にすると、ベンダーごとに前提がばらつき、稼働後に設定ミスや基準未充足が発覚するリスクが高まります。セキュリティは、機能要件の後付けにせず、最初に数値や項目で定義する必要があります。ベンダーの認証取得状況やリージョン選択まで要件に含めることが、安全なクラウド構築の出発点です。
- 暗号化とログ：保存データと通信経路の暗号化、アクセスログの保全期間
- アクセス制御：最小権限の原則に沿った権限の設計
責任共有モデルと責任分界の明文化
クラウド特有のRFP論点として外せないのが、責任分界の明文化です。クラウドには「責任共有モデル」があり、クラウド事業者・開発ベンダー・自社の三者で、どこまでを誰が担うかを明確にしないと、トラブル時に責任の所在が曖昧になります。
「誰がOSのセキュリティパッチを当てるのか」「障害時の一次対応は誰がするのか」といった役割は、要件定義の段階で文書にしておくことが重要です。
運用・障害対応の責任範囲とSLA
運用フェーズの責任分界は、SLA（サービスレベル合意）として定義します。監視の担当、障害検知の連絡フロー、一次対応・復旧の時間目標などを、具体的に取り決めておきます。
一次データでは、AWSの運用代行（監視・障害一次対応）は初期・月額とも数万円程度で外部に委託できます。そのため、内製と委託を組み合わせた運用設計も可能です。
クラウド事業者のサポートプランも、責任分界の一部です。一次データでは、AWSやAzureのビジネス向けサポートは月額最低$100（年$1,200）からで、エンタープライズ向けは月$15,000以上のケースもあります。
重大障害時にクラウド事業者からどれだけ手厚いサポートを受けられるかは、サポートプランの選択で変わります。RFPでは、こうした運用体制とサポート水準まで含めて、提案を求めるべきです。
- 運用の担当範囲：内製と委託を、どの作業で分けるか
- サポート水準：重大障害時に受けられる支援の範囲
スキルトランスファーと内製化方針
内製化の方針をRFPに盛り込むことは、競合の解説で手薄になりやすい論点です。特に、委託の最大のデメリットは、ノウハウが社内に蓄積されず、追加改修のたびにベンダー依存とコストが続くことです。
将来的にCCoE（Cloud Center of Excellence）を立ち上げ、内製運用へ移行したいなら、その意図をベンダーに伝えておきます。
また、協働の進め方を提案に含めてもらうとよいでしょう。riplaは、フルスクラッチ受託と国内開発の立場から、構築して終わりではなく、社内にノウハウを残すことを重視しています。運用を自走できる体制づくりまで見据えた要件整理も、同じ考えから大切にしています。
RFPは「作ってもらうための文書」であると同時に、「自社が将来どう運用するか」を描くための文書でもあります。
- 納品物：設計ドキュメントと運用手順
- 内製化の意向：将来の内製運用への移行を考えているかどうか
目指す運用モデルとSLO
責任分界とあわせて要件化したいのが、「将来どういう運用モデルを目指すか」です。従来型の「絶対に止めない」ことを至上命題とするITIL型の運用を続けるのか、それともSRE（Site Reliability Engineering）型の運用へ移行するのかで、求める体制も自動化の範囲も変わります。
SRE型を目指すなら、SLO（サービスレベル目標）を定め、許容できる範囲で素早く改善を回します。また、トイル（手作業の繰り返し）を減らす運用を前提に、監視と自動化の要件をRFPに盛り込みます。
具体的には、「障害検知から一次対応までの自動化をどこまで実装するか」「デプロイやスケーリングをどこまで自動化するか」「SLO違反時のアラートと対応フローをどう設計するか」といった項目を要件として示します。
運用文化の移行は、構築後に急にはできません。そのため、ここを要件段階で描いておくと、ベンダーは単に動くシステムを作るだけでなく、運用しやすい設計を意識した提案をしてくれます。要件定義の段階で目指す運用像を言語化しておけば、SRE化への移行をスムーズに進める準備にもなります。
- 運用モデルの方向性：従来型の運用を続けるか、SRE型へ移行するか
- 運用の進め方：改善と復旧を、どのような手順で回すか
構成パターンの選定基準
RFPでは、求める非機能要件に対して、どの構成パターンが妥当かをベンダーに提案させ、その根拠を比較できるようにしておきます。
代表的な構成パターンは、Web3層構成、静的サイト+CDN、サーバーレス（Lambda+API Gateway）の3つです。このほかに、マルチAZ高可用性構成や、オンプレと併用するハイブリッド構成もあり、それぞれコストと特性が異なります。
アクセス特性に応じた構成パターンの選び方
構成を選ぶ基準は、システムのアクセス特性です。そのため、RFPには自社のアクセス特性を示し、それに合う構成の提案を求めるのが定石です。
アクセスが少〜中規模で波があるなら、アイドルコストがゼロのサーバーレス構成が向きます。常時一定の負荷がかかるなら、リザーブドインスタンスを使ったWeb3層構成が経済的です。また、静的コンテンツが中心なら、CDNを組み合わせた構成で高速・低コストを両立できます。
構成の選定では、ベンダーロックインの観点も外せません。特定クラウドの独自サービスを使いすぎると、後で他社へ移行しにくくなります。将来のマルチクラウドやポータビリティを重視するなら、コンテナ（ECS Fargateなど）を使ってアプリケーションの可搬性を確保する設計を要件に含めておくとよいでしょう。
要件定義の段階でこの方針を決めておけば、構成選定の判断がぶれにくくなります。
- アクセス量と波：規模の大きさと、波があるかどうか
- 将来の移行：他社のクラウドへの移しやすさ
相見積もりで見る技術力とセキュリティ方針
RFPを複数社に出して相見積もりを取る際は、価格だけでなく、提案された構成の妥当性、技術力、セキュリティポリシーを比較する必要があります。
同じ要件でも、ベンダーによって提案する構成やマネージドサービスの使い方が異なります。その違いは、運用コストや拡張性に長く影響します。なぜその構成を選んだかを明確に説明できるベンダーほど、要件を正しく理解していると判断できます。
人月単価の前提も、相見積もりで確認すべき点です。一次データでは、人月単価は初級が月25万〜50万円、ミドルが月50万〜80万円です。また、シニア・アーキテクトは月65万〜120万円以上で、PM費用は開発費の10〜20%が目安です。
どのスキル層が、どれだけ稼働する前提で見積もっているかを見ると、価格の妥当性を判断する材料になります。安すぎる見積もりは、経験の浅い人材が中心だったり、後の追加費用を前提にしていたりする場合があります。そのため、内訳まで踏み込んで見極めることが大切です。
- 人月単価：スキル層ごとの単価と、稼働の前提
- セキュリティポリシー：提案に含まれる方針と、認証取得の状況
PoC評価軸と業界コンプラ要件
本格的な構築に入る前に、PoC（概念実証）を実施すると、要件の妥当性を検証できます。ただし、「とりあえず試す」だけのPoCは、時間と費用の浪費になりがちです。
RFPや要件定義の段階で、PoCで何を検証し、何をもって合格とするかという評価軸を、あらかじめ定めておく必要があります。ここは、競合の解説で手薄になりやすい論点です。
PoCの検証項目と合格基準
PoCでは、「想定ピーク時のアクセスでレスポンスタイムが目標内に収まるか」「想定アクセス量での月額コストが上限内か」「障害を意図的に起こしたとき、自動で復旧するか」といった項目を検証します。
検証の前提となる既存システムのCPU使用率やネットワークI/Oといった指標は、アセスメントで測定し、移行先の構成を裏づけます。
合格基準を決めずにPoCを始めると、「なんとなく動いたから本番化する」という曖昧な意思決定になりがちです。その結果、後の本番運用でトラブルが噴出します。PoCの期間目安も要件に含め、検証に区切りをつけておく必要があります。
要件定義の精度を上げることは、後の仕様変更コストを抑えることに直結します。検証で得た知見を要件定義書に反映し、本番構築の根拠を固めるのが、失敗しない進め方です。
- 性能・コスト・運用性：検証の観点ごとの合格ライン
- 検証の期間：PoCに区切りをつける時期の目安
アセスメントの測定指標
PoCの前段として、既存システムのアセスメント（現状分析）を要件に組み込んでおくと、移行先の構成設計の精度が上がります。
アセスメントでは、現行システムのCPU使用率、メモリ使用量、ネットワークI/Oといった指標を、一定期間測定します。移行先の構成は、この測定結果で裏づけます。
これらの実測値があれば、ベンダーは推測ではなく根拠を持って、インスタンスのサイズや自動スケーリングの閾値を提案できます。その結果、過剰スペックも過小スペックも避けられます。
RFPには、「移行前にアセスメントを実施し、その測定結果を構成提案の根拠とすること」を要件として明記しておくとよいでしょう。
とくにオンプレミスからの移行では、現行の負荷特性を数値で把握しないまま構成を組むと、本番で性能不足やコスト超過に直面しがちです。
アセスメントの指標と期間を要件に含めることは、競合の解説で手薄になりやすい実務上のポイントで、要件定義の精度を一段引き上げられます。推測ではなく実測に基づいて構成を組むことが、後工程での性能不足やコスト超過といった手戻りを防ぎます。
- ピーク時間帯のアクセス傾向：どの時間帯に負荷が集中するか
- 測定期間：一定期間の長さを、どう決めるか
業界別のコンプラ要件
金融・医療・製造といった業界では、業界特有のコンプライアンス要件を要件定義に落とし込む必要があります。たとえば金融なら金融情報システムセンターのFISC安全対策基準、医療なら厚生労働省・経済産業省・総務省による3省2ガイドラインがあります。製造業では、自社固有のセキュリティ要件などが対象になります。
これらを、クラウドの構成・運用でどう満たすかを、RFPの要件として明示しておくことが欠かせません。近年は、こうした要件をゼロトラストアーキテクチャの実装で対応するアプローチも広がっています。
コンプラ要件は、要件として整理したうえで、ベンダーにその充足方法を提案させます。後から追加すると大幅な手戻りになるため、要件定義の最初期に組み込むことが鉄則です。
riplaは、フルスクラッチ受託と国内開発の立場から、こうした業界コンプラ要件を構成・運用の設計へ正確に落とし込み、要件定義書として明文化する支援を重視しています。
- データの保管場所：リージョンの指定
- 監査対応：アクセスログの保全を含めた対応の方法
まとめ
クラウド開発・構築のRFP・要件定義書で押さえるべき柱は、4つです。
非機能要件は、可用性・性能・コスト上限・セキュリティを数値や具体的な項目で定めます。そのうえで、責任共有モデルを踏まえた責任分界とSLAを明文化します。
目指す運用モデルとSLOまで描いたうえで、アクセス特性とロックイン回避を踏まえて構成パターンを選びます。さらに、アセスメントの測定指標、PoCの評価軸、業界コンプラ要件を要件定義へ落とし込みます。
この4つを丁寧に詰めることが、過剰スペックや追加費用、運用トラブルを未然に防ぎます。
要件定義書は、「作ってもらうための文書」にとどめず、「自社が将来どう運用し、ノウハウをどう蓄積するか」まで描きます。
特に、コスト上限や責任分界、目指す運用モデルは、先に決めておきたい項目です。コンプラ要件を曖昧にしたまま発注すると、後の手戻りとコストが膨らみます。
riplaは、フルスクラッチ受託と国内開発の立場から、非機能要件の整理、相見積もりの見極め、目指す運用モデルの言語化を支援しています。内製化を見据えた要件定義書の作成まで、一貫して手がけています。
全体像の確認には、あらためて完全ガイドをご活用ください。
▼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を創業。