書籍ナレッジベース整備

朝、55.9MBの税務参考書をナレッジベースに取り込もうとして /import-book コマンドを叩いた。ターミナルにエラーが流れ始め、そこから半日、想定外のバグとの格闘が続いた。最終的に4冊分の書籍をセクション単位に統合するところまで持っていけたが、道中で踏んだ地雷の数は片手では足りない。

PDF取り込み失敗とバグ発見

/import-book でPDFを読み込ませたところ、即座に 400 INVALID_ARGUMENT で弾かれた。ログを追うと、PDFのページ数を取得する正規表現が Count キーワードを拾いきれず、フォールバック値の9999ページがAPIに送信されていた。

結果的にAPIが入力サイズの上限で拒否してくれたおかげで、課金は1円も発生しなかった。バグが財布を傷つける前に気づけたのは運がよかった。

この時点で /import-book コマンドをアーカイブし、ローカルGPU OCRの yomitoku に切り替える判断をした。

yomitoku で285ページを処理した。OCR自体は順調に完了したが、後続の図ファイルリネーム処理で事故が起きた。

grep -P（Perl互換正規表現）がロケール未設定環境で文字クラスを正しく扱えず、307枚の図ファイルが全て同じファイル名にリネームされた。つまり307枚が1枚に上書きされて消えた。

# 原因: LANG未設定で grep -P が壊れる
grep -P '[\x80-\xff]' # → ロケール依存で動作が変わる

grep を捨てて Python スクリプトに書き直し、リネーム処理を再実行して解決した。OCRの出力ファイルが残っていたので、データのロスはなかった。

OCR結果をDBに格納した。285ページが158チャンクに分割された。

続いて /cleanup-book でOCR結果をクリーンアップした。

装飾と情報図の判別は、画像サイズとキャプションの有無で振り分けた。手作業で確認したところ、誤判定はほぼなかった。

ページ単位で分割されたチャンクを、目次の章立てに沿ってセクション単位に統合した。151チャンクが81チャンクに減った。

この作業を手動で繰り返すのは割に合わないので、/restructure-book コマンドを新規作成した。目次を解析し、章・節の境界を検出して自動統合する仕組みになっている。

/restructure-book を使って残り3冊も処理した。

4冊目で143チャンクが41チャンクまで圧縮されたのを見て、目次ベースの統合が機能していることを確認できた。

PDFページ数の正規表現フォールバック: 9999という値がAPIに届く前に止まったのは偶然。フォールバック値は「安全な値」にすべきで、9999は安全ではない
grep -P のロケール依存: Windows環境（Git Bash）で LANG が未設定だと Perl互換正規表現が壊れる。文字列処理は Python に寄せた方が環境差を踏まない
上書きリネーム事故: リネーム先の重複チェックを入れていなかった。mv する前に宛先の存在確認を挟むだけで防げた

一日で4冊分のナレッジベースが整った。/restructure-book コマンドが動くようになったことで、今後の書籍取り込みは OCR → cleanup → restructure の3ステップで回せる。