2026年6月26日の開発日記
今日は早朝6時から夜まで、金融データの自動更新パイプラインを「人間が画面の違和感を拾って AI が裏で直す」構図で何往復もした1日。Micron Q4 FY26 のガイダンスチャートが1個ズレていた、earnings-dynamics の Focus Quarter ボタンが消えていた、beat-monitoring にハイパースケーラー枠を作りたい、hyperscaler-capex ページに営業CF を並べたい、税務系の実務書 19冊の restructure が残っている、公開GTFS API の仕組みを記事化したい──すべてユーザーからの依頼で始まり、AI が実装を回し、画面の違和感で軌道修正する、を繰り返した。
今日のタイムライン
今日やったこと
1. Micron Q4 FY26 ガイダンスチャート修正 + Focus Quarter ボタン復活
朝の /make-diary で Koyfin の auth_token を document.cookie 経由で取り直し、33 銘柄一括取得に成功。Micron Q3 ビートを受けたコンセンサスの大幅上方修正（FY29 EPS +262%）を Turso まで流し込んだあと、update-triple-beat-consensus.mjs を新規作成して beat-monitoring の forecast 四半期コンセンサスを Turso から自動上書きするようにした。
最初の全置換実装にバグがあり、Q3 FY26 の実績まで書き換えてしまった。ユーザーが「これ1個ずれてる」とスクショで指摘してくれて、forecast 行に範囲を限定する修正に切り替えた。さらに earnings-dynamics/MU の Focus Quarter Q4 FY26 ボタンが消えていた問題は、Turso eac_periods.report_date が null で period_ending + 28日 = 2026-06-28 に算出されていて、実発表日 2026-06-24 と 4日ズレていたのが原因。Turso を直接 UPDATE で実発表日に上書きしたら次Q ボタンが戻った。
主な成果:
update-triple-beat-consensus.mjsを新規作成、make-diary Step 2.6 に組み込み- forecast 行限定スコープへの修正コミット
11619905 - Turso
eac_periods.report_date更新ステップを make-diary Step 10.5-3e に組み込み（コミットbe9deb9e、243b7122）
詳細: Micron Q4 FY26 ガイダンスの1Qズレ修正と earnings-dynamics の Focus Quarter ボタン復活
2. beat-monitoring にハイパースケーラー5社を独立 tier 追加
ユーザーから「beat-monitoring にハイパースケーラー枠を作って5社追加してほしい」と依頼。/add-ticker で順次叩こうとしたら、MSFT/AMZN/GOOGL/META は前日に登録済みで、AAPL のみ完全新規という予想外の状況。AAPL リサーチをサブエージェントに背景で投げ、並行で5社の Koyfin KID 解決と valuation 取込を一気に終わらせた。
「インデックスにハイパースケーラー枠を作って」の真意を取り違えて最初はセクター分割案で実装。「いや、tier 自体を新規追加してほしい」と再依頼があり、「ビート継続・成長期待」と「継続ウォッチ」の間に新 tier「ハイパースケーラー」を独立配置で着地。さらに MSFT の FY26 ガイドが n/a だった指摘から全 38 銘柄で consensus: "n/a" 109件 17ファイルを抽出、米国銘柄 65件を 3 並列サブエージェントで埋めた（採用率 89%、AXTI 小型株はXで言及不足のため見送り）。
主な成果:
- AAPL/MSFT/AMZN/GOOGL/META の5社を新tier「ハイパースケーラー」に集約
- サプライズ系チャートを全38銘柄から削除（
TripleBeatPctChart呼び出しごと） - MSFT 1件 / META 6件 / Agent A 17件 / Agent B 11件 / Agent C を並列で完走
詳細: beat-monitoring にハイパースケーラー5社を独立 tier 追加・コンセンサス n/a を x-search 並列で埋める
3. hyperscaler-capex ページに営業CF セクション追加 + Koyfin EAC パイプラインのバグ修正
ユーザーから外部分析チームの Google スプレッドシートを提示され「/memory-makers/hyperscaler-capex に営業CF も並べて」依頼。Koyfin の eac_quarterly メトリクスを Cash-from-Operations で取り、ページに OCF セクションと「CapEx / 営業CF 比率」テーブルを追加。
ただ DB が CY2025Q3 で止まっていたので、chrome-extension-kofyin の postMessage ブリッジ（window.__kofyin.runSingleDownload）で7社一括DL（約3分）。取り込んでも period_ending がズレる重大バグを発見：eac_tsv_to_sqlite.py が ["Fiscal Years", "Fiscal Quarters"] しか認識せず、CY（Calendar Year）ラベルを弾いていた。さらに get_or_create_eac_period が全社共有 period_label で ORCL の5月決算が他社に上書きされる二重バグ。スクリプト修正＋既存レコード削除＋CYラベル一括 UPDATE で MSFT の 1Q CY2026A = Mar-31-2026 = 46,679 が Koyfin 画像と一致。続きは進捗 memo に残して翌日へ。
主な成果:
- OCF セクション・CapEx/OCF 比率テーブル追加
eac_tsv_to_sqlite.pyの CY ラベル対応バグ修正- 7社の CY ラベル period_ending を正規のカレンダー末日に一括書き換え
詳細: hyperscaler-capex ページに営業CF セクション追加と Koyfin EAC 取り込みパイプラインの CY ラベルバグ修正
4. 公開GTFS API の設計を読み解いて記事化
ユーザーから api.transit.ls8h.com がなぜ認証不要で公開できているのか調査依頼。WebFetch が 403 で弾かれて r.jina.ai 経由＋OpenAPI 直取得にフォールバック。trkbt10 さんの個人プロジェクトで、(1) GET のみ・書き込みなし、(2) 配信元が公的 GTFS オープンデータ、(3) ライセンス表記をレスポンス本体に同梱、(4) CORS * でブラウザ直叩き設計、という4点で「公開を前提に作られた純粋なオープンデータ再配信レイヤー」だった。
ユーザーの追い質問（attribution の解決ポイント、作者の目的、オープンの方が楽な理由）が記事を完成させた。公開API＝危険ではなく「読み取り専用＋ライセンスをレスポンス同梱」で設計レベルで安全に出せる、という学びを別記事にメタ整理。
主な成果:
- 公開記事 transit-ls8h-api-public.md を完成
- メタ振り返り記事を別途作成
詳細: 公開GTFS API を読み解く — 認証不要で出せる設計のキモはレスポンス本体に attribution を載せること
5. 税務・会計の実務書を一気に OCR & リストラクチャー
朝6:17 から積み残しの実務書 11冊を yomitoku で順次 OCR → Turso DB 格納。小さい順（6MB → 59MB → ... → 最後に 361MB のリカバリ対象）でこなし、バックグラウンド OCR 中に次の本の表紙を画像化して書誌情報先取りで待ち時間ゼロ。最大級の 1131 ページ本は OCR 40分。
ユーザーから「リストラクチャー全部終わってない」指摘で、yomitoku（chunks 投入）と /restructure-book（目次整形・セクション統合）が別フェーズだと気付く。並列は SQLite WAL 衝突するため直列必須、パイロット1冊で 422 → 39 チャンクに整理して型を確立してから残り10冊。さらに 12:18 から第2弾で 19冊を subagent 5 並列（HTTP 直接接続でWAL回避）で完走。
主な成果:
- 朝の 11冊を OCR → restructure まで一気通貫、午後の追加 19冊（既存 OCR 済み）を restructure のみ実行
- WAL 衝突対策として subagent 並列は HTTP 経由に統一
詳細: 税務・会計の実務書を一気に OCR & リストラクチャーで Turso に取り込む
おまけ：SeekingAlpha とセキュリティレビュー2件
- 「SeekingAlpha で投資銀行アナリストの評価記事は見られる？」の問い → 結論「載っていない（セルサイドの生レポートは機関投資家向け有料配信が前提、外に出すと配信契約違反）。SeekingAlpha は個人投稿＋コンセンサス集計のプラットフォーム」
/security-reviewを2回実行。どちらも author-only memo（HTML翻訳メモ、auto-generated データファイルのタイムスタンプ更新）で脆弱性なし
今日の試行錯誤
| # | テーマ | 試したこと | 結果 | 気づき |
|---|---|---|---|---|
| 1 | MU Q4 FY26 コンセンサス自動更新 | 全置換でforecast/実績ともに書き換え | 失敗（Q3 FY26 実績が消えた） | スクリプトの置換スコープは forecast 行に限定する |
| 2 | earnings-dynamics MU の次Qボタン復活 | reportDate のフォールバック式を見直し | 原因特定（Turso null → +28日） | DB 側のソースを直で更新するのが本筋 |
| 3 | beat-monitoring index のハイパースケーラー枠 | セクター分割で実装 | やり直し（意図と違う） | tier 自体を新規追加 |
| 4 | Koyfin EAC 7社一括 DL | postMessage ブリッジで連続実行 | 成功（約3分） | DL ファイル名が fallback するので renamer 経由で正規化 |
| 5 | eac_tsv_to_sqlite.py への CY ラベル取り込み | TSV をそのまま流す | 弾かれた（FY ラベルのみ判定） | 200行目の判定リストに Calendar 系を追加 |
| 6 | 書籍リストラクチャー並列化 | subagent で並列実行 | SQLITE_BUSY が1件発生 | HTTP 経由ならWAL衝突を回避できる |
今日の学び
- 金融データの「自動・手動」の切り分けは早めに固定する — beat-monitoring の forecast 行コンセンサスは自動、過去四半期の point-in-time コンセンサスは手動。スクリプト側で「触ってよい行」を明示する設計にしておかないと、ユーザー指摘で踏み抜く
- DB のソースに null があれば、フォールバック式に頼らず元を埋める —
report_date算出をperiod_ending + 28日に頼ると 4日ズレで次Qボタンが消える。Turso 側を更新するのが恒久対処 - 公開API の「認証不要」は設計の組み合わせで安全に出せる — GET only / 配信元はオープンデータ / attribution をレスポンス本体に同梱 / CORS
*、の4点セットで読み取り専用の安全な公開ができる - SQLite WAL の並列衝突は接続レイヤで切り分ける — subagent 並列は HTTP 経由に揃えると安全。直接書き込みを subagent でやらない
明日やること
- hyperscaler-capex の CapEx / 営業CF 比率テーブルが3行しか出ない問題（AAPL/CRWV のFreeプラン制限による欠損）の判断
- tripleBeat の forecast 行コンセンサス自動更新で残った Samsung 系（000660/005930）の通貨ミスマッチ整理
関連記事
- Micron Q4 FY26 ガイダンスの1Qズレ修正と earnings-dynamics の Focus Quarter ボタン復活
- beat-monitoring にハイパースケーラー5社を独立 tier 追加・コンセンサス n/a を x-search 並列で埋める
- hyperscaler-capex ページに営業CF セクション追加と Koyfin EAC 取り込みパイプラインの CY ラベルバグ修正
- 公開GTFS API を読み解く — 認証不要で出せる設計のキモはレスポンス本体に attribution を載せること
- 税務・会計の実務書を一気に OCR & リストラクチャーで Turso に取り込む