実際に移行できるもの
ページは Markdown として移行されます。これこそが求めているフォーマットです。 個別のページは PDF、HTML、または Markdown & CSV としてエクスポートできます。ワークスペース全体の場合、「設定」→「ワークスペース」→「設定」→「すべてのワークスペースコンテンツをエクスポート」から HTML、Markdown、または CSV を選択できます。Markdown & CSV オプションを選択すると、1ページにつき1つの .md ファイル、1つのデータベースにつき1つの CSV、そしてサブページやアセットが並行してフォルダ内に生成されます。
始める前に知っておくべきいくつかの制限事項があります：
- 「サブページを含める」 を有効にすると、ネストされたページが個別のファイルとしてダウンロードされます。個別ページのエクスポートにおいて、これは Business および Enterprise プランの機能ですが、ワークスペース全体のエクスポートにはプランに関係なく適用されます。
- 大容量のエクスポートはメールで届きます。 Notion は直接ダウンロードを開始するのではなく、ダウンロードリンクを送信します。そのリンクの有効期限は7日間です。ワークスペースのサイズによっては、処理に最大30時間かかる場合があるため、ワークスペースのエクスポートは昼食前に開始しておくものであり、その場で待つようなものではありません。
- 閲覧権限があるものだけが対象になります。 「エクスポート実行者がアクセス権を持たないページ（他のユーザーのプライベートページなど）はエクスポートに含まれません。」 実際のアーキテクチャ設計書がチームメンバーのプライベートページにある場合、それはエクスポートに含まれず、その旨が通知されることもありません。
- ワークスペースの PDF エクスポート機能は廃止されます。 Notion はワークスペースのコンテンツを PDF としてエクスポートするオプションを廃止しつつあり、2026年8月31日にかけて段階的に適用されます。HTML、Markdown、CSV は引き続き利用可能で、個別ページの PDF エクスポートも可能です。もしワークスペースの PDF エクスポートをバックアップの習慣にしていたなら、その習慣を改める必要があります。
データベースは CSV として移行されますが、これは見た目以上に情報が失われます。 Notion のデータベースは、行、ビュー、リレーション、ロールアップで構成されています。CSV で取得できるのは「行」だけです。リレーションから計算されたものは、取得できたとしても単なるテキストとして届き、データを理解するために実際に使用していたビューは一切含まれません。
Notion AI 自体は移行されませんし、移行すべきでもありません。 Notion AI の価値は、コーディングエージェントに渡すことなど思いもしないようなページも含め、現在のライブなワークスペース全体に対して回答できる点にあります。これは本当に優れた機能であり、Cursor がそれを再現することはありません。この移行は「Notion を辞める」ことではありません。ほとんどのチームにとって適切な最終状態は、Notion が引き続きドキュメントを保持し、ビルドに関連するサブセットがコードのある場所にも存在している状態です。
ページ間のリンクはほとんど機能しなくなります。 Notion の内部リンクはワークスペースの URL です。エクスポートされたフォルダ内では、それらは Notion を指し示すか（ワークスペースを維持していれば問題ありませんが、オフラインでは役に立ちません）、エージェントが想定していないファイル名に解決されます。エクスポートされたドキュメントは、Notion で見ていたときよりもフラットで、相互のつながりが薄いものになると想定しておいてください。
手動での移行手順
ステップ 1: コーディングエージェントが実際に使用できるページをエクスポートする
最初のステップとして、ワークスペース全体のエクスポートを行うのは避けましょう。これは最も時間がかかる方法（最大30時間）であり、ミーティングの議事録やマーケティングページまで引き込んでしまいます。また、その膨大な量のせいで、本当に重要な「仕分け」のステップをスキップしてしまうことになります。
代わりに、Notion のサイドバーを確認し、ページを次の3つのバケットに分類してください：
- ビルドに関連し、かつ永続的なもの — 仕様書、アーキテクチャ設計書、スキーマ、API コントラクト、意思決定ログ、クライアントの厳格な制約事項。これらがエクスポート対象です。
- ビルドに関連するが、流動的なもの — スプリントボード、タスクデータベース、ステータスページ。これらは Notion に残しておきます。コーディングエージェントにとって、先週のボードのスナップショットは何の役にも立ちませんし、そのスナップショットは数日以内に実態と乖離します。
- ビルドに関連しないもの — その他すべて。ワークスペースの大部分がこれに該当します。
次に、最初のバケットをエクスポートします。各ページを開き、エクスポートオプションを使用し、Markdown & CSV を選択します。そのページが親ページである場合は「サブページを含める」を有効にします（個別ページのサブページエクスポートが利用できないプランの場合は、ワークスペースのエクスポートを使用してください）。これにより、.md ファイルとアセットのフォルダが取得できます。
進めるにあたって、2つの点を確認してください。1つ目は、誰かのプライベートページにあるために、期待していたものが欠落していないかということです。意思決定ログに抜けがある場合、大抵はこれが原因です。2つ目は、エクスポートしようとしているページが、実はデータベースではないかということです。スキーマが Notion のテーブルにある場合、取得できる CSV はリレーションのない単なる行データになります。不完全な CSV を渡すよりも、スキーマを適切に書き出す方が賢明です。
ステップ 2: Notion ページをルールとリポジトリドキュメントに変換する
エクスポートされた Notion ページは、そのままではエージェントにとって有用なインプットにはなりません。Notion ページは、人間が閲覧するために書かれています（見出し、トグル、コールアウト、途中のテーブル、冒頭の3段落にわたる経緯など）。Cursor が必要としているのは、短い常時適用ルールか、参照先として指定できるドキュメントのいずれかです。
Cursor には2つの異なる格納場所があるため、この違いによって分類します：
常時適用される規約 → `.cursor/rules`。プロジェクトのルールは .cursor/rules 内に .mdc ファイルとして保存され、バージョン管理されます。これにはフロントマターのフィールドである description、globs、alwaysApply が含まれ、4つのアクティベーションモードがあります：
- Always Apply（常に適用） — すべてのチャットセッション
- Apply Intelligently（インテリジェントに適用） — エージェントが説明（description）に基づいて関連性があると判断したとき
- Apply to Specific Files（特定のファイルに適用） — ファイルがパターンに一致したとき
- Apply Manually（手動で適用） — チャットで @ メンションされたとき
この粒度を活用してください。API の規約には、API ディレクトリを指す globs を設定します。一般的なエンジニアリング標準は、「Customize」→「Rules」の下にある User Rules に配置し、すべてのプロジェクトに適用させます。Cursor のドキュメントでは、ルールを500行未満に抑え、大きなルールは組み合わせ可能なパーツに分割することを推奨しています。これは優れたアドバイスです。なぜなら、「Always Apply」に設定されたものはすべてのリクエストで読み込まれるからです。また、.cursor/rules の代わりにプロジェクトのルートにある AGENTS.md を使用し、サブディレクトリ内のネストされたファイルを含めることもできます。
参照資料 → リポジトリドキュメント。スキーマ、仕様書、意思決定ログは、整理された Markdown として docs/ に配置します（結論を先頭に、経緯は削り、日付は残す）。そして、ルール内に「db/ 以下の変更を行う前に docs/schema.md を読むこと」といった1行を記述してエージェントに参照先を伝えます。毎回読み込まれるルールにコンテンツを直接貼り付ける必要はありません。
構築したものに対して誠実になりましょう。Cursor 自身のドキュメントには、この仕組みが存在する理由が説明されています。「大規模言語モデルは、補完の間にメモリを保持しません。ルールは、プロンプトレベルで永続的かつ再利用可能なコンテキストを提供します。」 ルールはリクエストごとにコンテキストを再提供します。それらは、あなたがエクスポートして整理した「その時点」の情報を保持しますが、Notion は常に更新され続けます。
この乖離こそが、人々が過小評価しがちな部分です。来月、Notion で仕様書が更新されても、あなたの docs/spec.md は更新されません。2ヶ月も経てば、全員が最新の情報を読んでいると思い込んでいる一方で、エージェントは古いコピーに基づいて開発を行うことになります。
より良い方法：ドキュメントとコードをつなぐ単一のメモリレイヤー
ステップ 2 で行ったことを見てみましょう。ある製品のナレッジのスナップショットをエクスポートし、別の製品のフォーマットに手動で変換し、最初のコピーから乖離していく2つ目のコピーを作成しただけです。
本当にコストがかかるのは、作業に費やした午後ではなく、この「情報の乖離」です。そして、これこそが2つのツールの間にメモリレイヤーを挟むことで解決できる問題です。リポジトリ内の古いコピーの代わりに、単一のストアがビルドに関連するナレッジを保持し、両方のアシスタントがそこから読み込みます。これにより、一度記録された決定事項をすべてのツールが参照できるようになります。
MemoryLake はそのためのメモリレイヤーです。スキーマ、意思決定、制約事項を1つのストアに保持し、MCP 経由で Cursor から、また API 経由で他のあらゆるツールから読み取ることができます。これにより、エクスポートは「移行」ではなく、ドキュメントが変更されたときにいつでも繰り返せる「インジェスト（取り込み）」になります。
双方のメリットを公平に評価しましょう。Notion はドキュメント作成において本当に優れた場所です。共同編集、構造化、権限管理、そしてワークスペース全体を横断して回答する Notion AI は、いかなるルールファイルでも再現できません。これは維持すべきです。そして、.cursor/rules はバージョン管理されたプレーンテキストであり、プルリクエストでレビューされ、チームに自動的に継承されます。常時適用される規約にはこれも維持すべきです。メモリレイヤーは、その中間にあるナレッジのためのものです。ルールファイルにするには長すぎ、スナップショットのまま放置するには重要すぎ、複数のツールから必要とされるナレッジです。
ステップ 1: API キーを作成する
キーを生成すれば、約30秒で最初のリクエストを送信できます。コミットされる設定ファイルではなく、環境変数やシークレットマネージャーに保管してください。
ステップ 2: 最初のメモリをアップロードする
先ほど仕分けたドキュメント、画像、ファイルを投入します（仕様書、アーキテクチャ設計書、スキーマ、意思決定ログ、クライアントの制約事項）。可能であれば、要約されたサマリーではなく、エクスポートされたソースをそのままアップロードしてください。要約の過程で削ぎ落とされた注意書きこそが、6週間後に重要になることがよくあるからです。
ステップ 3: AI とエージェントを接続する
Claude、Codex、OpenClaw、その他の AI エージェントに、MCP または API 経由でメモリへのアクセス権を付与します。Cursor は MCP サーバーをサポートしているため、これは設定を追加するだけです。MCP クライアントを持たないツールの場合は、API 経由で必要な情報を取得し、プロンプトやワークフローに注入します。
実務における変化
最初の違いは、「テナンシーについて何を決定したか？」という疑問に対して、Notion のタブを開くことなく、その理由とともにエディタ内で回答が得られるようになることです。
2つ目は、コピーが古くなる問題が解消されることです。双方のツールが同じストアを読み込むようになれば、決定事項を更新するだけで、すべての場所で更新が反映されます。Notion を更新したものの、docs/ 内のファイルが古いまま放置され、密かに矛盾が生じるといった事態は防げます。
3つ目は、却下された選択肢が却下されたまま維持されることです。引き継ぎ後に最もよくある失敗は、仕様書で明示的に除外されたアプローチをエージェントが提案してくることです。これは、その除外理由が誰もエクスポートしなかった Notion ページに眠っていたために起こります。理由とともにストアに保管されていれば、そのようなことは起こりません。
そして、これは一般化できます。「仕様書はドキュメントツールにあり、コードはエディタにある」という構図は、ドキュメントツールが Notion であろうと他のであろうと、エディタが Cursor であろうと次世代のものであろうと同じです。リサーチをコーディングエージェントに移行する場合や、プロトタイプを本番用のエディタに移行する場合に、最終的に同じレイヤーが必要になるのもこれと同じ理由です。
移行のベストプラクティス
エクスポート後に仕分けるのではなく、エクスポート前に仕分ける
ワークスペース全体のエクスポートには30時間かかることがあり、すべてが出力されるため、仕分け作業をスキップしてしまいがちです。厳選された10ページは、雑多な400ページに勝ります。また、仕分けを行うことで、初めて「最新」の仕様書に3つの競合するバージョンが存在することに気づくことができます。
流動的なページは一切エクスポートしない
スプリントボード、タスクデータベース、ステータスページは、エクスポート後数日で実態と乖離します。これらは Notion に残し、必要に応じて Notion を参照するようにしてください。動き続けるデータのスナップショットは、データがないことよりも悪影響を及ぼします。なぜなら、それらは一見「正しい情報」のように見えてしまうからです。
権限による情報の欠落を確認する
エクスポートでは、チームメンバーのプライベートページなど、アクセス権のないページが静かに除外されます。意思決定ログが記憶よりも薄いと感じたら、まずこれを確認してください。解決策は、エクスポートを再実行することではなく、担当者に直接確認することです。
CSV をそのまま渡すのではなく、スキーマを適切に書き出す
Notion のデータベースは行データとしてエクスポートされます。リレーション、ロールアップ、ビューといった、データを分かりやすくしていた要素は失われます。データベースが構造的な情報の信頼できる唯一の情報源（Source of Truth）である場合は、関係性を文章で説明したドキュメントとして書き出してください。
移行するすべてのドキュメントに日付を入れる
エクスポートされたドキュメントはスナップショットであり、この移行における最大の懸念は、スナップショットが最新のものと誤解されることです。ファイル内にエクスポート日を記載してください。1行追加するだけで、単に古いドキュメントであるか、誤解を招くドキュメントであるかの違いを生みます。
結論
Notion から Cursor への移行は、単なる転送ではなく「変換」です。ビルドに関連するページを Markdown & CSV としてエクスポートします（個別ページごと、またはワークスペース全体の場合は「設定」→「ワークスペース」→「設定」から。大容量のエクスポートはメールで届き、リンクの有効期限は7日間、処理に最大30時間かかる場合があること、アクセス権のないページは除外されること、そして2026年8月31日までにワークスペースの PDF エクスポート機能が廃止されることに注意してください）。その後、常時適用される規約をスコープが定義された .cursor/rules に変換し、参照資料は日付を明記したリポジトリドキュメントにして、エージェントに参照させます。
慎重に検討すべきなのは、移行した「その後」に何が起こるかです。docs/ 内のスナップショットは、Notion 側が更新されるまでの間しかリポジトリに貢献しません。双方のツールが読み込むメモリレイヤーを導入すれば、一度記録した決定事項がそのままエディタに反映されます。これこそが、次の四半期に同じ作業を繰り返さずに済む唯一の方法です。