「デモではきちんと答えていたのに、リリース後は社内チャットボットがほとんど使われていない」「結局、担当者へのメールや電話での問い合わせが減らない」。 AIチャットボット開発 に取り組んだ企業から、このような声を聞くことは少なくありません。
多くのプロジェクトでは、チャットボットの良し悪しを「回答精度」、つまり質問に正しく答えられるかどうかで評価しています。回答精度はもちろん重要ですが、それだけでは十分ではありません。参照するナレッジデータの品質、利用者の質問の仕方への対応、既存システムとの連携、会話体験、権限管理、リリース後の運用といった要素が、チャットボットが実際に使われ、業務課題の解決につながるかどうかを左右します。
本記事では、AIチャットボット開発で回答精度以外に押さえるべき6つの要素と評価すべきKPI、AIエージェントとの違い、開発の進め方と導入前のチェックリストを解説します。
なぜAIチャットボットは回答精度だけでは評価できないのか
テスト環境と実際の利用環境の違い
開発段階の回答精度は、多くの場合、開発チームが用意したテスト用の質問で測定されます。こうした質問は文章が整っており、聞きたいことも明確です。
一方、実際の利用者は「経費の件」「VPNつながらない」のように短く曖昧な言葉で質問したり、前のやり取りを前提に質問したりします。そのため、テストで高い精度が出ていても、リリース後に同じ品質が得られるとは限りません。
「正しい回答」と「業務課題の解決」は異なる
回答精度が高いことと、利用者の課題が解決することは同じではありません。例えば、経費精算の手順を正しく説明できても、申請画面へのリンクがなかったり、利用者本人の申請状況を確認できなかったりすれば、利用者は結局、担当者に問い合わせることになります。この場合、回答は「正しい」ものの、問い合わせを減らすという導入目的は達成できていません。
また、「回答できない」ことも設計すべき結果の一つです。根拠のない回答をもっともらしく返すよりも、わからないことを正直に伝えて担当者に引き継ぐほうが、利用者の信頼を保てます。
評価すべき5つのKPI
回答精度に加えて、次のような指標を組み合わせて評価します。
| KPI | 意味 | 何を評価するか |
|---|---|---|
| 回答精度 | 回答内容が正しい割合 | 正しい情報を提供できているか |
| 自己解決率 | 担当者に問い合わせずに解決した割合 | 問い合わせ対応の負担を減らせているか |
| 再質問率 | 同じ内容を言い換えて質問し直した割合 | 回答が利用者のニーズを満たしているか |
| 利用継続率 | 一度使った人が継続して利用している割合 | 現場で継続的な価値を生んでいるか |
| 対応工数 | 問い合わせ対応にかかる時間・人員 | 業務負荷の軽減につながっているか |
なお、これらのKPIがすべてチャットボットの品質だけを反映するわけではありません。例えば利用継続率は、問い合わせが発生する頻度や業務の繁閑にも左右されます。目標値は業務の内容や導入目的によって異なるため、開発を始める前に、どの指標をどの水準で評価するかを関係者で合意しておくことが大切です。
AIチャットボット開発で見落とされがちな6つの要素
ここからは、6つの要素それぞれについて、よくある問題と業務への影響、対策のポイントを具体例とあわせて解説します。
ナレッジデータの品質と鮮度
社内文書などを参照して回答するAIチャットボットでは、RAG（検索拡張生成）と呼ばれる方式がよく利用されます。RAGは、関連する情報を検索し、その内容をもとに回答を生成する仕組みです。そのため、参照するデータが古かったり、内容の異なる文書が混在していたりすると、AIはそれをもとに誤った回答を返してしまいます。
例えば、社内規程が改定されたにもかかわらず旧版のファイルが共有フォルダに残っていると、チャットボットは旧版の内容に沿って「正確に」回答してしまいます。これはLLMの性能ではなく、ナレッジデータ管理の問題です。表を多く含むExcelファイルやスキャンしたPDFなど、内容を正しく読み取りにくい形式の文書も、精度が下がる原因になります。
対策のポイント
- 取り込む前に文書を棚卸しし、重複や旧版を整理する
- 情報の分野ごとに「正式な情報源」を決める
- 文書ごとに更新担当者と、改定時に反映するまでの流れを決める
- 施行日、対象部署、対象者などの情報（メタデータ）を付与する
モデルを変更するよりも、ナレッジデータを整備するほうが回答品質の改善につながるケースは少なくありません。
社内データの所在や整備状況を確認する観点は、「AI導入はインフラで止まる？AI Readiness（AI準備度）診断」で解説しています。
ユーザー入力への対応
実際の利用者の質問は、開発者が想定するほど明確ではありません。例えば「経費は？」という質問だけでは、精算の手順を知りたいのか、上限額を知りたいのか、締め日を知りたいのかがわかりません。ほかにも、社内でしか通じない略語や部署名、表記ゆれ、誤字、1つの文に複数の質問が含まれるケースがあります。
こうした入力に対応できないと、意図を外した回答が増え、利用者は「このチャットボットは使えない」と判断してしまいます。
対策のポイント
- 意図が曖昧な場合は推測で答えず、聞き返して確認する
- 社内用語・略語・同義語の辞書を整備する
- 質問の例を提示し、聞き方を案内する
- 複数回のやり取りで、前の会話の文脈を引き継げるようにする
実際の質問の傾向を把握するには、過去の問い合わせメールやチケット、FAQの履歴が役立ちます。これらは、リリース前に品質を確認するための評価データとしても活用できます。
既存システムとの連携
社内文書だけを参照するチャットボットは、「〇〇システムで確認してください」と案内することしかできません。利用者は結局、自分でシステムを開いて確認したり、担当者に問い合わせたりする必要があり、業務の負担はあまり減りません。
例えば「有給休暇はあと何日残っていますか？」という質問に答えるには、質問者が誰かを識別したうえで、人事システムの情報を参照する必要があります。連携には、次のようなレベルがあります。
| 連携のレベル | 例 | 効果 |
|---|---|---|
| チャネル連携 | Webサイト、Slack、Microsoft Teams、LINE | 普段使っているツールから質問できる |
| 認証連携 | SSO、社員IDとの連携 | 利用者に応じた回答や権限制御ができる |
| データ参照 | 注文状況、在庫、申請状況の照会 | 利用者ごとの個別の質問に答えられる |
| 業務連携 | 問い合わせチケットの起票、有人チャットへの引き継ぎ | 解決までの流れを完結できる |
連携を計画する際は、対象システムにAPIがあるか、参照だけでなく更新もできるか、認証方式や呼び出し回数の制限はどうなっているかを事前に確認しておきます。なお、チャットボットにデータの登録や更新といった操作まで任せる場合は、AIエージェントの領域に近づきます（後述）。
会話体験（UX）
回答精度が高くても、使いにくいチャットボットは定着しません。利用者は1〜2回試して期待した答えが得られないと、その後は使わなくなる傾向があります。また、チャットボットで何ができるのかがわからなければ、そもそも質問しようと思いません。
設計のポイント
- 最初のメッセージで、対応できること・できないことを伝える
- 回答は結論から示し、次に取るべき行動やリンクを添える
- 回答の根拠となった文書（出典）を表示し、利用者が自分で確認できるようにする
- 該当する情報がない場合や、回答に確信が持てない場合の伝え方を決めておく
- 有人対応に引き継ぐ条件を決め、会話履歴も一緒に引き継いで、利用者に同じ説明を繰り返させない
- 「役に立った／役に立たなかった」などのフィードバックボタンを設ける
- 社外向けか社内向けかに応じて、敬語や文体を調整する
権限・セキュリティ
社内向けチャットボットで特に注意したいのが、閲覧権限の扱いです。人事評価や給与、契約に関する文書をナレッジとして取り込んだ場合、権限を制御していなければ、本来は閲覧できない社員の質問にも、その内容を使って回答してしまうおそれがあります。
プロンプトで「機密情報は回答しないこと」と指示するだけでは十分ではありません。利用者の権限に応じて、検索の段階で参照できる文書を絞り込む仕組みが必要です。あわせて、次の点も確認しておきましょう。
- 質問内容や会話ログに含まれる個人情報の扱い
- 外部のLLMサービスに送信してよいデータの範囲
- 悪意のある入力でAIの動作を誘導する「プロンプトインジェクション」への対策（特に社外に公開するチャットボット）
- 価格や契約条件など重要な事項は、AIが生成した文章ではなく、確定した文言で回答する
運用・継続改善
リリース時点の品質が、そのまま維持されるとは限りません。社内規程や商品情報は変わり、利用者の質問の傾向も変化します。改善を担当する人がいなければ、チャットボットが何に答えられていないのか、どの回答が誤っているのかを誰も把握できず、品質が徐々に低下していきます。
対策のポイント
- 回答できなかった質問や評価の低い回答をログから定期的に分析し、ナレッジを追加・修正する
- 評価データを維持し、モデル・プロンプト・ナレッジを変更するたびに再テストする
- KPIをダッシュボードで可視化し、定期的に確認する
- 内容の更新は業務部門、システムの改修はIT部門や開発会社というように、役割を分担する
AIチャットボットは「リリースして終わり」の製品ではなく、運用しながら育てていくサービスです。
6つの要素のまとめ
| 要素 | よくある問題 | 主な原因 | 対策のポイント |
|---|---|---|---|
| ナレッジデータ | 古い・矛盾した回答 | 文書の重複、管理者の不在 | 正式な情報源と更新フローを決める |
| ユーザー入力 | 質問の意図を外す | 曖昧な質問、社内用語 | 聞き返し、用語辞書 |
| システム連携 | 回答だけで解決しない | 業務システムと未接続 | 照会、起票、有人対応への引き継ぎ |
| 会話体験 | 使われなくなる | 対応範囲が不明、出典がない | 初回の案内、出典表示、フィードバック |
| 権限・セキュリティ | 見せてはいけない情報を回答する | 検索時の権限制御がない | 利用者ごとのアクセス制御 |
| 運用・改善 | 品質が徐々に低下する | 改善担当・評価の仕組みがない | ログ分析、再テスト、役割分担 |
AIチャットボットとAIエージェントの違い
役割・機能・動作の違い
AIエージェントとは、与えられた目標に対して、AI自身が処理の手順を計画し、ツールやシステムを操作しながらタスクを実行する仕組みです。AIチャットボットとの主な違いは次のとおりです。
| 観点 | AIチャットボット | AIエージェント |
|---|---|---|
| 主な役割 | 質問への回答・情報提供 | タスクの実行・業務支援 |
| 動作 | 利用者の質問に応じて回答する | 目標に応じて処理を進める |
| システム連携 | 情報の検索・参照が中心 | 複数システムの操作も可能 |
| 判断・実行 | 基本的に回答を返す | 状況に応じて次のアクションを選択する |
| 適した用途 | FAQ、社内問い合わせ | 業務プロセスの自動化 |
ただし、両者の境界ははっきり分かれているわけではありません。最近のAIチャットボットには、APIを呼び出して在庫や申請状況を照会できるものもあります。違いの本質は、AIが自ら手順を計画し、複数のステップにわたって判断と実行を繰り返すかどうか、つまり自律性の度合いにあります。
また、RAGとAIエージェントは、どちらかを選ぶ対立する技術ではありません。RAGは根拠のある回答を生成するために情報を取得する方法であり、AIエージェントが業務に必要な情報を得るためにRAGを利用することもあります。
AIチャットボットで十分なケースとは？
次の質問に答えてみてください。
- 主な目的は、FAQや社内問い合わせへの回答ですか？
- 回答した後に、システムの操作や業務処理を実行する必要はありませんか？
- 定型的な質問が中心で、処理の流れも比較的シンプルですか？
- 人による確認・承認を前提とした運用で十分ですか？
多くが「はい」であれば、AIチャットボットから始めるのが適切です。反対に、複数のシステムをまたぐ処理や、データの登録・更新まで自動化したい場合は、AIエージェントを検討する価値があります。ただし、AIが操作を実行する場合は、誤った操作による影響が大きくなるため、権限管理や承認フロー、監視の仕組みが欠かせません。
チャットボットからAIエージェントへ進化させるステップ
最初からAIエージェントを目指すのではなく、チャットボットから段階的に機能を広げていく方法もあります。
- FAQ回答：社内規程やマニュアルをもとに質問に答える
- 情報検索・照会：業務システムと連携し、利用者ごとの情報を参照する
- 下書き作成：申請書やメールの下書きを作成し、利用者が確認して送信する
- 承認付き実行：担当者の承認を得たうえで、AIが登録や更新を行う
- 条件付き自動実行：定められた条件の範囲内で、AIが自動で処理する
チャットボット開発で整備したナレッジデータ、システム連携、ログ、評価の仕組みは、AIエージェントに拡張する際の土台になります。将来の拡張を見据えるのであれば、最初からその前提で設計しておくと手戻りを減らせます。
AIエージェントを本番運用する際に必要な権限管理や監視の仕組みについては、「AIエージェント開発はなぜPoCで止まるのか｜デモから本番運用へ進むための7つの壁と対策」で詳しく解説しています。
AIチャットボット開発の進め方と導入前チェックリスト
開発から運用までの5つのステップ
| ステップ | AIチャットボット開発での主な内容 |
|---|---|
| 1. 業務課題・データ環境の分析 | 対象業務、利用者、KPIを明確にし、社内文書・データ・アクセス権限を棚卸しする |
| 2. 戦略立案・AI技術の選定 | チャットボットの種類（ルールベース型・RAG型・ハイブリッド型）、LLM、連携するシステムやチャネルを決める |
| 3. 迅速なPoC | 実際の質問ログを使い、回答精度・自己解決率・権限制御を検証する |
| 4. 開発・運用保守 | システム連携、UX、セキュリティを実装し、テスト・評価と監視の仕組みを整える |
| 5. 定着支援 | 段階的にリリースして利用を促進し、ログとフィードバックをもとにナレッジと機能を改善する |
開発費用は、チャットボットの種類、ナレッジデータの量と整備状況、連携するシステムの数、セキュリティ要件、リリース後の運用範囲によって大きく変わります。開発費だけでなく、LLMのAPI利用料やナレッジの更新、定期的な評価など、運用段階の費用も見込んでおきましょう。定型的なFAQが中心であればSaaS型のチャットボットで十分な場合もありますが、既存システムとの深い連携や複雑な権限制御、機密性の高いデータの扱いが必要な場合は、個別開発が適しています。
開発前に確認したい8つのチェック項目
開発会社に相談する前に、次の項目を社内で確認しておくと、要件を整理しやすくなります。
- 導入目的とKPIが明確になっているか
- 利用対象者と利用シーンを定義しているか
- ナレッジデータの品質と更新頻度を確認しているか
- 曖昧な質問や想定外の入力に対応できるか
- 必要な既存システムと連携できるか
- ユーザーごとのアクセス権限を設定しているか
- 回答できない場合の有人対応フローがあるか
- リリース後の監視・改善体制が整っているか
AIチャットボット開発に関するよくある質問
Q1. AIチャットボットの開発にはどのくらいの期間がかかりますか？
対象業務の範囲、ナレッジデータの整備状況、連携するシステムの数によって大きく異なり、すべての案件に共通する期間はありません。まずは対象を1つの業務に絞ってPoCを行い、実際の質問で効果を検証したうえで、その結果をもとに全体のスケジュールを立てることをおすすめします。
Q2. 社内資料が整理されていなくても開発できますか？
開発は可能です。ただし、整理されていない文書をそのまま取り込むと、古い情報や矛盾した情報にもとづく回答が増えます。問い合わせの多い分野から優先的に文書を整理し、対象範囲を段階的に広げていく進め方が現実的です。
Q3. AIチャットボットの誤回答を防ぐにはどうすればよいですか？
誤回答を完全になくすことは難しいものの、減らすことはできます。社内文書を根拠に回答するRAGの採用、出典の表示、回答範囲の限定、根拠がない場合は回答せずに有人対応へ引き継ぐ設計などを組み合わせます。重要な内容は固定の回答を使う方法も有効です。リリース後も、利用者からの報告やログをもとに継続的に改善していきます。
まとめ
AIチャットボット開発 では、回答精度だけでは評価できない理由と評価すべきKPI、見落とされがちな6つの要素、AIエージェントとの違い、開発の進め方と導入前のチェックリストを解説します。
まずは対象業務を絞り、回答精度以外のKPIも含めて評価基準を決めたうえで、小さく始めて改善を重ねましょう。将来的にAIエージェントへ拡張する可能性があるなら、その前提でデータや連携の仕組みを設計しておくことも大切です。
開発会社を選ぶ際は、デモで正確に回答できるかだけでなく、ナレッジデータの整備、システム連携、権限制御、リリース後の改善まで、どのように提案・支援してくれるかを確認しましょう。
レリパ（Relipa）では、AIシステムの企画・設計から開発、運用・保守までを一貫して支援しています。業務課題とデータ環境の分析から始め、チャットボットの種類や連携方式の選定、PoCによる検証、リリース後の改善まで、お客様とともに進めます。将来のAIエージェントへの拡張や、RPAとAIを組み合わせた業務自動化についてもご相談いただけます。
「チャットボットを導入したいが、何から始めればよいかわからない」「導入済みのチャットボットが使われていない」といったお悩みがあれば、対象業務、よくある問い合わせの内容、お使いの文書やシステムの状況をお聞かせください。対象範囲、評価指標、開発の進め方を一緒に検討します。
