【情報セキュリティマネジメント】調達とベンダー選定、基準は提案を見る前に決める｜RFI・RFP・RFQ・提案評価

システム調達では、最も安い提案を選べばよいわけではありません。

必要な情報を集め、要求を調達文書へ反映し、事前に定めた基準で提案を比較します。選定後は、役割・責任と受入れ条件を契約へ落とし込み、不要になったシステムを安全に終了するところまで管理します。

SGでは、RFI・RFP・RFQ、提案評価、セキュリティ要件の一貫性、契約・受入れ、システム廃棄を中心に判断します。読み終えると、調達文書の使い分け、提案評価の順序、契約・受入れ、廃棄までを一つの流れとして判断できるようになります。

先に結論：調達は先に決める

評価基準や要求事項を後から追加すると、公平な比較や契約上の履行確認が難しくなります。

1．RFI・RFP・RFQは求める内容で分ける

市場や実現方法が分からない段階で情報を集めるならRFI、要求に対する具体的な解決策を求めるならRFP、仕様が明確で見積りを求めるならRFQです。

RFI、RFP、RFQを必ず全て使用し、常に同じ順序で発行するわけではありません。調達の目的、規模、仕様の確定度に応じて必要な文書を選びます。

RFPでは比較できる情報を示す

RFPには、ベンダーが共通の前提で提案できる情報を示します。

• 調達の目的と対象範囲
• 業務・機能・非機能・サービス・セキュリティ要件
• 目標スケジュール
• 契約条件
• ベンダーの体制・技術・実績に関する要件
• 提案書・見積書の形式
• 必須条件と評価項目

要求が曖昧だと、提案ごとに前提が異なり、内容や費用を適切に比較できません。

2．提案評価の基準は受領前に定める

評価項目、配点・重み、必須要件、採点尺度は、提案を受ける前に定めます。

提案書が届いた後に、有力なベンダーへ有利な評価項目を追加してはいけません。後付けの基準では、公平性と選定理由の説明可能性が損なわれます。

必須要件を失格条件として定めた場合は、他の評価点が高くても、その未達を点数で補うことはできません。

複数人が評価するときも、評価者ごとに異なる尺度を使わず、共通の基準で採点します。評価結果と判断根拠を記録し、選定理由を説明できるようにします。

3．価格だけで調達先を決めない

最安値の提案でも、要求への適合度、実現可能な工程、必要な要員、セキュリティ、運用・保守費用に問題があれば、最適な提案とは限りません。

一方、評価項目を増やし過ぎると、何を重視した選定かが分かりにくくなります。調達目的と重要な要求へ対応する項目に絞り、重み付けの理由を明確にします。

4．セキュリティ要件を契約・受入れまで通す

セキュリティ要件は、RFPへ一度書けば終わりではありません。

要件定義 → RFP → 契約書 → 受入れ条件

この四つへ一貫して反映します。提案評価では、その間にベンダーの回答が要求水準を満たすかを確認します。

発注者側が要求水準を決めず、ベンダーの任意提案をそのまま採用すると、自組織のリスクに十分な対策かを評価できません。

また、見積額への影響を避けてRFPや契約へ記載しなければ、ベンダーは必要な対策、要員、費用、責任を提案へ織り込めません。

秘密保持、事故報告、再委託、契約終了時の返却・消去など、委託契約の詳細は「委託契約とセキュリティ要求事項」の記事で扱います。

5．契約では役割と受入れ条件を明確にする

契約では、価格と納期だけでなく、次を明確にします。

• 受け入れるシステム・成果物
• 費用と支払条件
• 受入れ時期
• 発注者とベンダーの役割分担
• 変更・報告・問題発生時の対応
• セキュリティ上の責任
• 受入れの判定基準

受入れでは、必要な機能、性能・可用性、セキュリティ要件、文書、移行データ、試験結果などを、合意済みの条件に基づいて確認します。

納品されたという事実だけで、自動的に受入れが完了するわけではありません。

6．廃棄までがシステムライフサイクル

システムを停止しただけでは、廃棄は完了していません。

基本的な順序は次のとおりです。

1. 法令・契約・社内規程による保存義務を確認する
2. 必要なデータ・記録を後継システムなどへ移行する
3. 保存対象と消去対象を分ける
4. 不要なデータを適切に消去する
5. 利用者・管理者・保守アカウントを停止する
6. 機器・媒体を安全に処分又は再利用する
7. 保守、クラウド、ライセンスなどの契約を終了・変更する
8. 実施結果を記録する

保存が必要な監査証跡まで消去してはいけません。一方、不要なデータや権限を残すと、情報漏えい・不正利用の原因になります。

確認範囲には、自社のサーバだけでなく、バックアップ、クラウド上の複製、委託先が保持するデータも含めます。

データ消去の技術は「データ保護とバックアップ」、情報資産台帳の更新は「情報資産の洗出しと台帳」、クラウドの出口戦略は「クラウドサービスの選定と評価」の各記事で扱います。

7．科目Bでの使われ方

判断手順は次のとおりです。

1. 情報・提案・見積りのどれを求める文書か
2. 評価基準と必須要件を提案受領前に決めたか
3. 全提案を共通の尺度で比較しているか
4. セキュリティ要件が契約・受入れまでつながっているか
5. 廃棄前に保存・移行・消去の対象を整理したか

担当者としては、評価基準や必須要件を提案受領後に変えず、決めた時点と内容を記録します。ベンダーから水準の緩和を求められた場合も、担当者限りで判断せず、調達・法務の担当部署や上位者へ報告して指示を仰ぎます。

よくある取り違え

まとめ

• RFIは情報、RFPは提案、RFQは見積りを求める
• RFI・RFP・RFQの全てを固定順序で使用するとは限らない
• 評価項目、重み、必須要件、採点尺度は提案受領前に定める
• 必須要件の未達は、他項目の高得点で補えない場合がある
• 価格だけでなく、要求適合度、工程、体制、技術、セキュリティを評価する
• セキュリティ要件は、要件定義、RFP、契約書、受入れ条件へ一貫して反映する
• 契約では、成果物、費用、時期、役割・責任、受入れ条件を明確にする
• 廃棄前に保存義務と移行を確認し、不要データ・権限・機器・契約を適切に終了する
• クラウド、委託先、バックアップを含めて廃棄範囲を確認する

関連記事

• C11-T02：システム化計画と要件定義
• C7-T01：委託先の選定と事前調査
• C7-T02：委託契約とセキュリティ要求事項
• C5-T10：データ保護とバックアップ

本記事は、2026年8月3日時点のSGシラバスVer.4.1を基準に作成しています。

参考資料

• IPA「情報セキュリティマネジメント試験（レベル2）シラバス Ver.4.1」
• IPA「情報システム・モデル取引・契約書（第二版）」（2020年12月22日公開）
• IPA「情報システム開発契約のセキュリティ仕様作成のためのガイドライン ～Windows Active Directory編～」（2020年12月22日公開）
• IPA「IT製品の調達におけるセキュリティ要件リスト活用ガイドブック（第2.1版）」（2026年2月公開）

関連する問題

• 情報セキュリティマネジメント システム戦略・システム企画・企業活動 一問一答 第6問〜第10問
• 情報セキュリティマネジメント システム戦略・システム企画・企業活動 択一式（応用） 第6問〜第10問