Webスクレイピングの始まりはいつ？これからどうなる？

Webスクレイピングは「最近の技術」のように見えますが、源流をたどると1990年代初頭のWeb黎明期まで遡れます。一方で、2020年代はサイト側の防御や規制・標準化が進み、単純なHTML取得だけでは通用しにくくなっています。この記事では、スクレイピングがいつ始まったのかを歴史の節目で整理し、今後の方向性（技術・法務・実務）を俯瞰します。

この記事でわかること

スクレイピングの起点と、Web誕生〜クローラー登場までの年表
robots.txtやAPIの普及が「収集の作法」をどう変えたか
2026年以降のスクレイピング実務で重要になる論点

結論：始まりは

「Webスクレイピングの始まり」をどこに置くかは定義次第です。ただし実務的には、次の2つを押さえると整理しやすいでしょう。

ポイント

Web上の自動収集（クローリング）の起点：1993年6月、Webを巡回するロボット「World Wide Web Wanderer」が稼働（Web黎明期の計測目的）。
「スクレイピング」という発想の源流：Web以前からある「screen scraping（画面の見た目からデータを抜く）」の延長線上にWebスクレイピングがある。

前者は「Webから自動で取りに行く」技術的出発点、後者は「構造化されていない表示からデータ化する」発想の出発点です。どちらを採用するかで答えが変わります。

年表で整理する

スクレイピングは、Webの誕生→クローラーの登場→制御（robots.txt）→APIの一般化、という流れで実務が形作られてきました。

年	出来事	スクレイピングへの影響
1989	Tim Berners-LeeがWWWをCERNで提案	「Webという対象」が誕生する前段
1990	最初期のWebサーバ・ブラウザがCERNで稼働	HTML/HTTP/URLの基盤が整う
1993	CERNがWWWソフトウェアを公開（4/30）	Web普及が加速し「収集対象」が急増
1993	World Wide Web Wandererが稼働（6月〜）	自動巡回（クローリング）の黎明
1994	Robots Exclusion Protocol（robots.txt）が提案	「収集してよい範囲」を示す作法が生まれる
2000	企業APIが普及（例：eBayやSalesforceの公開API）	「HTMLではなくAPIで取得」が現実的な選択肢に
2022	Robots Exclusion ProtocolがRFC 9309として標準化	robots.txtが「慣習」から「仕様」へ近づく

Webの誕生についてはCERNの解説が分かりやすく、1989年の提案、1990年の稼働、1993年の公開が大きな節目です（特に1993年4月30日の公開は普及を決定づけました）。

参考：CERN: The birth of the Web、CERN: Where the web was born

技術の源流は？

screen scrapingの系譜

「スクレイピング」という言葉自体は、Webより前からある「screen scraping（画面スクレイピング）」の延長で理解するとズレが少ないです。画面表示（UI）を”逆算”してデータ化する発想で、WebページをHTMLとして解析する前段階の時代にも用いられてきました。

注意

近年は「screen scraping」という語が、セキュリティ文脈（個人情報の窃取など）で説明されることもあります。用語が同じでも文脈が異なるため、社内資料や顧客向け文書では定義を書いておくと安全です。

Webスクレイピングの成立

Webスクレイピングは、(1)HTTPでページを取得し、(2)HTMLから欲しい要素を抽出する、という2工程で説明されます。Wikipediaの「Web scraping」項目でも、取得（fetching）と抽出（extraction）を分けて整理しています。

参考：Wikipedia: Web scraping

robots.txtの意味

慣習から仕様へ

robots.txt（Robots Exclusion Protocol）は、1994年に提案された「クローラーに対するアクセス指針」です。法的な強制力そのものではなく、基本は任意遵守ですが、少なくとも技術的・運用的には”無視しない”のがプロフェッショナルな前提になっています。

公式ドキュメントによると

RFC 9309は、1994年にMartijn Kosterが定義したRobots Exclusion Protocolを「仕様化し拡張する」文書として公開されています（公開は2022年9月）。

参照：IETF RFC 9309: Robots Exclusion Protocol

実務での扱い

実務では、robots.txtは「技術的ルール」だけでなく、相手サイトの意向（許容範囲）のシグナルとして扱われます。特にB2Bのデータ収集や継続運用では、無視した結果としてブロックや法務対応に発展し、コストが跳ね上がることが珍しくありません。

API普及で変化

APIは代替ルート

2000年前後からWeb APIが広がり、「HTMLを解析して取る」以外に「APIで取る」ルートが現実的になりました。Wikipediaの整理でも、2000年にSalesforceやeBayがAPIを公開したことが触れられています。

ただし万能ではない

APIがあっても、必要な項目が提供されない、レート制限が厳しい、商用プラン前提などの理由で、スクレイピングが選ばれることはあります。逆に、APIがあるのにHTMLを叩くと、規約違反や過負荷のリスクが上がります。

これからどうなる

防御は強くなる

今後は、WAF/CDN、ボット判定、動的レンダリング、行動分析などにより、単純なHTTP取得＋HTMLパースは通りにくくなります。結果として「取得手段の高度化（ブラウザ自動化、レンダリング対応、分散実行）」が必要になりますが、同時にコストと運用難度も上がります。

ルール順守が重要

技術だけで押し切る運用は長続きしません。robots.txt、利用規約、著作権、個人情報（PII）などの観点で、取得可否・保存可否・再配布可否を分けて判断する流れが強まります。

「契約で解く」が増える

継続的にデータが必要なら、サイト運営者との合意（API契約、データ提供契約、パートナー制度）で解決するケースが増えます。短期的には遠回りに見えても、長期の停止リスクや法務リスクを抑えられます。

用途は二極化する

スクレイピング用途は、(1)公開情報のモニタリング（価格・在庫・求人・不動産など）と、(2)研究・監査的なデータ収集（アーカイブ、透明性確保）に分かれていきます。前者はビジネス要件が強く、後者は倫理・公益・説明責任が問われやすい領域です。

最小の実装例

最後に、学習用として「取得→抽出」の最小例を載せます。実運用ではレート制限、再試行、robots.txt確認、利用規約確認、ログ保全などが必要です。

import requests
from bs4 import BeautifulSoup

url = "https://example.com/"
res = requests.get(url, timeout=10)
res.raise_for_status()

soup = BeautifulSoup(res.text, "html.parser")

# 例：h1テキストを抽出
h1 = soup.select_one("h1")
print(h1.get_text(strip=True) if h1 else "(no h1)")

注意

このコードは「技術的に可能」を示すだけです。取得対象サイトのrobots.txtや利用規約に反する自動取得は、ブロックやトラブルの原因になります。

よくある質問

いつが始まり？

「Web上の自動巡回」という意味では1993年6月（World Wide Web Wanderer）が代表的な起点です。一方で「表示からデータを抜く」発想はscreen scrapingの系譜としてWeb以前から存在します（定義で答えが変わります）。

robots.txtは絶対？

robots.txtは任意遵守の仕組みですが、少なくとも運用上は「無視しない」が基本です。さらに2022年9月にRFC 9309として仕様化され、解釈のブレが減る方向に進んでいます。

今後も必要？

必要性は残ります。ただし、APIや契約による提供が増え、スクレイピングは「代替手段」や「監視・検証手段」としての色合いが強くなるでしょう。

収集を安定化しませんか？

サイト側の対策が強まるほど、取得設計と運用が成否を分けます。要件整理から取得方式の選定、運用監視まで一緒に最適化します。

お問い合わせスクレイピングに関するご相談・お見積もりはお気軽にどうぞ

相談する

まとめ

Webスクレイピングの「始まり」は定義次第ですが、Web上の自動巡回という観点では1993年6月のWorld Wide Web Wandererが重要な節目です。1994年のrobots.txt提案、2000年前後のAPI普及、2022年9月のRFC 9309標準化を経て、スクレイピングは「できるか」より「どう安全に継続するか」が中心テーマになりました。これからは技術・ルール・運用をセットで設計することが、最も堅実な戦略です。