395ページの参考書をAI OCRでクラウドDBに取り込み、Notion自動アーカイブの計画書を固めた日

開発book-knowledge-base

午前は書籍ナレッジベースへの取り込みを1冊、午後はNotion自動アーカイブの計画書詰め。どちらも「待ち時間」と「レビューの往復」が主役の一日だった。

この書籍ナレッジベースは、裁断・スキャンした蔵書をOCRしてクラウドDBに貯め、あとから日本語で「○○について関連書籍から探して」と聞けるようにする仕組み。SQLを自分で書くのではなく、Claude Code にDBを叩かせて該当セクションを引かせる使い方をしている。今日はそこに1冊追加した。

395ページの参考書を /yomitoku に流す

裁断してスキャンした参考書のPDFを1冊、/yomitoku コマンドに流した。yomitoku（日本語特化のAI OCR）を軸にしたパイプラインで、流れはこうなっている。

  1. PDFをページ単位でMarkdownに変換（図表は画像として抽出）
  2. 抽出した図ファイルをリネーム
  3. テキストをTurso（libSQL）のクラウドDBに格納
  4. 検索テストで取り込み結果を検証

依頼文を雑に書いて、フォルダパスの後ろに「リストラクチャーまでお願いね。」と続けて投げたのだが、Claude Code はパスと指示文を切り分けて「取り込み後に /restructure-book まで実行する依頼」と解釈してくれた。こちらの意図どおりだったのでそのまま走らせた。

OCRは20分コース

今回の本は395ページ。これまで流してきた本は1冊あたり百数十ページ程度だったので、一回り大きい。処理はバックグラウンドに任せたが、なかなか終わらないので「まだ終わってないですか。長いですね」と途中経過を聞きに行った。

返ってきた数字は p374/395。ペースは約3.3秒/ページで一定、トータル20分強でOCRが完了した。ページ数に比例して素直に時間がかかるだけで、処理自体は最後まで淡々と進んでいた。

DB格納と、待ち時間のスクリプト改善

395ページすべての変換が終わり、図は3ファイル抽出された。リネームを済ませてDB格納へ。395ページ分をHTTPで投入するので、ここでも数分待つ。

待っている間に、スクリプトの相対パス依存を除去してもらった。どのディレクトリから実行してもcwdに引きずられないよう、参照を絶対パスに直す小改修。待ち時間にこういう積み残しを差し込めるのは、処理をバックグラウンドに逃がしているおかげだ。

格納が完了すると、395ページは102チャンクに収まった。検索テストと、既存書籍との file_no 紐付けが壊れていないかの保護確認まで通して、取り込みフェーズは完了。

/restructure-book でページ→セクションに統合

続けて /restructure-book を実行。OCR直後のチャンクはページ単位でぶつ切りなので、目次に基づいてセクション単位に統合し直す工程だ。

ページ単位のままだと、検索でヒットしても文脈が途中で切れてしまい、引用にも要約にも使いにくい。目次ベースのセクション単位に組み直しておくと、あとから「この論点のセクションを丸ごと読ませる」使い方ができる。取り込みの本体はOCRよりむしろこちらだと思っている。

こちらも待ち時間との付き合いだった。FTS（全文検索インデックス）のリビルドはDB全体を作り直すので数分かかるうえ、Pythonのstdoutバッファリングのせいで途中経過が画面に一切出ない。止まっているのか進んでいるのか画面からは見分けられないまま、完了通知を待つことになった。

パイプライン完了時点の結果はこうなった。

  • OCR: 395ページすべてMarkdown化（約3.3秒/ページ・20分強）
  • 図表: 3ファイルを画像として抽出・リネーム
  • DB格納: 395ページ → 102チャンク
  • 再構造化: 目次ベースのセクション単位に統合、FTSリビルドまで完了

ビューアを立ち上げて表示チェック

1時間後、「まだ終わってないですか」と同じ質問をもう一度した。今度は答えが違って、実はとっくに終わっていた。動いているプロセスはなく、DBを直接確認した裏付けつきで「再構造化は完了済み」との回答。

それなら実物を見たい、と書籍ビューアのアプリを立ち上げてもらった。

  • ポート3100が空いているのを確認してからdevサーバーを起動
  • APIとページの応答を確認
  • ブラウザで実際の描画をチェック

ここでスクリーンショットが2回タイムアウトする小トラブルがあったが、コンソールとテキスト取得の別経路に切り替えて確認を続行させた。今日取り込んだ本をブラウザで開き、統合後の章チャンク（複数ページを1つにまとめたもの）についてコンソールエラーが無いことと本文テキストが揃っていることまでは確認できた。見切れや重なりといった見た目の最終確認は、スクリーンショットが復旧してからの持ち越しにした。

おまけ: /advisor に日本語で質問してエラーを返される

途中、/advisor というコマンドが目に入ったので「これって何に使うんですか？」と打ったら、Model not found エラーが返ってきた。引数がモデル名専用のコマンドで、質問文がそのままモデル名として解釈されていた。

ドキュメントを確認させたところ、メインのモデルとは別に強力なモデルをペアで待機させ、計画立案・エラー対応・完了判定といった重要な判断のタイミングだけ相談させる機能だと分かった。書籍パイプラインのような長時間ジョブと相性がよさそうなので、頭の片隅に置いておく。

午後: Notion自動アーカイブの計画書を詰める

別セッションで、Notion APIファーストの自動アーカイブ計画書（memo/2026-07-15/notion-api-first-automated-archive-plan.md）をレビューさせた。Notion上のページをAPI経由で自動的にアーカイブしていく仕組みの計画書で、UI操作ではなくAPIを正面に据える設計にしてある。

まず自前レビュー。API仕様の記述をNotionの公式ドキュメント4本と突き合わせて裏取りした結果、「設計は堅いが、修正した方がよい点が数件」という判定が返ってきた。指摘は重要度順に並べてもらい、直す価値のあるものを選んで修正を指示した。頭の中の記憶ではなく公式ドキュメントとの突き合わせで裏を取らせたのは、計画書の段階で仕様の思い込みを潰しておきたかったからだ。

修正にあたっては、追加するコメント取得の仕様（解決済みコメントが取れるか）だけ先に裏取りさせてから計画書に反映。あやふやな仕様のまま計画書に書いてしまうと、明日の実装で手戻りになるからだ。

仕上げにCodex（別モデル）の再レビューにかけたら、「指摘4点は正しく反映、残る致命的問題なし」の合格判定が出た。実装は明日に持ち越し。計画書まで詰めておいたので、翌朝は判断を挟まず手を動かすところから始められる。

学び

  • 大きめの本のOCRは20分コース。バックグラウンド実行と完了通知に任せて、待ち時間に別作業（スクリプトの絶対パス化など）を差し込むのが正解だった
  • Pythonのバッチ処理はstdoutバッファリングで「無言の数分」が生まれる。進んでいるかどうかは画面出力ではなく、プロセスの生死とDB側の変化で判断する
  • 同じ「まだ終わってないですか」でも、1回目は本当に処理中、2回目は完了済みだった。長時間ジョブの終了判定は、体感時間ではなくDBの実物を確認させるのが確実
  • スクリーンショットが取れないとき、コンソール・テキスト取得の別経路で確認できるのはエラー有無とデータ到達まで。見切れ・重なりの最終判定はスクショ復旧後に改めて行う
  • 仕様の裏取りは修正の前にやる。あやふやな箇所を残したまま計画書を直すと、実装当日に手戻りが来る
  • 計画書は「自前レビューで修正→別モデルの再レビュー」の二段構えにすると、翌日の実装に迷いなく入れる

明日やること

  • Notion自動アーカイブの実装に着手する（計画書はレビュー合格済み）

蔵書DBには1冊増え、明日の実装には合格済みの計画書が積んである。今日は仕込みの日として上出来だった。