裁断した専門書PDFを yomitoku で OCR にかけ、Turso DB まで投入するパイプラインを、朝と夜で計25冊くらい流した日。 朝は前日の積み残しを含めて6冊を一気通貫で処理。夜はその定型を流用して、未取り込みのPDF専門書を「レビュー数の多い順」で上から19冊ほど取り込んだ。

朝のセッション — 6冊バッチで定型ワークフローを確立

OCR バックグラウンド起動 → DB 投入 → restructure 4 並列

朝の最初のステップは、撮影済み画像の OCR を バッチ化してバックグラウンドに投げること。

Bash スクリプトで 4 冊分の yomitoku を順次実行する形にして、Task ツールでバックグラウンド起動。推定 24 分の見込みなので、その間は別作業に回せる。

[OCR バッチ] → [DB 投入] → [restructure サブエージェント 4 並列]
   24分前後       数秒/冊         並列で各 5〜10 分

OCR が完了したら DB 投入スクリプトを順次叩いて、4 冊で合計 983 chunks。 そこから章節を再構成する restructure をサブエージェント 4 並列で起動した。 ここが今日いちばん時間を稼げたポイントで、最も重い1冊（章節構造が複雑な書籍）は単独だと時間がかかるが、軽い 3 冊を並走させることで体感の待ち時間が消えた。

サブエージェントの「後出し result」に気づいた

restructure サブエージェントの結果ファイルが 2 件、メインに戻ってきていなかった。 当初は「失敗したのか？」と疑ったが、DB の chunks 数を見ると 195 → 94 に減っていて、実体としては正しく動いている。履歴ファイルだけ自分の手で簡易補完を入れたら、しばらくしてサブエージェントから後出しで詳細結果が届いた。 章別セクション数・巨大チャンクの切り詰め（214,850 字 → 1,026 字）・ページペアリング戦略まで含む充実版が、メイン側のレスポンスから数分遅れて返ってきた形。 簡易版を上書きさせる形で履歴ファイルを充実版に置き換えた。

サブエージェントの結果は同期的に返ってくるとは限らない。chunks 数など DB 側の実態で先に判断して、後出し result が来たら上書きする運用が落ち着く。

「やっぱ専門書がいいんですよ」 — 夜セッションのフィルタ判断

夜は別セッションで PDF 書籍の取り込みに集中。Dropbox 配下に 1,225 冊の番号付き書籍があって、DB 取り込み済みが 234 冊、未取り込みが 629 冊あることが分かった。

最初は「ベストセラー教養書」が上位に並ぶリストが出てきたが、自分が DB に入れたいのは実務で引きたい専門書。 「レビュー数が多い順で、専門書からやっていきたい」と方針を切り直してもらった。 税務・会計・法律・IT・データ系の実務書に絞ると 116 冊が残り、その中でレビュー数の多い順から上から順に流していくことにした。

yomitoku を独自スキル化してあるので、起動コストがほぼゼロ

yomitoku は /yomitoku という独自スキルにしてあって、

1. PDF パスを確認
2. 冒頭ページを読んで書籍情報を把握
3. yomitoku でバックグラウンド OCR
4. 完了したら図リネーム
5. DB 投入（amazon_metadata 自動紐付け）
6. 検索テスト

までを一連の流れとしてカプセル化してある。 夜セッションでは「次の冊のパスを渡す」だけで、このスキルが自動で全ステップを進めてくれる。 1冊あたり数百MBの大書も、人間がやることは「次これ」と決めるだけ。

並列起動の組み方 — 1冊OCR中に次冊のメタデータ準備

yomitoku は GPU を占有するので、OCR は同時に 1 本しか走らない。 だが「1冊のOCRが終わるまで完全に待つ」のはもったいないので、

• OCR 進行中: 次の冊のメタデータを Amazon から先取得
• OCR 完了: そのままDB投入を回しつつ、次の冊のOCRをすぐ起動

という二段重ねにした。1冊のDB投入（数十秒）の間に、次冊の OCR が走り始める形。 これで「OCR待ち時間中に人間が遊んでいる」状態をほぼ消せた。

19冊取り込みの実体

夜セッションで取り込めた専門書（書籍特定を避けて book_id ベースで件数のみ）:

合計 4,751 chunks 追加。最大の1冊で 517 chunks（38グループ統合）。 途中、ディレクトリ名に日本語が混じっていて yomitoku が文字化けで失敗するケースがあったので、英字パスにコピーして再実行した。リトライ前提でパイプラインを設計しておくと心が穏やかになる。

ペースコントロールは人間側の仕事

セッション中、何度か自分から介入してペースを調整した:

• 「これ今進行中ってことで合ってますよね」と進行確認
• 「次の10件を出してください」で先のロードマップを可視化
• 「いいきりのいいところでおしまい」で安全停止

特に最後の「キリのいいところで止める」は重要で、大書（723ページ分まで OCR 済み）が進行中だったが、中途半端な状態を残さないために OCR を明示的に停止して中間出力ディレクトリも削除させた。 パイプラインの途中で寝かせると、次セッションで「これって完了？未完了？」を判定するコストが発生する。終わらせるか、いったん全部消すか、どちらかに倒すのが正解。

学び

• OCR/restructure を並列バックグラウンドにすると、人間は別のことを並行できる。朝のセッションで restructure 4 並列を回している間、自分は撮影済み書籍のメタデータ確認や excluded フラグ整理を進められた
• 並列度を上げすぎないのもコツ。OCR は GPU 1本縛りなので同時起動は 1 本まで。restructure は API rate limit を意識して 4 並列に止めた（増やすほど後出し result の取り回しが煩雑になる）
• スキル化すると「次これ」だけで進む。/yomitoku を一度作っておけば、夜セッションのように 19 冊連続で流すときに、人間側のセリフが「次のパスはこれ」だけで済む
• 朝の6冊で得た定型が、夜の19冊で活きた。朝のセッションは「定型を確立する」コスト込みだったが、夜は同じ手順をなぞるだけなので、人間のペースで上から順に投げ続けるだけになった

明日以降のTODO

• 次回セッション開始時に「税務系で残った No469（723ページの大書、進行中で停止済み）」をクリーンスタートで再OCR
• 税務系のレビュー上位は一巡したので、次は会計・法律・IT 系の上位から
• ビジネス書として依頼が来ていた1冊（自己啓発系の有名本）を「専門書フィルタ」を外して追加