Azure Service Busとは？キュー・トピックの仕組みと料金階層・使い分けを実装視点で解説

Azure Service Busは、Microsoft Azureが提供するフルマネージドのエンタープライズメッセージブローカーです。アプリケーション同士を直接つながず、送信側と受信側の間にメッセージの受け渡し役を挟むことで、システムを疎結合に保ったまま非同期でデータをやり取りできます。この記事では、キューとトピック/サブスクリプションという2つの通信モデル、順序保証・デッドレター・重複検出といった機能、Basic/Standard/Premiumの3階層の違いと選び方、そしてStorage Queues・Event Hubs・Event Gridとの使い分けまでを実装の解像度で整理します。到達点は、どのサービスをどの階層で選び、どう組み込むかを自分で判断できる状態です。

まとめ：Service Busは順序と信頼性を重視する業務メッセージングの基盤

Azure Service Busは、注文処理や在庫連携のように「取りこぼしが許されない」業務メッセージングのために設計されたブローカーです。1対1で処理を渡すキューと、1件のメッセージを複数の受信側へ配るトピック/サブスクリプション（pub/sub）の2モデルを持ちます。セッションによる順序保証、デッドレターキュー、重複検出、スケジュール配信といった機能が、システム間連携の信頼性を担保します。

選定はまず階層から入ります。トピックやセッションが必要ならStandard以上、専有リソースと100MBの大容量メッセージ、Private Linkやジオレプリケーションが要るならPremiumです。用途が単純なジョブ投入で高度な機能が不要ならStorage Queues、毎秒数百万件のテレメトリ取り込みならEvent Hubs、Azureリソースのイベント通知ならEvent Gridと、目的で棲み分けます。Service Busが向くのは、順序・重複排除・トランザクションといった業務要件が絡む連携です。逆に大量ストリーム取り込みや軽量なジョブキューには過剰投資になります。実装では、送信はSDKから、受信はAzure Functionsのトリガーで受ける構成が定番になります。なお2026年9月30日にSBMPプロトコルのサポートが終了予定のため、新規実装はAMQPベースの最新SDKで組むのが前提です。

Azure Service Busの定義：メッセージブローカーが疎結合を生む仕組み

まずService Busが何を担う部品なのかを、メッセージブローカーという役割から押さえます。ここが曖昧なまま機能比較に入ると、選定を誤ります。

送信側と受信側を切り離すメッセージブローカーとしての中心的な役割

Service Busは、アプリケーションAがアプリケーションBを直接呼ばず、間に置いたキューへメッセージを預ける方式で連携を仲介します。Bが停止していてもメッセージはキューに残り、Bが回復してから処理を再開できます。この「相手の稼働状況に依存しない」性質こそ疎結合の本質です。送信側は受信側の処理速度に引きずられず、受信側は自分のペースでメッセージを取り出せます。同期的なAPI呼び出しと違い、処理を待たずに先へ進める非同期メッセージングの基盤であり、その考え方の全体像は非同期処理と同期処理の違いの解説で扱っています。Service Busはこの非同期連携を、運用の手間なくマネージドで実現する選択肢です。

キューとトピック/サブスクリプションという2つの基本通信モデル

Service Busには、宛先の数が異なる2つのモデルがあります。使い分けを誤ると設計をやり直すことになるため、最初に押さえます。

キューは、複数のワーカーで1つのキューを取り合い、負荷を分散する競合コンシューマーの構成に向きます。トピックは、たとえば「注文確定」という1件のイベントを、会計・在庫・通知の3サブスクリプションへ同時に配る発行/購読（pub/sub）がその役割です。この1対多の配信はイベント駆動アーキテクチャの実装パターンの中核となる仕組みで、サブスクリプションごとにフィルター条件を付ければ、必要なメッセージだけを各システムへ振り分けられます。

Azure Service Busの主要機能：順序保証・デッドレター・重複検出

Service Busが単なるキューと一線を画すのは、業務連携で必要になる信頼性機能を標準で備える点です。実務で使う機能を優先度順に見ます。

メッセージの順序保証を担うセッションとデッドレターキューの役割

メッセージの処理順が意味を持つ場合（同一顧客の入金→出金など）、セッションを使うと同じセッションIDのメッセージが順序どおり、かつ同一の受信者に届きます。処理に失敗し続けたメッセージや有効期限切れのメッセージは、自動的にデッドレターキュー（DLQ）へ退避され、本流の処理を止めずに後から原因を調査できます。DLQはService Busが標準で用意する副次キューで、実装者が別途キューを作る必要はありません。処理側では、まず正常系のキューを空にし続けることを優先し、DLQに溜まったメッセージは定期バッチで棚卸しする運用分担が現実的です。

重複検出・スケジュール配信・トランザクションが支える連携の信頼性

ネットワーク再送などで同じメッセージが二重に届く問題には、重複検出が効きます。指定した時間枠内で同一のMessageIdを持つメッセージを1件だけ受け付け、残りを破棄するのがその働きです。ほかにも、指定時刻まで配信を保留するスケジュール配信、複数の送受信を1単位として成否をそろえるトランザクション、一定時間だけ受信を保留するメッセージ遅延（デファー）があり、これらは主にStandard以上で利用できます。RabbitMQなど他のブローカーから移ってきた場合、こうした機能がマネージドで揃う点がService Busの持ち味で、ブローカーごとの設計思想の違いはRabbitMQとKafkaの使い分けの解説と併せて比較すると選定の軸が定まります。

SBMPプロトコルの廃止とAMQPへの移行という直近の実装事項

実装で見落とせない直近の事実として、旧来のSBMP（Service Bus Messaging Protocol）のサポートが2026年9月30日に終了予定です。それ以降はSBMPで接続できなくなるため、新規実装・既存改修ともにAMQP 1.0対応の最新Azure Service Bus SDKで組む必要があります。AMQPは業界標準のメッセージングプロトコルで、Premium階層で100MBの大容量メッセージを送れるのもAMQP経由に限られます（SBMP/HTTPでは上限1MB）。すでに稼働中のシステムがSBMPベースのSDKに依存している場合は、この期日までにSDK移行を計画しておくのが安全です。

料金階層Basic・Standard・Premiumの機能差と選び方

Service Busは3つの階層で提供され、使える機能と課金方式が異なります。必要な機能から逆算して階層を決めるのが定石です。

Basic・Standard・Premium3階層の機能差と課金モデルの違い

Basicはキューのみ、Standardはトピック/サブスクリプションやセッションを含む共有基盤、Premiumは専有リソースを割り当てる構成です。主な差は次のとおりです（2026年7月時点・Microsoft Learn記載に基づく）。

課金の考え方が階層で変わる点に注意します。BasicとStandardは送受信の操作数に応じた従量課金で、負荷が読みにくいうちはコストが変動するのが特徴です。Premiumはメッセージングユニット単位の固定課金で、操作数の追加課金がないため、高負荷で予測可能な性能が要るほど割安になります。まずStandardで機能要件を満たすか確認し、性能の安定やネットワーク分離が要件化した段階でPremiumへ移すのが、投資を先行させすぎない進め方です。

Premium階層のメッセージングユニットとスケールの考え方

Premiumでは、CPUとメモリを専有する単位であるメッセージングユニット（MU）を、1・2・4・8・16のいずれかで割り当てます。負荷に応じてMU数を動的に増減でき、Microsoft LearnはCPU使用率が25%を下回れば縮小、75%を上回れば拡張、メモリ使用率が60%を超えたら拡張を検討する目安を示しています。開始時は1〜2MU（パーティション利用時は1パーティションあたり1MU）から始め、リソース使用率メトリクスを見て調整するのが実務の型です。可用性ゾーンをまたぐ冗長構成や、プライマリ/セカンダリ間でメタデータとデータを複製するジオレプリケーションもPremiumの機能で、業務停止が許されないシステムの災害対策に用います。

Storage Queues・Event Hubs・Event Gridとの使い分け

Azureには目的の異なるメッセージング/イベントサービスが複数あり、Service Busを含む4つを混同すると設計を誤ります。役割で切り分けます。

Service Busを含む4サービスの守備範囲の違いを一枚で整理

実務でまず迷うのはService BusとStorage Queuesの選択です。セッション・トピック・トランザクションのいずれも要らず、単にジョブを1対1で渡すだけならStorage Queuesで十分で、コストも操作数課金で軽く済みます。一方でEvent Hubsは配信保証を持つメッセージングではなく、大量データを取り込んで複数コンシューマーが再生する用途に振り切った基盤です。Event Hubsとの違いは、扱う対象がキュー内の個別メッセージか連続するイベントストリームかにあり、その処理モデルの差はストリーム処理とバッチ処理の使い分けの解説と重なります。Event Gridは、Blobのアップロードやリソース作成といった「出来事」を購読者へ配るルーターで、Service Busキューを配信先の1つに指定することもできます。

Service Busを採用すべき場面と見送るべき場面の判断基準

ここは条件を付けて言い切ります。Service Busを採用すべきなのは、メッセージの順序保証（FIFO）、二重処理の排除、送受信をまたぐトランザクション、失敗メッセージの隔離といった業務要件が1つでも絡む連携です。決済・受発注・在庫引き当てのように、1件の取りこぼしや順序の乱れが実害につながる領域が代表例になります。逆に見送るべきなのは、毎秒数十万件を超えるテレメトリやログの取り込み（Event Hubsの領域）、Azureリソースのイベント通知だけが目的のケース（Event Gridの領域）、そして高度な機能を一切使わない単純なジョブキュー（Storage Queuesで十分）です。とくに「とりあえず高機能なService Busにしておく」という選び方は、Storage Queuesで足りる要件に対しては基本料金と運用の複雑さを増やすだけの過剰投資になります。要件表を作り、順序・重複・トランザクションの3項目に1つも該当しなければ、まずStorage Queuesを疑うのが失敗を避ける順序です。

マイクロサービス連携とAzure Functionsでの受信実装

選定の次は組み込み方です。Service Busは単体で完結せず、送信側・受信側のアプリケーションと組み合わせて初めて機能します。

Azure Functionsのトリガーでメッセージを消費する定番構成

受信側を常時起動のサーバーで持つ代わりに、Azure FunctionsのService Busトリガーで受ける構成が広く使われます。キューやサブスクリプションにメッセージが届くとFunctionが自動的に起動し、処理が終わればスケールインするため、負荷に応じたコストで消費側を運用できるのがこの構成の利点です。送信側はSDKからキュー/トピックへメッセージを投げるだけで、両者はService Busを介して疎結合のまま連携します。Functions側の料金プランや起動の仕組みはAzure Functionsの仕組みと料金プランの解説を参照してください。実装時は、Functionの処理が失敗したメッセージがDLQへ回るよう最大配信回数を設定し、リトライ戦略を明示しておくと、障害時にメッセージが無限に再処理される事態を防げます。

マイクロサービス間の疎結合を実現する非同期メッセージング連携

Service Busが力を発揮するのは、複数のサービスを疎結合で連携させるマイクロサービス構成です。サービス同士が同期APIで直接呼び合うと、1つの障害が連鎖して全体が止まりますが、間にService Busを挟めば受信側が落ちてもメッセージはキューに残り、回復後に処理を継続できます。この設計判断の前提となるモノリスとの違いや分割の考え方はマイクロサービスとモノリスの違いと選び方で整理しました。トピックを使えば1つのイベントを複数サービスへ配れるため、サービスを追加してもイベントの発行側を変更せずに購読者を増やせる拡張性が得られます。

Azure基盤の設計・メッセージング実装を外部と進める選択肢

Service Busの導入は、階層選定やパーティション設計、DLQの運用ルール、SBMPからAMQPへの移行計画まで、判断すべき論点が広がります。自社にAzureの設計・運用の知見が薄い場合、要件に合った階層と構成を最初に固めておかないと、後から専有リソースへの移行やSDK刷新で手戻りが発生するのが典型です。Azureを含むクラウド基盤の設計からメッセージング連携の実装までを外部と進めるなら、クラウドインフラ構築（AWS・Google Cloud・Azure）の支援のような伴走型のサービスを起点にすると、自社の要件に合わせて過不足のない構成を選べます。まずはどのメッセージングサービスをどの階層で使うかを棚卸しするだけでも、初期設計の誤りを減らせます。

Azure Service Busの導入を検討する現場でよく寄せられる質問

Service Busを検討する際に、実務でよく挙がる疑問に答えます。

Azure Service BusとAzure Storageキューの違いは何ですか？

Service Busは順序保証・トピック/サブスクリプション・トランザクション・デッドレターといった業務向けの信頼性機能を備えたエンタープライズブローカーで、Storageキューはこうした高度な機能を持たない軽量で安価な単純キューです。セッションやpub/sub、重複検出のいずれも不要で、単にジョブを1対1で渡すだけならStorageキューで足り、コストも操作数課金で軽く済みます。

Service BusとEvent Hubsはどう使い分けますか？

Service Busは個別メッセージを確実に届ける業務メッセージング、Event Hubsは毎秒数百万件規模のイベントを取り込むストリーム基盤です。取りこぼしや順序が問題になる連携はService Bus、テレメトリやログを大量に集めて複数の消費側が再生する用途はEvent Hubsが向きます。Event Hubsはメッセージ単位の配信保証を持たない点が、両者の決定的な違いです。

Service Busのメッセージサイズの上限はどれくらいですか？

StandardとBasicは1メッセージあたり256KBが上限です。Premiumでは大容量メッセージ機能により最大100MBまで送れますが、これはAMQPプロトコル経由に限られ、SBMPやHTTPでは1MBにとどまります。大きなペイロードは性能低下と遅延増加を招くため、100MBまで送れても実際にはできるだけ小さく保つのが推奨される使い方です。

Basic・Standard・Premiumはどう選べばよいですか？

キューだけで足りるならBasic、トピック/サブスクリプションやセッション・トランザクションが要るならStandard、専有リソースによる安定した性能・100MBの大容量メッセージ・Private Linkやジオレプリケーションが要るならPremiumです。多くの業務連携はStandardで要件を満たせるため、まずStandardで検証し、性能の予測可能性やネットワーク分離が要件化した段階でPremiumへ移行するのが現実的です。

Service Busで順序どおりに処理させるにはどうすればよいですか？

順序制御にはセッション機能を使うのが基本です。同じセッションIDを付けたメッセージは順序を保って、かつ同一の受信者に届くため、同一顧客の一連の処理などをFIFOで扱えます。セッションはStandard以上の階層で利用でき、順序が意味を持たない処理では無効のまま複数ワーカーで並列に消費するほうがスループットは上がります。

関連記事

• 非同期処理とは？同期処理との違いから実装方式まで実装者目線で解説：Service Busが実現する非同期メッセージングの土台となる考え方を、同期処理との対比で解説します。
• イベント駆動アーキテクチャとは？仕組み・実装パターンと採用判断を実装者目線で解説：トピック/サブスクリプションによるpub/subを中核に据えるアーキテクチャの全体像を扱います。
• マイクロサービスとは？モノリスとの違い・メリット・デメリットと選び方、モジュラモノリスまで整理：Service Busで疎結合にするマイクロサービス連携の前提となる設計判断を整理します。
• RabbitMQとKafkaの違いとは？設計思想・性能・使い分けの判断基準を実装視点で解説：他のメッセージブローカーの設計思想と比べることで、Service Busの立ち位置が見えます。
• Azure Functionsとは？仕組み・料金プラン・使い方をわかりやすく解説【2026年版】：Service Busトリガーでメッセージを消費する定番の受信側サービスを解説します。
• ストリーム処理とは？仕組み・処理モデルとバッチ処理との使い分けを実装視点で解説：Event Hubsとの違いにつながる、ストリーム処理の考え方を扱います。