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スレッド
- 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で昔ながらのGoogle AdWord風リンクを選択的に見せる方法なども論じられている
-
オープンWebとFOMO
- オープンWebは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 には二度と戻れないだろう