GitHub で「facebook scraper」と検索すると、475件のリポジトリが見つかります。そのうち、過去6か月以内に更新されたものは62件 のみしかありません。
この「公開されている」ことと「実際に動く」ことの大きな差こそが、2026年時点の GitHub 上での Facebook スクレイピングの実態です。
私は、リポジトリの issue タブ、Reddit の不満投稿、そして実際の出力結果をかなり時間をかけて調べてきました。そこで見えてきた傾向は一貫しています。上位スター獲得プロジェクトの多くは静かに壊れており、メンテナーはすでに離れていて、Facebook のスクレイピング対策はますます強固になっています。開発者もビジネスユーザーも、同じ検索結果にたどり着き、同じリポジトリを入れ、そして同じ「空っぽの出力」に行き着いてしまうのです。この記事は、2026年版の現実チェックです。今でも時間を割く価値があるリポジトリはどれか、Facebook がどうやってそれらを壊しているのか、そして GitHub を最初から選ばないほうがいいのはどんなときかを、率直に整理します。
なぜ人は GitHub で Facebook Scraper を探すのか
この検索の背景にある用途は、何年も前からずっと同じです。ツールが次々と不安定になっても、必要とされる理由は変わりません。
- リード獲得: 営業向けに、ビジネスページの連絡先情報（メール、電話番号、住所）を抽出する
- マーケットプレイス監視: EC や転売のために、商品リスティング、価格、出品者情報を追跡する
- グループ調査: 市場調査、OSINT、コミュニティ運営のために投稿やコメントを保存する
- コンテンツ・投稿のアーカイブ: 公開ページの投稿、リアクション、画像、日時を保管する
- イベント集約: イベント名、日付、場所、主催者をまとめて取得する
GitHub が魅力的に見える理由も明白です。コードが見える、無料で使える、コミュニティが保守してくれるかもしれない、そして項目や処理フローを自由にコントロールできるからです。
ただし、スター数やフォーク数は「今も動くかどうか」とは一致しません。スター数ベースの exact phrase 上位10件を見ても、2026年4月時点で10件すべてが12か月以上放置されていました。これは例外ではなく、むしろ標準です。
2025年11月の Reddit のスレッドでは、半年間試し続けたユーザーが、「外部のデータスクレイピングアプリにお金を払う」か「Python＋JSレンダリング＋かなりの計算資源を使う」以外では無理だと率直に語っていました。別の2026年4月の議論では、「Facebook は自動化を強くブロックするので、スクレイピングが特に難しい」とされ、さらにブラウザ自動化は「Facebook が DOM を頻繁に変えるため脆い」とまとめられていました。
用途は本物です。需要も本物です。不満も本物です。この記事では、そのギャップをどう乗り越えるかを見ていきます。
GitHub の Facebook Scraper リポジトリとは、そもそも何なのか？
GitHub 上の「Facebook scraper」とは、公開されている Facebook のページ、投稿、グループ、Marketplace、プロフィールからデータをプログラムで取得するオープンソースのスクリプト、たいていは Python 製のものです。すべてが同じ仕組みで動くわけではありません。主流は大きく3種類あります。
ブラウザ自動化型 vs API ラッパー型 vs 直接 HTTP 型
| 手法 | 典型的な構成 | 強み | 弱み |
|---|---|---|---|
| ブラウザ自動化 | Selenium, Playwright, Puppeteer | ログイン必須の壁を越えやすく、実ユーザーに近い挙動を再現できる | 遅い、重い、設定が甘いと指紋で見抜かれやすい |
| 公式 API ラッパー | Meta Graph API / Pages API | 安定していて、ドキュメントもあり、承認済みなら適法性も高い | 制限が非常に厳しく、公開投稿やグループデータの多くは取得できない |
| 直接 HTTP スクレイパー | requests、HTML パース、非公開エンドポイント | 動けば高速で軽量 | Facebook のページ構造や対ボット対策が変わるたびに壊れる |
kevinzg/facebook-scraper は、API キーなしで公開ページを直接リクエストとパースで取得する、いわば定番の直接 HTTP 型です。apurvmishra99/facebook-scraper-selenium はブラウザ自動化型の例です。minimaxir/facebook-page-post-scraper は、Graph API がまだ広く使えた時代の名残で、公式エンドポイント経由でページやグループの投稿を取得していました。
これらのリポジトリが主に扱うデータは、投稿本文、タイムスタンプ、リアクション数、コメント数、画像 URL、ページのメタデータ（カテゴリ、電話番号、メール、フォロワー数）、Marketplace の出品情報、グループやイベントのメタ情報などです。
2026年において、本当のトレードオフは言語ではありません。どんな失敗なら許容できるか、です。
2026年版 Facebook Scraper GitHub 新鮮度調査：どのリポジトリが実際に動くのか？
私は、GitHub で高評価かつよく推奨される Facebook scraper リポジトリを、2026年の実データに照らして調査しました。README の主張ではなく、実際のコミット日時、issue の量、コミュニティの報告を見ています。ここが最も重要な部分です。
新鮮度調査の全表
| リポジトリ | スター数 | 最終更新 | 未解決 Issue 数 | 言語 / 実行環境 | 今も取得できるもの | 状態 |
|---|---|---|---|---|---|---|
| kevinzg/facebook-scraper | 3,157 | 2024-06-22 | 438 | Python ^3.6 | 一部の公開ページ投稿、コメント/画像の一部、ページメタデータ | ⚠️ 一部破損 / 更新停止気味 |
| moda20/facebook-scraper | 110 | 2024-06-14 | 29 | Python ^3.6 | kevinzg と同様 + Marketplace 向けヘルパー | ⚠️ 一部破損 / ステールなフォーク |
| minimaxir/facebook-page-post-scraper | 2,128 | 2019-05-23 | 53 | Python 2/3 時代、Graph API 依存 | 過去の参考用のみ | ❌ 放棄済み |
| apurvmishra99/facebook-scraper-selenium | 232 | 2020-06-28 | 7 | Python + Selenium | ページ取得のためのブラウザ自動化 | ❌ 放棄済み |
| passivebot/facebook-marketplace-scraper | 375 | 2024-04-29 | 3 | Python 3.x + Playwright 1.40 | ブラウザ自動化による Marketplace リスティング取得 | ⚠️ 不安定 / ニッチ |
| Mhmd-Hisham/selenium_facebook_scraper | 37 | 2022-11-29 | 1 | Python + Selenium | 汎用 Selenium スクレイピング | ❌ 放棄済み |
| anabastos/faceteer | 20 | 2023-07-11 | 5 | JavaScript | 自動化寄り | ❌ リスク高 / 実績不足 |
ここで目立つ点は、いくつかあります。
- 「動いていそうなフォーク」である moda20 ですら、2024年6月以降更新されていません。
- 実情は README よりも issue キューを見たほうが早く分かります。
- kevinzg と moda20 はどちらも pyproject.toml で Python ^3.6 を指定したままで、依存関係の基盤が今の水準に更新されていないことを示しています。
kevinzg/facebook-scraper
GitHub で最もよく知られている Python 製 Facebook scraper です。 README では、ページのスクレイピング、グループのスクレイピング、認証情報や cookie によるログイン、さらに comments、image、images、likes、post_id、post_text、text、time といった投稿レベルの項目を扱えると説明されています。
ただし、運用上のシグナルはかなり弱いです。
- 最終更新: 2024年6月22日
- 未解決 Issue 数: 438 — 「Example Scrape does not return any posts」のようなタイトルを含む
- メンテナーは最近の issue に反応していません
結論: 一部破損。小規模な公開ページの試験や、フィールド名の参照先としてはまだ価値がありますが、本番用途には信頼できません。
moda20/facebook-scraper（コミュニティフォーク）
kevinzg の最も目立つフォークで、追加オプションや、README に記載された extract_listing のような Marketplace 向けヘルパーがあります。
issue キューを見ると、壊れ方がかなりはっきりしています。
- 「mbasic is gone」
- 「CLI 'Couldn't get any posts.'」
- 「https://mbasic.facebook.com is no longer working」
簡易版の mbasic フロントエンドが変わる、あるいは消えると、広い範囲のスクレイパーが一斉に弱体化します。
結論: 最も有名なフォークですが、2026年にはステールで壊れやすいです。GitHub ベースで行くなら最初に試す価値はありますが、安定性は期待しないほうがいいでしょう。
minimaxir/facebook-page-post-scraper
かつては、公開ページやオープングループから投稿、リアクション、コメント、メタデータを CSV にまとめて取得する、かなり実用的な Graph API ツールでした。README には、Facebook アプリの App ID と App Secret の使い方が今でも説明されています。
2026年時点では、これはもはや歴史的な遺物です。
- 最終更新: 2019年5月23日
- 未解決 Issue 数: 53 — 「HTTP 400 Error Bad Request」や「No data retrieved!!」を含む
結論: 放棄済み。Meta がその後かなり絞り込んだ API 権限モデルに密接に依存しています。
その他の注目リポジトリ
- passivebot/facebook-marketplace-scraper: Marketplace 用途では有用ですが、issue キューには「login to view the content」「CSS selectors outdated」「Getting blocked」などが並びます。Marketplace スクレイピングで何が壊れるかを、そのまま一行で示しているようなものです。
- apurvmishra99/facebook-scraper-selenium: 2020年9月の issue に、文字通り「Does it work with new Facebook layout?」という質問があります。これだけでほぼ十分です。
- Mhmd-Hisham/selenium_facebook_scraper と anabastos/faceteer: 現在の活動量が足りず、信用する材料がありません。
Facebook の対スクレイピング防御：GitHub の Scraper が相手にしているもの
この手の記事の多くは、曖昧な「利用規約を確認してください」という注意で終わります。でも、それでは役に立ちません。
Facebook は、大手プラットフォームの中でも特に強力な対スクレイピング体制を持っています。どの防御層があるかを理解することが、動くスクレイパーと、午後いっぱい空の出力に悩まされるだけのスクレイパーの違いです。
Meta 自身の2025年2月のエンジニアリング記事では、コードベース全体を静的解析してスクレイピングの経路を特定する「Anti Scraping team」、停止要求の送付、アカウント無効化、そしてレート制御システムの活用が説明されています。これは仮説ではなく、組織としての取り組みです。
ランダム化された DOM と CSS クラス名
Facebook は、HTML 要素の ID、クラス名、ページ構造を意図的にランダム化しています。 r/webscraping のコメントで言われていたように、「普通のスクレイパーでは Facebook は無理。HTML が更新のたびに変わる」のです。
壊れるもの: 昨日まで効いていた XPath や CSS セレクタが、今日は何も返さない。
対策: 可能な限り、テキストベースや属性ベースのセレクタを使う。硬直したセレクタに頼らず、ページ内容を読む AI ベースのパースのほうが相性は良いです。ただし、セレクタのメンテナンスは継続コストとして見込んでおく必要があります。
ログイン壁とセッション管理
Facebook の多くの面、プロフィール、グループ、一部の Marketplace リスティングなどは、閲覧にログインが必要です。ヘッドレスブラウザはリダイレクトされたり、簡略化された HTML しか返されなかったりします。passivebot の Marketplace scraper のissue タブでも、「login to view the content」が上位の不満として挙がっています。
壊れるもの: 匿名リクエストでは内容が取得できない、あるいは完全にリダイレクトされる。
対策: 実ブラウザのセッションから取得した cookie を使うか、ログイン済みセッション内で動くブラウザベースのスクレイピングツールを使う。アカウントを切り替える方法もありますが、リスクは高いです。
デジタル指紋による判定
Meta のエンジニアリング記事では、無許可のスクレイパーが「通常のユーザーの使い方を模倣して自分の正体を隠すことが多い」と述べられています。これは実質的に、検出の中心がブラウザ品質と挙動品質にあることを示しています。2026年3月や4月のコミュニティ議論でも、anti-detect ブラウザや一貫した fingerprint の利用が引き続き推奨されています。
壊れるもの: 標準的な Selenium や Puppeteer の構成は、簡単に見抜かれる。
対策: undetected-chromedriver や anti-detect ブラウザのプロファイルを使う。単純な user-agent の偽装より、実際のセッションの見え方と fingerprint の一貫性が重要です。
IP ベースのレート制限とブロック
Meta のエンジニアリング記事では、レート制限が防御戦略の一部として明示されており、フォロワー数の取得を制限して、さらに多くのリクエストを発生させ、レート制御を発火させるようにしていると説明されています。実際、ユーザーは 10秒間隔で10個のグループに投稿しただけでレート制限を受けたと報告しています。
壊れるもの: 同じ IP からの大量リクエストが、数分以内に制限またはブロックされる。データセンター系プロキシは事前に弾かれていることも多いです。
対策: データセンターではなく、住宅用プロキシのローテーションを使う。加えて、リクエスト間隔は無理のない範囲に保ちます。
GraphQL スキーマの変更
一部のスクレイパーは、Facebook の内部 GraphQL エンドポイントを使います。生 HTML よりも構造化されたデータが取りやすいからです。ただし Meta は内部 GraphQL に安定保証を出していないため、これらのクエリは静かに壊れます。エラーを返すのではなく、空データを返すのです。
壊れるもの: 構造化取得が、何も返さず静かに失敗する。
対策: 検証チェックを追加し、スキーマエンドポイントを監視し、既知の動作確認済みクエリに固定する。メンテナンス前提で考えましょう。
対スクレイピング防御のまとめ
| 防御層 | スクレイパーが壊れる理由 | 現実的な対策 |
|---|---|---|
| レイアウト変更 / 不安定なセレクタ | XPath や CSS セレクタが何も返さない、または一部しか取れない | 耐性のあるアンカーを優先し、目視で見えるページ出力と照合し、保守前提で運用する |
| ログイン壁 | ログアウト状態では内容が取れない、またはリダイレクトされる | 有効なセッション cookie か、ブラウザセッション型ツールを使う |
| 指紋判定 | 標準的な自動化が不自然に見える | 実ブラウザ、一貫したセッション品質、anti-detect 対策を使う |
| レート制限 | 空の出力、ブロック、スロットリング | ペースを落とす、バッチサイズを小さくする、住宅用プロキシをローテーションする |
| 内部クエリ変更 | 構造化取得が空データを返す | 検証チェックを入れ、クエリの保守を前提にする |
GitHub リポジトリが失敗したら：許可された代替手段を選ぶ
壊れたリポジトリが見つかったからといって、プラットフォームの制御を回避する別の抜け道を探すべきではありません。まず、ビジネス上の問いを明確にしてください。必要なのはページ単位の分析なのか、広告の透明性情報なのか、公開連絡先ディレクトリなのか、それとも商品カタログなのか。そうしたニーズの多くは、公式の Meta 製品、権限付き API、あるいは Meta 以外の公開ソースで満たせます。
たとえば、Graph API はアプリと用途に必要な権限がある場合だけ使い、Meta のリサーチプログラムは参加資格があるときだけ利用し、広告情報は Meta Ad Library が公開している範囲で使います。リード調査、価格調査、ローカルビジネスの発見については、利用規約やプライバシー上の義務を直接確認できる独立した公開サイトのほうが適しています。
実際の出力例：本当に何が取れるのか
競合記事はコード片ばかり載せて、実際の出力は見せません。以下が、各手法で現実的に期待できる内容です。
出力例: kevinzg/facebook-scraper（または有効なフォーク）
README の例では、取得した公開投稿は次のような JSON になります。
{
"comments": 459,
"comments_full": null,
"image": "https://...",
"images": ["https://..."],
"likes": 3509,
"post_id": "2257188721032235",
"post_text": "Don't let this diminutive version...",
"text": "Don't let this diminutive version...",
"time": "2019-04-30T05:00:01"
}
comments_full のような nullable フィールドに注目してください。2026年には、さらに多くの項目が空、または欠落した状態で返ってくると考えてください。多くの場合、それは単なる不具合ではなく、ブロックされているサインです。出力は生の JSON なので、後処理も必要です。
出力例: Facebook Graph API
Meta の現在の Pages API では、GET /<PAGE_ID>?fields=id,name,about,fan_count のようなページ情報取得が文書化されています。Page リファレンス には followers_count、fan_count、category、emails、phone といった公開メタデータの項目がありますが、Page Public Content Access や Page Public Metadata Access のような正しい権限が必要です。
これは、GitHub の scraper ユーザーが想定しているデータ形状よりかなり狭いものです。ページ中心で、権限で厳しく制御されており、任意の公開投稿やグループをスクレイピングする代替にはなりません。
Facebook データ種別 × 取得ルートの対応表
| Facebook のデータ種別 | 最初に検討すべき手段 | 主な制約 |
|---|---|---|
| 自社が管理している資産 | 公式 Meta 管理ツールと承認済み API | 権限や利用可能フィールドは変動する |
| 広告の観察情報 | Meta Ad Library | 公開されている項目とフィルターだけを使う |
| リード調査に必要な公開ビジネス情報 | 許可された Meta 以外のディレクトリや掲載サイト | その情報源の規約とプライバシー義務を確認する |
| 非公開、クローズドグループ、ログイン必須、またはアカウント限定の素材 | 自動収集しない | 代わりに権限のある方法を探す |
手順: GitHub で Facebook Scraper をセットアップする方法（やる価値がある場合）
ここまでの新鮮度調査を読んだうえで、それでも GitHub ルートを選びたいなら、まあ理解できます。以下が実践的な流れです。ただし、どこで壊れやすいかも正直に書いておきます。
ステップ1: 適切なリポジトリを選ぶ（新鮮度調査を使う）
先ほどの調査表に戻ってください。対象とする面に最も合っていて、かつ最も古くないリポジトリを選びます。インストールする前に、Issues タブを確認しましょう。最近の issue タイトルのほうが、README より現在の動作状況をよく教えてくれます。
ステップ2: Python 環境をセットアップする
python3 -m venv fb-scraper-env
source fb-scraper-env/bin/activate
pip install -r requirements.txt
よくある落とし穴は、依存関係のバージョン衝突です。特に Selenium や Playwright のバージョンで起こりがちです。kevinzg と moda20 はどちらも pyproject.toml で Python ^3.6 を指定しており、これは新しいライブラリとぶつかる可能性のある古い基準です。passivebot の Marketplace scraper は playwright==1.40.0 に固定されていますが、実験には向いていても、長期耐久性の証明にはなりません。
ステップ3: プロキシと対検出対策を設定する
軽いテスト以上をやるなら、最低でも次を考えてください。
- 住宅用プロキシのローテーションを用意する（Facebook 向け IP プールを持つ事業者を探す）
- ブラウザ自動化を使うなら、undetected-chromedriver を入れるか、指紋対策を設定する
- この工程を省かないこと。標準の Selenium や Puppeteer はすぐに弾かれます
ステップ4: 小さくテストして、出力を検証する
最初は大量一括ではなく、公開ページ1件から始めます。出力を丁寧に確認してください。
- 空欄や欠損が多い場合、Facebook の防御に止められている可能性が高いです
- ブラウザで実際に見えている内容と照らし合わせてください
- 1ページで成功することのほうが、見栄えのいい README よりずっと重要です
ステップ5: エラー、レート制限、保守に備える
- リトライロジックとエラーハンドリングを組み込む
- セレクタや設定を定期的に更新する前提で考える。これは一度作って終わりではなく、継続保守です
- スクレイパーを維持する時間が、データ活用の時間より長くなってきたら、ノーコード以外の方法を見直すサインです
Facebook スクレイピングに関する法的・倫理的な注意点
プラットフォームの規約、プライバシー規則、契約上の義務、データ保護法は、いずれも関係し得ます。公開されているからといって、自動収集が全面的に許可されるわけではありません。データは最小限にとどめ、目的と法的根拠を記録し、商用または大規模な運用では弁護士に相談してください。
ブラウザ拡張、ログイン済みセッション、あるいは「公開」というラベルを、Meta 製品からの自動収集許可だと解釈しないでください。
重要ポイント：2026年の Facebook スクレイピングで本当に使えるもの
リポジトリの活動状況、issue キュー、そして現行のプラットフォーム規則は、スター数や古い README よりも重要です。業務上の対象が自社で管理する資産なら、まずは公式 Meta ツールと承認済み API を使ってください。市場調査、リード調査、価格調査なら、許可された Meta 以外の情報源のほうが、文書化もしやすく、運用管理もしやすいことが多いです。
よくある質問
2026年に GitHub で動く Facebook scraper はありますか？
はい、ただし選択肢はかなり限られます。最も注目すべきなのは、kevinzg の元リポジトリをフォークした moda20/facebook-scraper です。現在の状態は上の新鮮度調査表を確認してください。公開ページの投稿や一部メタデータは部分的に取得できますが、issue キューを見ると mbasic の消失や空出力まわりの根本的な破綻が見られます。その他の多くのリポジトリは放棄済みか、完全に壊れています。
コードを書かずに Facebook をスクレイピングできますか？
手動での調査なら、Facebook 自身の検索ツールや管理ツールを使うのがよいでしょう。繰り返し実行したい、あるいはプログラムで扱いたいなら、公式 API とその権限を評価するか、許可された Meta 以外のソースを前提にワークフローを作り直してください。ノーコードの手軽さが、プラットフォーム、プライバシー、契約上の義務を消してくれるわけではありません。
Facebook をスクレイピングするのは合法ですか？
Facebook の 利用規約 では、許可のない自動データ収集は禁止されています。Meta は、アカウント停止、停止要求書の送付、そして訴訟を通じて、これを積極的に執行しています。合法性は法域や用途によって異なります。公開されているビジネス情報に限定し、個人プロフィールは避け、大規模運用なら法務に相談してください。
Facebook Graph API では今でも何が取得できますか？
2026年時点では、Graph API はかなり制限されています。適切な権限、たとえば Page Public Metadata Access があれば、id、name、about、fan_count、emails、phone のような限られたページレベルのデータにアクセスできます。ですが、公開投稿の多く、グループデータ（Groups API は廃止済み）、ユーザーレベルのデータは、もはや API では取れません。
Facebook scraper の GitHub リポジトリはどのくらいの頻度で壊れますか？
かなり頻繁です。Facebook は DOM 構造、対ボット対策、内部 API を継続的に変更しています。明確な更新周期は公開されていませんが、コミュニティ報告を見る限り、アクティブなスクレイパーでも数週間おきに壊れることがあります。moda20 フォークの mbasic 消失に関する issue キューは、その最近の例です。GitHub リポジトリに依存するなら、定期保守と出力検証のコストを見込んでおく必要があります。
さらに詳しく
