目次
企業情報サイトのプロジェクトにおいて、多くの人が「初期構築（ローンチ）」で力尽きます。しかし、本当の地獄はローンチした翌日から始まります。 情報は生鮮食品です。毎日どこかで会社が生まれ、消え、移転しています。更新されないデータベースは、ただの「デジタル廃棄物」へと腐敗していきます。
本記事では、サイトを長期的に維持・成長させるための、泥臭くも現実的な**「更新戦略」**について解説します。
1. 全件更新の不可能性
数百万件の企業データを、毎日すべてクローリングして更新することは、サーバーリソース的にもコスト的にも不可能です。全てのデータを常に最新に保とうとするのは、戦略として間違っています。
**「選択と集中」**が必要です。
2. ティア（階層）別更新ポリシー
企業の重要度に応じてランク付け（ティア分け）を行い、更新頻度を変えるのが定石です。
Tier 1：上場企業・有名大企業（約4,000社）
- 更新頻度：日次〜週次
- 理由：ユーザーの検索需要の大半（パレートの法則）は、これら有名企業に集中します。また、株価やプレスリリースなど情報の流動性が高いため、常にウォッチする必要があります。
Tier 2：中堅・活動的な中小企業
- 更新頻度：月次〜四半期
- 対象：求人を出している企業、プレスリリースを配信している企業。これらは「動き」があるため、見ているユーザーも多いです。
Tier 3：ロングテール・小規模事業者（数百万社）
- 更新頻度：年次〜更新なし（トリガー更新のみ）
- 戦略：基本的には国税庁のデータ更新時などに合わせて洗い替える程度。個別にクロールはしません。コストが見合わないからです。
更新コストの試算
全500万社を毎日クロールした場合のコスト試算です。
- 1リクエスト0.5円（プロキシ、サーバー代含む）と仮定
- 5,000,000社 × 0.5円 = 250万円/日
- 月間で約7,500万円
これをマネタイズ（広告収入など）で回収するのはほぼ不可能です。したがって、Tierによる間引きは経営戦略上、必須となります。
3. トリガーベースの更新
定期更新だけでなく、何かのイベントを検知して更新をかける**「イベントドリブン」**な仕組みを作ります。
- ユーザーからの報告：「この会社の住所、変わってますよ」という報告フォームを設置し、報告があった企業だけ優先的に再クロールする。
- ニュース検知：ニュースサイトで社名が登場した企業をピックアップして更新する。
4. データの「賞味期限」表示
更新できない企業のデータについては、正直に**「情報の鮮度」を表示**することが、ユーザーへの誠実さであり、信頼性の担保になります。
- 「このデータは2023年4月時点のものです」
- 「最終確認日：2年前（情報の正確性は保証されません）」
このようにアラートを出すことで、ユーザーは「古い情報かもしれないから、電話して確認しよう」と自衛できます。「古いのに最新のふりをして載せている」のが一番の悪です。
5. 自動化パイプラインの構築
更新作業を人力でやっていては破綻します。スクレイピング、名寄せ、データ投入までのパイプライン（ETL処理）を完全に自動化し、エラーが出た（サイト構造が変わって取得できない等）場合のみ人間が介入するフローを組みます。
現代的なデータパイプライン構成
- Orchestration: Airflow / Dagster
- 複雑な依存関係（Aの処理が終わったらBを実行）を管理。
- Crawling: Scrapy (Python) / Golang
- 並列処理で効率的にデータを収集。
- Storage: BigQuery / Snowflake
- 生データを蓄積し、加工用の中間テーブルを作成。
このようなモダンなデータ基盤を構築することで、少人数のエンジニアでも大規模データの鮮度を維持することが可能になります。
結論
サイトの価値は「情報の量」ではなく「情報の鮮度管理」で決まります。 データベースの価値は、保有件数もさることながら、その「鮮度管理」によって決定されます。 リソースには限りがあるため、全件一律の更新ではなく、アクセスの多い重要データにリソースを集中させるティア別更新戦略が有効です。これにより、運用コストを抑制しつつ、高いユーザー満足度を維持することが可能となります。