公開2026.07.17更新2026.10.17 アーキテクチャ

RabbitMQとKafkaの違いとは？設計思想・性能・使い分けの判断基準を実装視点で解説

RabbitMQとKafkaは、どちらも非同期メッセージングを支える基盤ですが、片方をもう片方の代替として選ぶと設計が破綻します。RabbitMQは「タスクを確実に1回処理させて消す」キュー型ブローカーで、Kafkaは「イベントを追記して何度でも読み直す」分散ログだからです。本記事は両者の設計思想の違いを動作モデルから整理し、順序保証・スループット・再処理可否など6観点の比較、Dockerで両者を並べて起動して挙動差を実測する手順、ユースケース別の使い分け、そして受託開発の設計現場で使っている採用条件と見送り基準までを実装視点で解説します。版番号は2026年9月7日時点で公式配布物を確認し、RabbitMQ 4.3系・Kafka 4.3系の仕様に基づいて記述しています。

まとめ：RabbitMQとKafkaの選定結論と使い分けの軸

選定の軸は「同じメッセージを後から読み直す必要があるか」の1点に置くのが結論です。メール送信や帳票生成のようなタスクを複数ワーカーへ分配し、処理が終わったら消えてよいならRabbitMQを選びます。逆に、1つのイベントを複数のシステムが別々の目的で購読する、あるいは障害復旧や新機能追加の際に過去データを再処理（リプレイ）したいならKafkaです。Kafkaはメッセージを消費後も保持期間まで残す追記型ログなので、この要件はKafkaでしか満たせません。

性能面の一般論だけで選ぶのは失敗パターンです。Kafkaのスループットはパーティション並列で伸びますが、ブローカー3台以上のクラスタ運用と監視・容量設計が前提になります。日次数十万件程度のジョブ処理にKafkaを立てるのは過剰投資で、RabbitMQ単体か、Amazon MQなどのマネージドサービスで足りる規模です。判断に迷ったら、本記事後半の「同一環境で起動し挙動差を実測する手順」を先に手元で回してから決めると、机上の比較表では見えない運用の重さが体感で分かります。判断の根拠と条件分岐は本文で順に示します。

メッセージブローカーのRabbitMQと分散ログのKafkaの設計思想の差

両者の違いは機能一覧を並べる前に、メッセージが「どこに置かれ、いつ消えるか」という動作モデルで押さえると腹落ちします。この章で土台を作ります。

Exchangeでルーティングするスマートブローカー型RabbitMQの動作

RabbitMQはAMQP（Advanced Message Queuing Protocol）を実装したメッセージブローカーです。プロデューサーはメッセージをキューへ直接入れるのではなく、まずExchangeへ送ります。Exchangeはdirect・topic・fanout・headersの4タイプがあり、ルーティングキーとバインディング規則に従ってメッセージを1つまたは複数のキューへ振り分けます。コンシューマーはキューからメッセージを受け取り、処理完了の確認応答（ack）を返した時点でメッセージがキューから消える仕組みです。振り分け・再配信・優先度・TTLといった判断をブローカー側が担う「スマートブローカー・ダムコンシューマー」型で、処理失敗時は公式ドキュメントのdead letter exchangeで規定されている退避先へメッセージを逃がす再試行設計が、キューとExchangeの宣言だけで組めます。プロトコルそのものの仕様と0-9-1／1.0の版差はAMQPの仕様と版の選び分けを解説した記事で扱っています。

コンシューマーへ一度に渡すメッセージ数を絞るprefetch（RabbitMQ公式のconsumer prefetch解説）も、この「ブローカーが配り方を決める」設計の延長にあります。ワーカーの処理が遅いときに配信側で流量を抑えられるため、アプリ側に流量制御のコードを書かずに詰まりを吸収できる構造です。可用性側では、レプリケーションをRaftで持つquorum queuesが4系の既定的な選択肢になっており、旧来のミラーキューを前提にした設計資料はそのまま流用できません。

パーティション分割した追記型ログをオフセットで読むKafkaの動作

Kafkaのメッセージ（レコード）はトピックへ追記され、消費されても削除されません。トピックは複数のパーティションに分割され、各パーティションはディスク上の追記専用ログとして順番に書き込まれます。コンシューマーは自分がどこまで読んだかを示すオフセットを持ち、ブローカーへ自らpullして読み進める形です。この読み位置をJavaクライアント側でどう管理するかはKafka Java APIのコミット方式の解説にまとめています。ブローカーは配り先を管理せず、読む位置の管理をコンシューマー側が担う「ダムブローカー・スマートコンシューマー」型です。この構造のため、同じトピックを分析系・通知系・検索系が互いに干渉せず並行購読でき、オフセットを巻き戻せば過去分の読み直しもできます。Kafka自体の構成要素と採用理由はApache Kafkaの仕組みとKRaft構成を整理した記事で詳しく扱っています。

設計時に見落としやすいのがパーティション数の既定値です。Kafka 4.3系のブローカー設定一覧ではnum.partitionsの既定が1と規定されており、CLIやクライアントの自動作成に任せると並列度1のトピックができます。Kafkaの性能はパーティション数で決まるため、トピック作成時に明示指定するのが実務上の前提になります。

RabbitMQ 4.3系とKafka 4.3系の現況と対応プロトコルの差

2026年9月7日時点の状況を公式配布物で確認すると、RabbitMQは4.3系が現行で、GitHubのリリース一覧では4.3.5（2026年8月17日）が最新のメンテナンスリリース、同系列の最小Erlangが27.0と明記されています。KafkaはApacheの配布ディレクトリに4.1系・4.2系・4.3系が並び、4.3系では4.3.1が最新です。Kafkaは4.0でZooKeeperを廃止しKRaftモードへ一本化したため、旧構成の記事にあるZooKeeperクラスタの運用は不要になりました。ZooKeeper前提の手順書がまだ社内に残っている場合、4系への移行時にそこが最初の躓きどころになります。

プロトコル面の差は統合設計に直結します。RabbitMQ側は4.0でAMQP 1.0がコアプロトコルになり、MQTTやSTOMPもプラグインで話せる多プロトコル対応が強みです。一方Kafkaはクライアントと独自バイナリプロトコルで通信するため、既存のAMQP資産やIoT機器のMQTT接続をそのまま受ける統合には向きません。IoTのデバイス側をMQTTで受け、バックエンドの分析基盤へKafkaで流す、といった橋渡し構成が現場では珍しくない形です。なおRabbitMQもStreamsという追記型ログ機能を持ちますが、エコシステム（後述のストリーム処理系）はKafkaが厚く、ログ型が主用途ならKafkaを選ぶ方が実装の選択肢が広がります。ブローカーと保存層を分離した第3の選択肢が要件に合う場合は、Apache PulsarとKafkaの構造差を整理した記事も突き合わせてください。

RabbitMQとKafkaを同一環境で起動し挙動差を実測する手順

比較表を読むより、手元で両方を立てて「ackで消える」「オフセットで読み直せる」を1回ずつ触った方が判断は速く固まります。ここではコンテナ2つで済む最小手順を示します。

Dockerで両ブローカーを起動して疎通までを確認する初期手順

RabbitMQは管理画面付きイメージ、Kafkaは公式イメージのKRaftモードを使います。Kafkaの公式イメージはストレージのフォーマット手順が内包されているため、Kafka 4.3.1のクイックスタートにある通りUUID生成とログディレクトリのフォーマットを自分で打つ必要がありません。次の3行で両方が立ち上がります。

docker run -d --name rabbit -p 5672:5672 -p 15672:15672 rabbitmq:4.3-management
docker run -d --name kafka -p 9092:9092 apache/kafka:4.3.1
docker exec rabbit rabbitmqctl status

RabbitMQ側は管理画面をブラウザで開けば、キューの滞留数・コンシューマー数・秒間の配信レートが最初から見えます。Kafka側に同等の画面はなく、状態はCLIかメトリクスで見る前提です。この時点で運用の性格差が現れており、専任のインフラ担当を置けない体制ではこの差が後の負担になって返ってきます。

pikaでquorumキューを宣言しackで消える挙動を確認する

RabbitMQの「ackした時点で消える」を確認します。公式チュートリアルのワーカー実装と同じく、キュー種別にquorumを指定し、prefetch_countを1にしてワーカー1台が1件ずつ処理する形にします。

import pika

conn = pika.BlockingConnection(pika.ConnectionParameters(host='localhost'))
ch = conn.channel()
ch.queue_declare(queue='task_queue', durable=True,
                 arguments={'x-queue-type': 'quorum'})
ch.basic_qos(prefetch_count=1)

def on_message(ch, method, props, body):
    print('received:', body.decode())
    ch.basic_ack(delivery_tag=method.delivery_tag)

ch.basic_consume(queue='task_queue', on_message_callback=on_message)
ch.start_consuming()

このワーカーを起動したまま管理画面のキューを見ると、メッセージ数がackのたびに減って0へ戻ります。ワーカーを止めて再起動しても、処理済みの分は戻ってきません。basic_ackの行をコメントアウトして再実行すると、今度はunackedとして滞留し、接続を切った瞬間に再配信されます。この2通りを見ておくと、RabbitMQで「再処理ができない」と言われる意味と、再試行はdead letter exchange側で設計するという分担が具体で理解できます。

kafka-topics.shでトピックを作りオフセット巻き戻しを試す

Kafka側では、パーティションを明示してトピックを作り、コンシューマーで読んだあとにオフセットを巻き戻して同じデータを再度読みます。コンテナ内のCLIを使う場合はdocker exec -it kafka bashで入ってから実行します。

bin/kafka-topics.sh --create --topic orders --partitions 3 --bootstrap-server localhost:9092
bin/kafka-console-producer.sh --topic orders --bootstrap-server localhost:9092
bin/kafka-console-consumer.sh --topic orders --group billing --from-beginning --bootstrap-server localhost:9092
bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 --group billing --topic orders --reset-offsets --to-earliest --execute

4行目を打った後にコンシューマーを再起動すると、既に読み終えたレコードが先頭から再び流れてきます。RabbitMQでは構造的に再現できない挙動で、これが「再処理要件があるならKafka一択」という判断の実体です。保持の条件はブローカー設定で決まり、4.3系の設定一覧ではlog.retention.hoursの既定が168（7日）と規定されています。キーごとの最新値だけを残したい場合はlog.cleanup.policyをcompactへ切り替えます。

log.retention.hours=168
log.cleanup.policy=compact
num.partitions=3

ここまでを1時間ほどで通せば、両者の差が「機能の多寡」ではなく「メッセージがいつ消えるか」という一点から派生していることが手触りで分かります。以降の比較はこの体感の上に読んでください。

順序保証・スループット・再処理など6観点でのRabbitMQとKafka比較

設計思想の差は、実装で効いてくる具体的な仕様差になって現れます。選定に直結する順に見ていきます。

メッセージ配信モデルと順序保証・再配信時の挙動に見る設計の差

RabbitMQのキューに複数のコンシューマーを付けると、メッセージは競合消費で分配され、全体の到着順は保証されなくなります。処理失敗による再配信でも順序は崩れるため、順序が要る場合はキューを分けて単一コンシューマーにするか、Single Active Consumer機能で実質1本に絞るのが定石です。Kafkaはパーティション内に限り順序を保証し、同じキー（例：注文IDや顧客ID）を持つレコードを同一パーティションへ寄せることで「同一エンティティ内の順序」を並列消費と両立できます。順序と並列度を同時に確保したい要件では、この差が選定の決め手になりやすい部分です。

パーティション並列が生むスループット差と低レイテンシ配信の得意分野

スループットの上限構造が両者で異なります。Kafkaはパーティション数だけ書き込みと読み出しを並列化でき、ディスクへの順次書き込みとゼロコピー転送でブローカー1台あたりの効率も高いため、秒間数万〜数十万件規模のイベント流入はKafkaの土俵です。負荷が増えたらパーティションとブローカーを足す水平スケールで受けられます。RabbitMQは1キューの処理能力に上限があり、大量流入はキュー分割やシャーディングで工夫する側になりますが、個々のメッセージを届けるまでの遅延は小さく、ミリ秒単位の応答が要るコマンド配送が得意分野です。前章で触れたprefetch制御が標準で備わるため、ワーカーの詰まりを配信側で吸収できます。優先度キューや遅延配信（プラグイン）のようにメッセージ単位で扱いを変える機構も、RabbitMQ側だけが持つ道具です。

メッセージ保持期間とオフセット巻き戻しによる再処理可否の決定差

RabbitMQはackされたメッセージを削除するため、処理後の再取得は原則できません。障害でデータ欠損が起きた場合や、後から集計ロジックを追加したい場合に、過去メッセージへ遡る手段がない点は設計時に必ず織り込む必要があります。Kafkaはレコードを保持期間まで残し（既定はlog.retention.hoursの168時間＝7日）、コンシューマーグループごとのオフセットを巻き戻せば同じデータを何度でも読み直せます。バグ修正後の再集計、新システム追加時の過去データ取り込み、障害時の突き合わせ調査が、すべてこの仕組みの上に載る構造です。期間ではなくキーごとの最新値だけを残すログコンパクションも選べるため、マスタデータの配布用途にも広げられます。再処理要件が明確にあるなら、この観点だけでKafka採用が決まります。

ルーティング柔軟性・対応プロトコル・スケール方式まで含めた比較一覧

ここまでの観点に運用面を加えた比較を一覧にします。表の各行は優劣ではなく「どちらの設計に寄っているか」を示すものです。

観点	RabbitMQ	Kafka
動作モデル	キュー型ブローカー	分散追記ログ
消費後のデータ	ackで削除	保持期間まで残る
保持期間の既定	無期限（ack時に削除）	168時間（7日）
再処理	原則不可	オフセット巻き戻し
順序保証	単一コンシューマー時	パーティション内
ルーティング	Exchangeで柔軟	トピックとキーのみ
プロトコル	AMQP・MQTT等	独自バイナリ
遅延・優先度配信	対応（一部plugin）	非対応
スケール方式	キュー分割中心	パーティション追加
状態の可視化	管理画面が標準同梱	CLIとメトリクス
最小構成	1ノードから	実運用は3台以上

ルーティングの柔軟さと配信制御はRabbitMQ、保持と並列スケールはKafkaに寄っています。両方を1製品で満たそうとせず、要件がどちらの列に多く並ぶかで判定する使い方を想定した表です。

タスクキューとイベントストリームそれぞれに適合するユースケース

仕様差を実際のシステム像に落とします。自分の案件がどちらの型に近いかを照合してください。

ジョブ分配・RPC応答・遅延配信などRabbitMQが適する処理の型

RabbitMQが適するのは「1件のタスクを誰か1人に確実に処理させる」型です。具体的には、画像変換・PDF帳票生成・メール送信をワーカー群へ分配するジョブキュー、Webリクエストから重い処理を切り離す非同期化、応答を待ち合わせるRPCパターン、注文確定の30分後にリマインドを送る遅延配信などが該当します。地域別・種別ごとに配送先を変えるようなルーティング要件も、topic Exchangeのバインディング規則だけで実装でき、アプリ側の分岐コードを減らせる点が利点です。マイクロサービス間で「この処理をやってほしい」というコマンドを渡す用途は、ほぼこの型に収まります。

ログ集約・CDC・イベントソーシングなどKafkaが適する処理の型

Kafkaが適するのは「発生した事実を複数の消費者が別目的で使う」型です。アクセスログ・アプリケーションログ・IoTセンサー値の集約、データベースの変更を捕捉して他システムへ流すCDC（Change Data Capture）、状態変化そのものを記録として積むイベントソーシング、そしてKafka StreamsやApache Flinkを使った到着データの逐次集計が代表例になります。CDCで使う実装はDebeziumの公式ドキュメントにコネクタ別の設定が揃っており、MySQLやPostgreSQLのbinlog／WALをKafkaトピックへ流す構成もここが起点です。逐次集計の設計はバッチ処理との使い分けを含めてストリーム処理の仕組みと処理モデルの解説記事で扱っています。購読側を後から追加しても送信側に変更が入らない疎結合が、データ利用部門が増え続ける分析基盤の入口として選ばれる理由です。

RabbitMQとKafkaを併用するアーキテクチャ構成と接続時の注意

両者は排他ではなく、役割を分けた併用が成立します。定石は、イベントの受け皿と配信をKafkaが担い、そこから派生する個別タスクの実行分配をRabbitMQが担う構成です。たとえばECサイトなら、注文イベントをKafkaへ流して在庫・分析・通知の各系統が購読し、通知系統の中でメール送信ワーカーへの分配はRabbitMQに任せる、という分担になります。イベントを起点にサービス間を疎結合へ保つ設計全体はイベント駆動アーキテクチャの仕組みと実装パターンの解説が前提整理に向く記事です。基盤をコンテナ前提で組む場合の全体像はクラウドネイティブの定義と移行判断を整理した記事と併読すると、メッセージング単体ではなく運用体制ごと判断できます。注意点は運用対象が2系統になることで、監視・パッチ適用・障害対応の窓口が倍になる点です。専任のインフラ担当がいない体制での安易な併用は避け、まず片方で成立しないかを先に検討してください。

受託開発の設計現場で言い切るRabbitMQとKafkaの採用・見送り基準

ここが本記事の独自の視点です。機能比較は答えを出してくれません。決めるのは要件と体制の条件分岐です。

再処理要件・購読系統数・メッセージ量で決める採用条件の判断手順

判断は3問で足ります。第1問、過去メッセージの再処理や監査用の保全が要件にあるか。あるならKafka一択です。RabbitMQでは構造的に満たせません。第2問、同じイベントを購読する系統がいくつあるか。3系統以上が見えているならKafkaへ寄せます。fanoutで真似はできても、系統追加のたびにキューとバインディングが増殖し、保持もできないためです。第3問、どちらでもない場合は流量で決めます。ピークが秒間数千件に収まるタスク分配ならRabbitMQで十分成立し、ルーティングと再試行の道具立てはむしろ豊富です。手元の要件がKafka側の条件に1つも該当しないなら、Kafkaを選ぶ理由はありません。

小規模システムへのKafka導入が過剰投資になる損益分岐の目安

「実績があるから」でKafkaを選んだ小規模案件は、ほぼ運用で苦しみます。Kafkaの実運用はレプリケーション前提でブローカー3台以上、パーティション設計・保持容量の見積もり・リバランス挙動の把握といった固有の運用知識が必要になり、KRaft化でZooKeeperが消えた現在でもこの負担は残ります。日次数十万件（平均すれば秒間数件）のジョブ処理にこの投資は見合いません。この規模はRabbitMQ1〜2ノードで受けられます。損益分岐の目安を挙げるなら、①ピーク流量が秒間1万件を超え続ける、②同一イベントの購読系統が3つ以上ある、③保持・再処理が業務要件に明記されている、のいずれかに達した時点がKafkaへ切り替える線です。どれにも達していない段階での先行導入は、使われないパーティション設計と監視基盤の維持費だけが残ります。

逆にRabbitMQを見送るべき場面も明確で、データ分析基盤への供給や複数部門でのイベント再利用が1年以内のロードマップに載っているなら、後からの載せ替えはコンシューマー実装の書き直しになるため、最初からKafkaで組む方が総コストは下がります。判断の分かれ目に立ったときは、コンシューマー側のコードが「消えるメッセージ」を前提に書かれているかを見てください。ackで完結する実装をオフセット管理へ移すのは、ライブラリの差し替えでは済まない書き換えになります。

Amazon MQ・Amazon MSKなどマネージドサービスと構築支援の選び方

自前運用の負担は、クラウドのマネージドサービスへ移すのが現実的な選択肢です。AWSならRabbitMQ互換のAmazon MQ、Kafka互換のAmazon MSKがあり、ブローカーのパッチ適用・フェイルオーバー・ストレージ拡張を提供側が引き受けるため、チームはキュー設計とアプリ実装に集中できます。費用の増え方は構成で大きく変わるので、Amazon MSKの料金ページでブローカー時間課金とストレージ課金、サーバーレス版の課金単位を先に読み、保持期間を延ばしたときにどこが伸びるかを見積もっておくと後の請求で驚きません。専任インフラ担当を置けない体制でメッセージング基盤を入れるなら、自前構築ではなくマネージドから始めるのが妥当な判断です。Amazon MQとSQSのどちらに載せるかは、Amazon MQとSQSの違い（プロトコル互換・料金構造・移行判断）で東京リージョンの実額とあわせて比較しています。

なお、キュー用途ではなくリアルタイムのストリーミングデータをAWS内で収集・配信したい場合は、Amazon MSKと並ぶ選択肢としてAmazon Kinesisの仕組みと使い分けも検討に値する選択肢です。どのサービスをどう組み合わせるかの構成設計から任せたい場合は、AWS・Google Cloud・Azureのインフラ構築支援のように設計と構築を外部へ委ねる方法もあり、要件整理の段階から相談する方が構成の手戻りを防げます。委託時は、メッセージ消失時の責任分界と監視項目を契約前に文書化しておくと運用開始後の齟齬を避けられます。

よくある質問

RabbitMQとKafkaの比較・選定で、設計レビューの際によく挙がる疑問に答えます。

RabbitMQとKafkaはどちらが高速ですか？

測る軸で答えが変わります。総量（スループット）はパーティション並列で伸びるKafkaが有利で、大量イベントの取り込み向きです。1件を届けるまでの遅延（レイテンシ）はメモリ中心で配るRabbitMQが小さく、ミリ秒単位の応答が要るコマンド配送に向きます。「速さ」を理由に選ぶ前に、自分の要件が総量と遅延のどちらを問うているかを先に確定させてください。

Kafkaは何をするミドルウェアですか？

イベントを時系列に追記して保存し、複数の購読者が任意の位置から読めるようにする分散ログです。トピックをパーティションへ分割して並列に書き読みし、消費されたレコードも保持期間まで残す点が一般的なメッセージキューとの違いになります。4系ではZooKeeperが不要なKRaftモードへ一本化され、ブローカー自身がメタデータを持つ構成へ変わりました。周辺にKafka Connect・Kafka Streamsが揃い、収集から逐次集計までを同じ基盤に載せられる範囲が広い点も、Kafkaが分析基盤の入口として選ばれる理由です。

KafkaがあればRabbitMQは不要になりますか？

なりません。Kafkaには優先度付き配信・メッセージ単位のTTL・遅延配信・複雑なルーティングといったタスクキュー向けの機構がなく、これらを自作するとコンシューマー側が複雑化します。タスク分配が主用途ならRabbitMQの方が実装は素直です。逆に保持と再処理はRabbitMQで代替できないため、上位互換の関係ではなく用途の違う道具と捉えるのが正確です。

RabbitMQとKafkaは併用できますか？

できます。イベントの配信基盤をKafka、個別タスクの実行分配をRabbitMQと役割分担する構成は実績のある定石です。ただし監視・パッチ・障害対応の運用対象が2系統になるため、体制が薄いうちは片方で成立しないかを先に検討し、併用は購読系統の増加やタスク分配の複雑化が実際に起きてから踏み切る順序を推奨します。

学習コストや運用難易度に差はありますか？

あります。RabbitMQは1ノードから動き、管理画面（Management UI）でキューの滞留やコンシューマーの状態を確認でき、導入初日から全体像を掴みやすい部類です。Kafkaはパーティション設計・オフセット管理・リバランスなど固有概念の理解が前提になり、実運用ではブローカー3台以上の容量・監視設計も伴います。小さく始めるならRabbitMQ、Kafkaは学習と運用の投資を回収できる要件があるときに選びます。

マイクロサービス間の通信にはどちらを選ぶべきですか？

通信の性質で分けます。「この処理を実行してほしい」というコマンドの受け渡しや応答の待ち合わせは、RabbitMQの領分です。「注文が確定した」のような事実（イベント）を複数サービスへ広く伝え、後から購読者を足したい場合はKafkaが向きます。1つのシステム内にコマンドとイベントが混在するのは普通のことで、その場合は本文で示した併用構成が選択肢になります。