データシステムを動かす

同じ情報源を手で確認し続けていて、機械に任せたい段階です。読むのは自分だけなので、実行漏れは空白ができるだけで済みます。

自分のマシンでタイマー実行するスクリプトが、いくつかの情報源を取得し、実行ごとに日付付きのファイルを書きます。生の応答は整えた結果の隣に保存します。

地図上の形: 定期スクリプト → ファイル

情報源に最適なパーサーがある言語を使います。ページのスクレイピングより公式のフィードや API を優先します。壊れにくく、規約も明確です。

• Python取得・解析・ファイル書き込み
• Claude Code収集器を書き、パーサーを直す

• 実行ごとに取得件数を 1 行書く。0 件は成功ではなく警告です。
• 生の応答をいくつか保存し、パーサーを変えるたびにそれでテストする。

他の人がページを読み、ダイジェストを購読しています。ノート PC を閉じたらデータが欠ける、はもう許されず、間違った数字は他人を誤らせます。

スケジュールはホスト型の基盤へ移り、毎時収集器を動かしてデータベースに書き、公開ページを配信します。保存前にすべての項目を想定の形で検証し、実行ごとに自身の健全性を記録します。

地図上の形: ホスト型 cron + DB + サイト（レーダーの形）

スケジュール、データベース、サイトが同じ場所にある基盤を選びます。部品が少ないほど静かな故障も減ります。ジョブを設計する前に、1 回あたりの時間と CPU の上限を確認します。

• Cloudflare Workerscron、DB、公開サイト（レーダーはここで稼働）
• Wranglerスケジュール、マイグレーション、ライブログ
• Zod形の違うデータを拒否

• 入ってくる項目をすべてスキーマで検証し、合わないものは保存せず拒否して記録する。
• 公開ページのすべての数字の横に取得時刻を表示する。
• 情報源が 0 件を返したとき、または実行自体が起きなかったときに警告する。

読者は出力から判断を下し、購読者は支払うかもしれず、一部の情報源には利用規約や個人情報があります。間違った数字や漏れたフィールドには結果が伴います。

結論は情報源と日付とともに追記のみの台帳に入り、予測は期限が来るとコードで精算されます。生の応答は安価なストレージに保管し、情報源ごとの規約を記録し、個人データは保存前に除去します。

地図上の形: ホスト型 cron + DB + サイト（レーダーの形）

判断と記帳を分けます。分析はモデルが書いてもよいですが、予測が当たったかの精算は、誰でも再実行できる普通のコードでなければなりません。

• Cloudflare Workers台帳は DB、生のアーカイブはオブジェクトストレージ
• GitHub収集ロジックの変更はすべてレビュー

• 台帳の項目は決して編集しない。訂正は古い項目を指す新しい項目にする。
• 予測はモデルではなく決定的なコードで精算する。
• 汚染テストをする。キーや個人データを含む項目を流し込み、どれも DB に届かないことを確かめる。

数百の情報源が 1 回の時間制限に収まらず、毎時いくつかが失敗し、何年分の履歴に問いを投げたい人が現れました。

収集はキュー上の小さなジョブに分かれ、それぞれ個別に再試行でき、2 回動いても安全です。生のアーカイブが唯一の事実の源となり、分析層は手で直すのではなくそこから作り直します。

地図上の形: キューベースのパイプライン · データウェアハウス + 分析層

ウェアハウスより先にキューを入れます。多くのデータシステムは、DB 一つで答えられない問いより、ずっと先に 1 回の時間制限にぶつかります。

• Cloudflare Workersキューと並列取得
• GitHub再取得と再実行をレビュー付きジョブに

• すべてのジョブを冪等にし、再試行で重複が生まれないようにする。
• 派生テーブルはどれもコマンド一つで生アーカイブから作り直せるようにし、実際に練習する。
• 情報源ごとに鮮度を追い、古くなったら担当者に知らせる。