Chrome Built-In AI、皆さん使っていますか？

登場して2年くらいの技術になりますが、今年の春についに Prompt API が Chrome にデフォルトで組み込まれるようになりました。
せっかく広く使えるようになりましたが、まだまだ利用が普及していない印象を受けます。

最初に GA したのがクセの強い領域であったことや、Gemini 自体への期待値の低さなどが要因だと考えたため、この記事では「思ったより悪くないよ」ということを伝えられればと思います。

技術概要

Built-In AI はその名の通り、ブラウザに内蔵されている AI を使うことができる機能です。
用途別に異なる API が提供されており、一応 Web 標準に載せる想定ですが、基本的には Google が主導している Chrome の機能であるのが実情です。

そのため、本記事では便宜上 Chrome Built-In AI を中心として解説します。

• Translator API(2025/06〜)
  • ブラウザ提供の翻訳モデルを利用する API
• Summarizer API(2025/06〜)
  • テキストの要約に特化した Task API
• Language Detector API(2025/06〜)
  • 入力テキストの言語と信頼度を判定する API
• Prompt API(2026/05〜)
  • テキスト・画像・音声入力と構造化出力に対応した汎用 API

最も汎用的で実用的な Prompt API が GA したのが今年ということもあり、登場自体は早いものの活用が加速するとしたらこれからという展開状況ですね。
今後も新たな機能追加の際は、chrome://flags によるオプトインを経て正式実装されると思われます。

余談ですが、標準を目指しているため、MDNにも項目があるほか、Edge だけは Prompt API を開発者向けプレビューとして提供されています。

デモ

せっかくなのでこの場で簡単に試せるようにしました。
もしまだ使ったことがない方は、続きを読む前にこの場で試してみることも可能です。
(初回実行は少し時間がかかります)

Chrome Built-In AIについて一言で説明してください。 実行

Built-In AI の魅力

最大の特徴は事前準備なく、無料で、エンドユーザーのマシン内で動くというコンパクトさでしょう。
AI事業者の Web API を叩くわけではなく、あくまでも端末内で完結するため追加の課金は不要。APIキーの準備なども不要なので、漏洩や過剰利用による問題も起きません。

コンセプトの面では、レイテンシや料金の問題を抱えるWeb API ベースでの AI 利用と、利用者側でのセットアップや大量のマシンリソースを必要とするローカルLLMの両方の課題を解決するソリューションとなっています。

ただし、様々な問題を一挙に解決しようとするため、一つの課題を抱えています。

モデルの詳細と性能

それがモデルの貧弱さです。

Chrome Built-In AI で利用されているモデルは Gemini Nano と呼ばれる専用モデルに固定されています。

スペックの詳細は共有されていませんが、Gemma 3nの情報が出た際にアーキテクチャの共有が明言されており、進化を考慮しても Gemma 3n から Gemma 4あたりの性能と考えられます。 パラメータ数も2B〜4Bクラスであると考えられるため、あくまでもシンプルで限定的な利用を想定したモデルであると認識しておけば間違いありません。

また、あくまでも Input に対して Output を返すだけのプリミティブな操作を想定しているため、何世代か前のAI利用のイメージとなります。
そのため日常使いやアプリケーションの根幹となる機能を提供する用途には向かず、例えば「自由入力を含むバリデーションをちょっとヒューリスティックに処理したい」といった限定利用が現実的でしょう。

総じて Agentic がスタンダードとなった現代から見ると少しシンプルすぎる側面があり、適切に使うにはユースケースの見極めを含めてコツが要る印象です。

一方で強みもあり、このレベルのモデルで音声や画像を処理できるのは流石 Gemini といったところ。
マルチモーダルを取り扱うAI利用では、予想以上の成果を上げてくれるはずです。

使い方

デモだけ先にお見せしましたが、ここからは実際の利用方法を紹介します。
今回の記事では Prompt API の例とします。

利用自体は簡単で、ブラウザに生えている LanguageModel API を叩くことですぐに利用できます。
最小構成であれば、以下の2行で起動から実行まで完了できます。

const session = await LanguageModel.create();
const response = await session.prompt('Hi.');

また、セッションの開始時にはいくつかのオプションを指定することができます。
いわゆるシステムプロンプトを設定する場合は、以下のように行います。

const session = await LanguageModel.create({
  initialPrompts: [
    { role: 'system', content: 'When you answer with a number, if it’s a multiple of 3, be sure to act like an idiot when you answer.' }
  ]
});
const response = await session.prompt('Please list the first 10 prime numbers.');

マルチメディアを活用する場合も初期設定で確定させる必要があり、例えば画像を扱う場合は以下のような設定が必要となります。

const imageData = document.querySelector<HTMLInputElement>('input[type="file"]')?.files?.[0];

if (!imageData) {
  throw new Error('画像ファイルを選択してください。');
}

const session = await LanguageModel.create({
  expectedInputs: [
    { type: 'image' },
  ],
  expectedOutputs: [
    { type: 'text', languages: ['en'] }
  ],
});

const response = await session.prompt([
  {
    role: 'user',
    content: [
      {
        type: 'image',
        value: imageData
      }
    ]
  }
]);

記述は少し煩雑ですが、シンプルなAPIであり、オフィシャルに提供されているものを含めて世の中にコード自体は出回っているため、エージェントに任せれば適切にコーディングしてくれます。

実装した先のツールと機能

https://crop.ygotools.com/

今回は超小規模アプリの題材として、MDCardCropperに組み込んでみました。
私がプレイ・動画投稿を行っているゲーム『遊戯王マスターデュエル』向けのゲーム内画像のクロップツールです。

具体的な機能としては、今回は OCR を AI に任せています。

これまでは cropped_YYYYMMDD_HHiiss.png 形式でダウンロードされるようにしていましたが、性質上使い回すことが多い画像をダウンロードすることになるので、あらかじめ human-readable なファイル名にすることで、少しでも作業負担を減らすことを狙っています。

こういった、あってもなくても良いが、あると少し嬉しいヒューリスティックな機能を実装するにはぴったりな印象がありますね。

おわりに

サポート状況としても性能としても、Production 運用に耐えるイメージはまだ湧きません。

ただ、Agent で即席でアプリを生成して公開するという流れが自然になってきており、小規模どころか零細規模のアプリケーションを作成・公開する機会が増えている状況とは好相性です。

これまでで言うと個人サイトのサブドメインでホスティングしていたような小規模サービスや、あるいは仕事なら社内サービスやツールのようなものにも、パケ死やAPIキーの取り回しの心配なく AI 関連の機能を統合できる点に魅力を感じます。

入力が安定しないようなデータは、素朴に実装するより AI に投げてから定形データに戻すほうが正確で効率的な場合も多いので、うまく使っていきたいですね。