裁断済み書籍 PDF に管理番号を振った日｜連番フォルダと Turso DB の監査、自動出力メモの片付け、evals レポートの見直し
裁断済み書籍 PDF に管理番号を振った日｜連番フォルダと Turso DB の監査、自動出力メモの片付け、evals レポートの見直し
裁断してスキャンした本は、Dropbox の連番フォルダに PDF で入れている。 そのうちどれを Turso DB に取り込んだのかを、午後に把握しておきたくなった。 リストはまだ DB に入っていないのではないか、と思いながら聞いた。 入ってはいた。 ただ、途中の番号で登録が止まっていた。
朝は朝で、別の一覧の見直しがあった。 毎朝のチェーンが出す evals レポートに、過去の週のエラーが赤く残っていた。 そもそもこれは何のためにやっていたのか、というところから聞き直している。
14:32 裁断済み PDF のリストは DB に入っていたか
最初に聞いたのは、裁断した書籍のリストはまだ DB に入っていないのか、だった。 入れるなら mdx-playground の DB と同じところがいいと思う、とも添えた。
Claude Code の答えは「入っています」だった。
置き場所は mdx-playground の DB ではなく、book-knowledge-base の Turso DB にある amazon_metadata テーブルである。
Dropbox の連番 NoXXX が file_no 列にあたり、取り込み済みの本は book_id 列で books テーブルにつながる。
ただし、No864 以降は登録が止まっていた。
フォルダと DB を突き合わせた結果は、A から C の3つの作業に分けて示された。 「順次 A から」と答えて進めさせた。
A：未登録分の登録と紐付け
Claude Code は既存の取得スクリプトの動きを確かめ、dry-run を既定にした登録スクリプトを用意した。
dry-run の結果は登録43件、紐付け28件で、想定どおりだった。
書き込みのついでに、No678 の book_id の打ち間違いも直させた。
続いて、書名で検索して Amazon の情報（ASIN、評価、表紙）を取らせた。 検索は通ったものの、書名の似た別の本に当たる誤マッチが見えた。 そこで46件すべてを書名と照合させている。 Web 検索では版を特定しきれない本もあり、最後は手元の PDF の奥付から ISBN を読み取らせた。 取得は全件成功し、No866 だけ大きい表紙画像と発売日が取れていなかった。
表示の確認では、もう一つ引っかかった。
書棚のページ /shelf は、評価順で上位500件しか読み込まない作りだった。
並び順を「No順」に切り替えて確かめると、API からは No864〜921 の57件すべてが返り、うち42件に DB 化済みの紐付けがあった。
B と C は一覧まで
A のあと、Claude Code は B（同じ番号が重なっている62件の仕分け）と C に進んだ。 DB を直したのは A だけで、B と C は一覧を作ったところで判断待ちになった。
一覧を見て、返事を貼り付けた。 Claude Code はそれを受けて紐付けの照合をファイル名優先に直し、仮番号を振る52冊のファイル名を確定させた。 登録が済んだところで、Dropbox の PDF 全件とリストを突き合わせ直させている。
結果は、番号の付いた PDF はすべて DB の一覧に入った、というものだった。 番号の付いていない PDF（約80件）だけが残った。
番号なしの PDF に管理番号を振る
番号なしの PDF にも番号を付けてほしい、と頼んだ。 管理番号でいいし、ファイルのリネームでかまわない。 周りから見ても分かるように付けてほしい。 問題はない気がするが、他のデータベースとの整合性があるならそれに合わせる、とも伝えた。
Claude Code は先に影響範囲を調べた。
調べたのは、DB の books.source_path がこれらのファイル名を参照していないか、ほかのリポジトリやデータから参照されていないか、の2点である。
途中、コマンドの引用符が崩れたため、スクリプトファイルに書き出して流し直していた。
file_no を持つテーブルは3つ（amazon_metadata、amazon_categories、book_colophons）あった。
Claude Code はそこから計画書を書いて Codex の承認を取り、HTML にして判断フォームのサーバーを立てた。 答えは、ファイル名の先頭に番号を付けるリネームで問題なく、ほかの DB との整合性も心配ない、だった。 ただ83件の中身はまちまちなので、3点だけフォームで決めることになった。
3つとも A を選んだ。 Claude Code はそのとおりに DB を更新し、63件の PDF をリネームした。 新しく登録した単行本の Amazon 情報も取り、フォルダと DB を突き合わせ直している。 コマンドラインからは文字コードの都合で JSON がうまく読めず、確認はブラウザに切り替えた。 番号を付け替えた11冊（No943〜953）は、表紙もタグも引き継がれて返ってきた。
Mac 側への連絡
作業の結果は、cross-machine-message のスキルで Mac 側のセッションにも送らせた。
宛先の tmux セッション claude は見つからなかった。
Mac 側には claude2 と claude3 の2つがあり、自分が言った「Claudeさん」を Claude Code は claude3 と受け取って送った。
番号の付け替えが終わったあとにも、更新を送らせている。
コミット、プッシュ、作業前からあった変更
コミットは、今回の作業で変えたファイルだけを選ばせた。
作業前からあった未コミットの変更（.claude/issues/…、data/…、memo/2026-09-03/）は含めていない。
コミットは Codex のコミットゲートで3回止まり、4回目で通った。
指摘はどれも、新しく作ったスクリプトを後で使うときの不具合だった。
今日 DB とファイルに対して行った作業の結果には影響していない。
主に直したのは5点で、コミットは 2260530（18ファイル）になった。
この時点では push していない。
「このセッション、未了事項はないって感じで大丈夫ですか」と聞いた。 頼んだ範囲で残っている作業はない、ただ残したままのことと確認がまだのことがいくつかある、という答えだった。
そこで、プッシュと dev サーバーの停止を頼んだ。
作業前からあった未コミットの変更も、内容によってはコミットしてかまわないと伝えた。
Claude Code は作業前からあった4件を含めて、6コミットを origin/master に push した（a83ca7c..d439214）。
自動出力の監査メモを残すか
Claude Code の報告には、監査結果のメモをどうするか、という話が入っていた。 これはローカルに残しているだけなのか、と聞き返した。 自動出力で、しかも古い。 何の図版の監査なのかも分からない。 一旦削除しちゃいますか、と投げた。
Claude Code は memo/2026-09-03/ を削除した。
git の管理外だったので履歴には残らない。
ただし scripts/audit_figure_references.py を実行すれば、同じものを作り直せる。
これで book-knowledge-base の作業ツリーには、未コミットの変更も管理外のファイルもなくなり、origin とも一致した。
07:55 evals レポートは何のためにあったか
時間は前後するが、朝は前日分の /make-diary を回していた。
2026-10-11 分の日記は、Codex のレビューで出た致命的な指摘3件の修正まで含めてコミットした（563f1ff3）。
チェーンの最後には、evals のレポートを更新させた。
そのレポートに、過去の週のエラーが残っていた。 そもそも何のためにやっていたのかを聞いた。 直すべきなら対応してほしい。 直すべきでないなら、今の状態がエラーでない以上、もうエラー表示を出さないでほしい、と頼んだ。
evals の運用は、記事に対する検査が error を出したらその場で記事を直し、再チェックで0にする、というものである。 ところがレポートは、過去に error の行が1つでもあると、日次も週次もバナーも ⚠ にしていた。 直し終わった週まで、赤いまま残っていたわけである。
過去の週のエラーは、どれも記事の側では直っていた。
直すべきなのは、レポートの表示のほうだった。
8月28日の分は現行の判定で再チェックさせ、その記録を足した（4b63c21d）。
当時の error（AMD の −19.9%）は、「52週高値からの位置」を騰落率と取り違えた誤検知で、現行のエンジンでは error が0になる。
表示のほうは、同じパイプラインと同じファイルについて、error より後に error 0 の検査があれば「解消済み」として警告から外す形に直させた。 件数は残し、注記を付ける。 直したあとに再発した error は、新しいものだけが開く。 テストは61件すべて通り、そのあと再発のケースのテストを足してもう一度コミットさせた。
Claude Code が Chrome のタブを読み直すと、バナーは ✓ になり、赤い日と赤い週は0件だった。 過去2週は「error は再チェックで解消済み」の注記つきで ✓ になった。 最後まで残った ⚠ は、案内文の中の1文字だけだった。
学びメモ
- 番号の付け方を決める前に、ファイル名を参照している場所（DB の列、ほかのリポジトリ）を先に洗わせた。
file_noを持つテーブルが3つあると分かってから、リネームで問題ないと判断できた - 古い自動出力のメモは、生成スクリプトが残っていれば消しても作り直せる。今回は、管理外のまま手元に置いていたメモを消して、未コミットの変更も管理外のファイルもない状態にした
- evals の赤は、記事の不具合ではなく、直し終わった error を数え続けていた表示の問題だった