Freshserviceのチケットデフレクション:2026年にAIでITチケットを削減する方法

ITチームにとってチケットデフレクションが本当に意味すること

デフレクションは、誰もが口にするのに、同じように定義している人はほとんどいない指標の一つです。だからこそ、設定をいじる前にきちんと定義しておく価値があります。

チケットデフレクションとは、人間のエージェントを介さずに解決される受信リクエストの割合のことで、通常はセルフサービス層が先に質問に答えるか、タスクを完了させることによって実現します。誰かがVPNのリセットを必要とし、Slackで質問し、AIがその人を導き、キューにチケットが1件も入らない。これがデフレクションされたリクエストです。

これは解決(レゾリューション)とは違います。レゾリューションは、チームが手作業で対応した何百件も含め、クローズされたすべてのチケットをカウントします。デフレクションは、あなたを一度も必要としなかったものだけをカウントします。この違いは重要です。なぜなら、すべてに「回答」しているように見えても、混乱したフォローアップの波を生むボットは、何もデフレクションしておらず、単に作業を後工程に移しているだけだからです。

計算式は単純です。デフレクション率 = セルフサービスで解決されたリクエスト ÷ 総リクエスト数。難しいのは、その裏にある品質基準です。デフレクションされたリクエストは実際に解決されていなければならず、そうでないものは、完全な文脈を持った人にきれいにエスカレーションされなければなりません。ここを間違えると、表向きのデフレクション数値は上がる一方で、チームは静かに溺れていきます。これは、私たちのサポートチケットデフレクションガイドで取り上げているのと同じトレードオフであり、以下のすべてを見るときに持ち続けるべき視点です。

Freshserviceのチケットデフレクションへのアプローチ

FreshserviceはFreshworksのAI駆動型ITSMプラットフォームであり、そのデフレクションに関する話は、すべて1つの製品、Freddy AI Agentを通じて展開されます。Freshworksはこれを、繰り返し発生する問い合わせを解決し「数分でライブになる」AIだと説明しており、Freshserviceのホームページでは、AI活用型セルフサービスによる66%のチケットデフレクションに加え、平均解決時間の77%の削減、そしてForrester社のTEI調査による356%のROIという数字を挙げています。

Freddy AI Agentは、自律型で従業員向けの階層であり、リクエストを傍受してチケットになる前に解決を試みるボットです。ナレッジソースを活用してよくある質問に答え、堅苦しいフォームを使わずに、会話からサービスリクエストを自動的に作成することもできます。その背後には、直接デフレクションはしないものの体験を形作る、もう2つのFreddy製品があります。返信の下書きやチケットの要約を行うエージェント支援層のFreddy AI Copilotと、サービスリーダー向けの分析層であるFreddy AI Insightsです。

Freshserviceにおけるデフレクションは、この1つのエージェントによって動かされる4つのチャネルで発生します。

• サポートポータル: 依頼者にとって従来のナレッジベース検索に代わる、会話形式のセルフサービス。
• メールボット: シンプルなメールの問い合わせに、関連するヘルプ記事で自動的に返信する。
• SlackとMicrosoft Teams: ServiceBot連携を通じて、従業員がすでに日常的に使っているツールの中で、一次対応の回答とサービスリクエストを行う。
• Microsoft 365 Copilot: M365の体験の中にサービスインテリジェンスを表示する。

紙の上では、これは完成されたイメージです。従業員がいる場所で対応し、ナレッジベースから回答し、AIが対処できないものだけをエスカレーションする。いつものように、落とし穴はセットアップと細部にあります。

Freshserviceでチケットデフレクションを設定する手順

Freddyを有効にするのは管理者のタスクであり、展開するチャネルによって手順は多少異なります。以下がその流れです。

ステップ1: 適切なプランに加入しているか確認する

これは、ほとんどのチームが最初にぶつかる壁です。公式のセットアップドキュメントによれば、Freddy AI AgentはFreshserviceのEnterpriseプランでのみ利用可能です。下位のプラン(Starter、Growth、Pro)には自律型エージェントは含まれていないため、デフレクションが目的であるなら、実質的に最上位プランへの加入を意味します。その費用については後ほど触れます。

ステップ2: グローバル設定でFreddyを有効にする

Enterpriseに加入したら、Admin > Global Settingsに移動し、Freddyを検索します。

Freddyのカードを選択し、チャネルごとのトグルを使って、デフレクションさせたい各サーフェスでエージェントを有効にします。ここでメールボットとサポートポータルのトグル、そして先にServiceBotのインストールが必要なSlackとTeamsのオプションを確認できます。

SlackとMicrosoft Teamsでは、そのプラットフォーム向けにServiceBotをインストールしないと、そこでFreddyを設定できません。サポートポータルとメールボットにはその必要はありません。

ステップ3: ナレッジソースを接続し、準備する

デフレクションの質は、AIが読み取れる内容次第です。FreddyのEnterprise Searchは、Freshserviceのナレッジベース、Microsoft SharePoint、Google Drive、Confluenceから情報を取得できます。ここでナレッジベースが重要な役割を果たすため、処理上の制約を事前に知っておく価値があります。

• Freddyがソリューション記事内で処理するのは、最初の50枚のインライン画像と最初の5つの添付ファイル(それぞれ最大5MB)のみです。
• 記事の処理完了には、1時間から24時間程度かかることがあります。
• 記事内の画像ベースのコンテンツは解釈できますが、.pdf、.docx、.xlsxファイルは読み取れません。

この最後の点は、ランブックがWordやPDFで管理されている多くのITチームをつまずかせます。信頼できる情報源がFreddyの解析できない文書の山であるなら、始める前からデフレクション率には上限が課されています。

ステップ4: 引き継ぎを設定し、利用状況を追跡する

セルフ解決に失敗した場合、Freddyの「シームレスなエージェント引き継ぎ」機能は、その会話をインシデントに変換し、アップロードされたスクリーンショットを含む完全なチャット履歴を担当エージェントに渡します。その後は数字を見守りましょう。Analyticsモジュール内のFreddy AI Agent概要レポートは利用状況とパフォーマンスを追跡しており、実際に何がデフレクションされているのかを知るためのフィードバックループとなります。

実際のデフレクションの姿(そしてギャップが見える場所)

これはマーケティングページが触れない部分です。Freddyのセットアップは簡単ですが、あの66%という数字に少しでも近づくのはまったく別の話であり、Freshserviceのユーザーコミュニティ自身がそれを率直に語っています。

最も鋭い警告は、Freddyを有効にして5か月後に結果を測定した、従業員600人規模の組織のITリーダーから寄せられています。

"Autoresolve is maybe 25% which is fine i guess. But our MTTR actually went UP. About 20% compared to where we were before... Freddy tries, fails, agent picks it up but has to scroll thru the full back-and-forth before they can respond... users who got autoresolved come back 2 days later w/ a follow up, new ticket because the original closed. Dup tickets are up like 15ish percent."

u/Time_Beautiful2460, r/Freshservice

これは1つの投稿に凝縮されたデフレクションの罠です。約25%の自動解決率が、平均解決時間を悪化させました。なぜなら、失敗したすべての試みが引き継ぎのオーバーヘッドを追加し、不安定な「解決」のすべてが重複チケットとして戻ってきたからです。見出しの数字は上がったのに、チームは遅くなりました。

AIの限界について、もっと率直な意見もあります。Freshserviceを評価していたあるシステム管理者はこう述べています。

"the AI is abysmal for incident deflection and offers zero insight into why users found it unhelpful when they rate it and it also doesn't learn from users rating an interaction as unhelpful."

u/howzer22x, r/sysadmin

「学習しない」という不満は、じっくり考えるべきものです。集めた低評価から改善できないデフレクションエンジンは、最初のナレッジベースが置いた場所で頭打ちになります。とはいえ、これはFreshserviceが悪いサービスデスクだという意味ではありません。多くの中規模チームは、そのすっきりしたUIと速いセットアップを実際に気に入っています。つまり、デフレクションの数字は自動で得られるものではなく、勝ち取るものであり、FreshserviceのAIの制限は、それを見越して計画すべきほど現実的だということです。

契約前に知っておくべき料金とセッションのモデル

Freshserviceにおけるデフレクションには、チームの予想を裏切るコスト構造があるため、きちんと整理しておきましょう。以下は4つのITSMティア(年払い)です。

構造上の落とし穴は右側の列にあります。自律型のFreddy AI Agentは、Enterpriseにのみバンドルされています。他のどのティアでもアドオン扱いか、そもそも利用できません。そのため、デフレクションを実現するということは、実質的に最上位プランを購入することを意味します。Freshserviceのコミュニティ自身も、この点について率直に発言しています。

"I do like the UI of Freshservice seems easy to use. The freddy AI is an add on so expensive for what it can do and only available at enterprise."

r/sysadmin

そして、課金単位の問題があります。Freddy AI Agentはセッション単位で計測され、セッションとは、あるユニークユーザーが24時間以内にエージェントと行うあらゆるやり取りを指します。各Enterpriseライセンスには年間1,200セッションが含まれており、追加のセッションパックや超過分は問い合わせによる見積もりとなります(Freshworksはこれらの数字を公開していません)。忙しいIT組織にとって、1,200セッションは多いとは言えず、しかもこのモデルは、あなたが直接コントロールできない指標に基づいて課金される仕組みです。

ユーザーが指摘する、より根深い異論は、料金が何に紐づいているかという点です。

"Freddy AI has the same limitations as every AI tool built by ITSM vendors. It's mainly tight to the Freshworks ecosystem, plus has limited human in the loop validation along with the fact that you don't have the ability to choose which LLMs you want to use. Also, its pricing is tied to the agents not the employees."

u/chris_la33, r/Freshservice

全体像については、私たちのFreshservice料金の内訳とEnterprise料金ガイドで、各項目を詳しく解説しています。要点をまとめると、ここでのデフレクションはEnterpriseティア、エージェント単位、セッション単位でのコミットメントを意味しており、契約する前に、実際に節約できるエージェントの工数に対してコストを見合わせるべきです。

デフレクション率を実際に高める方法

どのツールを使うにせよ、デフレクションを動かすレバーは同じです。ボットが担うのは結果のせいぜい20%であり、残りの80%はそれを取り巻くすべてのものです。ここにエネルギーを注ぐべきです。

1. まずナレッジベースを整備する。 これは間違いなく最大のレバーであり、だからこそ前述のWordやPDFの問題がこれほど重要なのです。AIが読み取れる形式で回答が書かれていなければ、どんなチューニングも救いにはなりません。記事を監査し、チケット履歴が明らかにするギャップを埋め、常に最新の状態に保ちましょう。「AI対応」が実際に何を意味するのかは、私たちのAIナレッジベースガイドで解説しています。

2. AIが確信を持てるものだけを振り分ける。 これはほとんどのチームが見落としがちなレバーであり、本当のデフレクションを重複チケットの罠から分ける決め手です。ボットにすべてのリクエストを無理に処理させるのではなく、確信の持てる質問だけを扱わせ、残りは手を付けずに人間に任せます。月間約7,000件のチケットを処理するDTCサプリメントブランドのCXリーダーは、この問題全体を私たちのチームに一言で伝えてくれました。AIは「100%の質問に答えられるようには決してならない」のであり、「すみません、わかりません」とだけ返すボットは無意味です。なぜなら「AIが本当に良い回答をしたかどうかを確認するために、自分の7,000件のチケットすべてをチェックすることはできない」からです。彼女が求めていたのは、「確信を持って対応できるチケットだけを扱い、それ以外はすべて放っておく」AIでした。これこそが確信度に基づくルーティングであり、前述のFreshserviceユーザーたちが求め続けてきたまさにそのコントロールです。

3. 過去のチケットで学習する。 過去のチケットは、考えうる最良の学習データです。従業員が尋ねる正確な質問と、実際に機能した正確な回答が含まれているからです。そこから学習するデフレクションエンジンは、薄いナレッジベースだけで動くものよりもはるかに高いところからスタートします。「フィードバックから学習しない」というFreddyへの不満が最も痛烈に効いてくるのも、まさにこの点です。

4. すでに使われているチャネルで従業員に対応する。 セルフサービスは、人々がそれを使ってこそデフレクションします。従業員がすでに質問をしているSlackやTeamsの中で回答することは、誰も訪れないポータルよりもはるかに多くをデフレクションします。

5. エスカレーションをきれいにする。 AIが引き継ぐ際、エージェントは失敗したやり取りを最初から読み返す必要なく、即座に完全な文脈を得られるべきです(これこそが、あの20%のMTTR悪化を引き起こした要因でした)。きれいなエスカレーションこそが、高いデフレクション率が隠れた手戻り作業に変わるのを防ぎます。

Freshserviceのチケットデフレクションでeeselを試してみる

上記で挙げたFreshserviceの限界、Enterprise限定の制約、セッション上限、フィードバックから学習できないAI、これらに心当たりがあるなら、まさにそのギャップを埋めるために作られたのがeeselです。eeselは、Freshservice、Jira Service Management、Slack、Microsoft Teamsなど、チームがすでに使っているツールの中で動作し、一次対応のITリクエストを自律的に処理するAIエージェントです。

デフレクションの計算式が違ってくる理由は2つあります。第一に、eeselは自社の過去のチケットで学習し、実際のリクエストに返信する前に、過去のリクエストに対してシミュレーションを実行できます。そのため、5か月後に発見するのではなく、事前に予測デフレクション率を確認できます。第二に、確信度に基づくルーティングを採用しています。どのリクエストを処理させるかを正確に自分で決め、残りは人間に任せます。これは、前述のFreshserviceユーザーたちが求め続けてきた、まさに唯一のコントロールです。

これはすでに実際のITヘルプデスクで機能しています。InDebtedのIT責任者であるJason Loyola氏は、Jira Service Managementのキューでeeselを一次対応として運用し、55%という目標に向けてチケットをデフレクションしています。料金は使用量に基づいており(エージェント単位やセッション単位ではなく、タスク単位)、コストは実際にデフレクションした分に応じて決まります。Enterprise契約なしで、数分で接続し、自社のチケットで試すことができます。