Azure Service Busとは？キューとトピックの仕組み・料金の実額と階層の選び方

Azure Service Busは、Microsoft Azureが提供するフルマネージドのメッセージブローカーです。送信側はメッセージをキューやトピックに預け、受信側は自分のタイミングで取り出すため、受信側が止まっていても送信側は止まりません。この記事では、キューとトピックの違い、デッドレターキュー・セッション・重複検出の既定値、Basic・Standard・Premiumの上限値、東京リージョンの料金の実額を公式ドキュメントとAzure Retail Prices APIの値で整理します。PythonとAzure Functionsの実装例と、2026年9月30日に終了した旧SDK・SBMPプロトコルの移行も扱います。

まとめ：Azure Service Busの役割と階層・料金を決める基準

Service Busは、受発注や在庫引き当てのように、メッセージの取りこぼしや順序の乱れが業務の損害になる連携に向いています。1対1で処理を渡すキューと、1件のメッセージを複数の購読者へ配るトピック/サブスクリプションの2つのモデルがあります。abandonやロック切れによって配信回数が既定の上限10回を超えたメッセージはデッドレターキュー（DLQ）へ移り、セッションを使えば同じセッションIDのメッセージを先入れ先出し（FIFO）で処理できます。

階層は機能で決まります。キューだけならBasic、トピック・セッション・トランザクション・重複検出が要るならStandard、専有リソース・最大100MBのメッセージ・Private Link・ジオレプリケーションが要るならPremiumです。東京リージョン（東日本）の小売価格は、Standardが月額1,575.5円（月1,300万操作まで込み）、Premiumが1メッセージングユニット（MU）あたり1時間146.1276円（730時間で約10.7万円）です。料金だけで比べるとPremiumが安くなるのは月約13億操作からなので、Premiumは性能の分離とネットワーク要件で選ぶ階層と考えてください。

2026年9月30日に旧SDK3種のサポートとSBMPプロトコルが終了しました（Service Bus自体は継続）。旧SDKで動いているシステムは、AMQPを使う現行SDKへの移行が必要です。

Azure Service Busの仕組みとキュー・トピックの違い

名前空間とメッセージブローカーとしての役割

Service Busでは、まず名前空間を作り、その中にキューやトピックを作成します。ブローカーがメッセージを受け付けると、3重に冗長化されたストレージに保存されます。ゾーン冗長を有効にした名前空間では、保存先が可用性ゾーンにまたがります。受信はプル型で、メッセージが届くまで待ち受ける長時間の受信にも対応しています。

送信側と受信側が同時に稼働している必要がない点が、同期的なAPI呼び出しとの違いです。処理の完了を待たずに次へ進む考え方は非同期処理と同期処理の違いで解説しています。

キュー（1対1）とトピック/サブスクリプション（1対多）の使い分け

キューは、複数のワーカーが1つのキューから取り合う競合コンシューマー構成に使います。トピックは、たとえば「注文確定」というイベントを会計・在庫・通知の3つのサブスクリプションへ同時に配る用途です。サブスクリプションごとにフィルターのルールを付けると、条件に合うメッセージだけがそのサブスクリプションへコピーされます。トピックを利用できるStandardとPremiumでは、1トピックあたりのサブスクリプションは最大2,000個です。この発行/購読の構成はイベント駆動アーキテクチャの実装パターンで中心になる仕組みです。

デッドレター・セッション・重複検出の既定値と設計の注意点

PeekLockの受信とDLQへ移る条件（最大配信回数10回）

既定の受信モードはPeekLockです。受信したメッセージはロックされます。処理に成功したら受信側がcompleteを呼び、失敗したらabandonで戻します。ロック期間の既定値は1分です。abandonするかロックが切れるたびに配信回数が1増え、既定値の10回を超えると、メッセージは理由コード MaxDeliveryCountExceeded 付きでDLQへ移ります。DLQはキューとサブスクリプションごとに自動で用意される副次キューで、別途作る必要はありません。

見落としやすいのは有効期限（TTL）切れの扱いです。期限切れのメッセージがDLQへ移るのは、キューやサブスクリプションで「期限切れ時のデッドレター」を有効にした場合だけです。無効のままだと期限切れのメッセージは削除され、DLQには残りません。もう1つは、完了処理の前に受信者や接続を閉じると完了の通知がサービスに届かず、ログ上は成功したのに再配信で配信回数が増えていく点です。アイドル状態の接続はサービス側が10分で切断するので、受信したメッセージを保持したまま後で完了させる実装は避けてください。

セッションによるFIFOの順序保証（Standard以上）

同じ顧客の「入金→出金」のように処理順に意味があるメッセージには、セッションを使います。送信側がセッションIDを付け、受信側がセッションを受け入れると、そのセッションIDのメッセージは1つの受信者に排他的に、順番どおり渡されます。AMQP 1.0のレベルでは、セッションIDはgroup-idプロパティに対応します。

セッションを有効にしたキューでは、セッションIDの無い通常メッセージを送受信できなくなります。順序が要らないメッセージまで同じキューに流す設計だと、ここで詰まります。順序が必要な流れと不要な流れはキューを分けてください。セッションはBasicでは使えません。

重複検出の時間枠とMessageIdの決め方

重複検出を有効にすると、指定した時間枠のあいだに送信されたメッセージの MessageId が記録されます。同じIDのメッセージがもう一度届くと、そのメッセージは受け付けられますが、すぐに破棄されます。時間枠の既定値は10分で、20秒から7日の範囲で設定できます。

効き目は MessageId の決め方で変わります。毎回ランダムなGUIDを振ると、送信の再試行で同じ注文が別IDになり、重複を検出できません。発注番号のように業務の文脈から再計算できる値を使ってください。パーティション分割を有効にしたエンティティでは、MessageId とパーティションキーの組で一意性を判定します。時間枠を過ぎた重複は防げないので、受信側の処理も同じメッセージを2回処理して問題が起きない形（冪等）にしておきます。

Basic・Standard・Premiumの機能差と上限値

3階層の機能と上限値の比較

Microsoft Learnのクォータ表（2026年8月11日更新）と料金ページの機能表をもとに、主な違いをまとめます。

Premiumの100MBには条件が2つあります。1つは、AMQPで送る場合に限られることです。HTTPでは単一メッセージの上限が1MBです（SBMPも同じ1MBでしたが、2026年9月30日で利用できなくなりました）。もう1つは、バッチ送信の上限がどのプロトコルでも1MBのままであることです。大きなペイロードは1件ずつ送る必要があります。エンティティごとの既定の上限は1MBなので、100MBまで送るにはキューやトピックの設定で上限を引き上げます。

PremiumのMU数とパーティション数の組み合わせ

Premiumでは、CPUとメモリを専有するメッセージングユニット（MU）を割り当てます。名前空間全体のMU数は、パーティション数の1・2・4・8・16倍から選びます。公式ドキュメントが示す目安は、1〜2MU（パーティションを使う場合は1パーティションあたり1MU）から始め、CPU使用率が25%を下回れば縮小、75%を上回れば拡張を検討するというものです。MU数は作成後も増減できます。課金は1時間ごとで、その時間内に割り当てたMU数の最大値で決まります。同じ時間内に縮小しても、その時間の料金は下がりません。

パーティション数は1・2・4から選びます。この値は名前空間の作成時にしか設定できず、後から変更できません。また、MU数はパーティション数の倍数にする必要があります。4パーティションで作った名前空間は最小でも4MUになるため、小さく始める予定ならパーティション数は1か2にしておくのが無難です。ジオレプリケーション（セカンダリリージョンへの複製）はPremiumの機能で、セカンダリも同じMU数で課金されます。複製したデータ量にも別途料金がかかります。

Azure Service Busの料金：東京リージョンの実額と試算

階層別の単価（東日本・円建て）

料金ページは表示にJavaScriptを使うため、ここではAzure Retail Prices API（認証不要）から東日本リージョン（japaneast）の円建て小売価格を取得しました（2026年10月9日時点・税抜）。為替と価格改定で変わるので、契約前に公式の料金ページで確認してください。

Standardには仲介接続（brokered connection）の課金もあります。AMQP接続などが対象で、課金は1時間ごとの同時接続数のピークを730で割って按分し、月で合計します。1,000接続分は基本料金に含まれ、同じAzureサブスクリプション内のキュー・トピック・サブスクリプションで共有されます。超過分は1接続あたり4.7265円からの段階料金です。受信側を多数のコンテナで常時接続させる構成では、操作数より先にこちらが効いてくる場合があります。

月間操作数別の試算とPremiumが割安になる境界

料金ページのFAQによると、64KB以下のメッセージの送信・受信・削除はそれぞれ1課金操作です。64KBを超えるメッセージは64KB単位で複数の操作になり、キューやトピックの作成・一覧取得などの管理操作も課金されます。注文件数と操作数は一致しないので、送信と受信の両方を数えてください。上の単価で、Standardの月額を操作数ごとに計算すると次のとおりです（仲介接続は1,000以内と仮定）。

料金だけで比べると、Premium 1MUがStandardより安くなるのは月約12.9億操作（730時間で均して毎秒約490操作）からで、それを下回る範囲ではStandardのほうが安く済みます。ただし、Standardには名前空間ごとに毎秒1,000クレジットのスロットリングがあります。送受信は1メッセージ1クレジット、管理操作は10クレジット、トピックのフィルター評価も1回1クレジットを消費するため、多数のフィルターを持つトピックでは、この操作数に届く前に制限にかかることがあります。Premiumを選ぶ理由は、ほかの利用者の負荷に左右されない性能、256KBを超えるメッセージ、Private LinkとVNet統合、ジオレプリケーションのいずれかが要件にある場合です。料金だけを理由にPremiumへ移るのは、MU数・仲介接続数・稼働時間を含めて比較し、それでも安くなる場合に限ってください。

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

Service Busを含む4サービスの比較

最も迷いやすいのはStorage Queuesとの選択です。Storage Queuesのメッセージは最大64KB（Base64エンコード時は48KB）ですが、キューの容量はストレージアカウントの上限まで使えます。Service Busはキュー1本あたり最大80GBです。Microsoftの比較ドキュメントは、80GBを超えるメッセージを1キューに溜める場合や、処理の進捗をキュー側で追跡したい場合にStorage Queuesを勧めています。逆に、FIFO、At-Most-Once配信（ReceiveAndDelete）、トランザクション、64KBを超えるメッセージのいずれかが要るならService Busです。

Event Hubsは、大量のイベントを取り込み、複数の消費側がそれぞれのペースで読み直す用途の基盤です。仕組みはAzure Event Hubsの解説で扱っています。Event Gridは、Blobへのアップロードなどの出来事を購読者へ配るルーターで、配信先にService Busキューを指定することもできます。再試行と順序の扱いはAzure Event Gridの名前空間と再試行の設計にまとめています。

Service Busを見送るべき3つの条件

次の条件に当てはまる場合は採用しないでください。

• 毎秒数千件以上のログやセンサー値を取り込む（Standardの上限は毎秒1,000操作。Event Hubsを使う）
• 順序・重複排除・トランザクションのどれも不要で、ジョブを1対1で渡すだけ（Storage Queuesで足りる）
• AWSやGoogle Cloudが主な基盤で、Azure側にはキューを置くだけ（クラウド間の通信と認証の管理が増える）

判断の目安として、要件に「順序」「二重処理の排除」「送受信をまたぐトランザクション」の3つのどれも入っていなければ、まずStorage Queuesで足りるかを確認してください。AWSで同じ役割を担うのはAmazon SQSの標準キューとFIFOキューです。他のブローカーとの設計思想の違いはRabbitMQとKafkaの違いでも整理しています。

PythonとAzure Functionsでの送受信の実装

Python SDK（azure-servicebus 7.15.0）でのキュー送受信

現行のPython SDKは azure-servicebus のバージョン7系です。掲載コードは7.15.0を使い、Python 3.12で構文と制御フローを確認しています（パッケージの要件はPython 3.9以上）。次のコードは、注文をバッチで送信し、受信側で処理に失敗した注文をDLQへ移します。MessageId には注文番号から作った値を入れています。重複検出が効くのは、Standard以上で重複検出を有効にした orders キューを作成済みで、再送が時間枠（既定10分）の内側にある場合です。

import json
import os

from azure.servicebus import ServiceBusClient, ServiceBusMessage

CONN_STR = os.environ["SERVICEBUS_CONNECTION_STRING"]
QUEUE = "orders"


def send_orders(orders):
    with ServiceBusClient.from_connection_string(CONN_STR) as client:
        with client.get_queue_sender(QUEUE) as sender:
            batch = sender.create_message_batch()
            for order in orders:
                batch.add_message(
                    ServiceBusMessage(
                        json.dumps(order),
                        message_id=f"order-{order['id']}",  # 重複検出の照合キー
                        content_type="application/json",
                    )
                )
            sender.send_messages(batch)


def process(order):
    if order["qty"] <= 0:
        raise ValueError("qty must be positive")
    print("processed", order["id"])


def receive_orders():
    with ServiceBusClient.from_connection_string(CONN_STR) as client:
        with client.get_queue_receiver(QUEUE, max_wait_time=5) as receiver:
            for msg in receiver:
                try:
                    order = json.loads(str(msg))
                    process(order)
                    receiver.complete_message(msg)
                except ValueError as e:
                    # 再試行しても直らない業務エラーは即DLQへ
                    receiver.dead_letter_message(
                        msg, reason="InvalidOrder", error_description=str(e)
                    )


if __name__ == "__main__":
    send_orders([{"id": 1, "qty": 2}, {"id": 2, "qty": 0}])
    receive_orders()

再試行しても結果が変わらない業務エラー（数量が0など）は、上限の10回まで待たずに dead_letter_message で直接DLQへ移しています。一方、DBのタイムアウトのような一時的な失敗は例外をそのまま投げ、ロックが切れた後の再配信に任せます。完了処理（complete）は with ブロックの中、つまり受信者を閉じる前に呼んでいます。このコードはPython 3.12で構文と分岐（completeとdead_letter）を確認済みですが、実際の名前空間への送受信は試していません。本番では接続文字列より、DefaultAzureCredential を使ったMicrosoft Entra ID認証を推奨します。

JavaScript／TypeScriptでは @azure/service-bus（7.10.0）、.NETでは Azure.Messaging.ServiceBus（7.21.0）、Javaでは com.azure:azure-messaging-servicebus（7.18.1）が同じ位置づけのSDKです（いずれも2026年10月9日時点の各レジストリの最新版）。

Azure Functionsのトリガーで受けるときの毒メッセージの扱い

受信側をAzure FunctionsのService Busトリガーで受ける場合、Pythonのv2プログラミングモデルでは次のように書きます。

import json
import logging

import azure.functions as func

app = func.FunctionApp()


@app.service_bus_queue_trigger(
    arg_name="msg", queue_name="orders", connection="ServiceBusConnection"
)
def handle_order(msg: func.ServiceBusMessage):
    order = json.loads(msg.get_body().decode("utf-8"))
    # 例外を投げると Abandon され、配信回数が上限（既定10）に達するとDLQへ移る
    logging.info("order=%s delivery_count=%s", order["id"], msg.delivery_count)

Functionsは、関数が正常に終わればcomplete、例外で終わればabandonを呼びます。公式ドキュメントは毒メッセージの処理を「Functions側で制御・設定できず、Service Bus自体が扱う」と明記しているので、リトライ回数はキューの最大配信回数で変えます。.NETの関数では、Service Bus拡張機能の5.x未満が終了した Microsoft.Azure.ServiceBus の型を使っている点に注意してください（5.x以降は Azure.Messaging.ServiceBus。isolated worker向けの最新は5.24.0）。Functionsのプランと料金はAzure Functionsの仕組みと料金プランで解説しています。

エミュレーターでのローカル検証と制約

開発とテストには、Microsoftが提供するService Busエミュレーターを使えます。エミュレーターはDockerコンテナとして動き、依存するSQL Server Linuxのコンテナと合わせて起動します。既定のポートは5672です。接続文字列は固定で、ローカル実行なら次の値を使います。

Endpoint=sb://localhost;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=SAS_KEY_VALUE;UseDevelopmentEmulator=true;

azure-servicebus 7.15.0のソースコードには UseDevelopmentEmulator を解釈する処理があり、エミュレーターではキューが自動作成されないため、コードと同じ orders キューを設定ファイル（Config.json）に定義するか、管理クライアントで作成してから、環境変数 SERVICEBUS_CONNECTION_STRING を上の値に差し替えます。エミュレーターでは、パーティション化したエンティティ、JMS、AMQP over WebSocket、大容量メッセージ、Entra ID認証、自動スケールは使えません。コンテナを再起動するとデータとエンティティは消えます。SLAが無いため、本番ワークロードには使えません。

2026年9月30日に終了した旧SDK・SBMPと移行手順

旧SDKのサポート終了とSBMPの利用停止

Service Bus自体の提供終了は発表されていません。Microsoftの終了告知によると、2026年9月30日に終わったのは次の2つです。

• Azure SDKのガイドラインに沿っていない旧SDK3種のサポート（WindowsAzure.ServiceBus、Microsoft.Azure.ServiceBus、com.microsoft.azure.servicebus）
• SBMP（Service Bus Messaging Protocol）のサポート。期日以降はこのプロトコルを使えない

旧SDKは期日以降も動きますが、Microsoftのサポートと更新は受けられません。危ないのはSBMPです。.NET Framework向けのWindowsAzure.ServiceBusは、既定でSBMP（SOAPベースの独自プロトコル）を使って通信します。接続文字列の ;TransportType=Amqp と、クライアント生成時の TransportType 設定のどちらでもAMQPを指定していなければ、SBMPで接続しています。なお、PythonのSDKは0.50系以前から7系への移行が推奨されています。ただし、0.50系にこの期日が適用されるという一次情報は確認できていません。

移行先SDKと既存システムの確認手順

移行先は、.NETなら Azure.Messaging.ServiceBus、Javaなら com.azure:azure-messaging-servicebus です。どちらも既定でAMQPを使います。既存システムでは、まず依存関係の一覧（.NETは dotnet list package --include-transitive、Javaは依存ツリー）で旧パッケージ名を探します。見落としやすいのは、BizTalk Server 2020のような製品、古いFunctions拡張機能、フレームワークが間接的に旧SDKやSBMPを使っているケースです。

QueueClient 中心のクラス構成が送信者・受信者・プロセッサーの単位に変わるため、パッケージの差し替えだけでなく受信処理の書き直しが必要です。旧SDKからの移行やSBMP依存の洗い出しを、Azure基盤の設計と合わせて進める場合は、クラウドインフラ構築（AWS・Google Cloud・Azure）の支援もご相談いただけます。

Azure Service Busについてよくある質問

Azure Service Busはいつから停止するのですか？

Service Bus自体の提供終了は発表されていません。2026年9月30日に終わったのは、旧SDK3種（WindowsAzure.ServiceBus、Microsoft.Azure.ServiceBus、com.microsoft.azure.servicebus）のサポートと、SBMPプロトコルのサポートです。旧SDKは期日以降も動きますが、サポートと更新はありません。SBMPは期日以降は使えないため、既定でSBMPを使うWindowsAzure.ServiceBusの利用者はAMQPの現行SDKへ移行してください。

Azure Service Busの料金はいくらですか？

東日本リージョンの小売価格（2026年10月9日時点・税抜）は、Basicが100万操作あたり7.8775円、Standardが月額1,575.5円（月1,300万操作まで込み、超過分は100万回あたり126.04円から段階的に低下）、Premiumが1MU・1時間あたり146.1276円（730時間で約10.7万円）です。料金だけで比べると、Premiumが割安になるのは月約13億操作からです。

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

Service Busはセッションによる順序保証、トピック、トランザクション、重複検出、DLQを備えた業務向けのブローカーです。Storageキューは最大64KBのメッセージを扱うシンプルなキューで、順序保証はありません。その代わり、キューの容量はストレージアカウントの上限まで使えます。順序・重複排除・トランザクションのどれかが要るならService Busです。どれも要らない場合でも、64KBを超えるメッセージ、トピックでの配信、DLQが必要ならService Busを選びます。

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

BasicとStandardは256KBです。Premiumは、AMQPで送る場合に1メッセージ最大100MBまで設定できます。ただし、エンティティの既定値は1MBなので、上限の引き上げが必要です。HTTPでは単一メッセージが1MBまでで、バッチ送信はプロトコルにかかわらず1MBまでです。サイズにはヘッダーとプロパティも含まれます。

Service Busのキューとトピックはどう使い分けますか？

1件の処理を1つの受信者に任せるならキュー、1件のイベントを複数のシステムに届けるならトピックを使います。トピックはサブスクリプションごとにメッセージを複製し、フィルターで受け取る条件を絞れます。Basicでは使えず、Standard以上が必要です。

関連記事

• Azure Event Hubsとは｜大量イベントを取り込むKafka互換ストリーミング基盤の仕組みと採用判断
• Azure Event Gridとは？名前空間とカスタムトピックの違い・再試行と順序の設計を実装者目線で解説
• Azure Functionsとは？仕組み・料金プラン・使い方をわかりやすく解説【2026年版】
• AMQPとは？0-9-1と1.0の違い・ルーティングの仕組みと採用判断を実装者向けに解説
• Outboxパターンとは？DB更新とイベント発行を一致させる実装方式を解説【2026年版】