2026年5月10日の開発日記

今日は eurekapu-nuxt4 の Cloudflare Pages SSG ビルドが3日連続で赤くなっていた OOM を、Codex の再帰レビューを挟みながら Excel 教材データ分離で根本対応した。並行して book-knowledge-base 側では yomitoku で書籍を1冊 Markdown 化して Turso DB に放り込み、957件の蔵書すべてから奥付情報を抽出するパイプラインの計画も Codex レビュー2周で固めた。終盤は財務諸表読み方教材の図解インベントリ計画まで進めて1日が終わった。

今日のタイムライン

今日やったこと

1. Cloudflare Pages SSG の OOM を Excel 教材データ分離で根本対応

5/7 から赤くなり続けていた SSG ビルド OOM の原因が、allMillerChapters.ts 等から教材全文を直 import している箇所だと Codex に指摘してもらい、Phase 1〜7 で TS 直 import を JSON fetch に切り替えた。top.vue の manifest は 490KB → 18KB（3.7%） まで縮み、10コース分616KBが public/ 配信に分離された。途中で SSR から fetch が 404 になる罠を踏んだが、server/api/content/excel/[...].ts 経由で static asset binding を読む方式に切り替えて突破。

主な成果:

• Phase 1: excelBasicFunctionsNarration.ts の JSON 化
• Phase 3: top.vue の軽量 manifest 化（490KB → 18KB）
• Phase 4: no-restricted-imports で再発防止 lint
• Phase 5: MillerViewerLoader.vue 新設（ラッパー方式でリスク最小）
• Phase 7: 10コース全部 JSON 化（616KB 分離）
• SSR 404 問題を server API 経由方式で解決
• Codex CLI の Windows サンドボックスエラーも [windows] sandbox = "unelevated" で根本解決

詳細: Cloudflare Pages SSG の OOM を Excel 教材データ分離で根本対応した話

2. yomitokuで書籍PDFをMarkdown化してTurso DBに格納

/yomitoku スラッシュコマンドで199ページの実務書を日本語特化AI OCRに通し、Markdownと170枚の図を抽出して Turso DB に格納した。amazon_metadata との紐付けも自動で成功し、書籍内の任意の論点を AI に問い合わせられる状態まで持っていけた。

主な成果:

• 199ページの実務書を Markdown 化（バックグラウンド実行で他作業と並列）
• 図170枚を抽出してリネーム
• Turso DB に格納成功
• amazon_metadata と自動紐付け成功
• 検索テストで動作確認

詳細: yomitokuで書籍PDFをMarkdown化してTurso DBに格納する

3. 蔵書957件の奥付情報抽出パイプラインの計画策定

Dropbox 配下の「00連番で管理するフォルダ」にある書籍PDF 957件から、奥付（版・刷・発行日・出版社・著者・ISBN・定価・印刷所など22項目）を一括抽出して Turso DB に格納するパイプラインの計画を立てた。Codex レビュー2周＋筆者からの「コスト変じゃない？」指摘で計画 v3 まで磨いた。

主な成果:

• 計画書 v3 を Codex レビュー通過まで持っていった
• DB スキーマ 008_book_colophons.sql 作成
• スキーマ適用スクリプト scripts/apply_colophon_schema.py 作成
• Phase 1 対象10件のリスト確定
• Anthropic API 直叩きを止めて Claude Code 内完結（追加API課金ゼロ）に修正

詳細: 蔵書957件の奥付情報を一括でDBに入れる抽出パイプラインの計画策定

4. 財務諸表読み方教材の図解インベントリ計画

Turso DB に既に格納済みの決算書解説書（188チャンク）をベースに財務諸表読み方教材を新設する計画を立てた。著作権配慮で書籍そのままはNGなので、170枚の図のインベントリ→既存サイトとの突き合わせ→PASS/AUGMENT/NEW判定→着手、の3段階フローに決めた。当初はOCRデータから自動判定する設計だったが、筆者の指示で「PDFを199ページ直接精査する」方針に切り替えた。

主な成果:

• memo/2026-05-10/zaimu-shohyo-yomikata-plan.md に計画書保存
• 配置先 /lessons/zaimu-shohyo-yomikata/ 確定
• 図のSVG化先行 → 判定後に教材本文着手のフロー合意
• 明日は「PDF所在の特定 → 20ページ×10バッチでの精査」から再開

詳細: 財務諸表読み方教材の図解インベントリ計画

5. PR #18 のレビューとスクワッシュマージ

cockpit モーダルズーム下で「ピル飛行」と「ガイド点線」のずれを直す PR #18 を独立レビューし、コード自体は問題なしと確認した。CI が落ちていたが原因は main 側の OOM（上記1番）なので、グリーン化を諦めてスクワッシュマージで終了した。

今日の試行錯誤

ログから拾った試行錯誤の主な周回を並べる。

今日の学び

• 「データがあるから使う」と「データの質を見て判断する」は別物。OCR で取得済み170枚あるからといってインベントリ材料に使うと、後で品質に足を引っ張られる。199ページなら直接見られる、と筆者がスケール感覚で判断した
• Codex 再帰レビューは「致命的指摘ゼロ」になるまで回すと計画が立つ。今日は奥付抽出計画で2周＋筆者指摘1回、Excel 分離計画で3周。クソリプ防止指示（「瑣末な点へのクソリプはしないで」）が効いた
• AI 同士のレビューでも「ビジネスの臭い」は人間しか嗅げない。「Codex がOK出した計画でも、コスト見積もりが筆者にはおかしく見える」のように、判断軸を持っているのは人間
• 「OOM 再発」と思い込んだら詳細ログを見直す。Build は通っていて Stripe webhook テスト失敗で落ちていた。応急処置（NODE_OPTIONS=6144）を push したのは反省点
• 新規 server routes は HMR で取り込めない。Nitro が起動時にスキャンするため、dev server の再起動が必要というハマりポイントを今日見つけた
• 計画書に Phase 1〜7 を書いておくと、その日のうちに動くところまで通せる。ラッパー方式（MillerViewerLoader）で既存コードへのリスクを最小化したのも効いた

明日やること

• book-knowledge-base: Phase 0 のスキーマ適用 → Phase 1 の画像化（10件×末尾5ページ＝約50枚）→ サブエージェント並列で奥付抽出
• eurekapu-nuxt4: NODE_OPTIONS=6144 の延命策を外す検討、Stripe webhook テストの修正
• eurekapu-nuxt4: 財務諸表読み方教材 — PDF所在の特定 → 20ページ×10バッチでの精査開始
• eurekapu-nuxt4: Loader の SSR キャッシュ戦略の整理（dev/prod 差異）

関連記事

• Cloudflare Pages SSG の OOM を Excel 教材データ分離で根本対応した話
• yomitokuで書籍PDFをMarkdown化してTurso DBに格納する
• 蔵書957件の奥付情報を一括でDBに入れる抽出パイプラインの計画策定
• 財務諸表読み方教材の図解インベントリ計画