Kibana Dashboards API：GA前に50以上のチームでテストされた、あらゆるパネルタイプに対応する安定した仕様

KibanaのDashboards APIとVisualizations APIは、Elastic 9.5で本番環境に対応しており、すべてのサブスクリプションティアで利用可能で、完全な下位互換性も備えています。ダッシュボードをJSONとして定義してGitにコミットし、継続的インテグレーションと継続的デプロイメント（CI/CD）パイプライン、Terraform、またはすでにお持ちのツールを使って環境全体にデプロイします。9.4のテクニカルプレビュー期間中に50以上のチームがAPIをテストし、中には既に本番環境で運用しているチームもあります。バージョン9.5ではタグ用の新しいエンドポイント（テクニカルプレビュー中）が追加され、マークダウンおよびリンクパネルエンドポイントはElastic Cloud Serverlessで利用可能となり、9.6でリリース予定です。

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

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

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

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

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

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

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

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

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

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を使用してメトリックパネルを含むダッシュボードを作成する簡単な例を示します。ライブラリに保存されたスタンドアロンの可視化を作成する場合も、同じロジックが適用されます。

PUT kbn:/api/dashboards/service-health-overview
{
  "title": "Service health overview",
  "description": "Key service metrics — managed via API",
  "tags": [
    "production",
    "sre-team"
  ],
  "panels": [
    {
      "type": "vis",
      "grid": {
        "x": 0,
        "y": 0,
        "w": 12,
        "h": 8
      },
      "config": {
        "title": "Error rate (5xx)",
        "type": "metric",
        "data_source": {
          "type": "esql",
          "query": "FROM logs-* | WHERE http.response.status_code >= 500 | STATS error_rate=count(*) BY host.name"
        },
        "metrics": [
          {
            "type": "primary",
            "column": "count"
          }
        ]
      }
    }
  ]
}

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

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

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

注

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