2026 年 8 月 5 日、 Amazon DynamoDB でのベクトル検索の一般提供についてお知らせします。運用データとともにベクトル埋め込みを DynamoDB に保存し、別のベクトルストアにデータを複製することなく、そのデータに対して直接類似度検索を実行できるようになりました。 DynamoDB は、99%以上の再現率を維持しながら、1桁ミリ秒のレイテンシーでネイティブなベクトル検索をサポートします。また、数兆個のベクトルを含む大規模なデータにも対応できるよう設計されています。サーバーのプロビジョニング、パッチ適用、管理は一切不要で、ソフトウェアのインストール、保守、運用も必要ありません。このサービスにはバージョンの管理がなく、メンテナンスウィンドウも設定されておらず、メンテナンスによるダウンタイムもゼロです。 ベクトルインデックスにはストレージ容量の制限がなく、データの増加に応じて水平方向にスケールします。DynamoDB のネイティブなベクトル検索を利用することで、エージェント型メモリ、検索拡張生成（RAG）、レコメンデーションエンジン、パーソナライズされたエクスペリエンス、異常検知など、セマンティック検索を必要とするアプリケーションを構築できるようになりました。 アプリケーションですでに DynamoDB を使用している場合、これまではベクトル検索を追加するために、データを専用のベクトルデータベースにコピーし、2つのサービス間でデータを同期するパイプラインを維持する必要がありました。これにより、運用上のオーバーヘッド、データ移動コスト、ライセンスコストが増加し、さらに大規模環境で予測可能な低レイテンシーを維持するという課題も生じていました。DynamoDB にベクトル検索が組み込まれているため、ベクトルデータと運用データを同じサーバーレスインフラストラクチャ上で管理し、同じ従量課金（リクエスト単位の課金）モデルを利用できます。 DynamoDB のベクトル検索では、ベクトル埋め込みを格納する属性に対して作成する新しいタイプのインデックスが導入されています。任意のモデル（Amazon Bedrock Titan Text Embeddings、Cohere Embed、OpenAI のテキスト埋め込みモデルなど）を使用して埋め込みを生成し、標準の PutItem 呼び出しを使用して、浮動小数点数のリストとしてテーブルに保存できます。次に、その属性に対してベクトルインデックスを作成し、次元数、距離関数、およびクエリ実行時に検索結果を絞り込むためのフィルターとして使用する非ベクトル属性を指定します。 SearchVectors API は、クエリベクトル、返される結果の数 (最大 100)、およびオプションのフィルター条件を受け入れます。類似度でランク付けされた結果を返します。 運用データがすでに DynamoDB に存在していて、別のデータベースをプロビジョニングしたり、同期パイプラインを管理したりせずに類似検索を追加したい場合は、DynamoDB のベクトル検索を使用してください。DynamoDB は完全にサーバーレスなので、ベクトル検索はインフラストラクチャを管理しなくても自動的にスケーリングされます。最大 4096 次元、ユークリッド、コサイン、ドット積の距離関数、およびインラインフィルタリングをサポートします。 DynamoDB でのベクトル検索入門 このチュートリアルでは、 DynamoDB コンソール を使用して既存の DynamoDB テーブルにベクトル検索を追加する方法を示します。このシナリオには、製品カタログテーブルを備えたオンラインスポーツ用品店が含まれています。各アイテムには、 ProductID 、 カテゴリ 、 説明 、 マーケットプレイス 、 名前 、 価格 などの標準的な操作属性があります。目的は、セマンティック検索を追加することで、購入者が完全一致するキーワードではなく、自然言語によるクエリを使って商品を検索できるようにすることです。 1.DynamoDB テーブルを準備する セマンティック検索を有効にするために、まずテーブルにすでに保存されている商品説明のベクトル埋め込みを生成します。埋め込みとは、機械学習モデルによって生成され、テキストの内容が持つ意味を捉えた数値表現です。説明が似ている2つの項目は、ベクトル空間上で互いに近い位置にある埋め込みを持つため、これによって類似度検索が可能になります。 Amazon Bedrock Titan Text Embeddings やその他の埋め込みモデルを使用して埋め込みを生成し、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS SDK 、 AWS CloudFormation 、またはその他の IaC ツールを使用して、それらをテーブルに追加できます。 既存の ProductCatalog のようなテーブルでは、 UpdateItem 呼び出しを使用して、各項目に descriptionEmbedding という新しい属性として埋め込みを追加します。DynamoDB は、既存の List データ型を使用してベクトル埋め込みを格納します。リストの各要素は、埋め込みベクトルの単一の浮動小数点数を表す 数値 です。つまり、既存の運用データの属性と一緒にベクトルを保存するために、新しいデータ型を導入したり、スキーマを変更したりする必要はありません。 2.ベクトルインデックスの作成 DynamoDBコンソール で ProductCatalog テーブルを開き、 インデックス タブを選択します。 ベクトルインデックスを作成 を選択します。 ベクトルインデックスを作成 ページでは、次のようにインデックスの詳細を入力します。 インデックス名 として ProductDescriptionIndex 、 ベクトル属性 として descriptionEmbedding を入力します。 埋め込みモデルの出力と一致する 次元数 を入力し、 距離関数 として コサイン を選択します。コサインはベクトルの大きさではなく角度を測定する指標であり、そのためテキスト埋め込みの意味的類似性を比較するのに有効です。DynamoDB のベクトル検索では、コサイン に加えて、 ユークリッド距離 と ドット積 の距離関数もサポートされています。 ユークリッド :購入回数などの数値でアイテムをクラスタリングする場合など、ベクトルの大きさが意味のある場合に使用します。 ドット積 :方向と大きさの両方が重要な場合に使用します。たとえば、関心の位置合わせと周波数を一緒に重み付けするレコメンデーションシステムの場合などです。原則として、距離関数を埋め込みモデルのトレーニングに使用した関数と一致させると、精度が最も高くなります。 パーティションキー として マーケットプレイス に入ります。ベクトルインデックスのパーティションキーは、DynamoDB がベクトルを各パーティションにどのように分散配置するかを制御するものであり、予測可能な低レイテンシーを維持しながら、インデックスを水平スケールアウトできるようにします。各検索は1つのパーティションキー値を対象として実行されます。そのため、複数のマーケットプレイス向けの商品カタログであっても、インデックス全体をスキャンすることなく、特定のマーケットプレイスの在庫のみを検索できます。パーティションキーは必須ではありませんが、大規模なデータセットやクエリスループットが高いワークロードでは、使用することが推奨されます。 インラインフィルター属性 を展開し、 フィルター属性としてカテゴリ を追加します。これにより、クエリ時に検索結果を特定の製品カテゴリに絞り込むことができます。フィルター条件では、完全一致の値のみサポートされます。 BETWEEN や BEGINS_WITH のような範囲条件はサポートされていません。検索結果にすべてのテーブル属性が含まれるよう、 属性の投影 は すべて に設定したままにしています。 ベクトルインデックスを作成 を選択し、インデックスのステータスが アクティブ に変わるまで待ちます。 3.ベクトル検索を実行 商品説明に使用したのと同じ埋め込みモデルを使用して、「 夏用の軽量ランニングシューズ 」などの自然言語検索用語からクエリベクトルを生成します。DynamoDB コンソールでは、左側のナビゲーションペインで 項目を検索 を選択し、 ProductCatalog テーブルを選択します。 検索 を選択してベクトル検索モードに切り替えます。 ベクトルインデックスを選択 ドロップダウンから ProductDescriptionIndex を選択し、クエリベクトルを 検索ベクトル フィールドに貼り付け、 結果の数 (上位 K) を 5 に設定します。 パーティションキー値 として US と入力して、検索範囲を米国のマーケットプレイスに限定します。  インラインフィルター属性を拡張し 、 カテゴリ を フットウェア と同じに設定して、検索をフットウェア製品のみに絞り込みます。最後に、 実行 を選択します。 DynamoDB は、フットウェアカテゴリ内で意味的に最も類似している5件の商品を、類似度スコアの高い順に返します。また、そのレスポンスには、商品名や価格などの通常の運用データ属性もあわせて含まれます。類似度スコアの意味は、インデックスに選択した距離関数によって異なります。コサイン距離関数とユークリッド距離関数では、類似度スコア値が低いほど類似度が高く、スコアが 0 の場合はベクトルが同一であることを示します。点積距離関数では、類似度スコアの値が高いほど類似度が高くなります。 API の呼び出しやドキュメントの検索など、ベクトル検索をプログラムで操作するには、お好みの AI コーディングツールで AWS MCP サーバー と プラグイン を試してください。 詳細については、 Amazon DynamoDB 開発者ガイドをご覧ください 。 今日から始めよう Amazon DynamoDB のベクトル検索は、一般的に AWS GovCloud (米国) リージョンを含むすべての商用 AWS リージョンで利用できます。リージョンごとの提供状況や今後のロードマップについては、 AWS のリージョン別提供機能 にアクセスしてください。料金の詳細については、 Amazon DynamoDB 料金表ページ をご覧ください。 ぜひ 8 月 5 日から DynamoDB のベクトル検索をお試しください。ご意見やご要望は、 Amazon DynamoDB の AWS re:Post 、または通常ご利用の AWS サポート窓口までお寄せください。 – Esra 原文は こちら です。

Elastic 9.5では、ログの保存方法、ベクトル検索、マルチモーダル検索、AIエージェントの運用、Prometheusからの移行など、幅広い領域に新機能が追加されました。 今回のポイントは、単に機能が増えたことではありません。これまでエンジニアが手作業で行っていた 保存方式の最適化、ベクトル検索の設定、PromQLの書き換え、AIエージェントの調査 を、Elastic側がより多く引き受ける方向へ進んだことです。 この記事では、Elastic 9.5の主要機能について、次の4点に絞って説明します。 何を解決する機能なのか 9.5で何が変わったのか どのような人や環境に役立つのか 導入前に何を注意すべきか 対象バージョン ：Elastic 9.5（2026年8月4日リリース） 想定読者 ：Elasticを利用しているエンジニア、導入を検討しているアーキテクト、運用担当者 目次 まず押さえたいGAとTech Preview Columnar Mode：ログを「検索中心」から「分析中心」へ 何を解決する機能か 9.5で何が変わったか なぜ役立つのか 注意点 VectorDB index modeとAuto-calibration：ベクトル検索の初期設定を簡単にする 何を解決する機能か VectorDB index mode DiskBBQとAuto-calibration 注意点 マルチモーダルsemanticフィールド：画像やPDFも意味で検索する 何を解決する機能か 9.5で何が変わったか 注意点 Agent Builder tracing：AIエージェントの処理を見えるようにする 何を解決する機能か 9.5で何が変わったか 具体例 プライバシー上の注意 PromQL GA：Prometheus資産をElasticで活用しやすくする 何を解決する機能か 9.5で何が変わったか 移行ツール メトリック 注意点 Workflows：作成しやすく、壊しても戻しやすくする バージョン管理 Visual Mode 自然言語オーサリング Human-in-the-loop Security：AIによる調査とルール運用を強化 AlertZeroは製品名ではない Attack Discoveryの変化 検知ルール変更履歴 注意点 その他のGA機能 Dashboards API Cases as Data どの機能から試すべきか GA機能で優先度が高いもの 検証環境で試すTech Preview まとめ 参考資料 まず押さえたいGAとTech Preview Elastic 9.5の機能は、すぐに本番利用を検討できる GA（正式提供）と、まず検証環境で試すべきTech Preview に分かれます。 機能 状態 一言でいうと PromQL対応 GA 多くの既存PromQLをElasticで実行できる Dashboards API GA ダッシュボードをコードとして管理できる Cases as Data GA ケース情報を分析用データとして利用できる Workflowsの自然言語オーサリング GA 自然文からWorkflowの初稿を生成できる Workflowsのバージョン管理 GA 変更履歴の確認、比較、復元ができる 検知ルール変更履歴 GA ルールの変更内容と変更者を追跡できる Columnar Mode / Columnar Logs Tech Preview ログの保存容量を減らし、分析向けに最適化する VectorDB index mode Tech Preview ベクトル検索向けの設定をまとめて適用する DiskBBQ Auto-calibration Tech Preview 実データに合わせてベクトル検索設定を自動調整する マルチモーダルsemanticフィールド Tech Preview テキスト、画像、音声、動画、PDFを意味で検索する Agent Builder tracing Tech Preview AIエージェントの処理をトレースとして確認する Tech Previewの機能は、将来のElasticの方向性を理解するうえで重要ですが、本番利用の前に機能制約、性能、ライセンスを確認する必要があります。 Columnar Mode：ログを「検索中心」から「分析中心」へ 状態：Tech Preview 対象：大量のログを長期間保存し、ダッシュボードや集計で利用する環境 何を解決する機能か 通常のElasticsearchでは、1つのフィールドを検索、範囲検索、集計、元データの保持など、複数の目的に合わせて保存します。これは高い検索性能を実現する一方、ログのようにフィールド数が多いデータでは、保存容量が大きくなります。 実際のログ運用では、すべてのフィールドを全文検索するわけではありません。多くのフィールドは、ダッシュボードでの絞り込みや集計に使われます。 9.5で何が変わったか Columnar Modeは、非テキストフィールドを主に列形式で保存し、転置インデックスや数値範囲検索用のBKDツリーを既定では作りません。 ログ向けのlogsdb_columnarでは、messageなどのテキストフィールドには全文検索用の転置インデックスを残し、それ以外の構造化フィールドは列形式を中心に保存します。 PUT logs-example {   "settings": {     "index.mode": "logsdb_columnar"   } } なぜ役立つのか 列形式では、クエリに必要なフィールドだけを読みやすく、同じ種類の値が並ぶため圧縮もしやすくなります。 例えば、次のようなログ基盤に向いています。 1日に大量のログを取り込む service.nameやlog.levelごとの集計が多い Kibana Dashboardで傾向を見ることが中心 保存コストのため保管期間を短くしている 注意点 すべての検索が速くなるわけではありません。trace.idやpod.uidのようなランダムな値を1件だけ探す検索や、数値の範囲検索は、通常のインデックスより遅くなる可能性があります。 また、index.modeは作成後に変更できません。既存データへ適用するには、ロールオーバーまたはreindexが必要です。現時点では一律の削減率も公表されていないため、自社データで比較することが重要です。 ドキュメントの更新、nestedデータ、特定ドキュメントの取得、全文検索の関連度評価が中心の場合は、従来のインデックスモードのほうが適しています。 要点 ：保存と分析を優先するログには有望ですが、ピンポイント検索が多い環境では事前検証が必要です。 VectorDB index modeとAuto-calibration：ベクトル検索の初期設定を簡単にする 状態：Tech Preview 対象：RAG、セマンティック検索、画像検索などをこれから構築するチーム 何を解決する機能か ベクトル検索では、文章や画像を数値の並びであるベクトルへ変換し、意味の近さを距離で検索します。 ただし、大量のベクトルを扱うには、圧縮方法、検索候補数、メモリの使い方など、多くの設定が必要です。最適な値はデータによって変わるため、従来は性能と精度を測りながら手作業で調整する必要がありました。 VectorDB index mode vectordb_documentを指定すると、ベクトル検索に適した複数の設定がまとめて適用されます。 PUT my-vector-index {   "settings": {     "index.mode": "vectordb_document"   } } 主な目的は次のとおりです。 ベクトルの保存容量を抑える ベクトルを_sourceへ重複保存しない 重いセグメントマージを効率化する 検索で頻繁に使う構造を先読みする 個別の内部設定をすべて理解しなくても、ベクトル検索向けの初期状態から検証を始められます。 DiskBBQとAuto-calibration DiskBBQは、検索に必要なデータの多くをディスクへ置き、メモリへ載せるデータを減らすための検索方式です。大量のベクトルを、限られたRAMで扱いたい環境に向いています。 Auto-calibrationを有効にすると、Elasticsearchが実際のベクトルを調べ、圧縮方法や検索候補数などを自動的に選びます。 "index_options": {   "type": "bbq_disk",   "auto_calibrate": true } 正しいパラメータ名はauto_calibrateです。 注意点 Auto-calibrationは、精度を100%保証する機能ではありません。検索品質、レイテンシ、取り込み性能は実データで確認する必要があります。 比較的検索しやすいデータでは圧縮を強くし、難しいデータでは情報を多く残すことで、容量と検索精度のバランスを自動調整します。 bbq_diskにはEnterpriseライセンスが必要です。また、index.modeやauto_calibrateはインデックス作成後に変更できないため、既存データへ適用する場合はreindexが必要です。 要点 ：ベクトル検索の専門的な初期設定を減らす機能です。ただし、最終的な品質確認まで自動化されるわけではありません。 マルチモーダルsemanticフィールド：画像やPDFも意味で検索する 状態：Tech Preview 対象：図面、商品画像、スキャン文書、音声、動画を検索したいチーム 何を解決する機能か これまでのsemantic_textは、主にテキストを対象とした機能でした。画像や音声を検索するには、データの種類ごとに別のモデルやパイプラインを作る必要がありました。 9.5で何が変わったか 新しいsemanticフィールドは、次のデータを扱えます。 テキスト 画像 音声 動画 PDF これらを同じ埋め込みモデルでベクトル化することで、異なる種類のデータを意味の近さで検索できます。 例えば、次のような検索が可能になります。 「赤い花柄のワンピース」という文章から商品画像を探す 画像をクエリにして似た画像を探す 自然文から関連するPDFや図面を探す 音声から意味の近い音声や説明文を探す "my_semantic_field": {   "type": "semantic",   "inference_id": ".jina-embeddings-v5-omni-small" } 注意点 非テキストデータはdata URL形式で投入します。入力サイズは既定で1MBで、Serverlessでは1MB固定です。また、PDFなどは自動的にページ単位へ分割されないため、細かく検索したい場合は事前の分割設計が必要です。 事前定義されたJinaモデルはElastic Inference Serviceを利用します。データの送信先、料金、ライセンス、データ主権もPoC前に確認してください。 ページ単位で検索したい場合は、事前にPDFをページごとに分割して投入します。 また、重要な制約として、semanticフィールドは 9.5以降に作成されたインデックスで使用する必要がある ため、既存インデックスではreindexが必要になる場合があります。 要点 ：検索対象をテキスト以外へ広げる機能です。実務では、ファイルサイズ、分割方法、推論コストが導入判断のポイントになります。 Agent Builder tracing：AIエージェントの処理を見えるようにする 状態：Tech Preview 対象：Agent BuilderをPoCまたは運用で利用しているチーム 何を解決する機能か AIエージェントは、1つの質問に対して複数回LLMを呼び出したり、ES|QLなどのツールを実行したりします。 そのため、応答が遅い、トークン消費が増えた、意図しないツールを呼んだといった問題が起きても、原因を特定しにくいという課題があります。 9.5で何が変わったか Agent Builderは、エージェントの実行内容をOpenTelemetry形式のトレースとして記録できるようになりました。 確認できる主な情報は次のとおりです。 LLMを何回呼び出したか 各処理にどのくらい時間がかかったか どのツールを実行したか 入力・出力トークン数 どの処理で失敗したか トレースはElasticsearchへ保存されるため、Discover、ES|QL、Lens、Dashboard、アラートなど、既存のElastic機能で分析できます。 具体例 あるエージェントの応答時間とトークン使用量が突然増えたとします。 トレースを確認すると、ES|QLツールが大量の結果を返し、その内容が後続のLLM呼び出しへ何度も渡されていたことが分かるかもしれません。原因が分かれば、クエリにLIMITを追加する、ツールの説明を修正するといった対応ができます。 プライバシー上の注意 トークン数やモデル名などの構造的な情報は記録されますが、ユーザーのプロンプト、LLMの回答、ツールの結果などは既定では記録されません。 詳細内容を記録するとデバッグには便利ですが、個人情報や機密情報が含まれる可能性があります。保存期間とアクセス権限を含めた設計が必要です。 要点 ：AIエージェントを通常のアプリケーションと同じように監視し、性能・コスト・失敗原因を調べるための機能です。 PromQL GA：Prometheus資産をElasticで活用しやすくする 状態：GA 対象：Prometheus、Grafana、OpenTelemetryメトリックを利用しているチーム 何を解決する機能か PrometheusからElasticへ移行するとき、大きな負担になるのはデータ転送だけではありません。既存のGrafana Dashboardやアラートルールに書かれたPromQLを、別のクエリ言語へ書き換える作業が必要でした。 9.5で何が変わったか ElasticはPrometheus互換HTTP APIと、ES|QLから利用できるPROMQLコマンドをGAとして提供します。 PROMQL sum by (service.name) (rate(http_requests_total[5m])) GrafanaからElasticのPrometheus互換APIを参照することで、多くの既存PromQLを変更せず利用できます。また、PromQLの結果をES|QLパイプラインで後処理することもできます。 移行ツール Observability Migration Platformは、GrafanaやDatadogのダッシュボードとアラートをKibanaへ移行するためのCLIです。 変換できないパネルを無理に作成するのではなく、手動確認が必要な箇所を示す設計になっています。移行前に検証する–validateオプションも用意されています。 メトリック 9.5ではメトリック用コーデックも改善され、Elasticの説明では、メトリックの保存容量が前バージョンからさらに約20%削減されています。PromQL対応だけでなく、保存効率も改善されています。 注意点 PromQLとPrometheusが完全互換になったわけではありません。and、unless、group_left、group_rightなど、一部の構文や動作には制限があります。既存のGrafana Dashboardやアラートは、移行前に実データで確認する必要があります。 要点 ：Prometheus/Grafanaの既存資産を活かしたまま、Elasticへ段階的に統合しやすくする機能です。 Workflows：作成しやすく、壊しても戻しやすくする 状態：GA （利用プランとAgent Builder／LLM設定の確認が必要） 対象：Elastic Workflowsで運用自動化を行うチーム バージョン管理 9.5では、Workflowの変更履歴を確認し、差分比較や過去バージョンへの復元ができるようになりました。 自動化は、一度動けば終わりではありません。条件や接続先を変更した結果、処理が動かなくなることがあります。変更者、変更日時、変更内容を追跡できることで、障害調査と監査が行いやすくなります。 自然言語によるWorkflow作成を利用するには、Agent BuilderへのアクセスとLLMの設定が必要です。 Visual Mode Workflowを、トリガー、ステップ、分岐を含む図として確認できます。ただし、9.5時点では読み取り専用です。ドラッグ＆ドロップでWorkflowを作成する機能ではありません。 自然言語オーサリング 「アラートが発生したら関連ログを取得し、AIで要約してSlackへ送る」といった指示から、WorkflowのYAML初稿を生成できます。 生成されたWorkflowは、人間が確認してから実行します。自然言語だけで安全な自動化が完成するわけではなく、作成作業のスタートを速くする機能と考えるべきです。 Human-in-the-loop Workflowを途中で止め、人間の入力や承認を待つステップも利用できます。AIや自動処理にすべてを任せず、重要な操作だけ人間が判断する設計に役立ちます。 要点 ：Workflowsは「作る機能」だけでなく、変更管理、レビュー、承認を含む運用基盤へ進化しています。 Security：AIによる調査とルール運用を強化 対象：Elastic Securityを利用するSOC、セキュリティ運用チーム AlertZeroは製品名ではない AlertZeroは、新しい製品や機能の名前ではありません。大量のアラートをそのまま人間へ渡すのではなく、AIと自動化によって優先順位を付け、アナリストが重要な脅威へ集中できる状態を表す考え方です。 Attack Discoveryの変化 従来のAttack Discoveryは、複数のアラートを関連付け、攻撃のまとまりとして説明する役割が中心でした。 9.5では、Agent BuilderとWorkflowsを利用し、次のような追加調査を行う方向へ拡張されています。 関連する生イベントを検索する ユーザーやホストのリスク情報を確認する アラート以外の証拠を探す 調査結果をまとめる 見逃していた活動からES|QLルールの案を作る 別のAlert Analysisワークフローでは、アラートを真陽性と誤検知に分類します。これにより、アナリストが低品質なアラートへ費やす時間を減らし、Attack Discoveryもより整理された対象を調査しやすくなります。 作成されたルール案は、人間がレビューし、承認するまで検知ルールとして追加されません。 検知ルール変更履歴 検知ルールの作成、編集、有効化、無効化、例外の追加などを履歴として確認できます。変更前後の差分表示と、過去状態への復元も可能です。 例えば、例外条件を広く設定しすぎてルールが発火しなくなった場合でも、どの変更が原因だったかを追いやすくなります。 注意点 Attack Discoveryのエージェント的な調査では、複数回のLLM呼び出しとツール実行が発生します。調査品質だけでなく、トークン費用、データ送信先、機密情報の扱いを確認してください。 また、AIが作成したES|QLルールは、構文が正しくても、自社のログに必要なフィールドが存在しない、誤検知が多いといった可能性があります。人間によるテストとレビューは必要です。 なお、Agent BuilderとWorkflowsを使った新しいAttack Discoveryの動作は、詳細設定で有効化する必要があり、9.5では既定でオフです。 要点 ：SecurityのAIは、アラートを説明する段階から、証拠を探して調査を支援する段階へ進もうとしています。 その他のGA機能 Dashboards API Kibana Dashboardを構造化されたJSONとして作成・更新できます。Gitでの差分管理、レビュー、CI/CDによる環境間展開が行いやすくなります。 ただし、すべてのパネルタイプをAPIだけで扱えるわけではありません。既存Dashboardをコード管理へ移す場合は、対応パネルを確認してください。 Cases as Data ケース情報を分析用インデックスへ同期し、Discover、Lens、ES|QL、Dashboardから分析できます。 これにより、ケース件数、クローズ率、対応時間、担当者ごとの負荷などを確認できます。更新はリアルタイムではなく、反映に時間差がある点に注意してください。 どの機能から試すべきか GA機能で優先度が高いもの 現在の課題 最初に確認する機能 PrometheusやGrafanaから移行したい PromQL対応と移行CLI Dashboardを環境間で管理したい Dashboards API SOCの対応時間や負荷を測りたい Cases as Data Workflowの変更が怖い バージョン管理 検知ルールの変更原因を追えない 検知ルール変更履歴 検証環境で試すTech Preview 現在の課題 検証する機能 ログの保存費用が高い Columnar Logs ベクトル検索の設定が難しい VectorDB index mode / Auto-calibration 画像やPDFを意味で検索したい semanticフィールド Agent Builderの遅延や費用が分からない Agent Builder tracing Tech Previewでは、既存環境を直接変更するのではなく、小さな新規インデックスや限定したデータセットで比較するのが安全です。 まとめ Elastic 9.5は、次の3つの方向へ進んだリリースと整理できます。 データ保存を効率化する Columnar Modeにより、大量ログを分析と長期保存へ最適化します。 検索とAIの構築作業を減らす VectorDB index mode、Auto-calibration、マルチモーダルsemanticフィールドにより、ベクトル検索の開始を簡単にします。 AIと自動化を運用できる形にする Agent Builder tracing、Workflowのバージョン管理、Human-in-the-loop、検知ルール変更履歴により、AIと自動化を監視・修正・監査しやすくします。 そのほかにも、KubernetesとAWSのオンボーディングでは、推奨されるOpenTelemetry経路を使ってセットアップが簡素化、APMのService Map改善、LLM ObservabilityのAnthropic対応が追加されています。Elastic Defendでは、脆弱なドライバーに対する予防的保護、Windows on ARM対応、エンドポイントのトラブルシューティングスキルが追加されました。Workflowsでは、Slackなどの外部ツールから承認することもできます。 GA機能は既存運用への適用を検討し、Tech Previewは将来の設計判断に向けて小さく検証するのがよいでしょう。 参考資料 Elastic 9.5公式リリースブログ Columnar Mode dense_vector field type semantic field type Agent Builder traces PromQL overview PromQL limitations Elastic Workflows Attack Discovery Detection rule changes history Cases as Data The post Elastic 9.5の新機能を速報解説：保存、ベクトル検索、AI運用はどう変わるのか first appeared on Elastic Portal .

Amazon DynamoDB を運用データに使用しているアプリケーションの多くは、ベクトル類似性検索も必要としています。これまでは、別途ベクトルデータベース、同期パイプライン、そしてそれらに伴うアーキテクチャの複雑さとコストの増加が必要でした。DynamoDB は ネイティブベクトル検索をサポート するようになりました。ベクトル埋め込み (embedding) をアプリケーションデータと一緒に保存し、DynamoDB で直接類似性検索を実行できます。これにより、単一のテーブルが運用データストアとベクトルストアの両方の役割を果たします。 この記事では、DynamoDB のネイティブベクトル検索を紹介し、研究論文のアブストラクトに対するセマンティック検索アプリケーションを構築します。 Amazon Bedrock で埋め込みを生成し、DynamoDB に保存し、セマンティックに検索します。また、コストを見積もり、コントロールできるように、ベクトル検索がどのように課金されるかについても説明します。 なぜ DynamoDB にベクトルを保存するのか 運用データを 1 つのデータベースに、ベクトル埋め込みを別のベクトルストアに維持することには、次のような課題があります。 データ同期 – ベクトルをソースデータと同期させ続けることは運用オーバーヘッドを増やし、古い結果を返すリスクがあります。 高いレイテンシー – ベクトルストアで最近傍を見つけた後、実際のアイテムデータを取得するためにプライマリデータベースへのラウンドトリップが必要になります。 コスト増加 – 1 つで両方の目的を果たせるところを 2 つのデータベースを実行して料金を払う必要があります。 アーキテクチャの複雑さ – サービスが増えると障害モードも運用も増えます。 DynamoDB ベクトル検索では、ベクトルをアイテムの属性として保存でき、これらの課題に対処できます。ベクトルインデックスで類似性検索を実行すると、DynamoDB は結果と一緒にアイテムデータを返します。他の場所で ID を検索する必要はありません。 主なメリット サーバーレスかつフルマネージド – プロビジョニング、パッチ適用、スケーリングするインフラストラクチャはありません。ベクトルインデックスと検索は自動的にスケールします。 ワークロードに応じてスケール – ベクトル検索は、DynamoDB が運用ワークロードをスケールするのと同様に水平方向にスケールするため、インデックス内で数兆のベクトルを保存および検索できます。 予測可能な低レイテンシーのパフォーマンス – データセットとスループットが増加しても、類似性検索は一貫したレイテンシーで実行されます。 既存データで動作 – 既存のテーブルにベクトルインデックスを追加し、DynamoDB にすでに保存されているアイテムにベクトル属性を追加します。あとは DynamoDB が処理します。 組み込みのフィルタリング – インデックスの検索スキーマで定義された属性でフィルタリングと組み合わせてベクトル類似性を利用できます。 使用量に応じた支払い – DynamoDB の課金モデルに合わせて、使用した分だけ支払います。 ユースケース DynamoDB のネイティブベクトル検索は、すでに DynamoDB をプライマリデータストアとして使用しており、アーキテクチャのオーバーヘッドを追加せずにデータをセマンティックに検索したいアプリケーションに適しています。一般的なユースケースには次のようなものがあります。 セマンティック検索 – データに正確なキーワードが現れない場合でも、意味に基づいて自然言語クエリと一致するアイテムを見つけます。 レコメンデーションエンジン – 説明、画像、またはユーザーの行動のベクトル的な近さに基づいて類似アイテムを提案します。 検索拡張生成 (RAG) – 大規模言語モデル (LLM) にとって最も関連性の高いコンテキストを取得し、応答の品質を向上させ、ハルシネーションを減らします。 エージェント記憶 – 会話の要約、学習した事実、過去の決定を埋め込みとして保存し、ベクトル検索で最も関連性の高いものを取得することで、AI エージェントに長期記憶を与えます。 異常検知と不正検知 – ベクトルを比較して、通常のクラスターから大きく外れているトランザクションや行動、または既知の不正パターンに近いものをフラグ付けします。 ソリューション概要 このウォークスルーでは、Hugging Face ウェブサイトの arxiv-abstracts-2021 データセット と、埋め込みを生成する Bedrock を使用して、研究論文のアブストラクトに対するセマンティック検索アプリケーションを Python で構築します。結果は、 「ブラックホール合体からの重力波の検出」 のようなクエリに応答できる DynamoDB テーブルとなります。論文本文に該当の単語が現れない場合でも、最も関連性の高い論文を返します。 以下の図はアーキテクチャを示しています。データを投入するために、アプリケーションは Bedrock で各アイテムの埋め込みを生成します。次に、アイテムをその埋め込みと共に、ベクトルインデックスを持つ DynamoDB テーブルに保存します。検索するには、アプリケーションは Bedrock を使用して自然言語クエリの埋め込みを生成し、その埋め込みでベクトルインデックスをクエリして、最も関連性の高い論文を返します。 図 1: Amazon Bedrock からの埋め込みで DynamoDB ベクトルインデックスにデータを投入して検索する 大規模な一致を素早く見つけるために、ベクトルインデックスは近似最近傍 (ANN) 検索を使用します。データセットが大きくなるにつれて、格納されているすべてのベクトルに対してクエリを比較することは非常に高価で遅くなります。ANN は代わりに、少しの正確性を大幅な速度向上と引き換えにします。真の最近傍に近い結果を返しつつ、検索を高速に、コストを予測可能に保ちます。 ウォークスルーは 3 つのステップで構成されます。 ベクトルインデックスを持つ DynamoDB テーブルを作成する。 Bedrock で埋め込みを生成し、テーブルにデータを投入する。 自然言語クエリでベクトルインデックスを検索する。 このウォークスルーの完全に実行可能なコードは、 GitHub リポジトリ で入手できます。 前提条件 このウォークスルーには以下が必要です。 AWS アカウント。 Python 3.12 以降。 環境用に設定された AWS 認証情報で、DynamoDB および Bedrock API を呼び出す権限を持つもの。 AWS リージョンでの Bedrock と Amazon Titan Text Embeddings V2 モデルへのアクセス。モデルへのアクセスをリクエストする手順については、 Bedrock ドキュメント を参照してください。 DynamoDB ベクトル検索のサポートを追加する AWS SDK for Python (Boto3) バージョン 1.43.64 以降。 ステップ 1: ベクトルインデックスを持つ DynamoDB テーブルを作成する ベクトルインデックスはテーブル作成の一部として定義できます。ベクトルインデックスは、埋め込みを保持する属性、次元数、および距離関数を指定します。DynamoDB の他のセカンダリインデックスタイプと同様に、インデックスに射影する属性も指定します。 UpdateTable API で既存のテーブルにベクトルインデックスを追加することもできます。すでに保存されているデータでベクトル検索を使用するためにテーブルを再作成する必要はありません。 以下のコードはテーブルとそのベクトルインデックスを作成します。 import boto3 dynamodb = boto3.client('dynamodb') # ベクトルインデックスを持つテーブルを作成する dynamodb.create_table( TableName='Papers', AttributeDefinitions=[ {'AttributeName': 'paper_id', 'AttributeType': 'S'}, ], KeySchema=[ {'AttributeName': 'paper_id', 'KeyType': 'HASH'}, ], VectorIndexes=[ { 'IndexName': 'VectorIndex', 'VectorAttribute': {'AttributeName': 'embedding'}, 'Dimensions': 1024, 'DistanceFunction': 'DOT_PRODUCT', # COSINE | DOT_PRODUCT | EUCLIDEAN 'Projection': { 'ProjectionType': 'ALL', # ALL | KEYS_ONLY | INCLUDE } } ], BillingMode='PAY_PER_REQUEST' ) print("Table 'Papers' created with vector index. The table will be ready shortly.") 以下の設定の選択肢を検討してください。 Dimensions – インデックス内のベクトルの長さ。この値は埋め込みモデルの出力と一致する必要があります。DynamoDB は最大 4,096 次元のベクトルをサポートします。 Distance function – DynamoDB がベクトルを比較し、類似性で結果をランク付けするために使用する尺度。この例では、埋め込みが生成時に単位ベクトルに正規化されるため (ステップ 2 参照)、 DOT_PRODUCT を使用します。単位ベクトルの場合、ドット積はコサイン類似度と等しくなるため、 DOT_PRODUCT は COSINE と同じランキングを提供しつつ、コサインの内部正規化ステップをスキップします。ベクトルがまだ正規化されていない場合は COSINE を使用します (内部で正規化するため)。マグニチュードが重要な場合は EUCLIDEAN を使用します。 COSINE と EUCLIDEAN では、スコアが低いほど類似性が高いことを示します。 DOT_PRODUCT では、スコアが高いほど類似性が高いことを示します。 Projection – この設定は、どの属性がインデックスにコピーされ、したがって検索結果として返せるかを決定します。ベクトルとベーステーブルのキー属性は含まれます。 INCLUDE はリストされた属性を追加し、 ALL はすべてを追加し、 KEYS_ONLY は何も追加しません。この例では ALL を使用しており、検索が単一の呼び出しでタイトル、アブストラクト、著者を含む完全な論文レコードを返します。多数または大きな属性を持つワークロードでは、必要なもののみを射影する INCLUDE を検討してください。これにより、インデックスが小さくなり、検索が安くなります。 インラインフィルター (オプション) – ベクトル検索は、検索中に射影された属性の組み合わせでフィルタリングできます。この例ではインラインフィルタリングを使用しません。これは別のブログ記事で扱います。 パーティションキー (オプション) – ベクトルインデックスの全体的なスループットをスケールし、大規模なデータセットの検索あたりのコストを削減します。ベクトルインデックスは分散されているため、パーティションキーを定義するかどうかに関係なく水平方向にスケールします。インデックスのパーティションキーを定義すると、すべてのベクトル検索でその値を提供する必要があります。DynamoDB はその後、その値を持つアイテムを保持するインデックスの部分に検索を制限します。これにより、DynamoDB が応答するために処理するデータが少なくなるため、検索のコストが削減されます。スループットのクォータはパーティションキーの値ごとに適用され、パーティションキーの各異なる値には独自のクォータが与えられます。したがって、パーティションキーを定義することで、インデックスが維持できる書き込みおよび検索の全体的なスループットも上がります。この例ではパーティションキーを使用しないため、すべての検索がインデックス全体をカバーします。パーティションキーの使用は別のブログ記事で扱います。 テーブルとベクトルインデックスの作成は非同期で行われます。データをロードする前に、 DescribeTable API を使用して、テーブルとインデックスが ACTIVE であり、バックフィルが完了していることを確認します。 import time def wait_until_active(table_name, index_name): while True: table = dynamodb.describe_table(TableName=table_name)['Table'] table_status = table['TableStatus'] # 対象のベクトルインデックスを検索 index_status = None backfilling = False for vi in table.get('VectorIndexes', []): if vi['IndexName'] == index_name: index_status = vi['IndexStatus'] backfilling = vi.get('Backfilling', False) break print(f"Table: {table_status} | Vector index: {index_status} | Backfilling: {backfilling}") if table_status == 'ACTIVE' and index_status == 'ACTIVE' and not backfilling: print("Table and vector index are ready.") return table time.sleep(5) table = wait_until_active('Papers', 'VectorIndex') テーブルの準備ができると、テーブルとインデックスは ACTIVE を報告し、 Backfilling: False となります。 Table: CREATING | Vector index: CREATING | Backfilling: False Table: ACTIVE | Vector index: ACTIVE | Backfilling: False Table and vector index are ready. ステップ 2: 埋め込みを生成してテーブルにデータを投入する 次のステップでは、データセットから最初の 1,000 件の論文を読み込み、Bedrock (Amazon Titan Text Embeddings V2) でベクトル埋め込みを生成し、すべてを DynamoDB に保存します。 import boto3 import gzip import json import requests DATASET_URL = 'https://huggingface.co/datasets/gfissore/arxiv-abstracts-2021/resolve/main/arxiv-abstracts.jsonl.gz' SAMPLE_SIZE = 1000 # 最初の 1K 論文のみを含める def clean(text): """空白と改行を単一のスペースに折りたたむ""" return ' '.join((text or '').split()) def load_papers(): """データセットをストリームし、最初の SAMPLE_SIZE 論文のみを読み込む ファイルは gzip 圧縮された JSON Lines コーパス (約 940 MB) です。ストリーミングは、 すべてをダウンロードするのではなく、SAMPLE_SIZE レコードに必要なバイト数のみを読み込みます。 """ papers = [] headers = {'User-Agent': 'aws-dynamodb-vector-search-sample'} with requests.get(DATASET_URL, stream=True, headers=headers) as resp: resp.raise_for_status() # Hugging Face は不透明な .gz ボディを提供するため、明示的に解凍します。 resp.raw.decode_content = False with gzip.GzipFile(fileobj=resp.raw) as gz: for _, line in zip(range(SAMPLE_SIZE), gz): papers.append(json.loads(line)) return papers # クライアントを初期化 bedrock = boto3.client('bedrock-runtime') dynamodb = boto3.client('dynamodb') def generate_embedding(text): """Amazon Bedrock Titan Embeddings V2 を使用してベクトル埋め込みを生成する""" response = bedrock.invoke_model( modelId='amazon.titan-embed-text-v2:0', contentType='application/json', accept='application/json', body=json.dumps({ # Titan の入力上限 8,192 トークン以下に収めるために切り詰めます。 # 20,000 文字は安全なマージンを残します。 'inputText': text[:20000], 'dimensions': 1024, # ベクトルインデックスの設定と一致させる 'normalize': True }) ) result = json.loads(response['body'].read()) return result['embedding'] papers = load_papers() print(f"Loaded {len(papers)} papers. Generating embeddings and writing to DynamoDB...") # 埋め込み付きで論文を DynamoDB に書き込む for i, paper in enumerate(papers): title = clean(paper.get('title')) abstract = clean(paper.get('abstract')) # 豊かな埋め込みのためにタイトルとアブストラクトを結合 text_to_embed = f"{title}. {abstract}" embedding = generate_embedding(text_to_embed) # 埋め込みを数値のリストとして保存 embedding_list = {'L': [{'N': str(v)} for v in embedding]} dynamodb.put_item( TableName='Papers', Item={ 'paper_id': {'S': paper['id']}, 'title': {'S': title}, 'abstract': {'S': abstract}, 'authors': {'S': clean(paper.get('authors'))}, 'embedding': embedding_list, # ベクトル属性 } ) if (i + 1) % 100 == 0: print(f" Processed {i + 1}/{len(papers)} papers...") print(f"Done! {len(papers)} papers stored with embeddings.") この例では、論文のタイトルとアブストラクトを一緒に埋め込むことで、論文の内容をキャプチャするテキスト表現を作成します。「画像を認識するためにコンピュータを訓練する」という検索クエリは、画像分類や物体検出に関する論文にマッチします。意味が近ければ、タイトルにその正確な単語が現れなくてもマッチします。タイトルとアブストラクトを埋め込むのは、それらが一緒に論文の核心的な意味を持つからです。著者はアイテムに引き続き保存されるため、各結果と一緒に返されます。 このスクリプトは論文を一度に 1 つずつ処理するため、1,000 件すべての論文をロードするのに約 2〜4 分かかります (1 論文あたり数百ミリ秒)。その時間のほとんどは Bedrock の埋め込み呼び出しに費やされます。 ベクトルインデックスにデータを投入する各書き込みは、ベクトル書き込み容量も消費します。 PutItem の呼び出しに ReturnConsumedCapacity='INDEXES' を設定して、ベクトル書き込みのコストを確認します。応答の ConsumedCapacity オブジェクトは、テーブル自身の書き込み容量と並んで、 VectorIndexes マップの下に各ベクトルインデックスで消費された VectorWriteRequestBytes を報告します。 TOTAL はテーブルの書き込み容量のみを返しベクトルインデックスのコストは省略されるため、 TOTAL ではなく INDEXES を使用してください。 ReturnConsumedCapacity='INDEXES' を設定すると、返される ConsumedCapacity は次のようになります。 { "TableName": "Papers", "CapacityUnits": 5.0, "Table": { "CapacityUnits": 5.0 }, "VectorIndexes": { "VectorIndex": { "VectorWriteRequestBytes": 4820.0 } } } テーブル自身の書き込み容量とベクトルインデックスの書き込みコストは別々に報告されるため、書き込みのコストのどれだけがベクトルインデックスの維持から発生しているかを確認できます。このコストの課金方法と価格設定については、 Amazon DynamoDB の料金ページ をご覧ください。 ステップ 3: ベクトルインデックスを検索する データがロードされると、テーブルはセマンティック検索の準備が整います。以下のコードでは、ステップ 2 の generate_embedding 関数を使用して自然言語クエリを埋め込み、 SearchVectors API を呼び出して最も類似する論文を見つけます。 import boto3 import json bedrock = boto3.client('bedrock-runtime') dynamodb = boto3.client('dynamodb') def search_papers(query_text, top_k=5): """セマンティック類似性を使用して論文を検索する""" # 検索クエリの埋め込みを生成 query_embedding = generate_embedding(query_text) # 検索ベクトルは数値のリストで、保存された属性と同じ形状 search_vector = [{'N': str(v)} for v in query_embedding] # ベクトル検索を実行 response = dynamodb.search_vectors( TableName='Papers', IndexName='VectorIndex', SearchVector=search_vector, TopK=top_k, ReturnConsumedCapacity='INDEXES', ) return response # サンプル検索 queries = [ "detecting gravitational waves from black hole mergers", "improving the efficiency of solar cells", "quantum error correction for fault-tolerant computing", ] for query in queries: print(f"\nQuery: \"{query}\"") print("-" * 50) response = search_papers(query, top_k=3) for rank, result in enumerate(response['SearchResults'], 1): item = result['Item'] score = result.get('Score', 'N/A') title = item['title']['S'] print(f" {rank}. {title} (score: {score})") # 応答は、クエリが処理したベクトル検索のバイト数を報告する consumed = response.get('ConsumedCapacity', {}) print(f" VectorSearchRequestBytes: {consumed.get('VectorSearchRequestBytes')}") SearchVectors の応答には SearchResults リストが含まれます。各要素は 2 つの部分を持ちます。 Item – ベクトルインデックスから一致したアイテムの射影された属性。 Score – インデックスの距離関数に基づいて、結果がクエリベクトルにどれだけ近いかを示す類似性スコア。 ReturnConsumedCapacity を INDEXES または TOTAL に設定すると、応答には、クエリが処理した VectorSearchRequestBytes を報告する ConsumedCapacity オブジェクトも含まれます。デフォルトの NONE は、これを省略します。ベクトル検索はベクトルインデックスからのみ読み取るため、内訳を出す別のベーステーブル容量はありません。ここでは、 INDEXES と TOTAL は同じ数値を返します。これは、書き込みとは異なります。書き込みでは、 INDEXES のみがベーステーブルの書き込みに加えてベクトルインデックスのコストを露出します。 デフォルトでは、ベクトル属性はアイテムと一緒に返されません。その理由と、リクエストする方法については「知っておくべきこと」パートをご覧ください。 ベクトルインデックスの使用量はどのように課金されるか ベクトルインデックスは、アイテムを保持する基礎となるテーブルに対する標準の DynamoDB 課金に加えて、3 つの次元で課金されます。インデックスに書き込むデータ、検索時に処理されるデータ、および保存するデータに対して料金が発生します。3 つすべてがバイトごとに計測され、GB ごとに課金されるため、プロビジョニングする容量ユニットはなく、各オペレーションが実行する作業に比例してコストがスケールします。 ベクトル書き込みリクエスト – ベクトルインデックスに書き込まれたデータに対して料金を支払います。これには、ベクトル自体とインデックスに射影された非ベクトル属性が含まれます。ベクトル属性や射影された属性に触れない書き込みは、ベクトル書き込みとして課金されません。これらの料金は、ベーステーブルの標準書き込み料金に加えて発生します。 ベクトル検索 – 類似性検索に応答するために処理されたデータに対して料金を支払います。インデックスがパーティションキーを定義している場合、検索は検索されたパーティションキーの値を持つアイテムを保持するインデックスの部分に制限されます。これにより、処理されるデータが減少し、したがって検索コストが削減されます。 ストレージ – ベクトルインデックスに保存されているデータに対して、GB-月あたりの料金を DynamoDB テーブルストレージと同じレートで支払います。 各オペレーションは、応答の ConsumedCapacity オブジェクトで消費されたベクトル容量を報告するため、コストを特定の書き込みや検索に帰属させることができます (ステップ 2 とステップ 3 を参照)。ベクトル使用量はバイトごとに計測されるため、これらの値は各オペレーションが処理したバイト数を追跡します。各ベクトル書き込みと各ベクトル検索には、最小課金サイズが 1 KB あります。1 KB を下回るオペレーションは 1 KB として計測され、それを超える場合はバイトごとに計測されます。これは、書き込みでインデックスに書き込まれたデータと、類似性検索に応答するために処理されたデータの両方に適用されます。 Standard または Standard-Infrequent Access テーブルクラスを使用するテーブルでベクトルインデックスを使用できます。GB あたりの料金については、 Amazon DynamoDB の料金 を参照してください。 コストを最適化するには、以下のプラクティスを検討してください。 ユースケースが最大の精度を必要としない場合は、256 または 512 などのより低い次元を使用します。これにより、ストレージ、書き込みごと、検索ごとのコストが同時に削減されます。 射影されたアイテムのサイズがストレージと検索が処理するバイト数の両方を左右するため、必要な属性のみをインデックスに射影します。 デフォルトでは埋め込みが結果に含まれないので、そのバイト数が検索料金にカウントされないようにしてください。必要なときにのみベクトルを射影します。 アクセスパターンに合う場合は、パーティションキーを持つインデックスを使用します。検索は検索された値を持つアイテムを保持するインデックスの部分のみをカバーし、より少ないバイトを処理します。 知っておくべきこと アプリケーションを設計する際に、DynamoDB ベクトル検索の以下の特性を念頭に置いてください。 オンデマンド容量モード – ベクトルインデックスは、オンデマンド ( PAY_PER_REQUEST ) 容量モードを使用するテーブルでのみサポートされます。 アイテムは必要な属性を持つ場合にのみインデックス化される – アイテムは、ベクトル属性を含む場合にのみベクトルインデックスに追加されます。インデックスがパーティションキーを定義している場合、アイテムはインデックスに含まれるためにそのパーティションキー属性も含む必要があります。 結果整合性 – ベクトルインデックスはアイテムがテーブルに書き込まれると非同期に更新されるため、ベクトル検索は結果整合性です。新しく書き込まれたか更新されたアイテムは、すぐに検索結果に表示されないかもしれませんが、インデックスが追いついた直後に検索可能になります。 ベクトルはデフォルトでは返されない – 埋め込みはインデックスに保存されていますが、 SearchVectors は結果から除外します。これにより、処理されるバイト数、したがって検索コストが増大しないようにします。必要な場合は、検索の ProjectionExpression で明示的にリクエストします。 ベクトル次元 – DynamoDB は最大 4,096 次元のベクトルをサポートし、インデックスの次元は埋め込みモデルの出力と一致する必要があります。 追加料金なしのバックフィル – UpdateTable API で既存のテーブルにベクトルインデックスを追加すると、DynamoDB は無料でインデックスをバックフィルします。バックフィルは、テーブルのアイテムにすでに保存されているベクトル属性を使用します。 インデックス設定は不変 – ベクトルインデックスの設定は、インデックスが作成されたときに設定され、その後変更できません。これには、次元、距離関数、射影、インラインフィルター属性、およびパーティションキーが含まれます。これらのいずれかを変更するには、必要な設定で新しいベクトルインデックスを作成します。前述のように、DynamoDB は新しいインデックスを無料でバックフィルします。1 つのテーブルは、デフォルトで最大 5 つのベクトルインデックスを持つことができます。 セカンダリインデックスのベクトル属性 – アイテムにベクトル属性を追加すると、すべての属性を射影するセカンダリインデックスに影響します。 ProjectionType: ALL で作成されたグローバルセカンダリインデックス (GSI) またはローカルセカンダリインデックス (LSI) は、新しいベクトル属性を自動的にインデックスにコピーします。これにより、インデックスのストレージ、書き込み、および読み取りのコストが増加する可能性があります。インデックスがベクトルを必要としない場合、そのインデックスが使用する属性のみを射影します。既存のすべての属性の GSI を、ベクトルを除外する特定の属性セットを射影するものに置き換えることができます。ただし、LSI はテーブルが作成されたときに固定され、その後追加または削除できないため、テーブル作成時に事前にその射影を計画してください。 パーティションキーごとのスループットクォータ – ベクトルインデックスの書き込みおよび検索のスループットは、パーティションキー値ごとに適用されるクォータの対象となります。現在の制限については、 DynamoDB のクォータ を参照してください。パーティションキーのないインデックスは、単一のクォータの対象となります。パーティションキーを持つインデックスは、パーティションキーの値ごとに個別のクォータを取得し、これによりインデックスが維持できる合計スループットが向上します。 クリーンアップ 将来の料金が発生しないように、このウォークスルーで作成したリソースを削除してください。DynamoDB テーブルを削除すると、そのベクトルインデックスも削除されます。 import boto3 dynamodb = boto3.client('dynamodb') dynamodb.delete_table(TableName='Papers') print("Table 'Papers' deletion initiated. The table will be removed shortly.") Bedrock のオンデマンド埋め込み呼び出しはリクエストごとに課金されるため、このウォークスルーで削除する常設の Bedrock リソースはありません。 まとめ DynamoDB のネイティブベクトル検索を使用すると、すでに運用データに使用しているデータベースで類似性検索を実行できます。別のベクトルストアなしで、よりシンプルなアーキテクチャ、より少ない運用オーバーヘッド、より低いレイテンシー、より低いコストを得ながら、DynamoDB のサーバーレススケーリングと予測可能なパフォーマンスを維持できます。 この記事では、ベクトルインデックスを持つ DynamoDB テーブルを作成し、Bedrock で埋め込みを生成し、DynamoDB にロードし、自然言語クエリでセマンティック検索を実行しました。セマンティック検索、レコメンデーションエンジン、または RAG アプリケーションを構築する場合でも、運用データとベクトルワークロードの両方に単一のサーバーレスサービスを使用できます。 始めるには、 DynamoDB ベクトル検索のドキュメント と GitHub の完全なコードサンプル を確認し、ベクトルインデックスを持つテーブルを作成してください。 論文のメタデータは arxiv-abstracts-2021 データセットからのもので、 CC0 1.0 Universal (パブリックドメイン) の下でライセンスされています。 本記事は 2026 年 08 月 05 日 に公開された “Build semantic search with native vector support in Amazon DynamoDB” を翻訳したものです。 原文: https://aws.amazon.com/blogs/database/build-semantic-search-with-native-vector-support-in-amazon-dynamodb/ 著者について Leonid Koren Leonid は AWS のプリンシパル NoSQL ソリューションアーキテクトで、既存のアプリケーションの近代化や NoSQL データベースを使用した新規アプリケーションのアーキテクチャ設計をお客様に支援しています。AWS に入社する前、Leonid は 2000 年代初頭からバックエンドシステムの設計と開発を行っていました。 Mo Kamioner Mo はイスラエルのエルサレムを拠点とする AWS のシニア DynamoDB ソリューションアーキテクトです。あらゆる規模のワークロードで 10 年以上 DynamoDB に携わり、世界中のお客様が DynamoDB の実装を設計、最適化、スケールすることを支援しています。Mo は複雑な問題に対するシンプルな解決策を見つけることに情熱を持っており、オフの時間には子供たちと IoT や Lego をいじっている姿が見られます。