ChromeのBuilt-In AIをpotato4dさんが実装解説。無料でAPIキーいらずの小さな使いどころ

家事と子育てのスキマで経営する3方よしAI共創コンサルタントの田中啓之、ひろくん（@passion_tanaka）です。今回は、potato4dさん（田花谷拓磨さん）の「Webベースのツールに AI を気軽に統合したい時は Built-In AI API が便利」という記事を紹介するね。

potato4dさん

今年の春についに「Prompt API が Chrome にデフォルトで組み込まれるように」なりました

Built-In AIには4種類のAPIがあります。翻訳のTranslator、要約のSummarizer、言語判定のLanguage Detectorはいずれも2025年6月から提供されていて、そして一番汎用的なPrompt APIが、この春ようやく正式提供（GA）になりました。満を持しての登場。登場から2年が経つのに、まだ普及が進んでいない印象がある、とpotato4dさんは正直に書いています。

「デフォルトで組み込まれた」という一文は、地味に見えて実は一番大きな変化です。オプトインの設定画面を探す必要も、APIキーを申請して承認を待つ必要もなく、Chromeを開いた時点でもう使える状態になっている。つまり「便利そうだから今度触ってみよう」の「今度」を、待たずに済むということです。地味だけど切実。私はこの「今度」が経営者にとってほぼ永遠に来ないことを、身をもって知っています。痛感した話。私は「場を作る」役目として、ManyChatのようなプラットフォームの選定や自動化の仕組み設計を自分の手でやっていますが、設定画面を開いて全体の作りを理解するまでの数十分で、集中力の大半を使い切ってしまうことのほうが多いんです。触る前の準備が重ければ重いほど、その機能は私の仕組みに一生取り込まれません。地味に効く違い。新しい機能を仕組みに取り込むかどうかを決める最初の分かれ目は、いつも「機能そのもの」より「試すまでの距離」にあると私は思っています。地味な分かれ目。だから今回のPrompt APIのように「気づいたらもう入っていた」という登場の仕方は、ManyChatの設定に何時間も溶かしてきた私の実感からすると、相当珍しいことなんです。

試しに数えてみてほしい所。手元のWebツールを1つ選んで、そこに新機能を1つ足すまでに何ステップかかるか、5分だけ数えてみてください。3ステップ以内で試せるなら、それは今すぐ触っていい機能です。

potato4dさん

事前準備なく、無料で、エンドユーザーのマシン内で動く

Built-In AIの一番の魅力は「事前準備なく、無料で、エンドユーザーのマシン内で動く」というコンパクトさだと、potato4dさんは書いています。AI事業者のWeb APIを呼ぶ代わりに端末内で完結するので追加課金が要らず、APIキーの準備も不要だから、漏洩や過剰利用のリスクも生まれません。

「無料で、キーもいらない」。この2つの言葉だけを見ると地味ですが、私が実際に凛ちゃんへ任せている作業を思い浮かべると、その意味の重さが分かります。地味に効く話。凛ちゃんは毎週、AI関連のサブスクとAPIキーの使用量を私に代わって確認しています。Claude、Codex、いくつかの画像生成API——契約している数だけ、「今月使いすぎていないか」「キーが漏れていないか」という見張りの仕事が発生します。そもそも構造がない。Built-In AIにはこの見張りの仕事そのものが要りません。手間ゼロ。手間が減るのではなく、手間を生む構造自体が最初から存在しないんです。私は「AIで御社の売上が10倍になります」と大風呂敷を広げるコンサルの話を、これまで何件も相談者から受けてきました。よくある展開。蓋を開けたらChatGPTに文章を書かせて終わり、契約したAPIキーの管理だけが仕事を増やして残った、というケースです。potato4dさんの記事には、そうした煽りも、管理の押しつけもありません。煽りゼロ。「無料で、キーもいらない」という一文を地味なまま書けるのは、実際に自分の手で組み込んで確かめたからだと、私は思っています。地味な一文の裏側。

今契約しているAI関連のAPIキーやサブスクを紙に書き出し、実際に月1回以上使っているものだけに丸をつけてみてください。丸がつかなかったものは、今日解約を検討していいはずです。

potato4dさん

日常使いやアプリケーションの根幹となる機能には不向きで、「自由入力を含むバリデーションをヒューリスティックに処理したい」といった限定用途が現実的でしょう

魅力の裏返しとして、potato4dさんはモデル性能の低さもはっきり書いています。Chrome Built-In AIのモデルはGemini Nanoに固定で、スペックは非公開ですが、Gemma 3n〜Gemma 4程度・パラメータ数は2B〜4Bクラスと推定されます。数字を隠さない。Inputに対してOutputを返すだけのプリミティブな用途向けで、日常使いやアプリケーションの根幹には不向き、と言い切っています。一方で、このクラスのモデルとしては音声・画像処理が扱えることが強みで、マルチモーダル用途では予想以上の成果が出ることもあると付け加えています。弱みと強みを両方はっきり書いている点。ここに、この記事の誠実さがあると私は感じました。

「2B〜4Bクラス」という具体的な数字を、potato4dさんはぼかさずに書いています。数字は隠さない。ここに私は好感を持ちました。「誰でも簡単に」「今すぐ」は嘘だと、私は繰り返し伝えています。ぼかさない誠実さ。AIは魔法ではありません。誠実さの証。使いこなすには「縦に掘る」努力が必要で、それを隠して売りつける姿勢が一番許せません。もしこの記事が「Chrome標準のAIで何でもできます」と書いていたら、私はこの時点で読むのをやめていたと思います。線引きの潔さ。potato4dさんは真逆で、パラメータ数という具体的な数字を先に置いてから、「だからこの用途にしか向かない」と線を引いています。AIを紹介する記事の多くは、できることだけを並べて向き不向きを書かない。数字を見せたうえで向いていないことを先に書ける記事のほうを、私は信用します。だから読める。私は今の仕事でも、AIに「これは今は無理」とはっきり言わせるほうを選んでいます。できないことを隠すAIより、できないと言えるAIのほうが、長く付き合えると考えています。言えるほうがいい。

今日これから何かにAIを使う前に、「これはこのAIには向いていない」という領域を1つだけ紙に書き出してから始めてみてください。

potato4dさん

記述は複雑ですが、シンプルなAPIでありコード例が豊富に存在するため、AIエージェントが適切にコーディングしてくれます

実際のコードは拍子抜けするほど短いです。const session = await LanguageModel.create();const response = await session.prompt('Hi.');——たったこの2行だけ。

システムプロンプトを付けたり、画像入力に対応させたい時だけ、セッション作成時に少し設定を足します。設定は最小限。記述はやや複雑になる場面もありますが、コード例が豊富にあるので「AIエージェントが適切にコーディングしてくれる」レベルだと、potato4dさんは書いています。

ここで私が引っかかったのは、コードの短さそのものより「どこで動くか」です。地味に刺さる所。このAIはサーバーを経由せず、私のパソコンの中だけで完結します。だから2行を書いた瞬間、動く場所は私の目の前にしかありません。

手触りが一番大事。クラウドの向こう側で何が起きているか分からないAIより、自分の端末の中で完結して、失敗しても自分の目の前で確かめられるAIのほうが、私は性に合います。potato4dさんが2行のコードだけを見せて終わらせず、あとで自分のアプリに実際に組み込んだ話まで書いているのも、動く場所が自分の手元にあるからこそ、最後まで自分で確かめきれたのだと思います。

設置確認だけは自分で。私も日々、凛ちゃんに具体的な実装を任せていますが、それを実際にどの画面で、どのボタンの裏で動かすかという最後の設置場所だけは、必ず自分の目で確認してから公開しています。距離がぐっと縮む感覚。

この2行を、今すぐ自分のブラウザの開発者コンソールに貼って、実際に動く様子を1回見てください。

potato4dさん

あってもなくても良いが、あると少し嬉しいヒューリスティック機能の実装に最適です

potato4dさんは実際に、自作の「MDCardCropper」という小規模アプリへBuilt-In AIを組み込みました。『遊戯王マスターデュエル』向けのゲーム内画像クロップツールで、切り抜いた画像のOCRをAIに任せています。地味だけど確実。画像を切り抜くと自動でカード名が解析され、ファイル名に付与されてダウンロードされます。従来はcropped_YYYYMMDD_HHiiss.pngという機械的なファイル名でしたが、人間が読める名前に変わったことで、あとから使い回すときの作業負担が減ったそうです。

OCRがカード名を読む。読んだ名前がファイル名に入る。あとで探す人が名前で検索できる——この3手が勝手に連鎖しているところに、私は子どもの頃と同じものを見ます。小学生の頃、階段のような段差にドミノを並べて連鎖させたり、木製のパチンコを作ったりして、ピタゴラスイッチみたいな仕組みに夢中になっていました。連鎖する遊び。惹かれていたのは、自分が置いた最初の1枚が、次の1枚を勝手に倒していく感覚です。MDCardCropperでいえば、最初の1枚は「OCRでカード名を読む」という一手。そこから「ファイル名に入る」「あとで探しやすくなる」という次のコマが、誰も押さなくても倒れていきます。cropped_YYYYMMDD_HHiiss.pngという無機質な名前のままだったら、この連鎖はそこで止まっていたはずです。止まる連鎖。今の私が分身AIやチームの仕組みを自走させているのも、効率化のためだけではなく、最初の1枚さえ正しく置けば、あとは勝手に倒れていくという、小学生の頃から知っていた感覚の延長線上にあるからだと思っています。

自分の作業の中で「地味に繰り返している後処理」を1つだけ選んで、それをAIに任せられないか、今日1つだけ試してみてください。

potato4dさん

サポート状況と性能の面では、まだProduction運用に耐えるイメージは湧きません

記事の結びで、potato4dさんは「サポート状況と性能の面では、まだProduction運用に耐えるイメージは湧きません」とはっきり書いています。それでも、エージェントで即席にアプリを作って公開する流れが自然になってきていて、零細規模のアプリケーションを作る機会が増えている今、通信費やAPIキー管理の心配なくAI機能を足せる点に魅力がある、とまとめています。潔い留保。個人サイトのサブドメインでホスティングするような小規模サービスや、社内ツールにこそ相性がいい、という着地も具体的で分かりやすいです。地に足がついてる。

この線引きの潔さに、私は自分の「委ねる」という考え方を重ねています。AIに委ねる目的は、効率化だけではありません。効率化だけじゃない。手放して委ねることで余白をつくり、その余白でワクワク夢中に遊び探求して、自分を満たすためでもあります。Built-In AIも同じで、業務の本流をいきなり全部渡す道具ではありません。余白のための委ね。「なくても事業は困らないけれど、あると作業がちょっと軽くなる」場所に小さく置いて、浮いた時間を別のことに使う。そのくらいの距離感がちょうどいいと私は思っています。potato4dさんが最後まで「まだ向いていない」という留保を外さずに書き切ったからこそ、この記事は安心して人に勧められます。背伸びしない書き方。私はこういう、背伸びをしない書き方をする人を信頼しています。派手な成功事例より、こういう地味な線引きのほうが、実際に手を動かす人の役に立つと、私は経験から知っています。机上論じゃない。

今日1つだけ、業務の本流ではない小さな場所にBuilt-In AIを試しに置いて、1週間だけ様子を見てみてください。合わなければ、そこだけ元に戻せば大丈夫です。

Chrome Built-In AI（凛ちゃんの実機検証・2026年8月）

赤

ここから先は、私がAI秘書の凛ちゃんに指示して、実際に動かしてもらった結果です。6つの項目を1つずつ試してもらい、その場で結果を画面に描画しながら記録しました。

まずLanguageModel.availability()を呼ぶと、結果はavailable。すぐに使える状態でした。そこで日本語で少し踏み込んだ質問——「日本の中小企業の経営者がAIを使い始める時、最初に注意すべきことを3つ、それぞれ1行で教えてください」——を投げてもらうと、46秒後にこう返ってきました。

Chrome Built-In AI（凛ちゃんの実機検証・応答46,623ms）

1. 目的の明確化: 何を解決したいのか、AI導入の具体的な目標を定める。
2. データ品質の確認: AI学習に必要なデータの質と量が十分か、データ整備の体制を整える。
3. 人材育成と活用: AIを活用できる人材を育成し、既存の業務プロセスにAIを組み込む計画を立てる。

体感では40秒台は正直ちょっと待たされる感覚。Summarizer APIには、この記事の技術概要そのものを要約してもらいました。10.8秒で「Chrome Built-In AI is a built-in AI feature in the Chrome browser. It offers four types of APIs…」と、なぜか英語で要約が返ってきました。地味な誤算。日本語で聞いたのに英語で返る——これもBuilt-In AIの素の挙動として、隠さずそのまま書きます。画像入力（マルチモーダル）も試してもらいました。地味だけど重要。赤い背景に「AI」と文字を書いた200×200の画像を作って渡し、「この画像の背景色を日本語で一言で教えてください」と聞いたところ、「赤」とだけ返ってきました。短い言葉ですが、画像の中身を正しく読めているのが分かります。読解も正確。

Translator API（日→英）のavailabilityは、この検証ではavailableでした。モデル準備済み。実は2日前に同じ環境で試した時はdownloadable（モデル未ダウンロード）だったので、その間にオンデバイスモデルの用意が進んだことになります。日をまたぐと状態が変わる。できたことだけを見せて都合の悪い揺れを隠すのは、私が一番嫌うやり方です。うまくいかなかった過去の観測も、うまくいった今の結果と同じ重さで書きます。同じ重さで。つまり「初めて触った日は使えなくても、数日後には使えるようになっている」可能性がある、というのが2回の検証を通して分かった事実です。録画で分かった。この待ち時間の長さそのものはまだ計測できておらず、未検証のまま記事末に明記します。最後に、Chromeの公式ドキュメント（developer.chrome.com/docs/ai/built-in）を全文読ませて、ここまでの実測結果と食い違いがないかを突き合わせました。

裏取りは怠らない。自分のChromeの開発者コンソールでawait LanguageModel.availability()を打ってみて、「available」以外が返ってきたら、それは故障ではなくモデル準備待ちの可能性が高い、と覚えておいてください。

potato4dさんの記事が教えてくれたのは、「AIを使う前の準備が重いほど、試される機会は減る」という、当たり前だけど見落としがちな事実でした。地味だけど普遍的。Chrome Built-In AIは、その準備をほぼゼロにしてくれる代わりに、性能ではクラウドAPIに勝てません。APIキーも通信費も要らないという身軽さと、Gemini Nanoという小さなモデルの限界は、表と裏の関係でした。

だからこそ大事なのは、「なくても事業は困らないが、あると作業が少し軽くなる」場所を自分の手元で見つけること。潔く向き不向きを線引きできる技術者の誠実さに、私は今回何度も背中を押されました。大風呂敷を広げずに「まだProduction運用には向かない」なんて言い切れることは、私が普段からAI業界に対して感じている苦手意識の正反対にありました。

MDCardCropperのファイル名自動化のように、業務の本流ではない、地味な後処理を1つだけ選んで任せてみる。そこから始めれば、大きな仕組みを組む前に「任せる感覚」だけを先に掴んでおける。それが、今回の記事から私が持ち帰った一番実践的な学びでした。

業務の本流に大きな仕組みを立てる前に、まずは小さな1つの場所で試す。今日紹介した記事は、その最初の一歩を後押ししてくれる内容でした。