Freshserviceに AIを追加する方法:2026年実践ガイド

まず、「Freshserviceに AIを追加する」とは実際何を意味するのか

私は日々インテグレーションを構築している立場として、率直に言います。「AIを追加する」という言葉は曖昧で、Freshworksはこの言葉をFreddy AIという名前のもとに3つの異なる製品を指すために使っています。設定を触る前に、自分が実際にどれを有効化しようとしているのかを知っておくと役立ちます。

• Freddy AI Agentは、人間が対応する前にリクエストをデフレクトし解決する、自律的で従業員向けのボットです。これは、多くの人が「AI」と言うときに思い浮かべるFreshservice AIエージェントです。
• Freddy AI Copilotはエージェント支援機能です。返信案の提示、チケットの要約、エージェントワークスペース内での文章作成支援を行います。チームを助けるものであり、エンドユーザーを助けるものではありません。
• Freddy AI Insightsは、サービスデスクのリーダー向けに根本原因分析を行うプロアクティブな分析機能です。

これが重要な理由は、それぞれ提供条件と課金方法が異なり、そこでチームが驚くことになるからです。つまり最初にすべき判断は「AIを追加すべきか」ではなく、「自分のプランとキューにはどちらのルートが合うか」です。ここで分岐点となります。

同じチケットキューに対する2つのルート:ネイティブのFreddy AI、またはFreshservice API経由で接続した重ねるタイプのエージェント。

ルート1:Freddy AIを有効化する(ネイティブな方法)

Enterpriseを利用している場合(またはエージェント支援のCopilotだけが欲しい場合)、ネイティブなルートは本当に速く進められます。FreshworksはGenAI版の新しいFreddy AI Agentを「初日から support を始める準備ができている」と位置づけており、有効化は実際に数クリックで済みます。セットアップの流れは以下のとおりです。

最初に確認すべき前提条件

• 自律型エージェントにはEnterpriseが必要です。 Freddy AI Agent概要ドキュメントには、Enterpriseプランで利用可能であると明記されています。Copilotは、ProとEnterpriseで提供される、エージェントごとの別の追加オプションです。
• SlackとMicrosoft Teamsは先にServiceBotのインストールが必要です。 そのプラットフォーム用のServiceBotが導入されるまで、それらのチャネルでFreddyを設定することはできません。Support PortalとEmail Botはこれを必要としません。
• 旧Virtual Agentを使っていた場合、2025年5月21日に廃止された点に注意してください。2024年10月18日より前に有効化していたユーザーは、エージェントを稼働し続けるためにGenAI版へのアップグレードが必要でした。

実際の手順

1. Admin > Global Settingsに移動し、Freddyを検索します。Freddy AIパネルに到達し、Freddyカードと、SlackおよびMicrosoft Teams用のServiceBotチャネルが表示されます。

Admin > Global Settings > 「Freddy」を検索することが、AI層を有効化するための入口です。Freshserviceサポートドキュメントより。

2. Freddyカードを開き、チャネルごとのトグルを使ってFreddy AI Agentを必要な場所で有効にします。Support Portal(申請者向けセルフサービス)、Email Bot(簡単なメールの問い合わせに適切なヘルプ記事で自動返信)、Slack/Microsoft Teams(チャット内での一次対応)です。

Freddy AI Agentはチャネルごとに有効化されます。「Setup Now」リンクから会話形式のセットアップに進めます。Freshserviceサポートドキュメントより。

3. 自社のナレッジに向けて設定します。FreddyのEnterprise Searchは、社内ナレッジベースに加えて、Microsoft SharePoint、Google Drive、Confluenceを参照できます。
4. コンテンツを読み込む際は、記事の処理ルールに注意してください。Freddyはソリューション記事ごとに最初の50枚のインライン画像と最初の5個の添付ファイル(それぞれ最大5MB)しか読み込みません。また、記事の処理完了には1時間から24時間かかることがあります。記事内の画像は解釈できますが、.pdf、.docx、.xlsxファイルは読み込めないため、添付PDFだらけのナレッジベースではパフォーマンスが低下します。

これがネイティブ設定のすべてです。本当にシンプルであり、ワークスペース内のエージェント支援としては妥当な出発点です。

チームがつまずく制限事項

ここからは率直に伝えなければなりません。セットアップが簡単だからといって、AIが安価または効果的だとは限らないからです。

制限があり、セッション単位で課金されます。 Freddy AI AgentはEnterprise限定で、各Enterpriseライセンスには年間1,200セッションが含まれます。セッションとは、24時間の枠内で特定のユーザーがエージェントと行う任意のやり取りを指します。超過パックは存在しますが、価格は見積もり制で、アカウントマネージャーを通じて設定され、公開されることはありません。詳しい計算については、Freshservice AIコストガイドで解説しています。ユーザーはこの課金モデルを次のように感じています。

"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

SharePointの権限範囲がロールアウトを阻む場合があります。 r/Freshserviceの複数のチームが、Teams用ServiceBotが非常に広範なアクセスを要求するために導入を見送っています。

"it requires 'Read files in all site collections' on an Application level to function, Which essentially give it the ability to read everything in our company Sharepoint as far as i'm aware."

u/Towelie888, r/Freshservice

そして引き継ぎコストが、静かに節約分以上のコストを生むことがあります。 ここには警告ラベルを貼りたいところです。従業員約600人の組織が、Freddyを有効化してから5カ月後、Tier-1のMTTRが低下するどころか上昇し、重複チケットが約15%増加したと報告しています。

"Autoresolve is maybe 25% which is fine i guess. But our MTTR actually went UP. About 20%... Tickets that dont autoresolve are sitting longer. I think what is happening is the handoff cost. Freddy tries, fails, agent picks it up but has to scroll thru the full back-and-forth before they can respond."

u/Time_Beautiful2460, r/Freshservice

これはAIそのものへの反対意見ではありません。すべてに答えようとし、失敗したときに散らかった状態を引き継ぐAIに対する反対意見です。私たちは実際の導入の中でまさにこの失敗パターンを目にしてきました。だからこそ、実際に機能する設計は下図の右側のようになります。

害になるAIと役立つAIの違いは、ほとんどの場合モデルではありません。いつ止まり、きれいに引き継ぐべきかを知っているかどうかです。ここでの数値は、上記のr/Freshserviceスレッドによるものです。

ネイティブ層がつまずくポイントの全体像については、Freshservice AIの制限事項で随時更新しているリストをご覧ください。

ルート2:Freshservice APIの上に専用のAIエージェントを重ねる

AIを追加するもう一つの方法は、Freshserviceをそのままの状態にしておき、Freshservice API経由で目的特化型のAIエージェントを上から接続することです。これは、私が自分でそのようなツールに関わっているからではなく、ほとんどのチームに勧めたいルートです。上記の問題をすべて回避できます。現在のプランを維持し、モデルを自由に選べ、デフォルトで人間をループに残せます。

仕組みとしては、重ねるタイプのエージェントはチケットキューを監視し、受信したリクエストを読み取り、ナレッジからコンテキストを引き出したうえで、どれだけ確信があるかに基づいて判断を下します。この確信度ゲートこそがすべての鍵です。

きちんと設定されたAI層は、すべての回答を自社のナレッジに基づかせ、自らの確信度を確認したうえで、解決・下書き・エスカレーションの3つの結果から1つを選びます。

過去のチケットにもヘルプ記事と同様に回答の根拠を置くため、ナレッジベースが文字通り述べていることだけでなく、最も優秀な担当者が実際にどう答えるかに近い形からスタートします。そして、実際のチケットに触れる前に過去のチケットに対してシミュレーションを実行できるため、本番導入を決める前に、チケット種別ごとの実際のデフレクション数値を確認できます。これが、MTTRの罠を回避するステップです。顧客が気づく前に、AIが決して触れるべきでないチケットを見つけられます。

トレードオフも正直に伝えます。重ねるタイプのツールは接続すべきシステムが1つ増えることを意味し、ネイティブなトグルではなくAPIインテグレーションを信頼することになります。しかし、Freshservice APIはドキュメントが整備されており安定しているため、接続作業は移行ではなく、数分で終わる一度きりの作業です。

ネイティブのFreddy対重ねるタイプのエージェント比較

この2つ以外の選択肢も含めた全体像を知りたい場合は、Freshserviceの代替ツールのまとめと、ServiceNowとの比較をご覧ください。

では、どちらのルートを選ぶべきか

これらのインテグレーションを数多く手がけてきた立場から、判断を整理します。

• すでにFreshservice Enterpriseを利用していて、主にエージェント支援が欲しい場合。 Freddy CopilotとAI Agentを有効にしてください。すでに費用を払っているのですから、活用しましょう。セッション数と引き継ぎの体験には注意しておいてください。
• Starter、Growth、Proを利用していて、本当のデフレクションが欲しい場合。 Freddyを使うためだけにEnterpriseへアップグレードしないでください。代わりにAPI経由でエージェントを重ねましょう。ほとんどの場合、プランのジャンプアップよりも安く済み、モデルのコントロールも維持できます。
• キューの大半が反復的なTier-1(パスワードリセット、アクセス申請、ステータス確認)の場合。 これは確信度ゲート型の重ねる層にとってのスイートスポットです。あるフィンテック企業のIT責任者は、ConfluenceとSlackを裏付けとした社内Jira Service Managementデスクの前段にAIエージェントを配置し、一次対応者として機能させ、デフレクションを15%から目標の55%へと引き上げました。これが本当の成功の形です。大きく地味な部分のキューが人の目に触れる前に処理される、それが100%という魔法の数字ではありません。

どちらのルートを選ぶにせよ、ROIが現れるのは、AIが確信を持ち、わからないことについて正直であるときだけです。

避けるべきよくある間違い

• 初日にキュー全体を野放しにすること。 監督付きで始めましょう。まず下書きさせ、その下書きを確認し、うまく対応できているチケット種別から自律性を与えていきます。これがMTTRの悪化を避けるための正しい方法です。
• 薄い、あるいはPDFだらけのナレッジベースを与えること。 FreddyはPDFを読めませんし、どんなAIも取得できる情報の質に左右されます。まずは実際の、整形された記事を用意してください。社内ナレッジベースについてのガイドで、「良い」状態がどういうものかを解説しています。
• セッションメーターを無視すること。 ネイティブのFreddyでは、年間1,200セッションは活発なデスクにとって決して多くありません。超過分の見積もりに不意打ちされないよう、AnalyticsのFreddy AI Agent概要レポートを追跡してください。
• ドライランを省略すること。 使っているツールが過去のチケットでシミュレーションできるなら、必ず実行してください。ブラインドで本番投入すると、実際のユーザーの前でAIの弱点を発見することになります。

Freshserviceのキューでeeselを試す

ルート2が合いそうであれば、eesel AIはまさにこのために作られています。既存のサービスデスクにAPI経由で接続するため、Enterpriseへのアップグレードも移行も必要ありません。すでにお持ちのFreshserviceのワークフローとチケット履歴をそのまま維持できます。初日から過去のチケットとヘルプドキュメントで学習し、コントロール可能な確信度ゲートに基づいて下書きまたは解決を行い、上記の引き継ぎの罠を再現しないよう、十分なコンテキストを伴ってきれいにエスカレーションします。

eeselはヘルプデスクに接続し、過去のチケットから学習し、本番投入前に結果をシミュレーションできるようにします。

省略すべきではない部分:まず、自社の過去のチケットでシミュレーションを実行してください。顧客が1人でも関わる前に、チケット種別ごとの実際のデフレクション率がわかります。これが、数値を押し上げるAIと、静かに数値を引き下げるAIとの違いです。クレジットカード不要で無料で試せるため、決定を下す前に、自分のキューの数値を確認できます。