自前でEvernote環境を構築した話｜ScanSnap×Brotherの1.7万件PDFをNotionに移さずAIで0.4秒検索にした全記録【2026年11月更新】

はじめに：乗り換え先は探さない——1.7万件の生PDFの上に「自前でEvernote環境」を構築するまで

紙が届いたらスキャナに通し、ノートアプリに放り込む。確定申告の控えも、領収書も、保険証券も、学校のプリントも、医療費の明細も、裁断した本も、15年間ずっとそうしてきた。スキャナはScanSnap、置き場所はEvernote。この組み合わせは、長く仕えた「藩」のようなものだった。

しかし相次ぐ値上げと仕様変更の末、別のアプリへ引っ越すのではなく、自前でEvernoteと同じ環境を構築する道を選んだ。スキャナも専用アプリとの一体運用をやめ、レシートやはがきなどの非定形サイズは引き続きScanSnapで通し、A3・A4の定形書類や数十枚の束はブラザーのドキュメントスキャナーのオートフィーダー（ADF）で一気に流す2台並行運用へ切り替えている。手元にあるのは、Google Drive上に積み上がった17,172件・22.7GBのPDFだ。ファイル名は日付か、意味の読み取れない数字列。中身を覚えているものは、ほとんどない。

引っ越し先としてまず浮かぶのはNotionやAppleメモだ。だが、どちらもこの量のPDF書庫を受け止める器ではなかった。かといってGoogle Driveに置いたままでは、検索しても目的の1枚に辿り着けない。嫌になったのは年貢の重さと囲い込みであって、「紙をスキャンして放り込めば中身で即座に探せる」という初期Evernoteの体験そのものは手放したくなかった。この記事は、PDFをどこにも移さず、生ファイルの外側にOCRとAIエージェントを置くことで「自前のEvernote環境」を構築した記録である。

先に結論：移さない、名前を付けない、索引だけを外に作る

細部は後の章に譲り、やったことと結果を先に並べる。数値はすべて自分の書庫での実測値だ。

• PDFは1件も別のアプリへ移さず、1件もリネームしていない。Google Drive上の生PDF 17,172件（22.7GB）をそのまま正本にした。
• テキスト層が空だった6,740ファイル・17,392ページは、Macに標準で入っているOCRで文字を補った。クラウドOCRの課金は0円だ。
• 検索用の索引は、台帳14.4MBとシャード125個（約85MB）の合計約99MB。元データに対して99.5%小さい。
• AIエージェントが全件を横断検索する時間は実測356〜401ミリ秒。新しくスキャンした紙は、約1.2秒の増分更新で検索対象に入る。

この記事が役に立つ人、立たない人

想定する読者は、Evernoteの値上げや仕様変更をきっかけに移行先を探していて、しかも資産の中心がテキストのメモではなくスキャンしたPDFである人だ。ノートの大半が文章で、添付は時々という使い方なら、Notionへのインポートで十分に片が付く。この記事の出番はない。

仕組みはApple Silicon搭載のMacを1台、母艦として使う前提で組んだ。スキャナの機種は問わない。なお、文中に出てくる書類の例は、個人を識別できる番号や固有名を取り除いて一般化している。

なぜ「Evernote×ScanSnap」難民はNotionでもGoogle Driveでも救われないのか

「第2の脳」が年貢を取り立てるまで：Evernote改悪と値上げの17年史

移行先の話に入る前に、出てきた藩の側を振り返る。Evernoteは最初から年貢の重い藩だったわけではない。手元には、2009年から契約を続けてきたドル建てアカウントに届いた領収書と価格改定の通知メールが残っている。一般向けの円建て改定額にも触れつつ、このアカウントに実際に請求された額を軸に年表をまとめる。

時期	出来事	書庫派への影響
2009年7月	Evernote Premiumの課金を開始。年額45ドル。当時の円換算でも4,000〜4,500円ほど	「すべてを記憶する（Remember Everything）」の時代。ScanSnapで焼いた紙を放り込めば、PDFの中の文字まで検索に掛かる
2016年6月	無料のベーシックで同期できる端末を2台までに制限。有料プランも値上げ	最初の転換点。年貢が上がり始める
2020年	アプリをゼロから作り直したv10を公開	動作が重くなり、機能が減る。旧版のEvernote Legacyへ避難する古参が続出
2021年9月	旧PremiumからPersonalへ移行。初年度は割引で41.99ドル	初年度だけは、黄金期とほぼ同じ水準で済む
2022年9月	Personalが定価の69.99ドルになる。当時のレートで約9,000〜10,000円	ここまでは、黄金期の倍ほどで収まっていた
2023年1月	イタリアのBending Spoonsが買収を完了	領主が替わる
2023年8月	更新前の通知メールで、Personalを69.99ドルから129.99ドルへ引き上げると通告（約1.86倍）	「まったく同じ製品の料金が高くなるわけではない」との文面とともにAI検索などを予告
2023年9月〜2025年9月	毎年9月に129.99ドルを3回請求。円安と海外事務手数料を含め、1回あたり約20,000円	同じ書庫に同じ機能のまま、年貢だけが倍になる
2023年12月	無料プランの上限を「ノート50件・ノートブック1個」へ縮小	上限を超えている利用者は、新しいノートを1件も足せない
2024年3月〜8月	3月に旧アプリのLegacyが完全停止。4月に日本法人が解散を公告。8月に無料プランの同期端末を1台に縮小	v10以外の逃げ場と、国内の窓口と、無料で使い続ける道が順に消える
2026年8月	次回の更新でPersonalを廃止し、自動的にAdvancedへ移行すると通告。年額は249.99ドル	約39,000円。2022年の69.99ドルから4年で約3.6倍になる
2026年10月	契約主体がミラノのBending Spoons Operations SpAへ移転する通知が届く	領主の本拠が、完全に国外へ移る

出発点は2009年だ。年額45ドルでPremiumの課金を始めた。円換算でも4,000〜4,500円ほどの時代である。Evernoteは「すべてを記憶する（Remember Everything）」を掲げていた。ScanSnapで紙を焼いて放り込めば、PDFの中の文字まで検索に掛かる。紙の書庫を丸ごと預ける「第2の脳」として、この組み合わせは定着した。2009年から数えれば17年、紙を本格的に書庫へ回し始めてからでも15年を超える。

最初の転換点は2016年6月だ。無料のベーシックで同期できる端末が2台までに絞られ、有料プランも値上がりした。日本向けのプレミアムは年額4,000円から5,200円に上がった。2020年には、アプリをゼロから作り直したv10が出る。動作は重くなり、機能は減った。旧版のEvernote Legacyへ避難する古参が続出した。

2021年9月に旧PremiumからPersonalへ移り、初年度は41.99ドルで済んだ。翌2022年9月の請求は定価の69.99ドルである。当時のレートで約9,000〜10,000円だ。重くなったとはいえ、ここまでは一桁万円の範囲に収まっていた。

2023年1月、イタリアのBending Spoonsが買収を完了する。ここから速度が変わった。日本向けの円建て料金でも、同年5月にPersonalは年額5,800円から9,300円へ、Professionalは年額12,400円へ上がった。7月には米国とチリの拠点を閉じ、運営を欧州へ集約した。

ドル建ての契約には、同年8月に価格変更の通知メールが届いた。Personalの年額を69.99ドルから129.99ドルへ上げるという。一気に約1.86倍だ。文面には「まったく同じ製品の料金が高くなるわけではない」とあり、AI検索などの新機能が予告されていた。実際に請求されたのは、2023年9月、2024年9月、2025年9月の3回で、毎回129.99ドルである。円安の150〜155円台と海外事務手数料を足せば、1回あたり約20,000円になる。

同じ年の12月、無料プランの上限は「ノート50件・ノートブック1個」まで削られた。それまでの上限はノート10万件だった。すでに何千件も入れていた利用者は、既存のノートを開くことはできる。だが、新しい1件は足せない。無料の書庫は、中身を増やせない檻になった。

2024年は退路が順に塞がれた年だ。3月に旧アプリのLegacyが完全に止まり、v10以外の選択肢が消えた。4月には日本法人のエバーノート株式会社が解散を公告した。8月には、無料プランで同期できる端末が1台だけになった。

決定打は2026年8月の通知メールだった。次回の更新で旧Personalを廃止し、自動的に「Evernote Advanced」へ移行するという。年額は249.99ドルだ。1ドル155円に海外事務手数料を足せば、約39,000〜40,000円になる。2022年の69.99ドルからわずか4年で、ドル建てで約3.6倍。2009年の円換算4,000円台と比べれば、約9〜10倍の年貢である。同じ時期の円建て改定（Personal 9,300円、Advanced 17,899円）が穏当に見えるほど、ドル建ての古参アカウントに届いた請求は桁が違った。

同じメールで案内された下位プランが、Starterだ。年額は99ドルで、仕様は次のとおりである。

項目	Evernote Starter	この書庫の実測
ノート数	1,000件まで	17,172件
添付ファイル数	1,000件まで	17,172件
総ストレージ	1GBまで	22.7GB
端末数	3台まで	（問題にならない）

件数で17倍、容量で22倍を超えている。17,172件・22.7GBのPDF書庫を抱える人間にとって、Starterは降りる先にならない。残るのは、毎年約3.9万円（249.99ドル）を払い続けるか、脱藩するかの二択だ。さらに2026年10月には、契約主体がミラノのBending Spoons Operations SpAへ移るという通知も届いた。

機能が3.6倍になったわけではない。書庫派が使っているのは、今も昔も「PDFの中まで探せる」という一点だけだ。17年かけて積み上げた紙を人質に取られ、毎年重くなる年貢を払い続けるか。それとも脱藩するか。この記事は、その二択から始まっている。

テキストメモ派と「紙のPDF書庫派」は別の生き物

Evernoteからの移行を扱う記事の多くは、ノート本文が主役のテキストメモ派に向けて書かれている。ノートが数千件あっても、中身が文章なら容量は知れている。移行ツールが本文を運べば、それで終わる。

紙のPDF書庫派は事情が違う。ノート本文は空で、主役は添付されたPDFだ。今回の書庫では、それが17,172件・22.7GBあった。1件あたり平均1.3MBほどだが、平均に意味はない。1枚きりの領収書と195MBのスキャン束が同じ棚に並んでいるからだ。

書庫派がEvernoteから離れにくかった理由は一つしかない。放り込んだPDFの中の文字まで検索に掛かったからだ。ファイル名が日付のままでも、フォルダ分けをしなくても、語句を打てば出てくる。整理しない人間にとって、この一点が代えの利かない機能だった。検索という機能を握られている限り、データは手元にあっても持ち出せない。人質に取られているのは、PDFそのものよりも「探せる状態」のほうである。

Notion・Appleメモの壁：藩を替えても年貢は続く

NotionもAppleメモも、文章を書いて育てる道具としてはよくできている。ただ、1.7万件の紙のPDFを抱えて移ろうとすると、三つの壁に順番に当たる。

一つ目は検索だ。添付したPDFの内側、とくにテキスト層を持たない画像だけのPDFの中身は、検索の対象として当てにできない。書庫派が欲しいのはまさにそこである。二つ目は量だ。数百件なら通るインポートも、万単位・数十GBになると途中で止まる。どこまで入ったのかは、自分で突き合わせるしかない。

三つ目がいちばん根深い。仮に全部入ったとしても、それは新しい独自データベースへの入れ直しにすぎない。10年後にそのアプリの料金や方針が変われば、同じ引っ越しをもう一度やることになる。仕える藩を替えただけで、年貢を納める構造は何も変わっていない。

Google Drive直置きの壁：開かずの段ボール箱

では、どのアプリにも入れず、Google Driveにファイルのまま置いておけばよいのか。ロックインは避けられる。だが、今度は探せなくなる。実際に起きたのは次の三つだ。

• ファイル名が手掛かりにならない。スキャナが自動で付けた日付と時刻の名前か、バーコード由来とおぼしき数字列だけの名前が大半だった。
• テキスト層のないPDFが6,740件ある。2014年ごろのスキャンに多く、画像としては読めても、文字としては存在していない。
• 重すぎて開けないPDFがある。20MBを超えるものが206件・合計9.0GB、最大は195MB・96ページ。スマートフォンやクラウド側のAIから開くと時間切れになる。

Google Driveの検索にも文字認識の仕組みはある。ただ、どのファイルのどのページまでが索引に入っているのかを、利用者側から確かめる手段がない。掛からなかったときに打つ手もない。結果として書庫は、中身を誰も覚えていない段ボール箱の山になる。捨ててはいないが、二度と開かれない。デジタルの墓場だ。

移行前の書庫を実際に数えた結果を、区分ごとにまとめる。

区分	件数	状態
Evernote移行で生じた残渣フォルダ	78,222件	エクスポート作業の副産物。書類としての実体はない
ScanSnapのPDF（レシート・はがき等の非定形含む）	17,142件	日付名、数字列だけの名前、100MB超の束が混在
Brother（A3/A4オートフィーダー）のPDF	30件	数十ページを1冊にまとめた束。合計316MB
上記のうちテキスト層が空のPDF	6,740件	17,392ページ分が文字として検索できない
上記のうち20MB超の巨大PDF	206件	合計9.0GB。最大は195MB・96ページ

本物は18%だけ：78,222件の移行残渣という伏兵

表の1行目が、想定していなかった伏兵だ。Evernoteから書き出したデータをDriveに置いた際、エクスポート用のフォルダ配下に78,222件のファイルが残っていた。実体のあるPDFは17,172件。件数で見ると本物は全体の18%で、残り82%は検索結果を濁らせるだけのノイズである。

手作業で仕分ける量ではない。仕分けたところで、ファイル名の問題もテキスト層の問題も残る。ここで方針が決まった。別のノートアプリへ移るのはやめる。人間は整理をせず、ファイルにも触らない。その代わり、生のPDFを読んで索引を作る役目を機械に持たせ、探す役目をAIに持たせることで、Google Driveの上に自前のEvernote環境を構築する。

【シミュレーター付き】22.7GBの生PDFを「99MBのJSONLシャード」に凝縮する3層アーキテクチャ

自前で構築したこのEvernote環境には「eba_index」という名前が付いている。本来なら「evernote」や「ever」とすべきところだが、手元のAIエージェント環境でこの自前書庫の担当を「えばちゃん（エバーノートの略）」という愛称で呼んでいた結果、AIがそのままローマ字の「eba」に変換してスクリプト群を命名してしまった名残である。やっていることは単純だ。PDFを動かさずに中の文字だけを抜き出し、AIが読みやすい小さなテキストファイル群として別の場所に並べる。先に、検討した三つの道を同じ物差しで比べておく。

観点	Notion・Appleメモへ移す	Google Driveに直置き	生PDF＋外付け索引
PDFの置き場所	アプリの独自データベース	Drive上のファイル	Drive上のファイルのまま
画像だけのPDFの全文検索	対象や精度にばらつきがある	掛かるかどうかを確認できない	ローカルOCRで対象ページを補完
1.7万件の一括取り込み	件数制限や途中停止の壁がある	不要	不要。読むだけで動かさない
195MB級の束PDF	扱いにくい	開く前に時間切れになりやすい	単ページに事前分割して1枚だけ開く
継続費用	容量や機能に応じた課金	Driveの容量料金のみ	Driveの容量料金のみ
やめるときの持ち出し	再びエクスポートが必要	そのまま持ち出せる	PDFはそのまま。索引は捨てて作り直せる

三列目の要点は最後の行にある。索引は生PDFから何度でも作り直せる派生物だ。壊れても失うものがない。正本はあくまで生のPDFで、仕組みのほうが使い捨てである。

基本哲学：スキャナは土管、人間は何もしない

この設計では、スキャナに賢さを求めない。レシートやはがきなどの非定形サイズを通すScanSnapでも、A3・A4の定形書類をオートフィーダーで流すブラザーのドキュメントスキャナーでも、役目は紙をPDFにしてGoogle Driveの決まったフォルダへ落とすことだけだ。付属ソフトの振り分け機能も、クラウド連携の名刺管理も、ファイル名の自動命名も使わない。スキャナはただの土管である。

だからメーカーの違う2台を並行運用していても困らない。書庫にはScanSnap側の17,142件とBrother側の30件が同居している。索引から見れば、どちらも「フォルダに落ちてきたPDF」でしかない。将来さらにスキャナを買い足したり入れ替えたりしても、監視するフォルダを一つ足すだけで済む。

自分の書庫で試算する：容量・検索速度・節約額

仕組みの説明に入る前に、規模感を掴むための試算ツールを置く。初期値は今回の書庫の実測値（17,172件、22.7GB、テキスト層なしの割合39%）だ。保有件数と総容量、画像だけのPDFの割合、いま払っているノートアプリの年額を動かすと、索引の大きさ、検索時間の目安、初回の構築時間、5年・10年で浮く金額が変わる。

年額の初期値38,700円は、249.99ドルを1ドル155円で換算した額だ。この額なら5年で193,500円、10年で387,000円が手元に残る。A3対応のスキャナを1台買い足しても、5年でお釣りが来る。件数に応じて変わる速度や時間は実測値からの比例計算であり、目安にとどまる。

Layer 1：残渣を除外し、変わった分だけを拾う

最初の層は掃除だ。エクスポート残渣のフォルダ配下にある78,222件を対象から丸ごと外し、実体のあるPDF 17,172件だけを相手にする。削除はしない。索引を作るときに見ないだけだ。元のファイルには一切手を付けないという原則は、ここでも守る。

17,172件のうち、索引に入ったのは17,057件だった。残る115件は、破損していたりパスワードで暗号化されていたりして読めなかった。これらは飛ばした事実を記録に残し、全体の処理は止めない。1件の壊れたPDFのために1.7万件が巻き添えになる設計は避けた。

もう一つの仕事が差分の検知だ。処理を終えたPDFを台帳に控えておき、次回からは新しく増えた分だけを処理する。これが、後で触れる「2回目以降は約1.2秒」の土台になる。

Layer 2：Apple純正のPDFKitとVisionで17,392ページを0円OCR

二つ目の層が文字の救出だ。まずmacOS標準のPDFKitでPDFを開き、すでに入っているテキスト層を取り出す。ScanSnapの付属ソフトでOCRを掛けてあったPDFは、ここで終わる。

問題はテキスト層が空のページだ。これが6,740ファイル・17,392ページあった。全体の約39%である。これらはページを画像として描き出し、同じくmacOS標準のVisionフレームワークにあるVNRecognizeTextRequestへ渡して、日本語として読み取らせる。

このOCR処理はすべてMacの中で完結する。クラウドのOCR APIに17,392ページを1枚ずつ送って従量課金を払う必要はない。OCR段階の追加費用は0円だ。書庫全体を外部のOCRサービスへ一括送信せずに済む点でも、下ごしらえをローカルで閉じる意味は大きい。手元の計算資源で下ごしらえを済ませてから上位のAIに渡す考え方は、ローカルの27Bモデルで検索RAGを再現した回と同じである。

精度について正直に書く。OCRである以上、誤読は必ず混じる。印字のかすれた紙や手書きの文字では、なおさらだ。ここで完璧を目指さないのがこの設計の肝になる。索引の役目は「どのファイルの何ページ目か」を当てるところまでと割り切った。数字の正確さは、次の章で述べる別の手段で担保する。

Layer 3：99MBのシャード化と、巨大な束PDFの単ページ分割

三つ目の層で、取り出した文字をAIが読める形に並べ直す。出力は二種類のテキストファイルだ。一つは「manifest.jsonl」という台帳で、PDF 1件につき1行、場所やページ数などの素性を記録する。大きさは14.4MB。もう一つがページごとの本文を収めたシャード群である。1ファイルが4MBを超えないように区切った125個で、合計は約85MBになった。

合わせて約99MBだ。22.7GBの書庫に対して99.5%小さい。スマートフォンの写真数十枚分ほどの量に、索引化できた17,057件の紙の中身が文字として入っている。1ファイルを4MB以下に抑えたのは、AIエージェントが1個ずつ無理なく読み込める粒度にするためだ。巨大な単一ファイルにすると、今度は索引そのものが開けなくなる。

同じ層でもう一つ、重いPDFの下ごしらえをする。Brotherのオートフィーダーで作った束PDF 30冊（316MB）と、ScanSnap側の20MBを超えるPDF 206冊（9.0GB）を、あらかじめ1ページ1ファイルのPDFへ切り分けて別フォルダに並べておく。元の束はそのまま残し、単ページ版を横に置く形だ。

これで、195MB・96ページの塊から必要な1ページだけを取り出せるようになった。索引が「この束の41ページ目」と指せば、AIは1枚ぶん、およそ2MBのPDFを0.1秒で引き出せる。重くて誰も開けなかった箱に、ページ単位の取っ手が付いた。

実測0.36秒の横断検索と「スキャンした瞬間に検索可能」にするlaunchd WatchPaths運用

初回94分、2回目以降は約1.2秒

作って終わりではない。毎日の運用に耐えるかが問題だ。構築と検索にかかった時間を、実測のまま載せる。

項目	実測値
対象PDF	17,172件・22.7GB
索引化に成功	17,057件
読めずにスキップ	115件
OCRで文字を補完	6,740ファイル・17,392ページ
索引の大きさ	台帳14.4MB＋シャード125個約85MB＝約99MB
単ページへ事前分割	束PDF 30冊・316MBと巨大PDF 206冊・9.0GB
初回フルビルド	94分（5,651秒）
2回目以降の増分更新	約1.2秒
全件の横断検索	356〜401ミリ秒

初回の94分には、Macの手元に実体がなくクラウド側にだけあった10,959件を順に取り寄せる時間、17,392ページのOCR、巨大PDFの単ページ分割がすべて含まれる。一晩どころか、昼食と打ち合わせ一つの間に終わる長さだ。

一度作ってしまえば、次からは差分だけを見るので約1.2秒で済む。そして検索は、125個のシャードと17,057件の台帳を端から端まで総なめにして356〜401ミリ秒。やっていることは全文の総なめにすぎない。99MBのテキストは、いまの計算機にとっては頭から全部読んでも一瞬で終わる量である。

スキャナのボタンを押した瞬間に索引が走る

増分更新が1.2秒で終わるなら、人間が実行する必要はない。macOSには、指定したフォルダに変化があったときだけ処理を起動する「launchd」の「WatchPaths」という標準機能がある。これにScanSnap用とBrother用の二つの保存先フォルダを見張らせた。

紙をスキャナに置いてボタンを押す。PDFがGoogle Driveのフォルダに落ちる。それを合図に増分の索引更新が走り、終わったときにはもう検索できる。常駐プロセスも、定時の一括処理も要らない。

実運用のために足した工夫は二つだけだ。一つは30秒の間引きで、数十枚を続けてスキャンしたときに1枚ごとの起動が重ならないようにした。もう一つは排他ロックである。前の更新が走っている間に次の合図が来ても、二つが同時に台帳を書き換えることはない。地味だが、放置して回す仕組みにはこの二つが効く。

12年越しに0.4秒で出てきた予約票

索引ができて最初に試したのは、もう見つからないと諦めていた類いの書類だった。たとえば2014年にスキャンした、ある通院の予約票だ。当時のPDFにはテキスト層がなく、ファイル名は日付と時刻だけ。12年間、どんな検索にも一度も掛からなかった1枚である。

AIエージェントに覚えている語句をいくつか伝えると、0.4秒後にファイルとページ番号が返ってきた。数字列だけの名前で正体不明だったPDF群も同じだ。中身の文字が索引に入った時点で、名前が何であるかは問題ではなくなる。

ここで、整理という作業の位置づけが変わった。フォルダ分けも命名規則も、後で探すための前払いだった。中身で引けるなら前払いは要らない。15年分の「いつか整理しよう」は、整理しないまま片が付いた。

0.4秒で特定し、単ページPDFを「目」で裏取りする

OCRは誤読する。金額の3と8、日付の1と7を取り違えた索引をそのまま信じて、振込や予定の登録をするわけにはいかない。そこで検索は二段構えにした。

一段目は索引の検索で、0.4秒で「どのファイルの何ページ目か」を特定する。ここは多少の誤読があっても、前後の語句で十分に当たる。二段目は、金額・日付・各種の番号のように1桁の誤りも許されない箇所に限る。AIが単ページに分割済みのPDFそのものを画像として開き、原本を直接読んで確かめる。

速くて安い手段で候補を絞り、高くて確実な手段は最後の1枚にだけ使う。この順番は、Perplexity Computerを解剖して決定論的ハーネスを組んだ回で整理した原則をそのまま当てはめたものだ。AIに書庫全体を眺めさせるのではない。機械的に絞り込んだ1ページだけを見せる。

実際のやり取りは一言で済む。たとえば「検診の案内に書いてあった日時を予定に入れて」と頼む。書庫番のAIエージェント（呼び名は「えばちゃん」）が索引で案内状を見つけ、該当ページを開いて日時を読み取り、Googleカレンダーへの登録まで終わらせる。頼む側はファイル名もフォルダも知らないままだ。

おわりに：アプリにデータを人質に取らせるな、「生ファイル」の上にAIの目を置け

正本は生ファイル、賢さは外付け

15年かけて学んだことを一行にするとこうなる。データと「探せる状態」を同じ業者に預けてはいけない。値上げは症状であって、根ではない。検索という機能がアプリの内側にしか存在しなかったために、アプリを出ることがそのまま検索を失うことを意味した。構造の問題だ。

今回の構成では、正本はどこででも開ける生のPDFで、置き場所は容量を借りているだけのストレージである。賢さの部分、つまりOCRと索引とAIは、すべて外付けにした。OSが替わればOCRを差し替え、もっと良いAIが出ればそちらに読ませる。PDFは1バイトも動かない。索引は99MBの使い捨てで、94分あれば作り直せる。年貢を納める先が、構造上なくなった。

AIBizOpsシリーズの中での位置づけ

この書庫は、当ブログで続けているAIBizOpsシリーズの実装例の一つでもある。出発点はWeb 4.0を江戸の大店になぞらえた第1巻だ。AIを主人に据えるのではなく、主人の仕事を番頭や手代に割り振るように役目を配る。今回でいえば、スキャナは土管、Macは下読み、索引は台帳、AIは書庫番である。どれも替えが利き、どれも主人ではない。

どの役目にどのAIを就けるかは、4層×6職種のJDマトリクスを定義した第4巻と、主要LLM・エージェントの実務ベンチマーク比較一覧に実測の裏付けをまとめてある。書庫番に求められるのは、難問を解く力よりも、決まった手順を崩さずに回す規律だ。その見極めにこの二本が使える。

サブスクリプションの整理という文脈では、生成AI 13人と付き合った記録の延長線上にある話でもある。道具を増やしては見直し、残すものと手放すものを決めていく。その過程で、最後まで手放せないのは道具ではなくデータのほうだと分かった。

最初の一歩は、書庫を数えること

同じ場所で立ち止まっている人に勧めたいのは、移行先を選ぶ前に、自分の書庫を数えることだ。PDFが何件あって、合計で何GBで、そのうち何割にテキスト層がないのか。数えて初めて、問題がアプリ選びではなく、39%の文字にならない紙と、82%を占めるノイズにあったと分かった。

なお、本記事で組んだ「eba_index」のスクリプト本体は、ローカルのフォルダ構成やエージェント環境への依存が強いため一般公開はしていない。ただし、特別な外部ライブラリは一切使っていない。本記事に書いた3層の仕様（Layer 1の差分台帳、Layer 2のPDFKit＋VNRecognizeTextRequestによるOCR補完、Layer 3の4MBシャード分割と単ページ切り出し、launchdのWatchPaths設定）をそのままClaudeやCursor、Codexなどのコーディングエージェントに渡し、自分のMacの保存先フォルダに合わせて書かせれば、数百行のPythonとSwiftで同じ仕組みをそのまま再現できる。

数えた結果が数百件なら、どのアプリへ移しても困らない。万の単位なら、移さないという選択肢を検討する価値がある。アプリは替わる。スキャナも替わる。15年後も確実に残っているのは、フォルダに置かれた生のファイルだけだ。AIの目は、その上に置く。

あわせて読みたい

• 生成AI交際録（集合ハブ）
• AI交際記録1｜ChatGPT
• AI交際記録2｜Claude
• AI交際記録3｜Gemini
• AI交際記録4｜Perplexity
• AI交際記録5｜Copilot
• AI交際記録6｜Manus
• AI交際記録7｜Grok
• AI交際記録8｜Suno
• AI交際記録9｜Grok Bot
• AI交際記録10｜Antigravity
• AI交際記録11｜GenSpark
• AI交際記録12｜Cursor
• AI交際記録13｜Meta Muse
• AI大奥外伝1・立ち上げ篇（役職と席）
• AI大奥外伝2・炎上篇（任命と再配置）
• AI大奥外伝3・復興前夜篇（監視と采配）
• AI大奥外伝4・見習い篇（見習いと七つの門）
• AI大奥外伝5・着任篇（選抜と着任）
• AI大奥外伝6・第2回大運動会篇（実戦5種目と新・総合番付30点満点）
• AI大奥外伝7・総取締役の禅譲と秋の大人事異動篇（壁打ち・全体設計と現場統括の分離、6専門職体制の誕生）
• 自前でEvernote環境を構築した話｜ScanSnap×Brotherの1.7万件PDFをNotionに移さずAIで0.4秒検索にした全記録（生PDF正本×Apple純正OCR×99MB JSONLシャード）
• 主要LLM 実務＆地頭ベンチマーク最新リーダーボード【随時更新】（全10問・30点満点の単一カレントマスター順位表）
• LLMへのジョブディスクリプション（JD）割り当てとAIオーケストレーションの適材適所フレームワーク（2軸JDマトリクス・ベンチマーク v4）
• Perplexityの検索RAG環境をローカルで完全再現した話（オープンソース27B×最小限Web APIの3層ハイブリッドRAG監査基盤）
• Perplexity Computerを解剖して「改良版」を自作した話（Cloud-First決定論的ハーネス）
• 大店モデルとBizAIOps（オーケストレーション）

よくある質問（FAQ）