フォロー・ザ・サン・サポートとは？
フォロー・ザ・サン・サポートは、サポート業務が日の光とともに地球を回るカバレッジモデルです。アメリカのチームが自分たちの一日を働いてキューをヨーロッパのチームに渡し、ヨーロッパがアジア太平洋のチームに渡し、そこからまたアメリカに戻ります。各拠点は通常の現地時間で働き、キューは眠りません。
私は毎日 eesel のサポートキューに入っていて、夜勤チームを疲弊させずに24時間365日のサポートを実現しようとするチームと多くの時間を過ごしてきました。フォロー・ザ・サンはホワイトボード上でいちばん見栄えのする方式です。Hacker News のあるエンジニアは、これ以上ないほど簡潔に説明しています。
"Three regular shifts (8 hours of work plus some lunch break that gives you time for a short overlap at the beginning/end of the shift) during that region's local daytime hours, in three different regions with time zones roughly 8 hours apart. That way nobody has to work nights and you still get 24/7 coverage."
括弧の中に注目してください。各シフトの端にある短い重なりが引き継ぎの場で、3拠点なら毎日3回あります。
これがこのモデルの核にあるトレードです。夜勤を引き継ぎと交換するのです。それが良い取引かどうかは、ほぼ完全にこの3つの境目をどう扱うかで決まります。このガイドの残りはその話です。
これはオフショアサポートの近い親戚で、よく混同されます。オフショアはチームがどこにいるか（通常はコストのため）の話です。フォロー・ザ・サンは各チームがいつ働くかの話です。3つの自社オフィスでも、オンショアチームに地球の反対側の外部委託拠点を加えた形でも、フォロー・ザ・サンは運用できます。
2拠点か3拠点か？
多くのチームは3つの形から選びます。実際に問題になる点で比べると次のとおりです。
| モデル | 拠点数 | シフトの長さ | 1日の引き継ぎ回数 | 主なコスト |
|---|---|---|---|---|
| 1拠点での夜勤 | 1 | 8時間、ローテーション | 0 | 夜間勤務、定着率 |
| 2拠点のフォロー・ザ・サン | 2、約12時間差 | 約12時間、または8時間で両端が空く | 2 | 遅い夜と早い朝 |
| 3拠点のフォロー・ザ・サン | 3、約8時間差 | 8時間 | 3 | 各拠点の人員 |
| 1〜2拠点とAI | 1〜2 | 8時間 | 人の引き継ぎは0〜2 | AIの設定とレビュー |
2拠点は、オフィスが2つで済むので、多くのチームがここから始めます。負担は真夜中ではなく、シフトの端に移ります。
"My team in Sydney partners with San Francisco for example, so worst case for me is a page at midnight just before I hand over, worst case for them is about 5am. So not usually anything happening in the middle of the night, at worst a late night or early morning, but never both."
これが成り立つには、2拠点が十分に離れている必要があります。米国とアイルランドの分担を検討していた r/devops のコメント投稿者は、"there isn't really enough difference in TZs to make that work cleanly" と述べ、負荷が偏らないようアイルランドのチームを増やす必要があるとも指摘していました（出典）。
3拠点ならきれいな8時間シフトになりますが、人員面でいちばん高くつきます。同じ r/devops のスレッドに、1拠点での24時間365日運用（"a high burnout rate"）から、米国チームとの12時間ずつの分担、さらに英国の3人チームを加えた8時間ずつの分担へと移行した会社の投稿者がいます。その3人の拠点についての彼の評価は次のとおりです。
"I can't see how we can create a sensible sustainable even rota in these three regions, I also feel like each team needs at least 6-8 people in it for it to be sustainable long term."
この数字は頭に置いておくべきです。2〜3人の拠点は拠点ではなく、休暇カレンダー付きの単一障害点です。各地域に本物の人員を置けないなら、規模を小さくして空白を埋める何かを加えるほうが、細い3拠点ローテーションより多くの場合うまくいきます。
1拠点の夜勤は、特に外部委託チームを使えば、いちばん安く見えます。ただ、負けるのは価格ではなく人の面です。r/msp のあるMSPオーナーは、以前のオフショア夜勤チームを経験したあとにこうはっきり述べています。"keeping people when they are being asked to work through their nights is something I feel never works well"（出典）。
フォロー・ザ・サンが壊れる場所：引き継ぎ
カバレッジは簡単な部分です。実際にフォロー・ザ・サンを運用した実務者の話はどれも同じことを言っています。弱点は時間帯ではなく、シフトの切り替えです。
最初の漏れはコンテキストです。各地域は一日の違う断面を見ています。
"The communication costs from time zones are real, and it makes everyone's context on what is going on different because they see updates from different regions."
サポートキューでは、同じ日に2人の顧客が同じ質問をして別々の答えを受け取る形で現れます。EMEA チームは朝のスタンドアップで配送遅延を知ったのに、APAC には伝わっていないからです。このモデルでシフトをまたぐ一貫した回答が、ほかのどこよりも重要になるのはそのためです。
2つ目の漏れは担当者です。次の拠点はチケットを引き継ぎますが、その裏にある専門知識は引き継げません。
"I've been at places that follow the sun, and you frequently have no idea what to do during an incident, because the person who owns the system is offline."
3つ目の漏れは、引き継ぎそのものというオーバーヘッドです。メモは書かれ、読まれ、信頼される必要があります。難しいチケット1件にメモを書くのは問題ありません。午後4時55分に30件書くと、メモは "ticket 4512, customer upset, pls check." になります。
調査でいちばん役に立ったのは、フォロー・ザ・サンモデルの設定についてのZendesk自身のガイドでした。自社サポートチームの運用を説明するくだりで、"there are no daily handoffs" と述べ、チケットは基本的に最初に取ったエージェントのもとにとどまるとしています。ここが発想の転換点です。フォロー・ザ・サンは、主に引き継ぎの問題ではなくルーティングの問題です。新しいチケットは起きている人に行きます。担当者は自分のチケットを持ち、翌日にまた続きを取ります。境目を越えるのは緊急のものだけで、それには丁寧なメモを付けます。
ホワイトボードでは見えない形で、拠点間に差を生むものがあと2つあります。労働法は、実際に誰が週末をカバーするかを決めます。Hacker News のあるコメント投稿者は "follow the sun rotation" のある会社に入り、ほかの国のほうが規制が厳しいため、米国チームがほかの全員の時間外サポートをしていたと気づきました（出典）。また、契約によっては拠点そのものが選べなくなります。別のコメント投稿者が関わったエンタープライズ顧客は、データを米国外に出せないため "a subcontractor in London provide support" を認めませんでした（出典）。3つ目のオフィスを決める前に、この両方を確認してください。
ヘルプデスクでフォロー・ザ・サン・サポートを設定する方法
どのチームにも、この順番でお勧めする設定です。手順はどのヘルプデスクでも同じですが、各手順を使えるようにするプランは違うので、手順のあとに一覧表を載せます。
1. 地域ごとにグループ（またはインボックス）を1つ作る
拠点ごとにグループ（"Support-Americas"、"Support-EMEA"、"Support-APAC"）を作り、各エージェントを所属地域に入れます。そのほかはすべてこのグループに紐づきます。スケジュール、ルーティング、ビュー、レポートです。Help Scout と Front では、地域ごとに1つのインボックスが同じ役割になります。
2. 各地域に独自の営業時間を設定する
各グループに、その地域のタイムゾーンでスケジュールを設定します。この手順は、プランによる制限がもっとも多く出るところです。Zendesk では、複数のスケジュールを設定できるのはEnterpriseプランだけで、Suite Professional では1つです。Freshdesk はグループごとに独自の営業時間を持てます（例として文字どおり "EU, North America, or Asia" を挙げています）。Pro 以上では追加の営業時間も使えます。
Zendesk での小さな落とし穴として、営業時間の区間は午前0時をまたげないため、22:00から06:00のシフトは2つの区間に分ける必要があります。
3. SLAを営業時間基準にする
各SLAポリシーを暦時間ではなく営業時間で数えるように設定します。APAC の一日の終わりに届いたチケットが、EMEA チームがログインする前に違反しないようにするためです。ここで取り上げたヘルプデスクはすべて対応しており、FreshdeskのSLAポリシーはグループの営業時間外にタイマーを止めます。注意点は、タイマーがチケットに付いたスケジュールに従うことで、先に手順2を正しく設定しておく必要があります。Front では、SLAルールは現在タイムゴールルールと呼ばれ、会話がスヌーズ中でもタイマーが動き続けるため、驚く人がいます。
4. 実際に対応できる人でルーティングする
この手順が、フォロー・ザ・サンを「3つのチームでキューを共有する」状態から、機能するモデルに変えます。割り当ては、今オンラインのエージェントにだけチケットを送るべきで、それが実践におけるインテリジェントルーティングの意味です。Zendeskのオムニチャネルルーティングは全プランでステータスと対応容量でルーティングし、Professional と Enterprise では、担当者が不在のときに再オープンされたチケットを再割り当てできます。この最後の機能がネイティブな引き継ぎです。顧客が現地時間の午前2時に返信し、担当者は寝ていて、チケットは起きている人に移ります。
先に知っておくべき落とし穴があります。Zendesk の統合エージェントステータスのドキュメントははっきり書いています。"Operating hours won't set an agent's status." エージェントは自分でオンラインとオフラインを切り替えます。一日の終わりにオフラインにし忘れると、ルーティングは夜通しその人にチケットを送り続けます。
私が確認した5つのヘルプデスクのうち、これをネイティブに解決するのは2つだけです。Freshdesk のAgent Shifts（Enterprise）は、シフト時間に応じて対応可否を自動で切り替え、各シフトは自分のタイムゾーンで設定できますが、午前0時をまたぐシフトは受け付けません（詳しくはFreshdesk Agent Shiftsのメモを参照）。Front のShifts（Enterprise）は、シフト開始でチームメイトを Available に、終了で Out of office にし、顧客から新しい返信が来ると、シフト外の人から会話の割り当てを外し "so someone else can follow up." とします。
5. 引き継ぎメモを標準化し、下書きはAIに任せる
境目を越えるチケットについては、引き継ぎメモに何を書くかを決めておきます。顧客が尋ねたこと、試したこと、約束したことと期限、現在の担当者、次のステップです。マクロにしておけば、テンプレートはワンクリックで呼び出せます。
そのうえで、手書きはやめましょう。今は多くのヘルプデスクに、まさにこの用途のためのAI要約があります。Help Scout のAI Summarizeは、"handing off a conversation to another teammate" を用途として挙げています。Freshdesk の Freddy の要約は Issue、Steps Taken、Outcome の構成で、プライベートノートも含みます。Front の要約は新しいメッセージのたびに更新されます。
上限には注意してください。Zendesk は2026年5月にCopilotチケット要約を Professional 以上で提供しましたが、エージェント1人あたり月5回（要約とライティングツールの合計）の共有枠で、アカウントあたり上限は500です。実際に引き継ぎを行う3拠点チームなら最初の週で使い切り、その後は Copilot アドオンが必要になります。設定はZendeskのAI要約のガイドで説明しています。
6. 全員が所有するナレッジベースを1つ持つ
地域間のずれを防ぐいちばん早い方法は、すべての拠点が読み、更新する1つのナレッジベースを持つことです。EMEA が配送遅延を知ったら、APAC が二度とさかのぼらない Slack のスレッドではなく、その日のうちにヘルプセンターに載せます。複数の言語に対応している場合は、地域ごとに翻訳したコピーを持たせるのではなく、多言語ヘルプセンターを設定してください。
どのプランで何が使えるか
各ベンダーの料金ページとヘルプセンターに基づく、2026年10月時点で各機能が使える最安プランです。価格はエージェント1人あたり月額、年払いで、ヘッダーのベンダー名は各社の料金ページにリンクしています。
| 機能 | Zendesk | Freshdesk | Help Scout | Gorgias | Front |
|---|---|---|---|---|---|
| 複数のスケジュール | Enterprise（営業へ） | Pro $55 | Plus $45（インボックスごとの営業時間） | Basic（チャネルごとの営業時間） | Professional $65（インボックスごとの営業時間） |
| 営業時間基準のSLA | Suite Professional $115 | Growth $19（ポリシー1つ）、複数は Pro | Standard $25（ポリシー1つ） | 全プラン | Professional $65 |
| 対応可否を考慮した割り当て | Suite Team $55 | Pro $55 | Plus $45 | 全プラン | Professional $65 |
| ステータスを自動で切り替えるシフト | ネイティブ非対応 | Enterprise $89 | なし | なし | Enterprise $105 |
| AIによる引き継ぎ要約 | Professional、エージェント1人あたり月5回、Copilot $50 で無制限 | Freddy AI Copilot $29 アドオン | Plus $45 以上 | 未確認 | Copilot $20 アドオン、Enterprise に含まれる |
Gorgias は、エージェント数ではなくチケット量で価格が決まるため異色で、全プランに "Pause SLA timer outside of business hours" のトグルがあります。新しい地域でエージェントを増やしていく成長中のチームにとって、この料金体系はどの席単位プランより使いやすく、ルールで地域ごとの営業時間外の自動返信も送れます。
フォロー・ザ・サン・サポートの席数コスト
先ほどの1拠点あたり6人の目安に従うとします。3拠点で18人です。地域別の営業時間が使えるプランと、自動シフトが加わるプランでの、ヘルプデスクの月額は次のとおりです。
| ヘルプデスク | 地域別営業時間のプラン | 18人 / 月 | 自動シフトのプラン | 18人 / 月 |
|---|---|---|---|---|
| Zendesk | Enterprise | 営業へ問い合わせ | ネイティブ非対応 | n/a |
| Freshdesk | Pro $55 | $990 | Enterprise $89 | $1,602 |
| Help Scout | Plus $45 | $810 | なし | n/a |
| Front | Professional $65 | $1,170 | Enterprise $105 | $1,890 |
| Gorgias | Basic 以上 | 席ではなくチケット量で課金 | なし | n/a |
これは人件費を含む前の数字で、本当のコストは人件費です。同じチケット量でも、1地域のチームなら8〜10人で足りるかもしれません。18人を3つのオフィスに分けるのはまったく別の予算です。量は24時間均等には分布せず、多くのキューには忙しい地域が1つと静かな地域が2つあるからです。3拠点モデルでは、静かな拠点にも祝日をカバーできるだけの人数が要ります。
ここは、AIとオフショアの比較の計算も含め、代替案と正直に数字を比べる価値があります。小規模なチームには、スタートアップのスケーリングガイドが同じ選択を扱っています。3拠点のうち2つが、主に午前3時の「注文はどこ？」に答えるために存在するなら、高くつく答え方です。
フォロー・ザ・サンモデルにおけるAIの位置づけ
AIはこのモデルを置き換えません。モデルに必要な人の数を変え、いちばんつらい役目、つまり静かな時間を一人でカバーする人になることを取り除きます。
eesel の多くの導入でこれを見てきました。うまくいくパターンは狭くて地味で、だからこそうまくいきます。
-
AIが拠点間の時間をカバーする。 空白の時間帯に、AIヘルプデスクエージェントが、ヘルプセンターと過去のチケットから定型チケット（注文状況、パスワードのリセット、ハウツーの質問）に答えます。Anytime Fitness は40か国以上で5,000以上のジムを運営していて、eesel を使う前は、午後10時に質問した会員は朝まで待っていました。今は、よくある質問にどの時間帯でも回答が届きます。
-
AIは確信のあることだけに答える。 それ以外は手を付けずに次の人間のシフトを待ちます。月に約7,000件のチケットを扱うCXリードが、営業の電話で私が言えるよりうまくこう表現しました。
"I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."
-
AIが引き継ぎを書く。 手を付けないチケットにはタグを付け、ルーティングし、内部メモを残すので、朝のシフトは冷えたキューではなくコンテキスト付きで始まります。これは人への引き継ぎの問題を反対側から見たものです。
-
AIがどの地域にも同じ答えを出す。 1つのナレッジベースと1セットの指示から読むため、APAC と EMEA が配送遅延の回答でずれることはありません。CartonCloud のサービスデスクリードは、その導入事例で効果を "consistent, on-brand tone, still keeping our own style and still keeping that human touch" と述べています。
私が関わっているあるチームはさらに一歩進めて、スケジュール実行の「毎日のサポート引き継ぎ要約」を回しています。毎朝、エージェントが全地域で過去24時間に起きたことをまとめるので、各拠点が同じ状況認識で一日を始められます。
同じ経験から、正直な警告が1つあります。eesel の長年の顧客で、営業時間がプロンプトの文章にしかなかったために、AIが営業時間まわりで一貫しない動きをしたことがありました。営業時間と引き継ぎルールは、ヘルプデスク自身の設定に置いて（上の設定手順にあるスケジュール、SLA、ルーティング）、AIにはそれを読ませてください。指示文の1段落で説明して祈るのではなく。
よくあるフォロー・ザ・サンの失敗
ほとんどは実際のキューで見たもので、いくつかは自分でもやりました。
- シフトの終わりに全部引き継ぐ。 午後5時にすべての未対応チケットを再割り当てするなら、1日3回コンテキストを失う仕組みを作ったことになります。引き継ぐのは緊急のチケットだけにしてください。
- 祝日を乗り切れないほど小さい拠点。 2人の拠点は、誰かが休めば1人になり、その1人が24時間365日の計画そのものになります。6〜8人で設計するか、規模を縮めてください。
- エージェントが自分でステータスを切り替えると信じる。 特に Zendesk では、オンラインのままの忘れは、寝ている人にチケットが回ることを意味します。プランにあるなら自動シフトを使うか、チケットトリアージのルーティンにシフト終了時の簡単な確認を入れてください。
- 暦時間のSLA。 ある地域の一日の終わりに作られたチケットは夜のうちに違反し、特に理由もなくSLAトラッキングを台無しにします。
- 拠点を別々に計測する。 ほかのカスタマーサービスKPIと並べて、拠点ごとではなくキュー全体で時間帯別の初回応答時間を見てください。空白は境目に現れ、拠点別のレポートはそれを隠します。
- 一日の端を忘れる。 あるシスアドミンが言ったように、デスクが17:00に閉まるなら "what happens if they have a critical incident at 16:50? Because that happens quite often"（出典）。フォロー・ザ・サンは、その16:50の瞬間を拠点の数だけ増やします。
フォロー・ザ・サン・サポートのための eesel
モデルが求めるより少ない人数でフォロー・ザ・サンを回している場合や、静かな時間をカバーするためだけに3つ目の拠点を加えようとしている場合は、まずその枠にeeselのAIヘルプデスクチームメイトを置いてみてください。Zendesk、Freshdesk、Gorgias、Front、Help Scout に接続し、過去のチケットとヘルプセンターから学び、どの時間帯でもキューを処理します。確信のあるものに答え、残りは次のシフトのための引き継ぎメモを付けて残します。
実際のチケットに触れる前に、過去の数百件のチケットでシミュレーションし、その回答をチームが実際に送った内容と比べられます。また、料金は席数ではなく処理したチケット単位なので、夜間の空白をカバーするために、別のオフィス1つ分のライセンスを買う必要はありません。
eeselを無料で試して、拠点間の時間が空白でなくなったとき、あなたのキューがどう見えるか確かめてください。