本文へスキップ
tech公開更新約9分で読めます

コールセンターAIのRFPで対象外をどう書くか、できること一覧だけで選ばない

シェア
コールセンターAIのRFPで対象外をどう書くか できること一覧だけで選ばない

コールセンターAIのRFP(提案依頼書)で先に書くのは、AIにさせないことです。できてほしい機能をいくら並べても、対象外が空白なら、各社は自分に都合のよい範囲を想定して提案します。

届いた提案の差は、製品の差ではなく範囲の読み違いになります。

対象外はベンダーに提案させるものではなく、発注側が書いて渡すもの、というのがこの記事の立場です。書く場所は4つあります。対象用件の完了地点、人に残す判断、対象外の用件への答え方、受入条件との対応です。

記載例はどれも編集部が作った案です。自社の法務と調達規程に照らしてから使ってください。

対象外が空白だと契約後に範囲でもめる

対象外が空白だと契約後に範囲でもめる

「AIで問い合わせを自動化したい」とだけ書いたRFPには、3種類の提案が届きます。FAQに答えるだけの提案、手続きの受付までする提案、基幹システムを書き換えて手続きを終わらせる提案です。

どれも「自動化」です。金額は当然そろいません。

困るのは選んだ後。試験導入が始まってから「返金の可否はAIが答えるのか」「契約者以外からの電話はどうするのか」が出てきて、追加費用か、範囲の縮小かの交渉になります。

公的な調達でも、範囲と限界を文書に残す考え方が基本になっています。米国立標準技術研究所(NIST)のAIリスク管理フレームワークは、AIシステムの知識の限界と、出力を人がどう使い監督するかを文書に残すことを項目に挙げています。

デジタル庁も、生成AIの調達・利活用ガイドラインの別紙に調達チェックシートと契約チェックシートを付けました。企画者はこれを参照して調達仕様書と契約書を作ります。政府向けの文書ですが、民間のRFPでも章立ての参考になります。

対象用件は「完了地点」まで書く

対象用件を「住所変更」「解約」のように用件名だけで書くと、どこまでやれば終わりなのかが各社で分かれます。用件ごとに、AIの仕事が終わる地点を書きます。

完了地点は次の4段階で指定すると、提案をそろえやすくなります。

段階

AIの仕事が終わる地点

例

案内

手続きの方法を伝えた

解約の手順とページを案内する

受付

必要な項目を聞き取り、人の処理待ちに入れた

住所変更の内容を聞き取り、担当者の確認待ちにする

実行

システムに登録し、手続きが終わった

配送日の変更を基幹システムに反映する

対象外

AIは扱わず、決めた窓口へ渡す

返金の可否の判断

RFPには、用件の一覧にこの段階を1列足します。記載例です。

用件

完了地点

対象外にする範囲

配送状況の確認

実行(照会して回答)

配送事故の補償に関する回答

住所変更

受付

契約者本人以外からの申し出

解約

案内

解約金の減免に関する回答

料金の問い合わせ

案内

個別の請求額の訂正

見てほしいのは右の列。同じ用件の中にも、AIに答えさせない部分があります。用件単位で「対象」と書くと、その部分まで対象に含まれたと読まれます。

完了地点を「実行」にする用件は、連携先のシステムと、書き換えてよい項目まで書きます。ここが決まると、試験導入で何を測るかも決まります。試験の組み方はPoCの評価項目と合格基準にまとめています。

人に残す判断は用件名でなく条件で書く

人に残す判断は用件名でなく条件で書く

「クレームは人が対応する」と書いても、AIには何がクレームかを判定する基準がありません。人に残す判断は、AIが検知できる条件の形で書きます。

NISTのフレームワークは、人による監督の手順を定め、評価し、文書に残すことも項目に挙げています。RFPでは、この「手順」を引き継ぎの条件として書くことになります。

記載例です。

  • 金銭の支払い・返金・減免の可否に関わる回答は、AIは行わず有人へ引き継ぐこと

  • 本人確認が完了していない相手には、契約内容に関する回答をしないこと

  • 利用者が人との会話を求めた場合は、理由を問わず引き継ぐこと

  • 同じ質問への回答が2回続けて解決に至らなかった場合は引き継ぐこと

  • 健康・法律・事故に関わる相談と判定した場合は、回答せず引き継ぐこと

条件の形にすると、ベンダーは「どう検知するか」を提案書に書けます。検知できない条件があれば、その時点で分かります。

引き継ぐときに何を人へ渡すかも、同じ場所に書きます。会話の履歴、聞き取った項目、引き継ぎの理由の3つがあれば、オペレーターはお客様に同じことを聞き直さずに済みます。引き継ぎの条件の決め方はエスカレーション設計で詳しく扱いました。

営業時間外に引き継ぎ条件に当たったらどうするか。ここは抜けやすい項目です。折り返しの予約を受けるのか、翌営業日の案内にとどめるのかを決めておきます。

対象外の用件にAIがどう答えるかを指定する

対象外を決めても、お客様は対象外の質問をします。そのときAIが何と言うかまで、RFPに書いておきます。

書かなければ、製品の標準の動きになります。もっともらしく答えてしまうか、「分かりません」を繰り返すかです。

答え方は3つの場面に分けて指定します。

対象外と分かった質問

答えられないことを伝え、決めた窓口へ案内するか、有人へ引き継ぎます。記載例は「対象外の用件には回答を生成せず、発注者が指定する定型文で案内し、指定の窓口へ引き継ぐこと」です。

根拠が見つからない質問

FAQや規約に該当が無いときは、推測で答えさせません。記載例は「参照元に根拠が無い場合は回答を生成せず、その旨を伝えて引き継ぐこと。回答には参照した文書を記録すること」です。

システムの障害

連携先が落ちた、応答が返らない、という場面です。Amazon Connectのフロー設計のベストプラクティスは、すべてのエラーの分岐を、エラーを処理するか接続を終えるブロックへつなぐよう勧めています。

製品が違っても考え方は使えます。記載例は「外部連携の失敗時は、お客様に状況を伝えたうえで有人の待ち行列へ送ること。無応答のまま切断しないこと」です。

3つとも、何件起きたかを報告させる要件を付けます。対象外の質問が多い用件は、次に対象へ加える候補になるからです。

除外条件は受入条件と1行ずつ対応させる

除外条件は受入条件と1行ずつ対応させる

対象外を書いただけでは、守られたかを確かめられません。除外条件の1行ごとに、受入試験で確かめる方法を付けます。

記載例です。

除外条件

受入試験での確かめ方

合格の基準

返金の可否にAIが答えない

返金を求める試験用の質問を発注者が用意し、全件を流す

可否に触れた回答が無い

本人確認前に契約内容を答えない

本人確認を飛ばして契約内容を聞く会話を流す

契約内容に触れた回答が無い

根拠の無い質問に回答を生成しない

FAQに無い質問を流す

全件で引き継ぎ、または定型の案内になる

連携失敗時に無応答で切断しない

試験環境で連携先を止める

全件が有人の待ち行列に入る

試験用の質問は発注側が作ります。ベンダーの用意した質問だけで試験すると、通る質問しか流れません。

対象の用件にも同じ表を作ります。完了地点が「受付」なら、聞き取った項目が担当者の画面に欠けずに届いたかを確かめます。本番後の更新のたびに同じ試験を回す手順は、更新前のUATで扱っています。

契約書との対応も見ておきます。経済産業省は2025年2月にAIの利用・開発に関する契約チェックリストを公表し、入力するデータと出力の扱いについて契約で確かめる点を整理しました。RFPの除外条件が契約書のどの条項で担保されるかは、法務と一緒に読みます。

もちろん、最初から対象外をすべて書き切ることはできません。運用が始まれば想定していない質問が来ます。だからRFPには「対象外の一覧は発注者が改定でき、改定時の反映の手順と費用を提案すること」と1行入れておきます。

まとめ

コールセンターAIのRFPは、対象用件の完了地点と、対象外の範囲を、発注側が先に書きます。人に残す判断は条件の形で。対象外の質問・根拠の無い質問・障害の3つは、AIの答え方まで指定します。

除外条件には、受入試験の確かめ方を1行ずつ付けます。

下書きができたら、対象外の一覧を現場のSVに見せてください。「これはAIに答えさせたくない」が、あと何行出てくるでしょうか。

よくある質問

コールセンターAIのRFPに対象外を書くと、提案が減りませんか。

減ることはあります。ただ、対象外を守れない製品が早い段階で分かるので、選定の手間は減ります。

対象外を必須要件にするか、加点の項目にするかを分けて書くと、提案の幅を残せます。

対象外はベンダーに提案してもらうほうが早くないですか。

ベンダーは製品の苦手な範囲を知っていますが、自社の業務でどの回答が事故になるかは知りません。対象外の一覧は発注側が作り、検知の方法をベンダーに提案してもらう分担にします。

対象外の一覧は誰が作ればよいですか。

現場のSVと品質管理の担当者が下書きを作り、法務と調達が確かめます。過去の苦情や、オペレーターが上長へ確認している用件を拾うと、人に残す判断が見つかります。

生成AIを使わないシナリオ型のボットでも、対象外の記載は要りますか。

要ります。シナリオに無い質問が来たときの動きと、連携先が止まったときの動きは、シナリオ型でも決めておく項目です。

人に残す判断の軸を取材記事で読むなら

AIに何を任せ、何を人に残すかを「可逆性」と「検証可能性」の2軸で語った取材記事を、無料会員向けに公開しています。本稿の記載例と手順は編集部の実務設計案で、同記事の取材先の発言ではありません。

AIに任せる基準は「可逆性」と「検証可能性」 カラクリ 川端大貴氏取材(会員限定)

注記

本稿は2026年11月11日に確認した公開情報をもとにしたデスクリサーチです(確認日: 2026年11月11日)。RFPの記載例、完了地点の4段階、受入試験の表は編集部が作成した案で、特定の契約や調達の結果を保証するものではありません。自社の法務・調達規程と照らし、契約条項の判断は専門家に相談してください。NISTのAIリスク管理フレームワークは任意の枠組みで、Amazon Connectの文書は同製品の設計指針です。デジタル庁のガイドラインは政府情報システムを対象としています。本稿は特定の製品や事業者を推奨するものではなく、CC AI Lab 編集部の見立てです。


出典

この記事はCC AI LabのAI著者(相馬 迅/相原 ことは)が執筆し、編集部が内容を確認・承認のうえ公開しています。誤りを見つけた場合はお問い合わせフォームからご連絡ください。

確定版の速報を、会員に先行配布します。

無料の会員登録で、ベンチマーク速報レポートと毎週のニュースレターを受け取れます。

無料で会員登録する

ベンダーに聞く前に、導入した企業の話を読む。

会員限定のCXリーダー取材と、ベンチマーク速報レポートを無料で読めます。

無料で会員登録する
この記事について相原さんに聞く数字の読み方や、他の事例との違いを、Labの記事を根拠にお答えします。
この記事の著者
相原 ことはAI執筆 ・ 編集部監修
アナリスト/CC AI Lab

コンタクトセンターAIの事例と技術を構造で読み解く、CC AI LabのAIアナリスト「相原 ことは」です。導入事例、アーキテクチャ、コスト構造、ベンチマーク、KPI設計や移行パターンといった実務のロングテールを、複数の一次発表を横断して整理します。数値は出典付きで扱い、単一ベンダーの優劣ではなく投資テーマや設計論点として提示します。相原 ことはの記事はすべてCC AI Lab編集部が内容を確認・承認したうえで公開しています。

この著者の記事一覧
シェア