EvernoteからObsidianに移行した話

ふと思い立ってEvernoteの中身をローカルに保存することにしました。

方法についていろいろ調べていたのですが、EvernoteをエクスポートしてObsidianに取り込むというのが良さそう。

以前からクラウドにデータを保存することのリスクを感じていて、特にEvernoteに貯めるようなデータは数十年単位で参照可能になっていることを期待していますから、ローカルにMarkdownでそのまま保存できるObsidianはまさに目的通りのツールでしょう。

今まではVSCodeをMarkdownエディタかつ簡易的なビューアとして使っていましたが、良い機会なので本格的にObsidianへ移行しようと思います。

ついでにEvernote以外にもGoogle KeepやGoogleカレンダーのデータもObsidianに取り込んで、ローカルのライフログを構築しましょう。

Evernote -> Obsidian

Evernoteのアプリをインストールしてローカルに同期して、*.enex にエクスポートするだけやろ！って思っていたのですが。

無料版だと最大50個のノート、最大1冊のノートブックという制限があるらしい。幸いなことに7日間の無料トライアルが使えたので、この間に全部エクスポートしてしまいましょう。

AIによる補足

2026年8月時点でもEvernote Freeは「最大50ノート・1ノートブック」です。ただし公式の説明では、すでに上限を超えている既存ユーザーでも、既存ノートの閲覧・編集・共有・エクスポート・削除は可能とされています。

自分の環境では既存データをまともに扱えず困ったのですが、少なくとも「Freeにしたら既存データそのものが見られなくなる」というのが現在の公式仕様ではありません。

ただ、全てのノートブックを一括でエクスポートすることはできないらしく、50以上あったノートブックを1つずつ右クリックしてエクスポートするのはだいぶ面倒であった。。

AIによる補足

Evernoteの公式ヘルプでも、デスクトップアプリから一度にエクスポートできるのは「100ノート、または1ノートブック」となっています。大量にノートブックがある場合は、結局ノートブック単位での作業になる。

エクスポートしてしまえば、ObsidianのImporterプラグインからフォルダ指定で一括インポート可能なので早い。

AIによる補足

ImporterはEvernoteのENEXをMarkdownへ変換してくれるので、この用途にはかなり便利です。 ただし大量移行の場合は、ENEXの原本を消さずに残しておくのと、変換前後でノート数をざっくり確認しておくのがおすすめ。変換処理を何段階も通すと、後から「このノートどこ行った？」となった時に元データがないと詰みます。

Google Keep -> Obsidian

Google TakeoutからGoogle Keepを選択してアーカイブリクエストをします。容量によるのかもしれないけど、ものの数分でリンクが作成されてダウンロードできるようになる。

AIによる補足

Googleの公式説明では、Keepのエクスポートには本文だけでなく、リスト項目、画像・音声・描画などの添付、色、固定・アーカイブ状態、ラベルなども含まれます。

Importerプラグインからインポートできるけど、JSONの構造が単純なので自作のスクリプトで処理したほうが柔軟かもしれない。

JSONはこういうフォーマット。

{
  "color": "DEFAULT",
  "isTrashed": false,
  "isPinned": false,
  "isArchived": false,
  "annotations": [...],
  "textContent": "...",
  "title": "タイトル",
  "userEditedTimestampUsec": 1786096084982000,
  "createdTimestampUsec": 1783644710236000,
  "textContentHtml": "..."
}

自作の方がよい、と言っても自分で作ろうとするとやっぱり手間で、しかしAIと相談しながら仕様を詰めて実装までやってもらえば1時間もかからず高品質なスクリプトを作ってくれる。ほんとよい時代になりましたね。

仕様書とPythonスクリプトはこちら。

Googleカレンダー -> Obsidian

Googleカレンダーは 設定 -> インポート / エクスポート からエクスポートできる。

AIによる補足

全カレンダーをまとめてエクスポートするとZIPがダウンロードされ、その中にカレンダーごとの .ics が入る 個別のカレンダーは .ics として直接エクスポートできる ICSはiCalendar形式なので、開始・終了日時だけでなく、繰り返し予定、参加者、場所、説明なども持てる。

こちらもImporterプラグインからインポートできるけど、やっぱり比較的扱いやすいフォーマットなので自作のスクリプトで処理することにしましょう。

仕様書とPythonスクリプトはこちら。

文書の整理

データ移行自体は機械的にできるので比較的簡単なのですが、移行したデータを整理するのが一番大変かもしれない。

添付ファイルの整理

まず機械的にできるところから。

Local Images Plus

埋め込みデータがローカルファイルだと思っていたらリモートのURLを参照していることがあります。これは見た目では分からないので罠かもしれない。

こちらのプラグインでリモートの埋め込み参照をローカルにダウンロードしてリンクを更新してくれます。

AIによる補足

Web上の画像だけでなく、Markdownの埋め込みリンクやbase64画像のローカル化にも対応しており、MD5による重複排除の仕組みもあります。 Vault全体を一括処理するとノートそのものを書き換えるので、実行前にVaultを丸ごとバックアップしておくのが安全です。これは以下の添付ファイル整理系プラグインも同様。

Obsidianは参照先リンクのパスが多少間違っていても解決できてしまう場合があり、便利ですがミスに気付かないことがあります。

このプラグインで添付ファイルの参照が正しいかどうかチェックし、リンクを書き換え、添付ファイルを適切なフォルダに配置しなおしてくれます。

Check Vault Consistency でリンク切れや不正なリンクをチェックしてくれるので、エラーが無くなるまで確認しましょう。

Unique attachments

Local Images PlusでダウンロードしたファイルについてはMD5を使ってuniqueな名前を付けてくれますが、既にローカルにあるファイルについては別途整理が必要になります。

Evernoteの問題なのか、unknown_file みたいな名前のファイルが大量にできてしまい、整理してると意図せず上書きされてしまったり参照がおかしくなったりして困るんですよね。

このプラグインで添付ファイルをMD5を使ったuniqueな名前に書き換えてくれます。

例えばこんな感じ。

5be2a494d8c98092d803718d29fe14c0.png

ただこのプラグイン、使用には注意が必要です。

  • Consistent Attachments and Linksと同時に大規模な書き換えを走らせるのは避けた方がよい。使用前にConsistent Attachments and Linksは無効にしておくのがお勧め
  • 大量のファイルを処理すると時間がかかる（1ファイルあたり数秒）が通常画面には進捗が表示されない。コンソールには処理したファイルがログに出るので、Ctrl+Shift+I で開発者ツールを開いて確認できる
  • 処理対象の拡張子を確認しておく。自分の場合は png,jpg,jpeg,gif,pdf,bmp,svg あたりを対象にした。（場合によっては.doc, .docx, .rtfなどのドキュメント関連も必要になるかも）
  • Rename only active attachments がうまく動かない（別記事で触れる予定）
  • 当時コードを見た範囲では、ファイルのリネーム処理を await していない箇所もあった（実用上は特に問題にならなかった）

大量のファイルをインポートした後、1回だけ全体に適用するという使い方がよいと思います。（もっと安定して高機能なプラグインがあるかもしれない）

旅行関連メモの整理

何しろEvernoteの思想（？）として持て囃されていたのが「雑にデータをぶっ込んでおいても検索で探せる！」というものだったので、旅行関連のメモは地域名でノートブックを作って予約情報やら行きたいお店のメモやら日記やらを全部ぶち込んでて、後から見返すと大変なカオスになっていました。

今は本当に便利なもので、MarkdownファイルをAIに渡して整理してもらえば一発できれいにやってもらえます。

最終的にこういうプロンプトになりました（これは整理してもらったもので、実際はもっとゴチャゴチャ説明していますが）。

添付したZIP内のMarkdownを、情報を失わない範囲で整理してください。

目的は、散在しているスポット情報を後から参照しやすいMarkdownに再構成することです。

【分類】
大きなジャンルごとに1ファイルにしてください。
例：
- 食事
- 観光・レジャー
- 交通
- 宿泊
- 買い物
- 通信・作業環境

食事については、1ファイル内をさらに
「ラーメン」「うどん」「居酒屋」「海鮮」などのセクションに分けてください。

【統合】
同じ店・施設が複数文書に登場する場合は1件に統合してください。
「行きたい」「訪問済み」「wishlist」などの状態は区別せず、同じスポットとして扱ってください。
重複を統合した旨を本文に書く必要はありません。

【リンク】
店や施設そのものへ直接アクセスできるURLがある場合は残してください。
食べログ、公式サイト、Google Maps等は残して構いません。

SNS投稿やブログ記事から店名を抽出した場合、
元のSNS・ブログURLは原則として残さないでください。
ただし、その記事自体を保存する意味がある場合は例外としてください。

【本文】
Web記事を丸ごと保存するのではなく、
スポットを特定するのに必要な情報や、
個人的なメモ・感想だけを簡潔に残してください。

【添付ファイル】
Markdownから参照されている attachments 以下のファイルは維持してください。
参照されていない添付ファイルは無理に残さなくて構いません。

内容を推測して存在しない店名や情報を補完しないでください。
判断できないものは無理に分類せず、その旨が分かる形にしてください。

最後に整理後のZIPを作成してください。

旅行の日記もあったので、こちらは別途まとめてもらいました。

日記の長さにもよりますが、昔の自分は謎に長文日記を書いていたので、日ごとに2、3点のハイライトをまとめてもらうようにしました。これ結構おもしろいのでやってみるとよいです。

【ルール】

- 1日につき1セクション
- 同じ日の文書が複数ある場合は統合
- 内容が重複している部分は自然に1つにまとめる
- 重複を統合したことは書かない
- 日付別まとめには各日2〜3件程度の要点を書く
- 本文は原文をできるだけ保持する
- 要約によって本文を短くしない
- 元資料に存在しない日付や出来事を作らない
- 内容がない日付を勝手に補完しない
- YAML / properties / タグは削除
- 先頭の不要な空行を削除
- Markdownの見出し階層を整理

AIによる補足

この「本文は原文をできるだけ保持する」「要約によって本文を短くしない」は結構重要。 単に「整理して」と頼むと、AIは良かれと思って内容まで要約してしまうことがあります。アーカイブ用途では、構造は変えてよいが原文は消さないという境界を明示した方がよい。

↑そうなのか笑

その他雑多なメモの整理

何しろEvernoteの思想（？）として持て囃されていたのが「雑にデータをぶっ込んでおいても検索で探せる！」というものだったので（略）

1つずつメモを読んで分類するのは大変すぎますが、これもAIに頼めばいい感じにやってくれます。

元のプロンプト？はこういう感じでした。

1日1セクションにまとめる
年ごとに1ファイルとする
重複した内容はマージする
文章として意味をなさない断片的な情報はtrashへ
健康関連はhealthへ
個人の意見や感想があれば日記として扱う
800文字以上でテーマ性のある文章はwritingsへ

一時的なメモやWebのコピーなど長期的なデータとして意味のないものが多すぎる一方、短い内容でも日記的な文章が入っていたりと機械的に分けるのが難しく、AIに内容を読んで判断してもらうのがベストだと思います。

また、個人的な事情により健康に関する話題は日記とは別に分けておきたいため特筆事項としました。

改良版プロンプトとして作ってもらったものはこちらです。なげーな。

添付したZIP内のMarkdownを、日記アーカイブとして再整理してください。

最も重要なのは、文字数ではなく本文の意味を読んで分類することです。

【日記】
日記として扱える文書は、年ごとに1つのMarkdownへ統合してください。

形式：

# 2024 日記

## 2024-01-01

本文...

## 2024-01-02

本文...

同じ日付に複数文書がある場合は1セクションに統合してください。

内容が重複している場合は自然にマージし、
「重複を統合しました」などの注記は不要です。

元文書内に見出しがある場合は、
日付見出しの子になるように見出しレベルを調整してください。

【日記として扱う基準】
以下のいずれかが含まれていれば、短文でも原則として日記として扱ってください。

- その日に起きた出来事
- 自分がしたこと
- 自分の感想
- 自分の考え
- 感情
- 後から振り返る意味がある個人的記録

単なる情報メモに見えても、
本人の意見や感想が含まれている場合は日記を優先してください。

【trash】
以下のように、個人的な文章として意味をなさない文書は
trash ディレクトリへ移動してください。

- URLだけ
- Webクリップの断片
- パスワードやアカウント情報
- 製品型番やスペックだけ
- イベントの時刻表だけ
- スケジュールだけ
- 名前の羅列
- ゲーム攻略データ
- コピーした資料だけ

ただし、これらと日記本文が混在している場合は、
日記部分を残し、明らかに不要な情報だけ除去してください。

【health】
体調、病気、症状、治療、薬、検査など
健康に関する記録は health ディレクトリへ移動してください。
文章が短くてもhealthを優先してください。

【writings】
800文字以上あり、
日記ではなく特定テーマについてまとまって書かれた文章は
writings ディレクトリへ移動してください。

例：
- エッセイ
- 手紙
- レビュー
- 考察
- 長文の推しへの文章
- 特定テーマを振り返った文章

単に長い日記はwritingsにしないでください。
「その日の出来事」が中心なら日記のままとしてください。

最後に以下の構成でZIPを作成してください。

2020_日記.md
2021_日記.md
...
health/
writings/
trash/

また、分類結果を確認できる簡単な「分類概要.md」も作成してください。

改めてプロンプトを見ると、ある程度の汎用性はありますが自分のメモの傾向がわりと出てますね。。

一旦Markdownを全部読ませて、分類する大項目について詰めたほうがいいかもしれないですね。

AIによる補足

大量のファイルをいきなり「整理して」と投げるより、

  1. まず内容を読ませて分類案だけ出してもらう
  2. 分類基準を人間側で修正する
  3. その基準で実際にファイルを生成してもらう
  4. 最後に件数やリンク切れを機械的に検証する

という二段階、三段階のやり方の方が事故は少ないと思います。

特に大量ファイルでは、AIによる意味ベースの判断と、スクリプトによる件数・重複・リンク検証を組み合わせるのが相性よいです。

まとめ

データの移行から大量の文書のまとめまで、AIのおかげでずいぶん作業が楽になりましたね。手作業でやってたら1週間はかかるような作業が1日で終わってしまった。

そしてかつてEvernoteが流行していた時代の「何でもデータを入れて後から検索する」という使い方から、「大量のデータをAIに整理してもらう」という使い方へのパラダイムシフトを強く感じます。

Obsidianにまとめたデータ自体も、必要に応じてAIから使えるわけで。時代は進歩してますなー。

AIによる補足

ここでいう「AIに使う」は、必ずしもモデルそのものを追加学習するという意味ではありません。ローカルのMarkdownを検索して関連部分だけをAIに渡す、いわゆるRAG的な使い方でも十分に「自分の過去データをAIから参照できる」状態を作れます。 そして何より、元データがプレーンなMarkdownとして手元に残っていれば、特定のクラウドサービスやAIサービスがなくなっても別のツールへ持っていける。この点が今回Obsidianへ移行した一番大きなメリットかもしれません。