OpenSearchの新エンジンは無料でログ分析を刷新

Amazon OpenSearch Service（Elasticsearchから派生したオープンソースの検索・分析エンジンをAWSがフルマネージドで提供するサービス）は、ログ検索とダッシュボード集計を支える基盤として多くの企業のオブザーバビリティ環境を担っている。だが運用するドメイン（OpenSearchのクラスタ管理単位）が肥大化するほど、ストレージ費用とクエリ待ち時間が現場の悩みになっていた。

AWSは2026年7月1日、ログ分析ワークロードに特化した新しいエンジンモードをOpenSearch Serviceで一般提供（GA）した[1]。既存の汎用エンジンと同じドメイン管理・API・セキュリティモデルを使いながら、列指向ストレージ（データを列単位でまとめて格納し集計処理を高速化する保存方式）を採用し、ストレージ量とクエリ速度の両面でベンチマーク上の大幅な改善を打ち出す。しかも料金体系は既存のままで、利用に追加費用は発生しない[1][2]。

対象になるのは、OpenSearch Serviceでログ検索・監視ダッシュボード・セキュリティ分析を運用しているインフラ担当者だ。本記事ではベンチマーク数値の中身と、既存クラスタから移行する際の制約を整理し、コスト視点での判断材料を示す。

予備知識

• OpenSearch: Elasticsearchから派生したオープンソースの検索・分析エンジン。全文検索とログ集計の両方を担う
• 列指向ストレージ: データを列単位でまとめて格納する方式。特定の列だけを読めばよい集計処理が高速になる
• Apache Parquet: 列指向データを保存するオープンなファイル形式。新エンジンの保存フォーマットに採用されている
• DSL / PPL: DSL（Query DSL）はOpenSearch従来のJSON形式クエリAPI。PPL（Piped Processing Language）はパイプでつなぐ構文のクエリ言語で、新エンジンはPPLとSQLのみに対応する

クラウド／コスト／移行

Azure GPv1ストレージ廃止：移行で逆にコスト増になるケースの見極め

Azure Storage GPv1（General Purpose v1、汎用ストレージアカウント旧バージョン）が2026年10月13日に廃止される。Azureでストレージアカウントを持つ組織は、この期日までにGPv2（Gener[…]

OpenSearch Serviceの新エンジンとは何か　列指向ストレージで何が変わるのか

新エンジンは、ログデータをApache Parquet形式の列ストアに保存しつつ、検索対象に設定したフィールドは従来通り転置インデックス（キーワードから該当データを高速に引ける索引構造）にも書き込む方式を採る[2]。

クエリはApache Calciteが解析・最適化し、集計系の処理はApache DataFusionへ、キーワード検索はLuceneへ振り分ける[2]。両エンジンはクエリの途中で処理を受け渡せるため、ログ本文の検索と数値の集計を1つのクエリ内で完結でき、往復のやり取りを増やさずに済む。データはベクトル化された列単位のバッチで処理されるため、大量ログの集計クエリでスループットが伸びやすい構造になっている[2]。

新エンジンを使うにはOpenSearch 3.5以上でドメインを作成し、コンソールでユースケースを「オブザーバビリティ」、エンジンモードを「最適化（optimized）」に選ぶ必要がある[2]。API・セキュリティ設定は既存の汎用エンジンと共通で、接続方式を大きく変える必要はない。

クラウド／コスト

AI推論コストが加速するクラウド・リパトリエーション

AI推論を24時間止めずに動かすコストと、クラウドの外へデータを出すたびに課される通信費（エグレス費用）が、企業のインフラ判断を揺さぶっている。銀行大手Barclaysが四半期ごとに実施するCIO調査（2024年第4四半期）では、8[…]

ベンチマークで見る性能差　旧エンジンとの比較

AWSが公開した内部ベンチマークによれば、新エンジンは価格性能比で最大4倍、データ取り込みスループットで最大2倍、分析クエリ速度で最大2倍の改善を示し、ストレージ使用量は最大70%削減される[1][2]。

いずれも「最大」という上限値であり、実際の改善幅はログのスキーマ設計・クエリパターン・データ量に左右される。それでも、集計中心のログ分析ワークロードでは列指向ストレージの効果が出やすく、ダッシュボード集計やアラート判定のような繰り返しクエリほど恩恵を受けやすい構造だ。

ストレージ70%削減は、同じコストで約3倍のデータを保持できることも意味する[2]。保持期間の延長がコストの壁で見送られていたセキュリティログや監査ログでは、保持ポリシーを見直す材料になる。

コスト

Seedance 2.0とは？使い方・料金・日本での使い方を解説｜音声つきで世界1位のByteDance製AI動画【2026】

※本記事は2026年7月時点の情報です。料金・提供条件は変動が速いため、最新は各公式でご確認ください。一部アフィリエイトリンクを含みます。 ✅ 先に結論（Seedance 2.0の要点） 何がすごい[…]

追加コストなしの仕組みと対象リージョン　誰がすぐ使えるのか

新エンジンの料金は既存の汎用エンジンと同じインスタンス・ストレージの標準課金がそのまま適用され、プレミアムは上乗せされない[1][2]。ハードウェア構成を変えずに性能とストレージ効率が上がる設計で、追加のライセンス費用や専用インスタンスタイプは不要だ。

GA時点の提供リージョンは12リージョンで、米国東部（バージニア北部・オハイオ）、米国西部（オレゴン）、カナダ（中部）、アジアパシフィック（ムンバイ・シンガポール・シドニー・東京）、欧州（フランクフルト・アイルランド・ロンドン・スペイン）が含まれる[2]。東京リージョンが初期提供に含まれているため、国内でログ分析基盤をOpenSearch Serviceで運用している企業もGA直後から利用を検討できる。

対象になるのは、OpenSearch Serviceを可観測性用途、つまりログ検索・メトリクス集計・SIEM相当のセキュリティ分析で使っているチームだ。全文検索エンジンとしての用途がメインで集計処理が少ない場合は、恩恵が相対的に小さい点は踏まえておきたい。

移行判断のポイント　制約と注意点

新エンジンは既存ドメインへの後付けができず、個別インデックスやフィールド単位での部分適用もできない。利用するには新規にドメインを作成し、データ取り込みパイプラインの向き先を新ドメインへ切り替える必要がある[3]。

もう一つの制約はクエリ言語だ。GA時点でサポートされるのはPPLとSQLのみで、従来のDSL（JSON形式のクエリAPI）は非対応となっている[2]。DSLベースで組んだダッシュボード・アラート・自動化スクリプトが多い環境では、PPLやSQLへの書き換えが移行の前提作業になり、その分だけ移行スケジュールが延びる[3]。

移行を検討する際は、まずDSLへの依存度を棚卸しし、次にOpenSearchバージョンを確認したうえで、新規ドメインでの並行検証を挟む順序が現実的だ。追加費用がかからない分、限定的なワークロードで先行検証し、ベンチマーク通りの改善が出るかを自社データで確かめてから本番切り替えを判断する進め方がリスクを抑えられる。

まとめ

OpenSearch Serviceの新エンジンは、既存の料金体系のままストレージを最大70%削減し、クエリ速度を最大2倍に引き上げる選択肢を、ログ分析用途の運用者に提示した。追加費用がかからない点は移行検討のハードルを下げるが、既存ドメインへの後付けができずDSLも非対応という制約は無視できない。移行判断の起点は、自社のダッシュボードやアラートがDSLにどれだけ依存しているかの棚卸しであり、依存度が低いチームほど先行して恩恵を得やすい。次のログ基盤の見直しサイクルで、新規ドメインでの検証を候補に入れておく価値がある。

よくある質問（FAQ）

Q1. 既存のOpenSearchドメインをそのまま新エンジンに切り替えられますか。
A. できません。新エンジンはドメイン作成時に選ぶエンジンモードで、既存ドメインへの後付けや個別インデックス単位での部分適用はサポートされていません。利用するには新規ドメインを作成し、取り込みパイプラインを切り替える必要があります[3]。

Q2. 追加費用は本当にかかりませんか。
A. AWSの発表によれば、新エンジンは既存のインスタンス・ストレージの標準課金がそのまま適用され、プレミアムの上乗せはありません[1][2]。ただし新規ドメインを並行稼働させる移行期間中は、旧ドメイン分の費用が重複して発生する点は考慮が必要です。

Q3. DSLで組んだダッシュボードはどうなりますか。
A. GA時点の新エンジンはPPLとSQLのみに対応し、DSL（JSON形式のクエリAPI）は非対応です。DSLに依存したダッシュボードやアラートは、移行前にPPLまたはSQLへの書き換えが必要になります[2][3]。

出典