【ITニュース解説】I track a public data registry from my terminal now — zero dependencies, one file

公開されているデータがいつの間にか変わっていることに気づかず、困った経験はないだろうか。Webサイトの企業リストに新しい企業が追加されたり、商品のオファーが静かに消えたり、評価のグレードが変わっていたりする状況だ。手元の情報がいつの間にか古くなり、問題が起きてから変化に気づくことが頻繁にある。このような課題に対し、ある開発者が非常にシンプルながらも強力な解決策を考案した。それが、公開されているデータレジストリ（データ集）の変更を追跡するためのツール「sourcey-tracker」だ。

このツールは、Pythonで書かれたたった一つのファイルで構成されており、外部のライブラリやフレームワークに全く依存していない。通常、Python開発ではpip installコマンドで様々なライブラリを追加するが、このツールはそういった手順が一切不要だ。仮想環境の準備もAPIキーも求められない。これは、Pythonに標準で備わっている機能だけで全てが実現されていることを意味する。

具体的に追跡対象となるのは、Sourceyというサービスが公開している三つのデータセットだ。これらはJSON（JavaScript Object Notation）という、人間にとっても機械にとっても読み書きしやすい形式のデータとして提供されている。例えば、企業リスト、スタートアップのクレジット情報、エージェントの準備状況を示す評価テーブルなどがある。これらのデータは、常に最新の状態が公開されており、その最新リリースにはデータの「指紋」のような役割を果たすSHA256ハッシュ値が付与されている点が重要だ。このハッシュ値があることで、「データを実際に目で見て確認する」のではなく、「データの中身がバイト単位で変化したことを数学的に証明する」という厳密な変更検知が可能になる。

開発された「sourcey-tracker」ツールは、いくつかの便利なコマンドを提供する。 statusコマンドを使えば、現在のレジストリのリリースIDや公開日時、各データセットに含まれるエンティティ（項目）の数をすぐに確認できる。 snapshotコマンドは、その時点でのデータセットを「スナップショット」としてローカルに保存する機能だ。このスナップショットは変更されない「不変の記録」であり、保存されたデータにはそのハッシュ値も一緒に記録される。 verifyコマンドは、保存されたスナップショットが改ざんされていないか、あるいは意図せず変更された箇所がないかを検証する。スナップショットファイルを再度読み込み、そこからハッシュ値を再計算し、最初にスナップショットを作成した時のハッシュ値と比較することで、整合性を確認するのだ。もしハッシュ値が一致しなければ、データが改ざんされたか変更されたことを意味する。 最も興味深いのがdiffコマンドだ。これは、二つの異なるスナップショットを指定して、どのような変更があったかを詳細に表示する。例えば、新しい企業が追加されたり、特定の企業のグレードがAからFに変わったり、オファーが削除されたりといったフィールドレベルでの変更を、古い値と新しい値を比較しながら報告してくれる。開発者が意図的にデータを変更してテストした結果、ツールの最初のバージョンでは見落としていたフィールド値の変更も、改修後は正確に捉えられるようになったという。これは、「同じエンティティが存在するか」だけでなく、「そのエンティティの中身が変更されたか」も正確に追跡することの重要性を示している。 changelogコマンドは、diffと同様に変更をまとめるが、watch --onceコマンドは、継続的インテグレーション（CI）環境などでの利用を想定しており、何か変更があれば終了コード1を返して終了する。これにより、自動化されたシステムでデータの変更をトリガーとすることが可能になる。

このツールが「ゼロ依存」であることは、単なる技術的な自慢ではなく、重要な利点をもたらす。まず、セキュリティの観点から非常に有利だ。外部のライブラリを利用すると、そのライブラリ自体に脆弱性があったり、悪意のあるコードが紛れ込んでいたりする「サプライチェーン攻撃」のリスクが常に存在する。しかし、このツールはPythonの標準ライブラリ（urllib.requestでWebからデータを取得し、hashlibでハッシュ値を計算し、jsonでJSONデータを扱う）のみを使用しているため、外部から新たな脆弱性を取り込むリスクが極めて低い。また、ツールのセキュリティ監査も容易だ。たった一つのPythonファイルを読むだけで、ツールがどのような処理をしているのか、個人情報などを外部に送信していないかなどを、誰でも簡単に確認できる。複雑な依存関係の解析や、ロックファイル（依存ライブラリのバージョンを固定するファイル）の履歴を追う必要が一切ない。

この変更検知のパターンは、他のプロジェクトにも応用できる汎用性の高いものだ。その核となるのは、「スナップショットの取得」と「検証」という二つのプロセスだ。スナップショットを作成する際には、実際のデータに加えて、データのソース、リリースID、SHA256ハッシュ値、取得日時などのメタ情報も一緒に保存する。そして検証する際には、保存されたスナップショットファイルを読み込み、データ部分からハッシュ値を再計算し、保存されているハッシュ値と比較する。もし二つのハッシュ値が一致すれば、データは変更されていないと判断できる。 ここで非常に重要なのが、「正規化されたJSONシリアライゼーション」という考え方だ。JSONデータは、キーの順序が変わってもデータとしての意味は同じとみなされることが多い。しかし、そのままハッシュ値を計算すると、キーの順序が少し変わっただけでも異なるハッシュ値が生成されてしまい、「データが変更された」と誤って検知してしまう可能性がある。これを避けるため、このツールではJSONデータを常に特定の順序（例えばキーをアルファベット順にソートする）で出力し、固定の区切り文字を使うことで、常に同じ形式のJSON文字列を生成する。この「正規化」されたJSON文字列に対してハッシュ値を計算することで、真にデータの内容が変更された場合にのみ異なるハッシュ値が生成され、正確な変更検知が可能になるのだ。

このようなツールを開発する上で、開発者自身が最も学びを得たのは「ミューテーションテスト」を通じてだったという。これは、ツールが正しく機能するかどうかを検証するために、意図的にデータを「破壊」し、その変更をツールが正しく検知できるかを確認するテスト手法だ。例えば、企業リストに架空の会社を追加したり、既存の会社のグレードを変更したり、オファーを削除したりといった操作を行い、それらの変更をツールが正確に報告するかを検証した。このテストを通じて、最初のバージョンではフィールドの値の変更（例：グレードAからF）を検知できなかったという課題が明らかになり、ツールの改善につながった。この経験は、「同じエンティティが存在していること」と「そのエンティティのデータが同じであること」は全く異なる主張であり、両方をきちんとテストする必要があるという重要な教訓を与えてくれた。

このパターンは、公開されているJSON形式のデータを扱う様々なレジストリに応用可能だ。データがバージョン管理されたJSON形式で公開されているならば、このツールが採用している「JSONを取得し、正規化し、ハッシュ値を計算し、スナップショットをとり、差分を比較する」という一連の流れを適用できる。ツールの中でレジストリ固有の記述が必要なのは、データを取得するエンドポイント（URL）の指定部分だけであり、そこを修正するだけで別の公開データにも対応できるのだ。 ただし、単にツールを作るだけでなく、そのツールが本当に信頼できるかを確認するために、まずは意図的にデータを変更してテストしてみることが重要だ。ミューテーションテストを経ていないトラッカーは、単なる「雰囲気で動くエンジン」に過ぎないかもしれないからだ。 このツールは、単一ファイル、標準ライブラリのみ、そしてMITライセンスという形で、オープンな精神に基づいて公開されている。シンプルな解決策がいかに強力であり、セキュリティや使いやすさ、そして信頼性においていかに価値があるかを示す良い例と言えるだろう。