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