チャットボットRFPの作り方｜比較できる要件表

チャットボットRFPの作り方を検討している担当者に向けて、複数の提案を同じ基準で比較するための要件を整理します。RFP（提案依頼書）では、希望する機能を並べるだけでは不十分です。対象業務と対象外業務、回答してはいけない条件、検証方法、見積もりの前提、運用時の担当範囲まで明記する必要があります。

比較の要点は、すべての候補へ同じ資料を渡し、同じ形式で回答を求めることです。現状整理から要件表、受入テスト、費用表、デモ、採点、契約前確認まで、チャットボットRFPの作り方を順に解説します。

チャットボットRFPでそろえるべき文書と比較条件

チャットボットのRFPは、本体と別紙に分けると管理しやすくなります。RFP本体には、導入目的、対象業務、対象外業務、利用環境、前提条件、提案範囲、選定日程を記載します。別紙には、要件回答表、費用表、デモ台本、質疑票、採点表を用意します。

候補ごとに質問や提出形式が異なると、提案内容を横並びで比較できません。配布時には資料の版、回答期限、質問受付期限、回答方法を統一します。途中で前提を変更した場合は、変更内容を全候補へ同時に共有し、旧版との差分が分かるように管理してください。

チャットボットの提案依頼書を配布する前に、各文書の項目名と回答形式が一致しているか確認します。たとえば、要件回答表で追加費用の有無を尋ねるなら、費用表にも対応する記入欄を設けます。要件IDを各資料に記載し、要件、検証結果、費用の対応関係を追えるようにすることが、比較を成立させる最初の判断基準です。

RFPを書く前に現状の問い合わせと対象範囲を切り分ける

最初に、現在受けている問い合わせを確認します。問い合わせ内容だけでなく、件数、回答に使う情報、個人情報の有無、判断の難しさ、有人対応が必要な理由を整理してください。件数や内容を把握できていない場合は、取得可能な記録だけを対象に分類し、推測値を確定情報として扱わないようにします。

分類後は、各問い合わせを「自動回答」「情報を確認してから回答」「有人対応」の三つに振り分けます。営業時間や公開済みの手続き案内は自動回答、必要な条件が不足している手続きの質問は確認質問後に回答、個別契約の解釈や解約の可否に関する判断は有人対応とする、といった切り分けです。

対象範囲は、チャネル、利用者、時間帯、問い合わせ種別まで指定します。「顧客対応を自動化する」だけでは、各社が異なる範囲を想定してしまいます。「Webサイトの訪問者を対象に、公開済みの営業時間と手続き方法を案内する」のように、誰が、どこで、何を完了するのかを示します。

同時に対象外も記載します。個別の契約判断、料金の確定、本人確認を伴う手続きなど、自動回答させない内容を明示してください。対象外の質問を受けたときは回答を生成せず、適切な窓口へ案内する動作も要件に含めます。

整理項目を確認したい場合は、チャットボットの要件チェックリストを使うと、機能だけでなく運用担当や有人対応の条件まで確認できます。チェック結果をそのまま転記するのではなく、自社で採用する範囲と対象外を決めてからRFPへ反映します。

機能要件を利用者の行動と完了条件で書く

機能要件は、機能名ではなく、利用者の行動と完了条件で記載します。「多言語対応」「有人連携」「ログ管理」だけでは、対応範囲や検証方法が分かりません。対象者、開始条件、実行する処理、完了状態、例外時の動作を一つの要件としてまとめます。

たとえば「多言語対応必須」は、「日本語と指定言語について同一内容のテスト質問を実行し、回答内容、参照根拠、回答不能時の案内を確認できること」と書き換えます。対象言語や質問内容が未確定なら、その点を未決事項として示し、ベンダーごとに異なる前提で見積もらせないことが重要です。

有人連携では、単に「担当者へ引き継げること」とせず、切替を開始する条件、受付時間内と時間外の動作、担当者へ渡す会話履歴、利用者へ表示する案内を定めます。担当者が同じ質問を聞き直さずに済む状態を完了条件とする場合は、引き継ぐ項目と閲覧権限も確認します。

各要件には、必須、推奨、任意の区分を付けます。すべてを必須にすると、要件ごとの重要度が伝わらず、追加対応の範囲も広がります。対象業務を完了するために欠かせないものを必須とし、運用上の利便性を高めるものは推奨または任意として切り分けてください。

生成AIの回答品質と答えない条件を受入テストにする

生成AIの要件定義では、回答できることと同じくらい、回答しない条件が重要です。「高精度に回答する」とだけ記載しても、質問の種類、正解の定義、評価方法が候補ごとに異なります。発注者側でテスト質問と期待する動作を用意し、同じ条件で確認します。

テストセットには、通常の質問、表記揺れ、情報不足の質問、対象外の質問、禁止する回答を誘う質問、更新済み情報に関する質問を含めます。質問数や合格率を一律に決めるのではなく、誤回答が業務へ及ぼす影響と、実際の問い合わせ範囲に基づいて構成してください。

採点対象は回答文だけではありません。参照した根拠を確認できるか、情報が足りないときに確認質問を返すか、回答してはいけない内容を拒否できるか、必要な場面で有人対応へ切り替えられるかを分けて評価します。回答が自然でも、根拠を確認できない場合は未確認項目として残します。

たとえば、利用者がその場では確定できない料金を尋ねた場合は、金額を推測せず、不足情報を確認するか担当者へ引き継ぐことを受入条件にします。期待する文言を完全一致で固定する必要はありませんが、「推測しない」「確認先を示す」「必要に応じて有人対応へ切り替える」という判定項目は明確にします。

テスト結果には、質問、期待する動作、実際の回答、根拠、判定、判定理由を保存します。評価者によって判断が分かれる場合は、判定基準を修正してから候補を採点します。製品資料に記載された精度や効果を、そのまま自社での受入結果として扱わないことも重要です。

非機能・セキュリティ・データ要件を質問形式で確認する

非機能要件は、「セキュリティ対策済み」「安定稼働」のような一語で終わらせず、確認したい事実を質問形式にします。可用性、障害通知、権限管理、操作ログ、バックアップ、サポート、データの保存と削除、契約終了時の移行に分けて回答させます。

データについては、保存場所、保持期間、削除方法、外部サービスへの送信先、学習利用の有無を確認します。回答には、対応可否だけでなく、標準提供か追加対応か、制約、担当主体、確認できる正式資料を記載してもらいます。正式な条件は、提案書だけでなく、契約書、利用規約、セキュリティ資料などでも確認してください。

回答の証拠を確認する観点は、AIチャットボットのセキュリティ確認項目でも整理しています。RFPでは自社が扱うデータと運用に関係する項目を選び、一般的なチェック項目を無条件に増やさないようにしてください。

可用性やサポート条件は、契約前の確認事項にもつながります。候補を絞った段階では、チャットボットのSLA・契約確認ガイドを参照し、障害連絡、対応時間、対象外条件を提案内容と照合します。

費用を同じ利用条件の総費用表で比較する

見積もりは、同じ利用条件を全候補へ提示して取得します。利用者数、想定する問い合わせ量、対象チャネル、データ保存期間、連携先、サポート時間、契約期間などの前提が異なると、合計額だけでは比較できません。数量が確定していない場合は、算定方法と見積もりに使った仮定を明記させます。

費用表では、初期設定、データ整備、月額固定、従量課金、外部API、保守運用、追加開発、教育、契約終了時の移行を別の行にします。税込・税別、単価、数量、上限、超過時の扱い、発注者が担う作業も記入項目にしてください。

固定的な相場をRFPへ書く必要はありません。各社の最新見積もりを、共通の利用条件で取得してください。安価な提案でも、データ整備や外部サービス、終了時移行が別料金なら総費用は変わります。一方、必要のない追加機能を含む提案は、その費用と対象業務への適合性を分けて評価します。

回答表・質疑管理・デモ台本を使って提案を採点する

要件回答表には、要件ID、要件内容、必須度、配点を発注者側で記入します。ベンダーには「標準対応・追加対応・非対応・要確認」の区分を選んでもらい、制約、追加費用、提供時期、確認資料を回答させます。「対応可能」だけの回答は、提供条件が分かるまで確定扱いにしません。

質疑は候補別の個別回答で終わらせず、提案条件に影響する回答を全候補へ共有します。質問者名など共有不要な情報を除き、質問、回答、回答日、RFPの変更有無を一つの質疑票で管理してください。回答によって要件や日程を変更した場合は、文書の版も更新します。

デモでは、候補ごとの自由説明だけでなく、共通台本を使います。「通常質問」「表記揺れ」「対象外質問」「古い情報を前提にした質問」「有人切替」など、受入テストにつながるシナリオを同じ順序で確認します。その場で確認できなかった項目は、説明だけで高得点にせず、未確認として記録します。

選定は、書面確認、共通デモ、必要な場合のPoC、採点根拠の保存という順で進めます。PoCは必須工程ではありません。書面やデモでは確認できず、かつ導入判断に影響する要件が残る場合に実施を検討します。実施の要否は、チャットボットでPoCを行うか決める基準で確認できます。

採点では、必須要件を満たすかを先に確認し、その後に推奨・任意要件、費用、運用条件を評価します。価格だけで順位を決めず、対象業務への適合、回答しない条件、証拠の有無、追加対応の範囲を含めて判断してください。比較軸の優先順位を整理する際は、チャットボットの選び方も参考になります。

契約前に責任分界と変更手順を確定する

候補を選んだ後は、提案書の内容をそのまま契約条件とみなさず、運用時の責任分界を確認します。生成AI提供者、SaaS事業者、導入支援会社、発注者が関係する場合は、データ登録、回答内容の確認、障害対応、利用者への告知、ナレッジ更新を誰が担うか整理してください。

誤回答、外部サービスの停止、仕様変更、費用条件の変更、契約終了が発生した場合についても、連絡経路、判断者、対応期限、データ移行方法を確認します。責任の所在を抽象的に決めるのではなく、事象の検知、一次対応、原因調査、利用者への連絡、復旧、再発防止の各作業を切り分けます。

仕様変更時は、変更内容の通知方法、要件への影響確認、追加費用の承認手順、適用時期を決めます。チャットボットRFPの回答表、費用表、デモ結果に記載された条件が、契約文書や正式資料と一致しているかも照合してください。法的な判断が必要な条項は、社内の契約担当者や専門家へ確認します。

チャットボットRFP作成時のよくある質問