メルカリのConfluenceからNotionへの移行プロジェクト（2025年〜2026年3月の軌跡）

## 目次 - はじめに - プロジェクトの発足 - 直面した「2 つつの壁」 完璧なインポートは幻想（技術の壁） - 金融事業ゆえの厳しい制約（コンプライアンスの壁） - 現状と今後 - もし過去に戻れるとしたら？ Confluence 導入時まで戻れたら… - Confluence→Notion 移行プロジェクト開始時に戻れたら… - おわりに ## はじめに こんにちは。Engineering Office の [kiko](https://x.com/kiko_tw) です。 今、私は Central Knowledge Management Committee のメンバーとして、社内のドキュメント基盤を Confluence から Notion へ移行するプロジェクトを推進しています。 当プロジェクトはまだ完遂していませんが、3 月末に一つの節目を迎えたので、同 Committee メンバーの t-yama さんと共に、これまでの振り返りをまとめました。 これから社内ドキュメントツールを導入しようとしている方や、他ツールから Notion への大規模移行を検討している方にとって、少しでも役立てば幸いです。 ## プロジェクトの発足 このプロジェクトは、単なるツールの乗り換えではなく、メルカリ全体の Knowledge Management（ナレッジマネジメント）の再構築として発足しました。([メルカリの Notion 導入についてのブログ](https://engineering.mercari.com/blog/entry/20251224-mercariadventcalendar/)) これまで Confluence 含め複数のツールに分散していた社内ドキュメントを、AI/LLM（大規模言語モデル）との親和性が高い Notion に集約することで、以下のメリットがあると考えています。 - ツールとして構造が一元化されるため、AI がコンテキストにしやすい - AI や他ツールとの連携コストを下げられる - ドキュメンテーションの重複やメンテナンスコストを減らせる - ツールの利用自体のナレッジを社内で共有、蓄積しやすくなる - ツールの違いによる、チーム間のナレッジのシェアや、働き方の違いといった分断を減らせる - 将来別のツールに移行する場合にコストを低くできる ## 直面した「2 つつの壁」 Confluence からの移行の検討が始まったのは、2025 年 7 月のこと。 まずは、VP（最高責任者）、PM Office、リスク・コンプライアンスチーム等へヒアリングしました。ヒアリングの結果、「一部移行を見送るドキュメントは在るものの、全体としては大きなブロッカーはない」と判断し、本格始動しました。しかし、プロジェクトを進めるうちに、2 つつの大きな壁にぶつかることになります。参考までに、それぞれに対する判断と対策についても合わせて付記します。 ## 1. 完璧なインポートは幻想（技術の壁） ![image](https://storage.googleapis.com/prd-engineering-asset/2026/03/d95487ae--2026-03-31-13.33.13.png)↑ガイドラインには、移行に関する情報やヒントを記載しています。 エクスポート・インポートの過程で、情報の欠損やレイアウト崩れが発生しました（我々が調べた当時、50 項目以上）。これは、Confluence と Notion が別ツールである限り仕様として当然に起きるものです。ただ、その量と範囲は結構なもの…IT チームは泥臭い検証を繰り返しました。 - 判断：手間をかけずに 100% 完璧な移行は不可能。移行後に必ず手作業が発生すること前提で進める。 - 対策：欠損箇所（マクロや特殊な表など）を特定。移行前に修正すべき点や、インポート後に対応すべき点、修正のベストプラクティスなどをまとめたガイドラインを整備。 ## 2. 金融事業ゆえの厳しい制約（コンプライアンスの壁） プロジェクト中盤、メルペイ・メルコインといった金融事業において、特定のドキュメントに求められるコンプライアンス要件が、現時点の Notion 標準機能ではクリアしきれないことが判明しました。 - 判断：対象ドキュメントの移行は全社の移行とは分ける。 - 対策：メルペイ・メルコイン側で担当者を立ててもらい、全社の移行とは別で対象ドキュメントの要件定義・ソリューション考案を進めてもらう。 ## 現状と今後 2 つの大きな壁はありましたが、当初から対象外としていたものや別ルート対応になったものを除き、今後も利用する社内ドキュメントはほぼ Notion へのインポートが完了。3 月末に、Confluence への常時アクセスが不要なライセンスの棚卸しが完了しました。 ただ、Confluence には、情報のオーナーがいない等の理由で Notion へ移行しなかったものの、情報資産として有用なドキュメントが多数残っています。これらの情報を、必要な時にいつでも閲覧できるよう、一時・恒久アクセス付与の仕組みを提供しています。 最終的には、Confluence 内のドキュメントは閉架図書のように取り扱う形を目指しています。 ## もし過去に戻れるとしたら？ さて、「もし最初から今の知見があったら何をするか？」を考えると、やり直したいポイントはいくつかあります。戻るポイントを、Confluence 導入時とプロジェクト開始時のそれぞれに設定して考えてみました。 ## Confluence 導入時まで戻れたら… どんなツールでも、導入時から完璧な運用ができるわけではありません。何年も運用していれば前提が変わってくるもので、それは導入時に何かしていれば防げたという類のものでもないと思います。 ただ、もし今から Confluence 導入時期に戻れるとしたら、Confluence はもっと自由度を抑えた運用設定にしておくべきだったと思います。弊社の Confluence 利用はユーザの自由度が高く、スペース作成や API の発行など、ルールはあってもシステム的に制御できている状態ではありませんでした。良く言えば「自由」、悪く言えば「制御できていなかった」状態だったと思います。 自由度が高いと、ユーザが意図せずセキュリティ上リスクのある設定をしてしまったり、例外的な使い方やエッジケース（特殊な事例）が大量に生まれてしまうというデメリットもあります。例えば API トークン（認証キー）はユーザ自身で発行できたため、個人やチーム単位で Confluence との API 連携を前提とした仕組み・運用が多数存在していました。その結果、Notion への移行が決まると、「同じように API を使わせてほしい」「システム連携も対応してほしい」という声が自然と出てきました。 Notion 導入時にこうしたルールを再度整備し運用に落とし込んだところ、「前より不便になった」「自由ではなくなった」という声も一部からありました。ただ、これは Notion が厳しいのではなく、前が自由すぎたのが問題だったと考えています。 とはいえ、最初は自由であとから制限をかけるというのは、反発を生みやすいものです。これはツール移行に限らず、プラットフォーム運用全般に言えることだと思います。組織が成熟していく過程で、後からルールを導入するのは仕方がない面もあります。ただ、自由な期間が長いほど反発は大きくなるので、できるだけ早いタイミングでルールを整備しておくのが望ましいと思います。 ## Confluence→Notion 移行プロジェクト開始時に戻れたら… 今回のような大規模な社内ドキュメントツールの移行は何度もやるようなものではありません。全員が初めての経験で、ノウハウも正解もない中、手探りで進めていくことになります。 その中で一番感じたのは、Confluence の現状に対する解像度をもっと早く高めておくべきだったということです。Confluence と Notion は別のサービスである以上、完璧な移行はできず、人的リソースや期限もあるため必然的にベストエフォート（最大限の努力）での対応になります。何に力を入れて、何を割り切るか——その判断には、ある問題がどれだけのユーザに影響するのか、メジャーな話なのかエッジケース（特殊な事例）なのかを見極める必要があります。 しかし実際には、その見極めに必要な情報が足りないことが多くありました。本当はエッジケースなので割り切った方がよいのに、ニーズの総数がわからないために決断できない、ということがよく発生しました。例えばマクロが移行できないとわかったとき、そもそも何のマクロが会社全体でどのくらい使われているのかがすぐには把握できませんでした。このあたりは後からわかるようになりましたが、技術面だけでなく、ユーザが実際にどう使っているか、どのスペース（作業領域）の更新頻度が高いか、特殊な要件があるかといったユースケースの利用実態を早期に深めておけば、判断はもっと速くできたと思います。 解像度の問題に加えて、「やった方がよいのはわかっているが、リソースが足りなくてできない」という場面もかなり多くありました。例えば、自前で移行ツールを作れば、移行できない問題やエッジケース（特殊な事例）に部分的に対応できるかもしれません。しかし、ツールの冪等性（何度実行しても結果が変わらない性質）の担保や、逆に新たな移行不能要素が生まれないかの検証など、別のリスクが発生します。それが起きたときにプロジェクトが破綻しないかというリスク許容度も含めると、安易には踏み切れません。やれたら良いけれど余裕がない——でも周りから見ると「なぜやらないのか」と思われてしまう——というジレンマは常にありました。 このように移行プロジェクトでは、技術的な対応に加えて、現場での使われ方の把握、リソース管理、ベストエフォートの判断、ユーザへのコミュニケーションなど、さまざまな観点での対応力が求められます。そのため、移行専任のプロジェクトとして適切なメンバーをアサインすることが非常に重要だと感じています。 ## おわりに 今回のプロジェクトは、社内ドキュメントツールの管理・運用の仕組みを考え直す良い機会になりました。 また、移行のやり方に唯一の正解はありませんが、少なくとも言えるのは次の1点です。 「欠損や崩れが起きることを前提に、準備と運用設計をしておくほど、移行は楽になる。」 今回の経験をもとに、今後もNotionの環境構築・設計に力を入れていきたいと思います。

メルカリのConfluenceからNotionへの移行プロジェクト（2025年〜2026年3月の軌跡）

背景や根拠まで確認しますか？

調べる

選ぶ

サイト