2026年版:Freshdeskチケットを自動化する方法 実践ガイド

Freshdeskでチケットを自動化する4つの方法

設定を触る前に、実際に何が用意されているのかを知っておくと役立ちます。Freshdeskは自動化を4つの明確なレイヤーに積み重ねており、「一度設定したら放っておける」ものから「自律的に読んで返信するエージェント」まで幅があります。

• クラシックオートメーションルールは「Xが起きたらYを行う」という条件とアクションのエンジンです。無料で、少なくとも部分的にはすべてのプランで利用でき、トリアージとルーティングという地味だが重要な作業を担います。
• シナリオオートメーションは手動マクロです。エージェントが一度クリックすると、複数のアクションがまとめてチケットに実行されます。
• Omnirouteは、ラウンドロビン、負荷、スキルのいずれかに基づいてどのエージェントがどのチケットを受け取るかを決めるルーティングの中枢です。
• Freddy AIは、顧客のメッセージを読み取り、人手を介さずに解決または返信のドラフトを作成する自律的なレイヤーです。

この順序には意味があります。ルールとシナリオはコストがかからず、驚くほど多くの雑務を取り除いてくれるので、まずそこから始めましょう。AIは費用が発生し始める領域なので、それに見合う効果があるチケットのために取っておきます。このガイドの残りの部分では、各レイヤーをこの順序で解説していきます。

まずはクラシックオートメーションルールから

このレイヤーは無料であり、繰り返し発生するトリアージ業務の大部分を担うため、初日に設定しておく価値があります。すべてはAdmin > Workflows > Automation Rulesの下にあり、Freshdeskはこれを3種類のルールに分けており、それぞれ独自のタブになっています。

始める前に名称について一点補足します。古いFreshdeskのチュートリアルを読んだことがあれば、Dispatch'r、Supervisor、Observerという用語を見かけるかもしれません。これらは廃止されています。現在の名称はTicket Creation、Ticket Updates、Hourly Triggers(最後のものはドキュメント上で文字通り「FKA Time Triggers」と表記されています)なので、もう存在しないメニューを探し回らないようにしましょう。

Ticket Creationルール(到着時のトリアージ)

Ticket Creationルールはチケットが届いた瞬間に実行されます。これがいわば入口で、適切なグループやエージェントへの割り当て、優先度やタイプの設定、自動返信の送信、明らかなスパムのマークなどを行います。チケットフィールド、連絡先のプロパティ、会社のプロパティを対象に、入れ子になったAND/ORブロックで条件を組み立てられます。Freshdeskは返金・返品チケットを課金グループへ振り分けるサンプルルールも用意しているので、白紙から作る代わりに複製して編集することもできます。

ここで最もよくある、そしてほぼ全員がつまずく落とし穴を紹介します。デフォルトでは、最初に一致したTicket Creationルールだけが実行されます。「なぜルールが動かないのか」というFreshdesk自身のトラブルシューティングの答えは、たいてい上位のルールが先に一致していたというものです。一致するすべてのルールを実行したい場合は、ルール一覧の上にある歯車アイコンをクリックし、「Execute all matching rules」に切り替えてください。ルールの順序は意図的に決め、最も具体的なものを上位に置きましょう。

Ticket Updatesルール(その後の動きに反応する)

Ticket Updatesルールは既存のチケットに対するイベントを検知して反応します。このルールタイプ特有のEventブロック、Conditions、Actionsで構成されます。典型的な使い方としては、顧客が返信したら解決済みチケットを再オープンする、チケットが解決したらCSAT調査を送る、VIP顧客が低評価をつけたらスーパーバイザーにメールする、などです。

作成ルールとは異なり、こちらには「最初の一致のみ」という設定はありません。一致するすべての更新ルールが上から下まで実行されます。また、Trigger webhookアクションもあり、これは外部システムへイベントを送り出すための逃げ道になります。知っておくべき点として、更新ルールは無料プランでは利用できず、Growthから利用可能です。

Hourly Triggers(時間ベースのクリーンアップ)

Hourly Triggersは1時間ごとにすべてのチケットをスキャンし、ある状態のまま長時間放置されているものに対してアクションを実行します。たとえば、48時間対応されていないチケットをエスカレーションする、古くなったチケットの優先度を高に上げる、といった具合です。

ルールを作る前に覚えておくべき3つの制限があります。これらは、他の点では正しいルールを静かに壊してしまうことがあるためです。

• 1時間に1回しか実行されないため、時間のしきい値は1時間以上に設定する必要があります。
• 過去30日以内に更新されたチケットのみが対象になります。
• チケットのプロパティのみを対象とし、連絡先や会社のフィールドは対象外で、件名、本文、依頼者のメールアドレス、CC、タグ、添付ファイルに関する条件は使えません。

この3種類のクラシックルールを組み合わせれば、多くの人が"チケット自動化"という言葉で思い描く作業のほとんどをカバーできます。より重いトリアージロジック(キーワードではなく意図で振り分けるようなもの)になると、Freshdeskの限界が見えてくるところでもあり、そこでAIチケット分類やより高度なサポートチケットトリアージが不足を補うことになりがちです。

シナリオオートメーションで繰り返しのアクションをまとめる

ルールは自動的に実行されます。シナリオオートメーションはその逆で、エージェントがクリックして実行する手動マクロです。エージェントが毎回チケットに「Refund」というタグを付け、Refundsグループに割り当て、ステータスを「Processing Refund」に手動で設定する代わりに、これらの手順を1つのシナリオにまとめられます。

Admin > Agent Productivity > Scenario Automations > New Scenarioの下で作成し、順序付けられたアクションを追加します。優先度、タイプ、ステータスの設定、缶詰め返信の事前入力(エージェントが確認するためのもので、自動送信はされません)、公開・非公開メモの追加、割り当て、タグ付け、スパムとしてマークすることまで可能です。表示範囲は自分だけ、自分のグループ、あるいは全エージェントに設定でき、シナリオは単一のチケットに対して実行することも、選択した多数のチケットに一度にまとめて実行することもできます。これが月曜朝のバックログ処理で実際に時間を節約できる部分です。

マクロがチームの業務の中心であるなら、より詳しいマクロテンプレートとマクロアクションのガイドも読む価値があります。Ticket Updatesルールと同様、シナリオも無料プランではなくGrowthプランから利用可能です。

Omniroute Routingでチケットを自動的に振り分ける

どのエージェントがチケットを受け取るかを決めるのは、それ自体が独立した自動化の課題であり、FreshdeskはそれをルーティングエンジンであるOmnirouteで解決します。Advanced Automatic Routingを有効化することでグループごとにオンにし、その後方式を選択します。

3つの方式はいずれも各エージェントのキャパシティ(同時に保持できるチケット数)を尊重し、オンライン状態のエージェントにのみ割り当てます。最初に伝えておきたい注意点は、OmnirouteはProとEnterpriseのみの機能だということです。Growthでは、代わりにTicket Creationルールでルーティングを行います。ルーティングが自動化の主な目的であれば、チケットルーティング自動化ガイドがヘルプデスク全般に通用するパターンを解説しています。

繰り返しの返信はFreddy AIに任せる

ルール、シナリオ、ルーティングはチケットを動かしますが、回答はしません。それを担うのが、FreshworksのAIスイートであるFreddy AIで、3つの要素に分かれています。Freddy AI Agent(顧客対応の自律的な解決)、Freddy AI Copilot(人間のエージェント向けの返信提案と要約)、そしてFreddy AI Insights(リーダー向けの分析)です。

Freshworksによると、AI Agentはチャット、メッセージング、メールにおいて最大80%の問い合わせを解決し、平均解決時間は2分未満だとしています。Freddy AIの本音レビューでは、こうした見出しの数字が実際にどこまで通用するのかを掘り下げています。自律的な部分はノーコードのAI Agent Studioで設定し、構築はわかりやすい6ステップのフローに従います。

1. エージェントを作成する:AI Agent Studioで名前、アバター、主要言語を設定します。
2. 機能を構築する:ナレッジ(ソリューション記事、ファイル、URL、カスタムQ&A)を追加し、注文キャンセルなどのタスク用にワークフローを構築し、業務の背景情報とカスタム指示を平易な言葉で記述します。
3. テストする:公開前に実際のシナリオをシミュレーションします。
4. プレビューしてリンクを共有する:エージェントライセンスを持たない関係者も試してフィードバックできるようにします。
5. チャネルにデプロイする(Web Chat、WhatsApp、Facebook、Instagramなど)。
6. パフォーマンスを分析する:Analyzeタブから、エンゲージメント指標とチケットログを確認できます。

読み込む前に知っておきたいナレッジの制限がいくつかあります。ボットが学習できるのは最大200ファイル(それぞれ最大35MB)とエージェントあたり10のURLまでで、読み取れるのは静的なテキストのみで、動画やスクリーンショットは対象外です。詳しい設定手順については、Freddy AIのナレッジベースと会話型ナレッジベースのガイドがステップごとに解説しており、返信提案のガイドはCopilot側をカバーしています。

Freddy AIの実際のコスト

ここでチームが驚くことが多いので、正確に説明する価値があります。Freshdeskのプランはシート単位の料金ですが、Freddy AI Agentはそれに加えてセッション単位で課金されます。その費用を単純に人を雇う場合と比較検討しているなら、AIエージェントと人間のエージェントのコスト比較が有用な確認材料になります。

それに加えて、実際に負担として感じるFreddy AIの料金があります。

• Freddy AI Agentのセッション: Growth以上のプランに500セッションが(一度だけ)含まれ、その後は追加100セッションごとに49ドルです。セッションとはエンドユーザーとの一意のやり取りを指し、Email AI Agentの場合は顧客の最初のメールから始まる72時間の期間で、その期間内のすべてのAI返信が1セッションとして数えられます。
• Freddy AI Copilot: エージェント単位の別料金アドオンで、1日単位のパスはありません。

セッション制はコミュニティの議論で最も多く指摘される摩擦点です。AIが実際にチケットを解決したかどうかにかかわらずセッションが消費されるうえ、セッション単価は量が増えると急速に上がっていくためです。あるサポート運用リーダーは、実際に試した後こう述べています。

"Freshdesk Freddy: for early stage teams that want something simple, it covers the basics auto assignment, suggested replies, FAQ deflection. It's reliable and affordable, nothing crazy."

これはr/AgentsOfAIからの逐語的な引用であり、公平な要約と言えます。基本的な用途には十分だが、それ以上を求めると料金がかかる、というものです。チーム規模別の詳しい計算については、エージェントごとの料金と解決件数ごとの料金の内訳をご覧ください。

Freshdesk純正の自動化が限界に達するところ

ここは、ほとんどのセットアップガイドが省略している部分です。ルールエンジンとFreddyはかなり遠くまで連れて行ってくれますが、基本を超えて先に進むと、決まって3つの壁にぶつかります。これらは、本番環境で発見するのではなく、あらかじめ計画しておく価値があります。

**ルールは教えたことしか知りません。**すべての条件は自分の手で書いたものです。これは「優先度がurgentならtier 2に割り当てる」のような場合には完璧に機能しますが、意図の判断となると通用しません。キーワードルールでは請求に関する不満と請求に関する質問を区別できません。だからこそ、ルールが読み取れない乱雑な自由記述のチケットには、チームはカスタマーサービス向けAIを求め続けるのです。

**Freddyの精度は複雑なチケットで落ちます。**実際のユーザーの報告で繰り返し語られるのは、FAQ形式の質問には強いが、ニュアンスのある内容には弱いという点です。ある運用担当者は、Freshdesk内でAIをテストした様子を次のように語っています。

"We tested an ai integration in freshdesk and had almost the exact same experience. it worked for very simple tickets but anything slightly complex got misclassified. agents ended up spending more time fixing errors than before, so we had to rethink our approach."

これはr/AiAutomationsのスレッドからの引用で、同じパターンが繰り返されます。自信満々だが間違った回答、CSATの低下、そしてAIがドラフトのみを作成し人間が送信する「アシストモード」への切り戻し、という流れです。

**AIが対応する範囲を細かく制御できません。*これが実際の導入を停滞させる要因です。チームは初日からAIにすべての返信をさせたいわけではなく、まずは安全なチケット種別から始めたいと考えています。私たちが話を聞いたあるDTCサプリメント企業のCXリードは、要望を一言でまとめてくれました。AIが100%の質問に回答することは決してないので、彼らが求めていたのは"an AI who is only handling the tickets that it's confident to handle, and all the other ones, leave them alone."*だったのです。この信頼度に基づくスコープ設定こそ、ハードコードされたセッション型ボットが苦手とする部分です。

Freddyをそこまで厳密にスコープできない場合、あるいはFreshdeskのAPIスロットリングやFreddyへ話を戻し続けるサポートチームが障害になる場合、それは通常、同じFreshdesk上で動作するサードパーティのAIヘルプデスクエージェントを検討すべきタイミングです。これはまた、Freshdesk AIの無料代替案やFreshdesk向けAI自動化アプリのクラスターが多くの検索トラフィックを集める理由でもあります。

あなたのFreshdeskの上でeeselを試す

そうした壁にぶつかったなら、eeselは、すでに運用しているFreshdeskの内部に直接組み込めるように作られています。移行の必要はなく、新しい受信箱を学ぶ必要もありません。届いたチケットを読み取り、過去のチケットやヘルプ記事から学習し、返信をドラフトまたは完全に解決し、例外的なケースはエスカレーションするAIチームメイトとして接続します。

Freddyを試した後に最も重要になりがちな2点は、まさに上で挙げた壁そのものです。1つ目はコントロールです。AIがどのチケット種別を処理し、どれには手を付けないかを自分で決められるので、狭く始めて信頼できるようになったら範囲を広げられます。2つ目は予測可能な料金です。eeselは解決したチケット1件あたり0.40ドルの固定料金で、席数課金もなく、役に立ったかどうかにかかわらず消費されるセッションもなく、まずは自社のチケット量の一部だけをルーティングして始めることもできます。

スケールもします。Design.comはFreshdesk上のeeselを通じて月間50,000件以上のチケットを、1,000件以上のヘルプ記事で学習させたマルチエージェント構成で処理しています。また、直接比較した評価でも精度の面で優位性を示しており、Freshdeskを利用するイタリアのあるメールセキュリティ企業は、独自のテストでeeselがFreddy AIよりも正確だったという結果を得ています。

まずは広い視野で全体像を把握したいなら、ベストなカスタマーサービスAIと最も安いヘルプデスク向けAIアプリのまとめが位置づけを整理してくれます。その上で、自分のFreshdeskの受信箱で無料で始めてみてください。