Notion から Confluence への乗り換え｜権限モデルとテンプレ移行のやり方

組織が成長し、プロジェクトが複雑化するにつれて、ドキュメント管理ツールの選定基準は「書きやすさ」から「管理の堅牢性」へとシフトします。Notionの自由な設計は、スモールチームや個人利用において圧倒的な機動力を発揮しますが、従業員数が100名を超え、全社的なガバナンスが求められるフェーズに入ると、「権限管理の複雑化」や「情報の散逸」という壁に突き当たることが少なくありません。

本記事では、IT実務担当者や情報システム部門（情シス）向けに、NotionからConfluenceへの乗り換えを成功させるための具体的な手順を解説します。特に、両ツールの最大の相違点である「権限モデル」の再設計と、独自性の強い「Notionテンプレート・データベース」をどのようにConfluenceへ落とし込むか、実務的なTipsを網羅しました。

NotionからConfluenceへの乗り換えが急増する背景と判断基準

「自由なNotion」が組織規模の拡大で抱える構造的課題

Notionはページ内にページを作成し、それぞれのページに対して個別に権限を付与できる「ページベース」の構造を持っています。この柔軟性は魅力ですが、組織規模が大きくなると以下の課題が顕在化します。

• 権限のブラックボックス化： 特定のページだけが外部共有されていたり、意図しないユーザーに閲覧権限が付与されていたりしても、一括で把握・制御することが困難。
• データベースの乱立： 誰でも簡単にデータベースを作成できる反面、似たようなマスタデータが各所に散らばり、情報の「正誤」が判断できなくなる。
• SaaSコストの増大： Notionのエンタープライズプランへのアップグレードを検討する際、既存のAtlassian製品（Jiraなど）との重複コストが無視できなくなる。

実際、SaaSコストを削減。フロントオフィス＆コミュニケーションツールの「標的」と現実的剥がし方でも触れている通り、ツールの集約はコストだけでなく、セキュリティガバナンスの観点からも極めて重要です。

Confluence移行で得られるガバナンスとJira連携のメリット

Confluenceへの移行は、単なるツールの変更ではなく「情報の階層化と整理」を強制する機会となります。最大のメリットは、Jiraソフトウェアとのネイティブな連携です。プロジェクトの要件定義書（Confluence）からJiraの課題を直接作成し、そのステータスをドキュメント上でリアルタイムに同期できる点は、エンジニアリング組織にとって大きな強みです。

【重要】NotionとConfluenceの権限モデルの決定的な違い

移行作業の中で最も失敗しやすいのが、権限設計の誤認です。両者の設計思想は根本から異なります。

Notion：柔軟な「ページ・ブロック単位」の継承と上書き

Notionの権限は、最上位の「ワークスペース」から個別の「ページ」、さらにはその中の「データベース」へと継承されます。特徴的なのは、「下位の階層で、上位よりも広い（または狭い）権限を個別設定できる」点です。これにより、「チームには非公開だが、この1ページだけ特定の外部パートナーに見せる」といった柔軟な運用が可能になっています。

Confluence：堅牢な「スペース単位」のアクセス管理とページ制限

一方、Confluenceは「スペース」という大きな箱が権限の最小単位となります。
公式ドキュメント（Atlassian Support: コンテンツの権限を設定する）にある通り、Confluenceの権限は以下の3段階で構成されます。

1. サイト権限： そもそもログインできるか。
2. スペース権限： そのスペース内のページを閲覧・作成・削除できるか。
3. ページ制限： スペース権限を持つユーザーの中で、さらに特定のページを閲覧制限するか。

注意点： Confluenceでは、スペース権限を持っていないユーザーに「特定のページだけ」を見せることは原則できません（ゲストアクセス機能などを除く）。「Notionでは見えていたのに、Confluenceに移行したら誰も見られなくなった」というトラブルの多くは、このスペース単位の縛りに起因します。

移行時に発生する「権限の破綻」を防ぐためのマッピング設計

移行前には、必ず以下の「権限マッピング表」を作成してください。

アカウント管理の自動化については、SaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐ。Entra ID・Okta・ジョーシスを活用した自動化アーキテクチャが参考になります。

NotionからConfluenceへのデータ移行プロセス（完全手順）

データ移行は「一括自動移行」が理想ですが、現実には手動の微調整が不可欠です。以下の4ステップで進めます。

STEP 1：移行対象の棚卸しとアーカイブ判断

Notion内の全てのデータを移行する必要はありません。古い議事録や更新の止まった個人メモは、移行対象から外してNotion側でアーカイブするか、PDFとして書き出すに留めます。移行ボリュームを減らすことが、トラブル回避の近道です。

STEP 2：Notionからのエクスポート（Markdown / CSV）

Notionの設定（Settings & Members）から「Export all workspace content」を選択します。
Confluenceへのインポートを前提とする場合、「Markdown & CSV」形式での書き出しが最も汎用性が高いです。HTML形式でも可能ですが、Confluence側で構造が崩れやすい傾向にあります。

STEP 3：Confluenceインポーターの活用と限界

Confluenceには標準で「外部コンテンツのインポート」機能が備わっています（管理画面 ＞ インポート）。しかし、Notion独自のコールアウトや複雑なデータベースビューは、このインポートだけでは再現されません。

• テキスト・画像： 概ね良好に移行されます。
• ファイル埋め込み： リンク切れが発生しやすいため、重要な添付ファイルは個別チェックが必要です。
• Notion データベース： 1レコード1ページとして移行されますが、プロパティ情報は失われるか、単純なテーブルに変換されます。

STEP 4：画像・添付ファイルのリンク切れチェックと修正

Notionからエクスポートしたファイルは、ローカルの相対パスで画像を保持しています。Confluenceへ一括アップロードした際、パスが解決されず画像が表示されないケースがあります。この場合、Confluenceの「ページへのファイルの添付」機能を用いて、再アップロードを行う必要があります。

テンプレートとデータベースの代替実装ガイド

Notionの利便性を支えていた機能を、Confluenceでどのように代替するかが、ユーザー満足度の鍵を握ります。

Notionデータベースは「Confluenceデータベース」または「Jira」へ

Notionの最大の特徴であるデータベースは、移行先を2つのパターンから選びます。

1. Confluence データベース（新機能）： 表形式でデータを管理し、フィルターやソートをかける。Notionに近い感覚で使えます。
2. Jira 課題（推奨）： タスク管理や進捗管理を伴うデータベースであれば、Jiraへ移行し、Confluenceの「Jira課題マクロ」で表示させるのがベストです。

コールアウト、トグル、同期ブロックの代替マクロ選定

Confluenceには強力な「マクロ」機能があります。

• コールアウト： 「情報」「ヒント」「注意」マクロで代替。アイコンや背景色の変更が可能です。
• トグルリスト： 「展開」マクロ（Expand）を使用します。
• 同期ブロック： 「コンテンツのインクルード」マクロ、または「ページ・プロパティ」マクロを組み合わせることで、一箇所の修正を複数ページに反映させる構造を構築できます。

こうしたツールの責務分解とデータ連携の考え方は、【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』で解説している「各システムの責務を明確にする」という原則に通じるものがあります。

Notion vs Confluence 機能・料金比較表

移行の稟議や検討材料として、2024年現在の主要なスペックを比較します。
※正確な最新料金は、各社公式サイト（Notion料金 / Confluence料金）をご確認ください。

移行後の運用設計：二度と「情報の墓場」にしないために

ツールを移行しても、運用ルールがなければ再び情報は散逸します。Confluenceへの移行を機に、以下の3点を徹底しましょう。

スペース名の命名規則とラベリングの徹底

スペース名には必ず「【全社】」「【開発】」「【プロジェクト：プロジェクト名】」といったプレフィックスを付けます。また、各ページには「ラベル」を付与するルールを設けます。Confluenceは検索が強力ですが、ラベルを併用することで、必要なドキュメントへの到達スピードが飛躍的に向上します。

権限管理の定期監査フローの構築

Confluenceの「スペース管理者」を各部署に任命し、半年に一度、スペースの閲覧権限と制限ページを見直すフローを運用に組み込みます。情シスが全てを管理するのではなく、現場の管理者に権限を委譲しつつ、サイト管理者が全体を俯瞰する「多層的な守り」が重要です。

NotionからConfluenceへの乗り換えは、単なる引っ越しではなく、組織のナレッジマネジメントを再構築するプロジェクトです。権限モデルの違いを正しく理解し、Jira連携を前提とした設計を行うことで、情報の透明性とセキュリティを高いレベルで両立させることが可能になります。

# Notion → Confluence 移行のカスタムスクリプト
import requests
from notion_client import Client as NotionClient

notion = NotionClient(auth="YOUR_NOTION_TOKEN")
CONFLUENCE_BASE = "https://yourorg.atlassian.net/wiki/rest/api"
CONF_AUTH = ("user@example.com", "API_TOKEN")

def migrate_notion_page(page_id, parent_confluence_id, space_key):
    # 1. Notion ページ取得
    page = notion.pages.retrieve(page_id=page_id)
    blocks = notion.blocks.children.list(block_id=page_id)["results"]

    # 2. Notion ブロック → Confluence ストレージ形式へ変換
    confluence_storage = convert_blocks_to_storage(blocks)

    # 3. Confluence ページ作成
    response = requests.post(
        f"{CONFLUENCE_BASE}/content",
        auth=CONF_AUTH,
        json={
            "type": "page",
            "title": page["properties"]["title"]["title"][0]["plain_text"],
            "space": {"key": space_key},
            "ancestors": [{"id": parent_confluence_id}],
            "body": {"storage": {"value": confluence_storage, "representation": "storage"}}
        }
    )
    new_page_id = response.json()["id"]

    # 4. 子ページを再帰的に処理
    for child in get_child_pages(page_id):
        migrate_notion_page(child["id"], new_page_id, space_key)

def convert_blocks_to_storage(blocks):
    # Notion の各ブロックタイプを Confluence ストレージ形式（XHTML）に変換
    # トグル → ac:expand マクロ、コールアウト → ac:adf-extension など
    pass