Azure導入では、RFP（提案依頼書）と要件定義が発注の関門です。非機能要件や責任範囲を示すと、提案を比べやすくなります。
Azureは選択肢が豊富で、要件が曖昧だと後から仕様変更や追加費用が膨らみがちです。全体像はAzure導入・構築の完全ガイドもご覧ください。
▼全体ガイドの記事
・MicroSoft Azure導入・構築の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
非機能要件と責任共有モデルの定義
Azure導入のRFPでは、非機能要件の記述が軽く見られがちです。可用性・性能・コスト上限・セキュリティは、構成の複雑さと費用を左右します。
これらを数値で定めないと、ベンダー各社は異なる前提で見積もります。そのため、提案を同じ基準で比べられません。
可用性・性能・コスト上限の定量定義
発注側は、構成判断に必要な非機能要件を数値でRFPに指定します。要件が明確であるほど、過不足のない提案につながります。
- 可用性：稼働率と計画停止の条件
- 性能：同時接続数と応答時間
- コスト：インフラ月額の上限
可用性は「月間稼働率99.9%以上」、計画停止は「月1回・深夜帯のみ許容」と書けます。
性能は、ピーク時の同時接続数と平均応答1秒以内などで示します。
数値がそろっていれば、ベンダーは可用性ゾーンや冗長化の要否を判断できます。その結果、過不足のない構成を提案しやすくなります。
一次データの相場感では、インフラ月額は小規模で数千円〜1万円、中規模で3万〜10万円が目安です。大規模エンタープライズでは数十万〜100万円以上になります。
サポートプランは、ビジネス向けで月額最低$100（年$1,200）からです。さらに、エンタープライズでは月$15,000以上のケースもあります。
こうした相場を踏まえ、事業規模に合うコスト上限をRFPに明記します。そうすれば、現実離れした提案や過剰スペックを初めから除外できます。
性能は、平常時とピーク時を分けて指定します。たとえば平常時は同時接続100、月末は500まで応答1秒以内と書けば、自動スケーリングを含む提案につながります。
年間稼働率99.9%と99.99%では、必要な冗長構成とコストが大きく異なります。そのため、業務影響度から水準を決めて、過剰な要件による費用増を避けます。
クラウドの責任共有モデルの要件化
責任共有モデルは、Azureと利用者のどちらが何を守るかを分ける考え方です。RFPでは、この責任の境界を具体的に示します。
- Azure：物理データセンターとネットワーク基盤
- 利用者：OS以上の設定、権限、暗号化、アプリ対策
- RFP：担当者と担保する内容を明記
境界が曖昧だと、「クラウドだから安全」という思い込みが重大なセキュリティ事故につながります。そのため、発注企業は責任を理解するだけでなく、要件に落とし込みます。
IaaSは利用者の責任範囲が広く、PaaSやサーバーレスではAzure側の負担が増えます。特にサーバーレスでは、OSパッチなどから解放されます。
サービスモデルによって責任範囲は変わるため、自社で担える運用と委託したい運用を、要件定義の段階で切り分けます。ただし、運用を委託しても、最終的な責任は発注企業に残ります。
監査やアクセス管理の要件も明確にします。設定管理や脆弱性対応、暗号化などの項目ごとに、Azure・委託先・自社の担当を表に整理し、RFPに添付します。バックアップやアクセス権限も、同じ表に含めます。
一覧があると、ベンダー間で責任範囲の解釈がそろいます。また、見積もりの前提が統一され、提案の比較精度も上がります。
構成パターン選定とPoC評価軸の設計
非機能要件を固めたら、要件に合う構成を選び、本格構築の前にPoC（概念実証）で検証します。最適な構成は要件によって変わります。
構成をベンダー任せにせず、自社の前提を示したうえで提案を受け、PoCで検証する流れをRFPに組み込みます。この流れが、後の手戻りを防ぎます。
構成パターンの選定基準の要件化
要件定義では、業務特性と非機能要件をもとに、これらの構成のどれを軸にするかの選定基準を定めます。
- Web3層：フロント・アプリ・DBを分離
- 静的サイト＋CDN：静的コンテンツをCDNで配信
- サーバーレス：Functions＋API Management
- 高可用性：複数のゾーンに分けて冗長化
- ハイブリッド：オンプレミスと併用
止められない基幹業務なら高可用性、アクセスが間欠的ならサーバーレス、既存Windows資産と併用するならハイブリッドを軸にします。
Azureでは、ハイブリッド構成とコストの相性も選定材料になります。Windowsライセンス込みDBは、特典を適用すると月$1,005です。
同じ整理をAWSとGCPに当てはめると、それぞれ月$1,610、月$1,274です。
既存Microsoftライセンスを持ち込めるかが、クラウド間の優劣を分けます。そのため、RFPには既存ライセンス資産の活用可否を前提に、構成と費用を提案するよう明記します。Azureの強みを踏まえた提案を得やすくなります。
PoCの検証範囲と合格基準の設定
PoCを投資判断に生かすには、事前に検証範囲と合格基準を決め、RFPに記載しておきます。
- 性能：想定ピーク負荷で応答が要件内か
- 可用性：ゾーン障害時の自動切り替え
- コスト：実際の利用での月額と上限
PoC前には、既存環境のCPU使用率やネットワークI/Oを測り、移行後に必要なリソースを見積もります。この計測を怠ると、過剰スペックか性能不足を招きます。
期間の目安と合格基準をRFPに明記し、検証結果をもとに本格構築へ進むかを判断します。こうした段階を踏むと、失敗の確率を下げられます。また、要件定義の精度が高いほど、後の仕様変更コストも抑えられます。
PoCの結果は合否だけでなく、次の判断への使い方も決めます。性能が要件ぎりぎりなら、本番のスペックを上げるか、キャッシュ層を加える対策を想定します。
検証結果は、構成と費用の見積もりにも反映します。PoCで終わらせず、数値を意思決定に生かす流れをRFPに記載します。そうすれば、検証への投資が判断精度の向上につながります。
移行方式・データ移行・運用引き継ぎの要件化
既存システムをAzureへ移す案件では、移行方法と運用の引き継ぎも要件に含めておかないと、本番に切り替えられない場合があります。
責任が曖昧だと、障害対応が滞るおそれもあります。そのため、移行の段取りや運用体制を要件定義に含め、後のトラブルを防ぎます。
移行方式とデータ移行の要件の切り分け
移行方式とデータ移行は、別々に定めます。RFPでは、方式を前提として示すか、方式の選定自体をベンダーに提案させるかを明記します。
- リフト＆シフト：既存環境をそのまま移す
- リプラットフォーム：一部をクラウド向けに改修
- リアーキテクト：根本から作り直す
リフト＆シフトは短期で移れますが、クラウドのコスト効率を活かしきれない場合があります。リアーキテクトは効果が大きい一方、工数と費用がかさみます。
データ移行は独立した工程です。従業員50〜100名規模のオンプレミスからクラウドへの移行では、設計・構築に100万〜400万円かかります。
同条件のデータ移行費は、20万〜80万円が相場とされています。RFPには、対象データ量・依存関係・許容する停止時間（ダウンタイム）を明記します。
移行リハーサルの有無も要件に含めます。これらを見積もりに含めておけば、後の予算超過を防げます。
運用体制と引き継ぎ範囲の要件明記
構築後の運用体制は要件定義の段階で決めておきます。そのうえで、各業務を自社で担うか委託するかを切り分けます。
- 監視・障害一次対応
- パッチ適用・バックアップ
- コスト管理
運用代行で監視や障害の一次対応を委託する場合、初期費用・月額費用とも数万円程度が目安です。
保守運用費は、年額で開発費の10〜20%が目安です。開発費500万円なら、年50万〜100万円になります。
RFPに運用費も含めると、構築費だけでなく運用フェーズまでの総コストで比較できます。
外部に構築を委託する場合は、運用引き継ぎ（スキルトランスファー）の範囲も決めておきます。引き渡しの対象には、設計意図や構成図のほか、運用手順書と障害対応フローを含めます。
提供物と説明を契約に含めないと、ベンダー依存が固定化し、内製への移行が難しくなります。RFPにも引き渡しと説明を明記します。
運用引き継ぎを要件に含めておくと、将来の内製化やベンダー切り替えの自由度を確保できます。さらに、長期的なベンダーロックインを避けることにもつながります。
業界別コンプライアンス要件の落とし込み
業界によっては、一般的なセキュリティ要件に加えて、法令やガイドラインに基づく要件があります。RFPに書いていないと、監査や審査で大幅な作り直しが起きます。
Azureには認証や準拠の枠組みがあります。ただし、それを自社の要件として明示し、構成に反映するのは利用者の責任です。
金融FISC・医療3省2ガイドライン等の要件化
業界ごとの基準を整理し、Azure構成への反映をRFPでベンダーに求めます。
- 金融：FISC（金融情報システムセンター）の安全対策基準
- 医療：3省2ガイドラインに沿った構成
- 製造：機密性の高い設計データを扱う場合の独自要件
医療の3省2ガイドラインは、厚生労働省・経済産業省・総務省が示す医療情報システムの安全管理に関する指針です。
具体的には、保存リージョンを国内に限定するかどうかと、暗号化方式を定めます。加えて、ログ保管期間や特権アカウントの管理方法も決めます。
業界別コンプライアンスの落とし込みは、競合記事で扱いが薄い部分です。だからこそ、丁寧な定義が提案品質を左右します。
riplaはフルスクラッチ受託の立場から、業界要件を要件定義書に具体化し、Azure構成に反映する支援を重視しています。
準拠の証明方法も実務上の要件です。認証取得済みのAzureサービスを使っても、自動的には基準を満たせません。
設定と運用が要件に沿うことを、監査で示せる状態にします。監査証跡の取得方法や定期チェックの実施体制もRFPに含めます。
指摘事項への是正フローまで定めておくと、本番化後の監査に備えられます。
ゼロトラストを前提にしたセキュリティ要件
ゼロトラストは、社内ネットワークを無条件に信頼せず、すべてのアクセスを検証する設計思想です。RFPでは、これを設計の前提として扱います。
- 認証：Entra ID（旧Azure AD）による多要素認証
- アクセス：条件付きアクセス
- 権限：最小権限の原則に基づく設計
RFPには、認証・認可をゼロトラスト前提で設計するよう記載します。これにより、設計思想に基づく構成をベンダーから引き出しやすくなります。
認証の強さは、業務の重要度に応じて段階を分けます。一般システムは多要素認証で足りる一方、特権操作や機密データには、追加承認や端末状態の確認を求めます。
すべてを最高レベルにすると利便性が損なわれ、形骸化を招きます。そこで、資産の重要度に応じて検証の強さを変える方針を示します。
セキュリティ要件には運用も含めます。導入時に設定しても、権限の肥大化や退職者のアカウントの放置が起きると、ゼロトラストは機能しなくなります。
権限を見直す頻度、ログの監査方法、インシデント対応の手順を定めます。構築時の仕様に加えて、運用を続けるルールも記載します。
まとめ
Azure導入のRFP・要件定義では、非機能要件を数値で示すことと、責任共有モデルを押さえることが軸になります。そのうえで、構成選定やPoC評価、業界別要件まで含めて考えます。
可用性・性能・インフラ月額の上限は数値で示します。
IaaS・PaaS・サーバーレスの責任範囲を分けたうえで、ハイブリッド特典によるWindows DBの月$1,005という費用も踏まえます。
これら一連の整理が、提案の比較精度と構築後の安定運用を支えます。
要件が曖昧なまま開発に進むと、仕様変更で費用と期間が膨らみます。riplaは非機能要件と業界要件を具体化し、Azure構成に落とし込むRFP・要件定義書づくりを一貫して支援します。
全体像の確認には、あらためて完全ガイドをご活用ください。
▼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を創業。