OpenSearch Serverless が S3 の PDF やログを直接取り込み、対象は NextGen だけ

S3 に置いたログや PDF を OpenSearch で検索できるようにするのに、取り込み用のパイプラインを自分で組まなくてよくなった。AWS が2026年10月22日に公開した Amazon OpenSearch Serverless の intelligent ingestion は、S3 のソースとコレクションのインデックスを選ぶだけで動く。データ型の判定、文書の解析、テキストのチャンク分割、ベクトル埋め込みの生成、インデックス登録までを引き受ける。設定は AWS マネジメントコンソールで数クリックか、API 呼び出し1回で済み、取り込み用のインフラを管理する必要はない。

条件は三つある。使えるのは OpenSearch Serverless の NextGen コレクション だけで、ソースは S3 に限られ、提供リージョンは7つだ。手元のコレクションがこれに当てはまるかが最初の分かれ目になる。

取り込める形式は2系統

系統	形式	取り込み時の処理
ログ・構造化データ	JSON、NDJSON、JSON 配列	変換を適用。埋め込みの付与は任意
非構造化ファイル	PDF、Word、プレーンテキスト、Markdown	見出し・読み順・表を保って解析し、チャンク分割と埋め込み生成

出典：AWS What’s New「Amazon OpenSearch Service introduces intelligent ingestion for logs and documents in Amazon S3」（2026年10月22日）

ログ側は、パイプラインのコードを書かずに変換がかかり、必要なら埋め込みも付く。どんな変換が適用されるのか、自動判定されたフィールドの型を後から指定し直せるのかは、発表には書かれていない。既存のログ用インデックスでマッピングを厳密に決めているチームは、ここを先に確かめたほうがいい。

文書側で実務に効くのは画像の扱いだ。PDF や Word にグラフ、図、スクリーンショット、写真が含まれていると、vision-language model がそのテキスト説明を生成し、周囲の本文と一緒にインデックスする。図の中にしか書かれていない情報も検索に掛かる。解析結果はセマンティック検索とハイブリッド検索にそのまま使える状態で入る、と AWS は説明している。

一度きりの job と、追い続ける stream

取り込みの単位は2種類ある。ingestion job は一度きりのロードで、移行やバックフィルに使う。ingestion stream は、バケットに新しいオブジェクトが届くたびにインデックスを同期し続ける。

S3 に過去数年分のログや社内文書がすでに溜まっているなら、job で過去分を流し込み、以降は stream で新着を追う組み合わせが考えやすい。ただしこれは発表の説明から組み立てた使い方で、同じインデックスに job と stream を重ねたときに重複がどう扱われるかは書かれていない。stream がオブジェクトの削除や上書きをインデックスに反映するかも、発表からは読み取れない。継続運用に乗せる前に確認したい点だ。

容量の上限はコレクション側で決まる

容量を事前に見積もる必要はない。処理能力はワークロードに合わせて伸びるが、上限はコレクションに設定した値までだ。大量のバックフィルを流すときに、どこで頭打ちになるかはその設定次第になる。

課金は実際に処理している間の分だけ、と発表は書いている。単価、埋め込み生成や画像説明の生成が別建てになるかは発表本文に載っていないため、見積もりを出す前に料金表を確認する必要がある。

別アカウントのバケットもそのまま使える

ソースの S3 バケットは、コレクションと同じアカウントにあっても別のアカウントにあってもよい。ログ集約用のアカウントにバケットを置き、検索用のコレクションを別アカウントで持つ構成でも、データを移さずに取り込める。そのときに必要なバケットポリシーや IAM ロールの具体的な形は、発表には示されていない。

着手前に見る順番

1. 使うコレクションが NextGen かどうか。
2. そのリージョンが7つの提供リージョンに入っているか。発表はリージョン名を挙げていないので、東京や大阪で使えるかは個別に確認が要る。
3. 過去分の一括投入（job）か、新着の同期（stream）か、その両方か。
4. 埋め込みや画像説明を含めた処理量が、料金表でいくらになるか。

条件が揃えば、OpenSearch Service のコンソールでコレクションを選び、Ingestion タブから設定を始められる。