鮮度の問題
50以上のディレクトリからデータを集約していると、データが完全に同期している瞬間はありません。ディレクトリAは1時間ごとに更新されるかもしれません。ディレクトリBは週次更新かもしれません。ディレクトリCはボランティアが手の空いたときに更新するかもしれません。結果として、ある項目は数分前に確認されたばかりで、別の項目は数週間前のままという、まだらなデータセットになります。
ユーザーは見ているデータが最新であることを期待します。MCPサーバーのセキュリティ評価を確認しているなら、その評価には先月のではなく現在の依存関係の状態が反映されていてほしいはずです。ダウンロード数を見ているなら、古い数字ではなく直近の数字が欲しいはずです。
クロール戦略
ソースごとに適切なクロール頻度は異なります。継続的に更新されるパッケージレジストリ(npm、PyPI)は頻繁にクロールします。週次で変わるコミュニティ管理のawesomeリストは頻度を下げます。GitHubリポジトリのメトリクスは比較的ゆっくり変わるので、定期的に取得します。
優先度ベースのクロールはリソース配分に役立ちます。人気のツール(ダウンロード数が多い、スターが多い、ディレクトリ掲載数が多い)は、利用が少ないツールよりも頻繁に更新します。これによって、多くの人が見ているツールほど新鮮なデータを持てるようになります。
イベント駆動のクロールはスケジュールクロールを補完します。あるツールがnpmに新バージョンを公開すると、そのイベントが当該ツールのデータ更新を引き起こし、次の予定クロールを待ちません。このアプローチによって、活発に開発されているツールを最新に保ちつつ、全体のクロール負荷は増やさずに済みます。
古さの検知
各データポイントには、最終確認日時を示すタイムスタンプがあります。古さの閾値は、データが更新を必要とする前にどれだけ古くてよいかを定義します。2日前のダウンロード数はおそらく問題ありません。6ヶ月前のセキュリティスコアは、依存関係が変わっていれば誤解を招くかもしれません。
データタイプごとに、古さに対する許容度は異なります。静的なメタデータ(ツール名、作者、説明)はめったに変わらないので、より長くキャッシュできます。動的なメトリクス(ダウンロード数、スター数、セキュリティスコア)は変化が早く、より頻繁な更新が必要です。変動性ベースのキャッシングは、データタイプごとの実際の変化速度に合わせて更新頻度を調整します。
スコアの再計算
セキュリティスコアや品質メトリクスは、根拠データの変化に伴って定期的に再計算する必要があります。依存関係がセキュリティパッチを公開すれば、ツールのセキュリティ評価が変わるかもしれません。メンテナンス活動が増減すれば、ツールの品質スコアが変わるかもしれません。
10万を超えるツールを対象に全スコアを再計算するのは計算コストが高くなります。根拠データの変化を引き金に発動する増分再計算の方が効率的です。ツールの依存関係ツリーが変わったときには、そのツールのセキュリティスコアだけを再計算すればよいのです。新しいディレクトリにツールが追加されたときには、ディレクトリ掲載スコアだけを更新すれば済みます。
鮮度を伝える
データ鮮度に関する透明性は、ユーザーが見ている情報への信頼度を調整するのに役立ちます。「最終更新」のタイムスタンプを表示する、スコアが最後に再計算された日時を示す、古い可能性のあるデータにフラグを立てる、これらすべてがユーザーの情報に基づいた判断を後押しします。
データを検証できない場合(ソースが一時的に利用不能なときなど)の適切な対応は、ツールを結果から取り除くのではなく、最後に把握できたデータを古さインジケーターとともに表示することです。そうすれば、ユーザー自身が「最新の既知データが自分の用途に十分新しいか」を判断できます。