Kafka UIとは？Kafbat UIへの世代交代と権限設計・本番投入の可否を実装視点で解説

Kafka UIとは、Apache Kafkaのクラスタをブラウザから覗いて操作するための管理コンソールです。正式な呼び名は「UI for Apache Kafka」で、トピックの構成、消費者グループの遅延、メッセージの中身といった、コマンドラインでは追いにくい情報を一枚の画面に並べます。ただし2026年8月30日時点でこの名前は二つのリポジトリを指し得る状態にあり、どちらを入れるかで受けられる更新が変わる。この記事では、版の実態、環境変数の粒度での導入手順、そして本番へ入れるときに最初に決めるべき権限設計を、設定値の解像度で整理します。Apache Kafka本体の役割と構成要素は別記事で扱っているため、ここではその外側に置く道具に絞りました。

まとめ｜Kafka UIを本番へ入れる条件と読み取り専用に寄せる判断

先に結論を置きます。Kafka UIを入れる価値が明確に出るのは、複数のチームが同じクラスタのトピックを共有していて、開発者が消費者グループの遅延を自分で確認したい場面です。逆に、単一チームが少数のトピックを回しているだけなら、Kafka同梱のCLIで用が足ります。画面を一つ増やすことは、そこへ認証と権限の設計を一式持ち込むことと同じだからです。

判断を分ける軸は三つあります。第一に版です。長く定番だったprovectus/kafka-uiは最終リリースが v0.7.2（2024年4月10日公開）、リポジトリへの最終pushが2024年7月で止まっており、後継のkafbat/kafka-uiが v1.5系（2026年4月20日公開の v1.5.0 が同年8月30日時点の最新タグ）まで進んでいます。これから入れるならKafbat UI側を選ぶ判断になります。

第二に権限です。既定の起動では認証が無効で、画面を開いた全員がトピックの削除やメッセージの投入まで行えます。本番クラスタへ向けるなら、AUTH_TYPEによる認証、RBACによるロール定義、そして読み取り専用の指定という三点を同時に決める必要がある。第三に運用の分担で、UIはブローカー外のただのクライアントなので、UIが落ちてもデータは失われない代わりに、UI経由の操作は監査の対象として別に記録を設計することになります。

Kafka UIとはブローカーの外に置く読み取り主体の管理コンソール

Kafka UIは、Kafkaクラスタに対して管理APIとコンシューマAPIを叩くだけのWebアプリケーションです。ブローカーへプラグインとして組み込むものではなく、独立したプロセスとして立ち上げ、ブートストラップサーバへ接続します。この構造上、UIを止めてもクラスタの稼働には影響しません。裏返せば、UIが見せている数値はすべてKafka側が持つメタデータの写しであり、UI自身が独自の履歴を長期保管しているわけでもない。

Kafka UIが担う範囲とCLIやコンソールとの役割の分担

Kafka同梱のkafka-topics.shやkafka-consumer-groups.shでも、トピック一覧や遅延の確認は行えます。それでも画面を用意する理由は、調べる人数と調べる頻度にあります。障害の一次切り分けで「どのトピックのどのパーティションで消費が止まっているか」を非管理者が自力で見られるかどうかは、問い合わせの往復回数を直接変えるからです。

一方で、Kafka UIが不得手な領域もはっきりしています。時系列でメトリクスを蓄積して閾値でアラートを飛ばす仕事は、UIではなく監視基盤の担当です。UIは「今どうなっているか」を見る道具で、「いつから崩れたか」を追う道具ではありません。監視基盤側で何をどう測るかはKafka監視の設計にまとめました。両者を混同すると、UIを開いたまま画面を眺める運用に落ちます。

provectus版とKafbat UIのどちらを入れるべきかの判断

検索で出てくる導入記事の多くはprovectuslabs/kafka-uiというDockerイメージを指しています。この表記が古い情報かどうかを見分けるところが、最初の分岐点です。

リポジトリの更新が止まった時期と後継版の版番号を実測で確認する

2026年8月30日にGitHub APIで両リポジトリを確認したところ、次の状態でした。

provectus側のリポジトリはアーカイブ扱いにはなっていないものの、2年以上リリースが出ていません。Kafbat UIは初期からの主要な貢献者が引き継いだ後継で、ライセンスはどちらもApache 2.0のままです。星の数（provectus側で12,272）に引きずられて古い方を選ぶと、Kafka 4.x系のブローカーに対する動作確認済みの版を受け取れないことになります。

provectus版から移し替えるときに変わる三つの設定箇所

既にprovectus版が動いている環境から移す場合、書き換えが要るのは主に三点です。イメージ名をghcr.io/kafbat/kafka-uiへ差し替えること、ZooKeeper接続を前提にしたKAFKA_CLUSTERS_0_ZOOKEEPERの指定が残っていれば外すこと、そして認証まわりのプロパティ名が現行のドキュメントと一致しているかを照合することです。ZooKeeperの指定については、KRaft構成へ移行したKafkaではそもそも接続先が存在しないため、残しておくと起動時に無駄な接続試行を抱えます。

設定ファイルの構造そのものは互換性が保たれているので、環境変数を並べ替えるほどの作業にはなりません。移行の実作業より、移行後に権限設計を見直す時間の方が長くかかります。

導入手順はDocker単体の起動からdocker composeでの常設へ

検証は一行で始められます。ここでは既定ポートである8080番をそのまま使う前提で進めます。

最小構成で起動しブローカーへの接続が通るかを確かめるまでの手順

まず、クラスタ名とブートストラップサーバだけを与えて立ち上げます。

docker run -p 8080:8080 \
  -e KAFKA_CLUSTERS_0_NAME=local \
  -e KAFKA_CLUSTERS_0_BOOTSTRAPSERVERS=kafka:9092 \
  -d ghcr.io/kafbat/kafka-ui

KAFKA_CLUSTERS_0_という接頭辞の末尾の0は配列の添字で、二つ目のクラスタを足すときはKAFKA_CLUSTERS_1_NAMEと続けます。複数環境を一つの画面から見るなら、この添字を増やしていく形になる。画面が開いたら、まずBrokersの一覧にブローカー数が想定どおり並ぶかを見ます。ここが空なら、ネットワーク到達性かリスナー設定の問題で、UI側の設定を疑う段階ではありません。

なお検証段階で設定をブラウザから編集したい場合はDYNAMIC_CONFIG_ENABLED=trueを付けて起動します。この指定は画面からクラスタ定義を書き換えられるようにするもので、後述のとおり本番では外す判断になります。

Schema RegistryとKafka Connectを同じ画面に束ねる指定

実務で価値が出るのは、周辺コンポーネントを同じ画面へ載せたときです。スキーマとコネクタを登録すると、メッセージのデコードとコネクタの稼働状態が同一画面から辿れます。

KAFKA_CLUSTERS_0_SCHEMAREGISTRY=http://schema-registry:8081
KAFKA_CLUSTERS_0_KAFKACONNECT_0_NAME=main
KAFKA_CLUSTERS_0_KAFKACONNECT_0_ADDRESS=http://connect:8083

Schema Registryを登録しておくと、Avroなどで書かれたメッセージが画面上で復号された形で読めます。登録しないままだとバイト列のまま表示されるため、内容を確かめる目的でUIを入れたのに読めない、という状態になりがちです。Connect側を登録すれば、コネクタの状態やタスクの失敗が一覧で見えます。Kafka Connectのコネクタ運用を人手で回している現場では、この一覧があるだけで確認の手数が減ります。

SASLで保護されたクラスタへ接続する場合は、クライアント側のプロパティをそのまま環境変数へ写します。KAFKA_CLUSTERS_0_PROPERTIES_SECURITY_PROTOCOL、KAFKA_CLUSTERS_0_PROPERTIES_SASL_MECHANISM、KAFKA_CLUSTERS_0_PROPERTIES_SASL_JAAS_CONFIGの三つが基本の組です。Amazon MSKのようにIAM認証を使う構成では、加えてコールバックハンドラのクラス指定が要ります。

画面から見えるトピックと消費者グループとメッセージ本文の中身

導入後、実際に使う画面はおおむね三つに収束します。それぞれ何を判断するための画面かを押さえておくと、権限設計の線引きも決めやすくなります。

このうち運用でいちばん見られるのはConsumersです。消費者グループの遅延が単調に増えているなら、消費側の処理速度が生産量に追いついていないか、処理が例外で止まっている。遅延が特定のパーティションにだけ偏っているなら、キーの分布が偏っているか、そのパーティションを担当する消費者だけが不調という読み方になります。UIはこの切り分けを、コマンドを覚えていない人にも渡せる形で提供します。

Messages画面には注意点があります。ここではメッセージ本文が平文で表示されるため、個人情報や決済情報を載せたトピックを扱う場合、閲覧できる人を絞らないまま公開すると、データベースの本番テーブルを全員に見せているのと変わらない状態になる。次章の権限設計は、この一点だけでも先送りできない理由になります。

認証と権限設計として本番投入の前に決めておきたい三つの設定項目

Kafka UIの既定値は検証向けに寄っています。本番クラスタへ向けるときは、認証方式・ロール定義・書き込みの遮断を三点セットで決めます。

AUTH_TYPEで選べる認証方式と社内基盤との接続の考え方

AUTH_TYPEに指定できる値は、DISABLED（認証なし）、LOGIN_FORM（ユーザー名とパスワード）、OAUTH2、LDAPです。値の選び方はそのまま運用の負荷に跳ね返ります。

LOGIN_FORMはSPRING_SECURITY_USER_NAMEとSPRING_SECURITY_USER_PASSWORDで単一の資格情報を与える方式で、設定は最も軽い。ただし共有アカウントになるため、誰が何をしたかを個人まで辿れません。検証環境や、社外へ出ていない閉じたネットワーク内での短期利用に向きます。

OAUTH2とLDAPは、社内の認証基盤に寄せる方式です。GoogleやGitHub、Azure、Cognito、Okta、Keycloakといった提供元に接続でき、既にディレクトリを持っているならLDAPで統合できる。後述のRBACでロールを割り当てるには、利用者を個人やグループとして識別できる必要があるため、権限を分けたいなら実質この二択になります。

RBACのロール定義で操作の権限を資源の単位で切り分ける方法

RBACは設定ファイル側でrbac.rolesとして定義します。一つのロールは、適用先のクラスタ、対象となる利用者や集団、そして許す操作の三要素で構成されます。

rbac:
  roles:
    - name: "readers"
      clusters:
        - prod
      subjects:
        - provider: oauth_google
          type: domain
          value: "example.jp"
      permissions:
        - resource: topic
          value: ".*"
          actions: read

resourceに指定できる区分は、applicationconfig、clusterconfig、topic、consumer、schema、connect、ksql、acl、auditです。actionsはread、write、allから選びます。valueは正規表現で対象を絞れるので、たとえば個人情報を含むトピックだけを名前の規則で除外する、といった線の引き方ができる。

実務での組み立て方としては、開発者ロールにtopicとconsumerのreadだけを与え、運用ロールにconnectのwriteまで許し、clusterconfigとaclは管理者だけに残す、という三層が扱いやすい配分になります。ロールを細かく割りすぎると、権限不足の問い合わせが増えて結局allへ寄せる圧力がかかるため、最初は三層程度から始めて必要に応じて割る方が続きます。

書き込み操作を止めるための読み取り専用の指定と動的設定の無効化

権限を人単位で割る前に、クラスタ単位で書き込みを封じる手もあります。KAFKA_CLUSTERS_0_READONLY=trueを指定すると、そのクラスタに対する変更操作が画面から行えなくなる。本番クラスタを閲覧目的でだけ登録し、変更はすべて構成管理側の手順に通す運用なら、この一行がいちばん確実な防壁になります。

あわせてDYNAMIC_CONFIG_ENABLEDは本番では有効にしないでください。有効なままだと、画面からクラスタの接続定義そのものを書き換えられる状態になり、認証を突破された場合の被害範囲が「見られる」から「別のクラスタへ接続先を差し替えられる」まで広がります。検証環境で使った起動コマンドを本番へ流用するときに、この一行だけ消し忘れる事故が起きやすい箇所です。

本番運用でKafka UIを採用する条件と見送るべき場面の線引き

ここまでの設定を踏まえて、入れる価値が出る条件と、入れない方が総量として軽い場面を切り分けます。

採用してよいのは複数のチームでトピックを共有している開発現場

採用の判断が立つのは、次の三つが同時に当てはまるときです。第一に、Kafkaを触る人数が管理者以外に5人以上いること。問い合わせを受けて管理者がCLIを叩いて返す往復が、週に何度も発生している状態なら、画面を渡す方が総工数で下回ります。

第二に、認証基盤が既にあること。OAuth2かLDAPで既存の身元情報に接続できるなら、権限設計は数時間で組めます。逆にここがないと、UIのために利用者管理の仕組みを別途持つ話になり、投じる手間が見合いません。第三に、メッセージ本文を見せてよい範囲が定義済みであること。トピックの命名規則に機微データの有無が現れていれば、RBACのvalueで機械的に除外できます。

この三条件が揃う現場では、UIの導入そのものは半日で終わります。データ基盤の設計から運用の分担まで含めて外部の手を入れる場合は、データ分析基盤構築・MLOps構築支援のように、基盤の構成と権限の設計をまとめて引き受ける形が実装の手戻りを減らします。

見送ってよいのは単一のチームが少数のトピックだけを回す構成の場合

反対に、見送る判断が妥当な場面もあります。トピックが10本未満で、触る人が2〜3人の管理者に限られ、全員がCLIを日常的に使っているなら、UIを立てても確認手段が一つ増えるだけです。加えて、そのUIには認証・証明書・版の更新という運用対象が付いてきます。守るものが増える割に減る手数が小さい、という判断になる。

もう一つ、マネージドサービス側に管理画面が既にある場合も見送りの候補です。Confluent PlatformにはControl Centerが同梱され、MSKにはAWSコンソール側の画面があります。Redpandaを使っているならRedpanda Consoleが標準の組み合わせです。画面を二重に持つと、どちらの数値を信じるかという運用上の迷いが生まれます。

AKHQとRedpanda Consoleを含めた管理UIの選択肢の比較

Kafka UI以外にも、同じ役目を担う実装があります。2026年8月30日時点の実測値で並べると次のようになります。

選び方の目安を書きます。素のApache KafkaやMSKを使っていて、無償の範囲で権限まで分けたいならKafbat UIかAKHQの二択です。両者の差は画面の作りと設定の記法にあり、機能の重なりは大きい。AKHQは長く運用されてきた分だけ設定例が豊富で、Kafbat UIは画面の応答が軽い傾向にあります。

Redpanda Consoleは、閲覧機能は無償で使える一方、SSOやRBACといった権限まわりが有償のエンタープライズ側に置かれています。Redpandaブローカーと組で使うなら自然な選択ですが、素のKafkaに対して権限分離まで求める用途では、ライセンスの境界を先に確認する必要がある。Control Centerは製品に含まれる以上、Confluentを既に契約しているなら追加の選定作業は要りません。

よくある質問

Kafka UIとKafbat UIは別物ですか？

役割は同じで、系譜が続いています。「Kafka UI」は「UI for Apache Kafka」の通称で、provectus社が公開していたものを、初期からの主要な貢献者がkafbat組織へ引き継いで開発を続けている形です。ライセンスはどちらもApache 2.0で、設定の書き方にも大きな断絶はありません。これから新規に入れるなら、更新が続いているKafbat UI側を選ぶ判断になります。

Kafka UIは無料で商用利用できますか？

Apache 2.0で配布されているため、社内の商用システムの運用に使う分に費用は発生しません。有償版の機能制限やサブスクリプションの区分も設けられていない構成です。ただし無償であることと運用が無料であることは別で、版の更新追従、証明書の管理、権限定義の見直しといった手間は自社側に残ります。

Kafka UIをそのまま監視ツールとして使えますか？

用途が異なります。Kafka UIが見せるのは現在値であり、時系列の蓄積や閾値超過の通知は担いません。消費者グループの遅延を継続的に見張り、一定量を超えたら通知する仕組みが要るなら、Prometheusのようなメトリクス基盤かSaaSの監視サービスを別に置きます。UIは障害発生後の切り分けを速める道具として位置づけるのが実態に合います。

本番クラスタへ接続しても安全ですか？

設定次第で、既定のままでは危険です。認証が無効な状態で本番へ向けると、画面に到達できた人がトピック削除やメッセージ投入まで行えます。少なくともAUTH_TYPEで認証を有効にし、KAFKA_CLUSTERS_0_READONLYで書き込みを封じ、DYNAMIC_CONFIG_ENABLEDを無効にしたうえで、到達経路そのものを社内網やVPN配下へ限定してください。

Kafka UI自体が落ちるとクラスタに影響しますか？

影響しません。UIはブローカーの外側で動く独立したクライアントで、データの流れる経路には入っていないためです。UIが停止している間はブラウザからの確認ができなくなるだけで、生産と消費は動き続けます。この性質があるため、UIの再起動や版の入れ替えは業務時間内でも実施しやすい部類の作業になります。

関連記事

• Apache Kafkaが選ばれる理由とは？特徴とメリットを徹底解説：Kafka本体の構成要素と用途を先に押さえられます。
• Kafka Connectとは？構成要素とコネクタ運用を実装視点で解説：UIのConnect画面が映す対象側の設計をまとめています。
• Kafka KRaftとは？ZooKeeper廃止後の構成と移行手順を実装視点で解説：ZooKeeper指定を外す判断の前提になる構成変更を扱っています。
• Confluent Kafkaとは？PlatformとCloudの構成差・ライセンス境界を解説：Control Centerを含む商用ディストリビューションとの比較材料です。
• Redpandaとは？Kafka互換ブローカーの構造・ライセンス・採用判断：Redpanda Consoleと組で使う構成の検討に使えます。
• Amazon MSKとは？仕組み・料金・使い方とKafka自前運用との違いを解説：IAM認証で接続する場合のマネージド側の前提を確認できます。