Amazon DynamoDBのネイティブベクトル検索とは―仕組みと使いどころを解説

はじめに

Amazon DynamoDBをアプリケーションのデータストアとして利用しながら、商品検索やレコメンデーション、AIエージェントの長期記憶などにベクトル検索を追加する場合、これまではAmazon OpenSearch ServiceやAmazon Bedrock Knowledge Basesなどの検索基盤を別に用意する構成が一般的でした。DynamoDBのデータを別サービスへ同期するため、検索基盤だけでなく、データ連携と整合性も管理する必要があります。
2026年8月5日、AWSはAmazon DynamoDBのネイティブベクトル検索を一般提供しました。ベクトル埋め込みを通常の属性と一緒にDynamoDBへ保存し、専用のベクトルインデックスに対して類似度検索を実行できる機能です。別のベクトルストアへデータを複製せず、業務データとベクトルを同じサービスで扱えるようになりました。

本記事では、DynamoDBのネイティブベクトル検索によって何が変わるのか、機能の仕組み、主な用途、他のAWSサービスとの使い分け、設計上の注意点を整理します。実際にAWS マネジメントコンソールでDynamoDBテーブルとベクトルインデックスを作成し、Pythonから検索する手順は次回紹介します。

ベクトル検索の前提となるエンベディングの仕組みは、以下の記事で解説しています。

DynamoDBのベクトル検索で何が変わったのか

従来、DynamoDBに保存した商品や文書を意味の近さで検索するには、DynamoDB StreamsやOpenSearch Ingestionなどを利用して、検索用のベクトルや関連属性を別サービスへ同期する構成が必要でした。この構成は、全文検索や高度なハイブリッド検索を実現できる一方、DynamoDBと検索インデックスの双方を管理する必要があります。
DynamoDBのネイティブベクトル検索では、ベクトルをDynamoDBのアイテム内に保存し、そのテーブルに作成したベクトルインデックスを直接検索します。検索結果にはインデックスへ射影した商品名や説明などの属性も含められるため、検索後にIDを使って元データを取得し直す処理も省略できます。

なお、OpenSearch Serviceが不要になったということではありません。全文検索、キーワードとのハイブリッド検索、複雑な集計、検索品質の詳細な調整が必要な場合は、引き続きOpenSearch Serviceが有力です。DynamoDBに業務データがあり、類似度検索を低い運用負荷で追加したい場合に、新しい選択肢が加わったと捉えるのが適切です。

ネイティブベクトル検索の仕組み

DynamoDBでは、埋め込みモデルが生成したベクトルを既存のList型で保存します。リストの各要素はNumber型の値であり、ベクトル専用の新しい属性型を使用するわけではありません。
ベクトルを保存する属性に対してベクトルインデックスを作成し、次元数と距離関数を設定します。アプリケーションは検索文を同じ埋め込みモデルでベクトル化し、SearchVectors APIへ渡します。DynamoDBは近似最近傍検索（ANN）を実行し、類似度の高いアイテムをスコア順に返します。

ベクトルインデックスの構成要素は、DynamoDB開発者ガイド「Using vector indexes in DynamoDB」で確認できます。

距離関数

DynamoDBでは、次の3種類の距離関数を選択できます。インデックス作成後に距離関数を変更できないため、埋め込みモデルの推奨設定に合わせて選ぶことが重要です。

テキスト埋め込みで判断に迷う場合、AWSの開発者ガイドではCOSINEが安全な既定の選択肢として案内されています。単位ベクトルへ正規化した場合、DOT_PRODUCTとCOSINEは同じ順位になりますが、スコアの意味は異なります。

検索スキーマ

ベクトルインデックスには、任意で検索スキーマを設定できます。検索スキーマには、ルーティングキーとインラインフィルター属性を定義します。ルーティングキーは、AWS公式ブログや開発者ガイドで「ベクトルインデックスのパーティションキー」と説明されている設定に相当します。
ルーティングキーを設定すると、検索対象を1つのキー値に限定できます。たとえば、テナント、国、マーケットプレイスなどをキーにすれば、検索するデータ量を抑え、キー値ごとに検索スループットを分散できます。ルーティングキーを定義したインデックスでは、検索時にその値の指定が必須です。

インラインフィルターは、ベクトルの類似度検索と同時にカテゴリなどの条件を適用する機能です。現在は等価演算子のみをサポートし、範囲条件やIN条件には対応していません。

主な仕様と制約

最新のクォータと機能上の制約については、DynamoDB開発者ガイドの「Vector indexes」および「Requirements and limitations」を確認してください。インデックスの更新動作については、「Data synchronization between tables and vector indexes」を参照してください。
ベクトルインデックスはQuery、Scan等では検索できません。また、DynamoDB Accelerator（DAX）はSearchVectorsに対応していないため、ベクトル検索はDynamoDBへ直接送信します。

想定されるユースケース

DynamoDBのベクトル検索は、頻繁に更新される業務データと意味検索を同じデータモデルで扱いたい用途に適しています。

• セマンティック商品検索
• 商品やコンテンツのレコメンデーション
• RAGで使用する関連文書の取得
• 会話履歴や過去の判断を検索するAIエージェントの長期記憶
• 既知の正常パターンや不正パターンと比較する異常検知

たとえば商品検索では、商品ID、名称、価格、在庫、カテゴリ、説明文のベクトルを1つのアイテムに保存できます。価格、在庫、カテゴリなどの属性を更新すると、変更内容はベクトルインデックスへ自動的に同期されます。

ただし、DynamoDBは埋め込みを再生成しません。説明文など、ベクトルの元となるデータを変更した場合は、アプリケーション側で埋め込みを再生成し、ベクトル属性も更新する必要があります。埋め込みの更新については、DynamoDB開発者ガイドの「Keep embeddings in sync with source content」も参照してください。

外部検索基盤との削除漏れや更新遅延を考慮する箇所が減る点は、更新頻度が高いデータで特に有効です。
一方、RAGの検索設計では、ベクトル検索だけで十分とは限りません。型番、正式名称、日付などの完全一致が重要な場合は、テキスト検索や構造化検索との組み合わせも検討する必要があります。検索方式の違いは、以下の記事で整理しています。

他のAWSサービスとの使い分け

AWSには複数のベクトル検索の選択肢があります。データの所在、検索機能、レイテンシー、更新頻度、運用方法に応じて選択します。

DynamoDBをすでにプライマリデータストアとして利用しており、検索要件がベクトル類似度と等価フィルターで満たせる場合は、ネイティブ機能によって構成を簡素化できます。反対に、検索がアプリケーションの中心であり、全文検索や複数方式のスコア統合が必要な場合は、OpenSearch Serviceを候補に残すべきです。

導入前に確認したい設計ポイント

結果整合性を前提にする

テーブルへの書き込み後、ベクトルインデックスは非同期に更新されます。そのため、新規登録や更新の直後は、対象アイテムが検索結果へ現れない可能性があります。「保存完了と同時に必ず検索できる」ことが必要な処理では、再試行や状態管理を設計に含めます。

ルーティングキーを検索単位に合わせる

小規模な検証では、ルーティングキーを持たないベクトルインデックスでも検索できます。しかし、インデックス全体を対象とするため、データ量と検索量が増えると処理量、レイテンシー、コストが増加します。
テナントIDやマーケットプレイスのように、すべての検索で必ず指定できる属性があれば、ルーティングキーとして検討します。値の偏りが大きい属性を選ぶと特定のキーへ負荷が集中するため、実際のアクセスパターンを基準に決定します。

射影属性を必要最小限にする

ベクトルインデックスの属性の射影には、ALL、KEYS_ONLY、INCLUDEの3種類があります。コンソールでは、それぞれ「All」「Only keys」「Include」と表示されます。

ALLは実装が簡単ですが、アイテムが大きい場合はインデックスのストレージと検索時に処理するデータ量が増えます。KEYS_ONLYはインデックスを小さくできますが、商品名や説明文などを表示するには、検索結果の主キーを使ったGetItemやBatchGetItemが別途必要です。検索結果の表示や後続処理に必要な属性が決まっている場合は、必要な属性だけをINCLUDEで射影する方法を検討します。
ベクトル属性はベクトルインデックスへ必ず射影されます。SearchVectors APIでProjectionExpressionを省略すると、ベクトルを含む射影済み属性がすべて返されます。必要な属性だけを指定すると、レスポンスサイズと返却データ量に応じた検索コストを抑えられます。ただし、検索時に調べるデータ量は変わりません。その削減には、ルーティングキーによる検索範囲の限定が有効です。

課金の単位を把握する

ベクトルインデックスでは、ベーステーブルの通常料金に加えて、次の3つが課金対象です。

• ベクトルインデックスへ書き込むデータ量
• ベクトル検索で処理し、返すデータ量
• ベクトルインデックスの保存データ量

書き込みと検索はバイト単位で計測され、1回あたり1KBの最小課金サイズがあります。次元数を抑える、不要な属性を射影しない、ルーティングキーで検索範囲を限定するといった設計は、ストレージ、書き込み、検索の複数のコストへ影響します。
単価はリージョンやテーブルクラスによって異なるため、見積もり時はAmazon DynamoDBの料金を確認してください。

インデックス設定の変更方法を考慮する

次元数、距離関数、射影、検索スキーマは、ベクトルインデックス作成後に変更できません。変更する場合は、新しい設定で別のベクトルインデックスを作成します。既存テーブルに追加したベクトルインデックスは、既存データのバックフィルが完了するまでSearchVectorsを実行できません。新旧インデックスの切り替え手順と検証期間は事前に計画する必要があります。

まとめ

DynamoDBのネイティブベクトル検索により、ベクトル埋め込みと業務データを同じテーブルへ保存し、SearchVectors APIで直接類似度検索を実行できるようになりました。外部ベクトルストアへの同期が不要になるため、DynamoDBを中心とするアプリケーションでは、構成とデータ管理を簡素化できます。
導入時の要点は次のとおりです。

• DynamoDBのアイテムにベクトルと業務データを一緒に保存できる
• ベクトルインデックスはANN検索、等価フィルター、任意のルーティングキーをサポートする
• DynamoDBは埋め込みを再生成しないため、元データの変更時はアプリケーション側でベクトルも更新する
• 全文検索や高度なハイブリッド検索が必要な場合はOpenSearch Serviceも候補に残す
• 結果整合性、射影属性、パーティション設計、バイト単位の課金を考慮する
• オンデマンド容量モード、最大次元数、検索結果サイズなどの制約を確認する

次回は、AWS マネジメントコンソールからDynamoDBテーブルとベクトルインデックスを作成し、Amazon BedrockとPythonを使って商品データの登録、通常のベクトル検索、フィルター付き検索を実行します。

生成AI活用支援サービスのご紹介

Tech Funでは、お客様のフェーズに合わせ、生成AI活用に向けた様々な支援をご提供しています。

1. 無料診断パック：業務・プロセスの現状を無料で診断し、生成AI活用の可能性をレポートします。
2. 検証（PoC）パック：診断で有効性が確認された業務を対象に、プロトタイプ構築を支援します。
3. コンサルティングサービス：生成AI導入戦略の策定から運用体制構築までを包括的に支援します。
4. Plain RAG：社内文書をもとに回答し、社内問い合わせを効率化するAIチャットパッケージです。

生成AIに限らず、Web・業務システム開発やインフラ設計など、技術領域を問わずご相談を承っています。「何から始めれば良いか分からない」という段階でも構いませんので、ぜひお気軽にお問い合わせください。

執筆・編集

Tech Fun Magazine R&Dチーム

Tech Funの生成AI研究に携わるエンジニアが、最新のAIモデル動向やプロンプト設計、実業務への応用手法など、生成AIに特化した知見を執筆・編集しています。
モデル評価や業務シナリオに応じたAI活用設計など、日々のR&D活動で得られる実践的なノウハウをわかりやすく紹介します。