自炊した蔵書は「取り込み済み」でも使えるとは限らない
自炊した蔵書は「取り込み済み」でも使えるとは限らない
朝いちばんに、クラウドストレージの共有リンクを Claude Code に渡した。 裁断した本のPDFはここに全部入っている、という所在の情報をまずドキュメントとして残しておきたかった。 ついでに、前の晩に手元へ落とした2冊を読み解いて整形しておいてほしい、と足した。
返ってきたのは「2冊とも取り込み済みです」だった。
入っていないと思ったら、入っていた
思い込みの出どころははっきりしている。 この2冊を取り込んだのは旧マシンで、そのときの作業跡が今の環境からは見えなかった。 画面に何も残っていないので、まだ手を付けていない本だと判断していた。
実際には取り込みも後処理も終わっていた。 記憶のほうが正しかったのに、目の前の画面を信じて上書きしてしまったことになる。
同じ勘違いは次もやる。 だから所在のドキュメントに、どのマシンで取り込んだ分がどこまで反映されているか、という一節を足させた。 原本の置き場所だけ書いても足りない。 どの機械で何をしたかは、蔵書のデータベースを引いても出てこない。
スキル化の計画書を一区切りにする
夜、蔵書を素材にしたスキル化の計画書を開いた。 この計画書からの作成はもう終わりでいいのか、と確認した。
答えは、終わりでいい、だった。 ただし計画書の側にはそう書かれていなかったので、2箇所に追記させた。
完了の判断が頭の中にしかない状態は、書いていないのと変わらない。 数日置いて開き直したときに、どこから再開すればいいのかが分からなくなる。 締め方まで含めて計画書だ、と思うようになった。
入っていると思ったら、使えなかった
深夜になって、ある専門書の巻末が気になった。 数字だけが並んだ表が20ページほど続く付録がある。 蔵書のデータベースには入っているはずなので、そこから引けばいいと考えた。
引かせてみると、該当ページはたしかに存在した。 ただし19ページ分が1つの塊に固まっていて、5万字を超える巨大なチャンクになっていた。 中身を見ると、数字が並ぶはずの場所に「+税」や「3歳」といった文字列が混ざっている。 OCRが表の格子を追いきれず、別の場所の断片を拾い集めていた。
行はある。 中身は使えない。 「取り込み済み」に2段階あることをここで初めて実感した。
原本から取り直す
DBの側は諦めて、クラウドに置いてある原本のPDFを落とし直させた。 175MBある。
付録は横向きに組まれていた。 1枚の画像に上下2ブロックが入っていて、それぞれが紙面1ページ分の表になっている。 回転させてから分割させると、20ページが40ブロックになった。 いきなり全部を投げず、まず1枚だけ codex に渡して出力の形式と精度を確かめさせた。 形が固まってから、残りを10並列で流した。
待っている間に検証の側を用意させた。 この表には強い規則性があるので、目視ではなく全件を機械で確かめられる。
最初に立てた規則は一部が外れていた。 実データから導き直させて、3回直したところで2,500行すべてが式と整合した。 途中で19件の指摘も出たのだが、こちらは表の区切りで値がリセットされる正常な挙動を検証側が拾っていただけだった。
そのあと表計算に転記させ、書き込んだ内容をAPI経由で読み返して往復照合させた。 不一致は0行だった。 別口で、レビュー用のサブエージェントに原本の画像と突き合わせさせた。 2,625セルの目視照合でも不一致は0だった。
表の規則は本文にも書いてあった
規則が出そろってから、本文側を読ませた。 自分が実データから導いた形と、本の中の記述が食い違っていないかを確かめたかった。
一致していた。 著者は本文の中でこの規則を明示していて、付録の使い方もその数ページ後に書いてある。 自分は、本を読めば分かることを表のほうから逆算していたことになる。
面白かったのは規則の強さのほうだ。 表の各行は、独立した数値の並びではない。 前の値から次の値が決まる連鎖になっていて、全体が数本の短い式で再現できてしまう。
これはダイヤル錠の候補を絞り込んだ一覧である。 機械の構造上ありえない組み合わせを落とすと、目盛りの数から素朴に想像するよりずっと少ない候補しか残らない。 守る側から読むと、この付録は「桁が多く見える錠でも、候補は見た目ほど多くない」という話になる。 具体的な式と値、操作の手順はここには書かない。
太字は電子化で落ちる
レビューから重い指摘が返ってきた。 太字が丸ごと落ちている、という。
表の一部の行が太字になっていて、それは著者が現場で当たりを付けている組を指している。 太字はOCRの結果にもDBにも残らない。 原本の画像を見に行かないと存在すら分からない。
codex に太字だけを抜き出させ、レビュー側が独立に目視で報告してきた行と照合した。 2つの経路が完全に一致した。 太字は77件で、全体の3%ほどだった。
ここで妙なことに気づいた。 太字が集中している組と、本文が確率の高い範囲として挙げている値が一致しない。 本文が中心とする組は、太字28種のうち11番目でしかなかった。 著者が現場で溜めた勘のほうを太字が指している。
電子化で落ちるのは文字ではない。 文字に載っていた強弱が落ちる。 テキストにしてしまえば、どの行も同じ重さの文字列になる。
回して確かめる画面にする
表を眺めても規則は頭に入らないので、盤を回して確かめられる画面を作らせた。 ボタンを順に押していくと段ごとに合否が色で分かれて、どこまで揃っているかが目で見える。
父が見るので、文字を大きくしてほしいと注文を付けた。 一度直させたのに注記だけが小さいままだったので、実測させた。 ルートの文字サイズが既定のままで、相対指定がそこに引きずられていた。 ルートごと上げて、いちばん小さかった注記を本文と同じ大きさにそろえた。 12.5pxが20pxになった。
見出しが読点でないところで割れて「77行し/かない」と表示されていたのも直した。 文字数を均す指定が日本語で悪さをしていた。
PCでしか見ないと伝えたので幅も広げた。 1画面に収まる版は別ファイルとして作らせ、今の版はそのまま残した。 気に入っているものを作り直させて失うのがいちばん惜しい。
学び
- 「取り込み済み」には2段階ある。DBに行があることと、中身が使えることは別物だった
- どのマシンで何をしたかは、データベースを引いても分からない。所在のドキュメント側に書いておく必要がある
- 完了の判断は計画書に書いて初めて完了になる。頭の中にあるうちは、次に開いたときに再開点を探すことになる
- OCRを通した時点で、太字のような装飾に載っていた情報は消える。原本を見に行く経路を残しておく
- 規則を体で分かるには、表を眺めるより触れる形にしたほうが早い。作った画面で、本の理論値より著者の印のほうが早く当たる場面が出た
明日やること
- 1画面に収まる版を、全ステップ通して動かして確認する
- 巨大チャンクになっていた付録ページを、取り直した結果でDB側に入れ直す
- 表を含む本が他にもないか、同じ壊れ方をしていないか当たらせる