By Andrew Tan
混同されがちな2つの事実
Apache Kafkaは今もオープンなプロトコルです。MSKで動かしても、自分で運用するクラスタで動かしても、Redpandaでも、Confluent Platformでも構いません。ワイヤーフォーマットが買収されたわけではありません。
そのプロトコルを商用KafkaスタックのデファクトにしたConfluentという会社は、2026年3月17日以降、IBMの会社になりました。IBMは約110億ドル、1株31ドルで買収しました。初日から語られたストーリーは「我々は独立したKafka企業であり続ける」というものではありませんでした。初日から語られたのはwatsonx.data、IBM MQ、webMethods、そしてIBM Zでした。Streamingを、企業向けAIとエージェントの基盤となるデータプラットフォームとハイブリッド自動化の燃料とする、というメッセージです。
これらを同じ出来事として扱うと、今後18ヶ月間の製品判断を眠ったまま過ごすことになります。これらを分けて考えると、次のベンダーとの会話がずっと実りあるものになります。
実際に買収が完了したもの
既に技術的なKafka比較は書きました。ここでは本質の集中について書きます。
買収完了当日、IBMはプレスリリースのタイトルに自らの主張を盛り込みました。「real-time data as the engine of enterprise AI and agents（リアルタイムデータを企業AIとエージェントのエンジンとする）」。Rob Thomasは「現在進行中の出来事に対してモデルとエージェントが行動する」と語り、当時まだCEOだったJay Krepsは「世界中のデータをIBMスケールで動かす」と語りました。
これは「best Kafka（最高のKafka）」という製品賭けとは全く異なるものです。
Best Kafkaとは、パーティションのリバランス、コネクタの品質、Flinkのパッケージング、クラウドSKU、そしてconsumer lagのページが火曜日に正常に動作するかどうか、といったことです。一方、IBMの賭けとは、Confluent CloudとPlatformがwatsonx、MQ、メインフレームへと引き寄せられることを意味します。Kafkaログは入口に過ぎません。目的地はIBMのAIと統合スイートです。
その賭けを好むこともできます。既にそのスイートの中で生きている企業は多数あります。しかし、それがConfluentが上場企業として売っていたのと同じロードマップであるかのように振る舞うべきではありません。
創業者はいなくなった。プロトコルは残った。
8月13日、Jay Krepsは約12年にわたる役割から退きました。110億ドルの買収後の創業者交代は普通のことです。それは同時に、意思決定の場がどこにあるかを教えてくれます。
これまではMountain Viewで、Kafka企業としての時間軸でロードマップが議論されていました。今はIBM Softwareの中で、watsonxとメインフレームの時間軸で議論されます。コネクタのリリース頻度、クラウドのパッケージング、「サポート」の意味するところは、全てその新しい時計に従います。
具体的なシグナルは10月下旬に現れました。IBMはApache Flink向けwatsonx.data統合を発表し、ビジュアルキャンバスとPython SDKを提供して、Confluent Platform for Apache Flinkにジョブを投入できるようにしました。これはKafkaキラーではありません。IBMがストリーム処理をwatsonx.data製品ラインに包み込んだものです。もしあなたが「独立したストリーミング企業」としてConfluentを買ったのであれば、この文章をもう一度よく読んでください。
私は「製品が悪くなった」と言っているのではありません。Confluent Cloudのテレメトリを見ているわけでもありません。私は「重心が移動した」と言っているだけです。そしてそれは誰にでも公開情報から見て取れます。
Kafkaという言語、IBMという出版社
Kafkaを言語だと思ってください。多くの人がそれを話します。文法はオープンです。IBMはその商業的な方言を教えていた最大の学校、教科書を出版し、カンファレンスの認定ブースを運営していた会社を買いました。
あなたは今もその言語を話せます。その言語を話せる人を雇えます。IBMに1ドルも払わないクラスタを運用できます。
ただし、商業的なデフォルトパス（Confluent Cloud、Confluent Platform、既に標準化したコネクタカタログ）が、Kafkaの独立性を守るために戦うと仮定することはできません。それはIBMのデータ＆AIプラットフォームに従います。watsonx.dataへのデュアルライトが、簡単に離脱できるようにすることよりも優先されるでしょう。
ベンダーは自らの主張に従います。あなたの仕事はその主張が変わったことに気づくことです。
次の四半期レビュー（QBR）で必ず入れるべき3つの質問
「まだKafkaにコミットしていますか？」というスライドは飛ばしてください。当然コミットしています。Kafkaはassetなのですから。
プレスリリースが触れていない運用上の質問をしてください。
向こう2年間のDual-run
IBMがSKUを統合し、コンソールをリブランドし、watsonxのコントロールプレーンに移行させる場合、古いパスと新しいパスが同じ出力を出す期間が必要です。Dual-runは退屈です。しかしベンダー統合を週末のカットオーバーなしで乗り切る方法です。
MQ、Z、倉庫が同じインシデントに巻き込まれた時のReplay
ほとんどのKafkaチームはconsumer groupを巻き戻す方法を知っています。難しいのは混在した場合です。ストリーム、メインフレームのトランザクション、夜間ERPファイル、そして既にクエリされたIcebergテーブルが絡むケースです。IBMの初日図はこれらを1つのファミリーに置いています。しかし火曜の夜のインシデントでは、それらを1つ巻き戻しても他を破壊しない人が必要です。
Batchがまだ第2のオーケストレータを必要としているかどうか
「ファイルはAirflow、トピックはConfluentを使ってください」という答えなら、あなたはプラットフォームを買ったことになりません。ストリーミングスイートを買って、従来の分離を維持しただけです。遅延したファイルと不正なトピックを同じ責任者でリプレイする1つのWorkflowを提示するよう求めましょう。
もしあなたのAEがソリューションアーキテクトを呼ばずに、それらの質問に答えられず、1週間遅れるようなら、それがシグナルです。
買収されなかった問題
IBMはストリーミング企業を買いました。しかしあなたの協調問題までは買っていません。
バッチジョブがウィンドウを逃したのにストリームは動き続けている状況をキャッチアップしなければなりません。3時間分のpoison messageをリプレイしても倉庫に二重書き込みしないようにしなければなりません。slowly changing dimensionをライブトピックと結合しなければなりません。新入社員に金曜の午後にどのシステムがsource of truthかを伝えなければなりません。
これらのどれもKafkaプロトコルの中には存在しません。Confluentコンソールに付いたIBMロゴがこれらを簡単にするわけではありません。むしろ、商用スタックがエージェントとwatsonxに向け直されている一方で、あなたの実際のワークロードが「支払いファイルと不正トピックを一致させる」である場合、一部はより難しくなるでしょう。
この件について落ち着いているチームは、Slackに「Kafkaはオープンソースだから大丈夫」と投稿したチームではありません。彼らは既にブローカーを単なるトランスポートとして扱い、ランタイム（リトライ、依存関係、リプレイ、承認）を自分たちでコントロールできる場所に置いています。
layline.ioの立ち位置
layline.ioでは、Kafkaを話しつつも午後6時にファイルを着地させなければならないチームと一緒に働いています。私たちはKafkaの代替でもIBMの代替でもありません。私たちはバッチとストリーミングの両方に跨って座るランタイムであり、協調作業がストリーミングベンダーのスイートの中に閉じ込められないようにします。
IBMのプラットフォームがあなたにとって正しいホームであるなら、それを使ってください。ただ、「我々は今もKafkaレコードを生成している」ことと「我々の運用モデルは変わっていない」ことを混同しないでください。レコードは同じように見えても、それらを取り巻く重力は同じではいられません。
Confluent CloudまたはPlatformを利用していて、プロトコルへの安心感とベンダーの重心を切り分けようとしている場合は、お問い合わせください。バッチとストリームに跨るdual-runとreplayを、次のリブランドを待たずにマッピングするお手伝いをしています。
Andrew Tan is a serial entrepreneur and founder of layline.io, building enterprise data processing infrastructure that handles both batch and real-time workloads at scale.
