fastCRW：AI agent 向けの一体型 Web data API
AI agent に「Web を調べさせる」と、問題はすぐ prompt ではなく engineering の話になる。
検索して、結果を開き、ページを markdown に変換し、dynamic page、timeout、site map、batch crawl、structured extraction、citation を扱う。多くのチームは最初 browser automation script でつなぐが、あとから安定性、queue、retry、output format、cost、agent client への接続が本題だと気づく。agent にとって Web は「開ければよい」ものではなく、repeatable で、引用でき、rate limit できる context supply chain であるべきだ。
今日メモしておきたい us/crw は、project name でもあり、product name としては fastCRW と書かれることが多い。Rust 製の Web data API で、search、scrape、map、crawl、extract、monitor といった操作に加え、Firecrawl 互換 interface、Python/TypeScript SDK、binary release、Docker/self-host path、MCP server を提供する。新しい browser wrapper というより、「Web から agent が使える data へ」の経路を、local でも managed cloud でも動かせる service にまとめるプロジェクトだ。
2026-07-11 時点で GitHub repository API、README、LICENSE、release API、tags API、recent commits API から確認できる公開情報では、us/crw は 299 stars、24 forks。主言語は Rust、engine の license は AGPL-3.0。リポジトリ作成日は 2026-03-02 19:51:43 UTC、最近 push は 2026-07-10 15:59:18 UTC。main の最新 commit は 376f8d98、commit time は 2026-07-10 15:58:52 UTC。最新 GitHub release は v0.23.0 で、公開時刻は 2026-07-10 10:13:35 UTC。最新 tag も v0.23.0 を指している。
プロジェクト概要
| 項目 | 内容 |
|---|---|
| リポジトリ | us/crw |
| 位置づけ | AI agents 向けの Web search、scrape、crawl、structured extraction API |
| Stars | 299 |
| Forks | 24 |
| 主言語 | Rust |
| ライセンス | AGPL-3.0 |
| リポジトリ作成日 | 2026-03-02 19:51:43 UTC |
| 最近 push | 2026-07-10 15:59:18 UTC |
| 最新 main commit | 376f8d98、2026-07-10 15:58:52 UTC |
| 最新バージョン | v0.23.0 |
| リリース公開時刻 | 2026-07-10 10:13:35 UTC |
| 主な機能 | search、scrape、map、crawl、extract、monitor、MCP server、Firecrawl-compatible API |
Web 処理を script ではなく service boundary にする
fastCRW の README は core interface をかなり明確に切っている。/v1/search は検索、/v1/scrape は単一ページを markdown、HTML、links、JSON に変換、/v1/map は site URL の発見、/v1/crawl はサイト全体の async crawl、extract は schema に沿った structured field extraction、monitor は page change diff を扱う。agent workflow では、この verb の形が分かりやすい。「model に browser を渡して自力で何とかさせる」より、system boundary に置きやすい。
Firecrawl 互換の使い方も意識されている。すでに agent や RAG pipeline を Firecrawl に接続しているチームなら、fastCRW を replacement backend として試しやすい。README は managed cloud と self-host が同じ API を使い、切り替えは主に base URL の変更だと説明している。この設計は tool evaluation に向いている。まず local で小さく試し、output format と failure behavior を確認してから、cloud を使うか決められる。
プロジェクト自体は Rust service だが、利用者が Rust を触る必要はあまりない。README に出てくる入口は cURL、Python SDK、TypeScript SDK、Docker、Homebrew、APT、crates.io、GitHub release binary、MCP package などだ。小さなチームなら、現実的な入口は二つある。HTTP API として backend queue の横に置くか、MCP server として Claude Code、Cursor、Codex CLI、Gemini CLI などの agent client につなぐかだ。
MCP の意味は「Web を調べる」を制御された tool にすること
多くの agent demo では、Web access はかなり緩い能力として扱われる。browser を渡す、shell を渡す、network を渡す。そして model が逸脱しないことを願う。fastCRW の MCP server は、Web access を一連の verb に絞るものに近い。agent が search したければ search、scrape したければ scrape、crawl したければ crawl を呼ぶ。返ってくるのは browser state ではなく、structured object と cleaned content だ。
実運用では、この形に二つの利点がある。
ひとつめは observability だ。agent が何回 search したか、どの URL を scrape したか、どの request が timeout したか、crawl job が何ページ返したかを集計できる。browser automation でも log は取れるが、通常は自分でかなり glue code を足すことになる。
ふたつめは permission boundary だ。社内 agent が必要としているのは公開 documentation の取得だけかもしれず、任意の shell network capability ではない。Web data capability を MCP server や internal HTTP service に閉じ込めれば、service layer に rate limit、allowlist、cache、audit、cost control を足しやすい。fastCRW がその governance を自動で完成させるわけではないが、temporary script よりも拡張しやすい境界を提供している。
search、scrape、crawl が一緒にあるのが実用的
単体の Web scraping tool は多い。単体の search API も多い。fastCRW の面白さは、この二つを同じ API に置いているところだ。search は結果を返し、scrape は単一ページを処理し、map は site URL を発見し、crawl は whole site を async に回し、extract は内容を schema JSON に圧縮し、monitor は変化検知を扱う。
これは agent/RAG の context preparation ではかなり実用的だ。たとえば agent に未知の open-source project の docs を読ませたい場合、homepage 一枚を scrape するだけでは足りない。より自然な流れは、docs site を map し、重要 path を crawl し、各 page を markdown にしてから、clean content で model に回答させることだ。競合調査や dependency monitoring でも、毎回 full scrape するより monitor/diff の方が noise を抑えやすい。
README では、built-in Web search が SearXNG のような self-hostable search backend を使い、追加の search vendor dependency を減らす方向も説明されている。これは実際に deployment して検証すべき点だが、方向性はよい。agent の Web context cost は LLM token だけではない。search API、browser instance、proxy、queue、failure retry もコストになる。これらを一つの service に集めると、少なくとも cost と failure point が見えやすくなる。
benchmark は見る。ただし自分で再現する
fastCRW の README は benchmark をかなり前面に出している。truth-recall、latency、memory usage、Firecrawl/Crawl4AI との比較などだ。recent commits にも benchmark discipline に関する作業があり、paired-delta stats、confidence interval、manifest hash、per-track report といった言葉が見える。単なる宣伝数字ではなく、test process に構造を足そうとしていることは分かる。
それでも production adoption では、benchmark は手がかりに過ぎない。Web scraping の成果は target site、location、anti-bot behavior、JS rendering、proxy pool、output requirement に強く依存する。本当に知りたいのは「公開 dataset で誰が勝つか」ではなく、「自分たちが読む URL から十分きれいな内容を安定して取れ、失敗時に扱える error を返すか」だ。
試すなら、実際に扱う 50 から 100 URL を選ぶのがよい。static docs、dynamic page、login なし page、長文 docs、list page、error page を混ぜる。成功率、markdown readability、latency、resource usage、failure category、retry cost を記録する。fastCRW を agent toolchain に入れるなら、README の数値ではなく、この実 URL set で既存方式と比べたい。
注意したいところ
第一に、license はよく見る必要がある。repository engine は AGPL-3.0 で、README では Python/TypeScript client SDK は MIT と説明されている。SDK を使うことと engine を使うことは別だが、modified version を network service として提供する場合、AGPL の義務は軽く扱えない。社内利用や商用利用の前に、責任者または法務と境界を確認したい。
第二に、「あらゆる Web data service の完全無料代替」ではない。README には managed cloud と self-host の両方がある。cloud には credits と pricing があり、self-host には machine、proxy、search backend、maintenance、abuse protection のコストがある。open-source engine は exit path をくれるが、運用コストを消すわけではない。
第三に、project は新しい。リポジトリ作成日は 2026-03-02、現在の latest version は v0.23.0 で、recent commits も活発だ。活発なのは良いが、API、SDK return shape、deployment parameter、benchmark method はまだ変わり続ける可能性がある。critical path に入れるなら version pin と rollback path を用意したい。
第四に、Web scraping には compliance boundary がある。robots、site terms、copyright、personal information、target site load は必ず考える必要がある。fastCRW は agent が Web data を取りやすくするが、「取れる」ことは「取ってよい」ことではない。
まとめ
us/crw / fastCRW が気になるのは、agent の Web access を one-off script から service interface に引き上げているからだ。search、scrape、crawl、structured extraction、monitoring、MCP、Firecrawl-compatible API が同じ線上にある。
coding agent、research agent、internal RAG system に Web context を足していて、今の構成が browser script、散らばった search API、手書き markdown cleanup の寄せ集めになっているなら、fastCRW は小さく評価する価値がある。価値は「すべての page を最良に取れる」ことではない。agent が Web data を必要としたとき、呼ぶ先が deployable、observable、replaceable な tool になることだ。