1. 絶望の始まり：Universal Searchの限界
Synologyユーザーなら誰もが頼る「Universal Search」。私も最初は信じていました。
しかし、30万枚という物量はあまりに非情。
- 検索にヒットしない: 「Buy」と検索しても、画像の中の文字を拾ってくれない。
- インデックスが終わらない: NAS（DS718+）のCPUが常に数日間フル回転しているのに、一向に検索結果が充実しない。
- 「undefined」の恐怖: あまりのデータ量に、画面上には「undefined」の文字が踊り、システムが静かにフリーズ。 「標準機能じゃ、この山は登りきれない。」これが全ての始まりでした。
2. 救世主「Paperless-ngx」との出会い、そしてDockerの沼
そこで白羽の矢を立てたのが、高度なOCR（文字認識）と自動タグ付けを備えた「Paperless-ngx」。
NASの「Container Manager」を使って、Docker上に構築することに。
ここからが本当の「四苦八苦」でした。
- YAMLの呪文: インターネットの海から拾ってきた適当な「docker-compose.yaml」を貼り付けるも、NASのフォルダ構造（volume設定）と噛み合わずエラー連発。
- 権限の壁: フォルダは見えているのに、Paperlessがファイルを吸い込んでくれない。
:ro（読み取り専用）の意味を知り、NASのパーミッション設定と格闘する日々。 - メモリの限界: DS718+の限られたメモリで、OCRエンジン「Tesseract」を回す無謀。コンテナが「予期せず停止しました」と落ちるたびに、心も折れそうに。
- 私の限界: Dockerのコンテナがどっかー行った…とか言ってました。でも諦めませんでした。
3. 「俺の勝ち（oreno-kati-1）」：ログとの対話
深夜の作業。ログを流し見ていると、赤い文字（ERROR）の中に一つの希望が見えました。 [paperless.matching] Tag FX検証 matched... because it contains this word: Buy
テスト用に作ったファイル名 oreno-kati-1.PNG。
これが自動で認識され、画面上に「FX検証」というタグを纏って現れた瞬間、深夜の部屋で小さくガッツポーズ。
「いける。これで30万枚を支配できる。」
テストで少しアップした画像から次々とタグでヒットしていきます。
後はこれを繰り返せば。取り敢えず一安心です。
4. 戦略的運用：速さと精度のトレードオフ
うっかり一気に30万枚を放り込んでしまった時はシステムが超不安定になってしまいましたが、
最初は100枚、次は1000枚、その次は2000枚…という感じで少しずつフォルダ追加するようにしました。
現在は、30万枚を「安全に」そして「確実に」処理するための最適解にたどり着いています。
- インポート時は『skip』モード: まずは1枚30秒ペースで、どんどんNASの中へ放り込む。吸い込まれたファイルがフォルダから消えていく快感。
- 夜中の『Redo OCR』: 深夜、人間が寝ている間にNASが本気を出す「二部制運用」。
- エラーを恐れない: 「lots of diacritics（ノイズ多すぎ！）」という警告も、今では「頑張ってるな」と愛着すら湧くように。
スクショ時点で884アイテム。1000枚近くあったのに、少しずつ消えていってる！嬉しい！
（元フォルダからコピーペーストしているだけなので、処理が終わったら順次消えていってくれた方が分かりやすくていいねと思いました）
09:03～16:50で残り0枚になりました！やった！！
早速Redo OCR（再処理）をかけているところです。朝までには終わってるかな～
5. あとがき：Googleからの宿題
意気揚々とAdsenseの再審査に挑むも、返ってきたのは「3月4日までお預け」の通知。
Googleに「もっと詳しく書け」と言われた気がしました。
いいでしょう。あと2週間、この30万枚が完全にデータベース化され、爆速で検索可能になるまでの「完成形」を、この記事に追記し続けてやります。
6. 解説追記
1. そもそも Docker（Container Manager）って何？
【解説のヒント】 NASの中に、独立した『小さなパソコン（コンテナ）』を仮想で作る技術です。Paperlessというアプリを直接NASにインストールすると、NASの設定を汚したり壊したりするリスクがありますが、Dockerなら専用の『箱』の中で動かすので、失敗しても箱ごと消せば元通り。初心者こそ、実はDockerが一番安全なんです。
2. 呪文のような「YAML（ヤムル）」の正体
【解説のヒント】 Container Managerの設定で出てくる『docker-compose.yaml』。これはアプリへの『指示書』です。『このフォルダを使いなさい』『メモリはこれくらい使いなさい』という命令を箇条書きにしているだけ。今回は、AIに相談しながらこの指示書を1行ずつ修正していきました。
3. 「マウント」と「:ro」の落とし穴
【解説のヒント】 Dockerを使う上で一番の壁が『マウント』。これはNASのフォルダとDockerの中を『トンネル』でつなぐ作業です。 私がハマった
:roは『Read Only（読み取り専用）』の略。Paperlessが『読み取れるけど、元の場所からは消せないよ！』という状態でした。全自動で整理したいなら、このトンネルの通行許可を正しく設定してあげることが不可欠です。
4. 🥗 「OCR処理」を料理に例えると？
OCR（文字認識）は、NASにとって「写真という食材から、特定の調味料（文字データ）だけを抽出して、整理棚（データベース）に並べる」という、ものすごく手間のかかる調理作業です。
1. skip モードは「下ごしらえ済み料理」
「すでにカットされた野菜（文字情報付きのPDFなど）はそのまま使い、まるごとの野菜（文字データがない画像）だけを切るモード。効率重視で、コンロの火（CPU）をあまり使いません。」
2. clean モードは「超こだわりシェフ」
「どんな食材も、一度洗って皮を剥き、一番いい状態にしてから調理し直すモード。画像にノイズ（ゴミ）があっても綺麗にしてから読み取るので、出来栄え（精度）は最高ですが、コンロの火を最大で使い続けるため、厨房（NAS全体）がめちゃくちゃ熱くなります。」
3. コンテナの停止は「ブレーカー落ち」
「30万枚という大量の注文（画像）を、一気に『clean（こだわり調理）』でさばこうとすると、コンロ（CPU）と冷蔵庫（メモリ）をフル回転させすぎて、厨房のブレーカーがバチン！と落ちてしまう。 これが、コンテナの『予期せぬ停止』の正体です。」
4. 「夜中にRedo OCR」は「仕込み作業」
「お客さんが多い昼間（NASを普通に使う時間）は、とりあえず食材を冷蔵庫（consumeフォルダ）に入れるだけにしておき、お店が閉まった深夜に、シェフが一人でコツコツと『こだわり調理（OCR）』を進める。これならブレーカーを落とさずに、翌朝には完璧な料理（検索可能なデータ）が並んでいる、というわけです。」
🌟 ちーなっつの体験談
正直、最初はログを見ても『宇宙語』にしか見えませんでした。
でも、AIと対話しながら『このエラーは、NASが疲れている証拠だよ』『この設定を変えれば、もっとスムーズに動くよ』と一つずつ紐解いていくうちに、気づけば30万枚という巨大な山を登るための装備が整っていました。赤い字で『File not found.』という不穏なエラー。
原因は、Paperlessの仕事の早さと、NASのファイル消去がデッドヒートを繰り広げた結果の『空振り』だった。
システムが賢すぎて、自分の影を追いかけて転んでいるようなもの。
ログの文字面に一喜一憂せず、実際のライブラリが増えているかを確認する。
これが、ログと仲良くなるための第一歩。あと、前回繋いでたマウントは再度SSHに入って「umount /volume1/photo/screenshots」で解除しておきました。
これで動作も少しは軽くなるかな。
🚀 「これから挑戦する方へ」
- 一気にやろうとしない: 30万枚は1日では終わりません。
- ログを怖がらない: 赤い字のエラーは、システムからの「助けて」の合図です。
- AIを相棒にする: 専門用語は全部AIに投げて、「これ、小学生にもわかるように説明して」と頼むのが近道です。
重要事項
