TAC公認会計士テキスト11冊を書籍ナレッジベースに一括取り込み

朝の積み残し（著者取得444件）を片付けてから、TAC公認会計士テキスト【計算】シリーズ11冊（合計3,488ページ）を yomitoku で OCR 化して Turso DB に格納した。さらに章節整理（restructure）を11冊全部に流して、3,167チャンクを約1,000セクションに統合した。途中で Windows の cp932 クラッシュ、DB の idle timeout、Embedded Replica の WAL ロック、shelf の表示0冊問題に当たり、それぞれ手当をしながら夜までに11冊揃えて shelf に「済」バッジを並べた。

朝イチの積み残し：著者取得444件を `--missing-author` で回す

昨日のセッションで CAPTCHA で止まっていた著者取得の続きから入った。--retry フラグで全788件を再走査するスクリプトを動かしたが、80件くらい走らせたところで気づいた。file_no 順で頭から舐めるので、最初の300件あたりは「既に著者取得済み」を再処理しているだけだった。新規取得は0件のまま、未取得444件には到達していなかった。

無駄を切るため、author IS NULL のレコードのみを対象にする --missing-author フラグを追加して回し直した。今度は target=444 で開始し、CAPTCHA を約23%の確率で挟みながら、約1時間で 350件を新規取得（DB上 344→694件）。残り94件は CAPTCHA で取れなかった分なので、また別日に回す。

進捗メモを memo/2026-04-30/progress.md に書いて、ついでに /books ページのタイトル右に「書棚を見る →」リンクを追加した。今までは /books から /shelf に飛ぶ動線がなかったので、青字で1行リンクを置いた。

ユーザー依頼：「公認会計士テキストも入れたい」

/shelf の動線が整ったあと、ユーザーから Dropbox の 00連番で管理するフォルダ に入っている公認会計士テキスト27冊が DB に取り込まれていない、という指摘が来た。確認すると、書籍ナレッジベースの取り込みスクリプトは NoXXX_ でナンバリングされた PDF だけを対象にしており、2023_公認会計士_... 命名のファイル群は素通りしていた。

27冊全部を一気に流すと所要時間が読めないので、まずは 【計算】シリーズ11冊（合計3,488ページ）に絞って取り込むことにした。優先順位はサイズ小→大→次にCF/連結のハイブリッド順。所要時間を読みやすくするのと、CFWS プロジェクトとの連携で連結関係の本が後で効くため。

最小の1冊（35MB・追加論点収益認識）でパイロットして、所要時間を測ることにした。PDF 先頭ページを読んでメタデータを判定したところ、表紙ロゴから判明したのは「これは CPA ではなく TAC の公認会計士講座テキスト」ということ。book_id のプレフィックスを cpa- から tac- に直した。

パイロット1冊：yomitoku→DB格納まで2分37秒で完走

GPU モードで yomitoku を回したら、120ページを 約2分37秒 で OCR し終えた。1ページあたり1秒強。図ファイル（27枚）をリネームして、yomitoku_import.py でメタデータ登録 + DB 格納を実行し、95チャンクが Turso に入った。FTS 検索で「収益認識」を引いてヒットすることを確認して、パイロット完了。

3,488ページを1ページ≒1.5秒換算で見積もると、残り10冊で約87分。pymupdf でページ数を機械的に拾い、メタデータ案を10冊分一括生成して、ユーザー承認を取って連続実行に進んだ。

Windows cp932クラッシュ：UTF-8/unbuffered 対応版に修正

10冊を順次処理する batch_import.py を書いて、Windows の分離プロセス（90分級なので Bash タイムアウトを避ける）でバックグラウンド起動した。直後にエラー判明：Windows の cp932 が ✓ を出力できずクラッシュ。最初の1冊（09 個別CF）はメタデータ登録までは終わっていたが、yomitoku 実行は中断していた。

スクリプトの先頭で stdout/stderr を UTF-8 unbuffered に切り替え、再起動した。

import sys
sys.stdout.reconfigure(encoding="utf-8")
sys.stderr.reconfigure(encoding="utf-8")
# 起動側: python -u batch_import.py で unbuffered

09 CF は yomitoku が既に完走済みだったので、図リネーム + DB 格納だけで34秒で完了。後続の04（負債・純資産、268p）は4分52秒、02（棚卸・固定資産、272p）は4分26秒。当初想定の1ページ1.5秒より速く、1秒/ページのペースで進み始めた。

DB idle timeout：reconnect() を各冊冒頭で呼ぶ

5冊目（07 連結財務諸表3）まで進んだところで、また止まった。エラーログを見ると DB 接続のidle timeoutで38分超で stream が切れていた。バッチを起動したときに張ったコネクションが長時間使われなくて、Turso 側で勝手にクローズされていた。

db.py に reconnect() を追加して、各冊の冒頭で呼ぶ修正を入れた。

def reconnect():
    global _client
    if _client:
        _client.close()
    _client = create_client(...)  # 新しい接続を張り直す

PID を新しく取り直して再起動。再格納フェーズ（既に DB に入っていた4冊分の差分埋め）が30〜57秒/冊で流れ、続けて残り5冊の本格処理に入った。03（リース・税効果）6分19秒、06（連結2）7分29秒、08（企業結合）7分55秒、01（金融商品・外貨）7分46秒、05（本支店・連結1）が最後。11冊全部の取り込みが13:11頃に完了した。

restructure 11冊：subagent並列でWALロック頻発、HTTP直接接続に切り替え

取り込みが終わった次は章節整理（restructure）。yomitoku がページ単位で切ったチャンクを、目次に沿って節レベルに統合する処理を11冊全部に流す。最初は subagent を11並列で起動した。Embedded Replica の WAL ファイルが14MB残ったままロックされ、復旧に時間がかかる事象が頻発。subagent が起動した Python subprocess が完了通知後も残って DB ロックを保持していた。

WAL 復旧のコストが大きすぎたので、アプローチを変えた。restructure コマンドの中身を HTTP 直接接続版に書き換え、subagent も Embedded Replica を経由せず直接 Turso の HTTP API を叩く形にした。9冊を subagent で順次起動し直す（並列ではなく直列）。

その前に、Tursoのバックアップを取ってから restructure を流すことにした。turso-replicas/scripts/backup_turso.py を見つけて実行し、backups/2026-04-30/ に books 43行 + chunks 6,500行を CSV で保存。

ここから9冊を直列で回した。各冊の削減量は以下：

04 負債・純資産: 229→63（166削除）
02 棚卸・固定資産: 224→69（155削除）
10 商品売買: 285→56（229削除）
07 連結3: 277→80
03 リース・税効果: 302→85
06 連結2: 321→114
08 企業結合・事業分離: 334→51（283削除、第4章II分離元企業46チャンクを1セクションに統合）
01 金融商品・外貨: 385→107
05 本支店・連結1: 423→（最大冊）

11冊で約70%チャンク削減（3,167→約1,000セクション）。

shelf 0冊問題：fetch_status='manual_register' でNULL除外を免除

DB 格納が終わったので、/shelf ページで TAC 教材11冊が並んでいるか確認しに行ったら、「コンテンツ: 公認会計士試験」chip をクリックしても表示0冊になっていた。

library.get.ts の絞り込みロジックを読むと、「★以上 4.0 / レビュー5件以上」のフィルタが入っていた。TAC 教材は star_rating も review_count も NULL なので、このフィルタで全部除外されていた。

fetch_status='manual_register' で識別して、星評価フィルタを免除する条件分岐を入れた。手動登録した本は星評価のしきい値を見ない、という運用ルール。修正後、Chrome DevTools MCP で /shelf を開いて11冊全部の表示を確認した。

連結タグの集計確認とM&A・組織再編タグの追加

ユーザーから「連結会計の本が全部『連結』タグで集計されているか確認してほしい」と言われた。shelf で「連結」chip をクリックすると現状13冊。タイトルに「連結」を含むがタグが付いていない本を抽出すると22件出てきた。分類して、明らかに連結会計の本にタグを追加。

合わせて、関連書籍として「M&A」タグ10冊、「組織再編」タグ7冊を新規にコンテンツ軸へ追加した。No834 のように両方付く本もある。

最後に shelf でスクリーンショットを撮って、11冊全部に 緑「済」バッジ + 青「📖 DB」バッジ が並んでいるのを確認した。コンテンツ chips にも「M&A 10」「組織再編 7」が並んだ。

教訓：restructure は HTTP 直接接続で動かす

このセッションの最大の学びは、/restructure-book コマンドは subagent 経由の Embedded Replica より HTTP 直接接続のほうが安定すること。subagent が起動した Python subprocess は完了通知後も生き残り、WAL ロックを持ったまま離さない。WAL 復旧のたびにレプリカ作り直しが必要になり、コストが大きすぎる。

教訓は /restructure-book スキルの md に追記した。今後 restructure を流すときは、subagent 経由ではなく HTTP 直接接続版のスクリプトを直接動かす。

明日は CAPTCHA で取れなかった著者94件の再取得と、残りの公認会計士テキスト16冊（【計算】シリーズ以外）の取り込み判断から入る。