拡張にAIを足したいが、サーバーもAPIキー課金も用意したくない
Chrome拡張に「選択したテキストを要約する」「入力文をちょっと整える」のようなAI機能を足したいと思ったことはありませんか。私もQR Sendを作りながら何度も考えました。ただ実際にやろうとすると、大抵はOpenAIやGeminiのAPIキーをどこかに持たせて、サーバー経由で呼ぶ設計になります。
これが個人開発だと地味に重いんです。APIキーを拡張のコードに直書きするわけにはいかないので、バックエンドを1個立てる必要が出てきます。課金体系も自分で設計しないといけませんし、ユーザーが増えれば増えるほど自分の懐が痛みます。「ちょっとAIっぽい機能を足したいだけなのに」というのが正直な感想でした。
そんな中で見つけたのが、ブラウザに同梱されたオンデバイスモデル（Gemini Nano）をそのまま呼び出せる仕組みです。今回はこれをChrome拡張から使う方法を整理します。
サーバーもAPIキーも要らない、という発想
ChromeにはGemini Nanoという軽量モデルがブラウザ本体に同梱されていて、これをJavaScriptから呼び出せるAPI群が用意されています。代表格がPrompt APIで、他にもSummarizer（要約）・Writer（文章生成）・Rewriter（書き換え）・Translator（翻訳）・Proofreader（校正）といった用途別のAPIがあります。
すべてオンデバイスで動くのが最大の特徴です。テキストがネットワークに出ていかないので、外部サーバーにデータを送らずに済みますし、APIキーもトークン課金も発生しません。ユーザーが増えても自分の請求額が増えないというのは、個人開発者にとってかなり大きい話です。
Chromeの公式ブログでも、拡張機能へのAI組み込みが2026年のI/Oでまとまった形で取り上げられていて、直近1年でChrome Web Storeに新規登録される拡張のうちAIを使っているものが増えている、という言及があります。追い風は来ているようです。
まず動かしてみましょう
ではコードを見てみましょう。Prompt APIの基本形はシンプルで、モデルが使える状態かを確認してからセッションを作る、という2段構えです。
const availability = await LanguageModel.availability();
if (availability !== "unavailable") {
const session = await LanguageModel.create();
const result = await session.prompt("この文章を1行で要約して: " + text);
console.log(result);
}availability()は”available”（すぐ使える）・”downloadable”（初回ダウンロードが必要）・”downloading”（ダウンロード中）・”unavailable”（この端末では使えない）のいずれかを返します。いきなりcreate()を呼ぶのではなく、まずここでチェックするのが作法です。
“downloadable”だった場合は、create()にモニター関数を渡すとダウンロードの進捗を取れます。
const session = await LanguageModel.create({
monitor(m) {
m.addEventListener("downloadprogress", (e) => {
console.log(`${Math.round(e.loaded * 100)}% ダウンロード済み`);
});
},
});初回だけモデル本体（数GB規模）のダウンロードが走るので、ここでローディング表示を出しておくと親切です。2回目以降はブラウザ側にモデルがキャッシュされているので、この待ち時間は発生しません。
「拡張だから普通に動くだろう」と思ったら罠がありました
ここが今回いちばん正直に書きたいところです。Prompt APIはもともとWebページ向けに、origin trial（機能を限定公開して試すChromeの仕組み）という形で提供されていました。拡張機能向けにも別枠でorigin trialが用意されていた時期があり、そのころはchrome.aiOriginTrial.languageModelという専用の名前空間を使い、manifest.jsonにaiLanguageModelOriginTrial権限とtrial_tokensを書く必要がありました。
ところが調べていくと、この拡張機能向けorigin trialはすでに終了していて、Chrome 138以降は拡張のservice workerからでもself.LanguageModel（Webページと同じ書き方）で直接呼び出せる、という情報が複数の情報源で一致していました。つまり今から新しく書くなら、上のコード例のように素朴にLanguageModel.availability()を呼ぶだけでよいはずです。
ただ正直に言うと、ここは仕様が動いている最中の領域です（2026年8月時点）。過去に存在したaiLanguageModelOriginTrial権限やtrial_tokensの記述が残ったサンプルコードもまだネット上に多く残っていて、どのChromeバージョンの拡張から権限指定なしで動くのか、細部までは断定できませんでした。実際に組み込む前には、公式ドキュメント（developer.chrome.com/docs/extensions/ai）で自分のターゲットバージョンでの挙動を確認することをオススメします。
動作要件はけっこう重いので注意です
ここも先に正直に書いておきます。Gemini Nanoはオンデバイスで動く分、ユーザーの端末にそれなりの余力を求めます。
- ストレージ: Chromeプロファイルのあるボリュームに22GB以上の空き容量が必要です。ダウンロード後に空き容量が10GBを切ると、モデルは端末から削除されて再ダウンロード待ちになります
- GPU: 4GBを超えるVRAMが必要です（音声入力を使う場合はGPU自体が必須になります）
- GPUが無い場合の代替: CPUコア4つ以上・RAM16GB以上
- ネットワーク: 従量課金でない回線であること（初回ダウンロードのため）
正直、この要件を見たときは「思ったよりハードル高いな」と感じました。低スペックのノートPCや、ストレージが心もとない端末だとavailability()が”unavailable”を返してくる可能性があります。自分の拡張のユーザー層によっては、全員がこの機能を使えるわけではない前提で、AI機能はあくまで「使えたら使う」補助機能として設計するのが安全です。
使い所を考えてみる
私が最初にQR Sendで思いついたのは、送るURLに添えるメモを一言で要約してくれる機能でした。サーバーを経由せずに、ユーザーが入力したテキストをその場でSummarizer APIに渡すだけで完結します。
const summarizer = await Summarizer.create({
type: "tldr",
length: "short",
});
const summary = await summarizer.summarize(userInputText);この手のAPIはpopup.jsやcontent scriptからも呼べますし、拡張のservice worker（バックグラウンド）からも呼べます。ただしservice workerはアイドル状態になると停止するので、長い処理を挟む場合はservice workerが眠ってしまわないよう気をつけてください。この「service workerが寝る」問題自体は、以前MV3の実践ポイントの記事でも触れました。
また、AI機能をエディタで試しながら組み込むときは、拡張をリロードしてconsoleを確認する作業がどうしても発生します。この作業をAIエージェントに任せる話はchrome-devtools-mcpの記事で書きましたし、フロントの見た目の検証まで任せたい場合はClaude Codeの公式Chrome拡張を使う記事も参考にしてもらえればと思います。組み込みAIの検証ループそのものも、AIに手伝わせられる時代になりました。
審査への影響はまだ手探りです
もう一つ正直に書いておきたいのが、Chromeウェブストアの審査への影響です。Prompt APIやSummarizer APIを使うこと自体が新しい権限を要求するわけではなさそうですが、AI生成コンテンツを扱う拡張として、プライバシーに関する説明の書き方が変わってくる可能性はあります。私自身はまだこの機能をQR Sendに組み込んで審査に出した実績がないので、ここは今後試して確認したいところです（試したらまた記事にします）。以前、拡張にscripting権限を足しただけでも審査で聞かれることが増えた経験があるので、権限が絡む変更には慎重になっています。
クラウドAPIとの使い分けも考えておきたい
組み込みAIは万能ではありません。Gemini Nanoは軽量モデルなので、複雑な推論や大量のコンテキストを読ませたい処理には向いていないと感じます。私の感覚では、「選択したテキストを一言で要約する」「短い文章のトーンを整える」くらいの軽い処理には十分ですが、込み入った分析や長文の生成が要るなら、素直にクラウドのAPIを使ったほうが結果は安定しそうです。
また、端末側の要件を満たさないユーザーも一定数いる前提を忘れてはいけません。availability()が”unavailable”を返してきたら、機能そのものを非表示にするか、クラウドAPI側にフォールバックするか、あらかじめ設計しておく必要があります。「オンデバイスで動くから完璧」ではなく、「動く端末では無料で速い」くらいの位置づけで考えるのが実際的だと思います。
まとめ
というわけで、Chrome拡張に組み込みAIを足す話をまとめました。サーバーもAPIキーも要らず、ユーザーのブラウザに載っているGemini Nanoをそのまま呼べるのは、個人開発者にとって素直にありがたい選択肢です。
一方で、端末のスペック要件は軽くありませんし、拡張向けのAPI仕様はまだ動いている最中です。「今すぐ全ユーザーに配れる機能」というより「使える人には使ってもらう補助機能」くらいの位置づけで、availability()のチェックを丁寧に書いておくのが今のところの現実的な落としどころだと思います。私も自分の拡張に一つずつ試しながら組み込んでいくつもりです。実際に試してみた方がいたら、ハマったところなどコメントで教えてもらえるとうれしいです。
コメント