別のAIがOCRした書籍のSQLiteを蔵書DB（Turso）へ取り込む前のレビューと、Googleタスク33件の棚卸し

開発book-knowledge-base

別のAIがOCRした書籍のSQLiteを蔵書DB（Turso）へ取り込む前のレビューと、Googleタスク33件の棚卸し

朝、Google タスクに残っている未完了を数えてもらったら33件あった。 「実は終わっている」ものが何件か混ざっているはずだ、と思っていた。

実物と突き合わせた結果、消してよいと言えたのは1件だけだった。 昼前には、別の AI（ChatGPT 側の Codex）が OCR して作った1冊目の SQLite が届いた。 そして昼過ぎ、自分は要らない鍵を1本作らせかけている。

朝：Googleタスク33件の進み具合を実物で確かめる

Claude Code に gogcli スキルでタスクを読ませ、各タスクの計画書、コミット履歴、成果物と突き合わせてもらった。 リポジトリごとに4つに分け、エージェントを並列で走らせている。

グループ件数完了済み内訳
iOS / CI / SNS 系70CI は期日前、iOS の3件は未着手
財務諸表 / CF 系70一部完了4、未着手2、新しい計画に置き換わったと見られるもの1
Excel / Git / 別表系90一部完了5、未着手4
mdx-playground ほか10最後のまとめで報告

財務系の調査では、動画を「完了」にした記録の正本が本番の D1 にあった。 ただ、読み取りが自動の許可判定で止まったので、手元にある写し（10/12 と 10/14 時点）で判定してもらっている。

消してよいと言えた1件は、「書籍7冊の取り込み」だった。 ほかに、別のタスクや新しい計画に吸収されていて、まとめられるものが3件あった。 残りの多くは、自分が見る、聞く、決めるのを待っている。

そこで、自分の側でいくつか決めた。

  • 書籍の追加取り込み7冊は、一旦これで区切る
  • ステップ学習の14列の固定は OK
  • Apple アカウントはまだ作っていないので、作る手順を教えてもらう
  • キャッシュフロー教材の再開は、自分の確認で止まっているなら終了でいい

残り31件を一覧にした HTML を作らせ、Chrome で開いてもらった。 一覧を見て、自分の確認待ちが多いことに気づいた。 そこで「自分がやること」と「Claude がやること」の2列に分けて作り直してもらった。 自分の作業が絡むのは31件中30件で、Claude が待たずに着手できるのは13件だった。

PDFの読み解きをChatGPT側に任せるプロンプト

book-knowledge-base の PDF を優先度の順に読み解いて整え、目次を整理して再構成し、Turso に入れる。 この一連の流れは Claude Code のスキルになっているので、ChatGPT 側にもリポジトリのスキルを参照して流してもらうことにした。 気になったのは、.env の鍵や API キーが無いと Turso に入れられないかもしれない点だ。 Claude Code にスキルの手順と未取り込みの一覧を読ませ、制約を先に書いたプロンプトを出してもらった。

続けて、OCR の変換速度の記録が残っているかを探してもらった。 ChatGPT 側の環境で計測してもらっているので、それと比べたかった。 Windows の GPU と Mac の記録は残っていた。 Windows の CPU で測った記録は無かった（book-knowledge-base と OCR 用のリポジトリの両方を探した）。 手元の記録を基準値として入れ、測り方も指定した質問用のプロンプトを作ってもらった。

昼前：1冊目のSQLiteは、そのまま本番に入れてよいか

この時間帯の最初に、CPU だけで OCR を動かしたときの速度をルールファイルのメモに追記してもらった（ff4c733）。 GPU 環境の3〜5倍遅いが、CPU だけで動かした結果としては健闘している、という評価だった。

本題は、ChatGPT 側が1冊目を OCR して作ったステージング DB と handoff zip である。 「Turso に取り込むのは、ここからできるか」と聞いた。

zip を隔離した作業領域に展開させ、引き継ぎ書を読ませてから、本番の Turso と読み取りだけで照合してもらった。 答えは「そのまま入れられる」だった。 この時点では、本番には何も書き込んでいない。

入れられることと、中身が正しいことは別の話だ。 内容もレビューしてもらった。

  • 前付から奥付まで、構成はそろっている
  • 原本 PDF のハッシュは、引き継ぎ書に書かれた値と一致した（同じ PDF から OCR されている）
  • 6ページを画像にして原本と見比べた結果、中身はきちんと入っていて大きな問題はない
  • ただし、取り込むときに直したほうがいい細かい点が4つある

ここで2つ頼んだ。 次回以降の取り込みで気をつけてほしい要点を、Codex 向けのプロンプトにまとめること。 そして、本番 DB に入れてしまうこと。

既存の取り込み処理の書き方に合わせて4点を直させ、本番の Turso に入れてもらった。 画面でも、表のページが原本どおり2列で出ていることと、計算式のページが崩れていないことを確かめている。 表が2つ見えたのは、PC 用とモバイル用に同じ表を持つレイアウトのためで、モバイル側は隠れていた。

Codex 向けのプロンプトは6点にまとまった。 これを Codex に伝えた。 2冊目のステージングが届いたら、今回と同じ手順で見てもらう。 原本 PDF とハッシュを照合し、表と式と注記を確かめ、本番との重複を調べてから、1トランザクションで入れる。 6点が直っているかも、届いた時点で機械的に確かめられる。

devサーバーが止まりきらなかった

最後に dev サーバーを止めてもらったら、1回目はバックグラウンドのタスクだけが止まった。 ポート3100では、Nuxt 本体（nuxt dev の node プロセス）がまだ待ち受けていた。 中身が book-knowledge-base の Nuxt だと確かめてから、そのポートのプロセスだけを止めてもらった。

昼：登録済み400冊のCSVと、書き出しスクリプトのコミット

本番の Turso から、登録済みの400冊を読み取り専用で取り出し、UTF-8 の CSV にしてもらった。 途中でいくつか引っかかっている。

  • コマンドに直接書いたクエリがクォートで崩れたので、スクリプトをファイルに切り出した
  • 3冊は amazon_metadata 側の紐付けが2行あったので、GROUP_CONCAT で1行にまとめた
  • amazon_file_no に -1 や 10400 のような値があったので、意味を確かめた
  • 読み戻して、件数、項目ごとの埋まり具合、日本語の文字化けを確認した

スクリプトは scripts/export_books_csv.py として既存スクリプトの書き方に合わせて置き、コミットしてもらった（d361c0b）。 Codex のコミットレビューで critical / high の指摘は出ていない。 push はしていない。 docstring どおりの手順でもう一度動かして、先に作った CSV と中身が同じことを確かめ、確認用の2本目は削除した。

接続先URLを聞かれて、読み取り専用トークンを作りかけた

Codex から、蔵書の閲覧と検索の接続確認に使う Turso の接続先 URL を聞かれた。 どのファイルのどの値を貼ればいいのか、Claude Code に聞いた。

Claude Code には .env を読ませない決まりなので、Turso CLI から URL を取れるか試してもらったが、取れなかった。 自分で env ファイルを開けばいいので、ファイルの場所とどの値かだけ教えてもらった。

ここで「Turso って CLI があるのか」と気づき、そのまま頼んだ。 Mac に Turso CLI を入れて、読み取り専用のトークンを作ってほしい、と。

手順結果
Windows 機から SSH で Mac に入り、Homebrew で turso を入れる依存先の tap（libsql/sqld）を明示的に追加する必要があり、追加して入れ直した。v1.0.34 が入った
turso auth loginブラウザで承認する対話式の手順なので、Claude Code だけでは進められない
Mac 側の Claude Code に LAN 直送で依頼するmDNS 名が引けず、IP を探した。ホスト鍵の指紋が記録どおりなのを確かめてから送った

返信を待っているあいだに、「そもそも、このトークンは何のために作るんだっけ」と聞き直した。 答えは、Codex に蔵書 DB を読ませるための Codex 専用の鍵だった。 いま .env にある鍵をそのまま渡すのは危ないので、別に作ろうとしていた。

でも、Codex にはステージング用の SQLite を作ってもらえばいい。 本番に入れるのはこちらでやる。 それなら Codex に DB の鍵は要らないので、取りやめた。

Mac 側は、Turso へのログインまでは済んでいた。 トークンは作られていない。 作成コマンドが Mac 側の許可判定で止まっていて、実行されていなかった。 Mac から「取り消し完了」の返信が届き、何も残っていないことを確かめた。

夕方：DropboxのOCRバックアップから7冊を本番へ

Dropbox にある 2026-10-29 付の OCR バックアップを、Turso に取り込むよう頼んだ。

  • ローカルの Dropbox 同期フォルダに zip が11個あり、作業領域にコピーして中身を確かめた
  • 本番の Turso と、book_id、ISBN、書名、番号で重複を照合し、amazon_metadata の対応行も調べた。重複はゼロ
  • 全11冊で dry-run（書き込みなし）を流した
  • コピーした原本に対してハッシュを照合できるよう、取り込みスクリプトに --source-copy-dir オプションを足した
  • ハッシュは全冊一致し、競合も無かった

原書の確認待ちの1冊は外し、7冊を本番に入れることにした。 本体の INSERT のあと、amazon_metadata の紐付けで接続ストリームの競合が出たので、1冊の状態を確かめてもらった。 そのあと、冊ごとのチャンク数、種類、全文検索のヒット、全体の件数を検証している。 dev サーバーが落ちていたので起動したところで、このログは終わっている。 検証の結果までは、ログに残っていない。

朝に区切った「書籍の追加取り込み7冊」のタスクと、ここで入れた7冊が同じものかどうかも、このログの範囲では確かめていない。

学びメモ

  • 鍵を1本増やす前に、データの通り道を見直す。ステージングの SQLite を受け取ってこちらで入れる流れなら、相手に DB の鍵を渡す必要は無い。「何のために作るんだっけ」と聞き直したことで、トークン作りそのものが要らないと分かった
  • dev サーバーを止めたら、ポートで待ち受けが消えたかを確かめる。バックグラウンドのタスクを止めても、Nuxt 本体が残っていることがある

残っていること

  • 2冊目のステージングで、Codex に伝えた6点が直っているかを確かめる
  • ChatGPT 側で計測した OCR の速度を、Windows の GPU と Mac の記録と比べる
  • Apple アカウントを作る
  • 夕方に入れた7冊の検証結果を確かめる
#book-knowledge-base#Turso#SQLite#OCR#Googleタスク#Claude Code#Codex