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

RabbitMQとKafkaは、どちらも非同期メッセージングを支える基盤ですが、片方をもう片方の代替として選ぶと設計が破綻します。RabbitMQは「タスクを確実に1回処理させて消す」キュー型ブローカーで、Kafkaは「イベントを追記して何度でも読み直す」分散ログだからです。本記事は両者の設計思想の違いを動作モデルから整理し、順序保証・スループット・再処理可否など6観点の比較、ユースケース別の使い分け、そして受託開発の設計現場で使っている採用条件と見送り基準までを実装視点で解説します。2026年6月時点の安定版（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へ退避させる再試行設計も宣言だけで組めます。

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

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

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

2026年6月時点の安定版は、RabbitMQが4.3系（GitHub releasesで4.3.2・2026年6月15日を確認）、Kafkaが4.3系（downloads.apache.orgで4.3.1を確認）です。Kafkaは4.0でZooKeeperを廃止しKRaftモードへ一本化したため、旧構成の記事にあるZooKeeperクラスタの運用は不要になりました。RabbitMQ側は4.0でAMQP 1.0がコアプロトコルになり、MQTTやSTOMPもプラグインで話せる多プロトコル対応が強みです。一方Kafkaはクライアントと独自バイナリプロトコルで通信するため、既存のAMQP資産やIoT機器のMQTT接続をそのまま受ける統合には向きません。IoTのデバイス側をMQTTで受け、バックエンドの分析基盤へKafkaで流す、といった橋渡し構成が現場では珍しくない形です。なおRabbitMQも3.9以降Streamsという追記型ログ機能を持ちますが、エコシステム（後述のストリーム処理系）はKafkaが厚く、ログ型が主用途ならKafkaを選ぶ方が実装の選択肢が広がります。

順序保証・スループット・再処理など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に寄っています。両方を1製品で満たそうとせず、要件がどちらの列に多く並ぶかで判定する使い方を想定した表です。

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

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

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

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

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

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

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で組む方が総コストは下がります。

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

自前運用の負担は、クラウドのマネージドサービスへ移すのが現実的な選択肢です。AWSならRabbitMQ互換のAmazon MQ、Kafka互換のAmazon MSKがあり、ブローカーのパッチ適用・フェイルオーバー・ストレージ拡張を提供側が引き受けるため、チームはキュー設計とアプリ実装に集中できます。専任インフラ担当を置けない体制でメッセージング基盤を入れるなら、自前構築ではなくマネージドから始めるのが妥当な判断です。どのサービスをどう組み合わせるかの構成設計から任せたい場合は、AWS・Google Cloud・Azureのインフラ構築支援のように設計と構築を外部へ委ねる方法もあり、要件整理の段階から相談する方が構成の手戻りを防げます。委託時は、メッセージ消失時の責任分界と監視項目を契約前に文書化しておくと運用開始後の齟齬を避けられます。

よくある質問

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

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

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

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

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

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

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

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

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

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

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

関連記事

• Apache Kafkaが選ばれる理由とは？特徴とメリットを徹底解説：本記事で比較したKafka側の仕組みと採用理由を単体で深掘りしています。
• イベント駆動アーキテクチャとは？仕組み・実装パターンと採用判断を実装者目線で解説：メッセージング基盤を使う上位の設計であるイベント駆動全体を整理しています。
• ストリーム処理とは？仕組み・処理モデルとバッチ処理との使い分けを実装視点で解説：Kafkaの主戦場である逐次データ処理の設計をバッチとの対比で解説しています。
• クラウドネイティブとは？CNCFの定義・構成技術・移行との違いと導入判断を解説：メッセージングを含むモダンアーキテクチャ全体の導入判断を整理した判断ハブです。