ZendeskでAIエージェントを作成しても、それだけで安定した問い合わせ対応が完成するわけではありません。ナレッジに答えがあっても質問の表現によって回答できなかったり、反対に、回答すべきでない内容へ自信を持って答えたりすることがあります。
重要なのは、個々の回答を「良かった」「悪かった」で終わらせず、会話ログを見ながら原因を分類し、適切な設定を直すことです。
この記事では、Zendesk AIエージェントの会話ログとテスト結果を使って回答品質を確認し、ナレッジ、検索ルール、応答設計、有人引き継ぎを継続的に改善する方法を解説します。
この記事は2026年9月時点のZendesk公式情報と画面を基にしています。AIエージェントの画面、利用できる指標や設定項目は、契約プラン、アドオン、契約時期、段階的なロールアウトによって異なる場合があります。
改善の要点
- AIエージェントの作成はゴールではなく、改善サイクルの開始点
- 集計値だけでなく、実際の会話と参照した情報をサンプル確認する
- 問題をナレッジ、検索範囲、応答設計、処理手順、有人引き継ぎに分ける
- 一度に複数の設定を変えず、同じテストケースで変更前後を比較する
- 自動解決率だけを追わず、誤回答や不適切な自動対応も確認する
運用開始後の評価と改善
AIエージェントのダッシュボードでは、自動解決、エスカレーション、会話などの概況と、AIエージェントごとの状態を確認できます。
画面は検証環境の例です。サブドメインなどを含む上部のブラウザ領域は掲載画像から除外しています。
集計値は変化を見つける入口になりますが、数値だけでは原因までは分かりません。たとえばエスカレーションが増えた場合でも、ナレッジ不足、質問の意図判定、有人対応を希望するカスタマーの増加など、複数の理由が考えられます。
そこで、気になる変化を見つけたら会話ログへ進み、実際のやり取りを確認します。Zendeskの会話ログでは、自動化されたやり取りのメッセージやアクションを個別にたどり、テスト会話を絞り込んで確認できます。
修正後は同じ質問で再テストし、意図した変化が出たかを比較します。
会話ログで確認できること
会話ログを開いたら、AIエージェントの最終回答だけではなく、会話全体を順番に確認します。
- カスタマーが最初に何を尋ねたか
- AIエージェントが質問をどう解釈したか
- 追加質問や確認が適切だったか
- どのナレッジや会話設計が使われたか
- 回答で問題が解決したか
- どの時点で、どの理由により有人対応へ切り替わったか
- テスト会話か実際のカスタマーとの会話か
公開後のログには、氏名、メールアドレス、注文番号、契約情報などが含まれる可能性があります。記事資料や社内報告へ転載するときは、本文だけでなく、会話ID、チケットID、URL、画面上部のサブドメインも確認し、不要な部分をトリミングまたはマスキングします。
回答品質を見直す7つの観点
回答品質の評価基準を決めずにログを見ると、担当者ごとに判断が変わります。初期運用では、次の7項目を共通の観点として使用すると整理しやすくなります。
1. 問い合わせ意図を正しく捉えたか
同じ単語を含む問い合わせでも、カスタマーが求めていることは異なります。たとえば「解約」という言葉は、解約方法、解約済みかの確認、返金条件、解約後のデータ保持など、複数の意図を含みます。
AIエージェントが表面的な単語だけで判断していないか、必要な追加質問を行っているかを確認します。
2. 適切なナレッジを参照したか
回答が正しく見えても、参照元が想定と違う場合は注意が必要です。似た製品、別ブランド、古い料金プラン、異なる国向けの記事を参照していないかを確認します。
ナレッジを追加するときは、AIが利用できる状態になっているか、対象ブランドや言語が合っているか、インデックス作成が完了しているかも確認します。
ナレッジの内容だけでなく、AIエージェントへ正しく接続され、利用可能な状態かを確認します。画面内のURLは説明用のダミーです。
3. 回答内容が正確で最新か
料金、対象条件、受付時間、手続き期限などは、文章として自然でも一部の条件が欠けると誤案内になります。ナレッジの原文と照合し、数字、日付、例外条件、対象範囲が正しいかを確認します。
古い回答が出た場合、AIの生成処理だけでなく、ナレッジ自体が古い可能性があります。公開ページ、社内手順、マクロなど、情報源同士の不一致も確認します。
4. 情報がないときに推測していないか
ナレッジに答えがない質問では、無理に回答せず、必要に応じて担当者へ引き継ぐことが重要です。架空の条件や手続きを補っていないか、断定できない内容を断定していないかを確認します。
個人情報、契約判断、返金可否、障害状況など、最新情報や個別確認が必要な問い合わせは、自動回答の対象から外すことも検討します。
5. 有人対応へ適切に切り替えられたか
エスカレーションが多いこと自体を、単純に悪い結果と判断してはいけません。AIが扱うべきでない問い合わせを安全に引き継いでいるなら、設計どおりの動作です。
一方で、ナレッジに明確な答えがあるのに毎回引き継いでいる場合は、意図判定や検索範囲に問題がある可能性があります。引き継ぎ後に担当者が対応できる情報が残っているかも確認します。
6. 同じ失敗が繰り返されていないか
個別の失敗を直すだけでは、似た質問で再発します。質問の表現が異なっても原因が同じ会話をまとめ、件数と影響範囲を確認します。
たとえば「領収書」「請求書」「支払い証明」の質問で同じ失敗が起きているなら、一つの記事だけを修正するのではなく、ナレッジの構造や用語の整理が必要かもしれません。
7. 言語・チャネル・表現による差がないか
同じ意図でも、短文、口語、表記ゆれ、誤字、別言語では結果が変わることがあります。メールとメッセージングでは会話の長さや必要な説明量も異なります。
代表的な問い合わせは、言い換えや情報不足のパターンを含めてテストします。すべての文章を網羅するのではなく、実際の問い合わせログで多い表現から優先します。
原因別の修正方法
AIエージェントの回答に問題があると、すぐに指示文やトーンを変えたくなります。しかし、原因がナレッジ不足であれば、応答表現を調整しても正しい情報は増えません。
ナレッジを追加・更新する
必要な情報が存在しない、内容が古い、例外条件が書かれていない場合は、ナレッジを修正します。一つの記事に複数の異なるテーマを詰め込まず、質問と回答の対応が分かる見出しや文章に整理します。
検索範囲・検索ルールを調整する
Zendeskの検索ルールでは、特定の状況でAIエージェントが検索するナレッジソースや、その一部を指定できます。記事、言語、ラベル、ユーザーセグメントなどで対象を分け、別ブランドや異なる契約条件の記事を参照しないようにします。
検索範囲を狭くしすぎると必要な記事まで見つからなくなるため、変更後は対象内と対象外の両方をテストします。
指示・トーン・会話設計を調整する
情報は正しいものの、説明が長すぎる、追加質問が分かりにくい、禁止したい言い回しがある場合は、AIエージェントの指示、トーン、会話設計を見直します。
右側のテストパネルで代表的な質問を試し、設定変更前後の回答を比較します。
手順・アクションを見直す
単に情報を答えるだけでなく、本人確認、情報取得、更新処理などが必要な問い合わせでは、会話の手順やアクションの設計が必要です。どの情報を聞き、どの条件で次へ進み、失敗時にどう処理するかを分けて確認します。
有人引き継ぎ・対象外条件を調整する
AIが答えるべきでない問い合わせは、有人対応へ切り替えます。引き継ぎ条件だけでなく、カスタマーに表示する案内、担当者へ渡す会話履歴、対応先のグループ、回答期限も運用と合わせます。
本番公開前のテスト方法
公開前には、成功する質問だけでなく、失敗させるべき質問も含めます。最低限、次のパターンを用意します。
- ナレッジに明確な答えがある質問
- 同じ意味を別の言葉で尋ねる質問
- 必要な情報が不足している質問
- ナレッジに答えがない質問
- 古い制度や存在しない商品についての質問
- 複数の要件を一度に含む質問
- 人間による対応を希望する質問
- 個別の契約・注文確認が必要な質問
テスト結果は「成功」「失敗」だけでなく、期待する動作、実際の動作、問題の種類、修正対象を記録します。修正後は新しい質問へ変えず、まず同じ質問で結果を比較します。
質問、参照する資料と設定の版、言語、チャネル、前の会話を揃えて比較します。新しい知識や設定を試す場合は、どの条件を変えたかも残します。架空サービスの日本語FAQ検証記事は、特定の環境で回答内容を評価した例であり、すべての窓口の品質や有人対応の完了を示すものではありません。
評価票には、期限・対象外条件・次の操作の案内漏れも記録します。「担当者へ相談してください」と表示されただけで引き継ぎ完了にはせず、相談先、受付時間、時間外の連絡方法、担当者へ渡す情報まで区別して点検します。他部署への確認待ちは問い合わせ窓口の運用診断もご利用ください。
週次で行う改善サイクル
運用開始後は、すべての会話を毎週読む必要はありません。件数とリスクに応じてサンプルを決め、同じ評価基準で継続します。
- ダッシュボードで会話数、自動解決、エスカレーションの変化を見る
- テスト会話、エスカレーション、回答不能などから確認対象を抽出する
- 7つの観点で会話を評価する
- 同じ原因の問題をまとめ、件数と影響で優先順位を付ける
- 修正対象を一つ選び、担当者と期限を決める
- 修正後に同じテストケースを実行する
- 改善結果と残った課題を記録する
初期段階では毎週、その後は問い合わせ量と更新頻度に合わせて隔週や月次へ変更します。料金改定、製品更新、キャンペーン、障害などがあるときは、通常の周期とは別に関連するナレッジとテストケースを確認します。
自動解決率だけで評価しない
自動解決率は重要な指標ですが、高ければ必ず品質がよいとは限りません。誤った回答で会話が終了しても、表面上は自動対応が完了したように見える場合があります。
次の指標とサンプルレビューを組み合わせます。
- AIエージェントが対応した会話数
- 自動解決と有人エスカレーションの割合
- 回答不能になった問い合わせの種類
- 同じ内容で再問い合わせされた割合
- 有人引き継ぎ後の解決時間
- サンプル評価で正確と判断できた回答の割合
- 重大な誤回答や不適切な案内の件数
指標の定義は、チャネルや契約しているZendesk機能によって異なる場合があります。社内報告では、画面に表示された名称だけでなく、自社で何を成功・失敗として数えるかを明記します。
運用チェックリスト
- 会話ログを確認する担当者と頻度を決めた
- テスト会話と実際の会話を区別して確認できる
- 回答品質を評価する共通の観点を決めた
- 回答と参照ナレッジを照合している
- 誤回答と適切なエスカレーションを分けている
- 問題ごとに修正対象と担当者を記録している
- 設定変更前後を同じテストケースで比較している
- 料金改定や製品更新時の確認手順を決めた
- ログを共有するときの個人情報マスキングルールがある
まとめ
Zendesk AIエージェントの品質改善では、回答文だけを直すのではなく、会話ログから問題の原因を切り分けることが重要です。
問い合わせ意図、参照ナレッジ、正確性、安全性、有人引き継ぎ、再発、条件差の7項目を共通基準にすると、担当者の感覚だけに頼らず改善できます。ナレッジ不足にはナレッジ整備、誤った参照には検索ルール、表現や対話の問題には応答設計というように、原因に合った設定を一つずつ修正します。
KIRIKOMIでは、Zendeskの設定・運用改善とナレッジベースの整備を、実際の問い合わせログと運用体制に合わせて支援しています。AIエージェントを作成するところから確認したい場合は、Zendeskでメール対応AIエージェントを作成する方法もご覧ください。
導入済みAIの会話と根拠を切り分け、設定の見直しから再テストまで進めたい場合は、AIエージェントの回答品質改善支援もご覧ください。