ES|QL - Elasticsearch Labs

Elasticsearch ES|QLがインデックス化されていないデータへの全文検索を可能に

Kevin Corcoran,Ioana Tagirta — Wed, 05 Aug 2026 00:00:00 GMT

ES|QL MATCHは、インデックスを作成していないデータに対して全文検索を実行するようになりました。計算された列、マッピングされていないフィールド、その場で組み立てられた文字列、さらにはS3に保存されているフェデレーションデータ。新しいTO_TEXT関数は、任意の文字列を解析可能なテキストとして扱うようにES|QLに指示するため、MATCHはクエリの存続期間中にのみ存在する値をトークン化し、大文字・小文字の正規化や用語の一致を行うことができます。これは、多くのクエリエンジンがインデックスなし文字列に対して提供しているLIKEやRLIKEパターンマッチングを超えた真の解析です。Elastic Cloud Serverlessで現在利用可能で、Elasticsearch 9.5ではテクニカルプレビューとして提供されています。

MATCHとTO_TEXTが任意のES|QL式で全文検索を可能にする方法

まずは、Elasticsearch 9.4では不可能だったクエリから始めます。このクエリは EVALコマンドを使用します。

この例では、要約にはマッピングやアナライザーの設定がありません。また、逆インデックスとも関連付けられていません。このクエリの有効期間中のみ存在しますが、それでも検索可能です。これを機能させるには、2つの追加要素が必要です。

まず、MATCHは、マップされたフィールドだけでなく、すべての式を最初の引数として受け入れるようになりました。これにはEVALで生成されたカラムや、インラインで使われる関数結果も含まれます。また、元のドキュメントから直接読み込む未マッピングフィールドも含まれます。さらに、この新しいユースケースでは、MATCHで通常受け入れられるすべてのデータタイプがサポートされます。

2つ目の要素は新しいTO_TEXT関数であり、テキスト型の出力を生成する最初のES|QL変換関数です。これまで、テキスト列はインデックス付きマッピングフィールドからのみ取得でき、ES|QL式によって生成される文字列はすべてテキストではなくキーワード値でした。MATCHは2つを異なる方法で扱うため、区別が重要です。テキスト値は分析され、キーワード値は正確に比較されます。これは、インデックス付きキーワードフィールドのMATCHクエリが用語クエリに書き換えられる方法を反映しています。TO_TEXT(x) は、ES|QLに対して、「この文字列を全文として扱う」ように指示する方法です。

これはElasticsearch 9.5のテクニカルプレビューとして提供されるため、いくつかの制限があります。

現在はフィルタリング機能のみを提供しています。式に対するMATCHは、現時点では関連性スコアには影響しません。インデックス付きフィールドに対する一致のみがスコアに影響します。
式を照合する際、あいまい検索などのクエリオプションはまだサポートされていません。
実行時テキストは標準アナライザーで解析されます。これはまだ設定変更できません。

これらの制約に対処するための取り組みが進められています。

ES|QLでLIKEやRLIKEの代わりに全文検索を使うのはなぜですか？

ES|QLには、インデックスなしで文字列を検索するLIKE（ワイルドカードパターン）とRLIKE（正規表現）という2つの方法がすでにありました。どちらもどんな文字列式でも動作するので、MATCHが何を追加するのか疑問に思うのは当然です。答えは分析です。これは、語幹抽出や同義語などの技術を用いる、より高度な検索方法です。また、ストップワード処理も行います。

LIKEは文字列を構成する単語を理解せずに行う単純な部分文字列マッチングです。例えば、キツネ（fox）に関するログメッセージを探しているとします。

これは大文字表記の「Fox spotted near the henhouse（鶏小屋の近くでキツネが目撃された）」とは一致しませんが、キツネとは全く関係のない「Outfoxed by the competition（競争相手に出し抜かれた）」とは一致します。大文字小文字の区別に関しては偽陰性、他の単語の中に埋もれた部分文字列に関しては偽陽性と、どちらの方向にも問題があります。

正則表現は格の問題を補うことができますが、単語境界の問題はすぐに複雑化してしまいます。例えばこんな感じです。

これでさえ、正解ではありません。文末に「!」や「?」が続く場合、「fox」を見落としてしまいます。また、タブ、引用符、括弧については何も言及していません。修正を加えるたびにパターンが長くなり、次にクエリを読む人は、それが実際に何をしているのかをリバースエンジニアリングしなければならなくなります。

MATCHはクエリと値の両方をアナライザーに通し、テキストを小文字の単語にトークン化して、単語同士を照合するため、問題が解消されます。

このクエリは、「The quick brown fox」や「FOX spotted near the henhouse」のような値には一致しますが、「Outfoxed by the competition」や「FOXTROT protocol enabled」には一致しません。単語の周囲の句読点に関係なく一致します。もちろん、これはすべて、MATCH(TO_TEXT(message), "brown fox") のような複数語クエリにも、期待どおりに機能します。

これまでインデックス化やマッピングが行われていなかったデータに対しても自然言語をサポートするため、 36個の専用言語アナライザーを利用できるようにするための作業が進められています。

インデックス化されていないデータやマッピングされていないデータの全文検索のユースケース

上記の例ではマッピングされたフィールドから計算された値を検索しました。ES|QL MATCHを式に適用する際のより興味深いユースケースは、これまで全く検索できなかったデータに関するものです。いくつか見ていきましょう。

マッピングを追加せずにES|QLでマップされていないフィールドを検索する方法

詳細なスタックトレースや生のリクエストペイロードなど、意図的にマッピングからフィールドを除外する場合もあります。デバッグ用のデータブロックを省略することもあります。これらのうちの1つをインデキシングすると、ドキュメントごとにディスクとヒープ容量が消費されます。四半期に1回しかクエリしないようなフィールドのためにインデックスを作成する価値はありません。

この決定は常に最終的なものでした。なぜならマッピングされていないフィールドはクエリから完全に見えなかったからです。Elasticsearch 9.5では、SET unmapped_fields="load"を使用して、ES|QLにマッピングされていないフィールドをソースドキュメントからキーワードとして直接ロードさせることができます。次に、それをTO_TEXTで囲むと、全文検索を実行できるようになります。

ここでは、stack_traceはマッピングされていません。すべての値は元の文書から取得され、その場で分析されます。行ごとにマッチングされています。これが実際の作業であり、逆インデックス検索ほど高速になることは決してありません。しかし今では、インデックスを作成しなかったそのフィールドも検索不能ではなくなりました。日常的なケースではマッピングを小さく保ちつつ、重要な場面では四半期に一度の質問にも対応できます。

キーワードフィールドでの全文検索（再インデックスなし）

キーワードフィールドは多くのことを可能にします。正確なマッチング、高速なアグリゲーション、ソート機能を提供するため、多くのフィールドがそのようにマッピングされます。しかし、マッピングはデータが到着した時点で決定されるため、当初の意図とは異なる方法でデータを利用したくなる状況に陥ることがあります。例えば、product_nameがダッシュボードで集約されるためキーワードとしてマッピングされ、1年分の製品データを受け取った後に、誰かがproduct_nameの値内で検索できるようにしたいと考えることもあるでしょう。

以前の解決策は、マッピングをテキストに変更する（または複数フィールドを追加する）ことと、すべてを再インデックスすることでした。これは時間と費用がかかる場合があり、多くの場合、ユーザーはわざわざその手間をかけたくないことが多いです。新しい答えは、1つの関数呼び出しです。

TO_TEXTはキーワード値をその場でテキストに変換するため、MATCHはそれらを正確に比較するのではなく、分析します。これにより、マッピングやソースドキュメントの再インデックス作成なしでキーワードフィールドをクエリできます。検索が日常的なクエリになった場合でも、フィールドをテキストとしてインデックスすることが長期的には正しい選択ですが、TO_TEXTを使えば、追加の手間なく今日すぐに結果を得られます。

異なるマッピングを持つインデックス間で同じフィールドを探索

ES|QLは複数のインデックスにまたがることができ、同じフィールドであっても、すべてのインデックスで常に同じ形式である必要はありません。同じフィールドが異なるインデックスで異なる型を持つ場合、ES|QLはそれを共用型として扱い、変換関数によって競合を解決します。今年のインデックステンプレートではメッセージフィールドのタイプがテキストになっているものの、昨年のテンプレートではキーワードだったという例を考えてみましょう。

クエリ実行時には、テキストインデックス由来の値であろうとキーワードインデックス由来の値であろうと、すべての値が分析されます。古いインデックスのキーワード値は、他のすべてと同様にトークン化され、小文字に変換されるため、「connection reset」は、どのインデックスに存在していても「Connection RESET by peer」を検索します。

もう一つ興味深いケースは、フィールドが一方のインデックスにのみマップされているものの、もう一方のインデックスにも存在（かつマップされていない）場合です。

ここで指摘しておくべき微妙なニュアンスがあります。error_detailsがlogs-2026にマッピングされていて、logs-2025にはマッピングされていない場合、ElasticsearchはこのクエリをLuceneにプッシュできません。フィールドがマッピングされていないインデックスは、マッチを返さないためです。代わりに、プランナーはフィールドが潜在的に未マッピングであることに気づき、行の出所に関わらず、行ごとにMATCH全体を評価します。どのインデックスにフィールドがマッピングされているかを知る必要はありません。クエリがその質問に答えます。

ES|QLが逆インデックスなしでクエリ時にテキストを分析する方法

ES|QLが式に対してMATCHを計画する場合、クエリ文字列を事前に一度だけ解析して、一連の用語に分解します。各行がどのように評価されるかは、式の型によって異なります。

式の種類

処理

マッチング動作

テキスト（TO_TEXT経由）

アナライザーは値を小文字の用語にトークン化

トークン同士の比較。いずれかのトークンがクエリ用語のいずれかと一致する場合、その行は一致（ORセマンティクス）。

キーワード、IP、日付、数字

分析なし。クエリ定数は一度ネイティブ型に変換。

行ごとの正確な比較

どちらの経路もLuceneを完全に迂回し、値を行ごとに評価します。非テキストパスは、これらのフィールドタイプに対してLuceneにプッシュダウンされたマッチクエリの動作と完全に一致するため、クエリがインデックスにヒットするかどうかに関わらず、セマンティクスは一貫しています。

逆インデックス検索は取り込み時に作業を行い、クエリ時に一致しない文書には一切触れません。実行時マッチはクエリ時に、到達するすべての行に対してその分析を行います。一方は既に処理が完了しているため高速であり、もう一方はデータがインデックス化されている必要がないため柔軟性があります。

ES|QL全文検索の今後の展望は

この記事の内容はすべて、ES|QLの検索機能を、事前にインデックスを作成したデータだけでなく、あらゆるデータに対して動作させるための、より大規模な取り組みの第一弾です。先に挙げた制約事項については積極的に改善に取り組んでおり、ロードマップはさらに次の段階へと進んでいます。

スコアリング。実行時の一致結果も_scoreに反映されるため、データがインデックス化されていない場合でも、関連性に基づいてソートできます。
式に対するMATCH_PHRASE。Elastic Cloud Serverlessですでに利用可能で、9.6でElastic Stackに登場します。
設定可能なアナライザー。式に対するMATCHおよびMATCH_PHRASEのアナライザーサポートにより、クエリ実行時に言語アナライザー、ステミング、同義語を利用できるようになります。
マッチオプション。実行時マッチングのためのあいまい度や演算子などのオプション。
ベクトル検索。行ごとに埋め込みを生成し、実行時にdense_vector式に対してk近傍法（kNN）を実行することで、インデックス化されていないデータにもセマンティック検索を適用できるようにします。

ES|QLの全文検索を今すぐ試す

実行時検索を今すぐお試しください。新しいES|QL機能が最初に実装されるElastic Cloud Serverlessでは現在利用可能で、Elasticsearch 9.5ではテクニカルプレビューとして提供されます。まず検索関数の参照から始め、ES|QLの制限ページで現在の制限を確認してください。これはテクニカルプレビュー版であり、皆様からのフィードバックをお待ちしています。これまでインデックス登録されていなかったものを検索して、良い意味でも悪い意味でも驚いたことがあれば、ぜひお聞かせください。

プロンプトから1分以内にダッシュボードを作成、コストを5分の1に削減：KibanaのAIダッシュボードとカスタムVega-Liteチャート

Marta Bondyra,Teresa Alvarez Soler — Tue, 04 Aug 2026 00:00:00 GMT

KibanaのAIチャットは現在、自然言語のプロンプトから1分以内に、Elasticsearch Query Language（ES|QL）を基盤とする完全なダッシュボードを作成します。Elastic 9.5では、この機能が9.4でのテクニカルプレビューを経て一般提供（GA）となり、失敗したクエリを再試行するエラー回復機能、階層型モデルルーティングによってES|QL生成コストを5分の1に抑える機能、インタラクティブなフィルターコントロールが利用可能になります。今回のリリースでは、散布図、箱ひげ図、条件付き書式、カスタムツールチップなど、通常はJSONで手動コーディングする必要があるVega-Liteチャートを自然言語で作成する機能も追加されました。

KibanaのAIダッシュボード作成の新機能

機能

テクニカルプレビュー（9.4）

一般提供（GA）（9.5）

エラー処理

失敗したES|QLクエリの再試行なし

クエリを検査・調整しながら最大3回まで自動的に再試行

ES|QL生成コスト

すべてのクエリをプライマリモデルにルーティング

階層型モデルルーティングにより、コストを最大5分の1に抑制

時間範囲

固定のデフォルト期間

データの時間的分布に基づく自動選択

フィルターコントロール

サポートなし

最も関連性の高いフィールドに自動的に追加

Vega-Liteチャート

サポートなし

散布図、箱ひげ図、条件付き書式、カスタムツールチップなどを自然言語で作成

チャート編集

サポートなし

既存のVega-Liteパネルを自然言語で編集

AIダッシュボード生成の自動エラー回復

テクニカルプレビューでは、エージェントが失敗したES|QLクエリを再試行しませんでした。9.5では、クエリエラーを検出し、各エラーを検査してクエリを調整しながら、最大3回まで再試行します。実際には、これにより空のパネルが発生する問題の大半が解消され、最初の試行で正しくレンダリングされるダッシュボードが生成されます。

Elastic 9.5では、なぜAIダッシュボードの作成コストが下がるのか？

ダッシュボード生成のすべてのステップで、同じレベルの推論が必要なわけではありません。9.5では、ES|QL生成はデフォルトで軽量モデルにルーティングされ、必要な場合にのみプライマリモデルにフォールバックします。コネクタでAnthropicのClaude Opus 4.8を使用している場合、すべてのパネルにおけるES|QL生成コストを5分の1に抑えられます。

データに基づく時間範囲の自動選択

ダッシュボードは、適切な期間のデータを表示してこそ役立ちます。エージェントは、ユーザーが特定の時間範囲を指定しない限り、クエリ対象のデータに適した時間範囲を選択するための改良されたロジックを適用するようになりました。固定の期間をデフォルトで使用するのではなく、データの時間分布を考慮し、進行中のインシデントであれば直近1時間、トレンド分析であれば過去90日間というように、適切な範囲へ調整します。

AI生成ダッシュボードへのフィルターコントロールの自動追加

ダッシュボード作成でコントロールがサポートされるようになりました。コントロールとは、基盤となるクエリを編集することなく、フィールド値に基づいてダッシュボードの表示内容を絞り込めるインタラクティブなフィルターです。ダッシュボードを生成する際、エージェントはフィルタリングに最も関連性の高いフィールドのコントロールを上部に自動的に追加します。

自然言語によるVega-Liteチャート：デフォルトを超えるチャートタイプと書式設定

VegaとVega-Liteは、Kibanaで幅広いチャートタイプとカスタマイズをサポートしています。9.5では、自分でコードを書く代わりに、自然言語でこれらのチャートを作成できます。

散布図、箱ひげ図などのVega-Liteチャートタイプ

Vega-Liteは、散布図、箱ひげ図、ファセットを使用したスモールマルチプル、バブルチャート、複合チャート（ヒストグラムとヒートマップの組み合わせなど）をはじめ、さまざまなチャートタイプをサポートしています。「応答時間とリクエストサイズの散布図をサービス名ごとに色分けして表示してください」といったプロンプトを入力すると、適切なデータマッピングが設定されたVega-Liteパネルが生成されます。生成されたチャートにはKibanaのデフォルトのカラーパレットが使用されるため、ダッシュボードの他の部分と自然に調和します。

標準チャートの条件付き書式、カスタムツールチップ、ラベル

棒グラフ、折れ線グラフ、面グラフなど、ダッシュボードで標準的にサポートされているチャートタイプでも、デフォルト機能以上の制御が必要になる場合があります。チャットからVega-Liteを使用することで、そのギャップを埋められます。たとえば、次のようなことができます。

条件付きの色設定：しきい値を超えたデータポイントを異なる色で表示できます。たとえば、ある指標がサービスレベル目標（SLO）を超えた場合に、折れ線グラフのデータポイントや棒グラフの棒を赤色にできます。エージェントに「折れ線グラフで500msを超えるポイントをすべて赤色にしてください」と依頼できます。
カスタムマークとラベル：データポイントに絵文字、記号、インラインテキストラベルを追加し、ステータスをひと目で確認できるようにします。
カスタムツールチップ：チャートの軸には含まれない追加の指標、コンテキスト、計算値をホバー時に表示できます。たとえば、「レコードの総数と各棒の割合を表示するツールチップを追加してください」と依頼できます。

この機能は、既存のVegaチャートの編集にも使用できます。カラースケールの変更、軸の調整、マークタイプの切り替えなど、Vega-Liteパネルを微調整する必要がある場合は、JSONコードを直接編集する代わりに、変更内容をチャットで伝えてください。

Kibanaで自然言語によるVega-Lite生成を実現した仕組み

文章からVega-Liteチャートを生成する処理は、単にモデルに一度JSONの生成を依頼するだけではありません。自然言語で表された意図を、検証済みのデータに基づくチャートへ変換する小規模なエージェント型パイプラインを構築しました。

リクエストを受け取ると、エージェントはまずVega-Liteが適しているかどうかを判断します。Vega-Liteのリクエストでは、Elasticsearchに対する実際のES|QLクエリに可視化の根拠を置き、その後、モデルを使用してVega-Liteコードを生成します。レンダリング前に、結果は正規化レイヤーを通過し、そこでスキーマが修正され、正準クエリが関連付けられます。また、安全にレンダリングするための変換も適用します。

このワークフローの信頼性を高めるため、いくつかの設計上の工夫を取り入れています。

型指定されたツール呼び出し：チャート作成は、自由形式のVega-Liteを会話に貼り付けるのではなく、構造化されたツール呼び出しとして実行されます。
制約付き生成：モデルは定義済みのスキーマ内でVega-Liteコードを生成するため、出力の予測可能性が高まり、検証も容易になります。
厳選された例：ファセット、レイヤーマーク、ヒートマップなどの構造パターンが、基盤となるデータをコピーすることなくガイダンスを提供します。
実行・検証ループ：チャート作成前にクエリが実行され、検証に失敗すると、ES|QL生成が修正されたうえで再試行されます。

KibanaでAIダッシュボード作成とVega-Liteチャートを試す

自然言語によるダッシュボード作成とVega-Liteチャートを試すには、Elastic 9.5にアップグレードするか、無料トライアルを開始して、Kibanaでチャットを開きます。次に、データからダッシュボードを作成するようエージェントに依頼します。Vega-Liteでは、散布図やバブルチャートなど、これまで作りたいと思いながら作成したことのないチャートを依頼してみてください。結果が思いどおりでなければ、エージェントに変更したい内容を伝えてください。エージェントが対話しながら調整します。

この機能を使用するには、Enterpriseライセンスが必要です。はじめに。

本記事に記述されているあらゆる機能ないし性能のリリースおよびタイミングは、Elasticの単独裁量に委ねられます。現時点で提供されていないあらゆる機能ないし性能は、すみやかに提供されない可能性、または一切の提供が行われない可能性があります。

LINQ to Elasticsearch ES|QL：C#を記述してElasticsearchをクエリ

Florian Bernd,Martijn Laarman — Wed, 01 Apr 2026 00:00:00 GMT

v9.3.4およびv8.19.18以降のElasticsearch .NETクライアントには、実行時にC# LINQ式をElasticsearchクエリ言語（ES|QL）クエリに変換する Language Integrated Query（LINQ）プロバイダーが含まれています。ES|QL文字列を手作業で記述する代わりに、 Where、 Select、 OrderBy、 GroupByなどの標準演算子を使用してクエリを構成します。このプロバイダーは、結果セットのサイズに関係なくメモリ使用量を一定に保つ行ごとのストリーミングを含め、変換、パラメータ化、結果の逆シリアル化を処理します。

最初のクエリ

まず、Elasticsearchインデックスにマップする普通のCLRオブジェクト（POCO）を定義します。プロパティ名は、標準的なSystem.Text.Json属性（[JsonPropertyName]など）または設定されたJsonNamingPolicyを通じてES|QL列名に解決されます。クライアントの他の部分に適用されるソースシリアル化ルールは、ここでも同様に適用されます。

using System.Text.Json.Serialization; public class Product { [JsonPropertyName("product_id")] public string Id { get; set; } public string Name { get; set; } public string Brand { get; set; } [JsonPropertyName("price_usd")] public double Price { get; set; } [JsonPropertyName("in_stock")] public bool InStock { get; set; } }

型を指定すると、クエリは次のようになります。

プロバイダーはこれを次のES|QLに変換します。

いくつか注意すべき点があります。

プロパティ名の解決： p.Priceは[JsonPropertyName] 属性のためprice_usdになり、p.BrandはデフォルトのcamelCase命名規則に従って brandになります。
パラメーターのキャプチャ：C#変数 minPriceとbrandは、名前付きパラメーター（?minPrice、?brand）としてキャプチャされます。これらはJSONペイロード内のクエリ文字列とは別に送信されるため、インジェクション攻撃を防ぎ、サーバー側のクエリプランのキャッシュを可能にします。
ストリーミング：QueryAsyncはIAsyncEnumerableを返します。Elasticsearchからデータが到着すると、行は1つずつマテリアライズされます。

また、実行せずに生成されたクエリとそのパラメーターを検査することもできます。

var query = client.Esql.CreateQuery() .Where(p => p.InStock && p.Price >= minPrice && p.Brand == brand) .OrderByDescending(p => p.Price) .Take(10); Console.WriteLine(query.ToEsqlString()); // FROM products | WHERE (in_stock == true AND price_usd >= 100) | SORT price_usd DESC | LIMIT 10 Console.WriteLine(query.ToEsqlString(inlineParameters: false)); // FROM products | WHERE (in_stock == true AND price_usd >= ?minPrice AND brand == ?brand) | SORT price_usd DESC | LIMIT 10 var parameters = query.GetParameters(); // { "minPrice": 100.0, "brand": "TechCorp" }

これはどのように機能するのでしょうか？LINQ の簡単なおさらい

LINQプロバイダーを可能にするメカニズムは、IEnumerableとIQueryableの区別にあります。

.Where(p => p.Price > 100) を IEnumerable 上で呼び出すと、ラムダは Func にコンパイルされます。これは、ランタイムがインプロセスで実行する通常のデリゲートです。これはLINQ-to-Objectsです。

同じメソッドを IQueryable で呼び出すと、C#コンパイラはラムダを Expression> でラップします。これは実行可能な形式ではなく、コードの構造を表すデータ構造です。式ツリーは実行時に検査、分析、および別の言語への変換を行うことができます。

// IEnumerable: the lambda is a compiled delegate IEnumerable local = products.Where(p => p.Price > 100); // IQueryable: the lambda is an expression tree, a data structure IQueryable remote = queryable.Where(p => p.Price > 100);

IQueryProviderインターフェースは拡張ポイントです。どのプロバイダーでも、これらの式ツリーをターゲット言語に変換するために CreateQuery と Execute を実装できます。Entity FrameworkはSQLを発行するためにこれを使用します。LINQからES|QLへのプロバイダーはこれをES|QLの生成に使用します。

上記のクエリの式ツリーは次のようになります。

例のクエリに対する式ツリー。

ツリーは内側から外側にネストされています。Takeが OrderByDescendingをラップし、これがWhereをラップし、これがFrom, をルート定数EsqlQueryable をラップします。Where述語自体がBinaryExpressionノードのサブツリーであり、&&、>=、および==演算子に対してMemberExpressionリーフがプロパティアクセス用、minPriceおよびbrand変数用のクロージャキャプチャ用に存在します。これは、プロバイダーが最終的なES|QLを生成するために使用するデータ構造です。

内部構造：変換パイプライン

LINQ式からクエリ結果までの経路は、6段階のパイプラインをたどります。

データ変換パイプラインの概要。

1. 式ツリーのキャプチャ

.Where()、.OrderBy()、.Take()などの演算子をIQueryable に連鎖させると、標準のLINQインフラストラクチャーが式ツリーを構築します。EsqlQueryable はIQueryable を実装し、EsqlQueryProvider に委譲します。

2. 変換

クエリが実行されると（列挙、 ToList()の呼び出し、またはawait foreach)使用によって）、 EsqlExpressionVisitorは式ツリーを内側から外側へと走査します。各LINQメソッド呼び出しを専門のビジターに送信します。

ビジター

翻訳します

対象

WhereClauseVisitor

.Where(predicate)

WHERE 条件

SelectProjectionVisitor

.Select(selector)

EVAL + KEEP + RENAME

訪問者別にグループ化

.GroupBy().Select()

STATS ... BY

OrderByVisitor

.OrderBy() / .ThenBy()

SORTフィールド [ASC\|DESC]

EsqlFunctionTranslator

EsqlFunctions.*、Math.*、文字列メソッド

80+ ES|QL関数

翻訳中、式で参照されるC#変数は名前付きパラメーターとしてキャプチャされます。

3. クエリモデル

ビジターは直接文字列を生成しません。代わりに、QueryCommandオブジェクト、すなわち不変の中間表現を生成します。FromCommand、WhereCommand、SortCommand、およびLimitCommandの各々が、1つのES|QL処理コマンドを表しています。これらはEsqlQueryモデルに集められます。

クエリモデルとコマンドパターン。

この中間モデルは、式ツリーと出力形式の両方から切り離されています。フォーマット前に検査、傍受（IEsqlQueryInterceptor経由）、または修正が可能です。

4. フォーマット

EsqlFormatter 各QueryCommandを順番に訪問し、最終的なES|QL文字列を生成します。各コマンドは1行になり、ES|QLが処理コマンドを連鎖させるために使用するパイプ (|) 演算子で区切られます。特殊文字を含む識別子は自動的にバッククォートでエスケープされます。

5. 実行

フォーマットされたES|QL文字列とキャプチャされたパラメーターは、JSONペイロードとしてElasticsearchの/_queryエンドポイントに送信されます。IEsqlQueryExecutorインターフェースはトランスポートレイヤーを抽象化し、ここで階層型パッケージアーキテクチャが登場します。

6. マテリアライズ

EsqlResponseReader JSON応答をストリーム化し、結果セット全体をバッファリングせずに処理します。ColumnLayoutツリーは、1クエリにつき1回事前に計算され、フラットなES|QL列名（address.street、address.cityなど）をネストされたPOCOプロパティにマップします。各行はTインスタンスに組み立てられ、 IEnumerable または IAsyncEnumerableによって1行ずつ生成されます。

レイヤーアーキテクチャ

LINQ to ES|QL機能は、以下の3つのパッケージに分かれています。

パッケージアーキテクチャー。Elastic.Esql は純粋な変換エンジンです。HTTPへの依存関係は一切なく、式ビジター、クエリモデル、フォーマッター、レスポンスリーダーが含まれています。スタンドアロンで使用すると、Elasticsearch接続がなくてもES|QLクエリを構築および検査できます。これは、テスト、クエリロギング、または独自の実行レイヤーの構築に役立ちます。

// Translation-only: no Elasticsearch connection needed var provider = new EsqlQueryProvider(); var query = new EsqlQueryable(provider) .From("products") .Where(p => p.InStock) .OrderByDescending(p => p.Price); Console.WriteLine(query.ToEsqlString()); // FROM products | WHERE in_stock == true | SORT price_usd DESC

Elastic.Clients.Esql は軽量なスタンドアロンのES|QLクライアントです。Elastic.Transportを経由してElastic.Esql上にHTTP実行を追加します。もしアプリケーションが他のElasticsearch APIではなく、ES|QLのみを必要とする場合、これが最小限の依存関係オプションです。

Elastic.Clients.Elasticsearch は完全なElasticsearch .NETクライアントです。また、Elastic.Esql を基盤とし、client.Esql名前空間を通じてLINQプロバイダーを公開します。これはほとんどのアプリケーションで推奨されるエントリーポイントです。

どちらの実行層パッケージも、変換と転送をつなぐ戦略インターフェースであるIEsqlQueryExecutorの独自の実装を提供します。

これら3つのパッケージはすべて、ソース生成のJsonSerializerContextと併用する場合、ネイティブAOTと互換性があります。完全なクライアントについては、Native AOTのドキュメントをご覧ください。

基本を超えて

上記の例では、フィルタリング、ソート、ページネーションについて説明しています。このプロバイダーはより幅広い操作をサポートしています。

アグリゲーション

GroupBySelectの集約関数と組み合わせるとES|QL STATS ... BYに変換されます。

var stats = client.Esql.Query(q => q .GroupBy(p => p.Brand) .Select(g => new { Brand = g.Key, Count = g.Count(), AvgPrice = g.Average(p => p.Price), MaxPrice = g.Max(p => p.Price) })); // -> FROM products | STATS COUNT(*), AVG(price_usd), MAX(price_usd) BY brand

予測

Select匿名型を持つと、 EVAL、 KEEP、 RENAME コマンドが生成されます。

var query = client.Esql.CreateQuery() .Select(p => new { ProductName = p.Name, p.Price, p.InStock }); // -> FROM products | KEEP name, price_usd, in_stock | RENAME name AS ProductName

豊富な関数ライブラリ

80以上のES|QL関数が EsqlFunctionsクラスを通じて利用可能で、日付/時間、文字列、数学、IP、パターンマッチング、スコアリングをカバーしています。標準的なMath.*およびstring.*メソッドも変換されています。

.Where(p => p.Name.Contains("Pro")) // -> WHERE name LIKE "*Pro*" .Where(p => EsqlFunctions.CidrMatch( // -> WHERE CIDR_MATCH(ip, "10.0.0.0/8") p.IpAddress, "10.0.0.0/8"))

ルックアップ結合

クロスインデックス検索はES|QL LOOKUP JOINに変換されます。

var enriched = client.Esql.Query(q => q .LookupJoin( "category-lookup-index", product => product.Id, category => category.CategoryId, (product, category) => new { product.Name, category!.CategoryLabel }));

未加工のES|QLエスケープハッチ

LINQプロバイダーでまだサポートされていないES|QL機能については、生のフラグメントを追加できます。

var results = client.Esql.Query(q => q .Where(p => p.InStock) .RawEsql("| EVAL discounted = price_usd * 0.9"));

サーバー側の非同期クエリ

実行時間の長いクエリについては、サーバー上でバックグラウンド処理を行うように設定します。

await using var asyncQuery = await client.Esql.SubmitAsyncQueryAsync( q => q.Where(p => p.InStock), asyncQueryOptions: new EsqlAsyncQueryOptions { WaitForCompletionTimeout = TimeSpan.FromSeconds(5), KeepAlive = TimeSpan.FromMinutes(10) }); await asyncQuery.WaitForCompletionAsync(); await foreach (var product in asyncQuery.AsAsyncEnumerable()) Console.WriteLine(product.Name);

サーバー側の非同期クエリは、通常のタイムアウトしきい値を超える可能性のある長時間実行される分析クエリや大規模データセットの処理、あるいはロードバランサー、APIゲートウェイ、プロキシなど、厳格なHTTPタイムアウトを強制するタイムアウトに敏感な環境で特に役立ちます。非同期クエリは、結果の取得から提出を切り離すことで接続切断を回避します。

はじめに

LINQ to ES|QLは次のバージョンから利用可能です。

Elastic.Clients.Elasticsearch v9.3.4 (9.x ブランチ)
Elastic.Clients.Elasticsearch v8.19.18（8.xブランチ）

NuGetからのインストール：

dotnet add package Elastic.Clients.Elasticsearch

エントリーポイントはclient.Esqlにあります。

メソッド

戻り値

ユースケース

Query(...)

IEnumerable

同期実行

QueryAsync(...)

IAsyncEnumerable

非同期ストリーミング

CreateQuery()

IEsqlQueryable

高度な構成と検査

SubmitAsyncQueryAsync(...)

EsqlAsyncQuery

長時間実行されるサーバー側クエリ

クエリオプション、複数フィールドへのアクセス、ネストされたオブジェクト、複数値フィールドの処理など、機能の詳細についてはLINQ to ES|QLのドキュメントを参照してください。

まとめ

LINQ to ES|QLは、C# LINQの完全な表現力をElasticsearchのES|QLクエリ言語にもたらし、クエリ文字列を手作業で作成することなく、厳密に型付けされた構成可能なクエリを書くことができます。自動パラメーターキャプチャ、ストリーミングマテリアライゼーション、スタンドアロン変換から完全なElasticsearchクライアントまで拡張できる階層型パッケージアーキテクチャーにより、あらゆる規模の.NETアプリケーションに自然に適合します。最新のクライアントをインストールし、LINQ式をインデックスに向け、残りはプロバイダーに任せましょう。

スイススタイルのハッシュテーブルを使用したより高速なES|QL統計

Chris Hegarty,Matthew Alp,Nik Everett — Mon, 19 Jan 2026 00:00:00 GMT

最近、Elasticsearchのハッシュテーブル実装の重要な部分をスイススタイルの設計に置き換えたところ、均一でカーディナリティの高いワークロードでビルドと反復処理の時間が最大2～3倍高速化されることがわかりました。結果として、Elasticsearch Query Language (ES|QL) の統計と分析操作において、低いレイテンシ、より良いスループット、そしてより予測可能なパフォーマンスが得られます。

これが重要である理由

ほとんどの典型的な分析ワークフローは最終的にデータのグループ化に集約されます。ホストあたりの平均バイト数の計算、ユーザーごとのイベントのカウント、または次元全体でのメトリクスの集計など、コアとなる操作は同じです。キーをグループにマップし、実行中の集計を更新します。

小規模であれば、ほぼすべての適切なハッシュテーブルで問題なく動作します。大規模になると（数億のドキュメントと数百万の個別のグループなど）、詳細が重要になってきます。負荷係数、プローブ戦略、メモリレイアウト、キャッシュの動作によって、線形パフォーマンスとキャッシュミスの連続との間に違いが生じる可能性があります。

Elasticsearchは長年にわたってこれらのワークロードをサポートしてきましたが、コアアルゴリズムを最新化する機会を常に探しています。そのため、スイステーブルからヒントを得た新しいアプローチを評価し、それをES|QLが統計を計算する方法に適用しました。

スイステーブルとは？

スイステーブルは、GoogleのSwissTableによって普及し、後にAbseilやその他のライブラリに採用された最新のハッシュテーブルファミリーです。

従来のハッシュテーブルでは、ポインターの追跡やキーのロードに多くの時間を費やし、結局一致しないことが判明します。スイステーブルの特徴は、キーと値とは別に保存される制御バイトと呼ばれる小さなキャッシュ常駐配列構造を使用してほとんどのプローブを拒否し、メモリトラフィックを大幅に削減できることです。

各制御バイトは単一のスロットを表し、この場合、スロットが空かどうかと、ハッシュから導出された短いフィンガープリントの2つの項目をエンコードします。これらの制御バイトはメモリ上に連続的に配置され、通常16個のグループで構成されており、単一命令多重データ（SIMD）処理に理想的です。

スイステーブルは、一度に1つのスロットをプローブする代わりに、ベクトル命令を使用して制御バイトブロック全体をスキャンします。1回の操作で、CPUは入力キーのフィンガープリントを16個のスロットと比較し、空のエントリーを除外します。この高速パスを通過する少数の候補のみが、実際のキーのロードとの比較を必要とします。

この設計では、少量の追加メタデータと引き換えに、はるかに優れたキャッシュローカリティと大幅に少ないランダムロードを実現しています。テーブルが拡大し、プローブチェーンが長くなるにつれて、それらのプロパティはますます価値が高くなります。

中央にSIMDがあります

ここでの真の主役はSIMDです。

制御バイトは単にコンパクトであるだけでなく、ベクトル命令で処理されるように明示的に設計されています。1 回のSIMD比較で16個のフィンガープリントを一度にチェックできるため、通常はループとなる処理が複数の広範な操作に変わります。例：

実際には、これは次のことを意味します。

ブランチ数の低減。
プローブチェーンの短縮。
キーメモリや値メモリからのロードの減少。
CPU実行ユニットの利用率が大幅に向上。

ほとんどの検索は制御バイトのスキャンを通過することはありません。そうすれば、残りの作業は焦点が絞られ、予測可能になります。これはまさに、最新のCPUが得意とする種類のワークロードです。

SIMDの仕組み

仕組みを知りたい読者のために、テーブルに新しいキーを挿入すると何が起こるかを説明します。128ビットベクトルのPanama Vector APIを使用し、16の制御バイトを並列で処理します。

次のスニペットは、Intel Rocket LakeとAVX-512で生成されたコードを示しています。手順はその環境を反映していますが、設計はAVX-512に依存しません。同じ高レベルのベクトル操作が、同等の命令（AVX2、SSE、NEONなど）を使用して他のプラットフォームでも実行されます。

; Load 16 control bytes from the control block vmovdqu xmm0, XMMWORD PTR [r9+r10*1+0x10] ; Broadcast the 7-bit fingerprint of the new key across the vector vpbroadcastb xmm1, r11d ; Compare all 16 control bytes to the new fingerprint vpcmpeqb k7, xmm0, xmm1 kmovq rbx, k7 ; Check if any matches were found test rbx, rbx jne

各命令は挿入プロセスにおいて明確な役割を果たします。

vmovdqu：128ビットの xmm0レジスタに16個の連続制御バイトを読み込みます。
vpbroadcastb：新しいキーの7ビットのフィンガープリントをxmm1レジスタのすべてのレーンにわたって複製します。
vpcmpeqb: 各制御バイトをブロードキャストされたフィンガープリントと比較し、一致する可能性のあるマスクを生成します。
kmovq + test：マスクを汎用レジスタに移動し、一致が存在するかどうかをすばやく確認します。

最終的に、ベンチマークにより、レジスタの幅を広げて32バイトまたは64バイトに拡張しても測定可能なパフォーマンス上の利点が得られないことが示されたため、一度に16個の制御バイトのグループをプローブすることに決定しました。

ES|QLにおける統合

Elasticsearchでのスイススタイルのハッシュの採用は、単なる置き換えではありませんでした。ES|QLには、メモリアカウンティング、安全性、コンピューティングエンジンの他の部分との統合に関して厳しい要件があります。

新しいハッシュテーブルを、ページリサイクラーやサーキットブレーカーアカウンティングなどのElasticsearchのメモリ管理と緊密に統合し、割り当てが常に可視かつ制限された状態になるようにしました。Elasticsearchのアグリゲーションは密に格納され、グループIDでインデックス化されるため、メモリレイアウトはコンパクトで高速に保たれ、反復処理も高速になります。また、ランダムアクセスを許可することで特定のパフォーマンスを最適化できます。

可変長バイトキーの場合、グループIDと一緒に完全なハッシュをキャッシュします。これにより、プローブ中に高価なハッシュコードを再計算する必要がなくなり、関連するメタデータを近くに保持することでキャッシュの局所性が向上します。再ハッシュ中は、値自体を検査せずにキャッシュされたハッシュと制御バイトに依存できるため、サイズ変更のコストが低く抑えられます。

実装における重要な簡素化の一つは、エントリーが決して削除されないことです。これにより、トゥームストーン（以前占有されていたスロットを識別するためのマーカー）の必要性がなくなり、空のスロットは実際に空のままになるので、プローブの動作がさらに改善され、制御バイトスキャンが効率的に維持されます。

その結果、スイステーブルの魅力となるパフォーマンス特性を維持しながら、Elasticsearchの実行モデルに自然に適合する設計が実現しました。

パフォーマンス

カーディナリティが小さい場合、スイステーブルのパフォーマンスは既存の実装とほぼ同等になります。これは予想どおりです。テーブルが小さい場合、キャッシュの影響は少なくなり、最適化するための調査もほとんど行われません。

カーディナリティが増加するにつれて、状況は急速に変化します。

上記のヒートマップは、異なるキーサイズ（8、32、64、128バイト）に対する時間改善係数を、1,000から10,000,000グループまでの基数にわたってプロットしています。カーディナリティが増加するにつれて、改善係数は着実に増加し、均一分布の場合は2～3倍に達します。

この傾向はまさに設計が予測していることです。カーディナリティが高くなると、従来のハッシュテーブルではプローブチェーンが長くなりますが、スイススタイルのプローブでは、SIMD対応の制御バイトブロック内でほとんどの検索が引き続き解決されます。

キャッシュの挙動が物語るもの

速度の向上をよりよく理解するために、同じJMH benchmarks をLinuxperf で実行し、キャッシュとTLBの統計を取得しました。

元の実装と比較すると、スイスバージョンでは全体的にキャッシュ参照が約60%少なくなります。最終レベルのキャッシュのロードは4倍以上減少し、LLCロードミスは6倍以上減少します。LLCのミスはメインメモリアクセスに直接変換されることが多いので、この減少だけでエンドツーエンドの改善の大部分を説明できます。

CPUに近いほどL1データキャッシュミスが少なくなり、データTLBミスが約6倍少なくなります。これは、空間的局所性が高く、メモリアクセスパターンがより予測可能であることを示しています。

これがSIMD対応の制御バイトの実用的なメリットです。散在したメモリ位置からキーと値を繰り返しロードする代わりに、ほとんどのプローブは、コンパクトなキャッシュ常駐構造をスキャンすることによって解決されます。アクセスされるメモリが少なければミスも減り、ミスが少なければクエリも速くなります。

まとめ

スイススタイルのハッシュテーブル設計を採用し、SIMDフレンドリーなプロービングを積極的に活用することで、高カーディナリティのES|QL統計ワークロードで2〜3倍の速度向上を達成し、より安定的で予測可能なパフォーマンスを実現しました。

この研究は、現代のCPUに対応したデータ構造が、ハッシュテーブルのような十分に確立された問題においても、大きな性能向上を実現できることを示しています。ここでは、追加のプリミティブ型の特殊化や、結合などの他の高カーディナリティパスでの使用など、さらに検討する余地がありますが、これらはすべて、Elasticsearchの内部を継続的に近代化するための広範かつ継続的な取り組みの一部に過ぎません。

詳細に興味がある方や作業をフォローしたい方は、GitHubのプルリクエストとメタイシューの進捗追跡をチェックしてみてください。

ハッシュを活用しましょう！

Google MCP Toolbox for DatabasesにElasticsearchサポートを導入

Enrico Zimuel,Laurent Saint-Félix — Fri, 12 Dec 2025 00:00:00 GMT

この記事では、Google MCP ToolboxとElasticsearchを併用し、Elasticsearchインデックスから情報を抽出する簡単なツールを構築する方法を解説します。

当社は最近、Google MCP Toolbox for Databasesのオープンソースプロジェクトに貢献し、Elasticsearchをデータベースとしてサポートしました。

この新しい機能により、Google MCP Toolboxを使用してElasticsearchに接続し、データと直接「会話」できるようになりました。

Elasticsearch

Elasticsearchインスタンスを実行する必要があります。Elastic Cloudで無料トライアルを有効化するか、start-localスクリプトを使ってローカルにインストールできます。

curl -fsSL https://elastic.co/start-local | sh

これにより、ElasticsearchとKibanaがコンピュータにインストールされ、Google MCP Toolboxの設定に使用するAPIキーが生成されます。

APIキーは前のコマンドの出力として表示され、elastic-start-localフォルダー内の.envファイルに保存されます。

サンプルデータセットをインストールする

インストール後、ユーザー名elasticとstart-localスクリプトによって生成されたパスワード（.envファイルに保存）を使用してKibanaにログインできます。

Kibanaから入手可能なeCommerce ordersデータをインストールできます。このデータベースには、eコマースWebサイトからの4,675件の注文に関する情報を含むkibana_sample_data_ecommerceという単一のインデックスが含まれています。各注文について、次の情報があります。

顧客情報（氏名、ID、生年月日、メールアドレスなど）
注文日
注文ID
商品（価格、数量、ID、カテゴリー、割引などを含む全商品のリスト）
SKU
合計金額（税抜、税込）
合計数量
地理情報（都市、国、大陸、場所、地域）

サンプルデータをインストールするには、Kibanaの統合ページを開き（検索トップバーで「Integration」を検索）、「Sample Data」をインストールしてください。詳細については、ドキュメントhttps://www.elastic.co/docs/explore-analyze/#gs-get-data-into-kibanaを参照してください。

この記事の目的は、Google MCP ToolboxがElasticsearchに接続し、自然言語でkibana_sample_data_ecommerceインデックスとやり取りするのがいかに簡単かを示すことです。

Google MCP Toolbox

Google MCP ToolboxはオープンソースのMCPサーバーで、アプリケーションやAIエージェントが安全かつ効率的にデータベースとやり取りできるように設計されています。以前は「GenAI Toolbox for Databases」と呼ばれていたこのプロジェクトは、モデルコンテキストプロトコル（MCP）との完全な互換性を採用した後に改名されました。その目的は、エージェントをデータベースに接続する際に従来必要とされていた接続プーリング、認証、オブザーバビリティ、その他の運用上の懸念をバックエンドで処理することで、重労働を排除することです。

Toolboxの本質は、開発者がデータベースのやり取りをカプセル化する再利用可能な高レベルのツールを定義できるようにすることです。これらのツールは、AIエージェントなどのMCP互換クライアントならどれでも起動できます。クライアントが低レベルのSQLクエリを実装したり、データベース接続を管理したりする必要はありません。このアプローチにより、データベース対応エージェントの構築に必要な定型コードの量が大幅に削減され、わずか数行のアプリケーションロジックに高度なデータ操作を統合できるようになります。ツールが定義されると、複数のエージェント、フレームワーク、言語間で共有できます（図1）。

Toolboxを使用する大きな利点は、組み込まれたセキュリティモデルです。OAuth2やOIDCなどの認証フローはネイティブにサポートされているため、開発者はデータベースの機密認証情報をエージェントで処理したり格納したりする必要がありません。このプラットフォームは、デバッグ、監視、本番環境への導入に不可欠な、OpenTelemetryによる指標やトレースなどの観測機能も提供します。全体として、MCP Toolboxは、あらゆるMCP対応システムのデータを操作するための、統一された安全で拡張可能なインターフェースとして機能します。

MCP Toolboxのインストール方法

MCP ToolboxサーバーをLinuxにインストールするには、次のコマンドを使用します。

export VERSION=0.21.0 curl -L -o toolbox https://storage.googleapis.com/genai-toolbox/v$VERSION/linux/amd64/toolbox chmod +x toolbox

macOSまたはWindowsにインストールする場合は、ここに記載されている手順に従ってください。

Elasticsearch向けにToolboxを構成する

Elasticsearch向けにMCP Toolboxを構成するには、次のようにtools.yamlファイルを作成する必要があります。

sources: my-cluster: kind: elasticsearch addresses: - http://localhost:9200 apikey: tools: customer-orders: kind: elasticsearch-esql source: my-cluster description: Get the orders made by a customer identified by name. query: | FROM kibana_sample_data_ecommerce | WHERE MATCH(customer_full_name, ?name, {"operator": "AND"}) parameters: - name: name type: string description: The customer name. toolsets: elasticsearch-tools: - customer-orders

値を有効なElasticsearch APIキーに置き換える必要があります。start-localを使用してElasticsearchをローカルで実行している場合は、start-localによって生成された.envファイルのES_LOCAL_API_KEY変数の下にAPIキーがあります。Elastic Cloudを使用している場合はここで説明した手順に従うことでAPIキーを生成できます。

前のツールには、Elasticsearch用の次のES|QLクエリが含まれています。

ES|QLに慣れていない方のために説明すると、ES|QLはSQLと同様にElasticが開発したクエリ言語で、1つ以上のインデックスを検索するために使用できます。ES|QLの詳細についてはこちらの公式ドキュメントをご覧ください。

上記のクエリは、kibana_sample_data_ecommerceインデックスに格納されている指定顧客名を含むすべての注文を?nameパラメーター（疑問符はパラメーターを示します）を用いて検索します。

顧客名は、以前のYAML設定で文字列型と「顧客名」という記述で定義されています。

このツールを使用すると、顧客の注文に関する質問に答えることができます。たとえば、「顧客Fooは2025年10月に何件の注文をしましたか？」

ツールとそのパラメーターの説明は、ユーザーの自然言語リクエストから関連情報を抽出するために不可欠です。この抽出は、大規模言語モデル（LLM）の関数呼び出し機能を使用して実行されます。実際には、LLMは、必要な情報を取得するためにどの機能（ツール）を実行する必要があるかを判断し、その機能に適したパラメーターも取得できます。

詳細については、Elasticsearchを使用したOpenAIの関数呼び出しに関するAshish Tiwariの記事を読むことをお勧めします。

Toolboxサーバーを実行する

次のコマンドで、以前のtools.yamlファイルを使用してMCPツールボックスを実行できます。

./toolbox --tools-file tools.yaml --ui

–uiパラメーターはhttp://127.0.0.1:5000/uiのウェブアプリケーションを実行します（図2）。

[ツール] > [customer-orders] を選択し、パラメータ名に顧客名（例：Gwen Sanders）を挿入して [ツールを実行] ボタンをクリックします。図3に示すように、JSON応答が表示されます。

セットアップが完了すると、MCP Toolboxはcustomer-ordersツールを実行してElasticsearchと通信し、ES|QLクエリを実行できるようになります。

Gemini CLIでのMCP Toolboxの使用

任意のMCPクライアントを使用して、MCP Toolbox for Databasesと通信できます。例えば、Gemini CLIというコマンドラインツールを使ってGeminiを使うことができます。Gemini CLIのインストールは、こちらの手順に従って行うことができます。

Gemini CLIは、MCP Toolbox用の事前設定された拡張機能を提供しており、gemini-cli-extensions/mcp-toolboxで入手できます。この拡張機能は次のコマンドを実行してインストールできます。

gemini extensions install https://github.com/gemini-cli-extensions/mcp-toolbox

インストール後、MCP Toolbox用のtools.yaml設定ファイルを格納したディレクトリに移動し、以下のようにGemini CLIを実行する必要があります（この手順は、Gemini CLIをMCP Toolboxで自動的に設定するために必要です）。

gemini

図4に示すように出力広告が表示されます。

次のコマンドを使用して、MCP Toolboxが接続されているかどうかを確認できます。

/mcp list

mcp_toolboxとcustomer-orders ツールが一覧に表示されているはずです（図5）。

MCP ToolboxがGemini CLI に接続されている場合は、「顧客Gwen Sandersの注文を教えてください」などの質問をいくつか試すことができます。Gemini CLIは、mcp_toolboxサーバーからcustomer-ordersツールを実行する許可を要求します（図6を参照）。

確認後、Gemini CLIはMCP Toolboxへのリクエストを実行し、結果としてJSON応答を取得し、それを使用して応答をフォーマットします（図7）。

Gemini CLIからの応答で、Gwen Sandersが2つの製品を1回の注文で、合計132ユーロの価格で購入したことがレポートされます。

MCP Toolbox SDKs

Google MCP Toolboxは、Go、Python、Javascriptで書かれたプログラムからすべての機能にアクセスするためのSDKも提供しています。

例えば、Python SDKはGithubの次のページhttps://github.com/googleapis/mcp-toolbox-sdk-pythonで入手可能です。

MCP Toolboxに接続するための簡単なエージェントを作成する必要があります。次のパッケージをインストールする必要があります。

pip install toolbox-core pip install google-adk

次のコマンドを使用して、新しいエージェントプロジェクトを作成します。

adk create my_agent

これにより、ファイルagent.pyを持つ新しいディレクトリがmy_agentとして作成されます。

Toolboxに接続するには、次の内容でmy_agent/agent.pyを更新します。

from google.adk import Agent from google.adk.apps import App from toolbox_core import ToolboxSyncClient client = ToolboxSyncClient("http://127.0.0.1:5000") root_agent = Agent( name='root_agent', model='gemini-2.5-flash', instruction="You are a helpful AI assistant designed to search information about a dataset of ecommerce orders.", tools=client.load_toolset(), ) app = App(root_agent=root_agent, name="my_agent")

Google APIキーを使用して.envファイルを作成します。

echo 'GOOGLE_API_KEY="YOUR_API_KEY"' > my_agent/.env

最後に、エージェントを実行して結果を確認します。エージェントを実行するには、次のコマンドを実行します。

adk run my_agent

または、Webインターフェース経由で提供することもできます。

adk web --port 8000

両方の場合において、Q&Aインターフェースを使用してMCP Toolboxと対話することができます。たとえば、先程の質問「顧客Gwen Sandersの注文を教えてください」をすることができます。

さまざまなSDKの詳細については、このドキュメントページをご参照ください。

まとめ

この記事では、Google MCP Toolbox for DatabasesのElasticsearch統合について説明しました。シンプルなYAML設定ファイルを使用して、自然言語の質問をES|QL言語を使用してElasticsearchクエリに変換する一連のツールを定義できます。

eコマースWebサイトからの注文を含むkibana_sample_data_ecommerceデータセットとの対話方法を示しました。この設定ファイルを使用すると、MCP Toolboxサーバーを簡単に実行し、任意のMCPクライアントから接続できます。

最後に、Gemini CLIをクライアントとして使用してMCP Toolbox for Databasesに接続し、Elasticsearchに保存されているeコマースデータをクエリする方法を示しました。特定の顧客の名前で識別された注文情報を取得するために自然言語クエリを実行しました。

MCPエコシステムが成長し続けるにつれて、このパターン（安全で本番環境ですぐに使えるインフラストラクチャーに裏打ちされた軽量なツール定義）は、最小限の労力で、ますます有能でデータを認識するエージェントを構築する新しい機会を生み出します。MCP Toolboxは、Elasticのサンプルデータセットを使ってローカルで実験する場合でも、大規模なアプリケーションに検索機能を統合する場合でも、自然言語を使ってElasticsearchのデータを操作するための、信頼性と拡張性に優れた基盤を提供します。

エージェントAIアプリケーションの開発の詳細については、Anish MathurとDana Juratoniによる記事「Elasticsearchを使用したAI エージェントワークフローの構築」をお読みください。

Google MCP Toolboxの詳細については、https://googleapis.github.io/genai-toolbox/getting-started/introduction/をご覧ください。

ES|QL 9.2：スマートになったLookup Joinと時系列サポート

Tyler Perkins,Kostas Krikellas,Julian Kiryakov — Tue, 02 Dec 2025 00:00:00 GMT

10月にリリースされたElasticsearch 9.2には、データの分析をこれまで以上に高速化、柔軟化、アクセスしやすくするための大きな進化が詰まっています。このリリースの中心となるのは、パイプクエリ言語であるES|QLの重要な機能強化で、エンドユーザーに直接さらに多くの価値をもたらすように設計されています。

ES|QLを使用してデータ分析ワークフローを変革するElasticsearch 9.2の特徴を見てみましょう。

データ相関の革命：よりスマート高速、柔軟になったLookup Join

ES|QLのLOOKUP JOINコマンドはElasticsearch 9.2で大幅に変更され、効率性と汎用性が飛躍的に向上しました。LOOKUP JOINは、ES|QLクエリ結果テーブルのデータを、指定されたルックアップモードインデックスの一致するレコードと結合します。結合フィールド内の一致する値に基づいて、ルックアップインデックスのフィールドが新しい列として結果テーブルに追加されます。以前は、データの結合は単一のフィールドと単純な等式に制限されていましたが、これが改善されました。これらの機能強化により、複雑なデータ相関シナリオに簡単に対処できるようになります。

Lookup Joinの主な機能強化は次のとおりです。

複数フィールド結合：複数のフィールドを簡単に結合できます。例えば、application_logs を service_name、environment の service_registry と結合する場合 version:

FROM application_logs | LOOKUP JOIN service_registry ON service_name, environment, version

式を使用して複雑なjoin述語を活用（テクニカルプレビュー）：

もはや、単純な等式に制限されることはありません。LOOKUP JOINでは、複数の条件を相関に指定し、==、!=、、<=、>= を含む 二項演算子の範囲を組み込むことができます。つまり、非常に微妙な結合条件を作成できるようになり、データに対してより高度な質問をすることができるようになります。

例1：サービスごとのSLAしきい値を使用したアプリケーションメトリクスの検索

FROM application_metrics | LOOKUP JOIN sla_thresholds ON service_name == sla_service AND response_time > sla_response_time

例2：このクエリは、時間とともに変化する地域の価格ポリシーに基づいて支払われるべき金額を計算します。複雑な日付範囲と等しい条件に基づく3つのデータセットを統合し、最終的に due_amountを算出します。2番目のルックアップ結合では、 meter_readingsインデックスのmeasurement_dateフィールドとcustomersインデックスのregion_idフィールドを使用してpricing_policiesインデックスに結合し、特定のregionとmeasurement_dateの正しい価格設定ポリシーを検索します。

FROM meter_readings | LOOKUP JOIN customers ON meter_id | LOOKUP JOIN pricing_policies ON region_id == region AND measurement_date >= policy_begin_date AND measurement_date < policy_end_date | EVAL due_amount = (kwh_consumed * rate_per_kwh + base_charge) * (1 + tax_rate) | EVAL period = policy_name | KEEP customer_name, period, due_amount, measurement_date, kwh_consumed, rate_per_kwh, base_charge, tax_rate | SORT measurement_date

フィルターされた結合のパフォーマンスが大幅に向上：

ルックアップテーブル条件を使用してフィルター処理される「拡張結合」のパフォーマンスが向上しました。拡張結合では、入力行ごとに複数の一致が生成され、大きな中間結果セットが作成されることがあります。これらの行の多くが後続のフィルターによって破棄されると、状況はさらに悪化します。9.2では、ルックアップデータにフィルターを適用するときに不要な行を除外することでこれらの結合を最適化し、破棄される行の処理を回避します。シナリオによっては、これらの結合は最大1000倍高速化される可能性があります。

この最適化は、ルックアップによって最初に多くの潜在的な一致が生成される可能性がある「拡張結合」を処理する場合に重要です。フィルターをインテリジェントにプッシュダウンすることで、関連するデータのみが処理され、クエリ実行時間が大幅に短縮され、膨大なデータセットでのリアルタイム分析が可能になります。つまり、非常に大規模または複雑な結合操作の場合でも、はるかに速く洞察を得ることができます。

Lookup Joinクラスター横断検索（CCS）の互換性：

8.19および9.1でLookup Joinが一般公開となった際、クロスクラスター検索（CCS）のサポートはありませんでした。複数のクラスターにまたがって運用している組織のため、LOOKUP JOINは9.2でCCSとシームレスに統合されるようになりました。ルックアップインデックスを結合したいすべてのリモートクラスターに配置するだけで、ES|QLは自動的にこれらのリモートルックアップインデックスを活用して、リモートデータと結合します。これにより、分散データ分析が簡素化され、Elasticsearch展開全体で一貫したエンリッチメントが保証されます。

これらの改善により、多様なデータセットを前例のない精度、速度、そして容易さで関連付けることができ、複雑な回避策や前処理のステップなしに、より深く、実用的な洞察を明らかにすることができます。

データを簡単に充実化：ルックアップインデックスのためのKibana Discoverユーザーエクスペリエンス

データのエンリッチメントはハードルではなく、シンプルであるべきです。KibanaのDiscoverに、ルックアップインデックスの作成と管理のための素晴らしい新しいユーザーエクスペリエンスを導入しました。

直感的なワークフロー：Discoverの包括的なオートコンプリートがES|QLエディターでルックアップインデックスや結合フィールドを提案するため、アップロードされたデータを既存のインデックスと驚くほど簡単に結びつけることができます。存在しないルックアップインデックスの名前を入力し、ワンクリックでルックアップエディターに直接アクセスしてインデックスを作成できます。既存の検索インデックスの名前を入力すると、編集オプションを提案します。

インライン管理（CRUD）： Discoverで直接、参照データセットをインライン編集機能（作成、読み取り、更新、削除）で最新の状態に保ちます。

簡単なファイルアップロード：CSVなどのファイルをDiscover内で直接アップロードし、 LOOKUP JOINですぐに使用できるようになりました。Kibanaのさまざまなエリアにジャンプしてコンテキストを切り替える必要はもうありません！

ユーザーIDを名前にマッピングしたり、ビジネスメタデータを追加したり、静的参照ファイルを結合したりする際、この特徴はデータのエンリッチメントを民主化し、結合のパワーをすべてのユーザーの手元に直接、迅速かつシンプルに、そして一箇所で提供します。

コンテキストの保持：INLINE STATSのご紹介（テクニカルプレビュー）

データの集約は重要ですが、時には集約を元のデータと並べて見る必要があることもあります。INLINE STATSをテクニカルプレビュー機能としてご紹介できることを嬉しく思います。

入力フィールドを集約された出力に置き換えるSTATSコマンドとは異なり、 INLINE STATS元の入力フィールドをすべて保持し、新しい集約されたフィールドを追加します。これにより、集計後に元の入力フィールドに対してさらに操作を実行できるようになり、より継続的で柔軟な分析ワークフローが実現します。

例えば、個々のフライトの行を保持しながら平均飛行距離を計算する場合：

FROM kibana_sample_data_flights | KEEP Carrier, Dest, DistanceMiles | INLINE STATS avgDist = ROUND(AVG(DistanceMiles)) BY Dest | WHERE DistanceMiles > avgDist

このクエリでは、avgDistが各行に対応するDest(ination)と共に追加され、さらに、フライト情報の列が残っているため、平均を超える距離のフライトに結果をフィルタリングできます。

ES|QL における時系列サポート (技術プレビュー)

Elasticsearchは、メトリックを格納するために時系列データストリームを使用します。TSソースコマンドを通じて、ES|QLの時系列集計のサポートを追加しています。これは、Elastic Cloud Serverlessと9.2 basicでテクニカルプレビューとして利用できます。

時系列分析は主に、1つ以上のフィルタリングディメンションでスライスされた時間バケット全体のメトリック値を要約する集計クエリに基づいています。ほとんどの集計クエリは、(a) 時系列ごとに値を集計する内部集計関数と、(b) 時系列全体で (a) の結果を結合する外部集計関数という2段階の処理に依存しています。

TSソースコマンドをSTATSと組み合わせると、時系列にわたるこのようなクエリを簡潔かつ効果的に表現できるようになります。より具体的には、ホストおよび時間あたりのリクエストの合計レートを計算する次の例を考えてみましょう。

TS my_metrics | WHERE @timestamp > NOW() - 1 day | STATS SUM(RATE(requests)) BY host, TBUCKET(1h)

この場合、時系列アグリゲーション関数 RATE はまず時系列と時間ごとに評価されます。生成された部分集計は、 SUMを使用して結合され、ホストおよび時間ごとの最終的な集計値が計算されます。

利用可能な時系列集計関数のリストはこちらで確認できます。カウンターを処理するための最も重要な集計関数のcounterレートがサポートされるようになりました。

TSソースコマンドはSTATSと組み合わせて使用するように設計されており、時系列集計を効率的にサポートするように実行が調整されています。例えば、データはSTATSに入る前にソートされます。処理コマンド（FORKやINLINE STATSなど）によって時系列データを強化または変更したり、その順序を変更したりすることは、現在TSとSTATSの間で許可されていません。この制限は将来解除される可能性があります。

STATS表形式の出力は、適用可能なコマンドを使用してさらに処理できます。例えば、以下のクエリは、ホストごとの平均の cpu_usage と時間の比率とホストごとの最大値の比率を計算します。

時系列データは、Luceneドキュメント値を利用した基盤となる列指向ストレージエンジンに保存されます。TSコマンドは、ES|QLコンピュートエンジンを介してベクトル化されたクエリの実行を追加します。クエリパフォーマンスは、同等のDSLクエリと比較して、しばしば1桁以上の向上が見られ、確立されたメトリクス固有のシステムと同等になります。今後、詳細なアーキテクチャおよびパフォーマンス分析も提供する予定ですので、どうぞご期待ください。

ツールキットの拡張：新しい ES|QL関数

ES|QLの実用性と多様性をさらに高めるために、新しい関数群を追加しました。

文字列操作：INCLUDES、MV_CONTAINS、URL_ENCODE、 URL_ENCODE_COMPONENT、URL_DECODEが追加され、より堅牢なテキストおよびURL処理を実現します。

時系列と地理空間:柔軟な時間バケツ処理のためのTBUCKET 、ベクトル演算のための TO_DENSE_VECTOR、高度な位置ベースの分析のためのST_GEOHASH 、 ST_GEOTILE 、 ST_GEOHEX 、 TO_GEOHASH 、 TO_GEOTILE 、 TO_GEOHEXなどの包括的な地理空間関数のセット。

日付のフォーマット：DAY_NAME、MONTH_NAMEは、より読みやすい日付表現のために使用されます。

これらの関数には、ES|QL内で直接データを操作および分析するための豊富なツールセットが用意されています。

内部の改善：パフォーマンスと効率性の向上

注目の機能以外にも、Elasticsearch 9.2にはES|QL全体にわたる数多くのパフォーマンス最適化が含まれています。関数が複数の類似したRLIKEクエリを置き換える場合に、プッシュダウンを使用してRLIKE (LIST) を高速化しました。RLIKE (LIST) を使用すると、これらのクエリを1つのオートマトンに結合し、複数ではなく1つのオートマトンを適用できます。また、インデックスの並べ替えによるキーワードフィールドの読み込みが高速化され、クエリ全般が最適化されました。これらの改善により、ES|QLクエリがこれまで以上に効率的に実行されるようになります。

今すぐ始めましょう！

Elasticsearch 9.2は、ES|QLを大きく飛躍させ、データ分析ワークフローにかつてないパワーと柔軟性をもたらします。ぜひこれらの新機能を試して、その違いを体験してください。

Elasticsearch 9.2のすべての変更点と機能強化の包括的なリストについては、公式リリースノートを参照してください。楽しいクエリングを!

Elasticsearch の ES|QL エディターエクスペリエンスと OpenSearch の PPL イベントアナライザーの比較

Libby Lin,George Kobar — Thu, 18 Sep 2025 00:00:00 GMT

8.14 から一般公開されているElasticsearch クエリ言語(ES|QL) では、検索、可観測性、セキュリティ調査用に設計された専用のクエリ言語とエンジンが導入されています。既存のパイプ言語から多くの部分を借用している OpenSearch のパイプ処理言語 (PPL) とは異なり、ES|QL は洗練性、使いやすさ、および Kibana プラットフォーム全体でのシームレスな統合に重点を置いてゼロから構築されました。

このブログでは、Elasticsearch 9.1 の ES|QL エディターの開発者エクスペリエンスを、OpenSearch 3.2 のイベントアナライザー (略して PPL) の PPL と比較しながら探っていきます。

違いはすぐに明らかになります。ES|QL エディターは、初心者ユーザーだけでなく、エキスパートレベルのユーザーにも力を与えるインテリジェントなオートコンプリート、コンテキストヘルプ、推奨クエリ、およびクラスター間クエリサポートを提供します。ES|QL オーサリングの思慮深い設計は、たとえば最近のクエリを使用した Kibana ワークフローによる統合クエリ検査と総合的な統合にも反映されています。

対照的に、PPL にはオートコンプリート、コンテキストガイダンス、分散クエリに対する同等のサポートがないため、学習曲線が急峻になり、試行錯誤が増えます。

ES|QL の学習と使用を容易にする

新しいクエリ言語を使い始めると、圧倒されると感じることがよくあります。Kibana Discover に直接組み込まれた ES|QL エディターは、クエリの作成とデバッグをサポートするだけでなく、言語に慣れて使いこなせるようになるまでの時間を短縮することで、そのプロセスを容易にするように設計されています。エディターは日常のタスクの摩擦を軽減するのに役立つため、構文や試行錯誤からソリューションの作成に焦点を移すことができます。これらの原則と、それをエディターにどのように統合したかの詳細については、こちらをご覧ください。

このエディターエクスペリエンスは Discover に限定されません。これは再利用可能なコードモジュールであり、ダッシュボード、Kibana アラート、Kibana マップなど、 Kibana の他の部分に統合する作業が進められています。

インテリジェントなオートコンプリート: クエリ作成を高速化

ES|QL エディターのオートコンプリートは包括的で、互換性のある関数、引数、リテラル、さらにはネストされた関数の提案を提供します。これは PPL には明らかに欠けている機能です。実際、ここで概説されているように、根本から再構築されました。

ここで説明されているように、検証はユーザーが入力すると実行され、フィールドを提案し、ユーザーにエラーを通知します。これにより、ユーザーの精神的負担が軽減され、クエリ作成プロセスの早い段階でエラーを防ぐことができます。

例: このネストでは、フィールドと互換性のある関数が提案されています。

PPL がサポートしていないもの:

互換性のある関数、引数、ネストされた関数を案内するインテリジェントなオートコンプリート機能があっても、利用可能なオプションについてさらに深く理解したい場合があります。ここで、ES|QL エディターのコンテキストヘルプが非常に役立ち、エディター内で即時に支援が提供され、クエリの開発が明確化され、強化されます。

指先で状況に応じたヘルプ

オートコンプリートによって生成されたコマンドに関する追加情報は、Ctrl キーとスペースキーを押すことで表示されます。問題の関数、引数、またはフィールドの詳細を示すパネルがすぐに表示されます。この軽量なインタラクションにより、開発者はスムーズに作業を進めることができ、エディターを離れたり外部ドキュメントを検索したりすることなく、ジャストインタイムのガイダンスを得ることができます。これにより、構文の検索に費やす時間が削減され、よくある間違いを未然に防ぐことができます。

実際の動作は次のようになります。

PPL にはこのレベルの組み込みガイダンスがないため、ユーザーは外部のドキュメントや試行錯誤に頼ることになります。その欠如は単に機能が欠けているというだけではなく、設計哲学におけるより広範な相違を浮き彫りにしています。ES|QL は、ユーザーのデータとワークフローに適応する、思慮深くコンテキストを意識したエクスペリエンスを優先します。この違いはクエリの複雑さが増すにつれて顕著になり、ES|QL エディターは学習と本番使用の両方においてより効率的で信頼性の高い環境になります。

データのコンテキストを考慮した推奨クエリ

ES|QL エディターは、ログなどの作業中のデータに合わせて自動的に調整される推奨クエリを提供します。空白のエディターを表示する代わりに、一般的なユースケースに最も関連性の高い開始点を表示します。推奨クエリを選択すると、すぐに使用できる標準クエリが生成され、必要に応じてさらに絞り込むことができます。このアプローチにより、特に完全な構文をまだ知らない新しいユーザーにとって、クエリの開発が加速されます。

以下は、ユーザーが「変化点の検出」クエリを選択する例です。

これを PPL の経験と比較してみましょう。

対照的に、ここでの PPL は基本的なオートコンプリートのみを提供するため、コンテキストや構造なしでクエリを組み立てることになります。このガイダンスの欠如は、フラストレーションと試行錯誤につながる可能性があります。ES|QL エディターのデータ対応の推奨クエリを使用すると、日常的なタスクの構文を最初から作成したり、暗記したりする必要がなくなります。エディターは認知負荷を軽減し、エラーの防止に役立ち、クエリの構築に悩むのではなく、問題解決やクラスター間検索の実行などのより広範な目標に集中できるようにします。

直感的なクラスター間クエリ

ES|QL エディターのオートコンプリートは、 CCS を使用して複数のリモートクラスターを操作する場合でも、優れた性能を維持します。理由は次のとおりです。

ES|QL エディターは、クラスター間でもシームレスなオートコンプリートを提供します。

ES|QL エディターのオートコンプリートは、クラスター名だけでなく、ローカルインデックスとリモートインデックスの両方をサポートします。ここで説明されているように、これはコーディネーターノードアーキテクチャのおかげで機能します。このアーキテクチャは、ローカルノードに送信するクエリプランを検証および生成し、クエリを実行して結果を集計してからユーザーに送り返すのに役立ちます。完全なリモートクラスター名を入力せずに「:」と入力すると、リモートインデックスの自動補完プロセスが開始されます。また、接頭辞に限定されるわけではありません。

これにより、命名規則を記憶したりコンテキストを切り替えたりすることなく、分散データセット全体の検出とクエリを簡単に実行できるようになります。

以下は、ユーザーが「clu:g」と入力してリモートインデックスを検索する例です。

対照的に、PPL はローカルインデックスに対して基本的な補完のみを提供し、提案はプレフィックスの一致に制限されています。リモートクラスターは手動で入力する必要があるため、エラーが発生する可能性が高まり、クエリの作成が遅くなります。

PPL はローカルインデックスに対してのみ補完を提供し、提案はプレフィックスに制限されます。

ES|QL ではさらに、負の符号を使用して直接除外できるため、探索に参加するクラスターをきめ細かく制御できます。この機能は、クラスター間の調査中に特定のデータセットを含めたり省略したりする必要があるハイブリッド環境で作業する場合に特に役立ちます。

これらの機能強化は、Elasticsearch がクラスター間検索における摩擦の軽減に重点を置いていることを反映しています。ES|QL エディターでは、分散クエリの構築と管理が容易になるため、アナリストや開発者は構文ではなく洞察に集中できます。一方、PPL ではその負担がユーザーに多く残ります。ES|QL エディターは、クラスター間クエリの作成を簡素化するだけでなく、それらのクエリの実行方法を検査するツールも提供し、複数のクラスターにわたる透明性とパフォーマンス監視を保証します。

検査ツールを使用してクロスクラスター検索の詳細を分析する

ES|QL エディターからアクセスできる検査ツールは、すべてのクラスターにわたるクエリ実行に関する明示的な情報をメタデータに提供するように設計されています。この機能は Kibana Discover で有効になっており、クエリインスペクターから直接アクセスできるため、検索の進行状況と詳細を分析できます。これは、Cross-Cluster Search ( CCS ) にとって特に重要です。この機能を使用すると、検索の進行状況を監視し、分散データセット全体でのクエリの実行方法を把握できます。

特に複雑な分散検索の場合、クエリ実行の詳細な可視性により、最適なパフォーマンスとトラブルシューティングが可能になります。

ES|QL エディターは、個々のクエリの仕組みを理解するだけでなく、Kibana プラットフォーム全体に重要な機能を深く組み込むことでユーザージャーニーをさらに強化し、シームレスで中断のないワークフローを促進します。

ES|QLとKibanaによる統合クエリエクスペリエンス

クエリ駆動型分析における最も一般的な摩擦の原因の 1 つは、コンテキストの切り替えです。すでに記述したクエリを思い出す必要がある場合がよくあります。中断されるたびに集中力が途切れ、調査が遅くなります。ES|QL エディターは、Kibana 全体のクエリ履歴を統合することでこの問題に対処します。

まとめ

ES|QL は単なる構文ではありません。ユーザーがデータを検索、探索、分析する方法を改善するという Elastic の戦略を反映しています。インテリジェントなオートコンプリート、コンテキスト認識型の推奨クエリ、エディター内ガイダンス、Inspect などのツールを備えた ES|QL エディターは、学習を加速し、エラーを削減し、クラスター間分析などの複雑なワークフローを簡素化します。Kibana 全体に統合されており、クエリをダッシュボード、アラート、視覚化にシームレスに接続して、中断のないワークフローを実現します。

要約すると、ES|QL は単なる別のパイプ言語ではありません。データとの対話方法を根本的に再定義する直感的な UI と組み合わせた、思慮深く設計されたクエリエンジンであり、OpenSearch PPL の多くの場合シーケンシャルでガイドが少ない性質とは対照的に、統合されたインテリジェントで継続的に進化するエクスペリエンスを提供します。

次は何？

このブログは ES|QL の表面的な部分のみを取り上げています。今後の投稿では、OpenSearch PPL との比較をさらに深め、地理空間、視覚化、コントロール(ダッシュボードで既に利用可能)、マルチデータ探索タブ、バックグラウンド検索、より豊富なクエリ履歴、FUSE などの今後のエディター機能について説明します。

今すぐES|QLをお試しください

無料トライアルで、完全に管理された Elasticsearch Serverless プロジェクトで ES|QL を試すことができます。8.11 以降のバージョンでも利用可能ですが、 8.19 および 9.1で最も快適にご利用いただけます。

1 つのコマンドでローカル環境で数分以内に開始できます。

curl -fsSL https://elastic.co/start-local | sh

Elasticsearch Ruby クライアント向け ES|QL クエリビルダーのご紹介

Fernando Briano — Wed, 17 Sep 2025 00:00:00 GMT

最近、Apache 2 ライセンスに基づいて公開された Ruby gem、 elastic-esqlをリリースしました。この gem を使用すると、Elastic のES|QLクエリを慣用的な Ruby で構築し、ES|QL クエリ API で使用できるようになります。ES|QL を使用すると、開発者はクエリを介して Elasticsearch に保存されているデータをフィルタリング、変換、分析できます。「パイプ」（ | ）を使用して、データを段階的に処理します。代わりに gem は Ruby 関数を使用します。これを元のオブジェクトに連鎖して、より複雑なクエリを構築できます。

ESQL:

ルビー：

Elastic::ESQL.from('sample_data').limit(2).sort('@timestamp').descending

インストール

この gem は、RubyGems から次のようにインストールできます。

gem install elastic-esql

または、プロジェクトの Gemfile に追加することもできます。

gem 'elastic-esql'

使用法

完全なクエリを一度に構築することも、 fromやrowなどのソースコマンドを使用してクエリオブジェクトを作成し、それに基づいて ES|QL メソッドを連鎖して構築することもできます。

query = Elastic::ESQL.from('sample_data') query.limit(2).sort('@timestamp')

gem はto_sメソッドでコードを ES|QL に変換するので、印刷されるか文字列としてキャストされるときに ES|QL クエリを返します。

query = Elastic::ESQL.from('sample_data').limit(2).sort('@timestamp').descending query.to_s # => "FROM sample_data | LIMIT 2 | SORT @timestamp DESC"

各関数の!に相当するものを使用して、クエリオブジェクトをインスタンス化し、その初期状態を変更できます。

query = Elastic::ESQL.from('sample_data') query.to_s # => "FROM sample_data" query.limit!(2).sort!('@timestamp') query.to_s # => "FROM sample_data | LIMIT 2 | SORT @timestamp"

このツールは、 enrichやsortなどの追加ステップを ES|QL 関数に連鎖させる便利な方法を提供します。Elastic::ESQLオブジェクトでenrich呼び出すと、それにonとwithを連鎖できます。

esql.enrich!('policy').on('a').with({ name: 'language_name' })

sortを使用した後、クエリにdesc 、 asc 、 nulls_first 、 nulls_lastを連鎖させることもできます。

Elastic::ESQL.from('sample_data').sort('@timestamp').asc.to_s # => 'FROM sample_data | SORT @timestamp ASC' Elastic::ESQL.from('sample_data').sort('@timestamp').desc.nulls_first.to_s # => 'FROM sample_data | SORT @timestamp DESC NULLS FIRST'

また、ES|QL クエリを自分で記述する場合や、ライブラリにまだ追加されていない機能を使用する場合に備えて、カスタム文字列もサポートされています。customクエリの末尾の文字列を結合します。パイプ文字を追加せずに、関数に送信されるとそれらが追加されます。これらはスペース文字によってクエリの残りの部分に結合されます。

esql = Elastic::ESQL.from('sample_data') esql.custom('| MY_VALUE = "test value"').to_s # => 'FROM sample_data | MY_VALUE = "test value"'

custom関数を連鎖させることもできます:

esql.custom('| MY_VALUE = "test value"').custom('| ANOTHER, VALUE') 'FROM sample_data | MY_VALUE = "test value" | ANOTHER, VALUE'

Ruby クライアントで ES|QL クエリビルダーを使用する

クエリオブジェクトを送信することで、 elasticsearch-rubyとesql.query API でクエリビルダーを直接使用できます。

require 'elasticsearch' require 'elastic/esql' client = Elasticsearch::Client.new index = 'sample_data' query = Elastic::ESQL.from(index) .sort('@timestamp') .desc .where('event_duration > 5000000') .limit(3) .eval({ duration_ms: 'ROUND(event_duration/1000000.0, 1)' }) client.esql.query(body: { query: query })

Elasticsearch Ruby クライアントの ES|QL Helper と一緒に使用することもできます。詳細については、以下を参照してください。

require 'elasticsearch/helpers/esql_helper' Elasticsearch::Helpers::ESQLHelper.query(client, query)

スタンドアロンツールとして

この gem は、ES|QL クエリを慣用的な方法で構築するためのスタンドアロンツールとして設計されています。ランタイム依存関係がないため、公式の Elasticsearch Ruby クライアントと一緒に使用することも、単独で使用することもできます。

生成されたクエリは、アプリケーションが Elasticsearch API (Ruby かどうかに関係なく) と対話するあらゆる方法でesql.query API で使用できます。elastic-esqlを使用してクエリを構築すると、生成された文字列をリクエスト本文のqueryパラメータとして API に送信できます。

以前、 Elasticsearch を一般的な Ruby ツールと併用する方法について書きました。この gem は、一般的な Ruby ツールと組み合わせて使用し、ES|QL を使用して Elasticsearch をクエリできます。

まとめ

このライブラリは現在開発中であり、最終的な API はまだ完成していません。現在はテクニカルプレビューとしてリリースされています。現在の API または一般的な使用方法に関してフィードバックがある場合は、遠慮なく新しい問題を開いてください。Ruby ES|QL クエリビルダーの詳細については、 READMEを参照してください。

Kibana を使用して地理空間データを Elasticsearch に取り込み、ES|QL で使用できるようにする

Craig Taverner — Fri, 25 Oct 2024 00:00:00 GMT

最近、Elasticsearch の新しい強力なパイプクエリ言語である ES|QL の新しい地理空間検索機能の使用方法を説明するブログを公開しました。これらの機能を使用するには、Elasticsearch に地理空間データが必要です。そこでこのブログでは、地理空間データを取り込む方法と、それを ES|QL クエリで使用する方法を紹介します。

Kibanaを使用した地理空間データのインポート

前回のブログの例に使用したデータは、統合テストのために社内で使用しているデータに基づいています。便宜上、Kibana を使用して簡単にインポートできるいくつかの CSV ファイルの形式でここに含めました。データには空港、都市、都市境界が混在しています。データは以下からダウンロードできます:

空港.csv
- これには 3 つのデータセットの結合が含まれます。
  - Natural Earthの空港（名称、場所、関連データ）
  - SimpleMapsからの都市の位置
  - 世界の空港データベースからの空港標高
空港都市境界.csv
- これには、上記の空港名と都市名が 1 つの新しいソースと結合されたものが含まれています。
  - OpenStreetMapの都市境界

ご想像のとおり、私たちは ES|QL の地理空間機能をテストできるようにすることを目的として、これらのデータソースを上記の 2 つのファイルに結合するのに時間を費やしました。これは、特定のデータニーズとまったく同じではないかもしれませんが、これによって、何が可能かについてのアイデアが得られると思います。特に、いくつかの興味深い点について説明したいと思います。

地理空間フィールドを含むデータを他のインデックス可能なデータと一緒にインポートする
geo_pointとgeo_shape両方のデータをインポートし、クエリで一緒に使用します
空間関係を使用して結合できる 2 つのインデックスにデータをインポートする
将来のインポートを容易にするための取り込みパイプラインの作成（Kibana 以外）
csv 、 convert 、 split

このブログでは CSV データの操作について説明しますが、 Kibana を使用して地理データを追加する方法はいくつかあることを理解することが重要です。マップアプリケーション内では、CSV、GeoJSON、ESRI ShapeFiles などの区切りデータをアップロードでき、マップ内に直接図形を描画することもできます。このブログでは、Kibana ホームページから CSV ファイルをインポートすることに焦点を当てます。

空港の輸入

最初のファイル、 airports.csv 、対処する必要がある興味深い癖がいくつかあります。まず、列を区切る追加の空白がありますが、これは CSV ファイルでは一般的ではありません。次に、 typeフィールドは複数値フィールドであるため、個別のフィールドに分割する必要があります。最後に、一部のフィールドは文字列ではないため、適切な型に変換する必要があります。これらはすべて、Kibana の CSV インポート機能を使用して実行できます。

Kibana のホームページから始めましょう。「統合を追加して開始する」というセクションがあり、そこに「ファイルをアップロードする」というリンクがあります。

このリンクをクリックすると、「ファイルのアップロード」ページに移動します。ここでairports.csvファイルをドラッグアンドドロップすると、Kibana がファイルを分析し、データのプレビューを表示します。区切り文字がコンマであること、最初の行がヘッダー行であることが自動的に検出されるはずです。ただし、すべてのフィールドがtextまたはkeywordであると想定すると、列間の余分な空白が削除されず、フィールドの種類も判別されなかった可能性があります。これを修正する必要があります。

Override settingsをクリックし、 Should trim fieldsのチェックボックスをオンにして、 Applyクリックして設定を閉じます。ここで、フィールドのタイプを修正する必要があります。これは次のページでご覧いただけますので、 Importをクリックしてください。

まずインデックス名を選択し、次にAdvancedを選択してフィールドマッピングと取り込みプロセッサページに移動します。

ここでは、インデックスのフィールドマッピングと、データをインポートするための取り込みパイプラインの両方に変更を加える必要があります。まず、Kibana はscalerankフィールドをlongとして自動検出したと思われますが、 locationフィールドとcity_locationフィールドをkeywordとして誤って認識しました。これらをgeo_pointに編集すると、マッピングは次のようになります。

{ "properties": { "abbrev": { "type": "keyword" }, "city": { "type": "keyword" }, "city_location": { "type": "geo_point" }, "country": { "type": "keyword" }, "elevation": { "type": "double" }, "location": { "type": "geo_point" }, "name": { "type": "text" }, "scalerank": { "type": "long" }, "type": { "type": "keyword" } } }

ここではある程度の柔軟性がありますが、選択したタイプによって、フィールドのインデックス作成方法や、可能なクエリの種類が影響を受けることに注意してください。たとえば、 location keywordのままにしておくと、地理空間検索クエリを実行することはできません。同様に、 elevation textのままにしておくと、数値範囲のクエリを実行することはできません。

ここで、取り込みパイプラインを修正します。Kibana が上記のscalerank longとして自動検出した場合、フィールドをlongに変換するプロセッサも追加されます。elevationフィールドに同様のプロセッサを追加して、今回はdoubleに変換する必要があります。この変換が確実に実行されるようにパイプラインを編集します。これを保存する前に、 typeフィールドを複数のフィールドに分割する変換をもう 1 つ実行する必要があります。次の構成で、パイプラインにsplitプロセッサを追加します。

{ "split": { "field": "type", "separator": ":", "ignore_missing": true } }

最終的な取り込みパイプラインは次のようになります。

{ "description": "Ingest pipeline created by text structure finder", "processors": [ { "csv": { "field": "message", "target_fields": [ "abbrev", "name", "scalerank", "type", "location", "country", "city", "city_location", "elevation" ], "ignore_missing": false, "trim": true } }, { "convert": { "field": "scalerank", "type": "long", "ignore_missing": true } }, { "convert": { "field": "elevation", "type": "double", "ignore_missing": true } }, { "split": { "field": "type", "separator": ":", "ignore_missing": true } }, { "remove": { "field": "message" } } ] }

locationフィールドとcity_locationフィールドには変換プロセッサを追加していないことに注意してください。これは、フィールドマッピングのgeo_pointタイプが、これらのフィールドのデータのWKT形式をすでに理解しているためです。geo_point型は、 WKT、GeoJSON など、さまざまな形式を理解できます。たとえば、CSV ファイルにlatitudeとlongitudeの 2 つの列がある場合、これらを 1 つのgeo_pointフィールドに結合するには、 scriptまたはsetプロセッサを追加する必要がありました (例:"set": {"field": "location", "value": "{{lat}},{{lon}}"} ）。

これでファイルをインポートする準備が整いました。Importをクリックすると、定義したマッピングと取り込みパイプラインを使用してデータがインデックスにインポートされます。データの取り込み中にエラーが発生した場合は、Kibana によってここで報告されるので、ソースデータまたは取り込みパイプラインを編集して再試行できます。

新しい取り込みパイプラインが作成されたことに注意してください。これは、Kibana のStack Managementセクションに移動し、 Ingest pipelinesを選択すると表示されます。ここで、作成したパイプラインを確認し、必要に応じて編集できます。実際、 Ingest pipelinesセクションは取り込みパイプラインの作成とテストに使用できます。これは、さらに複雑な取り込みを行う予定がある場合に非常に便利な機能です。

このデータをすぐに調べたい場合は後のセクションに進んでください。ただし、都市の境界もインポートしたい場合は読み続けてください。

都市境界のインポート

airport_city_boundaries.csvで利用可能な都市境界ファイルは、前の例よりもインポートが少し簡単です。これには、都市の境界をPOLYGONとして WKT で表現したcity_boundaryフィールドと、都市の位置をgeo_point表現したcity_locationフィールドが含まれています。このデータは空港データと同様の方法でインポートできますが、いくつか違いがあります。

自動検出されなかったため、オーバーライド設定Has header rowを選択する必要がありました
データにはすでに余分な空白が除去されていたため、フィールドをトリミングする必要はありませんでした。
すべての型が文字列または空間型であったため、取り込みパイプラインを編集する必要はありませんでした。
ただし、フィールドマッピングを編集して、 city_boundaryフィールドをgeo_shapeに設定し、 city_locationフィールドを geo_point

最終的なフィールドマッピングは次のようになります。

{ "properties": { "abbrev": { "type": "keyword" }, "airport": { "type": "keyword" }, "city": { "type": "keyword" }, "city_boundary": { "type": "geo_shape" }, "city_location": { "type": "geo_point" }, "region": { "type": "text" } } }

以前のairports.csvインポートと同様に、 Importをクリックするだけでデータがインデックスにインポートされます。データは、編集したマッピングと Kibana が定義した取り込みパイプラインを使用してインポートされます。

開発ツールで地理空間データを探索する

Kibana では、インデックス化されたデータを「Discover」で探索するのが一般的です。ただし、ES|QL クエリを使用して独自のアプリを作成することが目的である場合は、生の Elasticsearch API にアクセスしてみる方が興味深いかもしれません。Kibana には、クエリの記述を試すための便利なコンソールがあります。これはDev Toolsコンソールと呼ばれ、Kibana サイドバーにあります。このコンソールは Elasticsearch クラスターと直接通信し、クエリの実行、インデックスの作成などに使用できます。

次のことを試してください。

POST /_query?error_trace=true&format=txt { "query": """ FROM airports | EVAL distance = ST_DISTANCE(city_location, TO_GEOPOINT("POINT(12.565 55.673)")) | WHERE distance < 1000000 AND scalerank < 6 AND distance > 10000 | SORT distance ASC | KEEP distance, abbrev, name, location, country, city, elevation | LIMIT 10 """ }

これにより、次の結果が得られます。

距離

略語

名前

場所

国

市

標高

273418.05776847183

ハム

ハンブルク

ポイント (10.005647830925 53.6320011640866)

ドイツ

ノルダーシュテット

17.0

337534.653466062

テキサス

ベルリン・テーゲル国際空港

ポイント (13.2903090925074 52.5544287044101)

ドイツ

ホーエン・ノイエンドルフ

38.0

483713.15032266214

OSL

オスロ・ガーデモエン

ポイント (11.0991032762581 60.1935783171386)

ノルウェー

オスロ

208.0

522538.03148094116

BMA

ブロンマ

ポイント (17.9456175406145 59.3555902065112)

スウェーデン

ストックホルム

15.0

522538.03148094116

アーン

アーランダ

ポイント (17.9307299016916 59.6511203397372)

スウェーデン

ストックホルム

38.0

624274.8274399083

ダス

デュッセルドルフ国際空港

ポイント (6.76494446612174 51.2781820420774)

ドイツ

デュッセルドルフ

45.0

633388.6966435644

PRG

ルジン

ポイント (14.2674849854076 50.1076511703671)

チェコ

プラハ

381.0

635911.1873311149

アムス

スキポール

ポイント (4.76437693232812 52.3089323889822)

オランダ

ホーフトドルプ

-3.0

670864.137958866

フランス

フランクフルト国際空港

ポイント (8.57182286907608 50.0506770895207)

ドイツ

フランクフルト

111.0

683239.2529970079

ワウ

オケシー国際空港

ポイント (20.9727263383587 52.171026749259)

ポーランド

ピアセチュノ

111.0

Kibana Maps で地理空間データを視覚化する

Kibana Maps は、地理空間データを視覚化するための強力なツールです。これを使用すると、各レイヤーが異なるデータセットを表す複数のレイヤーを持つマップを作成できます。データはさまざまな方法でフィルタリング、集計、スタイル設定できます。このセクションでは、前のセクションでインポートしたデータを使用して、Kibana Maps でマップを作成する方法を説明します。

Kibana メニューで、 Analytics -> Mapsに移動して新しいマップビューを開きます。Add LayerをクリックしてDocumentsを選択し、データビューairportsを選択して、レイヤースタイルを編集し、 elevationフィールドを使用してマーカーに色を付けます。これにより、各空港の高さが簡単にわかります。

マップを保存するには、「変更を保持」をクリックします。

次に、 airport_city_boundariesデータビューを選択して、2 番目のレイヤーを追加します。今回は、 city_boundaryフィールドを使用してレイヤーのスタイルを設定し、塗りつぶしの色を薄い青に設定します。これにより、地図上に都市の境界が表示されます。空港マーカーが最上部になるようにレイヤーの順序を変更してください。

空間結合

ES|QL はJOINコマンドをサポートしていませんが、 ENRICHコマンドを使用して特殊な結合を実現できます。このコマンドは SQL の「左結合」に似た動作をし、2 つのデータセット間の空間関係に基づいて、1 つのインデックスの結果を別のインデックスのデータで強化することができます。

たとえば、空港の場所を含む都市の境界を見つけることで、空港のテーブルからの結果に、空港がサービスを提供する都市に関する追加情報を付加し、結果に対していくつかの統計を実行してみましょう。

FROM airports | ENRICH city_boundaries ON city_location WITH airport, region, city_boundary | STATS centroid = ST_CENTROID_AGG(location), count = COUNT(city_location) BY region | SORT count DESC | LIMIT 10

最初にエンリッチインデックスを準備せずにこのクエリを実行すると、次のようなエラーメッセージが表示されます。

cannot find enrich policy [city_boundaries]

これは、前述したように、ES|QL が真のJOINコマンドをサポートしていないためです。その重要な理由の 1 つは、Elasticsearch が分散システムであり、結合はスケーリングが難しい高コストの操作であることです。ただし、 ENRICHコマンドは、クラスター全体に複製された特別に準備されたエンリッチインデックスを利用し、各ノードでローカル結合を実行できるため、非常に効率的です。

これをよりよく理解するために、上記のクエリのENRICHコマンドに注目してみましょう。

FROM airports | ENRICH city_boundaries ON city_location WITH airport, region, city_boundary

このコマンドは、Elasticsearch に、 airportsインデックスから取得された結果を強化し、元のインデックスのcity_locationフィールドと、前のいくつかの例で使用したairport_city_boundariesインデックスのcity_boundaryフィールドの間でintersects結合を実行するように指示します。しかし、この情報の一部はこのクエリでは明確に表示されません。表示されるのはエンリッチポリシーの名前city_boundariesであり、不足している情報はそのポリシー定義内にカプセル化されています。

{ "geo_match": { "indices": "airport_city_boundaries", "match_field": "city_boundary", "enrich_fields": ["city", "airport", "region", "city_boundary"] } }

Elasticsearch のエンリッチインデックスとポリシーは、もともと、別の準備されたエンリッチインデックスのデータを使用して、インデックス作成時にデータをエンリッチするために設計されました。ただし、ES|QL では、 ENRICHコマンドはクエリ時に機能し、取り込みパイプラインを使用する必要はありません。これは実質的に SQL LEFT JOINと非常に似ていますが、2 つのインデックスを結合することはできず、左側の通常のインデックスと、右側の特別に準備されたエンリッチインデックスのみを結合できます。

どちらの場合でも、取り込みパイプライン用でも ES|QL で使用する場合でも、エンリッチインデックスとポリシーを設定するためにいくつかの準備手順を実行する必要があります。上記ですでにairport_city_boundariesインデックスをインポートしましたが、これをENRICHコマンドのエンリッチインデックスとして直接使用することはできません。まず、次の 2 つの手順を実行する必要があります。

上記のエンリッチポリシーを作成して、ソースインデックス、照合するソースインデックス内のフィールド、一致した場合に返されるフィールドを定義します。
このポリシーを実行して、エンリッチインデックスを作成します。これにより、元のソースインデックスをより効率的なデータ構造に読み取り、クラスター全体にコピーすることで、特別な内部インデックスが構築されます。

エンリッチポリシーは、次のコマンドを使用して作成できます。

PUT /_enrich/policy/city_boundaries { "match": { "indices": "airport_city_boundaries", "match_field": "city_boundary", "enrich_fields": ["city", "airport", "region", "city_boundary"] } }

そして、次のコマンドを使用してポリシーを実行できます。

POST /_enrich/policy/city_boundaries/_execute

airport_city_boundariesインデックスの内容を変更した場合は、エンリッチインデックスに反映された変更を確認するためにこのポリシーを再実行する必要があることに注意してください。ここで、元の ES|QL クエリをもう一度実行してみましょう。

これは、空港が最も多い上位 5 つの地域と、一致する地域を持つすべての空港の重心、およびそれらの地域内の都市境界の WKT 表現の長さの範囲を返します。

重心

カウント

地域

ポイント (-12.13908685930073331.024386116624648)

126

ヌル

ポイント (-83.1039831787347842.300230911932886)

デトロイト

ポイント (39.74537850357592 47.21613017376512)

городской округ Батайск

ポイント (-156.8098678719252320.476673701778054)

ハワイ

ポイント (-73.9451533276587740.70366442203522）

ニューヨーク市

ポイント (-83.1039831787347842.300230911932886)

デトロイト

ポイント (-76.6687301918864324.306286952923983)

ニュープロビデンス

ポイント (-3.0252167768776417 51.39245774131268)

カーディフ

ポイント (-115.4099348466843432.73126147687435）

メヒカリ市

ポイント (41.790108773857355 50.302146775648)

Центральный район

ポイント (-73.8890273217111845.57078813901171)

モントリオール

また、最も頻繁に見つかった地域はnullであったことにも気付くでしょう。これは何を意味するのでしょうか?このコマンドを SQL の「左結合」に例えたことを思い出してください。つまり、空港に一致する都市境界が見つからない場合でも、その空港は返されますが、 airport_city_boundariesインデックスのフィールドにはnull値が含まれます。一致するcity_boundaryが見つからなかった空港が 125 か所あり、 regionフィールドがnullである一致する空港が 1 か所あることがわかりました。これにより、結果にregionが含まれない空港が 126 件見つかりました。ユースケースですべての空港を都市の境界に一致させる必要がある場合は、ギャップを埋めるために追加のデータを入手する必要があります。次の 2 つの点を決定する必要があります。

airport_city_boundariesインデックス内のどのレコードにcity_boundaryフィールドがありませんか
airportsインデックス内のどのレコードがENRICHコマンドを使用しても一致しないか (つまり、交差しない）

Kibana Maps の地理空間データに ES|QL を使用する

Kibana は、マップアプリケーションに Spatial ES|QL のサポートを追加しました。つまり、ES|QL を使用して Elasticsearch で地理空間データを検索し、その結果をマップ上に視覚化できるようになりました。

レイヤー追加メニューに、「ES|QL」という新しいレイヤーオプションがあります。これまで説明したすべての地理空間機能と同様に、これは「技術プレビュー」段階です。このオプションを選択すると、ES|QL クエリの結果に基づいてマップにレイヤーを追加できます。たとえば、世界中のすべての空港を表示するレイヤーをマップに追加できます。

または、 airport_city_boundariesインデックスからポリゴンを表示するレイヤーを追加することもできます。さらに良い方法として、各地域に空港がいくつあるかという統計を生成する、上記の複雑なENRICHクエリはどうでしょうか。

新しいエクスペリエンス

前回の地理空間検索ブログでは、Elasticsearch 8.14 以降で利用可能なST_INTERSECTSなどの関数を使用して検索を実行することに焦点を当てました。このブログでは、これらの検索に使用したデータをインポートする方法を説明します。ただし、Elasticsearch 8.15 には特に興味深い関数ST_DISTANCEが搭載されており、これを使用して効率的な空間距離検索を実行できます。これが次のブログのトピックになります。

ES|QL を使用した Elasticsearch 地理空間検索

Craig Taverner — Mon, 12 Aug 2024 00:00:00 GMT

Elasticsearch は長年にわたって強力な地理空間検索および分析機能を提供してきましたが、その API は一般的な GIS ユーザーが使い慣れたものとはまったく異なっていました。過去 1 年間で、SQL と同じくらい、あるいは SQL よりも簡単なパイプクエリ言語である ES|QL クエリ言語を追加しました。これは、Elastic が得意とする検索、セキュリティ、可観測性のユースケースに特に適しています。また、ES|QL 内での地理空間検索と分析のサポートも追加されており、特に SQL またはGISコミュニティ出身のユーザーにとって、はるかに使いやすくなります。

Elasticsearch 8.12 および 8.13 では、ES|QL に地理空間タイプの基本サポートが導入されました。これは、8.14 で地理空間検索機能が追加されたことにより大幅に強化されました。さらに重要なことは、このサポートは、PostGIS などの他の空間データベースで使用されている Open Geospatial Consortium (OGC) の Simple Feature Access 標準に厳密に準拠するように設計されているため、これらの標準に精通している GIS 専門家にとって非常に使いやすくなっていることです。

このブログでは、ES|QL を使用して地理空間検索を実行する方法と、それを SQL およびクエリ DSL と同等の機能と比較する方法を紹介します。また、ES|QL を使用して空間結合を実行する方法と、結果を Kibana Maps で視覚化する方法も紹介します。ここで説明する機能はすべて「テクニカルプレビュー」段階であるため、改善方法について皆様からのフィードバックをお待ちしています。

地理空間データの検索

クエリの例から始めましょう:

FROM airport_city_boundaries | WHERE ST_INTERSECTS( city_boundary, "POLYGON((109.4 18.1, 109.6 18.1, 109.6 18.3, 109.4 18.3, 109.4 18.1))"::geo_shape ) | KEEP abbrev, airport, region, city, city_location

これは、三亜鳳凰国際空港 (SYX) の周囲の長方形の検索ポリゴンと交差する都市境界ポリゴンの検索を実行します。

空港、都市、都市境界のサンプルデータセットでは、この検索により交差するポリゴンが検索され、一致するドキュメントから必要なフィールドが返されます。

略語

空港

地域

市

都市の場所

シックス

三亜フェニックス国際空港

天外区

三亜

点(109.5036 18.2533)

簡単でした！次に、同じクエリの従来の Elasticsearch クエリ DSL と比較してみましょう。

GET /airport_city_boundaries/_search { "_source": ["abbrev", "airport", "region", "city", "city_location"], "query": { "geo_shape": { "city_boundary": { "shape": { "type": "polygon", "coordinates" : [[ [109.4, 18.1], [109.6, 18.1], [109.6, 18.3], [109.4, 18.3], [109.4, 18.1] ]] } } } } }

どちらのクエリも意図はかなり明確ですが、ES|QL クエリは SQL によく似ています。PostGIS での同じクエリは次のようになります。

SELECT abbrev, airport, region, city, city_location FROM airport_city_boundaries WHERE ST_INTERSECTS( city_boundary, 'SRID=4326;POLYGON((109.4 18.1, 109.6 18.1, 109.6 18.3, 109.4 18.3, 109.4 18.1))'::geometry );

ES|QL の例を振り返ってみましょう。とても似ていますよね？

Elasticsearch API の既存のユーザーにとって、ES|QL の方がはるかに使いやすいことがわかりました。既存の SQL ユーザー、特に Spatial SQL ユーザーにとって、ES|QL は使い慣れたものと非常によく似ていると感じられるものと期待しています。

なぜSQLではないのですか?

Elasticsearch SQL についてはどうですか?しばらく前から存在しており、いくつかの地理空間機能を備えています。ただし、Elasticsearch SQL は元のクエリ API の上にラッパーとして記述されたため、元の API にトランスパイルできるクエリのみがサポートされていました。ES|QL にはこの制限はありません。完全に新しいスタックであるため、SQL では不可能だった多くの最適化が可能になります。私たちのベンチマークでは、ES|QL は、特に集計において、クエリ API よりも非常に高速であることが示されています。

SQLとの違い

前の例から、ES|QL は SQL と多少似ていることは明らかですが、いくつか重要な違いもあります。たとえば、ES|QL はパイプクエリ言語であり、FROM などのソースコマンドで開始し、後続のすべてのコマンドをパイプ | 文字で連結します。これにより、各コマンドがデータテーブルを受け取って、そのテーブルに対して何らかのアクション ( WHEREによるフィルタリング、 EVALによる列の追加、 STATSによる集計の実行など) を実行する方法が非常に簡単に理解できるようになります。最終的な出力列を定義するためにSELECTから始めるのではなく、1 つ以上のKEEPコマンドがあり、最後のコマンドで最終的な出力結果を指定できます。この構造により、クエリに関する推論が簡素化されます。

上記の例のWHEREコマンドに注目すると、PostGIS の例と非常によく似ていることがわかります。

ES|QL

WHERE ST_INTERSECTS( city_boundary, "POLYGON((109.4 18.1, 109.6 18.1, 109.6 18.3, 109.4 18.3, 109.4 18.1))"::geo_shape )

ポストGIS

WHERE ST_INTERSECTS( city_boundary, 'SRID=4326;POLYGON((109.4 18.1, 109.6 18.1, 109.6 18.3, 109.4 18.3, 109.4 18.1))'::geometry )

文字列引用文字の違いは別として、最も大きな違いは、文字列を空間型に型キャストする方法にあります。PostGIS では::geometryサフィックスを使用し、ES|QL では::geo_shapeサフィックスを使用します。これは、ES|QL が Elasticsearch 内で実行され、型キャスト演算子::を使用して文字列をサポートされているいずれかの ES|QL 型(この場合はgeo_shape ) に変換できるためです。さらに、Elasticsearch のgeo_shapeおよびgeo_pointタイプは、WGS84 と呼ばれる空間座標系を意味し、通常は SRID 番号 4326 を使用して参照されます。PostGIS ではこれを明示的にする必要があるため、WKT 文字列にSRID=4326;プレフィックスを使用します。そのプレフィックスが削除されると、SRID は 0 に設定され、特定の座標系に関連付けられていない Elasticsearch タイプcartesian_pointおよびcartesian_shapeに似たものになります。

ES|QL と PostGIS はどちらも型変換関数の構文も提供しています。

ES|QL

WHERE ST_INTERSECTS( city_boundary, TO_GEOSHAPE("POLYGON((109.4 18.1, 109.6 18.1, 109.6 18.3, 109.4 18.3, 109.4 18.1))") )

ポストGIS

WHERE ST_INTERSECTS( city_boundary, ST_SetSRID( ST_GeomFromText('POLYGON((109.4 18.1, 109.6 18.1, 109.6 18.3, 109.4 18.3, 109.4 18.1))'), 4326 ) )

OGC関数

Elasticsearch 8.14 では、次の 4 つの OGC 空間検索関数が導入されています。

ES|QL

ポストGIS

説明

ST_INTERSECTS

ST_交差

2 つのジオメトリが交差する場合は true を返し、そうでない場合は false を返します。

ST_DISJOINT

ST_分離

2 つのジオメトリが交差しない場合は true を返し、そうでない場合は false を返します。ST_INTERSECTS の逆。

ST_CONTAINS

ST_Contains

1 つのジオメトリに別のジオメトリが含まれている場合は true を返し、含まれていない場合は false を返します。

ST_WITHIN

ST_以内

1 つのジオメトリが別のジオメトリ内にある場合は true を返し、そうでない場合は false を返します。ST_CONTAINS の逆。

これらの関数は PostGIS の対応する関数と同様に動作し、同じように使用されます。たとえば、 ST_INTERSECTS 2 つのジオメトリが交差する場合は true を返し、そうでない場合は false を返します。上記の表のドキュメントリンクに従うと、すべての ES|QL の例がFROM句の後のWHERE句内にあるのに対し、すべての PostGIS の例はリテラルジオメトリを使用していることに気付くでしょう。実際、どちらのプラットフォームでも、意味のあるクエリのどの部分でも関数の使用がサポートされています。

ST_INTERSECTSの PostGIS ドキュメントの最初の例は次のとおりです。

SELECT ST_Intersects( 'POINT(0 0)'::geometry, 'LINESTRING ( 2 0, 0 2 )'::geometry );

ES|QL でこれに相当するものは次のとおりです。

ROW ST_INTERSECTS( "POINT(0 0)"::geo_point, "LINESTRING ( 2 0, 0 2 )"::geo_shape )

PostGIS の例では SRID を指定していないことに注意してください。これは、PostGIS でgeometryタイプを使用する場合、すべての計算が平面座標系で実行されるため、両方のジオメトリが同じ SRID を持つ場合、SRID が何であるかは問題にならないためです。Elasticsearch でも、これはほとんどの関数に当てはまりますが、 geo_shapeとgeo_point球面計算が使用されるという例外があります。これについては、空間距離検索に関する次のブログで説明します。

ES|QLの汎用性

上記では、 WHERE句とROWコマンドで空間関数を使用する例を見てきました。他にどこで意味を成すのでしょうか?非常に便利な場所の 1 つは、 EVALコマンドです。このコマンドを使用すると、式を評価して結果を返すことができます。たとえば、国名ごとにグループ化されたすべての空港の重心が、国の境界内にあるかどうかを判断します。

FROM airports | EVAL in_uk = ST_INTERSECTS(location, TO_GEOSHAPE("POLYGON((1.2305 60.8449, -1.582 61.6899, -10.7227 58.4017, -7.1191 55.3291, -7.9102 54.2139, -5.4492 54.0078, -5.2734 52.3756, -7.8223 49.6676, -5.0977 49.2678, 0.9668 50.5134, 2.5488 52.1065, 2.6367 54.0078, -0.9668 56.4625, 1.2305 60.8449))")) | EVAL in_iceland = ST_INTERSECTS(location, TO_GEOSHAPE("POLYGON ((-25.4883 65.5312, -23.4668 66.7746, -18.4131 67.4749, -13.0957 66.2669, -12.3926 64.4159, -20.1270 62.7346, -24.7852 63.3718, -25.4883 65.5312))")) | EVAL within_uk = ST_WITHIN(location, TO_GEOSHAPE("POLYGON((1.2305 60.8449, -1.582 61.6899, -10.7227 58.4017, -7.1191 55.3291, -7.9102 54.2139, -5.4492 54.0078, -5.2734 52.3756, -7.8223 49.6676, -5.0977 49.2678, 0.9668 50.5134, 2.5488 52.1065, 2.6367 54.0078, -0.9668 56.4625, 1.2305 60.8449))")) | EVAL within_iceland = ST_WITHIN(location, TO_GEOSHAPE("POLYGON ((-25.4883 65.5312, -23.4668 66.7746, -18.4131 67.4749, -13.0957 66.2669, -12.3926 64.4159, -20.1270 62.7346, -24.7852 63.3718, -25.4883 65.5312))")) | STATS centroid = ST_CENTROID_AGG(location), count=COUNT() BY in_uk, in_iceland, within_uk, within_iceland | SORT count ASC

結果は予想通りで、英国の空港の重心は英国の境界内にあり、アイスランドの境界内にはなく、その逆も同様です。

重心

カウント

英国

アイスランド

英国内

アイスランド内

ポイント (-21.94663446396589364.13187285885215)

間違い

true

間違い

true

ポイント (-2.597342072712148 54.33551226578214)

true

間違い

true

間違い

ポイント (0.04453958108176276 23.74658354606057)

873

間違い

実際、これらの関数は、そのシグネチャが意味を成すクエリのどの部分でも使用できます。これらはすべて、リテラル空間オブジェクトまたは空間型のフィールドのいずれかである 2 つの引数を取り、ブール値を返します。重要な考慮事項の 1 つは、ジオメトリの座標参照システム (CRS) が一致している必要があることです。一致していない場合はエラーが返されます。つまり、同じ関数呼び出しでgeo_shape型とcartesian_shape型を混在させることはできません。ただし、 geo_pointタイプはgeo_shapeタイプの特殊なケースであり、両方とも同じ座標参照系を共有しているため、 geo_pointタイプとgeo_shapeタイプを混在させることができます。上記で定義された各関数のドキュメントには、サポートされている型の組み合わせがリストされています。

さらに、どちらの引数も、空間リテラルまたはフィールドを任意の順序で指定できます。2 つのフィールド、2 つのリテラル、フィールドとリテラル、またはリテラルとフィールドを指定することもできます。唯一の要件は、タイプに互換性があることです。たとえば、次のクエリは同じインデックス内の 2 つのフィールドを比較します。

このクエリは基本的に、都市の場所が都市の境界内にあるかどうかを尋ねます。これは通常当てはまるはずですが、常に例外があります。

基数

カウント

市内

少し

間違い

多くの

740

true

さらに興味深い質問は、空港の場所が、その空港がサービスを提供する都市の境界内にあるかどうかです。ただし、空港の位置は、都市の境界を含むインデックスとは異なるインデックスに存在します。これには、これら 2 つの個別のインデックスからデータを効果的にクエリして相関させる方法が必要です。

空間結合

ES|QL はJOINコマンドをサポートしていませんが、SQL の「左結合」と同様に動作するENRICHコマンドを使用して、特殊な結合を実現できます。このコマンドは SQL の「左結合」に似た動作をし、2 つのデータセット間の空間関係に基づいて、1 つのインデックスの結果を別のインデックスのデータで強化することができます。

FROM airports | ENRICH city_boundaries ON city_location WITH airport, region, city_boundary | MV_EXPAND city_boundary | EVAL boundary_wkt_length = LENGTH(TO_STRING(city_boundary)) | STATS centroid = ST_CENTROID_AGG(location), count = COUNT(city_location), min_wkt = MIN(boundary_wkt_length), max_wkt = MAX(boundary_wkt_length) BY region | SORT count DESC | LIMIT 5

重心

カウント

最小wkt

最大wkt

地域

ポイント (-32.5609347096071932.598117914802714)

207

ヌル

ポイント (-73.9451533276587740.70366442203522）

438

ニューヨーク市

ポイント (-83.1039831787347842.300230911932886)

473

デトロイト

ポイント (-156.302024586126220.176383580081165)

307

803

ハワイ

ポイント (-73.8890273217111845.57078813901171)

837

モントリオール

それで、ここで実際に何が起こったのでしょうか?JOINはどこで発生したのでしょうか?クエリの核心はENRICHコマンドにあります。

FROM airports | ENRICH city_boundaries ON city_location WITH airport, region, city_boundary

{ "geo_match": { "indices": "airport_city_boundaries", "match_field": "city_boundary", "enrich_fields": ["city", "airport", "region", "city_boundary"] } }

ここでは、 geo_matchクエリ ( intersectsがデフォルト) が実行され、照合するフィールドがcity_boundaryであり、 enrich_fieldsが元のドキュメントに追加するフィールドであることがわかります。これらのフィールドの 1 つであるregionは、実際にはSTATSコマンドのグループ化キーとして使用されていましたが、これはこの「左結合」機能がなければ実行できませんでした。エンリッチポリシーの詳細については、エンリッチのドキュメントを参照してください。これらのドキュメントを読んでいくと、取り込みパイプラインを構成することによって、インデックス作成時にデータを拡充するための拡充インデックスの使用について説明されていることに気付くでしょう。ES|QL では、 ENRICHコマンドがクエリ時に機能するため、これは必要ありません。必要なデータとエンリッチポリシーを使用してエンリッチインデックスを準備し、ES|QL クエリでENRICHコマンドを使用するだけで十分です。

また、最も頻繁に見つかった地域はnullであったことにも気付くでしょう。これは何を意味するのでしょうか?このコマンドを SQL の「左結合」に例えたことを思い出してください。つまり、空港に一致する都市境界が見つからない場合でも、その空港は返されますが、 airport_city_boundariesインデックスのフィールドにはnull値が含まれます。一致するcity_boundaryが見つからなかった空港が 89 か所あり、 regionフィールドがnullである一致する空港が 1 か所あることがわかりました。これにより、結果にregionが含まれない空港が 90 件見つかりました。もう 1 つの興味深い点は、 MV_EXPANDコマンドの必要性です。これが必要なのは、 ENRICHコマンドが入力行ごとに複数の結果を返す場合があり、 MV_EXPANDこれらの結果を結果ごとに 1 つずつ複数の行に分割するのに役立つためです。これにより、「ハワイ」が異なるmin_wktとmax_wkt結果を表示する理由も明らかになります。同じ名前でありながら境界が異なる複数の地域が存在したためです。

Kibanaマップ

新しいエクスペリエンス

上記の 2 つの例では、さらに別の空間関数ST_CENTROID_AGGが組み込まれていることに気付いたかもしれません。これは、 STATSコマンドで使用される集計関数であり、ES|QL に追加する予定の多くの空間分析機能の最初のものです。もっと詳しく紹介できるようになったら、ブログで紹介します!

その前に、私たちが取り組んできた特に興味深い機能、つまり Elasticsearch で最もよく使用される空間検索機能の 1 つである空間距離検索を実行する機能について詳しく説明したいと思います。距離検索の構文がどのようになるか想像できますか?おそらく OGC 関数に似ていますか?詳細については、このシリーズの次のブログをお読みください。

ネタバレ注意: Elasticsearch 8.15 がリリースされました。ES|QL による空間距離検索が含まれています。

ES|QLからPHPオブジェクトへ

Enrico Zimuel — Mon, 08 Apr 2024 00:00:00 GMT

elasticsearch-php v8.13.0以降では、 ES|QLクエリを実行し、結果をstdClassの PHP オブジェクトまたはカスタムクラスにマップできます。

ES|QL

ES|QLは、Elasticsearch 8.11.0 で導入された新しい Elasticsearch クエリ言語です。現在、テクニカルプレビューで利用可能です。Elasticsearch に保存されているデータをフィルタリング、変換、分析するための強力な方法を提供します。

「パイプ」（ | ）を使用して、データを段階的に操作および変換します。このアプローチにより、ユーザーは一連の操作を構成でき、1 つの操作の出力が次の操作の入力となり、複雑なデータ変換と分析が可能になります。

たとえば、次のクエリは、 sample_dataインデックスの最初の 3 つのドキュメント (行) を返します。

FROM sample_data | LIMIT 3

ユースケース: 公式 PHP クライアントの ES|QL 機能

公式 PHP クライアントで開発された ES|QL 機能を説明するために、次の情報を含む 81,828 冊の書籍 (54.4 MB) のCSV ファイルをElasticsearch に保存しました。

Title;Descrition;Author;Year;Publisher;Ratings

このリストは、公開されているAmazon Books Reviews データセットから抽出しました。

次の Elasticsearch マッピングを使用してbooksインデックスを作成しました:

'mappings' : { 'properties': { 'title': { 'type': 'text' }, 'description': { 'type': 'text' }, 'author': { 'type': 'text' }, 'year': { 'type': 'short' }, 'publisher': { 'type': 'keyword' }, 'rating': { 'type': 'half_float' } } }

rating値は、2.9 GB のBooks_rating.csvファイルから取得されたランキングレビューの平均です。

ここでは、 Elasticsearch にすべての書籍を一括インポートするために使用した PHP スクリプトを見つけることができます。一括操作には PHP 8.2.17 を使用して 7 秒と 28 MB の RAM が必要でした。提案されたマッピングでは、Elasticsearch のインデックスサイズは約 62 MB になります。

ES|QL の結果を PHP オブジェクトまたはカスタムクラスにマッピングする

esql()->query()エンドポイントを使用して、PHP で ES|QL クエリを実行できます。このクエリの結果はテーブルデータ構造になります。これは、 columnsフィールドとvaluesフィールドを使用して JSON で表現されます。columnsフィールドにはnameとtype定義があります。

以下は、ユーザーのランキングレビュー順に並べられた、Stephen King が書いたトップ 10 の本を取得する ES|QL クエリの例です。

$query = <<esql()->query([ 'body' => ['query' => $query] ]);

Elasticsearch からの JSON 結果は次のようになります。

{ "columns": [ { "name": "author", "type": "text" }, { "name": "description", "type": "text" }, { "name": "publisher", "type": "keyword" }, { "name": "rating", "type": "double" }, { "name": "title", "type": "text" }, { "name": "year", "type": "integer" } ], "values": [ [ "Stephen King", "The author ...", "Turtleback", 5.0, "How writers write", 2002 ], [ "Stephen King", "In Blockade Billy, a retired coach...", "Simon and Schuster", 5.0, "Blockade", 2010 ], [ "Stephen King", "A chilling collection of twenty horror stories.", "Signet Book", 4.55859375, "Night Shift (Signet)", 1979 ], ... ] }

この例では、書籍に関連する 6 つのプロパティ (著者、説明、出版社、評価、タイトル、年) と 10 件の結果 (すべて Stephen King の書籍) があります。

ES|QL でサポートされているすべてのタイプのリストはここに記載されています。

$result応答オブジェクトには、配列、文字列、またはオブジェクトとしてアクセスできます (詳細については、ここを参照してください)。

オブジェクトインターフェイスを使用すると、プロパティとインデックスを使用して値にアクセスできます。たとえば、 $result->values[0][4]リストの最初の本 (0) のタイトル (4) を返し、 $result->values[1][3] 2 番目の本 (1) のランクスコア (3) を返します。PHP の配列のインデックスは 0 から始まることに注意してください。

このインターフェースは、いくつかのユースケースでは十分ですが、ほとんどの場合、結果としてオブジェクトの配列を取得したいと考えます。

結果をオブジェクトの配列にマップするには、elasticsearch-php の新しいmapTo()機能を使用できます。

この関数は、 Elasticsearch レスポンスオブジェクトで直接使用できます。つまり、次のようにアクセスできます。

$books = $result->mapTo(); // Array of stdClass foreach ($books as $book) { printf( "%s, %s, %d, Rating: %.2f\n", $book->author, $book->title, $book->year, $book->rating ); }

カスタム Book クラスがある場合は、次のようにそれを使用して結果をマップできます。

class Book { public string $author; public string $title; public string $description; public int $year; public float $rating; } $books = $result->mapTo(Book::class); // Array of Book

クラスに ES|QL 結果に含まれるプロパティに加えて他のプロパティがある場合も、これは同様に機能します。mapTo()関数は、ES|QL 結果の列として返されるプロパティのみを使用します。

この記事で報告されているすべての例は、ここからダウンロードできます。