Zendesk移行：2026年完全ガイド

サポートデータの移行は、引っ越しによく似ています。すべてを箱に投げ込んでうまくいくことを願うこともできますが、時間をかけて整理、ラベル付け、計画を立てることで、すべてが新しい家のあるべき場所に正確に収まるようにすることができます。Zendeskの移行も同じように機能します。別のプラットフォームからZendeskに切り替える場合でも、合併後に複数のZendeskアカウントを統合する場合でも、Zendeskから完全に移行する場合でも、どのようなアプローチを取るかによって、チームの移行がどれだけスムーズになるかが決まります。

このガイドでは、初期計画から移行後の最適化まで、移行プロセス全体を説明します。3つの主要なアプローチ（DIY API、サードパーティツール、プロフェッショナルサービス）、注意すべき点、およびサポート業務を継続的に実行する方法について説明します。

すでにZendeskを使用しており、AIで機能を強化したい場合は、当社のZendesk連携をご利用いただくと、移行の煩わしさなしにチケット処理を自動化できます。

開始する前に必要なもの

チケットに触れる前に、次のものを用意してください。

• ソースシステムとターゲットシステムの両方への管理者アクセス。 移行元のプラットフォームと移行先のプラットフォームの両方に対する完全な管理者権限が必要です。
• 完全なデータインベントリ。 チケット、エージェント、エンドユーザー、組織、ナレッジベースの記事を数えます。これは、タイムラインとコストの両方に影響します。
• APIトークンまたはOAuth認証情報。 自動移行方法を使用する場合は、両方のシステムを認証する必要があります。
• チームの可用性。 問題を処理し、結果を検証するために、移行期間中に誰かが対応できる必要があります。
• 移行方法の決定。 これについては次のセクションで詳しく説明しますが、開始する前に、DIYで行うか、ツールを使用するか、専門家を雇うかを決めてください。

ステップ1：データを監査して準備する

移行の品質は、準備の品質に完全に依存します。データを準備する方法を次に示します。

現在のデータ品質を評価します。 レポートを実行して、重複レコード、アーカイブできる古いチケット、移行が不要になった非アクティブなユーザーを特定します。私が話をしたある企業は、長年の古いデータを最初にクリーンアップするだけで、移行範囲を40％削減しました。

カスタマイズを文書化します。 次の完全なリストを作成します。

• カスタムフィールドとその目的
• マクロとその使用方法
• トリガーと自動化
• ビジネスルールとワークフロー
• 統合構成

データマッピングドキュメントを作成します。 このスプレッドシートは、ソースシステムのすべてのフィールドをターゲットシステムにマッピングする必要があります。直接同等のフィールド、変換が必要なフィールド、およびまったく転送されない可能性のあるフィールドをメモします。

移行前にクリーンアップします。 今すぐデータ品質の問題を修正します。重複する連絡先をマージし、命名規則を標準化し、保持ポリシーで必要な期間よりも古いチケットをアーカイブします。移行後よりもソースシステムでデータをクリーンアップする方がはるかに簡単です。

ステップ2：移行方法を選択する

Zendesk移行を実行するには、主に3つのオプションがあります。それぞれが異なる状況に適しています。

オプションA：ネイティブZendesk API

特定のカスタマイズニーズを持つ技術チームに最適です。

メリット： プロセスを完全に制御できる、サードパーティのコストがかからない、複雑な変換を処理できる。

デメリット： 開発リソースが必要、レート制限とエラー回復を自分で処理する必要がある、多大な時間投資。

ZendeskのTicket Import APIを使用すると、履歴タイムスタンプ付きのチケットを作成し、元の作成日と解決日を保持できます。ただし、添付ファイルの処理、レコード間の関係の維持、失敗したリクエストの再試行のためのロジックを構築する必要があります。

オプションB：サードパーティの移行ツール

サポート付きのノーコードソリューションを求めるチームに最適です。

Help Desk Migration は、ガイド付き移行ウィザードを備えたZendesk Marketplaceアプリを提供しています。無料のデモでは、20件のチケットと20件のナレッジベースの記事を移行できるため、コミットする前にセットアップを検証できます。料金は1,000レコードあたり約100ドルから始まり、非線形にスケールします（10,000レコードの費用は約514ドルです）。90以上のプラットフォームをサポートし、デルタ移行（最初の転送後に更新をキャッチ）やインターバル移行（営業時間中に一時停止）などの機能が含まれています。

Import2 は、最大100件のチケットの無料サンプル移行を提供するクラウドベースのサービスを提供しています。2011年以来50,000人以上の顧客にサービスを提供しており、1日あたり約50,000件のチケットを処理しています。Import2は、結果に満足できない場合に返金保証を提供しています。

メリット： 構築済みのフィールドマッピング、組み込みのエラー処理、完全な移行前にテストするためのデモモード、利用可能なカスタマーサポート。

デメリット： コストはデータ量に応じてスケールする、一部の高度なカスタマイズにはプロフェッショナルサービスのアドオンが必要になる場合がある。

オプションC：プロフェッショナルサービス

複雑な要件を持つ大企業に最適です。

Zendesk Professional Services は、エンタープライズ顧客向けのガイド付き移行を提供しています。Premium Plus や Gravity CX などのサードパーティコンサルタントは、カスタムスクリプトと専任のプロジェクト管理による大規模なZendesk移行を専門としています。

メリット： ホワイトグローブサービス、エッジケース向けのカスタム開発、専任のプロジェクト管理、最小限の社内リソース要件。

デメリット： 最もコストの高いオプション、リードタイムが長くなる可能性がある。

方法の比較

ステップ3：テスト移行を実行する

最初にテストせずに完全な移行を実行しないでください。セットアップを検証する方法を次に示します。

デモ移行を実行します。 Help Desk Migration は、20件のチケットで無制限の無料デモを提供しています。Import2は、無料サンプルで最大100件のチケットを提供しています。これを使用して、フィールドマッピングを確認し、問題を特定します。

テストする内容：

• チケットの整合性（件名、説明、ステータス、優先度）
• 添付ファイルの処理（サイズ制限、ファイルタイプ）
• カスタムフィールドマッピング（ドロップダウン値、日付、テキストフィールド）
• ユーザーと組織の関係
• ナレッジベースの記事のフォーマット
• 内部メモとサイドカンバセーション

結果を検証します。 移行されたレコードの少なくとも10％をスポットチェックします。チケット番号が一致し、添付ファイルが正しく開き、カスタムフィールドが期待どおりに入力されていることを確認します。検索機能をテストして、移行されたデータが検出可能であることを確認します。

マッピングを繰り返します。 フィールドが正しくマッピングされていない場合は、構成を調整して別のデモを実行します。これが、無制限のデモ実行が重要な理由です。あるエンタープライズチームは、複雑なフィールドマッピングを完璧にするまでに12回のデモを実行しました。

タイムライン： テストと調整に1〜2週間を計画します。このフェーズを急ぐと、ほとんどの移行がうまくいきません。

ステップ4：完全な移行を実行する

テストが完了したので、いよいよ本番です。

戦略的にスケジュールします。 トラフィックの少ない期間中に移行を計画します。ほとんどの企業にとって、これは週末または夜間を意味します。月末、四半期末、または既知の繁忙期は避けてください。

明確に伝えます。 移行スケジュールについてチームに通知します。次のことについて期待を設定します。

• ソースシステムが読み取り専用になる時期
• 移行にかかる時間
• 通常の業務を再開できる時期
• 問題が発生した場合の連絡先

移行を実行します。 ツールのプロセスまたはカスタムスクリプトに従います。進捗状況を定期的に監視します。ほとんどのツールは、レコード数とエラーを示すリアルタイムダッシュボードを提供しています。

デルタ移行を検討します。 移行中にソースシステムを実行し続ける必要がある場合は、メインの移行が開始された後に作成または更新されたチケットをキャッチするために、デルタ移行を計画します。Help Desk Migration には、これがSignatureパッケージに含まれています。

エラーを監視して処理します。 レート制限（Zendeskは通常、API経由で1時間あたり700件のチケットを許可します）、失敗した添付ファイル、またはデータ検証エラーに注意してください。失敗したレコードを再試行するための計画を立ててください。

移行後のチケットがZendeskをどのように流れるかのコンテキストについては、Zendeskのチケット処理の仕組みに関するガイドをご覧ください。

ステップ5：移行後の検証と最適化

データ転送が完了しても、作業は終わりではありません。

検証チェックリストを実行します。

• ソースとターゲットの間でチケット数が一致する
• すべてのエージェントが正しい権限でログインできる
• ナレッジベースの記事が画像とともに正しく表示される
• カスタムフィールドに期待される値が含まれている
• 検索で移行されたレコードが返される

自動化を再アクティブ化します。 トリガー、自動化、SLAポリシーを再度オンにします。ワークフローを通じていくつかのチケットをテストして、正しく起動することを確認します。

統合を再接続します。 サードパーティツール（CRM、チャット、電話システム、レポートツール）のAPIキーとWebhook URLを更新します。

チームをトレーニングします。 完璧なデータ移行を行っても、エージェントは新しいシステムを理解する必要があります。次のことに焦点を当てたトレーニングセッションをスケジュールします。

• 移行されたチケットの検索
• 新しいワークフローの理解
• ターゲットプラットフォームで利用可能な新機能の使用

問題を監視します。 最初の1〜2週間は、チケット数、応答時間、およびエージェントのフィードバックを注意深く監視します。小さな問題は早期に修正する方が簡単です。

移行後のエージェントのオンボーディングをスピードアップしたい場合は、eesel AI Copilot が、過去のチケットとヘルプセンターのコンテンツに基づいてエージェントの応答を下書きできます。

一般的な移行の落とし穴とその回避方法

タイムラインの過小評価。 バッファ時間を組み込みます。週末にかかるはずの移行は、予期しない問題が発生すると、1週間に及ぶことがよくあります。最悪の事態を想定し、最善を期待してください。

APIレート制限。 ZendeskのAPIには制限があります（通常、チケット操作の場合は1分あたり700リクエスト）。100,000件のチケットを移行する場合、これは最大速度で約143分間のAPI時間になります。これをタイムラインに組み込んでください。

重複レコード。 移行前に連絡先と組織を重複排除します。2つのシステム間で重複を修正することは、1つのシステムで修正するよりも指数関数的に困難です。

統合の破損。 ヘルプデスクに接続するすべての統合をマッピングします。それぞれが新しいシステムにどのように再接続するかを計画します。移行が完了したと宣言する前に、個別にテストしてください。

エージェントの混乱。 データは完璧に移行できますが、エージェントが新しいシステムの使用方法を知らない場合、顧客は苦しみます。トレーニングとドキュメントに投資してください。

データ損失の不安。 すべてを検証するまで、ソースシステムを読み取り専用モードに保ちます。移行が100％成功したと確信するまで、削除またはダウングレードしないでください。

移行後にサポート業務を合理化する

移行は単にデータを移動することだけではありません。チームの働き方を改善する機会です。

最適化し、単に複製しないでください。 古いワークフローは古いシステムでは意味がありました。新たに開始することで、より良いプロセスを設計できます。すべての自動化を見直し、「これはまだ役に立ちますか？」と自問してください。

AIの強化を検討します。 データがZendeskに入ると、AIツールはチームがより効率的に作業するのに役立ちます。eesel AIでは、Zendeskと統合して、過去のデータから学習するAI搭載のチケット処理を提供しています。

仕組みは次のとおりです。eesel AI Copilot がエージェントがレビューする応答を下書きすることから始めます。AIがあなたのトーンとポリシーを学習するにつれて、一般的なチケットの自律的な解決のために eesel AI Agent にレベルアップできます。この段階的なアプローチにより、制御を引き渡す前に自信を構築できます。

当社の料金 はわかりやすく、最大1,000回のAIインタラクションで月額299ドルで、シートごとの料金はかかりません。既存のZendeskセットアップと並行して、中断することなく試すことができます。

移行は、より良いサポート業務を構築するチャンスです。それを活用してください。