Evernoteをやめて、書類の墓場をGoogle Driveに一本化した —— Paperless-ngxを見送った理由と、スキャンしたら勝手に名前が付く仕組み

#生活#ホームラボ

14年分・1,115件のノートをためたEvernoteを、Google Driveに移しました。移行そのものは3日で終わり、いまは自宅のスキャナで紙を読み込むと、数時間後にはDriveの年別フォルダに「2026年_固定資産税納税通知書_〇〇市.pdf」のような名前で並んでいます。私がやるのはスキャナのボタンを押すことだけ。

この記事は「何を選び、どう組んだか」の話です。移行そのものをAIに任せてどう事故を防いだかは、姉妹記事の「合計は合っているのに中身が違う」に書いたので、そちらは触れる程度にします。同じ状況(ScanSnapで書類をためてきて、Evernoteを続ける気が薄れてきた)にいる人向けです。

序章: 私のEvernoteは「データの墓場」だった

まず自分がEvernoteを何に使っていたかを正直に数えたのが、判断の出発点でした。

  • 用途の9割は、ScanSnapで取り込んだ書類のPDF。税金、株、保険、自治体の通知、契約書、領収証
  • 放り込む頻度は月に数件。取り出す頻度はもっと低く、年に数回、確定申告や何かの手続きのときに検索で引っ張り出す
  • スキャナ本体のボタンを押すだけでEvernoteに入る、という低摩擦は絶対に維持したい
  • スマホから、外出先でも見られること

つまり私に必要なのは「ノートアプリ」ではなく「OCR付きの書類保管庫」でした。書きもの・Webクリップ・タグ付けといったEvernoteの本領は、ほぼ使っていない。この認識が固まると、候補はかなり絞れます。

第1章: Paperless-ngxを本命にして、止まった

自宅にMac Studioが常時稼働しているので、最初の本命はセルフホストの書類管理ソフト、Paperless-ngxでした。DockerでPostgreSQL・Redis・ワーカーを立て、consumeフォルダにPDFを放り込めばOCR・タグ付け・全文検索が自動で走る。書類種別や対応相手での構造化検索もできる。7月に「ScanSnap Cloud → Google Drive → rclone → Mac StudioのPaperless-ngx、外からはTailscale経由」という構成まで描き、Evernoteのエクスポート(ENEX)を調べるところまで進めました。

そして1ヶ月止まりました。

止まった理由は単純で、必要性が薄かったからです。8月に相談役のClaudeから「データの墓場という要件が出た時点で、Google Drive単体で十分。Paperless-ngxはタグや書類種別で構造化検索したい場合の上乗せで、低頻度・キーワード検索・放り込むだけの用途には過剰」と言われ、反論できなかった。7月から止まっていること自体が必要性の低さの証拠だ、とも。

改めて要件と照らすとこうなります。

要件 Google Drive単体 Paperless-ngx
スマホ閲覧 公式アプリ Tailscale + Web UI or サードパーティアプリ
PDFの日本語全文検索 何もしなくても効く tesseractで自前OCR
スキャナ直送 ScanSnap Cloudから直接 Drive経由でrclone中継
保守 なし Docker 3コンテナ、DB、バックアップ責任
構造化検索(タグ・種別・相手) なし ある

最後の行だけがPaperless-ngxの勝ちで、それを私は年に数回しか使わない。月数件の流入に、常駐スタックを養うのは割に合わない。「ラボにあるから立てる」は、動機として弱い。Paperless-ngx自体への興味は残っているので、リリース監視には「未導入」として登録して動向だけ追っています。

第2章: 引っ越す前に、荷物を数える

移行先をDriveに決めても、Evernoteの中身を把握しないと計画が立ちません。エクスポートしたENEXは14本・約1.77GB。中身はXMLで、添付ファイルはBase64で埋まっているので、そのままでは何が何件あるか分からない。

ここでClaude Codeに enex_inspector という調査スクリプトを書かせました。lxmlのiterparseでXMLをストリーミングし、Base64本文はデコードせずにmimeタイプとサイズだけを読んで、ノートブック別に「ノート数 / PDF数 / 画像数 / テキストのみ数 / 添付総量」を表にする。読み取りのみで壊しようがない。14本1,115ノートの走査は、MacBook Airで11秒でした(私は数十分かかると思っていた)。

結果はこうです。

  • PDF 919件。うち258件(28%)はテキスト層がなく、Driveに入れても検索に引っかからない。古いScanSnapの設定や、EvernoteがOCRを自前で持っていたせいでPDF側には埋め込まれていなかったもの
  • テキストだけのノート 92件
  • 音声 25件(多くはほぼ月刊で配信していたポッドキャストの素材)、Office/zip/mp4 13件
  • 画像 416件。中身を確認すると、大半はEvernote公式ブログのWebクリップ本文や、行動記録アプリの30×30ピクセルのアイコンで、残す価値がない

この表があったので、移行の線引きは推測でなく数字で決められました。PDFは全部Driveへ(テキスト層のない258件はOCRしてから)、テキストノートはMarkdownに変換してDriveへ、音声・Officeも取り出せる形でDriveへ、画像は移行せずENEXの中に残す。ENEX原本は移行後も捨てないので、いつでも戻れる。

enex_inspectorの出力表。ENEX 14本・1,115ノートをノートブック別に、PDFのテキスト層あり/なし・画像・その他添付・テキストのみの件数と推定添付総量で集計している

第3章: これからの流入をどう受けるか

過去分を移すだけなら一度きりの作業ですが、紙は今後も月数件入ってきます。Evernote時代は、ScanSnap CloudがEvernoteに直接放り込み、EvernoteがOCRして検索できる状態にしてくれていた。Driveに変えると、ScanSnap CloudはDriveに直送できるものの、届くファイル名は 2026_09_14_12_30_45.pdf のような日時か、ScanSnap側のOCRが読んだ文書内日付になる。中身が何かは開かないと分からない。

Driveは全文検索が効くので「開かなくても探せる」のですが、フォルダを眺めたときに何の書類か分かる名前が付いていてほしい。これは検索とは別の要求です。

そこで作ったのが drive-renamer。Mac Studioで1日2回(8:30と20:30)動くlaunchdジョブで、やることは以下。

  1. rcloneでDriveの受信フォルダ(ScanSnap/)を見に行き、新着PDFを取る
  2. テキスト層がなければocrmypdfでOCRし、同じファイルを上書き(Drive上は新リビジョンになるので元も残る)
  3. PDFの冒頭テキストを自宅で動いているローカルLLM(GB10クラスタ上のDeepSeek-V4-Flash)に渡し、YYYY年_種別_発行元.pdf の名前を返させる。年は文書に書かれた実日付、スキャン日ではない
  4. Archive/YYYY/ へ移動
  5. 結果をDiscordに通知。LLMが落ちていたら保留して次回に回す。正常終了はUptime Kumaにpushして、動かなくなったら気づけるようにする

LLMをローカルにしたのは、機微書類(源泉徴収票、保険、口座の通知)を外部APIに投げたくなかったからです。自宅にたまたま推論サーバーがあるからできる贅沢で、無ければClaude APIのHaikuあたりで十分な仕事量です(その場合はマスク処理を考える必要がある)。

ScanSnap側の設定は、iX100のクラウドプロファイルを「Google Drive の ScanSnap フォルダに、検索可能PDF・日本語で保存」に変えるだけ。プロファイルの編集はMac版ScanSnap HomeだとGoogle Driveの認証で失敗し、Android版のScanSnap Homeからは通った、という小さな罠がありました。有料のScanSnap Cloud+は不要です。

ScanSnapのボタンを押してからDriveの年別フォルダに名前付きで並ぶまでの流れ図。ScanSnap Cloudが受信フォルダに置いたPDFを、Mac Studioのdrive-renamerがrclone・ocrmypdf・ローカルLLMの順に処理してArchive/YYYY/へ移し、結果をDiscordとUptime Kumaに送る

第4章: 過去分の一括移行(要点だけ)

drive-renamerが動き出してから、過去分の1,115ノートを同じ命名・同じフォルダ構成でDriveに入れました。抽出→OCR→LLMで命名→アップロードの4段階、各段階でdry-runを見て承認する方式で、Claude Codeに任せて3日。結果は1,031ファイル・1.09GiB、事故ゼロ。

ただし、途中で規則を10回変えています。ScanSnapが読み違えた日付をLLMがそのまま信じる、発行元が読めないと「発行元不明_発行元不明.pdf」が31件並ぶ、年賀状の年をスキャン年で分けると「2006年の年賀状」が2014フォルダに入る。どれも実データを見るまで気づけない穴で、そこをどう潰したかは姉妹記事に書きました。移行を自分でやる人には、そちらの「規則は実データに当てるまで穴が見えない」が一番役に立つと思います。

もうひとつ、地味に効いたのがタイムスタンプです。アップロードしたファイルの更新日時を、Evernoteのノート作成日時(=スキャンした日)に揃えました。これをやらないとDrive上の「最終更新」が全部移行日になり、日付順で眺める・期間で絞るが効かなくなる。rcloneはローカルのmtimeをDriveの更新日時として引き継ぐので、アップロード前にmtimeを設定するだけで済みます。

スマホのDriveアプリで開いた2019年フォルダ。上6件はLLMが読めずタイトルに戻した例、下は種別と発行元まで付いた例。変更日はスキャン当時の日付になっている

第5章: 移行後の使い心地と、正直な残件

移行後の日常はこうです。スマホでDriveアプリを開いて「固定資産税」で検索すると、2014年から今年までの通知が名前付きで並ぶ。Evernoteのときと体験はほぼ変わらず、月額はなくなり、ロックインもなくなりました。ENEX原本はMacとNASに置いてあるので、Driveが気に入らなくなっても戻れます。

残件も書いておきます。

  • drive-renamerの運用実績はまだ数日。流入が月数件なので、命名の精度や保留の頻度が見えるのは数ヶ月先。ここは追記します
  • rcloneがGoogle Driveに使う共有のclient_idは2026年中に廃止予告が出ていて、自前のOAuthクライアントに切り替える必要がある。切り替えないとある日止まる
  • Driveの容量は今回1.1GBしか増えていないので当面問題なし。ただし「墓場」なので減ることもない
  • 名刺と年賀状はDriveの _名刺/ _年賀状/YYYY/ に入れただけで、連絡先アプリなどには移していない。使う予定がないので放置

終章: 判断のまとめ

  1. 自分の使い方を数えてから選ぶ。「ノートアプリ」だと思っていたものが「書類保管庫」だった。用途が分かれば候補は勝手に絞れる
  2. ラボにあるからといって立てない。Paperless-ngxは良いソフトだが、月数件・年数回検索の用途には常駐スタックが釣り合わない
  3. 引っ越す前に荷物を数える。enex_inspectorの11秒が、移行計画の推測を全部数字に変えた
  4. 低摩擦を守るために、後工程を作る。スキャナのボタンだけで完結する体験を保ったまま、名前付けと振り分けは裏で機械にやらせる
  5. 戻れる状態を残す。ENEX原本は捨てない。Driveが嫌になったら、また引っ越せばいい

※ファイル名の例は一部を差し替えています。使ったもの: ScanSnap iX100、ScanSnap Cloud、Google Drive、rclone、ocrmypdf、ローカルLLM(DeepSeek-V4-Flash / vLLM)、launchd、Discord webhook、Uptime Kuma。移行作業の詳細と、AIに任せて事故を防ぐ話は「合計は合っているのに中身が違う」へ。