課題
2026年6月のApplyArcによるベンチマークでは、5つのLinkedIn求人スクレイパーを対象に200件の実際の求人取得テストが実施されました。そのうち3つは、約50件保存した時点でアカウントがフラグ付けされるか、サイレントにスロットリングされました。問題なく動作を継続できたのは2つだけでした。
このベンチマークが現状のすべてを物語っています。かつて求人サイトはスクレイピングが容易な対象でした。今ではオープンWeb上で最も難度の高い対象の一部となっています。
求人データに依存するシステム（人員計画、給与ベンチマーク、タレントマッピング、株式リサーチ用の採用シグナル分析など）を構築している場合、そのデータ収集レイヤーは2年前には存在しなかった多層防御に対処する必要があります。Indeedは不審なセッションに対して認証ページを表示します。LinkedInはIPローテーションを跨いでブラウザ側のシグナルを関連付けます。GlassdoorはIP単位ではなくASN単位でレート制限を適用します。ZipRecruiterは、ヘッダーがスクリプトではなく実ユーザーに見える場合にのみレンダリングされるJavaScript内に、給与レンジや投稿日を埋め込んでいます。
つまり「50件保存の壁」はLinkedIn独自の問題ではありません。このカテゴリ全体に共通する性質です。
求人サイトの難易度が上がり続ける理由
2026年に3つの変化が生じ、それらが重なり合いました。
第1に、Bot検知が行動ベース（Behavioral）に移行したことです。かつては静的チェック（User-Agent、IPレピュテーション、秒間リクエスト数）だけでホビー層のスクレイパーを阻止できていました。現在はそうではありません。今日の防御システムはサイト内の回遊行動を監視します。どのページをどの順序でロードしたか、滞在時間はどのくらいか、実ブラウザならキャッシュするJSバンドルを再取得していないかなどをチェックします。この変化についてはBot Detection Went Behavioralで解説しました。求人サイトの訪問者は再現性の高い限られたアクション（検索、クリック、閲覧、保存）を行うため、その一連のフローを省略するスクリプトは検知が容易であり、求人サイトはこの検知手法を早期に導入しました。
第2に、プロキシプールの規模が意味を持たなくなったことです。接続レイヤーでのフィンガープリント相関分析とASNレピュテーションによる防御の前では、5,000万IPのレジデンシャルプールも役に立ちません。この点についてはWhy Proxy Pool Size Stopped Matteringで取り上げました。重要なのは他社より多くの出口を持つことではなく、ターゲットサイトに適した出口を選択することです。
第3に、法的な側面です。IndeedとLinkedInはいずれも訴訟を起こす法務チームを抱えています。収集したデータを販売する事業者にとって、自宅のIPからパブリックスクレイパーを実行する時代は終わりました。
現在のデータ収集構成
2026年においてタレントインテリジェンス業務で成果を出し続けているパターンは、分割スタックです。保護された求人サイトには実ブラウザでレンダリングするフェッチを使用し、他のBotと同じプロバイダーからのアクセスにならないよう慎重に出口を選択します。
FourAのようなプラットフォームでは、2つのプロダクトを連携させることでこれを実現します。
Browserはレンダリング側を処理します。unblocker: trueでURLを送信すると、実際のブラウザセッションからレンダリングされたHTML、cookie、スクリーンショットが返されます。JSが実行され、遅延読み込みフィールドが展開され、基本的なクライアントの多くを検出する接続レイヤーのチェックをリクエストが通過します。プロキシの選択はバックグラウンドで実行されます。プラットフォームはリクエストごとに出口を選択し、レスポンスでその不透明なbase36 IDを返します（Single/Browserではトップレベルのr.proxy、Autoではr.session.proxy）。そのため、セッションの継続性が必要な場合は、後続の呼び出しで同じ出口を再利用できます。ほとんどの求人掲示板のタスクでは、Autoが適切なエントリーポイントです。各ターゲットが必要とするものに基づいてSingle、Proxy、Browserをオーケストレーションするため、コード側で処理する必要がありません。
import requests
r = requests.post(
"https://api.foura.ai/api/auto",
headers={"Authorization": "Bearer pk_live_..."},
json={
"url": "https://www.example-jobs.com/search?q=data+engineer&l=Remote",
"validate": {
"status": {"accept": [200]},
"data": {"accept": ["data-testid=\"job-card\""],
"fail": ["Just a moment", "captcha"]},
},
},
).json()
# r["data"] or r["body"] — rendered content (Auto picks Single→"data" or Browser→"body" per host)
# r["session"] — { "proxy": "<base36 id>", "cookies": [...], "userAgent": "..." }
# Reuse r["session"]["proxy"] on the next call to stick to the same exit, or pass it
# via `ignoreProxies: [<id>]` to force a different one.
これが実際に何をもたらすかについて、2点補足します。
ApplyArc形式の50件保存制限は、主にプールの問題ではなくセッションの問題です。適切にローテーションされた本物のブラウザセッションは、生のHTTPクライアントよりもはるかに長くレートリミットに引っかかることなく機能します。また、レスポンスには生の出口IPではなく不透明なproxy IDが含まれるため、どの出口がどのrequestを処理したかを追跡する必要がなく、コードをシンプルに保てます。
2点目は、スニペットに含まれていない部分についてです。求人サイト間の重複排除（LinkedIn、Indeed、企業の採用ページにある同じデータエンジニアの職種で、タイトルがわずかに異なる場合など）は、収集レイヤーではなく自社側の課題です。これを見誤るチームを多く見てきました。正規化はデータ取得よりも多くのエンジニアリング時間を消費し、大半のタレントインテリジェンス製品が最終的に差別化を図る領域でもあります。
結果
3つの求人サイトにわたって200社を追跡するタレントインテリジェンスチームの場合、検索結果、求人詳細ページ、時折発生する企業ページの更新を含め、週におよそ50,000回のページフェッチが必要です。そのワークロードで目指すべき指標は次のとおりです。
- Indeedクラスのターゲットで95%以上の成功率。ここでの成功とは、給与帯と掲載日が入力された状態でレンダリングされたHTMLを指します。
- レンダリングと出口ノード選択を含め、エンドツーエンドで求人あたり0.004ドル未満のコスト。
- 採用シグナルダッシュボードが市場から遅れないようにするための、アクティブな求人に対する6〜12時間の更新頻度。
これらの数値は、この分離スタックパターンを実行しているチームの報告に基づく目安です。実際のコストは、ターゲットとする求人サイトや、新規投稿をどれだけ積極的にフィルタリングするかによって異なります。
主なまとめ
求人サイトの難易度は現在、一般的なEコマースよりもアドテクやチケット販売サイトに近づいています。これは大きな変化であり、2024年に機能していたスクレイピングライブラリが2026年に同じ壁にぶつかり続ける理由を説明しています。
これを乗り越えてスケールするチームは、「スクレイパー」を作業単位として捉えるのをやめています。セッション、出口、重複排除を3つの独立した関心事として捉え、前者の2つにはインフラを導入することで、エンジニアが3つ目の課題に集中できるようにしています。最も安価な求人データとは、フラグが立った後に再収集する必要がなかったデータです。