- 【著者プロフィール】 山城 博規 / GMO天秤AI株式会社 やましろ ひろき 筆者
- GMO天秤AI株式会社 代表取締役社長。GMOあおぞらネット銀行でAI・DX推進、金融インフラエンジニアを経て現職。「特定のAIに依存しない」をコンセプトに、複数AIを同時比較できるプラットフォーム「GMO天秤AI」を運営。個人向けのFree・Lite、ビジネス向けのStandard・Bizの4プランを提供するほか、AIリスキリング事業も展開中。
2026年3月10日、Googleが「Gemini Embedding 2」を公開プレビューとしてリリースした。テキスト・画像・音声・動画・PDFを同じベクトル空間（データを数値の配列として表現した多次元の座標系）に埋め込める、初の"ネイティブマルチモーダル"エンベディングモデル（複数の種類のデータを統一的に数値化するAIモデル）だ。本記事では公式情報をまとめた上で、実際にAPIを叩いて5つの実験を行い、その実力を検証する。
概要
Gemini Embedding 2 とは
Google公式ブログによると、Gemini Embedding 2はGoogleが提供する初のネイティブマルチモーダル埋め込みモデルだ。従来のエンベディングモデルがテキスト専用だったのに対し、本モデルはテキスト・画像・音声・動画・PDFを1つのベクトル空間に統一的にマッピングできる。
これにより、例えば「AIコーディング」というテキストから関連する画像を検索したり、画像から類似テキストを見つけるといったクロスモーダル検索（異なる種類のデータをまたいで類似コンテンツを探す検索手法）が、単一モデルで実現できる。
スペック
Vertex AIドキュメントに記載されている主な仕様は以下の通り。
項目 | 詳細 |
モデルID |
|
ステータス | 公開プレビュー |
出力次元 | 最大3,072次元（MRL対応で任意に縮小可） |
最大入力 | 8,192トークン |
対応言語 | 100言語以上 |
リージョン | us-central1 |
入力モダリティごとの制限は以下の通り。
モダリティ | 制限 |
テキスト | 8,192トークン |
画像 | 最大6ファイル/リクエスト（PNG, JPEG） |
最大1ファイル、6ページ以内 | |
動画 | 最大1ファイル、80秒（音声付き）/ 120秒（音声なし） |
音声 | 最大1ファイル、80秒（MP3, WAV） |
料金
Gemini API料金ページによると、無料枠が用意されている。
入力タイプ | 無料枠 | 有料（/1Mトークン） | バッチ（50%オフ） |
テキスト | 無料 | $0.20 | $0.10 |
画像 | 無料 | $0.45（$0.00012/枚） | $0.225 |
音声 | 無料 | $6.50（$0.00016/秒） | $3.25 |
動画 | 無料 | $12.00（$0.00079/フレーム） | $6.00 |
個人での実験や小規模なPoC（概念実証：アイデアの実現可能性を検証するための試作）なら無料枠で十分まかなえる。今回の実験もすべて無料枠内で完了した。
主な特徴
Matryoshka Representation Learning（MRL） — デフォルトの3,072次元から、256次元まで任意に圧縮可能。ストレージやレイテンシ（応答遅延）とのトレードオフに応じて調整できる。
タスクタイプ指定 — RETRIEVAL_QUERY、RETRIEVAL_DOCUMENT などを指定して、用途に応じた最適化が可能。
ドキュメントOCR — PDF内の文字を自動認識して埋め込む。
APIの叩き方
Google AI StudioでAPIキーを発行すれば、REST APIとして fetch やcurlで直接叩ける。SDK（開発キット）も不要。
POST https://generativelanguage.googleapis.com/v1beta/models/gemini-embedding-2-preview:embedContent?key=API_KEY
{
"content": {
"parts": [{ "text": "埋め込みたいテキスト" }]
}
}
レスポンスの embedding.values に浮動小数点の配列（ベクトル）が返る。
検証：5つの実験で実力を測る
実験環境
実行環境: macOS上のNode.js（Claude Codeから直接実行）
API: Gemini Developer API（REST、SDKなし）
コスト: 全実験を通じて無料枠内
素材
テキストとして「AIコーディング」「経営・スタートアップ」「料理レシピ」の3テーマを用意し、それぞれ短文（30〜44字）、段落（217〜274字）、長文（560〜579字）の3サイズ、計9本を準備した。
画像はGeminiの画像生成モデルで5枚を生成した。AIコーディングのテーマで2枚（モニター構図とノートPC構図）、スタートアップ会議、料理シーン、そしてコントロール群として富士山の風景。
テーマA: AIコーディング（2枚）
モニター構図 | ノートPC構図 |
 テーマA代表 |  同テーマ別構図（類似度検証用） |
テーマB・C・コントロール（各1枚）
スタートアップ会議 | 料理(だし取り) | 富士山と桜 |
 テーマB代表 |  テーマC代表 |  コントロール群（全テーマと無関係） |
実験1: テキスト埋め込みの基本動作
目的: 日本語テキスト9本を埋め込み、次元数と応答時間を確認する。
結果:
テキスト | 文字数 | 次元数 | 応答時間 |
AIコーディング(短文) | 42字 | 3,072 | 606ms |
AIコーディング(段落) | 274字 | 3,072 | 509ms |
AIコーディング(長文) | 579字 | 3,072 | 481ms |
スタートアップ(短文) | 44字 | 3,072 | 550ms |
スタートアップ(段落) | 243字 | 3,072 | 357ms |
スタートアップ(長文) | 565字 | 3,072 | 743ms |
料理レシピ(短文) | 34字 | 3,072 | 566ms |
料理レシピ(段落) | 217字 | 3,072 | 531ms |
料理レシピ(長文) | 560字 | 3,072 | 539ms |
考察: 全てのテキストが3,072次元のベクトルとして返される。応答時間は350〜750ms程度で、文字数による大きな差は見られなかった。日本語も問題なく処理される。
実験2: テキスト間の類似度マトリクス
目的: 9本のテキスト全ペア（36組）のコサイン類似度（ベクトル間の角度から算出する類似性の指標。1に近いほど似ている）を算出し、意味の近さを正しく捉えているか検証する。
結果（類似度 TOP 5）:
ペア | 類似度 |
AIコーディング(段落) ↔ AIコーディング(長文) | 0.8935 |
スタートアップ(段落) ↔ スタートアップ(長文) | 0.8420 |
スタートアップ(短文) ↔ スタートアップ(段落) | 0.8173 |
スタートアップ(短文) ↔ スタートアップ(長文) | 0.8062 |
AIコーディング(短文) ↔ AIコーディング(段落) | 0.7723 |
結果（類似度 BOTTOM 5）:
ペア | 類似度 |
AIコーディング(長文) ↔ 料理レシピ(短文) | 0.4783 |
AIコーディング(短文) ↔ 料理レシピ(段落) | 0.4719 |
スタートアップ(長文) ↔ 料理レシピ(短文) | 0.4607 |
スタートアップ(短文) ↔ 料理レシピ(短文) | 0.4567 |
AIコーディング(短文) ↔ 料理レシピ(長文) | 0.4479 |
考察: 同テーマ内のテキストは長さが違っても0.77〜0.89と高い類似度を示し、異テーマ（特にAI/スタートアップ ↔ 料理）は0.44〜0.48に落ちる。表現や長さではなく、意味の近さをしっかり捉えていることがわかる。短文同士でもテーマが同じなら高い類似度が出る点は、検索クエリ（短い）→ ドキュメント（長い）の検索ユースケースで心強い。
実験3: 次元調整（MRL）で精度は保たれるか
目的: 出力次元を256/768/1,536/3,072と変えたとき、類似度の順位関係が維持されるかを検証する。
結果:
次元数 | 平均応答時間 | AI ↔ Startup | AI ↔ Cooking | Startup ↔ Cooking |
256 | 461ms | 0.5981 | 0.4693 | 0.4885 |
768 | 460ms | 0.5992 | 0.4897 | 0.4581 |
1,536 | 506ms | 0.5949 | 0.4820 | 0.4527 |
3,072 | 511ms | 0.6028 | 0.4810 | 0.4567 |
考察: 全ての次元数で AI ↔ Startup > AI ↔ Cooking という順位関係が保たれた。256次元に圧縮しても類似度の大小関係は崩れておらず、MRLが正しく機能している。256次元なら3,072次元に対してストレージが12分の1になるにもかかわらず、実用上ほぼ遜色ない判別ができる。
応答時間にも次元数による有意な差は見られず、次元の縮小はサーバー側の計算量にはほぼ影響しないようだ。
実験4: クロスモーダル — テキストで画像を検索できるか
目的: テキストと画像を同じベクトル空間に埋め込み、テキストクエリで正しい画像を1位に持ってこられるか検証する。この実験がGemini Embedding 2の最大の売りであるマルチモーダル統一空間の真価を問うものだ。
画像の埋め込み
まず5枚の画像を埋め込んだ。テキストに比べて画像は処理が重い。
画像 | 応答時間 |
AIコーディング(モニター) | 2,249ms |
AIコーディング(ノートPC) | 1,295ms |
スタートアップ会議 | 1,404ms |
料理(だし取り) | 1,329ms |
富士山と桜 | 1,438ms |
テキスト埋め込みが500ms前後だったのに対し、画像は1,300〜2,200msと2〜4倍の時間がかかる。
画像同士の類似度
最も類似度が高かったペアは、同テーマ（AIコーディング）の2枚だ。構図は全く異なるが、「プログラミングの画面」という意味を捉えている。
類似度 0.80 — 同テーマの2枚が最も近い
| ↔ | |
全ペアの類似度は以下の通り。
ペア | 類似度 |
AIコーディング(モニター) ↔ AIコーディング(ノートPC) | 0.8021 |
AIコーディング(ノートPC) ↔ スタートアップ会議 | 0.6960 |
AIコーディング(ノートPC) ↔ 料理(だし取り) | 0.6758 |
料理(だし取り) ↔ 富士山と桜 | 0.6639 |
AIコーディング(モニター) ↔ 料理(だし取り) | 0.6569 |
AIコーディング(モニター) ↔ 富士山と桜 | 0.6443 |
AIコーディング(ノートPC) ↔ 富士山と桜 | 0.6365 |
AIコーディング(モニター) ↔ スタートアップ会議 | 0.6250 |
スタートアップ会議 ↔ 料理(だし取り) | 0.6014 |
スタートアップ会議 ↔ 富士山と桜 | 0.5985 |
同テーマ（AIコーディング）の2枚が0.80と最も高く、構図が違っても「プログラミングの画像」という意味を捉えている。異テーマ間は0.60〜0.70に分布し、意味的な距離が反映されている。
テキスト→画像 検索ランキング
各テーマの短文をクエリとして、5枚の画像を類似度順にランキングした。
クエリ: 「AIエージェントが自律的にコードを書いて、テストして、デプロイまでこなす時代が来た。」
1位にヒットした画像
順位 | 画像 | 類似度 |
1位 | AIコーディング(モニター) | 0.3713 |
2位 | AIコーディング(ノートPC) | 0.3313 |
3位 | スタートアップ会議 | 0.2557 |
4位 | 料理(だし取り) | 0.2552 |
5位 | 富士山と桜 | 0.2389 |
クエリ: 「シード期のスタートアップにとって、限られたリソースでPMFを達成することが最優先課題だ。」
1位にヒットした画像
順位 | 画像 | 類似度 |
1位 | スタートアップ会議 | 0.3157 |
2位 | AIコーディング(モニター) | 0.2760 |
3位 | 料理(だし取り) | 0.2612 |
4位 | AIコーディング(ノートPC) | 0.2604 |
5位 | 富士山と桜 | 0.1902 |
クエリ: 「鶏もも肉を一口大に切り、塩コショウで下味をつけてから片栗粉をまぶす。」
1位にヒットした画像
順位 | 画像 | 類似度 |
1位 | 料理(だし取り) | 0.2971 |
2位 | スタートアップ会議 | 0.2393 |
3位 | AIコーディング(ノートPC) | 0.2376 |
4位 | AIコーディング(モニター) | 0.2350 |
5位 | 富士山と桜 | 0.2197 |
考察: 3テーマ全てで、対応する正しい画像が1位にランキングされた。 これはかなり印象的な結果だ。
ただし注目すべき点もある。クロスモーダルの類似度（0.19〜0.37）は、テキスト同士（0.44〜0.89）と比べて全体的に低い。これはテキストと画像という異なるモダリティ間の「距離感」が、同モダリティ内の距離感とは異なることを意味している。実用上は、テキスト→画像検索とテキスト→テキスト検索で異なる閾値を設定する必要があるだろう。
また、AIコーディングのクエリに対してAI画像2枚が1位・2位に並んだ点は、同テーマの画像バリエーションを正しく認識できている証拠だ。
実験5: タスクタイプ指定の効果
目的: RETRIEVAL_QUERY / RETRIEVAL_DOCUMENT というタスクタイプを指定した場合と指定しなかった場合で、検索精度に差が出るか検証する。
短文のAIコーディングテキストをクエリ、3テーマの長文をドキュメントとして類似度を比較した。
結果:
設定 | AI(long) | Startup(long) | 料理(long) |
指定なし | 0.7523 | 0.5408 | 0.4479 |
RETRIEVAL_QUERY / DOCUMENT | 0.7523 | 0.5408 | 0.4479 |
考察: 今回のテストでは完全に同一の結果となった。タスクタイプ指定による精度差は確認できなかった。
これはプレビュー版ゆえの可能性もあるし、タスクタイプの効果がより大規模なデータセットや特定の検索パターンで発揮される可能性もある。GA（正式版）リリース時に再検証したいポイントだ。
まとめ
観点 | 評価 |
日本語テキスト埋め込み | 問題なく動作。意味の類似度も正確 |
応答速度 | テキスト: 350〜750ms、画像: 1,300〜2,200ms |
次元調整（MRL） | 256次元でも順位関係を維持。実用に耐える |
クロスモーダル検索 | 3テーマ全てで正しい画像が1位。 最大の売りは本物 |
タスクタイプ指定 | 今回は効果確認できず。要再検証 |
料金 | 無料枠あり。本記事の全実験が無料で完了 |
Gemini Embedding 2の最大の価値は、やはりマルチモーダル統一空間だ。テキスト・画像・音声・動画を1つのベクトル空間で扱えることで、「テキストで画像を検索する」「画像で関連ドキュメントを探す」といったユースケースが、複数モデルを組み合わせることなく実現できる。
プレビュー版のため本番利用にはまだ慎重さが必要だが、RAG（検索拡張生成：外部データを検索して回答生成に活用する手法）やナレッジベースの構築を検討しているなら、今のうちに触っておく価値は十分にある。
