オチツカレサマ〜 12倍に膨れたOCR結果と、容量設計の罠

#OCR #NDLOCR #Garage #S3 #rclone #パイプライン #失敗ログ #構築記 #ainsoph-pipelines

オチツカレサマ〜 12倍に膨れたOCR結果と、容量設計の罠

はじめに

昨日（4/27）の夜、明治期日本語学の文献4冊を ainsoph-pipelines で一気にOCRしようとした。Phase 1 の実装が一通り終わって、最初の「ちゃんとした研究素材」を流し込む夜だった。

結論から言うと、1冊目は無事に終わり、2冊目の処理中にネットが切れて、4冊中3冊が破綻した。

そしてその過程で、OCR結果が元PDFの12倍に膨れ上がっているという、設計の根本に関わる事実に気づいた。

50GBのストレージ割当に対して、現状ペースで83冊で満杯になる計算だった。古典・仏教史・夢分析プロジェクトの長期蓄積を考えるとこれは破綻している。

「容量が足りない」と気づくのは、たいてい、ストレージが「もう足りない」と言ってからだ。今回は手前で気づけた。それだけが救い。

何が起きたか

22時前、4冊のPDFを順番にアップロード → 順次OCRしようとした。

日本語原学_104-203（100p, 48.2MB）
日本語原学_204-303（100p, 45.4MB）
日本語原学_304-329（30p弱）
日本語言学_4-103（100p）

合計で約200MB。

ainsoph-ocr run-all を叩く。1冊目は8.4分で完走。100ページの明治期活字、五十音図に基づく約音法・略音法・転音法の体系的解説が、Vault の Inbox/Sources/ に流れ込んだ。

2冊目に入る。OCR本体は完走した（ログに「OCR実行中 ... 100ページ」が出てから「Garageに結果アップロード中」に進んでいる）。

そして、

2026/04/27 19:41:19 ERROR : viz_page_015.jpg: Failed to copy:
... write tcp 192.0.0.2:55962->210.131.212.67:443: write: result too large

というエラーがログに刻まれた。

そこから先、4桁続くエラーの嵐。

2026/04/27 20:12:02 ERROR : ... dial tcp: lookup garage.ainsoph.xyz: no such host
2026/04/27 20:12:02 ERROR : ... dial tcp: lookup garage.ainsoph.xyz: no such host
2026/04/27 20:12:02 ERROR : ... dial tcp: lookup garage.ainsoph.xyz: no such host
（以降400回くらい同じエラー）

DNSが引けなくなっている。ネットが切れた。

3冊目以降は「PDFを取りに行く」段階で失敗。OCRすら走らない。

ステータスが嘘をつく

朝になってネットが戻った。ainsoph-ocr status で状態を確認する。

✓ ndlocr/日本語原学_104-203_digidepo_1836174_0001.pdf
✓ ndlocr/日本語原学_204-303_digidepo_1836174_0001.pdf
· ndlocr/日本語原学_304-329_digidepo_1836174_0001.pdf
· ndlocr/日本語言学_4-103_digidepo_1836174_0001.pdf

204-303 に ✓ が付いている。

しかしVaultを見ると、Markdownは104-203の分しかない。Garage上の結果フォルダにも、ページ画像とテキストが中途半端に残っているだけ。

つまり status の判定ロジックは、「Garageに ocr-results/<engine>/<name>/ フォルダがあれば完了」と見ている。部分的にアップロードされた残骸でも完了扱いになる。

中途半端のまま「終わりました」と報告するシステム。今朝の最初の発見はこれだった。

これは Phase 2 で直す。判定基準は text.txt（全ページ統合ファイル）の存在 + Vault側の .md 存在、にすべきだ。今夜は対症療法で進める。

真犯人を見にいく

ネット切れも問題だが、もっと根本的な疑問が残っていた。

なぜ200MBのアップロードでネットが詰まったのか？

Mac側の作業ディレクトリ（/tmp/ainsoph-ocr-work/）が膨らんでいた感覚があった。元PDFよりずっと重くなる予感がしていたので、Garage上の完了済み104-203を実測することにした。

$ rclone size garage:pdf-library/ocr-results/ndlocr/日本語原学_104-203_digidepo_1836174_0001/
Total objects: 401
Total size: 594.068 MiB (622925828 Byte)

594MB。元PDFは48MB。約12倍に膨れている。

内訳を見にいく。

$ rclone ls garage:pdf-library/ocr-results/ndlocr/日本語原学_104-203_digidepo_1836174_0001/ | grep viz_page | awk '{sum+=$1} END {print sum/1024/1024 " MB"}'
590.577 MB

種別	サイズ	比率
viz_page_*.jpg	590.6 MB	99.4%
page_*.	3.4 MB	0.6%

OCR検出結果を元画像に重ねた可視化画像が、容量の99.4%を占めている。

これがGarageに上がっていた。1冊あたり600MB近く。4冊一気に流すと2.4GB。ネット切れに弱いのは当然だった。

50GB割当に対しての持続性をざっくり計算する。

現状のまま：1冊600MB → 約83冊で満杯
viz画像を抜く：1冊3.4MB → 約14,700冊で満杯

177倍の差がある。

viz画像って何のためにあるの？

落ち着いて思い出す。

viz_page_NNN.jpg は、NDLOCR-Liteが出力する「OCR検出結果を元画像に重ねた可視化画像」。人間が「ここをこう認識したな」と目視で確認する用途。

機械的な後段処理（Smart Connections、Dify、Claudeとの対話、Digital Garden公開）には1ミリも必要ない。OCR本体のテキスト・JSON・XMLだけあれば後段は全部回る。

つまりGarageに上げていたのは、ほぼゴミだった。

思想と容量設計

ここで一度立ち止まって考える。

ainsoph-pipelines の設計思想は、五蘊（色・受・想・行・識）の意図的な分離にある。AIが「セルフという統合の幻想」を増幅させないように、認知の素材だけを整え、統合は人間に委ねる。

Pipeline は「色」「受」「想」までを担い、「行」「識」は人間に委ねる

この思想からすると、viz画像は何にあたるのか？

OCRエンジンが「自分はこう見ましたよ」と差し出す自己点検資料だ。「想（saññā）」の段階で生まれる、機械側の自己意識のようなもの。

人間がそれを目視確認するのはローカルで一度きりで十分。長期保管に値する素材ではない。

設計思想に照らしても、保存しないのが正しいという結論になる。

対策

3点セットで進める。

A. 既に上がっているviz画像を全削除

rclone delete --include "viz_page_*.jpg" garage:pdf-library/ocr-results/

これで即座に容量が回復する。

B. これから生成しない／アップロードしない

ocr-pipeline/ainsoph_ocr/pipeline.py と garage.py を修正。

生成自体を抑止できるなら、それが望ましい
NDLOCR-Lite側で抑止できないなら、生成→ローカル削除→Garageには最初から上げない

C. ローカル作業ディレクトリも掃除

/tmp/ainsoph-ocr-work/<title>/ は、正常完了したらディレクトリごと削除。失敗時は残してデバッグに使う。

これは要件として docs/specs/2026-04-27-viz画像抑止.md に固めた。Claude Code に投げる前に仕様化しておく、というワークフローを今回から徹底する。

副次効果：ネット切れに強くなる

viz画像を抜くと、Garageへのアップロード量は 600MB → 3MB。

数秒で終わる。Wi-Fiが少々ぐらついても無関係。昨夜のような事故は構造的に起こらなくなる。

ストレージ容量の話だと思っていたものが、ネットワーク耐性の話でもあった。問題は、たいてい、複数の顔を持っている。

朝になって気づいたもう一つの罠

夜中のうちに「CLAUDE.md を整備しよう」とClaudeに相談した。

「ない前提」で立派なテンプレを作ってもらって、Claude Code に貼ろうとしたら、既存の CLAUDE.md と巨大な差分が出た。

既存ファイルは、過去のClaude Codeセッションで丁寧に積み上げられていた。

「推測を断定的に語らない」最優先ルール
要件追加のフロー（背景・現状・対応方針・受け入れ条件・影響範囲）
設定駆動を尊重（エンジン追加はTOMLだけで完結）
失敗しても次へ進む（バッチ処理の鉄則）
Rule of Three（早すぎる共通化禁止）
Pipeline と五蘊の対応表

これを抽象的なテンプレで全置換しかけた。判断力が落ちている夜に、長年積み上げた設定ファイル系を触るのは危険。差分が大きい時点で何かがおかしい、と立ち止まれたのが救いだった。

教訓：

Claudeに「○○ファイルを作って／更新して」と頼む前に、必ず既存を読ませる。

これは ainsoph-pipelines の CLAUDE.md にも追記した。