Chrome Prompt API

 (developer.chrome.com)
6 ポイント 投稿者 GN⁺ 2026-04-29 | 1件のコメント | WhatsAppで共有
  • Chrome に組み込まれた Gemini Nano モデルへ自然言語のリクエストを送るブラウザネイティブ API であり、サーバー往復なしで オンデバイス AI 推論 を実行
  • AI ベースの検索、ニュース分類によるパーソナライズドフィード、コンテンツフィルタリング、カレンダー予定の作成、連絡先の抽出など、さまざまな活用が可能
  • prompt() による 一括応答、または promptStreaming() による ReadableStream ベースの ストリーミング応答 を選択可能
  • セッションベースのコンテキスト管理、ストリーミング応答、セッションクローンなど、きめ細かなセッション制御機能 を提供
  • サーバー往復なしでブラウザ内で AI 推論が行われるため、プライバシー保護と応答遅延の最小化 に有利
  • テキストだけでなく 画像と音声入力 をサポートするマルチモーダル機能を内蔵
    • 音声: AudioBuffer, ArrayBuffer, Blob など
    • 画像: HTMLImageElement, HTMLCanvasElement, VideoFrame, Blob など
  • responseConstraint フィールドに JSON スキーマ を渡すことで、モデル出力形式を boolean や特定の JSON 構造などに制限可能
  • initialPrompts でシステムプロンプトと以前の会話コンテキストを注入し、append() によりセッション作成後でも 追加コンテキストを事前送信 可能
  • 後続の assistant メッセージに prefix: true を追加すると、モデルが 特定の形式で応答を開始 するよう誘導可能
  • セッションごとの コンテキストウィンドウ 管理をサポート: contextUsage / contextWindow でトークン使用量を確認でき、オーバーフロー時には初期の会話を自動削除（システムプロンプトは維持）
  • clone() でセッションをフォークし、destroy() でリソースを解放、AbortSignal によりセッションおよびプロンプトの 途中キャンセル が可能
  • expectedInputs / expectedOutputs により入出力形式と言語を設定可能（現在 en, ja, es をサポート）
  • ハードウェア要件: Windows 10+/macOS 13+/Linux/ChromeOS、ストレージ 22GB 以上、GPU VRAM 4GB 超または CPU RAM 16GB 以上 + 4 コア以上
  • クロスオリジン iframe には allow="language-model" 属性でアクセスを委譲可能、Web Worker では現在未対応
  • Chrome 138 からオリジントライアルとして提供中

関連記事

1件のコメント

 
GN⁺ 2026-04-29
Hacker Newsの意見

  • このAPIは、私が長いこと考えていた de-snarkifier のアイデアにぴったり合いそう
    ソーシャルメディアは知的に刺激的で学べることもあるが、望まなくても イデオロギー的な言い争い やフレームウォーに吸い込まれやすい。ネットで知らない人と感情を消耗しながら争うのは、人間資本の浪費に近い
    こういうAPIがあれば、ブラウザ拡張で投稿を表示する前に攻撃的だったり皮肉っぽかったりする表現だけを和らげて、事実情報はそのまま保てるようにできそう。さらに進めて、攻撃的なトーンであるほど滑稽だったり無能っぽく聞こえるように変えてしまうこともできるかもしれない
    そうなれば読む側は見知らぬ他人の人格攻撃から守られ、書く側も無礼に振る舞う動機がなくなる。みんながこうしたフィルターを使えば、誰がより意地悪に振る舞うかを競う理由もなくなる

    • これは文章コミュニケーション版の Soylent みたい
      栄養は全部あるけれど、味は特に面白くないという感じ
    • こういうツールには本当に期待している。インターネットの 空っぽなカロリー を取り除いて、今の人気プラットフォームの利用が大きく減る可能性がある
      私が欲しいのは、クリックベイト見出し と広告を全部消して、乾いた事実ベースの見出しだけを見せること
      どんな話題でも、核となる記事が1本と実質的なコメントがいくつかあれば十分で、残りは大半が見たくない雑音だ
      今のソーシャルメディアの状態はひどすぎてほとんど使っておらず、HNだけが例外だったが、ここもAI飽和で似た方向に進んでいるように見える。それでも隔週くらいで数時間無駄にしてしまうので、それすら完全に断ちたい
      理想を言えば、コンテンツの98%をフィルタリングするか要約して消し去り、時間が経つほどインターネットは意図的に検索するときだけ使うものになってほしい。要するにインターネットの 娯楽性 を大半取り除いて、時間とエネルギーを現実や本のような高品質なソースに振り向けたい
    • YouTubeにはすでに似たものがあり、私は DeArrow を使っている
      この拡張はクラウドソーシングで扇情性を減らそうとするツールだが、上位貢献者の一部はLLMボットかもしれないという気がしている
    • 興味深いアイデアで、探ってみる価値がありそう
      ただ、こういうものは現実にぶつかると予測不能で、うまくいったとしても最初に想像したのとはかなり違う形で動く可能性が高い
    • 私はChromeの built-in AI APIs のPMだが、この de-snarkifier のアイデアは本当に気に入ったし、関心も広そうだ
      我慢できずに Snarknada のプロトタイプを急いで作り、低レイテンシなパターンと精度の可能性を合わせて見てみた
      こういう種類のユースケースでは オンデバイス が適していると考える理由はまさにここにある。無限スクロールのフィード全体をクラウドAPIで丸めようとすると、トークンコストが開発者にとって耐えがたいほど大きくなる。しかも個人フィードやDMのトーンを整えるために第三者サーバーへ送りたくないのも当然だ
      これをデバイス内に移せば、高頻度の Semantic Mutation がコスト面でも技術面でも初めて現実的になりうる。私の遊びのようなPMプロトタイプよりもっと本格的に作って、具体的な摩擦点が出てきたらぜひ聞かせてほしい。ロードマップの優先順位付けに役立つ
      [1]: コーディングエージェント（Cursor、Claude Codeなど）を使うなら、https://www.npmjs.com/package/built-in-ai-skills-md-agent-md を参照させることを勧める。多くのモデルは今では古くなった window.ai 名前空間で学習されているので、このスキルファイルが現行APIを正しく使う助けになる

  • このAPI設計を主導し、引退前に関連する 設計上の考慮事項 を整理した記事も書いておいた
    https://domenic.me/builtin-ai-api-design/

    • 短期と長期で、このAPIの ターゲットとなるユースケース をどう見ているのか気になる
      また、こうしたものを作る際に、ブラウザ同士でW3Cレベルではなく実務的に調整して共通点を合わせようとしているのかも気になる。結局この業界はかなり狭いので
    • ご引退おめでとうございます

  • これは実際に動いていて、私はすでに local inference 用途でリリースしたことがある
    検索のような低負荷なLLM作業では、いわば貧者のollamaのように使えた。最大の利点は 無料 でプライバシーを守れ、しかもユーザーがほとんど何もしなくてよいので、非技術ユーザーにローカル推論を提供するのに向いていることだ
    ただし実際のユーザー体験は良くない。モデルのダウンロードサイズはブラウザ本体より何桁も大きく、最初のトークンを受け取る前にその過程を終えなければならない
    これはOSが事前に焼き込まれたモデルを安定して提供し、このAPIがそこにぶら下がれるようになるまでは解決が難しそうだ

    • これは Prompt API を使うすべてのサイトで共有される1回限りのダウンロードだ
      より大きな問題は、たいていの一般的なPCではモデルが小さすぎて遅すぎること。infocomテキストアドベンチャー の文章をリアルタイムで変えようとしてみたが、今は多くのPCで遅すぎて実用的ではない
    • 次の大きな流れは、いっそ 5090を複数枚 積んで売るソフトウェア購読プレミアムなのかもしれない
    • MoEモデル なら、必要なときだけ専門家レイヤーをネットワークからHTTP range queryで取得できる
      bittorrentが複数ホストからファイル断片を受け取る方式に似ている。共通レイヤーは依然として受け取る必要があるが、最初のトークンまでの時間は全体サイズではなくアクティブサイズに比例させられる
      もちろんそうなると完全なオフライン推論ではないが、ブラウザのWeb機能であればそれは中核的な考慮事項ではないかもしれない
    • OSが 事前搭載モデル を安定して入れてくれる世界が来ないことを願う
    • 本当に良い
      ただ、モデルがブラウザよりはるかに大きく、最初のトークンの前にダウンロードが必要なら、これが 遅延ダウンロード を意味するのか気になる。最初に呼び出すユーザーはその場でダウンロードが終わるまで待たされるという話なら、ユーザー体験はかなりひどそうだ
      Chromeがダウンロード状態ダイアログのようなものを表示して混乱を減らすのか、またディスク使用量がどの程度なのかも知りたい

  • 見たところ、これは Gemini Nano を使っているようだが、最新の Gemma 4 E2B/E4B のほうがずっと良さそうなので、当面は拡張として量子化版を配布するほうがよいかもしれない

    • Gemini Nano-1: 46% MMLU, 1.8B
    • Gemini Nano-2: 56% MMLU, 3.25B
    • Gemma4 E2B: 60.0% MMLU, 2.3B
    • Gemma4 E4B: 69.4% MMLU, 4.5B
      出典:
    • https://huggingface.co/google/gemma-4-E2B-it
    • https://android-developers.googleblog.com/2024/10/gemini-nano-experimental-access-available-on-android.html
    • 今は内部事情を知らないが、私がこのチームにいた頃は最新の 小型Googleモデル をChromeに非常に速く入れていた
      Gemma 4やそれに対応するGemini NanoがまだChromeにないなら、すぐ入ると予想する
      そしてこの記事は2025-09-21に最後に更新されており、その時点ではすでに Gemini Nano 3 だった
    • その通り
      Prompt APIは、ブラウザ内の Gemini Nano に自然言語のリクエストを送る仕組みだと書かれている
    • Prompt APIはブラウザで利用可能なモデルを使う
      Edgeではおそらく Phi4 だろう

  • これは悪意ある JSスクリプト が何も知らない訪問者にトークン生成を押し付けるための良い手段にも見える
    より大きなプロンプトを細かく分割して複数のブラウザに送り、それぞれが小さな断片だけを処理する subagentパターン やRLMに似た構造で有用な結果を生むような分散化が可能かどうかも興味深い

    • 見返りに対して仕事が大きすぎるように見える
      技術的・事業的インフラも非常に複雑になるだろうし、わざわざユーザーのブラウザにプロンプトを押し付けたいなら、単に Chrome API をきちんと使うほうがよいのではないかと思う。こうした低性能モデルにサーバー側のプロンプトをオフロードして実際に有意義になるケースがどれほどあるのかも疑わしい
      しかも本当にそうしたいなら WebGPU もずっと前からあった
    • 小さなモデル のトークン生成程度にはほとんど価値がない

  • これはまともな Model API への一歩のように見えるが、まだ小さな一歩にすぎない
    Appleの Foundation Models も思い出される
    多くのAI統合はテキストコミュニケーションやチャットスタイルに集中しているが、実際には非テキストなインターフェースで恩恵を受けるソフトウェアも多い
    結局のところ、OSとブラウザがモデルを管理するAPIを提供し、アプリが単純なインターフェースでオンデバイスモデルとリモートモデルにアクセスできるようになるべきだと思う
    これがクロスプラットフォームで標準化されれば本当に良いし、モバイルまで含める必要があるので、現実的に強く押し進められるのは主にAppleとGoogleだろう。Metaが後に続くか、逆に先に動くかもしれないが
    要は 特定の宣伝用モデル専用 であってはならないということだ
    アプリは問い合わせて適切なモデルを選んで使えるべきだ
    (1) https://developer.apple.com/documentation/foundationmodels

    • Appleの Foundation Models は文書上は良く見えるが、実際には 4kコンテキストウィンドウ が引っかかる
      もちろんまだ初期段階ではあるが

  • https://github.com/mozilla/standards-positions/issues/1067

  • 私たちはこれを ハックデイの振り返り要約 に使っている
    https://remotehack.space/previous-hacks/
    RSSフィードを読み、本分向けの要約を生成する小さなスクリプトだが、静的サイトとかなり相性が良い。いつかは同じコンテンツに対して別の質問も投げられるように拡張したい

  • ブラウザからアクセス可能な ローカルLLM はプライバシー面では良いが、ブラウザごとにこのAPIの裏で動くモデルが違うなら、テストの悪夢は今よりひどくなりそうだ
    結局ほとんどの実装が Gemini Nano 基準に合わせられる可能性があり、それがユーザーをさらにChrome側へ引き寄せるのかも気になる

    • テスト 断片化 が本当に中核的な問題だ
      実際、プロンプトはモデル非依存ではないので、Gemini Nano 3 v2025向けに精密に調整したプロンプトがGecko側のモデルでは静かに性能低下する可能性がある。しかもAPIは分岐のための 能力検出 すら提供しない
      これは少なくとも拡張サポートの有無を問い合わせられたWebGLより悪い。名前もバージョンもブラウザの背後に隠れたモデルのプロンプト品質に依存して機能をリリースするのは、ユーザーがインストールした辞書しだいで機能が左右されるソフトウェアを出すようなものだ

  • Gemini Nano はGemmaと違ってオープンウェイトではないのではないかと思う
    誰かがすでにやっていれば別だが、モデルの重みをダンプしてみたい