Confluent Cloud の新機能：あらゆるスケールであらゆるワークロードに対応するデータストリーミング

理想的なデータストリーミングプラットフォームは、あらゆる種類のデータの動きを、自信をもって処理できるようにします。2026 年最初の Confluent Cloud のリリースでは、あらゆるスケールであらゆるワークロードに対応する Apache Kafka® をフル活用できる環境を提供します。

企業がキューの処理ワークロードをデータストリーミングと統合する場合、小売業がブラックフライデーのような大規模トラフィックの急増に備える場合、スタートアップ企業がリアルタイムデータを活用して AI アプリケーションを運用する場合など、Confluent プラットフォームは多様なデータニーズに柔軟に対応できます。さらに、拡張性の向上、コスト削減、分析機能の強化により、あらゆるワークロードをこれまで以上に簡単に Confluent Cloud に集約して管理できるようになります。

Kafka Copy Paste (KCP) による Confluent Cloud への移行のデモ動画では、Confluent Cloud への移行方法と、これらの新機能を活用する方法を確認できます。

Queues for Apache Kafka® によるキューとストリーミングの統合

Queues for Kafka（KIP-932）が Confluent Cloud で一般提供が開始されました。KIP-932 は Apache Kafka 4.2 のリリースと同時に提供されます。

多くの企業はこれまで2 つの別々のテクノロジー基盤を保持していました。1 つはリアルタイムワークロードのための最新のデータストリーミング基盤、もう 1 つはタスク配分のためのレガシーのキューイング基盤です。その結果、インフラの乱立やガバナンスの分断が発生していました。Kafka にネイティブなキューセマンティクスを導入することで、Queues for Kafka はこれらのプラットフォームを別々に管理する必要性を排除します。企業はメッセージング基盤をガバナンスされた単一でデータストリーミングプラットフォームに統合できるようになります。

Queues for Kafka を活用すると、Kafka と Confluent が提供してきた高い耐久性と拡張性をそのまま維持しつつ、総所有コスト（TCO）も削減できます。

Confluent Cloud における Queues for Kafka

Kafka にキューイング機能をもたらす秘伝のソースは、優れた拡張性をもたらす新しい share group の抽象化、キューセマンティクスを提供する新しい share consumer です。従来の consumer group では、パーティションとコンシューマが 1:1 で厳密に対応するという制約がありましたが、share group では、パーティション数に関係なく、複数のコンシューマが同じトピックのメッセージを協調して処理できます。これにより、突発的で並列性の高いワークロードの要求に応じて、コンシューマを弾力的に拡張できます。

メッセージごとの処理確認、パーティションの並列利用、そしてパーティション数を超える柔軟な拡張性が求められる運用のワークロードやアプリケーションのワークロードには、share group の利用を推奨します。こうしたワークロードの例としては、コマンド実行、サービス間通信、タスク実行、ワークキュー、ジョブ処理などがあります。

Confluent Cloud の Queues for Kafka では、さらに、Confluent Cloud コンソールに専用の share group のユーザーインターフェース（UI）を利用でき、コンシューマの状態やグループ管理を詳細に可視化（オープンソース版にはない機能）します。また、Confluent Cloud は、Metrics API を通じてキュー専用の重要な指標も提供するため、オートスケーリングの判断が可能になります。さらに、Confluent CLI や REST API によるプログラム的な管理と組み合わせることで、本番環境で利用できるキューサービスを、データストリーミングプラットフォームに完全統合して利用できます。

Confluent CloudのQueues for Kafkaを使用すると、次のことが可能になります。

• 従来のメッセージングシステムのワークロードを統合された単一の Kafka プラットフォームへ集約できます。

• Share group によって拡張性を向上できます。コンシューマの動的なスケーリングをパーティションの割り当てから独立させることで、これまで Kafka が抱えていたパーティションベースによる拡張性の制限を解決します。

• 新しい取り組みが可能になります。例えば、ワークの配分やタスクキュー処理パターンなど、従来の Kafka の consumer group では難しかった、または不可能だった処理が可能になります。

• Metrics API を通じて、コンシューマの状態やキュー固有の指標をリアルタイムで監視し、可観測性を向上できます。

Queues for Kafka は現在、Confluent Cloud の Enterprise クラスターおよび Dedicated クラスターで利用可能です。Standard クラスターへの対応は  2026 年後半に予定されています。詳しくはドキュメントを参照するか、qfk-demo をダウンロードして実行してください。また、KIP-932 に関する Apache Kafka コミュニティのディスカッションにもぜひ参加してください。質問がある場合は、担当のアカウントチームまでお問い合わせください。

Kafka Copy Paste で移行をもっとシンプルに

Kafka Copy Paste（KCP） が利用できるようになりました。KCP は、ホスト型 Kafka（将来的にはオープンソース Kafka にも対応）から Confluent Cloud への移行を自動化するために設計された、無料のオープンソース CLI ツールです。この新しい移行ツールにより、従来必要だった多くの手動作業が不要になり、移行プロセス全体が大幅に簡素化されます。その結果、移行期間を数か月から数日へ短縮でき、ほぼゼロダウンタイムのストレスの少ない移行を実現できます。

ワークロードをホスト型 Kafka からフルマネージドでクラウドネイティブなデータストリーミングプラットフォームへ移行することで、大幅なコスト削減と俊敏性の向上が可能になります。KCP を使えば、そのプロセスはこれまで以上に簡単になります。KCP は、ホスト型 Kafka から Confluent Cloud への移行プロセス全体をオーケストレーションします。具体的には次のような機能があります。

1. 検出と計画：KCP は既存の Kafka 環境をスキャンし、クラスター構成の検出、実際の使用状況に基づくコスト収集、Confluent の TCO（総所有コスト）計算ツールに必要な正確な入力データの提供を行います。

2. インフラのプロビジョニング：KCP は、事前設定済みの Terraform スクリプトを生成し、同等の Confluent Cloud クラスター、ネットワーキング、必要な移行インフラストラクチャを自動で構築します。

3. データ移行：KCP は、安全な外部 Cluster Linking を利用したデータレプリケーションをエンドツーエンドで自動化します。また、ACL（アクセス制御リスト）、コネクタ、Schema Registry データなどの関連コンポーネントの変換および移行も自動化します。

4. クライアント移行：近日中に KCP は Confluent Cloud Gateway を活用するようになります。これは クラウドネイティブな Kafka プロキシソリューションであり、移行時のクライアントのカットオーバー（切り替え）をより簡単にします。

GitHub で KCP を確認し、移行ワークショップにて実際の動作を体験ください。また、KCP を使った移行の主要ステップを詳しく解説した詳細なブログもぜひお読みください。

Confluent Cloud における拡張性の向上とコスト削減

Confluent Cloud に、Kafka クラスター向けの新しい機能が導入されました。これにより、コスト効率と予測可能性のバランスを保ちながら、安心してスケールできる環境を実現します。

サーバーレスクラスターの最大 eCKU 設定

運用者は、すべてのサーバーレスクラスタータイプ（Basic、Standard、Enterprise、Freight）において、Elastic Confluent Unit（eCKU） の容量上限を設定できるようになり、コストをより適切に管理できるようになります。チームは、予算を超過するリスクを気にせずに検証やオンボードを進めることができます。

Enterprise クラスターで最大 32 eCKU までスケール可能

主要なクラウド上の Enterprise クラスターは、最大 32 eCKU までオートスケールできるようになりました。これにより、合計 7.5 GB/秒以上のスループットを実現でき、従来の容量の 3 倍以上になります。すべてのクラスターでは、最大 10 eCKU までは数秒での高速スケーリングが引き続き可能です。それを超えるスケーリングについては、オンデマンド方式に切り替わり、eCKU あたり最大 20 分程度かかる場合があります。このように大規模なボリュームで迅速なスケーリングが必要なワークロードがある場合は、アカウントチームにご連絡ください。より高速なスケーリングを有効にできます。

Enterprise / Freight クラスター向け Client Quotas によるコスト削減

Client Quotas が Enterprise クラスターおよび Freight クラスターに拡張されました。これにより、これまで Dedicated クラスターでのみ利用可能だった機能と同等の機能が提供されます。Client Quotas を使用すると、特定のプリンシパル（ユーザーやアプリケーションなど）に対して、インバウンド（ingress）およびアウトバウンド（egress）のスループット制限を正確に設定できます。これにより、さまざまなワークロードを共有リソース上に安全に統合し、コストを最適化できます。

このような ガードレールを設定することで、「ノイジーネイバー問題」（特定のアプリケーションがスループットを独占したり、クラスター全体のパフォーマンスを低下させたりする問題）を防ぐことができます。その結果、マルチテナント環境でもコスト効率を保ちながら、各アプリケーションが安定したパフォーマンスを維持できるようになります。他のアプリケーションでトラフィックの急増が発生しても、それぞれのアプリケーションパフォーマンスは予測可能な状態に保たれます。

Enterprise クラスターでの Fetch‑From‑Follower によるネットワークコスト削減

Fetch-from-follower（KIP-392） は、これまで Freight クラスター向けに提供されていましたが、Enterprise クラスターでも利用可能になりました。Enterprise クラスターで Private Network Interface（PNI） を使用している場合、クライアントを別のアベイラビリティゾーン（AZ）のリーダーレプリカではなく、同じ AZ 内の最も近いフォロワーレプリカからデータを取得するように設定できます。これにより、AZ 間のトラフィックを削減でき、Amazon Web Services（AWS）のネットワークコスト（egress 費用）を大幅に節約できます。

Confluent Intelligence のアップデートによる AI エージェントの加速

昨年、Confluent Intelligence がリリースされました。これは、リアルタイムかつ豊富なコンテキストによって信頼性の高い AI を構築するためのフルマネージドサービスです。この度、Confluent Intelligence に、Streaming Agents の機能拡張、組み込み ML 機能、Model Context Protocol（MCP）サーバーのサポートの新機能が追加されました。これらの新機能により、既存エージェントとの接続、異常検知の精度向上、RAG（検索拡張生成）に使用できるベクトルストアの拡張、ネットワークの安全性向上、Confluent Cloud でのエージェントによるリアルタイムデータアクセスの標準化が可能になります。

Confluent Intelligence の新機能の詳細については、ブログを読むか、以下のデモ動画をご覧ください。

Confluent Cloud for Apache Flink® の多変量異常検知

実際に利用するデータが完璧であることはほぼなく、システムの健全性を把握するためには、複数の指標を相関しなければなりないことが多くあります。そのために、組み込み ML 機能向けの多変量解析による異常検知機能をアーリーアクセスで提供します。

従来のツールは指標を個別に監視するのに対して、多変量解析異常検知では複数の相関する指標を 1 つの統合ベクトルとして扱います。中央絶対偏差（MAD）を用いることで、システムの「本当の正常な状態」を特定し、外れ値を自動で無視しながらも単一の指標をチェックしただけでは見逃してしまう複雑な問題も捉えます。これにより、ノイズを排除し、重要な問題を顧客に影響が出る前に容易に検知・解決できます。

アーリーアクセスにサインアップ

Streaming Agents の A2A 統合

Confluent Cloud の Streaming Agents を使うと、フルマネージドの Apache Flink® と Kafka 上で、イベント駆動型のエージェントをビルド、テスト、デプロイ、オーケストレーションできます。新しく追加された Agent2Agent（A2A）統合（オープンプレビュー） により、Flink から直接 A2A を使って、外部の A2A 対応プラットフォーム（例：LangChain、CrewAI、SAP、Salesforce）のエージェントと通信し、タスクを協働およびオーケストレーションできます。これにより、Confluent の信頼性、再生可能性、可観測性を活かしながら、エージェント間のセキュアで安定した通信を可能にします。

A2A 呼び出しを Streaming Agents に組み込むことで、既存の外部システムやエージェントをイベント駆動型の AI システムに変えることができます。これにより、古いバッチベースのシグナルではなく、最新のビジネス状態に応じて動作するエージェントを構築できます。

さらに豊富な安全なコンテキストを利用可能に

適切なデータとセキュリティをエージェントに提供するため、Confluent は、プライベートネットワークとベクトル検索機能を拡張しました。

厳格なセキュリティ要件に適合しなければならない企業向けに、AWS および Azure のプライベートリンクがモデル推論、外部テーブル、ベクトル検索に対して 一般提供されます。これにより、Confluent Intelligence（Streaming Agents を含む） は、外部データベース、ベクトルストア、REST API に対して、プライベートな VPC 間接続を通じてセキュアにアクセスできます。これにより、厳格なコンプライアンス基準を満たしつつ、顧客情報や業務上の機密データをリアルタイムストリーミングに安全に組み込むことができます。

エージェントが自社独自の専門知識や業務データをさらに活用できるように、Confluent はベクトル検索のエコシステムを拡張し、Azure Cosmos DB と Amazon S3 Vectors を Confluent の外部テーブルおよび検索ファブリックにおけるネイティブ統合されたベクトル検索プロバイダーとして扱えるようになりました。これにより、MongoDB、Elastic、Couchbase、SQL Server、Oracle などと同様に、同一の枠組みの中で利用できるようになります。

Cosmos DB や Amazon S3 Vectors 向けのベクトル検索により、Flink SQL パイプライン内でリアルタイムに最も関連性の高い結果を取得でき、適切なコンテキストに基づいた、シームレスで本番運用可能な RAG（検索拡張生成）を実現できます。

Confluent Cloud でのオープンソース MCP サーバーのサポート

多くのチームは、AI エージェントが Anthropic の MCP（Model Context Protocol）を通じて Confluent Cloud にアクセスする標準化された方法を求めています。しかし、現在は自らが管理するオープンソース MCP サーバーのデプロイに苦労することがあります。この問題を解消するために、Confluent は、オープンソース MCP サーバーを正式にサポートするようになりました。これにより、MCP クライアントが安全に Confluent Cloud のリアルタイムデータ（Kafka、Flink、Tableflow など）にアクセスおよび管理できるようになり、自然言語で操作できるようになります。

これにより、企業は本番環境での運用が可能でベンダーから正式にサポートされる MCP サーバーを利用でき、マルチエージェントシステムの運用負荷を大幅に簡素化できます。

Tableflow の Azure および WarpStream への拡張

Confluent は、Tableflow をより多くのクラウドや環境で利用可能にすることに注力しています。エコシステムのサポートを拡張することで、どのクラウドやアーキテクチャを使用しているチームでも、リアルタイムストリームをワンクリックで実用的なテーブルに変換できるようにします。

この取り組みの一環として、Confluent Cloud で Microsoft Azure 向けの Tableflow が一般提供（GA）となりました。これにより、Kafka トピックを Azure Data Lake Storage Gen 2 上の Apache Iceberg™ または Delta テーブルとしてマテリアライズできるようになり、ストリーミングデータを分析や AI のユースケースに即座に活用できます。利用を開始するには、担当のアカウントチームにお問い合わせください。

トピックをテーブルとして自動的に保存できる Confluent Cloud と同じ仕組みを利用しながら、すべてのデータを自社環境で保持したい場合は、WarpStream Tableflow がゼロアクセスの Bring Your Own Cloud (BYOC) ネイティブアーキテクチャを提供します。これにより、機密性の高い元データは VPC 内でのみ処理・保存され、環境の外に出ることはありません。WarpStream Tableflow は、Confluent Platform、ホスト型 Kafka、オープンソース Kafka などの Kafka 互換ソースからの取り込みをサポートしており、フルマネージドの Iceberg テーブルを作成できます。詳細については、こちらのブログを参照してください。

Additional New Features and Updates

Enterprise / Freight クラスター向けの mTLS 認証

転送データのセキュリティを強化するため、AWS 上の Freight および Enterprise クラスターで相互 TLS（mTLS）認証が一般提供されます。これにより、データを交換する前にクライアントとクラスター間で双方向認証が行われます。この認証の導入方法については、こちらのドキュメントを参照してください。

コネクタのアップデート

フルマネージドの新しいコネクタ

Confluent Cloud でいくつかの新しいフルマネージドのコネクタが追加されました。

AI 支援によるコネクタのトラブルシューティング 

フルマネージドコネクタ向けの AI 支援によるトラブルシューティングを、Confluent Cloud の UI で直接利用できるようになりました。Azure OpenAI によって提供されるこの AI 支援トラブルシューティング機能は、1）コネクタ障害に関する簡明なサマリーと 2）推奨されるステップごとの修復手順を提供します。これにより、サポートチームからの対応を待つことなく、迅速に問題を解決できるようになります。

Azure でのカスタム Single Message Transform（SMT）

カスタム SMT が AWS に加えて Azure でもサポートされるようになりました。これにより、プライベートネットワーク環境のクラスターで、フルマネージドコネクタにカスタム SMT コードをアップロードして実行できるようになります。

Flink のセキュリティと拡張性の強化

組織が安全にスケールできるよう、プール単位の RBAC（ロールベースアクセス制御）を導入しました。これにより、最小権限の原則を Flink ワークロード全体に適用できます。プール単位の RBAC により、管理者は新しい FlinkDeveloper ロールなどの細かい権限を、環境全体ではなく個別のコンピュートプール単位で付与できます。これにより、ユーザーやサービスは自分のロールに関連するワークスペースやステートメントにのみアクセス可能となり、セキュリティリスクを低減できます。

要件が最も厳しいワークロードをサポートするために、コンピュートプールあたりの容量上限が 1,000 CFU まで大幅に拡張されました（限定提供）。これは従来の上限の 20 倍に相当します。これにより、より大規模なワークロードを単一プールで処理でき、データスループットの急増にも対応可能です。ジョブを少ないリソースに統合する場合や、インフラが高トラフィックに確実に耐えられるようにする場合、この上限の増加により、ストリーム処理のニーズに応じてコンピュートリソースを柔軟に拡張できます。詳細については、限定提供プログラムへサインアップしてください。

Confluent Cloud における KIP‑1071 Streams Rebalance Protocol

Confluent Cloud で Streams Rebalance Protocol（KIP-1071）がサポートされました。これにより、ブローカー主導の再バランスシステムが利用可能になり、Kafka Streams アプリケーションの再バランスが より高速で安定し、可観測性も向上します。

• 再バランス時間を 50% 以上短縮し、フェイルオーバーとスケーリングを高速化します。新しいコードのデプロイやインスタンス障害時のダウンタイムを最小化します。

• 一元的なブローカー調整によりパイプラインの暗転性を強化し、再バランスが連鎖してシステムが不安定になる状態や連鎖障害のリスクを排除します。

• Confluent Cloud UI と Metrics API 上で専用のブローカー側指標を使用し可観測性を強化します。これによって、再バランスのパフォーマンスとグループの健全性を直接確認できます。

Streams Rebalance Protocol は、現在 Dedicated クラスターと Enterprise クラスターで利用可能です。Basic および Standard クラスターでの提供は数週間以内に開始される予定です。以下の簡単な操作で、利用を開始できます。

1. アプリケーションが Kafka Streams クライアントライブラリ 4.2 以降を使用していることを確認します。

2. Kafka Streams アプリケーション設定で group protocol プロパティを設定します。

Properties streamsConfig = new Properties();
streamsConfig.put(StreamsConfig.APPLICATION_ID_CONFIG, "my-streams-app");
streamsConfig.put(StreamsConfig.BOOTSTRAP_SERVERS_CONFIG, "your-ccloud-bootstrap-url"); 
// Enable the new streams rebalance protocol
streamsConfig.put(StreamsConfig.GROUP_PROTOCOL_CONFIG, "streams");

をコピーするだけで操作は完了します。その後の処理は、Confluent Cloud がすべて行います。

新しい Confluent Cloud 機能を利用してビルドを始めてみる

Confluent を初めて利用される場合は、Confluent Cloud の無料トライアルにサインアップして最初のクラスターを作成し、新機能を試してください。初めてサインアップするユーザーは400 ドル分のクレジットを受け取って、最初の 30 日間 Confluent Cloud をご利用いただけます。さらに、コード CLOUDBLOG60 を使用すると、追加で 60 ドル分を無料で利用いただけます。

前述の内容は Confluent の一般的な製品の方向性を示すものであり、いかなる資料、コード、または機能の提供を約束するものではありません。記載されている機能や機能性の開発、リリース時期、提供時期、および価格は変更される可能性があります。お客様は、現在利用可能なサービス、機能、および機能性に基づいて購入の判断を行ってください。

Confluentおよび関連するマークは、Confluent, Inc.の商標または登録商標です。

Apache®、Apache Kafka®、Apache Flink®、Flink®、Apache Iceberg™、Iceberg™ およびそれぞれのロゴは、米国およびその他の国における Apache Software Foundation の登録商標または商標です。これらの商標の使用は、Apache Software Foundation による承認や推奨を意味するものではありません。その他すべての商標は、それぞれの所有者に帰属します。