ノートアプリを乗り換えるときのチェックリスト

数千件のノートを新しいアプリへ流し込み、一覧を日付順に並べ替えた瞬間に気づく。全部が今日の日付になっている。本文を開くと、画像があったはずの場所には壊れたリンクの記号だけが並んでいる。ノートアプリの乗り換えの失敗は、たいていこの形で、しかも作業の後半になってから発覚します。気づいたときには時間も気力も使い果たしていて、旧アプリと新アプリに中途半端に分かれたノートだけが手元に残る。数年分のノートを持って移るなら、流し込む前の確認にこそ時間を使う価値があります。

ノートアプリを作る側の立場から言えるのは、ノートのデータは見た目よりはるかにアプリ固有の形をしている、ということです。画面上ではどれも「テキストと画像のノート」に見えても、内部では本文の書式、添付ファイルの持ち方、日付やタグの記録方式がアプリごとに違います。乗り換えとは、この固有の形式からデータを引きずり出し、共通の形式を経由して、別の固有の形式へ流し込む作業です。経由地で何かが欠けるのが普通で、何も欠けない移行のほうがむしろ例外だと考えたほうが安全です。たとえば Notion の公式ヘルプは、コールアウトブロックには Markdown に相当する形式がないため、Markdown エクスポートでは HTML として出力されると明記しています(コンテンツのエクスポート)。共通形式に載らない要素は、こうして形を変えるか、消えます。

まずは、冒頭の「日付が全部同じになる」「画像が消える」がノートのどの層で起きるのかを見ておきます。原理が分かると、この後のチェックリストの各項目が何を守ろうとしているのかが読めるようになります。

ノートのデータはどこで欠けるのか

移行で問題が起きる場所は、だいたい決まっています。ノートというデータを分解すると、次の5つの層に分かれるからです。

• 本文のテキスト: 文字そのもの。基本となる層ですが、欠落や文字化けの確認は必要です
• 本文の書式: 太字・見出し・リストなどの装飾。アプリ独自の記法や埋め込み要素は、共通形式に変換した時点でただのテキストに退化するか、消えます
• 添付ファイル: 画像・PDF・音声。本文とは別の場所に保存されていることが多く、エクスポートに含まれない、含まれてもリンクが切れる、という事故が最多です
• メタデータ: 作成日・更新日など。ファイルの中身ではなく「ファイルについての情報」なので、コピーの過程で最も失われやすい層です
• リンクと構造: ノート間リンク、タグ、フォルダ階層。アプリが内部の仕組みで管理しているため、外に持ち出した瞬間に参照先や置き場所を失います

下の層ほど壊れやすい、と覚えておくと見通しがよくなります。テキストはまず無事、書式の残り方は方式によって変わり、添付とメタデータは確認しないと分からず、リンクと構造はほぼ作り直し。この前提でチェックリストを見ていくと、各項目が何を守ろうとしているのかが分かります。5つの層と、この後の項目で打つ手を並べると次のようになります。

なお、アプリが独自形式を使うこと自体は、必ずしも囲い込みの意図ではありません。タスク管理や手書き、表計算のような機能を持たせるには、プレーンテキストより複雑なデータ構造が必要になるからです。ただ、意図がどうであれ結果は同じで、機能が豊富なアプリほどデータは固有の形になり、出口は狭くなります。乗り換えを考えるとき、この機能と出口のトレードオフは常についてまわります。

移行前チェックリスト

移行を決める前に、次の7項目を確認します。どれも仕様表を眺めるだけでなく、実際に手を動かして確かめられるものです。

1. 旧アプリのエクスポート形式を確認する
2. 添付ファイルがエクスポートに含まれるか確かめる
3. 作成日・更新日が保持されるか確かめる
4. ノート間リンクとタグがどうなるかを把握する
5. 新アプリのインポートを10件で試す
6. ノートの量と移行先の上限を確認する
7. 移行作業にかける時間の上限を決める

それぞれ詳しく見ていきます。

1. エクスポート形式 — Markdown かプレーンテキストで出せるか

最初に確認するのはここです。Markdown またはプレーンテキストでエクスポートできるなら、本文についての心配は大半が消えます。どちらもただのテキストファイルなので、どんなエディタでも開け、特定のアプリが消滅しても読めます。

独自形式か PDF しか選べない場合は要注意です。独自形式は、それを読めるソフトが手に入らなくなった時点でデータとして死にます。PDF は人間が読む分には困りませんが、テキストとして編集・再利用する道がほぼ閉じます。ノートの価値の多くは検索と編集にあるので、「読めるが編集できない」形式は保管用であって、移行用ではありません。

出口と入口が非対称なアプリもあります。macOS Tahoe 26 のメモユーザガイドで書き出しの手順があるのは PDF と Markdown の2つで、読み込めるのは TXT・RTF・RTFD・HTML・Evernote の ENEX 形式、それと Markdown です(Macでメモを読み込む/書き出す/プリントする)。移行元として見るときはエクスポート形式を、移行先として見るときはインポート形式を、別々に確認する必要があります。

確認は仕様の記載だけで終わらせず、実際に1件エクスポートして、出てきたファイルをテキストエディタで開いてください。ひとくちに Markdown と言っても方言があります。CommonMark の仕様書は、曖昧さのない仕様が存在しなかったために実装が大きく分岐し、ある環境で一定の見た目に表示された文書が別の環境では違って表示される、と冒頭で説明しています(CommonMark Spec)。受け入れる側も同じ前提で作られていて、Notion の公式ヘルプはテキストと Markdown のインポートについて、標準の Markdown は取り込めるが「高度なマークダウンまたは非標準のマークダウン拡張機能(ツール固有の書式設定)」は取り込めないとしています(Notionにデータをインポートする)。見出しは見出しとして残っているか、リストは崩れていないか、チェックボックスや表のような凝った要素がどう出力されるか。自分の目で見るのが一番確実です。

2. 添付ファイル — 画像とPDFはどこへ行くか

添付は重点的に確認したい部分です。確認する点は2つ。エクスポートしたデータに画像や PDF のファイル自体が含まれているか。含まれている場合、本文からのリンクが生きているか。

よくあるパターンは、本文の Markdown と添付ファイルが別フォルダに出力され、本文側から相対パスで参照されているケースです。この場合、フォルダ構成を保ったまま新アプリへ読み込めればリンクは生き、フォルダ構成を崩すと全部切れます。Notion の HTML エクスポートはこれに近い形で、サブページを含めてエクスポートすると子ページごとにフォルダが作られ、そのフォルダにページの画像やデータが入る、と公式ヘルプが説明しています(コンテンツのエクスポート)。受け入れ側にも同じ注意があり、Notion の HTML インポートは「すべての HTML ファイルと、それらが参照する画像またはアセットが同じフォルダーにあること」を求め、画像が欠けたらアセットが同じフォルダか ZIP に含まれているかとパスを確認するよう案内しています(Notionにデータをインポートする)。もうひとつのパターンは、本文中の画像リンクが旧アプリのサーバ上の URL を指しているケースで、これは旧サービスへのアクセス条件が変わると開けなくなる可能性があります。エクスポートした本文を開いて、画像リンクが手元のファイルを指しているか、どこかの URL を指しているかを見れば判別できます。

画像を多用している人ほど、この確認を省略してはいけません。旅行の記録、ホワイトボードの撮影、レシートの控え。本文より添付のほうが本体、というノートは意外に多いものです。手書きのスケッチや音声メモを使っている場合は、それらがどんなファイル形式で出てくるかも見てください。手書きが画像として出れば閲覧には使えますが、筆跡の再編集などはできない場合があります。また、アプリ内でしか開けない形式でしか出ないなら、その部分は事実上持ち出せないものとして判断に織り込むことになります。

3. メタデータ — 作成日は「インポートした日」に化ける

多くの移行で、ノートの作成日は失われ、「インポートを実行した日」に化けます。数年分の日記やログが全部同じ日付になった状態を想像してください。日付順に並べて使っていた人には致命傷ですし、「あの出来事はいつだったか」をノートで確かめる使い方も崩れます。

この現象はノートに限った話ではありません。Google のデータエクスポートのヘルプは、写真や動画についての説明ですが、ダウンロードされた時刻に基づいて OS がファイル自体に新しいタイムスタンプを割り当てることがあり、元のタイムスタンプはファイルに埋め込まれたメタデータの側に残り続ける、と書いています(Google データをダウンロードする方法)。ファイルの外側に付いている日付は運搬で落ち、中身に埋め込まれた日付は残る。ノートでも同じ構図です。

対処は、エクスポートの前に日付を「中身」へ焼き込んでおくことです。ファイル名の先頭に 2024-05-10-打ち合わせメモ.md のように日付を付けるか、本文の1行目に日付を書く。メタデータ、ファイル名、本文の残り方は移行方式で異なります。必要な日付が読める形で残ったかを確認してください。旧アプリに一括リネームの機能がなければ、エクスポート後にファイル名を変換する一手間をかける方法もあります。すべてのノートに施す必要はなく、日記やログのように日付が本体の一部であるノートだけでも、先に手当てしておく価値があります。

4. ノート間リンクとタグ — 切れるのが標準

ノート間リンクは、アプリが内部IDで管理している場合、外に出した時点で切れるのが普通です。[[ノート名]] のような名前ベースの記法であれば、同じ記法を解釈する移行先では生き残る可能性がありますが、これは例外側だと考えてください。名前ベースのリンクでも、参照先が同じ移行の中に揃っていなければ解決できません。Obsidian の公式ヘルプが Notion からの移行で、内部リンクを正しく解決するために Notion のデータを一度に全部インポートすることを勧めているのは、この理由からです(Import from Notion)。タグも同様で、移行先に同じ概念がなければ、ただの文字列になるか消えます。

ここで確認すべきは「リンクが切れるかどうか」よりも「自分がリンクにどれだけ依存しているか」です。ノート同士を張り巡らせた網の目そのものが資産になっている使い方なら、その構造ごと持ち出せるかが乗り換え判断の中心になります。逆に、リンクをほとんど使わず検索でノートを見つける運用なら、リンク切れは実害になりません。移行の重さは、ノートの件数よりも、この依存度で決まります。後述する「必要な分だけその都度運ぶ」方式はリンクを切る前提の運び方なので、リンク依存度が高い人は、リンクでつながった一群だけはまとめて運ぶ判断になります。

5. インポートのリハーサル — 10件だけ試す

仕様の確認が終わったら、全量を移す前に10件だけで通し稽古をします。選ぶ10件は無作為ではなく、意地悪に選びます。画像が複数入ったノート、数千字の長文ノート、記号や絵文字だらけのノート、一番古いノート、リストや見出しを多用したノート。移行で壊れやすいものを意図的に含めるのがリハーサルの意味です。

同じアプリからのエクスポートでも、選ぶ形式で結果は変わります。Obsidian の公式ヘルプは、Notion からの移行に Notion の Markdown エクスポートを使わないよう勧めています。理由は「重要なデータが省かれる」からで、代わりに HTML エクスポートを指定しています(Import from Notion)。移行用の本命だと思っていた Markdown が最善とは限らない、という例です。リハーサルは、こうした差を全量を動かす前に知るための手段でもあります。

移した10件は、新アプリで開いて目視確認します。文字化けしていないか、改行が失われて段落が潰れていないか、画像が表示されるか、日付がどうなったか。あわせて、移した10件が新アプリの検索でちゃんと見つかるかも試してください。ここで見つかった問題は10件分の問題ですが、全量を移してから見つかれば数千件分の問題になります。リハーサルは遠回りに見えて、移行全体では最大の時間短縮です。

6. 量と上限 — 無料枠と容量を先に見る

ノートの総件数と添付の総容量を旧アプリ側で確認し、新アプリの制限と突き合わせます。無料プランの保存容量、1ノートあたりのサイズ上限、月あたりのアップロード量の上限。上限は公式ヘルプに書かれていることが多く、たとえば Notion のテキスト・Markdown・HTML のインポートは、1ファイルあたり無料プランで 5MB、有料プランで 50MB が上限だと明記されています(Notionにデータをインポートする)。全量インポートの途中で上限に当たると、中途半端に移った状態で止まり、どこまで入ったのかを確かめるだけで一仕事になります。容量が上限に近いなら、移行前に添付の多い不要ノートを削るか、有料プランの費用を移行コストに含めて判断します。

7. 時間の上限 — 移行作業に締切を切る

最後はデータではなく、自分の時間の話です。移行作業に使う時間の上限を先に決めてください。上限を決めないと、後述する「完璧な移行」の罠に落ちやすくなります。目安として、チェックとリハーサルに半日、本移行に半日。それで収まりそうにない規模だと分かったら、全量移行をあきらめて、次に説明する並行期間方式へ切り替えるサインです。

1. 公式の対応範囲を調べ、移行元からデータを書き出します。
2. 代表的なメモを移行先へ取り込みます。
3. 本文、添付、日時や構造を比べ、移行元を残して確認します。

出口の広さは公式ヘルプに書いてある

チェックリストの1番と2番は、多くの場合、公式ヘルプのエクスポートのページを読むだけで下調べが済みます。紹介記事や動画ではなく、開発元が書いた「何を、どの形式で、どこまで出せるか」の一覧を先に読むのが早道です。

Notion は「マークダウンとCSV」「HTML」「PDF」の3形式で、Markdown と HTML は ZIP にまとまって出てきます。データベース以外のページは Markdown に、データベースは CSV になります。PDF でサブページを含めるオプションはビジネスプランとエンタープライズプランに限られ、カスタム絵文字は PDF に出ません。エクスポートした ZIP が Windows で開けない場合はファイルパスの長さの上限が原因で、「子ページ用のフォルダーを作成」のオプションを外すか 7-Zip で解凍する、という対処まで公式ヘルプに載っています(コンテンツのエクスポート)。Mac のメモアプリは前述のとおり PDF と Markdown で書き出せ、読み込みは TXT・RTF・RTFD・HTML・ENEX と Markdown です(Macでメモを読み込む/書き出す/プリントする)。移行先の側にも読むべきページがあり、Obsidian のインポート手順は Notion のデータを他のアプリでも使える Markdown ファイルに変換すると述べたうえで、Notion 側では Markdown ではなく HTML でエクスポートするよう指定しています(Import from Notion)。

読むときのコツは、形式の一覧より「注記」を拾うことです。何が出ないか、どのプランで制限されるか、失敗したらどうなるか。注記に書かれているのは開発元が把握している欠損で、リハーサル10件の「意地悪な選び方」の材料にそのまま使えます。

移行の実際の手順

チェックが済んだら、次の順序で進めます。

1. 旧アプリから全量エクスポートし、日付を付けたフォルダ名で保管する(移行用とは別の、保全用の控え)
2. 意地悪に選んだ10件で、新アプリへのインポートをリハーサルする
3. 問題がなければ「今日から新規ノートは新アプリ」と境界日を決める
4. 旧アプリは読み取り専用の書庫として残し、新規の書き込みをやめる
5. 過去ノートは、実際に参照したものだけを、その都度新アプリへ移す
6. 並行期間の後、必要な記録と参照先、最終エクスポートの可読性を確認して、旧アプリの扱いを決める

この手順の核心は5番です。全ノートを一括で完璧に移すのではなく、「新規は新アプリ、過去は書庫」という並行期間を設けて、本当に使うノートだけを需要駆動で運びます。数年分のノートのうち、実際に読み返すのはごく一部です。全量移行は、その「読み返さない大多数」のために数週間を費やす作業になりがちで、並行期間方式はそれを回避します。移すかどうかの判断を、机上の分類ではなく「実際に開いたかどうか」という事実に任せるわけです。

「その都度移す」の実際は、たいていコピーアンドペーストで足ります。本文を貼り付け、必要な画像だけ添付し直し、末尾に元の作成日を1行書き添える。1件あたり数分の作業です。書庫を引く機会は多くても週に数回のはずで、この地道さのほうが数週間の一括移行より軽い、というのが並行期間方式の実感です。運んだノートには旧アプリ側で「移行済み」と分かる印を付けておくと、どちらが最新か迷わずに済みます。

境界日は、仕事の繁忙期を避けて選んでください。新アプリに慣れるまでの数日間は、メモを取る速度がどうしても落ちます。週末に境界日を置いて、静かな環境で新アプリの最初の数枚を書いてみるのが穏当です。

保全用の全量エクスポート(1番)だけは、並行期間方式でも省略しないでください。旧アプリのサービス終了、解約忘れによる自動削除、アカウントのトラブルなど、書庫が突然消える可能性は常にあります。エクスポート一式が手元にあれば、書庫が消えても最悪の事態にはなりません。これは移行の話であると同時に、バックアップの話でもあります。

よくある失敗と対処

整理してから移そうとして、頓挫する

一番多い失敗です。「どうせ移るなら、この機会に全部整理してから」と考えて、数年分のノートの棚卸しを始めてしまう。整理は移行の何倍も重い作業で、たいてい途中で力尽き、移行そのものが白紙に戻ります。散らかった旧アプリと、数十件だけ移した新アプリの両方が手元に残り、どちらも中途半端という最悪の着地です。

対処は、整理と移行を完全に切り離すことです。移行のときには整理をしない。汚いまま運ぶか、並行期間方式なら汚いまま書庫に置いておく。整理は移行が落ち着いてからいつでもできますが、2つのアプリに分裂した状態は時間が経つほど収拾がつかなくなります。

旧アプリの構造をそのまま再現しようとする

長年かけて育てたフォルダ階層やタグ体系を、新アプリで忠実に再現しようとするのも典型的な失敗です。アプリが変われば整理の道具立ても変わります。フォルダが得意なアプリ、タグが得意なアプリ、検索に寄せたアプリでは、同じ構造が最適とは限りませんし、そもそも再現できない場合もあります。

乗り換えは、構造を見直せる数少ない機会です。旧構造の再現に時間を使うより、フォルダ・タグ・検索という3方式の使い分けを踏まえて、新アプリの得意な形に寄せるほうが、その後の使い勝手は上がります。旧アプリで機能していなかった分類が、新アプリで機能し始めることはありません。

並行期間に、両方へ書いてしまう

境界日を決めたのに、手癖で旧アプリにも書いてしまい、「あのメモはどっちに書いたっけ」が始まるパターンです。書き先が2つある状態は、検索性を最悪にします。対処は意志ではなく物理的な障壁です。旧アプリの入口に「旧書庫」と目印を付け、読み取り専用として使う。ログアウトが未送信データや閲覧に影響する場合もあるため、手軽さだけで操作を決めない。「書かないように気をつける」より、書きにくくするほうが確実に効きます。

移行ツールの結果を確認しない

公式のインポート機能や有志の変換ツールは便利ですが、変換の癖は必ずあります。ツールを使った場合でも、リハーサル10件の目視確認は省略しないでください。データの化けは静かに起きます。エラーも警告も出さずに、画像だけが抜け落ちていた、更新日がすべて揃っていた、ということが実際にあります。ツールは作業を速くしますが、確認の責任までは肩代わりしてくれません。どのツールを使う場合でも原則は同じで、結果を目で確かめることと、実行前に旧データの控えを取っておくことです。

インポートをやり直して、重複だらけになる

途中で失敗した全量インポートをもう一度実行したら、成功していた分が二重に登録されてしまった、という失敗もよくあります。インポート機能の多くは「追加」であって「同期」ではありません。Notion の CSV インポートは既存の行を更新せず行を追加する動作で、公式ヘルプも重複がないか確認するよう注意しています(Notionにデータをインポートする)。同じノートが2枚ずつある状態は、検索のたびにどちらが本物かを考えさせられて、地味に消耗します。全量インポートの前には、新アプリ側を空に近い状態にしておくか、失敗したときに巻き戻せる手段(インポート先を分ける、実行前の状態を控えておく)を確かめてから実行してください。

旧アプリを先に解約してしまう

移行が終わった気になって、書庫として残すはずの旧アプリを解約・削除してしまう失敗です。解約すると読み取り専用の書庫が使えなくなるだけでなく、サービスによっては猶予期間の後にサーバ上のデータそのものが削除されます。解約してよいのは、最終エクスポートを取り、それが手元のエディタで開けることを確認した後です。この順序だけは逆にしないでください。

そもそも乗り換えるべきか

ここまで移行のやり方を書いてきましたが、その前段の判断にも触れておきます。乗り換えの動機が「新しいアプリが話題だから」なら、一度立ち止まる価値があります。移行には確認の手間がかかり、方式によっては欠損も起こるからです。

紹介記事や動画に映る新アプリは、理想的に整理された他人の運用です。あれは製品のいちばん良い顔であって、自分の数年分の雑多なノートを流し込んだ後の姿ではありません。そして、アプリを替えても解決しない問題があります。書く習慣そのものがない、分類を作り込みすぎて維持できない、といった運用側の問題は、道具を替えても再発します。このあたりはノートアプリが続かない理由で書いたことが、乗り換えの場面でもそのまま当てはまります。

一方、動機が「いまのアプリで具体的に困っていること」なら、乗り換えは有効な選択肢です。同期が遅い、検索が弱い、動作が重くなった、料金体系が変わった。困りごとが具体的なら、検証も具体的にできます。やることは、その困りごとが新アプリで本当に解決するかの確認だけです。方法は、過去ノートを移さずに、新規メモの運用だけで2週間使ってみること。移行コストを払う前に、解決の手応えだけを確かめます。手応えがなければそのまま戻ればよく、失うものはほとんどありません。

2週間の試用で見るのは、機能の一覧ではなく自分の行動です。困っていた場面で実際に困らなくなったか。メモを取る回数が減っていないか。試用期間中に旧アプリを開いた回数が多いなら、それは体が答えを出しています。

次のアプリ選びで見るべきこと

今回の移行で苦労した点は、そのまま次のアプリの選定基準になります。エクスポートで苦労したなら、次は標準形式で全量を出せるアプリを。添付で苦労したなら、添付をファイルとして取り出せるアプリを。日付で苦労したなら、メタデータを本文に焼き込みやすいアプリを。移行の痛みは、カタログからは読み取れない「出口の広さ」という基準を教えてくれます。

出口の広さとは、データを人質に取られない設計のことです。Markdown やプレーンテキストで、いつでも、全量を、添付ごと取り出せること。この性質はバックアップの記事で書いた「取り出せる」性質と同じもので、日常のバックアップと、いつか来る次の移行の両方を支えます。皮肉なことに、出口が広いアプリほど乗り換えの必要に迫られにくく、長く使えます。囲い込まないことがいちばんの引き留めになる、というのは道具として健全な姿です。

もうひとつ、乗り換えの頻度そのものにも触れておきます。ノートは道具の中でも蓄積が効くタイプで、乗り換えのたびに蓄積の一部が削れます。半年ごとに新しいアプリを渡り歩くと、どのアプリにも数か月分の断片だけが残り、全体としてはどこにも資産がない状態になります。乗り換えは数年に一度の引っ越しであって、模様替えではありません。だからこそ次のアプリは出口の広さで選び、簡単には乗り換えたくならない相手を選ぶのが理にかなっています。

あわせて見ておきたいのが同期の方式です。ノートがどこを経由して端末間を移動するのか、事業者にノートの中身が読める設計なのか。長く使うつもりのアプリほど、機能の派手さより、この土台を見てください。機能は後から増えますが、データの持ち方と同期の設計は、後からはめったに変わりません。方式ごとの違いは同期方式の記事に整理してあります。

よくある質問

全部移すのと書庫に残すの、どちらが正解ですか

ノートの量と依存度によります。数百件以下で添付も少ないなら、全量移行を候補にできますが、所要時間はリハーサルと実際の量から見積もります。数千件、数年分の規模なら並行期間方式を勧めます。判断の分かれ目は、リハーサル10件で出た問題の数です。問題の件数だけでなく、失われる情報の重要性と修正のしやすさを見ます。一つでも必要な情報が失われるなら、その扱いを決めてから進めます。

紙のノートからデジタルへ移るときも同じ考え方ですか

骨子は同じです。過去の紙ノートを全部打ち直すのは完璧主義の罠で、まず挫折します。現実的なのは「新規は今日からデジタル、紙のノートは本棚を書庫にする」という、この記事の並行期間方式そのままの運用です。よく参照するページだけ写真に撮ってデジタル側に置いておけば、検索の入口も作れます。紙とデジタルそれぞれの向き不向きは紙とデジタルの記事に書きました。

乗り換え先で最初にやることはありますか

検索の癖の把握と、書く場所の決定です。新アプリの検索がどう動くのか、部分一致で引けるのか、添付の中身まで見るのかを最初に試しておくと、書庫から過去ノートを引くときの判断が速くなります。そして、新規ノートを書き込む場所を1か所に決めてください。移行直後はフォルダやタグを作り込みたくなりますが、まずは書く場所を1つに絞るインボックス方式くらいの軽さで始めるほうが、新しいアプリでも書く習慣が途切れません。構造は、ノートが溜まってから必要に応じて足せます。

次の一歩

乗り換えを考えているなら、今日やることは移行ではありません。いま使っているアプリからノートを1件エクスポートして、テキストエディタで開いてみてください。5分で終わります。見出しは残っているか、画像はどこへ行ったか、日付はどこに書かれているか。その1件が、自分のデータの出口がどれくらい広いかを教えてくれます。あわせて、いま使っているアプリの公式ヘルプで「エクスポート」のページを探し、形式の一覧と注記を読んでおくと、1件の結果がなぜそうなったのかまで分かります。出口が広ければ、いつでも移れるという安心材料になります。出口が狭ければ、それこそが「話題の新アプリ」よりずっと具体的な、最優先で対処すべき困りごとです。

リハーサルの結果を、許容できる差と直す差に分ける

移行先の見た目が旧アプリと違うこと自体は、失敗ではありません。必要な情報が保たれ、日々の用途を続けられるかで判断します。架空の読書ノートなら色付きの枠がなくなっても使えるかもしれませんが、引用と自分の意見が同じ段落になると意味の区別が失われます。

この結果を短く残しておくと、本移行で同じ違いを毎回判断し直さずに済みます。一方で、リハーサルに含まれなかった種類のノートには、新しい問題がある可能性を残します。「十件通ったから全部同じ」とは考えず、長文や添付が多い群を移した後も対象に応じて確認します。

途中で止まっても、再開できる単位で移す

大量のデータを移す場合は、移行した範囲、出力した日時、取り込み先、確認結果を記録します。元のアプリが提供するIDや件数を使えるなら、それも照合の手がかりになります。タイトルだけでは、同名のノートを区別できない場合があるためです。

途中で失敗したときは、同じデータを再投入する前に、どこまで入ったかを確認します。移行専用のフォルダや保存先を使っていれば、普段使っている記録と混同せずに結果を調べやすくなります。取り込み済みの一部を消す場合も、元のデータと確認済みの控えがあることを先に確かめます。

リンクでつながったノートは、別々の小さな単位に分けると参照が解決されないことがあります。分割のしやすさだけでなく、移行ツールが要求するまとまりも優先してください。段階的に進める目的は細かく分割することそのものではなく、失敗の位置と、次に再開する位置を分かるようにすることです。

参考リンク

• コンテンツのエクスポート(Notion ヘルプ) — Markdown・HTML・PDF の3形式、コールアウトの HTML 出力、Windows のパス長対処
• Notionにデータをインポートする(Notion ヘルプ) — 非標準 Markdown 拡張の非対応、ファイルサイズ上限、CSV インポートの重複注意
• Import from Notion(Obsidian Help) — Markdown ではなく HTML エクスポートを使う指示と、内部リンク解決のための一括インポート
• Macでメモを読み込む/書き出す/プリントする(Apple サポート) — メモの書き出しが PDF と Markdown、読み込みが TXT・RTF・RTFD・HTML・ENEX であること
• CommonMark Spec — 仕様がなかったために Markdown の実装が分岐した経緯
• Google データをダウンロードする方法(Google アカウント ヘルプ) — ダウンロード時に OS がファイルへ新しいタイムスタンプを付けることがある旨