RFPの目的は「良い提案をもらうこと」ではない
RFPを「自社の要望を漏れなく伝える文書」と定義すると、分厚くなるほど良いRFPということになります。しかし実務で困るのは、提案が来ないことではなく、来た提案を横に並べられないことです。
500項目の機能要件を並べて全社が「対応可」と答えれば、その500項目は選定に一切寄与しません。金額だけが残り、最も安い見積もり＝スコープが最も狭い見積もりが選ばれます。
RFPの目的はひとつに絞れます。各社の回答を、同じ単位で並べられる形にすること。そのために必要な仕掛けは3つです。
- 機能への回答を4区分に強制する
- 数量前提を発注側が固定して渡す
- 見積もりに含まれない範囲を明記させる
以下、それぞれを設問レベルで具体化します。
仕掛け1：機能要件を「標準／設定／追加開発／実現不可」の4区分で答えさせる
「対応可否（○×）」で聞くと、ほぼ全項目が○になります。○の中身が、標準機能なのか、パラメータ設定なのか、スクラッチ開発なのかが区別されないためです。この区別こそが金額と将来の保守性を決めます。
| 区分 | 定義（RFPに明記する） | 意味 |
|---|---|---|
| S：標準 | 製品出荷時の機能で、設定変更なしに要件を満たす | 追加費用なし。バージョンアップ時の再検証も最小 |
| C：設定 | 製品が提供する設定・パラメータ・画面定義機能の範囲で満たす（コード記述を伴わない） | 実装工数は発生するが、バージョンアップで壊れにくい |
| D：追加開発 | コード記述、カスタム画面、外部プログラムを伴う | 費用が発生し、バージョンアップのたびに再検証が必要 |
| N：実現不可 | 当製品では満たせない | 代替案の記述を必須にする |
D（追加開発）には工数（人日）と単価の記入を必須とします。この欄が埋まると、各社の見積もり総額の差が、ライセンス差なのか追加開発量の差なのかが読めます。
この図の読み方には注意が必要です。標準適合率が高い＝良い、ではありません。C社は実現不可が9件あり、その9件が自社の必須要件であれば失格です。逆にB社は追加開発20件と多いものの、そのうち15件が「あれば望ましい」レベルの要件なら、スコープを削れば適合します。
つまり4区分回答は、それ単体では順位を決めません。要件側に必須／推奨／任意の優先度をあらかじめ振っておいて初めて機能します。RFPの機能要件一覧には、要件ごとの優先度列を必ず設けてください。
仕掛け2・3：前提を固定し、除外範囲を1項目ずつ答えさせる
数量前提を発注側が固定する
各社が自社に有利な前提を置くと、見積もりは比較できません。次の数値はRFP本文で発注側が指定し、「この数値を用いて見積もること」と明記します。
| 指定する数量 | 記載例 |
|---|---|
| 対象拠点数・ライン数 | 1工場、3ライン |
| 対象工程数 | 実績を記録する工程 84 |
| 同時接続端末数 | 現場端末 32台（うちハンディ 12台） |
| 名前付きユーザー数 | 現場作業者 260名、管理者 24名 |
| 接続する設備台数と世代 | 42台（うち2010年以前の設備 18台、通信手段未確認 6台） |
| 想定トランザクション件数 | 実績登録 12,000件／日、ピーク 1,400件／時 |
| 保管期間 | 品質記録10年、稼働データ3年 |
| 稼働時間・停止許容 | 24時間3シフト、計画停止は月1回4時間まで |
「通信手段未確認 6台」のように、分からないことは分からないと書いてください。曖昧なまま渡すと各社が異なる仮定を置き、後から差額請求の根拠になります。未確定項目には「PoCで確定する」「確定後に再見積もり」と処理方針を書き添えます。
見積もりに含まれない範囲を1項目ずつ答えさせる
最も安い見積もりの多くは、この欄が空欄です。「本見積もりに含まないもの」を自由記述にすると、各社が書きたいことだけを書きます。チェックリスト形式で、含む／含まない／別途見積もりの3択で答えさせてください。
- 既存システムからのデータ移行（移行ツール作成、データクレンジング）
- 設備接続の実機調査と現地作業
- ネットワーク工事、現場端末の調達・キッティング
- OS・DBのライセンス費用
- 現場作業者への操作教育（回数と対象人数を明記）
- 並行稼働期間中の運用支援
- 適格性評価（IQ/OQ/PQ）文書の作成と実施
- カットオーバー当日の立ち会い
- 稼働後3か月の初期サポート
- 年次バージョンアップ作業の工数
設問の書き方：比較不能になる問いと、比較可能になる問い
同じことを聞いていても、問い方で回答の質が変わります。
| 比較不能になる問い | 比較可能になる問い |
|---|---|
| トレーサビリティ機能はありますか | 添付の工程フローで、工程12（混合）を通過した製品について、投入した3つの原材料ロットから完成品シリアルまでの順逆双方向の追跡を、標準機能で行えますか。画面イメージを添付してください |
| 他システムと連携できますか | ERPへ工程完了実績を返す際、①連携方式（API／ファイル／DB直接）②標準で提供されるインターフェース定義の有無 ③1件あたりの標準的な遅延時間 を記載してください |
| 導入実績を教えてください | 多品種少量生産（1品目あたり月産500個未満、品目数1,000超）の国内工場での稼働実績を、件数と稼働開始年で記載してください |
| セキュリティ対策は万全ですか | 監査証跡として記録される項目（変更前値・変更後値・変更者・変更日時・変更理由）のうち、標準で記録されるものを列挙してください。記録の改ざん防止方式も記載してください |
| 保守サポート体制を教えてください | 障害の一次受付窓口の言語と受付時間、重大障害時の初動着手までの時間目標、その目標が契約書のどの条項に規定されるかを記載してください |
| AIに対応していますか | 貴社製品に組み込まれているAI機能について、①機能名 ②推論の実行場所（オンプレ／クラウド／ベンダー側） ③学習に顧客データを使用するか ④出力の根拠を提示する仕組みの有無 を記載してください |
右列に共通するのは、回答の形式まで指定していることです。「記載してください」だけでは分量も粒度もばらつきます。項目番号を振り、記入欄を持つ様式ファイル（表計算形式）として配布するのが確実です。
なお最終行のAIに関する設問は、2026年時点では必須項目になりつつあります。Gartnerが2026年3月23日に公開したMarket Guide for Manufacturing Execution Systemsは、MES選定の観点として相互運用性（オープンAPI・MCP整合）と、セキュリティ・観測性・human-in-the-loopという信頼メカニズムを挙げ、「派手な機能ではなく測定可能な成果に集中せよ」としています。AI機能の有無ではなく、推論の実行場所とデータの扱いを聞くのが実務的です。
章構成と、回答が返ってきた後の突合
必ず入れる7つの章と、入れてはいけない1つ
入れる章：
- 背景と目的──なぜ導入するのか、達成したいKPIを数値で記載
- 対象範囲──対象拠点・ライン・工程と、明示的な対象外の一覧
- 数量前提──前節の指定値。全社共通で使用させる
- 機能要件──要件ごとに優先度（必須／推奨／任意）と4区分回答欄
- 非機能要件──可用性、応答時間、保管期間、セキュリティ、監査証跡
- 提案・見積もり様式──6分類での費用記載、5年TCO、除外範囲チェックリスト
- 選定プロセスと評価方法──評価軸と配点、スケジュール、質疑応答の締切
入れてはいけないもの：現行業務の詳細手順書。現行手順をそのまま添付すると、各社はそれを実現する提案を作ります。結果として標準機能から外れた作り込みの提案が集まり、費用が跳ね上がります。渡すべきは「現行の手順」ではなく「満たすべき要件」です。現行手順は、質疑応答フェーズで必要に応じて開示すれば足ります。
回答が返ってきた後：最後に効くのは前提条件の統一
回答が揃ったら、点数化の前に前提条件の突合を行います。作業は3つです。
1. 除外範囲の差分を金額に戻す。 A社が含み、B社が含まない項目を洗い出し、B社の見積もりに追加見積もりを取ります。この作業をせずに総額を比較すると、スコープの狭い提案が最安値として上位に来ます。
2. 「実現不可（N）」の中身を優先度と突き合わせる。 必須要件にNが1つでもあれば、その時点で候補から外すか、要件そのものを見直すかの判断が必要です。要件を見直すなら、全社に同じ変更を通知して再回答を求めます。
3. 追加開発（D）の工数を合計し、5年間の再検証コストを加算する。 追加開発は一度作れば終わりではありません。年1回のバージョンアップごとに動作確認が必要です。目安として、初期開発工数の10〜20%を毎年の再検証工数として5年分加算し、その上で総額を比較してください。追加開発が多い提案は、この加算で順位が入れ替わることがあります。
この3つを終えて初めて、点数化に意味が出ます。RFPの様式そのものはMES RFPテンプレートを出発点にできます。
よくある質問
RFPは何社に出すべきですか？
4〜6社が実務的な上限です。回答の突合と前提条件の統一に、1社あたり数日から1週間かかります。8社を超えると比較作業自体が破綻し、結局は総額の安い順に見るだけになります。事前に情報提供依頼（RFI）で製品カテゴリと対応可能規模を確認し、明らかに合わない候補を落としてからRFPを出すと、質を落とさずに社数を絞れます。
要件が固まっていない状態でRFPを出してはいけませんか？
機能要件が固まっていなくても、対象範囲と数量前提が固まっていれば出せます。逆に、対象範囲が未定のままRFPを出すと、各社が異なるスコープで提案し、比較不能な資料が集まります。「やらないこと」の一覧が書けていれば、機能要件の詳細は質疑応答で埋められます。範囲確定の進め方はMESの要件定義でつまずく5つの論点で扱っています。
ベンダーからの質問にはどこまで答えるべきですか？
質疑応答は全社に同じ内容を開示するのが原則です。1社からの質問と回答を、質問元を伏せて全社に配布します。これを行わないと、質問した社だけが精度の高い提案を出し、評価が情報格差の比較になります。開示できない情報（原価情報、取引先名など）は「開示不可」と明示し、その前提で提案させてください。締切を設け、締切後の質問は受け付けないことも事前に明記します。
統合性はどの程度重視されていますか？
Rockwell Automationが2026年7月28日に公開した調査（17カ国1,560名）では、MES購買要件の第1位に「統合性」を挙げた回答者が44%でした。同調査ではMES導入済みが93%である一方、ERP・PLM・品質・OTと完全統合できているのは23%にとどまります。RFPで統合要件を機能一覧の末尾に置くのではなく、独立した章として扱い、連携方式・データ粒度・遅延時間・エラー時の再送方式まで踏み込んで問うのが妥当です。
