分散メッセージング 2026 — Kafka 3.9 / NATS / Redpanda / Pulsar / RabbitMQ 4 / WarpStream 徹底比較

プロローグ — 「メッセージキュー使いますか?」が変な質問になった時代

2026 年のあるチームの設計会議。

ジュニア:「イベントは Kafka で送ればいいですよね?」 シニア:「トラフィックどのくらい?」 ジュニア:「秒間 100 件です。」 シニア:「...なぜ Kafka?」

この短い会話に 2026 年の全部が入っている。一方には 「メッセージング = Kafka」 というほぼ宗教的な確信があり、もう一方には 「Kafka が要らない仕事に Kafka を使うな」 というベテランのため息がある。その間を NATS、Redpanda、Pulsar、RabbitMQ 4、RocketMQ、WarpStream、Buf Stream が埋めている。

2026 年現在、分散メッセージングは 三つのパラダイム に分かれる。古典的なメッセージキュー(RabbitMQ)、ログ基盤のストリーミング(Kafka 系)、クラウドネイティブの pub/sub(NATS、Pulsar)。さらにその上に 運用モデル の二軸が重なる — ディスク基盤 vs オブジェクトストレージ基盤(WarpStream、Kafka tiered storage)、セルフ運用 vs マネージド。

本記事はその全体地図を一度に整理する。Kafka 3.9 の KRaft 化、WarpStream の S3 上 Kafka、NATS の単一インフラ志向、Pulsar Functions、RabbitMQ 4 の Khepri 化、そして日韓ビッグテックが何をどう使っているかまで。

1 章 · 2026 年の分散メッセージング地図 — Pub/Sub / Queue / Stream の 3 パラダイム

まず用語から。メッセージシステムは通常三つに括られる。

2026 年には境界が曖昧になった。Kafka は queue 風(static membership、share groups)を持ち、RabbitMQ は stream(Streams プラグイン)を加え、NATS は JetStream で persistent stream を獲得し、Pulsar は最初から両方だった。

それでも 選択はパラダイムから 始める。次の意思決定木を勧める。

1. 「一つの作業を一人のコンシューマが処理して終わり」 か? → Queue(RabbitMQ、SQS)。
2. 「同じイベントを複数システムが見る」 か? → Stream(Kafka、Pulsar)か Pub/Sub(NATS)。
3. 「数日〜数年保管して再処理」 が要るか? → Stream + 長期保持(Kafka + tiered storage、Pulsar tiered)。
4. 「秒間数十〜数百件、単純」 → RabbitMQ か NATS Core。
5. 「マルチテナント、マルチリージョン、短い P99」 → NATS か Pulsar。
6. 「AWS のみ、S3 コストで完結したい」 → WarpStream。

Kafka が金槌なら全ての問題が釘に見える。2026 年のベテランは「秒 100 件なら RabbitMQ で十分、運用が 10 倍楽だ」と言う。

2 章 · Kafka 3.9(KRaft default、ZooKeeper 除去)→ 4.0 展望

2024 年の Kafka 3.7 で KRaft が production-ready 宣言、2024 年末の Kafka 3.9 で KRaft が既定 となり ZooKeeper モードは deprecated。そして 2025 年の Kafka 4.0 で ZooKeeper コードそのものが削除 された。

運用への影響は具体的だ。

最小の KRaft 起動。

# Kafka 3.9, single-node KRaft (開発用)
export KAFKA_HOME=/opt/kafka_2.13-3.9.0
$KAFKA_HOME/bin/kafka-storage.sh random-uuid
# 出力: yzs8XK6oR1qV3R-... (CLUSTER_ID)

$KAFKA_HOME/bin/kafka-storage.sh format \
  -t $CLUSTER_ID \
  -c $KAFKA_HOME/config/kraft/server.properties

$KAFKA_HOME/bin/kafka-server-start.sh \
  $KAFKA_HOME/config/kraft/server.properties

production では controller と broker を 分離 する(process.roles=controller vs process.roles=broker)。3 controller + N broker が標準構成。

2026 年現在の中核 KIP。

• KIP-405 — Tiered Storage: 古いセグメントを S3/GCS/HDFS に自動オフロード。hot はローカル SSD、cold はオブジェクトストレージ。保存コスト 1/5〜1/10。
• KIP-848 — Next Gen Consumer Rebalance: コンシューマグループのリバランスをサーバ側に。stop-the-world 時間短縮。
• KIP-932 — Queues for Kafka(Share Groups): 4.0 の目玉。Kafka 上に queue セマンティクス (同一トピックを複数コンシューマが競合消費、ack/timeout/redelivery)を正式サポート。RabbitMQ 領域へ侵入。
• KIP-1102 — Transactions v2: トランザクションコーディネータの安定性向上。

KRaft + tiered storage + share groups の組み合わせで、Kafka 4.0 は「stream も queue も長期保管も一つのシステム」を狙う。

3 章 · Confluent Cloud vs Aiven vs Redpanda — マネージド Kafka

Kafka を自前運用するチームは年々減っている。マネージドが成熟したからだ。

2026 年の実務ガイド。

• フルスタック統合 + エンタープライズサポート: Confluent Cloud。
• 純粋 OSS Kafka、マルチクラウド: Aiven。
• AWS ロックインで OK、MSK Serverless で単純化: MSK。
• 運用簡素 + 半数ノード: Redpanda Cloud。
• ストレージコストとクラウド egress を最小化: WarpStream。

価格で最大変数は クラウドの inter-AZ 転送費 だ。Kafka が 3 AZ レプリケーション既定だと、レプリカトラフィックが AZ をまたいで GB あたり 0.01〜0.02 ドル発生する。スループットの大きいワークロードではこの費用がクラスタ費用を超える。WarpStream と KIP-392(fetch from follower)はこの費用を削るための核心。

4 章 · Redpanda — C++ ベースの Kafka 互換

Redpanda は 2019 年に Vectorized(現 Redpanda Data)が始めた。一行で言えば JVM 無しで C++ で書き直した Kafka。ScyllaDB の Seastar の thread-per-core モデルを持ってきた。

主要な違い。

• No JVM、No GC pause: P99 レイテンシが安定。
• No ZooKeeper from day 1: Kafka より早く独自 Raft。
• 単一バイナリ: broker = controller、1〜3 ノードから運用可能。
• Kafka wire 互換: client・connector・UI そのまま。
• Tiered storage 内蔵: S3/GCS への cold データ。
• WASM transforms: Redpanda Data Transforms(broker 内で WASM 実行)。

性能主張は「同一ハードで Kafka 比 2〜5 倍スループット、1/3 ノード」。ベンチマークは常にワークロード次第だが、ノード数が減って運用負担が軽くなる 点は実体験と合う。

Docker で single-node 起動。

docker run -d --name redpanda \
  -p 9092:9092 -p 9644:9644 \
  redpandadata/redpanda:v24.3.1 \
  redpanda start --smp 1 --memory 1G --reserve-memory 0M \
  --overprovisioned --node-id 0 --check=false

Kafka クライアントでそのまま接続。

docker exec -it redpanda rpk topic create test
docker exec -it redpanda rpk topic produce test
> hello
> ^D
docker exec -it redpanda rpk topic consume test --num 1

2026 年の Redpanda の位置は「JVM/ZK 運用が嫌で、Kafka 互換が要るチーム」。ゲーム・金融・IoT のようにレイテンシ一貫性が重要な領域での採用が増えた。

5 章 · WarpStream(Confluent 買収 2024)— S3 上の Kafka

WarpStream は 2023 年に登場、2024 年 9 月に Confluent に買収された。一行で言えば Kafka wire 互換 + ストレージは S3 が本質。

伝統的 Kafka のコスト構造。

1. broker インスタンス費(EC2/EBS)。
2. AZ 間レプリカ転送費($0.01/GB)。
3. EBS ストレージ費。
4. コンシューマが他 AZ にあると fetch 費。

WarpStream のアーキテクチャ。

1. ステートレス Agent が Kafka wire プロトコルを受けて S3 に直接書く。
2. メタデータは WarpStream コントロールプレーン(または BYOC モードの自前コントローラ)。
3. ディスクが無い → AZ 間レプリカ転送が無い。
4. 全データが S3 → 11 ナインの durability はクラウドの責任。
5. コンピュート(Agent)とストレージ(S3)が完全分離 → それぞれ独立スケール。

代償は レイテンシ。古典 Kafka は P99 produce が 5〜50ms に対し WarpStream は 200〜500ms(S3 PUT レイテンシのため)。だから「低レイテンシのリアルタイム」には合わず、「高スループット + コスト最小 + 1 秒程度の遅延 OK」のワークロードに合う。データレイク投入、ログ/メトリクスパイプライン、CDC sink が代表例。

買収後の方向性は「Confluent Cloud の一 deployment 形態」への統合。Confluent Cloud Freight Cluster が実質 WarpStream エンジン。

6 章 · NATS + JetStream + KV + ObjectStore

NATS は 2011 年登場の軽量 pub/sub。2018 年に Synadia が会社として分離、同年 CNCF へ寄贈。哲学は「単純さと速さ」。

NATS の進化。

2026 年に NATS 単一ノード(クラスタリングは設計上単純)。

# JetStream 有効化
nats-server -js -sd /data/nats

ストリーム作成。

nats stream add ORDERS \
  --subjects "orders.>" \
  --storage file --retention limits \
  --max-msgs=1000000 --max-age=24h

KV 利用。

nats kv add config
nats kv put config feature.new-checkout '{"enabled":true}'
nats kv get config feature.new-checkout

ObjectStore(S3 風)。

nats object add my-bucket
nats object put my-bucket large.zip ./large.zip
nats object get my-bucket large.zip > out.zip

NATS の強みは 単一インフラ。queue + pub/sub + stream + KV + オブジェクト + 分散ロック + leader election を一バイナリで賄う。マイクロサービスが多くマルチリージョン/エッジがある現場では、NATS は「Kafka 一つ + Redis 一つ + Consul 一つ + MinIO 一つ」より単純。

弱点はエコシステム。Kafka の巨大な connector エコシステム、Schema Registry、ストリーム処理(ksqlDB、Flink)のような部分は NATS では弱い。

7 章 · Apache Pulsar 4.0 + Pulsar Functions

Apache Pulsar は Yahoo が 2016 年に OSS 化、2018 年に Apache 卒業。差別化は コンピュートとストレージの分離(broker = stateless、BookKeeper = storage)。

Pulsar 4.0(2025 年初)の核心。

• Lakehouse Tiered Storage: 古いデータを Parquet 形式で S3/GCS へ保存、Trino/Spark が直接クエリ。
• Pulsar Functions 安定化: ストリーム上で Lambda 風関数実行、function mesh でワークフロー。
• Topic Compaction 改善。
• WebSocket・HTTP・MQTT プロトコルゲートウェイ統合。

Pulsar の構造的優位。

弱点は 運用複雑度。broker + bookie + ZooKeeper(2026 年でも Pulsar は ZK を使う)の三コンポーネントが別運用。さらに日韓では知名度が低く運用人材が見つかりにくい。

2026 年の Pulsar は「大規模マルチテナント SaaS」領域で強い。Splunk、Yahoo、Tencent、StreamNative などが数十万トピックを単一クラスタで運用している。

8 章 · RabbitMQ 4.0 — Khepri(Raft)+ Streams プラグイン

RabbitMQ は 2007 年からの AMQP 0.9.1 実装で、「メッセージキューの標準」のような立ち位置。2024 年の RabbitMQ 4.0 が大きな転換だった。

主要変更。

• Mnesia → Khepri: クラスタメタデータの保存先を Erlang Mnesia(古典的分散 DB)から Khepri(Raft ベースの自社 DB)へ。split-brain 回復が綺麗になった。
• Streams プラグイン GA: Kafka 風の append-only ログを RabbitMQ 内部に統合(Stream Queue Type)。スループット 100 万 msg/s まで。
• Quorum Queue を既定化: 古典キューよりも Raft ベースの Quorum Queue を推奨。
• MQTT 5 / AMQP 1.0 強化。

RabbitMQ が今でもよく合う場所。

• ジョブキュー: Celery、Sidekiq、Resque などのワーカ系。
• RPC パターン: request-reply with reply-to queue。
• fanout / topic routing: ルーティングキー基準の複雑な分岐。
• バックオフィス処理: メール送信、PDF 生成、決済処理。

Quorum Queue 例。

# CLI で宣言
rabbitmqadmin declare queue name=tasks queue_type=quorum

Java クライアントから publish。

ConnectionFactory factory = new ConnectionFactory();
factory.setHost("rabbitmq");
try (Connection conn = factory.newConnection();
     Channel ch = conn.createChannel()) {
    ch.queueDeclare("tasks", true, false, false,
        Map.of("x-queue-type", "quorum"));
    ch.basicPublish("", "tasks",
        MessageProperties.PERSISTENT_TEXT_PLAIN,
        "hello".getBytes());
}

RabbitMQ を Kafka に置き換える試みは大抵後悔で終わる。秒間数千〜数万件のジョブ、複雑なルーティング、短い保持 ならば RabbitMQ の方が単純で安い。

9 章 · Apache RocketMQ(Alibaba)— 中国スケール

RocketMQ は Alibaba が 2012 年に作り 2017 年に Apache 卒業。Double 11(11/11)の中核インフラとして、秒間数百億メッセージ規模 で実証済みのシステム。

特徴。

• 順序保証モード: パーティションでなくメッセージグループ単位の順序(FIFO Topic)。
• トランザクションメッセージ: half-commit / commit / rollback の 3 段階 — DB トランザクションとメッセージ発行の原子性。
• スケジュールメッセージ・遅延メッセージ が内蔵。
• ダッシュボード・トレース の完成度が高い。
• RocketMQ 5.0+(2023〜): コンピュート/ストレージ分離、クラウドネイティブ。

韓国・日本・欧米ではほぼ使われないが、中国・東南アジアでは Kafka の代替として極めて一般的。Alibaba Cloud のメッセージサービスは実質 RocketMQ。

トランザクションメッセージの例(Java)。

TransactionMQProducer producer = new TransactionMQProducer("group");
producer.setTransactionListener(new TransactionListener() {
    public LocalTransactionState executeLocalTransaction(Message msg, Object arg) {
        // 1) DB トランザクション実行
        // 2) 成功 -> COMMIT、失敗 -> ROLLBACK、不明 -> UNKNOWN
        return LocalTransactionState.COMMIT_MESSAGE;
    }
    public LocalTransactionState checkLocalTransaction(MessageExt msg) {
        // ブローカが未解決メッセージを再確認
        return LocalTransactionState.COMMIT_MESSAGE;
    }
});

新規プロジェクトに RocketMQ を選ぶ日韓チームはほぼ無いが、Alibaba Cloud / Tencent Cloud にデプロイするならマネージド RocketMQ が自然な選択。

10 章 · NSQ / Memphis(Superstream)

NSQ

NSQ は bitly が 2013 年に OSS 化した分散メッセージシステム。Go 製。哲学は「中央ブローカ無し、トポロジが単純なシステム」。

• 単一バイナリ(nsqd) が各ホストにデプロイされ、メッセージはホストローカルから発行。
• nsqlookupd が発見を担う。
• クラスタリング無し(各ノード独立)。
• メモリ優先、overflow 時にディスク。

NSQ の武器は単純さ。大企業が使わないという印象はあるが、IRC bot・ドメインインデクシング・単純なジョブキューでは今も良い選択。ただし 2026 年の新規プロジェクトなら NATS がほぼ全機能で勝る。

Memphis → Superstream

Memphis は 2022 年登場の Kafka 代替試行。「開発者フレンドリな Kafka」を掲げ、GUI・schema management・DLQ を既定提供した。2024 年に会社が Superstream へリブランド、方向を「Kafka の上のコスト最適化レイヤ」へ転換した。

2026 年の Superstream のポジショニングは興味深い。

• Kafka を 置き換えない、AI で config を調整し、自動圧縮や partition balancing を行う。
• Confluent Cloud / MSK / Aiven の上に被せて 30〜50% のコスト削減を約束。
• 人気パターン: 誤って設定された batch.size・linger.ms・compression.type を実ワークロードに基づき再推奨。

「Kafka はそのまま、請求書を削る」コンセプトで、マネージド Kafka の請求が痛いチームが導入している。

11 章 · Buf Stream — gRPC streams の新たな挑戦

Buf は Protocol Buffers ツールで有名な会社。2024 年に Buf Stream を発表しメッセージング領域へ参入。

中心アイデア。

• Schema-first メッセージング: 全トピックが Protobuf スキーマ持ち。不正なメッセージは発行段階で拒否。
• Kafka API 互換: 既存 Kafka client をそのまま使える。
• Buf Schema Registry と統合 — スキーマ進化ルールを強制。
• ステートレスアーキテクチャ: WarpStream に似て S3/オブジェクトストレージが一次保存。

Buf Stream の価値提案。

• 「不正なデータがトピックに入る事故を、コンパイル/デプロイ段階で止める。」
• 「Buf CLI でスキーマ変更を lint、互換性チェック、breaking change を遮断。」
• 「Kafka client はそのまま — インフラ置き換えだけ。」

2026 年現在の Buf Stream は production 採用が少数だが、schema governance が中核価値となる組織(金融・ヘルスケア・B2B SaaS)で注目を集めている。Confluent Schema Registry + Kafka の「二システム」を一システムに束ねる試み。

12 章 · イベントソーシング / CQRS / Outbox / Saga パターン

メッセージシステムは道具にすぎず、どう使うか が本体。2026 年でも変わらない核心パターン 4 つ。

1) イベントソーシング(Event Sourcing)

状態を直接保存せず、状態を作ったイベントの列 を保存する。現在の状態はイベントを fold して得る。

// 注文状態 = イベントの fold
function orderState(events) {
  return events.reduce((state, e) => {
    switch (e.type) {
      case 'OrderCreated': return { id: e.id, status: 'PENDING', items: e.items };
      case 'OrderPaid':    return { ...state, status: 'PAID', paidAt: e.at };
      case 'OrderShipped': return { ...state, status: 'SHIPPED', tracking: e.tracking };
      default: return state;
    }
  }, null);
}

• 長所: 監査ログ、時間旅行、新ビュー再構築。
• 短所: クエリが難しい → CQRS と組合せ。

2) CQRS(Command Query Responsibility Segregation)

書き込みモデルと読み出しモデルを分離。読み出しモデルはイベントストリームから非同期でビルド。

3) トランザクション Outbox

最も多い間違い:「DB トランザクション → イベント発行」を別々にやって、その間で障害が起きると不整合。Outbox は同じ DB トランザクションに outbox テーブル INSERT を束ね、別プロセスが outbox を読んで Kafka に発行。Debezium CDC か自前 poller。

BEGIN;
  INSERT INTO orders (id, user_id, total) VALUES (...);
  INSERT INTO outbox (aggregate_id, event_type, payload)
         VALUES ('order-123', 'OrderCreated', '{"...":"..."}');
COMMIT;
-- 別プロセスが outbox をポーリング/CDC で Kafka へ

4) Saga

複数サービスをまたぐトランザクションの分散版。各段に補償トランザクションを定義。

• 決済 → 在庫減算 → 配送予約。どこかで失敗したら前の段を補償(返金、在庫戻し)。
• 実装は二つ: オーケストレーション(中央コーディネータ、Temporal、AWS Step Functions)vs コリオグラフィ(各サービスがイベントを見て反応)。

この 4 パターン無しで分散メッセージングを production 運用するのは、データ不整合の時限爆弾。

13 章 · 日韓導入 — カカオ、トス、LINE、Mercari、ZOZO、CyberAgent

カカオ

カカオは Kafka を社内マネージドサービス化 して運用する。カカオトークのメッセージフロー、検索インデックス、ログパイプラインが Kafka に乗る。KRaft 移行は 2025 年から段階的に進行中。一部チームは RabbitMQ をバックオフィスワーカに利用。

トス(Toss)

トスのデータエンジニアリングは Kafka 中心で知られる。決済イベント・CDC・リアルタイム ML 特徴量ストアが Kafka 上。近頃は一部ワークロードに WarpStream / Tiered Storage を検討。社内カンファレンス SLASH で Kafka 運用ノウハウの共有多数。

LINE

LINE はメッセージングインフラ自体が 自社開発キュー(LMQ) と Kafka のハイブリッド。トラフィックがグローバルでメッセージ順序が重要なため自社ソリューションを維持。広告・ログ・メトリクスは Kafka。Java 陣営が強いだけに ZooKeeper 時代からの運用経験が資産。

Mercari

Mercari は GCP 中心で Pub/Sub + Dataflow がメインだが、決済・在庫などで Kafka も使う。Mercari エンジニアリングブログに Pub/Sub vs Kafka の比較記事が多数。

ZOZO

ZOZO は検索・推薦パイプラインに Kafka を採用。ファッションカタログ変更 → 検索インデックス更新のほぼ全フローが Kafka。社内で Schema Registry 運用事例を共有。

CyberAgent / AbemaTV

AbemaTV のライブ配信メタデータ、広告入札パイプラインに Kafka。CyberAgent グループ各社が NATS・Pulsar も部分的に導入 — 日本のカンファレンス発表が増えた。

共通点: 2026 年には「Kafka 一本」より「ワークロード別の適材適所」の流れ。決済・CDC は Kafka、マイクロサービス通信は NATS、ジョブキューは RabbitMQ、データレイク投入は WarpStream / MSK Tiered。一社の中に 3〜4 種のメッセージングが共存するのが標準になった。

14 章 · 意思決定チェックリスト — 我々は何を使うか

最後にワンページ決定表。

運用観点で忘れない事。

• モニタリング: Prometheus + Kafka Exporter / Burrow(コンシューマ lag)、JMX、Datadog / Grafana。
• schema 管理: Confluent Schema Registry / Buf / Karapace。スキーマ無しで production トピックを作ると半年後に後悔。
• バックアップ/DR: MirrorMaker 2(Kafka)、Geo-replication(Pulsar)、JetStream mirrors(NATS)。
• 認証/権限: SASL/OAuth、ACL — production で匿名発行が通ってはいけない。
• コンシューマ lag 警報: lag が 30 分以上ならページ。最も多い incident 原因。

エピローグ — メッセージはインフラではなく契約だ

2026 年の分散メッセージングの本当の教訓は道具でなく 契約。システム間の契約 — どんなイベントが、どんなスキーマで、どんな保証(at-least-once、exactly-once、順序、レイテンシ)の下で流れるか。

道具は変わる。5 年前に ZooKeeper を運用していた人が今日 KRaft を運用し、来年は S3 上の Kafka を運用するかもしれない。しかし 契約をよく設計したチームは道具を変えても生き残る。設計を誤ったチームは道具を変えても同じ問題に出会う。

次回候補: Outbox パターン深堀り — Debezium CDC + Kafka で作る最も安全なイベント発行、コンシューマ lag を 0 にする方法 — KIP-848 / partition assignment / バックプレッシャ、NATS マルチリージョン — leaf node で本当の世界規模分散を作る。

「メッセージキューを選ぶことは、二つのシステムの間の契約を設計することだ。道具はその後に来る。」

— 分散メッセージング 2026、終わり。

参考 / References

• Apache Kafka 3.9 release notes
• KIP-833 — Mark KRaft as Production Ready
• KIP-405 — Kafka Tiered Storage
• KIP-848 — Next Generation Consumer Rebalance Protocol
• KIP-932 — Queues for Kafka (Share Groups)
• Confluent Cloud
• Aiven for Apache Kafka
• AWS MSK
• Redpanda Documentation
• Redpanda GitHub — redpanda-data/redpanda
• WarpStream Documentation
• Confluent acquires WarpStream (2024)
• NATS Documentation
• NATS JetStream
• NATS GitHub — nats-io/nats-server
• Apache Pulsar Documentation
• Pulsar Functions
• RabbitMQ 4.0 release notes
• RabbitMQ Khepri
• RabbitMQ Streams
• Apache RocketMQ
• NSQ Documentation
• Superstream — formerly Memphis
• Buf Stream
• Debezium — CDC platform
• Confluent Schema Registry
• LINE Engineering Blog
• Mercari Engineering
• ZOZO TECH BLOG
• CyberAgent Developers Blog
• Toss SLASH conference