MediaCrawler オープンソースツールとは？

「ログインできるから大量収集できる」と考えているなら、まず止まってください。MediaCrawler オープンソースツールは、Playwrightとログイン状態の再利用を使った複数サービス向けの公開情報収集プロジェクトであり、無条件の商用大量収集サービスではありません。利用前に、プロジェクトの免責事項、ライセンス、対象サービスの規約、適用される法令を確認するのが最短の安全策です。 (GitHub公式リポジトリ)

この記事を読むべき人

Playwrightを学びながら複数サービスの公開データ収集基盤を組みたい開発者、研究目的のデータパイプラインを設計するデータエンジニア、ブラウザー自動化環境を長期間運用する技術責任者に向けた内容です。単にコマンドを実行したいだけで、収集目的や保管期間を決めていない場合は、先に運用条件を整理してください。

※最終更新日：2026年8月13日。対応サービス、依存関係、保存方式、WebUI、免責事項は、同日確認した公式リポジトリと公式ドキュメントを基準にしています。対象サービスの規約やプロジェクトの内容は変更されるため、実行直前にも再確認してください。

MediaCrawlerは何を解決するオープンソースツールですか？

MediaCrawlerは、複数のコンテンツサービスを個別に操作する代わりに、共通した収集処理とサービス別の実装を組み合わせるプロジェクトです。公式READMEでは、小紅書、抖音、快手、Bilibili、微博、百度贴吧、知乎の7サービスが対応対象として掲載されています。対応数だけで選ぶのではなく、あなたの調査対象が現在の実装と一致しているかを確認してください。 (GitHub公式README)

主な収集パターンは、キーワード検索、指定コンテンツ、投稿者ページの確認、コメントを含む詳細情報の取得です。これにより、例えば「特定テーマの投稿を調べる」「指定URLやIDの内容を保存する」「投稿者単位で公開情報を比較する」といった研究型の作業を一つのコードベースで試せます。

一方で、次の3つの制約を見落とすと、技術的には動いても運用として失敗します。

• 規約とライセンスの制約：公式ライセンスは非商用の学習・研究用途を前提にし、大規模収集やサービス運営を妨げる行為を制限しています。ライセンスの条件と対象サービスの規約は別々に確認する必要があります。 (MediaCrawlerのライセンス)
• ログイン状態の制約：Cookie、ブラウザーのプロファイル、QRコード認証後のセッションに依存するため、セッション失効や追加認証で処理が止まる可能性があります。
• 画面変更の制約：Playwrightで画面を操作する構成は、サービス側のHTML、JavaScript、ログインフローが変わると修正が必要です。APIのように長期互換性が保証される仕組みではありません。

導入前に選ぶべき構成はどれですか？

まず、収集目的と運用期間から構成を選びます。最初から複数サービスを同時に動かすより、1サービス・少量・短期間で挙動を確認し、保存項目と停止条件を固めるほうが安全です。

公式READMEの現行記載では、Node.jsは16.0.0以上、CDPモードで接続するChromeは144以上が前提です。標準Playwrightモードを使う場合は、uv run playwright installで対応ブラウザーを導入します。Playwright自体も、ライブラリの更新後にブラウザーの再インストールが必要になる場合があると説明しています。 (MediaCrawlerの公式README)

注意：CDPの遠隔デバッグポートをインターネットへ直接公開しないでください。ログイン済みのブラウザーへ接続できる入口になり得るため、ローカル接続、SSHトンネル、ファイアウォール、接続元制限を組み合わせます。

第一歩：インストール前に用途と停止条件を決めます

最初に、次の項目を1枚の設計メモへ書き出してください。ここを曖昧にすると、収集量だけが増えて、削除や説明責任の設計が残りません。

1. 目的：研究、学習、公開情報の傾向分析など、収集理由を具体化します。
2. 対象範囲：サービス名、キーワード、投稿者、期間、必要な項目を限定します。
3. 利用者：自分だけが見るのか、研究チームで共有するのかを決めます。
4. 保管期間：原データと集計データを同じ期間保存しないようにします。
5. 停止条件：規約変更、アカウント異常、本人確認要求、データ用途の拡大が起きたら停止します。

「公開されている投稿だから収集してよい」という判断はできません。MediaCrawlerの免責事項は学習・研究目的を強調していますが、実際の適法性をプロジェクト声明だけから判断することはできません。著作権、個人情報、データベースの権利、契約上の利用条件などを、利用地域と対象サービスに照らして確認してください。

導入前に、利用する遠隔環境の管理範囲やサポート条件も確認しておくと、後から認証情報を移す作業を減らせます。Macの遠隔利用を検討している場合は、kvmbootのサービス概要で、利用形態が自分の管理要件に合うかを先に確認してください。

第二歩：Python、Node.js、ブラウザーを分離して準備します

公式READMEでは、推奨の依存管理方法としてuv syncが案内されています。古い記事のコマンドをそのまま使うのではなく、公開リポジトリのREADME、pyproject.toml、依存ファイルを同日に確認してください。Node.jsが必要なサービスもあるため、Pythonだけ用意すればよいとは限りません。 (MediaCrawlerの依存関係に関する公式情報)

標準的な確認順は次のとおりです。

1. リポジトリの対象ブランチとコミットを確認します。
2. Python環境を作り、uv syncまたはプロジェクトの指定方法で依存関係を導入します。
3. Node.jsのバージョンを確認します。
4. CDPモードならChromeのバージョンと接続方式を確認します。
5. 標準Playwrightモードなら、ブラウザー本体とOS依存パッケージを導入します。
6. 収集を始める前に、空のテスト用保存先とログ出力先を分けます。

PlaywrightはChromium、Firefox、WebKitを扱えますが、MediaCrawlerの各サービス実装がすべてのブラウザーで同じように動くことを意味しません。プロジェクトが案内する既定構成を優先し、ブラウザー変更は検証項目として扱ってください。 (Playwright公式Pythonドキュメント)

第三歩：ログイン状態を作り、認証資産を隔離します

MediaCrawlerの公式説明では、Playwrightを使ったブラウザー自動化と、保存したログイン状態の再利用が中心です。CDPモードでは既存のChromeへ接続し、Cookieやブラウザーの状態を再利用できます。初回実行ではQRコードによるログイン手順が例示されています。 (MediaCrawlerのログイン方式に関する公式説明)

実行時は、次の順序で進めると切り分けやすくなります。

1. 収集専用のブラウザープロファイルを作成します。
2. 個人利用のブラウザーや仕事用アカウントと混在させません。
3. 画面でログインし、対象サービスの表示範囲を確認します。
4. 小さな検索条件または指定コンテンツで読み取りだけを試します。
5. セッションファイル、Cookie、ログ、エクスポートデータの権限を確認します。
6. 処理終了後に、不要な認証状態を削除または無効化します。

Cookieとアカウント情報は秘密情報として扱います。リポジトリ、共有ストレージ、チャット、バックアップへ無加工で保存しないでください。また、CDPの管理ポートを複数人で共有すると、誰がどのアカウントを操作したか追跡しにくくなります。

第四歩：収集範囲を最小化し、保存先を決めます

キーワード検索、指定コンテンツ、投稿者ページでは、必要なデータ量と個人情報の含まれ方が異なります。例えば市場調査の初期段階なら、本文全文やコメント全件ではなく、投稿ID、公開日時、公開URL、集計に必要な反応数など、目的に必要な最小項目から始めます。

公式の保存ガイドでは、CSV、JSON、JSONL、Excel、SQLite、MySQL、PostgreSQLが案内されています。JSONLは1行ごとにJSONオブジェクトを保存する形式で、SQLiteはサーバーを別途用意せずに扱えるため、個人の検証に向きます。複数工程で検索・集計する場合は、データベースの権限設計と削除処理まで先に決めてください。 (MediaCrawlerのデータ保存ガイド)

保存方式の選び方は次のように整理できます。

• JSONL：後処理や差分確認をしやすい一方、重複排除や検索は別途必要です。
• CSV・Excel：人が内容を確認しやすい一方、長文や複数テーブルの管理には不向きです。
• SQLite：小規模な研究に扱いやすい一方、多人員での同時更新には向きません。
• MySQL・PostgreSQL：継続的なパイプラインへ組み込みやすい一方、認証、バックアップ、削除権限の設計が必要です。

WebUIでは、プラットフォーム、ログイン方式、収集タイプなどを設定し、実行状態やログ、データのプレビューと出力を確認できます。開発用の構成ではAPIサーバーとフロントエンドを別々に起動し、README記載の例ではAPIが8080、開発用フロントエンドが5173を利用します。遠隔環境で使う場合、これらのポートを公開する前に認証とネットワーク制御を追加してください。 (MediaCrawlerのWebUI説明)

第五歩：長期運用では「動かす」より「止める」を設計します

ブラウザー自動化の長期運用では、プロセスが起動しているだけでは成功とは言えません。次の問題が継続的に発生します。

• ブラウザープロセスの残留：異常終了後にプロセスや一時ファイルが残ると、次回起動時にプロファイルがロックされます。
• ログイン状態の失効：Cookieの期限切れ、端末確認、QRコード再要求で処理が停止します。
• 通信状態の揺らぎ：接続断、名前解決エラー、読み込み遅延により、保存データが途中で欠けることがあります。
• サービス仕様の変更：画面要素や公開範囲が変わると、同じ設定でも取得結果が変わります。
• データの蓄積：原文、コメント、画像URL、ログを残し続けると、保存場所とアクセス権の管理負担が増えます。

そのため、監視項目は「プロセスが動いているか」だけにしないでください。最終成功時刻、取得件数の急変、ログイン画面への遷移、保存ファイルの更新、エラー分類を確認し、異常があれば自動再試行より先に処理停止と人による確認を優先します。

遠隔環境を使う場合は、管理者だけが接続できる構成にしてください。ブラウザー自動化の運用では、CPUやメモリだけでなく、画面セッション、ディスクの書き込み、再起動後の復旧手順も確認対象になります。

どの時点で収集を止めるべきですか？

次のいずれかに該当した場合は、処理を一度停止します。

1. 対象サービスの利用規約、公開範囲、API条件が変更された。
2. アカウントへ異常通知、追加認証、利用制限が表示された。
3. プロジェクトのREADME、ライセンス、免責事項が更新された。
4. 収集対象が研究用の公開情報から、個人特定、広告配信、商用データ販売などへ広がった。
5. 取得したデータを第三者へ提供する必要が生じた。
6. 画像、動画、コメントなどの権利関係を確認できなくなった。

この停止条件は、アクセス制限を回避するための手順ではありません。認証画面、アクセス制御、利用制限を回避する方法を追加するのではなく、対象範囲を縮小する、正式なAPIやデータ提供制度を調べる、または収集を中止する判断が必要です。

長期運用を想定するなら、管理入口とアカウント分離を確認できる環境を選びます。Macを使う場合も、サービス規約とライセンスの制約が消えるわけではありません。

まとめ：MediaCrawlerを採用する判断基準

MediaCrawlerは、複数サービスにまたがる公開情報の扱いを学びたい人にとって、Playwright、ログイン状態、サービス別実装、保存層を一度に確認できる教材です。7サービス対応、WebUI、複数のファイル・データベース保存方式が用意されている点は、研究用の小さなパイプラインを作るうえで便利です。

ただし、非商用の学習・研究用途を前提とするライセンス、大規模収集を制限する条件、対象サービスごとの規約、ログイン状態の機密性を考えると、企業の本番データサービスとして無条件に採用するものではありません。まず1サービス・少量・短期間で検証し、保存項目、削除期限、監査ログ、停止条件を決めてから次へ進むのが妥当です。

研究用の小規模な検証環境を遠隔で用意する場合は、管理者の接続範囲、ブラウザーの分離、認証情報の保管場所を先に決めてください。利用期間や管理方法を検討する際は、kvmbootのサービス概要も確認すると、環境選定に必要な条件を整理しやすくなります。

よくある質問

FAQは、導入前に検索されやすい疑問を、対応サービス、ログイン、保存形式、遠隔運用、適法性の5点に分けて整理しています。

「公開情報を扱うから大丈夫」という前提で現在の構成をそのまま運用すると、アカウントの停止、保存データの過剰蓄積、規約変更への対応遅れという3つの問題が残ります。自前のWindowsやLinux環境でも動かせますが、画面セッションの維持、ブラウザープロセスの監視、遠隔管理入口の制限を自分で設計しなければなりません。短期の学習や検証で専用のMac環境が必要なら、kvmbootのレンタル環境を選ぶほうが、端末購入や環境廃棄を伴わずに期間を区切って試せます。ただし、長期の安定稼働や物理デバイス接続が必要な場合は、自社保有環境や正式APIのほうが適しています。

公開データ収集の目的、対象サービスの規約、アカウント管理を確認した段階で、管理入口や認証情報の扱いを含むブラウザー自動化環境の運用条件を確認してください。認証情報を扱う際は、kvmbootのヘルプセンターに掲載された利用上の案内も参考にし、収集範囲と保管期間を事前に文書化しておくと安全です。