Chrome拡張機能でGemini Nanoを使う──ローカルAI機能を業務ツールへ組み込む前に知ること

Chromeに備わるAI機能を使えば、Chrome拡張機能から端末上で文章の要約・分類・情報抽出を行える可能性があります。ただし、これは任意のローカルLLMを自由に載せ替える仕組みではありません。対応端末、初回ダウンロード、拡張機能の権限、外部通信を確認したうえで、用途を小さく限定して設計することが実用化への近道です。 情報確認日：2026年7月27日 生成AIを業務へ組み込む際、外部APIの従量課金や、社内データをどこまで送信してよいかが障壁になることがあります。その選択肢の一つが、ChromeのBuilt-in AIです。 Chrome拡張機能では、Prompt APIを通じてChromeが管理する基盤モデルへ自然言語で依頼できます。たとえば、開いているページの要点整理、問い合わせ内容の分類、定型文の下書き補助といった処理です。 ここで重要なのは、「ローカルで動く」という言葉だけで判断しないことです。業務利用に向く場面と、クラウドAIを使うべき場面を分けて考えます。  

Chrome拡張機能から使えるのは、ブラウザ管理のAI機能

Prompt APIは、Chrome内の基盤モデルへ指示を送るためのAPIです。Chrome公式の提供状況では、拡張機能でのPrompt APIはChrome 138から対象となっています。公式ドキュメントには、拡張機能からチャット機能を作るサンプルも案内されています。 実装側は、モデルファイルを直接読み込んだり、任意の量子化モデルを選んだりするのではありません。LanguageModel.availability()で利用可能かを確認し、LanguageModel.create()でセッションを作成して、要約や分類などの指示を渡します。 つまり、一般的なローカルLLMサーバーの代替というよりも、Chromeの対応環境で利用できるオンデバイスAI機能として扱うのが正確です。

向いている業務は「ページ内で完結する小さな支援」

最初の導入では、正解を自動確定する処理ではなく、人が最終確認する補助機能に絞ると安全です。 向いている例開いているWebページの要点を箇条書きにする問い合わせ文を「見積」「日程」「技術相談」などに分類する商品説明や社内メモから、確認すべき項目を抽出する長い説明文の下書きを短く整えるページ上のイベント情報を拾い、登録候補として整形する Chrome公式も、ページ内容に基づく検索、コンテンツ分類、カレンダー予定や連絡先の情報抽出を、Prompt APIを使った拡張機能の例として挙げています。 向かない例経理・契約・採用などで、AIの結果だけを根拠に自動確定する業務大量文書を長時間・高精度で解析する処理常に同一モデル、同一性能、同一出力形式を保証する必要がある処理端末要件を満たさない利用者が多いサービス 出力は生成AIの結果です。分類や抽出の結果を業務システムへ反映する場合も、確認画面や修正操作を残す設計が必要です。

導入前に確認したい5項目

1. 利用者の端末が対応するか公式要件では、Windows 10/11、macOS 13以降、Linuxなどが対象です。Chromeプロファイルが置かれたボリュームには少なくとも22GBの空き容量が必要です。GPUを使う場合はVRAMが4GB超、CPUで実行する場合はRAM 16GB以上かつ4コア以上が目安とされています。モバイルは対象外です。このため、顧客や社内メンバー全員へ同じ機能を提供する前に、対象端末を確認する必要があります。 2. 初回ダウンロードを利用者に見せられるか基盤モデルは、APIを初めて使うときに別途ダウンロードされます。利用可能か、ダウンロード中か、非対応かをAPIで確認し、画面上で状態を案内するのが基本です。「ボタンを押しても反応がない」状態にせず、初回準備には通信環境と時間が必要であることを表示しましょう。 3. オンデバイス推論と拡張機能の安全性を混同しない公式ドキュメントによると、モデルの初回ダウンロード後はネットワークを使わずに推論でき、モデル利用時にGoogleや第三者へデータは送信されません。ただし、これは拡張機能そのものの安全性を保証するものではありません。拡張機能がページ内容へアクセスする権限、外部サーバーへ送る独自処理、保存先、利用者への説明は別に確認すべきです。どのサイト・どのページの内容を読むのか取得する情報を最小化できるか外部通信を行うか。行うなら送信先と目的は何か結果や元データを保存するか利用者が機能を停止・削除できるか 4. 非対応時の代替手段を決める同じChromeでも端末性能やストレージ状況により、モデルを利用できないことがあります。対応可否を前提にしない業務フローを設計し、非対応の場合は、AI機能を使わず従来の画面操作だけを提供する、明示的な同意のもとでクラウドAIへ切り替える、管理者が用意した別の業務画面で処理する、といった代替手段を用意します。 5. APIの更新を前提に保守範囲を決めるBuilt-in AI APIsには、安定版、オリジントライアル、Early Preview Programなど提供段階が異なるものがあります。Prompt APIの拡張機能対応状況、対応する入出力、端末要件は更新され得ます。初期開発では、Chromeのバージョン条件、確認対象端末、動作確認手順を仕様書へ残し、更新時に再テストする範囲を決めておくと運用しやすくなります。

実装は「可否確認」から始める

基本的な流れは次のとおりです。拡張機能の画面を開いたとき、Prompt APIの利用可否を確認するダウンロードが必要なら、利用者の操作をきっかけに準備を始め、進捗を表示する利用可能になったらセッションを作成するページから取得する情報を必要最小限にして指示を送る生成結果を表示し、コピー・修正・確定は利用者が行えるようにする非対応・失敗時は代替画面へ切り替える特に、最初から「全ページを読ませて自動処理する」設計にしないことが重要です。対象ページ、抽出項目、出力形式を限定すると、精度・権限・利用者説明を管理しやすくなります。

クラウドLLM APIと使い分ける基準

オンデバイス処理は、端末上で完結させやすく、ネットワークがない状況でも使える可能性があります。一方で、対応端末の制約と、ブラウザ管理モデルという制約があります。クラウドLLM APIは、より大きな処理や集中管理、複数端末で同じ体験を提供したい場面に向きます。ただし、送信データ、利用規約、費用、認証、障害時の対応まで含めて設計する必要があります。ページ単位の要約・分類・下書き補助：Chrome内のオンデバイスAIを検討する高精度な分析・大量処理・組織横断のデータ連携：クラウドAIまたは専用バックエンドを検討する両方の要件がある：オンデバイスを第一候補にし、利用不可時だけ同意のもとでクラウドへ切り替える

まずは対象業務を小さく切り出す

Chrome内蔵AIを活かすなら、「どのモデルが最強か」よりも、「どのページで、どの操作を1回減らせるか」から始める方が成果につながります。たとえば、日々開く管理画面で、問い合わせを3種類に仮分類する。長い商品説明から確認事項だけを抜き出す。こうした小さな機能であれば、利用者の確認を残しながら検証できます。業務内容、利用端末、扱う情報、必要な精度を整理すれば、Chrome拡張機能内で完結させるべき範囲と、クラウドAIを併用すべき範囲を判断しやすくなります。対象業務の整理、Chrome拡張機能の試作、オンデバイスAIとクラウドAIの使い分け設計が必要な場合は、業務フローに合わせてご相談ください。

参考情報

The Prompt API | Chrome for Developers（公開：2025年5月20日、最終更新：2026年5月19日）Built-in AI APIs | Chrome for Developers（公開：2024年8月27日、最終更新：2025年9月12日）Get started with built-in AI | Chrome for Developers（公開：2024年12月12日、最終更新：2025年5月20日）Extensions and AI | Chrome for Developers