Chrome の組み込み AI APIs 入門 - ブラウザ内 Gemini Nano で何ができて何がまだ実験的か

AI 機能を Web アプリに足すとき、これまでは「ユーザーの入力をサーバーの LLM に送って、結果を返す」のが定番でした。でも、要約や翻訳のような軽い処理のたびに外部 API を叩くのは、コストもレイテンシもプライバシーも気になります。

Chrome の組み込み AI APIs は、この前提を変えます。ブラウザ内のオンデバイスモデル（Gemini Nano）を使い、サーバーに送らずその場で推論する。先日書いた WebMCP と同じく「ブラウザ自身が AI を持つ」流れの一部です。この記事では、何があって・どう使い・何がまだ実験的かを整理します。

何があるか（安定度の早見表）

組み込み AI APIs はオンデバイスモデルで動きます。ただしモデルは一つではなく、要約・Prompt・文章生成系（Writer/Rewriter）は Gemini Nano、翻訳と言語判定は専用の expert モデルを使い分けています。そして API ごとに成熟度がかなり違う——これが現状の最重要ポイントです。

共通の作法: availability から create へ

これらの API は共通の形を持っています。グローバルなクラス（Summarizer・Translator・LanguageModel など）があり、

1. まず存在を確認する
2. availability() でモデルが使えるか確かめる
3. create() でインスタンスを作る
4. 実行する

という流れです。安定版の Summarizer API で具体例を見ます。

// 1. サポートされているか
if ('Summarizer' in self) {
  // 2. 利用可否（'available' / 'downloadable' / 'downloading' / 'unavailable'）
  const availability = await Summarizer.availability();
 
  if (availability !== 'unavailable') {
    // 3. オプションを指定して生成
    const summarizer = await Summarizer.create({
      type: 'key-points',   // 'tldr' / 'teaser' / 'headline' も
      format: 'markdown',   // 'plain-text' も
      length: 'medium',     // 'short' / 'long' も
    });
 
    // 4. 実行（ストリーミングは summarizeStreaming）
    const summary = await summarizer.summarize(longText, {
      context: '技術ブログの記事本文',
    });
  }
}

availability() は 'available' / 'downloadable' / 'downloading' / 'unavailable' の4状態を返します。ポイントは 'downloadable' と 'downloading'。オンデバイスモデルなので、初回は端末へのモデルダウンロードが必要になることがあり、「すぐ使える（available）」とは限らない前提で UI を組む必要があります。Translator や LanguageModel（Prompt API）も、同じ availability() → create() の作法です。

何がまだ危ない / 注意点

オンデバイス AI は魅力的ですが、Web アプリに入れる前に踏まえるべき現実があります。

• Chrome 限定: 他ブラウザでは動かない。'Summarizer' in self のような存在チェックとフォールバックが必須
• モデルのダウンロードが要る: 初回は数百MB級の DL が走り得る。'downloadable' の状態を考慮した進捗 UI を
• 状態がバラバラ: オリジントライアルや Developer Trial の API（Prompt の Web 利用、Writer/Rewriter/Proofreader）は本番前提にできない
• 品質はクラウド LLM 未満: 小型オンデバイスモデルなので、高度な生成・長文の整合性はサーバー LLM に劣る。タスクを選ぶ
• 端末の性能・ストレージに依存する

サーバー LLM との使い分け

オンデバイス AI は「サーバー LLM の置き換え」ではなく「使い分け」で考えるのが現実的です。

たとえば「入力文の言語を判定して翻訳ボタンを出す」「コメントの下書きを手元で要約する」といった軽量・常用・プライバシー配慮の機能はブラウザ内 AI が映えます。一方、本格的な文章生成や横断的な推論はサーバー側に任せる——という二段構えが、2026年時点の妥当な設計です。Gemini 3.1 のようなクラウドモデルとオンデバイスの Gemini Nano を、役割で住み分けるイメージです。

まとめ

• Chrome の組み込み AI APIs はオンデバイスモデルで動く（要約・Prompt・文章生成系は Gemini Nano、翻訳・言語判定は専用モデル）。サーバーに送らず、プライバシー・オフライン・低レイテンシが利点
• 本番で安定して使えるのは Translator・Language Detector・Summarizer の3つ（Chrome 138以降）。Prompt は拡張で安定・Web は提供途中、Writer/Rewriter/Proofreader は試用段階（正確な状況は公式ステータスで確認）
• 共通の作法は availability() → create() → 実行。戻り値は4状態で、'downloadable' / 'downloading'（初回モデル DL）を前提に UI を組む
• Chrome 限定なので存在チェックとフォールバックが必須。トライアル段階の API は本番に使わない
• サーバー LLM とは「置き換え」でなく「使い分け」。軽量・機密・常用はブラウザ内、高度な生成はサーバー

「AI はサーバーに送るもの」という前提が、ブラウザ内モデルで少しずつ崩れています。まずは安定3 API とフォールバック設計から、手元で試してみてください。

参考リンク

• Built-in AI APIs（Chrome for Developers）
• Summarizer API（Chrome for Developers）
• WebMCP とは何か（当ブログ）
• CSS 2026 のブラウザネイティブ機能（当ブログ）
• Gemini 3.1 Flash と Live / TTS（当ブログ）