Chrome Built-in AIとは？7つのAPIの出荷段階と実装手順【2026年8月】

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

まとめ

翻訳・言語判定・要約の3つはChrome 138で出荷済みです。汎用の対話に使うPrompt APIも、拡張機能はChrome 138、通常のWebページはChrome 148で出荷されました。配信中の安定版はいずれもこれらより新しいため、オリジントライアルの登録もフラグ操作も不要でそのまま呼び出せます。残るWriter・Rewriter・Proofreaderの3つはWeb・拡張機能ともDeveloper trial段階で、本番の設計に入れる対象ではありません。

もう一つ、公式ドキュメントを読まないと踏み抜くのが動作要件の分かれ方です。空きストレージ22GB以上とVRAM 4GB超という重い条件がかかるのは、言語モデルを使う5つのAPIだけです。Translator APIとLanguage Detector APIは専用のエキスパートモデルを使うため、デスクトップなら端末スペックで弾かれません。ただし翻訳は言語ペアごとの言語パックを都度取得するため、初回のダウンロード待ちは残ります。以下、出荷段階の一覧、要件の分岐、タスク特化APIの実装、そしてサーバー側に倒すべき条件の順で説明します。

7つのAPIの出荷段階｜Webページと拡張機能で異なる利用可否

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

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

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

読み分けの軸はバージョン番号の有無です。数字が入っている行は出荷済みで、ユーザー側の準備は要りません。Developer trialと書かれた行はchrome://flagsでの有効化が前提のため、一般ユーザーの環境には機能そのものが存在しません。

Prompt APIの扱いには補足が要ります。Webページ向けのオリジントライアルはChrome 139から144の期間で終了しており、Chrome 148で正式に出荷されました。いま残っているオリジントライアルは、出力の揺れを制御するtemperatureとtopKをWebページから指定する部分だけです。拡張機能ならこのパラメータもChrome 148で出荷済みです。Prompt APIがWebに載った世代の全体像はChrome 148の安定版リリース概要と主要アップデート対象環境で確認できます。

本番投入の線引き｜Developer trialの3つを設計に入れない理由

ここは判断を明確にします。Writer・Rewriter・Proofreaderの3つは、社内の検証を除いて設計に入れないでください。Developer trialはユーザー自身がchrome://flagsを操作しない限り機能が存在しない段階であり、公開サイトに載せてもほぼ全員に対してunavailableが返ります。オリジントライアルであればサーバー側でトークンを配れば全ユーザーに届きますが、Developer trialにはその手段がありません。この差は大きく、両者を「まだ実験段階」とひとまとめに扱うと計画を誤ります。

逆に、Translator・Language Detector・Summarizer・Prompt APIの4つは出荷済みです。動くかどうかはユーザーの端末条件だけで決まり、その判定は次章のavailability()で取れます。

APIで分かれる動作要件｜エキスパートモデルと言語モデルの境界

公式ドキュメントは「Translator APIとLanguage Detector APIはエキスパートモデルを使い、それ以外のAPIは言語モデルを使う」と明記しています。この一文が要件の分岐点です。

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

この2つは翻訳と言語判定に特化した小さなモデルで動くため、大きな要件表の対象外です。公式が課している条件は「デスクトップのChromeで動作し、モバイル端末では動作しない」の1点です。多言語サイトの翻訳補助や、投稿された文章の言語を振り分ける処理であれば、端末スペックで弾かれる心配はありません。

その代わり、翻訳は言語ペアごとの言語パックをオンデマンドで取得します。公式は言語パックを「その言語の辞書のようなもの」と説明しています。22GBのような常時確保は不要ですが、初回だけダウンロード待ちが挟まる前提でUIを組んでください。進捗を出すか、遅延を許容する見せ方かのどちらかは決めておく必要があります。

ただし実行環境の制約は別にあります。Translator APIはWeb Worker内では動かず、呼び出しにはユーザー操作が必要です。クロスオリジンのiframeから使う場合は、埋め込み側でallow="translator"を付与してください。

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

Prompt・Summarizer・Writer・Rewriter・Proofreaderの5つには、次の条件がすべてかかります。公式は「以下の条件を満たす場合にChromeで動作する」という書き方をしています。条件を満たさない端末ではavailability()がunavailableを返し、コード側に誤りがなくても機能は出ません。

22GBは取得後も維持が必要な容量です。ダウンロード後に空きが10GBを下回るとモデルが削除され、条件を満たすまで再取得されません。ストレージが逼迫した端末では、一度動いた機能が翌週には消えます。実際に確保されているモデルのサイズはchrome://on-device-internalsで確認できます。なおPrompt APIで音声入力を使う場合はGPUが必須です。

可否の判定は次の2行で取れます。HTTPSのページでDevToolsのコンソールを開き、そのまま貼り付けてください。

// DevTools のコンソールで実行
'Summarizer' in self;              // API が生えているか
await Summarizer.availability();   // 実際に使えるか

戻り値はavailable・downloadable・downloading・unavailableの4種と、判定不能を表すnullです。実装で効くのはdownloadableとunavailableを分けることです。前者は要件を満たしていてモデルが未取得なだけなので、ダウンロードを開始すれば動きます。後者は要件を満たさないか、Permissions-Policyでブロックされている状態です。この2つを同じ「使えない」として扱うと、初回訪問のユーザー全員が機能なしの画面を見ることになります。値ごとの詳しい意味はGemini Nano（ジェミニナノ）とは？Chrome内蔵AIの性能・有効化・使い方【2026年最新】のavailability()の章にまとめてあります。Chrome自体のバージョン確認と更新の手順はChrome最新バージョンは150（2026年6月最新）｜更新方法・確認方法とリリース履歴の総まとめを参照してください。

タスク特化APIの実装｜要約・翻訳・言語判定の最小コード

実装は「機能検出→可否確認→生成して実行」の順に書きます。扱うのは、モデルの対応言語に日本語が含まれる要約と、言語ペア単位で挙動が変わる翻訳・言語判定の2系統です。Prompt APIのprompt()やpromptStreaming()による実装は、Gemini Nano（ジェミニナノ）とは？Chrome内蔵AIの性能・有効化・使い方【2026年最新】の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;

  // create() はユーザー操作の直後でないと拒否される
  if (!navigator.userActivation.isActive) return null;

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

  const summarizer = await Summarizer.create({
    ...options,
    monitor(m) {
      m.addEventListener('downloadprogress', (e) => {
        console.log(`Downloaded ${e.loaded * 100}%`);
      });
    },
  });

  return await summarizer.summarize(text);
}

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

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

日本語サイトで見落としやすいのが言語の非対称性です。Summarizer APIが受け付けるのはen・ja・es・de・frの5つに限られます。公式も、Chrome 149以降の言語モデルが入出力で扱うのはこの5言語だと明記。一方でTranslator APIの言語表には39の言語コードが並びます。同じBuilt-in AIでも守備範囲がまったく違うわけです。

対応外の言語を自前で弾く必要はありません。create()にexpectedInputLanguagesとoutputLanguageを渡しておけば、サポートできない組み合わせはブラウザ側が要求を拒否します。文脈として別言語のテキストを添える場合はexpectedContextLanguagesも宣言してください。宣言を省くと、対応外の言語が混ざったときに理由の分からない失敗として表面化します。

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

入力側の言語が不明なときは、Language Detector APIで判定してからTranslator APIへ渡します。detect()が返すのはdetectedLanguageとconfidenceの組を確信度の高い順に並べたリスト。先頭のdetectedLanguageをそのままsourceLanguageに渡せます。確信度は0.0から1.0の値なので、下のコードでは0.5未満を「判定できなかった」として翻訳を打ち切っています。

async function toEnglish(text, onChunk) {
  if (!('LanguageDetector' in self) || !('Translator' in self)) return null;

  // create() はユーザー操作の直後でないと拒否される
  if (!navigator.userActivation.isActive) return null;
  const detectorStatus = await LanguageDetector.availability();
  if (detectorStatus === 'unavailable') return null;

  const detector = await LanguageDetector.create();
  const [top] = await detector.detect(text);   // 確信度の高い順
  if (!top || top.confidence < 0.5) return null;  // しきい値は要件に合わせて調整

  const sourceLanguage = top.detectedLanguage;
  if (sourceLanguage === 'en') {                 // 訳す必要が無い場合も契約を揃える
    if (onChunk) { onChunk(text); return null; }
    return text;
  }

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

  const translator = await Translator.create({
    sourceLanguage,
    targetLanguage: 'en',
  });

  // 長文は逐次受け取る
  if (onChunk) {
    for await (const chunk of translator.translateStreaming(text)) {
      onChunk(chunk);
    }
    return null;
  }

  return await translator.translate(text);
}

ここでstatusに期待しすぎないでください。Translator APIはプライバシー保護のため、特定の言語ペアのダウンロード状況を隠します。そのサイトが実際にcreate()を呼ぶまで、対応済みのペアはすべてdownloadableとして報告される仕様です。つまり分岐で弾けるのはChromeがそのペア自体を持たないunavailableのときだけ。availableとdownloadableの差で「待ち時間が要るか」を先読みすることはできません。

もう一点、この関数はcreate()を2回呼ぶのに、ユーザー操作の確認は入口の1回だけです。LanguageDetector.create()でモデルの取得が走ると数十秒かかることがあり、その間に一時的なユーザー操作の有効期間は失効します。初回訪問で実際に起こる経路なので、翻訳ボタンを押した直後に走らせる前提にするか、言語判定と翻訳を別々の操作に分ける設計にしてください。使い終わったインスタンスはdestroy()で解放します。ページ内で繰り返し翻訳するなら、同じ言語ペアのインスタンスを使い回すほうが速くなります。

Prompt APIとの使い分け｜タスク特化APIで足りるかの判断基準

Prompt APIはGemini Nanoへ任意のプロンプトを投げる汎用の窓口で、画像と音声も入力に取れます。自由度は高い一方、出力の揺れを自分で吸収する負担がつきまといます。

先にタスク特化APIで足りるかを検討してください。Summarizer APIならtypeとlengthを指定するだけで出力形式が安定し、プロンプト設計もパースも不要です。Prompt APIで同じことをすると、書式指示の作り込みと結果の検証が丸ごと自分の仕事になります。さらにWebページではtemperatureとtopKがまだオリジントライアル扱いで、出力の揺れを絞る手段そのものが限られます。値の決め方は推論パラメータとは？temperatureとtop_pの決め方・推論モデルでの非対応を実装目線で解説【2026年版】にまとめました。

Prompt APIを選ぶ理由になるのは、分類・抽出・対話のようにタスク特化APIの型に収まらない処理か、画像や音声を入力に取りたい場合です。端末上の小型モデルは扱える文脈長が小さく、長文をそのまま投げると途中が落ちます。分割前提の設計についてはコンテキストウィンドウとは？トークン上限の数え方と有効長・溢れ対策を実装者向けに解説を参照してください。

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

まず外せない条件から挙げます。モバイル主体のサービスでは検討が終わります。Built-in AIのモデルはモバイル端末に存在せず、Translator APIも明示的にデスクトップ限定です。日本の消費者向けサイトはモバイル比率が高いため、到達率の時点で投資が回収できません。

不特定多数向けの公開サイトで、言語モデル系のAPIを唯一の実装にするのも避けてください。空きストレージ22GBとVRAM 4GB超という条件は、統合GPUと256GB SSDを積んだ業務用ノートPCで普通に落ちます。unavailableが返る比率を事前に見積もるのは難しく、実測するならavailability()の戻り値を計測に載せるしかありません。フォールバックのないUIは「一部の人にだけボタンが効かない」という形で露出します。出力の一貫性が要件になる用途、たとえば契約文面の生成や金額を含む計算の代行も対象外です。

もっとも相性が良いのは社内ツールの表記ゆれ検出です。配布端末のスペックを統制できるため要件を満たす端末だけを対象にでき、結果が出なくても従来のUIに戻るだけで済みます。同じ理由で、入力欄の要約プレビューやコメントの下訳も候補になります。いずれも失敗が本筋を壊さない領域。そこでは通信ゼロとオフライン動作の利点がそのまま効きます。サーバー側で自前のモデルを動かす選択肢と比べたい場合は、ローカルLLMの活用事例｜個人・業務での使い方とELYZAでの始め方が比較材料になります。

よくある質問

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

Gemini NanoはChromeに同梱されるオンデバイスの言語モデル本体で、Chrome Built-in AIはそのモデルをJavaScriptから呼び出すWeb API群の総称です。7つのAPIすべてがGemini Nanoを使うわけではなく、Translator APIとLanguage Detector APIは翻訳・言語判定に特化した別のエキスパートモデルで動きます。開発者が直接触るのはAPI側で、モデルのファイルを自分で管理することはありません。

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

翻訳・言語判定・要約・Prompt APIの4つは、通常のWebページから使えます。前者3つはChrome 138、Prompt APIのWeb版はChrome 148で出荷済みで、配信中の安定版はいずれもそれより新しいため追加の手続きは要りません。拡張機能でのみ先行しているのは、Prompt APIのtemperature・topKの指定です。Writer・Rewriter・Proofreaderの3つはWeb・拡張機能ともフラグでの有効化が前提の段階です。

DevToolsのコンソールにあるAI機能とBuilt-in AIは同じものですか？

別物です。DevToolsのコンソールでエラーの説明を出すAI支援機能が使うのは、開発者ツール側に組み込まれたクラウドのモデル。Built-in AIのほうは、自分のWebページや拡張機能のコードから呼ぶAPI群で、推論が端末上で完結する点が決定的に違います。ただしBuilt-in AIの動作確認にDevToolsのコンソールを使うのは有効で、'Summarizer' in selfとawait Summarizer.availability()を貼れば可否がすぐ分かります。

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

言語モデル系のAPIであれば、多くは端末要件の不足です。空きストレージが22GBに満たない、VRAMが4GB以下、GPUを使わない構成でRAMが16GB未満といった条件で返ります。バージョンが足りていても返る点に注意してください。もう一つの原因がPermissions-Policyによるブロックで、クロスオリジンのiframeから呼ぶ場合は埋め込み側のallow属性が必要です。なおdownloadableは要件を満たしたうえでモデルが未取得なだけなので、扱いを分けてください。

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

送信されません。推論は端末上で完結し、公式も「モデルの使用時にGoogleや第三者へデータは送られない」と明記しています。ネットワークが要るのはモデルの初回取得と更新のときだけで、取得後はオフラインでも動作します。外部に出せない社内文書の下処理や、通信が不安定な環境での補助機能に向く性質です。ただしこれはBuilt-in AIのAPIを通した処理の話で、同じページから別途クラウドのAPIを呼んでいれば当然そちらは送信されます。

クラウドのAI APIと比べてコストはどう変わりますか？

オンデバイス実行なので、トークン単位の従量課金は発生しません。ただしコストがゼロになるわけではなく、負担の置き場所が変わります。言語モデル系のAPIではユーザー側に22GB以上の空き容量を要求し、初回にモデルの取得時間もかかります。到達率の低下という形で機会損失も生じるため、クラウドAPIと比べる際は「API料金」ではなく「到達できるユーザーの割合」を軸に置いてください。呼び出し回数が少なく単価も低い用途では、素直にクラウド側に寄せたほうが総コストは下がります。

関連記事

• Gemini Nano（ジェミニナノ）とは？Chrome内蔵AIの性能・有効化・使い方【2026年最新】
• Chrome 148の安定版リリース概要と主要アップデート対象環境
• 推論パラメータとは？temperatureとtop_pの決め方・推論モデルでの非対応を実装目線で解説【2026年版】
• コンテキストウィンドウとは？トークン上限の数え方と有効長・溢れ対策を実装者向けに解説
• ローカルLLMの活用事例｜個人・業務での使い方とELYZAでの始め方