Chrome Built-in AIとは？7つのAPIの提供状況・動作要件と実装手順

Chrome Built-in AIは、Chromeが端末に取得して管理するAIモデルを、JavaScriptから直接呼び出すためのWeb API群です。推論は端末上で完結するので、入力したテキストがGoogleや第三者のサーバーに送られることはありません。ただし7つのAPIの出荷段階はそろっていません。安定版でそのまま動くAPIと、ユーザーがフラグを立てない限り存在しないAPIが混在しています。動作要件も一律ではなく、22GBの空き容量を求めるAPIと求めないAPIがあります。この記事は2026年11月1日時点の公式ドキュメントとChromeのソースを照合し、安定版Chrome 156を基準に、どのAPIを本番に載せてよいかを判断できるところまで整理します。

まとめ

翻訳・言語判定・要約の3つはChrome 138で出荷済みです。汎用のPrompt APIも、拡張機能ではChrome 138、通常のWebページではChrome 148で出荷されました。安定版は156なので、この4つはオリジントライアルの登録もフラグ操作もなしで呼び出せます。Writer・Rewriter・Proofreaderの3つは、オリジントライアルが終わったあとDeveloper trialに戻っており、本番の設計には入れられません。

要件で迷いやすいのは、空き容量22GB以上と、GPU実行またはCPU実行の条件がかかる範囲です。対象は言語モデルを使う5つのAPIだけで、Translator APIとLanguage Detector APIはデスクトップなら端末スペックで弾かれません。もう一つ見落とされやすいのが、モデルはセッションの途中でも削除されうるという仕様です。さらにFirefoxとSafariの開発元はPrompt APIに反対の立場を表明しています。どのAPIを使う場合でも、機能検出とフォールバックを前提に設計してください。

Chrome Built-in AIの7つのAPIと提供状況（Chrome 156時点）

Built-in AIは単一のAPIではなく、用途別に分かれた7つのAPIの総称です。どれもSummarizerやTranslatorのようなグローバルクラスとして公開されています。availability()で可否を確かめ、create()でインスタンスを作るという手順はすべてのAPIで共通です。

提供状況の一覧｜出荷済みとDeveloper trialの読み分け

Chrome for Developersの組み込みAI APIの可用性表を原文で照合すると、同じAPIでもWebページと拡張機能で段階が違うものがあります。表の数字は、そのAPIが出荷されたChromeのバージョンです。

Writer APIとRewriter APIは、Chrome 137から148まで共同のオリジントライアルを実施していました。Proofreader APIはChrome 141から145です。どちらも期間が終わり、出荷されないままDeveloper trialに戻りました。オリジントライアルでは有効なトークンを配信すると対応ブラウザの利用者が試せますが、端末要件や試験の利用制限は残ります。Developer trialにはトークンによる有効化の手段がありません。ユーザー自身がchrome://flagsを操作しない限り、大半の利用者の環境にはクラス自体がありません。この状態で直接呼び出すとunavailableではなく参照エラーになるので、先にクラスの存在を確認します。この3つは社内での検証に限ってください。

Prompt APIがWebに載った版の変更点はChrome 148とは？リリース日・ビルド番号と変更点、Prompt APIとChromeOS 148の要点で、配信中のChromeの版と更新手順はChrome最新バージョンは155（2026年10月）｜確認・更新方法とバージョン履歴一覧で確認できます。

Writer・Rewriter・Proofreaderをローカルで試すフラグ

手元で試すなら、Chrome 156のソース（about_flags.cc）に登録されている次のフラグを有効にして、ブラウザを再起動します。

最後のgemma4-for-built-in-aiは、フラグの説明文に「Prompt・Summarizer・Writerなど、すべての組み込みAI APIでGemma 4モデルを使う」とあります。安定版の既定モデルが切り替わったわけではありません。Prompt API用のフラグ名は版によって変わっています（150まではprompt-api-for-gemini-nano、151からはprompt-api）。手順はGemini Nanoとは？使い方・ダウンロード・対応機種をChromeとAndroid別に解説【2026年10月】にまとめています。

Prompt API Web版のサンプリング指定｜samplingModeの7段階

出力の揺れの指定方法は、Webページと拡張機能で別のものになりました。Prompt APIの公式ドキュメントによると、Webページでは数値のtemperatureとtopKは使えません。代わりにsamplingModeを列挙値で渡します。値はmost-predictableからmost-creativeまでの7段階で、既定に近いのはbalancedです。ただしWebでのsamplingModeはまだオリジントライアルの扱いです。拡張機能では従来どおりtemperature・topKとLanguageModel.params()が使えます。値の考え方は推論パラメータとは？temperatureとtop_pの決め方・推論モデルでの非対応を実装目線で解説【2026年版】を参照してください。

動作要件｜エキスパートモデルと言語モデルの境界

公式は「Translator APIとLanguage Detector APIはエキスパートモデルを使い、それ以外のAPIは言語モデルを使う」と明記しています。重い要件がかかるかどうかは、この区別で決まります。

TranslatorとLanguage Detectorに22GB要件がかからない理由

この2つは翻訳と言語判定に特化した小さなモデルで動くため、下の要件表の対象外です。条件はデスクトップのChromeであることだけで、モバイルでは動きません。多言語サイトの翻訳補助や、投稿された文章の言語の振り分けなら、端末スペックで弾かれる心配はほぼありません。

その代わり、翻訳は言語ペアごとの言語パックをその都度取得します。初回だけダウンロード待ちが入る前提でUIを組んでください。実行環境にも制約があります。Translator APIはWeb Workerの中では使えません。クロスオリジンのiframeから呼ぶ場合は、埋め込む側でallow="translator"を付けます。

言語モデル系5APIの端末要件とavailability()の戻り値

Prompt・Summarizer・Writer・Rewriter・Proofreaderの5つには、公式の要件がすべてかかります。満たさない端末では、コードに誤りがなくてもavailability()がunavailableを返します。

Prompt APIで音声を入力に使う場合はGPUが必須です。可否はHTTPSのページでDevToolsのコンソールを開き、次の2行を貼れば分かります。

'Summarizer' in self;   // APIが生えているか
// この端末で使えるか（APIが無ければ 'unsupported'）
('Summarizer' in self) ? await Summarizer.availability() : 'unsupported';

戻り値はavailable・downloadable・downloading・unavailableの4種類です。実装ではdownloadableとunavailableを分けて扱ってください。前者は要件を満たしていてモデルが未取得なだけなので、create()を呼べば取得が始まります。後者は要件不足か、Permissions-Policyでブロックされている状態です。両方を「使えない」とまとめると、初回訪問のユーザー全員に機能なしの画面を見せることになります。

モデルのダウンロード・更新・削除の仕組み

要件表だけを見て実装すると、ここで想定外の挙動に当たります。出典は公式のモデル管理の解説です。

初回ダウンロードのきっかけと端末に応じたモデルの選択

Gemini Nanoを使うAPIのどれかでcreate()が初めて呼ばれたときに、モデルの取得が始まります。Chromeはまず代表的なシェーダーを走らせてGPUの性能を見積もります。その結果で、4Bパラメータ級の大きい版を取るか、2B級の小さい版を取るか、CPU推論に回すかを決めます。同じコードでも、端末によって動くモデルの大きさが違うということです。取得は途中で回線が切れても再開し、タブを閉じても裏で続きます。ブラウザを閉じた場合も、30日以内に起動すれば再開されます。Proofreader APIのようにLoRAの重みで特化させるAPIでは、その重みもベースモデルと一緒に取得されます。

モデル更新時の全量取得とセッション中の削除条件

モデルの更新は差分ではなく、毎回すべてを取り直します。新しいモデルは裏で取得され、取得が済むと停止時間なしに差し替わります。ただし差し替えの瞬間に実行中だったプロンプトは失敗することがあります。JavaScriptからモデルの版を問い合わせる手段はなく、確認できるのはchrome://on-device-internalsだけです。

削除は次の3つの場合に起こります。

• 取得後に空き容量が10GBを下回ったとき
• 企業ポリシーGenAILocalFoundationalModelSettingsが1（Disabled）に設定されたとき
• 利用状況などの条件を30日間満たさなかったとき

削除は実行中のプロンプトに関係なく起こるので、セッションの開始時に使えたAPIが途中で使えなくなることがあります。しかも削除されたモデルは自動では取り直されず、どこかのサイトがcreate()を呼ぶまで戻りません。設計上の結論は、最初に1回可否を確認して終わりにしないことです。呼び出しごとに例外を捕まえ、失敗したらフォールバックへ切り替えてください。社内展開を考える場合は、管理者がポリシーでモデルを無効にしている可能性も確認しておきます。

ダウンロード進捗の見せ方と未取得状態のテスト

取得の進捗は、create()のmonitorオプションに渡すリスナーでdownloadprogressイベントとして受け取れます。e.loadedが1に達したあとも、展開とメモリへの読み込みが続きます。そのため公式の例では、この段階でプログレスバーを値なしの「処理中」表示に切り替えています。

開発機ではモデルが取得済みのことが多く、初回の体験を再現しにくいはずです。公式が勧めるのは、--user-data-dirに空の一時ディレクトリを指定してChromeを起動する方法です。モデルが期待どおりに応答しないときは、chrome://on-device-internalsのEvent Logsタブでモデルに渡った実際の入力を確認できます。

要約・翻訳・言語判定の実装と最小コード

実装は「機能検出→可否確認→生成して実行」の順に書きます。モデルのダウンロードが必要な状態では、create()にユーザー操作が必要です。初回の準備はボタンのクリックなどから開始してください。Prompt APIのprompt()・promptStreaming()と構造化出力の書き方は、Gemini Nanoの記事のPrompt APIの章にあります。

Summarizerの出力制御｜type・format・lengthの指定

要約の出力は3つのオプションで決まります。typeは既定がkey-pointsで、ほかにtldr・teaser・headlineがあります。formatの既定はmarkdownで、プレーンテキストにするならplain-textを指定します。lengthはshortが既定で、medium・longと長くなります。

const options = {
  type: 'key-points',
  format: 'plain-text',
  length: 'short',
  expectedInputLanguages: ['ja'],
  outputLanguage: 'ja',
};

async function summarize(text) {
  if (!('Summarizer' in self)) return null;
  if (!navigator.userActivation.isActive) return null;

  // create() と同じ設定で可否を確かめる
  const availability = await Summarizer.availability(options);
  if (availability === 'unavailable') return null;

  try {
    const summarizer = await Summarizer.create({
      ...options,
      monitor(m) {
        m.addEventListener('downloadprogress', (e) => {
          console.log(`Downloaded ${Math.round(e.loaded * 100)}%`);
        });
      },
    });
    try {
      return await summarizer.summarize(text);
    } finally {
      summarizer.destroy();
    }
  } catch (err) {
    // モデルの削除・差し替え中の失敗もここに来る
    console.warn(err);
    return null;
  }
}

availability()にはcreate()と同じオプションを渡してください。引数なしで呼ぶと日本語の指定が検証されず、可否確認は通ったのに生成で拒否される、という食い違いが起きます。

対応言語の宣言｜モデル側の5言語とTranslatorの39言語コード

Summarizer APIが受け付ける言語はen・ja・es・de・frの5つだけです。公式も、Chrome 149以降の組み込みモデルが入出力で扱うのはこの5言語だと書いています。一方、Translator APIの言語表には、zhとzh-Hantを別に数えて39の言語コードが並んでいます。対応外の言語を自前で弾く必要はありません。expectedInputLanguagesとoutputLanguage（文脈を添えるならexpectedContextLanguagesも）を宣言しておけば、扱えない組み合わせはブラウザ側が拒否します。

Language Detectorでの言語判定とTranslatorへのペア指定

入力の言語が分からないときは、Language Detector APIで判定してからTranslator APIに渡します。detect()はdetectedLanguageとconfidence（0.0〜1.0）の組を、確信度の高い順に並べて返します。中国語については、chromestatusの告知どおりChrome 151からzhではなくzh-Hansまたはzh-Hantが返るようになりました。=== 'zh'で分岐しているコードは見直してください。

async function toEnglish(text) {
  try {
    return await detectAndTranslateToEnglish(text);
  } catch (err) {
    console.warn(err);
    return null;
  }
}

async function detectAndTranslateToEnglish(text) {
  if (!('LanguageDetector' in self) || !('Translator' in self)) return null;
  if (!navigator.userActivation.isActive) return null;
  if (await LanguageDetector.availability() === 'unavailable') return null;

  const detector = await LanguageDetector.create();
  let top;
  try {
    [top] = await detector.detect(text);
  } finally {
    detector.destroy();
  }     // 確信度の高い順
  if (!top || top.confidence < 0.5) return null;  // しきい値は要件に合わせる
  if (top.detectedLanguage === 'en') return text;

  const pair = { sourceLanguage: top.detectedLanguage, targetLanguage: 'en' };
  if (await Translator.availability(pair) === 'unavailable') return null;

  const translator = await Translator.create(pair);
  try {
    return await translator.translate(text);
  } finally {
    translator.destroy();
  }
}

Translatorのavailability()に期待しすぎないでください。プライバシー保護のため、言語ペアごとの取得状況は隠されています。そのサイトが実際にcreate()を呼ぶまで、対応しているペアはすべてdownloadableと報告されます。分岐で弾けるのはunavailableのときだけで、待ち時間が要るかどうかを事前に知ることはできません。

この関数はcreate()を2回呼ぶのに、ユーザー操作の確認は入口の1回だけです。初回はモデルの取得に時間がかかり、その間にユーザー操作の有効期間が切れることがあります。言語判定と翻訳を別々の操作に分ける設計も検討してください。長文はtranslateStreaming()で少しずつ受け取れます。

Chrome以外のブラウザでの対応と標準化の状況

不特定多数向けに使うなら、到達率を決めるのはChrome以外の扱いです。

Edgeは同じAPI名で動きますが、中身のモデルが違います。Microsoft Learnの解説によると、Edgeの要約や文章生成はGemini NanoではなくMicrosoftのPhi-4-miniで動きます。Canary・Devの150.0.4070以降では、プレビュー版のAion-1.0-Instructも選べます。同じ入力でも要約の出来はブラウザごとに変わるので、Chromeで調整した後処理をそのままEdgeに当てはめないでください。Translator・Language DetectorのEdge 148は、Chrome公式ドキュメントの対応ブラウザ欄の値です。

FirefoxとSafariの開発元は、反対の立場を公に表明しています。MozillaはPrompt APIにnegativeの判定を出し、2026年5月5日にissueを閉じました。理由には相互運用性への懸念が挙がっています。Summarizer・Writer・Rewriterをまとめた提案（2025年5月23日にnegativeへ変更）と、Translator APIの前身であるWeb Translation API（2026年1月12日）もnegativeです。WebKitはPrompt APIにopposeのラベルを付けて2026年5月27日に閉じており、要約系の提案には立場を出していません。仕様そのものも、W3CのWeb Machine Learning Community Groupが公開している草案（Draft Community Group Report）で、W3Cの標準化トラックには乗っていません。

Androidへの展開については、chromestatusにPrompt・Summarizer・Translator・Language DetectorのAndroid版が登録されています。Language Detectorについては、2026年10月16日にChrome 157での出荷予定が告知されました。安定版のChrome for Androidではまだ使えません。ここから導ける結論ははっきりしています。Built-in AIは「対応環境でサーバー推論の呼び出しを減らす追加機能」として載せ、主経路はサーバー側か従来のUIに置いてください。

Prompt APIとタスク特化APIの使い分け

Prompt APIは任意のプロンプトを投げられる汎用の窓口で、画像と音声も入力に取れます。要約ならSummarizer APIでtypeとlengthを指定するだけで形式がそろい、要約用プロンプトを一から設計する負担を減らせます。ただし、出力の検証や、利用先に応じた整形・パースは別途必要です。Prompt APIで同じことをすると、書式の指示と結果の検証が丸ごと自分の仕事になります。

Prompt APIを選ぶ理由になるのは、分類・抽出・対話のようにタスク特化APIの型に収まらない処理か、画像・音声を入力に取りたい場合です。端末上の小型モデルは文脈長が小さいので、長文は分割して渡す前提で組んでください。考え方はコンテキストウィンドウとは？トークン上限の数え方と有効長・溢れ対策を実装者向けに解説にまとめています。ページの機能をAIエージェントに道具として公開したいなら、Built-in AIではなく別系統のWebMCPとは：MCPとの違い・registerToolの実装手順とChromeの対応状況【2026年10月】が該当します。

Built-in AIを採用すべきでない場面とサーバー側に倒す条件

モバイル主体のサービスなら、ここで検討は終わりです。言語モデル系のAPIもTranslator APIもモバイルのChromeでは動かず、Android版で出荷予定が告知されているのはLanguage Detector（Chrome 157）だけです。モバイル利用者への提供が必須なら、Chrome 156のBuilt-in AIを主経路にする設計は採用できません。

不特定多数向けの公開サイトで、言語モデル系のAPIを唯一の実装にするのも避けてください。要件を満たすかどうかは空き容量・GPU・RAMの組み合わせで端末ごとに変わり、GPUが弱くてもRAM 16GB以上・4コア以上ならCPUで動く一方、空き容量が22GBを切れば動きません。unavailableが返る比率は事前に見積もれないので、計測するならavailability()の戻り値を分析に送ります。契約文面の生成や金額を含む計算の代行のように、出力の一貫性が要件になる用途も対象外です。

向いているのは、失敗しても本筋が壊れない機能です。たとえば社内ツールでの表記ゆれの検出、入力欄の要約プレビュー、コメントの下訳です。社内ツールなら配布端末のスペックをそろえられ、ポリシー設定も自分たちで管理できます。トークン課金は発生しませんが、空き容量とモデル取得の待ち時間というコストをユーザー側が負担します。到達できる利用者の割合を基準に、クラウドのAPIと比べてください。Built-in AIとサーバー側の生成AIを組み合わせた構成の設計は、生成AI開発・AI受託開発で相談を受け付けています。自前のモデルをサーバーで動かす選択肢との比較にはローカルLLMの活用事例｜個人・業務の使い方と国内導入例、Ollamaでの始め方も参考になります。

よくある質問

Chrome Built-in AIとGemini Nanoは何が違いますか？

Gemini NanoはChromeが端末に取得する言語モデルそのもので、Chrome Built-in AIはモデルをJavaScriptから呼び出すAPI群の総称です。7つのAPIすべてがGemini Nanoを使うわけではありません。Translator APIとLanguage Detector APIは、翻訳と言語判定に特化した別のエキスパートモデルで動きます。開発者が触るのはAPIだけで、モデルのファイルはChromeが管理します。

通常のChromeで使えますか？拡張機能が必要ですか？

翻訳・言語判定・要約・Prompt APIの4つは、拡張機能なしで通常のWebページから使えます。拡張機能だけでできるのは、Prompt APIでtemperature・topKを数値で指定することです。Writer・Rewriter・Proofreaderは、どちらでもフラグを有効にしないと使えません。

スマホ（Android・iPhone）のChromeでも使えますか？

2026年11月時点では使えません。公式の要件は、言語モデル系のAPIについてChrome for Android、iOS、Chromebook Plus以外のChromeOSを未対応としています。Translator APIとLanguage Detector APIもモバイルでは動きません。Language Detector APIのAndroid版はChrome 157での出荷予定が告知されていますが、この記事の基準であるChrome 156では未対応です。

availability()がunavailableを返すのはなぜですか？

言語モデル系のAPIでは、端末要件の不足や指定した言語・モダリティの非対応によって、Chromeの版が新しくても返ります。ほかに、クロスオリジンのiframeでallow属性が無い場合や、企業ポリシーでモデルが無効にされている場合もあります。

入力した内容はGoogleに送信されますか？

送信されません。公式は「モデルの使用時にGoogleや第三者へデータは送られない」と明記しています。通信が発生するのはモデルの取得と更新のときだけで、取得後はオフラインでも動きます。ただしこれはBuilt-in AIのAPIを通した処理に限った話です。同じページから別途クラウドのAPIを呼んでいれば、そちらには当然データが送られます。

関連記事

• Gemini Nanoとは？使い方・ダウンロード・対応機種をChromeとAndroid別に解説【2026年10月】
• Chrome 148とは？リリース日・ビルド番号と変更点、Prompt APIとChromeOS 148の要点
• WebMCPとは：MCPとの違い・registerToolの実装手順とChromeの対応状況【2026年10月】
• コンテキストウィンドウとは？トークン上限の数え方と有効長・溢れ対策を実装者向けに解説
• 推論パラメータとは？temperatureとtop_pの決め方・推論モデルでの非対応を実装目線で解説【2026年版】