0xMassi/webclaw とは何ですか？

URL を LLM 向けの markdown / JSON に変換する Rust 製ツール。CLI、MCP サーバー、セルフホスト可能な REST サーバーを同梱する。ローカル完結を売りにする一方、ライセンスは AGPL-3.0 で、ホステッド版 webclaw.io が並存する構成を確認する。

0xMassi/webclaw は商用利用できますか？

厳しい条件付きでできます。AGPL-3.0 はネットワーク型コピーレフトのライセンスで、改変版をホスティングサービスなどとしてネットワーク越しに利用させる場合、その利用者にソースコードを同じライセンスで提供する必要があります。

0xMassi/webclaw は今もメンテナンスされていますか？

されています。最後のコミットは 1 日前です。

0xMassi/webclaw はどのプログラミング言語で書かれていますか？

主に Rust です（GitHub の言語統計による）。

webclaw レビュー: Rust 製ローカル抽出と AGPL-3.0 の実務判断

ひと目でわかる

これは何？: URL を LLM 向けの markdown / JSON に変換する Rust 製ツール。CLI、MCP サーバー、セルフホスト可能な REST サーバーを同梱する。ローカル完結を売りにする一方、ライセンスは AGPL-3.0 で、ホステッド版 webclaw.io が並存する構成を確認する。
誰に向いている？: ローカルで完結する抽出パイプラインを Rust の単一バイナリで持ちたいチーム、とくに MCP 経由でエージェントにスクレイプさせたい個人や小規模開発者には向く。逆に、抽出ロジックを自社サービスに組み込んでソース非公開で配布したい場合、AGPL-3.0 が障害になる可能性が高く、採用前に法務確認が要る。
商用利用できる？: 厳しい条件付きでできます。AGPL-3.0 はネットワーク型コピーレフトのライセンスで、改変版をホスティングサービスなどとしてネットワーク越しに利用させる場合、その利用者にソースコードを同じライセンスで提供する必要があります。
今もメンテナンスされている？: されています。最後のコミットは 1 日前です。
何の言語で書かれている？: 主に Rust です（GitHub の言語統計による）。

回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。

オープンソース詳細解説

Hysen Labs 編集部 · 2026年9月10日 · 0xMassi/webclaw

webclaw が埋める「ブロックされたページか、生 HTML か」の隙間

README はスクレイピングツールの出力を二種類に類型化している。ひとつはブロックされたページ、ログインウォール、空のアプリシェル。もうひとつはナビゲーション、スクリプト、スタイル、広告、重複したボイラープレートまみれの生 HTML である。webclaw はこの中間、つまり本文だけを取り出した markdown や JSON、あるいは LLM 向けに整形したテキストを返すことを狙う。対象読者は AI エージェントに Web を読ませたい開発者と、RAG パイプラインに文書を取り込みたい開発者だ。README の例では webclaw https://example.com --format markdown という一行で、Example Domain の本文だけが markdown として出てくる。ナビゲーションもスクリプトも残らない。ここで重要なのは、webclaw がブラウザ自動化ツールではなく抽出ツールだという点である。ページを操作したりフォームを送ったりする用途は想定されていない。

ローカル抽出とホステッド API の二層構造

README によれば、リポジトリにはオープンソースの CLI、MCP サーバー、抽出エンジン、セルフホスト可能なサーバーが含まれる。一方 webclaw.io は webclaw のホステッド抽出 API と位置づけられている。つまり同じ抽出エンジンに対して、手元で動かす経路と、API キーで叩く経路の二つがある。README のツール一覧では scrape、crawl、map、batch、extract、summarize、diff がローカル実行可能と明記され、extract と summarize はローカルまたは設定済みの LLM を使うとある。ローカル列に Yes が付く範囲では API キーは不要で、README も「ほとんどのサイトはローカルで抽出でき、API キーは不要」と述べている。WEBCLAW_API_KEY を設定するのは bot 保護や JavaScript レンダリングされたページを扱う場合だと説明されている。この切り分けは設計思想として明確で、静的 HTML は手元で処理し、難しいページだけ外部に投げるという運用を想定していると読める。

CLI の実際のフラグと、crawl の制約

README が示すフラグは用途ごとに分かれている。出力形式は --format で markdown、llm、json、text、html を選ぶ。本文だけに絞るなら --only-main-content。抽出対象を制御するなら --include "article, main, .content" と --exclude "nav, footer, .sidebar, .ad" を併用する。サイト全体を辿る場合は webclaw https://docs.rust-lang.org --crawl --depth 2 --max-pages 50 のように、深さとページ数の上限を明示する。上限を指定しない crawl は対象サイトの規模によっては際限なく広がるため、この二つのフラグは実質必須と考えたほうがよい。ページの変化を追うなら --format json で出力をファイルに保存し、--diff-with pricing-old.json で比較する。ブランド資産の抽出は --brand で、色、フォント、ロゴを対象にする。ここで注意したいのは、README に crawl が同一オリジンのリンクのみを辿ると書かれている点だ。外部ドメインをまたぐクロールは想定されていない。

MCP サーバーとしての導入手順

エージェント連携は MCP サーバー経由で行う。README の設定例は次のとおり。mcpServers に webclaw というエントリを作り、command を npx、args を ["-y", "@webclaw/mcp"] にする。これで Claude Code、Claude Desktop、Cursor、Windsurf、OpenCode、Codex CLI など MCP 対応クライアントから呼べる。設定ファイルを手で書く代わりに npx create-webclaw を実行すると、対応クライアントを検出して MCP サーバーの設定を書き込むと README は説明している。エージェントスキルとして使う場合は npx skills add 0xMassi/webclaw-skill を実行すると、scrape、crawl、map、extract、summarize、diff、brand、search がネイティブツールとして公開される。インストール経路は他に Homebrew（brew tap 0xMassi/webclaw の後に brew install webclaw）、GitHub Releases のバイナリ、Docker（ghcr.io/0xmassi/webclaw）、Cargo（webclaw-cli と webclaw-mcp を git から）がある。ソースビルドが失敗する場合は pkg-config、libssl-dev、cmake、clang などのネイティブツールが必要で、README は Debian/Ubuntu、Fedora/RHEL、Arch、macOS それぞれのコマンドを表で示している。

AGPL-3.0 がホステッド版との関係で意味するもの

ライセンスは AGPL-3.0 で、リポジトリの LICENSE に紐づく。AGPL の特徴は、ソフトウェアをネットワーク経由で提供する場合にもソース開示が及ぶ点にある。webclaw の場合、自社でセルフホストしたサーバーを顧客向け API として公開する使い方がまさにこの条項の射程に入りうる。README はホステッド版 webclaw.io の存在を明示しており、同じ抽出エンジンを OSS と商用ホステッドの両方で提供する構図になっている。したがって、webclaw を組み込んだサービスをソース非公開で外部提供したい場合、AGPL-3.0 が障害になる可能性がある。ここは法的助言ではないので、実際の配布形態が条項に触れるかは法務に確認してほしい。CLI を社内ツールとしてだけ使う、あるいは MCP サーバーを個人の開発環境で動かす範囲なら、この問題は生じにくい。

Firecrawl 互換 API と何が違うのか

README のトピックとサンプルには firecrawl-alternative、crawl4ai-alternative、jina-alternative といった語が並び、examples/ には firecrawl-compatible-api というディレクトリがある。Firecrawl はクラウド API を中心に据えた抽出サービスで、API キーを渡して HTTP で叩くのが基本の使い方になる。webclaw は同じ抽出を Rust のバイナリとして手元で実行できる点を前面に出す。README が「ローカル」列をわざわざ設けているのはそのためだ。違いは実行場所と依存関係にある。Firecrawl 系はネットワーク越しの従量課金とレート制限が前提になり、webclaw のローカル経路はその制約から離れられる。ただしローカルで完結するということは、bot 保護や JS レンダリングへの対処も自分の環境で抱えるという意味である。README はその逃げ道として WEBCLAW_API_KEY によるホステッド API を用意している。ローカル優先とホステッド併用のハイブリッドは、完全セルフホストを掲げる crawl4ai 系とは方向性が異なる。

限界と、向かないケース

README から読み取れる制約はいくつかある。第一に、crawl は同一オリジン限定である。複数ドメインを横断して収集したい場合、crawl を繰り返し呼ぶか batch を自分で組む必要がある。第二に、JS レンダリングや bot 保護のあるページはローカルでは扱いきれず、WEBCLAW_API_KEY を設定してホステッド側に回す前提になっている。つまり完全オフラインで難しいページまで処理する、という使い方は README の範囲では示されていない。第三に、extract と summarize はローカルまたは設定済みの LLM に依存する。LLM を別途用意しない限り、この二つのツールは動かない。第四に、リリース間隔が短い。v0.6.20 と v0.6.21 は同じ日に出ており、v0.6.22 はその二週間後である。0.6 系の段階で API やフラグが安定しているとは限らない。バージョンを固定して検証する姿勢が要る。

導入前に確かめるべき三つのこと

最初に確認すべきは、自分の対象サイトでローカル抽出がどこまで通るかである。README の例にある stripe.com や docs.anthropic.com のような静的寄りのページと、ログインの後ろにあるページや SPA では結果が違うはずだ。次に、crawl の --depth と --max-pages を自分のサイト規模に合わせて設計する。上限なしの crawl は意図しない負荷を対象サイトにかける。最後にライセンスである。AGPL-3.0 の下で自社の配布形態が許容されるかを、法務と確認しておく。これらを済ませてから、まず CLI 単体で試し、問題がなければ MCP サーバー経由でエージェントに接続する順序が現実的だ。リポジトリはアーカイブされておらず、最終 push は 2026-09-09 である。

編集部の結論

ローカルで完結する抽出パイプラインを Rust の単一バイナリで持ちたいチーム、とくに MCP 経由でエージェントにスクレイプさせたい個人や小規模開発者には向く。逆に、抽出ロジックを自社サービスに組み込んでソース非公開で配布したい場合、AGPL-3.0 が障害になる可能性が高く、採用前に法務確認が要る。導入前に確認すべきは 3 点。第一に、README に挙げられた v0.6.22 時点の CLI フラグ（--format、--only-main-content、--include/--exclude、--crawl、--brand、--diff-with）が自分の対象サイトで期待どおり動くか。第二に、WEBCLAW_API_KEY を設定しないローカル抽出で、JS レンダリングや bot 保護のあるページがどこまで扱えるか。第三に、AGPL-3.0 の下で自社の配布形態が許容されるかどうか。この 3 点が固まらないうちは、本番の RAG パイプラインに組み込まないほうがよい。

公式情報源

コミュニティノート