Facebookスクレイパー GitHub: 何がまだ使えて、何が使えないのか

GitHubで「facebook scraper」を検索すると、が見つかります。そのうち、過去6か月以内に更新されているのはだけです。

この「見つかるのに、実際には動かない」というギャップこそが、2026年のGitHub上のFacebookスクレイピングを象徴しています。

私はかなりの時間をかけて、リポジトリのIssue欄、Redditでの不満、そして実際の出力結果を掘り下げてきました。その傾向は一貫しています。上位の高評価プロジェクトの多くは静かに壊れたままで、メンテナーはすでに手を引き、Facebookのスクレイピング対策はますます巧妙になっています。開発者もビジネスユーザーも、同じ検索結果にたどり着き、同じリポジトリを入れ、同じ空っぽの出力にぶつかっているのです。この記事は、2026年時点での現実を見直すためのものです。どのリポジトリにまだ時間を使う価値があるのか、Facebookがそれらをどう壊しているのか、そしていつGitHubを最初から避けるべきなのかを、率直に検証します。

なぜ人々はGitHubでFacebookスクレイパーを探すのか

この検索の背景にある用途は、昔からあるものとほとんど変わりません。ツールは壊れやすくなっていても、必要とされる理由は変わらないからです。

• リード獲得: 営業活動のために、ビジネスページの連絡先情報（メールアドレス、電話番号、住所）を抽出する
• マーケットプレイス監視: ECやアービトラージ向けに、商品一覧、価格、出品者情報を追跡する
• グループ調査: 市場調査、OSINT、コミュニティ運営のために投稿やコメントをアーカイブする
• コンテンツ・投稿アーカイブ: 公開ページの投稿、リアクション、画像、タイムスタンプを保存する
• イベント集約: イベント名、日付、場所、主催者を収集する

GitHubの魅力は明快です。コードが見える、コストがかからない、コミュニティによるメンテナンスが期待できる（理論上は）、そして抽出項目や処理パイプラインを自由に制御できます。

ただし問題は、スター数やFork数と「今も動くかどうか」は一致しないことです。スター数ベースの上位10件の完全一致リポジトリを見ると、2026年4月時点で。これは偶然ではなく、むしろ標準的な状態です。

あるRedditユーザーは、で、6か月試した末にこう述べています。外部のデータスクレイピングアプリにお金を払うか、PythonにJSレンダリングを組み合わせて十分な計算資源を使わない限り「不可能」だった、と。別のユーザーも、で、「Facebookは自動化を強力にブロックするので、スクレイピングが特に難しい」うえに、ブラウザ自動化は「FacebookがDOMを頻繁に変更するため、壊れやすい」と要約しています。

用途は本物です。需要も本物です。そして苛立ちも本物です。この記事の残りは、そのギャップをどう乗り越えるかに焦点を当てます。

GitHubのFacebookスクレイパーリポジトリとは、正確には何なのか？

GitHub上の「Facebookスクレイパー」は、オープンソースのスクリプトです。通常はPythonで書かれており、Facebookのページ、投稿、グループ、Marketplace、プロフィールなどから公開データをプログラムで抽出します。ただし、すべてが同じ方法で動くわけではありません。主流は次の3つです。

ブラウザ自動化スクレイパー vs APIラッパー vs 直接HTTPスクレイパー

は、代表的な直接HTTP型の例です。APIキーなしで公開ページをスクレイピングし、直接リクエストと解析を使います。 はブラウザ自動化の例です。 は、かつて公式エンドポイント経由でページやグループの投稿を取得できた、Graph API時代の代表例です。

これらのリポジトリで典型的に対象となるデータは、投稿本文、タイムスタンプ、リアクション数・コメント数、画像URL、ページメタデータ（カテゴリ、電話番号、メールアドレス、フォロワー数）、Marketplaceの出品項目、グループやイベントのメタデータなどです。

2026年の本当の比較ポイントは、言語の好みではありません。どの種類の失敗まで許容できるか、です。

2026年版 Facebookスクレイパー GitHub 更新状況調査: 実際に動くリポジトリはどれか？

私は、GitHub上で特にスター数が多く、よく推奨されるFacebookスクレイパーのリポジトリを、2026年の実データで調査しました。READMEの主張ではなく、実際のコミット日、Issueの状況、コミュニティ報告を見ています。ここが最も重要な部分です。

更新状況の完全調査表

いくつか、すぐに分かる点があります。

• 「活動中のFork」と言えるものですら、moda20は2024年6月以降更新されていません。
• Issue欄を見るほうが、READMEよりも現実を早く教えてくれます。
• kevinzgとmoda20の両方は、 にPython ^3.6を維持しています。依存関係の基準が更新されていないサインです。

kevinzg/facebook-scraper

GitHubで最も有名なPython製Facebookスクレイパーです。 には、ページスクレイピング、グループスクレイピング、認証情報またはCookieによるログイン、さらに comments、image、images、likes、post_id、post_text、text、time のような投稿単位の項目が説明されています。

ただし、運用面のシグナルは弱いです。

• 最終更新: 2024年6月22日
• 未解決Issue: — たとえば「Example Scrape does not return any posts」など
• メンテナーは最近のIssueに応答していません

結論: 一部破損。低頻度の公開ページ実験や項目名の参照用としては価値がありますが、本番用途には信頼できません。

moda20/facebook-scraper（コミュニティFork）

kevinzg版の中で最も目立つForkで、追加オプションや extract_listing のようなMarketplace向けヘルパーがあります（ に記載）。

には、壊れている理由がはっきり出ています。

• 「mbasic is gone」
• 「CLI 'Couldn't get any posts.'」
• 「https://mbasic.facebook.com is no longer working」

簡略版のmbasicフロントエンドが変わる、または消えると、かなりの数のスクレイパーが一斉に機能しなくなります。

結論: 最も有名なForkではありますが、2026年時点では古く、壊れやすいです。GitHubベースの方法にこだわるなら最初に試す価値はありますが、安定性は期待しないでください。

minimaxir/facebook-page-post-scraper

かつては、公開ページや公開グループから投稿、リアクション、コメント、メタデータをCSVに集める実用的なGraph APIツールでした。 には、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用途には役立ちますが、 には「login to view the content」「CSS selectors outdated」「Getting blocked」が並んでいます。Marketplaceスクレイピングが何に壊されるのかを一行で示す事例です。
• apurvmishra99/facebook-scraper-selenium: 2020年9月に、 という文字通りのIssueがあります。それでほぼ全てが分かります。
• Mhmd-Hisham/selenium_facebook_scraper と anabastos/faceteer: どちらも、今の活動状況から見て信頼できるとは言えません。

Facebookのスクレイピング対策: GitHub製スクレイパーが相手にしているもの

このテーマを扱う多くの記事は、曖昧な「利用規約を確認しましょう」で終わります。それでは役に立ちません。

Facebookは、主要プラットフォームの中でも最も強力なスクレイピング対策を持つサービスのひとつです。どの防御層があるのかを理解できるかどうかで、動くスクレイパーになるか、空の出力を延々と見る午後になるかが決まります。

Meta自身の では、コードベース全体の静的解析でスクレイピング経路を特定し、差し止め通知を送り、アカウントを停止し、レート制限システムに依存する「Anti Scraping team」について説明しています。これは仮説ではなく、組織としての取り組みです。

ランダム化されたDOMとCSSクラス名

Facebookは、HTML要素のID、クラス名、ページ構造を意図的にランダム化します。 にもあるように、「普通のスクレイパーではFacebookは無理です。HTMLが更新のたびに変わる」のです。

何が壊れるか: 先週まで使えていたXPathやCSSセレクタが、今日は何も返さなくなります。

対策: 可能なら、テキストベースまたは属性ベースのセレクタを使います。厳密なセレクタに依存せず、ページ内容を読むAIベースの解析のほうがうまくいきます。セレクタの保守は、継続的なコストとして考えてください。

ログイン壁とセッション管理

Facebookの多くの画面、たとえばプロフィール、グループ、Marketplaceの一部一覧は、見るためにログインが必要です。ヘッドレスブラウザはリダイレクトされたり、簡略化されたHTMLしか返されなかったりします。passivebotのMarketplaceスクレイパーの でも、「login to view the content」が上位の不満です。

何が壊れるか: 匿名リクエストでは内容が取れない、あるいは完全にリダイレクトされます。

対策: 実際のブラウザセッションからセッションCookieを使うか、ログイン済みセッション内で動くブラウザベースのスクレイピングツールを使います。アカウントのローテーションも可能ですが、リスクは高いです。

デジタルフィンガープリント

Metaのエンジニアリング記事によると、無許可のスクレイパーは とされています。これは実質的に、検出の鍵がブラウザ品質と挙動品質にあるという意味です。 と のコミュニティ議論でも、anti-detectブラウザや一貫したフィンガープリントが推奨されています。

何が壊れるか: 標準的なSeleniumやPuppeteerの構成は、簡単に見抜かれます。

対策: undetected-chromedriver や anti-detectブラウザのプロファイルのようなツールを使います。単純なUser-Agent偽装よりも、現実的なセッションと一貫したフィンガープリントのほうが重要です。

IPベースのレート制限とブロック

Metaのエンジニアリング記事では、防御戦略の一部としてレート制限が明示されており、フォロワー一覧の件数を制限して、結果としてリクエスト数を増やし、 仕組みも説明されています。実際には、 レート制限されたという報告もあります。

何が壊れるか: 同じIPからの大量リクエストは、数分以内に速度制限またはブロックされます。データセンター系のプロキシIPは事前にブロックされていることも多いです。

対策: データセンタープロキシではなく、住宅回線プロキシをローテーションし、無理のないリクエスト間隔で実行します。

GraphQLスキーマの変更

一部のスクレイパーは、Facebookの内部GraphQLエンドポイントに依存しています。生のHTMLよりも、整った構造化データが返るからです。しかしMetaは内部GraphQLの安定性を保証していないため、これらのクエリは静かに壊れます。エラーではなく、空データを返すだけのことがあるのです。

何が壊れるか: 構造化抽出が、何も返さずに終わります。

対策: 検証チェックを追加し、スキーマエンドポイントを監視し、動作確認済みのクエリを固定します。保守は必要です。

スクレイピング対策のまとめ

GitHubリポジトリが失敗するなら: ノーコードという逃げ道

「facebook scraper github」にたどり着く人の多くは、開発者ではありません。営業担当でページのメールアドレスを探している人、Marketplace価格を追いたいEC運営者、競合調査をしたいマーケターです。Python環境の管理や壊れたセレクタのデバッグ、プロキシのローテーションなどは求めていません。

もしそれがあなたなら、判断はシンプルです。

Facebookページの連絡先情報（メールアドレス、電話番号）を抽出する場合

仕事がページの「概要」欄からメールアドレスや電話番号を抜き出すことなら、GitHubのリポジトリは過剰です。 の無料 と は、Webページをスキャンして、結果をSheets、Excel、Airtable、Notionに出力できます。AIが毎回ページを読み直すので、FacebookのDOMが変わっても壊れません。

Marketplaceやビジネスページから構造化データを抽出する場合

商品一覧、価格、所在地、企業情報を取り出したいなら、ThunderbitのAI Web Scraperで「AIで項目を提案」をクリックします。AIがページを読み取り、価格、タイトル、所在地のような列を提案してくれます。そのあと「スクレイピング」をクリックするだけです。XPathの保守も、コードのインストールも不要です。 に直接エクスポートできます。

定期監視（Marketplaceの価格アラート、競合追跡）

継続的な監視、たとえば「この価格帯に合うMarketplace出品があったら通知してほしい」といった用途には、Thunderbitの が使えます。間隔を自然な言葉で指定し（ のように）、URLを設定するだけです。cronジョブは不要で、自動実行されます。

GitHubリポジトリが今でも適しているケース

深いプログラム制御、大規模抽出、カスタムデータパイプラインが必要なら、GitHubリポジトリ（または構造化抽出用の）が適しています。判断は単純です。簡単な抽出をしたいビジネスユーザー → まずはノーコード。データパイプラインを構築する開発者 → GitHubリポジトリかAPI。

実際の出力例: どんな結果が返ってくるのか

競合記事はコード断片ばかり示して、実際の出力は見せません。以下は、それぞれの方法で現実的に期待できる内容です。

出力例: kevinzg/facebook-scraper（またはアクティブなFork）

にあるように、取得した公開投稿は次のようなJSONで返ります。

1{
2  "comments": 459,
3  "comments_full": null,
4  "image": "https://...",
5  "images": ["https://..."],
6  "likes": 3509,
7  "post_id": "2257188721032235",
8  "post_text": "この小さなバージョンを見くびらないで…",
9  "text": "この小さなバージョンを見くびらないで…",
10  "time": "2019-04-30T05:00:01"
11}

comments_full のようなnull許容フィールドに注目してください。2026年には、もっと多くの項目が空欄または欠落で返ってくるはずです。これは大抵、単なる不具合ではなく、ブロックされているサインです。出力は生のJSONなので、後処理が必要です。

出力例: Facebook Graph API

Metaの現在の には、GET /<PAGE_ID>?fields=id,name,about,fan_count のようなページ情報取得が記載されています。 には、followers_count、fan_count、category、emails、phone などの公開メタデータ項目がありますが、 のような適切な権限が必要です。

これは、GitHubのスクレイパー利用者が期待するよりも、はるかに狭いデータ形式です。ページ中心で、権限ベースであり、任意の公開投稿やグループのスクレイピングの代わりにはなりません。

出力例: Thunderbit AI Web Scraper

Facebookのビジネスページ向けにThunderbitが提案する列は、きれいで構造化された表になります。

投稿とコメントの出力は、次のようになります。

構造化された列、整形済みの電話番号、そのまま使えるデータ。後処理は不要です。GitHub系ツールの生JSONとの違いは、一目で分かります。

Facebookのデータ種別 × 最適ツールの対応表

2026年のFacebookでは、ひとつのツールですべてをうまく扱うのは不可能です。

この表を使えば、記事全体を読まなくても自分の用途に直接飛べます。

あなたのチームにはどの方法が合うのか？

• リード抽出を行う営業チーム: ThunderbitのEmail/Phone ExtractorまたはAI Scraperから始めてください。設定不要で、すぐ結果が出ます。
• Marketplaceを監視するECチーム: ThunderbitのScheduled Scraper、または（エンジニアリング資源があるなら）カスタムのScrapy + 住宅回線プロキシ構成。
• データパイプラインを構築する開発者: GitHubリポジトリ（アクティブなFork） + 住宅回線プロキシ + 保守予算。継続的な作業は前提です。
• グループ内容をアーカイブする研究者: ブラウザベースのワークフローのみ（Thunderbitまたはログイン付きSelenium）、かつコンプライアンス確認を行うこと。

率直な結論、そして は、1つの万能で信頼できる解決策は存在しない、ということです。欲しいデータに合わせて、正しいツールを選びましょう。

手順: GitHubからFacebookスクレイパーをセットアップする方法（やる価値がある場合）

更新状況の調査を読んだうえで、なおGitHubルートを選びたいなら、それも理解できます。以下が実践的な流れです。どこで壊れやすいかについての正直な注記付きで説明します。

STEP 1: 適切なリポジトリを選ぶ（更新状況の調査を使う）

上の調査表に戻ってください。対象に最も近く、かつ最も古くなっていないリポジトリを選びます。何かをインストールする前にIssuesタブを確認してください。最近のIssueタイトルのほうが、READMEよりも現在の動作状況をよく教えてくれます。

STEP 2: Python環境をセットアップする

1python3 -m venv fb-scraper-env
2source fb-scraper-env/bin/activate
3pip install -r requirements.txt

よくある落とし穴は、依存関係、特にSeleniumやPlaywrightのバージョン衝突です。kevinzgとmoda20はいずれも でPython ^3.6を指定しており、古い基準のため、新しいライブラリと衝突することがあります。passivebotのMarketplaceスクレイパーは に固定されています。試すには十分ですが、耐久性の証明にはなりません。

STEP 3: プロキシと対検出対策を設定する

ちょっとしたテスト以上のことをするなら、次を行ってください。

• 住宅回線プロキシのローテーションを設定する（Facebook向けIPプールを持つプロバイダを探す）
• ブラウザ自動化を使うなら、undetected-chromedriverを入れるか、フィンガープリント対策を設定する
• このステップを飛ばさないこと。通常のSeleniumやPuppeteerはすぐにフラグが立ちます

STEP 4: 小さくテストして、出力を検証する

最初は大量処理ではなく、公開ページ1件から始めます。出力を注意深く確認してください。

• 空欄や欠損データは、たいていFacebookの対策にブロックされているサインです
• ブラウザ上で実際に見える内容と出力を比較してください
• 1ページで成功するテストのほうが、立派なREADMEよりずっと重要です

STEP 5: エラー、レート制限、保守に備える

• リトライ処理とエラーハンドリングを組み込む
• セレクタや設定は定期的に更新する前提で考える。これは一度作って終わりではなく、継続的な保守です
• スクレイパーの保守に、データを使う時間より多くの時間を使っているなら、ノーコードに切り替えるべきサインです

Facebookスクレイピングの法的・倫理的な注意点

ここでは簡潔に、事実だけ述べます。この記事の主題ではありませんが、無視するのは不適切です。

Facebookの では、ユーザーは「事前の許可なしに、自動化された手段を用いて当社の製品からデータにアクセスしたり収集したりしてはならない」とされています。Metaの は2026年2月3日更新で、違反時の措置としてアカウント停止、APIアクセスの削除、アカウント単位の対応がありうることを明確にしています。

これは理論ではありません。Metaの には、無許可スクレイピングの積極的な調査、差し止め通知、アカウント停止が記されています。Metaはスクレイピング代行企業に対しても（たとえばVoyager Labs訴訟）。

最も安全な考え方は次の通りです。

• Metaの規約は明確にスクレイピング禁止です
• 権限のあるAPI利用は、無許可スクレイピングより安全です
• 公開されていることは、プライバシー法上の義務（GDPR、CCPAなど）を消しません
• 大規模に運用するなら、法務に相談してください
• Thunderbitは公開データのスクレイピング向けに設計されており、クラウドスクレイピング利用時にログイン要件を回避することはありません

重要なまとめ: 2026年にFacebookスクレイピングで本当に使えるもの

2026年時点では、FacebookスクレイパーのGitHubリポジトリの多くは壊れているか、信頼できません。これは脅しではなく、コミット日、Issue欄、コミュニティ報告が一貫して示している事実です。

今も動く少数のForkは、限定的な公開ページデータなら取得できますが、継続的な保守、対検出設定、そしてまた壊れることを前提にした現実的な期待が必要です。Graph APIは役立ちますが範囲は狭く、正しい権限があるページレベルのメタデータに限られ、多くの人が欲しい広範な公開投稿やグループのスクレイピングには向きません。

開発の手間をかけずにFacebookデータが必要なビジネスユーザーには、 のようなノーコードツールのほうが、より信頼性が高く、保守負担も少ないです。AIが毎回ページを読み直すので、DOM変更でワークフローが壊れません。 は無料で試せて、Sheets、Excel、Airtable、Notionに出力できます。

実践的なおすすめは、まず更新状況の調査表から始めることです。開発者でないなら、最初にノーコードを試してください。開発者なら、技術資源と保守する忍耐力がある場合に限ってGitHub構成へ投資してください。そして、どの道を選ぶにせよ、1つの解決策ですべてを賄おうとするのではなく、欲しいデータに合ったツールを選ぶことが大切です。

ソーシャルメディアデータのスクレイピングや関連ツールをさらに深く知りたいなら、、、 のガイドもあります。 では、操作手順の動画も視聴できます。

よくある質問

2026年に、GitHubで動くFacebookスクレイパーはありますか？

はい、ただし選択肢は限られています。最も注目すべきなのは、kevinzgの元リポジトリをForkした です。現在の状態は、上の更新状況の調査表を確認してください。公開ページの投稿や一部メタデータは部分的に取得できますが、Issue欄を見ると、mbasicまわりの破損や空の出力といった基本的な問題が出ています。その他の多くのリポジトリは、放棄されているか完全に壊れています。

コードを書かずにFacebookをスクレイピングできますか？

はい。 や無料のEmail/Phone Extractorを使えば、PythonやGitHubのセットアップなしで、ブラウザから数クリックでFacebookデータを抽出できます。AIが毎回ページを読み直すので、Facebookのレイアウト変更時にセレクタを保守する必要がありません。

Facebookをスクレイピングするのは合法ですか？

Facebookの では、許可のない自動データ収集は禁止されています。Metaはアカウント停止、差し止め通知、 を通じてこれを積極的に執行しています。違法かどうかは法域や用途によって異なります。公開されているビジネスデータに限定し、個人プロフィールは避け、大規模に運用する場合は法務に相談してください。

Facebook Graph APIでは、今でも何が取得できますか？

2026年時点では、 はかなり制限されています。id、name、about、fan_count、emails、phone などの限定的なページレベルデータは、 のような適切な権限があれば取得できます。多くの公開投稿データ、グループデータ（）、ユーザーレベルのデータは、もうAPI経由では利用できません。

FacebookスクレイパーのGitHubリポジトリは、どれくらいの頻度で壊れますか？

かなり頻繁です。FacebookはDOM構造、対ボット対策、内部APIを継続的に変更しており、公開された更新サイクルはありませんが、コミュニティ報告を見ると、現役のスクレイパーでも数週間おきに壊れています。moda20 Forkのmbasic消失をめぐるIssue欄は、最近の例です。GitHubリポジトリに依存するなら、定期的な保守と出力検証のための予算を見込んでください。

さらに学ぶ