蔵書DBの書籍取り込み:雑学本をサブエージェント5体で1項目1チャンクに分け直し、Webセキュリティの資料をOCRから仕上げる
蔵書DBの書籍取り込み:雑学本の分け直しとWebセキュリティの資料のOCR
朝、連番で管理しているフォルダから雑学本のPDFのパスを貼り、「これってもう取り込んでましたっけ?」と聞いた。 取り込んでいなければ、読み解く(OCR)ところから全部やってきれいにしておいてほしい、という頼み方である。
答えは「取り込み済み」だった。 5月13日の時点で766チャンクとして蔵書DBに入っており、OCRはやり直さずに済んだ。 残っていたのはクリーンアップである。
午後はスキャナの保存先に置いたWebセキュリティの資料を、リネームから順に通した。 どちらの本でも、同じことを何度か確かめ直した。 戻ってきた結果を、どこまで信じてよいか。
雑学本の図1,253枚から飾りを選り分ける
クリーンアップで手間がかかったのは、図の仕分けだった。 R2から図を手元に落とし、判定用のシートを53枚作らせた。 まず2枚だけは Claude Code 自身に見させて、判定基準をすり合わせた。 残りのシートはサブエージェント5体に判定させた。
判定リストを保存する段で、長いヒアドキュメントがシェルで崩れた。 1ファイルずつ Write で保存する形に切り替えて通した。
結果は、1,253枚のうち1,036枚が装飾だった。 判定は妥当だった。 目次ページの図は「PART 番号」の飾り数字で、p8〜p162 は写真中心のため飾りが少ない構成だった。 表紙と目次のまわりが消されていないことも確かめさせたうえで、本文に貼られていた1,032枚の図タグを外した。 柱(ページ上部の書名や章名)の除去対象21件もあわせて見させている。 全文検索(FTS)の再構築は時間がかかるので、バックグラウンドで流した。
検索は通った。 ただし「別腹」のような2文字の語は、trigram 索引の対象外になる。
ブラウザで確かめたときは、最初にサイドバーの表紙まで拾っていた。 本文の図だけに絞って撮り直させた。 自分のほうからもスクリーンショットを送った。 p210 では花飾りが3つ消えて本文だけになり、写真を残した p211 では写真がそのまま表示されていた。
履歴に書こうとした「未参照3枚」は、推測で書かずに実測で裏を取らせた。 最初は xargs がファイル名の空白で割れてしまい、DB側で直接突き合わせる方法に切り替えた。
「サブエージェントで分担して」と頼んだあと
クリーンアップの報告を受けて、もう一段頼んだ。 たぶん Sonnet が使えると思うので頑張ってほしい、サブエージェントで分担を決めてやってほしい、という内容である。 これを「1項目=1チャンク」への分け直しとして進めてもらった。
着手前に、いくつか地ならしをさせた。
- 1ページに複数のチャンクがあっても、DBとビューアが対応できるか
- 項目の後ろに
▽で始まる短文として混ざっていた「一言雑学」が、どこにどれだけあるか - 一言雑学のページの中身が、前のページに全部入っているか
- 全文検索の索引が、トリガーで自動更新されるか
途中で、シェル経由だとバックスラッシュが崩れる問題にも当たった。 スクリプトはファイルに書いてから実行する形にそろえさせた。 DBへ適用するスクリプトも、試しの指示1件で動かしてから本番の指示に使わせている。
5体には群Aから群Eまで、編ごとに分担させた。 報告は群ごとに一つずつ戻ってきた。
群Bの報告には、「別の項目に紛れ込んでいた本文を元の項目へ移した」とあった。 これは指示の範囲外である。 移した文字列が原文に実在するか(新しく作文していないか)を、全体がそろってから機械的に照合することにした。
群Dは、DBで「歴史編」とされている後半(p574以降)が、実際は「ワールド編」だと指摘してきた。 PART 扉は13まであるのに、DBの編は12しかなかった。 所属の付け替えは、全体がそろってからメイン側でまとめて行うことにした。
群Eは「推測を含めて直した」5件を報告してきた。 これは中身を一つずつ確かめる対象に回し、「主な参考文献」を後付に移す作業はメイン側で引き取った。
群Aは、PART 扉の近くにあった文の切れ端が、ことば編の最初の項目(KT-002)の冒頭だったと突き止めて、元に戻していた。
群Cを待つあいだに、そろった4群分の指示を試しに適用させた。 照合スクリプトが MK-025〜037 を食い違いとして出してきたが、それらの文は下書きにも実在していた。 照合側の誤判定とみて原因を探らせると、置換が効いていない箇所があり、Edit で直させた。 画像の並べ替え関数も読みにくい書き方になっていたので、書き直させた。
書き込み後は、ブラウザで p89 を確かめた。
3項目が見出し付きで並び、そのページの一言雑学が ▽ の箇条書きで表示されていた。
目次と、ワールド編の区切りも確かめさせた。
これで766チャンクが1,913チャンクになった。
Sonnet の各群が「確信が持てず直さなかった」項目が232件残った。 これはチェックボックス形式の要確認リスト1枚にまとめさせ、再構造化の履歴と一緒にコミットさせた。
午後はWebセキュリティの資料を619ページ分
スキャナの保存先にあったPDFを /rename-pdf でリネームさせ、連番で管理するフォルダへ移させた。
保存先には No920 がまだ残っていたので、今回の分は No921 にし、次回の開始番号は No922 に更新させた。
先にDBを確かめさせると、Webやセキュリティを含む書名はまだ1冊もなかった。
/yomitoku の手順で取り込みに入った。
自分がメタデータを確かめているあいだに、619ページのOCRをバックグラウンドで先に走らせてもらった。
OCRは619ページすべてがエラー0件で終わり、図は50枚だった。 DBに格納すると577チャンクになり、図50枚のR2アップロードも成功した。
続く /restructure-book は、まず書き込みなしの dry-run で節の割り当てを確かめさせた。
/book-cleanup では判定用のシートが3枚しかなかったので、サブエージェントには回さず Claude Code 自身に判定させた。
数字だけの行が見つかったが、これはページ番号ではなかった。 コード中の括弧が化けたもので、本文の一部なので触らずに残した。 除去したのは柱600箇所だけである。
FTS の再構築は、ここでもバックグラウンドで流した。
ただ、出力を tail に通していたので、終わるまで中身が見えなかった。
ブラウザ確認でも引っかかった。 Chrome DevTools MCP が応答せず、Chrome の状態を確かめてから接続し直させた。 その途中で見出しの欠落が見つかった。 見出しを戻したうえで、ほかの章扉のチャンクに同じ欠落がないかも確かめさせた。
表示では、図がR2から正しく配信されていた。 p20(はじめに)と、章扉カードを外した p30(第1章)は DOM で確かめた。
30分で止まったもの
取り込みを終えたあと、30分の上限で止まったものが2つあった。
1つはビューアの dev サーバーで、バックグラウンド実行の既定上限30分に達して止まっていた。 表示確認は止まる前に済んでいた。 すぐ開けるように、上限を2時間にして起動し直させた。
もう1つは、検索インデックスを再構築していたスクリプトである。 こちらも30分の上限で強制終了されていた。 このリポジトリには、FTS のリビルドが HTTP 経由だと止まって見える既知の issue があり、先にそれを確かめさせた。
実害はなかった。 インデックスは本文の更新に自動で追従する作りで、実際に検索して確かめた。 復元した「はじめに」の見出しは p20 でヒットし、柱の文字列は1件も残らず、チャンク数は519件のままだった。
そのあと、dev サーバーはもう一度止まった。 セッションが待機しているあいだにPCの空きメモリが極端に減り、Claude Code が自動で停止したためである。 サーバー自体の不具合ではなく、取り込んだデータ(Turso DB と R2 の図)にも影響はない。
学び
- サブエージェントの報告は、指示の範囲外の作業ほど裏を取る。群Bが本文を移したと書いてきたとき、移した文字列が原文に実在するかを機械照合の対象にした
- スクリプトが30分で強制終了されても、それだけで失敗とは決めない。検索でヒットするか、柱が残っていないか、チャンク数は変わっていないかを確かめてから判断した
- 照合スクリプトが食い違いを出したら、データより先にスクリプトを疑う。MK-025〜037 は文が下書きに実在しており、効いていなかったのは置換のほうだった
振り返り
朝の雑学本では、戻ってきた報告に種類の違う問題が並んだ。 範囲外の移動、編の取り違え、推測を含む修正、切れ端の復元である。 1,913チャンクは、どれもメイン側で照合してから書き込んだ。
照合を通らずに残っているのは、232件の要確認リストである。 Sonnet の各群が確信を持てずに直さなかった項目で、あとから見返せるように1枚にまとめた。