Firefox開発元が、ブラウザに「Prompt API」を組み込むGoogleを非難

The Register / 2026/5/1

💬 オピニオンDeveloper Stack & InfrastructureSignals & Early TrendsIndustry & Market Moves

要点

  • Mozillaは、ChromeブラウザにAIの「Prompt API」を直接組み込むGoogleの計画に対して反発しています。
  • Mozillaは、主要なブラウザ事業者がAI機能をウェブに直結させることで、ウェブ全体の「オープンさ」と相互運用性が損なわれることを懸念しています。
  • この対立は、一般的なウェブ標準から、巨大プラットフォーム事業者が主導するブラウザ固有のAIインターフェースへと移行する可能性を示しています。
  • 記事では、議論を技術的な統合の問題であると同時に、将来のウェブ開発の統治・アーキテクチャの問題として位置づけています。
  • 結果によって、開発者がAI搭載のブラウザ体験を作る方法が、共通標準かベンダー紐づきAPIのどちらに寄るかが左右され得ます。

Firefox製作者が、ブラウザにPrompt APIを組み込むためのGoogleの動きにくってかかる

Mozillaは、ChromeにAI APIを配線することがWebをよりオープンでなくすることを恐れている

Thu 30 Apr 2026 // 20:49 UTC

Mozillaは、GoogleがAIの配管(インフラ)を自社のChromeブラウザに組み込もうとしていることに対する反対を改めて表明した。ただし、Prompt APIとして知られるその技術が、すでにChromeやMicrosoft Edgeでテストされているのは今になってからだ。

MozillaのWeb開発者リレーションズ責任者であるJake Archibaldは、APIについてのGitHubでの議論の中で組織の懸念を明確にした。これは、ローカルの機械学習モデルからプロンプトとレスポンスを送受信するための標準的な方法を提供する。

「私たちはこのAPIへの反対を引き続き表明しており、Webプラットフォームの相互運用性、更新可能性(アップデータビリティ)、中立性に対して深刻な悪影響があると感じている」とArchibaldは述べた。

Googleが説明するPrompt APIは、「Webページに、ブラウザが提供する言語モデルへ直接プロンプトを送る能力を与える」ものだ。GoogleのGemini Nanoモデルに対して自然言語の指示を送る方法を提供する。Gemini Nanoは小型であるため、Chrome経由でローカル推論のためにダウンロードできる。

それほど小さいわけではない。Googleは22GBの空き容量を用意することを推奨しているが、デスクトップ用途のNano(v3Nano)モデルは約4.27GBだ。

Web開発者は、AIモデルとやり取りするためのさまざまな手段をすでに持っている。クラウドサービスのAPIを使って、ホストされたモデルと通信することもできる。また、JavaScript実行環境のフレームワーク、WASM、WebGPUといった技術を通じてローカルのモデルにアクセスすることも可能だ。

返却形式: {"translated": "翻訳されたHTML"}

OpenAIやPerplexityのようなさまざまなベンダーが、リモートでホストされたAIモデルへのアクセスを埋め込んだブラウザを出荷してきました。Mozilla自身もFirefoxでAIベースのスマートウィンドウをテストしており、AIモデルの足場(スキャフォールド)を作るためのツールを開発しています。

Prompt APIは、ブラウザのセキュリティ機構を活用しながらローカル推論を実行しやすくすること、応答時間をより速くすること、オフライン利用を可能にすること、そしてAIサービスを(例えば、有料のAI APIキーを持っていないユーザー向けに無料のAIフォールバックを提供するなど)より費用対効果の高い形で統合できるようにすることを目指しています。

Archibaldが述べるMozillaの懸念は、Googleによる導入の正当化はさておき、Prompt APIがウェブにとって何を意味するのか、という点にあります。

まず彼は、Google自身のNanoモデルがデフォルトになり、開発者がそれに標準化していくのではないかと心配しています。AIモデルの非決定的な応答をより予測可能にするためです。その傾向によって、共通のユーザー体験のためにAppleやMozillaがNanoのライセンスを求められるようになる、と彼は主張します。

さらに重要な点として、Archibaldは、Prompt APIを使うにはGoogleの生成AIの禁止事項ポリシーに同意する必要があると指摘しています。このポリシーは、「『邪魔になる(disturbing)』コンテンツ」を生成することのように、必ずしも違法とは限らない活動を禁じています。

「これはウェブプラットフォーム上のAPIとしては悪い方向のように思えますし、[ブラウザ]固有の使用ルールをめぐる、より多くのAPIに対して憂慮すべき前例を作ることになります」と彼は述べました。

最後にArchibaldは、GoogleがAPIに対する需要を誤って伝えたのは、ソーシャルメディアの投稿をいくつかつまみ上げて、それを開発者の支持の高まりだと呼んだことによる、と主張しています。

blink-devで出荷する意図では、ウェブ開発者を『強く前向き(Strongly positive)』としており、根拠として説明記事へのリンクまで貼っています」と彼は書きました。「しかし、そこで提示されている証拠は、その主張に適合していないように見えます。」

メールでArchibaldはThe Registerに対し、論点はPrompt APIがウェブにとって良いのかどうかであり、Mozillaはそれが良いとは考えていない、と伝えました。

「根本的な問題は相互運用性(インターオペラビリティ)です。プロンプトはモデルに強く結び付いています。開発者は必然的に、自分が対して構築しているモデルの癖やポリシーに合わせて調整してしまいます。 

『モデル固有のコードパス』が生まれてしまうのです。これは、ブラウザ互換性の問題がもう一度繰り返されるのと同じことです。その一部としてT&C(利用規約)の問題もあります。もしウェブAPIを使うことが、特定のベンダーのコンテンツポリシー(とりわけ法律を超えているもの)を受け入れることを意味するなら、もはやオープンなプラットフォームのために作っていることにはあまりなりません。」

開発者の熱意に関するGoogleの誇張について、Archibaldは、確かにAI機能に関心を持つ開発者はいるが、Googleはそれを裏付ける証拠を提示できていないと述べました。

「シグナルは『強く前向き』ではなく、極化しています」と彼は説明しました。「いずれにせよ、開発者の需要だけでは基準を満たしません。問題は、そのAPIが、プラットフォームを一つのベンダーのモデルに縛り付けることなく、実装をまたいで機能できるかどうかです。」

Googleは、コメント要請に対して直ちに返答しませんでした。

しかし木曜日、Prompt APIの出荷を担当するGoogle ChromeエンジニアのRick Byersが、Archibaldが述べた懸念を認める形で、GitHub上の議論に(追随する形で)投稿しました。

「Chromiumでこれを出荷するためのblink APIオーナーの承認者の一人として、Mozillaの標準方針にあるここでの懸念は私も共有していることを認めます」と彼は書きました。「ただし、私が異なるのは、『起こり得ることへの恐れ』でイノベーションを止めてしまう側に寄っている道ではなく、実験を促し、失敗から学び、競争を後押しする道を好む点です。」

Byersは、害があることを示す証拠の収集にウェブコミュニティの協力を求めました。Encrypted Media Extensions(EME)のような、他の物議を醸したウェブ技術をめぐる議論を引き合いに出し、結果は予測されていたほど深刻にはならなかったのではないか、と示唆しました。

ですが、データに焦点を当てても、現時点ではGoogle側の主張にはあまり役立っていません。Prompt APIを使ってChrome(Gemini Nano)とEdge(Phi-4 mini-instruct)のパフォーマンスを比較する、2月に作成されたレポートによれば、これらのモデルは単に、あまり良い結果を提供できていないのです。

「生成タスク(作曲、タグ生成など)では、失敗を『5段階評価で2以下のスコア』と定義するルーブリックに基づくと、Edgeの応答の24.29パーセント、Chromeの応答の15.17パーセントがタスクを完了できませんでした」とレポートは述べています。「分類タスクでは、Edgeの29.58パーセント、Chromeの23.93パーセントの応答が入力に対してラベル付けやカテゴリ分けを正しく行いませんでした。」

下支え(groundedness)や正確性の観点では、Edgeは17パーセントの確率で失敗(『ハルシネーション』)し、Chromeは6パーセントの確率で失敗しました。

それはウェブにとって良いのでしょうか?Chromeなら聞けますが、信頼できる答えが得られるとは限りません。®

共有

関連記事