2026.08.26 データベース

ElasticsearchとKibanaの連携｜接続設定とデータビュー定義・可視化の作り分け・権限分離の実務

ログインは通るのにDiscoverに1件も出ない、開発環境では見えるのに本番だけ見えない。KibanaとElasticsearchの連携でつまずく箇所は三つしかありません。プロセス同士の接続方式、インデックスと画面をつなぐデータビューの定義、そして機能権限とインデックス権限という二層の許可です。9.5系（2026年8月時点）の公式記述に沿って、この三層の決め方と切り分けの順序を実装目線で整理しました。

まとめ：着手前に決めておく接続と権限の6つの値

接続方式と権限設計は、後からの組み直しで手戻りが大きくなります。次の6点を先に決めてください。

接続方式：初回はenrollmentトークン、恒久運用は elastic/kibana のサービスアカウントトークン
認証情報の置き場：kibana.yml へ平文で書くか、kibana-keystore へ退避するか
データビューの粒度：インデックスごとに切るか、ワイルドカードで束ねるか
時刻フィールド：どれを時間フィルタの軸にするか
可視化の作成先：レガシーエディタを避け、LensとES|QLへ寄せる
権限の二層：機能権限とインデックス権限をどう組み合わせるか

結論から言えば、検証環境はenrollmentトークンで一気に通し、本番はサービスアカウントトークンをkeystoreへ入れる形が扱いやすい構成です。権限は viewer と editor で足りる案件が多く、行や列を隠す必要が出た時点でPlatinum以上のライセンス判断が発生します。データの入り口側はElasticsearchのログ収集とELKスタックの設計で扱うため、本記事は誰にどう見せるかだけを持ちます。

接続の三方式｜enrollmentトークン・サービスアカウントトークン・利用者資格情報

接続は認証情報の渡し方が三通りあります。選び方で初回の手間と運用時の作業量、資格情報の漏れやすさが変わります。

初回起動のenrollmentトークン｜30分の有効期限と6桁の確認コード

セキュリティ機能が有効なクラスタへ初めてKibanaを繋ぐとき、Elasticsearch側で発行するenrollmentトークンを使う経路があります。発行は次のコマンド1本です。

bin/elasticsearch-create-enrollment-token -s kibana

scope に指定できる値は node と kibana の二つ。有効期間は発行から30分だけです。初期設定画面へ貼ると、クラスタのセキュリティ設定が適用され、組み込みの kibana サービスアカウントで認証し、必要な設定が kibana.yml へ書き込まれます。途中で求められる6桁の確認コードは、Kibanaの起動時に表示されたコードを写す操作です。

長所は、TLS証明書の指定を含めて設定が自動で書かれる点。短所は有効期限で、手順を追いながら作業していると30分は意外と早く尽きます。切れたら同じコマンドで再発行すれば済みます。検証環境の立ち上げはElasticsearchのDocker構築とcompose定義にまとめました。

恒久運用はサービスアカウントトークン｜keystoreへ退避する手順

本番環境で持たせるべきは、期限のないサービスアカウントトークンです。事前定義のサービスアカウントは elastic/fleet-server と elastic/kibana の二つで、後者が「KibanaがElasticsearchと通信するために使うもの」と公式に定義されています。発行はREST APIです。

POST /_security/service/elastic/kibana/credential/token/kibana-prod-01

エンドポイントは namespace と service とトークン名を並べる形で、namespace が elastic、service が kibana にあたります。返ってきた値を kibana.yml の elasticsearch.serviceAccountToken へ設定すれば、username と password の組を置き換えられます。

CLIの elasticsearch-service-tokens でも作れますが、公式はRESTを推しています。理由は保管場所の差です。CLIで作ったトークンは $ES_HOME 配下のconfigへ生成される service_tokens ファイルへ書かれるため、ノードごとに配る運用になります。RESTで作ったトークンは .security インデックスへ保管されるので全ノードから使え、バックアップにも含まれる仕組み。ノードを足すたびに配る作業を残したくないなら、RESTを選んでください。トークンは次のコマンドでkeystoreへ入れ、設定ファイルからは行ごと消します。

bin/kibana-keystore add elasticsearch.serviceAccountToken

サービスアカウントは通常のロールを持たず、プリンシパル名を冠したロールディスクリプタで権限が決まります。elastic/kibana へ余計な権限を足す設計は成り立たず、利用者側の権限は別の層で組みます。

kibana.ymlで最低限埋める設定と、既定値のままでよい項目

kibana.yml で押さえる設定は多くありません。既定値を知っておくと、書かなくてよい行と書くべき行の区別がつきます。次の表は elasticsearch. の接頭辞を省いたものです。

設定	既定値	書き換えを検討する場面
hosts	[“http://localhost:9200”]	別ホストや複数ノードへ繋ぐとき
serviceAccountToken	記載なし	トークン方式にするとき
username / password	記載なし	トークンを使わない構成
requestTimeout	30000	重い集計で待ちが足りないとき
server.port	5601	他プロセスと衝突するとき
server.publicBaseUrl	記載なし	プロキシ配下で公開URLが違うとき

自己署名や社内CAでTLSを張る構成では、これに elasticsearch.ssl.certificateAuthorities が加わります。実務で漏れやすいのは server.publicBaseUrl。空のままだと、レポートやアラートの通知に埋め込まれるリンクが期待どおりになりません。requestTimeout の既定30000ミリ秒は、長期間を横断する集計を載せると足りなくなる場面もあります。値を伸ばす前に、集計側の期間やインターバルを見直す順序をおすすめします。Elasticsearch側でどこまで詰められるかはElasticsearchのチューニングとメモリ配分・シャード設計で扱っています。

データが見えない原因の大半はデータビュー｜インデックスと画面をつなぐ定義

ログイン画面まで出たのにDiscoverに何も表示されない、という相談で最も多い原因がデータビューの未定義です。データが入っていることと、Kibanaがそれを見に行けることは別の話になります。

データビューの作り方と、時間フィルタの軸にする時刻フィールドの決め方

データビューは、1つ以上のインデックス・データストリーム・インデックスエイリアスを指す抽象層です。分析機能はこの定義を経由してElasticsearchのデータへ到達します。指定するのは、対象を表すパターンと、時間フィルタの軸になるタイムスタンプフィールドの二つ。パターンには filebeat-* のようなワイルドカードが使えます。

日付でインデックスを割っている構成なら、ワイルドカードで束ねるのが素直な形でしょう。逆に、業務検索用のインデックスとログ用のデータストリームを混ぜると、フィールドの衝突で型が競合します。用途が違うものは分けてください。型の競合を避けるフィールド定義の決め方はElasticsearchのマッピング設計を参照してください。中身を一度見たいだけなら、保存せずに探索する Use without saving が向きます。参照させるものだけ保存し、命名を「用途-環境」の形へ揃えると運用が荒れません。

時刻フィールドの選択は後から効いてきます。既定の時刻フィールドを持たないデータビューでは、ダッシュボード全体にかかる時間フィルタが使えません。時系列でないマスタデータなら「時間フィルタを使わない」を選んで構いませんが、ログや計測値を扱うなら @timestamp を必ず指定します。

ランタイムフィールドを足してよい場面と、インデックス側へ寄せる判断

データが入ったあとで「この文字列から一部を切り出した列がほしい」となったとき、再取り込みをせずに済ませる手段がランタイムフィールドです。クエリ時に評価される計算フィールドで、インデックスが小さくなり取り込みも速くなります。

ただし公式は、Kibanaのパフォーマンスへ影響しうる点を明記し、頻繁に検索するフィールドはインデックス側へ持たせるよう促しています。線引きはこう。一時的に切り出す列や、月に数回しか触らない列はランタイムフィールドで足す。ダッシュボードの主要なフィルタやターム集計の軸になる列は、マッピングを直して取り込み直す。切り出しを入り口側へ寄せるなら、Logstash grokフィルターの使い方で扱う整形段階で確定させます。

Discover・Lens・ダッシュボードの作り分け｜どの画面で何を確定させるか

Kibanaは似たことが複数の画面でできるため、順序を決めないと同じ集計を作り直すことになります。Discoverで仮説を確かめ、Lensで見せ方を決め、ダッシュボードで並べる一方向の流れに置いてください。

Discoverは仮説の確認に使う｜表示列の固定と保存クエリの残し方

Discoverは生のドキュメントを条件付きで並べる画面です。やるべきなのは、狙ったドキュメントが取れているか、値が想定どおりに入っているかの確認に限られます。表示列を絞り、フィルタを足し、時間範囲を動かして件数の変化を見る。この段階で集計軸に使えるフィールドが確定します。

確認できた条件は保存クエリとして残すと、可視化を作る段で組み直さずに済むでしょう。値が想定と違う場合、原因は取り込み側にあることがほとんどです。keyword ではなく text になっていてターム集計が効かない、といった型の問題はElasticsearchとは？転置インデックスとシャード設計で扱うマッピングの層へ戻って直します。

9.0で新規作成が止まったレガシーエディタ｜LensとES|QLへの寄せ方

可視化の作り方は9.0で整理が入りました。TSVBとAggregation-basedの新規作成の導線が、ダッシュボードメニューとVisualizeライブラリメニューから削除されています。既存のものは閲覧・編集・複製が可能なので、動いているダッシュボードが即座に壊れるわけではありません。ただしレガシーエディタ（TSVB・Aggregation-based・Timelion）は10.0での完全削除が計画されており、新規はLensかES|QLへ寄せる判断が妥当でしょう。

移行の負担は思うほど大きくありません。Aggregation-basedの可視化はLensで開くと、全設定項目がLensのエディタ側に現れます。開いて保存し直すだけで移せるものも相当数あるはずです。付随して visualization:colorMapping は削除され、チャート単位のカラーマッピングが代替になりました。棚卸しの単位は可視化オブジェクトで数えてください。1枚に複数のレガシーパネルが載る構成が珍しくないためです。

ダッシュボードへ載せる前に決める保存時間範囲と自動更新の間隔

ダッシュボードは並べる作業に見えて、実際は負荷設計でもあります。保存する時間範囲と自動更新の間隔が、そのまま問い合わせ頻度になるからです。

数秒間隔の自動更新をかけたダッシュボードを常時開きっぱなしにする運用は、パネル数が増えた時点でクラスタを圧迫します。更新間隔は分単位に置き、秒単位の追跡が要る場面だけDiscoverで行うと安定します。時間範囲も保存できるため、開いた瞬間に直近24時間が出る状態にすると操作差が減るでしょう。

Dev Toolsでのクエリ検証｜画面で詰まったときに切り分ける順序

画面で結果が出ないとき、原因が権限かクエリかデータかを最短で切り分ける場所がDev Tools Consoleです。直接APIを叩けば、Kibanaの画面層を挟まずに判定できます。

kbn:プレフィックスとcurl書き出し｜画面の裏側を再現する

ConsoleはElasticsearchのAPIに加え、kbn: プレフィックスを付けるとKibanaのAPIも実行できます。データビューや保存オブジェクトの状態を、画面をたどらずに確認できるのが利点。切り分けは次の順に置くと速く終わります。

インデックス一覧のAPIで対象が存在し、ドキュメント数が0でないかを見る
_search で素のクエリが返るかを見る（返らなければ権限かクエリの問題）
kbn: 付きでデータビューの定義を引き、パターンと時刻フィールドが意図どおりかを見る
それでも画面に出ないなら、Kibanaの機能権限側を疑う

検証したリクエストは、curl・JavaScript・Pythonの形で個別に書き出せます。アプリケーション側へ同じクエリを移植するとき、この書き出しを起点にすると転記ミスが起きません。移植するクエリ本体の構文はElasticsearchのクエリDSLの書き方を参照してください。レスポンスはJQ式や正規表現で絞り込めます。

変数とヒストリで検証の再現性を上げる、Consoleの無効化設定

Consoleは変数名を波かっこで囲む再利用変数を定義できます。インデックス名や日付を変数へ逃がすと、環境を切り替えながら同じ検証を回せるでしょう。直近500件のリクエストはHistoryタブから呼び戻せ、書式を保ったままTXTへ書き出せるため、検証手順を成果物として残せます。本番で利用者に触らせたくない場合は、kibana.yml の console.ui.enabled を false にすると機能ごと無効にできます。

権限分離の設計｜Kibana機能権限とElasticsearchインデックス権限は別物

連携で最後に詰まるのが権限です。二層構造だと理解していないと、「ロールを付けたのにDiscoverが空」の原因にたどり着けません。

機能権限だけを付けると画面は開くのに空のDiscoverになる

Kibanaの権限は、画面や機能へのアクセスを制御するものです。基本権限の all（読み書き全部）と read（読み取りのみ）は全機能へ一括で適用されます。細かく決めたい場合は機能権限を使い、Discover・Dashboard・Visualize といった機能ごとに all と read を個別に付けます。一部の機能はサブ機能権限で細分化できますが、こちらはサブスクリプション機能です。

押さえるべきは、機能権限が「画面を開けるか」しか決めていない点。表示するデータはElasticsearchから取るため、対象インデックスへの読み取り権限が別途要ります。Discoverの機能権限だけを付けた利用者は、画面は開けるがデータは1件も出ない状態になるわけです。データビューを作らせるなら、Kibana側の Data View Management とElasticsearch側の view_index_metadata の両方が必要。片方だけだと読み取り専用の表示になり、作成・保存のボタンが現れません。

スペースで画面を割る設計と、組み込みロール4種で足りる範囲の差

見せる画面を部署で分けたい場合はスペースを使います。割り当てはスペース単位で対象を指定できるため、「営業では read、基盤チームでは all」といった設計が組めます。スペースとロールベースアクセス制御は Free and open – Basic に含まれ、無料の構成でも使えるものです。自前でロールを組む前に、組み込みロールで足りるかを確認してください。

組み込みロール	Kibana側の範囲	データインデックスの範囲
viewer	全機能の読み取り専用	ドット始まり以外の読み取り
editor	全機能へのフルアクセス	ドット始まり以外の読み取り
kibana_admin	全スペースの機能へのアクセス	明示されない（別途付与）
kibana_system	自身のインデックス読み書きと管理	監視は読み取り・レポートは読み書き

viewer は新しいKibana機能がリリースされたとき、その読み取り権限を自動で受け取ります。editor はKibana側がフルアクセスでもデータインデックスは読み取りのみなので、書き込みを伴う機能では追加のロールが要る場面もあるでしょう。kibana_system はKibanaというプロセスのためのもので、一般利用者へ付与しないよう公式が明記しています。

行や列を隠すならPlatinum以上｜無料の範囲で使える代替策

「自部門の行だけに絞りたい」「個人情報のフィールドだけ隠したい」という要件が出たら、ライセンスの話になります。ドキュメントレベルセキュリティ（DLS）とフィールドレベルセキュリティ（FLS）は Platinum と Enterprise に含まれる機能です。Gold は新規受付を終了しているため、実質的にPlatinum以上の判断となります。

無料の範囲で同じ効果を出すなら、インデックスそのものを分けるしかありません。部門ごとに書き込み先を分割し、インデックス権限で読み取り範囲を切る形です。取り込み側で分けるため、収集経路の設計時点でこの要件を織り込む必要があります。命名で保持と権限を割る設計はELKスタックの収集経路とインデックス分割の設計で扱うので、要件が先に見えている案件では収集側から通しで設計してください。

KibanaをElasticsearchと組んで採用してよい条件と、見送る場面

Kibanaは純正の可視化層なので入れて損はないと語られがちですが、実際には向く場面と向かない場面がはっきり分かれます。

採用してよい条件は三つ。第一に、見せたいデータの正本がElasticsearch側にあること。ログや計測値のように、Elasticsearchへ入れること自体が目的のデータなら素直に噛み合います。第二に、利用者が「条件を変えながら自分で掘る」使い方をすること。DiscoverとLensの組み合わせは探索的な分析に強く、定型帳票を配る用途とは相性が違います。第三に、権限の粒度がインデックス単位で足りること。

見送るべき場面も三つ。基幹のデータがリレーショナルデータベース側にあり、Elasticsearchへは検索用の写しだけを置く構成では、集計値の正しさをKibanaで担保しにくくなります。この場合は正本側へ繋ぐBIツールが素直でしょう。次に、部門ごとに行を隠す要件が確定していて、かつライセンス費を積めない場合。インデックス分割で回避できるかを先に検証し、取り込み側の複雑さが許容できないなら別の層で解きます。最後に、利用者が数名という規模では、運用工数を割く価値が出にくい場面もあります。

OpenSearch系なら可視化層はOpenSearch Dashboardsになり、設定名の一部が異なります。系列の選び分けはElasticsearchとOpenSearchの違いで整理しました。可視化レイヤの要件定義から権限設計を含む実装までを外部へ委ねたい場合は、BIツール導入支援で相談を受けています。

よくある質問

Kibanaは必ずElasticsearchと同じサーバへ入れる必要がありますか？

同居させる必要はありません。elasticsearch.hosts に接続先のURLを配列で指定すれば別ホストから接続できます。既定値が localhost の9200番のため同居が前提に見えますが、これは開発時の利便のための既定です。本番では別ホストへ分けるほうが、リソースの取り合いが起きず運用しやすくなります。

enrollmentトークンの有効期限が切れました。作り直して問題ありませんか？

問題ありません。トークンは30分間有効で、切れたら同じコマンドを再実行して新しいものを発行します。既に接続が完了しているKibanaには影響しません。なお恒久運用へ移す段階では、elastic/kibana のサービスアカウントトークンへ切り替えてください。

Discoverに何も表示されません。どこから調べればよいですか？

三点を順に見てください。まずDev Tools Consoleでインデックス一覧を取り、対象にドキュメントが入っているかを確認します。入っているなら、データビューのパターンが対象と一致しているか、時刻フィールドの指定が実際の名前と合っているかを見ましょう。ここまで問題なければ読み取り権限を疑います。機能権限だけを付けてインデックス権限を付けていないと、画面は開けてもデータは出ません。

今から新しい可視化を作る場合、TSVBを使ってもよいですか？

新規はLensまたはES|QLをおすすめします。9.0で新規作成の導線が削除され、レガシーエディタは10.0での完全削除が計画されているためです。既存のTSVB可視化は閲覧・編集・複製が続けられるので、慌てて作り直す必要はありません。Aggregation-basedのものはLensで開くと全設定項目がLens側に現れるため、移行の手間は軽く済みます。

利用者ごとに見せる行を絞りたいのですが、無料のライセンスでできますか？

ドキュメントレベルセキュリティは Platinum と Enterprise に含まれる機能のため、無料の範囲では使えません。Free and open – Basic はロールベースアクセス制御とスペースまでです。同じ効果を出すには、部門や区分ごとにインデックスを分けて書き込み、インデックス権限で読み取り範囲を切ります。取り込み側へ影響するため、要件が判明した時点で収集経路まで戻って検討してください。