2026年のFreshserviceチケットにAIを活用する方法
Alicia Kirana Utomo
Katelin Teen
最終更新 June 17, 2026

まとめ
FreshserviceのチケットキューにAIを導入する実際の方法は2つあります。FreshworksのネイティブレイヤーであるFreddy AIを有効にするか、ワークスペース内のエージェント支援には優れていますが、自律型エージェントはEnterpriseプランのみで、セッション課金となります。あるいは、APIを通じてFreshserviceの上に専用AIエージェントを追加することもできます。これにより、モデルの選択、本番前に過去のチケットでシミュレーション、ループに人間を維持、エージェントごとではなく使用量ベースの支払いが可能になります。
ライブサポートとITキューでAIを長年運用してきた私の正直な見解:Freshworks Enterpriseにすでに完全に投資しているなら、ネイティブオプションは問題ありませんが、ほとんどのチームは追加ツールの方が優れた問い合わせ削減とより多くのコントロールを得られます。AIが役立つか否かを実際に決めるのはモデルではなく、確信のあるチケットにのみ行動させ、残りを人間にルーティングするかどうかです。
「FreshserviceチケットへのAI」が実際に意味すること
ツールを選ぶ前に、サービスデスクでAIが何をするよう求められているかを正確に理解しておく価値があります。「AI」は3つの異なる仕事を意味するために使われるからです。
3つの仕事とは、問い合わせ削減(デフレクション)、支援(アシスト)、トリアージです。デフレクションとは、定型リクエスト(パスワードリセット、「Xへのアクセスを取得するには?」、状況確認)が人間に届く前に自律ボットが回答することです。アシストは、すでにチケットに対応中のエージェントのために返信を下書きしたり、長いスレッドを要約したり、メッセージを翻訳したりするコパイロットです。トリアージは、受信チケットを読んでタグ付けし、ルーティングし、社内メモとして提案返信を残すという静かな作業です。ITサービスデスクの価値の大部分は、1番目と3番目にあります。
私はここ数年、実際のライブサポートとITキューにAIエージェントを導入してきましたが、パターンは繰り返されます:勝利は決して「AIがすべてに答える」ではありません。繰り返し作業の30〜40%をAIが処理することで、スタッフが実際に人間が必要なチケットに時間を使えるようになることです。InDebtedが社内ITヘルプデスクに私たちを導入したとき、IT責任者のJason Loyolaはこう説明しました:「JiraのHelpdeskチケットへの最初の対応者として使っています。エージェントとまったく同じように機能します。」彼らは15%のデフレクションから始まり、55%を目指しています。これが、チケットがJira、Freshservice、あるいはどこにあっても同じ、サービスデスクでの良い結果の形です。
よく設定されたAIレイヤーが、1つのFreshserviceチケットをそのフローでどのように処理するかを示します。

オプション1:Freddy AI、Freshworksのネイティブレイヤー
最初の明確な動きは、すでに含まれているものを使うことです。FreshserviceのAIはFreddy AIという名称で、いくつかの点で本当に優秀です。3つの製品に分かれており、1つのものとしてマーケティングされているため、区別しておくことが重要です。
Freddy AI Agentは、Slack、Microsoft Teams、メールボット、サポートポータル全体でリクエストをデフレクションする自律型ティアで、ナレッジベースに加えSharePoint、Google Drive、Confluenceに基づいて回答します。Freddy AI Copilotはワークスペース内のエージェント支援ティアで、返信提案、チケット要約、リアルタイム翻訳を提供します。Freddy AI InsightsはサービスデスクリーダーのためにSLA違反のスパイクなどを検出する分析レイヤーです。FreshworksはITSM向けAIページに実際のITSMの数字を掲載しています:受信チケットの66%をデフレクション、最初の応答時間を41%短縮、Copilotにより平均解決時間が77%低下。
Freddyが本当に優れているのはCopilotです。エージェントがすでにFreshserviceワークスペースで作業しているなら、コンテキストスイッチなしでワンクリックで要約ツールと返信提案が使えることは、本当に仕事の質を高めます。これを使わないように勧めることはしません。
Freddy AIのコスト
ここがチームを混乱させる部分です。自律型エージェントは、おそらく現在使用しているプランには含まれていません。Freddy AIはEnterpriseティアのみにバンドルされており、エージェントごとのITSMプランは次のとおりです(年次請求):
| プラン | 価格(エージェント / 月) | Freddy AI |
|---|---|---|
| Starter | $19 | 含まれない |
| Growth | $49 | 含まれない |
| Pro | $99 | 含まれない |
| Enterprise | カスタム(営業に問い合わせ) | 含まれる |
Freddy AI Agentの課金単位はセッションで、Freshworks自身の料金FAQでは「ユニークユーザーが24時間以内にAI Agentと行うやり取り」と定義されています。各Enterpriseライセンスには年間1,200のFreddy AI Agentセッションが含まれており(短いサイクルには按分)、超過セッションパックは見積もりのみです。セッション単価の公開はなく、予測が困難です。Freshservice Freddy AI料金ガイドでフルモデルを詳しく説明していますが、要約すると:自律型エージェントを使用するには、最も高価なティアにいて、シートごとにFreshservice Enterpriseの価格を支払い、さらにAIを追加でメータリングすることになります。
Freddyの限界
ここは率直に話す必要があります。マーケティングの数字とユーザーのレポートは必ずしも一致しないからです。最もよく繰り返される不満は価格ではなく、より静かな失敗についてです:すべてのチケットに挑戦し、難しいものに失敗し、エージェントを以前より悪い状態に置くボットです。
600人規模の組織のITリーダーが、Freddyを有効にして5ヶ月後にまさにこれを書きました:
「自動解決はおそらく25%で、まあいいかとは思う。でも実際のMTTRは上がった。以前と比べて約20%…Freddyは試みて、失敗して、エージェントが引き取るが、返信する前にAIのやり取り全体をスクロールしなければならない。いくつかのチケットを計測したが、AIコンテキストを読むだけで1チケットあたり2〜3分余計にかかる…重複チケットも約15%増加した。」
同じRedditスレッドは全部読む価値があります。要点は「AIが悪い」ではなく、信頼度ゲートのないボットが、デフレクションの利益を上回りかねないハンドオフコストを追加するということです。以下は、そのメカニズムを並べて示したものです。

不満は他の部分にも集まっています。デフレクション品質は弱いと言われており、あるsysadminはAIが「インシデントデフレクションには最悪」と述べ、さらに「ユーザーがやり取りを役に立たないと評価しても学習しない」と言います。モデル選択肢がなく、あるFreshserviceユーザーはまとめとして「使いたいLLMを選ぶ機能がない。また、価格はエージェントに紐付いており、従業員ではない」と述べています。セットアップが権限でブロックされることもあり、あるチームはTeams ServiceBotが「アプリケーションレベルで『すべてのサイトコレクションのファイルを読む』権限が必要」なためにブロックされ、セキュリティチームが承認しませんでした。残りはFreshservice AIの制限の記事にまとめています。
これらはFreddy を悪い製品にするものではありません。Freshworks Enterpriseに深く投資していて、ニーズが主流であれば最もよく機能する製品にするものです。これらのギャップのいずれかが問題なら、レイヤリングがより良い選択です。
オプション2:Freshserviceの上に専用AIエージェントを追加する
ほとんどのチームが行き着く代替案は、Freshserviceをそのままにして、APIを通じて専用AIエージェントをその上に接続することです。プラン、ワークフロー、チケット履歴をそのまま維持できます。AIが最初の対応者とトリアージレイヤーになり、サービスデスクが真実の源となり続けます。これは、上記のギャップがあるからこそ私たちがeesel AIを作った理由です。

Freshserviceチームにとって最も重要な3つの違いがあります。第一に、過去のチケットでAIをトレーニングし、公開記事だけでなく社内ナレッジベース全体を活用できるため、誰かが退職したときに失われがちな暗黙知を含め、最もベテランのエージェントと同じように回答します。第二に、信頼度ベースのトリアージを利用できます:AIは確信のあるチケットにのみ対応し、それ以外はすべて人間に委ねます。これが上記のMTTR後退を防ぐ唯一の設定です。第三に、1つのベンダーのモデルに縛られず、エージェントごとではなくインタラクションごとに支払います。
このモデルの問題は、多くのチームにとって自社開発か購入かの決断となります。GENERAL BYTESのKarelは、自社開発の代わりに追加エージェントを選んだとき、次のように語っています:「自社のLLMアプリを書くことも考えたが、その時間を投資したくなかった。メンテナンスが不要なものが欲しかった。」レイヤリングにより、メンテナンスコストなしでカスタムビルドの柔軟性が得られます。
本当にデフレクションできるのでしょうか?ZendeskでのGridwiseのKim SimpsonはG2で報告しています:「最初の月に、eeselはティア1リクエストの73%を解決しています」、7日間のトライアル内に結果が出ました。このプラットフォームはFreshservice固有の魔法ではなく、どのキューにでも適用できる同じ信頼度ゲートアプローチです。より広いカテゴリについては、サービスデスク向けAI ITサポートツールのまとめで追加オプションを並べて比較しています。
FreshserviceチケットキューにAIをセットアップする方法
どのツールを選んでも、機能するロールアウトは同じで、「有効にして願う」の真逆です。問題が起きるチームは、初日にボットをキュー全体に向けるチームです。私が実行するシーケンスを紹介します。

- ヘルプデスクとナレッジを接続する。 AIをFreshserviceに接続し、ナレッジソースに向けます:Confluenceナレッジベース、SharePoint、Google Drive、社内ドキュメント、そして理想的には解決済みチケットも。AIの根拠が多いほど、推測が減ります。

-
本番前に過去のチケットでシミュレーションする。 これはほぼ全員がスキップするステップですが、最も重要です。AIを数千の過去のFreshserviceチケットに対して実行し、何と答えたかを確認します。1人の顧客にも影響を与える前に、実際のデフレクション見積もりとギャップのリストが得られます。同僚のAmoghはこれがどれほど頻繁に話題になるかについて繰り返しジョークを言っています:「みんな本当に、本当に、本当に過去のチケットでトレーニングしたがる。」それを望むのは、AIが何をするかを知る唯一の正直な方法だからです。
-
ドラフトモードから始め、人間が承認する。 AIに返信を書かせ、エージェントが承認または修正するための社内メモやドラフトとして残させます。信頼を構築し、AIは編集から学習します。この考えは、まさにこのコントロールが必要だったCXリーダーからのものです:「自信を持って対応できるチケットだけを処理するAIが必要で、その他のものはそのままにしておいてほしい。」それがゲーム全体です。

-
確実性の高いチケットタイプを自動解決にスケールアップする。 カテゴリ(パスワードリセット、アクセスリクエスト、「注文はどこですか」)がドラフトモードで確実に良い結果を出したら、AIにそれらを自律的にクローズさせます。それ以外はすべてゲートを維持します。ここでチケット分類とタグ付けが価値を発揮します。クリーンなカテゴリが1つのスライスずつスケールアップを可能にします。
-
数字を見て改善する。 デフレクション、解決時間、AIがハンドオフする場所を追跡し、失敗をフィードバックします。良いレポーティングが、一度きりのセットアップを継続的に改善するものに変えます。

Freddy vs. 追加AIエージェント:簡単な比較
決断を1画面で見たい場合はこちらです。どちらの列も「間違い」ではなく、異なるチームに適しています。
| 項目 | Freddy AI(ネイティブ) | 追加AIエージェント(例:eesel) |
|---|---|---|
| 自律型エージェントに必要なプラン | Enterpriseのみ | 任意のプラン;APIで接続 |
| 課金単位 | セッション(24時間あたり、ユーザーごと) | AIインタラクションごと、シートごとの料金なし |
| モデル選択 | いいえ、Freshworksに固定 | はい、モデルを選択可能 |
| 本番前に過去のチケットでシミュレーション | 提供なし | はい、過去のチケットで可能 |
| ヒューマンインザループ / 信頼度ゲート | 限定的 | 組み込み、チケットタイプごと |
| 解決済みチケットでトレーニング | 主にナレッジソース | はい、過去のチケットと文書 |
| セットアップ | 管理者有効化、Enterpriseゲート | Freshserviceを接続、現在のプラン維持 |
| 「役に立たない」評価から学習 | 弱いと報告されている | エージェントへのフィードバックループ |
HaloITSMやServiceNow風のオプションを含むより広いフィールドについては、Freshserviceの代替のまとめとFreshservice vs Jira Service Managementの比較をご覧ください。
避けるべき一般的な間違い
サービスデスクのAI導入(Freshserviceに限らず)で何度も見かけるいくつかの落とし穴。
- 初日にボットをキュー全体に向ける。 これがMTTR後退の原因です。ゲートを設け、段階的にスケールアップしましょう。
- シミュレーションをスキップする。 先月のチケットでAIが何をしたかを教えられないなら、盲目的にローンチしています。まずナレッジベースでトレーニングし、履歴に対してテストしましょう。
- セルフサービスをコンテンツダンプとして扱う。 ボットは背後にあるナレッジベースと同程度の品質しか持ちません。薄いまたは古いドキュメントは自信満々の誤答を生み出します。
- 社内ITとHRを忘れる。 Freshserviceの多くの価値は社内にあります。顧客チケットをデフレクションする同じエージェントが、従業員セルフサービス、HRヘルプデスク、Slack経由のITサポートを実行できます。
- レイヤーをテストする前にEnterpriseアップグレードを購入する。 Enterpriseを検討している唯一の理由がFreddyなら、現在のプランで最初に追加のAIヘルプデスクエージェントを試してください。その方法で確認する方が安上がりです。
Freshserviceチケットにeeselを試す
EnterpriseにアップグレードしたりAIものを移行したりせずにFreshserviceキューにAIを使いたい場合、それがまさにeesel AIが行うことです。既存のサービスデスクに接続し、過去のチケットと文書でトレーニングし、確信のあるものだけを解決してその他をチームに引き渡す信頼度ゲートで動作します。ほとんどのチームが重視する差別化ポイント:ライブチケットに触れる前に数千の過去のチケットでシミュレーションし、実際のデフレクション数値を確認できます。その後、自分のペースでドラフトモードから自動解決にスケールアップできます。無料で始め、エージェントごとではなくインタラクションごとに支払うことができます。

よくある質問
FreshserviceにはチケットのためのAI機能が組み込まれていますか?
FreshserviceチケットへのAI利用はいくらかかりますか?
AIはFreshserviceチケットを人間なしで自動解決できますか?
AIはFreshserviceチケットに回答するためにどんな知識を使えますか?
AIはFreshserviceの解決時間を改善しますか、悪化させますか?
プランを変更したり移行したりせずにFreshserviceでAIを使えますか?
小規模ITチームにとってFreshserviceチケットへのAI導入は価値がありますか?

Article by
Alicia Kirana Utomo
Kira is a writer at eesel AI with a Computer Science background and over a year of hands-on experience evaluating AI-powered customer service tools. She focuses on breaking down how helpdesk platforms and AI agents actually work so that support teams can make better buying decisions.


