ログ量の増加で予算と保持期間の板挟みになっていた運用チームに、AWSが現実的な選択肢を足しました。
2026年7月1日、Amazon OpenSearch Serviceにログ分析専用の最適化エンジンが追加されました。ストレージコスト最大70%削減、取り込み性能2倍、分析クエリ2倍高速化を、追加料金なしで提供します（参考）。
この記事では、新エンジンの技術的な変更点と、導入時に押さえるべき前提条件を整理します。
この記事でわかること
- ログ分析専用エンジンが解決する課題と性能改善の中身
- Apache Parquetとクエリルーティングによる仕組み
- 新ドメイン作成から使い始める手順
- 既存ドメインから移行する際の制約と注意点
ログ増加が運用コストを押し上げていた
Amazon OpenSearch Serviceは、分散検索と分析を担うマネージドサービスです。アプリ監視、ログ分析、セキュリティ監視、オブザーバビリティなど、リアルタイムにログを検索・集計する用途で広く使われています。
AWSのソリューションアーキテクトらによる説明では、多くの組織でログ分析のデータ量が年間30〜40%ずつ増えているとされています（参考）。クラウドネイティブ化、コンプライアンス要件の拡大に加え、AIアプリケーションが吐き出すテレメトリが追い打ちをかけています。
このまま従来の汎用エンジンで抱え続けると、予算を増やすか、別の分析データベースを二重に持つか、分析せずにログを捨てるかの三択に追い込まれます。集計やトレンド分析の比重が高まる一方、障害調査では全文検索が欠かせないため、単純な置き換えも難しいのが実情です。
何が変わったか：ログ分析専用エンジンの追加
今回の更新は、OpenSearch Serviceのドメイン内で選べる「最適化エンジン」の追加です。従来の汎用エンジンに加え、ログ分析ワークロード向けに設計されたモードが選べるようになりました。
AWSの社内ベンチマークでは、価格対性能が最大4倍、ストレージコスト最大70%削減、同じハードウェアで取り込みスループット2倍、分析クエリ2倍の高速化が報告されています。同コストで最大3倍のデータを保持できる計算も示されています。新エンジン自体に追加料金はかかりません。インスタンスとストレージの標準料金のみです。
管理コンソール、API、セキュリティモデル、ネットワーク設定は既存の汎用エンジンと共通です。運用画面や権限設計を一から作り直す必要はありません。
ストレージとクエリ処理の仕組み
従来のOpenSearchは、検索向けの転置インデックス（inverted index）を中心にデータを保持してきました。ログ分析では集計クエリの比重が高い一方、障害対応では特定文字列の全文検索が必要です。一つのストレージ方式ですべてを最適化するには限界がありました。
新エンジンは、集計向けデータをカラム型のApache Parquet形式で保存します。辞書エンコードや数値の密なパッキングにより、JSON形式のドキュメント単位オーバーヘッドを抑えます。検索が必要なフィールドには、引き続きApache Luceneのインデックスを維持します（参考）。
クエリ処理ではApache Calciteがクエリを解析し、最適なサブエンジンへ振り分けます。カラムデータへの集計・分析はApache DataFusionが担当し、全文検索の述語はLuceneが処理します。MATCHやMATCH_PHRASEといった全文検索述語が、SQLとPiped Processing Language（PPL）のクエリ内でネイティブに動作します。1つのクエリで集計結果を絞り込み、特定ログのポイント検索まで行えるのが大きな変化です。
AWSエンジニアのベンチマークでは、244億ドキュメント・生JSON 9.5TBのデータに対し、取り込みスループットは毎秒178万ドキュメントで、スタンドアロンのApache Luceneの約2倍に達したと報告されています。数十億件規模のログに対する時間フィルタ付き分析クエリはミリ秒単位で処理され、価格対性能は4倍の改善が示されています（参考）。
使い方：新ドメインでの有効化手順
最適化エンジンは、ドメイン作成時に選択する必要があります。既存ドメインへの後付けや、汎用ドメイン内の個別インデックスへの適用はできません。
手順の要点は次のとおりです。
- OpenSearch 3.5以上で新しいドメインを作成する
- AWSコンソールでユースケースに「observability（オブザーバビリティ）」を選ぶ
- エンジンモードを「optimized（最適化）」に設定する
データの探索はOpenSearch UI上のPPLで行えます。SQLでの問い合わせはAPI、JDBC/ODBCドライバー、Query Workbenchから利用できます。全文検索述語と分析SQLを同一クエリに組み合わせることも可能です。
提供リージョンは12か所です。米国東部（バージニア北部・オハイオ）、米国西部（オレゴン）、カナダ（中部）、アジア太平洋（ムンバイ・シンガポール・シドニー・東京）、欧州（フランクフルト・アイルランド・ロンドン・スペイン）で利用できます。OpenSearch Optimized Instancesが提供されているリージョンが対象です。
既存環境から移行する際の注意点
新エンジンの恩恵を受けるには、新ドメインの立ち上げと取り込みパイプラインの切り替えが必要です。単純な設定変更では済みません。
一方で、取り込みは従来と同じBulk APIとクライアントライブラリを使えます。アプリケーションコードや取り込みパイプラインの変更は不要とAWSは説明しており、移行の摩擦は下げられています（参考）。
既存ドメインを稼働させたまま新ドメインへ段階的に切り替える構成が現実的です。ダッシュボードやアラートの再設定、過去ログの再取り込み方針など、移行計画に含める項目は残ります。頻繁に更新が走るワークロードでは、移行期間の設計に余裕を持たせる必要があります。
汎用エンジンとの使い分け
汎用エンジンは、Webサイト検索のように検索中心のワークロードに向いています。今回の最適化エンジンは、ログの集計・トレンド分析が主で、障害調査の全文検索も併用するオブザーバビリティ用途を想定しています。
AIワークロードのテレメトリ増加でログ保持コストが課題になっているチームにとって、同じOpenSearch Serviceの枠内で分析性能とコスト効率を両立できる点が実務的なメリットです。追加料金なしで提供されるため、新規のログ分析基盤を検討している段階から最適化エンジンを選択肢に入れやすいアップデートと言えます。