• #OCR
  • #yomitoku
  • #TursoDB
  • #書籍デジタル化
  • #会計基準
  • #バッチ処理
  • #Embedded-Replica
開発book-knowledge-baseメモ

yomitoku OCRで会計基準9冊589ページを一括処理しTurso DBに格納した手順

会計基準のPDF10冊をyomitoku OCRに通してTurso DBに流し込んだ。1冊は壊れたファイルで弾かれ、残り9冊・589ページをGPUで順次処理した。蔵書DBが19冊から28冊に増え、チャンク数が約3,200に達した。


処理対象の10冊

全て会計基準の公的文書PDF。yomitokuに渡す前にファイルの中身を確認したところ、1冊だけ問題が見つかった。

壊れたファイルの除外

40_圧縮記帳取扱い.pdf をyomitokuに通そうとしたら、OCRエンジンがPDFとして認識できなかった。バイナリの先頭を覗くと <!DOCTYPE html> で始まっていた。HTMLファイルが .pdf の拡張子で保存されていただけだった。このファイルは除外し、9冊で処理を進めた。

処理した9冊

#書籍名ページ数
1連結キャッシュ・フロー計算書等の作成に関する実務指針68
2外貨建取引等の会計処理に関する実務指針95
3資本連結実務指針88
4持分法に関する実務指針71
5金融商品会計に関する実務指針158
6特別目的会社を活用した不動産の流動化に係る譲渡人の会計処理に関する実務指針25
7連結財務諸表の用語、様式及び作成方法に関する規則ガイドライン14
8財務諸表等の用語、様式及び作成方法に関する規則ガイドライン42
9固定資産の減損に係る会計基準の設定に関する意見書28
合計589

金融商品実務指針の158ページが最も重く、連結財務諸表規則ガイドラインの14ページが最も軽い。ページ数の差は10倍以上あるが、yomitokuのGPU処理はページ単位で走るので、所要時間はほぼページ数に比例した。


OCR処理の流れ

yomitoku OCRの実行

9冊を1冊ずつ順次処理した。yomitokuはGPUを使うため、並列実行するとVRAMが溢れる。1冊の処理が終わるのを待ってから次を投入する流れで回した。

# 各PDFに対して順次実行
yomitoku ${PDF_PATH} -o ${OUTPUT_DIR} -f md --figure --figure_letter

出力はページごとのMarkdownファイルと、検出された図・表の画像ファイル。589ページ分のMarkdownが生成された。

process_yomitoku_book関数でDB格納

OCR出力のMarkdownをTurso DBに格納する処理は process_yomitoku_book 関数に集約されている。この関数は以下を一括で実行する。

  1. 指定ディレクトリ内のMarkdownファイルを読み込み
  2. ページ順にソートしてチャンクに分割
  3. Turso Embedded Replicaに直接INSERT

前回の記事で書いた「init_books_db を呼ばない」「db_path を渡さない」という学びが既にコードに反映されており、今回は一度もエラーに引っかからなかった。CLAUDE.mdに手順を書き残しておいた効果が出た。

# process_yomitoku_book がやっていること(概要)
conn = connect_turso()  # 環境変数からURL/トークンを取得
for chunk in split_into_chunks(markdown_pages):
    conn.execute("INSERT INTO book_chunks ...", [chunk])
conn.sync()  # Embedded Replica → クラウドDBに同期

conn.sync() を呼ぶと、ローカルのEmbedded Replicaに書き込んだデータがTursoのクラウドDBに反映される。turso-replicasリポジトリ側のレプリカDBも同期されるため、他のプロジェクトからも即座に新しい書籍データを検索できる。


9冊の処理結果

全9冊が同じパイプラインで処理できた。1冊ごとに process_yomitoku_book を呼び、conn.sync() でクラウドに同期する。この繰り返しを9回実行した。

PDF → yomitoku OCR → Markdown群
  → process_yomitoku_book → Turso Embedded Replica
    → conn.sync() → クラウドDB同期

特筆すべきトラブルは起きなかった。壊れたPDFを最初に弾けたことと、前回のセッションで学んだAPI変更がコードに反映済みだったことが大きい。


蔵書DBの更新状況

Before → After

項目BeforeAfter
登録冊数19冊28冊
チャンク数約2,300約3,200

CLAUDE.mdの蔵書情報も19冊から28冊に更新した。Claude Codeが蔵書DBを検索するとき、この数字を見て「どの程度のデータが入っているか」を把握する。

追加された9冊のカバー領域

今回追加した9冊は、連結会計・外貨建取引・金融商品・減損会計といった実務指針と規則ガイドラインをカバーしている。既存の19冊が主に企業会計基準と適用指針だったので、実務指針系の層が厚くなった。全文検索で「連結キャッシュ・フロー」「ヘッジ会計」「持分法」などの用語を引くと、対応するチャンクが返ってくる状態になった。


学んだこと

  • 壊れたPDFはバイナリの先頭で即判別できる: <!DOCTYPE html> で始まるファイルはHTMLが拡張子だけPDFになっている。yomitokuに通す前に file コマンドやヘッダ確認で弾けば、OCRエラーの原因調査に時間を取られない
  • 前回の学びをコードに焼き込んでおくと同じ罠を踏まない: 前回2セッション連続で引っかかったTurso APIの変更点が process_yomitoku_book に反映されていたため、今回は9冊を通して一度もAPI関連のエラーが出なかった
  • 589ページの順次処理はGPU律速: yomitokuのOCR処理時間はほぼページ数に比例する。並列化はVRAM制約で難しいが、1冊ずつ流せばメモリ管理を気にせず済む。バッチジョブとして放置できる粒度