Freshdesk AI自動化の完全ガイド(2026年版)

「Freshdesk AI自動化」が実際に意味すること

「Freshdesk AI自動化」を検索すると、まったく異なる2つのものが混ざり合って出てきます。この2つは挙動も課金体系もまったく異なるため、まず切り分けておく価値があります。

FreshdeskはFreshworksのカスタマーサービス向けヘルプデスクで、Bridgestone、Klarna、PepsiCoを含む74,000社以上が利用しています。内部には、現在のAIブーム以前から存在する決定論的なルールエンジンと、その上に追加された新しい生成AIスイート「Freddy AI」があります。Freshdeskで「オートメーション」と言うとき、人はそのどちらを指しているのかわかりません。

私たちが使っているメンタルモデルはこうです。2つのレイヤーがあり、それを理解する一番シンプルな方法は「決定論的」対「生成的」という区分です。

最下層はルールです。チケットがこの条件に一致すれば、これらのアクションを実行する。読み取りも理解も判断もありません。バカ正直だからこそ信頼できるのです。最上層はFreddy AIで、実際にチケットを読み、何をすべきか判断します。バカ正直ではないからこそ柔軟であり、その柔軟性の対価をセッション単位で支払うことになります。

ここから両方を見ていきますが、まずは多くのチームがすでに頼りにしていながら「AI」とは呼んでいないレイヤーから始めましょう。

クラシックなオートメーションルールエンジン

Freddy以前、Freshdeskのオートメーションといえば3種類のルールを指しており、それらは今でも実際のFreshdesk運用の屋台骨です。これらはAdmin > Workflows > Automation Rulesの下にあり、それぞれ独自のタブに配置されています。Freshworksは以前この3つすべての名称を変更したため、数年前にFreshdeskを学んだ方向けに、旧名称を以下に括弧書きで示します。

3種類の主な違いは発火するタイミングであり、これこそが最も人を混乱させるポイントです。

本当に親切な点が1つあります。Freshdeskのオートメーションルールの概要によれば、「オートメーションルールで定義できる条件数に上限はなく、プランをまたいだ条件の制限もない」とのことです。好きなだけ複雑なルールを組み立てられます。組み立てるべきかどうかはまた別の話ですが。

Ticket Creationルール(旧Dispatch'r)

Ticket Creationルールは、チケットが到着した瞬間に発火します。これはいわば玄関口で、チケットを適切なグループやエージェントに割り当てたり、優先度やタイプを設定したり、メール通知を送ったり、スパムとしてマークしたりします。条件はチケットフィールド、コンタクトのプロパティ、会社のプロパティに基づき、ネストされたAND/ORロジックで構築できます。Freshdeskは、払い戻し・返品チケットを請求グループに直接ルーティングするサンプルルールまで用意しています。

ここには、ほぼ誰もが引っかかる罠が1つあります。デフォルトでは、Ticket Creationルールは「最初に一致したルールが優先」という方式で動作します。Freshdesk自身のドキュメントが警告する通り、「最初に一致したルールのみが実行されるため、ルールの順序は非常に重要」です。つまり、広範なキャッチオールルールが特定のルールより上位にあると、特定のルールは永久に実行されません。Freshworksが自社のFAQ「なぜ私のオートメーションルールが機能しないのか」に対して用意している答えは、要するに「上位のルールが先に一致した」です。歯車メニューから「一致するすべてのルールを実行」に切り替えることはできますが、デフォルトではオフになっており、見落としに気づかないと悩まされます。心当たりがあるなら、Freshdeskのチケット自動割り当てガイドで順序ロジックを詳しく解説しています。

Ticket Updatesルール(旧Observer)

Ticket Updatesルールは、既存チケット上のイベントを監視し、リアルタイムで反応します。解決済みチケットに顧客が返信したときに自動再オープンしたり、第三者がメモを追加したときにエージェントを割り当てたり、解決時にCSATアンケートを送ったり、VIP顧客が低評価を残した際にスーパーバイザーへメールしたりできるのは、このルールのおかげです。

このルールタイプを特徴づけているのはEventブロックです。誰がアクションを引き起こしたか(Agent、Requester、Collaborator、System)、そしてどのイベントを対象とするか(プロパティの変更、メモの追加、返信の送信、フィードバックの受領、さらにメール送信失敗や期限超過チケットといったシステムイベント)を指定します。Creationルールと異なり、「一致するすべてのルールが上から下まで実行される」ため、最初の一致だけで止まる落とし穴はありません。またTrigger webhookアクションもあり、これは多くのチームが外部システムへイベントを送り出す接点として使っており、Freshdesk Webhooksガイドで扱っています。

Hourly Triggers(旧Supervisor)

Hourly Triggers(Freshdeskのドキュメントでは明示的に「FKA Time Triggers」と表記)は、時間ベースの定型作業を担います。数日間解決済みのまま放置されているチケットの自動クローズ、48時間放置されたものへのエスカレーション、経過したチケットの優先度引き上げなど、キューを腐らせないための定番作業です。

見落としがちですが重要な制限が2つあります。1つ目は、これらのルールは1時間に1回スキャンするため、設定する時間しきい値は「常に1時間以上」でなければなりません。2つ目は、直近30日以内に更新されたチケットしか対象にできず、読み取れるのはチケットのプロパティのみで、コンタクトや会社のフィールドは読めません。期限超過から5分後に自動エスカレーションさせたいと思っても、Hourly Triggersではできません。これはまさに「ツールがイベントではなく時計で動く」制約であり、即座に反応するSLAを意識したオートメーションへとチームを向かわせる要因です。

シナリオオートメーション:ワンクリックのマクロ

ここまで説明したものはすべて自動で動きます。シナリオオートメーションはその手動版で、エージェントが手動でオンデマンドに実行するアクションの束です。マクロだと考えてください。

エージェントがチケットごとに「Refundとしてタグ付け、Refundsグループに割り当て、ステータスをProcessing Refundに設定」を手作業で繰り返す代わりに、シナリオならワンクリックでこの3つをまとめて実行できます。利用できるアクションは幅広く、優先度・タイプ・ステータスの設定、定型返信のプレフィル(レビュー用にステージングされるだけで自動送信はされません)、公開・非公開メモの追加、タグやウォッチャーの追加、エージェントやグループへの割り当て、メール送信などが可能です。シナリオはMore actionsから単一チケットに対して実行することも、Ticketsリストから選択範囲全体に対して一括実行することもできます。全アクション一覧はFreshdeskシナリオオートメーションガイドをご覧ください。

正直に言えば、シナリオは人間のための生産性ショートカットであり、「人手が不要」という意味でのオートメーションではありません。繰り返し発生するチケットタイプへのエージェントの対応を標準化するには優れており、定型応答とも相性が良いです。ただし、正しいシナリオを選んでボタンをクリックする人間は依然として必要で、これはチケット量がクリック作業を上回るまでは問題ありません。

チケットの自動割り当てとルーティング

ルーティングは、ルールエンジンが専用のサブシステムを持つ領域です。Freshdeskのチケット自動割り当ては、エージェントの負荷、稼働状況、割り当ての優先設定に基づいて誰が各チケットを受け取るかを決めるOmnirouteというエンジンによって動いています。

ルーティング方式は3種類あり、どれを選ぶべきかはチームの形によって変わります。

3方式すべて、チケットが届く前にエージェントがオンラインである必要があり、いずれもOmnirouteによって支えられています。比較コンテンツでよく見かける「インテリジェントなチケット割り当て」というフレーズは、たいていこの一式を指しているだけで、別の独立した機能ではありません。

早めに指摘しておきたい落とし穴があります。高度な自動ルーティングはProおよびEnterpriseプラン限定です。Growthプランでは、ラウンドロビン、負荷ベース、スキルベースルーティングは利用できず、小規模チームは通常のTicket Creationルールでルーティングするしかありません。キャパシティ自体(「エージェントが1営業時間内に対応できるチケット数」)は設定可能ですが、チャネル別のキューはFreshdesk単体ではなくFreshdesk Omniの機能です。ルーティングが自動化の主目的であるなら、現在契約しているプランではなく、実際に必要なFreshdeskの料金プランで価格を試算してください。

Freddy AI:「AI」が実際に存在する場所

ここまで説明したものはすべて決定論的です。ここからが生成AIのレイヤーです。Freddy AIはFreshworksのAIスイートで、「People-first AI」を掲げ、3つの対象ユーザーに向けた3つの製品に分かれています。

Freddy AI Agentは、顧客対応の自律解決役です。Freshworksは、チャット、メッセージング、メールを横断して最大80%の問い合わせを解決すると主張しており、Shopifyの注文更新、Stripeの返金、PayPalの取引処理といった業種別の作り込み済み「バーティカル」エージェントに加え、独自エージェントを構築できるノーコードのAI Agent Studioも備えています。これは実際にアクションを起こせる部分で、単に提案するのではなく、レコードの更新や返金処理まで行います。

Freddy AI Copilotはエージェントのワークスペース内に存在し、人間を支援します。返信案の提示、会話の要約、コンテキストスイッチ不要のリアルタイム翻訳などです。Freshworksはここでエージェントの生産性が60%向上すると謳っています。多くのチームが初日から求める自動トリアージや返信下書きのワークフローに最も近いのはこれです。

Freddy AI Insightsは経営層向けのビューで、根本原因分析を伴うプロアクティブなアラート、CSATトレンドの追跡、SLA違反の検知、そしてサポートデータについて質問できる対話型インターフェースを提供します。Freshworksはこれを「分析だけでなく、明確さ」だと表現しています。

紙の上ではこれは完成されたスイートです。自社に合うかどうかを左右する問いは、機能ではなくコストと制約に関するものなので、そこに進みましょう。

Freddy AI自動化にかかるコスト

クラシックなルールレイヤーはプランに含まれています。Freddy AIはそうではなく、その課金方法が導入者を驚かせるポイントです。

まずシート料金から。単体のFreshdeskの料金は、年間契約で3つの階層があります。

そして、このシート料金に加えてFreddy AIのアドオンが上乗せされます。

• Freddy AI Agentのセッション: ProとEnterpriseで500セッション無料(一回限り)、それ以降は100セッションごとに49ドル。「セッション」とはエンドユーザーとの一意のやり取りを指し、Email AI Agentの場合、顧客からの最初のメールから72時間の期間が1セッションで、その期間内のAIによる返信はすべて含まれます。
• Freddy AI Copilot: エージェント単位のアドオンとして販売され、日単位のパスはありません。
• Freddy AI Insights: アドオンとして提供されますが、料金は公開されていません。

つまり課金の実態は同時に動く2つのメーターです。エージェント単位のシート料金と、セッション単位のAI利用料です。これが表示価格が隠している部分であり、契約前に必ず試算することを勧める理由です。詳しい内訳はFreshdesk AI料金ガイドにまとめています。

これが問題になる理由は、セッション単位の課金が設計上予測不能だからです。忙しい月には請求額が急増し、簡単には上限を設定できません。これをチケット単位の一律料金モデルと比べると、量が増えたときの差は歴然です。これはAIエージェントと人間エージェントのコスト比較でも取り上げている緊張関係と同じであり、チームが代替手段を探し始める最も一般的な理由の1つです。

導入前に知っておくべき限界

Freddy AIは実在する製品であり、ルールエンジンは本当に高性能です。良い点を公平に評価するということは、悪い点についても正直であるということなので、友人にサポート業務全体をこの上に構築する前に知っておいてほしい制約を以下にまとめます。

• 最初の一致による罠は落とし穴です。 より上位のルールが先に一致してTicket Creationルールがサイレントに動作しないのは、「私のオートメーションが壊れている」問題の第1位であり、ルールリストが増えるほど悪化します。
• Hourly Triggersはイベントではなく時計で動きます。 1時間の最小しきい値と30日間の一致ウィンドウにより、時間的にシビアなエスカレーションはデフォルトでは粗くなります。
• ルーティングはProプランの向こう側にあります。 Growthプランの小規模チームは、ラウンドロビン、負荷ベース、スキルベースの割り当てをまったく利用できません。
• Freddyは従量課金でモデルロックされています。 シート料金に加えてセッション単位で支払い、LLMを選ぶ余地なくFreshworksのモデル上で動作します。契約前にトラフィックの一部でワークフローを試したくても、セッションメーターの設計上それはできません。
• サポートはFreddyへ誘導しがちです。 私たち自身の顧客調査では、あるFreshdeskチームがオートメーションについてFreshdeskサポートに問い合わせるたびに「Freddy AIへリダイレクトされ続けた」と語っており、しかも彼らは統合作業でAPIスロットリングにも直面していました。プラットフォームがオートメーションに関するあらゆる質問に対して自社の有料アドオンで答えるとき、選択肢は狭まります。

これはFreshdeskが悪いヘルプデスクだという意味ではありません。堅牢だが柔軟性に欠けるルールエンジンと、柔軟だが従量課金のAIアドオンが混在し、その継ぎ目が見える自動化の物語を持つヘルプデスクだということです。AIについてさらに詳しく知りたい方は、Freshdeskの率直なレビューとFreshdesk AIレビューをご覧ください。

eeselが当てはまる場面

ルールレイヤーが硬直的すぎて、Freddyが従量課金すぎると感じるなら、中間の道があります。Freddyのようにチケットを読み取るAIレイヤーでありながら、自社の条件で動作し、すでに使っているFreshdeskの中で動くものです。

それが私たちがeeselを構築した理由です。壊れやすいif-this-then-thatルールを書いたり、ブラックボックスのモデルにセッション単位で支払ったりする代わりに、平易な言葉でeesel AIエージェントに指示するだけです(例:「Tier 1の払い戻し質問を処理し、500ドルを超える場合は人間にエスカレーションする」)。すると、受信する各チケットを個別に読み取り、返信を作成または送信し、タグ付けとルーティングを行い、エッジケースをエスカレーションします。ルールの順序に依存しないため順序の罠はなく、1社のベンダーのLLMに縛られないためモデルロックインもありません。

Freshdeskチームにとって特に重要になりがちな点がいくつかあります。

• **Freshdeskの中で動作します。**総入れ替えではなく、eeselは100以上の統合の1つとして、すでにエージェントが使っているヘルプデスクの中に収まります。
• **従量課金、メーターは1つだけです。**eeselはタスクごとに課金され(解決したチケット1件あたり約0.40ドル)、シート料金もセッションパックもないため、請求額は人員数とAI利用量の掛け算ではなく、実際に行われた作業を反映します。詳細なモデルは料金ページに記載しています。
• **まずは一部だけで展開できます。**月間1,000件のチケットのうち200件をeeselに通し、結果を確認してから拡大する。この「一部だけ試してから信頼する」というアプローチこそ、セッション単位の課金では難しくなるものです。

これは魔法ではなく、人間のチームを完全に置き換えるふりもしません。ただ、Freshdeskのキューのうち繰り返し発生する60〜70%を自動化するという特定の仕事に関しては、チケットを読み取るモデル非依存のエージェントの方が、壊れやすいルールの積み重ねと従量課金のブラックボックスの組み合わせより優れています。私たちの調査で見つかった、年間5,000件から20,000件へとチケット数を拡大しているイタリアのメールセキュリティ企業は、Freshdeskを検討する中で、正面比較のテストでeeselがFreddy AIより精度が高いと評価しました。

「最初の月で、eeselはTier 1の依頼の73%を解決しています。私たちのチームは7日間のトライアル中に導入し、すぐに成果を上げました。このプラットフォームには、チケットのタグ付け、割り当て、ステータス更新のオートメーションまで含まれています!」

Kim Simpson、Gridwise(G2でeeselをレビュー)

eeselを試す

ここまで読んだあなたは、おそらく人員数の増加ペースを上回る速さで拡大しているFreshdeskのキューを自動化しようとしているはずです。eeselは、既存のFreshdeskに自律型AIエージェントを導入し、初日から過去のチケットとヘルプ文書から学習し、ルールを1つも書かずセッションメーターを気にすることもなく、繰り返し発生するチケットの解決とルーティングを始めます。

ここでの決定的な違いは、平易な英語で指示を出し、実際のチケット履歴を使って本番投入前にシミュレーションでき、実際に処理したチケットの分だけ料金を支払えばよいという点です。eeselを試すのは無料で、月間50,000件以上のFreshdeskチケットを処理しているチームがどう活用しているかはカスタマーサービスAIガイドをご覧ください。