FreshdeskからZendeskへの移行：2026年完全ガイド

ヘルプデスクをFreshdeskからZendeskに移行することは、賑やかなオフィスを移転するようなものです。何年にもわたる顧客との会話、チケット履歴、組織の知識がすべて、そのままの状態で到着する必要があります。間違えると、サポートチームは数週間もコンテキストを探し回ることになります。正しく行うと、Zendeskのエンタープライズグレードの機能を、滞りなく利用できるようになります。

このガイドでは、FreshdeskからZendeskへの移行プロセス全体について説明します。開始前に監査すべきこと、状況に合った移行方法、移行の実行方法、そして移行後の新しいセットアップを最適化する方法について解説します。

移行前の計画：監査とマッピング

FreshdeskからZendeskへの移行を成功させるには、インポートツールに触れるずっと前から準備が必要です。何を移行するのか、そしてシステム間でどのようにマッピングされるのかを正確に把握する必要があります。

データインベントリチェックリスト

まず、Freshdeskアカウント内のすべてをカタログ化します。

• チケット：オープンとクローズの両方、完全な会話履歴を含む
• 連絡先と会社：顧客プロファイルと組織の関係
• エージェントプロファイル：チームのユーザーアカウントとロール
• ナレッジベース記事：カテゴリ、セクション、およびすべてのコンテンツ
• カスタムフィールド：作成したチケット、連絡先、および会社のフィールド
• タグ：チケットの分類とルーティングの方法
• 添付ファイルとインライン画像：チケットに関連付けられたファイル
• マクロと自動化：参照用（これらは再構築され、移行されません）

データ構造のマッピング

FreshdeskとZendeskでは、異なる用語が使用されています。以下をマッピングする必要があります。

マッピングのステップは、ほとんどの移行がつまずくところです。ここで時間をかけてください。カスタムフィールドがどのように変換されるか、どのタグを保持する必要があるか、そしてチケットのステータスがどのように一致するかを文書化します。この分析をスキップすると、データは技術的にはそのまま到着しますが、文脈的には壊れてしまいます。

移行方法の選択

FreshdeskからZendeskへの移行には、主に3つのアプローチがあります。適切な選択は、チケットの量、技術リソース、タイムライン、および予算によって異なります。

方法1：プロフェッショナルな移行サービス

最適なケース： 大量のチケット（50,000件以上）、限られた技術リソース、またはタイトなスケジュール

Help Desk MigrationやHelpandoなどのサービスは、プロセス全体を処理します。両方のプラットフォームに接続し、データをマッピングし、テスト移行を実行し、完全な転送を実行します。

メリット：

• コーディングは不要
• テスト済みのプロセスにより、エラーのリスクが軽減されます
• 問題が発生した場合のサポートが含まれています
• デルタ移行オプション（最初の転送後に新しいチケットを同期）

デメリット：

• DIYよりもコストが高い
• プロセスに対する直接的な制御が少ない
• サードパーティのタイムラインへの依存

価格： ボリュームベース。たとえば、Help Desk Migrationは、標準的な条件下で1,000レコードあたり約100ドル、10,000レコードあたり514ドルを請求します。また、サービスティアも提供しています：Standard（無料、9/5サポート）、Premium（最大50,000レコード、16/5サポート）、およびSignature（デルタおよびインターバルオプションを備えた大規模な移行）。

方法2：自動化された移行ツール

最適なケース： 制御と利便性のバランスを求める中規模チーム

Klamp.ai（Freshworks Marketplaceで入手可能）などのツールは、データのマッピングと移行のためのセルフサービスインターフェイスを提供します。接続を構成し、フィールドマッピングを設定し、ウィザードを通じて移行を実行します。

メリット：

• 視覚的なフィールドマッピング
• 完全な移行前のテスト機能
• DIY APIアプローチよりも高速
• コーディングは不要

デメリット：

• 構成は依然として必要
• 複雑なカスタムフィールドに制限がある場合があります
• 完全なサービスよりも手厚いサポートはありません

方法3：DIY API移行

最適なケース： 特定のカスタマイズニーズを持つ技術チーム

Zendeskは、移行専用のTicket Import APIを提供しています。エンドポイントPOST /api/v2/imports/ticketsは、履歴タイムスタンプ、コメント、および添付ファイルを含むチケットを受け入れます。一括インポートでは、POST /api/v2/imports/tickets/create_manyを介してリクエストごとに最大100件のチケットを受け入れます。

メリット：

• データ変換の完全な制御
• 継続的なサービス料金は不要
• エッジケースのカスタムロジック
• 正確なタイムスタンプと作成者を保持できます

デメリット：

• 開発リソースが必要
• 構築とテストに時間がかかる
• 適切な検証がない場合のエラーリスク
• レート制限とエラー回復を処理する必要があります

オープンソースのリソースが役立ちます。GitHubのfd2zd Rubyスクリプトは、コードに慣れているチーム向けのスターターフレームワークを提供します。

APIに関する主な考慮事項：

• インポートされたチケットではトリガーは実行されません
• インポートされたチケットでは、ZendeskのメトリックとSLAは計算されません
• 添付ファイルは個別にアップロードし、トークンで参照する必要があります
• archive_immediatelyパラメーターを使用すると、クローズされたチケットを直接アーカイブに送信できます（750,000件以上のチケット移行に役立ちます）

移行の実行：ステップバイステップ

方法を選択したら、この手順に従って中断を最小限に抑えます。

ステップ1：Zendeskの基盤をセットアップする

データをインポートする前に、Zendeskがデータを受け取れるように構成します。

• エージェント、グループ、およびロールを作成します
• 営業時間とSLAポリシーを設定します
• カスタムフィールドとチケットフォームを構成します
• 必要なアプリ（Jira、Slackなど）をインストールします
• 移行中に新しいエンドユーザーへのウェルカムメールを無効にします
• テスト用のサンドボックス環境を作成します

この足場により、インポートされたデータがリンクする有効な参照が確実に存在します。

ステップ2：Freshdeskデータを準備する

• チケット、連絡先、および会社をエクスポートします
• 重複と古いレコードをクリーンアップします
• APIアクセス資格情報を確認します
• 再構築する必要があるカスタムワークフローを文書化します

ステップ3：正しい順序で移行する

データのリレーションシップが重要です。次の順序でインポートします。

1. 会社/組織：チケットはこれらを参照します
2. 連絡先/ユーザー：チケットもこれらを参照します
3. チケットスキーマ：チケットの前にカスタムフィールドが存在する必要があります
4. チケットと会話：コアデータ
5. ナレッジベース記事：いつでも実行できます
6. CSATデータ：該当する場合

ステップ4：検証とテスト

移行後、以下を確認します。

• システム間でチケット数が一致する
• 添付ファイルとインライン画像にアクセスできる
• エージェントの割り当てが正しく転送された
• ナレッジベースのフォーマットがそのまま残っている
• カスタムフィールドの値が期待どおりに入力された
• 関連チケット間のリンクが機能する

優先度の高いチケットと最近の会話でスポットチェックを実行します。ルーティングと割り当てが機能することを確認するために、いくつかのエージェントワークフローをテストします。

移行後：eesel AIでZendeskのセットアップを最適化する

移行により、データがZendeskに移行されます。次に、そこから価値を得る必要があります。

ここで私たちがお手伝いできます。eesel AIでは、Zendeskと統合して、移行されたデータを即座に生産性の向上に変えます。その方法は次のとおりです。

自律的な解決のためのAIエージェント。 当社のAIエージェントは、最前線のサポートチケットをエンドツーエンドで処理し、移行されたチケット履歴から学習して、人的介入なしに問題を解決します。成熟したデプロイメントでは、最大81％の自律的な解決が実現され、通常2か月以内にペイバックが得られます。

より迅速な応答のためのAIコパイロット。 人間の注意が必要なチケットの場合、当社のAIコパイロットは、ナレッジベースと過去の解決策に基づいて返信を作成します。エージェントはレビューし、必要に応じて編集して送信します。エージェントがフィードバックを提供するにつれて、下書きは時間の経過とともに改善されます。

キュー管理のためのAIトリアージ。 コンテンツに基づいて、チケットを自動的にタグ付け、ルーティング、優先順位付け、およびクローズします。これにより、手動でソートしなくてもキューをクリーンに保つことができます。

移行後にeesel AIを追加する利点：完全なZendesk履歴からすぐに学習できます。ヘルプデスクに接続すると、過去のチケット、ヘルプセンターの記事、マクロ、および接続されているドキュメント（Confluence、Googleドキュメント、Notion）を吸収して、ビジネスコンテキストを初日から理解できます。

eesel AIがZendeskとどのように連携するかを確認するか、AIエージェントおよびAIコパイロット製品を直接調べてください。

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

慎重な計画を立てても、これらの問題は多くのチームをつまずかせます。

テストのスキップによるデータ損失。 常に代表的なサンプルでテスト移行を実行してください。完全な移行をコミットする前に、カスタムフィールドが正しく入力され、添付ファイルが転送され、リレーションシップがそのまま残っていることを確認してください。

チケットリレーションシップの破損。 FreshdeskチケットIDはZendeskに転送されません。元のIDは、参照用にカスタムフィールドまたはタグに保存できますが、チケット間のリンクを更新する必要があります。

タイムスタンプの混乱。 ZendeskのインポートAPIでは、履歴のcreated_atおよびupdated_at時間を設定できますが、1970年より前の日付は切り上げられます。履歴データが有効な範囲内にあることを確認してください。

エージェントの作成者の問題。 FreshdeskエージェントがZendeskに存在しない場合、チケットはAPIユーザーによって作成されたものとして表示される場合があります。移行前にエージェントIDをマッピングするか、プレースホルダーアカウントを作成します。

ワークフローの中断。 自動化、トリガー、およびSLAは移行されません。Zendeskのフレームワークでこれらを再構築する時間を計画します。移行を、ワークフローを簡素化および改善する機会として活用してください。

ストレージ制限。 Zendeskプランには、ファイルストレージ制限があります（10 GBベース+エージェントごとの割り当て）。大規模な添付ファイルライブラリでは、クリーンアップまたはストレージのアップグレードが必要になる場合があります。

Zendesk移行を最大限に活用する

FreshdeskからZendeskへの移行を成功させるには、徹底的な移行前計画、リソースに適した実行方法の選択、そして勝利を宣言する前にすべてを検証するという3つの要素が重要です。

最後のチケットがインポートされたときに作業が終わるわけではありません。チームはZendeskのインターフェイスに関するトレーニングを受ける必要があります。ワークフローを再構築する必要があります。そして、これはFreshdeskでは利用できなかったAI機能を追加する絶好の機会です。

移行を計画していて、新しいZendeskセットアップからの価値を加速したい場合は、eesel AIをチームに招待してください。数分で移行されたデータから学習し、自律的な解決、下書きの返信、またはインテリジェントなトリアージを通じて、エージェントをすぐに支援を開始できます。