メインコンテンツへスキップ
LinkedInは、職業ID、企業データ、求人、投稿が集まる一方で、もっとも慎重に扱うべきスクレイピング対象の1つです。技術的には公開ページに有用なシグナルがありますが、ログインウォール、rate limit、アカウント制限、自動化検知が強く、規約・プライバシー上のリスクも大きくなります。 公開データだけを、許可された用途で、必要最小限に収集します。本番用途では公式API、licensed data、managed providerを検討します。

​
ページ種別

Bright DataのLinkedIn Scraper APIはprofiles、companies、jobs、postsに分かれています。Apifyのactorも同様です。LinkedInは1つのworkflowではなく、ページ種別ごとに分けるのが自然です。

​
公開アクセスとログイン

公開プロフィールや求人はログインなしでも一部見える場合があります。一方、検索やpeople discoveryはログインを要求されやすく、個人アカウントを使う自動化はリスクが高くなります。長時間スクロールする個人アカウント前提の設計は避けます。

​
求人データ

求人は比較的扱いやすい対象です。title、company、company URL、location、job URL、date posted、employment type、seniority、description、applicant countを取得します。求人は単なるlistingではなく、採用意欲、成長領域、技術導入のシグナルとして使えます。

​
プロフィールと企業ページ

プロフィールでは、公開されている最小限のフィールドに限定します。企業ページでは、会社名、website、industry、headquarters、company size、description、public page URL、公開投稿を中心にします。営業利用ではopt-out、suppression、retention ruleをCRM側と接続します。

​
技術上の課題

LinkedInでは、login prompt、rate limit、dynamic rendering、search result limit、session/fingerprint check、layout variationが起こります。prebuilt toolはpagination、retry、field mappingを助けますが、責任ある用途設計を代替するものではありません。 hiQ v. LinkedInは公開LinkedInデータのスクレイピング議論に大きな影響を与えましたが、すべてのLinkedInスクレイピングを安全にしたわけではありません。契約、プライバシー、規約、アカウントアクセスの問題は残ります。これは法的助言ではないため、本番利用ではlegal reviewを入れてください。 実務上は、求人や企業レベルの公開情報の方が、profile-heavyな個人データセットより扱いやすいことが多いです。