ベクトルDBの選び方：RAGで失敗しないためのAWSサービス徹底比較


# 1. はじめに


LLM（大規模言語モデル）を用いた**生成AI**が普及し、**RAG（Retrieval-Augmented Generation）** という外部検索＋LLM回答の仕組みが注目されています。

RAGでは**ベクトルDB**が重要な役割を果たし、**クエリや文書の埋め込みベクトル**を高速に検索します。

本記事では、**AWS東京リージョン**で使える代表的なベクトルDBサービスを比較し、どれを選べばよいかの目安を提供します。

---

# 2. 比較表まとめ（結論パート）

まずは**結論だけ**をさっと確認したい方向けに、東京リージョンで利用可能な**5つのベクトルデータベースサービス**を**一目で比較**できる表を用意しました。

より詳しい解説は **「3. 詳細レポート」** で行います。興味のある方はそちらもご覧ください。

以下、**RAG（Retrieval-Augmented Generation）や生成AI用途**で利用できるAWS東京リージョンのベクトルデータベース5種類を、**行と列を入れ替えた表形式**で比較します。

**大規模対応(スケール)** / **検索速度** / **更新反映** / **コスト** / **無料枠** / **主な特徴** の6項目について、**記号（◎, ○, △, ×）＋簡単な説明**を付与しています。

|                              | **Amazon OpenSearch**<br>(k-NN)                                                         | **Aurora PostgreSQL**<br>(pgvector)                                                          | **Amazon MemoryDB**<br>(Redis互換,HNSW)                                                     | **Amazon DocumentDB**<br>(MongoDB互換,IVFFlat)                                               | **Pinecone**<br>(SaaS,HNSW)                                                                                                               |
|------------------------------|-------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **大規模対応<br>(スケール)**   | **◎**<br>（分散検索により<br>数億〜数十億ベクトルも容易）                                   | **○**<br>（単一Auroraクラスターで<br>数百万〜数千万規模まで）                                     | **△**<br>（インメモリ＋1シャードが<br>基本、巨大データは苦手）                                                        | **○**<br>（レプリカ増設による読み取り<br>スケールはある程度可能）                                             | **◎**<br>（専用ベクトルDBで自動シャーディング、<br>大規模でも対応）                                                                                          |
| **検索速度**                | **○**<br>（msオーダで高速、<br>パラメータ調整で性能UP）                                        | **○**<br>（HNSW/IVFFlatで<br>十分高速）                                                       | **◎**<br>（インメモリで<br>msより速い応答が可能）                                                               | **○**<br>（IVFFlatで数百万レベルなら<br>ms〜数十ms程度）                                                 | **◎**<br>（高い最適化で安定高速、<br>LangChain等とも連携容易）                                                                                                 |
| **更新反映**                | **○**<br>（定期refresh次第で<br>ほぼリアルタイム）                                             | **○**<br>（書き込み後に<br>即検索可能）                                                       | **◎**<br>（書き込みとほぼ同時に<br>検索反映される）                                                              | **○**<br>（数秒のラグはあるが<br>リアルタイム性は高め）                                                 | **○**<br>（アップサート後<br>数秒で検索可能）                                                                                                         |
| **コスト**                  | **△**<br>（ノード数増により<br>コスト肥大しやすい）                                            | **○**<br>（SQL+既存RDB運用で<br>比較的コントロールしやすい）                                   | **△**<br>（メモリ容量に依存、<br>大規模時は急増）                                                               | **△**<br>（IOリクエスト課金で<br>費用が増えやすい）                                                     | **△**<br>（無料枠以外は有料プランで<br>大規模時に費用が高騰）                                                                                                      |
| **無料枠**                  | **12ヶ月**<br>(t2/t3.small + 10GB)                                                           | RDS版のみ無料<br>(Aurora本体は対象外)                                                           | **2ヶ月**<br>(t4g.small + 20GB/月)                                                                               | **1ヶ月**<br>(t3.medium + 5GBストレージ等)                                                               | **Starterプラン**<br>(約10万ベクトル上限、USリージョン)                                                                                                  |
| **主な特徴**                | - **テキスト検索＋ベクトル**<br>ハイブリッドが強力<br>- 大規模分散OK<br>- Serverlessも利用可<br>- 運用チューニング必要 | - **SQL＋ベクトル**で<br>構造化も一元管理<br>- HNSW/IVFFlatインデックス<br>- 水平スケールは限定的<br>- IOPSコスト注意                      | - **インメモリ超高速**<br>リアルタイムRAGに最適<br>- 索引は単一シャードに集約<br>- 大容量時はメモリコスト増<br>- バックアップ復元時に要注意 | - **JSON＋ベクトル**を<br>同じDBに格納<br>- MongoDB互換API<br>- IOコスト増の懸念<br>- 完全なMongoDBではない点に注意              | - **ベクトルDB専門SaaS**<br>大規模も自動スケール<br>- 運用負荷ほぼゼロ<br>- 海外リージョン利用で遅延注意<br>- 機密データを外部送るリスク要検討               |


上記のように、それぞれのサービスには**一長一短**があります。
素早い結論としては：

- **テキスト検索も統合し、ハイブリッド検索のユースケースが多い** ⇒ **OpenSearch**  
- **RDBベースで既存SQL環境と統合したい** ⇒ **Aurora PostgreSQL (pgvector)**  
- **超低レイテンシを最重視し、リアルタイム更新も頻繁** ⇒ **MemoryDB**  
- **ドキュメント指向DBでJSON＋ベクトルをまとめて管理したい** ⇒ **DocumentDB**  
- **インフラ運用を丸投げし、専門のベクトルDBを使いたい** ⇒ **Pinecone**  

ここで満足された方はこのままでもOKですが、さらに詳しく**どんな仕組みで動くか**、**導入時の注意点**などを知りたい方は次に進んでください。

以下では、それぞれの詳細を見ていきます。

:::note info
上部で十分にまとまっているので、以降は興味のある方のみ読んでください。
:::

---

# 3. 詳細レポート（必要な方のみ）

ここでは各サービスについて、**サービス概要**・**ベクトル検索機能の詳細**・**導入手順とユースケース**・**リスク評価**などを詳しく掘り下げます。
**RAG（Retrieval-Augmented Generation）** 向けにどのような利点・欠点があるかを中心に解説していきます。

## 3-1. Amazon OpenSearch Service

### サービス概要

**Amazon OpenSearch Service**は、オープンソースのOpenSearch（Elasticsearchから派生）をベースにした検索・分析プラットフォームです。
全文検索やログ分析をリアルタイムに行えるほか、**ベクトル検索にも対応**しています。
東京リージョンを含むマルチリージョンで提供され、**大規模データの分散検索**が可能です。
近年では**Serverlessモード**が追加され、**ベクトルエンジン**もサーバレスで利用できるようになりました。

OpenSearchは**テキスト検索機能**が非常に強力で、「ベクトルとキーワードのハイブリッド検索」が簡単に実装できる点がRAG用途に好評です。
たとえば「Embedding類似スコアが一定以上 AND タイトルに"特定キーワード"を含む文書」など、多彩なクエリ構成が可能です。

### ベクトル検索機能の詳細

OpenSearchのベクトル検索は、**k-NNプラグイン**を使って実現されています。
フィールドタイプに`knn_vector`を設定することでANN（Approximate Nearest Neighbor）検索が利用できます。
内部のアルゴリズムは**HNSW**（Hierarchical Navigable Small World）などいくつかあり、精度と検索速度をチューニングできるのが特徴です。

ベクトル数が**数十億規模**になってもシャーディングと分散ノードで処理でき、一定のミリ秒オーダーで検索可能とされています。
これは**大規模RAG**や**グローバルユーザ向けレコメンド**などにとって強力な選択肢になります。

### 導入手順と具体的なユースケース

1. **OpenSearchドメインの作成**  
   - AWSコンソールから「Amazon OpenSearch Service」を選び、ドメインを作成します。ノードタイプやAZ数、ストレージを指定し、東京リージョンを選択。
2. **ベクトルインデックスの作成**  
   - 以下のようにJSONでインデックスを作成し、`"type": "knn_vector"`を定義します。次元数や使用するANNアルゴリズムも指定可能。
     ```json
     PUT my-index
     {
       "settings": { "index": { "knn": true } },
       "mappings": {
         "properties": {
           "embedding": {
             "type": "knn_vector",
             "dimension": 768,
             "method": {
               "name": "hnsw",
               "engine": "faiss",
               "space_type": "cosine"
             }
           },
           "text": { "type": "text" }
         }
       }
     }
     ```
3. **データ投入**  
   - `_bulk` APIやクライアントライブラリで文書を登録し、その中にベクトルを含めます。
4. **類似検索クエリ**  
   - `POST my-index/_search`で`"knn": {...}`パラメータを指定し、ベクトルに類似した上位K件を取得。キーワード検索と組み合わせも可能。

**ユースケース例**: 
- 大量のFAQや製品ドキュメントを「全文検索」と「ベクトル検索」の両方で検索し、最適な回答を返すRAGシステム。
- ログの異常検知でログエントリをEmbeddingし類似パターンを検出する、画像検索（画像特徴ベクトル）などにも応用できます。

### リスク評価と注意点

- **クラスタ運用負荷**: OpenSearchはノード数やシャード分割などを適切に設定しないとスケールしきれない場合があります。メモリ不足やディスク不足のリスクに注意。
- **コスト増大**: ベクトル数・インデックスサイズの増加に伴い、多数のノードが必要になるとコストがかさみます。利用頻度が高い場合はServerlessに移行するなど検討が必要。
- **チューニング難易度**: HNSWのパラメータ（ef、Mなど）やインデックスrefresh設定を誤ると検索精度・速度が最適化されない恐れがあるため、事前の検証が望ましい。

---

## 3-2. Amazon Aurora PostgreSQL (pgvector拡張)

### サービス概要

**Amazon Aurora PostgreSQL**は、PostgreSQL互換のリレーショナルデータベースで、AWS独自のストレージレイヤーや最適化により高いパフォーマンスと可用性を実現します。
標準的なRDBMSとしての機能に加え、近年のアップデートで**pgvector拡張**が利用可能になり、**ベクトル型のカラム**を定義してANN検索が可能となりました。
RDBの強みを活かしながら**ベクトル検索を一元的に扱える**点が注目されています。

### ベクトル検索機能の詳細

Aurora PostgreSQLでは**pgvector**拡張モジュールを`CREATE EXTENSION vector;`で有効にし、テーブルにベクトル列を定義します。
さらに、**IVFFlat**または**HNSW**方式のインデックスを作成することで高速な近似近傍検索が可能です。
クエリはSQLで、`ORDER BY embedding <-> query_vector LIMIT k;`のように書くだけで**類似度順**にレコードを並べられます。

Aurora特有の読み取り最適化や並列処理により、**数百万〜数千万レコード**規模でも高速検索が期待できます。
また、**トランザクション管理**や**リレーショナルな結合**が必要なシーンでは特に便利です。

### 導入手順と具体的なユースケース

1. **クラスター作成**  
   - Aurora PostgreSQL互換モードでDBクラスターを立ち上げる。バージョン14以降でpgvector対応を選択。
2. **拡張有効化**  
   - `CREATE EXTENSION IF NOT EXISTS vector;`を実行してpgvectorを使えるようにする。
3. **テーブルとインデックス作成**  
   - 例:  
     ```sql
     CREATE TABLE documents (
       id SERIAL PRIMARY KEY,
       content TEXT,
       embedding VECTOR(768)
     );
     CREATE INDEX ON documents USING hnsw (embedding vector_l2_ops)
       WITH (m = 16, ef_construction = 256);
     ```
4. **データ投入・検索**  
   - ドキュメントに対するEmbeddingをINSERTし、`SELECT ... ORDER BY embedding <-> :query_vec LIMIT 5;` のように類似検索。

**ユースケース例**: 企業内FAQなどで**SQLによる柔軟な絞り込み**（例: テナントID、日時など）と**ベクトル類似検索**を合わせて実行。
既存の業務DBを拡張して、顧客情報や取引履歴と関連づけた高度なRAGができる。

### リスク評価と注意点

- **スケール面**: Auroraは単一クラスター内で大規模なベクトルを扱うと、ストレージIOPS・メモリが逼迫する可能性あり。**水平分割**が必要ならOpenSearch等の方が適しているケースも。
- **インデックス構築の負荷**: 大量データにHNSWインデックスを張る場合は時間とCPU・メモリを消費。並列化やバッチ投入でコントロールする。
- **コスト管理**: Auroraでは**プロビジョンドIOPS**や**ストレージ課金**があり、検索負荷が高いとコストが増大しやすい。Aurora Serverless v2で自動スケールを活用する方法もある。

---

## 3-3. Amazon MemoryDB for Redis

### サービス概要

**Amazon MemoryDB for Redis**は、Redis互換APIを提供する**インメモリ型**のマネージドデータベースです。
データをメモリ上に置くことで読み取りはマイクロ秒〜ミリ秒単位と**最速級**の性能を実現しつつ、マルチAZレプリケーションと永続化で耐久性も確保しています。
2023年には**ベクトル検索機能**（RediSearchベース）が追加され、**リアルタイムRAG**の実装に向いた選択肢となっています。

### ベクトル検索機能の詳細

Redisの検索モジュール「RediSearch」を利用し、**HNSW**アルゴリズムによるANN検索をインメモリで実行します。  
- `FT.CREATE`コマンドでベクトルフィールドを定義し、**M**（近傍リスト数）や**EF**（探索範囲）などHNSWのパラメータを設定。  
- `FT.SEARCH`コマンドでクエリベクトルを渡すことで、**単一桁ms**の超高速検索が可能。  
- データ更新してもすぐに索引へ反映されるため、**リアルタイム性**に強い。

### 導入手順と具体的なユースケース

1. **クラスタ作成**  
   - エンジンバージョン7.1以降で、ベクトル検索機能が有効化されたパラメータグループを選ぶ。  
2. **インデックス作成**  
   - 例:  
     ```bash
     FT.CREATE idx:qa ON HASH PREFIX "qa:" SCHEMA question TEXT answer TEXT question_vector VECTOR HNSW ...
     ```
3. **データ投入**  
   - Redisコマンド（HSET等）を使ってベクトルを格納する。  
4. **検索**  
   - `FT.SEARCH idx:qa "*=>[KNN 5 @question_vector $vec AS score]"` などで類似度上位5件を取得。

**ユースケース例**:  
- **チャットボットのリアルタイム履歴検索**（新しい会話文をすぐにDBに登録し、対話の文脈に合わせてRAGを行う）  
- **瞬時にユーザー行動を反映するパーソナライズレコメンド**  
- **超低遅延が必須な金融取引の不正検知**など  

### リスク評価と注意点

- **インメモリコスト**: 全データをメモリに乗せるため、データ量増加に応じてノードのメモリサイズを拡大が必要。非常に大きなベクトルセットには不向き。  
- **シャーディング制限**: ベクトル索引は単一シャード内のみ扱えるため、**数千万〜億レベルのレコード**を扱う用途には現状厳しい。  
- **バックアップ時の再構築**: 再起動・リストア直後に索引のバックフィルが必要で、その間検索不可になる場合がある。可用性設計に注意。

---

## 3-4. Amazon DocumentDB (MongoDB互換)

### サービス概要

**Amazon DocumentDB**は、MongoDB互換のAPIとクエリ言語で**JSONドキュメントを扱える**フルマネージドDBです。
スケーラブルな分散ストレージとレプリカで高可用性を実現し、MongoDBのような開発体験を得られます。
2023年末から**ベクトル検索**に正式対応し、**DocumentDBだけでドキュメントと埋め込みを統合管理**できるようになりました。

### ベクトル検索機能の詳細

ドキュメント内にあるベクトル（数値配列）を**IVFFlat**方式のインデックスでANN検索し、Aggregation Pipelineの`$search`ステージでクエリを実行します。
- 索引作成時に`createIndex`で`vectorOptions`を指定し、**dimensions**や**similarity**（ユークリッド・コサイン・内積）を設定。  
- 検索クエリでは`{ $search: { vectorSearch: { path: "embedding", vector: [ ... ], k: 5 }}}`のように書くだけでOK。  
- **数百万スケール**のベクトルでも数十ms〜数百ms程度で回答可能。

### 導入手順と具体的なユースケース

1. **エンジンバージョン5.0のDocumentDBクラスター作成**  
2. **コレクションにベクトルフィールドを追加してドキュメントを格納**  
3. **索引作成**  
   ```javascript
   db.mycol.createIndex(
     { embedding: "vector" },
     { name: "vec_idx",
       vectorOptions: { dimensions: 768, similarity: "cosine", lists: 100 }
     }
   );
   ```
4. **検索クエリ**  
   ```javascript
   db.mycol.aggregate([
     {
       $search: {
         vectorSearch: {
           path: "embedding",
           vector: [ /* クエリベクトル */ ],
           k: 5,
           similarity: "cosine",
           probes: 3
         }
       }
     }
   ])
   ```
**ユースケース例**:  
- **JSONドキュメントとEmbeddingを一元化**し、RAGボットで回答生成。  
- 同一ドキュメントにタイトルやタグを持たせ、ハイブリッド検索（タグ絞り込み + ベクトル類似）を行う。  
- **既存のMongoDBツール**（ODMライブラリなど）を使い慣れたチームに特に適している。

### リスク評価と注意点

- **IVFFlatのパラメータ調整**: `lists`を増やすと精度向上だがメモリ・検索時間増。`probes`を増やすと精度が高まるがIO増。  
- **IO課金**: DocumentDBは**IOリクエストごとに料金**が発生する仕組み。クエリ回数が多いとコストが膨らむ可能性。  
- **MongoDB完全互換ではない**: 一部機能やバージョン差異があるため、Atlas検索等を使用している既存MongoDBアプリを移行する際は要テスト。

---

## 3-5. Pinecone（AWS Marketplace経由）

### サービス概要

**Pinecone**はAWS公式サービスではなく、外部の**専用ベクトルデータベースSaaS**です。
AWS Marketplaceから契約・決済を行うことで、請求を一本化できます。
**大規模ベクトル検索に特化したマネージドプラットフォーム**で、独自のスケーラリング技術により大量データでも一定の低遅延を提供しています。
インフラ管理不要で、**LangChainなど生成AIフレームワーク**との連携がスムーズです。

### ベクトル検索機能の詳細

Pineconeの内部実装は公開されていませんが、**HNSW型ANN**など高度に最適化されたエンジンを使っているといわれています。
ユーザはREST APIまたはSDKを通じて**インデックスを作成**し、ベクトルを`upsert`すると、バックグラウンドで索引が構築されます。

- メタデータも合わせて登録でき、**メタデータフィルタ**とベクトル類似検索の組み合わせが容易。  
- **自動シャーディング**により大規模データを複数ノードに分散し、スケーラブルにクエリを裁く。  
- **サービス運営側がインフラを全管理**しているため、ユーザはパラメータ調整などが最小限で済む。

### 導入手順と具体的なユースケース

1. **AWS Marketplace経由でPineconeをサブスク**  
2. **Pineconeコンソール/CLIでインデックス作成**  
   - ベクトル次元、ポッドタイプ、リージョン（有料プランで東京選択可）を指定。  
3. **データ投入**  
   - `upsert` APIにベクトルとID、メタ情報を送る。  
4. **クエリ実行**  
   - Query APIにクエリベクトルを送り、k近傍のIDとスコアを取得。  
   - フィルタ指定でメタ情報による絞り込みも可能。

**ユースケース例**:  
- **巨大コーパス**（数億文書以上）をEmbedding化して全社検索を提供。  
- 複数クラウド/オンプレからのアクセスを集約し、**マルチクラウドRAG**を実現。  
- LangChain等ライブラリでサンプルも豊富なので、**プロトタイプ開発**を素早く進めたいスタートアップや研究開発チームに好適。

### リスク評価と注意点

- **コスト**: 大規模データを扱うと月額費用が大きくなる可能性。無料Starterプランは約10万ベクトル程度と少量向けで、米国リージョンのみ。  
- **外部サービス依存**: AWSネイティブでないため、サービス障害時の対処や**ネットワーク遅延**に注意。機密データのEmbeddingを外部に送ることへのポリシー面検証も必要。  
- **上限コントロール**: 上限設定がないため、バグや誤操作でクエリ量・データ量が膨大になると**高額請求**になり得る。モニタリングとアラート設計が重要。

---

# 4. まとめと今後の展望

ここまでご紹介した5つのサービスは、AWS上で**RAG用途**に活用する代表的なベクトルデータベースです。
それぞれ**得意領域**と**注意点**が異なるため、自社の要件を整理した上で選定することが重要です。

### サービス別の総括

- **Amazon OpenSearch Service**  
  - **テキスト検索 + ベクトル**の総合力が高い  
  - 大規模データをマルチシャードで扱いやすい  
  - 運用・チューニングに一定の知識が必要  

- **Amazon Aurora PostgreSQL**  
  - **SQLでメタデータ・ベクトルを一元管理**できる  
  - 既存RDBワークロードに拡張しやすい  
  - 水平スケールの柔軟性はOpenSearchに劣る場合がある  

- **Amazon MemoryDB**  
  - **最速レイテンシ**が武器。リアルタイム更新も強い  
  - データ量が多いとメモリコストが跳ね上がる  
  - 1シャード内で完結するので超巨大データには不向き  

- **Amazon DocumentDB**  
  - **ドキュメント＋ベクトルを同じDBに保管**できる  
  - MongoDB互換で開発がスムーズ  
  - 大量クエリ時のIOコストやパラメータ調整に注意  

- **Pinecone**  
  - **インフラ運用を完全にお任せ**でベクトル検索に専念  
  - スケールが容易で数億〜数十億レベルに対応可  
  - 費用が高くなりがち、外部サービス依存のリスクあり  

### 選定時のポイント

1. **データ規模と更新頻度**  
   - 何千万〜数億以上のデータを扱うか？  
   - 更新のリアルタイム性（秒単位、分単位？）はどれほど必要か？  

2. **既存システムとの連携様式**  
   - SQL/RDBで統合したいのか、MongoDBやドキュメント型を使いたいのか？  
   - 既にElasticsearch/OpenSearchを使っているか？  

3. **チューニング難易度**  
   - アルゴリズムやパラメータを自分で細かく調整するか、なるべく隠蔽された形で使いたいか？  

4. **コスト構造**  
   - インスタンス課金、IO課金、ストレージ課金などの内訳は？  
   - 試験運用から本番に拡張しても予算内に収まるか？  

### 今後の技術動向

- **マルチシャードによるベクトル検索**のさらなる高速化：MemoryDBなど、一部サービスでシャーディング制約が解消される可能性。  
- **量子化技術**や**圧縮埋め込み**の標準化：メモリ/ストレージ消費を抑えつつ高精度を保つ手法の普及。  
- **LLM推論とDBの密結合**：AuroraやDocumentDBが、生成AI用の推論フレームワークと直接連携する動きが進む見込み。  
- **セキュリティ・プライバシー対策**：機密情報をEmbedding化して外部サービスに渡す際のガイドライン整備や暗号化技術の高度化。

---

# 5. 参考文献

- [Vector engine for Amazon OpenSearch Serverless now generally available](https://aws.amazon.com/about-aws/whats-new/2023/11/amazon-opensearch-serverless-vector-engine/)
- [k-NN vector - OpenSearch Documentation](https://opensearch.org/docs/latest/field-types/supported-field-types/knn-vector/)
- [Free Cloud Computing Services - AWS Free Tier](https://aws.amazon.com/free/)
- [Load vector embeddings up to 67x faster with pgvector and Amazon Aurora](https://aws.amazon.com/blogs/database/load-vector-embeddings-up-to-67x-faster-with-pgvector-and-amazon-aurora/)
- [Build generative AI applications with Amazon Aurora and Amazon Bedrock Knowledge Bases](https://aws.amazon.com/blogs/database/build-generative-ai-applications-with-amazon-aurora-and-amazon-bedrock-knowledge-bases/)
- [Get started with a free trial of Amazon MemoryDB for Redis](https://aws.amazon.com/blogs/database/get-started-with-a-free-trial-of-amazon-memorydb-for-redis/)
- [Power real-time vector search capabilities with Amazon MemoryDB](https://aws.amazon.com/blogs/database/power-real-time-vector-search-capabilities-with-amazon-memorydb/)
- [AWS announces vector search for Amazon MemoryDB for Redis (Preview)](https://aws.amazon.com/about-aws/whats-new/2023/11/vector-search-amazon-memorydb-redis-preview/)
- [Amazon DocumentDB (MongoDB 互換) のベクトル検索が一般公開されました](https://aws.amazon.com/jp/blogs/news/vector-search-for-amazon-documentdb-with-mongodb-compatibility-is-now-generally-available/)
- [Vector search for Amazon DocumentDB (with MongoDB compatibility) is now generally available](https://aws.amazon.com/blogs/aws/vector-search-for-amazon-documentdb-with-mongodb-compatibility-is-now-generally-available/)
- [Amazon DocumentDB Free Trial](https://aws.amazon.com/documentdb/free-trial/)
- [Opening up our free plan (Pinecone)](https://www.pinecone.io/blog/updated-free-plan/)
- [Pinecone pricing: Features and plans explained (Orb)](https://www.withorb.com/blog/pinecone-pricing)
- [Retrieval Augmented Generation (RAG) with Pinecone](https://www.pinecone.io/learn/retrieval-augmented-generation/)

---
### 会社紹介

**株式会社 Mosaica**  
最先端テクノロジーで社会課題を解決し、持続可能な未来を創造する IT カンパニー。
AI ソリューション、クラウド統合、DX 推進、経営コンサルティングなど包括的なサービスでビジネス変革を支援しています。  

詳しくは [公式サイト](https://mosaica.co.jp/) までお気軽にご相談ください。
公式サイト： https://mosaica.co.jp/