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

エージェントはダッシュボードをゼロから構築しますが、既存のものも使用できます。ダッシュボードを表示中に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単独の裁量に委ねられます。現時点で提供されていないあらゆる機能または性能は、すみやかに提供されない可能性、または一切の提供が行われない可能性があります。

そこで、Elasticは読み取り専用のダッシュボードを開発しました。求めていたコントロールが獲得でき、安心してダッシュボードを共有できます。編集アクセス権を持つ別の人が変更したり壊したりすることを心配する必要はありません。

注：読み取り専用の権限は、Elastic Cloud ServerlessおよびElastic Cloud Hosted、Elastic Self-Managedのバージョン9.3以降で利用可能です。

「すべてのユーザーが編集可能」権限が妨げになる場合

Kibanaにおいて、共有は通常、スペースレベルの権限を意味していました。誰かがスペースでダッシュボードを作成できる場合、他の人のダッシュボードも編集または削除できます。コラボレーションにとっては便利ですが、場合によってはそうとも言い切れません。たった一度の意図しない編集が、誤った判断、信頼の喪失、そして多大な後始末へと連鎖的に影響を及ぼす可能性があります。

ダッシュボード名に「read-only」と入れて皆が気づくことを期待するとか、タグを付けてうまくいくことを祈るといった回避策もあるにはありますが、期待と権限モデルはイコールではありません。必要なのは、スペースから全員を締め出すことなくダッシュボードをロックするための現実的な手段でした。

問題の実例

DebとKevinはどちらも、オペレーションスペース内のログ監視ダッシュボードへの編集権限を持っています。Kevinがチャートにいくつか変更を加えます。Debがダッシュボードに戻ると、数字は彼女が提示したものと一致しませんでした。彼女は（多くの場合記憶を頼りに）何が変更されたのかを突き止め、それを修正し、どれだけの報告書が誤ったデータで送信されたのかを考えなければならなくなります。

読み取り専用ダッシュボード：理にかなった所有権と制御

読み取り専用のダッシュボードでは、他のユーザーがダッシュボードを編集できるかどうかを管理できます。ダッシュボードを共有する際、編集（デフォルト：従来どおり）または閲覧を選択します。閲覧モードでは、あなた（とKibana管理者）のみが変更または削除できます。他のユーザーは開いて利用できますが、変更することはできません。

手に入るもの

• ダッシュボードの整合性：閲覧モードでは、スペースで編集アクセス権を持つ他のユーザーはダッシュボードを変更または削除できません。操作を試みると、ロックされているというメッセージが表示されます。グラフとロジックは設定した状態のまま維持されます。

• コントロールを維持：コントロールは所有者が維持し、いつでも編集、改良、更新が可能です。閲覧専用として共有しても、自分がアクセスできなくなるわけではありません。他の全員が表示できるバージョンが固定されるだけです。

• 柔軟なライフサイクル： ダッシュボードはいつでも「編集可能」に戻すことができます。また、Kibanaの管理者は引き続きすべてのダッシュボードを管理できます（所有者が退職した場合など）。行き止まりになることはありません。

最終決定済みの、業務上極めて重要なダッシュボードを広く共有しても、その一貫性が維持されることが保証されます。これは、Serverlessを含むすべてのElasticのティアとサービスで利用可能です。

役割と可能な操作

クイックリファレンス（役割別）：

• ダッシュボードの所有者：作成者として、完全な編集権限があります。

• Kibana管理者：すべてのダッシュボードを管理できます。

• スペース編集権限を持つユーザー：ダッシュボードの作成と編集が可能ですが、閲覧専用のダッシュボードの編集や削除はできません。

• スペース閲覧権限を持つユーザー：ダッシュボードの表示と一覧表示のみが可能です。

操作

ダッシュボード所有者

Kibana管理者

スペース編集権限を持つユーザー

スペース閲覧権限を持つユーザー

ダッシュボードの一覧表示と表示

✔

✔

✔

✔

新規ダッシュボードの作成

✔

✔

✔

✘

編集可能なダッシュボードの変更/削除

✔

✔

✔

✘

読み込み専用ダッシュボードの変更/削除

✔

✔

✘

✘

読み取り専用にする方法

新しいダッシュボードを保存する際、または後で共有メニューから「閲覧のみ」に設定できます。

新しいダッシュボードを保存する際

• ダッシュボードを作成し、「保存」をクリックします。

• 「新しいダッシュボードとして保存」モーダルで、「権限」を探します。

• 「編集可能」から「閲覧可能」に変更します。

• ［保存］をクリックします。これで完了です。他のユーザーにとっては閲覧専用となります。

既に所有しているダッシュボードの場合

• ダッシュボードを開いてください。

• 「ダッシュボードを共有」メニューを開きます。

• 共有モーダルで、「権限」を見つけて「閲覧可能」に切り替えます。変更はすぐに適用されます。そのスペースの他のユーザーは、編集や削除ができなくなります。

• 共有アクションにマウスを合わせると、特定のダッシュボードが持つ権限の種類を確認できます。

どのダッシュボードがロックされているかを確認する

メインのダッシュボードリストでは、編集または削除できないダッシュボードの選択用チェックボックスは無効化されています。これにより、閲覧専用の項目を簡単に見分けられます。

ダッシュボードでは、編集アクションも無効になっており、ツールチップが表示され、ダッシュボードが閲覧専用に設定されていることが説明されます。

試してみる

読み取り専用ダッシュボードが利用可能になりました。ダッシュボードを作成し、「閲覧可能」に切り替えて共有します。チームは信頼できる唯一の情報源を得ることができ、あなたは安心感を得られます。タイトルに「編集しないでください」という文言を入れる必要はもうありません。

読み取り専用ダッシュボードをどのように活用されているか、ぜひお聞かせください。コミュニティフォーラムでご意見をお聞かせください。

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

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（データソースの切り替え用）のような特定の演算子では使用できません。幸い、当社はこれらの機能を追加するために積極的に取り組んでいます。

コントロールの今後

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

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

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

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

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

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

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