プロンプト API
(developer.chrome.com)- Chrome に組み込まれた Gemini Nano に自然言語のリクエストを送る Web API で、質疑応答・分類・コンテンツフィルタリング・予定抽出・連絡先抽出のような作業に活用できる
- 利用前には 別途モデルのダウンロード が必要で、対応 OS・ストレージ容量・GPU または CPU メモリなどの 実行条件 を満たしている場合にのみ動作する
- セッションは
LanguageModel.availability()で利用可能かを確認したあとcreate()で準備し、initialPrompts・append()・clone()でコンテキストを引き継いだり分岐させたりできる - 入力は text, image, audio を受け取れ、出力は現在 text のみをサポートし、
prompt()は完成した応答を、promptStreaming()はストリーミング応答を返す responseConstraintベースの 構造化出力、コンテキストウィンドウ管理、権限ポリシー、マルチモーダル処理まで含め、ブラウザ内でオンデバイス AI を扱う実行モデルを提供する
概要
- Chrome 内蔵の Gemini Nano に自然言語のリクエストを送る API として動作し、Web ページベースの質疑応答・記事分類・コンテンツフィルタリング・予定抽出・連絡先抽出といった活用が可能
- モデルは Chrome に API が組み込まれていても 別途ダウンロード が必要で、初回利用前には Google の Generative AI Prohibited Uses Policy を確認する必要がある
- 生成 AI の利用前には People + AI Guidebook の参照が推奨される
- TypeScript の型定義は @types/dom-chromium-ai パッケージで取得できる
- Chrome Extensions 開発者は、期限切れの origin trial 権限
aiLanguageModelOriginTrialを削除する必要がある
ハードウェアと実行条件
- Prompt API・Summarizer API・Writer API・Rewriter API・Proofreader API は、Chrome で特定条件を満たした場合に動作する
- 対応 OS は Windows 10/11、macOS 13+、Linux、ChromeOS で、ChromeOS は Chromebook Plus デバイスで Platform 16389.0.0 以上の場合に対応する
- Chrome for Android、iOS、Chromebook Plus ではないデバイスの ChromeOS は、Gemini Nano ベースの API をまだサポートしていない
- ストレージは Chrome プロファイルがあるボリュームに 最低 22GB の空き容量 が必要
- モデル実行は GPU または CPU で可能
- GPU には 4GB 超の VRAM が必要
- CPU には 16GB 以上の RAM と 4 コア以上の CPU が必要
- オーディオ入力を使う Prompt API には GPU が必要
- ネットワークは初回モデルダウンロード時のみ 無制限または従量課金ではない 接続が必要
- その後のモデル利用にはネットワーク接続は不要
- モデル利用時、データは Google や第三者へ送信されない
- モデルサイズはブラウザ更新に応じて変わる場合があり、現在のサイズは
chrome://on-device-internalsで確認できる - ダウンロード後に空き容量が 10GB 未満 になるとモデルはデバイスから削除され、再び条件を満たせば再ダウンロードされる
利用開始とモデル準備
- 利用可否は
LanguageModel.availability()で確認できる availability()には、その後prompt()またはpromptStreaming()に渡すものと 同じオプション を渡す必要がある- 一部モデルは特定のモダリティや言語をサポートしない場合があるため、オプション一致が重要
- モデルのダウンロードとセッション作成は user activation を確認したうえで
create()から開始する - ダウンロード中であれば進捗イベントを受け取り、ユーザーにダウンロード状況を知らせるべき
- localhost では Chrome フラグを有効にすると組み込み AI API を利用できる
chrome://flags/#optimization-guide-on-device-modelchrome://flags/#prompt-api-for-gemini-nano-multimodal-input- その後、Relaunch または Chrome の再起動が必要
- エラーが出る場合は localhost トラブルシューティング を参照できる
セッション作成と基本設定
- セッションは
LanguageModel.create()で作成される - Chrome Extensions 向け Prompt API では、セッションごとに topK と temperature をオプションで調整できる
- デフォルト値と最大値は
LanguageModel.params()で確認できる - この機能は Chrome Extensions または sampling parameters origin trial 利用時にのみ適用される
- デフォルト値と最大値は
params()はdefaultTopK,maxTopK,defaultTemperature,maxTemperatureを返す- 新しいセッション初期化時に
topKとtemperatureは 両方指定するか、両方省略するか にしなければならない create()はsignalフィールドでAbortSignalを受け取り、セッションを中断できる
コンテキストとプロンプト構成
initialPromptsで以前の会話コンテキストを入れることで、ブラウザ再起動後に保存されたセッションを引き継げる- プロンプト配列には
system,user,assistantの役割を一緒に入れられる - 最後の
assistantメッセージにprefix: trueを付けると、応答の一部を 事前に埋めて 特定の出力形式を誘導できる- 例として TOML コードブロック開始文字列をあらかじめ入れ、出力形式を固定する
- セッション作成後は
append()で追加コンテキストを事前投入できるinitialPromptsと異なり、セッション作成後もコンテキストを蓄積できるappend()はプロンプトが検証・処理・追加されたあとに履行される- 追加できないプロンプトであれば promise は reject される
入出力モダリティと言語対応
- セッション作成時に
expectedInputsとexpectedOutputsで 想定される入出力形式と言語 を設定できる expectedInputsのtypeはtext,image,audioをサポートするexpectedOutputsのtypeは現在 text のみ許可 されている- 言語は
languages配列で設定し、Prompt API は"en","ja","es"を受け付ける- 追加言語のサポートは開発中
- 入力側には system prompt の言語と 1 つ以上の user prompt 言語を入れられる
- 出力側には 1 つ以上の出力言語を入れられる
- サポートされない入力または出力に遭遇すると
"NotSupportedError"DOMException が発生する場合がある
マルチモーダル入力
- 音声文字起こし や画像説明・キャプション・alt text 生成のような用途に活用できる
- 関連デモ
- 音声入力は次の型をサポートする
- 視覚入力は次の型をサポートする
- 例では画像
BlobとHTMLCanvasElementを一緒に渡して 2 つの視覚資料を比較させ、その後AudioBufferでユーザーの音声応答を受け取らせている
構造化出力と制約
prompt()またはpromptStreaming()のresponseConstraintに JSON Schema を入れることで構造化出力を利用できる- 関連機能は structured output で確認できる
- 例では boolean スキーマを入れ、投稿が陶芸関連かどうかに
trueまたはfalseのみで答えさせている - 実装時には JSON Schema や正規表現をメッセージの一部として一緒に入れることもでき、その場合は context window の一部を使用する
session.measureContextUsage()にresponseConstraintオプションを渡すと、制約条件がコンテキストをどの程度使うか測定できるomitResponseConstraintInputオプションを使うとこの動作を避けられる- この場合は、プロンプト内に望ましい出力形式の案内を一緒に入れることが推奨される
プロンプト実行方式
- 短い応答が想定される場合は
prompt()を使って 完成した結果 を一度に受け取れる - 長い応答が想定される場合は
promptStreaming()を使って 部分結果をストリーミング で受け取れる promptStreaming()はReadableStreamを返すprompt()とpromptStreaming()はどちらも第 2 引数でsignalを受け取り、実行中のプロンプトを中断できる
セッション管理
- 各セッションは会話の コンテキスト を保持し、以前のやり取りが後続の応答に反映される
- 各セッションには処理可能な最大トークン数があり、
session.contextUsageとsession.contextWindowで現在の使用量と上限を確認できる - 新しいプロンプトでコンテキストウィンドウを超える場合、システムプロンプトを除いた会話の先頭部分が 質問・応答ペア単位 で削除され、空き領域を確保する
- こうした状況はセッションの
contextoverflowイベントで検知できる - 会話履歴を削除しても十分なトークンを確保できない場合、
prompt()またはpromptStreaming()は QuotaExceededError で失敗し、何も削除されないrequested: 入力が占めたトークン数contextWindow: 利用可能だったトークン数
- 詳細は session management を参照できる
セッション複製と終了
clone()で既存セッションをコピーし、会話の分岐 を作れる- 複製されたセッションは既存コンテキストと初期プロンプトを保持する
clone()もsignalフィールドでAbortSignalを受け取れる- セッションが不要になったら
destroy()でリソースを解放できる - セッションが破棄されると以後は利用できず、進行中の実行も中断される
- セッション作成には時間がかかることがあるため、頻繁にプロンプトを送る予定ならセッションを維持したほうがよい場合がある
権限ポリシーと実行環境の制約
- デフォルトでは Prompt API は 最上位 window と同一 origin の iframe でのみ利用できる
- cross-origin iframe には Permission Policy の
allow="language-model"属性でアクセス権を委譲できる - 現在 Prompt API は Web Workers では利用できない
- 各 worker ごとに permissions policy の状態を確認する責任ドキュメントを定めるのが複雑なため
デモと参考資料
- Web アプリケーションのデモ
- Chrome Extensions テスト用のデモ拡張機能も提供されている
パフォーマンスとフィードバック
- Web 向け Prompt API はまだ 開発進行中
- 最適なパフォーマンスのために session management のベストプラクティスを参照するのがよい
- 実装フィードバックの窓口
1件のコメント
Hacker Newsの意見
このAPIは、私が長いこと考えていた de-snarkifier のアイデアにぴったり合いそう
ソーシャルメディアは知的に刺激的で学べることもあるが、望まなくても イデオロギー的な言い争い やフレームウォーに吸い込まれやすい。ネットで知らない人と感情を消耗しながら争うのは、人間資本の浪費に近い
こういうAPIがあれば、ブラウザ拡張で投稿を表示する前に攻撃的だったり皮肉っぽかったりする表現だけを和らげて、事実情報はそのまま保てるようにできそう。さらに進めて、攻撃的なトーンであるほど滑稽だったり無能っぽく聞こえるように変えてしまうこともできるかもしれない
そうなれば読む側は見知らぬ他人の人格攻撃から守られ、書く側も無礼に振る舞う動機がなくなる。みんながこうしたフィルターを使えば、誰がより意地悪に振る舞うかを競う理由もなくなる
栄養は全部あるけれど、味は特に面白くないという感じ
私が欲しいのは、クリックベイト見出し と広告を全部消して、乾いた事実ベースの見出しだけを見せること
どんな話題でも、核となる記事が1本と実質的なコメントがいくつかあれば十分で、残りは大半が見たくない雑音だ
今のソーシャルメディアの状態はひどすぎてほとんど使っておらず、HNだけが例外だったが、ここもAI飽和で似た方向に進んでいるように見える。それでも隔週くらいで数時間無駄にしてしまうので、それすら完全に断ちたい
理想を言えば、コンテンツの98%をフィルタリングするか要約して消し去り、時間が経つほどインターネットは意図的に検索するときだけ使うものになってほしい。要するにインターネットの 娯楽性 を大半取り除いて、時間とエネルギーを現実や本のような高品質なソースに振り向けたい
この拡張はクラウドソーシングで扇情性を減らそうとするツールだが、上位貢献者の一部はLLMボットかもしれないという気がしている
ただ、こういうものは現実にぶつかると予測不能で、うまくいったとしても最初に想像したのとはかなり違う形で動く可能性が高い
我慢できずに 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/
また、こうしたものを作る際に、ブラウザ同士でW3Cレベルではなく実務的に調整して共通点を合わせようとしているのかも気になる。結局この業界はかなり狭いので
これは実際に動いていて、私はすでに local inference 用途でリリースしたことがある
検索のような低負荷なLLM作業では、いわば貧者のollamaのように使えた。最大の利点は 無料 でプライバシーを守れ、しかもユーザーがほとんど何もしなくてよいので、非技術ユーザーにローカル推論を提供するのに向いていることだ
ただし実際のユーザー体験は良くない。モデルのダウンロードサイズはブラウザ本体より何桁も大きく、最初のトークンを受け取る前にその過程を終えなければならない
これはOSが事前に焼き込まれたモデルを安定して提供し、このAPIがそこにぶら下がれるようになるまでは解決が難しそうだ
より大きな問題は、たいていの一般的なPCではモデルが小さすぎて遅すぎること。infocomテキストアドベンチャー の文章をリアルタイムで変えようとしてみたが、今は多くのPCで遅すぎて実用的ではない
bittorrentが複数ホストからファイル断片を受け取る方式に似ている。共通レイヤーは依然として受け取る必要があるが、最初のトークンまでの時間は全体サイズではなくアクティブサイズに比例させられる
もちろんそうなると完全なオフライン推論ではないが、ブラウザのWeb機能であればそれは中核的な考慮事項ではないかもしれない
ただ、モデルがブラウザよりはるかに大きく、最初のトークンの前にダウンロードが必要なら、これが 遅延ダウンロード を意味するのか気になる。最初に呼び出すユーザーはその場でダウンロードが終わるまで待たされるという話なら、ユーザー体験はかなりひどそうだ
Chromeがダウンロード状態ダイアログのようなものを表示して混乱を減らすのか、またディスク使用量がどの程度なのかも知りたい
見たところ、これは Gemini Nano を使っているようだが、最新の Gemma 4 E2B/E4B のほうがずっと良さそうなので、当面は拡張として量子化版を配布するほうがよいかもしれない
出典:
Gemma 4やそれに対応するGemini NanoがまだChromeにないなら、すぐ入ると予想する
そしてこの記事は2025-09-21に最後に更新されており、その時点ではすでに Gemini Nano 3 だった
Prompt APIは、ブラウザ内の Gemini Nano に自然言語のリクエストを送る仕組みだと書かれている
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
もちろんまだ初期段階ではあるが
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と違ってオープンウェイトではないのではないかと思う
誰かがすでにやっていれば別だが、モデルの重みをダンプしてみたい