Kibanaのダッシュボードで、標準の「Lens」では表現できない複雑なチャート（サンキーチャートやカスタムマップ、特殊な散布図など）を作りたいとき、強力な武器になるのが  Vega / Vega-Lite  です。 しかし、これまでは重厚な Elasticsearch の Query DSL（JSON）を手書きしてデータを集計する必要があり、記述の複雑さに頭を悩ませた方も多いのではないでしょうか？ そんな開発者・アナリストに朗報です。バージョン 9.4+（Serverless Stack）以降、直感的で強力な新しいクエリ言語  ES|QL（Elasticsearch Query Language）  を Vega のデータソースとして直接利用できるようになりました！ 今回は、この  ES|QL × Vega  の組み合わせがもたらすメリットと、具体的な実装方法をコード例付きで解説します。 目次 なぜ ES|QL × Vega なのか？ 3つのメリット 1. 複雑な Query DSL からの解放 2. データ形式の自動変換 3. ダッシュボードの「時間範囲」や「フィルター」と完全同期 ES|QL を呼び出すための設定パラメータ Vega / Vega-Lite を使った Visualization の作成手順 【実践】サンプルコードで見る実装例1：折れ線グラフ（Vega-Lite） 💡 コードの解説 🖼️ 実行結果 【実践】サンプルコードで見る実装例2：時間帯×日付のヒートマップ（Vega-Lite） 💡 コードの解説 🖼️ 実行結果 まとめ：データ分析と表現の幅を広げよう なぜ ES|QL × Vega なのか？ 3つのメリット 1. 複雑な Query DSL からの解放 パイプライン演算子（  |  ）を使ってデータを段階的に加工できる ES|QL を使うことで、ネストの深い Elasticsearch 独自の集計クエリを書く必要がなくなります。クエリの可読性が劇的に向上します。 2. データ形式の自動変換 ES|QL のクエリ結果は本来「列指向（Columnar）」ですが、Kibana の Vega インテグレーターが自動的に  Vega が期待する「行ベース（Row-based / 1行1オブジェクト）」のJSON形式へ変換  してくれます。手動でのパース処理（  format.property  などの指定）の手間が大幅に減ります。 3. ダッシュボードの「時間範囲」や「フィルター」と完全同期 Kibana の拡張トークンを利用することで、ユーザーがダッシュボード上で操作した時間フィルターや検索条件を、ES|QL クエリ内に動的にマッピングできます。 ES|QL を呼び出すための設定パラメータ Vega の  data.url  オブジェクト内に以下のパラメータを指定することで、ES|QL モードが有効になります。 パラメータ 必須/任意 概要 "%type%" 必須 "esql"  を指定します。 "query" 必須 実行したい ES|QL （1行で書く） "%context%" 任意 true  に設定すると、ダッシュボードのグローバルフィルターがクエリに自動適用されます。 "%timefield%" 任意 タイムスタンプのフィールド名を指定。これを設定すると、クエリ内で名前付きパラメータ  ?_tstart  と  ?_tend  が利用可能になります（ダッシュボードの時間範囲が代入されます）。 "dropNullColumns" 任意 true  （デフォルト）の場合、null 値しか含まれない列をレスポンスから自動で除外します。 "params" 任意 クエリに動的に代入したい名前付きパラメータの配列を指定します。 Vega / Vega-Lite を使った Visualization の作成手順 Kibanaにおけるカスタム可視化の作成手順は以下の通りです（従来通り）。 1: Dashboard を新規作成するか、既存の Dashboard を編集モードにします。 2: 右上の [Add panel] プルダウンメニューから [New panel] を選択します。 3: パネル選択画面から [</> Custom visualization] を選択します。 4: Vega / Vega-Lite の作成画面が表示されるので、右側のエディタに JSON を記述していきます。 5: デバッグしたい場合は、上部の Inspect をクリックしてください。 【実践】サンプルコードで見る実装例1：折れ線グラフ（Vega-Lite） 以下は、サンプルデータ（Webログ）を使用し、時間の経過に伴うイベント数を2時間おきに集計して折れ線グラフ（Line Chart）で描画する Vega-Lite (v6) の定義例です。 { "$schema": "https://vega.github.io/schema/vega-lite/v6.json", "title": "Event counts per 2 hours", "data": { "url": { "%type%": "esql", "%context%": true, "%timefield%": "@timestamp", "query": "FROM kibana_sample_data_logs | WHERE @timestamp >= ?_tstart AND @timestamp < ?_tend | STATS doc_count=COUNT() BY tbucket=TBUCKET(2 hour) | SORT tbucket" } }, "mark": "line", "encoding": { "x": { "field": "tbucket", "type": "temporal", "axis": { "title": false } }, "y": { "field": "doc_count", "type": "quantitative", "axis": { "title": "Document count" } } } } 💡 コードの解説 ** %timefield%: "@timestamp"  と  ?_tstart  /  ?_tend** ES|QL クエリ内の  WHERE @timestamp >= ?_tstart AND @timestamp < ?_tend  に注目してください。これにより、Kibana ダッシュボードの右上にある時間セレクター（例: 「過去24時間」など）の範囲が、自動的にこのプレースホルダーに流し込まれます。 STATS ... BY tbucket=TBUCKET(...) ES|QL の強力な関数  TBUCKET  を使い、2時間ごとのバケットに丸めてカウント（  COUNT()  ）しています。従来の Query DSL で  date_histogram  アグリゲーションを書くよりも圧倒的にシンプルです。 mark : "line" "mark": "line"  を指定することで、集計データを折れ線グラフとして描画するよう指示しています。 encoding  セクション ES|QL で集計した結果の列名（  tbucket  と  doc_count  ）が、そのまま Vega-Lite の  field  として直感的にマッピングされているのがわかります。 🖼️ 実行結果 【実践】サンプルコードで見る実装例2：時間帯×日付のヒートマップ（Vega-Lite） 次に、1時間ごとのイベント数を「曜日や日付×時間帯」のマトリクスで可視化し、アクセスの時間帯トレンドを一目で把握できるヒートマップ（パンチカード）の例をご紹介します。 { "$schema": "https://vega.github.io/schema/vega-lite/v6.json", "title": "kibana_sample_data_logs 内の時間ごとのログ数", "data": { "url": { "%type%": "esql", "%context%": true, "%timefield%": "@timestamp", "query": "FROM kibana_sample_data_logs | WHERE @timestamp >= ?_tstart AND @timestamp < ?_tend | STATS count=COUNT() BY datetime=TBUCKET(1 hour) | LIMIT 10000 | SORT datetime" } }, "config": { "view": { "strokeWidth": 0, "step": 13 }, "axis": { "domain": false } }, "mark": "rect", "encoding": { "x": { "field": "datetime", "timeUnit": "hours", "type": "ordinal", "title": "時" }, "y": { "field": "datetime", "timeUnit": "date", "type": "ordinal", "title": "日" }, "color": { "field": "count", "type": "quantitative", "legend": { "title": "カウント" } } } } 💡 コードの解説 mark : "rect"によるグリッド描画 Vega-Lite でヒートマップを作る際は、タイル（四角形）を描画する  "rect"  マークを使用します。 timeUnit を使った「時」と「日」の切り出し ES|QL 側からは  TBUCKET(1 hour)  で丸められた一連のタイムスタンプが返ってきます。それを Vega-Lite 側の  timeUnit  プロパティを使って、X軸には「時（hours）」、Y軸には「日（date）」として切り出してマッピングしています。これにより、複雑なクエリを書くことなく、フロントエンド側で綺麗な2次元マトリクスを表現できます。 color による密度の可視化 集計したイベント数（  count  ）を  color  の  quantitative （量的データ）として指定することで、ログ件数に応じた色の濃淡が自動的に適用されます。 🖼️ 実行結果 まとめ：データ分析と表現の幅を広げよう これまでの Kibana カスタム可視化は、「Query DSL が難解で手が出せない」というエンジニアも多かったかと思います。しかし、ES|QL の登場によって、SQL ライクな直感的な記述でバックエンドのデータを引き出し、Vega の表現力をフルに活かせるようになりました。 ダッシュボードの表現力をもう一段階引き上げたい方は、ぜひ公式ドキュメントの  Custom visualizations with Vega | Elastic Docs  を参考に、ES|QL × Vega の強力なタッグを試してみてください！ その他の参考URL Kibana dashboards improvements | Elastic Search Labs Vega公式 Vega-Lite公式 The post Kibanaの新定番！ES|QL と Vega を組み合わせて自由自在なカスタム可視化を実現する first appeared on Elastic Portal .

Elastic 9.4.0 より Elastic Agent Builder が GA になりました。 今回は、Elastic Agent Builder で作成した Tool や AI Agent が Local LLM 環境でも実際に動作するのか検証してみました。 目次 検証環境 準備 Tool, AI Agent, Connector の作成 Tool の作成 AI Agent の作成 Connector の作成 Feature Settings AI Agent の実行 Answer 実行結果の考察 LLMの改善 検証環境 PC : Windows 11 Pro (32 GB RAM) Docker Container : Rancher Desktop 1.22.3 Elastic Stack : Elastic 9.4.2 Trial License (Docker 上で動作) Local LLM 実行環境 : LM Studio 0.4.16 Local LLM : Qwen 3.5 2B (Q4_K_M) Context Length: 14419 / GPU Offload: 24 テストデータ : kibana_sample_data_logs (Kibana に付属のサンプルデータ) 準備 サンプルデータ kibana_sample_data_logs を Kibana の画面から登録しておきます。(※脚注1 1 ) Docker の Host マシン上で LM Studio を起動します。 LM Studio に qwen3.5-2b をダウンロードし、ロードします。 LM Studio の Developer Mode で Server を 11434 ポートで開始します。 Context Length : 15000 程度 GPU Offload : 24 Tool, AI Agent, Connector の作成 今回は、  「kibana_sample_data_logs のログ数を送信先ごとに集計し、上位10件を取得する」  ための Tool, AI Agent を作成していきます。 また、AI Agent と LLM の中継を行う Connector も作成します。 AI Agent のシーケンス図（概略） ※あくまで一例です。 Tool の作成 AI Agent → Tool の順にトップダウンで作成することも可能ですが、 今回は Tool → AI Agent の順にボトムアップで作成していきます。 Kibana にログイン後、Home / Elasticsearch / Agents メニューをクリックします。 Tools メニューをクリックし、さらに、Manage all tools をクリックします。 ※注 [Add tool] ではありません。 Tools library 画面が表示されるので、[+ New tool] をクリックします。 Tool の新規登録画面が表示されます。 下記のように入力していきます。 Type  : ES|QL ES|QL Query  : 下記のクエリーを入力 （ログを送信先ごとに集計し、上位n件を返すクエリー） FROM kibana_sample_data_logs | WHERE @timestamp > ?start_datetime AND @timestamp < NOW() | STATS count = COUNT(*) BY geo.dest | SORT count DESC | KEEP geo.dest, count | LIMIT ?limit ES|QL Parameters (1) Name  : start_datetime Description  : 調査の起点となる日時 Type  : date Optional  : true Default value  : 05/01/2026 ES|QL Parameters (2) Name  : limit Description  : 上位何件のログを取得したいか? Type  : integer Optional  : true Default value  : 10 Tool ID  : tool_get_kibana_sample_data_logs_count_by_geo_dest Description  : 下記を入力 kibana_sample_data_logs について、指定された開始日時 (start_datetime) 以降の送信先 (geo.dest) ごとのログ数を調べる。 ログ数の多い順に上位 limit 件のログ数を返す。 入力し終えたら、[Save & test] を押して、Tool の保存と ES|QL のテストを行います。 AI Agent の作成 Tool を作成し終えたら、次は Tool を呼び出す AI Agent を作成します。 デフォルトで表示されている AI Agent 名の右にある、下向きのアイコンをクリックします。 [Manage agents] をクリックします。 AI Agent の一覧が表示されます。画面右上の [+ New agent] をクリックします。 AI Agent の新規登録画面が表示されます。 下記のように入力していきます。 Agent ID  : get_kibana_sample_data_logs_count_by_geo_dest Custom Instructions  : 下記を入力 あなたは kibana_sample_data_logs についての分析を行うエージェントです。 # 指示1 与えられた質問から、調査対象の開始日時、および取得したい件数を抽出しなさい。 その開始日時を start_datetime 、取得したい件数を limit として記憶しなさい。 # 指示2 次のツールを使って、送信先ごとのログ数を取得しなさい。 その際、指示1 で抽出した開始日時を start_datetime 、取得したい件数を limit parameter として渡しなさい。 - tool : tool_get_kibana_sample_data_logs_count_by_geo_dest Display name  : Get kibana_sample_data_logs count by geo.dest Display description  : 下記を入力する。 kibana_sample_data_logs について 指定された開始日時 (start_datetime) 以降のログ数を送信先 (geo.dest) ごとに集計する。 ログ数の多い順に limit 件の送信先を返却する。 （Custom Instructions が LLM に対する指示となります。） 入力し終えたら、先ほど作成した Tool : tool_get_kibana_sample_data_logs_count_by_geo_dest を参照するよう設定します。 画面上部の Tools タブをクリックします。 デフォルトで設定されている Tool を全てオフにします。 次に、先ほど作成した Tool : tool_get_kibana_sample_data_logs_count_by_geo_dest にチェックを入れます。 画面右上の [Save] をクリックします。 Connector の作成 AI Agent を作成したので、AI Agent と LLM を中継する Connector を作成します。 Stack Management / Alerts and Insights / Connectors をクリックします。 Connector の一覧画面が表示されます。右上の [(+) Create connector] をクリックします。 接続タイプの選択画面が表示されます。 今回は、OpenAI 互換の LM Studio 経由で接続するので、OpenAI を選択します。 OpenAI （互換の）Connector の登録画面が表示されます。 今回は、Docker の Host である host.docker.internal の 11434 ポートが接続先となるので 次のように入力していきます。 Connector name  : local_qwen_3_5_2b Select an OpenAI provider  : OpenAI URL  :  http://host.docker.internal:11 4 34/v1/chat/completions Default model  : qwen3.5-2b API key  : LM Studio で設定した API Key LM Studio で API Key を省略した場合は、dummy など適当に入力する。 Add HTTP header Key  : content-type Value  : application/json 入力し終えたら Test で接続できることを確認する。 Feature Settings 先ほど作成した Connector : local_qwen_3_5_2b を利用できるよう、Feature Settings で設定します。 Stack Management / Model Management / Feature Settings をクリックします。 Feature Settings 画面が表示されます。 Agent Builder の Assigned models の (+) Add a model をクリックして、先ほど作成した local_qwen_3_5_2b を選択します。 AI Agent の実行 準備ができたので AI Agent を実行してみます。 Home / Elasticsearch / Agents から get_kibana_sample_data_logs_count_by_geo_dest を選択します。 Connector に local_qwen_3_5_2b が選択されていることを確認します。 local_qwen_3_5_2b 以外が選択されている場合は、そのコネクター名をクリックして、local_qwen_3_5_2b に変更します。 それでは、チャット欄に質問を入力してみます。 2026-06-01T00:00:00Z 以降のログ数を送信先ごとに表示してください。ただし、ログ数が多い順に上位5件のみ表示してください。 私の環境では、回答を得られるまでに2分40秒ほどかかりました。 回答に至るまでの Reasoning も表示されます。 Reasoning Calling tool tool_get_kibana_sample_data_logs_count_by_geo_dest Parameters { "start_datetime": "2026-06-01T00:00:00.000Z", "limit": 5} ESQL FROM kibana_sample_data_logs | WHERE @timestamp > "2026-06-01T00:00:00.000Z" AND @timestamp < NOW() | STATS count = COUNT(*) BY geo.dest | SORT count DESC | KEEP geo.dest, count | LIMIT 5 Found 5 results 167 seconds ↑ 8,878 tokens ↓ 197 tokens Answer 2026-06-01T00:00:00Z以降のログ数（上位5件） 送信先ごとのログ数は以下の通りです： 送信先 ログ数 CN 723 IN 625 US 311 ID 125 BR 106 このデータは、tool_get_kibana_sample_data_logs_count_by_geo_dest ツールの結果に基づいています。 実行結果の考察 正しい結果が返ってきました。 （上記の結果は、実行するタイミングによって参照するデータの範囲が変わるため、違うタイミングでは異なる結果となります。） このように Tool, AI Agent, Connector を作成することで Local LLM でも AI Agent を動かすことができました。 正しい結果を返すためには、適切な Tool の作成、適切な AI Agent の Instruction の設定、適切な LLM の選択が必要となります。 （なお、Tool から MCP Server へ接続することも可能です。また、AI Agent の実行には Tool だけでなく、Skill や Workflow も利用することが可能です。） LLMの改善 今回のローカル環境 (Qwen 3.5 2B) では、回答を得られるまでに約2分40秒の時間がかかりました。 また、非常に軽量のモデルを利用しているため、より複雑なビジネスの質問には対応しきれない可能性が高いです。(※脚注2 2 ) もし実運用を見据えてパフォーマンスを改善する場合、以下の２つのアプローチが考えられます。 a. ローカル環境のマシンリソースを増強し、より強力な大型モデルを動かす b. クラウド上の強力な LLM 外部 API を呼び出す ローカル環境の増強はコストや手間の面でハードルが高いため、手軽に強力な LLM を試す方法としては EIS（Elastic Integration Server） を使ったクラウド LLM の呼び出しがおすすめです。 EIS を経由すれば、Anthropic Claude Sonnet 4.6 などを簡単に呼び出すことができます。 興味のある方は、ぜひ以下の参考記事もあわせてご覧ください。試しに Anthropic Claude Sonnet 4.6 で同じ質問を入力したところ10秒ほどで結果が返却され、しかも指示していないにもかかわらず、グラフまで表示されました。 （※EISを利用するには、有償の Elastic Cloud 環境が必要です。Anthropic Claude Sonnet 4.6 などの利用料金は別料金となります。） ベクトル検索と EIS を使った AI 生成回答の活用 EIS でクラウド LLM を活用する方法 kibana_sample_data_logs の登録方法 ↩︎ Observability 用の推奨モデル Security 用の推奨モデル ↩︎ The post Elastic AI Agent を Local LLM で動かしてみた。 first appeared on Elastic Portal .

FIFA ワールドカップ 2026は、アメリカ・カナダ・メキシコの3か国開催です。 会場が大陸全体に散らばっているので、チームによって移動の負担がかなり違いそうだな、と思いました。 そこで、各チームのグループステージの「移動スケジュールの重さ」を、Elastic を使って地図とダッシュボードで見えるようにしてみました。この記事では、何を作ったのか、何のデータを使ったのか、そしてどこまでが言えてどこからは言えないのかを、なるべくシンプルに説明します。 目次 概要 着眼点 手法 ダッシュボードの作り方は1つじゃない（しかも AI に任せられる） なぜ Elastic でやると面白いのか まとめ 概要 一言でいえば、「どのチームの移動スケジュールが最も過酷か」を可視化したダッシュボードです。 中心となるのは、独自の「移動負担スコア（travel_burden_score）」です。念のためお伝えしておきますが、これはあくまで仮説に基づいたカスタム指標であり、公式なデータではありません。今回は以下の5つの要素に重みをかけて組み合わせてスコアを算出しました。 ベースキャンプから各試合会場までの距離 ベースキャンプから最も遠い会場までの距離 試合順に見た会場間の移動距離 試合間の休養日数 タイムゾーンの移動（時差） つまり、「長距離の移動が多い」「時差が大きい」チームほどスコアが高くなる仕組みです。 着眼点 なぜ面白いと思ったのかというと同じ「グループステージ3試合」でも、チームによって移動の負担には天と地ほどの差があるからです。  例えばボスニア・ヘルツェゴビナ代表の場合、ベースキャンプはサンディに置かれますが、試合会場はトロント、ロサンゼルス、シアトルと各地に分散しています。これを地図で見ると、大陸を横断するようなハードな移動が必要なことが一目瞭然です。  数字だけではピンと来なくても、地図上に線を描いてみるとその過酷さが伝わりますよね。これがダッシュボードを作ってみようと思った最大の理由です。 手法 背景を知らない方のために、使ったものを簡単に説明します。 データはすべて公開データです。 自分で試合結果や移動データを作ったりはしていません。 試合日程・会場：OpenFootball（無料・自由に使える公開データ） 各チームのベースキャンプ：FIFA の公式発表ページ 会場やベースキャンプの座標：Wikipedia / GeoNames などの公開情報 これを Elastic の仕組みに載せています。Elastic という名前を初めて聞く方向けに、まずひとことで言うと、検索（Search）・監視（Observability）・セキュリティ（Security）を1つにまとめたデータプラットフォームです。 具体的に使ったのは次の3つです。 Elasticsearch ：データをためて高速に検索・集計できるエンジン。Elastic の心臓部です。今回の「チームごとの移動データ」をここに入れています。 Kibana ：そのデータをグラフや表で可視化するツール。ダッシュボードはここで作ります。 Kibana Maps ：地図の上にデータを重ねて見せる機能。ベースキャンプ、試合会場、移動の線を地図に描いています。 データの整形（距離の計算など）は、シンプルな Python スクリプトで行っています。距離は2点間の直線距離で計算しています。 ここはとても大事なので、はっきり書きます。これは 実際の移動ルートや、チームのコンディションを直接示すものではありません。 距離は「直線距離」です。実際の移動は道路や飛行機なので、もっと長くなります。 ベースキャンプは「都市レベル」の座標です。正確な練習場の場所までは使っていません。 あくまで「日程表から見える移動の負担」を推定しているだけです。 なので、「移動が重い＝負ける」という話ではありません。 ただ、スケジュール上の移動負担をデータで眺めてみるという意味では、面白い切り口になったと思っています。 ダッシュボードの作り方は1つじゃない（しかも AI に任せられる） 大きく3つあります。 手動で作る ：Kibana の画面で、パネルを足したり並べたりして作る。一番わかりやすい方法です。 API で作る ：Python などからプログラムでダッシュボードを生成する。今回はこの方法で、ダッシュボードをファイル（NDJSON）として書き出し、誰でも取り込めるようにしました。 AI に任せる ：Elastic には、AI エージェント向けのSkillsが公開されていて、その中にはダッシュボード作成用のものもあります。つまり、AI に作らせることもできます。 さらに Agent Builder という機能もあります。これは、自分のデータの上で動く「質問に答えるアシスタント」を作れる仕組みです。実務で複雑なダッシュボードを扱うときに、その裏にあるデータについて「なぜこのチームが1位なの？」のような質問を自然言語で投げて、答えてもらう、といった使い方ができます。 なぜ Elastic でやると面白いのか 今回はサッカーを題材にしましたが、やっていることは、もっと一般的な問題と同じです。 「公開（または社内）の予定データに、場所の情報をくっつけて、距離・休み・時差から負担を点数にして、地図とダッシュボードで見せる」 という流れです。 これは、たとえば次のような場面とそのまま重なります。 現場スタッフをどの拠点からどの現場へ動かすか（フィールドオペレーション） イベントの会場配置と人員の動き 配送・物流の負荷 拠点ごとの混雑やインフラ負荷 セキュリティ：ログインがどの国・拠点から来ているかを地図に出し、ふだんと違う場所からのアクセスを見つける（不正アクセスの兆候の可視化） Elastic は、データの取り込みから、検索、集計（ES|QL という問い合わせ言語。Splunk を使ったことがある方は、あの SPL と同じ立ち位置のものだと思ってください）、ダッシュボード、地図までを1つの基盤でまかなえます。だから「予定データを運用の知見に変える」のに向いています。サッカーの例は、その分かりやすい入り口というわけです。 まとめ 大会が終わったら、実際の結果やチームのパフォーマンスと推定した移動の大変さ見比べてみるのも面白そうだなと思っています。 ここで個人的な感想を少しだけ。 Elastic は、コツをつかむまでは正直ちょっと小難しいところがあります。でも今は GenAI（生成AI）を一緒に使うことで、その最初のハードルがかなり下がってきている感じがします。「全部を自分で覚えてから作る」のではなく、 AI に手伝ってもらいながら作って、動かしながら理解する ことができる時代になってきたな、と実感しました。 最後まで読んでいただき、ありがとうございました。 サイオステクノロジー株式会社 Saman The post ワールドカップ2026の各チームの移動の大変さを Elastic で可視化してみた first appeared on Elastic Portal .