Bun 1.4がWebスクレイパーに進化

ネイティブWebViewがPlaywrightへの依存を回避

Simon Willison氏は自身の研究において、Bun 1.4の新機能であるBun.WebViewモジュールをテストしました。リリースノートではランタイムコアのRustでの書き直しとアイドル時のCPU使用率の5分の1への減少が大きく取り上げられていますが、実際の変化は自動化において起こりました。WebViewはローカルのChromiumまたはmacOS WebKitインスタンスを制御するサポートをネイティブに統合しました。これにより、多くの小規模なタスクにおいてPuppeteerやPlaywrightのような重量級フレームワークをダウンロードしてインストールする必要性を事実上排除しました。

データ抽出とテストのためのより軽量な代替手段

単にページを読み込み、JavaScriptを実行し、スクリーンショットを撮りたいだけの開発者にとって、参入障壁は劇的に下がりました。Willison氏は依存関係のない約150行のTypeScriptを使用し、自身のshot-scraperツールに触発された完全に機能するJSON APIを構築しました。このAPIはリクエストごとに新しいブラウザタブを起動し、並行クエリを処理し、/javascriptや/screenshotのようなエンドポイントを介して構造化されたJSON結果またはエラーを返すことができます。

メモリ要件に潜む罠

コード自体は軽量ですが、Webエンジンを支配する物理法則は変わりません。Willison氏のcgroupsテストにより、複雑なWebページで完全なChromeプロセスを実行するには、依然として約192〜256MBのRAMを備えたコンテナが必要であることが明らかになりました。メモリの節約は、ページレンダリング自体ではなく、主に制御コードとNode.jsのオーバーヘッドの排除に適用されます。512MBのRAMを備えたマイクロインスタンスでは、大量の並行スクレイピングはあっという間にメモリ不足によるクラッシュを引き起こす可能性があります。

サーバーレスおよび小規模プロジェクトでの採用が真の実用性を示す

重要なテストは、このモデルが研究実験から日常的な本番ワークフローに移行するかどうかです。これまでPlaywrightのインストールによってビルド時間が不釣り合いに膨れ上がっていた、小規模なスクレイピングコンテナやCI/CDパイプラインにおいて真の影響が見られるでしょう。Bun.WebViewの信頼性が証明されれば、新世代の軽量な分析および自動化エージェントの基本的な構成要素となるでしょう。

Lilithの判定

巨大なフレームワークのインストールという方程式から外せば、ブラウザの自動化はDevOpsの領域から使い捨てスクリプトのカテゴリーへとシフトします。これはあらゆる小さなエージェントにとって無料のインフラストラクチャなのです。