毎朝の日記生成と決算データ取り込みを1コマンドで回した記録

毎朝の /make-diary を「日記を書くだけのコマンド」から「日記生成 → 決算データ取り込み → 決算ビートのXサーチまで一気に回るパイプライン」に育てた、その初日の記録。 コマンドを叩いてコーヒーを淹れて戻ってくると、前日の日記6本と統合日記、タイムラインのPNG、Xポスト案5個、そして3銘柄ぶんの決算スナップショットがTursoに積まれている。ここまで1本のコマンドで通るようにした。

主役はあくまで自分で、AIは実行係。「どう分けるか」「どこを公開記事にするか」を決めるのが自分の仕事で、手を動かすのはサブエージェントに任せた。

1. 前日(2026-05-28)の日記を生成する

まず /make-diary を引数なしで実行して、前日ぶんの日記を作らせた。 syncログを読むと、前日は9セッション動いていた。これを内容で8カテゴリに切り分ける。プロジェクト本体の作業、財務データまわり、決算記事、自動化スクリプト、家族の予定メモ……と性質がバラバラなので、1本の記事に押し込むと読み返したときに何も思い出せない。だからカテゴリごとに記事を分ける。

切り分けが決まったら、file-editor サブエージェントを並列で派遣して詳細記事を一気に書かせた。

• 詳細記事6本（カテゴリ別）
• 統合日記1本（各記事へのリンク + 試行錯誤テーブル）
• タイムラインPNG 1枚

並列で投げると、1本ずつ直列に書かせるより体感で待ち時間が3分の1くらいに縮む。各エージェントには「100〜200行」「サービス名・書籍名は匿名化」「主語は本人」のルールを毎回渡す。ここを渡し忘れると、AIが主役の文章が混ざってきて後から書き直すはめになる。

タイムラインは generate-timeline-full.mjs にその日の日付を渡して生成させた。セッションのJSONLを読んでPlaywrightで色帯のPNGをレンダリングする仕組みで、プロジェクトごとに何時から何時まで触っていたかが横帯で一目で分かる。

2. pathリンターを通す

記事を全部書き終えたら、update-paths.mjs --check でpathの整合性を検証した。

node scripts/update-paths.mjs --check

このリンターは「path未設定の記事がないか」「同じpathが2つの記事に振られていないか」「予約語と衝突していないか」を見る。今回は 1110ファイルをスキャンして1110ファイルそのまま通過。新しく足した日記記事のpathが既存とぶつかっていないことを、件数が前後しないことで確認できた。

毎日記事が増えていくので、ここで重複を弾いておかないとビルド時にZodの手前で事故る。リンターが赤くならないことを毎朝の合言葉にしている。

3. ブラウザで実際の見た目を確認する

リンターが緑になっても、それは「pathが整合している」だけで「ちゃんと表示される」保証ではない。Dev ServerとデバッグChromeを並列で立ち上げて、自分の目で確認した。

• Dev Serverが200を返すまで待つ
• 統合日記ページを開いてファーストビューをスクリーンショット
• ページ最下部までスクロールして、試行錯誤テーブルと関連記事リンクが崩れていないか確認
• 詳細記事も1本だけ抜き打ちで開いて表示を確認

特に見るのはタイムラインのPNGがちゃんと出ているか。画像パスを絶対パスで書くと本番で割れるので、./timeline-....png の相対パスになっているかを画面で見て確かめる。今回は統合日記・詳細記事ともにスクリーンショットで正常レンダリングを確認できた。Zodエラーの赤い画面も出なかった。

4. 税理士・会計士フォロワー向けのXポスト案を5個出す

日記が固まったところで、同じセッションログから税理士・会計士フォロワー向けの単文ポスト案を5個生成させた。これはコンソール出力のみで、公開記事には一切ファイルを作らない。content/ を汚すと日記サイトに混ざってしまうため。

ポスト案を作るときに毎回気をつけているのは、「自分がやったこと」と「AIがやったこと」を混ぜないこと。判断したのは自分、手を動かしたのはAI、という構図を崩すと嘘になる。あとは280文字以内・ハッシュタグなし・AI臭い言い回し禁止のいつものルールで5個揃えた。

5. /check-earnings をチェーンで実行する

ここからが今回パイプラインに繋いだ後半。日記が終わったら、間を置かずに /check-earnings の手順をそのまま流した。

半導体3銘柄（NVDA / MU / SNDK）の市場コンセンサス予想を、クラウド財務データサービスの内部APIから取得する。手順8で立ち上げ済みのデバッグChromeをそのまま使い、銘柄ごとに内部APIのレスポンスを一時JSONに書き出した。

uv run python scripts/check_earnings.py --skip-koyfin --date 2026-05-29

書き出したJSONを取り込みスクリプトに流して、Tursoの consensus_estimates テーブルに snapshot_date=2026-05-29 でUPSERT。ここで日付を間違えやすい。日記は前日(2026-05-28)を書いているのに、決算スナップショットは当日基準で積む。/make-diary の前日感覚を引きずって前日の日付を渡すと、別日のデータを上書きしかねない。今日の日付を渡すこと、と毎回自分に言い聞かせる。

3銘柄ぶんのUPSERTが通ったあと、SEC EDGARの8-Kチェックと前日との差分計算を並列で走らせた。新規の8-Kが無くてもexit 0で抜けて、最後にサマリまで到達させる。途中で1銘柄こけても全部止めず、揃ったぶんだけ流して残りは翌日に持ち越せる設計にしてある。

6. earnings-beat-scan を回して「公開記事として保存」する運用に切り替えた

最後に、3銘柄以外の米国上場企業で「ガイダンスがコンセンサスを5〜10%以上上回った銘柄」を earnings-beat-scan スキルで洗い出した。中身はXサーチ（Grok経由）で過去24時間の決算発表を引いてくる。

ここで前日決算の継続言及を拾ってしまうと、もう織り込み済みの古いニュースを「今朝のビート」として誤報する事故が起きる。過去にそれをやらかしているので、決算カレンダーの投稿で発表日ゲートをかけた。具体的には、決算カレンダー系アカウントの投稿で「2026-05-28引け後cohort」を確認し、その窓に入っている銘柄だけを残す。窓の外の言及は問答無用で捨てる。

今回からの運用変更: これまで earnings-beat-scan の結果はコンソール出力だけで消えていた。今日からは結果を 公開記事 earnings-beats として保存することにした。サマリのテーブルと、ガイダンスをレイズした銘柄の詳細セクションを記事に落とす。毎朝の決算ビートが日記サイトに残っていけば、後から「あのときどの銘柄がレイズしたか」を遡れる。0件の朝は記事を作らず、コンソールに1行だけ出して終わる。

数値はGrokの要約なので、最終確認は各社IRの決算リリース本文で取る、という但し書きを記事末尾に必ず添える。ここを抜くと、要約の丸めた数字を一次情報のように扱ってしまう。

今日の試行錯誤

今日の学び

• 日記生成・Xポスト案・決算取り込み・決算ビートを1コマンドのチェーンに繋ぐと、朝の作業がコマンド1本に圧縮された。判断だけ自分がやって、実行はサブエージェントとスクリプトに丸ごと回せる
• サブエージェントを並列で派遣するときは、毎回「主語は本人」「匿名化ルール」「行数の上限」を指示に同梱しないと、後で書き直す手間が発生する。指示テンプレを固定しておくのが効く
• 同じパイプラインの中でも、日記は前日・決算は当日と基準日が違う。1本のコマンドにまとめたことで、かえって日付の取り違えが起きやすくなった。当日の日付を渡す箇所をコメントで明示しておく
• 決算ビートのような外部要約は、発表日ゲートと一次情報の但し書きをセットにしないと、古いニュースや丸めた数字をそのまま流してしまう

明日やること

• 決算スナップショットの取り込みで、特定銘柄だけ認証切れでこけたときに残りを確実に流せているか、翌朝のログで確認する
• earnings-beats 記事の発表日ゲートが効いているか、窓外銘柄が混ざっていないかを生成直後にざっと目視チェックするstep を運用に足す
• サブエージェントへの指示テンプレを1ファイルに切り出して、毎回コピペせず参照で済むようにする

関連記事

• 2026-05-28 引け後の米国決算ビート速報