APIとWebスクレイピング: プロジェクトに適したデータ収集方法はどちらか?

公式APIは安定しているが制限がある。Webスクレイピングはその範囲を補う。両者の選び方、組み合わせるタイミング、そしてそれを決定づけるトレードオフについて。

プロジェクトがウェブ上のデータを必要とするとき、最初の分岐点は単純明快だ。情報源の公式APIを使うか、ウェブページからデータを収集するか。どちらも正当なデータ取得方法であり、チームはしばしば原則論としてどちらか一方を主張する。しかし実際には、正しい答えはAPIが実際に何を提供しているか、ページに何が表示されているか、そしてプロジェクトが何を必要としているかによって決まる。

このガイドでは、実際のプロジェクトを左右する要因に基づいて両者を比較し、それぞれがどこで優れているかを説明し、両者を組み合わせるという一般的な中間的アプローチについても取り上げる。公式APIと同じように、ページを構造化データに変換するweb scraping APIを使う方法も含めてだ。

要点まとめ

要因	公式API	ウェブスクレイピング
利用可能なデータ	プロバイダーが公開を選んだものだけ	公開ページに表示されるすべて
フォーマット	構造化されている(通常JSON)、文書化済み	パースまたは抽出が必要なHTML
安定性	バージョン管理され、変更は告知される	ページのレイアウトが変わると壊れる
制限	レート制限、クォータ、場合によっては有料プラン	自分自身のキャパシティ、サイトの許容度、利用規約
利用規約	何ができるかを明記した明確なライセンス	サイトの利用規約と法律次第
カバー範囲	APIごとに1つのプロバイダー	どのサイト、どの市場でも同じ手法
見えるもの	プロバイダーのデータモデル	ある特定の場所の訪問者が見るもの

公式APIが必要なフィールドを、必要な量だけ、自分の用途を許す条件の下で提供してくれるなら、そこから始めればいい。スクレイピングが出番を得るのは、この3つの条件のいずれかが満たされないときだ。

公式APIがより良い選択となる場合

必要なデータがそこにある場合。 多くのAPIは太っ腹だ。カタログデータ、公開プロフィール、財務報告書、公開されている政府のデータセットなど。レジデンシャルプロキシが不要な場合についての我々のテストでは、試した公開APIはすべてプロキシなしで確実に動作することがわかった。
広さよりも安定性が必要な場合。 変更通知付きでバージョン管理されたAPIは、ページレイアウトを追いかけ続けるパーサーに比べて、維持にかかる手間がはるかに少ない。
ライセンスが重要な場合。 データを公開したり、再販したり、それを元にした製品を構築するつもりなら、APIの利用規約が何が許されているかを正確に示してくれる。スクレイピングしたデータの場合、それは自分で判断しなければならない。
どのページにもないデータが必要な場合。 一部のAPIは、ウェブページには表示されない履歴、識別子、一括エクスポートを公開している。

ウェブスクレイピングがより良い選択となる場合

APIが存在しない場合。 これは今でもウェブの大部分に当てはまる。ほとんどの小売業者、地元企業、ニュースサイト、ディレクトリには公開データAPIがない。
APIが必要なものを含んでいない場合。 APIはページに掲載されている項目、例えば現在のプロモーション、在庫状況のメッセージ、レビュー、買い物客に実際に表示される価格などを省略していることが多い。
ユーザーが実際に見ているものが必要な場合。 価格、ランキング、広告、在庫状況は、場所、デバイス、言語によって異なることが多い。APIはプロバイダーの正規データを提供するが、ページはある市場における実際の体験を提供する。その見え方を収集するには通常、その市場内部からページをリクエストする必要があり、ここでレジデンシャルプロキシが登場する。
多数の情報源を同じ方法で扱う必要がある場合。 1つのスクレイピング構成で100の小売業者をカバーできるが、100のAPIとなれば100の統合、キー、レート制限の仕組みが必要になる。そもそも存在すればの話だが。
APIの制限が合わない場合。 クォータ、料金体系、承認プロセスのせいで、必要な量においてAPIが実用的でなくなることがある。

中間的なアプローチ

選択はオールオアナッシングであることはめったにない。

両方を使う。 よくあるパターンは、安定した中核部分(製品識別子、カタログ構造)にはAPIを使い、APIが欠いている部分(リアルタイム価格、プロモーション、地域ごとの在庫状況)にはスクレイピングを使うというものだ。それぞれが最も得意なことをする。

ページ自身のAPIを使う。 多くの現代的なウェブサイトは、内部のJSONエンドポイントからコンテンツを読み込んでいる。利用が適切な場合、これらはスクレイピングのカバー範囲とAPIのクリーンなフォーマットを兼ね備えている。ページの裏にあるAPIを見つけるという我々の調査では、そうしたデータがどれほど頻繁に存在するか、そして頼る前に何を確認すべきかを示している。

ページにすでにある構造化データを使う。 多くのページは検索エンジン向けにJSON-LDを埋め込んでいる。製品名、価格、評価、営業時間などだ。これを読み取る方が、目に見えるレイアウトをパースするよりもはるかに堅牢だ。HTMLをパースする代わりにJSON-LDを抽出するを参照のこと。

web scraping APIを使う。 web scraping APIはURLを受け取り、ページそのもの、あるいは抽出済みのフィールドをJSONとして返す。その際にプロキシ、ブラウザ、リトライ処理をすべて内部で処理する。あなたのコードから見れば、公式APIとほぼ同じように振る舞う。リクエストを1つ送れば、構造化データが返ってくる。それは情報源自身のAPIが適している場面でそれに取って代わるものではないが、スクレイピングの保守負担の大部分を取り除いてくれる。web scraping APIの使い方についての初心者向けガイドではその手順を解説しており、構築か購入かのガイドでは自前のスクレイピングインフラを運用する方が理にかなう場合について取り上げている。

段階的な判断方法

**必要なフィールドを列挙し、**それぞれがどこに存在するかを記録する。APIか、ページか、両方か。
**APIの利用規約と制限を確認する。**自分の用途と量に照らし合わせて。
**ページの見え方を確認する。**必要なものが場所やデバイスによって変わるか。もしそうなら、APIはそれを表示しない可能性がある。
**情報源の数を数える。**良いAPIを持つ情報源が1つか2つならAPIが有利であり、情報源が多数ならスクレイピングのアプローチが有利になる。
**保守コストを見積もる。**API統合はほぼ一度構築すれば済むが、スクレイパーはページが変わるたびに監視と修正が必要になる。
**プロジェクト単位ではなくフィールド単位で選ぶ。**あるフィールドはAPIから、別のフィールドはページから取得するのはごく普通のことだ。

どちらの道でも伴う責任

APIを使うということは、その利用規約に従うということだ。クォータ、帰属表示、許可された用途などだ。ページから収集するということは、サイトの利用規約が自分を拘束する範囲でそれに従い、robots.txtとレート制限を尊重し、ログインの背後にあるコンテンツには近づかず、個人データがあれば適用される法律の下で取り扱うということだ。どちらの道も義務から自由ではない。ただ、それらが書かれている場所が違うだけだ。

よくある質問

APIを使うのとウェブサイトをスクレイピングするのでは、どちらが良いですか。

公式APIが必要なデータを、必要な量だけ、自分の用途を許す条件の下で提供してくれるなら、それを使うべきだ。APIが存在しない場合、APIが必要なものを含んでいない場合、あるいは特定の市場のユーザーが見ているままのデータが必要な場合には、スクレイピングを行う。

ウェブスクレイピングはAPIより信頼性が高いですか。

通常はそうではない。ページレイアウトは予告なく変わるが、APIはバージョン管理されているからだ。抽出ルール、ページ上の構造化データ、監視によってその差は縮まり、web scraping APIは保守作業の多くを代わりに引き受けてくれる。

APIとウェブスクレイピングを併用できますか。

できる。多くのチームが実際にそうしている。データの安定した中核部分にはAPIを使い、APIが提供しないリアルタイム価格、プロモーション、地域ごとの在庫状況といったフィールドにはスクレイピングを使う。

web scraping APIとは何ですか。

自前のプロキシとブラウザを通じてウェブページを取得し、HTMLまたは抽出済みのフィールドをJSONとして返すサービスのことだ。あなたのコードにとってはスクレイピングがAPI呼び出しのように見えるようになるが、サイト自身の公式APIに取って代わるものではない。

結論

必要なものを、合致する条件の下で提供してくれるなら、まず公式APIから始めよう。APIが欠いているもの、つまりAPIが存在しない情報源、APIが省略しているフィールド、そして価格や在庫状況の地域ごとの実際の見え方については、スクレイピングに頼ろう。実際の多くのプロジェクトは結局両方を使うことになり、プロジェクト単位ではなくフィールド単位で選択し、web scraping APIはスクレイピング側の作業をAPI側の作業とほとんど同じように感じさせてくれる。