Freshdeskの自動化ルール:仕組みと設定方法(2026年)

Freshdeskにおける「自動化ルール」の本当の意味

Freshdeskの管理画面で「automations」を探して見て回ったことがある人なら、名前がネット上のチュートリアルの半分と合っていないことに気づいたはずです。それはFreshdeskが3つの従来のルールタイプをひっそりと改名したからです。旧来のDispatch'r、Observer、Supervisor(またはTime Triggers)はUIから姿を消しました。現在表示されるのはTicket Creation、Ticket Updates、Hourly Triggersで、すべてAdmin > Workflows > Automationsの下、それぞれ独自のタブに収まっています。

内部の仕組みは変わっていません。すべてのルールは条件(Xが真のとき)とアクション(Yを実行する)から構成されており、Freshdesk自身の自動化ルールの概要でも、タイプは正確に3種類あると確認されています。ルールごとに違うのは、いつ実行される機会を得るかです。

多くの人が「Freshdeskの自動化ルール」と言うときに指しているのはこの層で、これは後述する2つの隣接機能、シナリオオートメーション(手動マクロ)と自動チケット割り当てとは別物です。プラットフォームの自動化関連全体を見渡したい場合は、Freshdesk自動化の完全ガイドで全体像をつかめます。この記事ではルールエンジン自体に焦点を絞ります。

Freshdeskの自動化ルール、3つのタイプ

各ルールが何をするかではなく、いつ実行されるかで考え始めると、全体のモデルがすっと理解できるようになります。まずはタイミングを一目で見てみましょう。

1. Ticket Creationルール(旧Dispatch'r)

これらはチケットが作成された瞬間に実行されるため、トリアージの最前線となります。Freshdeskのチケット作成のドキュメントによると、作成ルールはチケットをグループやエージェントに割り当てたり、ステータス・優先度・タイプなどのプロパティを設定したり、メール通知を送信したり、チケットを削除してスパムとしてマークしたりできます。条件はチケットフィールド、連絡先プロパティ、会社プロパティに基づいて構築でき、AND/OR演算子とネストされたブロックが使えます。

ここにほぼ全員がつまずく設定があります。デフォルトでは最初に一致したルールのみが実行されます。Freshdesk自身のドキュメントでも「ルールの順序は非常に重要で、最初に一致したルールのみが実行される」と警告されています。つまり、発火すべきルールが発火しない場合、原因はたいてい上位のルールが先に一致してチェーンを止めていることです。これを変更するには、ルール一覧の上にある歯車アイコンをクリックし、「Execute all matching rules」を選択します。

新しいチケットをエージェントが目にする前に振り分けたいときはこのルールタイプの出番です:請求関連の質問を経理グループに回す、VIP企業からのチケットを高優先度に引き上げる、受付確認の自動応答を送るなど。これは従来型エンジンがトリアージに最も近づける方法ですが、指定したフィールドでしか振り分けられず、チケットが実際に何についてのものかは判断できません。

2. Ticket Updatesルール(旧Observer)

作成ルールが最初に一度だけ発火するのに対し、チケット更新ルールは「指定したイベントを常時リッスンし」、条件と照合してからアクションを実行します。これは反応型のレイヤーで、顧客が返信したら解決済みチケットを再オープンする、第三者がメモを追加したらエージェントを割り当てる、チケットが解決したらCSATアンケートを送る、VIPからの低評価があればスーパーバイザーにメールする、といったことができます。

更新ルールを特徴づけているのは、他の2つのルールタイプにはない上部のイベントブロックです。これは2つの部分から成ります:「いつのアクションによって発生したか」(エージェント、依頼者、いずれか、共同作業者、またはシステム)と「これらのイベントのいずれかを含む」(プロパティの変更、メモの追加、返信の送信、フィードバックの受信、期限超過チケットなどのシステムイベント)。その下は通常どおり条件とアクションが続きます。

作成ルールと異なり、ここには最初の一致のみを実行するトグルはありません:「一致するすべてのルールが上から下へ実行されます」。更新ルールにはTrigger webhookアクションもあり、これはFreshdeskを外部システムに拡張する方法で、Freshdesk Webhookガイドで解説している仕組みと同じであり、センチメント低下時にSlackに通知するような便利なレシピの基盤にもなります。1点注意:更新ルールはFreeプランでは使えず、Growth以上が必要です。

3. Hourly Triggers(旧Time Triggers)

3つ目のタイプは時間の経過を扱うもので、FreshdeskのHourly Triggersのドキュメントでも「FKA Time Triggers」だと明記されています。これらは起きていないことを捕捉するルールです:放置されているチケット、SLA違反が近いチケット、解決済みだが未クローズのチケットなど。典型例は、48時間放置されたチケットを優先度を上げてスーパーバイザーに通知することでエスカレーションするものです。

落とし穴は名前の通りです。Hourly Triggersは1時間に1回だけ実行されるため、設定する時間しきい値は「常に1時間以上」である必要があります。利用前に知っておくべき制限がもう少しあります:過去30日以内に更新されたチケットのみを対象とし、チケットのプロパティのみで動作し、連絡先や会社のプロパティ、メールの件名・本文・依頼者のメールアドレス・CC・タグ・添付ファイルに対する条件は使えません。時間ベースのルールを設定して遅延を感じたことがあるなら、これが理由です。回避策については専用のFreshdeskタイムトリガーガイドで詳しく解説しています。

Freshdeskの自動化ルールをステップバイステップで設定する方法

必要なタイプがわかれば、構築の形は3つとも同じです:任意のイベント、いくつかの条件、そして1つ以上のアクション。

ここでは、多くのチームがまず取り組むTicket Creationルールの手順を紹介します:

1. Admin > Workflows > Automationsに移動し、Ticket Creationタブを開きます。
2. New Ruleをクリックし、後で見てわかる名前を付けます(「Rule 7」より「Route billing to Finance」のほうがいい)。
3. 条件を設定します。例:チケットの件名に「refund」が含まれる OR タイプが「Billing」。より複雑な条件にはAND/OR演算子とネストされたブロックを使います。
4. アクションを設定します:Financeグループに割り当てる、優先度をHighに設定する、通知を送るなど。複数を積み重ねることもできます。
5. **実行順序を確認します。**ルールをドラッグして位置を調整し、歯車アイコンから最初の一致のみか、すべての一致かを選びます。このステップひとつで、「なぜルールが発火しないのか」という悩みの大半を防げます。
6. 保存し、本番で信頼する前に実際のチケットでテストします。

実践的な習慣がいくつかあると、この作業はぐっと楽になります。Freshdeskには事前構築済みのサンプルルール(返金チケットを請求グループに振り分けるものなど)が用意されており、ゼロから作る代わりに参考にしたり複製したりできます。また、すべてのルールには過去7日間で何件のチケットに影響したかを示すルールごとの統計が表示され、ルールが実際に機能しているかを最速で確認できます。ルール内の条件数に上限はないため、細かく指定することもできますが、すべての条件はあなたが事前に考えておく必要がある点は忘れないでください。

その他の自動化レイヤー:シナリオとルーティング

3つのルールタイプに注目が集まりがちですが、2つの隣接機能も裏で多くの仕事をこなしており、自動化ルールと混同されることがよくあります。

シナリオオートメーションは手動版の兄弟のような存在です。条件で発火する代わりに、エージェントがチケットに対して実行するワンクリックのアクションの束で、マクロ層です。チケットをRefundとタグ付けし、Refundsグループに割り当て、ステータスをProcessingに設定する、という作業を毎回手作業で行う代わりに、それらを1つのシナリオにまとめてワンクリック(または選択した複数チケットに一括)で実行できます。これらはAdmin > Agent Productivity > Scenario Automationsにあり、それぞれをプライベート、グループ全体、または全員と共有のいずれかに設定できます。詳しくはFreshdeskシナリオオートメーションガイドで解説していますが、以下のスクリーンショットはシナリオが持てるアクションの幅を示しています。

自動チケット割り当てはもう一つの機能です。FreshdeskのOmnirouteエンジンによって動作し、エージェントの負荷、稼働状況、スキルに基づいて誰がチケットを受け取るかを決めます。ルーティング方法は3つあります:ラウンドロビン(循環式で容量を考慮)、負荷ベース(各エージェントの忙しさに応じて割り当て)、スキルベース(言語や製品の専門性に一致させる)。重要な注意点として、Advanced Automatic RoutingはProとEnterpriseのみで、より高度な自動割り当てオプションは安価なプランでは利用できません。

自動化ルールにはどのFreshdeskプランが必要?

すべての自動化がすべてのプランで使えるわけではなく、これが「この設定がなぜ見つからないのか」という混乱の多くの原因になっています。Freshdeskの料金プラン全体でどう組み合わさっているかは以下の通りです。(数値はスタンドアロンのFreshdeskプランを反映しており、価格は年払い・エージェント単位です。)

要点はこうです:作成時の基本的なトリアージは無料で使えますが、反応型・時間ベース・負荷対応の機能には少なくともGrowthプランが必要で、最も賢いルーティングはProとEnterpriseに限定されています。アップグレードする価値があるか迷っているなら、Freshdeskプラン比較とFreshdeskの正直なレビューの両方でトレードオフを詳しく解説しています。

Freshdeskの自動化ルールが行き詰まるところ

自動化ルールが得意なのはただ一つ、書いた条件が真であるときに、指示したとおりのことをすることです。それは同時に限界でもあります。すべてのルールは、チケットがどんな見た目になるかについて事前に立てた推測であり、チケットはめったにその通りには動きません。

3つの壁が繰り返し現れます:

• **ルールは条件に一致するだけで、意味には一致しません。**作成ルールは件名に「refund」を含むチケットを振り分けられますが、「お金を返してほしい」と書く顧客はそのまますり抜けてしまいます。結局、際限なく長くなるキーワードリストを維持することになり、常に一つの言い回しの差で見逃してしまいます。
• **時間ベースのロジックは粗い。**Hourly Triggersは1時間に一度しか動かないため、「30分以内に返信がなければエスカレーション」という表現は不可能です。動きの速いキューにとって、1時間は永遠のようなものです。
• **実際には何も答えられません。**ルールはルーティング、タグ付け、優先度の設定、定型応答の事前入力はできますが、質問を読んで本当の回答を書くことはできません。その作業は依然として人間の仕事です。

これは取引の現場でも感じてきたことです。ある評価の中で、あるFreshdesk顧客は新しい自動化ルールを既存のルール群とうまく共存させられず、ルール同士が実行順序を巡ってぶつかり合い、サポートに問い合わせるたびにFreshdesk自身のFreddy AIへと繰り返し誘導されていました。問題はルールが悪いということではなく、理解を近似しようとしてif-thenロジックを積み重ねていくと、いずれその重みで崩れてしまうということです。これはFreshdeskのAI自動トリアージや意図によるタグ付けの記事でも繰り返し触れているのと同じギャップです。システムにフィールドを照合させるのではなく、チケットを理解させたいと思った瞬間、あなたはすでにルールエンジンを卒業しているのです。

ルールが届かないチケットにはeeselを

ここまで読んだなら、おそらくルーティングルールはすでに整えていて、ルールでは解決できないチケットの山を前に立ち尽くしているはずです。それこそeesel AIが作られた理由です。既存のFreshdesk(そしてSlack、メール、Shopify、100以上の他のツール)の上に乗り、過去のチケットやヘルプ文書から数分で学習し、顧客が実際に意図したことを読み取ることで、キーワード一致のルールには決してできなかった返信の下書き作成、あるいは完全な解決までをこなします。

Freshdeskのルールと並べたとき重要なのは、AIがどのチケットに触れるかをあなたがコントロールし続けられる点です。オールオアナッシングの切り替えではなく、チケットタイプや確信度でスコープを絞れるため、繰り返しの多い質問はAIに任せ、エッジケースはチームに残せます。「AIにすべての自動返信を任せたくない」という、多くの導入を止めてしまう不安に応える形です。料金は1解決あたり定額0.40ドルで、席数課金は一切なく、自分で設定した支出上限があります。既存のFreshdeskを置き換えるのではなく上に重ねる形なので、移行のスケジュールも不要です。

50ドル分のクレジットとカード登録なしで始められます。実際のチケットに向けて試し、1セントも使わないうちにどこまで対応できるか確かめてください。eeselを試すなら、すでに構築したFreshdeskのルールはそのまま活かしつつ、eeselがルールの手が届かない部分をすべてカバーします。