中国国内の SNS リサーチや KOL 分析、越境マーケティング調査の現場では、小紅書（Xiaohongshu）や抖音（Douyin）といった中国発プラットフォームからのデータ収集が避けて通れないテーマになりつつあります。しかし、これらのプラットフォームは JavaScript による署名アルゴリズムや Web リクエストの暗号化を採用しており、いわゆる「JS 逆向解析」の壁に阻まれてスクレイピング基盤の構築が難しいという課題があります。
こうした状況を打開する選択肢の一つが、NanmiCoder/MediaCrawler という OSS です。中国 SNS 7 プラットフォームに対応した Python 製のデータ収集ツールで、GitHub のスター数は 55,160、フォーク数は 11,163 と、この領域では突出した支持を集めています（数値は 2026年7月1日時点のリポジトリメタデータに基づきます）。
一方で、初見のエンジニアが導入判断を下すには、対応プラットフォームの範囲、Playwright ベースの技術構造、そして「Non-Commercial Learning License 1.1」という独自の非商用学習ライセンスなど、確認すべき論点が多数あります。特にライセンスは GitHub 上の SPDX 表示が「NOASSERTION」となっており、企業内での利用可否を判断するには LICENSE ファイルの原文にあたる必要があります。
本記事では、MediaCrawler の技術原理・対応機能・類似 OSS との違い・ライセンス条件・メンテナンス状況を、公式リポジトリと公式ドキュメントの記述に基づいてドキュメントベースで整理します。動作検証やインストールを伴う実体験ではなく、あくまで「自プロジェクトに採用すべきか」を検討するための判断材料の提示を目的とします。読み終えた時点で、MediaCrawler が自プロジェクトの用途と制約に適合するか、あるいは Spider_XHS や MediaCrawlerPro など別の選択肢を検討すべきかの見取り図を得られる構成にしています。
MediaCrawlerとは｜中国SNS 7プラットフォームに対応するデータ収集OSS
MediaCrawler は、開発者 NanmiCoder 氏によって公開されている Python 製の OSS で、中国国内で広く利用されている主要 SNS・動画プラットフォーム 7 種類に対応した公開情報の収集ツールです。リポジトリの README では「多平台自媒体数据采集工具」と定義されており、単一プラットフォームに特化するのではなく、複数プラットフォームを 1 つのコードベースで統合的に扱う点が最大の特徴です（出典: NanmiCoder/MediaCrawler）。
対応プラットフォーム一覧
MediaCrawler が対象とするプラットフォームは以下の 7 種です。いずれも中国国内で強い存在感を持つ SNS・動画・Q&A サービスで、日本市場や欧米市場を対象とした Twitter・Instagram・TikTok（国際版）などはスコープ外となります。
プラットフォーム | 種別 | 主な用途 |
|---|---|---|
小紅書（Xiaohongshu / XHS） | 写真・レビュー SNS | ライフスタイル・化粧品・旅行のクチコミ調査 |
抖音（Douyin） | ショート動画 | 動画マーケティング・KOL 分析 |
快手（Kuaishou） | ショート動画 | 地方都市層のマーケティング調査 |
B站（Bilibili） | 動画共有 | ACG・エンタメ・技術系 UGC 分析 |
微博（Weibo） | 短文投稿型 SNS | ニュース・世論分析 |
貼吧（Baidu Tieba） | 掲示板 | ロングテール話題の抽出 |
知乎（Zhihu） | Q&A | 専門分野の議論・意見集約 |
このラインアップから分かる通り、MediaCrawler は「中国国内向けのマーケティングリサーチ、KOL 分析、話題モニタリング」に用途が明確に絞られた OSS です。中国以外の SNS を主対象とする場合、選定候補から外れる点は導入判断の最初の分岐点になります。
リポジトリ基本情報
執筆時点（2026年7月1日）のリポジトリメタデータは以下の通りです。数値は gh api /repos/NanmiCoder/MediaCrawler のレスポンスに準拠しています。
項目 | 値 |
|---|---|
主要言語 | Python |
スター数 | 55,160 |
フォーク数 | 11,163 |
最終 push | 2026-07-01 |
ライセンス（SPDX） | NOASSERTION（実体は Non-Commercial Learning License 1.1） |
archived | false（アーカイブされていない） |
fork | false（本家リポジトリ） |
disabled | false |
visibility | public |
archived=false かつ fork=false であることから、本記事執筆時点で MediaCrawler は本家リポジトリとしてメンテナンスが継続中です。直近の push が 2026年7月1日である点、およびスター 55,160・フォーク 11,163 という規模は、中国 SNS スクレイピング領域では突出した支持を示しています。ただし SPDX ID の NOASSERTION はライセンス選定上の重要な論点で、後述するライセンスセクションで詳しく触れます。
MediaCrawlerが解決する課題とアプローチ
MediaCrawler の技術的な価値を理解するには、中国 SNS からのデータ収集で従来ハマりやすい問題を先に整理しておくと分かりやすくなります。
従来のスクレイピングで壁になるポイント
小紅書・抖音・微博をはじめとする中国 SNS は、Web API のリクエストに「x-s」「x-t」「_signature」などの署名パラメータを付与しており、この値は JavaScript 内の複雑な暗号化アルゴリズムによって生成されます。従来型のスクレイピング手法（requests + BeautifulSoup 等）でこれらのプラットフォームからデータを取得しようとすると、以下のような壁にぶつかります。
- 署名生成ロジックがブラウザ内 JavaScript に埋め込まれており、リバースエンジニアリング（いわゆる「JS 逆向解析」）が必須になります
- 署名アルゴリズムはプラットフォーム側の更新で頻繁に変わるため、追随コストが大きくなります
- ログイン後にのみ取得できるデータ（コメント・詳細情報など）にアクセスするには、Cookie 管理や CSRF トークンの取り扱いが加わります
これらの理由から、中国 SNS のスクレイピング基盤を内製すると、専任のエンジニアが署名解析の追随に張り付く体制が必要になりがちで、事業目的（リサーチ・KOL 分析）に対する ROI が悪化しやすいという課題があります。
Playwright + ログイン状態保持による回避戦略
MediaCrawler は、ブラウザ自動化フレームワークである Playwright を土台に、この課題を回避しています。README の技術原理セクションでは、以下の考え方が明記されています（出典: MediaCrawler README「技术原理」）。
- 保持したログイン状態のブラウザコンテキストを再利用し、JS 実行環境から署名パラメータを取得します
- 複雑な暗号化アルゴリズムを逆向解析する必要がなく、参入障壁が大きく下がります
要点は、「署名生成ロジックそのものを解析するのではなく、生成された署名値をブラウザ内の JS 実行式（page.evaluate() 相当）から取り出す」というアプローチにあります。プラットフォーム側が署名アルゴリズムを更新しても、ブラウザ内で生成される最終的な値を取得している以上、追随コストがゼロになる訳ではないものの、暗号化ロジックのリバースエンジニアリングよりは大幅に軽くなります。
CDPモードで既存Chromeを再利用する仕組み
MediaCrawler は、Playwright が起動するブラウザとは別に、既存の Chrome ブラウザに CDP（Chrome DevTools Protocol）経由で接続するモードも README で紹介されています。この方式では、既にユーザーがログイン済みの Chrome プロファイルを再利用でき、Playwright ドライバの追加インストールが不要になるという利点があります。
一方で、標準の Playwright モードでは Playwright 用のブラウザドライバを別途インストールする必要があります。両モードの使い分けは、環境構築の制約（既存 Chrome の有無、ブラウザプロファイルの管理方針）と、無人運用したいかどうかで判断するのが妥当です。詳細な設定手順は公式ドキュメントで案内されているため、後述のリンクを起点に READMEおよびドキュメントを確認してください。
対応機能と機能マトリクス
MediaCrawler がどこまで「使える OSS」なのかを判断するには、プラットフォームごとの機能カバレッジを確認するのが近道です。README では、7 プラットフォーム × 7 機能軸のマトリクスが提示されています。
プラットフォーム × 機能マトリクス
以下は README「功能特性」セクションで示されている対応状況を日本語で整理したものです（出典: MediaCrawler README「功能特性」）。
プラットフォーム | キーワード検索 | 投稿ID指定 | 二階層コメント | クリエイター主頁 | ログイン状態キャッシュ | IPプロキシプール | コメントWordCloud |
|---|---|---|---|---|---|---|---|
小紅書（Xiaohongshu） | 対応 | 対応 | 対応 | 対応 | 対応 | 対応 | 対応 |
抖音（Douyin） | 対応 | 対応 | 対応 | 対応 | 対応 | 対応 | 対応 |
快手（Kuaishou） | 対応 | 対応 | 対応 | 対応 | 対応 | 対応 | 対応 |
B站（Bilibili） | 対応 | 対応 | 対応 | 対応 | 対応 | 対応 | 対応 |
微博（Weibo） | 対応 | 対応 | 対応 | 対応 | 対応 | 対応 | 対応 |
貼吧（Baidu Tieba） | 対応 | 対応 | 対応 | 対応 | 対応 | 対応 | 対応 |
知乎（Zhihu） | 対応 | 対応 | 対応 | 対応 | 対応 | 対応 | 対応 |
7 プラットフォームすべてで同じ機能軸が揃っている点が、MediaCrawler の設計思想を象徴しています。プラットフォーム間でのデータ形式差分は内部で吸収され、上位のユーザーは「どのプラットフォームでも同じ CLI 引数と設定で扱える」構造になっています。
一方で、機能軸が「収集系」に統一されている点にも注意が必要です。分析・可視化・投稿・ダウンロードといった機能は基本的にスコープ外で、あくまで「収集して保存する」までを担う設計になっています。分析・可視化までワンストップで実現したい場合は、後段のパイプラインを別途構築する前提になります。
データ保存形式のバリエーション
MediaCrawler が収集したデータは、以下の形式で保存できます。プロジェクトの後段の分析パイプラインに合わせて選択できるため、ETL 実装の柔軟性が高いという評価につながります。
- CSV
- JSON
- JSONL
- Excel
- SQLite
- MySQL
構造化データを直接 RDB に流し込みたい場合は MySQL や SQLite、BI ツールや Excel での即時分析であれば CSV や Excel、機械学習の前処理パイプラインに乗せるなら JSONL、といった使い分けが想定されます。詳細な設定は公式の 公式ドキュメント で案内されています。
WebUIの位置づけ
MediaCrawler には、コマンドラインだけでなく、可視化操作画面（WebUI）を起動する機能も含まれています。README によれば、FastAPI ベースのバックエンド（api/ 配下）と Vite ベースのフロントエンド（webui/ 配下）で構成され、開発時は Vite の dev server、本番時はビルドされた静的資源を FastAPI から配信する二段構えになっています。
コマンドライン操作に不慣れなリサーチャーやアナリストにも扱いやすい導線を用意しつつ、CI・自動化パイプラインからは Python CLI として動かす、という二面利用が想定できる構造です。
セットアップと基本的な実行フロー
このセクションでは、README に記載されている前提要件と代表的な実行コマンドを、動作検証を伴わないドキュメントベースで整理します。実際のインストールや起動は、公式リポジトリの README と公式ドキュメントに従って読者自身の環境で行うことを前提としています。
前提要件
README で明記されている前提は以下の通りです。
- Python 依存管理: uv（推奨）
- Node.js 16.0.0 以上
- Chrome 144 以上（CDP モードで既存 Chrome に接続する場合）
- Playwright 用ブラウザドライバ（標準 Playwright モードの場合のみ）
Python のパッケージマネージャとして uv が推奨されている点は、近年の Python プロジェクトのトレンドを反映しており、pip と venv の組み合わせよりも依存解決の再現性が高い構成になっています。CDP モードで既存 Chrome を再利用する場合は Playwright ドライバのインストールが不要な代わりに、Chrome バージョンが 144 以上である必要があります。
実行コマンド例（README抜粋）
README では、以下のようなコマンド例が示されています（出典: MediaCrawler README）。
uv sync
uv run main.py --platform xhs --lt qrcode --type search
uv run main.py --platform xhs --lt qrcode --type detail
uv run main.py --help
uv sync で依存関係を同期した後、main.py を --platform 引数付きで実行します。--platform xhs は小紅書を指定し、--lt qrcode は QR コードによるログイン方式、--type search はキーワード検索モード、--type detail は投稿 ID 指定モードを表します。他のプラットフォームを対象とする場合は --platform の値を差し替える形になります（dy で抖音、ks で快手など、詳細は --help で確認可能）。
QR コード方式は、スマートフォンの各 SNS アプリで QR を読み取ることでログインを完了させる、中国の SNS で一般的な認証フローです。この方式が採用されていることで、パスワード・2FA・SMS 認証の実装差異を吸収し、複数プラットフォームで統一的なログイン導線を提供している点も MediaCrawler の設計の巧妙な部分です。
WebUI起動フロー
README には、WebUI を起動する場合の構成として、FastAPI ベースのバックエンドと Vite ベースのフロントエンドの起動が案内されています。開発モードでは Vite の dev server（webui/ ディレクトリ配下）と FastAPI サーバー（uvicorn 経由）を並走させ、本番モードでは Vite でビルドした静的資源を FastAPI から配信する構成になります。
具体的な起動コマンドは、リポジトリ更新に追随して差分が発生する可能性があるため、公式ドキュメント の該当セクションを参照するのが確実です。
類似OSSとの違い｜Spider_XHS・social-media-copilotとの比較
MediaCrawler が「自プロジェクトの第一候補」になるかを判断するには、類似 OSS との比較が欠かせません。ここでは、3 つの類似リポジトリを軸に、方向性の違いを整理します。
プラットフォームカバレッジで見る使い分け
まず、対象プラットフォームの広さで比較します。
リポジトリ | 対象プラットフォーム | 方向性 |
|---|---|---|
MediaCrawler | 小紅書・抖音・快手・B站・微博・貼吧・知乎（7 種） | マルチプラットフォーム統合 |
小紅書のみ | 単一プラットフォーム深堀り | |
小紅書・抖音・快手・B站 | マルチプラットフォーム（範囲は MediaCrawler より狭い） |
Spider_XHS は小紅書に特化しており、PC API 実装や KOL・分销データ抽出など、小紅書に固有の高度なユースケースをカバーする方向で開発が進んでいます。プロジェクトの対象が小紅書だけで完結し、より深い機能（発信 API・KOL 分析等）が必要な場合は、Spider_XHS の方が適合する可能性があります。
一方、MediaCrawler は 7 プラットフォームを 1 つのコードベースで統合的に扱えるため、複数プラットフォームを横断してデータを収集し、後段で統合分析する用途に強みがあります。
動作形態（サーバー / ブラウザ拡張）で見る使い分け
次に、実行形態の違いです。
- MediaCrawler: Python プロセスから Playwright を制御する「サーバー / CLI 型」
- social-media-copilot: Chrome / Edge のブラウザ拡張機能として動作。API サーバー版もあり、Docker デプロイに対応
social-media-copilot はブラウザ拡張として動作するため、非エンジニアがブラウザ上のボタンから GUI で操作できる導線が最初から用意されています。単発の調査タスクや、非エンジニアのリサーチャーが手動で対象データを取得する用途では、こちらの方が親和性が高い場合があります。
一方、CI パイプラインや定期実行スケジューラ、あるいは分析基盤の一部として自動化したい場合は、Python CLI として制御できる MediaCrawler の方が組み込みやすい構造です。
取得 vs 投稿の方向性
同じ「SNS 自動化」でも、取得（scrape）と投稿（upload）は方向が逆で、用途が全く異なります。
- MediaCrawler: 取得（scrape）方向のツール
- social-auto-upload: 投稿（upload）方向のツール。抖音・小紅書・視頻号・TikTok・YouTube・Bilibili への投稿自動化に対応
同じ SNS を扱っていても、リサーチ・分析目的で情報を集めたいのか、コンテンツを配信・パブリッシュしたいのかで、選ぶべき OSS は全く別物になります。両者を混同すると要件と実装がすれ違うため、プロジェクトの目的が「収集」なのか「配信」なのかを最初に明確化する必要があります。
MediaCrawlerProとの棲み分け
MediaCrawler の作者は、有償版として MediaCrawlerPro を別 GitHub Organization で提供しています。両者はソースコードレベルで別プロジェクトとして分離されており、OSS 版から Pro 版へのシームレスなアップグレードパスは用意されていません（この点は README にも明記されています）。
OSS版とPro版の主要差分
Pro 版で提供される追加機能として、README では以下が挙げられています。
- 断点続爬（中断からのレジューム）
- マルチアカウント + IP プロキシプール標準対応
- Playwright 依存の除去
- Linux 環境完全対応
- 自媒体コンテンツ解体 Agent（LangGraph ベース）
- AI Agent Skill サポート（Claude Code / Cursor / OpenClaw 連携）
- 動画ダウンローダーデスクトップ
Pro 版はソースコード購入型の「知識付費」モデル（有償で学習コンテンツとソースコードを提供するモデル）で運用されており、OSS 版とは互換性のない別プロジェクトとして分離管理されています。詳細な提供形態については 公式ドキュメントの知識付費紹介 を参照してください。
どちらを検討すべきかの判断軸
OSS 版と Pro 版のどちらを検討すべきかは、以下の観点で切り分けるのが実用的です。
観点 | OSS 版が適する条件 | Pro 版を検討すべき条件 |
|---|---|---|
用途 | 学習・研究目的、社内 PoC、小規模リサーチ | 大規模・継続運用、業務組み込み |
ライセンス許容度 | 非商用限定で問題ない | 商用利用が必要（別途契約が必要） |
レジューム要件 | 中断・再開が発生しない、または手動対応で許容できる | 大規模クロールでレジュームが必須 |
マルチアカウント | 単一アカウントで足りる | 複数アカウント・IP ローテーションが必要 |
AI Agent 連携 | 不要 | LangGraph・Claude Code・Cursor 等との連携を活用したい |
「まず動く形で試したい」「PoC で仮説検証したい」というフェーズであれば OSS 版で十分ですが、実運用フェーズに入り、規模・信頼性・商用利用可否が論点になった段階で Pro 版が選択肢に上がる、という位置づけです。
ライセンスと利用範囲｜商用利用可否と実務上の判断
MediaCrawler を採用検討する上で最大の論点は、ライセンスです。GitHub の SPDX ID は NOASSERTION と表示されており、これは OSI（Open Source Initiative）が認定するオープンソースライセンスに該当しないことを意味します。実体としては、リポジトリの LICENSE ファイルに明記された独自の「Non-Commercial Learning License 1.1」が適用されます（出典: MediaCrawler LICENSE）。
Non-Commercial Learning Licenseの要点
LICENSE ファイル本文には、以下の主要条項が含まれています（該当箇所の抜粋）。
NON-COMMERCIAL LEARNING LICENSE 1.1
Copyright (c) [2024] [relakkes@gmail.com]
The Software is limited to learning and research purposes only, and may not be
used for large-scale crawling or activities that disrupt platform operations.
Without the written consent of the copyright owner, the Software may not be
used for any commercial purposes or to cause improper influence on third
parties.
要点を日本語で整理すると、以下の 3 点が特に重要です。
- 用途は「学習および研究目的」に限定される
- 大規模クロール、およびプラットフォームの運営を妨害する行為は禁止される
- 商用目的での利用、または第三者に不当な影響を与える利用は、著作権者の書面同意なしには認められない
商用利用・大規模クロール禁止条項の意味
「商用目的の利用は書面同意が必要」という条項は、企業内で MediaCrawler を業務ワークフローに組み込むことを事実上制限します。たとえば、以下のような利用は原則としてライセンス条項に抵触する可能性があります。
- クライアント向けのマーケティングリサーチレポートを作成するため、業務として MediaCrawler で継続的にデータを収集します
- 自社の商用 SaaS プロダクトにデータ収集機能として MediaCrawler を組み込みます
- 有償のリサーチサービスの原資として MediaCrawler で収集したデータを販売します
一方で、以下のような用途は「学習・研究目的」の範囲として比較的整理しやすいものと解釈できます。
- 社内エンジニアが技術検証として MediaCrawler の内部構造を学びます
- 大学・研究機関での学術研究の一環として、小規模なデータ収集を行います
- 商用化前の PoC で、実現可能性の検証としてサンプルデータを取得します
ただし、これらの解釈は最終的には各企業の法務判断に委ねられます。README 内の免責声明では、中国国内法（网络安全法 等）への遵守も強調されており、日本国内で利用する場合は、自国の法制度に加え、各プラットフォームの利用規約（例: 小紅書の利用規約）にも別途配慮する必要があります。
各プラットフォーム利用規約との整合性
MediaCrawler のライセンスとは別軸で、収集対象となる各プラットフォームの利用規約にも留意する必要があります。多くの SNS では、自動化ツールによるスクレイピングを禁止・制限する条項を利用規約に含んでおり、これはツール側のライセンス条項とは独立して適用されます。
つまり、MediaCrawler のライセンス条件をクリアしていても、対象プラットフォームの利用規約に違反する形で運用した場合、アカウント停止や法的措置のリスクが発生し得ます。この二重のチェックは、実務でこの種の OSS を採用する際の基本動作として押さえておくべきポイントです。
メンテナンス状況とコミュニティ
導入判断のもう一つの重要な観点が、「今後もメンテナンスが継続されるか」というリスク評価です。
リポジトリ規模の位置づけ
執筆時点のリポジトリメタデータは、スター 55,160・フォーク 11,163 という規模です。中国 SNS スクレイピング領域だけでなく、Python 製 OSS 全体で見ても上位クラスの支持を得ているプロジェクトで、単一開発者のホビープロジェクトが放置されるリスクは相対的に低いと評価できます。
最終 push は 2026年7月1日で、直近のコミット活動も継続しており、archived=false かつ fork=false である点からも、本家リポジトリとして現在もアクティブに開発が続いていることが確認できます。
コミュニティ動線
README では、微信交流群（WeChat グループ）や B 站の開発者アカウントなど、中国国内の主要コミュニケーションチャネル経由でのコミュニティ動線が案内されています。日本語や英語のコミュニティ導線が同等に整備されているわけではないため、日本のエンジニアが情報収集する場合は、README・公式ドキュメント・GitHub Issues が主要な情報源になります。
深い議論や中国語圏の最新知見にアクセスしたい場合は、B 站の開発者チャンネルを参照するのが有効ですが、コミュニケーション上の言語ハードルは織り込んで計画する必要があります。
MediaCrawlerの採用判断チェックリスト
最後に、これまで整理してきた論点を「初見エンジニアが自プロジェクトへの採用可否を判断する」ためのチェックリストとしてまとめます。以下の項目に順番に回答することで、MediaCrawler がプロジェクトに適合するか、あるいは類似 OSS や Pro 版を検討すべきかの見取り図が得られます。
- 対応プラットフォームの適合性: 収集対象が中国 SNS 7 プラットフォーム（小紅書・抖音・快手・B站・微博・貼吧・知乎）のいずれか、あるいは複数に該当するか。中国以外の SNS（Twitter・Instagram・TikTok 国際版など）が対象の場合、MediaCrawler は不適合です。
- ライセンス制約の許容度: 用途が「学習・研究・PoC」の範囲に収まるか。業務ワークフローへの組み込みや商用サービスへの利用が必要な場合、Non-Commercial Learning License の条項を法務と協議の上、書面同意の取得または別ライセンス製品の検討が必要になります。
- プラットフォームカバレッジの広さ: 単一プラットフォーム（例: 小紅書のみ）で完結するなら、Spider_XHS のような特化 OSS の方が機能深度で優位な場合があります。マルチプラットフォーム統合が必要な場合、MediaCrawler の統一設計が強みになります。
- 動作形態の要件: ブラウザ拡張として非エンジニアが操作する必要があるなら social-media-copilot、CI・自動化パイプラインから制御するなら MediaCrawler、というトレードオフを整理してください。
- OSS版の機能で足りるか: レジューム・マルチアカウント・大規模運用・AI Agent 連携が必要なら Pro 版が選択肢になります。学習・PoC・小規模運用であれば OSS 版で十分です。
- 各プラットフォーム利用規約と自国法制度: MediaCrawler のライセンス条件とは別に、収集対象プラットフォームの利用規約、および日本の法制度への配慮が必要です。特に商用利用を検討する場合は、法務・コンプライアンス担当と事前協議を行ってください。
これらの観点をチェックすることで、単に「機能一覧を眺めて採用可否を決める」よりも、意思決定の解像度を高められます。MediaCrawler は、中国 SNS のマルチプラットフォーム統合スクレイピング OSS としては現時点で最も広い機能カバレッジと活発なメンテナンスを持つ選択肢の一つですが、その利用範囲は独自ライセンスと各プラットフォームの利用規約によって明確に区切られています。導入検討時にはこれらの制約を最初に確認することが、後工程でのトラブルを避ける最も確実な方法になります。
