Freshworksは、Freddy AI Agentが顧客の問い合わせを最大80%解決すると謳っている。だが同社が事例として紹介している企業の一つ、Total Expertのデフレクション率は約23%にとどまる。もう一社のUPaymentsは75%以上だ。同じ製品、同じマーケティング上の主張なのに、結果はまったく異なる。
その差はAIそのものではなく、導入の仕方にある。Freshdeskの公式ドキュメント、Freshworksコミュニティの導入ガイド、そして実際にFreddy AIを大規模運用しているチームによるG2のレビューを丹念に調べた結果、解決率70%以上を達成する導入と25%で頭打ちになる導入の違いは、おおよそ7つの要素に集約されることが分かった。しかも、その中で最も重要な要素は、AIの設定そのものとは関係がない。
Freshdesk AIエージェントのパフォーマンスは、ローンチ前のナレッジベースの質、Instructions(指示)の精度、そしてデフレクション率単体ではなくCSATと組み合わせて解決率を測定しているかどうかで、ほぼすべてが決まる。 期待通りの成果が出ていない導入の多くは、AIの設定自体は正しく、コンテンツの入力側に問題がある。自律型のAgentを有効にする前にFreddy Copilotから始めてナレッジギャップを洗い出し、セッションの自動チャージルールを設定せずにローンチすることは絶対に避け、本番環境で痛い目に遭う前にメールのスレッド処理の制約を計画に織り込んでおこう。
AIの設定をいじる前に、まずナレッジベースを整える
これは単なるアドバイスではない。Freshdeskの公式ドキュメント、Freshworksコミュニティ、そして第三者によるレビューのすべてで一貫して報告されている、最も確かな知見だ。
"Freddy AIは、従来の再学習ではなくナレッジベースの記事を通じて学習する。新しいQ&Aや記事が追加されるたびに、応答の精度は大きく向上する。"
ナレッジベースが乏しかったり古くなっていたりする状態でFreddy AIを導入したチームは、ほぼ例外なく結果が悪いのをAIのせいにする。だが実際に問題があるのは、AIに与えられたコンテンツの方だ。60%を期待していたのにデフレクション率が25%にとどまっているなら、最初に確認すべきは「ナレッジベースはどれだけ網羅的で、最新の状態に保たれているか」という点だ。
実務的な話をすると、AI向けのライティングは人間向けのライティングとは違う。実践者が一貫して効果が高いと挙げるポイントをいくつか紹介する。
- 1記事1トピックにする。 複数の機能やプロセスを1つの記事でカバーすると、意図のマッチングが混乱する。「解約方法は?」と「ダウングレード方法は?」の両方を扱っている記事があるなら、分割しよう。
- 答えを先頭に置く。 「良い質問ですね!サブスクリプション管理についてですが...」のような長い前置きは、AIが応答の根拠とすべき情報を後回しにしてしまう。答えを最初に書こう。
- 単なる「はい/いいえ」で終わらせない。 文脈を含んだ回答の方がAIのパフォーマンスは上がる。「はい、請求サイクルの途中でもダウングレードできます。変更は次のサイクルの開始時に適用され、日割り分の差額はアカウントにクレジットされます」という回答は、単なる「はい」よりもずっと有用だ。
- 言葉を直接的かつ具体的にする。 「料金は変動します」のような曖昧な表現は、AIにとって手がかりにならない。具体的な数字やポリシーを明記しよう。
FreshdeskのAI Agent Studioは、ローンチ後に未回答クエリログを表示する。これはエージェントが応答できなかったすべての問い合わせの記録だ。このログをナレッジベースのロードマップとして扱おう。健全な運用を続けているチームほど、これを毎週の実行項目として扱っている。
ナレッジソースの制限を理解する
Freshdesk AIエージェントは4種類のソースからナレッジを取り込める。それぞれに、始める前に知っておくべき制約がある。
| ソースタイプ | エージェントごとの上限 | アカウントごとの上限 | 主な制約 |
|---|---|---|---|
| URL | 10件 | 25件(全エージェント合算) | 公開ページのみ。認証、CAPTCHA、動的JSには非対応 |
| ファイル | 200件 | - | PDF、DOCX、TXT。1ファイル最大35MB。画像・動画は不可 |
| ソリューション記事 | 無制限 | - | 「ソリューション記事から学習」をオンにする |
| カスタムQ&A | 無制限 | - | 特定の限定シナリオに最適 |
アカウントあたり25URLという上限に、多くのチームが不意を突かれる。特に複数ブランドや大規模なコンテンツライブラリを管理しているチームは要注意だ。上限に達した場合、現実的な対処法は、重要度の高いURLのコンテンツをアップロード文書に変換することだ。
運用面で注意すべき点が一つある。URLの取り込みは非同期処理で、処理が完了するとメールが届くが、これに最大30分かかることがある。ポップアップ、ログイン画面、CAPTCHAがあるページは、エラー表示なしに静かに失敗する。エージェントは単純にその知識を持たないままになる。URLを追加したら必ず「抽出コンテンツのプレビュー」を確認し、正しく取り込まれたかを確かめよう。
Instructions(指示)は具体的に書く - 特に「やってはいけないこと」を
InstructionsはAI Agent Studio内のフィールドで、業界用語、ブランドの語り口、扱ってはいけないトピック、明示的なエスカレーション条件といったビジネス上の文脈を追加する場所だ。多くのチームはこのフィールドを十分に活用できていない。
「親切かつプロフェッショナルに対応する」といった汎用的な指示はほとんど効果がない。パフォーマンスの高いエージェントは、何をスキップすべきか、いつ引き継ぐべきかを正確に伝えるInstructionsを持っている。実践者による、測定可能な改善につながった具体例を紹介する。
- 法的な紛争、[X]を超える請求の取り消し、「弁護士」や「訴訟」に言及するリクエストは即座にエスカレーションする
- 具体的な料金やプロモーション条件は一切提示せず、料金ページに案内する
- 自社の内部システム特有の専門用語は使わない(該当用語をここに列挙)
- 顧客が3回連続で不満を表明した場合、確信度スコアに関わらず人間への引き継ぎをトリガーする
制約が具体的であるほど、エージェントの挙動は予測しやすくなる。汎用的なガイダンスは一貫性のない出力を生み、明示的なルールは信頼できる挙動を生む。
LLMの応答のばらつきについて補足しておく。Freddy AIは他の大規模言語モデルと同様、同じ質問に対して毎回微妙に異なる応答を返すことがある。これは想定内の挙動であり、設定ミスではない。ばらつきに気づいたら、正しい対処法は該当するInstructionsを厳密にするか、ナレッジ記事を更新することであり、モデル自体から完璧な一貫性を引き出そうとすることではない。
ローンチ前にエスカレーション設計を固める
エージェントがどのように人間のオペレーターへ引き継ぐかは、どのように問題を解決するかと同じくらい重要だ。もしかするとそれ以上かもしれない。文脈が完全に引き継がれる丁寧なエスカレーションは、優れた顧客体験になる。一方、「それにはお答えできません」という行き止まりの返答の後、人間とのやり取りを最初からやり直すはめになるのは、フラストレーションのたまる体験だ。
ローンチ前に押さえておくべき3つのポイントがある。
1. 引き継ぎ条件を明示的に定義する。 ネガティブな感情の検知、VIP顧客セグメント、請求に関する紛争、確信度スコアが閾値を下回った場合、営業時間外のリクエストなど、具体的なトリガーを設定しよう。エージェントが「自分で判断して」エスカレーションするだろうという期待に頼ってはいけない。
2. 役に立つ引き継ぎメッセージを書く。 「これ以上のサポートができるスペシャリストにおつなぎします。これまでの会話も共有するので、同じ内容を繰り返す必要はありません」。これだけで十分だ。期待値を設定するにとどめ、説明過多にならないようにしよう。
3. 文脈が完全に引き継がれるようにする。 AI Agent Studioは、エスカレーションする前に、顧客の意図、アカウントの状態、会話の要約をチケットのペイロードに書き込む必要がある。AIからの引き継ぎ後に人間のオペレーターが「どういったご用件でしょうか?」と聞き直すはめになると、顧客のフラストレーションは倍増する。この「コンテキストロス率」、つまり人間が顧客に問題を言い直してもらう必要があったエスカレーションの割合は、明示的に追跡する価値がある。目標は5%未満だ。
メールのスレッド処理という制約。 これは、メールを主要チャネルとしているチームが見落としがちな、本番環境で初めて気づく落とし穴だ。Freddy AIのEmail AIエージェントは、スレッドの最初のメッセージにしか応答しない。同じメールスレッド内のそれ以降の返信にはAIが応答せず、そのまま人間のオペレーターに渡る。サポート量の大半が何往復もするメールスレッドであれば、実際のAI自動化率はセッション指標が示す数字よりも大幅に低くなる。関係者にデフレクション率の数字を約束する前に、このことを把握しておこう。
まずCopilotから始め、その後Agentへ拡張する
これは実践者たちが最も一貫して推奨する導入の順序であり、いちばん派手なものから展開したくなる直感には反している。
"多くのチームは、既存のオペレーターをすぐに支援できるAI Copilotから始め、慣れてきた段階でAI Agentを追加している。"
その理屈はこうだ。人間のオペレーターに返信案の提示、会話の要約、リアルタイム翻訳、感情分析アラートを提供するFreddy AI Copilotは、即座に、しかもリスクの低い価値をもたらす。あるFreshdesk導入企業でCustomer Care部門ディレクターを務めるAngela Thomas氏は、Copilotが非常に役立ったため、チームの定型返信の書き方そのものが変わったと語っている。そして重要なのは、Copilotは顧客がAIの失敗を目にすることなく、ナレッジベースのギャップを洗い出せるという点だ。
Copilotを4~6週間使い、洗い出されたギャップを埋め終えれば、本格的なAI Agentの導入ははるかに安全な賭けになる。その頃には、AIが自信を持って対応できるトピックと、もっとコンテンツが必要なトピックがすでに見えているはずだ。
推奨される段階的な展開は次の通りだ。
| フェーズ | 展開するもの | 目的 | 成功のシグナル |
|---|---|---|---|
| 1 | AI Copilotのみ | ナレッジベースのギャップ発見、チームの習熟 | オペレーターが日常的に返信案を活用している |
| 2 | 1チャネル(Webチャット)でのAI Agent | 低リスクで解決品質を検証 | CSATがベースライン維持または改善 |
| 3 | 高頻度ワークフローの追加(注文状況、パスワードリセットなど) | 自動化の深度を高める | 該当ワークフローのエスカレーション率30%未満 |
| 4 | 追加チャネルへの拡大 | 実証済みのパフォーマンスをスケール | チャネルごとの解決率が目標を達成 |
各フェーズの拡大は、カレンダー上の日付ではなく、前フェーズの実データによってトリガーされるべきだ。
デフレクション率だけでなく、解決率を測定する
多くのチームはデフレクション率を追跡し、それを成功の指標として扱っている。だがそれは正しくない。デフレクション率は、人間に到達しなかった問い合わせの数をカウントするものであり、そこには顧客が諦めたケース、間違った回答を受け取ったケース、単に会話を放棄したケースも含まれる。CSATが悪いのにデフレクション率だけが高い状態は、AIを導入していないよりも悪い。信頼をより早く失わせるからだ。
Freshdeskの優れた導入事例が採用している測定アプローチは次の通りだ。
| 指標 | 測定内容 | 目標値 |
|---|---|---|
| 解決率 | 人間の助けなしに完全解決したAI会話の割合 | 成熟期で55~70%、トップクラスで80%以上 |
| デフレクション率 | 人間に到達しなかった問い合わせの割合 | 業界中央値41.2%、上位四分位58.7% |
| CSATの変化幅 | AI導入前のベースラインからのCSATの変化 | 横ばいまたは改善 |
| 再オープン率 | 「解決済み」になったが48時間以内に顧客が再度連絡してきたチケットの割合 | 8%未満 |
| エスカレーション時のコンテキストロス | 人間が顧客に内容を繰り返してもらう必要があったエスカレーションの割合 | 5%未満 |
| ハルシネーション率 | 事実と異なる情報を含むAI応答の割合 | 1%未満 |
ハルシネーション率は、多くのチームが払っている以上の注意を払う価値がある指標だ。返金期限、料金、保証条件、SLAに関するコミットメントに触れるAI応答は、間違っていればコンプライアンス上のリスクになる。最初の4週間は、AIが解決したチケットのサンプルを抜き打ちでチェックしよう。事実と異なるポリシー詳細を見つけたら、該当するInstructionsを厳密にするか、「正確な料金については料金ページをご確認ください」のような明示的なフォールバック文言を追加しよう。
理解しておくべきベンチマークのギャップがある。2026年の業界中央値のデフレクション率は41.2%、上位四分位で58.7%だ。もし自分たちが40%であれば、それは期待を下回っているのではなく、むしろ成熟した導入としてまさに妥当な水準にいるのかもしれない。文脈が重要だ。
ローンチ前にベースラインを確立しておこう。カテゴリ別のチケット量、初回応答時間、解決時間、CSATについて過去90日分のデータを取得する。導入前のベースラインがなければ、ROIを示すことも、パフォーマンスの悪化を特定することもできない。
本番投入前に、運用上の制約を把握しておく
本番環境でのインシデントになる前に知っておくべき、プラットフォームの制約がいくつかある。
セッションの枯渇。 アカウントのセッション枠がゼロになると、AIエージェントはセッションを追加購入するまで、すべての問い合わせへの応答を停止する。これは段階的な機能低下ではなく、完全な停止だ。顧客が依存している導入であれば、自動チャージ機能(セッションが50を切ると発動する)を必ず有効にしておこう。また、プレビューテストも実際のセッションを消費する点を忘れずに。テストフェーズ用の予算は別枠で確保しておこう。
URL取り込みのサイレント失敗。 CAPTCHA、ポップアップ、ログイン画面、重いJavaScriptを含むページは、明確なエラーメッセージなしに取り込みに失敗する。エージェントは単純にその知識を持たないままになる。URLを追加したら、抽出コンテンツのプレビューを必ず確認しよう。失敗したURLについては、フォールバックとしてPDFやDOCX形式のコンテンツをアップロードしよう。
アカウントあたり25URLの上限。 これはアカウント内のすべてのエージェントに適用される。複数のエージェント(異なるブランド、異なる地域)を運用している場合、このプールは共有される。上限に近づいたら、重要なURLコンテンツをアップロードファイルに変換しよう。
複数ブランドでの運用。 1つのエージェントに複数のブランドを担当させるのではなく、ブランドごとに1エージェントを用意しよう。ブランドごとに専用のエージェントを持たせた方が、ナレッジ管理、テスト、パフォーマンス追跡が格段にすっきりする。
AI Insightsは英語のみ対応。 多言語分析はロードマップに含まれている。多言語で運用している場合、現時点では英語以外のエージェントのパフォーマンスをFreshdeskの標準レポート機能で追跡する必要がある。
| 制約 | 影響 | 回避策 |
|---|---|---|
| Email AIは最初のメッセージのみ対応 | 複数往復するメールスレッドは処理されない | メールのデフレクション見込みに織り込む。補助的なAIレイヤーを検討する |
| アカウントあたりURL25件の上限 | 大規模なコンテンツライブラリには制限が厳しい | 重要なURLをアップロードファイルに変換する |
| セッション枯渇=完全停止 | AIが一切応答しなくなる | セッション50件のしきい値で自動チャージを有効にする |
| URL取り込みのサイレント失敗 | 警告なしにナレッジギャップが発生 | URL追加のたびに抽出コンテンツのプレビューを確認する |
| AI Insightsは英語のみ | 多言語運用では分析ができない | 英語以外のボリュームはFreshdeskの標準レポートを使う |
FreshdeskでeeselAIを試す
Freddy AIのネイティブ機能、特に25URLの上限、メールのスレッド処理の制約、セッション課金モデルが、自社のサポート量やワークフローにしっくりこないと感じているなら、eesel AIはFreshdeskに直接連携する。既存のセットアップと並行して動くレイヤーとして機能する。
Design.comは、eesel AIのマルチエージェント構成を使い、Freshdesk上で月間5万件以上のチケットを処理している。課金モデルはまったく異なり、セッション単位ではなく解決チケット1件あたり0.40ドルを支払う形で、シート費用は発生しない。ナレッジの取り込みも25URLに制限されず、eeselはZendesk、Google Docs、Notion、Confluence、Slack、そして既存のヘルプセンターから同時に取り込める。ドラフトモード(送信前に人間がレビュー)とオートノマスモード(確信度の高いチケットは直接送信)により、チケットのカテゴリに応じて完全自動化と人間の監督付きAIの間を自由に調整できる。
本導入の前に実際のチケットで試してみたいなら、50ドル分の無料トライアルがある。クレジットカードは不要だ。