AIベンダーの選び方とRFP（提案依頼書）の書き方

AI導入の検討が動き出すと、まず「何社かに声をかけて見積もりを取ろう」という流れになりがちです。ところが要件が固まらないまま相見積もりを取ると、各社が想定した前提がばらばらで、金額も作業範囲も並べて比べられない資料が集まるだけになります。ここでは、比較できる提案を集めるためのRFP（提案依頼書）の書き方と、届いた提案をどう見極めるかを実務目線で整理します。

「とりあえず相見積もり」が比較にならない理由

同じ「AIで問い合わせ対応を効率化したい」という依頼でも、受け取ったベンダーが想像する中身は大きく変わります。既存のFAQを検索しやすくするだけの提案と、基幹システムと連携して回答まで自動生成する提案では、費用も期間も一桁違ってきます。前提がそろわない見積もりを金額だけで並べると、安く見える提案が実は範囲を狭く読んだだけというケースが少なくありません。

比較を成立させる条件は「全社が同じ土俵で答えている」ことです。そのために発注側が用意するのがRFPで、要は各社に同じ質問を、同じ形式で投げるための文書だと考えると分かりやすくなります。完璧な仕様書を書く必要はなく、決まっていないことは「未確定」と明記したうえで、判断に必要な前提だけをそろえれば十分に機能します。

RFPに書いておきたい項目

盛り込む内容は案件によりますが、次の9点が入っていれば提案の粒度はそろいやすくなります。

目的と対象範囲

• 背景と課題：なぜ今このテーマなのか。どの作業にどのくらいの人手と時間がかかっているのか。数値を出せる範囲で書くと、提案側が効果を試算しやすくなります。
• 対象業務の範囲：対象にする業務と、今回は対象外にする業務を両方書きます。「対象外」の明記は、後から範囲が膨らむ事態を抑えるのに役立ちます。
• 既存システムと連携要件：ERP・販売管理・CRM・グループウェアなど、関係するシステム名（一般名で可）とバージョン、APIやデータ出力機能の有無を記載します。

データとセキュリティの条件

• データの持ち方と鮮度：どこにどんなデータがあり、どの頻度で更新されるか。リアルタイムが要るのか、日次で足りるのか。ここが曖昧だと構成が決まらず、提案が抽象的になります。
• セキュリティ要件：個人情報や機密情報を扱うか、入力データを学習に使わせない条件が要るか、保管先の指定や監査ログの要否など。社内規程があれば該当箇所を引用します。

進め方と評価のルール

• 想定スケジュール：選定・着手・試験運用・本稼働の希望時期。決算期や繁忙期など動かせない事情も添えます。
• 評価基準と配点：価格・実現性・保守体制・セキュリティ・実績などの評価軸と、その重みを開示します。配点を先に示すと、各社が力を入れる方向がそろい、読み比べが楽になります。
• 体制と役割分担：発注側が担う作業（データ抽出、現場ヒアリングの調整、テスト協力など）と、ベンダーに任せる作業の境目を書きます。ここが空白だと、着手後に「それは御社の作業だと思っていた」というすれ違いが起きやすくなります。
• 費用の内訳提示フォーマット：初期費用・月額・オプション・保守を分けて記載してもらう形式を指定します。合計金額だけの提案は比較に使いにくいためです。

ゼロから書き起こすのが負担な場合は、AI導入 設計アシスタントに自社の状況を入力すると、目的・対象業務・データ・体制などを整理した設計書が生成されます。これをRFPの下敷きにすると、抜けの少ない骨組みを短時間で用意しやすくなります。書式まで含めて型が欲しい場合は、買い切り教材のAI導入 実務テンプレート集にRFPの雛形も収録しています。

届いた提案を比較する観点

提案書が集まったら、価格表よりも先に「書きぶり」を見ます。判断材料になりやすいのは次の点です。

• 「できる／できない」だけでなく「どう実現するか」が書かれているか：要件一覧に○×を並べた回答からは、実際の難易度を読み取れません。手順・使う仕組み・前提条件まで書かれた提案のほうが、検討が深い傾向があります。
• 運用開始後の保守範囲：障害対応の時間帯、問い合わせ窓口、外部サービスの仕様変更時の対応が誰の責任範囲か。作って終わりの見積もりは、翌年から想定外の費用が出やすくなります。
• 追加費用の発生条件：データ量・利用者数・処理件数が増えたときの課金の伸び方や、対象業務を1つ追加したときの費用感を、条件つきでよいので示してもらいます。
• データの所有権と契約終了時の扱い：投入したデータや蓄積された設定が誰のものか、終了時に返却・削除されるのか、エクスポート形式は何か。ここを詰めておくと乗り換えの自由度を保ちやすくなります。

見極めのために聞いておきたい質問

提案書だけでは分からない部分は、説明の場で直接尋ねます。相手の実務経験が表れやすい質問を挙げます。

• 「過去の類似案件で難航した点は何でしたか。どう乗り越えましたか」——順調だった話しか出てこない場合、類似の経験が薄い可能性があります。
• 「想定した精度が出なかった場合、どう対応しますか」——追加学習・ルール併用・適用範囲の縮小など、具体的な打ち手を持っているかを見ます。
• 「当社側にお願いしたい作業と工数はどのくらいですか」——発注側の負担を正直に示す相手のほうが、着手後の齟齬は少なくなりやすいところです。

内製と外注の分かれ目

すべてを外に出す必要はありません。目安として、業務の要件を決める部分は社内に残し、実装や運用基盤は外部に任せるという分け方が扱いやすい傾向があります。要件は自社の業務知識がないと決められず、丸ごと預けると出来上がったものが現場の手順と合わない事態になりがちだからです。

一方で、開発・保守を継続できる人がいないまま内製に踏み切ると、担当者の異動とともに動かなくなるリスクがあります。判断軸は、（1）数年にわたり手直しし続けられる人がいるか、（2）扱うデータを外部に預けてよいか、（3）失敗してもやり直せる規模か、の3点で整理すると考えやすくなります。迷う段階なら、小さな範囲で外部の力を借りて型を学び、二つ目以降を内製に寄せる進め方も選択肢です。

よくある質問

Q. RFPは何ページくらい書けばよいですか？

分量よりも、前述の項目が埋まっているかが重要です。小規模な案件なら数ページ程度でも比較可能な提案は集まります。体裁を整えることに時間をかけすぎて検討が止まるほうが機会損失になりやすいため、未確定の項目はそう明記して先に配布し、質疑で埋めていく進め方でも実務は回ります。

Q. 何社に声をかけるのが適当ですか？

ケースによりますが、3社前後で比較する例が多く見られます。社数を増やすほど検討の手間が増え、評価が浅くなりがちです。規模の異なる相手を混ぜると、同じ課題に対する解き方の幅が見えて判断材料が増えます。

Q. 費用の目安が分からず、予算枠の書き方に困っています。

金額を伏せると、想定と桁の違う提案が届いて比較が難しくなることがあります。上限額を書きにくい場合は、「初年度はこの範囲で試験導入し、効果が確認できれば次年度に拡大を検討する」といった投資の考え方を示す方法があります。費用は業務内容と連携先の複雑さで大きく変わるため、社内の試算は削減できる時間や工数から逆算しておくと妥当性を判断しやすくなります。

ベンダー選定は、相手を見極める作業であると同時に、自社の要件を言語化する作業でもあります。RFPを書く過程で「何を任せたいのか」がはっきりすると、提案の読み方も契約後の進め方も変わってきます。個別に相談したい場合はご相談・料金のページもあわせてご覧ください。