Amazon DynamoDBが、リアルタイムのベクトル検索を一般提供として利用できるようになりました。これまで運用データとベクトル埋め込みは別々のストアに分けて管理し、両者を同期させるパイプラインを維持するのが一般的でした。今回のアップデートは、その前提を大きく変える可能性を持っています。本記事では、GAで何が新しくなったのか、既存手段とどう違うのか、そして実運用で活かすための設計とコストの検討観点から段階的な導入の進め方までを、本番運用の視点で整理してお伝えします。

DynamoDBリアルタイムベクトル検索GAで何が新しくなったのか

今回追加されたのは、既存のGSIやLSIとは別種の新しいインデックスタイプである「ベクトルインデックス」です。2026年8月5日に発表され、AWS GovCloud（米国）を含むすべての商用AWSリージョンで一般提供されています。最大の特徴は、運用データとベクトル埋め込みを同じDynamoDBテーブルに一緒に保存できる点にあります。これにより、専用のベクトルストアへデータを複製し、二つのサービス間で同期を取り続けるパイプラインを維持する必要がなくなります。

検索には新しいAPIであるSearchVectorsを用います。方式は近似最近傍（ANN）検索で、類似度スコアの高い順に結果を返します。インデックスの作成や管理は既存のCreateTableおよびUpdateTable APIの延長で行えるため、運用モデルがこれまでのDynamoDBと共通しているのも実務上の利点です。サーバーレスで稼働し、メンテナンスによるダウンタイムを気にせず使える点も、運用負荷を抑えたいチームにとって魅力的でしょう。

性能について、AWSはブログのなかで「99パーセント以上の再現率を維持しながら1桁ミリ秒のレイテンシー」でネイティブなベクトル検索をサポートすると説明しています。ただし、この数値の測定条件は公開されていません。データ規模や次元数、距離関数などによって実際の結果は変わるため、確定したベンチマークとして受け取るのではなく、必ず自社のワークロードで実測して確かめることをおすすめします。

既存のベクトル検索手段との違いを正しく捉える

まず、DynamoDB内部でのインデックス種別の位置づけを整理しておきましょう。GSIやLSIが完全一致や範囲クエリを対象とするQuery/Scanのためのものであるのに対し、ベクトルインデックスは類似度検索を担うSearchVectorsという別カテゴリに属します。目的が異なるため、既存のインデックスと置き換えるのではなく、用途に応じて併用する設計になります。

既存のDynamoDB機能との統合も進んでいます。StreamsやGlobal Tables、TTL、PITRやバックアップ、S3へのExportやImportといった機能と併用できます。一方で、DAXはSearchVectorsに対応していない点に注意が必要です。その他の読み取りではDAXを利用できますが、ベクトル検索そのものはキャッシュ経由では実行できないと理解しておきましょう。

他のベクトル検索の選択肢との比較についても触れておきます。OpenSearchのk-NNや、AuroraおよびRDS PostgreSQLのpgvector、Amazon S3 Vectorsなども有力な候補ですが、今回のAWS公式ブログやドキュメントにこれらとの性能やコストの直接比較は示されていません。したがって優劣を断定することは避けます。あくまで一般論として述べるなら、DynamoDBのアプローチは「キーバリューやドキュメント型の運用データベースに埋め込みを同居させる」という思想に立っている点が、他の手段との考え方の違いだと捉えられます。どれが優れているかではなく、自社のワークロードにどの思想が合うかで選ぶのが実務的です。

実運用での活用シーンとフィルタ設計の考え方

公式に挙げられている活用シーンは幅広く、検索拡張生成（RAG）、AIエージェントのメモリ、レコメンデーション、セマンティック検索、パーソナライズ体験、異常検知や不正検知などがあります。いずれも運用データと同居できる強みと結びつけて考えると、実装の見通しが立てやすくなります。

• RAGでは、ドキュメントの埋め込みをDynamoDBに保存し、LLMへ渡す関連コンテキストを取得します。ユーザーやテナント、カテゴリといったメタデータと一体で扱えるため、絞り込みと検索を近い場所で完結させやすくなります。
• AIエージェントのメモリでは、会話の埋め込みを保存してセッションをまたいだ文脈を維持できます。低レイテンシと運用データベース一体という特性が親和的です。
• レコメンデーションでは、商品やコンテンツ、ユーザー特徴の類似検索を行います。距離関数のDOT_PRODUCTを人気度スコアでスケールしてランキングへ反映する例が公式に記載されています。
• セマンティック検索では、キーワード一致ではなく意味ベースで探します。テキスト埋め込みではCOSINEが推奨されています。

距離関数はCOSINE、DOT_PRODUCT、EUCLIDEANの3種類から選べます。迷った場合はテキスト埋め込みに適するCOSINEから検討するのが無難でしょう。フィルタ設計では前提を正確に押さえておく必要があります。インラインフィルタは等価の指定のみに対応しており、範囲指定やINは現時点では使えません。そのため、絞り込みの軸となる属性は等価で表現できる形に整えておくことが設計の出発点になります。運用データと同居する構造は、こうしたメタデータによる絞り込みと相性が良く、RAG基盤を運用データベースの近くに寄せたいケースで検討する価値があります。

導入前に押さえる設計とコストとパフォーマンスの検討観点

設計で最初に意識したいのは、作成後に変更できない項目があることです。次元数と距離関数は作成後に変更できません。次元数は最大4096次元まで対応しますが、いったん決めると後戻りできないため、事前の検証が欠かせません。距離関数も同様で、確定前に代表データで挙動を確かめておくべきです。

上限値も把握しておきましょう。1回のSearchVectorsで返せるのは最大100件、1テーブルあたりのベクトルインデックスは最大5つまでです。キャパシティモードはオンデマンドのみで、プロビジョンドは選べません。スケール設計では、SearchSchemaにパーティションキーを最大1つ定義できる点が鍵になります。定義しておくと大規模時のレイテンシやスループットの向上に寄与し、未定義だと毎回インデックス全体を検索する挙動になります。プロジェクションはKEYS_ONLY、INCLUDE、ALLから選び、含めなかった属性は検索結果に返せないため、返したい属性を先に見極めておく必要があります。Global Tablesを使う場合は、各リージョンへ非同期にレプリケートされインデックス化されるため、ANNの性質と相まってリージョン間で結果の順序が微妙に異なりうる点も考慮しておきましょう。

コストについては慎重に扱う必要があります。今回のブログには具体的な料金数値の記載がありません。キャパシティがオンデマンドのみである点は確定していますが、書き込みやストレージ、検索リクエストといった課金の内訳や単価は、AWS公式のDynamoDB料金ページで別途確認する必要があります。金額を推測で断定せず、一次ソースにあたるようにしてください。なお、内部で用いられるインデックスのアルゴリズムは公式に「近似最近傍」とだけ記載されており、特定の方式名は明示されていないため、ここでも断定は避けます。

PoCから本番へ段階的に導入・検証する進め方

変更不可の項目が複数あることを踏まえると、いきなり本番へ組み込むのではなく、小さく検証してから確実に広げる進め方が向いています。おおまかな流れを順に見ていきましょう。

• まず埋め込みモデルを選定し、それに合わせて距離関数を確定します。距離関数と次元数は作成後に変更できないため、代表データで事前に検証してから決めるのが安全です。
• 次に次元数をモデルの出力に合わせて決めます。最大4096次元の範囲で、同じく後から変えられない前提で選びます。
• 続いてスキーマとパーティションの設計をPoCで評価します。小規模なら無指定でも動きますが、大規模を想定するならパーティションキー設計を先に検討しておきます。
• プロジェクション設計では、検索結果で返したい属性をINCLUDEやALLに含めます。INCLUDE属性も後から変更できず、変えるには再作成が必要になるため、返す属性を先に固めておきます。
• その上で、自社データと自社クエリを使って再現率とレイテンシを実測し、料金もオンデマンド前提で小規模に見積もります。TTLによる失効、Streams、Global Tablesのリージョン間の非同期挙動、DAX非対応といった点も本番設計の前に確認します。

本番への移行は、既存テーブルへUpdateTableのVectorIndexUpdatesでインデックスを追加し、Backfillingが完了してIndexStatusがACTIVEかつBackfillingがfalseになるのを待ってから検索を始めます。こうした「小さく確実に」検証を積み重ねてから本番へ進める姿勢は、新機能を取り入れる際のリスクを抑えるうえで有効です。RAG基盤やAWSの新機能の活用を検討している場合も、まずは限定的な範囲で確かめることをおすすめします。

まとめとして導入を判断するための着眼点

今回のアップデートで得られる最大の実務価値は、運用データベースと埋め込みを同居させられることによって、データ同期にまつわる運用負荷とリスクを減らせる点にあります。専用ストアと同期パイプラインを別立てで維持する構成から解放されることは、運用チームにとって大きな意味を持ちます。

一方で、次元数や距離関数が作成後に変更できないこと、インラインフィルタが等価のみであること、キャパシティがオンデマンドのみであること、DAXがSearchVectorsに対応しないことといった制約も存在します。これらを前提として、自社のワークロードが本当に適合するかを見極めることが重要です。他の手段より一律に優れていると一般化するのではなく、あくまでワークロード次第という中立的な視点で判断してください。RAGやサーバーレス基盤を検討中であれば、小さく検証して確実に本番へ進める進め方が、堅実な第一歩になるはずです。私たちも、こうしたAWSの新機能を活かしたRAG基盤づくりを、段階的に無理なく進めるお手伝いができればと考えています。