Keywords

botasaurus review, web scraping, open source, benchmark

Content

Botasaurus は、Omkar Cloud が提供する Python ベースの Web スクレイピング・フレームワークで、スクレイパー構築をひと通りまとめたオールインワン・キットとして案内されています。普通の関数に @browser、@request、@task を付けるだけで、フレームワーク側がブラウザドライバー、ブラウザっぽい HTTP クライアント、キャッシュ、並列処理、複数形式への出力まで面倒を見てくれます。ここで大事なのは、これはメタパッケージだという点です。pip install botasaurus は1つのライブラリを環境に入れるというより、ファーストパーティの複数の wheel と、かなり広い依存ツリーをまとめて組み立てる動きになります。この機械的な事実こそ、私が正直に測れた中でいちばん面白かったポイントでした。

Botasaurus はアンチ検知を前面に押し出していますが、今回のレビューではその論点には踏み込みません。私はフレームワークを調べるにあたり、何がインストールされるのか、何が import されるのか、どんなメソッドがあるのか、どれくらい重いのか、どのライセンスなのかを確認しました。実運用の防御相手にぶつけて性能比較することはしていません。以下のフットプリントや import の数値はすべて pip、python -c "import ..."、そしてページ取得を指示していない状態で生成したクラスの introspection から得たものです。ブラウザを実際に起動したのは後になってからですが、それも自分で書いて 127.0.0.1 で配信したページに対してだけで、ドライバーが自分自身について何を名乗るのか、また JavaScript で自己構築するページから内容を取得できるのかを確かめるためでした。実在サイトは一切使っていませんし、アンチボットサービスにも触れていません。CAPTCHA も扱っていません。実サイトに対する有効性は意図的に対象外ですし、やっていない benchmark をやったように言うより、最初にそう明言しておきたいのです。

その前提を置いたうえでの結論は、フットプリントの話であり、しかも悪くない話です。クリーンインストールすると、中心にあるブラウザドライバーが約 4 MB なのに対し、site-packages 全体では 44 パッケージ、合計 122.3 MB になります。つまり、フレームワークが重いのはドライバーが重いからではなく、「全部入り」をうたう以上、HTML を取りに行く作業に numpy や lxml、gevent、そして他にも十数個の部品を持ち込むからです。もう1つの発見は、よく長所として語られるのに、そのまま信じてはいけない数字です。import botasaurus は 0.08 ms で終わりますが、これは超軽量フレームワークを意味するのではなく、単に玄関が空っぽなだけです。

Botasaurus は実際には何か

Botasaurus — GitHub 上の omkarcloud/botasaurus で、2026年7月14日時点のメタデータ取得時には 5,561 stars、486 forks、58 open issues でした — は、単機能ライブラリではなく Python フレームワークです。私が試したバージョンは、メタパッケージの botasaurus 4.0.97 と、その下で動くエンジンの botasaurus-driver 4.0.92 でした。メタパッケージの requires-python >=3.7（ドライバーは >=3.5）という条件に対し、PyPI の classifier は 3.11 までのサポートしか主張していません。にもかかわらず、私の環境では Python 3.14.2 でインストールでき、import のスモークテストも通りました。これは今回のインストールについての証拠であって、すべての機能の互換性を保証するものではありません。

カテゴリの位置づけは重要です。なぜなら、それによって「良い」とは何かが決まるからです。Botasaurus は フレームワーク 側に属し、Scrapy や Crawlee と同じ系統です。つまり、その構造、デコレーター、慣習に乗る代わりに、周辺の配線を管理してもらうわけです。これは、nodriver のような特化型ドライバーとは違います。nodriver は Chrome DevTools Protocol への接続を提供して、あとは自由に使わせてくれるタイプです。Botasaurus はドライバー（botasaurus-driver）を内包しつつ、それをタスクランナー、キャッシュ層、出力シリアライザー、リクエストクライアントで包み込みます。単なるドライバーを買うのではなく、意見のあるワークフローごと買う、という理解が近いでしょう。

3つのデコレーターが設計の縮図です。そしてこの3つの入口は本物です。botasaurus.browser.browser、botasaurus.request.request、botasaurus.task.task はいずれも存在し、import できることを確認しました。@browser は人間っぽく振る舞うブラウザドライバー上で関数を実行します。@request は見た目がブラウザ風の軽量 HTTP クライアント上で動きます。@task は前の2つに明確に当てはまらないものを包む汎用ラッパーです。デコレートすると、Botasaurus が周辺の仕組みを提供します。並列実行、ドライバーの再利用、結果キャッシュ、JSON/CSV/Excel/HTML への書き出しです。筋の通ったアイデアではあります。これだけのフレームワークをスクレイパーの周囲に置くべきかどうかが、本当の問いであり、それは欠陥ではなく好みの問題です。

総評と、その評価範囲

Botasaurus は、十分に完成度が高く、形も整っていて、フレームワークに期待される仕事、つまり定型処理を短くすることをきちんとやっています。デコレーター方式はわかりやすく、MIT ライセンスは本当に寛容です。インストールも特に揉めません。API の使い勝手だけを採点するなら、かなり良い評価になるでしょう。

ただ、私がずっと引っかかっているのは、このフレームワークの看板である アンチ検知 の部分です。そこを責任あるレビューとして語ろうとすると、誰かの本番防御に向けて試すことになってしまいます。ドライバーには、明らかにアンチ検知を意識した API があります。存在は確認しましたが、挙動はどの対象に対しても試していません。これ以上は断言しません。保護されたサイトに向けたこともありませんし、成功率も測っていませんし、仕組みを逆解析したわけでもありませんし、表現をいじってその3つを匂わせるつもりもありません。メソッドがクラスにあることは事実です。実際の現場で何をするかは、今回のレビューとは別の話です。

以下で扱うのは、機能、インストール、リソース、ライセンスの棚卸しと、私が管理するページ上でドライバーが何をするか、という範囲です。多くのレビューよりもずっと狭い主張ですが、その狭さこそが要点です。

自分自身について何を名乗るか

本物の防御に触れずに答えられる問いがあります。Botasaurus がブラウザを動かすとき、そのブラウザは見ているページに対して自分について何を明かすのか、です。私は、navigator.webdriver、ユーザーエージェント、platform、languages、plugin 数と hardware 数、window.chrome の形、Permissions API の返答、window と screen のサイズといった、わかりやすい項目を読むページを書き、127.0.0.1 で配信し、4つのスタックをそこに向けました。Botasaurus、nodriver、そして比較対象として標準の Playwright と標準の Puppeteer です。4つとも同じ Chrome ビルド（Chrome for Testing 151.0.7922.10）を使っているので、違いがあるならブラウザではなくライブラリ側の差です。headless と headed の両方で、それぞれ3回実行しました。以下の値はすべて3回とも一致しました。

違いはどの比較対象を使うかに依存します。標準の Puppeteer と比べると、Botasaurus は navigator.webdriver を変えていました。language のリストとゼロサイズの window geometry は一致し、ユーザーエージェントだけはバージョン表記が違いました。標準の Playwright と比べると、確認された差分には language リストと window geometry も含まれていました。nodriver と比べると、boolean と languages は一致し、ここで示した範囲では user-agent の表記だけが違っていました。これはデフォルトでの自己開示の観察であって、アンチ検知の成績ではありません。

見かけの false より面白い点が2つあります。1つ目は、その値がどうやってそうなるのかです。4つのスタックすべてで、そのプロパティは依然として Navigator.prototype 上のブラウザ本来の native getter でした。function get webdriver() { [native code] } のままで、インスタンスに後から足された own property でもなければ、置き換えられた関数でもありません。つまり Botasaurus はページ読み込み後にプロパティを書き換えているのではなく、ブラウザ起動時点で値が決まり、プロパティ自体はそのまま残っています。

2つ目は、マーケティングをそのまま信じきれない点です。headless モードでは、Botasaurus のユーザーエージェントは依然として HeadlessChrome/151.0.0.0 と名乗ります。これは標準の Puppeteer と同じで、標準の Playwright とも同じです。headed で動かすと Chrome/151.0.0.0 になりますが、やはり同様です。Driver コンストラクタには user_agent パラメータがありますから、指定すること自体はキーワード引数1つでできます。ただ、デフォルト設定のままでは、ブラウザ自動化で最も有名な自己識別文字列は隠されません。

他の項目は4つのスタックでほぼ同じでした。ここははっきり言っておく価値があります。以下の項目は Botasaurus、nodriver、Playwright、Puppeteer ですべて同じ値でした。

昔からよくある、Permissions API と Notification.permission が食い違う件は、どこにも出ませんでした。4つとも default と prompt で一致していました。さらに document と window を走査して、古い WebDriver スタックで知られていた cdc_ 系の残骸も探しましたが、どれも空でした。

実運用に入れる前にもう1点知っておくべきです。Botasaurus は 122 MB あっても、ブラウザ自体は同梱もダウンロードもしません。find_chrome_executable() は、マシンにすでに入っている Chrome を見つけるだけです。私の環境では /Applications/Google Chrome.app で、バージョンは 150.0.7871.187 でした。そしてそのバージョンがユーザーエージェントにも出ます。あなたの環境が名乗るのは、あなたの fleet にたまたま入っている Chrome そのものです。これだけ意見が強いフレームワークなのに、デフォルトは驚くほど無主張です。

ここで言うべきことは、何がこの観測で何がそうでないかです。これは、誰にも隠すよう求められていない自動化スタックが何を開示するかの記録です。守る側にいる人には役立ちますし、自分のツールが何をばらまいているのか知りたい場合にも役立ちます。ただし、どのサービスにとってそれが重要かを測るものではありません。私はそれを試していませんし、上のどの行も結果を含意していると読まないでください。

この fixture に対する、もう少し寛容な見方

名乗るのと、正しい HTML を返すのとは別の話です。私は Botasaurus を、この benchmark repo の他のツールと同じ3クラスの fixture に向けて動かしました。なので、数値はここで測った他のツールと揃っています。ページには3種類の要素があります。A は静的リンクで、マーカーは配信バイト列にそのまま書かれているもの。B は parse 中に inline script で生成されるノードで、マーカーと URL は断片から組み立てられるため、JavaScript を実行しないと見えません。C は load event の 800 ms 後 に挿入されるノードで、同じように組み立てられます。C がいちばん厄介で、load event 時点で読むと見えません。

Botasaurus は他の重めの実装と同じ地点に着地しました。driver.get() の直後に driver.page_html を読むと、それは load 時点のスナップショットです。JavaScript は正しく実行されます。B クラスが served bytes に存在しないことがその証拠です。ただし、800 ms 遅れの要素 C は逃します。driver.wait_for_element("#delayed-injected") を足せば、3つとも取れます。3回の反復と、スイート全体を3回回した結果で安定しており、flaky にはなりませんでした。

面白いのは、注入遅延を振って、各スタックのデフォルト読取がどこで諦めるかを見るときです。

他のスタックは、注入が load 後 100 ms 以上遅れると、その瞬間に C を取り逃します。Botasaurus だけは 300 ms まで拾い、400 ms でようやく諦めました。これはフレームワークがフレームワークらしくある、という話です。その原因はコンストラクタにあります。wait_for_complete_page_load=True がデフォルトなので、get() は単なる load event よりも意味のあるタイミングで返ってきます。具体的には、デフォルト読取は wall clock で 401〜431 ms かかり、nodriver の 119〜129 ms、Puppeteer の 125〜171 ms よりかなり遅くなります。

このローカルの遅延注入 fixture では、トレードオフはおおよそ1ナビゲーションあたり 250 ms の追加待ちと引き換えに、後から来るデフォルトスナップショットを得る、というものでした。今回の実行では load 後 300 ms までに入ったコンテンツを拾えましたが、だからといって任意のサイトで Botasaurus の方が正確だと断定できるわけではありません。明示的な待機条件を書かずに手早く scraping するなら、この余裕が遅れて来るノードの取りこぼしを防ぐことはあります。逆に高頻度のナビゲーションや、すでに厳密な条件で待っている場合には、単なるオーバーヘッドです。

規模感を見るために、起動時間をもう2つ。ブラウザ起動では Botasaurus は nodriver と Puppeteer とほぼ同じで、Playwright よりはかなり遅れました。

さらに wait_for_element() は、遅延が 300 ms までなら追加コストはほぼありません。get() の時点で注入後の状態にすでに到達していたからです。その後、400〜800 ms では約 1.42 s に、1500 ms では 2.43 s まで伸びます。

122 MB の問い：メタパッケージは実際に何を入れるのか

ここは算数がいちばん役に立ちます。新しい仮想環境で pip install botasaurus をクリーンに実行すると、44 個の dist-info パッケージにまたがる 122.3 MB の site-packages ツリーができました。pip 自体（10.9 MB。これは Botasaurus が要求したものではなく venv のオーバーヘッドです）を除くと、フレームワークと依存関係の合計はおよそ 111 MB です。実際にブラウザを自動化する本体、つまりブラウザドライバーはそのうち約 4 MB にすぎません。ということは、残り約 107 MB はメタパッケージがあなたに必要だと判断したその他すべてです。

では何に使われているのか。トランジティブ依存の重いもの上位5つだけで大半を占めます（各行は artifacts/raw/runs/resource_baseline.run1.json の install_footprint.heaviest_deps_mb エントリです。合計値は私が足したもので、ファイルの項目そのものではありません）。

numpy が最大だったのは意外でした。Web ページを取得して解析する道具の中に、線形代数ライブラリが入っているわけですから。間違いとは言いません。フレームワークは便利な依存を寄せ集めるものですし、ツリーのどこかが配列計算を欲しがっているのでしょう。ただ、この用途に対しては少々大掛かりです。

比較のために言うと、特化型ドライバーの nodriver は同じ環境で 6 パッケージ、約 17.2 MB でした。つまり、およそ 7倍 軽い計算です。（この数値は今回のパックからではなく、同じホストで別タイミングに測った nodriver の artifacts/raw/runs/resource_baseline.run1.json の install_footprint.site_packages_total_mb です。122.3 ÷ 17.2 = 7.1 になります。）どちらも欠陥ではなく、これは機能込みのフレームワークと特化型ドライバーの機械的コスト差です。コンテナでは、この site-packages の実測フットプリントがアプリケーション層に効いてきます。もちろん、これがイメージ全体のサイズではありませんし、今回の測定ではビルド時間や cold deploy 時間も測っていません。

もう1つのフットプリント上の注意点があります。introspection 中に、from botasaurus.request import request を初めて使ったとき、約 12.8 MB の一回限りのダウンロードが発生しました。記録された実行結果では、そのアーティファクトや保存先が十分に特定できなかったため、インストール済みフットプリントの安定した増分としては扱いませんでした。ただ、このコードパスは初回実行時にネットワークアクセスを必要とする可能性がある、ということは示しています。air-gapped なデプロイを考えるなら、自分の環境で再現しておく価値があります。

0.08 ms の import が嘘をつく理由

コールドスタートの import 時間は、数字を雑に読むと間違えやすいところです。7回の新しいサブプロセス import で測ると、トップレベルの import botasaurus は中央値で 0.08 ms でした。これだけを引用すると、このカテゴリで最軽量のフレームワークに見えます。

でも違います。速いのは、中身がほとんどないからです。トップレベルの botasaurus パッケージは __version__ を公開しておらず、public namespace もほぼ空です。import してもやることがほとんどないので、ほとんど時間がかかりません。CLI ツールや serverless の cold start で本当に効いてくるのはエンジンの import で、from botasaurus_driver import Driver は安定して 約 135 ms かかります。これは、1ページも取得する前に払う本当の固定費です。そしてドライバーモジュールを import したあとの resident memory は 29〜30 MB ほどになります。もちろん、まだ Chrome プロセスはありません。実際にブラウザを起動すればこれよりかなり増えますが、メモリは測っていないので数値は置きません。

学びはシンプルですが重要です。import botasaurus が瞬時に終わるのは、フレームワークが軽いからではなく、トップレベルが空洞だからです。cold start を見積もるなら、実際に依存する import を測ってください。

API の形：ほぼ空の玄関の裏にある99メソッド

エンジンの Driver クラスは 99個 の public method を公開しており、ナビゲーション、要素検索、cookie と local storage、マウスとキーボード操作、スクリーンショット、タブ管理、CDP のパススルー、ファイルアップロードまで幅広くカバーしています。コンストラクタは18個のパラメータを取ります。headless、proxy、profile、tiny_profile、block_images、block_images_and_css、wait_for_complete_page_load、chrome_executable_path、extensions、arguments、user_agent、window_size、lang、そしていくつかの追加項目です。構築時 API として見ると、一般的なブラウザラッパーの制御はひと通り揃っています。

ただ、トップレベルの形にはちょっとした落とし穴があります。悪質ではないのですが、確かにあります。import botasaurus で得られる namespace はほぼ空で、__version__ もなく、トップレベルの公開名も実質ありません。実際に使うものはすべてサブモジュール側にあります。from botasaurus.browser import browser, Driver、from botasaurus.request import request、from botasaurus.task import task です。botasaurus.__version__ をログに出してビルドを記録しようとしても見つかりません。代わりに importlib.metadata を使う必要があります。何かが壊れるわけではありません。ただ、Python 開発者が無意識に期待する構成ではないので、初日に混乱して5分無駄にするのを避けられます。

先に触れたメソッドのドキュメントについて、もう1つだけ公平に言えることがあります。存在が確認できたアンチ検知系メソッドのうち、コード内 docstring が付いていたのは 2つだけ でした。残りは名前そのものが説明になっていて、メソッドごとの詳しい説明はインストール済みソースではなく外部ドキュメントサイトにあります。これは品質の評価ではなく、どこに説明が置かれているかという話です。良いライブラリでも、文章はコードの外に置くことは珍しくありません。ただ、あなたの作業が「ソースを読んで理解する」タイプなら、この領域の多くは名前しか教えてくれません。

ライセンス：ドライバーまで含めて MIT

メタパッケージも botasaurus-driver も、いずれも MIT を宣言しており、標準的な License :: OSI Approved :: MIT License classifier が付いています。MIT は寛容です。コピーレフト義務はなく、自分のコードを公開する必要もなく、商用導入の摩擦が小さい。これは、近接するアンチ検知ドライバーである nodriver が AGPL-3.0 で配布されていることと比べると、本当に大きな違いです。AGPL はネットワーク利用条項を含むコピーレフトで、法務部門が警戒しやすいライセンスです。ライセンスが採用判断の条件なら、Botasaurus の MIT は明確な加点材料です。

ただし、ここでもメタパッケージの形に注意が必要です。この寛容な MIT は、Omkar Cloud が公開しているファーストパーティの wheel に適用されるものであって、インストール時に引き込まれる約40個のトランジティブ依存すべてを自動的に保証するわけではありません。それぞれが独自のライセンスを持っています。私は Omkar Cloud が公開しているパッケージのトップレベル MIT は確認しましたが、依存ツリー全体のライセンス監査はしていません。趣味のプロジェクトなら、この違いはあまり問題にならないでしょう。ただ、ソフトウェア部材表を気にする会社でツリー全体を採用するなら、40パッケージのツリーは自前のライセンススキャナーに通してから決めるべきです。問題を見つけたからではなく、見ていないからです。そして、メタパッケージこそ予想外のライセンスが隠れやすい場所です。

良い点と悪い点

良い点:

• @browser / @request / @task の3デコレーター構成がきれいで、3つの入口がすべて確認できる。定型処理が短い。
• メタパッケージとドライバーの両方が MIT ライセンスで、AGPL-3.0 の類似ドライバーとは対照的。寛容で、商用利用しやすく、コピーレフトではない。
• ドライバーの表面積が広い。99個の public method と18パラメータの constructor が、通常のブラウザ自動化ニーズを広くカバーする。
• Python 3.14.2 と 3.12.13 でインストールと import のスモークテストを通過した。classifier は 3.11 までだが、実行時互換性を証明したわけではない。
• 私が測ったスタックの中で、デフォルト読取の猶予が最も広い。load 後 300 ms で注入されたコンテンツまで拾えたのは Botasaurus だけで、nodriver、Playwright、Puppeteer は 100 ms で取り逃した。wait_for_complete_page_load=True が実際に効いている。
• 標準の比較対象が true を返すのに対し、デフォルトで navigator.webdriver が false になる。ただしプロパティは書き換えておらず、descriptor はブラウザ本来の native getter のまま。
• キャッシュ、並列実行、ドライバー再利用、JSON/CSV/Excel/HTML 出力が最初から入っている。後付けではない。

悪い点:

• ディスク使用量が大きい。44パッケージで 122.3 MB、特化型ドライバーの約7倍で、その主因はドライバー本体ではなく numpy（30.9 MB）や lxml（19.2 MB）のような依存関係。
• 安心感のある 0.08 ms のトップレベル import は誤解を招く。本当に依存するエンジン import は約 135 ms で、その後のメモリはブラウザ起動前でも約 29〜30 MB。
• デフォルト読取の猶予が広いのは無料ではない。同じページ・同じ Chrome で、軽量ドライバーの 119〜129 ms に対して、ナビゲーション＋読取が 401〜431 ms かかる。
• headless 実行では、デフォルトの user-agent に HeadlessChrome がそのまま出る。標準の比較対象と同じで、user_agent パラメータはあるのに自動では設定されない。
• 122 MB あるのにブラウザは同梱されない。ホストにすでに入っている Chrome を使うだけなので、開示されるブラウザバージョンは環境依存。
• 今回の実行では @request の初回利用で約 12.8 MB の一回限りのダウンロードが発生した。アーティファクトと保存先が十分に取れておらず、安定した増分とは言えない。
• トップレベル package はほぼ空で __version__ もない。実際の API とバージョンは、もっとわかりにくい場所にある。
• アンチ検知系メソッドの多くはコード内 docstring を持たないため、ソースを読んでも名前しかわからない。

ここで扱った数字の外、つまり未検証の領域は次の通りです。実運用でのアンチボット有効性（意図的に対象外）、ページごとのメモリ、proxy と profile の扱い、大規模時のスループット、そして macOS arm64 以外のプラットフォームです。フットプリントと import の数値はブラウザを一切起動せずに得たもので、取得率と自己開示の数値は 127.0.0.1 上の fixture とだけ話したブラウザから得ています。

どんな人向けで、どんな人は避けるべきか

Botasaurus が向いているのは、部品ではなくフレームワークを欲しい人です。空のファイルからスクレイピングプロジェクトを始めるとき、構造を自分で組み上げるより、ある程度の型を採用したいなら、これは筋の通った MIT ライセンスの選択肢です。MIT は寛容ですが、利用や配布の形に応じた通常のコンプライアンス確認は当然必要です。すでに Scrapy か Crawlee 的な考え方に慣れているチームなら、構成の感覚はすぐつかめるでしょう。

一方で、導入先がサイズにシビアなら、少なくとも再検討した方がいいです。numpy や gevent を抱えた 122 MB のインストールは、実際にやりたいことが「ブラウザを動かしていくつかの項目を取る」だけのとき、スリムなコンテナには重すぎます。特化型ドライバーなら、その何分の一かの重さで自動化を得られますが、周辺の配線は自分で書く必要があります。そして、アンチ検知の有効性そのものを判断したいなら、これは完全に避けるべきです。そこだけは意図的に試していないので、確認も反証もしていないマーケティングの主張を信じることになってしまいます。

代替案と、Thunderbit の位置づけ

まず正直な整理をしておきます。Botasaurus は無料で、MIT ライセンスで、セルフホストです。実行基盤は自分で持ち、更新も自分で管理し、依存ツリー全体 — 44パッケージすべて — を、自分でパッチ管理し、ライセンス順守し、将来のリリースで numpy が何をするかまで引き受けます。多くのチームにとって、その所有権こそが欲しいものであり、1リクエストごとに費用が発生する管理サービスは、純粋なコストで「すでに持っているフレームワーク」に勝てません。

オープンソースの中で比較するときは、形で比べるのが有効です。Botasaurus のようなフレームワーク寄りなら、Scrapy と Crawlee が当然の比較対象です。どちらも成熟していて、意見があり、それぞれ独自の作法があります。クローラーを組み立てるフレームワークではなく、ページから LLM 向けの Markdown が欲しいだけなら、Crawl4AI やコンテンツ抽出特化の Trafilatura がその用途に寄っています。Python でアンチ検知寄りの軽めのものを探すなら Scrapling が候補になりますし、コンパイル言語もありなら Go の Colly は JavaScript レンダリングを捨てる代わりに速度と軽さを得ています。Botasaurus を含むあらゆるブラウザ駆動型の選択肢は、Playwright と Puppeteer の比較 で示したコスト構造を引き継ぎます。実ブラウザは安く動かせるものではなく、その分フレームワーク側に重量が乗るのです。

マネージド API は、その同じパイプラインの別の地点にあります。Botasaurus はセルフホストの開発者向けスタックです。Thunderbit は、同じ開発者向けにマネージド版を提供しています。Open API は2エンドポイントです。POST /distill（1 credit）は、ページをクリーンで LLM 対応の Markdown として返します。レンダリングとアンチボット処理はサーバー側で行われるので、ブラウザも依存ツリーも自分で用意する必要がありません。POST /extract（20 credits）は、あなたが定義した JSON Schema に対して構造化 JSON を返します。renderMode は none、basic、full から選べ、ページにどれだけブラウザが必要かで切り替わります。どちらにも最大100 URL までのバッチ版があります。エージェントやコーディングアシスタント向けには MCP server があり、thunderbit_suggest_fields は無料で、料金を払う前にページが何を持っているかを教えてくれます。cron や CI 向けには npx @thunderbit/thunderbit-cli の CLI もあります。コードを書きたくない非開発者向けには、Chrome extension が同じエンジンをノーコードツールとして使いますし、Thunderbit の YouTube チャンネル の解説動画では典型的なワークフローを確認できます。

トレードオフは、どちらが優れているかではなく、仕事をどこで持つかです。Botasaurus は、フレームワーク、ブラウザ群、依存関係、インフラ、保守をあなた側で抱え、リクエストごとのベンダー課金はありません。ただし、計算資源、帯域、プロキシ、運用コストは引き続き必要です。マネージド API は、レンダリングとスキーマに沿った出力を肩代わりし、その分だけ呼び出し課金になります。自前構成と比べるなら、料金ページ で見積もれます。

Webデータ抽出に Thunderbit を試す

結論

Botasaurus は、オールインワンの Python フレームワークが欲しく、その依存フットプリントを受け入れられるなら、十分に有力な候補です。3デコレーターの設計は明快で、ドライバーの表面は広く、classifier が主張しているより新しい Python でもインストールと import のスモークテストを通過しました。私のローカル fixture では、デフォルトのスナップショットが load 後 300 ms で挿入されたコンテンツまで拾え、他のテスト済みスタックが 100 ms で取り逃したのも事実です。ただし、これは fixture の結果であって、一般的な順位ではありません。

ただし、主張のサイズ感は正しく見てください。これは 122 MB、44パッケージのインストールで、ドライバー本体は約 4 MB、残りは numpy、lxml、gevent などです。特化型ドライバーの約7倍で、その重さはコンテナイメージと cold deploy 時間に跳ねます。0.08 ms のトップレベル import は空っぽの玄関にすぎず、軽いフレームワークを意味しません。実際に請求されるのは、約 135 ms のエンジン import です。寛容なデフォルト読取には、ナビゲーションごとに約 250 ms のコストがかかります。そして、実際に答えられた default-disclosure の問いでは、マーケティングが示すほど広い景色ではありませんでした。標準の Puppeteer とは1つの boolean だけが違い、headless の user-agent には相変わらず HeadlessChrome が出て、その他の観測項目は4つのスタックで全部同じでした。このツールを売る看板であるアンチ検知の主張こそ、今回のレビューでは採点していません。メソッドの存在は確認し、自分のマシン上のページに対してドライバーを動かしたところで止めました。意図的です。フットプリントを把握し、気持ちのいい import 数字は無視し、ステルスの売り文句は未解決の問いとして扱うなら、Botasaurus はフレームワークとしてきちんと仕事をする製品です。羽のような軽さのドライバーを期待すると、docker build の時間に驚くでしょう。

Webデータ抽出に Thunderbit を試す Get Started Free

FAQ

Botasaurus は無料ですか？ ライセンスは何ですか？ 無料で、MIT ライセンスです。botasaurus のメタパッケージも botasaurus-driver のエンジンも、OSI 承認の MIT classifier を持っています。MIT は寛容で、コピーレフト義務がなく商用利用にも向いています。これは、AGPL-3.0 で配布される同種のアンチ検知ドライバーと比べると、かなり大きな違いです。注意点は、MIT が Omkar Cloud の自社パッケージに適用されるだけで、インストールが引き込む約40個のトランジティブ依存を自動的にカバーするわけではないことです。会社でツリー全体を採用する前には、自分たちのライセンススキャンを通してください。

Botasaurus のインストールサイズはどれくらいですか？ また、なぜ import botasaurus は一瞬に見えるのですか？ 新しい環境でのクリーンな pip install botasaurus は、私の環境で 44 パッケージ・122.3 MB の site-packages ツリーを作りました。ブラウザドライバー本体は約 4 MB しかなく、重さの大半はメタパッケージが広い依存ツリーを連れてくることに由来します。主なものは numpy（30.9 MB）、lxml（19.2 MB）、botasaurus_requests（12.6 MB）、gevent（11.3 MB）、pygments（8.4 MB）です。同じマシン上で見ると、nodriver のような特化型ドライバーの約7倍のフットプリントです。これは欠陥ではなく、「全部入り」の代償であり、特にコンテナイメージのサイズに効きます。import 時間でそのフットプリントが隠れて見えるだけで、import botasaurus は約 0.08 ms しかかかりませんが、それはトップレベル package がほぼ空だからです。__version__ もなく、公開名もほとんどないので、import してもやることがほぼありません。本当にコストがかかるのはエンジンの from botasaurus_driver import Driver で、約 135 ms です。その後、ブラウザが起動する前でも resident memory は約 29〜30 MB あります。serverless の cold start を見積もるなら、空っぽのトップレベルではなく、エンジンの import を測ってください。

Botasaurus は自分自身について何を開示しますか？ 実際のアンチボット対策で試しましたか？ 前半は測定しましたが、後半は意図的にやっていません。127.0.0.1 で配信したページに対し、比較対象と同じ Chrome ビルドを動かしたところ、navigator.webdriver は false でした。標準の Playwright と Puppeteer はどちらも true を返します。この値はプロパティのパッチではなく、ブラウザ起動時に決まっています。descriptor は Chrome 本来の native getter のままです。それ以外の大半の項目は比較対象と一致しました。platform 文字列、plugin 数、12 コア、16 GB の端末メモリ、window.chrome の形、Permissions API の不一致がないこと、document と window に cdc_ 系の残骸がないこと、これらはすべて同じでした。headless 実行では user-agent に HeadlessChrome/151.0.0.0 がそのまま出ます。これは比較対象2つも同じです。Driver コンストラクタには user_agent パラメータがありますが、自動では設定されません。効果については、ライブサイトに向けておらず、アンチボットサービスにも接続せず、CAPTCHA も触っていません。アンチ検知向けの名前を持つメソッド群の存在は確認しましたが、どの対象にも呼び出していませんし、挙動も測っていませんし、成功率も出していませんし、仕組みも説明していません。上の開示テーブルは、スタックが何を名乗るかを示すだけで、誰がそれを見てどうするかは示していません。

Botasaurus は JavaScript レンダリングされたコンテンツを正しく扱えますか？ はい、しかもデフォルトはかなり寛容です。3種類のコンテンツを持つ fixture では、driver.get() と driver.page_html の組み合わせで、800 ms の注入遅延に対して 3件中2件を取得しました。JavaScript は正しく実行されていますが、遅すぎるコンテンツは読取時点にまだ来ていません。driver.wait_for_element() を使うと 3件中3件になります。特徴的なのは、デフォルト読取がどこで諦めるかです。Botasaurus は load 後 300 ms までに注入されたコンテンツを拾えますが、nodriver、Playwright、Puppeteer は 100 ms で落とします。これはコンストラクタの wait_for_complete_page_load=True によるもので、ナビゲーションごとに約 250 ms のコストがかかります。

インストール後、Botasaurus はどう import して使えばいいですか？ 多くの人が想像する形ではありません。トップレベルの botasaurus namespace はほぼ空なので、実際の API はサブモジュールにあります。from botasaurus.browser import browser, Driver、from botasaurus.request import request、from botasaurus.task import task を使います。普通の関数に @browser、@request、@task を付けると、フレームワークがドライバー、キャッシュ、出力まわりを処理します。botasaurus.__version__ はないので、実行しているビルドをログに残したいなら importlib.metadata を使ってください。