Mozilla激怒｜Chrome Prompt API反対×Web独占の全貌
A
AI Friends
2026年5月2日・19分で読める
❤️ 0
🔖 0
⚡ 0
「ChromeにAIが組み込まれて便利になる」——その流れに対して、Mozillaが本気で怒っています。理由は単純な反対ではなく、「これはWebの未来を狭める」という本質的な懸念です。
2026年4月30日、Mozilla公式の標準化リポジトリで『Prompt API』に対して『opposed（反対）』ステータスが明記され、Web開発者コミュニティに激震が走りました。ブラウザに組み込まれたAIは確かに便利な反面、Web全体がGoogle Gemini Nanoという特定モデルに縛られる危険性が指摘されています。
この記事では、Mozillaが反対する3つの本質的理由、Firefox AI Runtimeの代替設計、Chrome・Firefox・Safariの三者比較、そして日本のWeb開発現場への影響までを順に整理します。
Mozillaは自社のGitHubで管理する『standards-positions』リポジトリで、GoogleがChromeに導入した『Prompt API』に対し『opposed（反対）』のステータスを付与しました。これは『support（支持）』『neutral（中立）』など複数段階あるなかで、最も否定的なシグナルにあたります。
Mozillaの開発者リレーションズリードJake Archibald氏は「相互運用性・更新性・中立性に深刻な悪影響がある」と公式コメントを出しています。2026年4月30日にThe Registerが報じたことで、この反対表明は広く注目を集めました。Mozillaは過去にもChrome独自APIに反対してきましたが、今回は特に強い言葉で危険性を訴えている点が特徴的です。
反対の対象となっている『Prompt API』は、Chromeに組み込まれた『Gemini Nano（小型のGoogle製AI）』をJavaScriptから直接呼び出せる仕組みです。Webサイトが「文章を要約して」「翻訳して」といった自然言語命令を、ブラウザ内のAIに送れる機能だと考えればわかりやすいでしょう。
Chrome 138以降、拡張機能向けには『一般提供（GA）』が始まっています。Webページ向けはフラグ有効化またはオリジントライアル参加で利用可能で、テキスト・画像・音声のマルチモーダル入力に対応しています。クラウドAIに通信する必要がないため、応答速度・コスト・プライバシーすべてに利点があるのは事実です。Mozillaが警鐘を鳴らすのは、便利さそのものではなく、その先にある構造的な問題のほうです。
Prompt APIは現在、W3C（World Wide Web Consortium・Web標準を決める国際団体）の『WebML』コミュニティグループで提案中の段階です。Web標準として世界中のブラウザに採用される可能性のある仕様として、議論が進んでいます。
つまりMozillaの反対は『単なる一企業の意見』ではなく、Web標準化プロセスにおける重要な論点提示にあたります。Apple WebKit（Safari）も2026年時点で慎重姿勢を示しており、Web開発者にとっては自分たちの仕事の未来を左右する議論が、いままさに進行中という状況です。
Mozillaの最大の論点は、「プロンプトはAIモデル固有の癖と政策に最適化される」という性質にあります。Gemini Nano向けに調整したプロンプトは、別のブラウザの別のAIモデルでは同じように動く保証がありません。
実際、Prompt APIのREADMEファイル自体に「ブラウザ間の相互運用性は保証されない」と明記されています。これはWeb標準の根本理念に反するというのが、Mozillaの強い批判です。Webサイトを作る側からすると「Chromeでは動くけど、Firefoxでは違う動き、Safariではまた違う」というブラウザ互換性問題——いわば1990年代のIE時代の悪夢——が再来する可能性を、Mozillaは強く警戒しています。
第二の懸念は、特定モデルへの事実上のロックインです。Mozillaは「Gemini Nanoが事実上の標準になれば、AppleやMozillaも互換性のためにNanoのライセンスを買わざるを得ない圧力がかかる」と警告しています。結果としてWeb全体がGoogleの単一モデルに縛られる危険性があるという主張です。
AIの応答は非決定的（毎回答えが微妙に違う）なため、開発者は特定モデルの「癖」に最適化せざるを得ません。その結果、Gemini Nano以外では動かないコードが量産される悪循環が生まれます。Mozillaは「AppleがNanoを買わざるを得なくなる構図は健全ではない」と、業界全体への波及を懸念しています。
第三の懸念は、規約面の従属関係です。Prompt APIの利用にはGoogleの『Generative AI Prohibited Uses Policy（生成AI禁止用途ポリシー）』への同意が必須となっています。このポリシーには「不快な内容の生成」など、必ずしも違法ではない用途まで禁止項目に含まれています。
Mozillaの主張は「Web標準のAPI利用が、特定企業の社内ポリシーに依存するのは中立性に反する」というものです。言い換えれば、Googleの社内ルール変更でWeb全体の動きが変わってしまう脆弱な構造への警鐘です。Webは本来、誰もが自由に使える公共インフラとして発展してきたため、特定企業の規約への従属は哲学的にも大きな問題と映ります。
Firefoxにも『AI Runtime』と呼ばれるブラウザ内AI機能が存在します。しかし設計思想はChromeと決定的に異なり、内部機能（ブラウザ自身が使う処理）と拡張機能向けに限定し、一般のWebサイトからは呼び出せない構造になっています。
背景にあるのは「Webの中立性を守るため、ブラウザがAIを使うのは構わないが、それをWeb APIとして公開するのは別問題」というMozillaの哲学です。ブラウザ内部の高機能化と、Web標準としての公開とは線を分ける、という慎重な切り分けです。利便性とWeb全体の健全性を両立させようとする姿勢が表れています。
もう一つの大きな違いが、モデルの透明性です。Firefox AI Runtimeはどのモデルを使っているかを開発者・ユーザーに明示的に識別させる設計を採用しています。Prompt APIが「どのモデルが使われるかはブラウザ次第」のモデル非依存アプローチを取るのと対照的です。
Mozillaは「どのモデルが応答を生成しているかが分からないと、開発者は責任ある実装ができない、ユーザーも何が起きているか理解できない」と、透明性の重要性を強調しています。長期的な信頼性と説明責任を重視する哲学が、設計の隅々に表れているわけです。
誤解されやすい点ですが、Mozillaは「ローカルAI処理・オフライン動作・コスト削減・プライバシー優位」というPrompt APIの利点自体は明確に認めています。AIブラウザ機能そのものに反対しているわけではありません。
Mozillaの主張は「Webが特定モデル・特定企業に縛られない設計を確保すべき」という点に集中しています。つまり「反AI」ではなく「反ロックイン」のポジションです。技術の進歩は受け入れつつ、Webのオープン性という根本価値を守ろうとする姿勢が鮮明と言えます。
GoogleはChromeを「AIブラウザ」として再定義する戦略を取っています。Prompt API以外にもSummarizer API・Writer API・Rewriter API・Proofreader APIなど複数のAI機能を組み込み、Gemini Nanoエコシステムを構築中です。
2026年5月時点でWindows 10/11・macOS 13以降・Linux・ChromeOSで動作し、市場シェア60%超の優位性を活かしたデファクト標準化戦略を進めています。シェアと開発リソースで先行実装し、後から標準化を主導する——というのが、Googleの一貫したスタイルです。
MozillaはWeb全体の中立性を守るオープンソース陣営の番人として位置づけられます。今回のPrompt API反対表明はその代表例で、ブラウザシェアは数%に低下したものの、標準化議論への影響力は依然として大きい存在です。
Firefox AI Runtimeで内部AI機能は実装しつつも、Web APIとして公開しない一線を堅持しています。独自のブラウザAI戦略よりも「公平な標準化」を優先する姿勢で、Mozillaの存在意義は市場シェアではなく「Webの公共性を守る監視役」にあると言えます。
AppleのSafari（WebKit）は2026年5月時点でPrompt API実装の予定がなく、Apple Intelligenceは独自のオンデバイスAI戦略を展開しています。Web APIへの組み込みについては、慎重姿勢を維持しています。
Apple SVPのEddy Cue氏が「AI検索エンジンのSafari統合を積極検討中」と発言したことはありますが、独自のApple Intelligenceエコシステムを優先し、Googleエコシステムへの追従は避ける戦略です。プライバシー重視と独自エコシステムを軸に、Web標準よりも自社プラットフォーム優先の姿勢が鮮明になっています。
2026年5月時点で日本のブラウザシェアはChrome約65%・Safari約25%・Edge約7%・Firefox約3%です。Prompt APIを使ったWebサイトはChrome優先設計になりがちで、他ブラウザでの動作確認・代替実装の負担が増加します。
大手ECサイト・メディアサイトは「Chrome向けAI機能」と「Safari向け代替実装」の二重メンテナンスを迫られる可能性が出てきます。開発工数とテスト負荷が膨張することが懸念され、特に中小Web制作会社にとっては、コスト管理が難しくなる現実的な問題です。
これまでWebサイトのAI機能は「OpenAI APIなど外部AIをクラウド経由で呼ぶ」構造で、サーバーコストとAPIコストが重い課題でした。Prompt APIならブラウザ内で完結し、費用ゼロで実現できます。
大手企業は「コスト削減のため積極導入したいが、Mozilla反対の警鐘で標準化リスクを意識、Chrome専用実装になると将来の移植が困難」というジレンマを抱えています。コストとロックインのバランスをどう取るかが、今後の重要な経営判断になっていきます。
Prompt APIの「データがブラウザ外に出ない」性質は、医療・金融・法律など機密性の高い業界にとって大きな魅力です。患者情報・顧客資産情報をクラウドAIに送らずに済むため、情報漏洩のリスクを大幅に下げられます。
日本の医療機関・金融機関は個人情報保護法・APPI対応で厳格な制約があり、ブラウザ内ローカルAIは法的リスクを大幅に軽減できる選択肢になります。Mozillaの懸念とは別の文脈で、プライバシー重視業界には魅力的な技術であることも事実です。
都内でフリーランスWeb開発を営む健太さんは2026年5月時点で、クライアントからChrome Prompt APIを使った要約機能の導入を相談されているといいます。「コスト的には魅力的だが、Mozilla反対のニュースで悩んでいる」のが本音です。
Firefox・Safariユーザーへの代替実装を提案するか、Chrome専用と割り切るかで、追加見積もりが30%増になる試算もあります。「標準化が固まるまで半年待つことも選択肢」と判断に悩んでいます。Web開発者にとっては、技術選定の難しさが一段と増した時代です。
地方の中小ECサイト運営者・佐藤さんは2026年5月時点で、商品説明の自動要約・レビュー翻訳などにAIを使いたいと考えています。「月額10万円のクラウドAI費が痛い、Prompt APIなら費用ゼロでぜひ導入したい」というのが導入動機です。
「うちの顧客はChrome利用者が7割なので、まず実装して試したい。Safari・Firefoxユーザーは従来の代替表示でカバーする」という前向きな判断です。中小事業者には、コスト削減とリスク許容のリアルな天秤が日々続いています。
IT企業勤務でWebリテラシーが高い美咲さんは、普段はFirefoxを使っています。「最近Chrome専用機能のサイトが増えて、Firefoxでは劣化版しか見られないことに違和感を覚えている」と話します。
「Mozilla反対のニュースを読んで『これは大事な議論だ』と感じた。ブラウザの選択肢が実質的に奪われる未来は避けたい、個人としてはFirefoxを応援し続けたい」との意見です。技術選択の自由がWebの将来を決める重要な要素であることを、ユーザー側でも実感する人が増えています。
Chrome 138以降で拡張機能向けに一般提供（GA）が始まっています。Webページ向けはフラグ有効化またはオリジントライアル参加が必要です。
マルチモーダル機能（画像・音声入力）はオリジントライアル中で、参加すれば本番Webサイトでテスト可能です。Chrome側での正式リリース時期は未定です。動作環境はWindows 10/11・macOS 13以降・Linux・ChromeOSで、モデル（Gemini Nano）は初回利用時に自動ダウンロードされます。
試したい開発者はいますぐ試験できますが、安心して使いたい場合は本格普及を待つのが賢明です。
「Webの中立性とブラウザ互換性の根本を脅かす設計だから」がMozillaの本音です。
過去の歴史でも、IE専用機能・Flash・特定企業独自APIなど、Webの分断を招いた事例が多数あります。Mozillaは「同じ轍を踏まない」ことを使命としています。Prompt APIは利便性が高いだけに、安易に普及すると「Chrome専用Web」が事実上の標準になり、Webのオープン性という根本価値が失われるリスクがある——というのが反対の核心です。
長期的な視点で見れば、Mozillaの懸念は妥当な側面が大きいといえます。
「プロトタイプ・社内ツールはOK、本番Webサイトは慎重に」が業界アドバイザーの一般的な見解です。
2026年5月時点ではChrome専用機能のため、Safari・Firefoxには別実装が必要です。本番運用ではブラウザ判定とフォールバック設計が必須となります。標準化の方向性が定まる2027年以降に本格採用するのが安全策で、それまではOpenAI APIなどクラウドAIとの併用が現実的な選択肢になります。
新規構築なら、業界標準で建てて後でリフォームできる余地を残しておく——その姿勢が技術選定の鍵です。
「独自のApple Intelligence戦略があり、Googleエコシステムへの追従を避けたいから」が主な理由です。
AppleはiOS 18・macOS 15からApple Intelligence（独自AI機能）を展開しており、SafariのAI機能も自社モデルで実装する方向です。Web APIへの組み込みには慎重姿勢を維持しています。
背景には「プライバシー重視のApple哲学」「独自シリコン（Apple Silicon）への最適化」「Googleへの依存回避」など、複数の戦略的理由が絡んでいます。
「複数ブラウザを使い分け、Webの選択肢を維持する意識が大切」というのがコミュニティの共通アドバイスです。
個人ユーザーがFirefox・Safariを選び続けることが、ブラウザ多様性を維持する直接的な行動になります。シェアの偏りはWeb全体の選択肢を狭める結果につながりかねません。
プライバシー重視ならFirefox・Brave、Apple製品ユーザーならSafari、業務効率ならChromeなど、用途に応じた使い分けが現実的なアクションです。
「ChromeにAIが組み込まれて便利になる」——その背後では、Webの中立性を守る30年の闘いが新たな局面を迎えています。
Mozillaの公式反対は「便利だから反対」ではなく「便利だからこそ設計を慎重にすべき」という、Web開発の長期的な健全性を見据えた本質的な議論です。Gemini Nanoのロックイン懸念、Googleの利用規約への依存、相互運用性の崩壊リスクは、開発者・事業者・ユーザーすべてに関わる重要な論点で、決して「一企業の意見」として片付けられるものではありません。
今日からできる3ステップは次のとおりです。①Web開発者は技術選定でブラウザ互換性を意識する、②事業者はChrome専用実装と移植コストをセットで見積もる、③ユーザーは複数ブラウザの使い分けでWebの選択肢を維持する。便利さと中立性のバランスを誰がどう守るのか——Webの未来を左右する論争が、2026年から本格化しています。
この記事は AI Friends からのクロスポストです。
@aifriends
AI Friends（https://aifriends.jp）のクロスポスト公式アカウント。AIツールの紹介・使い方・できることを、中学生でもわかるやさしい日本語で届けます。
まだコメントはありません
