Kibana Dashboards APIにおける後方互換性の意味

テクニカルプレビュー中はリリース間でAPIの仕様が変更される可能性があります。[1]現在はこれは該当しません。一般提供（GA）開始とは、以下のことを意味します。

• 完全な後方互換性。新しいフィールドやパネルの種類は今後追加されますが、既存のフィールドや動作は変更されません。今後、互換性を損なうような変更を行う場合は、非常に慎重に検討し、新しいメジャーバージョンでのみ導入します。

• 本番環境での利用に対応し、完全にサポートさ。このAPIには、Elasticの完全なサポート保証が付いています。本番環境では、自動化された導入、環境の昇格、およびプログラムによるダッシュボード管理に安全にご利用いただけます。

タグ、マークダウン、リンクパネル用の新しいKibana APIエンドポイント

Elastic 9.5では、タグ用の新しいスタンドアロンエンドポイントも導入され、ダッシュボードの分類やフィルタリングが可能になりました。専用のCRUDエンドポイントによりプログラムによる管理が可能になり、複数の環境にわたって大規模にダッシュボードを整理しやすくなりました。

新しいマークダウンおよびリンクパネルエンドポイントは現在Serverlessで利用可能で、次回のスタックリリース（9.6）に搭載される予定です。

Kibana Dashboards APIはどのようなパネル型をサポートしていますか？

Dashboards APIは、9.5のすべての値渡しパネル（再利用のために保存されたライブラリパネルとは対照的に、ダッシュボードで直接定義されたもの）をサポートしています。サポートされているすべてのパネル型には、型指定され検証済みのスキーマがあります。

パネル型

ステータス

XYチャート

サポートあり

メトリクス

サポートあり

円グラフ

サポートあり

ゲージ

サポートあり

ヒートマップ

サポートあり

データ表

サポートあり

ツリーマップ

サポートあり

Discoverセッション

サポートあり

コントロール

サポートあり

マークダウン

サポートあり

リンク

サポートあり

MLパネル

サポートあり

オブザーバビリティパネル

サポートあり

マップ

まもなくリリース

Vega

まもなくリリース

Kibanaのダッシュボードをコードとして管理する方法

Dashboards APIを使用すると、完全なダッシュボード・アズ・コードのワークフローが実現できます。ダッシュボードをクリーンで差分比較可能なJSONとしてエクスポートし、それをGitにコミットして真の情報源とし、プルリクエストで変更内容を確認し、開発環境、ステージング環境、本番環境に同じ定義をデプロイできます。ダッシュボードをコードとして管理するようになったら、Gitを唯一の信頼できる情報源として扱います。UIで直接行った変更は、次回デプロイ時に上書きされます。

ダッシュボードをスペース、クラスター、またはステージ間で移動する際の主な課題は、ダッシュボードがデータビューやライブラリの視覚化などのオブジェクトをIDで参照することです。これらのIDは自動生成され、環境ごとに異なるため、ある環境からエクスポートされたダッシュボードが、別の環境には存在しないオブジェクトを指し示すことがあります。この問題を解決するには3つの方法があり、自動化の度合いが高い順に以下に示します。

• Terraformを使用する。Elastic Stack Terraformプロバイダーは各リソースを追跡し、環境ごとにIDを自動マッピングするため、開発から本番環境へダッシュボードを移行する際に参照が一貫して保たれます。

• 値渡しのElasticsearchクエリ言語（ES|QL）パネルを定義する。パネルを構築する最もポータブルな方法は、ES|QLを使用してダッシュボードで直接可視化を定義することです。ES|QLクエリは、クエリ内で指定したインデックスからデータを読み取るため、パネルにはData viewやライブラリオブジェクトへの外部参照は含まれません。その結果、完全に自己完結型のポータブルダッシュボードとなります。

• 一致するIDを割り当てる。Data viewやライブラリの視覚化など、保存済みのオブジェクトを参照する場合は、POST（IDを自動生成）ではなく、PUT（アップサート）を使用して、選択したIDでオブジェクトを作成してください。「logs-prod」のような人間が読みやすいIDを使うことで、環境を超えて再利用・認識しやすくなります。

これらの移植性パターンとダッシュボード・アズ・コードのワークフロー全体に関する詳細な説明については、「ダッシュボードをコードとして管理する」ドキュメントをご覧ください。

PUTメソッドを使用してDashboards APIでKibanaダッシュボードを作成

ここでは、ダッシュボード名（service-health-overview）を使用してカスタムIDを割り当てるために、POSTではなくPUTを使用してメトリックパネルを含むダッシュボードを作成する簡単な例を示します。ライブラリに保存されたスタンドアロンの可視化を作成する場合も、同じロジックが適用されます。

Kibana Dashboards APIロードマップ：マップ、Vega、スタンドアロンのエンドポイント

APIの展開範囲を積極的に拡大していきます。次に、マップとVegaパネルのサポートを進め、それらに型付きスキーマを追加します。また、ダッシュボードのライフサイクルから切り離したDiscoverセッション（既存のダッシュボードパネルのサポートを超えて）、Vega、マップ、Annotations向けのスタンドアロンCRUDエンドポイントも構築しています。

スキーマ定義の詳細は、Dashboards APIドキュメントをご覧ください。Terraformユーザー向けにはElastic Stack Terraformプロバイダーが一般提供のDashboards APIをサポートしています。

注

1. コアエンドポイントはテクニカルプレビュー版から変更されていません。9.4向けに構築した統合機能は、9.5でも動作します。唯一の破壊的変更は、ダッシュボード一覧と所要時間単位のフォーマットに影響を与える2つの小さな変更で、こちらに記載されています。

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の単独裁量に委ねられます。現時点で提供されていないあらゆる機能ないし性能は、すみやかに提供されない可能性、または一切の提供が行われない可能性があります。

毎年、自然災害によって、緊急事態管理者、軍司令官、公安当局者は、限られた時間の中で重大な決断を迫られることになります。従来、こうした意思決定は、緊急連絡網やスプレッドシート、そして何十人もの人々に分散した組織的知識に依存しています。調整にかかる手間だけでも、貴重な時間が奪われます。

本記事では、脅威を検知し、ロジスティクスを推論して自動的にアクションを実行する災害対応向けの即応性に優れたエージェント型連携システムをElasticがどのように提供できるかをご紹介します。具体例として、シミュレーションを構築しました。ハンプトン・ローズの海岸線を脅かす架空のカテゴリー4のハリケーンによって、7つの軍事施設にわたる137,000人以上の要員の自動再配置がトリガーされるというものです。

免責事項：これはデモンストレーション目的で作成された完全に架空のシナリオです。 ハリケーンELARA-26は実在しません。施設の所在地は、公開されている実際の地理データ（米国国防総省［DoD］のMilitary Installations, Ranges, and Training Areas［MIRTA］データセット）に基づいたものですが、人員数、収容可能人数、資産、連絡先メールアドレス、ミッションプロファイルなどの運用データはすべて完全に架空のものです。このデモに含まれる内容は、実際の軍事的な即応態勢、能力、または運用手順を反映したものではありません。

自動化された災害対応に地理空間とエージェント型の連携が必要な理由

自然災害によって重要なインフラが脅かされると、次のような調整の課題が直ちに発生します。

• 影響ゾーンにある施設はどれですか？

• 何人の人員を移動させる必要があるか？

• どこに行けばいいのか、そしてそれらの施設には収容能力があるか？

• 今すぐ連絡する必要があるのは誰か？

これらの質問は待ってくれません。 その答えも同様です。

パイプラインのデプロイ：要件とセットアップ

サンプルリポジトリのこちらにある手順に従って、Cloud Connectを介してElastic Inference Service（EIS）を使用するローカルElasticクラスターをデプロイします。

Elasticsearchのエージェント型災害対応パイプラインの仕組み

このパイプラインには、エンドツーエンドで連携して機能する7つのレイヤーがあります。

1. データインジェスト：Elasticsearchに送信されたGlobal Disaster Alert and Coordination System（GDACS）の災害イベント。

2. インジェストパイプライン：GeoJSONがインジェストされ、Elastic Common Schema（ECS）に正規化されます。

3. 地理空間エンリッチメント：イベントの影響エリアのポリゴンがインデックス登録された軍事施設の境界と照合されます。

4. アラート：災害がいずれかのインストール環境と交差すると、Kibanaの検出ルールが作動します。

5. ワークフローの自動化：アラートによってKibanaワークフローがトリガーされ、AIエージェントの会話が開始されます。

6. AI推論：エージェントは、影響を受ける施設、その資産、および最寄りの支援施設をもとに推論を行い、すべての資産と人員の再配置を決定します。

7. メール通知：エージェントは、出入りする人員や資産について、すべての受信者にメールを送信します。

各レイヤーを見てみましょう。

ステップ1：地理的境界に基づいて軍事施設をインデックス化

基盤となるのは、source.coop/seerai/hifldのDoD MIRTAデータセットです。このデータセットは、各施設に対してPointタイプのgeo_shapeを提供します。これは完全な境界ポリゴンではなく、重心座標となります。

mitra-facilitiesインデックス内の各インストールドキュメントは、MIRTAが提供する内容に加えて、運用プロファイルデータ（すべて架空のもの）でエンリッチされています。

このリッチなインデックスによって、AIエージェントは単に「近くに基地がある」というだけでなく、「収容能力があり、任務の種類が適合し、到着する資産を受け入れるための物流を備えた基地がある」という、インテリジェントな割り当て決定を下すことが可能になります。

ステップ2：GDACSイベントの取り込みと正規化

GDACSは、地震、熱帯低気圧、洪水、山火事、火山、干ばつに関するリアルタイムのGeoJSONを公開しています。このフィードをデータストリーム（logs-gdacs.events-*）に取り込み、生のGeoJSONをECSフィールドに正規化するカスタム取り込みパイプラインを使用します。

GDACS取り込みパイプラインは、注目すべきいくつかの処理を実行します。

ジオメトリ抽出：重心はマップ表示用にgeo_pointとして格納され、影響ポリゴンはgdacs.affected_areaにgeo_shapeとして格納されます。これは、後で交差クエリに使用されるフィールドです。

重大度の正規化：災害の種類ごとに、重大度のスケールが異なります。熱帯低気圧は風速（km/h）で、地震はリヒター・マグニチュードで測定されます。パイプラインはそれらすべてを正規化された0～100のスコアにマッピングします。

正規化された深刻度スコアはその後、検出ルールのアラート深刻度マッピングで使用されるseverity_levelラベル（low、medium、high、critical）にマッピングされます。

ECSとの整合性：event.kind: alert、event.category: threat、event.start/event.endにマッピングされたタイムスタンプ、重複排除のための安定したフィンガープリントベースの_id。

ステップ3：地理空間エンリッチメント：インデックス作成時に影響を受ける施設を特定する

Elasticsearchのgeo_matchエンリッチポリシーは、インデックス時に災害ポリゴンを各施設の境界と照合するため、クエリ時の結合は不要です。検索時にクエリを実行する代わりに、取り込みパイプラインでエンリッチプロセッサーを使用して、ドキュメントのインデックス時に災害の影響ポリゴンを各施設の境界と照合します。

エンリッチポリシーはgeo_matchポリシーです。

プロセッサーは取り込みパイプラインの最後で実行されます。

INTERSECTSは、境界線が災害ポリゴンに接しているか重複しているすべての施設や、部分的な交差さえも検出します。その結果、すべてのGDACSイベントドキュメントは、どの施設が影響区域内にあるかを正確に示すaffected_facilitiesネスト配列とともに格納されます。結合クエリは不要です。

ステップ4：検出ルール：施設への影響に関するアラート

Kibanaの検出ルールは、logs-gdacs.events-*データストリームを監視し、GDACSイベントが少なくとも1つの影響を受けた施設でエンリッチされたときにトリガーされます。

このルールは1時間ごとのスケジュールで実行され（現在から1時間前までの期間を対象）、動的な重大度マッピングを使用します。取り込みパイプラインによって計算されるgdacs.severity_levelフィールドが、アラートの重大度を自動的に決定します。

アラートの深刻度も、フィールドマッピングを通じてリスクスコアに影響を与えます。

ルールがトリガーされると、設置名、タイプ、場所を含むエンリッチされたaffected_facilities配列を含む完全なアラートコンテキストが、ダウンストリームのKibanaワークフローに渡されます。

ステップ5：ワークフローの自動化：アラートからエージェントへの橋渡し

Kibanaワークフローは、検出から対応への引き継ぎを処理します。自然災害対応ワークフローは、以下のアラートによって開始されます。

アラートのペイロード全体（災害の種類、重大度、被災地域、影響を受けた設備の一覧）が、初期コンテキストとしてAIエージェントに転送されます。そこから先はエージェントが処理を引き継ぎます。

ステップ6：AIエージェント：データから連携したアクションへ

mitra.responseエージェントは、アラートペイロード全体を受け取り、単一のエージェントループで対象範囲を評価し、受け入れ施設を特定し、人員を割り当て、避難通知と受け入れ通知を送信します。これらはすべて、人間の介入なしで行われます。

エージェントには2つのツールが用意されています。

• mitra.nearest_facilityは、geo_shapeクエリを使用してmitra-facilitiesインデックスにクエリを実行し、指定された座標からの距離で並べ替えて、利用可能な収容能力を持つ周辺のアクティブな施設を最大50件返します。

• mitra.send_emailは、施設オブジェクトのJSON配列を反復処理し、フォーマットされた避難通知または受入通知を送信します。

エージェントの指示セットは、明確なワークフローを定義します。

1. 状況を評価する。アラートをパースし、影響を受ける施設を特定して、災害の範囲を判断します。

2. 移行が必要な対象のインベントリを作成する。施設ごとの人員数、重要資産、住宅要件。

3. 再配置先施設を見つける。影響を受ける各施設に対してmitra.nearest_facilityを呼び出し、危険区域内にある施設を除外します。

4. 配分に関する決定を行う。単一施設ソリューションと複数施設ソリューションの比較検討、支店間の互換性、収容能力、資産サポートなどを考慮します。

5. 調整メールを送信する。避難元施設に避難指示を、受入施設に受入通知を送信します。

6. サマリーレポートを作成する。影響を受けるすべての施設、総人員、移動した資産、再配置先施設、懸念事項の簡単なサマリーを作成し、確認のためにチャットに出力します。

エージェントの割り当てロジックは、現実世界の制約に従います。住宅収容能力を超えないこと、可能な場合は同一部隊内での移転を優先すること、複数部隊にまたがる移転の場合は共同拠点を使用すること、そして移動時間を最小限に抑えるために距離を優先することなどが含まれます。

最寄りの施設ツール

基盤となるワークフロークエリでは、circleフィルター付きのgeo_shapeと_geo_distanceソートを使用します。

利用可能な収容人数は、収容可能人数から現在の人員数を差し引くスクリプトフィールドを介して、クエリ実行時に計算されます。エージェントは、上限を超えないように、これを使用してデスティネーション間で人員を割り当てます。

ハリケーンELARA-26：137,000人の人員をエンドツーエンドでエージェント的に調整

ハリケーン「ELARA-26」は、バージニア州のハンプトン・ローズ地域に上陸すると予測されているカテゴリー4の暴風雨（最大風速213 km/h）です。GDACSイベントが取り込まれると、影響を受けるエリアのポリゴンは、この地域にある7つの主要な軍事施設と交差します。検出ルールがトリガーされます。ワークフローによってエージェントの会話が開始されます。

単一のエージェントループ内で、エージェントは以下を行いました。

• 影響エリア内の7つの施設（合計137,372名の人員）を特定しました。

• 嵐の進路外にある受け入れ施設を見つけるために、mitra.nearest_facilityを呼び出しました。

• 利用可能な収容能力と距離に基づいて、9つの受入施設に人員を分散配置しました。

• 影響を受けた7つの施設すべてに避難指示を生成して送信しました。

• 受入通知を作成し、9件の受入施設すべてに送信した。

• 以下のような、調整に関する詳細な概要を作成しました。

避難対象施設：

施設

人件費

ノーフォーク海軍基地

50,000

統合遠征基地リトルクリーク・フォートストーリー

18,000

オシアナ海軍航空基地

15,355

オシアナ海軍航空基地ダムネック別館

17,509

NG州立軍事基地キャンプ・ペンドルトン

9,707

ラングレー・ユースティス統合基地

15,000

ヨークタウン海軍兵器基地

11,801

受入施設：

施設

距離

避難受入人員

フォート・グレッグ・アダムズ

97 km

約40,000

クワンティコ海兵隊基地

148 km

約30,000

インディアン・ヘッド海軍支援施設

151 km

約30,000

アンドルーズ統合基地

180 km

約30,000

パタクセント・リバー海軍航空基地

141 km

約10,000

NG MTA キャンプ・バトナー

174 km

約5,000

NG Bethany Beach トレーニングサイト

209 km

約4,707

リバナステーション

140 km

約7,500

国防総合補給センター

22 km

約6,000

再配置された資産には、輸送車両、ヘリコプター、パトロール艇、医療ユニット、工作車両、発電機、給水トレーラー、シェルターキット、通信システムが含まれます。

自動メール通知

エージェントが割り当て計画を確定すると、mitra.send_emailを呼び出し、1回の処理で16通のメールを送信しました。つまり、影響を受けた7つの施設すべてへの避難指示と、受け入れ先となる9つの施設すべてへの受け入れ通知です。各メッセージには、受入先施設、到着する人員数、移動する資産、調整担当の連絡先が含まれていました。以前であれば電話連絡網に何時間もかかっていた作業が、エージェントによる推論が完了した瞬間に自動的に完了しました。

RAGとポリシーグラウンディングによるエージェント型災害対応の拡張

このデモは、収容能力の数値、距離、稼働状況などの構造化データのみに基づいています。Elasticのセマンティック検索およびRetrieval-Augmented Generation（RAG）機能に2つの要素を追加することで、エージェントを大幅にスマートにすることができます。

過去の対応検索：過去の事後レポート、連邦緊急事態管理庁（FEMA）のインシデント概要、災害対応記録をベクトル埋め込みとしてインデックス化します。新しいイベントが発生すると、エージェントは類似のイベントがどのように対応されたかをセマンティックに検索し、単なるキャパシティの計算だけでなく組織の知識を活用して割り当ての意思決定を行うことができます。

ポリシーとドクトリンの根拠付け：国防総省（DoD）の緊急事態管理指令、施設の業務継続計画（COOP）、司令官のガイダンスをインデックス化します。エージェントは対応を規定する実際のポリシーを取得して引用できるため、すべての決定が推論ではなくドクトリンに基づいていることを保証できます。

どちらも同じElasticネイティブのアプローチに従います。推論パイプラインがインデックス作成時に埋め込みを生成し、セマンティック検索ツールがエージェントに公開されます。 調整パイプラインは同じままです。エージェントはさらに賢くなります。

公共部門のエージェント型対応にElasticsearchが最適なプラットフォームである理由

これはチャットボットではなく、ダッシュボードでもありません。脅威を検知し、複雑なロジスティクス問題を推論して、人間の介在なしに137,000人の移転を調整した、応答性の高いエージェント型ワークフローシステムです。このような成果が可能になるのは、依存するすべての機能が単一の統合プラットフォームに集約されているからです。

Elasticsearchの地理空間サポート（geo_point、geo_shape、エンリッチメントポリシー、距離ベースの並べ替え）は、交差検出や施設検索の大規模な実行を可能にする空間推論を処理します。セマンティック検索とベクトル埋め込みによりエージェントを事実にグラウンディングさせ、AIの推論がハルシネーションによる推測ではなく、データに実際に存在する情報に基づくようにします。Kibanaの検出エンジン、Workflows、Agent Builder、Agent Builderツールにより、外部の連携コードを必要とすることなく、未加工のイベントから連携したアクションへと至るパイプラインとしてこれらすべてが統合されます。

Elasticのようにこれらを統合できるプラットフォームは他にありません。リアルタイムのインデキシング、地理空間の精度、セマンティック検索、エージェンティックオーケストレーションのすべてを1つのスタックに統合し、エンタープライズグレードのセキュリティとオブザーバビリティが組み込まれていることこそが、これらのうち1つには優れていても残りは自分たちでつなぎ合わせる必要があるツールと、Elasticを一線を画す存在にしている理由です。

緊急事態管理、消防、法執行、公衆衛生のためのエージェント型地理空間対応

人、施設、リアルタイムイベントが交差するあらゆる場所に、同じアーキテクチャーが適用されます。特定のデータは変更され、パイプラインは変わりません。

緊急事態管理：FEMAや州の緊急事態管理局は、避難所の位置、集結地域、脆弱な人々を、到来する米国国立気象局（NWS）の悪天候ポリゴンと照らし合わせて地図化し、嵐が上陸する前にリソースの事前配置を自動的に開始できます。

消防・救急医療サービス：消防署は、部隊の位置や対応ゾーンを山火事の境界線や建物火災のクラスターに重ね合わせ、適切な装備を備えた最も近くの対応可能な部隊へ相互応援要請を自動的にルーティングできます。

法執行機関：機関は、進行中のインシデントの位置を学校区域、重要インフラ、警察官の位置と関連付け、手動でのトリアージを待たずに、位置情報を考慮したロックダウン通知やリソースの派遣をトリガーできます。

公立学校の安全対策：学区は、キャンパスの敷地境界に対するリアルタイムの脅威フィードを監視できます。脅威が学校の敷地境界に差し掛かった場合、ディスパッチャーが電話を取る前に、エージェントは直ちに管理者に通知し、ロックダウンの連絡を開始し、法執行機関の対応を調整できます。

公衆衛生：保健機関は、疾病監視データや環境有害区域を診療所の所在地、人口密度レイヤー、供給拠点の在庫と照合し、最も必要とされている場所にリソースを配分できます。

セクター

ユースケース

Elasticの機能

緊急管理

避難所の場所をNWSの悪天候ポリゴンと照合する

geo_shapeエンリッチメント+Kibanaワークフロー

消防およびEMS

山火事の境界線に部隊の位置を重ね合わせる

地理空間ルーティング+最寄り施設クエリ

法執行機関

事件と学校区域および警察官の配置を関連付ける

位置情報に基づくアラートルール + 担当者の派遣

公立学校の安全

キャンパス境界に対する脅威フィードを監視する

検出ルール+自動通知

公衆衛生

危険区域を診療所の場所や物資拠点と照合する

セマンティック検索 + 地理空間エンリッチメント

データはシナリオごとに異なります。取り込み、インデックス作成時のエンリッチメント、交差の検出、自律的な対応のトリガー、そしてアクションという根本的なパターンはすべて同じです。Elasticは、公共機関が一度構築すればどこでも適用できるプラットフォームを提供します。

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

エージェントはダッシュボードをゼロから構築しますが、既存のものも使用できます。ダッシュボードを表示中にAI Chatのサイドバーを開くと、自動的に接続されます。指標が急上昇した理由を尋ねたり、地域別に分析したり、比較パネルを追加したりしてみましょう。既存のダッシュボードが単なる最終成果物ではなく出発点となります。

舞台裏：AI Chatでダッシュボードを構築した方法

私たちは、スキル（与えられた問題に対する操作方法の構造化された記述）を通じて、エージェントに特定のタスクを教えます。しかし、ダッシュボードスキルを構築するには、LLMに有効なKibanaダッシュボードを生成する方法を教える必要がありましたが、従来のSaved Object APIでは、深くネストされたJSON、微妙なバージョン間の変更、脆弱な参照など、多くの問題があり、非常に困難でした。別のアプローチが必要でした。

プログラマティックダッシュボード専用に設計されたAPI

新しいDashboards APIは、まさにこのシナリオのために構築されました。生の内部状態を公開する代わりに、パネルの種類ごとに型付けされ検証済みのスキーマを提供します。APIは、クリーンな外部構造とKibanaの内部表現間の変換を処理するため、エージェントはダッシュボードのフォーマット方法ではなく、ダッシュボードに含めるべき内容に集中できます。

1つのスキル、1つのツール、多数の操作

dashboard-managementスキルは、操作の順序付き配列を受け入れる単一のmanage_dashboardツールを公開します。各操作は個別のアクションです。メタデータの設定、マークダウンパネルの追加、自然言語からのES|QLベースの可視化の作成、既存パネルの編集、パネルの折りたたみ可能なセクションへのグループ化、グリッド上のアイテムの再配置などが可能です。

エージェントは、タイトル、説明、セクション、およびその中のすべてのパネルなど、ダッシュボード全体を1回の呼び出しで説明できます。

操作は順序通りに実行されるため、後のステップは前のステップを参照し、その上に構築できます。この設計により、議論は実装の詳細ではなく、意図に焦点を当てたものとなります。

可視化パイプライン：自然言語からES|QL、そして可視化へ

ダッシュボードを要求すると、エージェントはデータ（インデックス、フィールドマッピング、タイプ）を探索し、可視化を計画し、manage_dashboardを呼び出します。

各パネルは、グラフタイプの選択、ES|QL生成、可視化構成、検証という独自のパイプラインを通過します。これをメインのエージェントスレッドから分離しました。可視化の構築にはパネルごとに複数のモデル呼び出しが必要であり、それをメインのコンテキストに混ぜるとウィンドウが肥大化し、推論が不明瞭になるためです。

manage_dashboardの内部では、すべてのパネルが同時に組み立てられ、順番に組み立て直されます。結果として、埋め込みパネルを備えた完全なダッシュボードが得られます。孤立した可視化も、同期の問題もありません。

ダッシュボードツール内に可視化作成機能を移動した理由

最初のアプローチでは、個別のcreate_visualizationツールを使用しました。パネルごとに1回呼び出しを行い、各添付ファイルをダッシュボードツールに渡しました。うまくいきましたが、各可視化には独自のツール呼び出し、独自のライフサイクル、そして明示的なハンドオフが必要でした。さらに悪いことに、会話内で可視化を編集してもダッシュボードパネルが更新されず、ユーザーを混乱させる結果となりました。

視覚化の作成機能をmanage_dashboardに直接統合しました。同じ並行ワークフローが実行されますが、パネルは中間的な接続を介さずにダッシュボード構造に組み込まれます。呼び出し回数が減り、同期の問題も発生せず、ライフサイクルは1つに統合されます。

スタンドアロンの可視化は引き続き機能します。既存のチャートは添付参照を使ってダッシュボードに追加できますが、新規作成の場合はインライン作成のほうがより適切です。

セキュリティチーム向け

SOCアナリストや検出エンジニアには、調査中にダッシュボードエディターを往復する余裕はありません。AI Chatでは、ルールの種類、ホスト、MITREの戦術別にアラート量を尋ねると、約1分でスレッドに表示されます。ハンティングが進むにつれて、コンテキストを損なうことなく、プロセス実行の異常、ネットワーク接続、タイムラインの比較といったパネルを重ねていくことができます。

作業が終わったら保存します。ダッシュボードは、事後分析の参考資料となり、次のアナリストの出発点となり、週次の脅威ブリーフィングの資料にもなります。再説明は不要です。

セキュリティチームがダッシュボード作成や最近開始されたその他のAI Chat機能をどのように利用できるかについては、こちらのブログ記事をご覧ください。

オブザーバビリティおよびサイト信頼性エンジニア（SRE）向け

午前2時にサービスがダウンした場合、ダッシュボードを一から構築する時間はありません。AI Chatを使用すると、SREは必要なメトリクス（サービスごとのp99レイテンシ、導入イベントに対するエラー率、過去1時間のポッド再起動数）を記述し、約1分で調査スレッドに完全なダッシュボードを取得できます。エージェントは、全体像がはっきりしてくるにつれて、パネルを追加し、時間ウィンドウを変更し、地域ごとに細分化し、段階的に調整できます。

ダッシュボードを保存すると、インシデントブリッジに参加する全員が作戦室ですぐにそのダッシュボードを利用できるようになります（同じパネル、同じフレーム）。事件後、それは事後検証の基礎となります。

次のステップ

トークンの最適化、よりリッチな全画面表示、より幅広いパネルのサポート、そして継続的な品質の向上に取り組んでいます。テクニカルプレビューは、優先順位を決定する絶好の機会です。何か不足している点があれば、上部メニューの「フィードバックを送信」アイコンからお知らせください。

試してみる

Elastic 9.4にアップグレード（またはトライアルを開始）するか、AI Chatを全画面モードで開いて、実際の調査で試してみてください。エージェントに注目している指標のグラフを作成してもらい、その後、次の詳細な内訳を依頼します。ストーリーが成立したら、保存して共有してください。同じパネル、同じ構図で、再説明は不要です。エンタープライズライセンスが必要です（利用開始はこちら）。本記事に記述されているあらゆる機能または性能のリリースおよびタイミングは、Elastic単独の裁量に委ねられます。現時点で提供されていないあらゆる機能または性能は、すみやかに提供されない可能性、または一切の提供が行われない可能性があります。

Kibanaがダッシュボードを読み込む際にデータを取得する方法

ダッシュボードを開くと、ほとんどのパネル（内部的には、これらを埋込と呼びます）が1つ以上のElasticsearchクエリを開始します。しかし、同期検索の単純な呼び出しと応答の代わりに、非同期検索のパワーを使います（ドキュメント）。

非同期検索では、クエリ結果が特定のHTTPリクエスト外でもElasticsearch内で利用可能な状態に保たれます。これが重要な理由を以下に挙げます。

• ネットワークの不安定性に耐性が高く、データの読み込みを安定させます

• バックグラウンド検索機能により、ユーザーは長時間実行されるダッシュボードやDiscoverセッションを待つ間も、Kibanaで他の作業を行うことができます

最初のクエリが送信された後、Kibanaは検索を監視して完了を検出し、結果のセットを取得します。

従来のポーリングがKibanaのダッシュボードのロード時間に与える影響

従来のポーリングでは、Kibanaはクエリを送信し、最初の接続を閉じてから、Elasticsearchの完了を定期的にチェックします。

Elasticsearchは、クエリ送信後に検索を完了して結果を返すまでの短い時間を設けています。もし検索がこれほど速く完了する場合、それは単純な呼び出しと応答のやり取りに相当します。しかし、長時間の検索の場合、最初の接続は切断され、Kibanaは検索の完了を定期的に確認し始めます。これはポーリングと呼ばれます。

従来のポーリングのパフォーマンス上の課題

上の図をご覧いただくと、このアプローチのパフォーマンス上の欠点がお分かりいただけるかもしれません。検索はKibanaのスリープインターバルのいずれかで終了する可能性が最も高く、そのため時間の無駄につながります。

最悪のシナリオ（検索がスリープ期間の始めに完了する場合）では、ポーリングインターバルの全期間が無駄になります。

バックオフ戦略の影響

ポーリング時にはバックオフ戦略を適用するのが標準的な方法です。これは、検索の期間が長くなるほど、ポーリングの頻度が低くなることを意味します。

しかし、これはまた、検索の期間に応じて潜在的な時間損失が比例して増加することを意味します。

ポーリング間隔がノコギリ状のレイテンシパターンを作り出す仕組み

これらの要素を合わせると、失われた時間は段階的なノコギリ状の関数となります。

ここで、ピークは最悪のシナリオ、谷は最良のシナリオを表しています。これは、従来のポーリングコストが、検索期間（およびネットワーク条件）に応じて、ゼロからポーリング間隔の全期間まで変化することを示しています。

継続的なポーリング：Kibanaが待ち時間を排除する仕組み

従来のポーリングの問題は、KibanaとElasticsearchの間にある根本的な連携不足です。理想は、Kibanaが結果が利用可能になったことを即座に認識することです。では、ほぼすべての時間をElasticsearchのチェックに費やし、待機時間をまったく設けないポーリングパターンに逆転させたらどうなるでしょうか？

長時間のポーリングとスリープ期間の廃止を組み合わせることで、結果は準備ができ次第すぐに提供されます。

HTTP/1の陳腐化

その理論は堅実なものです。では、継続的なポーリングをオンにすると、なぜこのKibana導入はそれほど陳腐化して見えるのでしょうか？

重要なのは、この導入がHTTP/1上で実行されていることです。HTTP/1では、HTTPリクエストはTCP接続に1:1でマップされます。そのため、複数の長時間にわたるポーリングリクエストがブラウザの限られた接続プールを占有し、他のリクエストがキューに溜まってしまいます。

一方、HTTP/2+では、ネットワークリクエストは多重化によってTCP接続を共有できるため、この問題は発生しません。

つまり、HTTP/2+では継続的なポーリングは利点となりますが、HTTP/1では欠点となります。

HTTP/1

HTTP/2+

TCP接続

HTTPリクエストごとに1つ

多重化（多くのリクエストが接続を共有）

継続的なポーリング実行

パフォーマンスが低下（接続プールの枯渇）

最大の効果（結果をすぐに表示）

KibanaがHTTPプロトコルを検出して最適なポーリングを行う方法

HTTP/2は推奨されているプロトコルであり、Kibanaのデフォルトは9.0以降であるため、このパフォーマンス向上を実装しないのはもったいないでしょう。一方、HTTP/1のエクスペリエンスは非常に陳腐化しているため、プロトコルをまだアップグレードしていないオンプレミス導入でリスクを冒すことは許されません。答えは明確です。どのプロトコルが使用されているかを検出し、最適なポーリング戦略を適用する必要があります。

Kibanaサーバーがどのプロトコルを使用しているかを知ることは確かに可能です。しかし、そこには落とし穴があります：制限要因はブラウザの接続プールです。つまり、本当に重要なのはブラウザが何を使用しているかということです。

プロキシの関係で、これらは必ずしも同じではありません。

最適化をサーバープロトコルに基づいて行うと、2つの誤りのどちらかが起こり得ます。

1. 適用すべきでないのに継続的なポーリングを適用し、エクスペリエンスを低下させる。

2. 継続的ポーリングを適用すべき場合に適用せず、最適化の機会を逃す。

幸いなことに、最新のブラウザは PerformanceObserver を使用することで、完了したリクエストの最後のネットワークホップのプロトコルを検出する方法を提供しています。そこで、最初のクエリ送信のプロトコルを監視し、それに基づいて最適化します。

ラボでの結果：継続的ポーリングと従来のポーリングとの比較（Kibana）

継続的なポーリングを検証するために、1秒から23秒の範囲でクエリが遅延するダッシュボードを作成し、最適化を有効にした状態と有効にしていない状態での読み込み時間を測定しました。次に、継続的なポーリングが有効なダッシュボードと有効でないダッシュボードを読み込み、その結果を（賞品のかかったレースのように楽しんで）測定しました。

このパターンは、元のノコギリ型の図を踏襲しています。クエリの期間によっては、効果が小さい場合もあれば、数秒に及ぶ場合もあります。

まとめ

この最適化により、従来のポーリング方式に内在する遅延を、より効率的な継続的ポーリング方式に置き換えることに成功しました。主な課題は、HTTP/1環境でのパフォーマンス低下を防ぐために、この最適化を条件付きで実装することでした。私たちはこの課題を、ブラウザの PerformanceObserver を使って、最終ネットワークホップで使用されているプロトコルを確実に検出することで解決しました。

ラボでのテストによりこの理論が検証され、継続的なポーリングによって結果が準備でき次第すぐに得られることが示されました。平均して、これはユーザーエクスペリエンスの有意義な改善につながり、データの読み込みを最大25％高速化します。

この取り組みは、ユーザーが洞察を得るまでの時間を短縮するという私たちのコミットメントにおける、最新のステップです。KibanaをElasticsearchデータに対してより透明性の高いプロキシにすることで、私たちの影響が及ぶ範囲内でのパフォーマンスの限界を押し広げます。ぜひ今後の続報をお待ちください。

（2025年、トーマス・ナイリンクはKibanaのダッシュボードのパフォーマンスを向上させる方法と動機について優れた概要を紹介しました。これはその取り組みをアップデートしたものです。

Kibanaダッシュボードビルダーとは？

必要なダッシュボードをわかりやすい日本語で説明すると、インタラクティブなグラフ、ドラッグアンドドロップのレイアウト、Kibanaへのワンクリックエクスポートが表示・実行されるとしたらどうでしょうか。

それがまさに example-mcp-dashbuilder の役割です。これはオープンソースのモデルコンテキストプロトコル（MCP）アプリケーションで、AIアシスタントをElasticsearchに接続し、会話を通じて総合的なKibanaのダッシュボードを作成できます。メニューをクリックしたり、手動で可視化設定を書く必要はありません。必要なものを説明するだけで、AIがデータを調査し、Elasticsearch Query Language（ES|QL）でクエリを書き、グラフを作成し、ライブかつインタラクティブなダッシュボードを提供します。これらはすべて、エディタのチャット画面内で行われます。

プロンプトからダッシュボードまでを数秒で

実際の様子を以下で紹介します。次のように入力します：

「「logstash-*」から、リクエストの合計数、時間の経過に伴う転送バイト数、上位の地理的ソース、対応コードの内訳を含むWebトラフィックダッシュボードを作成してください。」

AIは次のように動作します：

1. データを発見：インデックスを一覧表示し、フィールドマッピングを検査します。

2. ES|QLのクエリを作成：スキーマに合わせ、適切なアグリゲーションを使用します。

3. 可視化を作成：棒グラフ、折れ線グラフ、スパークライン付きメトリクス、ヒートマップ、円グラフを作成できます。

4. すべてを整理整頓：折りたたみ可能なセクション、わかりやすいタイトル、適切なレイアウト。

5. インタラクティブなプレビューを表示：チャット内でツールチップ、時間選択機能、ドラッグ＆ドロップ機能を利用できます。

各グラフは作成されると同時にインラインで表示されるため、リアルタイムで進捗状況を確認できます。次にview_dashboardは、Kibanaの48列グリッドにすべてのパネルが配置された完全なダッシュボードを表示します。

単一のグラフを本文中にプレビュー表示します。

ES|QLで構築

すべてのデータ検索には、Elasticsearchのパイプ型クエリ言語であるES|QLを使用しています。AIは単に未加工のクエリをそのまま渡すだけでなく、ES|QL構文に関して標準搭載された知識とお客様のデータ構造に関する情報を使用して、各可視化タイプに対して正確かつ効率的なクエリを作成します。

サーバーには包括的なES|QLリファレンスがMCPリソースとして含まれています。クエリを書く前に、AIはこのリファレンスを読み取り、利用可能なコマンド、関数、およびパターンを理解します。データ可視化のベストプラクティス・ガイド（リソースとしても機能）と組み合わせることで、AIはクエリの方法だけでなく、何が可視化を優れたものにするのかも知ることができます：

• 時系列には BUCKET(@timestamp, 1 day) を使い、常に時間フィールドで SORT します。

• 円グラフは| SORT value DESC | LIMIT 6で6切れに制限します。

• カテゴリー比較のための棒グラフ、トレンドを示す折れ線グラフ、主要業績評価指標（KPI）のためのメトリクスを選択します。

オープンエンド分析によるAI主導のデータ探索

頭の中で既に設計したダッシュボードを、実際に作成することはまた別の作業です。「このインデックスの何が興味深いのか？」と尋ねること、そして有用な答えを得ることはより難しく、AIが単に描くのではなく、探索する方法を知る必要があります。

example-mcp-dashbuilder は、構造化された探索フローを定義する analysis://guidelines リソースを提供します。そのリソースとは、データのプロファイリング、ターゲットを絞ったアグリゲーションの実行、調査に値するパターンの抽出、最も興味深い発見のためのチャートの作成、ユーザーが次に望むかもしれないドリルダウンクエリの提案などです。トリガーフレーズ（例えば「ログを分析」や「このインデックス内のパターンを発見」）は、AIが何かを行う前にプレイブックを読み込むようにするため、オープンエンドなプロンプトはランダムなチャートの集合ではなく、一貫性のある調査を生成します。

結果：AIに馴染みのないインデックスを渡すと、開始点が返されます。開始点は、ダッシュボードと「以下に気づきました。これらの中に詳しく調べたいものはありますか？」というプロンプトと短いリストです。

Kibanaダッシュボードのエクスポートとインポート：完全な往復処理

エクスポート/インポートの往復処理は、既に Kibana を使用しているチームにとって example-mcp-dashbuilder が真に役立つ部分です。example-mcp-dashbuilder は独自の機能を持ち、エディタ内に存在する対話型のダッシュボード画面ですが、作業内容をエディタ内に閉じ込めることはありません。ここで構築されたダッシュボードは、必要に応じてKibanaに移動できます。既存のKibanaダッシュボードは、AI支援による編集のために逆方向に移動させることが可能です。

Kibanaにエクスポート

ダッシュボードにご満足いただけましたら、次のコマンド1つでエクスポートできます：

「このダッシュボードをKibanaにエクスポートしてください」

すべてのパネルは実際のKibana Lensの可視化に変換されます。変換後も以下は保持されます：

• ES|QLクエリ：LensにおけるES|QLのデータソースとして直接転送されます。

• グリッド位置：Kibanaと同じ48列システムを使用しているため、レイアウトはKibanaと全く同じに見えます。

• カスタムカラー：シリーズパレット、メトリックの背景、ヒートマップのカラーランプ。

その結果として、全面的に機能するKibanaのダッシュボードができます。スクリーンショットでも埋め込みでもありません。共有してKibanaで編集を続けることができるダッシュボードです。

Kibanaダッシュボードとカーソルチャットのダッシュボードを並べて表示します。

Kibanaからインポート

往復処理は逆方向でも機能します。

「ID abc-123でKibanaのダッシュボードをインポート」

これは既存のKibanaのダッシュボードを取得し、そのLensの可視化を編集可能なチャート構成に変換し、グリッドのレイアウトとセクションを保持して、すべてを example-mcp-dashbuilder に読み込みます。そこから自然言語で修正し、再エクスポートできます。

このように、AIは既存のKibanaワークフローにおける共同作業者となり、それを置き換えるものではありません。

カスタムテーマと色

ブランド化されたダッシュボードをご希望ですか？お問い合わせください：

「カスタムカラーを使用したピンクを基調としたダッシュボードを作成」

すべての可視化タイプはカスタムカラー設定をサポートしています：

• チャート：palette はシリーズとスライスに対して16進数の色の配列を指定できます。

• 指標：color が背景色を設定します。

• ヒートマップ： colorRamp は、低い値から高い値への勾配を定義します。

AIはテーマのリクエストを自然に受け取ります。「海のテーマ」と伝えると、青やティールの色合いが選択されます。「自社のブランドカラーと一致させてください」と伝えて16進数の値を指定すると、エクスポート時にKibanaに引き継がれます。

カスタムカラーの、テーマを使用したダッシュボード。

example-mcp-dashbuilder の仕組み：MCPアーキテクチャ

example-mcp-dashbuilderは、AIアシスタントを外部ツールやデータに接続するためのオープン標準である MCPに基づいて構築されています。アーキテクチャの概要は以下の通りです：

MCPサーバーは、AIが直接呼び出せる25のツールを公開しています。これには、ES|QLクエリの実行からダッシュボードのエクスポートまで、網羅的な内容が含まれています。さらに、インラインプレビューがデータの取得、レイアウト変更の永続化、時間フィールドの検出に使用する内部専用の「アプリのみ」ツールもいくつかあります。また、3つのリソースも提供しており、データ可視化のベストプラクティスガイド、ES|QLリファレンス、そしてオープンエンドのプロンプト（「ログを分析」、「このインデックスで何が興味深いのか」）に対応する深度分析プレイブックがあります。そして、stdioまたはHTTPのいずれかで実行されます。HTTPトランスポートはストリーム可能な対応とセッション管理をサポートしているため、複数のクライアントが1つのサーバーに接続できます。

MCPアプリは、インタラクティブなプレビューを表示します。React、Elastic Charts、Elastic UIを組み合わせて構築されており、1つの独立したHTMLファイルにまとめられています。AIが view_dashboard を呼び出したり、チャートを作成したりすると、ホストはこのHTMLをサンドボックス化されたiframe内にレンダリングします。アプリ全体はMCP Appsのプロトコルを通じてサーバーと通信し、postMessage上の callServerTool() を使ってデータの取得、レイアウトの保存、時間フィールドの検出を行います。localhostサーバーもなく、ポート設定も、外部ネットワーク依存もありません。

これは、あらゆるMCP互換のクライアント（Cursor、Claude Desktop、Claude.ai、VS CodeとCopilotの併用など）と動作することを意味します。

example-mcp-dashbuilder はどのようなチャートタイプをサポートしていますか？

執筆時点では、最も一般的なダッシュボードのシナリオをカバーする以下の6種類のチャートタイプがサポートされています。

タイプ

最適な用途

例

棒グラフ

カテゴリ比較

地理的ソース別のリクエスト

折れ線グラフ

一定期間におけるトレンドの変化

1時間あたりの転送バイト数

エリア

時間経過に伴うボリューム

時間経過に伴うリクエスト量

円グラフ

全体に占める割合（最大6切れ）

対応コードの分布

メトリック

スパークライン付きの単一KPI

時間別トレンド付きのリクエスト総数

ヒートマップ

二次元領域全体でのパターン

曜日・時間別リクエスト

ダッシュボードは、整理のための折りたたみ可能なセクション、自動時間フィールド検出を備えたタイムピッカー、および複数のダッシュボードを保存して切り替える機能をサポートしています。並行チャットセッションは、すべてのツールコールでdashboardIdがスレッド化されているため、互いに分離された状態を維持します。

example-mcp-dashbuilder のインストールと実行方法

example-mcp-dashbuilder はオープンソースであり、すぐに利用可能です。Node.js 22+、Elasticsearchインスタンス（ローカルまたはElastic Cloud）、およびMCP互換のクライアントが必要です。

Claude Desktop： GitHub Releasesから最新版.mcpbをダウンロードし、ダブルクリックします。Claude Desktopから、Elasticsearchの認証情報を入力するよう促されます。

Cursor / Claude Code / VS Code Copilot：MCP設定をリリースされた tarball に指定します。クローンや npm install は不要です。

環境変数として ES_NODE, ES_API_KEY（または ES_USERNAME / ES_PASSWORD）と KIBANA_URL を設定します。ソースから作業したい場合は、リポジトリをクローンし、npm run setup を実行して、ローカルのElasticsearchとElastic Cloud（Cloud ID + APIキー）の両方を処理するインタラクティブウィザードを使用します。

次のように、構築を開始できます：

「ログのインデックスを探索し、可能な限り洞察に富むダッシュボードを作成してください」

AIがその後を引き継ぎます。😉

ロードマップ：example-mcp-dashbuilder の今後

これは初期リリースであり、現在も鋭意開発を進めています。以下の分野などに注力しています。

• より多くのチャートタイプ：ゲージグラフ、ドーナツグラフ、ツリーマップ、データテーブル、タグクラウドなど、Lensの全機能に対応。

• ダッシュボードをGitにプッシュ：ダッシュボードの設定をリポジトリに書き込み、バージョン管理やコードレビューのワークフローを行います。

• 優れたエラーUX：ES|QLクエリが失敗した場合、一般的な修正案を含むより詳細なフィードバックを提供します。

• より高度な分析フロー：詳細分析のプレイブックを拡張し、より多くのデータ形式（ログ、メトリクス、トレース）に対応します。

お客様が構築されたものを、ぜひご紹介ください。お試しの後で問題があればご報告いただき、お客様のチームにとって最も役立つ可視化やワークフローはどのようなものかお知らせください。

GitHub: elastic/example-mcp-dashbuilder

謝辞

ウォルター・ラフェルズバーガーとティム・シュネルの実装への貢献に感謝します。

FAQ

example-mcp-dashbuilder とは？example-mcp-dashbuilder は、AIアシスタントをElasticsearchに接続するオープンソースのMCP（Model Context Protocol）アプリケーションです。Kibanaのダッシュボードを平易な日本語で説明し、ES|QLクエリを自動生成し、可視化を作成し、エディタのチャット画面内にライブかつインタラクティブなダッシュボードを表示できます。

example-mcp-dashbuilder はデータ取得にどのようなクエリ言語を使っていますか？すべてのデータ取得には、Elasticsearchのパイプクエリ言語であるES|QLを使用しています。MCPサーバーには、クエリを書く前にAIが読み取るES|QLリファレンスが標準搭載されているため、各可視化タイプの正しい構文と効率的なアグリゲーションが確保されます。

example-mcp-dashbuilder で作成したダッシュボードをKibanaにエクスポートできますか？はい。「このダッシュボードをKibanaにエクスポート」を実行すると、すべてのパネルが実際の Kibana Lens の可視化に変換され、ES|QLクエリ、48列のグリッドレイアウト、カスタムカラー、シリーズパレットが保持されます。結果は、スクリーンショットや埋め込みではなく、全面的に機能するKibanaのダッシュボードです。

既存のKibanaのダッシュボードを example-mcp-dashbuilder にインポートして、AI支援型編集はできますか？はい。KibanaのダッシュボードIDを指定すると、既存のダッシュボードが取得され、Lensの可視化が編集可能なグラフ構成に変換され、example-mcp-dashbuilder に読み込まれます。その後、自然言語を使用してダッシュボードを変更し、Kibanaに再エクスポートできます。

example-mcp-dashbuilder と互換性のあるMCPクライアントはどれですか？example-mcp-dashbuilder は、Cursor、Claude Desktop、Claude.ai、VS Code with Copilotなど、あらゆるMCP互換クライアントで動作します。stdioとHTTPトランスポートの両方をサポートしており、localhostサーバーやポートの設定は不要です。

example-mcp-dashbuilder はどのチャートタイプをサポートしていますか？現在のリリースでは、棒グラフ、折れ線グラフ、面グラフ、円グラフ、メトリクス（スパークライン付き）、ヒートマップの6種類のグラフがサポートされています。Kibana Lensの全機能に合わせて、ゲージグラフ、ドーナツ、ツリーマップ、データテーブル、タグクラウドなどを追加する予定です。

example-mcp-dashbuilder を実行するには何が必要ですか？Node.js 22以上、Elasticsearchインスタンス（ローカルまたはElastic Cloud）、およびMCP互換クライアントが必要です。環境変数 ES_NODE、ES_API_KEY（またはES_USERNAME/ES_PASSWORD）、KIBANA_URLを設定します。Claude Desktopの場合は、GitHub Releasesから.mcpbファイルをダウンロードし、ダブルクリックしてインストールします。

変数コントロールとは何ですか？

Kibanaのダッシュボードを使用したことがある方なら、クラシックなダッシュボードコントロール（データの値を表示する便利なドロップダウン）をご存知でしょう。これにより、数回のクリックでフィルタリングできます。

変数コントロールは表面上では似ていますが、巧妙な工夫が施されています。ダッシュボード上のすべてのパネルを自動的にフィルター処理するのではなく、個々の可視化内の ES|QLクエリに直接プラグインすることができます。

つまり、各コントロールを適用する場所をユーザーが決定できるということです。さらに、時間間隔の調整、内訳フィールドの切り替え、可視化パラメーターの即時変更など、さまざまなクリエイティブなトリックに使用できます。基本的に、ダッシュボードに真のインタラクティブな体験を提供し、より速く、より簡単に洞察を得られるようにしています。

変数コントロールのユースケース

変数コントロールは便利そうですが、実際に何ができるのでしょうか？ダッシュボードをレベルアップさせる例をいくつかご紹介します。

選択された可視化をフィルター

一部の可視化をフィルターし、他の可視化はそのままにしておきたい場合は、変数コントロールがまさに最適です。必要なパネルを選択して、可視化の背後にあるES|QLクエリでそれらを接続できます。

異なる時間間隔を選択

ユーザーが「5分」、「1時間」、「1日」など、適切な時間枠を切り替えることができるようにします。事前定義された間隔で変数コントロールを構築し、それを時系列クエリに接続します。

機能を変更

各操作ごとに複数のチャートを作成する代わりに、ダッシュボードユーザーが最大値、平均値、異なるパーセンタイル、またはその他のアグリゲーターを選択できるようにします。

異なるフィールドでグループ化

調査中に、データをさまざまな次元で分類する必要がある場合があります。変数コントロールを使用すると、複数の「グループ化」フィールドを定義し、ダッシュボードユーザーが分析情報を明らかにするのに役立つフィールドを選択できるようにすることができます。

作成方法

変数コントロールを作成する最も簡単な（そしておそらく最も楽しい）方法は、可視化のES|QLクエリエディタから直接作成することです。クエリを入力し始め、オートコンプリートメニューを使用すれば、Kibanaが役立つコントロールを自動的に作成します。

ただし、変数自体から開始したい場合は「パネルを追加」→「コントロール」→「変数コントロール」に進み、コントロールを作成した後で変数を可視化に追加することもできます。

例1：複数値選択によるフィルタリングコントロール

1. ES|QLクエリを利用した可視化を選択し、WHERE句内の「コントロールを作成」をクリックします。

2. 自動的に変数作成のポップアップにリダイレクトされます。ここでは「クエリからの値」タイプが自動で選択され、変数の名前も既に入力されています。可視化クエリで動作するよう、コントロールの名前は常に「?...」で始める必要があります。

通常、フィールドから値を取得し、ダッシュボードで選択した時間範囲に応じて値を更新するには、次のようなクエリが必要になります。

3. コントロールを保存すると、それがダッシュボードのトップに表示され、可視化クエリが変数コントロール名で更新されます。

4. コントロールに多重選択を追加したい場合は、ステップ2でクエリ内の MV_CONTAINS 関数を使用し、「複数選択を許可」を選択する必要があります（9.3以降で利用可能）。

例 2: 時間間隔制御

時系列を構築する場合は、日付ヒストグラム間隔に変数コントロールを簡単に追加できます。

1. 時系列のES|QLクエリを記述するときは、「コントロールを作成」をクリックします。変数を間隔用に作成する際は、BUCKET の代わりに TBUCKET を使用する方が良いです。これにより、「1 hour」、「1 day」などの見やすい間隔を受け入れることができます。TBUCKETには、時間範囲に自動的に適応できる自動オプションも近日中に導入される予定です。

2. ドロップダウンメニューでオプションを入力する間隔を定義します。

3. ドロップダウンメニューで異なる間隔を選択し、可視化がどのように変化するかを確認します。

例3：関数の変数

1. 「静的値」タイプのコントロールを使用して変数を作成し、ドロップダウン値に関数名を追加します。関数を置き換えるには、「??...」で始まる変数名を使用することが重要です。

2. ES|QLクエリに変数名を含めます。

例4：フィールドの変数

1. 「静的値」タイプのコントロールを使用して、必要なフィールドの名前を書き留めることができます。フィールドで機能させるためには「??...」で始まる変数名を使用することが重要です。

2. 可視化クエリで任意の場所に変数を参照します。

Discoverの変数コントロール

変数コントロールは単なるダッシュボードの特徴ではなく、DiscoverのES|QLエディターでも直接利用可能です。Discoverでより高速なデータ探索エクスペリエンスを実現するコントロールを構築し、それをダッシュボードに表示したり、その逆を行ったりすることができます。

技術的な詳細

ここまでで、変数コントロールには、クエリのどの部分を参照できるか、使用すべき命名プレフィックス（値の場合は「?...」、フィールドまたは関数の場合は「??...」）などのいくつかのルールがあることに気付かれたでしょう。これは、変数がクライアント上で行われる単純な文字列置換ではなく、実際にはクエリ言語自体の第一級オブジェクトであるためです（ES|QL ではパラメーターと呼ばれます）。

この設計にはいくつかの大きな利点があります。1つは、Kibanaが各変数のコンテキストを理解できるため、設定を自動的に生成して事前入力できることです。また、この言語が変数の入力を厳密に検証し、悪意のある挿入を防ぎ、何かおかしい点があれば適切にエラーを出力するため、安全性もはるかに高くなります。さらに、複雑な検証とエラー処理をクライアントではなくサーバー側に移動することで、パフォーマンスと安定性が向上します。パフォーマンスに関する注意点として、ベストプラクティスは、高速クエリを含む変数を構築することです。これにより、ダッシュボードよりも先に読み込まれ、遅いクエリがダッシュボード全体のパフォーマンスに影響を与えることを防ぎます。

もちろん、このアーキテクチャーにも（現時点では）いくつかの制限があります。変数はまだフィルタリング用の「任意」オプションをサポートしておらず、現在、LIKEやFROM（データソースの切り替え用）のような特定の演算子では使用できません。幸い、当社はこれらの機能を追加するために積極的に取り組んでいます。

コントロールの今後

この機能はまだ完成ではありません。以下のような改善を予定しています。

✨ ダッシュボードのどこにでもコントロールを配置できる機能

✨ コントロールの連鎖（一つのコントロールの出力が次のコントロールのインプットになるよう）

✨ 変数の「任意」選択のようなより良い選択オプション

✨ 新しいコントロールタイプ（検索するタイプのコントロールとデータソースの変数）

✨ さらに、ユーザーの皆様のご要望に応え、通常コントロールの事前フィルタリングなどの操作性の改善

アイデアやご意見があれば、ぜひお聞かせください。

この記事では、それを実現します。ダッシュボードのイメージを取得し、マッピングを分析し、Kibana にまったく触れることなくダッシュボードを生成するアプリケーションを作成します。

手順:

1. 背景とアプリケーションのワークフロー

2. データを準備する

3. LLM構成

4. アプリケーション機能

背景とアプリケーションのワークフロー

最初に思いついたのは、LLM に NDJSON 形式の Kibana保存オブジェクト全体を生成させて、それを Kibana にインポートさせることでした。

私たちはいくつかのモデルを試しました:

• ジェミニ 2.5 プロ

• GPT o3 / o4-ミニハイ / 4.1

• クロード 4つのソネット

• グロク3

• ディープシーク（ディープシンク R1）

プロンプトについては、次のように単純なものから始めました。

いくつかのショットの例と、各視覚化の構築方法に関する詳細な説明を確認したにもかかわらず、うまくいきませんでした。この実験に興味がある方は、こちらで詳細をご覧ください。

このアプローチの結果、LLM によって生成されたファイルを Kibana にアップロードしようとしたときに、次のメッセージが表示されました。

これは、生成された JSON が無効であるか、形式が間違っていることを意味します。最も一般的な問題は、LLM が不完全な NDJSON を生成したり、パラメータを幻覚させたり、あるいは、どれだけ強制しようとしても NDJSON ではなく通常の JSON を返したりすることでした。

この記事（検索テンプレートがLLM フリースタイルよりもうまく機能した）に触発され、完全な NDJSON ファイルを生成するように要求するのではなく、テンプレートを LLM に提供し、コード内で LLM によって提供されたパラメータを使用して適切な視覚化を作成することにしました。このアプローチは期待を裏切らず、予測可能で拡張可能です。LLM ではなくコードが重い処理を実行するようになったためです。

アプリケーションのワークフローは次のようになります。

簡潔にするために一部のコードは省略しますが、完全なアプリケーションの動作コードはこのノートブックに記載されています。

要件

開発を始める前に、次のものが必要です。

1. Python 3.8以上

2. Venv Python環境

3. 実行中のElasticsearchインスタンス、そのエンドポイント、APIキー

4. 環境変数名 OPENAI_API_KEY に保存された OpenAI API キー:

データを準備する

データについては、シンプルさを保ち、Elastic のサンプル Web ログを使用します。ここで、そのデータをクラスターにインポートする方法を学習できます。

各ドキュメントには、アプリケーションにリクエストを発行したホストの詳細と、リクエスト自体とその応答ステータスに関する情報が含まれています。以下にサンプル文書を示します。

ここで、先ほどロードしたインデックスkibana_sample_data_logsのマッピングを取得しましょう。

後で読み込むイメージと一緒にマッピングを渡します。

LLM構成

構造化出力を使用して画像を入力し、JSON オブジェクトを生成するために関数に渡す必要がある情報を含む JSON を受け取るように LLM を構成しましょう。

依存関係をインストールします。

Elasticsearch はインデックス マッピングの取得に役立ちます。Pydantic を使用すると、Python でスキーマを定義して LLM に従うように要求することができ、 LangChain はLLM と AI ツールの呼び出しを容易にするフレームワークです。

LLM から必要な出力を定義するために、Pydantic スキーマを作成します。画像からわかる必要があるのは、グラフの種類、フィールド、視覚化タイトル、ダッシュボード タイトルです。

画像入力には、先ほど描いたダッシュボードを送信します。

ここで、LLM モデルの呼び出しとイメージの読み込みを宣言します。この関数は、Elasticsearch インデックスのマッピングと、生成するダッシュボードの画像を受け取ります。

with_structured_outputを使用すると、Pydantic Dashboardスキーマを LLM が生成する応答オブジェクトとして使用できます。Pydanticを使用すると、検証付きのデータ モデルを定義できるため、LLM 出力が期待される構造と一致することが保証されます。

画像を base64 に変換して入力として送信するには、オンライン コンバーターを使用するか、コードで実行します。

LLM にはすでに Kibana ダッシュボードに関するコンテキストがあるため、プロンプトですべてを説明する必要はなく、Elasticsearch と Kibana で動作していることを忘れないようにするための詳細のみを説明します。

プロンプトを分解してみましょう:

セクション

理由

あなたは、Kibana バージョン 9.0.0 の画像から Kibana ダッシュボードを分析するエキスパートです。

これを Elasticsearch と Elasticsearch バージョンで強化することで、LLM が古い/無効なパラメータを幻覚する可能性を減らします。

ダッシュボード イメージと Elasticsearch インデックス マッピングが提供されます。

LLM による誤った解釈を避けるために、この画像はダッシュボードに関するものであることを説明します。

以下は、ダッシュボードのベースとなるインデックスのインデックス マッピングです。これを使用すると、使用可能なデータとフィールドを理解するのに役立ちます。インデックス マッピング: {index_mappings}

LLM が有効なフィールドを動的に選択できるようにマッピングを提供することが重要です。そうしないと、ここでのマッピングをハードコードすることになり、厳しすぎることになります。あるいは、正しいフィールド名を含むイメージに依存することになりますが、これは信頼できません。

画像に表示されている内容に基づいて、各視覚化に関連するフィールドのみを含めます。

画像に関係のないフィールドを追加しようとすることがあるため、この強化を追加する必要がありました。

これにより、表示する視覚化の配列を含むオブジェクトが返されます。

LLM応答の処理

私たちはサンプルの 2x2 パネル ダッシュボードを作成し、 Get a dashboard API を使用して JSON 形式でエクスポートしました。その後、パネルを視覚化テンプレート (円グラフ、棒グラフ、メトリック) として保存し、いくつかのパラメータを置き換えて、質問に応じて異なるフィールドを持つ新しい視覚化を作成できます。

テンプレート JSON ファイルはここで確認できます。後で置き換えたいオブジェクトの値を {variable_name} に変更したことに注意してください。

LLM が提供した情報を使用して、どのテンプレートを使用し、どの値を置き換えるかを決定できます。

fill_template_with_analysis 視覚化の JSON テンプレート、タイトル、フィールド、グリッド上の視覚化の座標など、単一のパネルのパラメータを受け取ります。

次に、テンプレートの値を置き換えて、最終的な JSON 視覚化を返します。

簡単にするために、LLM が作成することを決定したパネルに割り当てる静的座標があり、上の画像のように 2x2 グリッド ダッシュボードが生成されます。

LLM によって決定された視覚化タイプに応じて、JSON ファイル テンプレートを選択し、 fill_template_with_analysisを使用して関連情報を置き換え、後でダッシュボードを作成するために使用する配列に新しいパネルを追加します。

ダッシュボードの準備ができたら、ダッシュボードの作成 APIを使用して新しい JSON ファイルを Kibana にプッシュし、ダッシュボードを生成します。

スクリプトを実行してダッシュボードを生成するには、コンソールで次のコマンドを実行します。

最終結果は次のようになります。

まとめ

LLM は、テキストをコード化したり、画像をコード化したりするときに、強力な視覚機能を発揮します。ダッシュボード API を使用すると、JSON ファイルをダッシュボードに変換することも可能で、LLM といくつかのコードを使用して、画像を Kibana ダッシュボードに変換することもできます。

次のステップは、さまざまなグリッド設定、ダッシュボードのサイズ、位置を使用して、ダッシュボードのビジュアルの柔軟性を向上させることです。また、より複雑な視覚化と視覚化タイプのサポートを提供することも、このアプリケーションにとって便利な追加機能となるでしょう。

最初のSpotify Wrapped分析との違い

最初のブログでは、Spotify エクスポートを直接使用し、正規化タスクやその他のデータ処理は実行しませんでした。今回も同じデータを使用しますが、データをより使いやすくするためにデータ処理を行います。これにより、次のようなより複雑な質問に答えることができるようになります。

• トップ 100 の曲の平均再生時間はどれくらいですか?

• トップ 100 の曲の平均的な人気はどれくらいですか?

• 曲の平均視聴時間はどれくらいですか?

• 最もスキップされたトラックは何ですか?

• いつトラックをスキップしたいですか?

• 一日のうち特定の時間帯に他の時間帯よりも多く音楽を聴いていますか?

• 特定の曜日に他の曜日よりも多く聴いていますか?

• 特に興味のある月ですか？

• 最も長い聴取時間を持つアーティストは誰ですか?

Spotify Wrapped は、今年何を聴いたかを示してくれる、毎年楽しい体験です。前年比の変化は表示されないため、かつてはトップ 10 に入っていたものの、現在は消えてしまったアーティストを見逃してしまう可能性があります。

Spotify Wrapped データを分析用に処理する

最初の投稿と 2 番目の投稿では、データの処理方法に大きな違いがあります。最初の投稿のデータを使用して作業を継続する場合は、いくつかのフィールド名の変更を考慮する必要があり、また、ES|QL に戻ってhour of dayなどの特定の抽出をオンザフライで実行する必要があります。

それでも、皆さんはこの投稿を追うことができるはずです。Spotify から Elasticsearch リポジトリへのデータ処理では、Spotify API に曲の長さや人気度を問い合わせ、いくつかのフィールドの名前を変更したり、強化したりします。たとえば、Spotify エクスポートのartistフィールド自体は単なる文字列であり、フィーチャーや複数のアーティストのトラックを表すものではありません。

ダッシュボードでSpotify Wrappedデータを視覚化する

データを視覚化するために Kibana でダッシュボードを作成しました。ダッシュボードはここから入手でき、Kibana インスタンスにインポートできます。ダッシュボードは非常に広範囲にわたっており、上記の質問の多くに答えてくれます。

いくつかの質問とその答え方を一緒に見ていきましょう。

トップ 100 の曲の平均再生時間はどれくらいですか?

この質問に答えるには、Lens または ES|QL を使用できます。3つのオプションをすべて検討してみましょう。この質問を Elasticsearch のやり方で正しく表現してみましょう。上位 100 曲を見つけて、それらの曲すべてを合わせた平均時間を計算します。Elasticsearch の用語では、これは 2 つの集約になります。

1. トップ100曲を調べる

2. 100 曲の平均再生時間を計算します。

Lens

Lens では、これはかなり簡単です。新しい Lens を作成し、テーブルに切り替えて、 titleフィールドをテーブルにドラッグ アンド ドロップします。次に、 titleフィールドをクリックしてサイズを 100 に設定し、 accuracyモードを設定します。次に、 durationフィールドをテーブルにドラッグ アンド ドロップし、 last valueを使用します。実際に必要なのは、各曲の長さの最後の値だけだからです。同じ曲の長さは 1 つだけです。このlast value集計の下部には要約行のドロップダウンがあり、 averageを選択すると要約行が表示されます。

ES|QL

ES|QL は、DSL や集約と比較するとかなり新しい言語ですが、非常に強力で使いやすいです。ES|QL で同じ質問に答えるには、次のクエリを記述します。

この ES|QL クエリを段階的に説明します。

1. from spotify-history - これは私たちが使用しているインデックス パターンです。

2. stats duration=max(duration), count=count() by title - これは最初の集計であり、各曲の最大継続時間と各曲の数を計算しています。Lens で使用されているlast valueの代わりにmaxを使用します。これは、ES|QL には現在 first または last がないためです。

3. sort count desc - 曲は各曲のカウントで並べ替えられるため、最も多く聴かれた曲が一番上に表示されます。

4. limit 100 - 結果は上位 100 曲に制限されます。

5. stats Average duration of the songs=avg(duration) - 曲の平均再生時間を計算します。

私にとって特に興味深い月はありますか?

この質問に答えるには、ランタイム フィールドと ES|QL の助けを借りて Lens を使用できます。すぐに気づくのは、データ内にmonthを直接示すフィールドがないため、代わりに@timestampフィールドから計算する必要があるということです。これを行うには複数の方法があります。

1. ランタイムフィールドを使用してレンズに電力を供給する

2. ES|QL

個人的には、ES|QL の方がすっきりして素早いソリューションだと思います。

これで完了です。特別なことは何も必要ありません。 DATE_EXTRACT関数を利用して@timestampフィールドから月を抽出し、それを集計することができます。ES|QL 視覚化を使用すると、それをダッシュボードにドロップできます。

アーティストごとの年間視聴時間はどのくらいですか?

その背後にある考え方は、アーティストが単なる一回限りのものなのか、それとも再発するものなのかを確認することです。私の記憶が正しければ、Spotify では年間ラップのトップ 5 アーティストのみが表示されます。おそらく、6 位のアーティストはずっと同じままでしょうか、それとも 10 位以降は大きく変わるのでしょうか?

これを最も簡単に表現したものの 1 つは、パーセンテージ棒グラフです。これには Lens を使用できます。次の手順に従ってください:

listened_to_msフィールドをドラッグ アンド ドロップします。このフィールドは、曲を聴いた時間をミリ秒単位で表します。デフォルトでは、Lens はmedian集約を作成しますが、これは不要なので、 sumに変更します。上部の棒グラフの種類として、 stackedではなくpercentage選択します。内訳については、 artist選択し、トップ 10 を選択してください。Advancedドロップダウンでは必ずaccuracy modeを選択してください。各カラーブロックは、このアーティストをどれだけ聴いたかを表します。タイムピッカーに応じて、バーは日、週、月、年などの値を表す場合があります。週ごとの内訳が必要な場合は、 @timestampを選択し、 mininum intervalをyearに設定します。私の場合、最もよく聴いたアーティストはFred Again..であり、総聴取時間の約 12% がFred Again..に費やされたことがわかります。また、2024年にはFred Again..若干減少しましたが、 Jamie XX大幅に増加しました。バーの大きさだけを比較してみましょう。また、 Billie Eilishが 2024 年に継続的に再生されている間、バーの幅が広くなっていることもわかります。これは、2023 年よりも 2024 年にBillie Eilish多く聴いたことを意味します。

全体の視聴時間に対するアーティストごとのトップトラックはどうですか?

それは長い質問ですね。私が何を言いたいのか、それで説明してみたいと思います。Spotify では、特定のアーティストのトップソング、または全体のトップ 5 曲を教えてくれます。それは確かに興味深いですが、アーティストの内訳はどうですか?私の時間はすべて、何度も繰り返し再生する 1 つの曲に費やされているのでしょうか、それとも均等に分散されているのでしょうか?

新しいレンズを作成し、タイプとしてTreemapを選択します。metricについては、前と同じように、 sumを選択し、フィールドとしてlistened_to_msを使用します。group byには 2 つの値が必要です。最初はartistで、次に 2 番目にtitleを追加します。中間結果は次のようになります。

これをトップ 100 アーティストに変更し、詳細ドロップダウンでotherを選択解除し、精度モードを有効にしましょう。タイトルをトップ 10 に変更し、精度モードを有効にします。最終結果は次のようになります。

これは具体的に何を意味するのでしょうか?時間要素を見なくても、Spotify での私の全視聴履歴のうち、5.67% をFred Again..視聴に費やしたことがわかります。特に、その時間のうち 1.21% をDelilah (pull me out of this)視聴に費やしました。アーティストが占める曲が 1 曲だけなのか、それとも他の曲もあるのかどうかを見るのは興味深いです。ツリーマップ自体は、このようなデータ分布を表すのに適した形式です。

特定の時間と曜日に聞きますか?

そうですね、 Heat Mapを活用した Lens 視覚化を使えば、非常に簡単に答えることができます。新しいレンズを作成するには、 Heat Mapを選択します。Horizontal AxisではdayOfWeekフィールドを選択し、トップ 3 ではなくTop 7に設定します。Vertical Axisの場合はhourOfDayを選択し、 Cell Valueの場合は単純なCount of records選択します。これで次のパネルが生成されます:

このレンズには、解釈するときに邪魔になる厄介な点がいくつかあります。少し整理してみましょう。まず、凡例はあまり気にしないので、上部の三角形、四角形、円の記号を使用して無効にします。

さて、2番目に面倒なのは、日付の並べ替えです。指定した値に応じて、月曜日、水曜日、木曜日などになります。hourOfDayは正しくソートされています。日をソートする方法は面白いハックであり、 Top Valuesの代わりにFilters使用すると言われています。dayOfWeekをクリックしてFiltersを選択すると、次のようになります。

さあ、日付を入力し始めましょう。1 日につき 1 つのフィルター。"dayOfWeek" : MondayにしてラベルMondayを付け、これを繰り返します。

ただし、1 つの注意点は、Spotify がタイムゾーン情報なしで UTC+0 でデータを提供していることです。もちろん、IP アドレスと視聴した国も提供されており、そこからタイムゾーン情報を推測することはできますが、これは不正確になる可能性があり、米国のように複数のタイムゾーンがある国では面倒すぎる可能性があります。これは重要です。Elasticsearch と Kibana はタイムゾーンをサポートしており、 @timestampフィールドに正しいタイムゾーンを指定すると、Kibana は自動的に時間をブラウザの時間に合わせて調整します。

完成するとこのようになり、私は勤務時間中は非常に積極的に聞き手であり、土曜日と日曜日はそれほどではないことがわかります。

まとめ

このブログでは、Spotify データが提供する複雑な点について、もう少し詳しく説明します。いくつかの視覚化を実現するためのシンプルで簡単な方法をいくつか紹介しました。自分の視聴履歴をこれほど細かく制御できるのは、本当に素晴らしいことです。シリーズの他の部分もご覧ください:

• パート1：KibanaでSpotify Wrappedを作成する方法

• パート3：異常検出人口ジョブ

• パート4: データ内の関係性の検出

• パート5：ベクトルを使って最高の音楽仲間を見つける

このチュートリアルで設定する内容の図を以下に示します。

Ollamaを使用したローカル推論の設定

Ollamaは、ローカル推論用に厳選されたオープンソースモデルのセットを迅速にテストするための優れた方法であり、AI開発者に人気のツールです。

Ollamaをベアメタルで実行

Mac、Linux、またはWindowsでのローカルインストールは、特にMシリーズのAppleチップを使用しているユーザーにとって、ローカルのGPU機能を活用する最も簡単な方法です。Ollamaをインストールしたら、次のコマンドを使用してDeepSeek R1をダウンロードして実行できます。

ハードウェアに適したパラメータサイズに調整することをお勧めします。利用可能なサイズはこちらでご確認いただけます。

ターミナルでモデルとチャットできますが、CTL+dでコマンドを終了するか「/bye」と入力しても、モデルは実行されたままです。モデルがまだ実行中であることを確認するには、次のように入力します。

Ollamaをコンテナ内で実行

最も簡単な方法としては、OllamaをDockerのようなコンテナエンジンを利用して実行することもできます。ローカルマシンのGPUの使用は、環境によっては必ずしも簡単ではありませんが、コンテナに数GBモデルに適合するRAMとストレージがあれば、簡単なテストセットアップを行うことは難しくありません。

OllamaをDockerで起動して実行するには、次のコマンドを実行するだけです。

これにより、現在のディレクトリに「ollama」というディレクトリが作成され、コンテナ内にマウントされ、Ollamaの設定とモデルを格納します。使用するパラメータの数によって、数GBから数十GBまでの範囲になるため、十分な空き容量があるボリュームを選択してください。

注意：マシンにNvidia GPUが搭載されている場合は、必ずNvidia コンテナツールキットをインストールし、上記のdocker 実行コマンドに「--gpus=all」を追加してください。

Ollamaコンテナがマシン上で起動したら、deepseek-r1のようなモデルを次のコマンドでプルできます。

ベアメタルアプローチと同様に、ハードウェアに合ったサイズにパラメーターサイズを調整したい場合があります。利用可能なサイズについては、https://ollama.com/library/deepseek-r1をご覧ください。

モデルのプルが終了したら、「/bye」と入力してプロンプトを終了できます。モデルがまだ実行中であることを確認するには以下の手段を実行します。

curlを使用したローカル推論のテスト

curlを使用してローカル推論をテストするには、次のコマンドを実行します。JSONナラティブ応答を簡単に読み取れるように、stream:falseを使用しています。

「OpenAI互換」のOllamaとRAGプロンプトをテスト

便利なことに、OllamaはKibanaを含む幅広いツールとの互換性のために、OpenAIの動作を模倣するRESTエンドポイントも提供しています。

このより複雑なプロンプトをテストすると、<think>セクションを含むコンテンツが生成されます。このセクションでは、モデルが問題を推論するようにトレーニングされています。

OllamaをKibanaに接続する

Elasticsearchを使用する優れた方法は、「start-local」開発スクリプトを使うことです。

KibanaとElastisearchがネットワーク上でOllamaにアクセスできることを確認します。Elastic Stackのローカルコンテナ設定を使用している場合は、「localhost」を「host.docker.internal」または「host.containers.internal」に置き換える必要があるかもしれません。これは、ホストマシンへのネットワークパスを取得するためです。

Kibanaで、[Stack Management] > [アラートと洞察] > [コネクタ]に移動します。

この一般的な設定の警告が表示された場合の対処方法

xpack.encryptedSavedObjects.encryptionKeyが正しく設定されていることを確認する必要があります。これは、KibanaのローカルDockerインストールを実行する際によく見落とされる手順であるため、Docker構文で修正する手順をリストします。

コンテナのシャットダウン時に変更が保存されるように、kibana/configディレクトリを永続化してください。私のKibanaコンテナのボリュームは、docker-compose.ymlで次のようになります。

これで、キーストアを作成し、値を入れて、コネクタのキーが平文で格納されないようにすることができます。

変更を確実に有効にするには、クラスター全体を完全に再起動してください。

コネクタの作成

コネクタ構成画面（Kibana では、[Stack Management] > [アラートと洞察] > [コネクタ] に移動）からコネクタを作成し、[OpenAI] タイプを選択します。

コネクタを次の設定で構成します。

• コネクタ名：Deepseek（Ollama）

• OpenAIプロバイダーを選択：その他（OpenAI互換サービス）

• URL: http://localhost:11434/v1/chat/completions

  • ollamaへの正しいパスを調整してください。コンテナ内から呼び出す場合は、host.docker.internalまたは同等のものに置き換えてください。

• デフォルトモデル：deepseek-r1:7b

• APIキー：何か適当に入力してください。入力は必要ですが、値は重要ではありません。

コネクタセットアップでのOllamaへのカスタムコネクタのテストは現在8.17では機能しませんが、Kibanaの今後の8.18ビルドでは修正される予定です。

コネクタは次のようになります。

Elasticsearchにベクトル埋め込みデータを取り込む

すでにPlaygroundに精通していてデータが設定されている場合は以下のPlaygroundの手順にスキップできますが、簡単なテストデータが必要な場合は、_inference APIが設定されていることを確認する必要があります。8.17以降、機械学習の割り当ては動的であるため、e5多言語高密度ベクトルをダウンロードして有効にするには、Kiban Devツールで次のコマンドを実行する必要があります。

まだダウンロードしていない場合は、Elasticのモデルリポジトリからe5モデルのダウンロードが開始されます。

次に、RAGのコンテキストとしてパブリックドメインの書籍を読み込みましょう。こちらのリンクから、プロジェクト・グーテンベルクで「不思議の国のアリス」をダウンロードできます。これを.txtファイルとして保存してください。

[Elasticsearch] > [ホーム] > [ファイルのアップロード] に移動します。

テキストファイルを選択またはドラッグアンドドロップし、インポートボタンを押します。

「データのインポート」画面で「詳細設定」タブを選択し、インデックス名を「book_alice」に設定します。

「自動的に作成されたフィールド」のすぐ下にある小さな「追加フィールドを追加」オプションを選択します。「セマンティックテキストフィールドの追加」を選択し、推論エンドポイントを「.multilingual-e5-small-elasticsearch」に変更します。[追加] を選択し、[インポート] を選択します。

ロードと推論が完了したら、Playgroundに向かう準備が整います。

PlaygroundでのRAGのテスト

Kibanaで [Elasticsearch] > [Playground] に移動します。

Playground画面には、コネクタが存在することを示す緑色のチェックマークと「LLM接続済み」と表示されます。これは、上記で作成したOllamaコネクタです。Playgroundのより詳しいガイドについては、こちらをご覧ください。

青色の [データソースを追加] をクリックし、以前に作成したbook_aliceインデックス、または埋め込みに推論APIを利用する以前に構成した別のインデックスを選択します。

Deepseekは、強力なアライメント特性を備えた思考連鎖モデルです。これはRAGの観点から見ると良い点と悪い点の両方があります。思考連鎖のトレーニングは、Deepseekが引用文の中で一見矛盾しているように見える記述を合理化するのに役立つかもしれませんが、トレーニング知識への強力な整合性により、コンテキストの根拠よりも独自の世界の事実を優先する可能性があります。善意ではありますが、この強固な整合性により、LLMが個人的な知識が一致しないトピックや、トレーニングデータセットで十分に表現されていないトピックについて話し合う際に、指導が困難になることが知られています。

Playgroundのセットアップでは、「You are an assistant for question-answering tasks using relevant text passages from the book Alice in wonderland」というシステムプロンプトを入力し、他のデフォルトを受け入れました。

「Who was at the tea party?」という質問に対する答えはこうです。「Answer: The March Hare, the Hatter, and the Dormouse were at the tea party. [Citation: position 1 and 2]」これは正しいです。

<think>タグを見ると、Deepseekが質問に答えるために引用の内容をしっかりと検討したことがわかります。

アライメントの限界をテスト

Deepseekのために知的に挑戦的なシナリオをテストとして作成しましょう。Deepseekのトレーニングデータが真実ではないと知っている陰謀論のインデックスを作成します。

Kibana開発ツールで、次のインデックスとデータを作成しましょう。

これらの陰謀論は、LLMの基礎となるでしょう。積極的にシステムプロンプトを出したにもかかわらず、Deepseekは私たちが説明した事実を受け入れません。自分の個人データの方が信頼性が高く、根拠があり、組織のニーズに合っていることがわかっている状況だったら、これは受け入れられないでしょう。

「are birds real?」というテストの質問（説明はknow your meme）に対して、次の答えが得られます。「In the provided context, birds are not considered real, but in reality, they are real animals. [Context: position 1]」。このテストにより、DeepSeek R1は7Bパラメータレベルでも強力であることが証明されました。ただし、データセットによっては、RAGにとって最適な選択ではない可能性があります。

今回学んだ内容

まとめると以下のようになります。

• Ollamaなどのツールでモデルをローカルで実行することは、モデルの動作を確認するのに最適なオプションです。

• DeepSeek R1は推論モデルであるため、RAGのようなユースケースには利点と欠点があります。

• Playground は、AIホスティングの初期の時代にデファクトスタンダードになりつつあるOpenAIのようなREST APIを介してOllamaなどの推論ホスティングフレームワークに接続できます。

全体として、ローカルの「エアギャップ」RAGがここまで進歩したことに感銘を受けました。Elasticsearch、Kibana、そして利用可能なオープンウェイトモデルのツールは、2023年にプライバシー重視のAI検索について初めて記事を書いたときから大幅に進歩しました。

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に編集すると、マッピングは次のようになります。

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

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

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

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

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

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

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

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

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

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

距離

略語

名前

場所

国

市

標高

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 つのインデックスの結果を別のインデックスのデータで強化することができます。

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

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

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

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

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

ここでは、 geo_matchクエリ ( intersectsがデフォルト) が実行され、照合するフィールドがcity_boundaryであり、 enrich_fieldsが元のドキュメントに追加するフィールドであることがわかります。これらのフィールドの 1 つであるregionは、実際にはSTATSコマンドのグループ化キーとして使用されていましたが、これはこの「左結合」機能がなければ実行できませんでした。エンリッチ ポリシーの詳細については、エンリッチのドキュメントを参照してください。

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

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

• 上記のエンリッチ ポリシーを作成して、ソース インデックス、照合するソース インデックス内のフィールド、一致した場合に返されるフィールドを定義します。

• このポリシーを実行して、エンリッチ インデックスを作成します。これにより、元のソース インデックスをより効率的なデータ構造に読み取り、クラスター全体にコピーすることで、特別な内部インデックスが構築されます。

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

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

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

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

重心

カウント

地域

ポイント (-12.13908685930073331.024386116624648)

126

ヌル

ポイント (-83.1039831787347842.300230911932886)

3

デトロイト

ポイント (39.74537850357592 47.21613017376512)

3

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

ポイント (-156.8098678719252320.476673701778054)

3

ハワイ

ポイント (-73.9451533276587740.70366442203522）

3

ニューヨーク市

ポイント (-83.1039831787347842.300230911932886)

3

デトロイト

ポイント (-76.6687301918864324.306286952923983)

2

ニュープロビデンス

ポイント (-3.0252167768776417 51.39245774131268)

2

カーディフ

ポイント (-115.4099348466843432.73126147687435）

2

メヒカリ市

ポイント (41.790108773857355 50.302146775648)

2

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

ポイント (-73.8890273217111845.57078813901171)

2

モントリオール

また、最も頻繁に見つかった地域は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が搭載されており、これを使用して効率的な空間距離検索を実行できます。これが次のブログのトピックになります。