EmbeddingGemma 2 — テキスト・コード・画像・動画・音声を1つの埋め込み空間に載せる 740M の Apache 2.0 モデル
Google が 2026-10-06 に EmbeddingGemma 2 を公開した。テキスト、コード、画像、動画、音声を1つの共有埋め込み空間に載せるマルチモーダル埋め込みモデルで、パラメータ数は 7.4億（テキスト専用なら 2.7億まで落とせるモジュラー構成）、ライセンスは Apache 2.0。コンテキスト長は 8,000 トークンで、公式換算では音声約5.5分、画像29枚、動画58フレームに相当する。量子化時のメモリ要件は Pixel 11 Pro でテキスト専用 191MB、フルマルチモーダル 567MB とされ、端末上で動く規模である。MTEB Code で 78.68、公式は「1B 未満のマルチモーダル埋め込みモデルの中で先頭」と表現している。配布は Hugging Face と Kaggle、Gemini Enterprise Agent Platform の Model Garden にも追加予定。
ニュース原文を読む ↗要約
Google が EmbeddingGemma 2 を公開しました。テキスト、コード、画像、動画、音声を1つの共有埋め込み空間に載せるマルチモーダル埋め込みモデルです。
「1つの空間に載る」ことが、この発表の中身です。
社内資料を検索対象にしようとすると、現実にはテキスト、スキャンした PDF、スライドの画像、会議の録音、研修動画が混ざっています。従来はこれを扱うのに、モーダルごとに別の埋め込みモデルを用意し、それぞれ別のベクトル空間で検索して結果をマージする構成が必要でした。「会議の録音と議事録を横断して探す」ようなことが、構造的に難しかったわけです。
同じ空間に載るなら、テキストのクエリで音声を引けます。 構成が1つになり、ベクトルストアも1つで済みます。この単純化が、実装コストと運用コストの両方に効きます。
規模は端末で動くサイズです。 パラメータ数は **7.4億（740M）**で、**テキスト専用なら 2.7億（270M）**まで落とせるモジュラー構成を持ちます。量子化時のメモリ要件は、公式が Pixel 11 Pro でテキスト専用 191MB、フルマルチモーダル 567MB という数字を出しています。スマートフォン上で動くということです。
ライセンスは Apache 2.0 です。 商用利用に対する制約が少なく、製品に組み込めます。 これは「API 経由でしか使えない埋め込みモデル」との決定的な違いです。
コンテキスト長は 8,000 トークンで、公式の換算では音声約5.5分、画像29枚、動画58フレームに相当します。動画58フレームという上限は実務上の制約として押さえてください。 長い動画を丸ごと1ベクトルにする用途には向きません。
ベンチマークは MTEB Code で 78.68、MAEB でも結果を出しており、公式は「1B 未満のマルチモーダル埋め込みモデルの中で先頭」と表現しています。一部ではより大きい競合モデルを上回るとしています。
配布は Hugging Face と Kaggle で、Gemini Enterprise Agent Platform の Model Garden にも追加予定です。デプロイは MediaPipe、LiteRT、transformers.js などに対応します。transformers.js が挙がっているのは、ブラウザ内で動かせるという意味です。
想定用途として公式が挙げているのは、オンデバイスのセマンティック検索、RAG パイプライン、コードのインデックス、メディアライブラリの整理、プライバシー優先のアプリケーションです。
何が変わったか
- EmbeddingGemma 2 が公開された（2026-10-06）
- テキスト・コード・画像・動画・音声を1つの共有埋め込み空間に載せる
- パラメータ数 7.4億（740M）。**テキスト専用は 2.7億（270M）**まで落とせるモジュラー構成
- ライセンスは Apache 2.0
- コンテキスト長 8,000 トークン。公式換算で音声約5.5分 / 画像29枚 / 動画58フレーム
- 量子化時のメモリ要件は Pixel 11 Pro でテキスト専用 191MB、フルマルチモーダル 567MB
- ベンチマークは MTEB Code 78.68。公式表現は「1B 未満のマルチモーダル埋め込みモデルの中で先頭」
- 配布は Hugging Face / Kaggle、Gemini Enterprise Agent Platform の Model Garden にも追加予定
- デプロイは MediaPipe / LiteRT / transformers.js などに対応（ブラウザ内実行も可能）
業務インパクト（一般企業向け）
社内検索・社内 RAG を検討している組織には、構成を見直す材料になります。
現在の構成を確認してください。 社内文書検索を作っていて、画像や音声を「対象外」にしているなら、それはモデルの制約が理由だった可能性があります。1つのモデルで横断できるなら、対象を広げる判断ができます。 特に議事録と会議録音、研修資料と研修動画のように、同じ内容がテキストと非テキストで二重に存在する組織では、効果が出やすいです。
Apache 2.0 かつオンデバイスで動く点は、データを外に出せない案件で決定的です。 医療、金融、自治体、製造業の設計情報——「クラウドの埋め込み API にデータを送れない」という制約がある領域では、従来「だから RAG は難しい」で止まっていました。端末上またはオンプレで動くモデルなら、その前提が変わります。 ただし埋め込みだけがオンデバイスでも、生成側が API なら意味が薄いことに注意してください。どこまでを外に出さないのかを先に決める必要があります。
検討時に必ず測るべきは、日本語での検索精度です。 公式が出しているベンチマークは MTEB Code（78.68）と MAEB です。日本語のビジネス文書での精度は、これらの数字から分かりません。 自社の実文書で、実際の検索クエリを50件ほど用意して上位 N 件の正解率を測るのが、唯一信頼できる判断材料です。「ベンチマークで先頭」は選定の理由にはなりません。
動画58フレームという上限は、設計に直接効きます。 長時間の研修動画を丸ごとベクトル化する用途には使えません。シーン分割やチャプター単位でのチャンク化が前提になります。この分割設計が実装の主要な工数になると見積もってください。「モデルが対応しているから動画検索ができる」ではありません。
既存のベクトルストアを持っている組織は、移行コストを計算してください。 埋め込みモデルを変えると、既存のベクトルは全部使えません。 全文書の再埋め込みが必要です。文書数が多いと、これ自体が数日かかる作業になります。「新しいモデルの方が良い」だけでは移行の理由になりません。 対象モーダルが広がることで得られる価値と、再埋め込みのコストを比べてください。
副業・個人活用視点
小規模案件での「社内検索」が、現実的に作れる範囲に入ります。
これまで小規模の社内検索案件は、埋め込み API の従量課金と、モーダルごとのモデル構成で見積もりが膨らみがちでした。Apache 2.0 で端末やサーバー上で動くモデルなら、推論コストが固定費側に寄ります。 月額の従量課金を嫌うクライアントには、この構成の方が説明しやすいです。
狙い目は「写真とメモが混ざっている現場」です。 建設、不動産、設備保守、飲食——現場の記録が写真とテキストメモで残っている業種は多いです。そして写真は検索できないまま溜まっています。 「現場写真を文章で探せます」は、業務の実感に直結する提案です。汎用の社内 AI 導入より、ずっと刺さります。
transformers.js 対応は、個人開発者にとって重要です。 ブラウザ内で埋め込みを計算できるなら、サーバーを持たずに動くツールが作れます。データが端末から出ないので、プライバシーを売りにできます。 個人が作るツールで「データを預かりません」と言えるのは、強い差別化です。サーバー費用がかからないので、無料公開して集客に使う構成も成り立ちます。
ポートフォリオとして作るなら、日本語での精度測定まで含めてください。 「EmbeddingGemma 2 で検索を作りました」は量産されます。「日本語のビジネス文書50件・クエリ50件で正解率を測り、既存モデルと比較した」まで出せる人は少ないです。 そしてこの測定結果そのものが、受託の提案材料になります。 一度測っておけば、クライアントに「この規模の文書なら、この精度が出ます」と言えます。
注意点として、埋め込みモデルの差し替えコストを自分の見積もりに入れてください。 クライアントに納品した後でモデルを変えると、全文書の再埋め込みが必要です。 文書数が多い案件では、これが保守の工数として跳ね返ります。最初から「モデルを差し替えられる構造」で作るか、差し替え時の費用を契約に書いておくかのどちらかが必要です。ここを曖昧にしたまま納品すると、半年後に無償対応を求められます。