課題
2026年6月のApplyArcによるベンチマークでは、実際の求人抽出200件を対象に、5つのLinkedIn求人スクレイパーをテストしました。そのうち3つは、約50回の保存（saves）の後にアカウントがフラグされるか、密かにスロットリングされました。クリーンに生き残ったのはわずか2つだけでした。
このベンチマークがすべてを物語っています。かつて求人サイトは簡単なターゲットでした。今や、それらはオープンウェブで最も困難なターゲットの一部となっています。
求人リストデータに依存するプロダクト（労働力計画、給与ベンチマーク、タレントマッピング、投資調査用の採用シグナルなど）を構築している場合、その収集レイヤーは2年前には存在しなかった多層防御のスタックと戦うことになります。Indeedは、見慣れないセッションに対してCAPTCHAを要求します。LinkedInは、IPローテーションをまたいでブラウザ側のシグナルを関連付けます。Glassdoorは、IPごとではなくASNごとにrate limitを適用します。ZipRecruiterは、給与幅や掲載日をJavaScript内に配置し、headerがスクリプトではなく人間のように見える場合にのみレンダリングされるようにしています。
したがって、50-saveの壁はLinkedInだけの問題ではありません。それはこのカテゴリ全体に共通する性質です。
求人サイトの難易度が上がり続ける理由
2026年に3つの変化が起き、それらが重なり合いました。
1つ目は、ボット検知が行動ベース（behavioral）になったことです。かつては、静的なチェック（User-Agent、IPレピュテーション、秒間リクエスト数）だけでホビーユーザーのスクレイパーを阻止するには十分でした。今は違います。今日の防御システムは、サイト内での動きを監視しています。どのページをどの順序でロードしたか、滞在時間はどのくらいか、本物のブラウザならキャッシュするはずの同じJSバンドルを再取得していないか、といった点です。この変化については、Bot Detection Went Behavioralで解説しました。求人サイトがこれを早期に導入したのは、訪問者の行動パターン（検索、クリック、閲覧、保存）が少なく、繰り返し行われるため、シーケンスの半分をスキップするスクリプトを容易に特定できるからです。
2つ目は、proxyプールのサイズが重要ではなくなったことです。接続レイヤーでのフィンガープリント相関分析とASNレピュテーションによる防御の前では、5000万規模の住宅用IP（residential pool）も役に立ちません。これについては、Why Proxy Pool Size Stopped Matteringで取り上げました。効果的なのは、他者よりも多くの出口（exit）を持つことではなく、ターゲットサイトに適した正しい出口を選択することです。
3つ目は法的要因です。IndeedとLinkedInは、いずれも訴訟を起こす法務チームを擁しています。収集したデータを販売することを計画している場合、自宅のIPから公開スクレイパーを実行する時代は終わりました。
現在のデータ収集のあり方
2026年のタレントインテリジェンス業務において、機能し続けているパターンは「分割スタック」です。保護された求人サイトに対しては本物のブラウザでレンダリングされたフェッチを行い、さらに他のボットと同じプロバイダーからアクセスしていると見なされないよう、慎重に出口を選択します。
FourAのようなプラットフォームを使用する場合、これは2つのプロダクトが相互に連携することを意味します。
Browserがレンダリング側を処理します。unblocker: trueを指定してURLを送信すると、レンダリングされたHTML、cookie、および本物のブラウザセッションからのスクリーンショットが返されます。JSが評価され、遅延ロードされるフィールドが入力され、requestはほとんどの基本的なクライアントを検出する接続レイヤーのチェックを通過します。proxyの選択はバックグラウンドで実行されます。プラットフォームはrequestごとに出口を選択し、response（Single/Browserではトップレベルのr.proxy、Autoではr.session.proxy）に不透明なbase36 IDを返します。これにより、セッションの継続性が必要な場合に、後続の呼び出しで同じ出口を再利用できます。ほとんどの求人サイトの作業において、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-saveの壁」は、主にセッションの問題であり、プールの問題ではありません。適切にローテーションされた本物のブラウザセッションは、生のHTTPクライアントよりも、rate limitに達するまでにはるかに長く持ちこたえます。そして、responseには生の出口ではなく不透明なproxy IDが含まれているため、コードをシンプルに保つことができ、どの出口がどのrequestを処理したかを追跡する必要がありません。
2つ目の注意点は、スニペットに含まれて「いない」部分についてです。異なる求人サイト間での重複排除（LinkedIn、Indeed、および企業の自社採用ページにある同じデータエンジニアの職種で、3つのわずかに異なるタイトルがある場合など）は、収集レイヤーではなく、あなた自身の課題です。私たちは、多くのチームがこの点を過小評価しているのを見てきました。データの正規化は、データの取得よりも多くのエンジニアリング時間を消費し、ほとんどのタレントインテリジェンス製品が最終的に競合する部分となります。
結果
3つの求人サイトにわたり200社を追跡するタレントインテリジェンスチームは、週に約50,000回のページフェッチ（検索結果、求人詳細ページ、および時折行われる会社ページの更新）を必要とします。このワークロードにおいて達成を目指すべき数値は以下の通りです。
- Indeedクラスのターゲットで95%以上の成功率。ここでいう成功とは、給与幅と掲載日が入力されたレンダリング済みのHTMLを取得できることを指します。
- 求人1件あたりのコストがエンドツーエンドで0.004ドル未満。これにはレンダリングと出口の選択が含まれます。
- アクティブな職種に対する6〜12時間の更新間隔。これにより、採用シグナルのダッシュボードが市場から遅れるのを防ぎます。
これらの数値は、この分割スタックパターンを実行しているチームからの報告に基づく例示です。実際のコストは、ターゲットとする求人サイトや、新規投稿をどの程度積極的にフィルタリングするかによって異なります。
結論
現在、求人サイトの難易度は、一般的なeコマースよりもアドテックやチケット販売サイトに近くなっています。これは大きな変化であり、2024年に機能していたスクレイピングライブラリが、なぜ2026年になっても同じ壁に突き当たり続けるのかを説明しています。
この壁を越えてスケールするチームは、「スクレイパー」を作業の単位として考えるのをやめています。彼らはセッション、出口、重複排除を3つの独立した関心事として捉え、最初の2つについてはインフラストラクチャを購入することで、エンジニアが3つ目の課題に時間を費やせるようにしています。最も安価な求人リストデータとは、フラグを立てられた後に再収集する必要がなかったデータのことです。