ハクソク

世界を動かす技術を、日本語で。

プロンプトAPI

13日前原文(developer.chrome.com)

概要

Prompt API は、 Gemini Nano を利用してChromeブラウザ内で自然言語処理を実現するAPI。 多様な用途 （AI検索、ニュース分類、コンテンツフィルター等）に活用可能。 対応OSやハードウェア要件 に注意が必要。 拡張機能開発 や マルチモーダル入力 もサポート。 JSON Schema による出力制約やセッション管理も可能。

Prompt APIの概要と用途

  • Prompt API は、 Gemini Nano を活用し、ブラウザ内で自然言語リクエストを処理するAPI
  • AI検索 ：Webページ内容に基づく質問応答の実装
  • パーソナライズニュースフィード ：記事自動分類とユーザーによるフィルタリング
  • カスタムコンテンツフィルター ：ユーザー定義トピックに基づく記事の自動ぼかしや非表示
  • カレンダーイベント作成 ：Webページからイベント情報抽出し、カレンダー登録支援
  • 連絡先抽出 ：Webサイトから連絡先情報を抽出し、リスト化を支援
  • 拡張機能開発 や新しいAI体験の創出

ハードウェア・ソフトウェア要件

  • 対応OS ：Windows 10/11、macOS 13+ (Ventura以降)、Linux、ChromeOS（Chromebook Plusのみ）
  • 非対応 ：Chrome for Android/iOS、Chromebook Plus以外のChromeOS
  • ストレージ ：Chromeプロファイルがあるボリュームに22GB以上の空き容量
  • GPU/CPU要件 ：
    • GPU ：4GB超のVRAM必須（音声入力利用時はGPU必須）
    • CPU ：16GB以上のRAM、4コア以上
  • ネットワーク ：無制限または非課金の接続
  • モデルサイズ確認 ：chrome://on-device-internalsで確認可能

利用開始手順とAPIの基本

  • モデルのダウンロード ：初回利用時に自動ダウンロード
  • 利用前に ：Googleの生成AI禁止事項ポリシーの承認が必要
  • 利用可否確認 ：LanguageModel.availability()で利用可能か判定
  • セッション作成 ：LanguageModel.create()で新規セッション開始
    • ダウンロード進捗 ：downloadprogressイベントで進行状況を取得し、ユーザーに通知
  • ローカル環境での利用 ：Chromeのフラグを有効化（chrome://flags/#optimization-guide-on-device-model, chrome://flags/#prompt-api-for-gemini-nano-multimodal-input）

モデルパラメータとセッション管理

  • パラメータ取得 ：LanguageModel.params()でtopKやtemperatureのデフォルト値・最大値を取得
  • 拡張機能用セッション ：topKやtemperatureを個別に指定可能
  • AbortSignalによる中断 ：signalフィールドでセッションの中断制御
  • 初期プロンプト ：initialPromptsで過去の対話履歴や文脈を付与

応答制約・マルチモーダル対応

  • 応答制約 ：prefix: trueで特定形式の応答を誘導
  • 期待する入出力形式の指定 ：expectedInputs/expectedOutputsでテキスト・画像・音声など指定
    • 対応言語 ：「en」「ja」「es」（今後追加予定）
  • マルチモーダル ：画像・音声・テキストを組み合わせたプロンプトも可能
    • 例：画像比較、音声応答、画像説明生成

append・JSON Schemaによる応答制御

  • append() ：セッション作成後にも追加プロンプトを投入し、文脈追加が可能
  • JSON Schema ：responseConstraintで応答形式（例：boolean）を厳密指定
    • 正規表現やJSON Schema を利用した構造化出力
    • context window の消費量測定も可能

エラー・トラブルシューティング

  • NotSupportedError ：未対応の入力や出力指定時に発生
  • localhostでのエラー ：フラグ設定やChrome再起動で解決を試みる

今後の展望

  • 対応言語や機能の拡充 予定
  • 新しいChrome拡張機能やAI体験 への応用拡大

Prompt API は、 Chrome拡張機能開発 や Webアプリ において、 高度なAI機能 を手軽に実装できる強力なツール。 ハードウェア要件やAPI仕様 を確認し、 多様なユースケース に活用可能。

Hackerたちの意見

これ、ちゃんと動くよ。「ローカル推論」って感じで、低スペックなLLMタスク、例えば検索とかに使える貧乏人向けのollamaみたいなもんだ。最大の利点は無料でプライバシーも守られるし、ユーザーには特に何もさせなくていいから、技術に詳しくない人にもローカル推論を提供できるのがいいね。ただ、実際のユーザー体験はあんまり良くない。モデルのダウンロードがブラウザそのものをダウンロードするよりも桁違いに大きいし、最初のトークンが返ってくる前にそれをやらなきゃいけないからね。これを解決するには、OSが自分たちのプリベイクモデルを安定して提供し始めないと無理だと思う。

└

これを解決するには、OSが自分たちのプリベイクモデルを安定して提供し始めないと無理だと思う。次の大きなトレンドは、5090を特典として含むソフトウェアのサブスクリプションプレミアムオファーかもね。

└

これ、ちゃんと動くよ。「ローカル推論」って感じで、低スペックなLLMタスク、例えば検索とかに使える貧乏人向けのollamaみたいなもんだ。すごいね！ > モデルのダウンロードがブラウザそのものをダウンロードするよりも桁違いに大きいし、最初のトークンが返ってくる前にそれをやらなきゃいけない。確かに、これってモデルが遅れてダウンロードされるってこと？つまり、これを使った場合、初めてモデルが呼ばれるときにユーザーはモデルがダウンロードされるまで待たされるってこと？それ、ひどいユーザー体験だね。もしかしたら、Chromeはダウンロードダイアログのステータスを表示することで混乱を減らすかも？あと、ディスク上の影響ってどんな感じ？

└

オペレーティングシステムが自分たちのプリベイクされたモデルを確実に出荷し始める そんなディストピアが決して起こらないことを願ってる。

└

でも実際のユーザー体験はあまり良くないことを忘れないでね。モデルのダウンロードはブラウザ自体をダウンロードするよりも桁違いに大きいし、最初のトークンを受け取る前にそれが必要なんだ。MoEモデルを使えば、HTTPレンジクエリを発行してネットワークから専門的なレイヤーをオンデマンドで取得できるから、bittorrentが複数のホストからファイルのチャンクをダウンロードするのと似てる。共有レイヤーはダウンロードしなきゃいけないけど、最初のトークンを得るまでの時間は総サイズではなくアクティブサイズに比例することになる。もちろん、これでは完全に「オフライン」の推論にはならないけど、ウェブブラウザの機能としてはそれほど重要な考慮事項ではないよ。

└

実際にプライバシーを守ってるの？Chromeは基本的に、ユーザーからできるだけ多くの情報を引き出すために存在してるけど、広告や軍事契約などで得られる利益よりも大きな罰則の訴訟を避けるためにね。Androidもあまり変わらないよ。これに代わるものがあれば歓迎だな。例えば「デバイスが休止中で充電中の間に、ユーザーの最近のテキスト通信を要約する」とか、盗聴法の法的抜け道としてのアプリケーションが考えられる。

└

これは、プロンプトAPIを使ってる全てのウェブサイトで共有される一度きりのダウンロードなんだ。もっと大きな問題は、ほとんどの標準PCのモデルが小さくて遅いってこと。プロンプトAPIを使って、（インフォコムの）テキストアドベンチャーのテキストをリアルタイムで変更しようと思ってたけど、今のところ多くのPCでは遅すぎて実用的じゃないね。

悪意のあるJSスクリプトが、トークン生成を無防備な訪問者にオフロードするのにはいい方法かもね。大きなプロンプトを分解して、サブエージェントパターンやRLMみたいなもので複数のブラウザに送信して、役立つものを生成できるかどうか見てみるのも面白そう。

└

これ、リターンが少ないのにやることが多すぎる感じ。技術的・ビジネス的なインフラはすごいことになりそうだし。もし誰かがプロンプトをユーザーのブラウザにオフロードしたいなら、Chrome APIを正しく使えばいいんじゃない？この低スペックモデルにオフロードするのが現実的に役立つサーバーサイドのプロンプトってどれくらいあるんだろう？それに、やりたいならWebGPUもあるし、しばらく前からあるよね？

└

小さいモデルのトークン生成。ほとんど価値がないよ。

このAPI、前から考えてたアイデアにぴったりかも：ソーシャルメディア用のデスナークファイア。ソーシャルメディアは知的に刺激的で教育的だけど、イデオロギーの攻撃や炎上に巻き込まれるのも簡単だよね。ネットで知らない人に対して炎上するために使う感情的・知的エネルギーは、完全に無駄な人材資本だと思う。こういうAPIがあれば、ブラウザ拡張機能でコンテンツを表示する前にデスナークファイアできるんじゃないかな。投稿の事実関係はそのままにして、攻撃的な言葉や皮肉を取り除くようにLLMに頼むことができる。もし本当に楽しみたいなら、攻撃的なトーンで書かれたものを、滑稽か無能に聞こえるように変えるように頼むこともできる。そうすれば、投稿が攻撃的であればあるほど、作者がバカに見えるってわけ。これには二重の利点があると思う。読者にとっては、ネット上の知らない人からの個人的な攻撃から守られるし。もちろん、重要な問題について本気で議論する時は必要だけど、知らない人とその議論をすることに得られるものは少ないと思う。逆に、知らない人同士が叫び合うのは政治的に有害だと思う。書き手にとっては、皮肉や失礼なことを言うインセンティブがなくなる。もし他の人がこうやってコンテンツをフィルタリングするなら、彼らに対して意地悪しようとしても意味がないし、誰が一番悪口を言えるかの「底辺争い」もなくなる。

└

逆に、全てのコメントが同じように聞こえて、ネットコンテンツが平均的なスラップにさらに希薄化されちゃうかも。

└

これは書き言葉のソイレントだね。特に特徴のない味だけど、栄養価は満点。

└

このアイデアは嫌いだけど、学校の「安全な場所」みたいな使い方では人気が出るかもしれないね。

└

探索する価値のある面白いアイデアだと思う。でも…現実と接触すると予測不可能なタイプのアイデアだよね。もしうまくいったとしても、最初のアイデアとは全然違う形で機能すると思う。

└

YouTubeではすでにこれが存在していて、俺も使ってるよ。その拡張機能はDeArrowって言って、クラウドソーシングでセンセーショナリズムを減らすことを目指してる。ただ、トップの貢献者がLLMを使ってるボットだったとしても驚かないけどね。

└

こういうのが出てくるのをちょっと楽しみにしてる。インターネットから無駄なジャンクカロリーを取り除く可能性があるから、今日の人気プラットフォームの使用が大幅に減ることを期待してる。私の希望リスト: - すべてのクリックベイトタイトルと広告を排除したい。ドライな事実のタイトルだけ見たい。 - どんなトピックでも、メインの記事（高品質なブログでない限り要約だけを見るオプション付き）といくつかの実質的なコメントだけが欲しい。残りは見たくないジャンク。今の人気ソーシャルメディアの状態では、全く使ってない（HNはAIの飽和で同じ方向に向かってるから使ってるけど）。でも、毎週のように数時間無駄にしてしまうのは避けたい。理想的には、98%のコンテンツがフィルタリング/要約されて、時間が経つにつれて意図を持って調べ物をするためだけにインターネットを使いたい。これがインターネットから「エンターテインメント」の価値を大半排除して、リアルライフや高品質な情報源（本）にエネルギーを再集中させたい。

└

それを無視するか、[条件]の下では関わらないって言えばいいよ。結局、AIが何かを間違って書き換えたときに、あなたが言ってないことに関わってしまって、バカみたいになるのはあなただからね。

└

ただし、嫌悪感を抱くような、差別的または扇動的な言葉を知的に扱うのは重要じゃない。それが何を目指しているのか、きちんと指摘されるべきだよ。

└

そしたら、現実をもっと理解できるようになるね。テックジャイアンツに他の人が何を表現しているか教えてもらうだけで。いいアイデアだね。

└

こんなアプリがあったらいいな。ニュース用にhttps://www.boringreport.org/をよく使ってるけど、あなたが言ってることに似たことをニュース記事に対してやってるんだ。

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

└

参照: https://github.com/mozilla/standards-positions/issues/1213

これは正しいモデルAPIの未来への一歩だと思う。ただの小さな一歩だけどね。Appleのファウンデーションモデルを思い出すな。多くのAI統合がテキストコミュニケーションやチャットスタイルに焦点を当ててるけど、たくさんのソフトウェアは非テキストインターフェースから恩恵を受けるんだ。OSやブラウザがモデルを管理するためのAPIを提供するべきだと思う。そうすれば、アプリ用の簡素化されたインターフェースでデバイス内やリモートのモデルにアクセスできるようになる。クロスプラットフォームで標準化されたものができたら素晴らしいね。モバイルデバイスでも必要だから、実現しやすいのは主にAppleとGoogleだと思う。（Metaも追随するか、逆に行くかもね）重要なポイントは、プロモートされたモデルに限定されるべきじゃないってこと。（1）https://developer.apple.com/documentation/foundationmodels だから、アプリは適切なモデルを問い合わせて取得できるようになるんだ。

└

Appleのファウンデーションモデルは、4kのコンテキストウィンドウを見るまでは素晴らしいと思えるけどね。（まだこの章の初めだってことは分かってるけど。）

俺はこのAPIのデザインを主導してたんだ、引退する前にね。これに関する考慮事項についての俺のまとめがここにあるよ: https://domenic.me/builtin-ai-api-design/

└

短期的および長期的な使用ターゲットをどう考えてる？こういうことをする時に、他のブラウザとコミュニケーションを取って共通のものに落ち着こうとしてるの？W3Cのことを言ってるんじゃなくて、実際には小さな世界だから。

└

退職おめでとう！

これを使ってハックデイのまとめを書いてるよ: https://remotehack.space/previous-hacks/ RSSフィードを調べて、その内容を使って要約を生成する小さなスクリプトなんだ。静的サイトにぴったりだよ。いつか、内容についていろんな質問をするように拡張したいな。

これ、裏ではGemini Nanoを使ってるっぽいね。でも最新のGemma4 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-nan...

└

もう内部情報は持ってないけど、このチームにいたときは、最新の小さい（Googleの）モデルをChromeにすぐ入れるのが早かったよ。もしGemma 4（またはそれに相当するGemini Nano）がまだChromeに入ってないなら、すぐに入ると思う。この記事は2025年9月21日に更新されたけど、その時点で既にGemini Nano 3が入ってたみたい。

└

これはGemini Nanoを裏で使ってるみたいだね。うん、「プロンプトAPIを使えば、ブラウザでGemini Nanoに自然言語リクエストを送ることができるよ。」

└

プロンプトAPIは、ブラウザで利用可能なモデルを使ってるよ。Edgeだと、Phi4だと思う。

プライバシーを考慮したローカルLLMがブラウザで使えるっていうアイデアはいいと思うけど、各ブラウザが異なるモデルをこのAPIに結びつけると、テストが今よりもさらに悪夢になるんじゃないかな。これが多くのユーザーをChromeに引き寄せる原因になるのかな？大半のAPIの使い方がGemini Nanoモデルに合わせて調整されてるかもしれないし。

└

@tom1337 テストの断片化がここでの本当の問題だよ。プロンプトは実際にはモデルに依存してるから、Gemini Nano 3 v2025用に調整されたプロンプトは、Geckoが出すものでは静かに劣化しちゃうし、APIには分岐するための能力の内省がないんだ。これは、少なくとも拡張機能のサポートを問い合わせられたWebGLの状況よりも悪いよ。名前のない、バージョンがブラウザの後ろにあるモデルに対してプロンプトの質に依存する機能を出すのは、ユーザーがインストールしている辞書に依存する機能を出すのに近いね。

これ、Firefoxとか他のブラウザでもすぐにサポートされる可能性あるかな？