「アナリスト予想を時系列にスクラブできるページが mdx-playground のどこかにあったはず」と思い出して探し始めたら、最終的に 別リポジトリの React + Vite PoC だったというオチに辿り着いた。ついでに起動時のエラー2件を掘り当てて半分だけ直し、半端な編集でアプリを壊さないように残りを明日への積み残しにした。
きっかけ: 「あのページ」が思い出せない
朝イチで Claude Code に投げた質問はこうだった。
確かアナリスト予想を毎日取ってるじゃないですか。それを表現するコンテンツのレイアウトって、確かどっかにあったと思うんですけど、ページでね。進捗のスライダーバーを動かすことで、次の四半期までの決算におけるアナリストの予想がどう変化するかみたいなチャート。どこにありましたっけ?
スライダーバーで時系列を動かすと、Koyfin が日次で出しているコンセンサスの数字がチャート上でぬるぬる変化する、そんな見た目だったはず。それがどこにあったか思い出せない。
探索1回目: mdx-playground 内を一通り当たって全滅
Claude Code に候補を出させた。
/financial-quiz/nvidia-eps-forecastの感応度分析パラメータ/beat-monitoring/MUの決算サプライズ表eac-light系の earnings dynamics 風コンポーネント
pnpm dev で立ち上がっている localhost:3000 を Chrome DevTools MCP で開いて、両方とも実物を確認させた。が、どれも違う。感応度分析は売上成長率と粗利のスライダーで EPS を逆算するやつだし、beat-monitoring/MU は直近8四半期のサプライズ表で、時系列スクラブ要素はない。
ここで Claude Code が「徹底的に探した結果、mdx-playground には存在しません」と断言してきた。が、自分の記憶では絶対に見ている。
いや、私見たんですよ、本当に。どっかあると思うんですけどね。ちゃんとディープリサーチして。
探索2回目: 並列サブエージェントを派遣したら別リポから出てきた
並列でサブエージェントを起動して、C:\Users\numbe\Git_repo\ 配下の他リポも含めて広く探させた。
結果、C:\Users\numbe\Git_repo\earnings-dynamics-poc\ という別リポジトリの React + Vite PoC として存在していた。mdx-playground 側を何度grepしても出てくるわけがなかった。
構成はざっくりこう。
- 監視銘柄: 30件
- データ供給: Koyfin → Turso DB
- UI: React + Vite
- API: Cloudflare Worker(
/api/tickers等) - 体験: 進捗バーで決算発表日直後(左端)〜次の決算発表日(右端)の3ヶ月を時系列スクラブし、アナリスト予想の日次変化を見る
5月末あたりに勢いで切り出した PoC で、mdx-playground の「思いつきページ置き場」のノリで作ったまま、置き場所ごと記憶から抜け落ちていた格好。思い出しにくい場所に分けた個人ツールは、最初から探索範囲に別リポを含めないとまず見つからない、というのが今日の最大の収穫だった。
バグ1: Vite の SPA fallback が API レスポンスを乗っ取っていた
PoC リポを開いて localhost:5173 を叩いたら、画面に赤字で出た。
監視銘柄 読み込みエラー: Unexpected token '<', "<!doctype "... is not valid JSON
JSON が来るはずのところに <!doctype html> が返ってきている、見覚えのあるやつ。Chrome DevTools の Network パネルで /api/tickers を確認させたら、レスポンスが text/html で index.html がそのまま返ってきていた。
原因
Vite の dev server は、登録されていないパスを SPA fallback で index.html に流す。API(Cloudflare Worker 側)と dev server を別ポートで動かす構成にしていたのに、vite.config.ts に /api を Worker 側へ転送する proxy が入っていなかった。結果、API リクエストが全部 SPA fallback に飲まれて HTML が返り、フロント側で JSON parse が失敗する、というよくある形。
対処
vite.config.ts に /api を Worker のポートへ流す proxy を足してもらい、Worker も起動。リロードしたら 30銘柄の監視リストが描画されて、NVDA が初期選択された状態で時系列スクラブの UI が立ち上がった。これが探していた画面。「あった、これだ」となった瞬間。
バグ2: Micron の発表予定日が 2026-07-16 になっている
NVDA は普通に動いた。続けて Micron(MU)に切り替えたら、発表予定日が 2026-07-16 と表示された。
これは違う。MU の次の決算は FY26 Q3 で、本来は 2026-06 のいくつか(来週木曜)。1ヶ月ずれている。
原因
derivedReportDate の計算ロジックを Claude Code に追わせたら、根は DB 側にあった。
- Turso の
period_endingカラムに、未来分の値が 全部2026-06-18で潰れて入っていた - フロント側の
derivedReportDateは、そのperiod_endingに +28日して決算発表予定日を算出する作り - だから
2026-06-18 + 28日 = 2026-07-16が表示されていた
つまり「決算発表予定日が間違っている」のではなく、その手前の「四半期末日が間違っている」のが本丸だった。
対処方針(半分だけ手を入れて止めた)
MU は8月決算なので、本来 FY26 Q3 末は 2026-05-31。fiscal_year_end_month から会計年度ベースで Q1〜Q4 の末日を逆算する方式に直すのが正しい。
ただし period_ending を直すと、それを参照している既存ロジック(過去の実績表示・チャート軸・各銘柄のメタ表)が連鎖で崩れる可能性が高い。NVDA が綺麗に出ている状態を壊したくない。
ここで一旦止めて、「整合する範囲の修正だけ入れて、残りは明日への積み残しに回す」と決めた。
明日への積み残しメモ
memo/2026-06-20/earnings-dynamics-poc-to-mdx-playground-migration.md に、以下を書き残して今日は終了。
- 別リポにある PoC を mdx-playground の一画面として取り込むかどうかの方針判断
- 取り込むなら Turso のスキーマと既存の beat-monitoring DB をどう繋ぐか
period_endingをfiscal_year_end_monthから逆算する修正の手順と、影響範囲のチェックリスト- MU 以外の8月決算・3月決算・12月決算銘柄も同じ症状を踏んでいないかの確認項目
学び
- 思い出しにくい場所に置いた個人ツールは別リポでも探索範囲に入れる: mdx-playground 内だけ grep していてもゼロ件しか出ない。並列サブエージェントに
Git_repo全体を当たらせて初めて見つかった。次に「あのページどこだっけ」が来たら、最初から横断探索を頼む - DBの未来日付が潰れていると、report日逆算ロジックを巻き添えで壊す: 表示側のロジックを疑う前に、データ側の値を一度目視で確認する癖をつける。今回も
derivedReportDateの式を追う前に DB のperiod_endingを見ていれば、5分で当たれた - Vite dev server で
/apiを Worker に流す proxy 設定は、PoC でも初手で入れる: 「SPA fallback で HTML が JSON を上書きする」のは何度も踏んでいる。テンプレ化しておく - NVDA が動いている画面を壊さない判断を優先する: 全銘柄を直したくなる気持ちはあったが、半端な修正で当日の動作画面が消えると次に開いたとき自分が困る。「整合する分だけ入れて積み残す」で正解だった