開発book-knowledge-base

書籍OCR取り込みをバッチ化して複数セッション並列で回す

書籍ナレッジベースへの取り込みを、1冊ずつ指示する運用から「キューを書いておけば勝手に消化される」運用に切り替えた日。午前中に手動で6冊取り込みながらパイプラインの精度を確かめ、午後には /import-batch コマンドを新設して不動産カテゴリ8冊のうち5冊を全自動で流し込んだ。

午前: 手動取り込みでパイプラインを温める

まず不動産登記の解説書（約490ページ）を /yomitoku で取り込んだ。OCRはGPUで約1.7秒/ページ、486ページで15〜20分。完了後に図49件をリネームし、453チャンクをDBに格納して、/restructure-book で目次ベースのセクション統合をかけたら80チャンクまでまとまった。

続けて財務分析系の経営書1冊（126→48チャンク）、不動産投資の税金本と不動産の税金入門書の2冊、さらに不動産投資の融資対策本（248→48）と節税本（123→74）と、計6冊を直列で流した。途中で取り込みスクリプトのシグネチャが変わっていて（db_path引数が不要になっていた）一度エラーで止まったが、修正して再実行で通った。

404で恥をかいたルート構成

取り込み完了後に「内容を確認したいからアプリで開いて」と頼んだら、ブラウザに404が返ってきた。原因はURLの間違いで、このアプリには /books/<bookId> という書籍トップのルートが存在せず、ページ番号付きの /books/<bookId>/<page> しかない。登記記録例の表がMarkdownテーブルとしてきちんと入っていることは、ページを開き直して確かめられた。

Turso DBの容量を確認する

「今どれくらい入ってるのか」が気になってTurso DBの容量を調べさせた。CLIが未インストールだったのでSQLで直接集計。

  • 全体: 約98MB（77冊・8,701チャンク）
  • 本文テキスト自体は13.5MBだけ
  • 容量の半分以上はFTS全文検索インデックスが占める

本文よりインデックスの方が重い、という入り方を初めて数字で見た。この調子なら容量はまだ気にしなくていい。

蔵書シェルフを起点に取り込み計画を立てる

/shelf（蔵書の棚ページ）を眺めていて、1冊ずつパスを指定して取り込む作業に飽きてきた。会計系・税金系・不動産系を中心に、レビュー4以上・レビュー件数5件以上でフィルターして、計画通りにバンバン入れて最初から全部リストラクチャー済みの状態にしておけばいい——という方針に切り替えた。

Chrome DevToolsでshelfのカテゴリ体系と評価分布を確認しつつ、DB側からも対象冊数を数えて、コア＋経営系245冊の取り込み計画に落とし込んだ。カテゴリごとに★順で並べ、/import-batch と言うだけで1セッション10〜15冊を全自動処理する体制になった。

複数セッション並列のための設計

ここで「複数セッションで同時に非同期で回すと、同じ本を重複して取り込むのでは」という問題に気づいた。対策として担当割りと着手マークの両方をコマンド定義に入れさせた。

  • キューは1枚のマークダウン: memo/2026-06-12/import-queue.md。各セッションが処理完了のたびにチェックボックスを [x] に更新するので、どのセッションから見ても残りが分かる
  • 担当カテゴリ制: /import-batch 不動産 のようにカテゴリを引数で渡し、セッションごとに担当を分けて重複を物理的に避ける
  • 着手マーク: 取りかかった本にはマークを付けてから処理する
  • GPUロックファイル: yomitoku OCRはGPU（VRAM 8GB）を1プロセスしか使えないので、OCRの同時実行を防ぐロックを入れる

並列化で一番の制約がモデルでもAPIでもなくローカルGPUのVRAMだった、というのがこの設計の面白いところ。

CodexもパイプラインにJoinできるようAGENTS.mdを整備

「これってOpenAIのCodexでもできるんでしたっけ？」と聞いたら、キューの仕組み（チェックボックス・着手マーク・GPUロックファイル）は単なるファイル編集とbashなので、Codex CLIでも同じプロトコルを守れるという答え。ツール非依存に設計してあったのが効いた。

そこでCodex用に AGENTS.md を作らせたら、実は既にAGENTS.mdが存在していて、しかも中身はCLAUDE.mdのコピーで .claude/ が .Codex/ に誤置換された壊れた状態だった。それを修正したうえでCodex固有のセクションを末尾に追記する形で整備した。

午後: /import-batch 不動産 を実走

午後に /import-batch 不動産（担当8冊）を実行した。流れはパイプライン化されていて、1冊のOCRがGPUで走っている間に次の本のメタデータ判定を進め、OCRが終わった本の取込〜restructureはsubagentに委譲して、メインはすぐ次のOCRを開始する。

OCR(No.n) 実行中
  ├─ メタデータ判定(No.n+1) を並行
  └─ 取込+restructure(No.n-1) を subagent に委譲

途中で処理が詰まった。コマンドの結果確認が進まなくなり、原因はおそらく同時に動かしていたGPT Codexがリソースを食っていたこと。Codex側を確認して「今うまくいってますか？」と声をかけたら復帰し、4冊目（448→115チャンク）が完了していた。

最後はOCR進行中の1冊（残り28ページ）の完了を待ってキリよく区切り、8冊中5冊完了のクリーンな停止状態で終了。進捗ログを memo/2026-06-12/import-batch-fudosan-progress.md に復帰プロンプト付きで保存してあったので、午後の別セッションでは「進捗メモを読んで続きを実行して」の一言で再開できた。

学び

  • 取り込みキューをマークダウン1枚にして「チェックボックス＋着手マーク＋担当割り」を入れるだけで、複数セッションの並列運用が成立する
  • 並列化のボトルネックはGPU（VRAM 8GB・OCR 1プロセス制約）。ロックファイルで直列化する箇所を明示するのが先
  • パイプラインをツール非依存（ファイル編集とbashだけ）に設計しておくと、Codexのような別エージェントも同じプロトコルで参加できる
  • AGENTS.mdのような設定ファイルは「既にあるが壊れている」ことがある。作る前に既存を確認させてよかった
  • 進捗ログに復帰プロンプトを埋め込んでおくと、セッションが切れても詰まっても一言で続きから走らせられる
  • FTS全文検索インデックスは本文テキストの数倍の容量を食う。容量見積もりはインデックス込みで考える

明日以降やること

  • 不動産カテゴリの残り3冊を /import-batch で消化する
  • 会計系・税金系カテゴリのバッチを別セッションで並走させ、担当割りプロトコルが実際に重複なく回るか確かめる
  • CodexセッションをAGENTS.md経由で1バッチ参加させて、GPUロックが守られるか検証する