複数のBtoB SaaSやクラウドサービスを比較するとき、各社のデモが魅力的でも、最後に「何を根拠に選んだのか」が説明できなくなることがあります。料金、機能、導入期間、セキュリティ、運用負荷の条件が整理されないまま提案を集めると、評価の後出しや検討のやり直しにつながります。
RFP（Request for Proposal、提案依頼書）は、調達したいものや制約、回答してほしい内容、選定の進め方を候補企業へ伝える文書です。ここではBtoB SaaSを例に、要件の整理→RFPの作成→回答の比較→選定理由の記録までを具体化します。
RFPの前に「何のために導入するのか」を決める
例えばマーケティングオートメーションを入れ替える場合、「機能の多いMA製品を買う」は目的ではありません。「現在の顧客データを営業と適切に共有する」「同意や配信停止を運用できる」「既存CRMと必要な情報を交換できる」など、導入後に確認できる状態へ言い換えます。
その際、現場担当者だけで決めず、利用部門、情報システム、セキュリティ、法務・購買、経営判断者の必要性を確認します。全員の希望を無条件に必須要件へ入れると、候補が一社も残らなくなる可能性があります。
必須条件と評価項目を分ける
RFPの中で最も重要なのは、満たさなければ導入できない条件と、より優れた提案に加点する条件を分けることです。例えば、必要なデータ保護契約を結べない場合は採点前に適格性を確認し、操作画面の使いやすさは評価項目として比較します。
米国連邦調達規則のFAR Subpart 15.3では、評価要素を調達目的に合わせ、提案間で意味のある比較ができるよう定義する考え方が示されています。同規則は米国政府調達のルールであり、すべての日本企業に直接適用されるわけではありません。ここでは評価基準を先に示し、その基準で比較するという手順を参考にします。
そのまま使えるRFPの構成
- 1. 背景と目的：現行業務、導入理由、解決したい問題、求める成果。
- 2. 対象範囲：利用者数、対象部門、データの種類、利用地域、連携システム。
- 3. 必須要件：機能・可用性・認証・法務・データ管理で欠かせない条件と、確認方法。
- 4. 評価項目：機能適合、運用性、導入支援、総費用、セキュリティなどの比較観点。
- 5. 回答形式：各要件への対応可否、代替案、証拠資料、制限、実現時期、追加費用。
- 6. 進行日程：質問受付、回答期限、デモ・検証、最終判断、契約・移行の予定。
- 7. 契約・運用条件：データの返却・削除、変更通知、障害時の責任分界、終了時の移行支援。
個別の企業名や未公開のシステム構成、顧客データなどは、候補企業に渡してよい情報か先に判断してください。詳細なアーキテクチャや機密性の高い資料は、契約やアクセス管理が整ってから必要な範囲で共有します。
評価表の例：重み付けは先に決めておく
以下は100点満点の説明用例です。一般的な正解の配点ではなく、導入目的ごとに重みを定めるためのテンプレートです。セキュリティなどの必須条件を満たすことは、加点項目の高得点で相殺しない設計も必要です。
- 業務要件への適合：30点 — 必要な業務を実行できるか、例外処理まで説明があるか。
- 既存システム連携・データ移行：20点 — API、同期方法、項目定義、移行検証、出口戦略。
- セキュリティ・運用管理：20点 — 組織の必須基準を満たしたうえで、追加の管理・監査性を比較。
- 費用・契約条件：15点 — 初期費用、利用料、従量課金、追加機能、解約時コストを含む総費用。
- 導入支援・保守：15点 — 計画、担当体制、障害対応、変更管理、サポート時間。
評価を再現可能にするには、0〜5段階などの採点基準を項目ごとに文書化します。例えば機能適合なら「0＝未対応」「3＝条件付きで対応」「5＝追加開発なしで検証済み」と定義する方法が考えられます。『営業担当の説明が良かった』といった印象だけで高得点にしないためです。
セキュリティは「認証取得の有無」だけで終えない
クラウドサービスでは、SOC 2やISO認証の有無を質問するだけでなく、対象範囲、実施主体、責任分界、データ保存先、アクセス制御、監査ログ、インシデント通知、バックアップと復旧、サブプロセッサーなど、実際の利用条件を確かめます。証明書や監査報告書は、対象サービス・対象期間が導入予定の範囲と一致するかも確認します。
2026年1月公開のCloud Security Alliance「Cloud Controls Matrix and CAIQ v4.1」は、クラウドのセキュリティ統制を整理する資料です。軽量な初回評価にはCCM-Lite／CAIQ-Liteも公開されており、全207統制を最初から質問する必要があるわけではありません。軽量版は96統制と138の質問から構成されます。
CAIQはベンダーの回答を比較するための共通言語になりますが、回答が「はい」なら自社での利用が安全だと保証するものではありません。機密度や利用規模、法令・契約上の条件と合わせて判定します。
サプライヤーのリスクは、実際に契約する前に確認する
米国NISTが2026年7月8日に公開したSP 1326「C-SCRM Due Diligence Assessment Quick-Start Guide」は、ICTサプライヤーのリスク評価に向けた実務的な出発点を示しています。主な調査領域は、所有・支配関係、製品やサービスの由来、レジリエンス、基本的なサイバー対策、サプライチェーンの階層です。
このガイドは、IT製品を選ぶあらゆる企業に同じ質問を義務付ける法律ではありません。調達のリスクに応じて、候補企業について何を調べ、どの証拠を要求するべきかを考えるための参考資料です。
ベンダーの回答を比較するときに起きやすい4つの失敗
- 後から配点を変える：好みの提案を有利にしやすく、意思決定の再現性を損なう。
- 『対応可』の意味が違う：標準機能か追加開発か、現時点で使えるか将来予定かを分ける。
- 総費用を見ない：データ移行、教育、外部支援、解約・返却の費用を忘れる。
- 証拠を要求しない：デモ、仕様書、契約条項、検証環境などで確認できない主張を採点してしまう。
特にデモは、営業担当が用意した成功例を見るだけでなく、自社の代表的な業務シナリオと例外処理を事前に共有し、同じ条件で検証する方が比較しやすくなります。選定者がすべての業務を一回のデモで確認できるわけではないため、未検証点を記録して契約前の条件としてください。
提案を受け取った後の意思決定ログ
最終結果だけでなく、必須条件の適合状況、評価担当、確認資料、点数の理由、未解決事項、契約条件、代替案、意思決定日を記録します。例えば「候補A：機能は高得点だが移行条件が不明」「候補B：運用負荷は低いが拡張機能に追加費用」といった差を示すことで、選定しなかった案を含めて理由を説明できます。
導入後には、選定時の想定に対して実際の利用や費用、ユーザーの負担がどう変わったかを確認します。選定時の評価点数だけで業務改善が達成されたと考えないことも大切です。
まとめ：RFPは要望リストよりも『判断の設計図』
よい提案依頼書は、ベンダーに大量の質問を投げるものではありません。導入目的と必須条件を明確にし、候補を公平かつ意味のある形で比較し、後から選定理由を説明できるようにする文書です。機能や価格の比較だけでなく、セキュリティや退出・移行時の条件も含めて、導入後の判断に耐える情報を揃えましょう。
関連記事として、RTO・RPOとSaaSの復旧条件、SLA・SLO・SLIと稼働率、BtoB競合比較表の作り方も参照できます。
主要資料と確認範囲
・Acquisition.gov／FAR Subpart 15.3：評価基準を調達目的に応じて定義し、提案間で比較可能にする原則。米国連邦政府調達の規則であり、日本の民間調達へ法的義務として適用するものではない。
・Cloud Security Alliance／CCM・CAIQ v4.1、CCM-Lite／CAIQ-Lite：クラウドの統制と質問項目の枠組み。
・NIST SP 1326（2026年7月）：ICTサプライヤーの事前調査における主要な観点。
※本文のRFP構成と100点の評価例は、上記の資料を参考にした当サイトによる説明用の例です。特定企業の導入成功を実証したデータではなく、法的・セキュリティ上の適合を保証するテンプレートでもありません。