社内wiki移行ガイド｜ツール別の注意点と手順

最終更新日:2026年9月7日

社内wikiの乗り換えで最初につまずくのは、「今あるデータをそのまま移せるのか」という一点です。本文のテキストは移せても、タグの階層構造・グループの権限設定・画像の参照先・記事同士のリンクは、移行元と移行先の仕様差によってこぼれ落ちることがあります。

社内wikiの移行では、先に「移せないもの」を把握しておくことが重要です。この記事では、移行前の確認項目、移行元ツール別の注意点、DocBaseへの移行手段、移行後の見直しポイント、そして実際の移行事例で報告されている失敗と対策を整理します。読み終えるころには、自社の移行にどれくらいの手間がかかり、どこに人手が必要になるかを見積もれる状態になります。

社内wikiの移行は「何が移せないか」を先に確認すると失敗を防ぎやすくなります

社内wiki移行の成否は、移行元ツールのエクスポート仕様と、移行先ツールのインポート仕様の「差分」で決まります。この差分を移行作業の前に洗い出しておくことが、もっとも確実な失敗回避策です。

Markdown形式でエクスポートできるツールであれば、本文テキストは比較的移行しやすい部分です。ただし、独自記法・埋め込みコンテンツ・内部リンクは変換や修正が必要になる場合があります。そして問題になりやすいのは、本文以外の情報です。

移行で失われやすい情報

情報の種類	失われやすい理由
画像・添付ファイル	エクスポートしたMarkdownが移行元のURLを指したままになることがある
記事同士のリンク	移行元のURLは移行後に解決できなくなる
権限・公開範囲	ツールごとに権限モデルが異なり、そのまま再現できない
タグの階層構造	階層タグに対応していないツールでは平坦化される
外部共有リンク	移行先で発行し直しになり、共有先への再連絡が必要になる
作成者・作成日時	インポート方式によっては実行者・実行日時で上書きされる

移行作業を「データのコピー」だと考えると、この一覧の項目が後から問題として噴き出します。移行前に、残す情報・統合する情報・移行しない情報を決めておくと、移行後の手戻りを減らしやすくなります。

社内wikiの移行を検討する4つのきっかけ

社内wiki移行の相談が発生する背景は、大きく4つのパターンに分かれます。自社がどのパターンに当てはまるかを言語化しておくと、移行先の選定基準がはっきりします。

①契約条件やプランが自社の使い方と合わなくなった

利用人数が増減した、ストレージ容量が足りなくなった、必要のない機能まで含んだプランを契約している、といったケースです。ユーザー単価制のツールでは、閲覧中心のメンバーにも費用が発生する場合があるため、全社展開を想定するときは料金体系を確認しておく必要があります。

②AI活用への対応が追いついていない

社内のナレッジをAIに参照させたい、というニーズは近年の移行理由として増えています。具体的には、MCP（Model Context Protocol）による外部AIアプリとの連携ができるか、AIに渡す情報の範囲を管理できるか、AIの利用履歴を確認できるか、といった観点です。

なお、AI利用の制御は「どの単位で制御できるか」で提供形態が分かれることがあります。DocBaseの場合、ドキュメント単位でAIの利用対象から除外することと、AI利用履歴を確認することは標準機能です（ドキュメント単位の除外は、メモに no-ai タグを付けて設定します）。一方、グループ単位でのAI利用制限はセキュリティパック（有料オプション）の対象機能です。移行先を比較する際は、必要な制御の単位まで含めて確認してください。

③導入したが使われていない・検索しても見つからない

情報は溜まっているのに、必要なときに見つからない状態です。この場合、ツールの移行だけでは解決しません。移行と同時に、グループ設計・タグ設計・ドキュメントのタイトル・本文の粒度を見直すと、検索性を改善しやすくなります。

④管理体制やセキュリティ要件が変わった

ISO 27001（ISMS）認証の有無、SAML SSOの必須化、IPアドレス制限の導入など、情報システム部門の要件が厳しくなったタイミングです。既存ツールが要件を満たせない場合、移行が現実的な選択肢になります。

こうした統制機能は、標準機能として提供されるか有料オプションかがツールによって異なります。DocBaseの場合、暗号化とISO 27001認証は標準ですが、SAML SSO・IPアドレス制限・2段階認証の必須化・監査ログはセキュリティパック（有料オプション）の対象機能です。

なお、移行を検討する際は「今のツールの不満」だけでなく「移行にかかる工数」も同じ天秤に載せてください。次の章のチェックリストが、その見積もりの材料になります。

移行前に確認すべき5つのこと

移行作業に着手する前に、以下の5項目を数字と実物で確認してください。ここが曖昧なまま進めると、途中で作業が止まったり、移行後の手戻りが増えたりします。

①データ量（ドキュメント数と総容量）

確認すべきこと：ドキュメント数（DocBaseでいうメモ件数）と、添付ファイルを含めた総容量です。

件数は特に重要です。インポート機能には、ツールや方式によって件数の上限・制約があります。たとえばesaの公式ヘルプでは、Qiita Teamからのインポートについて「APIのみでは10,000件以上のインポートは不完全となる」ため、エクスポートしたZIPファイルの利用が必要だと明記されています。NotePMの公式ヘルプでも、Qiita Teamの記事が10,000件以上ある場合はすべての記事がインポートされない可能性があると案内されています。大量データを移行する場合は、移行元・移行先それぞれのヘルプで制限を確認してください。

総容量は、移行先のストレージ容量に収まるかの判断材料です。DocBaseの場合、プランごとに割り当てられた容量に加えて、追加ストレージを10GBあたり500円（税抜）で追加できます。

②添付ファイルと画像

確認すべきこと：画像がどこに保存され、エクスポート時にどう出力されるかです。

リンク切れや手動修正が起きやすい箇所です。エクスポートしたMarkdownファイル内の画像URLが移行元のドメインを指したままになっていると、移行後に旧ツールを解約した瞬間、すべての画像がリンク切れになります。実際にQiita TeamからNotionへ移行した事例でも、画像ファイルは手動で差し替える必要があったと報告されています。

エクスポートしたファイルを1つ開き、画像の記述が https://旧ツールのドメイン/... になっていないかを必ず目視で確認してください。

③権限構造（グループと公開範囲）

確認すべきこと：現在のグループ構成と、各グループに誰が所属しているかの一覧です。

権限モデルはツールごとに設計思想が異なるため、そのまま移すことはできません。移行時にどう変換されるかは、移行先の仕様を事前に読んでおく必要があります。

特に注意が必要なのは、閲覧制限のあるコンテンツの扱いです。esaの公式ヘルプには、esa側にメンバーごとの閲覧権限制限がないため、Qiita Teamのシークレットグループのコンテンツもすべてインポートされる、と明記されています。移行先の権限モデル次第では、意図せず公開範囲が広がることがあります。

④外部共有リンク

確認すべきこと：社外に共有しているURLがどれだけあるかです。

取引先や顧客に共有しているURLは、移行後に使えなくなる可能性があります。旧ツールを解約する場合やURL体系が変わる場合は、共有先への再連絡が必要です。リストアップは早めに済ませてください。移行対象から外して旧ツールに残す判断もあり得ます。

⑤Markdownの方言差

確認すべきこと：移行元と移行先が対応しているMarkdown記法の差です。

Markdownには標準仕様であるCommonMarkと、GitHub Flavored Markdown（GFM）で追加された表・打ち消し線・チェックボックスなどがあります。さらに各ツールが独自に拡張した記法があり、この部分が移行時に崩れます。

実例として、クラウドワークスの技術ブログでは、Qiita TeamからNotionへ移行した際に「Notionは見出しが3階層までしか対応していない」「コードブロックのファイル名表示に対応していない」という非互換に個別対応する必要があったと報告されています。

移行前に、自社でよく使っている記法をリストアップし、移行先の記法ドキュメントと突き合わせてください。DocBaseのMarkdownはCommonMark準拠で、表・打ち消し線・チェックボックスなどのGFM相当の記法に加え、画像サイズ指定、<details> による折りたたみ、TeX記法、Mermaid、PlantUML、脚注などの独自拡張に対応しています。詳細はDocBaseのMarkdown記法と書き方を確認するでご覧いただけます。

移行元ツール別｜移せるもの・移せないもの

ここからは移行元ツール別に、公式ドキュメントで確認できる仕様と、公開されている移行事例から分かる注意点を整理します。

なお、各ツールの仕様は更新されます。実際の移行前には必ず各サービスの公式ヘルプで最新の仕様を確認してください。

どの移行元でも、移行後に実物で確認すべき4項目

移行元がどのツールであっても、次の4項目は公式ドキュメントだけでは判断できません。本番移行の前に少量のテストインポートを行い、実物で確認してください。

確認項目	見るべきこと
画像・添付ファイル	移行後のドキュメントで実際に表示されるか。URLが移行元を指したままになっていないか
記事同士のリンク	クリックして移行先のドキュメントに到達するか
公開範囲・グループ	意図しない範囲に公開されていないか。非公開だったものが見えていないか
件数	移行元と移行先で件数が一致しているか。取りこぼしがないか

Qiita:Teamから移行する場合

DocBaseは管理画面からのインポートに対応しています。Qiita:Team側で read_qiita_team スコープのアクセストークンを発行し、DocBaseの設定画面でチームURLとトークンを入力すると処理が始まります。

DocBaseへのインポート時の挙動（公式ヘルプで確認できる内容）

項目	挙動
実行できる人	オーナー・管理者のみ
グループに属していたメモ	同名のグループを新規作成して移行される
グループ未所属のメモ	サービス名のグループを作成して移行される
公開範囲	上記いずれも全員には公開されない
重複メモ	インポートされない
完了通知	ドキュメントごとに成功・失敗が表示され、完了時に確認メールが届く

なお、Qiita:Teamからesaへ移行する場合は、記事・コメント・添付ファイル・タグ（階層タグは parent/child から #parent-child へ変換）・プロジェクトとグループ（esaのカテゴリへ変換）が対象になると公式ヘルプに記載されています。移行先によって変換ルールが異なるため、比較検討中の方は各社のヘルプを読み比べてください。

esaから移行する場合

DocBaseは管理画面からのインポートに対応しています。esaの管理画面でAPIトークンを取得し、チームURLと合わせてDocBaseの管理画面に入力する流れです。管理画面から操作できるため、通常のインポートではプログラミングの知識は不要です。

より細かい制御が必要な場合は、スクリプトによるインポートも可能です。DocBaseの公式ヘルプには、esaからエクスポートしたMarkdownファイルをDocBaseへ投稿するRubyスクリプトの例が公開されています。ただしDocBaseのAPIには1時間あたり300リクエストのレート制限があるため、短時間に300リクエストを超える可能性がある場合は、待機処理を組み込んでください。

※ DocBaseの公式ヘルプで確認できるのは、esaが管理画面インポートの対象であることまでです。 タグ・添付ファイル・公開範囲が項目別にどう変換されるかは公開されていないため、前掲の4項目をテストインポートで確認してください。

Kibelaから移行する場合

DocBaseは管理画面からのインポートに対応しています。DocBaseのヘルプセンターには「現在DocBaseではesa、Qiita:Team、Kibelaに対応しています」と明記されており、この3サービスは管理画面から操作できます。

Kibelaからの移行では、エクスポート時の権限に注意してください。Kibelaから他サービスへ移行した事例では、エクスポートのダウンロードリンクが管理者のみ使用可能だったため、ファイルの再アップロード・ダウンロードという余分な工程が発生したと報告されています。DocBaseへの移行でも、エクスポート権限と作業担当者の権限は着手前に確認してください。

※ esaと同様、DocBaseの公式ヘルプで確認できるのは、Kibelaが管理画面インポートの対象であることまでです。 項目別の変換挙動は、前掲の4項目をテストインポートで確認してください。

Confluence・Notionから移行する場合

DocBaseの管理画面インポートが対応しているのはesa・Qiita:Team・Kibelaの3サービスです。ConfluenceやNotionからの移行は、この機能の対象外になります。

これらのツールから移行する場合は、次の3つの方法を検討することになります。

各ツールで書き出せる形式を確認し、Markdownに変換できる場合はDocBaseのREST APIやCLI、MCPサーバー経由で投稿する。Markdownで直接出力できない場合は、HTMLやCSVからの変換工程が必要になる
件数が限られていれば手動で移す
移行対象を絞り込み、必要になったものだけを順次移す

3つ目の「必要になったものだけを移す」は、実務的にもっとも現実的な選択肢になることがあります。Qiita TeamからNotionへ移行したクラウドワークスの事例では、一括移行を試みるのではなく、エクスポートしたCSVを移行状況の管理表として使い、記事を必要に応じて移行する運用が紹介されています。全件移行が必要ない場合は参考になる進め方です。

Excel・Googleドライブなどのファイルから移行する場合

Excelやスプレッドシートで管理していたナレッジを移す場合は、「ファイルのまま持っていく」か「ドキュメントとして書き直す」かを先に決めてください。

DocBaseは添付ファイルとしてPDFやExcelファイルをアップロードでき、添付ファイルも全文検索の対象になります。ただし公式ヘルプによると、1つのメモに対する添付ファイルの合計が75MBを超える場合は検索対象外になります。ファイルのまま持っていく場合は、1ドキュメントあたりの添付量を分散させてください。

一方で、WordやExcelのファイルを自動的にMarkdownのドキュメントへ変換する機能については、公式ヘルプで確認できませんでした（※要確認）。ドキュメントとして書き直す場合は、手作業での書き起こし、または後述するMCPサーバー経由での作成を前提に工数を見積もることをおすすめします。

DocBaseへの移行手段は4つあります

社内wikiの移行先を検討している方に、DocBaseを候補としてご紹介します。DocBaseは移行の手段が4つ用意されており、データ量・移行元の形式・社内のスキルに合わせて選べる点が特徴です。

移行手段	向いているケース	添付ファイル
①管理画面からのインポート	esa・Qiita:Team・Kibelaからの移行	対応
②REST API	対応外ツールからの一括移行、変換処理を挟みたい場合	対応
③CLI	スクリプトを書かずにコマンドで操作したい場合	対応
④MCPサーバー	Officeファイルなど、構造を整えながらドキュメント化したい場合	非対応

料金はユーザー単価制ではなくチーム単位の定額制のため、閲覧だけのメンバーを含めて社内全体に広げても費用が読みやすくなっています。DocBaseの料金プランを確認する。

30日間の無料トライアルをクレジットカード不要で始められます。 移行前に、実際のデータを少量だけ入れて検証してみてください。

DocBaseの30日間無料トライアルを始める（クレジットカード不要）

①管理画面からのインポート（esa・Qiita:Team・Kibela）

4つの中では始めやすい方法です。 移行元のチームURLとAPIトークンを管理画面に入力して実行します。通常の操作ではプログラミングは不要ですが、大量データや個別の変換が必要な場合は、下記のAPIやスクリプトによる対応を検討してください。実行できるのはオーナーまたは管理者のみです。

インポートの詳しい手順はDocBaseで外部サービスのデータをインポートする手順を見るで確認できます。Qiita:Teamからの移行手順はQiita:TeamのデータをDocBaseにインポートする方法を見るにまとまっています。

②REST API

対応外のツールから移行する場合や、変換処理を挟みたい場合に使います。 DocBaseのREST APIはメモの作成・取得・更新・削除、検索、グループ管理などに対応しています。

移行元のデータをMarkdownなどに変換できる場合は、必要な変換（画像URLの差し替え、タグの付け替えなど）をかけたうえで、REST APIを使って一括投稿できます。前述のとおり1時間あたり300リクエストのレート制限があるため、その件数を超える可能性がある場合は待機処理を入れてください。

③CLI（@krayinc/docbase-cli）

スクリプトを書かずにコマンドで操作したい場合の選択肢です。 DocBase CLIはnpmパッケージとして提供されており、以下のコマンドでインストールできます。

npm install --ignore-scripts -g @krayinc/docbase-cli

対応している操作は、メモの検索・作成・更新・削除・アーカイブ、コメントの一覧取得・作成・削除、ユーザー検索、グループの検索・作成・メンバー管理、タグ一覧、添付ファイルのアップロードとダウンロード、グッジョブの投稿です。出力はすべてJSON形式のため、他のツールと組み合わせやすくなっています。

認証はOAuth認証とアクセストークン認証の2方式に対応しています。この2つは挙動が異なるため、移行作業で使う際は注意が必要です。

認証方式	主な用途	AI利用制限の適用
OAuth認証	対話的な利用、AIコーディングツール	適用される
アクセストークン認証	CI/CD、スクリプト	適用されない

ドキュメント単位のAI除外（メモに no-ai タグを付けて設定）は標準機能、グループ単位のAI利用制限はセキュリティパック（有料オプション）の対象機能です。いずれの制限も、アクセストークン認証では適用されません。CI/CDから利用する場合は、この点を運用ルールに含めてください。

CLIの詳細はDocBase CLIの機能とコマンド一覧を見るで確認できます。

④MCPサーバー

インポート機能が対応していない形式のファイルを、構造を整えながらドキュメント化したい場合の選択肢です。

DocBaseの公式リモートMCPサーバーはメモの作成に対応しているため、ClaudeなどのMCP対応クライアントから、手元のファイルやGoogleドライブ上のドキュメントを読み取って、DocBaseに取り込めます。

他の3つとの違いは、変換ルールをプロンプトで指示できる点です。「見出し構造を整理してから取り込む」「表形式のデータをMarkdownの表に変換する」「1つのExcelシートを複数のドキュメントに分割する」といった加工を、スクリプトを書かずに指示できます。ExcelやWordのように、そのままでは変換できない形式を扱う場合に向いています。

一方で、次の2点は他の手段と異なるため、選ぶ前に確認してください。

添付ファイルの操作に対応していません。 公式ヘルプに記載されているMCPサーバーの操作にはメモ・コメント・タグ・グループの管理が含まれますが、添付ファイルは含まれていません。画像やPDFを含む移行では、CLIまたはREST APIと組み合わせてください
移行専用に設計された機能ではありません。 件数が多い場合の安定性や変換品質の担保は、利用者側で確認する必要があります。まずは数件で試し、意図した構造で取り込めるかを確認してから本格的に使うか判断してください

MCPサーバーの詳細はDocBase公式リモートMCPサーバーの対応内容を見るで確認できます。

DocBaseのMarkdownはCommonMark準拠です

DocBaseはMarkdownの標準仕様であるCommonMarkを採用しており、GFMで一般的な表・打ち消し線・チェックボックスにも対応しています。加えて、画像サイズ指定、<details> による折りたたみ、#{メモID} によるドキュメントの差し込み、TeX記法、Mermaid、PlantUML、脚注といった拡張記法があります。

また、Markdownに不慣れなメンバーでもリッチテキストモード（WYSIWYG編集）で直感的に編集できます。内部フォーマットはMarkdownに統一されるため、メンバーによって編集方法が異なっても、フォーマットが混在することがありません。移行後の投稿ハードルを下げやすくなります。

移行後にやるべき3つのこと

データを移し終えた時点では、移行はまだ終わっていません。 権限・タグ・リンクの確認と、情報の整理が残っています。移行は、情報の整理をやり直せる数少ない機会です。ここで手を抜くと、旧ツールで抱えていた「使われない」「見つからない」という問題をそのまま持ち込むことになります。

①グループ設計と公開範囲を見直す

インポート機能は、移行元のグループ構造をそのまま再現するとは限りません。DocBaseのQiita:Teamインポートでは、グループに属していたメモは同名のグループが新規作成されて移行され、グループに属していなかったメモはサービス名のグループにまとめられます。いずれも全員には公開されないため、移行後にグループと閲覧権限を確認する作業が必要です。

移行直後は、組織の現状に合っていないグループが並んでいる状態だと考えてください。誰が何を見るべきかを整理し直し、グループを統廃合してください。

②タグを再設計する

タグは放置すると増え続け、表記ゆれで機能しなくなります。移行のタイミングで、使われているタグの一覧を出し、名寄せと削減を行ってください。

DocBaseにはタグの一覧表示と名寄せ機能があります。AI機能がONの場合、追加費用なしでAIタグ自動生成も利用できます。

③古いドキュメントを棚卸しする

移行対象を絞り込む作業は、移行の前にやるのが理想ですが、移行後でも効果があります。

実際の移行事例では、日報・週報を除外して満足していたところ、後からファイル名の単語をランキング化することで、さらに1,000ファイル程度を削減できたと気づいたケースが報告されています。「明らかに不要なもの」を除外するだけでは足りません。ファイル名やタイトルの傾向を機械的に分析すると、まとまった単位で不要なデータが見つかります。

社内wiki移行によくある5つの失敗と対策

実際の移行プロジェクトで報告されている失敗を、対策とセットで整理します。

失敗①画像がリンク切れになる

よくある失敗です。 エクスポートしたMarkdown内の画像URLが移行元を指したままになっていると、旧ツールを解約した瞬間に画像が表示されなくなります。

クラウドワークスの技術ブログでは、Qiita Teamの標準エクスポートに画像が含まれないため、APIを使って画像込みで書き出すPythonスクリプトを自作し、それでも移行後に画像ファイルを手動で差し替える必要があったと報告されています。

対策： 移行後、旧ツールを解約する前に、画像が正しく表示されるかを必ずサンプル確認してください。移行元のドメインを指すURLが本文に残っていないか、機械的に検索するのが確実です。

失敗②記事同士のリンクが切れたまま放置される

移行元の記事URLは、移行先では解決できません。前述のクラウドワークスの事例でも、他の記事への参照リンクは移行後に手動で更新する必要があったと記載されています。

対策： 移行前に、本文中に含まれる自ツールのURLを一括抽出してください。件数がわかれば、置換スクリプトを書くか手作業で対応するかを判断できます。

失敗③件数上限で一部が移行されない

前述のとおり、esa・NotePMいずれの公式ヘルプでも、10,000件を超えるデータのインポートには制約があると記載されています。

対策： 移行前に総件数を数えてください。上限に近い場合の対処は移行先ツールの仕様によって異なるため、分割移行・件数調整・サポートへの確認のうち、どれが可能かをヘルプで確認してください。移行後は、移行元と移行先の件数を突き合わせて確認してください。

失敗④インポートのサイズ制限に引っかかる

移行先ツールにはインポート時のファイルサイズ制限がある場合があります。KibelaからNotionへ移行した事例では、5MB以下への分割が必要だったうえ、50MBを超えるファイルは受け付けられず、特大ファイルには別の処理を実装する必要があったと報告されています。

対策： 移行先のインポート仕様でサイズ制限を確認し、容量の大きいファイルを事前に洗い出してください。

失敗⑤旧ツールのURLからのリダイレクトを用意しない

社内の他のドキュメントやチャットに貼られた旧ツールのURLは、移行後もそのまま残ります。前述のKibelaからの移行事例では、旧ツール側のリダイレクト対応が不十分で、旧URLが取り残される結果になったと報告されています。

対策： 旧ツールをすぐに解約せず、一定期間は並行稼働させてください。旧ツールのトップページに移行先の案内を掲示するだけでも、社内の混乱を抑えやすくなります。

なお、同じ事例では移行後に「検索が難しくなった」という利用者の声も報告されています。移行先を選ぶ際は、検索の使い勝手を実際に触って確認することをおすすめします。

よくある質問（FAQ）

Q. 社内wikiのデータはすべて移行できますか？

いいえ、すべてが移行できるとは限りません。本文のテキストはほとんどの場合移行できますが、画像の参照先、記事同士のリンク、権限設定、タグの階層構造などは、移行元と移行先の仕様差によって失われたり変換されたりします。移行前に、移行元のエクスポート仕様と移行先のインポート仕様を突き合わせて確認してください。

Q. DocBaseはどのツールからのインポートに対応していますか？

管理画面からのインポートは、esa・Qiita:Team・Kibelaの3サービスに対応しています。この3つは管理画面から必要情報を入力してインポートでき、通常の操作ではプログラミングは不要です。それ以外のツールからは、REST API・CLI（@krayinc/docbase-cli）・MCPサーバーのいずれかを使った移行、もしくは手動での移行になります。

Q. 社内wikiの移行にはどれくらいの期間がかかりますか？

データ量と移行方式によって大きく変わるため、一律の目安はありません。管理画面インポートに対応しているツールからの移行であれば、インポート処理自体は短時間で完了します。工数がかかるのはインポートの前後、つまり移行対象の棚卸しと、移行後のグループ・タグの再設計、画像やリンクの確認作業です。1万件規模の移行では、移行作業そのものよりこの前後の工程に時間が必要になります。

Q. 移行元のツールはいつ解約すればよいですか？

移行後すぐの解約は避けてください。画像やリンクが正しく移行できているかの確認が済んでいない段階で解約すると、画像がリンク切れになった際に復旧できなくなります。一定期間は並行稼働させ、旧ツールに貼られたURLからの導線と、画像の表示確認が完了してから解約することをおすすめします。

Q. 移行時にドキュメントの公開範囲はどうなりますか？

DocBaseにQiita:Teamからインポートした場合、グループに属していたメモは同名のグループが新規作成されて移行され、グループに属していなかったメモはサービス名のグループにまとめられます。いずれも全員には公開されません。移行後にグループと閲覧権限を確認してください。

なお、公開範囲の扱いは移行先によって異なります。閲覧権限の仕組みがないツールへ移行する場合は、非公開だったコンテンツが全員に見える状態になることがあるため、移行先の権限モデルは事前に必ず確認してください。

Q. MarkdownはそのままDocBaseで使えますか？

DocBaseはMarkdownの標準仕様であるCommonMarkを採用しており、表・打ち消し線・チェックボックスといったGFMで一般的な記法にも対応しています。ただし、移行元ツールの独自拡張記法はそのままでは再現されない場合があります。よく使っている記法をリストアップし、DocBaseのMarkdown記法と書き方を確認するで対応状況を照合してください。

Q. ExcelやWordのファイルはドキュメントに変換できますか？

WordやExcelのファイルを自動的にMarkdownのドキュメントへ変換する機能は、公式ヘルプで確認できませんでした（※要確認）。ファイルはそのまま添付でき、添付ファイルも全文検索の対象になりますが、1つのメモに対する添付ファイルの合計が75MBを超える場合は検索対象外になります。ドキュメントとして書き直したい場合は、手作業での書き起こし、またはMCPサーバー経由での取り込みを検討してください。MCPサーバーなら、見出し構造の整理や表の変換をプロンプトで指示しながら取り込めます。

Q. 移行後にAIでナレッジを活用できますか？

DocBaseはAI機能のON/OFFをチーム管理者が一括管理する仕組みで、AIメモ要約・AIコメント要約・AIタグ自動生成を追加費用なしで利用できます。また、MCPサーバーに対応しており、MCP対応クライアントからDocBaseのデータを参照できます（対応状況は各クライアントの仕様に依存します）。AIへの入力データがAI学習に利用されることはありません。なお、グループ単位でのAI利用制限にはセキュリティパック（有料オプション）が必要です。詳細はDocBaseのAI機能一覧を見るをご覧ください。

まとめ｜移行の不安は、実データを少量入れて試すのが一番確実です

社内wikiの移行で確認すべきことを、あらためて整理します。

移行の成否は、移行元のエクスポート仕様と移行先のインポート仕様の差分で決まる
失われやすいのは本文以外の情報（画像の参照先・記事同士のリンク・権限・タグ階層・外部共有リンク）
移行前にデータ量・添付ファイル・権限構造・外部共有リンク・Markdownの方言差を確認する
移行元がどのツールでも、画像・記事同士のリンク・公開範囲・件数の4項目はテストインポートで実物確認する
DocBaseへの移行手段は4つ（管理画面インポート・REST API・CLI・MCPサーバー）。管理画面インポートはesa・Qiita:Team・Kibelaの3サービスが対象
移行後にグループ設計・タグ設計をやり直し、古いドキュメントを棚卸しする
旧ツールはすぐに解約せず、画像とリンクの確認が済むまで並行稼働させる

仕様書を読み比べても判断がつかない部分は、実際のデータを少量入れて試すのがもっとも早い確認方法です。よく使っている記法を含むドキュメントを数本移してみれば、自社のデータで何が崩れるかがその場でわかります。

DocBaseは30日間の無料トライアルをクレジットカード不要で始められます。初期設定費用もかかりません。移行を決める前の検証にご利用ください。