【ITニュース解説】Why Post-Fetch Filtering on LinkedIn Guest Pages Drops Your Dataset Yield

LinkedInから求人情報を自動的に集める「スクレイパー」というツールを使うとき、いくつか知っておくべき技術的な注意点がある。このツールはLinkedInにログインせずに公開されている情報を利用するため、通常の利用方法とは異なる挙動を示すことがある。システムエンジニアとして、このようなツールの特性を理解し、データ収集の効率や信頼性を高める方法を知ることは、今後の開発に役立つだろう。

まず、スクレイパーがどのように求人情報をフィルタリングしているかという重要な点がある。ユーザーが「特定の経験レベル」や「特定の職種」といった条件を指定して求人を探す際、通常はLinkedInのシステムがこれらの条件で絞り込み、関連性の高い求人だけを返すと思うかもしれない。しかし、このスクレイパーはログインせずに公開されている「ゲストページ」から情報を取得するため、LinkedInはゲストユーザーに対して詳細な検索フィルタリング機能を提供していない。そのため、スクレイパーはまず、指定されたキーワードに合う求人情報を大量に取得し、その後にツール内部で、ユーザーが設定した条件に合わないデータを捨てるという処理を行う。これを「取得後フィルタリング」と呼ぶ。この方式には問題があり、例えば「最大100件のデータを取得する」と設定しても、取得された大量のデータの中からフィルタリングでほとんどが捨てられてしまうと、最終的に手元に残るデータはごくわずかになってしまう可能性がある。スクレイパーが裏側で多くの情報を処理していても、ユーザーが期待するデータ量が得られないという事態が発生するのだ。

このようなデータの取得効率の低下を検知するには、スクレイパーの実行が完了した後、最終的に手元に残ったデータ数をプログラムで確認することが重要である。取得されたデータ数が、事前に決めた最低限必要な数を下回っていた場合、自動的に警告を発する仕組みを導入すべきだ。ApifyのAPIクライアントを使えば、スクレイパーの実行結果や最終的なデータセットの情報を簡単に取得できるため、手元に届く求人情報が少なすぎるときにすぐ気づくことができる。

次に、求人情報の「詳細度」についても理解が必要である。このスクレイパーには「standard（標準）」と「full（完全）」という二つの詳細度設定があり、デフォルトは「standard」だ。「full」モードに変更すると、スクレイパーの挙動は大きく変わる。具体的には、「full」モードでは、一つの求人情報を取得するのに「standard」モードに比べて約5倍から7倍の時間がかかるとされている。さらに重要なことに、「full」モードでは求人への「応募URL」が取得できない。「standard」モードでは静的な応募リンクが取得できるのに対し、「full」モードではLinkedInがJavaScriptを使って動的に生成するボタンから情報を取得するため、静的なURLを抽出できないという技術的な制約があるからだ。また、「full」モードでは会社情報も詳細に取得しようとするが、もし検索結果に多数の異なる会社からの求人が含まれていた場合、それらすべての会社情報を取得するために追加のウェブアクセスが多数発生し、処理時間が大幅に増加する。このため、スクレイパーの実行時間は、入力した検索条件だけでなく、検索結果に含まれる会社数によって大きく変動することになる。もし応募URLが欲しい場合は、「standard」モードを選ぶ必要がある。

スクレイピングで得られるデータの構造が常に一定ではないという点も知っておくべきである。例えば、求人情報に給与が記載されていない場合、その情報が「null」として含まれるのではなく、「給与」に関する項目自体がJSONデータから完全に省略される。会社情報についても同様で、会社概要がなければその項目が存在しないことになる。このような変動的なデータ構造に対応するためには、プログラムでデータを解析する際に、「辞書のキーが存在するかどうか」を常に確認しながら安全に値を取り出す工夫が必要だ。Pythonであれば .get() メソッドを使って、キーが存在しない場合でもエラーにならずにデフォルト値を返すように実装することで、プログラムが途中でクラッシュするのを防ぎ、多様なデータに対応できる堅牢な処理を構築できる。

また、LinkedInのゲスト検索エンジンは、ロケーション（場所）の入力に関して厳格なルールを持っている。検索する場所の名前は、必ず「英語」で入力する必要がある。例えば、「ドイツ」を「Deutschland」と入力したり、「ロンドン」を「Londres」と入力したりすると、LinkedInは場所を正しく認識できず、検索が失敗したり、意図せずグローバル検索になったり、あるいは「何も見つからなかった」という結果を返すことがある。スクレイパーはこの入力のスペルや言語を自動で修正しないため、一見成功したように見えても、結果が空という状況に陥ることがあるので注意が必要だ。

Apifyプラットフォームを使う上で、API呼び出しのタイムアウトにも注意が必要である。同期的にスクレイパーを起動した場合、300秒（5分）を超えると自動的に接続が切断されてしまう。特に複数の場所を対象としたり、会社情報を詳細に取得しようとしたりする複雑なスクレイピングでは、5分を超えることは容易に起こりうる。このような問題を避けるためには、スクレイパーを「非同期」で起動する必要がある。非同期起動では、スクレイパーの実行を指示したらすぐに「実行ID」を受け取り、実際の処理は裏側で行われる。ユーザーは後からこのIDを使って実行状況を確認したり、処理が完了したときに通知を受け取ったりすることで、タイムアウトエラーを防ぎ、より大規模なスクレイピングを安定して実行できる。

さらに、Apifyのリクエストキューという仕組みには「一つのキューは一度に一つのスクレイパーしか処理できない」という制約がある。もし複数のスクレイパーを同時に動かして速度を上げたい場合でも、同じリクエストキューを共有しようとするとエラーが発生する。そのため、スループットを向上させるには、それぞれのスクレイパーが完全に独立したリクエストキューを持つように設定し、個別に実行する必要がある。異なるタスク間で重複するデータが出ないようにするには、以前の実行で取得したIDを次の実行の入力に渡し、重複を除外する機能を利用することができる。

このスクレイパーは「PAY_PER_EVENT（イベントごとの課金）」モデルで料金が発生する。これは、スクレイパーの起動時と、最終的にデータセットに書き込まれた「結果」の件数に応じて課金される仕組みだ。イベント料金に加えて、スクレイパーが消費するコンピューティングリソース（メモリやCPU時間など）に対しても、Apifyのプランに応じたプラットフォーム利用料が別途発生する。したがって、全体のコストを把握するためには、イベント料金だけでなくプラットフォーム利用料も考慮に入れる必要がある。特に、取得後フィルタリングで多くのデータを取得してから捨てる場合、捨てたデータ自体には結果としてのイベント料金はかからないが、それらを処理するために消費されたプラットフォーム利用料は発生するため、検索フィルタをあまりにも広範に設定すると、効率が悪くなり、予想以上にコストがかかる可能性がある。

このスクレイパーにはいくつかの「限界」も存在する。ログインなしで動作するため、ログインユーザーに限定された求人情報や、プライベートなネットワーク内の求人にはアクセスできない。また、前述したように、経験レベルや職種といったフィルタは取得後フィルタリングに頼るため、データの取得効率が悪い場合がある。加えて、プロキシという技術を使ってウェブサイトにアクセスするが、使用するプロキシの種類によってはセッションの寿命が短く、長時間にわたるスクレイピングで接続が途切れてしまうリスクもある。そして、LinkedInの公開検索エンドポイントは、短時間に大量のアクセスがあるとCAPTCHA（人間かどうかの認証）を要求したり、IPアドレスをブロックしたりすることがあるため、データが全く取得できなくなる場合も考えられる。

これらの特性を踏まえ、このスクレイパーを実際のシステムに組み込む際には、「堅牢なパイプライン設計」を心がけることが不可欠だ。データが不足している場合でもエラーにならないようにする、API呼び出しが失敗した場合の代替策を準備する、プロキシの寿命を考慮して実行時間を調整するといった工夫が必要となる。例えば、Pythonのプログラムを使って、非同期でスクレイパーを起動し、完了するまで定期的にステータスを確認し、取得したデータはキーの存在を安全にチェックしながら処理する、といった実践的なアプローチが推奨される。スクレイパーの入力、出力、制限については、公式のドキュメントを常に確認し、最新の情報に基づいてシステムを設計することが重要だ。