本記事は Zilliz 公式ブログの A Developer's Guide to Exploring Milvus 2.6 Features on Zilliz Cloud（2026年2月11日 / Ivan Tang）を日本語向けに翻訳・再構成したものです。日本語環境固有の観点は「🇯🇵」マークのセクションとして加筆しています。
シリーズ構成
Milvus 2.6 で追加された機能のうち、開発者が書いていた「接着剤コード」を消せるものを 4 回に分けて扱います。
| 回 | テーマ | 内容 |
|---|---|---|
| ① Embedding Function（本記事） | 埋め込み生成をデータベースに寄せる | 生テキストを入れるだけでベクトル化される |
| ② Lexical Highlighting | なぜヒットしたのかを見せる | マッチ箇所のハイライト、RAG のデバッグ |
| ③ N-gram インデックス | 部分一致を速くする |
LIKE %〜% の高速化、日本語全文検索の設計 |
| ④ Decay Ranker と Boosting | ランキングを業務要件に寄せる | 鮮度による減衰、メタデータによるブースト |
各回は独立して読めます。日本語環境で特に効くのは ③ と ④ だと思いますが、まずは全体の背景から。
はじめに：ベクトル検索 + 接着剤コードからの脱却
Milvus はもともと、大規模向けの高性能なオープンソースベクトルデータベースとして始まりました。ベクトル ANN 検索が主機能でした。
ところが開発者コミュニティが大きくなるにつれ、要望が広がっていきました。全文検索、ブースティング、JSON や struct といった半構造化データ型のサポート。これは「類似度検索以外の機能がないと AI アプリの開発が進まない」という、データベース機能の収斂に向かう流れの反映でもあります。
そして 2.6 では、その収斂が機能要望のレベルではなくデータベース本体に現れました。減衰ベースのランキング、フィールドレベルのブースティング、構造化・非構造化をまたいだハイブリッドフィルタリング —— これまで開発者がデータベースの外側で組み立てていたものが、データベースの機能になりつつあります。
言い換えると、Milvus 2.6 は「ベクトル検索 + 接着剤コード」から「もう少し進んだ検索エンジン」への移行地点です。本シリーズでは、その中からいくつかの機能について、何ができて、いつ使い、どう使うのかを見ていきます。
なお本シリーズの内容は Zilliz Cloud で GA になっているため、そのまま試せます。
Embedding Function（Data In, Data Out）
「埋め込みの生成自体をデータベース側でやってくれないか」と思ったことはないでしょうか。Embedding Functions は、OpenAI・VoyageAI・Cohere といった外部の埋め込みサービスを Milvus が呼び出し、生テキストをベクトルに変換してくれる機能です。
どう動くのか
Embedding Function を設定した状態で "すばしっこい茶色の狐が、怠け者の犬を飛び越える。" を挿入したとします。Milvus はこれをプロキシ層で捕まえ、プロバイダ固有の埋め込みパイプラインに流し、モデルが返したベクトルを格納します。
検索時には同じ変換が逆向きに走ります。クエリテキストは、インデックスに到達する前にベクトル化されます。
嬉しいのは、埋め込みワークフローの管理をデータベース側に寄せられることです。取り込み時にデータベースが裏で埋め込みを生成してくれるので、API 連携、バッチ処理、リトライ、レート制限、失敗時のハンドリングを自前で持たなくてよくなります。
使い方
Zilliz Cloud で始めるには 3 ステップです。
正しく設定できていれば、コンソールのコレクションスキーマ画面に Embedding Function が表示されます。
あとは生テキストを投入するだけで、埋め込みが自動生成され、指定した dense ベクトルフィールドに格納されます。検索クエリ側も埋め込み生成が不要になります。
ハマりどころとして、バッチサイズの上限があります。
2026-01-21 14:03:12,902 [ERROR][handler]: RPC error: [insert_rows], <MilvusException: (code=65535, message=numRows [1000] > function [openai]'s max batch [640])>
ベストプラクティス
- バッチサイズの上限を守る（上限値はエラーメッセージに出ます）。これはモデルプロバイダ側の API 呼び出しあたりトークン上限に抵触しないための安全機構です。たとえば OpenAI は 1 回の API 呼び出しあたり最大 300,000 トークンという制限があります
- 長文・大きな文書は挿入前にチャンク分割する。 OpenAI は全埋め込みモデルで入力テキストあたり 8192 トークンの上限があります
- VoyageAI や Cohere はデフォルトで長文を自動的に切り詰めますが、これに頼ると文書の末尾が黙って失われます
🇯🇵 補足：日本語では「文字数 ≒ トークン数」の感覚が英語と大きく異なる
OpenAI は英語について「1 トークン ≈ 4 文字」を目安として示していますが、日本語では漢字・ひらがな・カタカナ・記号の構成や、使用するモデル／トークナイザによって 1 文字あたりのトークン数が大きく変わります。そのため、英語文書の文字数を基準にチャンクサイズを設計すると、想定より早くモデルの入力上限に達する可能性があります。
特に重要なのは、文字数ではなく実際のトークン数を基準にすることです。OpenAI なら tiktoken、Voyage AI なら各モデルに対応した tokenizer / count_tokens() などを使い、実データのトークン分布を確認してからチャンクサイズとバッチサイズを決めるのが安全です。
🇯🇵 補足：生テキストが外部に出ることを、先に確認する
もうひとつ、日本の案件では設計に入る前に確認しておきたい点があります。
Embedding Function は、生テキストを外部の埋め込みサービス（OpenAI など）に送信します。 データベースが代行してくれるぶん実装は楽になりますが、データの流れとしては「社内文書が外部 API に出ていく」ことに変わりありません。
金融・製造・自治体・医療といった領域では、この時点で採用可否が決まることがあります。便利さと引き換えに何が起きているかは、アーキテクチャ図に明示しておいたほうが、後の審査で揉めません。
外部送信ができない環境では、埋め込み生成を閉域内の自前推論に置き、Milvus にはベクトルを投入する従来の構成になります。この場合 Embedding Function の恩恵は受けられませんが、本シリーズで扱う残り 3 つの機能（ハイライト、N-gram、Decay / Boosting）は問題なく使えます。
次回
第 2 回は Lexical Highlighting です。検索結果の「なぜこれがヒットしたのか」を可視化する機能で、日本語ではアナライザ設定の検証ツールとしても使えます。
参考リンク
原記事
- A Developer's Guide to Exploring Milvus 2.6 Features on Zilliz Cloud（Ivan Tang, 2026年2月11日）
ドキュメント
関連ブログ