Vector DBの次の使い方 ― MiniMax × Zilliz Cloudと日本の公開事例から考えるAI Data Infrastructure

Last updated at 2026-09-21Posted at 2026-09-21

本記事の第1部は、ZillizのCustomer StoryHow MiniMax Scales Real-Time AI and Trillion-Scale Deduplication with Zilliz Cloudの紹介です。
第2部は、公開情報をもとに日本のLLM開発・推薦システム・学習データ前処理へ置き換えて考えた筆者の分析です。

第1部：MiniMax Customer Story

MiniMaxはZilliz CloudでリアルタイムAIと兆規模の重複排除をどうスケールさせたか

MiniMaxはZilliz Cloudを利用し、リアルタイム推薦とLLM学習データの重複排除という、性質の大きく異なる2つのAIワークロードを大規模に運用しています。

原文で示されている主な結果は次のとおりです。

5,000 QPS超でも30msのレイテンシ
リアルタイム推薦向け
学習データ重複排除のコストを3〜5分の1に削減
LLMデータ前処理を2倍高速化
従来のMapReduceベースのシステムとの比較
ペタバイト規模のデータ重複排除
ネイティブなMinHash + LSHエンジンを利用

MiniMaxについて

MiniMaxは、大規模言語モデルを提供する主要企業の一つであり、マルチモーダルAIシステムや、世界規模で利用される実アプリケーションを開発しています。

同社のコンシューマー向けプロダクト Talkie は、ユーザーが仮想エージェントを作成し、対話できるConversational AIプラットフォームです。月間アクティブユーザーは数千万人規模に達し、世界でも広く利用されるAI Companionプラットフォームの一つとなっています。

その裏側でMiniMaxは、大規模モデルの学習とインフラにも大きく投資しています。

事業が拡大するにつれて、同社が扱うデータの複雑性も増していきました。高並行・低レイテンシのユーザー体験を支える一方で、ペタバイト規模の非構造な学習データも管理しなければなりません。

MiniMaxはこうした課題に対応するため、性能と柔軟性の両方を維持しながら効率的にスケールできるデータ基盤としてZilliz Cloudを活用しています。

課題：成功によって、従来インフラでは対応困難な要求が生まれた

MiniMaxの成長は、AIインフラにおける重要な問題を浮き彫りにしました。

従来型のデータベースやデータ処理システムは、現代のAIアプリケーション特有の要求を前提に設計されたものではありません。

MiniMaxでは、オンライン側とオフライン側の双方でスケールの限界に直面しました。

RedisではAI規模のベクトル検索に対応できなかった

Talkieの急速なユーザー増加により、従来のキャッシュベースの仕組みでは対応しづらい性能要件が生まれました。

数千万人規模の月間アクティブユーザーに対して即時かつパーソナライズされた推薦を提供するため、Talkieでは数百万件のコンテンツに対してリアルタイムの意味的類似検索を行う必要がありました。

対象には例えば次のようなコンテンツがあります。

Voice Pack
Interactive Message
Conversation Starter

要求された性能は厳しく、5,000 QPSを超えるピークトラフィック時でも30ms未満で応答する必要がありました。

ユーザー数が数千規模だった段階では機能していたRedisベースの仕組みは、この規模になると十分な性能を提供できなくなりました。

その理由として次の2点が挙げられています。

Redisのインメモリアーキテクチャでは、百万級のベクトルを保持するコストが高い
ネイティブなベクトル操作が不足していたため外部プラグインに依存し、追加レイテンシと運用複雑性が生じていた

数十兆トークンの重複排除は、経済的に成立しなくなっていた

一方、LLM学習データパイプラインでは、オンライン推薦とはまったく別のスケール問題が発生していました。

数十兆トークンを含む学習データセットを処理するには、高度な重複排除が必要です。

重複コンテンツはモデルの過学習を招き、汎化性能を損なう可能性があります。しかし、この規模になると、従来の重複排除手法は計算量・コストの両面で現実的ではなくなっていきました。

MapReduceベースの処理では、一つのデータセットを処理するだけで数週間から数か月を要することがあり、多大なエンジニアリングリソースを消費し、モデルの学習サイクルそのものを遅らせていました。

Exact Matchでは計算負荷に耐えられず、Semantic Deduplicationも兆規模に適用すると処理コストが高くなります。

データセットがペタバイト規模へ拡大するにつれ、前処理のボトルネックが高度なモデル学習そのものの経済性を脅かすようになっていました。

解決策：オンラインとバッチという両極端のAIワークロードを支える専用基盤

MiniMaxが必要としていたのは、既存の汎用システムに後付けでAI機能を追加した仕組みではなく、AIワークロードを前提として設計されたインフラでした。

Zilliz Cloudは、リアルタイムのベクトル検索と、兆規模のバッチ処理効率という異なる要求を一つの基盤で支え、ワークロードごとに別々のシステムを管理する運用複雑性を削減しました。

5,000+ QPS向けの再設計：Redisの回避策からネイティブVector Searchへ

Talkieの推薦システムを大規模に支えるため、MiniMaxはベクトル検索基盤をZilliz Cloud中心に再設計しました。

新しい構成では、

8 Compute Units
7 Replicas

を配置し、高い水平スケーラビリティと、大量同時アクセス時の信頼性を確保しました。

Redisではベクトル操作のために外部プラグインや回避策が必要でしたが、Zilliz CloudはAIアプリケーション向けに設計されたネイティブなVector IndexとANN（Approximate Nearest Neighbor）Searchを提供します。

MiniMaxが既に利用していた32次元Embeddingは、追加の前処理や外部ツールを挟まず、そのままシステムへ投入できました。

Embeddingの取り込みからIndex構築、リアルタイム類似検索までの推薦パイプライン全体を、AIワークロード向けに最適化された統一APIで扱えるようになりました。

これは単なるデータベース移行ではなく、AI規模の処理を前提に設計されたインフラへの転換でした。

兆規模ワークロード向けに設計されたMinHash + LSHエンジン

学習データ側の課題に対して、MiniMaxはZillizのエンジニアリングチームと協力し、Zilliz Cloud内にネイティブに組み込まれたカスタムの重複排除エンジンを実装しました。

この仕組みは、

MinHash
Locality-Sensitive Hashing（LSH）

を組み合わせ、テラバイト〜ペタバイト規模のデータから冗長コンテンツを効率的に検出・削除します。

MinHash

MinHashは各文書をコンパクトなシグネチャへ圧縮します。

これにより、元の全文を総当たりで比較することなく、大量の文書間の類似性を効率的に推定できます。

LSH

MinHashでシグネチャを作っても、すべての文書ペアを比較すれば依然として高コストです。

LSHは類似するデータを同じバケットへ入りやすくすることで探索対象を大幅に絞り込み、全ペア比較を行うことなくNear-Duplicate候補を高速に見つけられるようにします。

MiniMaxは独立したDeduplication Serviceを新たに構築するのではなく、MinHash + LSHエンジンをZilliz CloudのIndexing System内で動作させました。

Embedding Insert、Index構築、Approximate Queryと同じAPI群を利用できるため、ワークフローを分断せず、データ量の拡大に合わせて分散・水平スケールできる構成となりました。

結果：高速化、コスト削減、運用簡素化

統一されたインフラによって、MiniMaxの2つのMission-Critical Workloadで定量的な改善が得られました。

Talkieのリアルタイム推薦：ピーク時でも30ms未満

Redisから移行した後、TalkieのRecommendation Engineは、5,000 QPSを超えるトラフィック急増時でも30ms未満というレイテンシ目標を安定して満たしました。

Vector-nativeなアーキテクチャによってSemantic Matchingの精度も向上し、推薦品質とユーザーEngagementの向上につながりました。

Multi-Replica構成によって、それまで課題だったAvailabilityとStabilityも改善しました。

Talkieが数千万人規模のユーザーへ拡大しても、大きな性能劣化なく安定稼働を続けられるようになりました。

また、Redisの高コストなインメモリ要件をなくしたことでインフラ費用も低下しました。

Zilliz CloudのComputeベースのモデルにより、必要に応じてリソースを増減でき、Redisの固定的なMemory Overheadより柔軟な運用が可能になりました。

Data Deduplication：2倍高速、3〜5倍の効率改善

カスタムMinHash + LSH実装によって、MiniMaxの学習データ管理も大きく変わりました。

従来のMapReduceシステムと比較して、

処理速度：2倍
コスト：3〜5分の1

となり、10億文書規模の重複排除を日常的な処理として経済的に実行可能になりました。

さらに重要なのは学習データ品質です。

重複データを効率よく削除することで、過学習の原因となりうる冗長データを減らし、モデルの性能と汎化能力の改善につなげられます。

DeduplicationがEmbeddingやSimilarity Searchと同じシステムに統合されたことで、別々のツールやパイプラインを管理する必要も減り、運用をシンプルにできました。

MiniMaxはその後、MinHash + LSHの能力を当初のDeduplication以外のデータ前処理ワークフローにも展開し、AI研究の新しい取り組みに活用しています。

今後：同じVector-native Foundationをマルチモーダルへ

Zilliz Cloud導入後、MiniMaxはTalkie以外の新しいAIプロダクトへVector Infrastructureを拡張しています。

同じVector-nativeな基盤を再利用し、

Image Embedding
Audio Embedding
Text Embedding

を扱うマルチモーダルなユースケースへ展開しています。

MinHash + LSH Engineも追加のData Pipelineへ適用され、モデル学習やDataset Refinementの反復を高速化しています。

MiniMaxの成長に合わせて、検索レイヤーを都度再設計することなくスケールできる柔軟性を持たせることが狙いです。

第2部：MiniMax実装を超えて見る、ZillizのAI Data Infrastructure

ここからは原文翻訳ではなく、MiniMax実装から離れて、現在Zillizが公式に公開している一般機能と、日本の公開事例を分けて整理します。

MiniMax事例で確認できるのは、OnlineのRealtime Recommendationと、OfflineのTraining Data Deduplicationです。一方、現在のZilliz Cloudは、Realtime Servingに加えて、Data Lake上の探索やBatch-orientedなSimilarity Searchにも機能領域を広げています。

この第2部では、

Zilliz公式Documentationで確認できる一般機能
日本企業・研究Projectが公開している実際の課題
その両者を並べた上での「筆者の整理」

を明確に分けます。

共通する技術的な軸は、大量のDataから、似ているもの・条件に合うものを探し、次の処理へ渡すRetrieval / Similarity Operationです。

1. Online：Recommendation / Searchを支えるRetrieval Layer

Online側では、Vector SearchがProductのCritical Pathに入ります。

User / Item / Content
        ↓
     Embedding
        ↓
Vector Search + Filter
        ↓
Candidate Retrieval
        ↓
Reranking / Business Logic
        ↓
Recommendation / Search

Zilliz Cloudでは、Vector SearchにScalar / ARRAY / JSONなどのFilterを組み合わせられます。また、継続更新されるDataにはUpsertやConsistency Level、Serving時のThroughputにはReplicaを利用できます。

重要なのはANN単体の速度だけではなく、Insert / Update、Filter条件、Recall、Latency、Peak QPS、Replica、IndexingとSearchのResourceまで含めたProduction設計です。

2. Offline：DedupだけではないTraining Data Operations

Training Data側では、DeduplicationはSimilarity Operationの一つにすぎません。

Web / PDF / Code / Image / Audio / Synthetic Data
                       ↓
                 Data Lake
                       ↓
          Search / Filter / Similarity
                       ↓
        Candidate Dataset / Sample Set
                       ↓
             Training / Evaluation

Zilliz Cloudでは、このようなOffline / Intermittent Workload向けに、External Collection、On-Demand Search、Large TopKなどが提供されています。

External Collection

External Collectionは、AWS S3やIcebergなど外部Storage / TableのDataをZilliz CloudへCopyせずにQuery Layerとして扱う機能です。

On-Demand Search

Training Data ExplorationやBatch Searchは、常時Trafficが流れるOnline ServiceとはResource Patternが異なります。On-Demand Searchでは、Similarity Search / Queryを必要なときに実行し、RequestがないとComputeを自動Suspendできます。

2026年9月時点ではPublic Previewで、Enterprise Projectや対応Regionなどに制約があります。利用時には最新の公式Documentationを確認する必要があります。

Large TopK

Large TopKは、対応Collectionで返却可能なEntity数を最大1,000,000まで拡張し、Candidate Generation、Model Evaluation、Data Mining、Large-scale Similarity Searchなどを想定しています。

ここでのポイントは、Zillizを「Dedup Engine」としてだけ見るのではなく、Training Dataに対するSimilarity Search / Dataset Exploration / Candidate Retrievalを共通化するRetrieval Layerとして見ることです。

3. 日本でも、この2種類のInfrastructure課題はすでに現れている

以下の日本事例は「この会社がZillizを使うべき」という意味ではありません。確認したいのは、MiniMax事例で見えたOnline RetrievalとTraining Data Operationsの課題が、日本でも実際に現れているかです。

3.1 LINE VOOM：MilvusでBatch RecommendationからRealtime Retrievalへ

LINE VOOMでは、Embedding生成・保存・Candidate Extractionの一部がDaily Batchだったため、新規PostがRecommendation Candidateへ入るまで最大1日のDelayがありました。

そこでEmbeddingをOnlineで保存し、Realtime ANN Searchを行うVector DBとしてMilvusを導入しています。公開記事ではIndex Type、CPU、Scale-up / Scale-out、Replication、QPS、Latency、Recallなどを実Dataで検証し、導入後には次の改善を報告しています。

投稿後7日以内にRecommendation Exposureされた新規Post数：12%改善
投稿当日にRecommendation Exposureされた新規Post数：39倍以上
LINE VOOM: MilvusによるRealtime Recommendation
日本語版

2026年には、LINEヤフーが別途運用しているValdについても、約4年間のProduction Operationから得た知見が公開され、Recall / Latency / Throughput、Insert時のIndexing負荷、Replica、Resource IsolationなどがProduction上の重要項目として説明されています。

Valdの長期運用Best Practice

筆者の整理

LINE VOOMは、日本でもRealtime Vector RetrievalがProductのCritical Pathに入っていることを示しています。

3.2 Preferred Networks：MinHashLSHを自社で最適化するほど、Training Data Dedupは重い

PFNはPLaMo-100Bで約460B Tokenの日本語Dataset構築にMinHash Deduplicationを利用し、PLaMo 2のPost-trainingでも文字13-gram MinHashとFaissを利用しています。

さらに2025年10月、PFN Pretrain TeamはLarge-scale Dataset向けMinHashLSH自体の改善を公開しました。Datasetが10^10 orderまで大規模化すると、Signature保持とCandidate MatchingがMemory Bottleneckになります。

LSHにBloom Filterを組み合わせたLSHBFでは、80GB CorpusでBaselineに対し、

Processing Time：38.4%削減
Memory Usage：87.2%削減

を報告しています。

筆者の整理：

PFNのようにInfrastructureを自社開発できる組織では、MinHashLSHそのものを最適化するアプローチが取られています。

この事例が示すのは、Training Data DeduplicationがAlgorithmだけでなくMemory / Runtimeまで専用最適化が必要なInfrastructure Problemになっていることです。

さらに、MinHashLSH単体ではなく、Dedup後のDataset Exploration、Similar Sample Retrieval、大規模Candidate Generation、Data Lake上のSearch、Training / Evaluation向けDataset Selectionまで含めて見る方が自然です。

3.3 Swallow：DedupからQuality Filteringへ

Swallow Corpus Version 2では、Common Crawlから抽出した約83億の日本語Pageに対してDeduplicationを行い、日本語Page全体のDedup完了に約1か月を要したことが公開されています。

2026年のGPT-OSS Swallowでは、Continual Pre-training Corpusは400B Tokenで、その半分近くをSwallow Corpus v3.2が占めています。v3.2は2025年3月までのCommon Crawlから日本語Web Pageを抽出し、Deduplication + Quality Filteringを行って構築されています。

さらにGPT-OSS Swallow / Qwen3 Swallowでは、Swallow Corpusから合成したQA Dataや、推論過程を含むSynthetic Post-training Dataも学習に利用したことが公開されています。

筆者の整理

公開情報を時系列で見ると、SwallowのData Pipelineは単純な Crawl → Dedup → Train だけではなく、Dedup → Quality Filtering → Synthetic / Curated Data → CPT / SFT / RLへ広がっています。

ここで言いたいのはSwallowがZillizを必要としているということではなく、Training Data Processingが「一度だけの前処理」から、複数Stageで繰り返すData Operationへ変化しているという点です。

3.4 LLM-jp：Webだけでなく、PDF・Mid-training・SFT・DPOへ

LLM-jp Corpus v4は総量19.5兆Token、日本語6,880億Tokenで、Web Dataに加え、Wikipedia、PDF / HTML、特許、法律、国会議事録など複数Sourceを含みます。

2026年5月には、国立国会図書館WARPのURL Listをもとに収集した約5,000万件のPDFからなるLLM-jp PDF Collection v1を公開しました。公式発表では、PDFから抽出したTextはLLM-jp Corpus v3以降に含まれ、実際のLLM Trainingに利用されていると説明されています。

現在のLLM-jp Release Pageでは、Pre-training Corpusの最新版としてLLM-jp-corpus v4.1が掲載されているほか、

LLM-jp-midtraining-corpus v2
llm-jp-4-thinking-sft-data
llm-jp-4-33b-thinking-dpo-data
そのほかのLLM-jp-4系DPO Data

が公開されています。

2026年8月公開のLLM-jp-4 33Bも、Base ModelはPre-training + Mid-training、Thinking ModelはSFT + DPOというTraining Stageを明記しています。

筆者の整理

重要なのはCorpus Sizeだけではなく、Training Dataが

Web Corpus
PDF
Domain-specific Data
Mid-training Corpus
SFT Data
DPO Data

のように複数Stageへ分かれ、それぞれを生成・更新・再利用する必要が出ている点です。

Data Assetが増えるほど、運用上は「どのDataを使うか」「どのDatasetに何が含まれるか」「特定条件のSampleをどう抽出するか」といったDataset Operationsが複雑になります。

Similarity Search、Dataset間の近似重複確認、Domain / Quality条件でのSample Selection、Evaluation Failureに近いSampleの探索は、そうしたData Operationsに対してVector Retrievalを適用できる一般的なUse Caseであり、LLM-jpが現在これらをZillizで実施しているという意味ではありません。

4. Zillizの位置づけ

Zillizの価値は、「DeduplicationができるVector Database」ではなく、Online ServingからTraining Data OperationsまでSimilarity-based Retrievalを共通化できるInfrastructureとして捉える方が自然です。

                AI DATA INFRASTRUCTURE

Online / Serving                 Offline / Training Data

Recommendation                  Data Lake / Corpus
Search                          PDF / Synthetic / SFT / DPO
      │                                  │
      ▼                                  ▼
Vector Search                    Search / Similarity
Filter / Update                  Filter / Candidate Retrieval
      │                                  │
      ▼                                  ▼
Product                       Dataset / Evaluation / Training

MiniMax Customer StoryのDeduplicationは、このOffline側の一つの具体例です。

5. Zillizで考えるTraining Data Retrieval

公開されているZilliz Cloudの機能を組み合わせると、Training Data側では次のような構成を考えられます。

Object Storage / Data Lake
Text / Code / Image / Audio / Metadata
              │
              ▼
      External Collection
              │
      Vector + Scalar Index
              │
              ▼
       On-Demand Search
              │
         Large TopK
              │
              ▼
 Candidate Dataset / Sample Set
              │
              ▼
 Training / Evaluation Pipeline

Zillizが担当するのはModel Trainingそのものではなく、巨大なData Collectionから次に使うDataを検索・抽出するLayerです。

Zillizの公式Documentationで直接確認できる用途としては、Exploratory Retrieval、Batch Similarity Search、Data Mining、Candidate Generation、Model Evaluation、Large-scale Similarity Searchがあります。

これらをTraining Dataに適用する場合、Metadata Filterを組み合わせたSample SelectionやCandidate Dataset作成といった設計が可能です。

なお、これはZilliz Cloudの公開機能を組み合わせた一般的な設計であり、MiniMaxがこのArchitectureを採用しているという意味ではありません。

まとめ

MiniMaxのCustomer Storyは、OnlineのRealtime RecommendationとOfflineのLarge-scale Training Data Deduplicationという2つのWorkloadを示しています。

日本の公開情報を見ると、LINE VOOMではRealtime Vector RetrievalがProductionに入り、PFNではMinHashLSHそのものをMemory / Runtimeの観点から最適化する必要が生じ、SwallowではDedupからQuality Filteringへ、LLM-jpではWeb、PDF、Mid-training、SFT、DPOへTraining Data Assetが拡張しています。

ここから見えるのは、AI Infrastructureの課題がModelだけではなく、その前後にあるDataをどう探し、比較し、選び、繰り返し利用するかへ広がっていることです。

ZillizをRAG専用DatabaseやDedup Engineとしてではなく、TrainingとServingの双方でSimilarity-based Data Operationsを支えるRetrieval Layerとして見ると、MiniMax事例の意味も、日本のAI開発に対する適用範囲もより広く見えてきます。

参考資料

Zilliz / Milvus

日本の公開事例

Disclaimer
第1部はZilliz Customer Storyの内容を日本語化したものです。
第2部では、Zillizの一般的な製品機能と、日本企業・研究Projectが公開している技術情報を分けて記載しています。
日本の各組織がZilliz Cloudを利用している、MiniMaxと同一のArchitectureを採用している、あるいはZillizの導入を検討していることを意味するものではありません。
「筆者の整理」「筆者の理解」と記載した箇所は、公開情報を並べた上での筆者個人の解釈です。企業固有の事実としては扱っていません。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up