2026年4月時点で、GitHubで「linkedin scraper」を検索すると、およそが見つかります。その大半は、時間の無駄になるでしょう。 きつい言い方でしょうか。たぶんそうです。ただ、私が目立つリポジトリ8件を監査し、何十本ものGitHub issueスレッドを読み、Redditやスクレイピング系フォーラムのコミュニティ報告を突き合わせた結果は、まさにそうでした。パターンは毎回同じです。スター数の多いリポジトリは注目を集め、LinkedInの対ボット担当チームがコードを分析し、検知対策は修正され、ユーザーは壊れたセレクター、CAPTCHAループ、あるいはアカウント停止に行き着きます。あるRedditユーザーは現状を率直にこう表現していました。LinkedInは「より厳しいレート制限、より優れたボット検知、セッショントラッキング、頻繁な変更」を導入しており、古いツールは今や「すぐ壊れるか、アカウントやIPがフラグされる」とのことです。営業担当、採用担当、あるいはオペレーション担当として、スプレッドシートでLinkedInデータを扱いたいなら、先月クローンしたそのリポジトリは、もう使い物にならないかもしれません。このガイドは、どのGitHubプロジェクトが本当に時間をかける価値があるのか、どうすればアカウントを焼かれずに済むのか、そして、そもそもコードを使わないほうが合理的なのはいつか、を見極めるためのものです。
GitHubのLinkedInスクレイパーとは？
GitHub上のLinkedInスクレイパープロジェクトは、LinkedInページから構造化データを抽出する処理を自動化するオープンソースのスクリプトです。通常はPython、場合によってはNode.jsで書かれています。典型的な対象は次のとおりです。
- 人物プロフィール：氏名、肩書き、会社、所在地、スキル、職歴
- 求人情報：職種名、企業名、勤務地、掲載日、求人URL
- 企業ページ：概要、従業員数、業界、フォロワー数
- 投稿とエンゲージメント：本文、いいね、コメント、シェア
内部では、多くのリポジトリが2つのどちらかの方式を採用しています。ブラウザ駆動型のスクレイパーは、Selenium、Playwright、Puppeteerを使ってページを描画し、画面遷移をクリックで進め、CSSセレクターやXPathでデータを抽出します。もう少し少数派ですが、LinkedInの内部API（非公開）エンドポイントを直接叩こうとするものもあります。さらに新しい流れとして、GitHubではまだ少数ですが増えつつあるのが、ブラウザ自動化にGPT-4o miniのようなLLMを組み合わせ、壊れやすいセレクターに頼らずページテキストを構造化フィールドへ変換する手法です。
ただし、ここには根本的な利用者のズレがあります。こうしたツールは、仮想環境、ブラウザ依存関係、プロキシ設定に慣れた開発者向けに作られています。一方で、「linkedin scraper github」と検索する人の多くは、採用担当者、SDR、RevOpsマネージャー、創業者などで、欲しいのはただスプレッドシートの行だけです。
このギャップが、issueスレッドで見られる大半の不満の理由です。
なぜLinkedInスクレイピングにGitHubを使うのか
魅力は明白です。無料。カスタマイズ可能。ベンダーロックインなし。データパイプラインを完全に自分で管理できる。SaaSツールの価格が変わったり、サービス終了したりしても、コードは残ります。
| ユースケース | 必要とする人 | 一般的に抽出するデータ |
|---|---|---|
| リード獲得 | 営業チーム | 氏名、肩書き、企業名、プロフィールURL、メールの手がかり |
| 候補者探索 | 採用担当 | プロフィール、スキル、職歴、所在地 |
| 市場調査 | オペレーション／戦略チーム | 企業データ、従業員数、求人情報 |
| 競合インテリジェンス | マーケティングチーム | 投稿、エンゲージメント、企業更新情報、採用動向 |
ただし、「無料」はライセンス上のラベルであって、運用コストではありません。実際のコストは次のとおりです。
- セットアップ時間：扱いやすいリポジトリでも、環境構築、ブラウザ依存関係、Cookie抽出、プロキシ設定に30分〜2時間以上かかることがある
- 保守：LinkedInはDOMや対ボット対策を頻繁に変えるため、今日動くスクレイパーが来週には壊れることがある
- プロキシ：住宅用プロキシの帯域は、プロバイダとプランによってほどかかる
- アカウントリスク：一番高くつくのはLinkedInアカウントで、プロキシIPのように代替できるものではない
リポジトリ健全性スコアカード：あらゆるLinkedInスクレイパー GitHubプロジェクトをどう評価するか
「おすすめLinkedInスクレイパー」系の記事の多くは、スター数でリポジトリを並べています。しかしスター数は、過去の関心を示すだけで、現在の動作状況を示すものではありません。3,000スターあっても2022年以降コミットがないリポジトリは、実用ツールではなく博物館の展示品です。
git cloneする前に、次のフレームワークを使ってください。
| 評価基準 | 重要な理由 | 赤信号 |
|---|---|---|
| 最終コミット日 | LinkedInはDOMを頻繁に変更する | ブラウザ駆動型で6か月以上前 |
| open/closed issue比率 | メンテナの対応速度 | openがclosedの3倍超、特に最近の「blocked」や「CAPTCHA」報告が多い |
| 対検知機能 | LinkedInは容赦なくBANする | READMEにCookie、セッション、速度調整、プロキシの記載がない |
| 認証方式 | 2FAとCAPTCHAでログインフローが壊れる | パスワードだけのヘッドレスログインしか対応していない |
| ライセンス種別 | 商用利用時の法的リスク | ライセンスなし、または条件が曖昧 |
| 対応データ型 | 用途によって必要なリポジトリは異なる | 必要なのに1種類のデータしか扱えない |
一番時間を節約できるコツは、どのリポジトリでも使う前にIssueタブで「blocked」「banned」「CAPTCHA」「not working」を検索することです。最近のissueがそうした語句だらけで、メンテナの返答がないなら、次へ進んでください。そのリポジトリは、もう負けています。
2026年の監査で実際に分かったこと
GitHub上で目立つLinkedInスクレイパーリポジトリ8件に、このスコアカードを適用しました。結果は、あまり明るいものではありませんでした。
| リポジトリ | スター数 | 最終コミット | 2026年も動く？ | 主な対象 | 主なメモ |
|---|---|---|---|---|---|
| joeyism/linkedin_scraper | 約3,983 | 2026年4月 | ✅ 条件付きで可 | プロフィール、企業、投稿、求人 | Playwrightベースへ再実装、セッション再利用あり。ただし最近のissueではセキュリティブロックや求人検索の破損が見られる |
| python-scrapy-playbook/linkedin-python-scrapy-scraper | 約111 | 2026年1月 | ✅ チュートリアル／公開データ向け | 人物、企業、求人 | ScrapeOpsプロキシ統合。無料プランは1スレッドで月1,000リクエストまで可 |
| spinlud/py-linkedin-jobs-scraper | 約472 | 2025年3月 | ⚠️ 求人のみ | 求人 | Cookie対応、実験的なプロキシモードあり。公開求人情報だけ欲しいなら有用 |
| madingess/EasyApplyBot | 約170 | 2025年3月 | ⚠️ 用途違い | Easy Apply自動化 | データスクレイパーではない。求人応募を自動化するツール |
| linkedtales/scrapedin | 約611 | 2021年5月 | ❌ | プロフィール | READMEには今でも「2020年に動作」とある。issueではPIN認証やHTML変更の問題が見られる |
| austinoboyle/scrape-linkedin-selenium | 約526 | 2022年10月 | ❌ | プロフィール、企業 | 以前は有用だったが、2026年には古すぎる |
| eilonmore/linkedin-private-api | 約291 | 2022年7月 | ❌ | プロフィール、求人、企業、投稿 | 非公開APIラッパー。非公開エンドポイントは予測不能に変わる |
| nsandman/linkedin-api | 約154 | 2019年7月 | ❌ | プロフィール、メッセージ、検索 | 歴史的には興味深いが、約900リクエスト/時のレート制限警告が文書化されている |
2026年の読者にとって、重い注意書きなしで実用的に使えそうだったのは、8件中わずか2件でした。これは特別な例外ではなく、GitHub上のLinkedInスクレイピングではむしろ普通です。
BAN防止の実践策：プロキシ、レート制限、アカウント保護
アカウント停止は、運用上の最大リスクです。技術的には優秀なスクレイパーでも、ここで失敗します。コードは動いても、アカウントが持ちません。ユーザー報告では、プロキシと長い待機を入れていても、でフラグが立った例があります。
レート制限：コミュニティ報告はどうなっているか
完全に安全な件数は存在しません。LinkedInは生の件数だけでなく、セッションの経過時間、クリックのタイミング、バーストのパターン、IPの信用度、アカウントの挙動を評価します。コミュニティデータは、おおむね次の帯に集まっています。
- あるユーザーは、プロキシと33秒間隔でも40〜80件のプロフィールで検知されたと報告
- 別のユーザーは、1アカウント1日30件前後に抑えるべきと助言
- より攻めた運用者は、を1日を通して分散させたと主張
- では、約1時間に900リクエストで内部レート制限警告が出ることが文書化されている
実務的な結論としては、1アカウントあたり1日50件未満のプロフィール閲覧が低リスク帯です。1日50〜100件は中リスクで、セッションの質がかなり重要になります。1日100件超/アカウントは、かなり攻めた領域です。
プロキシ戦略：住宅用 vs データセンター
LinkedInでは、通常のユーザー通信に見えやすい住宅用プロキシが標準です。データセンターIPは安いものの、高度なサイトでは検知されやすく、LinkedInはまさにそうした「安いトラフィックが見つかりやすい」サイトです。
現在の価格感は次のとおりです。
- ：プランによって**$3.00〜$4.00/GB**
- ：プランによって**$4.00〜$6.00/GB**
回転はリクエスト単位ではなく、セッション単位で行ってください。リクエストごとに切り替えると、単一IPよりも「プロキシ基盤です」と強く示す指紋になります。
捨てアカウントの運用ルール
この点については、コミュニティの助言はかなりはっきりしています。メインのLinkedInアカウントを、使い捨てのスクレイピング基盤として扱わないでください。
アカウントを使ったスクレイピングをどうしてもやるなら、次を守ってください。
- 本業のプロフィールとは別アカウントを使う
- プロフィールをきちんと埋め、数日間は人間らしく振る舞わせてからスクレイピングを始める
- スクレイピング用アカウントに本物の電話番号を紐づけない
- スクレイピングセッションを、実際の営業活動やメッセージ送信と完全に分離する
なお、LinkedInの（2025年11月3日施行）では、虚偽の身元やアカウント共有が明確に禁止されています。捨てアカウント戦略は運用上は一般的ですが、契約上はかなりグレーです。
CAPTCHAへの対処
CAPTCHAは単なる邪魔ではありません。あなたのセッションが、すでに監視対象になっているというサインです。対処法には次のようなものがあります。
- 手動で解いてセッションを続ける
- ログインフローを毎回やり直すのではなく、Cookieを再利用する
- のような解決サービスを使う（画像CAPTCHAは1,000件あたり約$0.50〜$1.00、reCAPTCHA v2は1,000件あたり約$1.00〜$2.99）
ただし、ワークフローが頻繁にCAPTCHAを踏むなら、解決サービスのコストは最優先ではありません。あなたのスタックは、秘匿性の戦いに負けています。
リスクの帯域
| 件数 | リスクレベル | 推奨アプローチ |
|---|---|---|
| < 50件/日 | 低 | ブラウザセッションまたはCookie再利用、低速ペース、強引な自動化はしない |
| 50〜500件/日 | 中〜高 | 住宅用プロキシ、温まったアカウント、セッション再利用、ランダム遅延 |
| 500件超/日 | 非常に高い | 商用API、または対検知機能を内蔵した保守済みツール。公開GitHubリポジトリだけでは通常足りない |
オープンソースの逆説：人気のLinkedInスクレイパー GitHubリポジトリほど壊れやすい理由
ユーザーの懸念はもっともです。「オープンソース版を公開したら、LinkedInは何をしているか見て対策できるのでは？」というものです。その心配は被害妄想ではありません。構造上、正しい懸念です。
見つかりやすさの問題
スター数が多いと、ユーザーからの信頼と、LinkedInのセキュリティチームの標的化、2つのシグナルが同時に立ちます。リポジトリが有名になるほど、LinkedInがその手法を個別に潰す可能性が高まります。
このライフサイクルは監査データにも表れています。linkedtales/scrapedin は、2020年当時のLinkedInの「新しいウェブサイト」で動くと宣伝できるほど、十分に注目されていました。しかし、その後の認証やレイアウト変更に追随できませんでした。nsandman/linkedin-api も、かつては有用なテクニックを示していましたが、最終コミットは現在の対ボット環境よりずっと前です。
コミュニティパッチの強み
オープンソースの本当の利点は1つあります。LinkedInが対策を変えたとき、活発なメンテナやコントリビューターがすばやく修正できることです。今回の監査では joeyism/linkedin_scraper がその代表例でした。依然として認証ブロックや検索破損のissueは出ていますが、少なくとも更新は続いています。フォーク版は、元リポジトリより新しい回避手法を早く実装することがよくあります。
どう対処するか
- 公開リポジトリ1本に、恒久的な基盤として頼らない
- 更新された回避手法を実装する活発なフォークを追う
- 本番用途では、非公開のフォークを保守することを検討する（固有の調整を公開しないため）
- LinkedInが検知やUIの挙動を変えたら、手法も変わると考える
- 1つのツールに全賭けせず、複数の方法を持つ
AIによる抽出 vs CSSセレクター：実務的な比較
2026年における、より興味深い技術的な分岐は、GitHubかノーコードかではありません。セレクタベース抽出か意味理解ベース抽出か、です。この差は、多くの比較記事が認める以上に重要です。
CSSセレクターの仕組みと壊れ方
従来型のスクレイパーは、LinkedInのDOMを解析し、各フィールドをCSSセレクターまたはXPath式に対応付けます。ページ構造が安定しているなら、この方法は非常に優秀です。精度が高く、限界コストが低く、解析も速い。
失敗のしかたも明快です。LinkedInがクラス名、ネスト、遅延読み込みの挙動を変えたり、異なる認証壁の向こうにコンテンツを置いたりすると、スクレイパーは即座に壊れます。監査で見たissueタイトルがそれを物語っています。「HTMLが変わった」「求人検索が壊れた」「値が欠ける」「authwallでブロックされる」。
AI/LLM抽出の仕組み
新しい手法は、概念としてはシンプルです。ページをレンダリングし、表示テキストを集め、モデルに構造化フィールドを出力させる。多くのノーコードAIスクレイパーや、新しいカスタムワークフローの基盤はこれです。
現在の（入力100万トークンあたり$0.15、出力100万トークンあたり$0.60）を使うと、1プロフィールのテキスト抽出は通常1件あたり約$0.0006〜$0.0018です。中規模のワークフローなら、ほぼ誤差レベルです。
直接比較
| 観点 | CSSセレクター / XPath | AI/LLM抽出 |
|---|---|---|
| セットアップ工数 | 高い — DOMを調べ、フィールドごとにセレクターを書く | 低い — 欲しい出力を自然言語で説明するだけ |
| レイアウト変更時の壊れやすさ | すぐ壊れる | 自動で適応する（意味を読める） |
| 構造化フィールドの精度 | セレクターが正しければ約99% | 約95〜98%（たまにLLMの解釈ミスあり） |
| 非構造／可変データへの対応 | 独自ロジックなしでは弱い | 強い — AIが文脈を解釈する |
| 1プロフィールあたりのコスト | ほぼゼロ（計算コストのみ） | 約$0.001〜$0.002（APIトークン費用） |
| ラベル付け／分類 | 別の後処理が必要 | 1回で分類・翻訳・ラベル付けが可能 |
| 保守負担 | 継続的にセレクター修正が必要 | ほぼゼロ |
どちらを選ぶべきか？
非常に大量で、安定していて、エンジニアが管理するパイプラインなら、コスト面ではセレクタベースがまだ勝つことがあります。ですが、数百件規模（数百万件ではない）のプロフィールを扱う中小規模ユーザーの多くにとっては、AI抽出のほうが長期的な投資として優れています。LinkedInのレイアウト変更で失う開発者工数のほうが、モデルのトークン代より高くつくからです。
GitHubリポジトリが過剰なとき：ノーコードという選択肢
「linkedin scraper github」と検索する人の多くは、ブラウザ自動化の保守担当になりたいわけではありません。
欲しいのは、表の行です。
issueスレッドでは、GitHub系スクレイパーの使い勝手に対する不満がはっきり出ています。「2FAに対応していないし、UIがないので使いやすくない」。利用者には採用担当、SDR、オペレーション担当が含まれており、Python開発者だけではありません。
作るか、買うか
| 観点 | GitHubリポジトリ | ノーコードツール（例：Thunderbit） |
|---|---|---|
| セットアップ時間 | 30分〜2時間超（Python、依存関係、プロキシ） | 2分未満（拡張機能を入れてクリック） |
| 保守 | LinkedInが変わるたび自分で直す | ツール提供側が更新を担当 |
| 対検知 | プロキシ、遅延、セッションを自分で設定 | ツールに内蔵 |
| データ構造化 | 解析ロジックを自分で書く | AIが自動で項目を提案 |
| 出力先 | 自分でエクスポート経路を作る | Excel、Google Sheets、Airtable、Notionへワンクリック |
| コスト | 無料リポジトリ + プロキシ代 + あなたの時間 | 無料枠あり。大量利用はクレジット制 |
ThunderbitがコードなしでLinkedInスクレイピングを処理する方法
は、GitHubリポジトリとは別のやり方でこの問題に向き合います。セレクターを書いたり、ブラウザ自動化を設定したりする代わりに、次のように使います。
- をインストールする
- 任意のLinkedInページ（検索結果、プロフィール、企業ページ）へ移動する
- 「AIで項目を提案」をクリックする — ThunderbitのAIがページを読み取り、構造化された列（氏名、肩書き、会社、所在地など）を提案する
- 必要に応じて列を調整し、抽出を実行する
- Excel、Google Sheets、、またはNotionへ直接エクスポートする
Thunderbitは毎回AIでページを意味的に読むため、LinkedInがDOMを変えても壊れません。これは、カスタムPythonスクリプトにGPTを組み込む場合の利点と同じですが、コードベースを自分で保守するのではなく、ノーコード拡張機能として使える点が違います。
— 検索結果一覧から個々のプロフィールを開いて、データ表を充実させる作業 — も、Thunderbitなら自動で処理できます。ログイン必須ページでも、別途プロキシ設定なしでブラウザモードが使えます。
それでもGitHubリポジトリを使うべき人は？
GitHubリポジトリが向いているのは、次のような人です。
- 深いカスタマイズや特殊なデータ型が必要な開発者
- 非常に大量にスクレイピングするため、1クレジットあたりのコストが重要なチーム
- CI/CDパイプラインやサーバー上でスクレイピングを実行する必要がある人
- LinkedInデータをより大きな自動化ワークフローに組み込む人
それ以外、とくに営業、採用、オペレーションの各チームには、が、セットアップと保守の両方をまるごと不要にします。
ステップごと：GitHubのLinkedInスクレイパーを評価し、使う方法
GitHubが正しい選択だと判断したなら、時間の無駄とアカウントリスクを最小化するために、次の段階的なワークフローを使ってください。
STEP 1: リポジトリを検索して候補を絞る
GitHubで「linkedin scraper」を検索し、次で絞り込みます。
- 最近更新されている（過去6か月以内）
- 自分のスタックに合う言語（最も一般的なのはPython）
- 実際の用途に合う範囲（プロフィール、求人、企業のどれか）
動いていそうなものを3〜5件に絞ります。
STEP 2: リポジトリ健全性スコアカードを適用する
先ほどのスコアカードで各リポジトリを評価します。次のいずれかがあれば除外してください。
- 過去1年にコミットがない
- 未解決の「blocked」や「CAPTCHA」issueがある
- パスワード認証しかない
- セッション、Cookie、プロキシの記載がない
STEP 3: 環境をセットアップする
今回の監査で見られた一般的なセットアップコマンドは次のとおりです。
1pip install linkedin-scraper
2playwright install chromium
3pip install linkedin-jobs-scraper
4LI_AT_COOKIE=<cookie> python your_app.py
5scrapy crawl linkedin_people_profileよくあるつまずきは次のとおりです。
session.jsonファイルがない- ブラウザドライバのバージョン不一致（Chromium / Playwright）
- ブラウザのDevToolsからのCookie抽出
- プロキシ認証のタイムアウト
STEP 4: 小規模なテストスクレイプを実行する
まずは10〜20件のプロフィールから始めます。次を確認してください。
- フィールドは正しく解析されているか
- データは十分か
- セキュリティチェックに引っかかったか
- 出力形式は使いやすいか、それとも生のJSONが雑然と出ているだけか
STEP 5: 慎重にスケールする
ランダム遅延（リクエスト間で5〜15秒）、同時実行数の抑制、セッション再利用、住宅用プロキシを追加します。新しいアカウントで、いきなり1日何百件も回さないでください。
STEP 6: データをエクスポートし、構造化する
多くのGitHubリポジトリは、生のJSONまたはCSVを出力します。結局、次の作業が必要になります。
- レコードの重複排除
- 肩書きと企業名の正規化
- CRMやATSへの項目マッピング
- コンプライアンス向けのデータ出典の記録
（この手順を飛ばしたいなら、Thunderbitが構造化とエクスポートを自動で処理します。）
LinkedInスクレイパー GitHub vs ノーコードツール：完全比較
| 観点 | GitHubリポジトリ（CSSセレクター） | GitHubリポジトリ（AI/LLM） | ノーコードツール（Thunderbit） |
|---|---|---|---|
| セットアップ時間 | 1〜2時間超 | 1〜3時間超（+ APIキー） | 2分未満 |
| 技術スキル | 高い（Python、CLI） | 高い（Python + LLM API） | 不要 |
| 保守 | 高い（セレクターが壊れる） | 中程度（LLMは適応するが、コード更新は必要） | なし（提供側が保守） |
| 対検知 | 自前（プロキシ、遅延） | 自前 | 内蔵 |
| 精度 | 動いていれば高い | 高いが、たまにLLMの誤りあり | 高い（AI駆動） |
| コスト | 無料 + プロキシ代 + あなたの時間 | 無料 + LLM API代 + プロキシ代 | 無料枠あり。大量利用はクレジット制 |
| 出力 | 自前（JSON、CSV） | 自前 | Excel、Sheets、Airtable、Notion |
| 最適な人 | 開発者、カスタムパイプライン | 保守を減らしたい開発者 | 営業、採用、オペレーションチーム |
法的・倫理的な考慮事項
短くしますが、ここは飛ばせません。
LinkedInの（2025年11月3日施行）では、ソフトウェア、スクリプト、ロボット、クローラー、ブラウザプラグインを使ってサービスをスクレイピングすることが明確に禁止されています。LinkedInはこれを執行でも裏付けています。
- ：LinkedInがProxycurlに対して法的措置を発表
- ：その件は解決したと発表
- ：Law360が、LinkedInが大規模データスクレイピングをめぐり追加被告を提訴したと報道
hiQ対LinkedInの一連の裁判は公開データアクセスに関する一定のニュアンスを生みましたが、では、契約違反の理論に基づきLinkedInが有利でした。「公開されている」ことは、「商用再利用のために大規模スクレイピングしても明らかに安全」という意味ではありません。
EU関連のワークフローでは、。フランスのデータ保護当局によるは、スクレイピングされたLinkedInデータを、データ保護ルールの対象となる個人データとして規制当局が扱った具体例です。
Thunderbitのような保守済みツールを使っても、法的義務が消えるわけではありません。ただし、セキュリティ反応をうっかり引き起こしたり、レート制限に触れてLinkedInの注意を引いたりするリスクは下がります。
2026年に何が機能し、何が機能しないか
機能するもの
- どのリポジトリでも、まずリポジトリ健全性スコアカードを適用する
- 自動ログインを繰り返すより、Cookie／セッションを再利用する
- アカウントベースのスクレイピングが必要なときは住宅用プロキシを使う
- 小さく、遅く、人間らしいスクレイピングワークフローにする
- 柔軟性をトークン単価より重視するなら、AI支援抽出を使う
- 実際に欲しいのがスクレイパーの所有ではなくスプレッドシート出力なら、を使う
- 1つの公開リポジトリに賭けず、複数の方法を持つ
機能しないもの
- メンテナンス状況や最近のissueを確認せずに、スター数の多いリポジトリをクローンする
- LinkedInにデータセンタープロキシや無料プロキシリストを使う
- レート制限や対検知対策なしで、1日何百件にもスケールする
- 保守計画なしでCSSセレクターに長期依存する
- 本物のLinkedInアカウントを使い捨て基盤として扱う
- 「公開アクセス可能」と「契約上または法的に問題ない」を混同する
FAQ
LinkedInスクレイパーのGitHubリポジトリは2026年でもまだ動きますか？
動くものもありますが、ごく一部です。目立つ8件のリポジトリを監査したところ、2026年の読者にとって重い注意書きなしで実用的に使えそうだったのは2件だけでした。重要なのは、スター数ではなく、保守活動とissueの健全性で評価することです。どのプロジェクトでも、セットアップ時間をかける前にリポジトリ健全性スコアカードを使ってください。
BANされずに1日何件のLinkedInプロフィールをスクレイピングできますか？
LinkedInは単なる件数ではなくセッション挙動を評価するため、絶対に安全な件数はありません。コミュニティ報告では、1アカウント1日50件未満が低リスク帯、50〜100件/日はインフラ品質が重要な中リスク帯、100件超/日はより攻めた領域とされています。5〜15秒のランダム遅延と住宅用プロキシは助けになりますが、リスクを完全には消せません。
LinkedInスクレイパー GitHubプロジェクトのノーコード代替はありますか？
あります。なら、AIによるフィールド検出、ブラウザベースの認証（プロキシ設定不要）、Excel、Google Sheets、Airtable、Notionへのワンクリック出力で、数クリックでLinkedInページをスクレイピングできます。コードを保守せずにデータを欲しい営業、採用、オペレーションチーム向けに作られています。から試せます。
LinkedInデータのスクレイピングは合法ですか？
グレーゾーンですが、年々輪郭は厳しくなっています。LinkedInの利用規約はスクレイピングを明確に禁止しており、LinkedInはにスクレイパーに対して法的措置を取りました。公開データアクセスに関するhiQ対LinkedInの先例も、最近の判断で狭められています。GDPRは、収集方法にかかわらずEU居住者の個人データに適用されます。商用利用なら、必ず自分の状況に即した法的助言を得てください。
AI抽出とCSSセレクター、LinkedInスクレイピングではどちらを使うべきですか？
CSSセレクターは、動いている間はレコードあたり速くて安いですが、LinkedInがDOMを頻繁に変えるため、保守の終わりなき作業を生みます。AI/LLM抽出は、1プロフィールあたりのコストが少し高く（現在ので約$0.001〜$0.002）、レイアウト変更に自動で適応します。数百万件ではなく数百件のプロフィールを扱う多くの非エンタープライズユーザーにとっては、AI抽出のほうが長期的な投資として優れています。Thunderbitの内蔵AIエンジンなら、コードを書いたり保守したりする必要なく、この利点を得られます。
詳しく見る