WP-AI-Post-Abilities-Dev

ブログ

  • Firefoxの2023年高速化は、ベンチマークではなく実ユーザー指標で語られている

    Firefoxの2023年高速化は、ベンチマークではなく実ユーザー指標で語られている

    Mozilla Hacksの「Down and to the Right: Firefox Got Faster for Real Users in 2023」を読みました。この記事は、Firefoxの性能改善をベンチマークの点数だけではなく、実際のユーザー環境から集計した匿名のタイミング指標で見ようとしている点が特徴です。

    記事の要点

    記事では、FirefoxがSpeedometer 3の取り組みを通じて性能改善を進めてきた一方で、本当に大事なのはその改善が実ユーザーの体験に届いているかだと説明しています。Firefoxはページ読み込み、応答性、起動などに関する匿名化されたタイミング指標を集めていますが、プライバシーを守りながら集計するため、特定サイトごとの細かな分析には限界もあります。

    まず取り上げられているのがFirst Contentful Paintです。MDNによると、FCPはブラウザがDOM由来の最初のコンテンツを描画し、ページが読み込まれていることをユーザーへ示すタイミングです。記事では、response startからFCPまでの中央値が2023年初めの約250msから10月には約215msへ改善し、ページ読み込みのフィードバックが約15%早くなったと説明されています。

    次に、ページ読み込み中のJavaScript実行時間です。95パーセンタイルで見ると、年初の約1560msから10月には約1260msへ下がり、約300ms、ほぼ20%の改善が見られています。記事では、Speedometer 3に関連する作業がSpiderMonkey JavaScriptエンジンの最適化につながったことが、この改善の大きな要因だと示唆されています。

    さらに、読み込み後の応答性としてkeypress present latencyも紹介されています。これはキー入力から結果が画面に表示されるまでの時間です。95パーセンタイルでは、年の大半で約65msだったものが、Firefox 116と117のリリース後に59ms未満へ下がったとされています。

    気づき

    この記事の気づきは、性能改善の成果を「速くなったはず」では終わらせず、ユーザーが感じるタイミングまで戻して見ていることです。ベンチマークは改善の方向を決める道具として強力ですが、最終的にはFCPや入力応答のような体感に近い指標で確認しないと、仕事の価値が見えにくい。プライバシーを守りながら集計値で判断する制約込みで、実ユーザー指標へ接続しているところが実践的だと感じました。

    参照した記事

  • FirefoxのVue.js高速化は、実利用ベンチマークがJIT最適化を導いた例だ

    FirefoxのVue.js高速化は、実利用ベンチマークがJIT最適化を導いた例だ

    Mozilla Hacksの「Faster Vue.js Execution in Firefox」を読みました。この記事は、FirefoxでVue.jsの実行速度が改善された背景を、Speedometer 3とJavaScriptのProxy最適化という観点から紹介しています。

    記事の要点

    Speedometer 3は、実際のユーザー体験に近い形でブラウザ性能を測るための横断的なベンチマークです。その更新作業の中で、Vue.jsのテストがVue 2からVue 3へ変わったとき、Firefoxで性能課題が見つかりました。原因の中心にあったのが、Vue 3のリアクティビティで使われるJavaScriptのProxyです。

    Proxyは、オブジェクトのプロパティ読み書きなどを横取りして振る舞いを変えられる強力な仕組みです。MDNの解説にもあるように、getやsetなどの操作をhandlerで定義できます。一方で、Proxyは設計上とても汎用的で、JITコンパイラにとっては最適化しづらい対象でもあります。

    Vue公式のリアクティビティ解説では、Vue 3がreactive objectにProxyを使い、プロパティの読み取りで依存関係を追跡し、書き込みで更新を通知する仕組みが示されています。つまり、Vueアプリの重要な実行経路にProxyが入っています。Mozillaはこの利用実態を受けて、特定のcall-siteで出会うProxyの形に合わせ、JIT内で実行できるように最適化しました。この変更はFirefox 118に入り、記事ではVue.jsベンチマークが年間で約40%改善したと説明されています。

    気づき

    面白いのは、最適化の出発点が「仕様としてProxyがある」ことではなく、「Vue 3という実アプリの重要経路でProxyが使われている」ことだった点です。汎用機能を全部速くするのは難しくても、現実の使われ方をベンチマークで捉えれば、安全に特殊化できる範囲が見えてきます。ブラウザ性能改善は、エンジン内部の技術だけでなく、フレームワークの進化をどう観測するかにも左右されるのだと感じました。

    参照した記事

  • Gradio UI for Figmaは、AIプロトタイピングの設計段階も短くする

    Gradio UI for Figmaは、AIプロトタイピングの設計段階も短くする

    Mozilla Hacksの「Prototype even faster with the Gradio UI for Figma component library」を読みました。生成AIの探索では、アイデアを素早く形にして試すことが重要です。記事では、Hugging Faceの低コードプロトタイピングツールであるGradioを使って実験や体験を作ってきた一方で、デザイン段階にはまだ従来どおりの手間が残っていた、と説明されています。

    記事の要点

    Mozillaのチームは、GradioベースのFigmaコンポーネントライブラリを公開しました。これはGradio 4.23.0をもとにしたデザイン部品群で、Mozilla Innovation ProjectsのFigmaプロフィールから利用できます。開発者がGradioで素早くプロトタイプを作れるなら、デザイナーも同じ前提の部品でワイヤーフレームを素早く作れるようにしよう、という狙いです。

    ライブラリには、タイポグラフィ、アイコン、ボタン、チェックボックス、ラジオ、スライダー、タブ、アコーディオン、エラーメッセージ、メディアプレイヤー操作部などが含まれます。大きめの部品としては、ラベル付きテキストボックス、動画プレイヤー、カウンター、ナビゲーションなども用意されています。

    参照先のGradio公式サイトも確認すると、GradioはPythonで機械学習アプリのWebインターフェースを短時間で作るためのツールとして位置づけられています。画像、音声、動画、チャット、プロット、データフレームなど幅広い部品を扱えるため、Figma側に対応する部品を用意する意味も分かります。

    気づき

    この記事の気づきは、プロトタイピング速度は実装ツールだけでは決まらないという点です。開発者だけが速くなっても、デザインの部品名、見た目、振る舞いの共有が遅ければ、検証全体の速度は上がりません。Gradio UI for Figmaは、AIプロトタイプの「作る速さ」を、設計、合意、実装の共通言語にまで広げる取り組みとして読めました。

    参照した記事

  • 0DINは、生成AIの脆弱性を“報告できる形”に分類する試みだ

    0DINは、生成AIの脆弱性を“報告できる形”に分類する試みだ

    Mozilla Hacksの「0Din: A GenAI Bug Bounty Program – Securing Tomorrow’s AI Together」を読みました。0DINは、生成AIシステムに特化したバグバウンティプログラムです。AIの安全性を抽象的な倫理論だけで扱うのではなく、研究者が脆弱性を見つけ、報告し、検証され、報奨を受ける流れに落とし込もうとしています。

    記事の要点

    記事では、0DINが生成AIの脆弱性を探すためのプログラムであり、セキュリティ研究者、開発者、AIセキュリティに関心のある技術者が参加できると説明されています。参加者は対象範囲内で問題を見つけ、詳細なレポートを提出し、0DIN側のレビューを経て、影響度に応じた報奨を受けます。

    扱う脆弱性の例としては、ガードレールの回避、プロンプトインジェクション、学習データ漏えいなどが挙げられています。参照先のポリシーページでは、報奨の目安が低・中・高・重大の段階で示され、対象は主要な商用・オープンソースの生成AIモデルに及びます。ただし、対象はモデル自体の問題であり、周辺ソフトウェアの一般的な脆弱性とは区別されています。

    報奨マッピングの表も確認しました。そこでは、Prompt Extraction、Training Source Leakage、Prompt Injection、Interpreter Jailbreak、Weights Disclosureなどの境界違反がモデルごとに分類され、深刻度の目安が付けられています。生成AIの弱点を「危ないかどうか」だけでなく、どの境界が破られたのかとして整理しようとしている点が特徴的です。

    気づき

    この取り組みで重要なのは、生成AIのリスクを発見するだけでなく、報告しやすい分類にしていることだと思いました。プロンプトインジェクションやデータ漏えいは言葉として広がっていますが、実際に報奨制度へ載せるには、対象、再現性、影響度、開示の流れをそろえる必要があります。0DINは、AIセキュリティを研究テーマから運用可能な脆弱性管理へ近づけるためのインフラとして読めました。

    参照した記事

  • Llamafile v0.8.14は、ローカルAIを“起動してすぐ使える道具”へ近づける

    Llamafile v0.8.14は、ローカルAIを“起動してすぐ使える道具”へ近づける

    Mozilla Hacksの「Llamafile v0.8.14: a new UI, performance gains, and more」を読みました。Llamafileは、LLMのモデル重みを多くの環境で動く単一実行ファイルとして扱えるようにする、Mozilla Builders系のオープンソースAIツールです。

    記事の要点

    v0.8.14の目立つ変更は、新しいコマンドラインのチャットUIです。Llamafileを起動するとターミナル上でそのまま対話でき、従来のWebベースUIよりも軽く、手早く使える導線になっています。Web UIも残っており、ローカルの8080番ポートから利用できます。

    もう一つ重要なのが、OpenAI互換APIサーバーとして作られているLlamafilerです。記事では、embeddings endpointがすでに出荷され、従来のllama.cpp由来の実装より高速だと説明されています。将来的にはcompletions endpointも整い、Llamafileの標準APIサーバーになる流れです。

    性能面でも大きな更新があります。記事では、prompt evaluationの速度がIntel Core i9で4倍、AMD Threadripperで8倍、Raspberry Pi 5で10倍に伸びた例が紹介されています。さらにLlama 3.2、Llama 3.1 405B、OLMo、TriLMなどのモデル配布や、音声認識向けのWhisperfileにも触れられており、ローカルAIの対象がチャットだけに閉じていないことが見えてきます。

    気づき

    この記事で面白いのは、ローカルAIの実用化が「強いモデルを用意する」だけでは進まないと分かる点です。単一ファイルで配れること、起動後すぐ対話できること、OpenAI互換APIで既存アプリから使えること、CPUやRaspberry Piでも速度が上がること。こうした地味な使い勝手の積み上げが、クラウド前提だったAI体験を手元の道具へ近づけているように感じました。

    参照した記事

  • FirefoxのIPCファジングは、ブラウザ全体を巻き戻す発想で実用段階へ

    FirefoxのIPCファジングは、ブラウザ全体を巻き戻す発想で実用段階へ

    Mozilla Hacksの「Snapshots for IPC Fuzzing」を読みました。Firefoxのセキュリティモデルでは、Webコンテンツを扱う低権限プロセスと、より権限の強い親プロセスを分けています。そのため攻撃者がサンドボックスを越えるには、プロセス間通信、つまりIPCの境界を狙う必要があります。

    記事の要点

    この記事の中心は、FirefoxのIPCインターフェースをどう効率よくファジングするかです。IPCはブラウザの実行状態と強く結びついているため、単体の関数のように切り出して試すのが難しく、失敗時にはブラウザ全体の再起動が必要になりがちです。これではcoverage-guided fuzzingに必要な反復速度と再現性が落ちてしまいます。

    そこでMozillaは、Nyxを使ったsnapshot fuzzingを導入しています。ファジングを始められる状態でシステムをスナップショット化し、各試行のあとにその状態へほぼ即座に戻す、という考え方です。記事によると、2024年時点でFirefoxのIPC向けsnapshot fuzzing targetは本番運用されており、すでにIPC層の潜在的な問題の発見と修正につながっています。

    あわせて参照した技術解説では、FirefoxをLinuxゲスト上で動かし、NyxとAFL++、Firefox側のカスタムagentを組み合わせていることが説明されています。単一のIPCメッセージを差し替えて試すtargetや、スナップショット環境でもcoverageを測れるようにする工夫も紹介されていました。

    気づき

    印象的だったのは、「テスト対象を小さく分離できないなら、環境ごと巻き戻せるようにする」という実用的な発想です。セキュリティテストというと検出ロジックの賢さに目が行きがちですが、この話では反復速度、再現性、失敗後の復帰コストを下げることが成果に直結しています。大きなソフトウェアの品質改善では、テストを書く前に「何度でも安く試せる状態」を作ること自体が重要な設計なのだと感じました。

    参照した記事

  • FirefoxクラッシュレポーターのRust移植は、失敗時こそ独立して動く設計の話

    FirefoxクラッシュレポーターのRust移植は、失敗時こそ独立して動く設計の話

    Mozilla Hacksの「Porting a cross-platform GUI application to Rust」は、FirefoxのクラッシュレポーターをRustで書き直した取り組みを解説する記事です。公開日は2024年4月23日。目立つ新機能ではありませんが、Firefoxの信頼性を支える重要な部品の話です。

    クラッシュレポーターは、多くのユーザーが頻繁に目にするものではありません。ただし、Firefoxのメインプロセスが落ちたとき、クラッシュ情報を集め、ユーザーに送信可否を確認するためには、ブラウザ本体とは別に動く小さなアプリケーションが必要になります。

    なぜRustで作り直したのか

    記事によると、従来のクラッシュレポーターはWindows、Linux、macOSで別々のGUI実装を持ち、C++やObjective-Cの接着コード、古いApple開発ツール由来のバイナリ、テスト不足などを抱えていました。動いてはいるものの、改善しづらい「十分だが触りにくい」状態だったわけです。

    そこでMozillaは、保守性と信頼性を高めるためにRustでの再実装を選びました。Rustのメモリ安全性だけでなく、型システム、標準ライブラリ、エラー処理のしやすさが、クラッシュ時に確実に動く小さなアプリケーションに向いていると判断されています。

    クラッシュレポーターは特殊なGUIアプリ

    このアプリの難しさは、Firefox本体の機能に頼りすぎられないことです。Firefox本体が壊れて落ちている可能性があるため、クラッシュレポーターまで同じコードに依存してしまうと、肝心な場面で一緒に失敗するリスクがあります。

    一方で、ユーザーとやり取りするためにはGUIが必要です。記事では、既存の巨大なクロスプラットフォームGUIライブラリを採用するのではなく、クラッシュレポーターに必要な最小限のUIモデルを定義し、WindowsではWin32、macOSではCocoa/AppKit、LinuxではGTKへ変換する構成が説明されています。

    小さなUIモデルとテスト用UI

    興味深いのは、GUIフレームワークを作ること自体を目的にしていない点です。クラッシュレポーターに必要な要素は限られているため、Window、Label、Button、TextBox、Checkbox、Progress、Scroll、HBox、VBoxのような最小限のモデルを用意し、それぞれのOS実装へ落とし込んでいます。

    さらに、実際のGUIを出さずにモデルを操作できるテスト用UIも用意されています。これにより、ボタン押下、入力、状態変化、ファイルシステムや外部コマンドなどの副作用をテストしやすくしています。古い実装で弱かったテスト面を、再設計の中心に置いているのが分かります。

    参照リンクから見えた背景

    記事内で参照されているFirefoxの安定性改善記事では、Windowsのメモリ確保失敗時に即クラッシュせず少し待って再試行することで、クラッシュを大きく減らした取り組みが紹介されています。クラッシュレポーターの改善は、こうした安定性改善の次の段階として読むことができます。

    Project Fluentは、Firefoxの他の部分と同じローカライズ基盤へクラッシュレポーターを寄せる文脈で登場します。クラッシュ時に出る画面だからこそ、普段のFirefoxと同じ翻訳・ローカライズ運用へ合わせる意味があります。

    また、Linux実装ではbindgenでGTKのRustバインディングを生成し、Windows実装ではwindows-sysを使っています。ネイティブ感とアクセシビリティを保つために、各OSのGUI APIへかなり直接に向き合っている点も特徴です。

    気づき

    この記事で一番印象的なのは、クラッシュレポーターのような「異常時にだけ出る小さな部品」ほど、設計上の独立性とテスト容易性が重要になるという点です。通常時に使う便利な抽象や大きな依存は、クラッシュ時には逆にリスクになります。

    Rust移植の目的も、単に「Rustにしたから安全」という話ではありません。依存を絞り、UIモデルを小さく保ち、ロジックとUIスレッドの責務を分け、テスト用UIとモックで副作用を検証できるようにする。失敗時に動くソフトウェアは、成功時の使いやすさとは別の基準で設計しなければならないのだと感じました。

    読んでおきたい人

    • Rustで既存C++/Objective-C系ツールを置き換えたい人
    • 小さなクロスプラットフォームGUIを保守している人
    • クラッシュレポートや診断ツールを設計している人
    • テストしにくいGUIアプリをどう分解するか知りたい人

    参照記事

  • sqlite-vecはLocal AIに“自分のデータを手元で検索する”土台を足す

    sqlite-vecはLocal AIに“自分のデータを手元で検索する”土台を足す

    Mozilla Hacksの「Sponsoring sqlite-vec to enable more powerful Local AI applications」は、Mozilla Buildersがsqlite-vecを支援することを紹介した記事です。公開日は2024年6月25日。テーマは、ローカルAIアプリケーションに必要なベクトル検索を、広く使われているSQLiteへ持ち込むことです。

    Mozilla Buildersの初回テーマはLocal AIです。記事では、AIモデルやアプリケーションをデスクトップ、ノートPC、スマートフォンなどの端末上で動かすことにより、プライバシーとユーザーの制御を高められると説明されています。sqlite-vecは、そのLocal AIに「手元のデータを意味で検索する」能力を足す部品として位置づけられています。

    sqlite-vecとは何か

    sqlite-vecは、SQLiteにベクトル検索機能を追加する拡張です。GitHubリポジトリでは、float、int8、binary vectorを仮想テーブルに保存し、SQLで近傍検索できる小さな拡張として説明されています。Cで書かれており、依存が少なく、SQLiteが動く場所で動くことを重視しています。

    記事が強調しているのは、SQLiteの普及性です。SQLiteは組み込みデータベースとして非常に広く使われており、Firefoxにも組み込まれています。そこにベクトル検索が加わると、ローカルで動くAIアプリが、ユーザーの手元にある文書や履歴、メモなどを外部に送らずに検索しやすくなります。

    Local AIとRAGの接点

    ベクトルデータベースは、RAGやセマンティック検索の基盤として使われます。大きなモデルを毎回クラウドに呼び出すのではなく、手元のデータから関連情報を検索し、その文脈を使って小さなモデルを補助する。これはLocal AIを実用に近づけるうえで重要な構成です。

    Mozilla Buildersの発表記事でも、Local AIの文脈でRAGは重要な領域として挙げられていました。小さめのモデルでも、必要な情報を手元のデータから取り出せれば、クラウド前提ではないAIアプリケーションを作りやすくなります。

    参照リンクから見えた背景

    sqlite-vecのGitHubリポジトリを見ると、sqlite-vssの後継として作られていることが分かります。旧プロジェクトであるsqlite-vssはFaissベースのベクトル検索拡張でしたが、現在は開発の重点がsqlite-vecへ移っています。

    開発者Alex Garcia氏のブログ記事では、sqlite-vecを純Cで、依存なしに、WASMやモバイル、Raspberry Piでも動くようにしたいという方向性が説明されています。これは「高性能な専用DBを用意する」よりも、「既にアプリの中にあるSQLiteへ意味検索を足す」発想に近いです。

    また、llamafileもMozilla Buildersのプロジェクトとして紹介されています。llamafileがローカルでLLMを動かしやすくする側の取り組みだとすると、sqlite-vecはローカルにあるデータをLLMから使いやすくする側の取り組みだと見ることができます。

    気づき

    この記事で面白いのは、Local AIを「モデルを端末で動かす」だけの話にしていない点です。実際のアプリケーションでは、モデルそのものだけでなく、ユーザーのデータをどう保存し、どう検索し、どう文脈として渡すかが重要になります。

    sqlite-vecは、その地味だが重要な部分を担います。すでに多くのアプリに入っているSQLiteにベクトル検索が加われば、AI機能のために新しいサーバーや専用DBを立てなくても、ローカルファーストなRAGやセマンティック検索を試しやすくなります。Local AIの実用化は、モデルの軽量化だけでなく、こうした足元のデータ基盤で決まるのだと感じました。

    読んでおきたい人

    • ローカルAIやオンデバイスAIのアプリを作りたい人
    • SQLiteを使ったアプリにセマンティック検索を入れたい人
    • RAGをクラウド依存にせず実装したい人
    • AI機能とプライバシーを両立したい開発者

    参照記事

  • Firefox Nightlyのローカルalt text生成は、AIをアクセシビリティへ寄せる実験だ

    Firefox Nightlyのローカルalt text生成は、AIをアクセシビリティへ寄せる実験だ

    Mozilla Hacksの「Experimenting with local alt text generation in Firefox Nightly」は、Firefox Nightlyで試されたローカルalt text生成機能を紹介する記事です。公開日は2024年5月31日。記事公開時点ではFirefox 130で、PDFエディター内の画像に対して自動で代替テキストを生成する実験として説明されています。

    ポイントは、画像を外部サーバーへ送らず、端末上の小型AIモデルで説明文を生成することです。最終的な目標としては、PDF編集に限らず、スクリーンリーダーを使うユーザーがWeb上の画像を理解しやすくする用途も視野に入っています。

    なぜalt textなのか

    Webは、同じコンテンツをユーザーの状況に応じて異なる形で扱えるところに強みがあります。画像のalt textはその代表例で、スクリーンリーダーなどの支援技術にとって重要な情報になります。

    ただ、現実には多くの画像に適切な代替テキストが付いていません。記事では、Web Almanac 2022でかなり多くの画像がalt textを欠いていたことにも触れています。そこでFirefoxは、画像の内容をローカルで推定し、ユーザーが確認・編集できる初稿を出す方向を試しています。

    小型モデルを使う理由

    記事では、Vision TransformerとDistilGPT-2を組み合わせた182Mパラメータ級のモデルが紹介されています。GPT-4oのような大規模モデルほど詳細な説明はできませんが、alt textには必ずしも長い説明が必要なわけではありません。短く要点を押さえた初稿を出し、人間が文脈に合わせて調整できることが重要です。

    小型モデルを端末上で動かす利点として、Mozillaはプライバシー、リソース効率、透明性、CO2排出の把握、モデル改善のしやすさを挙げています。画像やPDFの内容、生成された説明文がMozillaへ送られない設計は、この機能の性格を大きく決めています。

    既存のFirefox機能を活かした実装

    実装面では、Firefox Translationsで使われてきたローカル推論の考え方を拡張しています。翻訳機能では、モデルとWASMランタイムをダウンロードし、その後はオフラインで翻訳できます。alt text生成でも、ONNX RuntimeとTransformers.jsをFirefox Nightlyへ組み込み、モデルをローカルにキャッシュして使う構成です。

    Firefox AI Runtimeのドキュメントでも、このコンポーネントはTransformers.jsとONNX Runtimeをベースにした実験的なローカル推論ランタイムとして説明されています。単発のデモではなく、ブラウザ内で複数の推論タスクを扱うための足場を作っている点が見えます。

    参照リンクから見えた背景

    MDNのaltプロパティ解説を見ると、altは単なるSEO用テキストではなく、画像が利用できない場合や支援技術で画像を伝えるための基本属性です。Mozilla Hacksの記事は、この基本的なWebの仕組みにAIをどう補助的に差し込むかという話でもあります。

    ONNX RuntimeとTransformers.jsは、ブラウザ内推論の実装基盤として重要です。さらに、mozilla/distilvitやmozilla/checkviteが公開されており、モデルやデータセット改善の流れを外から追えるようになっています。

    気づき

    この取り組みで印象的なのは、AIを「何でも答える大きな機能」としてではなく、ユーザーが困っている具体的な欠落を埋める補助機能として使っている点です。alt text生成は、完璧な説明文を自動で作ることが目的ではありません。画像に何も説明がない状態を減らし、人間が確認・修正できる出発点を作ることが目的です。

    また、ローカル推論にこだわっている点も重要です。アクセシビリティのために画像やPDFをクラウドへ送る設計だと、便利さとプライバシーが交換条件になってしまいます。Firefoxの実験は、その交換条件を小型モデルとブラウザ内推論で回避しようとしているように見えます。

    読んでおきたい人

    • WebアクセシビリティとAIの接点に関心がある人
    • オンデバイスAIやブラウザ内推論の実装例を知りたい人
    • PDFや画像編集機能にアクセシビリティ支援を入れたい開発者
    • AI機能をプライバシー重視で設計したい人

    参照記事

  • PuppeteerのFirefox公式対応は、テスト自動化をブラウザ横断へ戻す一歩

    PuppeteerのFirefox公式対応は、テスト自動化をブラウザ横断へ戻す一歩

    Mozilla Hacksの「Announcing Official Puppeteer Support for Firefox」は、Puppeteerがバージョン23からFirefoxを公式にサポートしたことを紹介する記事です。公開日は2024年8月7日。ブラウザ自動化やE2Eテストを書いている開発者にとって、かなり実務的な意味を持つアップデートです。

    これまでPuppeteerはChrome/Chromiumの自動化で広く使われてきました。記事では、起動時に browser: "firefox" を指定するだけでFirefoxを対象にでき、Chromeと同じような開発者体験でテストを実行できるようになったと説明されています。

    ポイントはWebDriver BiDi

    今回のFirefox対応は、Firefox専用の独自プロトコルをPuppeteerに足した話ではありません。土台になっているのは、W3Cで標準化が進むWebDriver BiDiです。記事では、GeckoとChromiumの両方に実装があるクロスブラウザのプロトコルとして紹介されています。

    WebDriver BiDiによって、コンソールログの取得、デバイスエミュレーション、ネットワークインターセプト、ページ読み込み前に動くpreload scriptなど、従来はブラウザ固有のDevToolsプロトコルに寄りがちだった機能を、標準化された形で扱いやすくなります。

    従来の自動化が抱えていた二択

    記事の技術背景では、従来の選択肢としてW3C WebDriverとブラウザ固有のDevTools系プロトコルが整理されています。WebDriverは横断性がある一方で、HTTPベースのコマンド/レスポンスモデルなので、ログやネットワークイベントのようなリアルタイム性のある処理は扱いにくい面がありました。

    一方、Chrome DevTools Protocolのようなブラウザ固有プロトコルは機能が豊富ですが、ブラウザ内部に強く結びつきます。そのため、ツール側はブラウザごとの実装差やバージョン差を追いかける必要があり、クロスブラウザ対応の負担が大きくなります。

    参照リンクから見えた流れ

    Puppeteer公式ドキュメントでは、PuppeteerはChromeまたはFirefoxをDevTools ProtocolまたはWebDriver BiDi経由で制御する高水準APIとして説明されています。つまり、Firefox対応は一時的な実験ではなく、Puppeteerの通常の利用モデルの中に入ってきています。

    また、Chrome Developers側の記事でも、Firefox、Chrome、PuppeteerでWebDriver BiDiがproduction-readyになった流れとして扱われています。MozillaだけでなくChrome側の記事でも同じ方向性が説明されている点は重要です。

    Mozilla Hacksの過去記事であるクロスブラウザテストの記事Part 1とPart 2を読むと、WebDriverの横断性とCDP系ツールの機能性の間で、開発者が長く揺れていたことが分かります。今回の記事は、その流れの続きとして読むとかなり納得しやすくなります。

    さらに、Firefox Developer Experienceの記事では、Firefoxの実験的CDPサポートを廃止し、WebDriver BiDiへ移行する方針が説明されています。独自互換を追いかけるのではなく、標準化された双方向プロトコルへ寄せる判断です。

    気づき

    この発表の面白さは、単に「PuppeteerでFirefoxも動くようになった」ことではなく、「高機能な自動化」と「ブラウザ横断性」を両立させる道筋が見えてきたことにあります。これまでのテスト自動化は、標準のWebDriverを使えば横断性はあるが機能が足りず、CDPを使えば便利だがブラウザ依存が強い、という二択になりがちでした。

    WebDriver BiDiは、その二択を崩すための共通レイヤーです。ツール作者はブラウザごとの独自プロトコルを追い続ける負担を減らせますし、アプリ開発者は同じテストコードを複数ブラウザで動かしやすくなります。Web互換性を高める仕事は、ブラウザ機能そのものだけでなく、テストツールの標準化にも現れるのだと感じました。

    読んでおきたい人

    • PuppeteerでE2Eテストやスクレイピング補助をしている人
    • ChromeだけでなくFirefoxでも自動テストを回したい人
    • WebDriver、CDP、WebDriver BiDiの違いを整理したい人
    • ブラウザ横断テストの運用負荷を下げたい開発チーム

    参照記事