Confluent Kafkaとは？PlatformとCloudの構成差・ライセンス境界・費用分担を実装視点で解説

Confluent Kafkaとは、Apache Kafkaの原作者が設立したConfluent社が、Kafka本体へ運用・ガバナンス機能を束ねて配布している商用ディストリビューションの通称です。自分のサーバへ入れる「Confluent Platform」と、Confluentが運用する「Confluent Cloud」という2つの提供形態があり、どちらを選ぶかで課金の単位も運用の分担も変わる。この記事では、Kafka本体との境目、追加コンポーネントの役割、ライセンスの帰属、自前KafkaやAmazon MSKと並べたときの費用の見え方を、設定と数字の粒度で整理します。採用する条件と見送ってよい場面も条件付きで示しました。

まとめ｜Confluentを採用する判断基準と素のKafkaで足りる条件

Confluentへ寄せる価値が出るのは、スキーマの取り決めを複数チームで共有する必要があるときと、Kafkaクラスタの運用要員を確保できないときの2つです。単一チームが1系統のトピックを流しているだけなら、Apache Kafka本体のままで用が足ります。

判断を分ける軸は3つあります。第一に、追加コンポーネントはApache 2.0・Community License・Enterprise Licenseの3層に分かれており、無償の範囲と契約が要る範囲の境目を先に引かないと、検証環境の構成をそのまま本番へ持ち上げられません。第二に、Confluent Cloudの課金はサーバ台数ではなくeCKUとデータ量で動くため、トラフィックが読めない段階では見積りが振れます。第三に、Confluent Platform 8.0系以降はZooKeeperが外れており、既存クラスタからの移行はKRaft構成への移行を伴います。

費用感でいえば、Confluent Cloudの最小構成は月額ゼロから始められる一方、Standard相当を常時動かすと2026年8月30日時点の公開価格で月385ドルからのeCKU費用に転送料が積み上がる。自前で組めばインスタンス代は安く見えますが、そこへ運用工数が乗ります。

Confluent Kafkaの定義｜Apache Kafkaとの関係

「Confluent Kafka」という製品名は、Confluentの公式カタログには存在しません。検索語としては、Confluentが配布するKafkaディストリビューション全般を指す呼び方として定着しています。中身は、Apache Kafkaという素の分散ログへConfluent製のコンポーネント群を同梱したパッケージです。Kafka本体の役割や用途はApache Kafkaの特徴とメリットの解説で扱っているため、ここではConfluentが足した部分に絞ります。

confluentinc/cp-kafkaとcp-serverの違いとイメージ選択の基準

コンテナで検証を始める人が最初に当たるのが、Docker Hubに並ぶconfluentinc/cp-kafkaとconfluentinc/cp-serverの2つです。この選択がライセンスの分岐点そのものになっています。

手元のdocker-composeがcp-kafkaなら、その構成はCommunity側で完結しています。cp-serverへ差し替えた瞬間、Tiered StorageやSelf-Balancing Clustersが使える状態になり、本番利用には契約が要る領域へ入る。検証段階でどちらを触っていたかは、設計レビューの前に確認してください。

Confluent PlatformとConfluent Cloudという2つの提供形態

提供形態は大きく2系統です。Confluent Platformは、ダウンロードして自社のサーバやKubernetesクラスタへ展開する自己管理型。Confluent Cloudは、Confluentがブローカーごと運用するマネージド型で、いわゆるKafka as a Serviceに当たります。

両者の機能は一致しません。Platform側にしかないもの（オンプレミスへの配置、ネットワークの自己管理）と、Cloud側にしかないもの（自動スケール、稼働率保証）があります。Cluster Linkingで両者をつなぐハイブリッド構成も選べますが、その機能自体がEnterprise Licenseの対象です。

Confluent Platformの構成コンポーネント｜Kafkaへ何が足されているか

Confluent Platformを展開すると、Kafkaブローカーのほかに複数のプロセスが立ち上がります。公式ドキュメントが挙げる主要コンポーネントは、Schema Registry、Kafka Connect、ksqlDB、Kafka Streams、Control Center、REST Proxy、Tiered Storage、RBACなどです。

Schema Registryが解くのはトピックの取り決め崩れという運用課題

Confluentを選ぶ理由として実務で最も効くのがSchema Registryです。Kafkaのトピックはバイト列を運ぶだけなので、生産側がフィールドを1つ削れば消費側のデシリアライズが落ちる。Schema RegistryはAvro・JSON Schema・Protobufのスキーマを一元管理し、REST経由で登録と取得を担います。

実装上の勘所は互換性モードの指定です。BACKWARDなら新しいスキーマで古いデータを読めることが保証され、フィールドの削除は通るが必須フィールドの追加は弾かれる。FORWARDはその逆で、FULLは両方を要求します。既定値のまま流すと、生産側のリリースが消費側を巻き込んで止まる事故が起きます。スキーマの保存先はKafkaの内部トピックで、Registry自体は状態を持ちません。

Kafka ConnectとksqlDBが担う入出力とストリーム処理

外部システムとの接続はKafka Connectが担います。これはApache Kafkaに含まれる仕組みで、Confluent側の付加価値はコネクタの品揃えと管理機能です。コネクタの構成要素や運用の勘所はKafka Connectの解説記事に譲ります。Confluent Hubのコネクタにはオープンソースと商用が混在する点だけ押さえてください。

ksqlDBは、SQLに似た構文でストリームとテーブルを定義し、結合や集計を宣言的に書けるコンポーネントです。自前でKafka Streamsを書く手間は省ける一方、内部ではKafka Streamsが動くため、ステートストアの容量やリバランスの挙動は同じ制約を受けます。

8.0系で刷新されたControl Centerとメトリクス基盤

Control Centerは、トピックやコンシューマラグを画面から追える管理UIです。素のApache Kafkaに対して無償で同種の画面を用意する選択肢は、Kafka UIとKafbat UIの解説で整理しています。Confluentのブログを2026年8月30日に確認した時点では、8.0系でメトリクス基盤がPrometheusベースへ組み替えられ、反映が2〜3分以内、扱えるパーティション数が最大40万、起動が1分以内という数字が示されていました。旧構成では起動に15〜50分かかる規模もあったとされます。

あわせてConfluent Manager for Apache Flink（CMF）がControl Centerへ統合され、KafkaとFlinkの管理画面が1か所へ寄りました。ストリーム処理をFlinkで組む構成なら、運用画面の分散が減ります。

ライセンス境界｜Apache 2.0・Community・Enterpriseの線引き

機能一覧より先に確認すべきはライセンスの帰属です。「無償でダウンロードできる」と「そのまま本番で使ってよい」は別の話になります。

Community Licenseで引っかかるのは他社へ提供する構成だけ

Community Licenseの制約は、公式FAQでは「Excluded Purpose」として定義されています。禁じられるのは、Schema RegistryやksqlDBをホスティングサービスとして第三者へ提供し、Confluent自身の製品と競合する行為です。自社の業務システムへ組み込む、改変する、自社製品の一部として再配布する。これらは許可されています。

SaaSを提供する企業が、その基盤としてSchema Registryを使うこと自体は問題になりません。引っかかるのは「Schema Registryそのものをサービスとして売る」ケースだけです。

Enterprise Licenseの対象がそのままConfluentを買う理由になる

一方、Enterprise License側の顔ぶれには、Confluentへ費用を払う理由がそのまま並びます。Tiered Storageは古いセグメントをオブジェクトストレージへ逃がしてブローカーのディスクを軽くする機能、Cluster Linkingはクラスタ間をブローカーレベルで複製する機能、RBACは役割ベースの権限制御です。

いずれも自前運用で規模が大きくなったときに欲しくなる領域を突いています。逆にいえば、これらが要らない規模ならCommunity版でも組めます。検証環境の構成を本番設計として固める前に、どの機能が契約側にあるかを一覧化しておいてください。

Confluent Cloudの課金単位｜eCKUとクラスタタイプの選び分け

Confluent Cloudはサーバ台数で課金しません。eCKU（Elastic Confluent Unit for Kafka）という論理的な処理単位の時間課金へ、データ転送量とストレージ量が積み上がる構造です。公開価格ページを2026年8月30日に確認した時点の数値を並べます。

月額の目安はBasicがゼロ、Standardが385ドル、Enterpriseが895ドル、Freightが2,300ドルからです。Basicはストレージ上限が5TBなので、それを超える保持期間ならStandard以上へ移ります。

スループットが読めないうちはBasicで測ってから型を決める

この価格構造で誤りやすいのが、パーティション数を先に決めてしまう設計です。Basicの1,500という上限は、トピックを細かく切る設計だと意外に早く届く。一方でEnterpriseの96,000という枠は、単一チームの用途では持て余す規模でしょう。

実務では、Basicで実データを数週間流し、eCKU消費とData In/Outの実測値を取ってから型を選ぶ順序を推奨します。eCKUは需要に応じて伸縮するため、ピーク時の消費が読めれば月額の上限も見積もれる。Freightは転送料と保管料が最も安い代わり、最小2単位の固定費と高いレイテンシ許容が前提で、ログ集約のような用途に向きます。

Dedicatedクラスタを選ぶのは専有とネットワーク要件が出たとき

上記4タイプとは別に、CKU単位で容量を専有するDedicatedがあります。プライベートネットワーク接続や自社管理の暗号鍵、完全な分離といった要件が出た段階で候補に入る型です。

自前Kafka・Amazon MSKとの費用と運用分担の比較

Confluent Cloudの見積りが妥当かは単体では判断できません。同じワークロードを自前のKafkaクラスタで持つ場合、Amazon MSKのようなマネージドKafkaで持つ場合と並べて、費用と運用分担の両方を見ます。

誰がブローカー障害とバージョン追随を見るかで運用工数が決まる

見落とされがちなのがパーティション再配置の行です。自前運用でもMSKでも、ブローカーを増やしたときの再配置は自社の作業として残る。深夜の再配置を何回避けられるかが、マネージドサービスの実質的な価値になります。

MSKとConfluent Cloudは課金の軸が違い単純比較にならない

AWSの公開価格を2026年8月30日に確認した時点では、MSK ProvisionedのStandardブローカーがkafka.m5.largeで0.21ドル毎時、kafka.m7g.largeで0.204ドル毎時、ストレージが0.10ドル毎GB月でした（いずれも米国東部の表示価格）。Expressブローカーはmsk.m7g.largeで0.408ドル毎時に取り込み0.01ドル毎GBが加わり、Serverlessはクラスタ0.75ドル毎時・パーティション0.0015ドル毎時・データイン0.10ドル毎GB・データアウト0.05ドル毎GBという構成です。

Confluent Cloudの表と並べると、課金の軸そのものが違います。MSK Provisionedはインスタンス時間で積み上がるため、トラフィックがゼロでも台数分の費用が発生する。対してConfluent CloudのBasicは、流していなければeCKU消費が抑えられ、データ量が増えるほど転送料の単価差が効いてきます。MSKの料金構造と使い方はAmazon MSKの解説記事で扱っています。

結論として、小規模で断続的なワークロードはConfluent CloudのBasicが有利になりやすく、常時高スループットならMSK ProvisionedやExpressのほうが費用を読みやすい。どちらで組むにせよ、トピック設計とスキーマ設計を先に固めないと見積りは動き続けます。設計段階から並走が必要なら、データ分析基盤構築・MLOps構築支援のような外部の設計支援を挟む手もあります。

Confluentを採用する条件と、Kafka本体のままでよい場面

ここまでの整理をもとに、判断を言い切ります。

Confluentを採用する条件はスキーマ共有と運用要員と規制要件

Confluentへ寄せる判断が正しくなるのは、次のいずれかに当てはまるときです。

第一に、生産側と消費側が別チーム・別リリースサイクルで動き、トピックのスキーマを取り決めとして固定する必要がある場合。Schema Registryと互換性モードの組み合わせが直接効きます。自前で同等の仕組みを作ると、レジストリの可用性まで面倒を見ることになるでしょう。

第二に、Kafkaの運用を担える人員を確保できない場合。ブローカーを立てるだけなら簡単ですが、パーティションの偏り、コンシューマラグ、リバランスの嵐といった症状に慣れた人がいないと障害のたびに手が止まる。Confluent Cloudはこの領域を丸ごと引き受けます。

第三に、フィールド単位の暗号化や監査ログが規制で要求される場合。8.0系で一般提供へ移ったClient-Side Field Level Encryptionはメッセージ内の個別フィールドを暗号化する仕組みで、金融・医療・公共の要件に直接応えます。

見送ってよいのは単一チームが単一系統のトピックだけを扱う構成

一方、次の場合はApache Kafka本体のままで足ります。単一チームが自分で作って自分で読むトピックしか持たない構成では、Schema Registryの投資対効果が出ません。互換性の取り決めはコードレビューで足りるからです。

また、JVMを含む運用そのものを軽くしたいなら、Confluentへ行くよりRedpandaのようなKafka互換ブローカーを検討する道もあります。プロトコル互換を保ちながら構成を単純化する、Confluentとは異なる解き方です。

既存のKafkaクラスタから移行するときに踏みやすい2つの落とし穴

既存のKafkaクラスタからConfluent Platformへ寄せる場合、版の境目に注意点が2つあります。

1つは、8.0系がApache Kafka 4.0をベースにし、ZooKeeperが完全に外れている点です。既存クラスタがZooKeeper構成なら、移行はKRaft構成への移行を伴う。工程と切り戻しの境界はKafka KRaftの移行解説で扱ったとおり、ファイナライズを越えると戻れません。Kafka 2.1未満のクライアントもサポート対象から外れるため、接続するアプリ側の棚卸しが先に要ります。

もう1つは、リリースノートに記載された個別の不具合です。公式ドキュメントを2026年8月30日に確認した時点では、Kafka 4.3をベースとする8.3系のうち8.3.0にRocksDBステートストアのメモリリークがあり、リバランスやエラー復旧でオフヒープメモリが伸び続ける可能性が示されていました。8.3.2以降で修正されたとされるため、Kafka StreamsやksqlDBを本番で回すならパッチ版まで含めて版を指定してください。サポート期間もCommunity版が1年、Enterprise版が3年と差が出ます。

よくある質問

Confluent KafkaとApache Kafkaは別物ですか

別物ではありません。配布物の中核はApache Kafkaそのもので、そこへSchema RegistryやControl Centerを同梱した形です。プロトコルもクライアントも共通なので、Apache Kafka向けのコードはそのまま動きます。

Confluent Platformは無償で本番利用できますか

コンポーネント次第です。Kafka本体・Connect・StreamsはApache 2.0、Schema Registry・ksqlDB・REST ProxyはCommunity Licenseで、自社利用なら費用は発生しません。Control CenterやTiered Storage、RBACはEnterprise Licenseの対象なので、本番で使うには契約が要ります。

Kafka as a Serviceとして使うならどのクラスタタイプから始めるべきですか

実測が取れていない段階ならBasicです。初回のeCKUが無料で、パーティション上限1,500・ストレージ上限5TBの範囲なら検証から小規模本番まで通せます。実績を数週間ためてから上位の型へ上げると見積りが安定するでしょう。

confluentinc/cp-kafkaイメージはどのライセンスで動きますか

confluentinc/cp-kafkaはCommunity版の構成に対応するイメージで、Apache 2.0のKafkaブローカーにConfluentのパッケージングを施したものです。商用機能を含むconfluentinc/cp-serverとは別物なので、無償の範囲で組むなら前者を指定します。docker-composeのサンプルには両方が混在するため、コピー元の確認が必要です。

Confluent CloudからAmazon MSKへ移ることはできますか

技術的には可能です。どちらもKafkaプロトコル互換なので、クライアント側の接続先と認証方式を差し替えれば通信は成立する。ただしSchema Registryに預けたスキーマ、ksqlDBのクエリ、Confluent固有のコネクタ設定は移行対象として残ります。

関連記事

• Apache Kafkaが選ばれる理由とは？特徴とメリットを徹底解説：Kafka本体の構成要素と用途を先に押さえられます。
• Kafka Connectとは？構成要素とコネクタ運用を実装視点で解説：外部システム連携の設計と運用の勘所をまとめています。
• Amazon MSKとは？仕組み・料金・使い方とKafka自前運用との違いを解説：AWS側のマネージドKafkaと費用構造を比較できます。
• Kafka KRaftとは？ZooKeeper廃止後の構成と移行手順を実装視点で解説：8.0系以降で前提となるKRaft構成への移行工程を扱っています。
• Redpandaとは？Kafka互換ブローカーの構造・ライセンス・採用判断：Confluent以外の商用選択肢との比較検討に使えます。
• Azure Event Hubsとは｜Kafka互換ストリーミング基盤の仕組みと採用判断：Azure側でKafka互換エンドポイントを使う構成の検討材料です。