AI開発の相談を始めたものの、ベンダーごとに提案の粒度も金額の内訳も異なり、比較に迷うことがあります。その一因は、提案依頼書（RFP）の情報が不足し、各社が別々の前提で見積もっていることです。この記事では、RFPで整理したい7項目、比較表の作り方と配点例、面談での質問リストを手順にまとめます。
- 対象業務を1つに絞る 現行フローと件数を書き出す
- RFPに7項目を記載する 各社に同じ条件で渡す
- 提案を比較表に並べる 評価軸に配点を置く
- 上位2〜3社と面談する 質問リストで前提を確認する
- 小さく始める範囲を決める 検証してから本開発へ
なぜ提案が比較できなくなるのか
「AIで問い合わせ対応を効率化したい」とだけ伝えると、A社はチャットボット、B社は社内検索、C社は業務フローの見直しを前提に提案します。実現方式が違えば金額も期間も変わり、金額だけの比較に偏りやすくなります。方式が異なる提案も、目的への適合性と対象範囲を整理して比べることが大切です。
もう一つの原因は、データの所在と連携先が書かれていないことです。開発費にはモデルの利用や調整に加え、データ整備・取得・既存システムとの接続も影響します。これらが未確定だと、各社が異なる仮定で見積もり、後で範囲や費用の見直しが必要になる可能性があります。未確定事項は仮定と確認方法を明記してもらいます。
各社の技術や体制を比べる前に、見積もりの前提情報と対象範囲を確認します。
RFPに書く7項目
まずは次の7項目を整理します。A4で3〜5枚程度は初期整理の一例であり、必要な分量は業務の複雑さによって変わります。不明点を無理に埋めず、未確定事項として示し、提案時に置く仮定を各社へ確認してください。
| 項目 | 書く内容 | 不足した場合の懸念 |
|---|---|---|
| 1. 目的 | 何をどの状態にしたいか。評価用データ・達成基準・人による確認の範囲 | 成功の定義が各社バラバラになる |
| 2. 対象業務 | 対象の部署・業務・対象外の範囲 | 範囲が広がり金額が膨らむ |
| 3. 現行フロー | 誰が何を使ってどう処理しているか。月間件数 | 工数の見積もり根拠がなくなる |
| 4. データの所在 | どのシステム・ファイルに、どの形式で、何件あるか | 接続費用が見積もりから漏れる |
| 5. 連携先 | 既存の基幹システム、SaaS、取り込みと書き出しの方向 | 開発後に接続できない事態が起きる |
| 6. 制約条件 | 予算の幅、希望時期、データ利用・保管条件、担当者の稼働 | 実行できない提案が混ざる |
| 7. 評価観点 | 必須条件、何を重視して選ぶか、配点 | 各社が売りたいものを前面に出す |
書き方のコツ
- 目的は「精度を上げる」ではなく「現在1件15分かかっている確認作業を、担当者が目視確認する形で短縮する」のように、作業単位で書きます（件数や時間は自社の実測値を入れてください）。
- 現行フローは、例えば箇条書きで「①受信 ②転記 ③上長確認 ④返信」と並べます。分岐や例外が多ければ図も添えます。どの工程を置き換えたいかに印を付けます。
- データは形式や品質、例外が分かるサンプルを用意します。共有権限や秘密保持条件を確認し、個人情報・機密情報を除いた模擬データを優先してください。マスキングしただけで安全と判断せず、共有範囲・保存期間・外部AIへの入力可否も確認します。
- 評価観点と配点をRFPに先に書くことは、各社への誘導ではなく、比較の公平性を保つための情報です。
比較表の作り方と配点
提案書が集まったら、各社の資料の構成に引きずられないよう、自社で作った表に転記します。転記する時点で「書いていない」ことが見えるのが目的です。
| 評価軸 | 配点の目安 | 見るポイント |
|---|---|---|
| 課題理解 | 20 | 発注側の現行フローと課題を具体的に捉えているか |
| 実現方式の妥当性 | 20 | なぜその方式かの理由と、採らなかった案の説明 |
| 既存環境との連携 | 15 | 接続方法と、接続できない場合の代替案 |
| 体制と進め方 | 15 | 担当者の役割、自社側に求める作業量 |
| 運用・改修 | 15 | 公開後の修正の依頼方法と費用の考え方 |
| 金額 | 15 | 同じ対象範囲・利用量・期間での総費用、内訳、追加費用の条件 |
上の配点は合計100点の例であり、金額の比重に一律の正解はありません。予算や案件のリスクに合わせ、提案を受け取る前に社内で決めます。必須のセキュリティ条件や接続要件は、合計点で相殺せず、満たすかどうかを別に確認してください。
各評価軸の採点基準と根拠もそろえます。例えば「根拠なし・一部確認・十分確認」のような段階を決め、未記載は確認待ちとして扱います。合計点に加えて未解決の前提やリスクを確認し、最終判断を行います。
費用は初期開発だけでなく、想定利用量でのAPI・クラウド・ライセンス・保守・データ整備・改修・移行費も含め、同じ期間と範囲で比較します。税の扱い、見積有効期限、従量費の算定条件や対象外作業をそろえ、追加作業は見積もりと承認を経て進める手順を確認します。
面談で確認する質問リスト
提案書だけでは、進め方の実態は分かりません。上位2〜3社に絞って面談し、同じ質問を投げます。
進め方について
- 最初の1か月で何を決め、何を成果物として出しますか
- 当社側は誰が、週あたりどれくらいの時間を使う想定ですか
- 要件変更の影響をどう見積もり、費用・納期の変更を誰が承認しますか
技術と連携について
- 既存システムからのデータ取得はどの方式を想定していますか。それが使えない場合の代替は何ですか
- 想定した精度や処理結果が出なかった場合、どの段階で判断し、どう方針転換しますか
- 評価用データと受入基準をどう定め、誤回答や例外を誰が確認しますか
- 成果物のプログラム・設定・データについて、利用権限、提供形式、第三者サービスの制約、他社への移行条件はどうなりますか
- データをどこで処理・保管し、誰がアクセスできますか。外部AIでの学習利用や削除条件はどう確認しますか
運用について
- 公開後、文言や条件の変更は誰がどう行いますか
- 保守の範囲に含まれるもの、含まれないものを具体的に教えてください
- 担当者が交代する場合、引き継ぎはどう行われますか
面談では技術的な実現性と根拠を確認し、自社側の作業量、運用体制、想定どおりに進まない場合の対応まで具体化します。
小さく始めて判断する
7項目を埋める過程で「データの所在がはっきりしない」「効果の見込みが立たない」と分かることもあります。その場合は、いきなり本開発を発注せず、対象業務を1つに絞った検証を検討します。検証の期間・費用・成果物・評価用データ・次へ進む基準と、中止や見直しの条件を先に決めます。検証で良い結果が出ても、本番のデータ量や例外処理、セキュリティ、運用費は別に確認が必要です。
本開発を検討するために確認したい状態
- 対象業務と対象外が文書で確定している
- データの形式・件数・取得方法が確認済み
- 検証で「次へ進む／見送る」の基準を満たした
検証から始めた方がよい状態
- 効果の見込みが数字で置けない
- データが複数システムに分散し実態が不明
- 社内で対象業務の優先順位が合意できていない
当社のAIコンサルティング・システム開発では、AI活用領域の見極めや構想・ロードマップの整理、PoC設計と効果検証、要件定義、開発、既存環境との連携、運用改善までを支援しています。RFPを書く前段階の「どこから手を付けるか」の整理からご相談いただけます。具体的な支援範囲・成果物・費用は、対象業務やデータの状況を確認したうえで個別にご提案します。
よくある質問
Q: RFPはどれくらいの分量が必要ですか
A: 分量よりも必要な情報と未確定事項が伝わるかが重要です。目的・対象業務・現行フロー・データの所在・連携先・制約条件・評価観点を整理し、各社が置いた仮定や対象外の範囲も確認します。形式を整えることに時間をかけるより、現行フローの件数など実測値を入れることを優先してください。
Q: 予算額をRFPに書くと、その額いっぱいの提案が来るのではないですか
A: 予算を伏せると、実行不可能な提案や過大な提案が混ざり、比較のやり直しが発生しやすくなります。上限額をそのまま書くことに抵抗がある場合は、幅を持たせて記載し、あわせて「この範囲で優先する機能」を明示する方法があります。判断は社内の調達ルールに合わせてください。
Q: 1社だけで進めてはいけませんか
A: 社内の調達ルールや案件の条件によっては、既存の取引先を選ぶ方法もあります。ただしその場合も7項目を文書にし、前提条件と見積もりの内訳を書面で受け取ってください。比較相手がいない場合は特に、技術・費用の妥当性、受入基準、変更手順、運用や引き継ぎの条件を確認し、段階ごとに判断できるようにします。
まとめ
提案を比較するときは、各社の方式や体制の違いと、RFPの前提情報の不足を分けて整理します。目的・対象業務・現行フロー・データの所在・連携先・制約条件・評価観点の7項目を書き、各社に同じ条件で渡すことから始めてください。集まった提案は自社で作った比較表に転記し、必須条件を確認したうえで、案件に合った配点と採点基準で評価します。面談では技術的な実現性に加え、自社側の作業量と、想定どおりにいかなかった場合の進め方を確認します。7項目を埋める作業そのものが、社内で何を実現したいのかを明確にする工程になります。
