Elastic 9.5の新機能を速報解説：保存、ベクトル検索、AI運用はどう変わるのか

Elastic 9.5では、ログの保存方法、ベクトル検索、マルチモーダル検索、AIエージェントの運用、Prometheusからの移行など、幅広い領域に新機能が追加されました。

今回のポイントは、単に機能が増えたことではありません。これまでエンジニアが手作業で行っていた保存方式の最適化、ベクトル検索の設定、PromQLの書き換え、AIエージェントの調査を、Elastic側がより多く引き受ける方向へ進んだことです。

この記事では、Elastic 9.5の主要機能について、次の4点に絞って説明します。

• 何を解決する機能なのか
• 9.5で何が変わったのか
• どのような人や環境に役立つのか
• 導入前に何を注意すべきか

対象バージョン：Elastic 9.5（2026年8月4日リリース）
想定読者：Elasticを利用しているエンジニア、導入を検討しているアーキテクト、運用担当者

まず押さえたいGAとTech Preview

Elastic 9.5の機能は、すぐに本番利用を検討できるGA（正式提供）と、まず検証環境で試すべきTech Previewに分かれます。

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機能で優先度が高いもの

検証環境で試すTech Preview

Tech Previewでは、既存環境を直接変更するのではなく、小さな新規インデックスや限定したデータセットで比較するのが安全です。

まとめ

Elastic 9.5は、次の3つの方向へ進んだリリースと整理できます。

1. データ保存を効率化する
   Columnar Modeにより、大量ログを分析と長期保存へ最適化します。
2. 検索とAIの構築作業を減らす
   VectorDB index mode、Auto-calibration、マルチモーダルsemanticフィールドにより、ベクトル検索の開始を簡単にします。
3. 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