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 .

Elastic Stack（ELKスタック）を導入する際、多くのエンジニアが最初に頭を悩ませるのが「データの収集・加工（前処理）に何を使うか」という問題です。 かつては「前処理といえばLogstash」の一択でしたが、Elasticsearchに  Ingest Pipeline  が実装されて以降、その手軽さとパフォーマンスから強力な選択肢となっています。 本記事では、LogstashとIngest Pipelineのアーキテクチャの違い、機能面での優劣、そして「結局どちらを選ぶべきか」の判断基準を技術者視点で解説します。 目次 1. LogstashとIngest Pipelineの概要 Logstash とは？ Ingest Pipeline とは？ 2. 4つの軸で見る決定的な違い ① 入出力の柔軟性（Inputs & Outputs） ② データの加工・拡充能力（Transformation） ③ 耐障害性とバッファリング（Queueing） ④ インフラ構成と運用コスト 3. 【結論】どちらを選ぶべきか？ ユースケース別の推奨 ✅ Ingest Pipeline を選ぶべきケース ✅ Logstash を選ぶべきケース 💡 比較サマリー 💡 ハイブリッド構成（併用）という選択肢も まとめ 1. LogstashとIngest Pipelineの概要 比較に入る前に、それぞれの立ち位置を簡単におさらいしておきましょう。 Logstash とは？ データ処理パイプラインを構築するための独立した外部サーバー（コンポーネント）です。豊富なプラグイン（Input / Filter / Output）を備え、多様なデータソースからデータを吸い上げ、複雑な加工を施した上で、Elasticsearchをはじめとする様々な宛先にデータを送信できます。 Ingest Pipeline とは？ Elasticsearchのクラスタ内部（Ingestノード）で動作する  前処理機能です。データがElasticsearchにインデックス（格納）される直前に、JSON形式のドキュメントに対して「プロセッサ」と呼ばれる処理を数珠つなぎに適用してデータを加工します。 2. 4つの軸で見る決定的な違い 2つのコンポーネントの特性を、「入出力」「データ加工能力」「耐障害性」「運用コスト」の4つの軸で比較します。 ① 入出力の柔軟性（Inputs & Outputs） Logstash: 圧倒的な柔軟性を持ちます。HTTPやSyslogなどのPush型だけでなく、リレーショナルデータベース（JDBC）やメッセージキュー（Kafka, RabbitMQ）からデータを自発的に取得（Pull）できます。また、加工したデータをElasticsearchに送りつつ、同時にS3へ生ログをアーカイブする、といった マルチ出力 が可能です。 Ingest Pipeline: あくまですべての処理が「Elasticsearchにデータが書き込まれるタイミング」で動作するため、外部へデータを読みに行くことはできません。Beatsやアプリケーションからデータを「Push」してもらう必要があります。また、出力先もパイプラインが動いているElasticsearch自身に限定されます。 ② データの加工・拡充能力（Transformation） Logstash: 条件分岐（if-else）のネストや、Rubyプラグインを用いたコードレベルでの柔軟な記述が可能です。また、処理中に外部のファイルやデータベースを参照してデータを補完（エンリッチ）する処理も得意です。 Ingest Pipeline: Grok、GeoIP、JSONなどの主要なプロセッサが標準搭載されており、一般的なログ（Apache, Nginx, システムログなど）のパースであれば十分すぎる性能を持っています。 enrich  プロセッサを使えばElasticsearch内の別インデックスを参照したデータ拡充も可能ですが、Logstashほど外部システムと密に連携した複雑な加工はできません。 ③ 耐障害性とバッファリング（Queueing） Logstash: 永続的キュー（Persistent Queues）を内蔵しています。Elasticsearch側が一時的なスパイクやメンテナンスでデータを受け付けなくなっても、Logstashがローカルディスクにデータを安全にバッファリングし、データロストを防ぎます。 Ingest Pipeline: 自身にデータを溜めるディスクキューはありません。Elasticsearchのインデキシング負荷が高くなると、データ送信元（Beatsなど）に対して「これ以上送らないでくれ」というバックプレッシャーをかけます。送信元がバッファを持っていない場合、データロストの追跡や再送管理を送信元側で担保する必要があります。 ④ インフラ構成と運用コスト Logstash: 独立したプロセス（JVM）として動くため、メモリやCPUの設計、パッチ当て、監視などの運用コストが上乗せされます。ただし、データ処理の負荷をElasticsearchクラスタから完全に分離できるというメリットもあります。 Ingest Pipeline: 新たにサーバーを構築する必要がありません。KibanaのUIやREST APIからJSON定義を投入するだけで即座にデプロイ・変更が可能です。運用は非常にシンプルになりますが、重いパース処理（複雑なGrokなど）が大量に走ると、Elasticsearch自体のリソース（検索やインデックス性能）を圧迫するリスクがあります。 3. 【結論】どちらを選ぶべきか？ ユースケース別の推奨 システム要件や現在の構成に合わせて、インフラエンジニアは以下の基準で選択することをお勧めします。 ✅ Ingest Pipeline を選ぶべきケース 「シンプルさ」と「スピード」を最優先する場合 データソースが  Elastic Agent  や  Beats  に統一されており、直接ElasticsearchにデータをPushできる。 ログの加工要件が、タイムスタンプの整形や不要フィールドの削除、シンプルなGrokパース程度である。 これ以上、管理対象のサーバーやコンポーネント（ミドルウェア）を増やしたくない。 ✅ Logstash を選ぶべきケース 「複雑なパイプライン」や「大規模・多様な環境」を管理する場合 データベース（SQL）やKafka、サードパーティのAPIなど、 多種多様な場所からデータをPullで収集 する必要がある。 受け取ったデータをElasticsearchだけでなく、 S3や別のオブジェクトストレージにも同時にバックアップ したい。 パース処理が非常に複雑で、Elasticsearchの検索・インデックス性能に影響を与えたくない（負荷を分離したい）。 データの突発的なスパイクに備え、堅牢なディスクバッファリング（永続的キュー）が必須である。 💡 比較サマリー 比較項目 Logstash Ingest Pipeline 配置・アーキテクチャ 独立した外部サーバー（JVM） Elasticsearchクラスタの内部（Ingestノード） 入力（データ収集） 自由度：高 （Pull型、Push型、各種DB、MQ対応） 自由度：低 （ElasticsearchへのPushのみ） 出力（データ送信） マルチ出力対応 （ES、S3、Kafka、ファイル等） Elasticsearch内部のみ キュー・バッファリング 内蔵（Persistent Queuesによるデータロスト防止） なし（送信元にバックプレッシャーをかける） 加工・拡充の複雑さ 非常に複雑なロジック、Rubyコード、外部DB参照 単一ドキュメント内の処理、簡単なクラスタ内ルックアップ インフラ管理負荷 高（追加のサーバー管理やチューニングが必要） 低（Elasticsearchの設定としてAPI管理可能） 推奨ユースケース 多種多様なソースからのデータ収集、マルチ出力、複雑なパース処理、負荷分離、高堅牢性が求められる大規模環境。 シンプルさとスピードを優先する場合。Beats/Agent利用時、標準的なログパース、管理コンポーネントを増やしたくない場合。 💡 ハイブリッド構成（併用）という選択肢も 「Logstashで多様なデータソースから収集・バッファリングを行い、Elasticsearchに転送した後の細かいパースはElasticのIntegration（標準のIngest Pipeline）に任せる」という  Logstash ➔ Ingest Pipeline  のハイブリッド構成も、大規模環境では一般的です。 まとめ 手軽さ、運用のしやすさ、標準的なログパース  ➔  Ingest Pipeline マルチ入出力、複雑なロジック、高堅牢性・バッファリング  ➔  Logstash 現代のElastic Stack構築における王道アプローチは、以下の2ステップです。 まずは運用の手軽な  Ingest Pipeline  で要件を満たせるか検討する。 入出力の制限やパースの複雑さ、インフラ分離の必要性が出てきた段階で  Logstash  の導入、あるいは併用へとステップアップする。 自社のインフラ規模やログの特性に合わせて、最適なデータパイプラインを選択しましょう！ The post Elasticのデータ前処理、どっちを選ぶ？ Logstash vs Ingest Pipeline 徹底比較 first appeared on Elastic Portal .

はじめに 本記事は、2026年3月10日に開催された Elastic{ON} Tokyo での発表「 『定型』を許さない製造業データへの挑戦 」の内容をもとにした連載の最終回です。 第1回：ビジュアル情報を活かす 第2回：分断されたデータを繋ぐ 第3回（本記事）：止めずに進化させる 第1回ではビジュアル情報を使った類似図面検索、第2回ではデータソース横断検索の設計について書きました。最終回の本記事では、製造業データの「非定型性」にどう向き合っているか、そして進化し続けるインデックスをどうやって無停止で運用しているかについて書きます。 「正解のデータモデル」が存在しない 製造業のデータにおける3つ目の壁は、データモデルの多様性です。 データ構造がバラバラ 図面の「表題欄」ひとつとっても、会社ごとに記載項目やフォーマットは驚くほど違います。しかもこの違いは会社単位に留まりません。部品の種類によっても、設計者の書き方によっても、データの持たせ方は変わります。 たとえば同じ「部品データ」でも、機械部品の「部品図」と電気制御の「回路図」と仕様を書いた「仕様書」ではデータ種そのものが違う。同じデータ種の中でも、図番や品名のような共通項目以外は「材質」だったり「熱処理」だったり「表面処理」だったりと、作るモノ次第で必要な情報が変わる。極端な話、ネジ一本と大型エンジン筐体では管理すべき項目が全く違います。 普通のシステムなら共通スキーマを事前に定義するところですが、製造業データではそれが通用しないのが厄介なところです。 検索ニーズもバラバラ データ構造がバラバラであるように、検索の切り口もバラバラであるということも重要です。 同じ部品を探したいという目的でも、立場が変われば検索の切り口は全く違います。設計は「形状」から入りたいし、調達は「発注実績」から入りたいし、品質管理は「不具合履歴」から入りたい。 もっと厄介なのは、一人のユーザーの中でもこのコンテキストが動的に切り替わるということです。最初は「似た形の図面」を漠然と探していた設計者が、良い事例を見つけた瞬間に「このサプライヤーで作った実績はあるか？」と調達の視点に切り替わる。実績を見たら今度は「この加工方法での不具合率は？」と品質の視点に潜っていく。 固定の検索項目では、この思考の連鎖には追従できません。どんな切り口から入ってきても、コンテキストがどう遷移しても、データ間の関係性を提示し続けられる柔軟さが必要です。 進化し続けるインデックス、止められない制約 ここまで書いてきた多様性は、データ構造や検索の切り口が日々変わり続けた結果として生まれたものです。新しい製品カテゴリが増えれば管理すべき属性が変わるし、探し方も変わる。そしてこの変化は今後も止まりません。 こうした変化に追従するには、データや検索の切り口に合わせてインデックス設定を切り替えていくことが重要です。すなわち、マッピングの更新、アナライザーの調整、フィールドの追加や型変更など、インデックス定義を継続的にアップデートする必要があります。 ただ、ここに大きな制約があります。 CADDi Drawer は今この瞬間の意思決定を支えるアプリケーションなので、インデックス構造の変更でユーザーの業務が止まるのは許容できません。一方、Elasticsearch の reindex 処理ではデータの一貫性を保つために書き込みを止めるのが一般的な手法です。 「常に最新のインデックスに進化させたい」と「24時間365日、更新も検索も止めてはいけない」。この2つの要求は正面からぶつかります。 ゼロダウンタイム reindex の仕組み 標準的な reindex の問題 Elasticsearch でインデックス定義を変更する通常の手順はこうです。 新しいマッピングでインデックスを作成する 旧インデックスから新インデックスへデータをコピーする（reindex） エイリアスを切り替えて新インデックスを参照させる 旧インデックスを削除する 問題はステップ2です。reindex 中に旧インデックスへ書き込まれたデータは新インデックスに反映されない。書き込みを止めれば一貫性は保てますが、ユーザーの更新がブロックされる。止めなければ、切り替え時にデータが欠損する。どちらも受け入れられません。 私たちのアプローチ そこで、ゼロダウンタイムでインデックスを切り替えられる仕組みを自前で実装しました。 書き込みと読み込みのパスを抽象化し、新旧のインデックスを並行稼働させながら、一貫性を保った状態でトラフィックを切り替えます。 具体的には、reindex を開始したら新旧両方のインデックスに書き込むことで、新インデックスにも最新データが反映されるようにしています。reindex が完了したら、読み取りパスを新インデックスに切り替える。この切り替えは瞬時に行われるので、ユーザーの検索は中断しません。書き込み順序の保証やデータ整合性のチェックも組み込んでいて、データが欠損しない仕組みになっています。 ユーザーからはメンテナンスの存在が見えず、常に最新のインデックス構造で検索できる状態を維持しています。 スキーマ変更を恐れずに回せる 個人的には、このゼロダウンタイムの仕組みで一番大きいのは、スキーマの変更を躊躇なくやれるようになったことだと思っています。 製造業のデータモデルに正解がない以上、スキーマは仮説です。現場のフィードバックを受けて継続的に直していくしかない。ユーザーから既存スキーマでは表現できない属性の要望が出てきたらフィールドを追加するし、検索精度を上げたければアナライザーの設定を見直してインデックスを再構築するし、新しいデータソースが接続されたら非正規化構造ごと変える場合もあります。 こうした変更のたびにサービスを止めていたら、改善のサイクルは回りません。ゼロダウンタイム reindex があることで、本番環境のインデックスを継続的に進化させ続けられています。 連載のまとめ 3回にわたって、CADDi Drawer の検索基盤について書いてきました。 第1回では、図面をベクトル化して kNN 検索で類似図面検索を作った話。第2回では、10兆規模の組み合わせを用途別インデックスと動的制御で捌いている話。そして今回は、スキーマが変わり続ける中でゼロダウンタイム reindex でインデックスを進化させ続けている話。 振り返ると、3つの壁はそれぞれ独立した問題のように見えて、根っこでは繋がっています。ビジュアル検索がなければ探索は始まらないし、データソース横断がなければ探索は完結しないし、スキーマを柔軟に変え続けられなければ探索は陳腐化する。どれか一つが欠けても「探索」にはならない。 3つの壁を個別の技術課題として解くのではなく、「探索」という一つの設計思想で貫けたことが、振り返ってみると一番大きかったと思っています。 製造業のデータはこれからも変わり続けます。私たちの検索基盤も、それに合わせて進化し続けていきます。 本連載の内容は Elastic{ON} Tokyo での発表をもとにしています。発表スライドは こちら からご覧いただけます。