元データと実行スナップショットを分離した収集構造

✨ GPT-5.5の要約 　

JSON・CSV・DuckDBの間で揺れていた基準データをPostgreSQLへ移しながら、元となるevidence、observation、基準データ、実行snapshot、納品用成果物を分離した記録。

JSON・CSV・DuckDBの間で基準データが揺れた

ここ数日、データ収集、検証、実行、納品のフローをセットアップしていると、いろいろな問題が次々に出てきた。やはり自分はDBをきちんと学んだことも扱ったこともないので、データの保存方式を頻繁に変え、そのたびに単なる置き換えでは済まなかった。

最初はデータをJSON/CSVで収集し、閲覧用にDuckDBを付けて確認していた。ところが、ワーカーの成果物とコーディネーターがDBを作り直し続ける構造が混ざり、何が原本データで何が基準データなのかがずっと揺れた。

そこでMySQLでDBを作るプランも立ててみた。ただ、問題はMySQLそのものというより、複数のワーカーやスクリプトが基準データを直接更新する構造だった。そのまま進めれば、同時update、衝突、所有権、ロールバックの問題が繰り返される可能性が高かった。

その後も別の方式を検討したが、核心は同じだった。収集データ、基準データ、実行データ、納品用成果物の境界が曖昧なら、結局同じ問題がまた起きる。

DB製品よりmutation ownershipが核心だった

PostgreSQLへ移したからといって、問題が勝手に解決するわけではなかった。どのDBを使うかより先に、誰が基準データを変更できるのかを決めなければならなかった。

ワーカーは原本evidenceとobservationをappend-onlyで残す。基準データは直接修正しない。コーディネーターがevidenceとobservationを検証した後、基準データと基準値を更新する。基準データを変更する責任を一か所に集めてこそ、衝突が起きたときに何を戻すべきかも追跡できた。

PostgreSQLの中で役割を分けた

そこで今日PostgreSQL DBへ移しながら、ここ数日セットアップしてきた全体の流れも一緒に整理した。すべてをDBという一つの塊として処理せず、役割を分けた。

• 元となるevidence
  • 公開情報から収集した根拠と元の値を保存する
  • 処理済みの値と状態は元データを上書きせず、別の履歴として残す
  • JSON/CSVファイルはevidence mirrorにはなり得るが、基準データではない
• observation
  • ワーカーは担当する収集チャネルの観測値だけをappend-only ledgerへ提出する
  • 発見と補強は別の役割として分ける
  • ワーカーは基準データを直接修正しない
• 基準データ
  • コーディネーターがevidenceとobservationを検証する
  • 検証済みの値だけを定めた構造に合わせて基準データへ反映する
  • viewは計算、検証、exportのための表面として使う
• 実行snapshot
  • 収集viewをそのまま実際の実行基準にはしない
  • 重複除去と品質ゲートを通過した対象を、ある時点のsnapshotとして固定する
  • 実行結果と除外・後続状態は基準データから分離して管理する
• 納品用成果物
  • CSV、Google Sheet、Excel、vox.ai向けのファイルは、基準データまたは実行snapshotから生成する
  • これらは表示または納品のための成果物である
  • 成果物を再び基準データのように修正しない

根拠から実行と納品まで追跡できるようになった

こうして、収集した根拠がどこに積まれ、ワーカーが何を残し、どの値が基準値になり、どのsnapshotが実際の実行に使われ、何が納品用成果物なのかを追跡できるフローが完成した。

もちろん、まだまだ足りない構造なので、これから触るべきところは多いだろう。引き続きテストし、フィードバックし、修正する中で、いろいろな大変動が起きるはずだ。そしてそうやってフローも、ハーネス構造も、自分の直感も全部発展していくのだろう。

自分のフローセットアップが、もしかしたら誰かの役に立つかもしれないと思い、共有してみる。