Tony Wang4 分で読めますGoogle Scholar をスクレイピングする方法 2026年版(Python & API)
2026年に Google Scholar の結果(タイトル、著者、被引用数、リンク)を、公式 API がないなかで取得する方法と、なぜスクレイパーをブロックするのか、何が有効かを解説します。
Google Scholar には公式 API がなく、ある程度の規模で収集するのが最も難しい Google プロパティの 1 つです。自動化されたトラフィックに対しては、CAPTCHA と IP バンですぐに立ちはだかります。2026年に実用的な手段は、Scholar の公開されている結果ページを、プロキシとレンダリングを処理する Scraping API 経由で取得し、必要なフィールドをパースすることです。本ガイドでは、なぜ自前実装が壊れるのか、そしてどうすれば確実に行えるのかを解説します。
2026年に公式の Google Scholar API はありますか?
ありません。そして、これまで一度もありませんでした。 Search(限定的な Custom Search JSON API があります)や Maps とは異なり、Google は Scholar API を公開・限定を問わず一度も提供していません。Custom Search 製品は Scholar を明確にカバーしていません。つまり、Scholar をプログラムから照会する公認された構造化された方法は存在せず、あらゆる選択肢 — scholarly ライブラリ、ヘッドレスブラウザ、Scraping API — は公開されている HTML を取得してパースしているだけです。
Google Scholar のスクレイピングは合法ですか?
Scholar は公開されている学術メタデータをインデックスしており、公開データの収集は一般に非公開アカウントへのアクセスとは異なる扱いを受けます。ただし無条件ではありません。
- 公開されている結果データのみを収集してください。ログインが必要なものやペイウォールの奥にある全文は対象外です。
- レート制限を尊重してください。Scholar の防御はサービスを守るためでもあるので、リクエストのペースを抑えてキャッシュしましょう。
- 書誌メタデータ(タイトル、著者、被引用数)は広く再利用できますが、商用で再配布する前に Google の利用規約とお住まいの地域の法律を確認してください。
これは法的助言ではありません。詳しくは2026年、ウェブスクレイピングは合法ですか?をご覧ください。
選択肢 1:Python で自前実装する(そしてなぜ壊れるのか)
最もよく知られた自前実装用ライブラリは、Scholar のフロントエンドをパースする scholarly です。
from scholarly import scholarly
for i, pub in enumerate(scholarly.search_pubs("retrieval augmented generation")):
print(pub["bib"]["title"], pub.get("num_citations"))
if i >= 9:
break
いくつかのクエリまではうまく動き、そこで止まります。繰り返し悩まされるのは次の点です。
- すぐに立ちはだかる CAPTCHA の壁 — Scholar は 1 つの IP からほんの数回の自動リクエストがあると reCAPTCHA を表示します。
scholarly自身も、継続するにはプロキシや CAPTCHA 解決サービスが必要になると明記しています。 - IP バン — データセンター IP はすぐにブロックされます。ある程度の量を継続するには、ローテーションするレジデンシャルプロキシが必要です。
- ページネーションの保証なし — Scholar はどこまで深くページ送りできるかを制限し、結果を並べ替えるため、深い結果セットは信頼できません。
- 壊れやすいパース — HTML はバージョン管理されておらず、予告なく変更されます。
選択肢 2:ノーコードや既製ツール
文献管理ツールやブラウザツールは引用を 1 つ 2 つ取得できますが、保存・結合・スケジュール実行できる構造化された形で、元になる結果セット — タイトル、著者、被引用数、リンク — を提供してくれることはありません。パイプラインや製品に組み込むなら、パース済みのデータが欲しいところです。
選択肢 3:Scraping API 経由で Scholar を取得する
Scholar 専用のエンドポイントはどこにも存在しないため、信頼できるアプローチは、公開されている Scholar の結果 URL を、レジデンシャル IP をローテーションしページをレンダリングする汎用の Web スクレイピングエンドポイント 経由で取得し、結果をパースすることです。プロキシ、リトライ、アンチボット対策は代わりに処理されます。
curl -X POST "https://api.crawlora.net/api/v1/web/scrape" \
-H "x-api-key: $CRAWLORA_API_KEY" \
-H "Content-Type: application/json" \
-d '{"url": "https://scholar.google.com/scholar?q=retrieval+augmented+generation"}'
import requests
from bs4 import BeautifulSoup
h = {"x-api-key": "YOUR_API_KEY"}
q = "retrieval augmented generation"
url = f"https://scholar.google.com/scholar?q={q.replace(' ', '+')}"
# fetch the rendered HTML through the scraping API (handles proxies + anti-bot)
resp = requests.post("https://api.crawlora.net/api/v1/web/scrape",
headers=h, json={"url": url}).json()
html = resp["data"]["html"] # field is illustrative — confirm in the docs
soup = BeautifulSoup(html, "html.parser")
for item in soup.select("div.gs_ri"):
title = item.select_one("h3.gs_rt")
cited = item.select_one("a:-soup-contains('Cited by')")
print(title.get_text(strip=True) if title else "",
cited.get_text(strip=True) if cited else "Cited by 0")
Scraping API が IP ローテーションと CAPTCHA を誘発するフィンガープリントを処理してくれるので、ブロックと戦う代わりに、自分が気にするフィールド — タイトル、著者と掲載媒体、被引用数、結果のリンク — のパースに時間を使えます。
収集できるもの
- 結果のタイトル、著者、掲載媒体、発行年
- 被引用数(「Cited by N」)と、引用している研究へのリンク
- 論文またはそのランディングページへのリンク、および Scholar が提示している場合は PDF へのリンク
- 結果の順位。あるクエリに対する論文の可視性を時系列で追跡するのに役立ちます
制限とよくある課題
- 積極的なブロック。 Scholar は CAPTCHA と IP バンで強力に防御します。Scraping API 経由であっても、リクエストのレートは控えめにし、結果をキャッシュしてください。
- 構造化された API がないため、パースが壊れやすい。 HTML をパースしているので、セレクタは防御的に扱い、ときどきレイアウトが変わることを想定してください。
- 浅く、並べ替えられるページネーション。 Scholar は結果の深さを制限し、関連度で並べ替えます。1 回の取得は、網羅的なインデックスではなく、順位付けされたサンプルとして扱いましょう。
- 被引用数は概算で、遅れがある。 Google の「Cited by」の数値は Google のスケジュールで更新され、他の引用データベースと異なることがあります。
出典
どこで役立つか
まずは無料で試す: 無料ウェブスクレイパーで Scholar の結果 URL を実行するか、アンチボットチェッカーで対象がどれだけ強くボットをブロックするかを確認しましょう。登録は不要です。
Scholar は、一般的なパターンのなかでも手強いターゲットの一例です。API がなく、アンチボットが強力なので、取得をアンブロッカー経由でルーティングしてパースします。より広いツールセットや隣接する検索ソースについては、Google Trends をスクレイピングする方法、Brave Search をスクレイピングする方法、ウェブスクレイピング API の選び方をご覧ください。そもそもなぜ普通のスクリプトがブロックされるのかについては、スクレイパーはローカルでは動くのにサーバーでは 403 を返すをご覧ください。
まずはプレイグラウンドでエンドポイントを試し、API ドキュメントでリクエストとレスポンスのスキーマを読み、料金ページでクレジットのコストを確認することから始めましょう。
よくある質問
Google Scholar に API はありますか?
ありません。そして、これまで一度もありませんでした。限定的な Custom Search JSON API がある Search とは異なり、Google は Scholar API を公開・限定を問わず一度も提供しておらず、Custom Search 製品は Scholar を明確にカバーしていません。あらゆる選択肢 — scholarly の Python ライブラリ、ヘッドレスブラウザ、Scraping API — は、Scholar の公開されている HTML を取得してパースしているだけです。
ブロックされずに Google Scholar をスクレイピングするには?
Scholar は 1 つの IP からほんの数回の自動リクエストがあると reCAPTCHA と IP バンを突きつけてくるため、自前実装のスクリプトはすぐに行き詰まります。実用的なアプローチは、レジデンシャル IP をローテーションし CAPTCHA を誘発するフィンガープリントを処理する Scraping API 経由で Scholar の公開されている結果 URL を取得し、返された HTML からタイトル、著者、被引用数、リンクをパースすることです。それでもリクエストのレートは控えめにし、結果をキャッシュしてください。
Google Scholar をスクレイピングするのは合法ですか?
Scholar は公開されている学術メタデータをインデックスしており、公開データの収集は一般に非公開アカウントへのアクセスとは異なる扱いを受けますが、無条件ではありません。公開されている結果データのみを収集し(ペイウォールの奥にある全文は不可)、レート制限を尊重し、商用で再配布する前に Google の利用規約とお住まいの地域の法律を確認してください。タイトル、著者、被引用数といった書誌メタデータは広く再利用できます。これは法的助言ではありません。