ConfluenceかNotionか、移行で消える権限と履歴を先に見る

ConfluenceからNotionへはページや添付を移せるが、アクセス権限と版の履歴はそのまま引き継げない。閲覧範囲や過去の修正を業務で使っているなら、編集機能や料金を比べる前に、移行後も同じ仕事を続けられるかを判断する必要がある。

NotionのConfluenceインポート仕様では、ZIP方式は通常5GBまで、申請した場合は15GBまで、API方式は30GBまで対応する一方、権限と履歴は移行対象外とされる。コメントはAPI方式でのみ保持され、マクロやプラグインの多くは元の形で残らない。本文を取り込めたという結果だけで、社内Wiki全体の移行可否は決められない。

インポート方法で、残る内容が変わる

ZIP方式はConfluenceのスペースをHTMLで書き出し、Notionに取り込む部分移行向けの方法だ。APIによる一括取り込みは広い範囲を対象とし、コメントとユーザーの対応付けを保持する。少数のページを移す方法として、URLまたはページIDを指定する手順も用意されている。試行の目的が本文の体裁を見ることなのか、コメントを含む運用を確かめることなのかで、選ぶ経路は変わる。

ユーザーの対応付けが残っても、その人の閲覧・編集権限まで再現されるわけではない。元のプライベートページはインポート対象外で、ページから参照されていない添付ファイルやメディアも取り込まれない。ページ階層は移行対象だが、複雑な構造では完全に保持されない場合がある。対象の容量だけで方式を選ばず、非公開ページ、参照されない添付、深い階層を試行対象に含めたい。

権限はスペース名だけでは再現できない

Confluence Cloudでは、Atlassianの権限構造の説明にあるとおり、全体権限、スペース権限、コンテンツの制限が重なる。スペースを閲覧できる人でも、個別ページには閲覧制限を掛けられる。移行先の公開範囲をスペース単位だけで決めると、ページごとの例外を見落とす。

棚卸しでは、スペースごとの閲覧者と編集者に加え、制限付きページ、外部への公開、複数グループに属する人を記録する。そのうえでNotionのグループ、チームスペース、ページ権限に割り当てる。移行したページの権限はNotion側で設定し直す必要があるため、対象者を招く前に公開先を整える順序が重要になる。

管理者の画面でページを開けるだけでは、権限の試験にならない。閲覧のみの人、編集できる人、アクセスできないはずの人で、ページと添付ファイルの表示を比べる。意図しない公開は移行を止める条件にし、必要な人が閲覧できない場合も設定を直してから再試行する。なお、Confluence CloudのFreeプランでは権限とコンテンツ制限を調整できないため、現行の制限付き運用と安易に同列比較はできない。

履歴とコメントは別々に残し方を決める

版の履歴はNotionへのインポート対象外だ。修正前の文面や変更者を後から参照する必要があるページでは、元のConfluenceをいつまで閲覧可能にするか、誰が保管を担うかを決める。最新版の本文が移っても、過去の承認や判断をたどる手段まで移ったことにはならない。

コメントは履歴と違い、取り込み経路で結果が変わる。Confluence Cloudの書き出し仕様では、HTML書き出しにページコメントは含まれず、PDFにもコメントは含まれない一方、CSVには添付とコメントが標準で含まれる。NotionのConfluence向けZIP取り込みに使うのはHTMLの書き出しファイルなので、CSVにコメントが含まれることをZIP移行の保証とは考えられない。

コメントが承認や意思決定の記録なら、API方式で元のページとの結び付きや発言者の表示を試す。取り込まない方針なら、どこから過去の議論を参照するかを明確にする。本文の更新先をNotionに変えても、判断の経緯を探すたびに移行元へ戻る運用はあり得るため、履歴とコメントを一つの「過去データ」として合否判定しないほうがよい。

マクロと添付は、表示より業務上の意味を見る

Confluenceのマクロは、Notionで近いブロックに変換される場合がある。ただし、多くのマクロやプラグインは元の動作を保てず、テキスト、画像、リンクなどになる。展開できる項目が読みやすく残る場合と、外部サービスに依存した表示や操作が失われる場合では、手直しの負担が違う。

試行では、崩れた箇所を単なる見た目の差と、情報や操作の欠落に分ける。たとえば手順を読むための内容が残っていれば整形で済むかもしれない。一方、利用者がその場で更新する仕組みなら、静的な表示への変換では目的を果たせない。添付も、ファイル名が見えるかだけでなく、利用者が必要な版を開けるかまで確かめる。

移行前の採点表は、欠落の影響まで記す

試行対象には、短い通常ページだけでなく、制限付きページ、コメントの多いページ、添付を含むページ、マクロを使うページを入れる。各項目は「そのまま使える」「補修すれば使える」「移行できない」で採点し、補修が必要なら担当者と完了条件も記す。機密情報の意図しない公開や、必須の記録にアクセスできない状態は、合計点とは別の停止条件にする。

• ページ：本文、見出し、リンク、子ページの関係が残り、利用者が目的の情報へたどり着けるか。
• 添付：ページ内の画像やファイルを開けるか。参照されない添付を別途保管する必要があるか。
• コメント：残すべき議論が元のページに結び付き、発言者を識別できるか。ZIPとAPIの結果は分けて記録する。
• ユーザー：ページの作成者やコメントの発言者を移行後も識別できるか。対応付けと権限の再設定は別に評価する。
• 権限：閲覧・編集の範囲と個別ページの例外を再現できるか。許可されていない人からも試す。
• 履歴：過去の版が必要なページを特定し、Confluenceでの保管と参照方法を定められるか。
• マクロ：変換後も情報や操作の意味が通じるか。代替手段が必要なら作業量を見積もれるか。

件数だけでなく、欠落すると誰の作業が止まるかも記す。利用頻度の低いページでも、承認記録や限定公開の情報を含めば優先度は高い。体裁の修正だけで済むページは、補修に必要な時間を見積もったうえで移行対象に残せる。

小規模試行で、移行を見送る条件を確かめる

試行には、移しやすいページより運用上の例外を選ぶ。元ページの場所、閲覧範囲、添付、コメント、必要な過去の版を控えておけば、移行後の差を項目ごとに判断できる。試行用の取り込み先は、本番の公開範囲を広げる前に評価できる場所にする。

1. 対象スペースから通常ページと制限付きページ、コメント・添付・マクロに特徴のあるページを選ぶ。
2. コメントの保持と対象範囲を基準にインポート方法を選び、移行先に取り込む。
3. 本文、階層、添付を元ページと照合し、欠落を再取り込み、手作業での補修、方式上の制限に分ける。
4. 移行先の権限を設定し、異なる立場の利用者で表示と編集の可否を確かめる。履歴とコメントの参照先も決める。
5. 停止条件に当たる項目があれば対象や方式を見直し、補修項目は担当者が直してから再試行する。

撤退条件は試行前に定める。制限付きページの公開範囲を再現できない、重要なコメントの所在を示せない、業務で使うマクロの代替がない場合は、本番移行を延期する判断が妥当だ。一部の知識だけをNotionへ移すなら、Confluenceに残すページ群と、それぞれの更新先を決めておく必要がある。

使い勝手と費用は、移行できる範囲で比べる

ITreviewの製品比較は、両製品の合計789件のレビューを基に、満足度、使いやすさ、管理のしやすさ、価格などを並べている。日常の編集体験を比べる材料にはなるが、手元の制限付きページやマクロが移るかどうかは、自組織の試行結果で判断するしかない。

残留と移行の費用には、利用料に加えて権限の再設定、ページの補修、元データの保管を含める。Atlassianのライセンス案内では、Confluence CloudのFreeプランは最大10ユーザー、ストレージ2GBで、StandardとPremiumには無料試用が用意されている。必要な権限管理と容量を満たすプランを前提に比べれば、移行で発生する手作業も費用判断から漏れにくい。

関連記事：

• ポッドキャスト移行で購読者を失わない、301より先に見る項目
• Hugging Faceの「オープン継続」を検証する、買収後に見る4項目
• Gemini 3.8移行で請求が膨らむ前に、thinkingを3段階で試す