AIがサポートのシフト引き継ぎを助ける方法は2つあり、重要なのは2つ目です。分かりやすいほうは、より良い引き継ぎメモを書くことです。未解決のチケットを1件ずつ要約し、SLAや約束した更新の期限が迫っているものにフラグを立てます。多くのチームが見落としているのは、シフトの合間にキューを処理するAIエージェント自身はシフト交代をしないということです。そのため境目を越えるチケットが減り、人に引き継ぐチケットには、午後5時55分に記憶を頼りに書いたメモではなく、エスカレーションの瞬間に書かれたメモが付きます。
シフト交代で本当に失われるのは、コンテキストではないことがほとんどです。失われるのは約束です。「14:00 UTCまでに状況をお知らせすると伝えた」という点、次のステップの担当者、すでに試した対処です。良い引き継ぎメモには5つの要素があります（顧客の要望、試したこと、約束した内容と期限、次の担当者、見つけた証拠）。Zendesk、Freshdesk、Help Scoutのネイティブな要約は最初の2つをうまくカバーしますが、残りはエージェントが手入力した場合に限られます。
eeselのようなAIチームメイトは、既存のヘルプデスクの中でこれを行います。SE Rankingは、16か国・全タイムゾーンに広がるZendeskチームですが、ここでは1か月で約1,260件のチャットを顧客の名前とメールアドレス付きで人に引き継ぎ、チケットに約2,600件の内部メモを残しました。料金は500クレジットで月額299ドルからです。
なぜシフト交代では物事がこぼれ落ちるのか？
引き継ぎは、チケットに持ち主がいない唯一の瞬間だからです。退勤する担当者は気持ちがすでに仕事を離れ、入ってくる担当者はまだ状況を読み込んでいません。退勤する担当者の頭の中にしかなかったことは、そのまま消えます。私は毎日eeselのサポートキューを扱っていますが、痛い目に遭うのは難しいチケットではほとんどありません。簡単なチケットで、誰かが小さな約束をしたのに誰も書き残さなかった、というケースです。
こぼれ落ちやすいものを、被害の大きい順におおよそ並べるとこうなります。
- 約束。 「経理に確認して、今日中にご連絡します。」チケットは他の保留チケットと同じに見えますが、顧客は特定の時刻を待っています。
- すでに試したこと。 これがないと、次の担当者は顧客にもう一度キャッシュのクリアをお願いしてしまい、顧客はそれに気づきます。
- 次のステップの担当者。 エンジニアリングへエスカレーション済み？ 顧客の返信待ち？ それとも、すでに帰宅した同僚のところ？
- SLAの時計。 午前9時15分に違反するチケットは、次のシフトのリストの途中ではなく先頭に置くべきです。
- 顧客の気分。 苛立った顧客からの3回目の連絡は、初回の連絡とはまったく違って読めます。
顧客も外側からこれを感じ取っています。あるエンジニアがHacker Newsで、チケットがリージョン間を行き来したときのクラウドベンダーのサポートの様子を書いています。
"...instead they keep sending tickets back for "more info", inevitably followed by a hand-off to another team in a different time zone. We have spent days trying to convince them there was an issue before, which just seems unacceptable."
これが薄い引き継ぎのコストで、次のチームは診断を一からやり直すことになります。ニッチな問題でもありません。別のコメント投稿者は、フォロー・ザ・サン方式をかなり率直に表現しています。
"It can absolutely work, given the right async workflows, but it can also absolutely fail. I'm inclined to believe failure is the default mode of operation."
「適切な非同期ワークフロー」こそが、ほぼすべてです。多くのチームは、各シフトの終わりに共有ドキュメントやSlackスレッドで対処しようとします。それは1週間ほどは機能しますが、やがてドキュメントは古くなります。疲れた担当者が退勤前に最後にやることが、それを書くことだからです。
AIはサポートのシフト引き継ぎをどう助けられるのか？
ここでAIにできる仕事は4つあり、ほとんどの記事が説明しているのは最初の1つだけです。私なら、次の順でオンにします。
このスケッチのチケット数は説明用です。下の計算ツールにご自身の数字を入れてみてください。
1. 未解決チケットを要約する。 ChatGPTやほとんどのベンダーが売り込むのはこの形です。AIが各チケットを読んで要約を書くので、入ってくる担当者は20件の返信をスクロールせずに済みます。役に立ちますし、ほとんどのヘルプデスクにはすでにあります（詳しくは後述）。その要約の質については、チケット要約のガイドで深く掘り下げています。
2. リスクの高いチケットにフラグを立てる。 引き継ぎは古い順ではなくリスク順に並べます。1時間以内にSLAが期限を迎える、約束した折り返し、繰り返しの連絡、障害の報告などです。日付順に並んだ40件の要約リストは、本当に重要な数件を隠してしまいます。
3. 境目を越えるものを減らす。 計算を変えるのはこの仕事です。チケットに回答して解決するAIヘルプデスクエージェントは、午後6時にログオフしません。注文ステータス、使い方の質問、返品リンクなど、退勤するシフトが片付けている間や入ってくるシフトが着く前にAIがこれらを解決すれば、そもそも引き継ぎ項目になりません。最も安上がりな引き継ぎは、そもそも発生しない引き継ぎです。
4. エスカレーションの瞬間にメモを書く。 AIがチケットを解決できないとき、それを人に渡します。その受け渡し自体が引き継ぎであり、シフトに1回ではなく、文脈が最も新しい瞬間にすべてのチケットで行われます。引き継ぎはシフト終わりの雑務ではなく、チケットの属性になります。
3と4があるからこそ、「AIがより良い引き継ぎドキュメントを書く」というのは過小評価だと私は考えます。より良いドキュメントも、同じチケットの山が1つの机から次の机へ移ることを前提にしています。シフトの合間にキューを処理するエージェントは山を小さくし、残ったものについてのメモは、シフトの終わりに疲れることのない存在が書いたものになります。
良い引き継ぎメモには何を入れるべきか？
チケットごとに5つの項目です。メモにこれらが揃っていれば、次の担当者はスレッドを読まずにチケットに対応できます。1つでも欠けていれば結局スレッドを読むことになり、メモは何も節約しなかったことになります。
| 項目 | 例 | 誰が記入すべきか |
|---|---|---|
| 顧客の要望 | 注文4417の返金 | AI（会話から） |
| 試したこと | リセットリンクを2回送信、失敗 | AI（返信と内部メモから） |
| 約束した内容と期限 | 「14:00 UTCまでに更新」 | AIが返信から下書きし、人が確認 |
| 次のステップの担当者 | 請求チーム | 人、またはAIが適用するルーティングルール |
| すでに見つけた証拠 | 注文は支払い済み、未発送 | AI（Shopify、CRM、請求ツールの照会から） |
最後の列のパターンは注目に値します。最初の2項目と最後の項目はAIが非常に得意です。チケットや連携システムの中にある事実だからです。約束と担当者は、人が承認すべきところです。これらはコミットメントであり、引き継ぎメモの中の誤ったコミットメントは、ないよりも悪いからです。同じ瞬間の顧客側については、チャットでの有人対応への引き継ぎのガイドで扱っています。
2つのルールが、タイムゾーンをまたいでもこれらのメモを信頼できるものにします。
- 情報源にリンクする。 メモ内のすべての記述は、チケットで確認できるべきです。「顧客が怒っている」は意見ですが、「48時間以内に3回目の連絡」は次の担当者が検証できる事実です。
- 見つけたことと推測を分ける。 「注文は10月28日に発送済み」（Shopifyより）と「おそらく配送業者の遅延」（推測）は、決して同じ書き方にしてはいけません。
Zendesk、Freshdesk、Help Scout、Gorgiasはすでに何をしているか？
今ではほとんどのヘルプデスクが、チケットをオンデマンドで要約できます。それは引き継ぎの「何が起きたか」の部分をカバーします。ただし、標準では「何が約束され、誰が担当しているか」を継続的に管理するものはありません。以下は各社の公式ドキュメントに基づく内容で、2026年10月30日に確認しました。
| ヘルプデスク | 引き継ぎに関連するネイティブAI | カバー範囲 | プランと制限 |
|---|---|---|---|
| Zendesk | Agent Workspaceのチケットサマリー | 公開コメントを要約。内部メモは管理者が有効にした場合のみ | SuiteおよびSupport Professional以上、月間の利用枠あり。Copilotアドオンの一部 |
| Freshdesk | Freddy AI Summarize | プライベートメモを含むIssue、Steps Taken、Outcome | Freddy AI CopilotのTicket content assist配下、管理者による有効化が必要 |
| Help Scout | AI Summarize | ワンクリックの会話要約 | PlusおよびProプラン。要約は常に英語 |
| Gorgias | AI Agentの引き継ぎ設定 | 引き継ぎトピックと、チャットがオンライン時・オフライン時の別々のメッセージ | Gorgias AI Agentの一部 |
Zendeskのチケットサマリー
Zendeskのサマリーは、チケットヘッダーの下にバナーとして表示されます。ドキュメントによれば「the public comments that have been added to a ticket so far」を要約し、内部メモは管理者が有効にした場合のみ含まれます。引き継ぎでは、この設定が非常に重要です。退勤する担当者が試したことを書くのは、たいてい内部メモだからです。サマリーは5分ごとに手動で更新でき、新しいコメントを取り込めます。詳しくは、Zendesk Copilotのチケットサマリーの記事をご覧ください。
FreshdeskのFreddy AI Summarize
Freshdeskのサマリーは、構造化されているため、標準機能の中では引き継ぎメモに最も近いものです。Issueセクション、プライベートメモを含むSteps Takenセクション、そしてOutcomeがあります。エージェントは編集して保存でき、Freshworksはチーム参照用にサマリーをプライベートメモに追加することを勧めています。新しい返信が来ても自動では更新されず、再生成が必要です。設定については、Freddyの要約のウォークスルーをご覧ください。
利用者は、期待どおりの引き継ぎのメリットを語っています。
"Freddy makes our tickets easy to understand for all agents. The need for explanation has decreased, as agents can find the Freddy summary at the top of the ticket."
Help Scout AI SummarizeとGorgiasの引き継ぎ
Help Scoutは、ドキュメントで引き継ぎという用途を直接挙げている唯一のベンダーで、AI Summarizeは「useful for handing off a conversation to another teammate.」とされています。複数のタイムゾーンにまたがるチームには、知っておくべき制限が2つあります。会話の言語にかかわらず要約は常に英語で書かれること、そして自動では更新されず、新しい返信が来たらUpdate Summaryをクリックする必要があることです。詳しくは、Help Scout AIの概要をご覧ください。
Gorgiasは反対の方向からアプローチします。AI Agentの引き継ぎ設定では、チャットがオンラインのときとオフラインのときで別々の引き継ぎ指示を書き、オフラインのメッセージで営業時間を伝え、次のシフトがフォローアップできるように買い物客のメールアドレスを集められます。これはシフト間ではなくAIからチームへの引き継ぎですが、同じ瞬間の話です。Gorgiasの引き継ぎガイダンスの記事で取り上げました。
4社に共通する課題： サマリーはオンデマンドで取得され、過去を説明するものです。誰が何を負っているかでキューを並べ替えることはなく、誰かが開こうと思ったチケットにしか存在しません。静かなキューならそれで十分です。1日に2〜3回シフト交代があるチームでは、次の担当者が来たときに引き継ぎメモがすでにそこにある必要があります。
本番ではどう見えるのか？
ここでは、それぞれ違う形で引き継ぎの問題を解決している3社のeesel顧客を紹介します。数字はすべて公開されている導入事例からのもので、2026年8月8日から9月8日の期間です。
SE Ranking：書き出された引き継ぎルール。 SE Rankingは、3つの製品のサポートをZendeskで運用しており、16か国・全タイムゾーンをカバーするチームです。これはフォロー・ザ・サン型チームの姿であり、引き継ぎルールは明文化されています。チャットが人を必要とするとき（返金、トライアル延長、同じ質問が繰り返された場合、顧客が画面が一致しないと言う場合）、eeselは顧客の名前とメールアドレスを付けて引き継ぎます。トラブルシューティング中だった場合は、顧客にすでに伝えたことのメモを付けて引き継ぎます。ティア2の問題は、まず証拠（ドメイン、監査リンク、コネクタのスクリーンショット）を添付したチケットになります。そして、顧客に「今から担当者が入ります」とは決して言わず、1〜2営業日以内に返信がある旨を伝えます。その1か月間で、約1,260件のチャットをチームに引き継ぎ、約2,600件の内部メモを残しました。その大半は、人が送信するための下書きでした。
この最後のルールは、複数のタイムゾーンにまたがるどのチームにも真似してほしいものです。午前3時にライブ担当者を約束するボットは、まさに引き継ぎで消えてしまう種類のコミットメントを生み出します。
Amagency：読み込みの手間を省くメモの形式。 Amagencyは、4つの消費者向けブランドのサポートを1つのGorgiasアカウントで運用しています。eeselはそこで顧客に直接返信することはありません。代わりに、すべての内部メモの先頭に、コピーしてすぐ使える顧客への返信全文があり、その下に、見つけた注文の詳細とフラグを立てた事項を示す短いセクションが付きます。名前以外はすべて引き継ぎメモです。次にチケットを引き継ぐ人は、スレッドを開かずに証拠と提案された返信を見られます。1か月で約350件のチケットに、約900件の内部メモと460件の返信下書きを残しました。また、平日の毎朝シドニー時間の9時にワークスペースの短いレビューを実行し、チームにメモをメールで送っており、これがシフト開始時のブリーフィングとして機能しています。
Swiftreg：夜勤ではない夜勤。 ZendeskでSwiftregは、英国のナンバープレート販売会社で、チケットの大半は営業時間中に届きますが、事例によれば、夜間に届くチケットも日中と同じように扱われます。月間約2,100件のチケットのうち、eeselは1,494件の公開返信を送り、次のステップがスタッフにある場合に1,055件の内部メモを残しました。朝にキューを開いた人は、夜間のチケットが回答済みか、メモが付いているかのどちらかであることを確認できます。
ある顧客の設定にあるルールは、書き出されたルールが引き継ぎドキュメントより優れている理由を示しています。エージェントを設定していたサポート管理者は、こう言いました。
"I have a rule in CS where we do not address a cancel or refund request when there is an issue attached to it."
こうしたルールは、たいていベテラン担当者の頭の中にあり、口づてにシフトからシフトへ伝わります。エージェントの指示に書き込まれれば、誰が当番であっても、午後2時でも午前2時でも同じように適用されます。これは、複数シフトのチームにとってAIの静かなメリットです。ポリシーが、その日誰が働いているかに左右されなくなります。
引き継ぎにどれだけの時間がかかっているか？
ご自身の数字を入れてみてください。デフォルトでは、1日2回のシフト交代、各回40件の未解決チケット、メモなしのチケットに次の担当者が慣れるまで6分、適切なメモがある場合は1.5分と想定しています。現在の引き継ぎが確実に押さえている項目にチェックを入れると、チェッカーが抜けを一覧にします。
現在の読み込み時間は、メモがすでに押さえている6項目の数に応じて変わります。「AIエージェントあり」は、設定した割合のチケットを引き継ぎ前にエージェントが解決し、それ以外のすべてに完全なメモを残すと仮定しています。
目につくことが2つあります。1つ目は、読み込み時間が思ったより大きいことです。毎日、シフト交代のたびに支払うからです。80件を1件4.5分で処理すると、誰かが顧客に返信する前に、新しいシフトが状況把握だけに6時間を使うことになります。2つ目は、メモのほうが、チケットの振り分け（デフレクション）よりも多くの仕事をしていることです。スライダーが0%でも、デフォルト設定では、すべてのチケットに完全なメモがあれば読み込み時間は約3分の2減ります。気になる数字が読み込み時間ではなくキューの大きさそのものであれば、チケットのバックログを解消する記事と対応時間を短縮する記事がその面を扱っています。
AIは何を引き継ぎ、何を人に残すべきか？
AIは事実と定型のチケットを担い、人はコミットメントと判断を受け持つべきです。2〜3シフトで回すチームなら、私はこう分けます。
| シフト交代時 | AIが担当 | 人が担当 |
|---|---|---|
| 定型チケット（注文ステータス、使い方、返品） | 引き継ぎの前後に回答して解決する | シフト開始時にサンプルを確認する |
| 未解決チケットごとの要約 | 触れたすべてのチケットに書く | 読んで、間違いがあればフラグを立てる |
| 試した手順と見つけた証拠 | 返信、メモ、照会から取り出す | チケット外で行ったこと（電話、Slackスレッド）を追記する |
| 約束した更新と期限 | 返信から下書きし、期限が近いものにフラグを立てる | 約束を確認し、守る |
| エスカレーションの担当者 | ルーティングルールを適用する | 担当を引き受ける（特にエンジニアリングや請求） |
| 障害とセキュリティ問題 | 当番の担当者を呼び出す | インシデントと顧客への更新を担う |
| 怒っている顧客や繰り返しの顧客 | 引き継ぎの先頭にフラグを立てる | 返信を書く |
AI側を安全にするためのガードレールは短いものです。別のシフトが担当しているチケットを、黙ってクローズしたり再割り当てしたりしてはいけません。AIが書くすべての引き継ぎメモは、元のチケットにリンクすべきです。そして、スケジュール上提供できない有人対応を約束してはいけません。これもSE Rankingのルールです。より広い設計については、AIハンドオフのベストプラクティスの記事をご覧ください。
ヘルプデスクでAI支援の引き継ぎをどう設定するか？
5つのステップです。最初の2つは、AIの有無にかかわらずどの引き継ぎプロセスにも必要なヘルプデスクの整備です。
ステップ1：5つの項目を本物のチケットフィールドにする
自由記述の引き継ぎメモは読み飛ばされます。次の担当者と約束期限（日時）のカスタムフィールドかタグを追加し、SLAの期限がチケットビューに表示されるようにします。フィールドにすれば、人もAIも記入でき、「約束期限」で並べ替えたビューを作れます。
ステップ2：リージョンごとに営業時間を設定する
ヘルプデスクは誰がいつオンラインかを把握している必要があります。そうでないと、SLAのタイマーや「チャットはオフラインです」のメッセージが、シフト交代のたびに間違ったものになります。Zendeskは複数のスケジュールをEnterpriseでサポートし、Freshdeskは複数の営業時間をPro以上でサポートし、GorgiasはBasic以上のすべてのプランで営業時間があり、Help Scoutは会社の営業時間とPlusおよびProのカスタム受信トレイ営業時間があります。それぞれのメニューの手順は、週末対応ガイドで順に紹介しました。SLAの設計そのものについては、SLAのベストプラクティスをご覧ください。
ステップ3：AIエージェントを接続し、引き継ぎメモのテンプレートを渡す
エージェントを、ヘルプデスク、ヘルプセンター、過去のチケット、および照会に必要なシステム（Shopify、請求ツール）に接続します。次に、新人に説明するように平易な言葉で引き継ぎのルールを書きます。「チケットを人に渡すときは、顧客の要望、試したこと、約束したことと期限、担当すべき人、見つけたことを内部メモに残してください。」eeselでは、これはエージェントの指示に書くテキストにすぎず、すべてのエスカレーションで24時間適用されます。
ステップ4：シフト開始時のブリーフィングをスケジュールする
各シフトの開始時に、AIが短いブリーフィングを投稿するようにします。2時間以内にSLAが期限を迎えるチケット、今日が約束期限の更新があるチケット、繰り返しの連絡、前回のシフト以降にエスカレーションされたものすべてです。チームがすでに見ている場所、つまりSlack、Microsoft Teams、メールに送ります。eeselでは、これはスケジュールジョブで、プロンプト、時刻、タイムゾーンを指定するだけなので、APAC向けとヨーロッパ向けのブリーフィングをそれぞれ現地時間の9時に届けられます。
ステップ5：2週間は下書きのみで運用し、その後広げる
まずは、AIがメモと下書きを書き、返信は送らない状態から始めます。シフト交代のたびに、入ってくる担当者に1つ質問します。メモだけでこのチケットに対応できましたか？ 答えがノーの箇所ではテンプレートを直します。その後、AIに上位2〜3件の定型トピックを自力で解決させます。私は何年もeeselがAIエージェントを本番のサポートキューに導入するのを見てきましたが、新しい設定はどれも、まず実際の過去のチケットに対して実行されます。自信ありげな回答は、自社のデータでしか見えない形で間違えるからです。よくある落とし穴は、AI導入の失敗例のリストで扱っています。
引き継ぎが機能しているかどうやって判断するか？
キューだけでなく、引き継ぎそのものを測ります。4つの数字で必要なことのほとんどが分かります。
- 守られなかった約束。 約束した更新時刻が、返信のないまま過ぎたチケット。この取り組み全体が、ゼロに近づけるためにあるのがこの数字です。
- シフト最初の1時間のSLA違反。 違反がシフト交代の直後に集中しているなら、引き継ぎが時計を見失っています。
- シフト開始後の最初のアクションまでの時間。 入ってくるシフトが、引き継いだ最初のチケットに返信するまでの時間。良いメモがあれば、1時間ではなく数分になります。
- シフト交代ごとに境目を越えるチケット。 上の計算ツールが見積もる数です。AIが定型の量を引き受けるほど減るはずです。
AIが触れたものはすべてタグ付けして、AIのチケットとチームのチケットを分けられるようにします。SE Rankingは、eeselが扱うすべてのチケットにai_handledタグ、さらに役立った・役立たなかったのタグを求め、封じ込め率を推測ではなくZendeskで数えられるようにしました。AIカスタマーサービスの指標とエスカレーションの質の記事でさらに詳しく解説しており、レポートの作り方そのものはサポートレポートにAIを使うで扱っています。
eeselが適切でない場合：1〜2人のエージェントで単一シフトを運用しているなら、ヘルプデスクの5行の引き継ぎテンプレートとネイティブの要約ボタンで十分です。また、問題がシフト間の瞬間ではなく、長時間誰もオンラインにいないことであれば、時間外サポートのガイドをお読みになるか、サポートの人員配置にAIを使うで人員配置の選択肢をご覧ください。
シフト引き継ぎにeeselを試す
サポートチームがシフトで働いていて、誰も記録していない山とともに朝が始まるなら、eeselはシフト交代のないチームメイトのように機能します。Zendesk、Freshdesk、Gorgias、Help Scoutの既存のキューに加わり、ヘルプセンターと過去のチケットがすでにカバーしていることに回答し、人に渡すすべてのチケットに、事実、下書き、証拠を含む内部メモを残します。スケジュールされたブリーフィングを、各リージョンのシフト開始時にSlackやTeamsに届けることもできます。
SE Rankingは、これで16か国にまたがる1つのキューを運用しており、Amagencyは、チームが開く前にGorgiasのチケットに送信可能な返信を受け取っています。プランは、毎月固定のクレジット枠です。1チケットまたは1チャットが1クレジットで、500クレジットで月額299ドルから、無料プランの100クレジットなら、まずご自身のチケットでメモを確認できます。
eeselを試して、今夜の引き継ぎに使ってみてください。あるいは、カスタマーサービス向けのベストAIエージェントのまとめで、他との比較をご覧ください。