Facebookページのスクレイピング方法：Apifyでのデータ取得・検証とプロキシ設定

Facebookページのスクレイピングでは、企業・店舗などのページに表示される情報を取得し、調査やレポートに使えるデータへ整理します。本記事では、ページURL、名称、カテゴリなどの基本情報を対象に、Apifyでの取得からエクスポート後の検証までを解説します。取得した情報は、Facebookページの比較や分析に使える形に整理します。

使用するのは、ApifyのActor（実行ツール）apify/facebook-pages-scraperです。入力URLの設定、実行上限、出力フィールドの確認を順に進めます。外部プロキシに対応した処理でRola IPを使う場合の接続確認も、取得データの検証とは分けて説明します。

先に押さえたいポイント

ツール選びでは、取得したい情報と入出力スキーマが一致するかを最初に確認します。少数の許可済みURLで試し、接続とデータの両方を検証してから定期実行へ進みます。

• 対象を絞る： ページの基本情報を取得するツールか、投稿やコメントを取得するツールかを区別します。
• 上限を分ける： 課金対象件数の上限と、実行時間の上限は別々に設定します。
• 出力を検証する： 対象ページとの一致、必須フィールド、欠損理由、ファイルの読み込みを確認します。
• 外部プロキシの対応を確認する： Rola IPを契約するだけで、Actorの通信経路が変わるわけではありません。
• アクセス制限では停止する： ログイン要求やチェックポイントが表示されたら、取得方法と権限を見直します。

Facebookページのスクレイピングで取得できる情報

ページの基本情報には、URL、名称、カテゴリ、説明文、Webサイトなど、企業や団体についてページ上に表示される情報が含まれます。実際に必要なフィールドを先に決め、試験実行の合格条件にしてください。

Facebookページのスクレイピングツールを比較するときは、プロキシや出力形式より先に、サンプルレコードとフィールド定義を確認します。たとえば企業・店舗ディレクトリを作るなら、まず対象ページを正しく識別できることと、ディレクトリに必要な事業情報がそろうことを優先します。

データの扱いでは、次の点を統一します。

• 取得できる項目は、ページ、表示言語、閲覧条件によって異なります。
• 取得できない値はnullで保持し、理由が分かる場合は記録します。
• フォロワー数が取得できなくても、0に置き換えません。
• 反応数などが省略表記の場合は、数値へ変換する前の原文も保存します。

Facebookページのデータ取得方法を選ぶ

取得方法は、必要なアクセス権限と保守の負担を踏まえて選びます。本記事の手順は管理型のページ情報取得Actorを対象とし、Meta Pages APIや独自のブラウザ処理とは前提が異なります。

APIを選ぶ場合は、Meta Pages APIの公式ドキュメントを確認してください。実装前に、APIバージョン、アプリと対象ページの関係、トークン、権限、取得フィールド、ページネーションを整理します。

あわせて、Metaによる許可されたスクレイピングと許可されていないスクレイピングの説明と、適用される自動データ収集規約を確認します。公開されている情報でも、自動取得や再公開が許可されているとは限りません。実行前に許可範囲を定め、非公開プロフィールやアクセスが制限されたコンテンツは対象外にしてください。

Facebookスクレイピング用プロキシの選び方

プロキシは、処理ごとに出口IPを切り替えるか、一定期間維持するかで選びます。先に利用ツールの外部プロキシ対応を確認し、そのうえで必要なセッション維持時間や契約条件を検討してください。

独立したジョブにはローテーション型住宅プロキシを検討する

独立したブラウザジョブでは、ローテーション型住宅プロキシを候補にできます。1回の処理時間に合うよう、プロバイダー側のセッション維持時間を設定します。

参照の商品ページには、国指定とスティッキーセッションの説明があります。実装時には、選択したプランで利用できるセッション設定と有効時間を改めて確認してください。

同じブラウザジョブでページ本体と後続リクエストを処理する間は、同じ出口IPを維持する設計にします。Playwrightのブラウザコンテキストを作成するだけでは、出口IPは固定されません。 出口の維持はプロバイダー側のセッションパラメータと有効時間に依存するため、ジョブの開始・終了時などに確認します。

ジョブ間でIPを切り替えても、対象サイトのアクセス制限が解除されるわけではありません。動作の違いは、スティッキーセッションとIPローテーションの比較も参考になります。

同じ出口を継続利用する場合は固定型住宅プロキシを検討する

許可された定期処理で同じネットワークアドレスを使う必要がある場合は、固定型住宅プロキシと対象プランの条件を確認します。出口が安定していれば、接続トラブルの切り分けやセッションの継続を管理しやすくなります。

費用を見積もる前に、次の条件を確認してください。

• IPの割り当て期間
• 利用できる地域
• 認証方式
• 帯域や通信量の条件
• 接続数の上限

Rola IPが担うのは通信経路

Rola IPは、対応するデータ取得処理にプロキシ接続を提供します。許可されたデータへのリクエスト、フィールド抽出、停止上限、レコード検証、保存は、取得アプリケーション側の役割です。

スクレイピング向けプロキシは、この通信部分に関係します。外部プロキシを契約しても、管理型Actorがその認証情報を受け付けるとは限りません。

試験実行では、検証を通過した1レコード当たりの通信コスト、接続の安定性、出口IPの一貫性を測定します。取得頻度は、許可された処理条件と対象サイトの応答に合わせて設定してください。

ApifyでFacebookページをスクレイピングする手順

最初は少数の許可済みURLを使い、入力からエクスポートまで一通り確認します。Actorのビルド、設定、元データを同じ実行記録にまとめると、不具合が起きた処理を追跡できます。

手順1：Actorと取得対象URLを確認する

apify/facebook-pages-scraperを開き、現在の説明とスキーマを確認します。試験実行で使うActor IDとビルドも記録してください。実行結果の比較や、フィールド変更について問い合わせる際の識別情報になります。

公開チュートリアルでは、次のURLを使用しています。

• https://www.facebook.com/Starbucks/
• https://www.facebook.com/TheCocaColaCo/
• https://www.facebook.com/McDonalds

実際の試験では、取得が許可されたURLに置き換えます。不要なトラッキングパラメータを除去し、重複URLを整理してから入力してください。

手順2：入力項目と外部プロキシ対応を確認する

ActorのページURL入力欄に、許可済みURLを入力します。過去の画面では、この欄はStart urlsと表示されています。ページの基本情報を返すツールであることと、現在のビルドで追加の入力が必要かを確認してください。

参照のActor入力スキーマでは、startUrlsはURLオブジェクトの配列で、必須項目です。対象は個人プロフィールではなくFacebookページです。各要素にページURLを指定するため、URLの種類と重複の有無を確認します。

Rola IPの認証情報は、Actorがカスタムプロキシ設定に明示的に対応している場合に限って入力します。Actor内部でネットワークを管理している場合もあります。外部プロキシを設定できない場合は、対応する連携方法を検討してください。別途プロキシを購入するだけでは、このActorの通信経路は変わりません。

手順3：課金上限と実行時間の上限を別々に設定する

試験実行では、次の条件を決めます。

1. 入力は少数の許可済みURLに限定します。
2. 現在のツールで利用できる設定から、有限のタイムアウトを指定します。
3. タイムアウト時の停止処理を決めます。
4. 独自のブラウザ処理では、ページ遷移時間、スクロール、再試行にも上限を設けます。
5. 設定値を実行IDと一緒に保存します。

ログイン要求、チェックポイント、アクセス制限が表示された場合は停止し、取得経路と権限を見直します。

手順4：実行してページ単位のレコードを検証する

Actorを開始し、実行IDとビルドを記録します。完了後はデータセットを確認し、入力した各URLを「検証済み」「取得不可」「失敗」に分類します。失敗したページを理由も残さず除外しないでください。

1. 対象ページとの一致： 出力URLまたは安定したページIDが、想定した入力に対応しているか確認します。リダイレクトや別の企業・店舗への取り違えは調査します。
2. 必須フィールド： レポートに必要なフィールドがあり、データ型も想定どおりか確認します。
3. 欠損理由： 取得できない必須値はnullのまま保持し、「元情報を閲覧できない」「項目自体が存在しない」など、分かる範囲で理由を記録します。パーサーの不具合は別に扱います。
4. ファイルの読み込み： ダウンロードしたJSONを想定した構造で解析できるか、CSVを列と文字コードの崩れなく読み込めるか確認します。解析したレコードを元のページとも照合します。

手順5：必要なフィールドをエクスポートする

入れ子構造を含むレコードにはJSON、表形式のレポートにはCSVやExcelを選びます。利用できる形式は、現在のツールで確認してください。

過去のエクスポート画面では、Viewの選択が出力対象フィールドに影響します。プレビューに見えている情報がすべて出力されると考えず、ファイルそのものを確認します。

元のエクスポートファイルは、正規化後のデータセットと一緒に保存します。取得時の観測日時はISO 8601形式のUTCで記録し、エクスポート日時とは分けてください。元の日時表記の精度が不明な場合は、その文字列も残します。

手順6：スキーマを検証してから定期実行する

{
  "facebookUrl": "https://www.facebook.com/TheCocaColaCo/",
  "pageName": "TheCocaColaCo",
  "title": "The Coca-Cola Company | Atlanta GA"
}

この抜粋では、URLが入力ページと一致すること、3つの値がいずれも文字列であること、JSONとして解析できることを確認できます。新しい実行結果でも、ダウンロードしたファイルとすべての必須フィールドに同じ検証を適用します。

• 正規化したページURLを基準に重複を除去します。
• 変化する値は、観測日時付きのスナップショットで保存します。
• 取得を試みたページ数、検証済みページ数、失敗したページ数を分けて集計します。

Facebookページ分析に使うデータを整理する

Facebookページ分析では、比較する項目と観測時点をそろえることが基本です。ページのハンドルと表示名を別々に保持し、観測日時、検証状態、欠損理由を記録して、比較できるデータに整えます。

たとえば、企業・店舗のページを比較するなら、名称、カテゴリ、Webサイトなどの公開情報を同じ基準で整理します。リーチやインプレッションなどの運用指標を分析したい場合は、ページの基本情報とは分けて、必要な指標を取得できるツールと権限を確認してください。

投稿本文が必要な場合は、別途、投稿取得に対応したツールを選びます。投稿URLまたは安定した投稿ID、元の投稿日時、取得時の観測日時を検証してください。ページの基本情報は投稿元の企業・団体を説明するデータであり、投稿レコードの代わりにはなりません。

PythonとPlaywrightでプロキシ接続を確認する

次のコードは、独自のブラウザ処理を作る場合の任意の接続確認用です。Facebookのページ情報を取得するコードではなく、IP確認用エンドポイントへの接続を検証します。

Python向けプロキシ連携ガイドに従い、選択した商品のゲートウェイと認証情報を用意します。管理型Actorで使う場合は、そのActorが外部プロキシを受け付けるかを先に確認してください。

開発環境を準備する

管理されたローカル環境で、利用が承認されたPlaywrightのバージョンとChromiumをインストールします。実行結果には、Python、Playwright、ブラウザ、OSの正確なバージョンを残してください。

後述のPythonコードをproxy_check.pyとして保存します。次のPowerShellコマンドは認証情報の入力を求めるため、パスワードを文字列としてコマンド履歴に残さずに実行できます。

python -m pip install playwright
python -m playwright install chromium
$env:ROLA_PROXY_SERVER = Read-Host 'Proxy scheme host and port'
$proxyCredential = Get-Credential -Message 'Rola proxy credentials'
$env:ROLA_PROXY_USERNAME = $proxyCredential.UserName
$env:ROLA_PROXY_PASSWORD = $proxyCredential.GetNetworkCredential().Password
try {
    python proxy_check.py
    if ($LASTEXITCODE -ne 0) { throw 'Proxy check failed' }
    python -m pip freeze > requirements-environment.txt
} finally {
    Remove-Item Env:ROLA_PROXY_SERVER -ErrorAction SilentlyContinue
    Remove-Item Env:ROLA_PROXY_USERNAME -ErrorAction SilentlyContinue
    Remove-Item Env:ROLA_PROXY_PASSWORD -ErrorAction SilentlyContinue
    Remove-Variable proxyCredential -ErrorAction SilentlyContinue
}

requirements-environment.txtには、インストール済みパッケージのバージョンが記録されます。実行記録と一緒に保管してください。依存関係の記録だけでは、処理の動作を検証したことにはなりません。

また、適切な権限を持つプロセスからは環境変数を参照できるため、管理されたローカルセッションで実行します。

接続確認コードを保存する

import asyncio
import ipaddress
import json
import os
from urllib.parse import urlsplit
from playwright.async_api import async_playwright

async def check_proxy():
    server = os.environ["ROLA_PROXY_SERVER"]
    parsed = urlsplit(server)
    if parsed.scheme != "http" or not parsed.hostname or not parsed.port:
        raise ValueError("Use an authenticated HTTP gateway with a port")
    proxy = {
        "server": server,
        "username": os.environ["ROLA_PROXY_USERNAME"],
        "password": os.environ["ROLA_PROXY_PASSWORD"],
    }
    async with async_playwright() as p:
        browser = await p.chromium.launch(proxy=proxy, timeout=30000)
        try:
            page = await browser.new_page()
            response = await page.goto(
                "https://api.ipify.org?format=json",
                wait_until="domcontentloaded", timeout=30000,
            )
            if response is None or not response.ok:
                raise RuntimeError("IP echo returned no successful response")
            payload = await response.json()
            if not isinstance(payload, dict) or not isinstance(payload.get("ip"), str):
                raise ValueError("IP echo must return an object with an IP string")
            exit_ip = ipaddress.ip_address(payload["ip"])
            print(json.dumps({"check": "passed", "exit_ip": str(exit_ip)}))
        finally:
            await browser.close()

asyncio.run(check_proxy())

Playwrightのネットワーク設定ガイドには、プロキシの設定方法が記載されています。この例は、ポートを指定した認証付きHTTPゲートウェイを前提としています。SOCKS5が必要な商品では、クライアント側の対応を別途確認してください。

次の場合は、接続確認に失敗します。

• 必要な環境変数がありません。
• ゲートウェイのスキーム、ホスト、ポートが想定と異なります。
• 接続やページ遷移がタイムアウトします。
• エンドポイントが正常な応答を返しません。
• 応答が想定したJSONではありません。
• ipフィールドを有効なIPアドレスとして解釈できません。

エラーを解消してから、データ取得処理へ進んでください。

接続できた後に通信経路と取得結果を分けて確認する

接続確認が通ったら、返された出口IPをプロキシを使わない直接接続時の結果と外部に共有せずに比較し、通信経路を確認します。共有スクリーンショットでは、必要に応じてIPアドレスを伏せます。

国の判定は信頼できるサービスで別途確認します。一定期間同じ出口が必要な場合は、ジョブの開始・終了時などにIPを確認し、必要な時間だけセッションが維持されているかを検証してください。その後、許可されたFacebookページ取得処理で、対象へのアクセスとフィールドの内容を確認します。

Facebookスクレイピングのエラーを切り分ける

再試行の前に、プロキシ接続、対象サイトの応答、データ抽出のどこで失敗したかを確認します。以下の「再確認の合格条件」を満たした段階から処理を再開し、認証情報や機密性の高い出力は共有ログに残さないでください。

ブラウザのページ遷移タイムアウトには、複数段階の遅延が含まれる場合があります。必ず読み込み段階の問題と決めつけず、基礎となる接続確認で分類してください。

TCP接続の成功だけでは、認証や対象サイトへのアクセスまで成功したとは判断できません。1つの層を修正したら、まずその層を再確認してからジョブ全体を再開します。

定期実行の前に試験結果を記録する

処理規模を広げる判断は、少数の許可済みページで得た実行記録を基準にします。設定、消費量、検証結果を残せば、再実行や障害調査で同じ条件をたどれます。

実行記録には、次の画面を短い流れで添付します。

1. 入力内容と有限のタイムアウト設定
2. 実行IDとビルド
3. 元レコードとフィールド対応
4. エクスポート後の検証結果

日付とフィールド名は読める状態を保ち、認証情報や不要な個人情報は隠してください。元のエクスポートファイルも保存します。スクリーンショットで画面上の状態を残しても、ファイルを解析できるかどうかは、ダウンロードした実データで確認する必要があります。

まとめ：接続とデータを検証してから運用へ進む

Facebookページのスクレイピングは、必要なデータを定義し、それを返せるツールを選ぶことから始めます。許可済みURLを少数で試し、課金と実行時間の上限を分けて設定したうえで、レコードの照合と出力ファイルの検証を行います。

Rola IPを使う場合は、利用する処理の外部プロキシ対応を確認してください。独立したジョブにはローテーション型と適切なセッション設定、同じ出口が必要な処理には条件の合う固定型を検討します。運用へ進む基準は、許可された取得元、上限のある実行、元情報まで追跡できるレコードがそろうことです。