開発book-knowledge-base

裁断して山積みになっていた実務書を、yomitoku で OCR して Turso の DB に流し込む作業がようやくバッチ運用に乗った。1日で3バッチ分、合計30冊以上を取り込み、DB は朝の173冊から夕方には225冊・29,619チャンクまで伸びた。手元の本棚に「日本語で質問するとAIが本をまたいで該当箇所を引いてくる」検索面ができはじめている。

キューと現実のズレを最初に潰す

朝イチでまず気づいたのは、進捗を書き溜めていた memo/2026-06-12/import-queue.md が現実から1〜2日ぶん遅れていることだった。スキップ扱いになっていた法務分野の2冊はすでに変換済みだったし、M&A分野で「あと1冊」と書いていたものも、実際は別の本のOCRが裏で完了して取り込み待ちで止まっているだけ、というズレが何箇所もあった。

進捗マークダウンを手で更新するのは、こういう並行バッチ作業との相性が悪い。1セッションで5〜10冊が並列でOCR・DB取り込み・キュー更新を走るので、人間がメモを書き換える速度がワークフローに追いつかない。

そこで朝の最初の作業を「キューの実態調査」に当てた。Claude Code に DB の book_id 一覧を引かせて、キューの記述と突き合わせて、ズレを全部洗い出してもらう。やったことはシンプルで、

  • DB側の登録冊数・各書籍のチャンク数を Turso から取得
  • キュー側のチェックボックス（[ ] / [>] / [x]）と突合
  • 並走中の別セッションが OCR を走らせていた分は触らずに残す

経営戦略5冊の項目が「着手中」のまま実態は止まっていたり、税務5冊が24時間前から [>] で塩漬けになっていたり、キューに無い4冊が法務カテゴリで取り込み済みだったり。30分かけてキューを現実に合わせ直すと、その日に何をやるべきかが一気にクリアになった。

進捗マークダウンを手書きで保つのはもう諦めて、Claude Code に毎朝キューと DB の差分を取らせて整える運用に切り替えるべきだ、と決めた。

/import-batch コマンドで分野ごとに10〜15冊を流す

午前と午後で計3バッチを走らせた。すべて /import-batch <分野名> の形で起動して、Claude Code 側でカテゴリのキューを読んで、★4.4以上の未着手書籍から10〜15冊を選んで全自動で進めてもらう。

1バッチでやってもらう内容はこう。

  • 候補10冊を [>] で着手宣言してキューに書き戻す
  • 各PDFからメタデータ（書名・著者・ページ数）を並列で取得
  • yomitoku の OCR バッチスクリプトを PowerShell で生成して直列で走らせる
  • OCR が1冊完了するたびに、Monitor で完了通知を拾って、DB取り込みスクリプトを並行起動
  • 全冊DB登録完了後、キューを [x] に更新してコミット

ファイナンス分野12冊は朝の06:20開始で1時間45分、会計分野10冊は10:08開始で約53分、税務分野10冊は11:12開始で約48分。当初は「OCR 4〜5時間+DB登録で全体6〜8時間」と見積もっていたファイナンスバッチが1時間45分で終わった瞬間、この運用は回ると確信した。

ページ数の重いやつ（646pや752p）が含まれていてもバッチ全体は1時間少々で終わる。yomitoku が1ページ1秒前後で進むのと、OCR と DB 取り込みが並行で走るのが効いている。

OCR と DB 取り込みを並行させる勘所

地味だが効いたのが「OCRバッチを直列で1冊ずつ走らせる一方、完了した本から順に DB 取り込みを並列で被せる」という流し方。GPU は yomitoku で1本専有しているので OCR は直列でしか走らせられないが、DB 取り込み（Python スクリプトでチャンク分割→Turso INSERT）は CPU 仕事なので OCR と並行できる。

Monitor で yomitoku の終了イベントを拾い、終わったらすぐ次の OCR を起動しつつ、終わった本の取り込みを別プロセスで進める。これで「OCR 4時間+DB登録1時間=5時間」の直列見積もりが「OCR 1時間+並行DB登録」に圧縮される。

途中、PowerShell スクリプトの文字コードで何度かハマった。

  • 書名にカッコや日本語が入っていて、PowerShell から yomitoku に渡すコマンドラインが壊れる
  • バッチスクリプトを UTF-8 で保存すると NativeCommandError で落ちる → BOM付き UTF-8 で保存で解決
  • yomitoku の進捗ログが UTF-16 で書かれているため Monitor のパターンマッチが効かない → ログ読み取り側を UTF-16 対応に修正

書名のかっこは PowerShell 側で '' エスケープして安全化した。一度ハマると同じパターンで翌バッチでも踏むので、最初のバッチの後で「OCRバッチ生成テンプレ」を AGENTS.md に書き出してもらって、次回からは Claude Code がそれを参照して生成するようにした。

SQLは書かない。Claude Codeに日本語で投げる

DB は Turso に置いている。スキーマは「book（書籍メタ）」と「chunk（章節単位の本文）」の2テーブル中心で、書籍1冊が100〜300チャンクに分割されて入る。本日のバッチ後で 225冊 / 29,619チャンクまで増えた。

ただし自分は SQL を書かない。書けないし、書く気もない。

「会計の入門書たちで『減損』はどう説明されているか横断的にまとめて」と Claude Code に日本語で投げると、Claude Code 側で Turso の chunk テーブルに全文検索クエリを投げて、ヒットした該当チャンクを引き、書籍をまたいで要約まで返してくれる。自分は本棚に向かって日本語で質問するだけで、本をまたいだ論点整理が返ってくる。

これは紙の本棚や PDF ビューアでは絶対に追いつけない速度で、特に分野横断の論点（「税務と会計でこの取引の扱いが違うのはなぜか」みたいな問い）を立てるときに効く。1冊の本を全部めくる代わりに、関連書20冊の該当章だけが瞬時に集まる。

ただし注意点もあって、chunk テーブルの粒度（章節レベルか、段落レベルか）で検索結果の質が大きく変わる。今は yomitoku の出力 markdown を /restructure-book で章節ごとに再構造化してからチャンクに分割しているが、ここの境界判定はまだ調整余地がある。

今日のバッチ結果と次の手番

  • 朝の状態: DB 173冊 / 18,411チャンク
  • ファイナンス12冊バッチ後: DB 185冊 / 21,615チャンク
  • 会計10冊バッチ後: DB 195冊 / 23,427チャンク
  • 税務（第1弾）10冊バッチ後: DB 205冊 / 25,351チャンク
  • 税務（第2弾）10冊バッチ後: DB 215冊 / 27,957チャンク
  • 経営・経営戦略10冊バッチ後: DB 225冊 / 29,619チャンク

1日で52冊・11,208チャンク増えた。コミット5本に分割して履歴も読みやすくしてもらった。

次は財務分野の残り、それから法務・契約の宅建教科書群を片付ける順。今日のバッチが想定の半分以下で終わるペースなので、明日以降も /import-batch を毎セッション1〜2本ぶん回せば、週内に主要分野は埋まる見込み。

明日以降にやること

  • 毎朝のキューと DB の差分チェックを /import-batch の前に必ず1ステップ挟む
  • OCRバッチ生成 PowerShell の文字コード扱い（BOM付きUTF-8、UTF-16ログ読み取り）を AGENTS.md に残す
  • チャンク分割の境界（章節レベル vs 段落レベル）を、検索精度を見ながら調整する
  • 並走セッションが残した [>] 着手宣言を24時間以上たったら自動で再評価対象に出す仕組みを入れる