2026 年 4 月末、Mozilla が Chrome の Prompt API（ブラウザ内蔵 LLM API）への反対表明 を Web 標準化リポジトリに公開しました。Chrome は Gemini Nano をブラウザに同梱して 「JavaScript から window.ai.languageModel を叩くだけで LLM を使える」 世界を推進していますが、Mozilla は 「ブラウザ間でモデルが違うため、ユーザーへの出力品質に互換性がなくなる」 という立場で反対しています。
受託 Web 開発の現場で 「Chrome では動くが Firefox / Safari では動かない AI 機能」を作ると、納品物としての資産価値が一気に落ちます。本記事では、ブラウザ内蔵 AI API の現状を整理した上で、受託でフォールバックを考えた実装戦略をまとめます。
ブラウザ内蔵 AI API の現状（2026 年 5 月時点）
Chrome（Google）が先行する一方、Firefox（Mozilla）と Safari（Apple）の温度感は明確に異なります。
| ブラウザ | Prompt API | Translator API | Summarizer API | Writer/Rewriter API |
|---|---|---|---|---|
| Chrome 147+ | Origin Trial / Stable へ | Stable | Origin Trial | Origin Trial |
| Edge | Chrome に追従 | Chrome に追従 | Chrome に追従 | Chrome に追従 |
| Firefox | ❌ 反対表明 | ⚠️ 検討中 | ⚠️ 検討中 | ❌ 反対 |
| Safari | ⚠️ Apple Intelligence と統合検討 | ✅ ローカル翻訳実装あり | ⚠️ 様子見 | ⚠️ 様子見 |
Chrome の Prompt API はモデルとして Gemini Nano（〜2GB のオンデバイスモデル）を同梱する前提で、プロンプト文字列を直接渡して応答を受け取る汎用 API です。Mozilla はこの汎用 API に対して、「モデルの差で出力が変わるため、Web プラットフォームに乗せるべきではない」という主張をしています。
一方、Translator API / Summarizer API のような “用途特化型 API” はブラウザ間で実装可能性が比較的高く、Mozilla も Translator API には条件付きで肯定的です。受託で実装するなら、「汎用 LLM API」ではなく「用途特化 API」優先が安全な指針になります。
これは Google AI Mode in Chrome の SEO インパクト で扱った「ブラウザの AI 化」の続編として、開発者側がどう備えるかを問われている流れと言えます。
受託で AI ブラウザ機能を実装する 3 つの選択肢
実装パターンは大きく 3 つです。
選択肢 1: Chrome 専用に絞る（推奨しない）
Chrome 限定機能として割り切る方法。Web Store 拡張機能や B2B の社内ツール（Chrome 強制） ではアリですが、一般公開する顧客向けサイトでは選択しない方が良いです。納品後の 「Firefox ユーザーから問い合わせ」でクレーム対応工数が発生する確率が高いためです。
選択肢 2: サーバー LLM ＋ ブラウザ AI のハイブリッド（推奨）
サーバー側に LLM API（OpenAI / Gemini / Claude）を持ち、ブラウザに Prompt API があれば優先利用するパターン。Chrome では低レイテンシ・無課金、それ以外のブラウザではサーバー API にフォールバック、という二段構成です。実装は次節で詳述します。
選択肢 3: サーバー LLM のみ（守備に強い）
ブラウザ側の AI を一切使わない。コスト面では Chrome ユーザーで損をしますが、全ブラウザで体験が均一で、サポートが楽です。ECサイト・予約システムなど、「機能が動かない」のがクリティカルな案件はこちら。
選択の目安：
- 一般公開サイト・大規模 EC → 選択肢 3 を起点に検討
- 社内ツール・B2B 管理画面 → 選択肢 2 で Chrome 推奨ガイダンス
- Chrome 拡張・限定配布アプリ → 選択肢 1 も許容
ハイブリッド実装のサンプル — Feature Detection から始める
選択肢 2（ハイブリッド）の実装サンプルです。Chrome に Prompt API があれば使い、なければサーバーにフォールバックします。
// 1. Feature Detection
async function getLanguageModel() {
// Chrome の window.ai.languageModel を試す
if (typeof window !== 'undefined' && 'ai' in window && 'languageModel' in (window as any).ai) {
try {
const availability = await (window as any).ai.languageModel.availability();
if (availability === 'available' || availability === 'downloadable') {
return await (window as any).ai.languageModel.create();
}
} catch (e) {
// ユーザーが許可しなかった/モデル未ダウンロード等
}
}
return null;
}
// 2. クライアント側のラッパー
export async function summarize(text: string): Promise<string> {
const localModel = await getLanguageModel();
if (localModel) {
// 端末内モデルで処理（高速・無料・オフライン可）
return await localModel.prompt(`次の文章を 3 行で要約してください:\n${text}`);
}
// サーバー API にフォールバック
const res = await fetch('/api/summarize', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ text }),
});
if (!res.ok) throw new Error(`Summarize failed: ${res.status}`);
const { summary } = await res.json();
return summary;
}ポイントは getLanguageModel() でブラウザ内蔵 API を 1 度だけ確認し、結果を使い回す設計です。毎回 Feature Detection をすると、ユーザーの権限ダイアログが繰り返し出る可能性があり、UX が荒れます。
サーバー側の /api/summarize は OpenAI / Gemini / Claude のどれでも実装可能です。プロンプトをサーバーで管理することで、ブラウザ内モデルとサーバーモデルの 品質差を最小化できます（プロンプトの作り込みでサーバー側の品質を保つ）。
プログレッシブエンハンスメントの設計原則
受託でブラウザ AI 機能を組み込む際の設計原則を整理します。
| 原則 | 説明 | 実装例 |
|---|---|---|
| Core Functionality は AI 非依存 | AI が動かない環境でも基本機能は完動 | フォーム送信は AI 抜きで成立 |
| AI は “おまけ” として表現 | ”AI 提案” “AI 要約” など補助的な見せ方 | ボタンに ? アイコン + 説明 |
| 失敗時の代替を常に用意 | API 失敗時に人間向けのエラー表示 | 「もう一度試す」「サーバー版に切替」 |
| オフライン時の挙動を明記 | 端末内モデルがあるならオフラインでも動く | UI 上に “オフライン対応” バッジ |
| モデルダウンロード状態の可視化 | Gemini Nano は初回 2GB DL が必要 | ”AI 機能準備中…” の進捗表示 |
特に モデルダウンロードの状態管理は要注意です。Chrome は初回利用時に Gemini Nano（〜2GB）を裏でダウンロードしますが、回線環境によっては数十分かかります。ユーザーに進捗を見せず、無音で待たせる UX は避けるべきです。
これは Web プラットフォーム Baseline 2026 で扱った “ブラウザ機能の段階的採用” の AI 版に当たります。Baseline 入りしていない API は、プログレッシブエンハンスメント前提で取り入れるのが鉄則です。
サーバー側 LLM のコスト最適化
ハイブリッド実装でフォールバック先になるサーバー側 LLM のコスト戦略です。
| 戦略 | 内容 | コスト削減効果 |
|---|---|---|
| モデルの使い分け | 簡易処理は GPT-5.5 mini / Haiku、複雑処理のみ Opus | 70〜90% 減 |
| キャッシング | 同一プロンプトの結果を Redis / Cloudflare KV にキャッシュ | 30〜60% 減 |
| ストリーミング | レスポンスをストリームで返し、UX 改善 + 早期キャンセル可 | 体感速度 2〜3 倍 |
| エッジ推論 | Cloudflare Workers AI で東京リージョン推論 | レイテンシ半減 |
| オンプレ LLM | Granite / Gemma / DeepSeek-V4 を自前ホスティング | 大規模なら 80% 減 |
中小〜中規模の受託案件なら、「OpenAI / Anthropic API + Cloudflare Workers + Redis キャッシュ」 が最もコスパが良い構成です。月間 1〜10 万リクエスト規模で、月額 5〜30 万円程度に収まることが多いです。
これは Hono × Cloudflare Workers エッジ API ガイド で扱ったエッジ API 構成の AI 版として、そのまま延長できます。
受託で見積もるべき “AI 機能の本当のコスト”
ブラウザ AI 機能の見積もりは、初期実装費用だけ見ると失敗します。受託で必ず見るべき継続コストの内訳です。
| コスト項目 | 月額レンジ | 備考 |
|---|---|---|
| LLM API 課金（フォールバック） | 5〜30 万円 | 月間 1〜10 万リクエスト想定 |
| 監視・ログ保管 | 2〜5 万円 | プロンプト履歴保管含む |
| プロンプトの定期改善 | 5〜15 万円 | 月次で 1〜2 日工数 |
| モデル更新対応 | 3〜10 万円 | Chrome / Gemini / GPT のバージョンアップ追従 |
| インシデント対応備え | 1〜3 万円 | 保険的予備 |
初期実装に 100〜300 万円かかる AI 機能は、月額 20〜60 万円の継続コストが乗るのが現実です。受託契約時に「初期費 + 月額保守」のセットで見積もるのが、後々のトラブルを防ぎます。
受託パッケージの価格レンジ
弊社のブラウザ AI 機能受託パッケージの価格レンジです。
| パッケージ | 期間 | 価格レンジ | 主成果物 |
|---|---|---|---|
| Feature Detection 改修のみ | 2〜4 週 | 80〜200 万円 | 既存サイトの API 互換改修 |
| ハイブリッド AI 機能の新規実装 | 8〜12 週 | 400〜900 万円 | サーバー API + ブラウザ AI 連携 |
| 全面 AI 機能の受託開発 | 16〜24 週 | 1,000〜2,500 万円 | 設計 + 実装 + 監視基盤 |
| 月額運用・改善 | 月額 | 30〜100 万円/月 | プロンプト改善 + コスト最適化 + 監視 |
「AI を入れたいが、ブラウザ間互換が心配」「Chrome のみ対応で良いか迷う」というご相談は お問い合わせフォーム からお気軽にどうぞ。
まとめ — “Chrome 優位” 時代の Web 受託で取るべき姿勢
Mozilla の反対表明は、ブラウザ内蔵 AI が一枚岩で進まないことを示す象徴的な出来事でした。受託の現場では、「Chrome 限定機能を作らない / 作るなら必ずフォールバック」が基本姿勢になります。
弊社では、ブラウザ AI 機能の Feature Detection・ハイブリッド実装・継続運用までを 段階的にパッケージ化しています。プログレッシブエンハンスメント前提の堅牢な設計で、Chrome 依存にならない受託 Web 開発を支援します。「ブラウザ AI を導入したいが互換性が心配」「Chrome 専用で作ってしまったが、Firefox / Safari にも対応したい」というご相談もお気軽に お問い合わせフォーム からどうぞ。
