自炊した入門書を節単位に組み直す(234チャンクを109に)

開発book-knowledge-base

朝いちばんに投げた指示は一行だけだった。

「ドキュメントを見て続きをやってください。綺麗にするやつから全部」。

自炊した数学の入門書を蔵書DBに取り込む作業が、前の日の途中で止まっていた。

どこまで進んだかを自分で数え直すより、引き継ぎ書に書いた順番をそのままなぞらせるほうが早い。

続きの4工程

残っていたのは再構造化、クリーンアップ、検証、履歴の記録の4つだった。

これを頭から順に走らせた。

234のページチャンクを109の節チャンクにする

再構造化は、OCRにかけた画面単位のチャンクを、本の節の切れ目でまとめ直す工程になる。

適用前のスナップショットを退避させてから、1トランザクションで入れ替える段取りにしてもらった。

結果、DBのチャンクは234のページ単位から109の節単位になった。

図は218枚すべてを残した。

コンタクトシートを作り、サブエージェント5体に装飾図かどうかを判定させた。

そのうえで、判定の割れた全10枚を1枚ずつ突き合わせさせた。

装飾と判定されて落ちかけた2枚は、本文がそのまま名指ししている図だった。

迷ったら残す、でいい。

クリーンアップでは、OCRが見出しと誤検出した49行を平文に戻し、段落の途中に紛れ込んだ柱を落とした。

行末の改行は105チャンクで3,305箇所を結合した。

母艦側の取り込みで改行が生のまま入り、日本語の文の途中に空白が開いて描かれていたためである。

最後に全文検索のインデックスを作り直し、ブラウザで実物の描画まで確かめて終わった。

蔵書一覧に出てこない、と思った

作業の途中で手が止まった。

左の蔵書一覧をいくら見ても、この本が出てこない。

取り込みは済んでいるはずなのに、なぜ画面に出ないのか。

聞いてみたら、出ていた。

399冊中118番目に。

一覧は登録日の新しい順に並ぶ。

そしてこの本の登録日は、初回の取り込み時のままだった。

前の日に母艦側から再取り込みしたとき、同じ書籍行の中身を丸ごと置き換えたので、登録日だけが古いまま残っていたわけだ。

「出ていない」ではなく「ずっと下にある」。

自分の目が、一覧の上のほうしか見ていなかった。

3ヶ月前に入れた別経路の版

登録日が6月だと聞いて引っかかった。

昔この本を登録していたのか。

していた。

3ヶ月ほど前に、電子書籍リーダーの見開きスクリーンショット118画面から同じ本を取り込み、41チャンクに整形した版がある。

今回は1ページずつ撮り直したので画面が235枚あり、節に割ると109になる。

どちらの精度が高いのか気になって、同じ箇所を並べて見比べてもらった。

本文の文字はほぼ同じで、精度は同等だった。

違うのはページの粒度で、新しい版のほうが節が細かく割れるぶん、検索と参照に強い。

旧版のチャンクはバックアップに退避してある。

並び順を直すか、この本の登録日を直すか

選択肢は2つ出てきた。

一覧の並びを更新日順に変えるか、この本だけ登録日を9月に書き換えるか。

前者を選んだ。

この1冊の辻褄を合わせても、次に別の本を再取り込みしたときに同じところで迷う。

更新日順なら、最近いじった本が自然に上へ来る。

ORDER BY COALESCE(updated_at, created_at) DESC

一覧の並びをこの形に変えて、この本が先頭に出ることを画面で確かめた。

隠れていた図92枚

もうひとつ、表示側に地雷があった。

ビューアは面積9万px²以下の画像をアイコンとみなして非表示にしていた。

この本の情報図218枚のうち92枚が、その閾値の下にいた。

天秤や数直線、小さな作図が並ぶ。

どれも本文の説明と対になっていて、消えると話の筋が追えなくなる。

クリーンアップ済みの本では非表示を切り、幅の狭い図は原寸より引き伸ばさずに描くよう変えてもらった。

ブラウザを再読み込みして、それまで空白だった位置に小さな図が出ていることを確かめた。

学び

  • 「出ていない」と思ったら、まず並び順と件数を疑う。データの不在より、表示の条件のほうがよく壊れる
  • 同じ行を使い回す再取り込みは登録日を更新しない。一覧の並びに登録日を使っている限り、手を入れた本ほど下に沈む
  • アイコン除けの閾値は、小さな図が主役の本ではそのまま本文の欠落になる。閾値はページ側ではなく本の性質で切り替える
#自炊#OCR#全文検索#蔵書データベース#Claude Code