私たちの立場：私たちはGeonodeであり、プロキシを販売しています。プロキシはアグリゲーターの構成要素の一つですが、多くのガイドではこれが過度に強調されがちです。そこで、率直に申し上げておきます――プロキシは最初に購入すべきものではなく、最後に購入すべきものです。 集約可能なデータの大部分は、無料かつ構造化され、安定しており、この目的のために明示的に提供されているフィード、API、サイトマップを通じて入手可能です。誰かがRSSフィードとして公開しているコンテンツのためにクローラーを構築するのは無駄な作業であり、その事実を確認する前に帯域幅を購入するのは無駄なお金です。 プロキシが重要になるのは、特定の時点――つまり、レート制限のあるサイトに対して、複数の地域から大量のクロールを行う場合――であり、その時点は多くの人が想定しているよりもずっと後になります。その境界線がどこにあるかについては、以下のセクションで詳しく説明します。
アグリゲーターの種類：4つのモデル
これらは経済的側面も法的リスクも異なり、これらを混同することが最初の過ちとなる。
リンクアグリゲーターは、見出しを収集して外部サイトへのリンクを掲載する。ストレージ容量が少なく、法的リスクも低く、ユーザーの乗り換えコストも低い。 その価値は、完全にキュレーションとスピードにあります。ニュースやコンテンツのアグリゲーターの多くは、このカテゴリーに属します。
リスト型アグリゲーターは、求人、不動産、自動車、イベントといった構造化された記録を収集し、検索可能なデータベースとして提示します。価値は高く、労力もかかりますが、重複排除がエンジニアリング上の最大の課題となるモデルです。
価格アグリゲーターは、複数の販売業者にまたがる同一商品の価格を追跡します。最も範囲が狭く、最も難しい分野です。商品説明が異なる小売業者間で商品を照合することは真に困難な問題であり、価格が古くなることは価格情報がないことよりも悪影響を及ぼすため、情報の鮮度に対する要求は極めて厳しいものです。
レビュー・評価アグリゲーターは、意見データを統合します。カバー範囲が限られ、正規化作業が膨大で、情報源を誤って伝えているという非難に最もさらされやすい分野です。
慎重に1つを選びましょう。アーキテクチャも異なり、法的分析も異なります。「あらゆるものを網羅するアグリゲーター」という考え方は、プロジェクトを完結不能なものにしてしまう原因となります。
まずは簡単な方法でデータを入手する
優先順位の高い順に並べています。このリストを順に試していき、うまくいった時点でそこで止めてください。
公式API。 提供元がAPIを公開している場合は、それを利用しましょう。安定しており、構造化され、公認されている上、不具合が生じても誰かが修正してくれます。 利用規約をよく読んでください。多くの場合、再配布、キャッシュの保持期間、商用利用が制限されており、これらの制限が製品開発に影響を与えます。
パートナーやアフィリエイトのフィード。 多くの業界では、アグリゲーターがトラフィックをもたらすため、アグリゲーター向けに特別に大量のフィードを公開しています。求人サイト、不動産ポータル、小売業者、旅行会社は、データセット全体を提供してくれるパートナープログラムを頻繁に設けています。 これはこの分野で最も活用されていない情報源ですが、その理由は、人々が「Xをスクレイピングする方法」を検索するばかりで、Xにメールを送ってフィードがあるかどうかを尋ねないからです。尋ねてみてください。驚くほど多くの場合、肯定的な回答が得られます。
RSSおよびAtomフィード。 今でも広く公開されており、リンクの集約には依然として理想的です。 構造化されており、コストも低く、まさにこの目的のために設計されており、利用できるよう明確に提供されています。
サイトマップ。 sitemap.xml を利用すれば、完全なURLリストに加え、lastmodのタイムスタンプも得られます。これにより、力業ではなく効率的にクロールできます。クロールが必要な場合でも、サイトマップが変更箇所を教えてくれるため、その部分のみを取得すれば済みます。
ページ内の構造化データ。 HTMLパーサーを作成する前に、<script type="application/ld+json">ブロック内にJSON-LDが含まれていないか確認してください。JobPosting、Product、Event、Recipe向けのSchema.orgマークアップは、検索機能を駆動するため広く普及しており、いずれにせよ取得する予定だったページから、クリーンな構造化データを得ることができます。また、CSSセレクタよりもはるかに優れた耐改修性を備えています。
HTMLの解析。 最後の手段です。脆弱でメンテナンスが大変であり、アグリゲーターの運用を恒久的な仕事にしてしまう原因となります。
順序は、個々の項目よりも重要です。このリストの一番下から着手したチームは、クローラーを構築した後、半年後にフィードの存在に気づくことになります。
クロールが必要な場合：robots.txt は今や標準規格です
robots.txtは2022年に「慣習」ではなくなりました。RFC 9309はRobots Exclusion Protocolを標準化しており、クローラーを開発する際には、この規格で定義された動作を実装する必要があります。
正確に把握しておくべき4つの要件：
一致の判定は順序ではなく、特異性に基づきます。 「見つかった中で最も特異性の高い一致をMUST使用しなければならない。最も特異性の高い一致とは、オクテット数が最も多い一致のことである。」多くの手作りのパーサーが想定しているような「最初の一致が優先」というルールではありません。
キャッシュの保持期間は24時間を超えてはなりません。 「robots.txt ファイルにアクセスできない場合を除き、クローラーはキャッシュされたバージョンを24時間以上使用してはならない。」デプロイ時に一度取得するだけでは準拠とはみなされません。
サーバーエラーが発生した場合は停止する。 「サーバーまたはネットワークのエラーにより robots.txt ファイルにアクセスできない場合……クローラーは完全なアクセス拒否であると見なさなければならない。」5xxエラーは完全にアクセスを中止することを意味する。対照的に、404エラーは制限がないことを意味する――ファイルが存在しないため、アクセスが拒否されるものはない。
少なくとも500 KiBを解析すること。 「解析の制限は、少なくとも500キビバイトでなければならない。」大規模なサイトには大規模なファイルが存在する。
自分で実装するのではなく、メンテナンスされているライブラリを使用すること。特定条件との照合ルールだけでもバグの一般的な原因となり、robots.txtを誤読するクローラーは、苦情を招くクローラーとなる。
ファイル自体以外にも、一般的なマナーを守りましょう。連絡先URLを含む実際のユーザーエージェントで自身を識別し、Crawl-delayが指定されている場合はそれを尊重し、429や503の応答に対しては即座に引き下がり、変更のないコンテンツを二度取得しないようキャッシュを行ってください。 If-Modified-Since や If-None-Match を使った条件付きリクエストは、配信元にもあなたにも何のコストもかかりません。アグリゲーターをブロックするサイトのほとんどは、その存在自体ではなく、その動作を理由にブロックしているのです。
法的側面：著作権、TDMオプトアウト、データベース権
これは法的助言ではなく、管轄区域によって状況は大きく異なります。しかし、開発に着手する前に理解しておくべき点が4つあります。
事実そのものは一般的に著作権の対象となりませんが、表現は対象となります。 役職名、給与、価格、日付などは事実です。 その仕事を売り込むために書かれた説明文は「表現」です。前者を集約することは、後者を複製することよりもはるかに法的に確実です。この単一の区別が、賢明なアグリゲーター設計のほとんどを形作っています。つまり、構造化された事実を保存し、文章については出典へのリンクを張るのです。
抜粋の長さは重要です。 見出しと一文をリンク付きで転載することは、記事全体を転載することとは性質が異なります。この境界線がどこにあるかについて、いくつかの法域で訴訟が提起されており、その判断はまちまちです。短いほど安全であり、転載するよりも外部リンクを張る方が最も安全です。
EUには、設計上機械可読なテキストおよびデータマイニングのオプトアウト規定がある。 指令 (EU) 2019/790の第4条は、権利者が「例えば機械可読な手段を用いるなど、適切な方法」で権利を明示的に留保していない限り、誰でもテキストおよびデータマイニングを行うことを認めています。 オンライン上で公に利用可能となっているコンテンツについては、同指令は、機械可読形式による権利留保（「メタデータやウェブサイト・サービスの利用規約を含む」）を適切な手段として扱っている。また、この例外が適用されるには、当該資料が合法的にアクセスされたものであることが求められる。
クローラーにとっての実務上の意味は、機械可読形式で表明された権利留保は尊重されるべきものであり、EUはそれらを表明するためのプロトコルの標準化に取り組んできたということです。機械可読形式の権利留保を無視するクローラーを構築することは、その基盤にコンプライアンス上の問題を組み込むことに他なりません。
EUには、これとは別にデータベース権も存在します。 著作権とは別に、データベース指令は、データベースの内容の取得、検証、または提示に要した実質的な投資を保護するsui generis（独自の）権利を創設しました。これは、内容自体が著作権の対象となるかどうかにかかわらず適用されます。 これはアグリゲーターにとって直接的な関連性があります。なぜなら、個々の掲載情報が単なる事実である場合でも、他者の掲載情報データベースの相当な部分を抽出することは、この権利の適用対象となり得るからです。
さらに、利用規約という問題があります。これは法令に基づくものではなく契約上の規定であり、多くのサイトがこれを利用して自動アクセスを全面的に禁止しています。何もクリックしていない場合にその規約が拘束力を持つかどうかは、管轄区域によって異なる、真に議論の分かれる問題です。いずれにせよ、利用規約は必ず読んでおくべきです。そこにはサイト側がその行為に対してどのような対応を取るかが明記されており、それは裁判所が下す判断よりも、多くの場合、より直接的に関連する情報だからです。
実用的な要約としては、公認の情報源を優先し、文章ではなく事実を保存し、複製ではなくリンクを貼り、機械可読な制限事項を遵守し、商業的に重要な事柄については専門家の助言を求めることです。
アーキテクチャ：4つの段階と、その中でも難しい1つ
どのアグリゲーターも、同じ4つの段階を経ており、そのうち難しいのは1つだけです。
フェッチ。 生のコンテンツを取得する。留意点：スケジューリング、レート制限、再試行、キャッシュ、条件付きリクエスト。生のレスポンスは常に保存しておくこと――パーサーが動作しなくなった場合、データを再取得するのではなく、過去のデータを再解析できるようにするためだ。
解析。 生のコンテンツを構造化されたレコードに変換する。 考慮すべき点：脆弱性と変更の検出。パーサーが例外をスローしたときではなく、出力形式が変更されたときにアラートを発するようにすべきです。なぜなら、コストのかかる失敗とは、パーサーが黙って返すフィールド数を減らし始めることだからです。
正規化と重複排除。 これが最も難しい段階です。詳細は後述します。
提供。 検索、フィルタリング、表示。標準的なWebエンジニアリングであり、目に見える部分であるため、多くのチームが初期段階で過剰に投資しがちな部分です。
重複排除こそが、アグリゲーターの成否を分ける鍵です。 同じ求人が、異なるタイトルで4つの掲示板に掲載されることがあります。同じ物件が、3つの不動産業者を通じて異なる価格で掲載されることもあります。 同じ商品が、小売店ごとに異なる名前で扱われていることもあります。ユーザーはほぼこの点だけでサイトを評価します。同じものを6回も表示するリストサイトは、たとえ情報がどれほど網羅的であっても、機能不全と見なされてしまいます。
効果的なアプローチは、コストの低いものから順に段階的に進めることです：
正確な識別子。 ISBN、部品番号、登録番号、ソースIDなど。 これらが存在する場合は、それらを使用し、それ以上は行わないこと――これだけで問題は完全に解決される。
正規化されたキー。 小文字に変換し、空白を削除し、句読点を除去したフィールドから正規キーを構築する：雇用主＋役職＋勤務地；郵便番号＋寝室数＋床面積。低コストで大部分をカバーできる。
ファジーマッチング。 タイトルや説明文に対してトークンベースの類似度判定を行い、手動でラベル付けされたサンプルに基づいて閾値を調整します。これは必要不可欠ですがコストもかかります。すでに大まかなキーを共有している候補に限定してください。そうしないと、費用対効果の悪い全ペア比較になってしまいます。
曖昧なケースに対する手動レビュー。 一定割合のケースには人間の介入が必要であることを受け入れてください。ユーザーから苦情が出るのを待たずに、早めにレビュー待ちリストを作成しておきましょう。
後々のトラブルを防ぐための2つの設計上の決定事項：すべてのソースレコードを個別に保持し、それらを正規エンティティにリンクさせること。破壊的なマージは避けること――マージを誤ってしまい、元に戻す必要が生じるからです。 また、2つのレコードがなぜマージされたのかをログに残すこと。「なぜこの商品ページに間違った価格が表示されているのか」という質問は必ず寄せられるが、マージされたデータだけでは答えられないからだ。
鮮度、スケジュール、およびコスト
鮮度の要件はケースによって大きく異なり、コスト構造全体に影響を与えます。
| 種類 | 許容される鮮度の低下 | 影響 |
|---|---|---|
| ニュース | 分単位 | フィード駆動型、可能な限りプッシュ配信 |
| 求人 | 数時間～1日 | ほとんどの情報源では毎日のクロールで十分 |
| 不動産 | 数時間 | 掲載中の物件のみを頻繁にチェック |
| 価格 | 数分～数時間 | コストがかかる項目 |
| イベント | 数日 | 通常は週1回で十分 |
予算を圧迫する過ちは、変動が最も激しい項目の頻度に合わせてすべてをクロールしてしまうことです。 その解決策は階層化です。頻繁に更新されるものは頻繁にクロールし、めったに更新されないものはめったにクロールせず、サイトマップや条件付きリクエストによるlastmodを活用して、変更のないコンテンツを完全にスキップします。
削除の検知は、誰も計画に入れていない鮮度の問題です。採用が決まった求人や売却済みの物件は削除される必要がありますが、情報源がそれを告知することはめったにありません。 これに対処するには、何らかのシグナル（ページが404エラーになる、ステータスフィールドが変更されるなど）か、ポリシー（3回のクロールで検出されなかったレコードを非アクティブとしてマークする）のいずれかが必要です。これを誤ると、アグリゲーターは古い掲載情報で埋まってしまいます。これは、重複に次いで、ユーザーがアグリゲーターへの信頼を失う2番目に多い理由です。
コストはレコード数ではなく、フェッチ回数に比例して増加します。1時間に1万件の物件情報をチェックする場合、1日あたり24万回のフェッチが発生します。同じ物件情報を1日1回チェックする場合は、1万回です。同じデータであっても、帯域幅と情報源への負荷には24倍の差が生じます。許容できる古い情報の放置時間が1時間増えるごとに、コストが発生します。
プロキシが適している場面と適していない場面
パイプラインの最終段階について、可能な限り正確に説明します。
プロキシが必要ない場合： フィードやAPIを利用している場合、トラフィック量がそれほど多くない場合、レート制限のないソースに対して1か所からクロールを行っている場合、あるいはまだ構築やテストの段階にある場合です。これらは、初期段階のアグリゲーターの多くを完全に網羅しています。
プロキシが必要な場合： 1つのIPアドレスでレート制限を受けるほど大量のクロールを行う場合、コンテンツが地域ごとに異なり複数の地域を調査する必要がある場合、分散型クローラーを運用しており、複数のスレッドを持つ1台のマシンではなく、個別のクライアントとして認識させたい場合、または地域固有の価格設定や在庫状況を確認するために地理的な精度が必要な場合。
どのタイプを選ぶか： ほとんどのクロールにはデータセンタープランが適しています。コストが大幅に安く、公開されているリストページを閲覧する分には通常、これ以上の機能は必要ないからです。当社のプランは1GBあたり0.14ドルからで、IPアドレス単位ではなくトラフィック量に応じて課金されます。 データセンタープランでは明らかに不十分な場合、または一般消費者向けネットワークのジオロケーションが必要な場合にのみ、住宅用プラン（$0.79/GB～）に切り替えてください。新規アカウントには1 TBの住宅用トラフィックが無料で提供されますので、これだけで住宅用プランが必要かどうかを判断するのに十分です。 数値は当社の料金ページより、2026年9月時点のものです。
誰も計画に組み込まないコスト要因： ヘッドレスブラウザ。 ソースがJavaScriptによるレンダリングを必要とする場合、ブラウザはすべての画像、フォント、スクリプトを取得するため、帯域幅の使用量は単純なHTTP通信に比べて桁違いに増加します。不要なリソースタイプはブロックしてください。帯域幅が従量課金制の場合、これが利用可能な最大のコスト削減手段となります。より広範な経済性については、当社のプロキシ価格ガイドで解説しています。
そして率直な限界： プロキシは配信の問題を解決します。しかし、利用規約の問題を解決するわけでも、データベースの権利の問題を解決するわけでもなく、ソース側があなたのアクセスを歓迎するようになるわけでもありません。サイト側からクロールを禁止されている場合、アドレスを増やしても解決にはなりません。それは単に、その禁止事項をより効率的に無視する方法に過ぎないのです。
なぜほとんどのアグリゲーターは失敗するのか
技術的な理由ではない。
独自の価値がない。 他の誰もが集約しているものを集約しても、既存のサイトよりも劣ったものになってしまう。価値は、他にはない網羅性、他にはない整理整頓、あるいは既存の大手には手が出せないほどニッチな分野にあるべきだ。
重複。 上記でも触れたが、改めて強調する価値がある。これがユーザーが離れていく最大の理由だ。
古いデータ。 掲載されていない情報よりも、無効な情報が信頼を損なうスピードは速い。なぜなら、掲載されていない情報は目に入らないだけだが、無効な情報はユーザーの時間を無駄にするからだ。
価値を上回るメンテナンスの負担。 手作業で作成したHTMLパーサーが20個あれば、それは永遠に続くパートタイムの仕事だ。ソースを追加するたびに、固定の継続コストが増加する。フィードを提供するソースを優先し、メンテナンスの負担が貢献を上回るソースは惜しみなく切り捨てる覚悟を持て。
鶏と卵の問題。 アグリゲーターはユーザーを集めるために網羅性が必要であり、網羅性を正当化するにはユーザーが必要です。解決策は、広範囲を部分的にカバーするよりも、狭い分野で完全な網羅性を確保することです。
後になって発生する法的問題。 ある情報源を基盤にビジネスを構築した後に差し止め命令を受けることは、事業開始前にパートナーと話し合うよりもはるかにコストがかかります。主要な情報源とは早い段階で話し合いましょう。トラフィックの増加を歓迎する情報源もあれば、そうでない情報源もいます。後者については、事業開始当初に把握しておく方が賢明です。
よくある質問
アグリゲーターサイトを構築することは合法ですか？
それは、何を、どこから、どのように集約するかによって異なります。 事実そのものは一般的に著作権の対象となりませんが、表現は対象となります。そのため、構造化データを保存し、出典へのリンクを掲載する設計の方が安全です。EUでは、「テキストおよびデータマイニングの例外」、機械可読形式での権利留保、および独立したデータベース権がすべて適用されます。商業的に重要な事項については、専門家の助言を求めてください。
アグリゲーターはデータをどこから取得するのでしょうか？
優先順位の高い順に、公式API、パートナーやアフィリエイトのフィード、RSSおよびAtom、サイトマップ、ページに埋め込まれた構造化データ、そして最後にHTMLの解析となります。最も見過ごされがちな情報源はパートナーのフィードです。多くの業界では、アグリゲーターがトラフィックをもたらすため、アグリゲーター向けに完全なデータセットを公開しています。クローラーを構築する前に、事前に確認してください。
アグリゲーターを構築するのにプロキシは必要ですか？
当初は必要ありません。フィードやAPIにはプロキシが不要ですし、1か所からの小規模なクロールでも通常は必要ありません。プロキシが必要になるのは、トラフィック量によってレート制限が適用される場合、地域固有のコンテンツを閲覧する必要がある場合、または分散型クローラーを実行する場合です。 デフォルトではデータセンターの帯域幅を使用するのが賢明です。住宅用回線は、明らかに必要と認められる場合にのみ使用してください。
アグリゲーターは重複する掲載情報をどのように処理しますか？
階層的なマッチングを行い、最も優先度の高いものから処理します。具体的には、正確な識別子が存在する場合はそれを優先し、次にクリーニングされたフィールドから構築された正規化されたキー、さらに大まかな候補グループ内でのあいまいな類似性、そして曖昧な残りの部分については人間によるレビューを行います。 ソースレコードは分離したままにし、破壊的なマージを行うのではなく、正規エンティティにリンクさせる。
robots.txt では何をしなければならないか？
RFC 9309 以降、これは単なる慣習ではなく標準となっている。 順序ではなく特異性に基づいて照合し、ファイルは少なくとも毎日更新し、サーバーエラーを完全なアクセス拒否として扱い、404エラーを制限なしとして扱い、少なくとも500 KiBを解析する。独自のパーサーを作成するのではなく、メンテナンスされているライブラリを使用する。
アグリゲーターはどのくらいの頻度でデータを更新すべきか？
ユースケースが許容する限り、更新頻度はできるだけ低く抑えるべきです。コストはフェッチ回数に比例して増加するためです。ニュースは数分、求人情報は数時間、イベント情報は数日単位での更新が必要です。ソースを変動性に応じて階層化し、サイトマップ（lastmod）や条件付きリクエストを使用して変更のないコンテンツをスキップし、削除されたリストを検出するための明確なポリシーを定めてください。
スクレイパーをブロックしているサイトからコンテンツを集約することはできますか？
技術的には可能かもしれませんが、そうすべきかどうかは別の問題です。ブロックは意図の表明であり、それを回避しても、利用規約、データベース権、あるいは関係性は変わりません。より良い方法は、フィードの提供を依頼することです。クローラーをブロックしているサイトの多くが、パートナー向けデータを喜んで提供しています。
アグリゲーターを構築する上で最も難しい部分はどこですか？
断然、重複排除と最新性の確保です。データの取得や解析は、ライブラリを使えば解決済みの問題です。表現の異なる2つの掲載情報が同一のものであると判断すること、そしてそのうちの1つがいつの間にか存在しなくなってしまったことに気づくこと――そこにこそ、技術的な労力とユーザーの信頼の両方がかかっているのです。
まとめ
アグリゲーターを構築する上でのコツは、どの問題が「真の問題」なのかを見極めることです。コンテンツの取得は、その一つではありません。フィード、API、サイトマップ、埋め込み構造化データは、人々が予想するよりもはるかに広い範囲をカバーしており、いきなりHTMLパーサーの記述に取り掛かるチームは、たいてい、すでに解決済みの問題を解決しようとしているに過ぎません。
真の問題は下流にある。重複排除の有無が、ユーザーがデータを信頼するかどうかを決定づける。削除の検出の有無が、ユーザーが二度目にそのデータを信頼するかどうかを決定づける。 メンテナンスの負担の大小は、20もの情報源がそれぞれ独自にマークアップを変更する状況下で、プロジェクトが存続できるかどうかを左右します。そして、法的側面――表現の著作権、機械可読なTDM（テキスト・データ・マイニング）の留保、EUのデータベース権、利用規約――が、その全体がビジネスとなるか、それとも負債となるかを決定づけます。
広範囲で不完全なものではなく、範囲を狭めて完全に仕上げることを目指しましょう。パートナーからのフィードは問題のカテゴリー全体を一挙に解消するため、情報源に直接問い合わせることも含め、あらゆる機会で公認の情報源を優先してください。インフラ（プロキシを含む）は、限界に達したことが明確になった時点で追加し、それ以前には追加しないでください。