「AIチャットボットを入れたんですが、思ったような答えが返ってこなくて」
導入後しばらく経った頃にいただく、わりとよくあるご相談です。
原因のかなりの部分は、AIの性能そのものではなく、AIに何を読ませているかにあります。そして、その「何を読ませるか」の準備を誰がやるのかが曖昧なまま開発が進んでしまい、結果として「想定したような回答が返ってこない」という状態に着地してしまうケースが少なくありません。
ざっくり言うと：AIチャットの導入は、新人さんを雇うのに似ています。新人さんを採用するときは、面接で人を選ぶだけでなく、入社後に読んでもらうマニュアルを誰がどう整えるか、という話がセットになりますよね。AIチャットも全く同じで、「どのAIを使うか」だけでなく、「何を読ませるか」を誰がどう用意するかを最初に決めておかないと、入社初日の新人さんと同じ状態で本番に出すことになってしまいます。
なぜそうなるのか
近年のAIチャットボットの中身は、大きく2つの部分に分かれます。
- 会話を担当するAI本体：OpenAI、Anthropic、Google などが公開している外部サービスを使うのが一般的です。ここは発注側が中身を直接いじることはあまりありません
- AIに渡す自社情報：FAQ、利用規約、商品マニュアル、社内ナレッジなど。こちらは自社にしか用意できない部分です
つまり「AIチャットを作る」という開発の中で、本当に差がつくのは下のレイヤーです。発注者側からすると「AIが賢く答えてくれる仕組みを作ってもらう」というイメージかもしれませんが、開発側からすると「賢いAIに渡す材料を、お客様と一緒に揃える」という作業がかなりのウエイトを占めます。
ここの認識がズレたまま見積もりや要件定義に入ると、自社情報を整える作業の責任が宙に浮きます。「開発会社が良きに計らってくれる」と思っていたら、開発会社側は「お客様から最新マニュアルが上がってくる前提」で進めていた、というすれ違いが起きるわけです。
失敗パターン
※以下は実在の案件ではなく、よくある想定シナリオです。
パターン1：FAQが古いまま渡される
「うちのサポートサイトのFAQをそのままAIに読ませてください」と依頼したものの、そのFAQが2年前のままで、料金プランも商品ラインナップも変わっている、というケース。AIはFAQの内容を素直に答えるので、結果として古い情報がそれっぽい日本語で堂々と返ってきます。AIは賢いほど、間違いも自然に話してしまうという側面があるため、元情報の鮮度がそのまま回答品質に直結します。
パターン2：マニュアルが分散していて統合されていない
料金は営業資料、操作方法はヘルプサイト、解約条件は規約PDF、社内向けの細則はチームの作業ドキュメント、というふうに情報が複数の場所に散らばっていて、しかも書き方も担当者ごとにバラバラ、というパターン。AIに渡す前段階でこれを統合する作業が必要なのですが、「自社の何かしらの情報を渡せばAIが上手にまとめてくれる」と期待していると、ここで足が止まります。情報を一箇所に集める作業と、表記を揃える作業の分担を最初に決めていないと、案件が進みません。
パターン3：「想定問答集」を作らずに本番開始
AIチャットを公開する前に、よくある質問と模範回答のペアをテストケースとして100〜200件用意するのが理想ですが、これを省略してリリースしてしまうケース。リリース直後に「あれ、この質問にはこう答えてほしくないんだけど」となり、現場のサポートチームが慌ててAIを止める、という結末になりがちです。お試し導入の段階でPoC（お試し導入）で失敗する典型パターンと似た構造で、評価基準を後回しにすることのリスクが顕在化します。
どう備えればよいか
1. 「学習データの責任者」を最初に決める
発注者・開発会社のどちらが、自社情報の収集・整形・更新を担当するのかを最初に明文化します。「開発会社にお任せ」では絶対にうまくいかない領域です（開発会社は自社の最新業務を知らないため）。現実的には、お客様側で1名「AIに読ませる情報のオーナー」を置いて、開発会社がその情報をAIで使える形に整える分担が回りやすい構成です。
2. 想定問答集をリリース前に揃える
サポートチームと一緒に、「よくある質問」「ややこしい質問」「答えるべきでない質問」をそれぞれ数十件ずつ書き出します。これがそのままリリース前の品質テストに使えます。最初の段階で時間はかかりますが、リリース後の手戻りを大幅に減らせます。
3. 「答えない」設計を意図的に入れる
料金・解約・契約・本人確認に関わる質問は、AIに自由回答させずに定型応答や有人エスカレーションに振ると決めておきます。「全部AIで答えたい」という気持ちはわかりますが、間違えるとトラブルになる領域を絞り込むことで、AIに任せられる範囲を逆に広く取れる、というのが現場感覚です。
4. 公開後の更新ルートを用意する
サービスの仕様変更があったときに、AIが参照している情報をどう更新するのか。運用フェーズの体制を最初に決めておくことが大切です。ここを設計に含めずに作ってしまうと、開発会社しか更新できないブラックボックスになり、後でお客様の更新コストが上がってしまいます。
まとめ
AIチャットボットの導入で「想定回答が返ってこない」と感じたら、まず疑うべきはAIそのものではなく、AIに渡している情報です。そしてその情報の準備は、開発会社よりお客様側にしかできない部分が多くあります。
発注検討の段階で、次の4つをチェックしてみてください。
- 自社情報の収集・整形・更新の責任者は誰か
- 想定問答集はいつまでに、誰が、何件用意するのか
- 「AIに答えさせない領域」を最初に決めたか
- 公開後の更新ルートと体制が見積もりに含まれているか
このあたりが見積もり書や提案書にしっかり書かれている開発会社であれば、運用フェーズも含めて安心して任せやすくなります。