1週間止まっていた統計チェーンを取り戻す。make-diary が macOS で Step 9〜12 をスキップしていた

毎朝 /make-diary は回していた。 Mac で。 だから統計も一緒に入っているものだと思っていた。

ただ、Mac の Chrome には Koyfin のログインセッションがない。 株価の取得に使っている拡張機能も入れていない。 その1週間、Windows PC は一度も開かなかった。

今朝は久しぶりに Windows で回した。 それでも引っかかるものが残ったので、統計情報の更新がちゃんと行われているかを確認させた。

統計チェーン（Step 9〜12）は 8/1〜8/3 で止まっていた。 今日実行した /make-diary でも走っていない。

なぜ止まっていたのか

/make-diary の手順書には、8/4 に自分で書き足した但し書きがある。

macOS で実行する場合、Step 1.5 と Step 9〜12 は丸ごとスキップする

Koyfin のブラウザ取得も、各国統計サイトのスクリプトも、Google Sheets 連携も、Windows 機で組んだ経路に乗っている。 macOS で順に試せば、失敗の切り分けだけで朝が終わる。 だから飛ばして「決算・統計チェーン: SKIP（macOS のため）」の1行だけを報告させる形にした。

判断そのものは今も間違っていないと思う。 落としていたのは、飛ばした分が積み上がっていくことに気づく仕組みのほうだ。 毎朝あの1行を読んでいたのに、それが7回並んだ状態を一度も想像しなかった。

取り戻せたものと、もう戻らないもの

止まっていた分を、取れる順に取りに行かせた。

メモリ価格は 8/7 の1日だけ拾えた。 8/3 から 8/6 までの4営業日は、無料枠の仕様で永久に欠測になる。 取り戻す作業のなかで、これだけは取り戻せない側だった。

台湾ODM の月次売上は 7月分が入り、30銘柄ぶんの TS を再生成した。 台湾MOF の総輸出も 7月分（$75,298M、前年比 +32.9%）が取れた。 チャートには反映されたのに、ページ本文には6月時点の文言が残っていた。 テストの最新月アサーションも6月のままで止まっていたので、両方を追随させた。 数字を入れるだけでは終わらず、その数字を説明している文とテストまで一緒に動かす必要がある。

Koyfin は74銘柄でバッチを回し、73銘柄が 200 で返ってきた。 Turso への取り込みも73銘柄すべて成功した（株価は 8/7 終値）。 そこから earningsDynamics と summaries と valuation を再生成した。

position-news は 8/6 と 8/7 の2セッション分を書かせた。 2日で SNDK が -10.2%、SKハイニックスが -14.8%。 MU の下げは SNDK の決算が波及したものと、Citi の目標株価引き下げだった。

ここまでを 22320686 でコミットした（122ファイル）。

エントリポイント判定の OS 差

同じ朝、position-news のスクリプトにも OS 違いの穴が見つかっていた。

エントリポイントの判定を import.meta.url === 'file://' + process.argv[1] で書いていた。 Windows のパスは C:\... から始まるので、この比較は絶対に一致しない。 main() が呼ばれないまま exit 0 で終わり、株価取得は空の JSON を吐いていた。 エラーは出ない。終了コードも 0 になる。

pathToFileURL による判定へ3スクリプトとも置き換えた（98bff975）。 macOS では従来どおり動いていたので、Mac だけを使っていた1週間は表に出なかった。

新Q検知が挙げた15銘柄の中身

新Q検知は15銘柄を挙げてきた。 その結果をそのまま信じさせず、先に既存 JSON の中身を見させた。

内訳は割れた。 12銘柄は、先に入れておいた予測行に実績が入らないまま残っていたものだった。 残る3銘柄が、本当に新しい四半期の追加だった。 検知の件数は同じでも、手を動かす内容は「置き換え」と「追加」で別物になる。

15銘柄を直列で回させた。 途中で Grok が発表日を誤認したので、聞き方を変えて取り直させた。 AAOI と APP については、株価が動いた日から実際の発表日を逆算させ、検索期間を引き直させた。

終わったあとに Turso の report_date を見せてもらったら、15件とも null のままだった。 判明した実発表日を、period_ending が 2026-06-30 の行に限って入れさせた。 再生成後、新Q検知は 0 件になった。

ビートしたのにガイダンスで売られた回（SNDK、WDC、AMD、APP）と、素直に買われた回（PLTR +29.5%、PWR +17.3%）が混ざっていた。 91ファイルを 4addc5b7 でコミットした。

「韓国の統計は？」

一通り終わった報告を読んで、引っかかった。 更新したページは SNDK と position-news のデイリーと台湾だけなのか。 韓国の統計はどうなったのか。

聞き直して分かった。 その3ページは目で見て確認したページであって、データ更新が及んだページの全部ではなかった。 影響範囲を洗わせたら、韓国側に取りこぼしが1件出てきた。 PDF から取っている単価が1ヶ月遅れていた。

7月分の PDF は見つかった。 落としに行ったところで KDI が連続アクセスを弾いてきたので、そこで止めた。 時間を置いて取り直すこともできたが、今日は見送ることにした。

なぜ取りこぼしが起きるのか

なぜ取りこぼすのかを説明させたら、原因は 8/1 のコミット本文に書いてあった。

韓国の品目別（HSK別）月次は、관세청 が翌月15日頃まで公開しない。 8/1 に、その半月の空白を、証券会社リサーチが月末に X へ出す速報で埋める運用へ切り替えていた。 コミット本文の末尾にはこう書いてある。

15日頃の KCS 確報で確報値に置き換える（スキル Step 3.4 / 3.5 に手順を追記済み）

手順は書いてあった。 書き忘れではない。 ただ、その手順を起動する合図が「15日頃」という日付だった。 毎朝のチェーンが自分で条件を判定して拾いに行く形にはなっていない。 合図が日付である限り、その日に機械の前へ座っていなければ、宿題はそのまま通り過ぎる。

作業を必ずサブエージェントに投げて、その返答をメインのエージェント側でレビューする体制にすれば、この種の取りこぼしは拾えるのか。 そう提案してみたが、この日は原因を特定したところで止めた。

学び

• スキップを設計したら、スキップした回数が溜まっていくことに気づく仕組みを一緒に置く。1行の SKIP 報告は、7日分並べて初めて危険信号になる
• 遡れないデータ（TrendForce の無料公開ページ）と、後から取り直せるデータを分けて扱う。前者は開かなかった日がそのまま欠測として残る
• 「後で置き換える」という宿題を、日付だけを合図にして残さない。コミット本文に書いても手順書に書いても、実行のきっかけが人間の記憶なら落ちる
• 新Q検知のような検知結果は、件数を見て動く前に中身を見る。今回は15件のうち12件が「置き換え」で、3件だけが「追加」だった
• 終了コード 0 を成功と読まない。Windows のエントリポイント判定は、main() を呼ばずに正常終了していた