book-knowledge-base のKindle取込パイプラインに小説・描き方シリーズの除外ロジックを足し、午前4冊・午後4冊で計8冊を1日で取り込んだ。最初は直列で待ち時間を寝かせていたが、スラッシュコマンドを読み返して並列化したところ撮影とOCRが噛み合った。途中で方向誤判定と Chrome の Tabs cannot be edited right now を踏んだので、リカバリも含めて残す。

取り込み対象から外す本にタグを付けた

朝のセッションは、進捗ファイル memo/2026-06-19/kindle-import-progress.md の冒頭に「次に取り込む候補トップ10」を表示させたかったところから始まった。ただ候補リストに小説や画集が混ざっていたので、まずは取り込まないものを切り捨てた。

kindle_library_tagger.py に novel タグの判定ロジックを追加して dry-run を走らせた。43件ヒットしたが、鈴木みそ（Kindle出版ノウハウ）と前田裕二（人生の勝算）が誤って小説判定に流れていたので除外条件を足した。寺田寅彦の随筆7冊は amazon_metadata.author 側に「寺田 寅彦」の半角スペース表記しか入っておらず、英語表記しか見ていなかった判定ロジックを直したら拾えるようになった。最終的に47件に novel タグを付けた。

# 集計とスキップ判定の双方に novel/drawing を追加
SKIP_TAGS = {"comic", "novel", "drawing", "excluded"}

続いて描き方シリーズ。デッサンやイラスト技法書の drawing タグを足したら12件ヒットして、ここは誤判定なしで一発で通った。途中で「英単語1100」が紛れ込みかけたのでタイトルキーワードを絞った。

進捗ジェネレーターにも同じスキップ判定を入れ、ついでに「次に取り込む候補トップ10」を進捗ファイルの冒頭に出すよう改造した。これで朝イチで進捗ファイルを開いただけで、次に何を取り込むかが見えるようになった。Audrey Tan の本（B09MQDL4XF）は読まない判断にしたので excluded タグでスキップ化した。

1冊目バッチ: 直列で待っていたら指摘された

最初に着手したのが経営KU精鋭4冊（コンサル一年目 / イシューからはじめよ / 目的ドリブン / 仮説行動）。/yomitoku-kindle でコンサル一年目（B00MA671WW）の撮影を始めた。117ページ・約8分で撮影が終わり、OCRをバックグラウンドに投げてOCR完了通知をひたすら待っていた。

ここでユーザーから指摘が入った。

非同期的にやってもらいたいんですけど、OCR待ってる間、例えばスクリーンショットのプロセス、次のやつ進められたりするじゃないですか。てかそれ、スラッシュコマンドに書いてませんでしたっけ？

/yomitoku-kindle のスラッシュコマンドの Step 16 を読み返したら「バッチ実行中なら次の本の撮影／OCR／DB投入に進む」と書いてあった。仕様としては並列を想定していたのに、自分が単発実行の頭のまま直列でブロックしていた。

並列に組み替えた。1冊目のOCRが走っている間に2冊目（イシュー）のスクショを別ウィンドウで開始。1冊目のDB投入と紐付け（90チャンク → kindle_library + amazon_metadata）が終わった時点で、restructure はサブエージェントに非同期で投げた。restructure は数分かかる目次整形タスクなので、メインのスレッドはそのまま3冊目（目的ドリブン）の撮影に進める。

この構成にしたら、撮影律速の本（200ページ前後で約8分）の間にOCR（3〜5分）と restructure（サブエージェントに投げきり）が裏で進む。1冊あたりのウォールクロックが2倍くらい縮んだ感覚があった。

午後の2冊目バッチで方向誤判定を踏んだ

午後は不動産投資2冊（B0CV4SLXBG / B00GX1Q0YU）＋ DD論（B07F1189D3）＋仮説行動（B0DF1TPKVQ）の4冊。

1冊目 B0CV4SLXBG は方向 auto で開始して問題なく通った。72チャンク格納してFTSも全クエリヒット、restructure サブエージェントを起動。並行で2冊目 B00GX1Q0YU の撮影を開始した。

問題は2冊目のOCR完了直後。p.1の画像を確認したら奥付が映っていた。方向判定が逆転していた。

撮影方向: ltr で開始
実体: 和書（rtl）
結果: p.1 が奥付・p.118 が表紙

ここはDB投入前のリカバリだったので、画像ファイルの並び順を反転 → md再生成 → OCR再実行で済んだ。再実行後の p.1 は表紙になり、紐付けまで通って94チャンク格納。restructure サブエージェントに投げて50セクションに整形された。

DB投入後だと restructure までやり直す必要があるので、p.1の方向判定はOCR完了直後の必須チェックとして体に刻まれた。

Chrome の Tabs edit エラーを2回踏んだ

3冊目 B07F1189D3（DD論）の撮影が45枚で error / Tabs cannot be edited right now で中断した。Chrome 側の干渉エラーで、Chrome 拡張がタブを編集しようとした瞬間に拒否された。タブを閉じて新規タブで開き直し、rtl で再開した。

そのまま続けると、また同じエラーで2枚で停止した。2回目で初めて画面をよく見たら、Kindle Cloud Reader のダイアログ「Most Recent Page Read」が出ていた。前回の読了位置に飛ぶか聞いてくるダイアログで、これが開いているとタブ操作が阻害される。ダイアログを閉じてから rtl で再開したら、最後まで撮影が通った。138枚撮影完了。

学びとして残したいのは、Chrome 拡張のタブ操作系エラーは「Chrome 全体の状態」ではなくて「ページ上に開いているダイアログ」で再現することが多い、ということ。次に同じエラーが出たら、Chrome を再起動する前に Cloud Reader のダイアログを疑う。

バッチ完了と進捗

午前4冊＋午後4冊で計8冊を取り込み、進捗は取込済 11冊 → 17冊、KU借中 19冊 → 15冊残まで進んだ。各書籍は撮影約8分・OCR約3〜5分・DB投入とrestructureは並行で消化、というリズムで回った。

今回の構成で固まったパイプラインは次の形になった。

1. メインスレッド: 撮影 → OCR起動 → DB投入 → 紐付け → 次の本の撮影開始
2. サブエージェント: restructure（目次整形・セクション統合）を非同期で消化
3. 進捗ジェネレーター: 冒頭に並列処理ルールと次の取込候補トップ10を出す

書籍取込はOCR・DB投入・restructure それぞれが別の I/O 待ちを持つので、サブエージェント並列の効きが分かりやすい。直列で寝かしていた時間が、別の本の撮影で埋まる構図にできた。

明日に持ち越したこと

• KU借中の残り15冊を、撮影律速で消化していく
• 方向判定はOCR完了直後の p.1 チェックを毎回回す（DB投入後だと restructure までやり直し）
• Chrome の Tabs cannot be edited right now が出たら、まず Cloud Reader のダイアログを疑う