ヘルプデスクのマクロを管理する方法:実践的な2026年版ガイド

マクロが実際に行うこと

マクロとは、エージェントがチケットを作成または更新する際に手動で適用する、あらかじめ用意された返信やアクションです。この「手動で適用する」という部分こそがマクロのアイデンティティそのものであり、ヘルプデスクの自動ルールとの決定的な違いです。

ワンクリックで、Zendeskのマクロは公開返信や内部メモの追加、チケットフィールドの更新、タグの追加・削除、担当者の変更、件名の設定、フォロワーの追加、ファイルの添付、サイドカンバセーションの開始まで行えます。Zendeskのマクロに関するドキュメントにその通り記載されています。覚えておくべきなのは、マクロにはアクションしか含まれず、条件は含まれないという点です。何もチケットを評価してくれるわけではなく、いつ適用するかはエージェント自身が判断します。

これは初心者が見落としがちな点なので、簡単な表にまとめておく価値があります。マクロ、トリガー、オートメーションは従来型のビジネスルールスタックを構成する3つの要素であり、それぞれ異なる役割を担っています。

よくあるチケットに対して「この返信を送りかつステータスをsolvedにしかつタグを付ける」をしたいなら、それはマクロです。「48時間返信がなければXをする」をしたいなら、それはオートメーションです。この2つを混同することが、Zendeskのワークフローが予測不能に感じられる最も多い原因です。

マクロの管理が作成よりも難しくなる理由

ここに落とし穴があります。マクロを作るのは2分で終わり、それだけで生産的に感じられるため、チームは大量に作ってしまいます。一方、マクロを管理するには継続的な規律が必要で、雑用のように感じられるため、ほとんど誰もやりません。結果は予想通りです。ライブラリは一方向にしか成長しません。

マクロの肥大化を見た目以上に深刻にしている構造的な要因が3つあります。

• ネイティブの完全な使用状況レポートが存在しない。 Zendeskにはマクロの使用頻度を示すダッシュボードが標準で用意されていません。よくある回避策は、追跡用タグをマクロのアクションとして追加し、Zendesk Exploreでタグ別に集計することです。コミュニティが開発したマクロ分析ダッシュボードアプリが数百件の閲覧数を集めているという事実自体が、チームがどれだけこれを求めていて、標準機能ではどれだけしか得られていないかを物語っています。
• 上限が高すぎて溜め込みを許してしまう。 Zendeskはアカウントあたり5,000個の共有マクロという上限を設けています。これはチームが現実的に使える量をはるかに超えているため、整理しようという自然なプレッシャーが働きません。
• 古くなったマクロは、誰かが送信するまで見えない。 価格情報が古かったり、リンク切れがあったりするマクロは、誰かが顧客に適用するまでリストの中で静かに存在し続けます。そしてそのときには、あなたの名前入りの誤った回答になってしまっています。

このことは、マクロの管理画面で直接確認できます。実際のライブラリでは「使用状況(過去7日間)」列がゼロだらけになっているのです。

このガイドの残りの部分は、その列を正直な状態に保つための規律についてです。

ステップ1:役割を果たすマクロを作る

マクロの管理は作成の段階から始まります。うまく作られたマクロは、その後のメンテナンスがずっと少なくて済みます。

Zendeskでは、管理センター > ワークスペース > エージェントツール > マクロ > マクロを作成から作成します。マクロがその存在意義を発揮するか、それとも単なる雑物になるかを分けるルールがいくつかあります。

• 返信内容とフィールドの変更をひとつにまとめる。 ステータスを設定するだけのマクロは、マクロとして半分しか機能していません。本来の目的は、コメントを追加してステータスを設定することを(さらにタグや優先度も含めて)ワンモーションで行うことです。マクロを作るなら、その仕事を最後までやらせましょう。
• プレースホルダーは慎重に使う。 {{ticket.requester.first_name}} のようなプレースホルダーは返信をパーソナライズします。ひとつ本当の落とし穴があります。問題チケットやインシデントチケットでは、プレースホルダーをバックスラッシュでエスケープしてください(\{{ticket.requester.first_name}})。そうすることで、送信時にリンクされた各チケットごとに正しく表示され、最初のリクエスターの名前が全員に漏れてしまうことを防げます。
• プレーンテキストのフォールバックを用意する。 コメントエディターはリッチテキスト、インライン画像、最大5つの添付ファイルに対応していますが、SMSやモバイルなどのチャネルは対応していません。「プレーンテキストのフォールバックを含める」にチェックを入れておけば、マクロがどのチャネルでも問題なく読めるようになります。

実際の文言については、白紙の状態から書き始めないでください。上位の問い合わせ種別に対応した確かなマクロテンプレートのセットと、それぞれがどのマクロアクションをまとめるべきかの明確な指針があれば、そこまでの道のりの大半は終わっています。マクロを最も活用しているチームは、上位10〜20種類のチケットタイプ向けに作成したらそこで止め、あらゆるエッジケースに対してひとつずつ作ることはしません。

ステップ2:エージェントが実際に見つけられるように整理する

チケット対応の場で誰も見つけられないマクロは、存在しないのと同じです。見つけやすさを左右する要素は2つ、命名とカテゴリー分けです。

命名については、ひとつの形式を決めて、チーム全体でそれを守りましょう。[チーム] アクション - コンテキスト(例:[Support] クローズ - 再現不可)のような形式にすると、エージェントが名前の先頭を入力するだけで即座に絞り込めるため、検索が速くなります。ここでは工夫よりも一貫性がものを言います。

カテゴリー分けについて、Zendeskにはうまい仕掛けがあります。マクロのタイトルにカテゴリーの階層をコロン2つ(::)で区切って入れるのです。Assign to::me::question のようなタイトルは入れ子になったカテゴリーパスを作り、200個の名前がフラットに並ぶよりもはるかに一覧しやすくなります。

正しく設定すれば、エージェント向けのメニューは再び使いやすくなります。エージェントが最もよく使うマクロが上部に表示され、カテゴリー分けされたマクロは終わりのないスクロールではなく、すっきりとした階層をたどるだけで見つかります。

知っておく価値のある整理のレバーがもう少しあります。手動並べ替えをオンにしてマクロを好きな順序にドラッグしたり、管理画面のリストをステータス、公開範囲、カテゴリーでフィルタリングしたり、GrowthおよびProfessionalプランでは使用状況で並べ替えたりできます。大規模なライブラリを管理しているなら、カテゴリー別にマクロを整理する方法についての詳細な解説で、設定全体をカバーしています。そして個人用と共有の公開範囲を早い段階で正しく設定することも重要です。管理者が優れた個人用マクロを共有マクロに複製できるようにしておくことが、良い文言をチーム全体に広める方法だからです。

ステップ3:スケジュールに沿って監査し、削除する

これは誰もが飛ばしてしまうステップですが、実際にライブラリを健全に保っているのはこのステップです。マクロをコードのように扱い、定期的にレビューして使われなくなった枝を切り落としましょう。

1時間程度で終わる四半期ごとのチェックで、ほとんどのチームには十分です。

1. 使用状況を取得する。 マクロページを使用状況で並べ替えるか、設定済みならタグベースのExplore集計を実行します。過去90日間で使用回数がゼロのものは削除候補です。
2. 無効化してから削除する。 Zendeskではすでに無効化されたマクロしか削除できず、削除は元に戻せないため、まず無効化しておくのが安全な保留策です。1サイクルの間に誰からも苦情が出なければ、削除します。
3. 重複を統合し、古い文言を修正する。 ほぼ同じことを言っている2つのマクロはひとつにまとめるべきです。ついでに、すべてのマクロでリンク切れや古い価格情報がないか確認しましょう。

これらはすべて同じ管理画面から行うことになります。そこにはアクションメニューと、公開範囲、ステータス、使用状況の列があります。

大掛かりなクリーンアップの負担を大きく減らしてくれるツールが2つあります。一括編集には、マクロのエクスポートとインポートをAPI経由で行うことで、何百件もクリックして回るのではなく、スプレッドシート上で仕分けできます。そして、マクロの挙動がおかしいとき(アクションが静かにスキップされる、フィールドがフォームに存在しないなど)は、よくあるマクロの問題を修正するガイドが、マクロ自体が壊れていると決めつける前に確認すべき典型的な原因をカバーしています。

マクロをAIに任せる

Zendeskはマクロ関連のAI機能を2つリリースしていますが、混同されがちなので、ここではっきり分けて説明します。

マクロの提案(エージェント向け) は、エージェントが対応しているチケットに、既存の共有マクロのどれを適用すべきかを推奨します。Zendeskのモデルはチケットの件名とコメントを見て、過去9か月間にマクロが適用されたチケットと比較し、適用マクロメニューの上部に最大3件の提案を表示します。

これは便利ですが、注意すべき点が2つあります。デフォルトではオフになっており、アカウントが過去9か月間で共有マクロを適用したチケットを少なくとも100件持ち、かつそれぞれ最低1回は使われた共有マクロが3件以上ある場合にのみオンになります。また新しいマクロがモデルに反映されるまでには2週間かかります。Zendeskのセットアップ資料にその通り記載されています。そして、この機能が提案するのは常に共有マクロのみで、個人用マクロは対象外です。

マクロの提案(管理者向け) は、現在は管理者向けCopilotフィードのマクロコンテンツ提案に統合されており、逆方向の働きをします。全エージェントの返信に見られる繰り返しのコンテンツをスキャンし、新しいマクロの作成を提案するのです。これはZendesk AIアドオンの一部で、月次で更新されます。「エージェントがいつも手打ちしているこの内容をマクロにしてほしい」とシステムに教えてほしいと思ったことがあるなら、これがまさにそれであり、ZendeskのAIコンテンツ提案とも自然に連携します。

どちらも便利です。ただしどちらも、あなたを同じループの中にとどめます。適用するのも、維持するのも、削除するのも、依然として人間です。ここで当然の疑問が浮かびます。

Freshdesk、Gorgias、Help Scoutにおけるマクロの違い

視点を切り替える前に、これがZendeskだけの話ではないことを知っておく価値があります。主要なヘルプデスクにはどれもマクロの概念があり、名前が違うだけで、管理上の悩みもそのままついてきます。

プラットフォーム固有の点もいくつか触れておく価値があります。Freshdeskのシナリオオートメーションは、ドキュメント上で明確に「シナリオを使ってマクロコマンドを作成し、ワンアクションで実行する」ものと説明されており、別途存在する定型返信とは並列の機能なので、片方だけを想定しているチームは戸惑いがちです。GorgiasのマクロはライブのShopify注文データを返信に取り込めるため、eコマースで特に威力を発揮しますが、Gorgias自身のAIエージェントはマクロライブラリを一切参照せず、独自に回答を生成することには注意してください。そしてHelp Scoutの保存された返信はこの中で最もシンプルな機能であり、小規模チームには十分ですが、Standardプランの10件という上限にはすぐに突き当たります。

呼び方が何であれ、管理の基本方針は同じです。一貫して命名し、整理し、監査し、削除する。そして上限があるという点も同じであり、それが本当の変化点につながります。

2026年の視点転換:マクロを減らし、解決を増やす

これらの管理画面に長く向き合ってきた末にたどり着いた、逆説的な結論がこちらです。大量に発生する繰り返しのチケットに対しては、2026年におけるベストなマクロ戦略は、多くの場合「マクロを増やす」のではなく「マクロを減らす」ことです。

マクロには依然として、人間がチケットを読み、正しいマクロを選び、適用するという作業が必要です。それはゼロから入力するよりは速いものの、解決そのものではなく、ライブラリが大きくなりすぎてナビゲートしにくくなる地点を超えて拡張することもできません。マクロが生まれるきっかけとなった繰り返しのチケット(注文状況、返金、パスワードリセット、「注文はどこ?」)は、まさに今、AIエージェントがエンドツーエンドで処理できるようになったチケットです。

ここでAIヘルプデスクエージェントがメンテナンスの計算式を変えます。あなたが手作業で拡大し続けるライブラリを維持する代わりに、AIはあなたがすでに持っている資産、つまり既存のマクロ、過去に解決したチケット、ヘルプセンターから学習し、繰り返しのチケットを下書きしたり、完全に解決したりします。過去チケットでのトレーニングは、営業電話で聞くリクエストの中でも圧倒的に最も多いものです。チームの一人はこう表現しました。「みんな本当に、本当に、本当に過去のチケットで学習させたいと思っている」。これがうまくいくのは、解決済みのチケットにはすでに、マクロが標準化しようとしていた答えが刻み込まれているからです。

これを取り入れたチームは、その効果をシンプルな言葉で表現しています。Zendesk Teamプランを使うある小規模なeコマースサポートチームは、AIレイヤーが「単純なAIで簡単に答えられる質問に、私たちの小さなサポートチームが押しつぶされずに済むよう本当に助けてくれている」と語りました。マクロの目的は、常に同じ質問に手作業で答え続けることをやめることでした。AIはただ、その仕事を仕上げているだけです。

重要な注意点であり、購入を検討する人々が最も気にかけているのが、コントロールです。初日からすべてを委ねる必要はありません。あるDTCサプリメントブランドのCXリーダーが述べたように、目指すのは「自信を持って対応できるチケットだけを扱うAIで、それ以外はすべて手を出さない」という状態です。まさにこれがそのモデルです。AIが繰り返しの量を引き受け、マクロと人間はエッジケースを担当し、あなたのライブラリは本当に人の手が必要なものだけへと縮小していきます。

"eesel AIを選んだのは、複数チャネルのデータ入力オプションを提供してくれるからです……CSV、Zendesk、Google Docsをソースとして連携させることで、私たちの膨大なドキュメントを最大限に活用できています。"

Wesley Wang氏、CTO、Ecosa(Ecosaの事例より)

eeselを試す

あなたのマクロライブラリが、いつの間にか副業のようになっているなら、eeselはまさにその課題のために作られています。Zendesk(そしてFreshdesk、Gorgias、Help Scout、メール)にネイティブのAIエージェントとしてインストールされ、既存のマクロ、過去のチケット、ヘルプセンターから自動的に学習します。手動でのトレーニングやデータのラベル付けは不要です。

慎重なサポートリーダーにとって最も重要な2点は次の通りです。実際のチケットに触れる前に、過去のチケットでAIをシミュレーションし、AIが何をしたはずかを正確に確認できます。また、料金は1チケットあたり0.40ドルの定額制で、解決ごとの追加料金や座席ごとの料金は一切ありません。どのチケットを処理し、いつエスカレーションするかは、あなたがコントロールし続けられます。

"ベンダーとの関係というより、パートナーシップのように感じます……新しく入社したカスタマーサクセス担当者が、オンボーディング中に私たちのeesel AIボットが一番の親友だったと冗談を言っていたほどです。"

Jon Miron氏、サポート・オペレーション ディレクター、Yellowdig(Yellowdigの事例より)

本当に必要なエッジケース用にマクロを残しつつ、繰り返しの量はAIにリストから外してもらいましょう。eeselを試して、実際のチケットに対して実行し、マクロライブラリのどれだけが不要になるか確かめてみてください。