ブラウザー内 AI かサーバー推論か：選ぶ前にフォールバックを設計する

要点

• 推論場所は流行ではなく、対象端末、データ経路、失敗時の挙動で決める。
• Chrome の LanguageModel.availability() を4状態で扱い、非対応環境には明示的なサーバー経路を用意する。
• 両経路を同じ受け入れ条件で検証できなければ、ハイブリッド構成は結果の不整合を増やす。

二つの経路、二つの契約

Chrome Prompt API は基盤モデルをブラウザー内で動かします。Thomas Steiner と Alexandra Klepper による公式ページは 2025 年 5 月 20 日公開、2026 年 8 月 26 日更新です。モデルは各オリジンの初回利用時に別途取得され、その後はネット接続が不要で、端末内推論のデータは Google や第三者へ送信されないと説明されています。

ただし現在の対象は Windows 10/11、macOS 13 以降、Linux、Chromebook Plus で、Android、iOS、通常の Chromebook は対象外です。空き容量 22 GB 以上に加え、VRAM が厳密に 4 GB を超える GPU、または RAM 16 GB 以上・4コア以上の CPU が必要で、音声入力には GPU が要ります。これはベンダー要件であり、当サイトの実測ではありません。

サーバー経路は逆です。2026 年 4 月 21 日更新の Cloudflare Workers AI 文書では env.AI.run() でモデルを呼びます。バインディングを使うためアプリコードに API トークンは不要ですが、要求は端末外へ出てネットワークと提供者に依存します。2026 年 10 月 13 日確認の制限は、標準テキスト生成が毎分 300 リクエスト、Workers Paid 必須モデルが通常課金で毎分 20、プリペイド AI Gateway クレジットで 50 です。値は変わり得るため、拒否処理が必要です。

つまり判断基準は、その機能が欠けても成立するかです。個人的な要約は段階的に無効化できますが、決済や必須サポートで多数の端末を除外することはできません。後者は管理可能なサーバー経路、または生成機能なしが妥当です。

再利用できる能力ルーター

Chrome は availability() に実際のプロンプトと同じ言語・モダリティ条件を渡すよう求めます。

js const requirements = { expectedInputs: [{ type: "text", languages: ["en", "ja"] }], expectedOutputs: [{ type: "text", languages: ["en"] }] }; export async function chooseInference({ allowServer, online }) { if ("LanguageModel" in globalThis) { const state = await LanguageModel.availability(requirements); if (state === "available") return { path: "local", state }; if (state === "downloadable" || state === "downloading") return { path: "wait-for-user", state }; } if (allowServer && online) return { path: "server", state: "fallback" }; return { path: "none", state: "unsupported" }; }

これは自作テンプレートで、実行済み試験ではありません。wait-for-user は、Chrome が必要な取得前に利用者操作を求めるためです。表示時に勝手に取得してはいけません。サーバー側にはタイムアウト、AbortSignal、一時障害への回数制限付き再試行、レート制限表示を加え、安全でない書き込みは自動再試行しません。

分析には経路、能力状態、遅延帯、離脱を記録できますが、生の私的プロンプトは既定で保存しません。経路別の完了率が違うなら、計算コストを不整合へ移しただけです。

設計時には、フォールバックを「同じ機能の別実装」と定義します。ローカル側だけ自由文、サーバー側だけ構造化 JSON を返すような差を残すと、後段の UI と検証が二重になります。入力サイズ、出力スキーマ、タイムアウト後の表示、利用者が再試行できる回数を共通契約にします。ローカルで使えない高度な機能は、黙ってサーバーへ送るのではなく、データが端末外へ出ることを先に示して選択を求めます。

運用では「どちらが速かったか」だけでなく、「同じ仕事を完了できたか」を比較します。例えば有効な JSON、必須キー二つ、禁止語ゼロという三条件を両経路へ適用します。モデル名や端末性能が変わっても、製品側の合格条件は変えません。サーバーのレート制限時にローカルへ逆フォールバックする場合も、端末が available であり、同じ入力条件を満たすことを再確認します。

よくある誤り：真偽値だけを見る

if (LanguageModel) useLocal(); else useServer(); は不十分です。API 名の存在は、モデル準備、対象言語、端末資源を保証しません。初回が固まる、非対応端末で例外になる、説明なく取得が始まるなら、この誤りを疑います。

downloading は進捗表示、downloadable はクリック待ち、unavailable はフォールバックへ送ります。コンテキスト上限にも注意します。Chrome 文書では、満杯時に古い問答が除去され、大きすぎる要求は QuotaExceededError になります。

当てはまらない場合

固定ルール分類、索引検索、計算機で足りるなら生成 AI は不要です。全利用者に同じ挙動が必須、モデル版の固定、モバイル対応、集中ログが必要ならローカル優先は不向きです。原文を端末外へ出せず、オフライン必須で機能が任意ならサーバー優先は不向きです。医療・法律・金融・安全の判断では、実行場所に関係なく未確認の生成結果は信頼できません。

実践課題：契約を試す

LanguageModel.availability() をスタブ化し、4状態にサーバー到達可・不可を組み合わせた8ケースを実行します。成果物は、各ケースで経路が一つだけ選ばれ、未捕捉例外がゼロの表です。downloadable は利用者選択前にサーバーを呼ばず、unavailable + online + allowServer はサーバーを選ぶ、という2断言も追加します。可能なら同じ無害な3プロンプトを両経路へ渡し、「必須2キーを持つ有効な JSON」など同一条件で判定します。一つの良い回答だけで同等とは判断しません。

私たちの結論

条件付きでハイブリッドを推奨します。端末内推論は任意でプライバシー重視の補助へ使い、サーバー経路も正式機能として設計します。同じ条件で両方を試せないなら、一貫性のためサーバー専用にするか生成依存を外してください。推論場所は実装詳細で、予測可能な完了こそ製品要件です。

出典：Chrome for Developers「The Prompt API」2025-05-20公開、2026-08-26更新 ↗、Chrome for Developers「Get started with built-in AI」 ↗、Cloudflare「Workers Bindings」2026-04-21更新 ↗、Cloudflare「Limits」2026-10-13確認 ↗。