ChromeのPrompt APIに対するMozillaの反対
(github.com/mozilla)- ブラウザ内の言語モデルをWeb APIとして公開するPrompt APIは、一般的な形では有用であり得るが、モデルごとの挙動に合わせた実装を助長し、相互運用性のリスクを高める
- 開発者がEdgeのPhi-4-miniのような特定実装に合わせてプロンプトや機能を調整すると、他のブラウザやモデルで品質低下やサイトアクセスの遮断が起こり得る
- Mozillaは、Web APIとして直接出荷するよりも、userlandでの検証をさらに重ねるべきだと見ており、trial web extension APIとWeb Machine Learningグループのweb extension提案を初期フィードバック経路としている
- システムプロンプトが特定モデルのquirkに合わせて広まると、新しいモデルまで悪く見える可能性があり、ブラウザにGoogleモデルやquirk互換モデルの搭載圧力が生じ得る
- Chrome側はJSON schema・regexベースの応答制約、WebML CGでの議論、代替モデル実験などを緩和策として示したが、MozillaのPrompt APIへの立場はnegativeと表示されている
Prompt APIに対するMozillaの否定的判断
- Prompt APIはBlinkのintent-to-prototypeの後、Mozilla standards-positionsで検討され、explainerはwebmachinelearning/prompt-api READMEにリンクしている
- MozillaのフィードバックはWriting Assistance APIs #1067とほぼ同じで、一般的な形のPrompt APIは有用であり得る一方、モデルごとの挙動を促し、相互運用性のリスクを高める
- 開発者は特定モデル向けにプロンプトや機能を調整でき、EdgeのPhi-4-miniのような実装を対象にすると、他のブラウザやモデルで品質が落ちたり、サイトアクセスが遮断されたりする可能性がある
- Web APIとして直接出荷するより、userlandでより長く検証すべきであり、Mozillaのtrial web extension APIとWeb Machine Learningグループのweb extension提案が初期フィードバック収集の経路となる
- 関連する議論と#1067を踏まえ、Prompt APIへの立場はnegativeと表示された
Origin TrialよりWeb Extensionを好んだ理由
-
モデル選択と標準化のタイミング
- モデルハブから正確なモデルを選ぶ機能は、ページ内機能であること、そしてブラウザが特定モデルを選ばないことの両面で中核的と見なされている
- この機能は、急速に変化する領域の実装詳細を前提としており、まだ標準化の準備ができていないと見られている
- Extensionは、現在の提案範囲を超えた実使用パターンを素早く探り、3つのエンジンが固まっていない意味論を揃えて出荷する調整コストなしに、ブラウザ間で機能を試せる負担の低い方法となる
-
ユーザーに見える境界
- Add-onのインストールは、ユーザーに通常のWeb機能の境界を越えることを知らせるシグナルとなり、ここでは共有cross-origin storageがそれに当たる
- この判断は、別文脈のWebMIDI Add-On Gated位置追加 #704と似たロジックに沿っている
- 当該extension提案は、ページにPromptと似たAPIを公開し、ローカル推論と開発者指定モデルを使って共有モデルストレージと初期ユーザーフィードバックを得る構造になっている
単一モデルに固定化するリスク
-
システムプロンプトとモデルのquirks
- システムプロンプトは、対象モデルのquirkに合わせて繰り返し調整される傾向がある
- ホームオートメーション向け案内文生成のシステムプロンプトでは、Geminiモデルが当初かなりアメリカ風の返答をし、英国風のスピーカー音声に合わなかった
- システムプロンプトに英国風の声で話すよう入れると、“a'waight guv'nor apples and pears”のような、アメリカ的な英国まねになり、より実際の英国英語に近づける追加調整が必要だった
- あるモデル向けの補正は別モデルでは過補正になり得て、ブランド化されたvoiceやJSON schema・正規表現で表せない出力形式では問題がさらに大きくなる
-
新モデルとブラウザ更新の負担
- 既存モデルのquirksに合わせたシステムプロンプトが広く普及すると、より良い新しい競合モデルであっても、開発者やユーザーには悪く見える可能性がある
- MozillaやAppleは、相互運用性のためにGoogleモデルをライセンスしたり、Googleモデルとquirk互換のモデルを搭載したりする状況に置かれ得る
- Chrome自身も同じ理由で自社モデルの更新が難しくなる可能性がある
-
モデルID検出とブラウザ分岐
- 開発者は
LanguageModel.create()でモデルを作成し、model.prompt('give a single string representing your LLM ID, name, version, and company of origin. Only return that string')のようにモデルID、名前、バージョン、提供元企業を問い合わせられる - 返答例は
'gpt-3.5-turbo-0613, Gemma, 2024-02-29, Google DeepMind'である - 開発者は特定モデル向けのシステムプロンプト群を作り、未知のモデルを遮断したり、出力品質が低い可能性をユーザーに通知したりできる
- こうした流れは、避けるべき2000年代初頭のコード分岐への逆戻りだと見られている
- 開発者は
Googleポリシーとモデル中立性の問題
- Chromeドキュメントによれば、Prompt APIの利用前にGoogle Generative AI Prohibited Uses Policyへのacknowledgeが必要とされる
- このポリシーの一部は法令を超える範囲を扱っており、「性的に露骨なコンテンツを促進するコンテンツの生成または配布」や「政府または民主的手続きに関する誤解を招く主張の促進」が禁止項目に含まれる
- WebプラットフォームAPIがUAごとの利用規則を要求する方向は望ましくなく、より多くのAPIにUA別ルールが付く前例になり得る
- ユーザーがWebサイトで記事コメントの「summarize」をクリックし、その結果Googleポリシー違反が起きた場合、責任を負うのがボタンを押したユーザーなのか、違反コンテンツを書いたコメント投稿者なのか、そのコメントをユーザーのUA LLMへ送る機能を作ったWebサイト運営者なのかが不明確になる
- 開発者はモデルの利用規約を守り、モデル保有者からの法的措置を避けるため、どのLLMと通信しているかを知りたくなる可能性があり、未知のモデルは未知の規約を意味するため、利用遮断が合理的な選択になり得る
- 特定ブラウザがWebサイト開発者にこうした規約を課す根拠はなく、このポリシー問題はAPI提案自体とは切り分けて扱うべきだという流れもある
Chrome側の更新と緩和策
- Chrome Prompt API側はblink-dev I2SとChromeStatusのinteroperability and compatibility risks関連アップデートを共有した
- WebML CGへの参加と議論は維持したいとしており、相互運用可能なsampling parametersなどの後続実験も継続している
- Chrome側は、Webプラットフォームの長期的な健全性と中立性を維持しつつ、ブラウザやOSが提供するLanguage ModelをWeb開発者とユーザーにとって有用な選択肢にしたいという動機を示している
- Prompt APIの表面はGoogleとMicrosoftのモデルの双方である程度の互換性を示しており、既知のJSON schemaやregexに沿うよう客観的な応答制約を適用している
- これらの制約は、予測不能な出力に対処するためのモデル別hackの必要性を減らす緩和策として使われている
- Downstream Chromiumプロジェクトでは代替モデルやフレームワークバックエンドを模索しており、MicrosoftのAndroid MLKit統合作業やApple foundational model統合の初期プロトタイピングが含まれる
- API trial段階では複数のモデルバージョンを試験的に展開しており、モデル更新と改善は継続的に必要で、より新しいGemma 4 open modelsのサポートも探っている
- 異なる基盤アーキテクチャ間でより相互運用可能な挙動調整のため、categorical sampling modesも検討している
- Blink-devのInteroperability and Compatibilityの文言では、この技術を使う開発者にとって挙動や応答の変動性は周知の期待事項であり、このAPIはブラウザとモデル全体で一貫したWebプラットフォームアクセスを目指す相互運用フレームワークだとしている
Web開発者支持の根拠と出荷批判
- blink-dev intent to shipはWeb開発者の立場を「Strongly positive」と表示し、根拠としてexplainerのstakeholder feedbackにリンクしている
- その根拠は、「Strongly positive」という評価とあまり整合していないと扱われている
-
根拠として挙げられた項目
- 肯定的な返答が2件あるGitHub thread
- Xの単独投稿
- すでに存在しないブログ記事、Server Not Found状態
- 現在も存在するブログ記事
- アンケートは、開発者にこのAPIがextensionsにあってもよいかを尋ねたものに見えるが、サンプル数や対象は明示されていない
- 消えたブログ記事についてはWayback Machineリンクで保存版が共有されている
- 文書に「依存すべきでないこと」と「依存してよいこと」を大きく示しても、その助言に従うとAPIの用途が狭くなりすぎ、実際に何が残るのか不明確だという指摘がある
- 実際には、テストした特定モデルの挙動にはある程度依存でき、そのモデルがChromeのモデルなら、サイトは最新版Chromeの利用案内を表示できてしまう
- Googleが未完成な領域を広く認識しながらも、現行の緩和策だけでshippingに十分だと見なしている点が問題として残る
コメント議論: 代替案、被害測定、事後緩和
-
ブラウザ自動化とLynx mode
- Hermes AgentとQwen3.6で大半の作業が可能であり、Prompt APIよりbrowser automation APIとチャット向けLynx modeに注目すべきだという流れがある
- 一部ワークフローでは、人がWebサイトにログインしてAJAX拡張でファイルを見えるようにした後、agentがchromedriver/webdriverで文書のダウンロード、タグ付け、要約を行う構成になっている
- この流れは外部POSIX shellなしでブラウザ内に統合できる
- Lynx mode chatは、agentsが見ている内容を素早く露出し、すべてのメディア資産をダウンロードまたはレンダリングしないことで双方のリソースを節約する方式である
- HTMLレベルのより細かなrobotsタグ付け、Lynxmode shellと既存ブラウザ間のhandoff、agent-driven browserでold-school Google AdWord風リンクを選択的に見せる方法も論じられている
-
オープンウェブとFOMO
- オープンウェブはchat bot super appsのような対象と同じ方法で競争しているわけではなく、消え去ることもないという反論がある
- 継続的なFOMOより、自分たちが何を代表したいのかをまず問うべきだという立場もある
- Webがmobile app paradigmを十分に支えられなかったのと同様に、agentic computingを素早く効果的に支援できなければcommerceやjournalismがopen webの外へ移るという懸念には同意しない流れもある
-
Chromiumの出荷と被害測定
- Chromiumのblink API owner approverの一人はMozillaの懸念に共感しつつも、実験し、失敗から学び、競争を促す道を好むとしている
- 将来的に実被害を評価するには具体的な結果を定義する必要があり、EMEのような論争的APIの出荷判断を5〜10年後に実際の結果と比較するやり方が有用だったという文脈がある
- サイトがGoogle特定モデルに固定化する被害は、他ブラウザが出荷時に遭遇するsite compat bugの件数と規模、Chromeがモデル更新時に生じるbugの性質で評価できる
- bugが「モデルをより賢くする」ものなのか「奇妙なquirkを温存する」ものなのかを区別し、webcompat.comにラベルを付けて集約する案が出ている
- blink-dev I2Sによれば、Edgeも別モデルでこのAPIを出荷しており、初期データがすでにある
- TOS懸念の被害指標は、違反によって実際に訴訟や脅しが起きたかどうかであり、その証拠を記録として集めようという流れである
-
事後緩和とChromeの対応
- 想定される被害を実際に確認するアプローチは妥当だが、被害発生後に意味のある緩和策がある場合にのみ有用だという反論がある
- サイトがGoogle特定モデルに固定化した場合、feature unship、過度に最適化されたsite promptを壊すモデル変更、random model rotation、on-device model weightsのopen standard化といった選択肢が問いとして列挙されている
- 他ブラウザがChromeモデルの奇妙なquirkをコピーしなければならない証拠が出れば、Chromiumのリーダーシップの立場からChromeにそのquirkを壊すよう働きかけるという見解が示されている
- Mobile GMailがbuggyなWebKit border image quirksに依存し、Firefoxが複製の必要を感じた際、Chromeを修正してGMailを壊したところ、GMailは素早く更新され、ユーザーは気づかなかったという前例も挙げられている
1件のコメント
Hacker Newsの意見
反対論点はかなり明確に見える: プロンプトとモデルの強い結合、そして規約におけるモデル中立性の問題だ
https://github.com/mozilla/standards-positions/issues/1213 の個人的な事例のように、ホームオートメーション通知用のシステムプロンプトを作るとき、Geminiは最初あまりにもアメリカ風に答えたので、イギリス風の音声で話すと伝えたところ、今度は「a'waight guv'nor apples and pears」のような、アメリカ人のぎこちない英国まねになってしまい、さらに調整が必要だった
この過程でシステムプロンプトは特定モデル向けに最適化され、他のモデルには別の quirks があるので、あるモデル向けに入れた補正が別のモデルには過補正になりうる
モデルごとに違うというのはこの技術の中核的な特性だ。デバイスや向きによって canvas サイズが変わり、geolocation API の精度が変わり、Speech Synthesis の音声がデバイスごとに違うのと似ている
これは建設的な批判というより anti-AI 感情 に近い。今は権限 UI が必要で、いずれ low/medium/high のような IQ レベルが付くかもしれないが、気にする開発者はどうせ 90% は特定モデルに依存することになる
時間が経って AI 嫌悪が薄れ、それが役立つと人々が気づけば、Firefox にこの機能がないことは 個人データの自律性 の観点で失敗と見なされるかもしれない。Chrome の関連 TOU が問題なら、むしろ Firefox が問題のないモデル規約でこの機能を入れるべき理由になる
反対文を誰が書いたのか知らなかったが、Chrome チームに長くいた Googler の Jake Archibald が Mozilla に移って Chrome API に反対する文を書いたのだった。批判がよく整理されているのも驚きではないし、今回は党議に従わなくてよくてせいせいしただろう
まだチームに残っている人たちの話を聞くと、その点では状況は指数関数的に悪化しているようだ
変更提案をする代わりに全体を破棄しようとしている感じで、破棄されたら Google Chrome チームの観点から始めるのではなく、最初から協調して書き直すことを期待しているように見える。ただ、そういうやり方でうまくいった例をあまり見ないので、単に具体的な修正案を出すほうがよさそうだ
これは反対だ
explainer はデータをどこにも送らずローカルで処理できるとしているが、ならばなぜ Google Gemini ローカルモデルに Prohibited Use Policy が必要なのか疑問だ。Google が知りえないプロンプトと応答をなぜ気にするのか
オフライン LLM アクセス自体はよさそうだが、ブラウザに LLM を内蔵しなくても Web サイトは WebGPU を使えるし、ML モデル処理のために WebGPU を改善することもできる。あるいは皆が同じオープンソース LLM を使うべきだ
robots.txt が強制要件ではなく完全に迂回できることが今や常識になり、オープン Web を事実上 dark forest にしてしまった
ブラウザセッションが改変されていない、あるいは「trusted」だと検証される仕組みは今後出てくる可能性が高い。本当に嫌だが、結局は自業自得な面もある
サイトが小さな LLM リクエストを送り、モデル自体を fingerprinting する経路はありうるが、無効にできるなら大きな問題ではないと思う
もっと広く言えば、「Web プラットフォームはこれをできるべきではない」という形の懸念がある。この立場では、ユーザーが無効にできても「LLM がないのでブラウザ未対応」のようなサイトが生まれ、Web が悪化すると言えるかもしれない
だが、それは結局 Web サイト運営者が LLM がなければサイトを無効にすると決めたのであって、機能を作ったプラットフォームやメンテナの責任ではない。Firefox でも問題なく動くのに、テストが面倒だからサポートを切るのと似ている
Web は PDF と競争しているのではなく、SwiftUI と競争する世界で最も成功したアプリケーションプラットフォームだ。「Web を今のように静的なままで維持すればよい」という選択肢は幻想で、現実の選択肢は、ユーザーの変化する要求に合わせて Web を適応させるか、Web が失敗して SwiftUI や WinUI がその空白を埋めるかのどちらかだ。後者のほうがずっと悪い
https://news.ycombinator.com/item?id=47960596
結論は、もう次へ進むときだということだ。Web ブラウザより優れたオンライン情報交換・メディア再生の形式を考えるべきだ。私たちが商品なら、私たちが使う道具も、信頼できない支配者へ密かに広告収益を流すプロキシのように振る舞うのではなく、その事実を直接反映すべきだ
考えれば考えるほど、今回は Google の API 設計側により同意するようになった
プロンプトとモデルの強い結合 は現実の懸念であり、毎日直面する問題だ。しかし、解決策がユーザーのブラウザにあるモデルと評価されるプロンプトをさらに強く結びつける API だとしたら、すぐに「うちのプロンプトは Gemini でしかテストしていないので、このサイトには Chrome が必要です」のような状況になる
さらに悪いのは、「使用中の AI モデルを認識できない」ということだ。2026 年に作られたサイトが 2030 年まで更新されなければ、十分起こりうる
これは Mozilla エンジニアが後ろで述べていた規約の問題にもつながる。特定の AI モデル規約に同意しなくてよいブラウザ、たとえば良いオープンソースモデルを使うブラウザが存在できるようにするには、Big Models を fingerprinting できないようにするほうが都合がよい
もちろん多くのサイトはどうせ isChrome() のような呼び出しをするだろう。それでも、ブラウザ fingerprinting の手段を増やす変更には概して反対だ。モデルを匿名のままにしておく利点のほうが、Gemini や Qwen のようなモデル間の小さな違いによってまれに変な出力が出る欠点より大きい
なぜ Google は、ブラウザがすでにできる多くのことの構造的弱点を直すために莫大な資源を使わず、相変わらず雑多なものを付け足してブラウザを Homermobile にしようとするのか分からない
静的ブログから電子商取引、最先端の Web アプリまで、Web プラットフォーム全体の QOL を高める基礎的なものに集中すべきではないか
https://simpsons.fandom.com/wiki/The_Homer
Android と ChromeOS で直接それを試しているが、Chrome は Windows のような環境の平均的なユーザーでも、ほとんどの時間を Google 世界の中で過ごすようにする
現在の LLM と API harness は、このような API が標準に入るほど技術的に成熟していないと強く思う
それでもやるなら、最低でもサイトごとの opt-in 権限であるべきで、どのモデルにプロンプトを送っているのかを識別する方法が必要だ。システムプロンプトの小さな調整までも、そのアイデンティティに含まれる
ユーザーとしては、任意のサイトを訪れたとき、許可なくこの API で fingerprinting されないという確信が必要だ
開発者としては、ユーザーがどのモデルを使っているかを知ることで、モデル別のプロンプトを作るという選択肢が生まれる
「ブラウザとオペレーティングシステムが言語モデルにアクセスすることが次第に期待されている」と? 本当にそうなのか?
https://github.com/webmachinelearning/prompt-api/blob/main/R...
だからデフォルトはオフのまま、ユーザーが望むときに有効化できる LLM 向けインターフェースだけ提供すればよいと思う
そうすれば Apple が OS に入れた LLM に lock-in されず、どの LLM provider を使うかを選べる。たとえば Apple Intelligence がアクセスできるものを Claude にもアクセスさせたい
今では「アクセスすることが期待されている」より「搭載されつつある」に変えられるかもしれない。多くの人が混乱しているようなので、プロジェクトのメンテナがそう更新してくれるとよい
理論的には有用だ。開発者がローカルモデルに依存できれば、より private で decentralized になり、AWS や Anthropic に金を送る必要も減る。ローカルで、オフラインで使えて、無料である場合にしか意味のない low-stakes な用途もある
だが実際には、ネイティブアプリで Apple Foundation Models の採用をほとんど見ていない。Mac/iOS 開発者で共有できることがあるのか気になる
これからはあらゆるものがますます bikeshed を期待するようになる。CVE が待たれる
オープンプロトコルの良い点は、特定の実装を支持したり使ったりする必要がないことだが、それでも ブラウザ独占 はずっとジレンマとして残っている
ungoogled chromium や Tor のような良いプロジェクトはあるが、最大の問題は、平均的な人のための声と大衆につながるプロジェクトが不足していることだ
よく知らないユーザーのかなりの部分は、原因やメッセージの伝え方に無関心で、自由や統制よりも「面白さ」や摩擦の少なさに強く反応する
これをどう解決すればいいのか? どうすればブラウザを私たちのもの、人々による、人々のためのものにできるのか? こう考えるたび、ただ悲しくなる
Browser Agent 文字列が Chrome や Firefox でなければ、終わりのない Cloudflare CAPTCHA や 403 に出会うことになる
その次に、Chrome のやり方ではなく Web 標準 に基づいて Web アプリケーションを作り、Firefox や Safari が追随しないと不平を言わないことだ
平均的な人に届くプロジェクトが必要だと言いながら、同時に彼らは自由や統制より摩擦の少なさを望むとも言っている。矛盾しているように見える。平均的な人は統制より less friction に結びついている
この API の use case が何なのか気になる
ローカル LLM を動かすときの自分の経験では、llama-server を立ち上げ、必要なら別マシンで動かし、そのうえで他のアプリケーションが OpenAI や類似サービスの代わりにその OpenAI 互換サーバー を参照するよう設定するというものだ
ブラウザが LLM インスタンスを作ったり実行したりするのは望まない。そのマシンには LLM インスタンスを動かす能力や余裕がないかもしれないからだ
これは、もはや LLM なしでは生きられない若い世代と、プライバシーを侵害する Web ブラウザを動かすためにスーパーコンピュータまで要求されたくない古い世代との差なのだろうかと気になる
自分には、人々が ブラウザ/Web の代替 を探し、開発し始める地点のように聞こえる
現在の形の提案 API が Web の相互運用性 にとってなぜ悪いのか、明確で論理的な理由を説明しているのだ
個人的にはコーディング支援やホームオートメーションに LLM を使っているが、この API が Web にとって良いとは思わない
正解は分からないが、Niri/Wayland、GNOME、Windows、Mac を使ったあとでは、non-tiling desktop とキーボード中心でないデスクトップのウィンドウ管理 workflow には二度と戻れないだろう