開発book-knowledge-base

自分の本棚にAIで質問するインフラを1冊ずつ増やす

裁断してスキャンした実務書のPDFが、HDDに転がったまま積もり続けていた。 今日はそのうち1冊（199ページ）を、book-knowledge-base プロジェクトの /yomitoku スラッシュコマンドに食わせた。 処理が走っている数十分の間、別の作業（奥付抽出計画）を並列で進めて、戻ってきたら Turso DB に1冊分の全文が増えていた。

「OCRしました」で終わる話ではない。 自分の本棚に AI で質問できる状態を、1冊ずつ作っている。

yomitokuとは

yomitoku は日本語特化の AI OCR ツールで、手書き混じりや段組み・表の入った実務書でも、本文と図表を分離して Markdown を吐く。 今回使った /yomitoku コマンドは、その変換だけでなく以下までを一気通貫で回す。

  • PDF → ページ単位の Markdown 化
  • 図表を別画像として抽出
  • 抽出結果を Turso DB（libSQL/SQLite互換）に格納
  • amazon_metadata テーブルと書籍IDで自動紐付け

最後の紐付けが効くと、Amazon 側で持っているタイトル・著者・出版社のメタデータと、OCR した本文セクションが結合された状態で検索できる。

やったこと

PDFを探す（一度迷子になった）

最初に find でPDFを当てに行ったが、想定パスに無くて空振りした。 別ディレクトリを順に当たって、ようやく目当てのファイルを掘り当てた。

裁断本のPDFはディレクトリを分けて保管しているつもりでも、案外散らかっている。今後は格納先のパス規約を固めたい。

先頭10ページで書籍情報を把握 → 199ページと判明

PDFが見つかったら、まず先頭10ページを読んで何の本かを確認した。 タイトル・著者・章立てが頭に入った段階で、総ページ数を確認したら 199ページ。 yomitoku は分量に応じて処理時間が伸びるので、数十分かかる前提で動かす段取りに切り替えた。

バックグラウンドで yomitoku を起動 → 他作業と並列

/yomitoku をバックグラウンド実行にして、別のターミナルで奥付抽出の計画書を書いていた。 完了通知が来たら結果を確認する、というリズム。

199ページの本を完走させると、

  • 199ページ分の Markdown
  • 170枚の図 が別画像として出力された

図ファイルは既定の命名規則でリネームされて、Markdown 側からの相対パスで参照される構造になる。

DB格納で2回つまずいた

ここから先がやや手探りだった。

つまずき1: 関数シグネチャを取り違えた

DB 格納処理を呼ぼうとして、引数の渡し方を間違えた。1回エラーで止まったので、シグネチャを確認してから再実行した。

つまずき2: init_books_db がスキーマ衝突

最初に init_books_db を回そうとしたら、既存テーブルと衝突して止まった。 スキーマは既に作ってあるので、初期化は飛ばして insert_book から直接実行する流れに切り替えた。

init_books_db   ← スキップ（既存スキーマあり）
insert_book     ← 書籍メタデータを登録
前処理 + セクション統合   ← Markdown を章節単位にまとめ直して格納

この順で実行したら、DB 格納が通った。

検索テストとAmazonメタデータの紐付け

格納が終わったら、検索テストを1本叩いて動作を確認した。 本文中のキーワードでセクションが引けて、同時に amazon_metadata 側の書籍IDが解決された状態で返ってきた。

つまり「この本のこの章にこう書いてある」という単位で、Claude Code から問い合わせられる。

/yomitoku コマンドの中身

実行している処理を分解するとこうなる。

PDF
 ↓ yomitoku（日本語特化AI OCR）
ページごとのMarkdown + 図画像
 ↓ 章節単位への再構成
セクション化されたMarkdown
 ↓ Turso DB（libSQL）に insert
書籍コンテンツテーブル
 ↓ amazon_metadata と書籍IDで自動結合
全文検索 + メタデータ検索が可能な状態

人間がやったのは、PDFのパスを渡したことと、シグネチャミス・スキーマ衝突の2点をリカバリしたことだけ。 Claude Code がコマンドの中で順次実行している。

今日の発見

  • 199ページの実務書でも、バックグラウンドに回せばほぼ放置で完走する。1冊ずつ蔵書DBに積み上げる運用が現実的になった
  • 図表が170枚抽出された。本文だけでなく図解の位置も保持されるので、後で AI に図解付きで要約させる余地が残る
  • init_books_db のような「初回だけ実行」系コマンドは、毎回確認するクセを付けないとスキーマ衝突で止まる
  • WebFetch でも yomitoku でも、長時間処理をバックグラウンド化して別作業と並列で動かすのが効くと改めて確認した

税理士・会計士フォロワー視点での応用

裁断本の山がHDDに眠っている人ほど効く。

  • 自炊した実務書（税法解説書、会計実務書、判例集）を全文検索可能な状態に変換できる
  • 過去の参考書をDB化すれば、「○○の論点について書いてある書籍を横串で当てる」が日本語で頼める
  • SQLは書かなくていい。「○○について関連書籍から検索して内容を要約して」とClaude Codeに頼むだけで、裏でDBが叩かれる

「自分の本棚にAIで質問する」インフラは、1冊ずつしか増やせない。 今日はその1冊が増えた。

次にやること

  • 残っている裁断本PDFをディレクトリで一元化する
  • 奥付抽出の計画書を仕上げて、書籍メタデータの取得経路を整理する
  • 検索クエリのバリエーション（章横断・書籍横断）をいくつか試して使用感を掴む