朝5時半に「あれ、確かインポートするのを計画してたはずなんだけど途中で終わってたんだよね」と引き継ぎ計画書を Claude に探させたところから1日が始まった。気付けば夜まで /import-batch を回し続けて、不動産・DD・デザイン・コンサル・宅建・お金の6カテゴリを Turso DB に流し込んでいた。最後のお金・投資系10冊を流し終えたタイミングで「じゃあ残りは明日にしましょうか」と切り上げた。

今日の流れ（ざっくり）

合計 38冊（スキップ1冊を除く）。

朝の再開 — 残っていた不動産3冊と「あと6冊あるんでしたっけ？」

冒頭の音声入力は「あの確かえっと インポートするのを 計画してたはずなんですけど 途中で終わってたんですよね」だった。Claude Code に bulk-import-plan.md を漁らせて、不動産カテゴリの取り込みが3冊残ったまま止まっていたのを発見した。

3冊（No200／No202／No201）の OCR を回しながら、ユーザー優先指定でビジネス・デューデリジェンスの本（No24）を割り込ませた。ここまでは順調で、合計4冊を一気にレストラクチャーまで完走した。完了報告を受けたあとに「あの、ちょっと待って。デューデリジェンスの本で、ビジネス・デューデリジェンスって1冊しかなかったでしたっけ。」と質問が飛んだ。

Claude が「タイトル一致は1冊だけです」と返したが、ユーザー側にはまだ DD カテゴリの本が6冊残っている記憶があった。再確認させたところ、M&A・DD カテゴリにあと6冊あったのが判明。「途中でやめたんですか？」と問われ、Claude は「Auto modeで一気に進めるべきでした」と詫びて、DD関連8冊を一気に投入し直した。

途中で1冊だけ、ファイル名が「図解でわかるM&A」なのに中身が「図解でわかる投資ファンド」になっていた本が見つかり、これはスキップにした。連番フォルダ運用の落とし穴。

デザイン系 — 「Googleのやつ」が通じる瞬間

不動産＋DD で12冊終わったあと、「デザイン系も取り入れてほしい」と注文が入った。キューには「デザイン」を含む本が2冊しか入っていなかったが、Dropbox の裁断PDFを漁ると思想系・実務系のデザイン本が10冊以上眠っていた。元の計画書では「自己啓発・プログラミング・語学・歴史」を除外していて、その流れでデザイン系も外していたらしい。

「実務スキルの方がいいですね。Googleのやつなかったですかね」という曖昧な指示で、Claude が No107_Google流資料作成術（『Storytelling with Data』の日本語版）を当てた。「あ、そうそうそう、Googleのやつそれね」で確定。データ可視化＋プレゼン＋伝え方系の4冊を投入した。

このあと、別件で「蔵書レビューページにミラーカラムレイアウトの折りたたみを入れてくれ」という指示が画像付きで飛んできた。OCR を裏で回しながら eurekapu-nuxt4 の参考実装を読みに行き、3カラム折りたたみを実装して HMR で確認した。OCR の待ち時間が UI 実装の時間に化けた瞬間で、/import-batch の隙間時間は意外と使える。

セッション分担という気づき — 「OCR係」と「リストラクチャー係」を分ける

今日いちばんの収穫は、別セッションで投資・お金カテゴリを並行起動しようとして気付いた挙動の話。

yomitoku（OCR）は GPU(CUDA) を専有するので、/c/Users/numbe/Git_repo/book-knowledge-base/data/.yomitoku.lock という排他ロックで「OCRは全セッション通じて同時1プロセス」に制限している。並走を試みた瞬間、ユーザーがこう言った。

一連の流れを複数セッションでやるんじゃなくて、あるセッションでは OCR してもらって、あるセッションではリストラクチャーやってもらうっていうのを分担した方が早いってことですね、これ。

その通りで、OCR は GPU 律速で1冊ずつ順番待ち、一方でメタデータ判定／取込／restructure／DB 書き込みは GPU を使わないから別プロセスで並行できる。つまり、

• セッションA: OCR をひたすら回す（GPUロック保持係）
• セッションB: A が吐いた中間生成物を受け取って restructure と DB 投入を回す（CPU・I/O 係）

という分担にすると、A の OCR が次の本に進んでいる間に B が前の本を仕上げられる。今日のセッションは1人で両方やったので、OCR完了通知を待ってから取り込みに進む直列待ちが何度も発生した。明日からは分担する。

コンサル10冊 — 「大胆に減りすぎ」とリストラクチャー再実行

コンサル系3点セット（10冊）は /import-batch 1コマンドで朝10時台から流し始めた。途中で No764 のレストラクチャー結果を見て、ユーザーが違和感を拾った。

確かにちょっと大胆すぎますね。なんか目次、小見出しなどもうちょっと細かくなっているっぽいですけど、なんでこんなに大胆に減っちゃったんですか？

調べると、章（年次）単位で7チャンクに統合されていて、第1〜3章が各40〜54KB の巨大チャンクに膨らんでいた。1チャンクに79項目を詰め込んでいる状態。subagent に再構造化を依頼して、7チャンク→86チャンク に分解し直した。「001 インテレクチャルリーダーシップ VS『優しさ』のリーダーシップ」のような各 VS 項目が個別チャンクで section に格納され、全文検索で「論点マネジメント」「ケース設計」が個別ヒットするようになった。

リストラクチャーの「ちょうど良さ」は本ごとに違って、目次がフラットな実用書なら章単位の統合でいいが、項目数が多い大判の書籍だと項目単位まで割らないと検索が鈍る。AI 任せにすると章単位で大胆にまとめがちで、画面に出てくるチャンク数を見て「これは粒度が荒すぎる」と人間が拾わないと壊れたまま気付かない。

宅建系 — 「みんなが欲しかった！」はもう入っていた

宅建士の教科書3冊（No821／No820／No818）を投入したあと、ユーザーが「みんなが欲しかったのだったっけ？それはもう取り込み済みだったってことでしたっけ。」と尋ねた。Claude は最初「取り込んでいません」と答えたが、改めて amazon_metadata を引き直すと、No819 みんなが欲しかった！宅建士の教科書 2025年度版 が 既に取り込み済み（takken-kyokasho-2025-01-takkengyoho で74チャンク登録済み）だった。book_id で紐づいているせいでキューの候補から除外されていただけ。「キューに無い＝未取り込み」と即断するとミスる。

途中で「アップピリオド・アップハイフン・宅検」と聞こえた音声入力があり、Claude は最初これを「app-takken」（アップタッケン）と聞き間違えていたと気付いて、app-takken プロジェクトの過去問JSONの存在を確認した。Turso DB への取り込みは別タスクで明日以降。

お金・投資系10冊で打ち切り

夕方、memo/2026-06-14/next-session-toushi-okane.md に書き出しておいた10冊（投資の聖典・名著系）を /import-batch で投入した。No845（282p→104→27チャンク）から始めて、最後の No824 まで完走。全10冊終わったタイミングでユーザーから一言、

じゃあそれは明日やりましょうか。

お金カテゴリの残り15冊（No589 など）は積み残し。1日 /import-batch を回し続けて、「あと一歩で全カテゴリ揃う」のところで切り上げた。

今日の収穫

• /import-batch は1コマンドで10冊を順次回せて、1セッションで完結する設計が効いた
• ただし1セッション内では OCR と restructure の直列待ちが発生する。OCR係セッションとrestructure係セッションを分けるのが正解
• AI のレストラクチャーは章単位で大胆にまとめがち。チャンク数を画面で見て「粒度が荒すぎる」と人間が拾わないと壊れる
• 「キューに無い＝未取り込み」と即断しない。amazon_metadata の book_id で除外されているだけのケースがある
• ファイル名と中身が一致しない PDF が混ざる。中身を冒頭ページで確認してからスクリプトを書くべし

明日やること

• OCR係セッションとリストラクチャー係セッションの分担運用を試す
• お金カテゴリ残り15冊（No589 ほか）を /import-batch で投入する
• app-takken の過去問JSON群を Turso DB に取り込むかどうか方針を決める
• レストラクチャーの粒度判定を自動化できないか考える（チャンクあたりサイズが閾値を超えたら再分割する仕掛け）