Firefox 開発元、Google のブラウザ内 Prompt API 導入を批判

Mozilla は、AI の配管機能を Chrome ブラウザに組み込むという Google の決定に対する反対意見を再確認したが、Prompt API と呼ばれるこの技術がすでに Chrome や Microsoft Edge でテストされていることを考えると、やや遅れてのこととなった。Mozilla のウェブ開発者関係責任者である Jake Archibald 氏は、ローカルの機械学習モデルからプロンプトとレスポンスを送受信するための標準的な方法を提供するこの API に関する GitHub の議論で、同組織の懸念を明確に述べた。「私たちは引き続きこの API に反対しており、ウェブプラットフォームの相互運用性、更新可能性、そして中立性に深刻な悪影響を及ぼすものだと考えている」と Archibald は語った。Google が説明するところによると、Prompt API は「ウェブページがブラウザ提供型言語モデルに直接プロンプトを送信できる能力を与える」ものである。これは、Chrome を通じてローカル推論のためにダウンロード可能なほど小型の Google の Gemini Nano モデルに対して自然言語の指示を送る方法を提供する。そのサイズは決して小さくはない – Google は 22 GB の空き容量を推奨しているが、デスクトップ用の Nano (v3Nano) モデルは約 4.27 GB である。 ウェブ開発者はすでに AI モデルと対話するためのさまざまな手段を持っている。ホストされたモデルとの通信にはクラウドサービス API を使用できるし、JavaScript ランタイムフレームワーク、WASM（WebAssembly）、または WebGPU などの技術を通じてローカルモデルにアクセスすることも可能だ。OpenAI や Perplexity といった様々なベンダーは、リモートホスト型の AI モデルへのアクセスを埋め込んだブラウザを提供している。Mozilla 自体も Firefox で AI ベースのスマートウィンドウ（Smart Window）をテストしており、AI モデルの基盤構築のためのツールを開発中だ。 Prompt API の目的は、ブラウザのセキュリティメカニズムを活用した形でローカル推論を容易にし、より高速なレスポンス時間を生み出し、オフラインでの利用を可能にし、さらに AI サービスの統合においてコスト効果の高い方法を提供することにある（例えば、ユーザーが有料の AI API キーを持たない場合に無料の AI フォールバックを提供するなど）。Archibald が表明した Mozilla の懸念は、この Prompt API がウェブに何を意味するかという点、そして Google の展開に対する正当化についてである。まず彼は、Google 自身の Nano モデルがデフォルトとなり、AI モデルの非確定的なレスポンスをより予測可能にするために開発者がそれに対して標準化する恐れがあると懸念している。その傾向は、共通のユーザー体験のために Apple や Mozilla が Nano のライセンスを取得するよう圧力をかける結果になると彼は主張する。 おそらくより重要なのは、Archibald 氏が指摘するように、Prompt API を使用するには Google の生成 AI 禁止利用ポリシー（Generative AI Prohibited Uses Policy）に同意する必要があり、これは必ずしも違法ではない活動、例えば「不気味な」コンテンツの生成などを禁止している点だ。「これはウェブプラットフォーム上の API として悪い方向であり、[ブラウザ] 固有の使用ルールを持つより多くの API に対する懸念すべき先例を設定するものだ」と彼は語った。最後に Archibald は、Google が一部のソーシャルメディアの投稿を都合よく選び取り、それを開発者の支持の大規模な広がり（groundswell）であるかのように呼ぶことで、この API への需要を誤って表現したと主張している。「blink-dev での出荷意図はウェブ開発者を『強く肯定的』としているが、根拠として解説資料へのリンクを提示している」と彼は書いた。「そこで提供された証拠は、その主張には合致していないように思える」。 メールで Archibald は The Register に対し、問題は Prompt API がウェブにとって良いかどうかであり、Mozilla はそれが良くないと考えていると伝えた。「核心的な問題は相互運用性だ」と彼は言った。「プロンプトはモデルに密結合しており、開発者は必然的に構築対象となるモデルの癖やポリシーに合わせて調整せざるを得なくなる。それこそが、ブラウザ互換性の問題が再び生じる原因となるモデル固有のコードパスを生み出すのだ」。利用規約（T&C）の問題もその一部だ：ウェブ API の使用が特定のベンダーのコンテンツポリシー（特に法律を超えたもの）の受諾を意味する場合、もはやオープンプラットフォームのために構築していることにはならない。 Google による開発者の熱意の誇張について Archibald は、確かに AI 機能に興味を持つ開発者はいるが、Google はその証拠を提供しなかったと述べた。「信号は二極化しており、『強く肯定的』ではない」と彼は説明した。「どちらにせよ、開発者の需要だけでは基準を満たさない。問題は、この API がプラットフォームを一つのベンダーのモデルに縛り付けることなく、実装全体で機能するかどうかだ」。 Google はコメント依頼に対して直ちに回答しなかった。しかし木曜日、Prompt API の出荷を担当した Google Chrome エンジニアである Rick Byers 氏が GitHub の議論に参加し、Archibald が表明した懸念を認めた。「Chromium でこれを導入するための blink API オーナー承認者の一人として、Mozilla の標準化ポジションにおけるこれらの懸念を共有していることを認めたい」と彼は書いた。「私が異なるのは、起こりうる事態への恐怖からイノベーションの停滞を恐れるよりも、実験を促進し、失敗から学び、競争を促す道を選ぶ点だ」と。Byers 氏はウェブコミュニティに対し、議論を進めるために害の証拠を集めるよう協力を求めた。暗号化メディア拡張（Encrypted Media Extensions: EME）など他の論争的なウェブ技術に関する議論に言及し、その結果は予測されたほど悲惨なものではなかったと示唆した。しかし、データに焦点を当てても、これまでのところ Google の主張にはあまり役立っていない。 2 月に作成され、Prompt API を使用して Chrome（Gemini Nano）と Edge（Phi-4 mini-instruct）のパフォーマンスを比較したレポートによると、これらのモデルは非常に良い結果を提供していない。「生成タスク（文章作成、タグ生成など）において、Edge のレスポンスの 24.29% と Chrome のレスポンスの 15.17% がタスクを完了できなかった」とレポートは述べている。これは、5 段階評価で 2 点以下を失敗と定義するルブリック（評価基準）に関するものである。「分類タスクにおいては、Edge のレスポンスの 29.58% と Chrome のレスポンスの 23.93% が入力を正しくラベル付けまたは分類しなかった」。 根拠のある正確さ（groundedness）と精度については、Edge は 17% の場合で失敗（ハルシネーション）し、Chrome は 6% の場合で失敗した。それがウェブにとって良いことだろうか？Chrome に聞いてみることもできるが、信頼できる答えが得られるとは限らない。 2024 年 4 月 30 日 UTC 23:45 に Google スポークスマンのコメントを追加して更新 この記事が提出された後、Google のスポークスマンは The Register に対し以下のコメントを送信した：

Firefox 開発元、Google のブラウザ内 Prompt API 導入を批判

背景や根拠まで確認しますか？

このニュースを、実務の判断につなげる

関連記事

調べる

選ぶ

サイト