2026年6月24日の開発日記

朝から両手にハンドルを持って走った一日。左手は mdx-playground の memory-makers（CXMT を独立 maker として追加して予測区切り付きチャートまで描画）、右手は book-knowledge-base（Kindle Cloud Reader 一括判定 → スクショ取込本ノイズ除去 → PDF 専門書 OCR を並列で回す）。「実装を走らせてから前提を疑い直す」という同じ動作を、両プロジェクトでそれぞれ違うかたちで踏み抜いた。

今日のタイムライン

今日やったこと

1. CXMT を memory-makers に独立 maker として追加

中国の DRAM 専業 CXMT を /memory-makers/makers に独立エントリとして加え、長鑫科技 IPO の招股说明书を一次資料として 4 期分のチャートを描画した。当初は「兆易創新（GigaDevice）の四半期報告書を経由すれば CXMT の売上が取れる」と踏んでいたが、リサーチサブエージェントが「兆易創新の長鑫科技持分は約 1.80% に過ぎず、联营企业ではなく『其他权益工具投资』として処理されている」と返してきて、その経路が成立しないと判明。一次資料を招股说明书に切り替え、兆易創新は本来の NAND/MCU/NOR メーカー位置に戻し、CXMT を独立 maker として登録し直した。

主な成果:

• apps/web/app/data/memory-makers/cxmtIpoFinancials.ts を新設、招股说明书ベースの財務データを整理
• GroupedBarChart.vue に forecastFromIndex prop を追加し、実績/予測をハッチパターン＋点線区切りで視覚分離
• 6 カテゴリ（2022〜2025 実績 + 2026 Q1 実績 + 2026 通年予測）を 1 枚に統合
• コミット 1a0a0c36

詳細: 中国DRAM最大手 CXMT を memory-makers に独立追加した話

2. 韓国半導体 旬報×品目別 拡張プランを「途中で見送る」判断

前日積み残しだった「韓国半導体旬報チャートを品目別に拡張」を進めた。重量チャート 5 本（DRAM/NAND/MCP/DRAMモジュール/SSD）の描画完了、テスト 17 件 pass、Chrome DevTools で目視確認まで進めて staging 直前まで持っていったところで、自分の頭に違和感が走った。「品目別って 10 日とか 20 日で取れないんじゃない？」。旬報粒度では月次までしか出ないので、重量チャートは月次にしかならず、旬報の精度では役立たない。重量チャート部分は revert、s10/s20 ヘルパとデータ整合性テストだけ残してコミット 5ab14bab。計画書を「Status: Closed」に書き換え、意思決定記録を別ファイルで残してコミット 808d49f7。

主な成果:

• 重量チャート実装を最後の最後で撤退
• s10/s20 ヘルパとテストだけ救出して commit
• 計画書 3 件を「Closed」「Deferred」状態に更新

詳細: 韓国半導体旬報の「品目別」拡張プランを途中で見送った話

3. Kindle Cloud Reader 対応判定を 438 件一括処理

蔵書 DB の未判定 ASIN 421 件 + 既判定 17 件、合計 438 件の Cloud Reader 対応判定を朝のうちに片付けた。Kindle Capturer 拡張のおかげで「ASIN: + 該当 ASIN がページに出る → cr-ok」と判定ロジックは確立できたが、22 件判定して cr-ok = 0 だったところで「これは判定ロジックがバグってるんじゃないか」と疑い、前日 cr-ok 確定で取込済みだった本の ASIN で当てて検証して OK と確認。42 件判定した時点で残り 396 件は実判定せず一括 cr-app-required タグ付けで完了させた（Claude Code の提案を承認した形）。Playwright + CDP で別プロセスからログイン済み Chrome のタブを掴むのは Chrome 136+ のセキュリティで不可と確認（Chrome 144+ の chrome://inspect 経由は別ルートとして残る）。

主な成果:

• 全 438 件判定完了（前日までの cr-ok 確定済みの少数を除き、今回新規判定した分は cr-ok = 0）
• bot 検出なしで約 8 秒/冊のペースを維持
• 「サンプル 42 件で母集団推定 → 残りは一括処理」の判断を採用

詳細: Kindle Cloud Reader 対応判定を 438 冊一括処理した話

4. Kindleスクショ取込本のノイズ一括除去 + Web UI のページ番号非表示

ito-modern-accounting-3rd の DB を Web UI でブラウジング中、「表紙が 1、はじめが 2、その次が 53」というページ番号に違和感を覚えた。Kindle Windows 版のスクショ取込本では page_number が PNG の連番にしかならず、紙の実ページとは無関係。source_path が kindle: で始まる本を判定式にして、Web UI 側でバッジを非表示にする hasMeaningfulPageNumbers computed を追加。

ついでに DB 側にも本文への書籍タイトル混入・ランニングヘッダー重複というノイズ問題があったので、52 冊全部を対象に独立 cleanup フェーズ（apply_kindle_noise_filter）を実装。最初は「Workflow で並列再 restructure」を計画していたが、既存の restructure 結果を活かす方が嬉しいので、行レベル削除 + section prefix の tags 移管だけする独立フェーズに方針変更。

主な成果:

• Web UI の [bookId]/[page].vue に判定 computed を追加
• 52 冊一括適用で累計 8,948 行 のノイズ削除
• 書籍タイトル 100% 混入だった 4 冊もすべてクリーン
• 2 コミットに分割（Web UI 改修 + ノイズフィルタ実装）

詳細: Kindleスクショ取込本 52 冊からノイズを一括除去した話

5. PDF 専門書の OCR 並列パイプライン（朝の 6 冊 + 夜の専門書追走）

朝のセッションで OCR 4 冊バックグラウンド起動 → DB 投入 → restructure サブエージェント 4 並列起動という定型を回した。夜のセッションでは「PDF の未取込書籍をレビュー数・評価順にリスト化して上から順に」と指示して、専門書を中心に取り込みを継続。/yomitoku をスキル化してあるので「次のパスはこれ」と渡すだけで OCR→Markdown→図表抽出→Turso 投入まで進む。並列度を上げすぎず、進捗確認しながら「いいきりのいいところでおしまい」とペースをコントロールした。

主な成果:

• 朝 6 冊の OCR / DB 投入 / restructure 完走（合計 983 chunks）
• 夜セッションでさらに専門書を上から順に追走
• 朝の定型ワークフローが夜の取り込みで活きた

詳細: PDF 専門書を yomitoku で並列 OCR 取り込みした話

今日の試行錯誤

今日の学び

• 実装を走らせてから前提を疑い直す動作は、AI に作業させる時代でも自分の係。重量チャートも CXMT も「動いてから気づいた」場面が複数回ある
• サブエージェント並列は「OCR バッチ → DB 投入 → restructure」のような独立ステージで威力を発揮する。並列度を上げすぎないこと、進捗確認を挟むことがコツ
• Web UI の違和感（意味のないページ番号）から DB 側のノイズ問題（タイトル混入）まで芋づる式に拾えた。読んでて気持ち悪いものを放置しない
• Chrome 149 (136+) のセキュリティで CDP 経由のバックグラウンド化はもう使えない。MCP メインで回す前提に頭を切り替える
• AI が提案してきた選択肢に「いいよ」と決めるのは自分の係。「サンプルから母集団推定して一括処理」のような統計的な打ち切り判断も、最終承認は人間

関連記事

• 中国DRAM最大手 CXMT を memory-makers に独立追加した話
• 韓国半導体旬報の「品目別」拡張プランを途中で見送った話
• Kindle Cloud Reader 対応判定を 438 冊一括処理した話
• Kindleスクショ取込本 52 冊からノイズを一括除去した話
• PDF 専門書を yomitoku で並列 OCR 取り込みした話