AWS導入・構築で最初の関門になるのが、RFP（提案依頼書）と要件定義です。RFPは、発注側が「何を、なぜ、どこまでやってほしいか」を、ベンダーに伝える文書です。
要望が言語化されていないと提案は的外れになり、整理してRFPに落とし込めば手戻りも防げます。全体像はAWS導入・構築の完全ガイドでご確認ください。
▼全体ガイドの記事
・AWS導入・構築の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
AWS構築のRFPに盛り込むべき項目
AWS構築のRFPでは、技術的な希望だけでなく、その背景にある事業目的や制約条件まで書くことが、質の高い提案を引き出す鍵になります。ベンダーは、発注側の意図を正しく理解できて初めて、最適な構成と現実的な見積もりを提示できるからです。
目的・現状・移行対象の明確化
RFPの冒頭では、なぜAWSを導入するのかという目的を具体的に書きます。目的が曖昧だと、ベンダーは過剰な構成を提案しがちで、結果としてコストが膨らみます。目的を明確にすることが、適正規模の提案を引き出す第一歩です。
次に、発注側は現状のシステム構成と移行対象を整理します。現状情報は、ベンダーが移行範囲と工数を見積もるための土台です。
特にデータ量とアクセス特性は、後述する費用見積もりの精度を左右します。一次データでは、従業員50〜100名規模のオンプレからクラウドへの移行は、設計・構築100万〜400万円に加えて、データ移行に20万〜80万円が別途かかると示されています。移行対象の規模を正確に伝えることが、見積もりのブレを抑えます。
- 目的：オンプレミスの老朽化への対応、アクセス増加に備えたスケーラビリティの確保、インフラ費用の削減
- 現状情報：既存のサーバー台数、OS、ミドルウェア、データ量、ピーク時のアクセス数
予算・納期・体制と評価基準の提示
予算を一切示さないと、ベンダーは見積もりの方向性を定めにくく、提案の比較も難しくなります。
一次データでは、クラウド開発は費用の約80%が人件費です。人月単価は、初級で月25万〜50万円、ミドルで月50万〜80万円、シニア/アーキテクトで月65万〜120万円以上とされ、PM費用は開発費の10〜20%が相場です。こうした構造を理解したうえで自社の予算レンジを示すと、現実的な提案が集まります。
あわせて、提案をどう評価するかの基準もRFPに盛り込みます。価格だけで選ぶのか、技術力やセキュリティへの取り組みも重視するのかを示します。また、保守運用体制まで含めて評価するのかを明示すると、ベンダーは評価軸に沿った提案を出してきます。
一次データでも、ベンダー選定では相見積もりに加えて、技術力やセキュリティポリシーの確認が重要とされています。評価基準を明示すると、発注側も提案を公平に比べられ、選定の納得感が高まります。
- 予算・納期・体制：予算感、希望納期、自社側の関与度合い
- 評価基準：価格、技術力、セキュリティへの取り組み、保守運用体制
可用性・性能・コスト上限など非機能要件の定め方
AWS構築の要件定義では、機能要件以上に非機能要件が重要になります。非機能要件は、「どんな機能を作るか」とは別に、「どれくらい止まらず、速く、安全に、いくらで動かすか」という品質・制約を定める要件です。
クラウド構築では、非機能要件の定め方が構成とコストを直接決めます。そのため、RFPと要件定義書では具体的な数値で示すことが欠かせません。
可用性と性能の数値目標
たとえば、月間の停止時間は数分以内という水準を求めるなら、マルチAZ構成や冗長化が必要になり、構成は中規模以上になります。
一方、「夜間の数時間なら止まってもよい」業務なら、シングル構成でも要件を満たせます。可用性の目標を高くするほど構成は複雑になり、コストも上がります。そのため、業務の重要度に見合った水準を過不足なく設定することが肝心です。
ピーク時に何人が使うのか、画面表示は何秒以内に返したいのかといった目標があると、ベンダーはインスタンスタイプや台数、自動スケーリングの設定を具体的に設計できます。
一次データの構成例では、シングル構成（20万〜30万円）で足りるか、EC2・RDS各2台＋WAF＋ELBの高可用性構成（50万〜60万円）が必要かは、この可用性・性能要件によって決まります。要件を数値で示すことが、適正な構成と見積もりの前提になります。
- 可用性：許容できる停止時間の目標（数値）
- 性能：同時アクセス数、応答時間、処理件数の目標
コスト上限と運用費用の要件化
クラウド特有の非機能要件として、コスト上限を明示しておくことが大切です。AWSは従量課金のため、構成や使い方によって月額が変動します。
一次データでは、インフラ月額は小規模で数千円〜1万円、中規模で3万〜10万円、大規模エンタープライズで数十万〜100万円以上と幅があります。
構築後の保守運用費も、初期構築費と並べて要件に織り込みます。一次データでは、保守運用費は年間で開発費の10〜20%が相場とされ、開発費500万円なら年50万〜100万円（月4万〜8万円）が目安です。
さらに、リザーブドインスタンスを使うと、t3.largeの場合は従量$78.3が3年契約で$40.4まで下がります。初期と運用の両面でコストを要件化すると、導入後に「思ったより高い」という事態を防げます。
- インフラ費用：月額の上限と、自社が許容できる範囲
- 運用費用：保守運用費の目安、コスト最適化策の提案
責任共有モデルを踏まえた役割分担とPoCの評価軸
AWSをはじめとするクラウドでは、セキュリティや運用の責任を、クラウド事業者と利用者が分担する「責任共有モデル」が前提になります。AWS側はデータセンターや物理インフラの安全を担い、利用者側はOSの設定、アクセス権限、データの保護といった部分に責任を持ちます。
この境界を要件定義で明確にし、どこまでをベンダーに任せ、どこからを自社が担うのかを決めておくと、後のトラブルを防げます。
委託範囲と内製範囲の切り分け
要件定義では、ベンダーへの委託範囲と自社の内製範囲を切り分けます。
委託のメリットは本業に集中できることです。一方で、社内にノウハウが蓄積されにくいというデメリットがあります。そこで、構築フェーズからスキルトランスファーを要件に含め、将来の内製化を見据えて役割分担を設計しておくと、長期的な自走力につながります。
一次データでは、AWS運用代行（監視・障害一次対応）は初期・月額とも数万円程度が相場とされています。
自社に運用人材がいない初期段階は委託し、内製化が進むにつれて自社へ移していく、という段階的な役割移行を要件として設計できると理想的です。責任共有モデルを踏まえた役割分担は、セキュリティ事故や運用の空白を防ぐうえでも欠かせません。
- 委託範囲：設計・構築、監視、障害一次対応
- 内製範囲：自社が担う運用部分と、内製化へ移していく段階
PoCの検証範囲と合格基準の要件化
大規模な構築や移行に進む前に、PoC（概念実証）で技術的な実現性を検証することが、リスク低減に有効です。
ここで多くの企業が陥るのが、「PoCで何をどこまで検証し、何をもって合格とするか」の評価軸を曖昧にしたまま進めてしまうことです。評価軸が不明確だと、PoCが「なんとなく動いた」で終わり、本番化の判断材料になりません。
PoCの要件化では、検証する項目と、それぞれの合格基準を具体的に定めます。あわせて、検証に使う指標（CPU使用率、ネットワークI/Oなど）と検証期間の目安も決めておきます。
この評価軸の明確化こそ、競合の解説では手薄になりがちな実務上の要所です。PoCを「やったつもり」で終わらせず、確かな意思決定につなげる鍵になります。
riplaはフルスクラッチ受託とクラウド構築・運用の伴走の立場から、PoCの評価軸設計から本番化判断までを支援しています。
- 検証項目：性能、既存システムとの連携、想定コスト
- 合格基準：応答時間の目標値、データ移行の正確な完了、月額の上限内
業界特有のコンプライアンス要件の落とし込み
業種によっては、一般的なセキュリティ要件に加えて、業界特有のコンプライアンス（法令・ガイドライン遵守）要件をクラウド構築に織り込む必要があります。
これは多くの競合解説が深く触れない領域ですが、規制業種では、要件定義の段階でこれを盛り込めるかどうかが、プロジェクトの成否を分けます。後から対応しようとすると、構成の作り直しや大幅な追加コストが発生しかねません。
金融・医療・製造の業界基準の要件への反映
金融業であれば、FISC安全対策基準への適合が求められます。医療分野では、医療情報システムの安全管理に関するいわゆる3省2ガイドラインへの対応が必要です。製造業でも、取引先から求められるセキュリティ要件や、図面・技術情報の保護要件が存在します。
これらの業界基準は、RFPと要件定義書に「準拠すべき基準」として明記します。そのうえで、ベンダーがその基準を満たす構成を設計できるかを確認することが不可欠です。業界基準への適合は、設計時の構成や運用の細部にまで落とし込まれます。
RFPの段階で「自社はどの基準に従う必要があるか」を示し、ベンダーに対応実績を問うことで、コンプライアンスに強いパートナーを選べます。要件定義でここを曖昧にすると、監査で指摘を受けて作り直す、という最悪の手戻りを招きかねません。
- 構成要件：データの保管場所（国内リージョン指定）、暗号化、アクセスログの保全、監査対応
- ベンダーへの確認：業界基準を満たす構成の対応実績
業界基準への対応は、保管場所や暗号化といった設計時の構成に加えて、アクセスログを一定期間保全し、定期的に監査できる状態を維持するといった運用面まで要件に含める必要があります。
要件定義書には、構築時に満たすべき項目と、運用フェーズで継続的に満たし続けるべき項目を分けて記載しておくと、ベンダーとの認識齟齬を防げます。
規制業種では、この運用面の要件化を怠ると、稼働後の監査で初めて不備が発覚し、是正に追われることになります。
ゼロトラストとセキュリティ運用の要件化
近年のセキュリティ要件では、社内ネットワークの内側を無条件に信頼しない「ゼロトラスト」の考え方が広がっています。すべてのアクセスを検証し、最小限の権限のみを付与する、という設計思想です。
要件定義では、ゼロトラストをどこまで実装するかを決めたうえで、認証・認可の具体策を要件として定めます。クラウドはアクセス経路が多様なため、こうした設計が特に重要になります。
セキュリティは構築時だけでなく、運用時の継続的な監視・対応まで含めて要件化することが大切です。誰がどう運用するかまで決めておきます。
RFPと要件定義書にコンプライアンスとセキュリティ運用を織り込むことは、規制業種でAWS導入を成功させる前提条件です。要件が固まれば、相見積もりで各ベンダーの対応力を公平に比べられ、自社に最適なパートナーを選べるようになります。
- 認証・認可：アクセス制御、多要素認証、通信の暗号化
- 運用：脆弱性スキャン、ログ監査、インシデント対応の手順
提案の評価と保守運用・SLAの要件化
RFPを出して提案が集まったら、それらをどう評価し、契約や保守運用の条件をどう要件化するかが次の論点になります。
構築だけでなく、その後の運用まで見据えた要件を最初に固めておくことが、長く安定して使えるシステムにつながります。要件定義は、構築の入口であるとともに、運用の設計図でもあります。
相見積もりの正しい比較と評価項目
複数ベンダーから集めた提案を比較する際、金額だけで判断するのは危険です。安い見積もりの裏には、必要な工程が含まれていない、保守が手薄といった理由が隠れていることがあります。
一次データでも、ベンダー選定では相見積もりに加えて、技術力やセキュリティポリシーの確認が重要とされています。提案の評価項目は複数の観点で設定し、それぞれを点数化して総合評価すると、納得感のある選び方になります。
見積もりの内訳を要件として求めることも有効です。クラウド開発は費用の約80%が人件費であるため、どのレベルの人材が何人月かかわるのかを内訳で示してもらえば、提案の妥当性を判断できます。
一次データでは、人月単価は初級で月25万〜50万円、ミドルで月50万〜80万円、シニア/アーキテクトで月65万〜120万円以上です。PM費用は開発費の10〜20%が相場とされています。この相場と照らせば、提示された工数・単価が現実的かを確認でき、過大・過小な見積もりを見抜けます。
- 評価項目：価格、技術力、セキュリティ、保守体制、実績
- 見積もりの内訳：工数、人材レベル、人月単価、PM費用
保守運用とSLAの要件化
要件定義で見落とされがちなのが、構築後の保守運用とSLA（サービス品質保証）です。保守の取り決めを要件に書いておかないと、運用開始後に「想定していた対応をしてもらえない」というトラブルが起きます。
こうした取り決めも、要件として具体的に定めることが大切です。
保守運用の費用感も要件に織り込みます。一次データでは、保守運用費は年間で開発費の10〜20%が相場で、開発費500万円なら年50万〜100万円（月4万〜8万円）が目安です。
AWS運用代行（監視・障害一次対応）は、初期・月額とも数万円程度が相場とされています。これらの相場を踏まえて費用を要件化すれば、運用フェーズの予算も見通せます。構築から運用までを一続きで要件化することが、導入後に困らないシステムを実現する前提です。
riplaはフルスクラッチ受託とクラウド構築・運用の伴走の立場から、保守運用やSLAまで含めた要件設計を支援しています。
- 保守の範囲：担当者と保守の範囲、応答時間
- 連絡・報告：障害時の一次対応時間、連絡体制、定例の運用報告
まとめ
AWS導入・構築のRFPと要件定義では、目的、現状、移行対象、予算、評価基準といった基本項目を押さえることが出発点になります。そのうえで、可用性・性能・コスト上限・セキュリティといった非機能要件を数値で定めると、適正な構成と見積もりを引き出せます。
さらに、責任共有モデルを踏まえて委託範囲と内製範囲を切り分け、PoCの検証範囲と合格基準を明確にしておきます。FISCや3省2ガイドラインといった業界コンプライアンスも盛り込んでおくと、規制業種でも安心して進められる要件定義になります。
要件定義で大切なのは、技術的な希望を並べることよりも、「自社の業務にとって、どの品質を、いくらまでの範囲で、誰が担って実現するか」を数値と役割で具体化することです。ここを丁寧に詰めれば、相見積もりの比較や提案の評価がやりやすくなり、導入後の手戻りや追加費用も防げます。
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を創業。