SQLデータベースやCSVで管理しているFAQは、項目名を合わせるだけでZendeskへ移せるとは限りません。
FAQの本文だけでなく、カテゴリ、公開範囲、添付ファイル、言語、URL、更新履歴などが現在の仕組みと結び付いているためです。移行前にデータの構造と運用を確認せず、記事の登録から始めると、公開後に検索しにくい、更新できない、リンクが切れるといった問題が起こります。
この記事では、既存FAQをZendeskのナレッジベースへ移行できるか判断するための7つの確認点と、移行方法の選び方をお伝えします。
FAQ移行の要点
- FAQ本文だけでなく、分類、権限、添付ファイル、URL、更新方法まで確認する
- 既存項目をZendeskのカテゴリ、セクション、記事へどう対応させるか決める
- 少量なら手作業、大量または更新が続く場合はAPIや段階移行を検討する
- データをすべて移すことが、必ずしも最適とは限らない
- AIが参照する外部ナレッジと、Zendeskの記事として移行することは分けて考える
ZendeskへのFAQ移行で行うこと
Zendeskのヘルプセンターでは、記事をカテゴリ、セクション、記事の階層で管理します。既存システムのフォルダ、分類コード、製品、対象者などを、そのまま同じ形で持ち込めるとは限りません。
移行では、主に次の作業が必要です。
- 既存データの項目と関係を確認する
- Zendesk側のカテゴリ、セクション、記事へ対応付ける
- 本文やリンクをZendeskで表示できる形に変換する
- 公開範囲、言語、ラベルなどを設定する
- テスト環境または限定した範囲で登録結果を確認する
- 本番移行後の更新方法と担当者を決める
記事数だけで難易度を判断するのではなく、1件の記事がどのデータと結び付いているかを見ることが重要です。
移行前に確認したい7つの項目
1. データ構造
最初に、FAQを構成するテーブルやCSVの列を確認します。質問、回答、カテゴリだけでなく、公開状態、表示順、対象製品、ラベル、作成日、更新日、言語などが別のテーブルに分かれている場合があります。
確認したい内容は次のとおりです。
- FAQを一意に識別するIDがあるか
- カテゴリや製品との関係がどの項目で管理されているか
- 1つのFAQが複数の分類に属しているか
- 公開、非公開、下書き、終了などの状態があるか
- 文字コード、改行、空欄、重複データに問題がないか
SQLからCSVを出力できても、複数テーブルの関係を再現できなければ、移行時に情報が欠ける可能性があります。
2. 本文と表示形式
回答本文がプレーンテキストかHTMLか、独自の記法を含むかを確認します。表、見出し、リンク、装飾、埋め込みコンテンツが多いほど、変換と表示確認が必要です。
特に、本文中の相対URL、独自タグ、JavaScript、インラインスタイルは、そのままでは正しく表示されない場合があります。代表的な記事を使って、変換後の表示を先に試すと安全です。
3. 画像と添付ファイル
画像やPDFがデータベース内に保存されているのか、別のストレージにあるのか、URLだけが記録されているのかを確認します。
記事本文を移せても、画像の参照先が旧環境のままでは、旧システム停止後に表示できなくなります。ファイル名の重複、認証が必要な画像、容量の大きい添付ファイルも移行難易度に影響します。
4. 公開範囲と権限
一般公開、会員限定、社内限定、契約プラン別など、現在の公開条件を確認します。既存システムに細かな権限条件がある場合は、Zendeskのユーザーセグメントや権限設計で再現できるかを検討します。
移行できるかだけでなく、移行後も意図した利用者だけが閲覧できるかを確認する必要があります。
5. 多言語と翻訳の関係
日本語と英語が別レコードなのか、共通IDで結び付いているのかを確認します。翻訳の対応関係が分からない場合、同じ記事の翻訳として登録できず、言語ごとに別の記事になる可能性があります。
言語コード、元記事との関係、翻訳の公開状態、更新時の同期方法まで確認します。
6. URLとSEO
現在公開しているFAQには、検索結果や外部サイトからアクセスされているURLがあるかもしれません。URLが変わる場合は、重要なページを特定し、リダイレクトやリンク更新を計画します。
検索流入がある記事を一律で統合・削除すると、利用者が必要な情報へ到達できなくなる可能性があります。アクセス数、問い合わせへの影響、記事の重複を確認して移行対象を決めます。
7. データ品質と移行後の運用
移行は、古いFAQをそのまま複製する作業ではありません。重複、更新されていない回答、担当者不明の記事、同じ質問への異なる回答が含まれていないかを確認します。
公開後に誰が更新し、誰が承認し、どのタイミングで見直すかも必要です。記事を登録できても、運用が決まっていなければ、時間とともに情報の信頼性が下がります。
移行方法の選び方
手作業で移行する
対象が少なく、本文の修正や統合を同時に行う場合に向いています。1件ずつ内容を確認できる一方、件数が多い場合は時間と入力ミスが増えます。
APIで移行する
記事数が多く、項目の対応関係が明確な場合は、ZendeskのHelp Center APIを使った登録を検討できます。繰り返し実行できるように処理を作れますが、データ変換、エラー記録、再実行、登録後の検証が必要です。
段階的に移行する
利用頻度が高い記事や、特定の製品カテゴリから先に移します。小さな範囲で分類や表示を確認し、その結果を次の移行へ反映できるため、全件一括よりもリスクを抑えやすい方法です。
外部ナレッジへの接続と記事移行の違い
Zendeskでは、外部のナレッジソースをAIが参照できるよう接続する方法もあります。ただし、外部データを参照できる状態にすることと、Zendeskのナレッジベースの記事として登録・運用することは同じではありません。
利用者向けのFAQサイトをZendeskで公開したいのか、AIが回答根拠として参照できればよいのか、担当者が社内情報を検索できればよいのかによって、適した方法は変わります。
Zendeskへ移行しない選択肢
次のような場合は、既存の管理方法を維持する、別のナレッジ基盤を選ぶ、外部ナレッジとして接続するといった選択肢も検討できます。
- 現在の権限やワークフローが複雑で、Zendesk上では再現しにくい
- FAQ以外の大量の文書と一体で管理する必要がある
- 既存システムが他の業務プロセスと強く結び付いている
- 公開サイトではなく、AIや社内検索からの参照が主目的である
製品を先に決めるのではなく、誰がどこで情報を使い、誰が更新するかを基準に判断します。
既存FAQ Zendesk移行診断
KIRIKOMIでは、SQLデータベースから出力したデータやCSVを確認し、Zendeskへの移行可否、難易度、方法を無料でお伝えする「既存FAQ Zendesk移行診断」を提供します。
診断で確認するもの
- 主要なFAQデータ1件
- テーブル定義と総件数
- 個人情報を除外・匿名化した代表データ30〜50件
- CSV、Excel、JSONなどの出力データ
- 現在のFAQ画面や更新方法が分かる資料
SQLデータベースへ直接接続するのではなく、ご提供いただいた定義情報と出力データを確認します。
診断結果
- Zendeskへ移行できるか
- 移行難易度を低・中・高の3段階で判定
- 既存項目とカテゴリ、セクション、記事の対応案
- 手作業、API、段階移行から適した方法を提案
- 移行前に必要なデータ整備と注意点
- 現行維持や他の管理方法を含む選択肢
- 移行を進める場合の概算範囲
初回ヒアリングは30分、結果報告は45分を目安とし、データ受領から5営業日程度でご報告します。
診断には、データの修正、変換プログラムの作成、テスト・本番環境への登録、画像の一括移行、記事の書き直し、テーマ制作、リダイレクト設定、全件テストは含みません。必要な場合は、診断後に別途ご相談いただけます。
サービスの範囲は、FAQ・ナレッジ・運用改善の「既存FAQ Zendesk移行診断」でもご確認いただけます。
Q&A
Zendeskをまだ契約していなくても相談できますか？
はい。契約前でも、現在のFAQデータと運用を確認し、Zendeskが適しているかを含めてお伝えします。
データが十分に整っていなくても診断できますか？
はい。テーブル定義、総件数、代表データなど、確認できる範囲から移行上の課題と追加で必要な情報をお伝えします。
診断後に移行を依頼する必要はありますか？
いいえ。診断結果のみをご利用いただけます。移行やデータ整備が必要な場合は、別途ご相談いただけます。
個人情報を含むデータは必要ですか？
診断に個人情報は必要ありません。氏名、メールアドレス、注文情報などは除外または匿名化してご提供ください。
まとめ
既存FAQの移行では、記事数よりも、データ同士の関係、表示形式、権限、URL、更新方法が難易度を左右します。全件を移す前に代表データで確認し、移行後の利用目的に合う方法を選ぶことが重要です。
Zendeskへ移行できるか分からない段階でも、Zendesk移行の無料相談窓口からご相談いただけます。契約前の技術的な疑問や、自社で進める移行についても歓迎します。