PaaS活用のRFP（提案依頼書）と要件定義書では、非機能要件、責任分担、構成パターン、PoCの評価軸、業界規制を定めます。全体像は、PaaS活用の完全ガイドでご確認ください。
PaaS（Platform as a Service）の活用を外部パートナーに委託する場合も、社内で導入を進める場合も、要件定義で何を、どの粒度で定めておくかを知っておくことが、導入の失敗を防ぐ最大の保険になります。「便利な基盤」という漠然とした理解で進めると、可用性や責任分担の認識がベンダーと食い違い、後から仕様変更や追加費用が膨らみます。
▼全体ガイドの記事
・PaaS活用の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
PaaS導入の非機能要件の定義
PaaS導入のRFPでもっとも重要なのは、非機能要件の定義です。機能要件（何をするシステムか）ももちろん大切ですが、PaaSの選定では「どれだけ止まらず、どれだけ速く、いくらまでで、どれだけ安全か」という非機能要件が、構成とコストを左右します。
非機能要件は、すべての項目をセットで定めることが、ぶれない選定の土台になります。ここを曖昧にしたままRFPを出すと、ベンダーごとに前提の異なる見積もりが返ってきて、比較ができなくなります。
可用性と性能の目標値の明文化
可用性は、システムがどれだけ止まらず稼働し続けるかの指標です。RFPには、この目標を数値で書いておくべきです。
可用性を高めるには、前述のマルチAZ構成などの冗長化が必要で、その分コストも上がります。一次データでは、中規模の高可用性構成（仮想サーバーやDBを各2台、WAFやロードバランサー込み）の構築相場は50万〜60万円が目安とされています。
求める可用性が費用にどう跳ね返るかを理解したうえで、目標値を設定することが大切です。
性能要件も、想定する負荷を具体的な数値で明示することで、ベンダーは適切なリソースとスケーリング設計を提案できます。PaaSの自動スケーリングは、需要に応じてリソースを増減します。ただし、上限を決めておかないと、コストが青天井になる恐れがあります。
平常時とピーク時で分けて負荷を想定し、RFPに書き込むことが、過不足のない構成提案の前提になります。
- 可用性：年間の許容ダウンタイム、目標稼働率（例：99.9%）
- 性能：同時アクセス数、リクエスト量、レスポンスタイムの上限
コスト上限とセキュリティ要件の盛り込み
非機能要件は、可用性・性能・コスト・セキュリティの四つをセットで定めることが、ぶれない選定の土台になります。PaaSは従量課金が基本のため、RFPでコスト上限を設定しておくことが欠かせません。一次データでは、月額のインフラ費用の幅は、小規模で数千円〜1万円、中規模で3万〜10万円、大規模エンタープライズで数十万〜100万円以上とされています。
そのため、RFPには想定月額の上限を要件として書いておくべきです。サポートプランもコストに影響するため、必要なサポートレベルも明示しておくことが大切です。
セキュリティ要件も、RFPの中核です。まず、データの暗号化やアクセス制御を具体的に定めます。ログの保全や脆弱性対応の体制も、同様に要件に書き込みます。
PaaSではミドルウェアより下の層は事業者が管理しますが、アプリケーションとデータの保護は利用者の責任です。そのうえで、自社が実装すべきセキュリティ対策をRFPに明記しておくと、ベンダーとの認識のずれを防げます。
- サポートプラン：ビジネス向けは月額最低100ドル、エンタープライズは月1万5,000ドル以上のケースもある
- 上限超過時の対応：アラートや制御の仕組み
クラウド責任共有モデルの要件への落とし込み
PaaSの要件定義で見落とされがちなのが、クラウドの責任共有モデルの明文化です。
PaaSでは、物理基盤やOS、ミドルウェアを事業者が担います。その上のアプリケーションやデータ、アクセス管理は、利用者の役割になります。
この境界をRFPと要件定義書で明確にしておかないと、障害やインシデントの際に「どちらの責任か」で揉める原因になります。
事業者と自社の責任境界の表による整理
責任共有モデルを要件に落とし込む実務的な方法は、責任分担を表に整理することです。表の行には、データセンターの物理セキュリティ、ハードウェア、OSを置きます。
ミドルウェアのパッチとネットワークも並べます。アプリケーションコードとデータも、同じ表に加えます。ユーザー認証といった項目も表に含め、この一覧をRFPに添付すると、ベンダーは自社が期待する分担を正確に把握できます。
特に注意したいのは、「共同で担う」とした項目の運用の流れです。たとえば脆弱性対応では、事業者がミドルウェアにパッチを当てる一方、アプリケーション側の改修は自社が行う必要があります。
この連携の手順を要件として決めておかないと、対応に隙間が生まれます。そのうえで、責任境界を表で示し、境界があいまいな部分の運用ルールまで定めておくと、導入後のトラブルを未然に防げます。
- 担当の区分：項目ごとに「事業者が担う」「自社が担う」「共同で担う」のいずれか
- 共同で担う項目：事業者と自社の作業の分かれ目と、連携の手順
ベンダーロックイン回避の方針
PaaSの要件定義では、ベンダーロックインへの方針もあらかじめ定めておくべきです。特定のクラウド事業者の独自サービスを多用するほど開発は速くなりますが、後から別の事業者へ移行しにくくなります。
そのため、RFPには「ロックインをどこまで許容するか」「将来の移行可能性をどの程度確保するか」という方針を示し、ベンダーに設計上の配慮を求めます。
ロックインを抑える具体的な手段として、コンテナ技術によるポータビリティの確保があります。アプリケーションをコンテナ化しておけば、事業者間の移行が比較的容易になります。
一方で、マネージドサービスをまったく使わないのも、PaaSの利点を損ないます。「どの機能はマネージドを使い、どの部分は移植性を優先するか」のバランスを要件定義で示すことが、開発スピードと将来の柔軟性を両立させる鍵になります。この方針の有無が、長期的なコスト構造を左右します。
- コンテナ技術：移植性を高め、事業者間の移行に備える手段
- マネージドサービス：開発スピードを支える一方で、移行の難しさにもつながる要素
構成パターンの選定基準の要件化
PaaSを活用するアーキテクチャには、典型的な構成パターンがいくつかあります。
代表的なものは、Web3層構成、静的サイト＋CDN、サーバーレス（関数＋APIゲートウェイ）です。ほかに、マルチAZの高可用性構成やハイブリッド構成もあります。
RFPでは、自社のシステム特性に合った構成パターンの選定基準を要件として示すことで、ベンダーから適切な提案を引き出せます。
ワークロード特性で構成を選ぶ基準
構成は、ワークロードの特性で選びます。アクセスに波があり低頻度の処理ならサーバーレスが適し、常時一定の負荷がかかるシステムなら、マネージドなコンテナや仮想サーバーが選択肢になります。
静的なコンテンツが中心ならCDNを前面に置く構成が効率的です。RFPには、アクセスパターン、データ量、処理の特性を記載し、それに合う構成をベンダーに提案させます。
選定基準を要件化する際は、料金との対応も意識します。サーバーレスは、低頻度なら月数百円程度で済む一方、高負荷の連続処理には不向きです。
常時稼働の仮想サーバー（Linux 2コア／約8GB）の従量課金は、一次データ上、AWSで月78.3ドル、Azureで79.6ドル、GCPで62.3ドルが水準です。3年契約にすれば、さらに下がります。
「どんな構成だと、自社のワークロードでいくらになるか」を要件段階で見積もれるよう、構成と料金の対応関係を整理しておくことが重要です。
- 特性による使い分け：アクセスの波や負荷の一定さで決まる
- 見積もりの前提：構成ごとの月額を、自社の負荷で試算できる状態
PoCの評価軸の要件定義への組み込み
PaaS導入のRFPでは、本格構築の前にPoC（概念実証）を行うことを要件に組み込むのが堅実です。そのうえで、何をどこまで検証し、何をもって合格とするかという評価軸を、あらかじめ定義しておく必要があります。たとえば、想定アクセス時のレスポンスタイムが目標値内に収まるか、月額コストが上限を超えないか、自社の運用体制で監視や障害対応を回せるか、といった具体的な合否基準です。
評価軸を要件定義に明記しておくと、検証が「なんとなく動いた」で終わらず、本番移行の判断材料になります。さらに、検証が長引かないよう、期間の目安も定めておくことが大切です。
PoCを軽視して一気に本番化すると、転送量の急増や想定外のコストといった失敗を招きます。だからこそ、RFPの段階でPoCの位置づけと評価軸を明文化することが、PaaS導入のリスクを構造的に下げる要件定義の作法です。
- 合格基準：目標値や上限と照らした合否の判断材料
- 検証の位置づけ：本格構築の前に置く、評価軸つきの段階
業界別コンプライアンス要件の反映
PaaSの要件定義で見落とすと致命的になりやすいのが、業界特有のコンプライアンス要件です。金融、医療、製造といった規制の厳しい業界では、クラウド利用に固有の基準が課されます。
これらをRFPと要件定義書に反映しておかないと、構築後に基準を満たさず作り直しになる、という重大な手戻りを招きます。
金融・医療など規制業界の基準の織り込み
金融業界では、FISC（金融情報システムセンター）の安全対策基準への準拠が求められます。医療業界では、いわゆる3省2ガイドライン（医療情報システムの安全管理に関するガイドライン）への適合が必要です。
これらの基準は、データの所在地や暗号化に細かい要求を課します。アクセス管理や監査ログの保全にも、細かい要求があります。そのため、RFPには自社が準拠すべき基準名を明記し、その充足をベンダーの提案要件とすべきです。
製造業をはじめとする他業界でも、取引先や業界団体から求められるセキュリティ要件があります。
これらを満たせるかは、PaaS事業者の対応を見て確認する必要があります。要件定義の段階で、自社にどの規制が適用されるかを一覧にし、RFPに反映します。そうすれば、規制への適合を後から取り繕う事態を避けられます。
コンプライアンスは設計の前提であり、後付けできない要件だと認識することが肝心です。
- 適用の確認：自社に当てはまる規制の把握
- 事業者側の対応：コンプライアンス対応のサービス、リージョン選択、認証取得状況
ゼロトラストの実装方針の要件化
近年のセキュリティ要件では、ゼロトラストアーキテクチャの考え方を要件定義に含めることが増えています。「社内ネットワークだから安全」という前提を置かず、すべてのアクセスを検証する設計思想です。
PaaS環境では、APIアクセスの認証強化、最小権限の付与、通信の暗号化などが具体的な実装手段になります。RFPに「ゼロトラストの方針でアクセス制御を設計すること」を要件として示すと、ベンダーの提案の質が揃います。
ゼロトラストは一度に完全実装するものではなく、段階的に成熟度を上げていく取り組みです。そのため、要件定義では、最初に守る範囲を決め、そこから対策を厚くしていく方針を示すのが現実的です。
riplaはフルスクラッチ受託と国内開発の立場から、業界規制とセキュリティ要件を要件定義の最初期に織り込み、後戻りのない設計を支援しています。コンプライアンスとセキュリティを要件の前提に据えることが、規制業界でのPaaS活用を成功させる土台になります。
- 資産とアクセス経路：優先して守る対象の特定
- RFPへの明記：アクセス制御の設計方針をベンダーの提案要件に含める
まとめ
PaaS活用のRFP・要件定義書を整理すると、その肝は、曖昧さを残さず数値と方針で定義することに尽きます。
可用性・性能・コスト上限・セキュリティの四要件を明文化し、責任共有モデルを表で示します。ワークロード特性に応じた構成の選定基準とPoCの評価軸も示します。また、業界規制とゼロトラストの方針を前提に据えます。
この一連の作り込みが、見積もりの比較可能性と導入後の安定を担保します。
要件定義で大切なのは、ベンダーに丸投げしないことです。自社のワークロードや許容コスト、適用される規制は発注側が整理し、RFPで明確に伝えます。そうすることで、適切な提案と妥当な見積もりを引き出せます。
riplaはフルスクラッチ受託と国内開発を組み合わせ、PaaSの非機能要件と業界コンプライアンスを要件定義の初期から織り込み、後戻りのない導入を支援しています。
全体像の確認には、あらためて完全ガイドをご活用ください。
▼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を創業。