ジェミニ埋め込み: RAGとコンテキストエンジニアリングを支える

2025年8月1日原文(developers.googleblog.com)

概要

Gemini Embedding モデルの一般提供開始と開発者による急速な採用
文書検索・分析、RAG、分類 など多様な応用事例の紹介
コンテキストエンジニアリング によるAIエージェントの性能向上
各業界における 実装例と成果、他モデルとの比較
今後のAIエージェント基盤 としての重要性の強調

Gemini Embedding モデルの業界応用事例

Gemini Embedding モデル、開発者による高度なAIアプリケーション構築への活用
分類・セマンティック検索・RAG など従来用途に加え、 コンテキストエンジニアリング で運用文脈の完全提供
埋め込み技術 により、文書・会話履歴・ツール定義など重要情報を効率的にモデルのワーキングメモリへ統合

グローバルなコンテンツインテリジェンス向上（Box）

Box、Gemini Embedding を統合し、複雑な文書からの質問応答・洞察抽出を実現
gemini-embedding-001、正答率81%以上・他モデル比3.6%リコール向上
多言語対応 により、世界中のユーザーが多様な言語・地域コンテンツから洞察取得可能

金融データ分析の精度向上（re:cap）

re:cap、B2B銀行取引大量分類に Gemini Embedding を活用
F1スコア、従来Googleモデル比1.9%・1.45%向上（21,500件の取引データで検証）
高精度分類 により、顧客向け流動性インサイトの提供力強化

法務分野でのセマンティック精度（Everlaw）

Everlaw、大規模リーガルドキュメントの精密セマンティックマッチングに Gemini Embedding を採用
gemini-embedding-001、1.4百万件の専門文書で87%精度を達成（Voyage: 84%、OpenAI: 73%）
Matryoshka特性 により、情報を少次元で圧縮・検索効率とストレージコスト削減を両立

開発者向けコードベース検索の進化（Roo Code）

Roo Code、Gemini Embedding でコードベースのインデックス・セマンティック検索を実装
Tree-sitter との連携で論理的コード分割、曖昧なクエリにも高い関連性
LLM駆動のコード検索 で柔軟性・正確性・開発者ワークフロー適合性を向上

個別化メンタルウェルネス支援（Mindlid）

Mindlid、会話履歴理解によるリアルタイム適応型AIウェルネスコンパニオンを提供
gemini-embedding-001、420msの低遅延と82%のTop-3リコール率（OpenAI比4%向上）
関連性・応答速度 の大幅改善によるユーザー体験向上

AIアシスタントの文脈理解と効率化（Interaction Co.）

Poke（Interaction Co.）、Gmailからの情報抽出・タスク自動化に Gemini Embedding を活用
ユーザーメモリ・関連メール抽出 の高速化・精度向上
100通のメール埋め込み時間、Voyage-2比90.4%短縮（21.45秒で完了）

次世代AIエージェントの基盤としての展望

AIシステムの自律性向上、提供する文脈品質が効果を左右
gemini-embedding-001 のような高性能埋め込みモデルが、情報検索・推論・自律行動型エージェント構築の要
導入開始方法 は Gemini API ドキュメント参照
パフォーマンス指標 は各開発者による報告であり、Googleの独自検証ではない旨の注意

Hackerたちの意見

マトリョーシカの埋め込みは面白そうだね。

「ジェミニ埋め込みモデル、gemini-embedding-001は、マトリョーシカ表現学習（MRL）技術を使ってトレーニングされていて、モデルが高次元の埋め込みを学ぶのを教えるんだ。その初期セグメント（またはプレフィックス）は、同じデータのよりシンプルで役立つバージョンでもあるんだ。output_dimensionalityパラメータを使って、出力埋め込みベクトルのサイズを調整できるよ。小さい出力次元を選ぶと、ストレージスペースを節約できて、下流アプリケーションの計算効率も上がるけど、品質はあまり犠牲にならない。デフォルトでは3072次元の埋め込みを出力するけど、品質を落とさずに小さいサイズに切り詰めることもできるよ。768、1536、または3072の出力次元を使うことをおすすめする。」

└

マトリョーシカのトリックは本当に面白いね。ここにいい説明があるよ: https://huggingface.co/blog/matryoshka いくつかのモデルで見たことあるけど、Nomic Embed 1.5が最初だったね。https://www.nomic.ai/blog/posts/nomic-embed-matryoshka

└

Googleのチームは、そのマトリョーシカ技術に夢中みたいだね。どこまでスケールするのか気になるな。

└

面白いけど、彼らが主張してる改善はそんなに画期的じゃないよね。

└

OpenAIのtext-embedding-3-largeやtext-embedding-3-smallの埋め込みモデルにはマトリョーシカ特性があるのかな？

こういうアプリケーションに関わってる人に聞きたいんだけど、テキストのエージェント検索と比べて埋め込みってまだ価値あるのかな？例えば、テキストファイルのディレクトリがある場合、全部の埋め込みをVDBに保存して使う方がいいのか、それともLLMが十分に良くなったから、ripgrepとか使って自分で検索させる方がいいのかな？

└

セマンティック検索はまだ重要だと思う。特にコーディングエージェントにとって、正規表現検索も急速に重要性を増してるね。

└

RAGを使うのに真剣に時間をかけてないけど、AWSのナレッジベースを使ってエージェント検索と比較した時は、結局エージェント検索（ClaudeコードSDK経由）に戻っちゃった。RAGには調整できる部分がたくさんあって、全体的に複雑だなって印象を受けた。もしかしたら、テキストの量が十分に多くなればその複雑さが報われるかもしれないけど、今はエージェント検索がすごくうまくいってて、始めるのもずっと簡単だよ。

└

もしあなたのLLMが十分に良ければ、grepやFTSエンジンを使ったツールコールの方が良い結果が得られると思うよ。良いモデルは「犬 OR 犬科」みたいに検索パターンを適応させることもできるし、以前はベクトルの類似性が大きな利点だったかもしれない。埋め込みを使うには色々と手間がかかる。チャンク戦略を決めて、埋め込みを実行して、素早く取り出せるように保存方法を考えなきゃいけない。大きなデータ量になると、埋め込みストアをメモリに保持しなきゃいけなくなることが多いから、結構な負担になるよ。去年は埋め込みにたくさん取り組んだけど、ツールベースの検索がこんなに強力になった今は、あんまり興味を失っちゃった。埋め込みを使ったツールベースの検索をつなげるのは探る価値があるけど、ripgrepから得られる結果が十分良ければ、かなりの追加労力をかける価値はないかもしれないね。

└

ちょっと気になるんだけど、テキスト以外のファイルはどうやって扱うの？PDFファイルがたくさんあったらどうするの？

└

使い方やスケールによるね。もし無構造テキストが100万件あったら（よくあることだけど、商品説明やユーザーレビューのウェブスクレイピングとか）、それに対して埋め込み検索をして、最も関連性の高いドキュメントを見つけたいよね。もし100個の.pyファイルがあったら、エージェントにはgrepツールでそれをナビゲートさせたい。

他のGCPユーザーに質問だけど、Googleの古い埋め込みモデルの積極的な廃止についてどう感じてる？毎年12ヶ月ごとにデータを再実行するためにお金を払わなきゃいけない気がする。

Hacker Newsで議論の続きを見る

ハクソク