HN 日本語サマリー

← 一覧へ戻る
AI・機械学習

Kitesurf: V8アイソレートで動作するエージェントファーストブラウザ

Kitesurf: Agent-first browser that runs in V8 isolates (blog.cloudflare.com)

196 pointsby m3h52 コメント

要約

Cloudflareは、AIエージェント向けに設計された新しいブラウザ「Kitesurf」を発表しました。これは、従来のブラウザエンジン(Chromiumなど)がAIエージェントにとって不要なオーバーヘッド(タブ、拡張機能など)を多く持つという課題に対処するため、Workers上で動作するように開発されました。KitesurfはCPUとメモリ消費量が大幅に効率的で、スクリーンショットやHTML抽出などのエージェントタスクに最適化されています。開発にはRustとWebAssemblyが活用され、Web Platform Tests(WPT)や視覚回帰テストなどの厳格なテストプロセスを経て、高い品質と堅牢性を実現しています。

全文翻訳

独自のブラウザを構築すべきか?これは、Cloudflare社内で長年、数ヶ月ごとに持ち上がってきた質問の一つです。当然のことながら、それは多くの理由と、それを構築すべきであるという説得力のある議論を伴う長いスレッドを引き起こす種類の質問です。ブラウザは明らかに私たちが毎日コンピューターで使用する最も重要なソフトウェアであり、インターネットのオペレーティングシステムと言えるでしょう。私たちはより良いインターネットを構築するという使命を持つ企業です — 新しいブラウザを構築するという挑戦に誰が乗り出したくないでしょうか?しかし、私たちはそのような事業の技術的な困難さと、それによって解決するユニークな問題とのバランスを完全に見つけることができませんでした。そして、そのアイデアは何度も棚上げされてきました。しかし今、転機が訪れました。 魔法のようなことが起こりました。私たちのデベロッパープラットフォームにおける一連の強力な技術的進歩が現実のものとなり、AIエージェントの出現と新しい種類のブラウザへの需要が同時にクリティカルになったのです。WorkersでのWebAssembly(Wasm)の実行は非常に成熟しました。ダイナミックワーカー、SQLiteベースのDurable Objects、Worker間RPC、サービスバインディング、高いNodeJS互換性、そしてより高い制限は、以前は不可能だった、より野心的で複雑なアプリケーションへの扉を開きます。 AIの台頭とともに、私たちのヘッドレスブラウザ自動化API製品であるBrowser Runは、目覚ましい成長を遂げています。エージェントは多くのタスクを実行するためにブラウザを必要とし、多くの場合、それなしでは成功できません。しかし、問題があります — Chromiumのようなブラウザエンジンは人間向けに構築されており、AIモデルには不要なオーバーヘッドが伴います。それらは膨大なメモリとコンピューティングリソースを消費するため、各エージェントに独自のインスタンスを提供することは法外に高価であり、Webの大部分を、より高いパラメータ知識を持つ最も洗練された高価なAIモデルにのみ制限し、他の多くのエージェントアプリケーションを締め出しています。私たちは、人間にとってのみ有用なものを軽くするとしても、AIモデルにとって重要なものに優れたブラウザをすべてのエージェントに提供すべきです。例えば: AIはタブ、テーマ、ブラウザ拡張機能、またはデバイス間の同期を気にしません。AIはトークン数、コンテキストウィンドウ、スケーラビリティ、パフォーマンス、コストを気にします。 構造化された機械可読コンテンツは重要ですが、視覚的な完璧さやスムーズな60fpsスクロールはそうではありません。CSSの解析が少しずれていたり、レンダリングがピクセルパーフェクトでなくても、エージェントは問題なく動作します。 ブラウザを使用するAIの文脈における脅威モデルは異なります。プロンプトインジェクションやツールの安全性のような新しい問題が最優先事項です。 これらの認識に直面し、12週間前、私たちは再び問いを投げかけました。「独自のブラウザを構築すべきか?」この時、答えは満場一致で「はい!」でした。 本日、私たちはKitesurfを発表します。これは、私たちがエージェントのために特別に構築した、Workersの上に完全に構築された新しいブラウザで、Browser Runでベータ版として無料で利用できます。 Kitesurfは、スクリーンショットやHTML抽出のような一般的なエージェントタスクにおいて、ChromiumよりもCPUとメモリ消費量が大幅に効率的です。以下は、それを構築した経緯です。しっかり準備してください、技術的になりますが、面白く保つことをお約束します。 始まり Kitesurfは、Cloudflareで多くの素晴らしいアイデアが始まったのと同じように始まりました。誰かが興味深いものを見つけ、次の瞬間には、彼らはチームの残りを、一見不可能だが非常に魅力的なアイデアで「オタクを悩ませる」ことになったのです。 最初のインスピレーションは、AIオートメーションのためのRustで書かれたヘッドレスエンジンであるobscuraから得ました。「Chromeなし、Node.jsなし、依存関係なし」という特徴がありました。 その後、AIエージェントの助けを借りて、それをWorkersに移植しようとしました。最初はあまりうまくいきませんでした。しかし、AIにしっかりとした計画と成功の明確な定義を与えたところ — エージェントが無限にループし、必要に応じて質問できるように十分詳細 — うまくいきました。 この(かろうじて)動作するプルーフオブコンセプトに衝撃を受け、私たちはチームに任せることにしました。 設計上の決定 作業を開始する前に、私たちが下した設計上の決定をいくつか紹介します。 テスト、テスト、テスト プロトタイプから、本番環境で大規模なタスクに実際に役立つフル機能のブラウザへの移行には、多くの作業とイテレーションが必要であることを私たちは知っていました。AIを使用してプロセスを加速することが鍵であったことを隠すつもりはありません。しかし、このような複雑なプロジェクトでAIをどのように使用し、速度を失うことなくコードと結果の両方の品質を管理できるでしょうか?答えは、できるだけ多くのテストを提供することです。 Web Platform Tests(WPT)が登場しました。これは理想的なセットアップです。機能適合性を評価するための明確な目標をAIエージェントに与える、広範な成功基準のスイートです。エージェントに割り当てる機能の選択と順序をキュレーションし、人間がアーキテクチャ作業とエージェントのアプローチのレビューに集中できるようにしました。 しかし、WPTテストは限界があります。それらはW3C標準への適合性を測定しますが、ブラウザが実際のウェブサイトをレンダリングおよび操作する能力を測定するわけではありません。このギャップを埋めるために、統合テストと視覚回帰テストの組み合わせを実装しました。これは、ChromiumとKitesurfの両方に対して、実際のウェブサイト上でマルチステップのPuppeteerテストを実行し、アサーションの比較だけでなく、各ステップでのレンダリング出力を比較して、望ましくない違いを強調します。 可能な限りRustを使用する Cloudflareは、WorkersでWebAssembly(Wasm)の優れたサポートを提供するために、かなりの時間を費やしてきました。これは、高性能なC、C++、Rustパッケージを使用してWasmにコンパイルできるため、非常に便利です。Emscripten(例えば)とその多くのモック依存関係レイヤーを使用すると、コンパイルされたバイナリが大きくなり、遅くなる可能性があります。 代わりに、可能な限りネイティブRustを選択し、wasm-bindgenを使用して直接WebAssemblyにコンパイルすることを選択しました。これにより、不要なエミュレーションレイヤーを回避し、可能な限りメタルに近い状態で、信頼性高く実行できます。 例外処理 ブラウザは、信頼性が低く、時には敵対的なWeb全体を、保持しているページをドロップすることなくレンダリングする必要があります。そのため、例外処理は単なる衛生管理以上のものです。それは、アプリケーションがクラッシュするだけでなく、不正な入力からどのように生き残るかです。 そのため、私たちは最初に1つのルールを定めました。あらゆる失敗は、空白のフレームまたは欠落した要素に低下し、決してデッドセッションにはしないということです。あらゆる境界で障害を捕捉し、安全で空のデフォルトを選択し、診断に必要なだけのログを記録します。 分離 ラップトップでブラウザを実行する場合(信頼できるサイトを訪問しており、それらの間で一部のリソースを共有しても許容される)、エージェントはタスクが要求するものを指します。つまり、任意のソースからの任意のコードです。 そのため、私たちはこのブラウザを、すべてのページロードが信頼されていない入力であり、すべてのセッションが新しく開始されるという仮定に基づいて構築しました。各コンポーネントは分離されており、その機能に厳密に必要なリソースにのみアクセスできます。 これは、セキュリティモデルが設計によって分離を中心に構築されているCloudflare Workersに最適です。しかし、プラットフォームはアイソレート間の境界を提供するだけです。私たちはアプリケーションレベルでも同じ原則を強制し、各コンポーネントが何にアクセスできるかを決定し、ページ間で漏洩しないようにする必要があります。 可能な限りステートレスに ステートは失敗を高価にするものです。再構築するものがなければ、クラッシュからの回復は新しいセッションを開始してリクエストをリプレイするだけです。ステートレスコンポーネントは本質的に使い捨て可能で並列です。遅延したらすぐに破棄し、一度に数千を実行し、物を温めておくのではなく需要に合わせてサイズ調整します。これはオートメーションに完全に適合します。ロードはバーストで到着し、最も安いことは、使用した分だけコストがかかり、完了したら消える作業をスピンアップすることです。要するに、コンポーネントがステートレスになれる場所はどこでもそうすべきです。 構築方法 良い計画、広範なテスト、そして優れたツール環境を備え、初期のプルーフオブコンセプトを超えて開始する準備ができました。これは、今日でも有効な、リクエストのKitesurfの非常に高レベルなライフサイクルです。 Kitesurfを機能させる3つの主要コンポーネントに飛び込みましょう:エンジン、