Azure Service Bus入門｜Queue・TopicとAWS SQSとの違いをオンプレ経験者向けに解説する実践ガイド

Azure Service Busを最初に触ったとき、「Topicが作れない」「BasicではなくStandard以上にしないといけなかったのか」という経験をしたエンジニアは多い。AWS SQSを触ってきた人には「キューだけあればいい」という思い込みがあり、Azure Service Busの「Queue＋Topic」の二重構造とティア制限の組み合わせで最初は混乱しがちだ。

この記事では、Azure Service Busの基本概念から、Queue・Topicの設計判断、3段階の料金ティア、Azure CLIによる操作手順、そしてEvent Grid・Event Hubsとの使い分けまで、オンプレのMQ経験者が現場で即使えるレベルで解説する。

Azure Service Busとは？オンプレのメッセージキューとの違い

Azure Service Busは、Microsoftが提供するフルマネージドのエンタープライズメッセージブローカーだ。オンプレではActiveMQやRabbitMQ、IBM MQをサーバーにインストールして自前でクラスタ管理していたものが、Azureではサーバー管理不要でそのまま使えるサービスとして提供されている。

オンプレのMQとの主な違いを整理する。

・サーバー管理不要: ブローカーのOS更新、クラスタ管理、スケールアップは不要。名前空間（Namespace）という単位でリソースを確保するだけだ。
・耐久性の担保: メッセージはデフォルトで複数レプリカに書き込まれる（Standard・Premium）。RabbitMQのミラーキューを自前で構成していた作業が不要になる。
・AMQP 1.0対応: 業界標準プロトコルを採用しているため、既存のAMQPクライアントがほぼそのまま動く。
・AWS SQSとの概念的な違い: AWS SQSはQueueのみ（パブリッシュ/サブスクライブはSNSが別サービスとして担当）。Azure Service Busは1つのサービスでQueueとTopicの両方を提供する。

なお、オンプレからAzure VMへのリフトアンドシフト時のLinuxサーバー管理・構築については、姉妹サイトLinuxMaster.JPでも詳しく解説している。

QueueとTopicの違い — 2つのエンティティを使い分ける

Azure Service Busには「Queue」と「Topic」という2種類のメッセージエンティティがある。この二重構造がAWS SQS単体しか知らないエンジニアが最初につまずく部分だ。

1. Queue（キュー）— ポイント・ツー・ポイント型

Queueは1対1のメッセージ配信だ。送信者（Producer）がメッセージを送ると、1つの受信者（Consumer）がそのメッセージを受け取る。受け取られたメッセージはQueueから削除される（Complete操作が発行された場合）。

典型的なユースケースは「注文処理ジョブキュー」だ。フロントエンドが注文をQueueに投入し、バックエンドの注文処理サービスが1件ずつ取り出して処理する。同じメッセージを複数の処理サービスに届ける必要はない。

・AWS対応: Amazon SQS StandardまたはFIFO Queueに相当。
・オンプレ対応: ActiveMQのQueue、RabbitMQのDirect Exchange + Queue。
・対応ティア: Basic・Standard・Premium（すべてで利用可能）。

2. Topic（トピック）— パブリッシュ/サブスクライブ型

Topicは1対多のメッセージ配信だ。1つのTopicに送られたメッセージを、複数のSubscription（サブスクリプション）が独立して受け取れる。各Subscriptionにはフィルタリングルールを設定できる。

典型的なユースケースは「在庫変更イベントの複数サービスへの配信」だ。在庫管理サービスが変更をTopicに送ると、「発注サービス」「倉庫サービス」「分析サービス」が同じメッセージをそれぞれ独立して受け取り、自分の処理を実行する。

・AWS対応: Amazon SNS（Topic）+ SQS（Subscription）のファンアウト構成に相当。Service Bus単体でその役割を担う。
・オンプレ対応: ActiveMQのTopic、RabbitMQのFanout/Topic Exchange。
・【重要】対応ティア: StandardとPremiumのみ。Basicでは使用不可。

3. どちらを選ぶか？判断基準

Azure Service Busの料金体系（2026年1月時点）

Azure Service Busには3つのティアがある。ティアは名前空間作成時に選択し、後から変更は原則できない（名前空間を作り直す必要がある）。設計段階でしっかり選んでおくことが重要だ。

※ Japan Eastリージョン・2026年1月時点のUSD概算。レートや価格改定があるため、見積もりはAzure公式価格計算ツールで必ず確認すること。

Basicが適しているケース: TopicやVNet統合が不要で、処理量が少ないPoC・開発環境。ただし後からStandardへの変更はできない点に注意。将来Topicが必要になっても名前空間ごと作り直す必要が生じる。

StandardとPremiumの選定ポイント: Premiumは専用リソース（他テナントとの共有なし）であるためレイテンシが安定している。またVNet統合でプライベートエンドポイント経由のアクセスが可能だ。金融・医療のようにコンプライアンス要件が厳しい環境や、XMLやJSONバルク転送のような大容量メッセージが発生するシステムではPremiumが実質必須となる。

Azure Virtual Network（VNet）のサブネット設計と組み合わせることで、PremiumのPrivate Endpointによるセキュアな接続構成を実現できる。

基本的な使い方（Azure CLI）

1. 名前空間（Namespace）の作成

名前空間はAzure Service Busリソースのルートコンテナだ。名前空間名はグローバルに一意で、<namespace>.servicebus.windows.net というエンドポイントになる。

# Azure CLI — リソースグループ作成（既存RGがあればスキップ）
az group create --name myRG --location japaneast

# Service Bus 名前空間の作成（Standard ティア）
az servicebus namespace create \
  --resource-group myRG \
  --name mySBNamespace \
  --location japaneast \
  --sku Standard

# 接続文字列の確認
az servicebus namespace authorization-rule keys list \
  --resource-group myRG \
  --namespace-name mySBNamespace \
  --name RootManageSharedAccessKey \
  --query primaryConnectionString \
  --output tsv

2. QueueとTopicの作成

# Azure CLI — キューの作成（メッセージロック5分、TTL1日）
az servicebus queue create \
  --resource-group myRG \
  --namespace-name mySBNamespace \
  --name orderQueue \
  --lock-duration PT5M \
  --default-message-time-to-live P1D \
  --max-size 1024

# トピックの作成
az servicebus topic create \
  --resource-group myRG \
  --namespace-name mySBNamespace \
  --name inventoryTopic

# サブスクリプションの作成（全メッセージを受信）
az servicebus topic subscription create \
  --resource-group myRG \
  --namespace-name mySBNamespace \
  --topic-name inventoryTopic \
  --name warehouseSubscription

3. 接続文字列とアクセス管理のベストプラクティス

実際のメッセージ送受信はSDK（Python・Java・.NET・JavaScriptなど）経由で行う。CLIでの直接送受信はできないが、Azure Portalの「Service Bus Explorer」機能（ブラウザ上でメッセージを送受信できる）を使って動作確認が可能だ。

接続文字列の安全な管理方法:

・開発環境: 環境変数に格納（コードへの直書きは絶対禁止）。
・本番環境: Azure Key Vaultにシークレットとして格納し、アプリがKey Vaultから取得するパターンを採用する。
・より安全な方法: Azure Managed Identityを使えば接続文字列自体の管理が不要になる。Azure Functionsなどから接続する場合は、Managed Identityを使ったパスワードレス認証が推奨だ。

Event Grid・Event Hubsとの違いと使い分け

Azureには「メッセージング・イベント系」サービスが複数あり、どれを選べばいいか迷いやすい。Service Bus・Event Grid・Event Hubsは目的が根本的に異なる。

使い分けの具体的な判断基準:

・Service Bus を選ぶ: 注文・支払い・ジョブキューなど、確実に1度だけ処理したい、失敗時に再試行したい、メッセージの順序が重要なケース。「ビジネスロジックの実行を確実に委譲する」用途に適している。
・Event Grid を選ぶ: 「BlobストレージにファイルがアップロードされたらFunctionsを起動する」「VMが作成されたらSlackに通知する」など、Azureリソースの状態変化に反応して何かを起動するケース。
・Event Hubs を選ぶ: IoTデバイスからの大量センサーデータ収集、アクセスログの大量パイプライン処理、Apache Kafkaとの互換が必要なストリーミング処理のケース。

実務Tips — Dead Letter QueueとMessage Lock設計

1. Dead Letter Queue（DLQ）の仕組みと監視

Dead Letter Queue（DLQ）は、処理に失敗したメッセージや有効期限切れのメッセージが自動的に移される特殊なサブキューだ。Azure Service Busではすべてのキュー・Subscriptionに自動でDLQが付属する。オンプレのMQではDLQを自前実装することが多かったが、Service Busでは設定不要で最初から使える。

DLQに移されるタイミング:

・最大配信回数（MaxDeliveryCount、デフォルト10回）を超えた場合
・メッセージのTTL（Time-to-Live）が期限切れになった場合
・TopicのSubscriptionフィルタルール評価でエラーが発生した場合

DLQパスは <queue-name>/$deadletterqueue という形式でアクセスできる。本番運用では必ずAzure MonitorにDLQメッセージ数のアラートを設定し、DLQ専用の再処理ロジックを用意すること。DLQを放置するとシステムの問題が見えなくなる。

2. メッセージロック設計とMaxDeliveryCount

「メッセージロック」はService Busの信頼性を支えるキモだ。ConsumerがQueueからメッセージを取り出すと、設定したLock Duration（ロック期間）の間、他のConsumerから見えなくなる。この間にCompleteを返さないとロックが解放され、同じメッセージが再配信される。

よくあるトラブルと対処法

【症状】Topic/Subscriptionが作成できない
Basicティアの名前空間ではTopicが使えない。Azure Portalでも作成ボタンがグレーアウトしている。解決策はStandard以上の名前空間を新規作成することだ。ティアの変更はできないため、Basicで作った名前空間はそのまま使い続けるか削除するかの2択になる。

【症状】プライベートエンドポイント経由でアクセスしたい
Standard名前空間はVNet統合・Private Endpointに対応していない。Azure Private Linkを使ったプライベートエンドポイント接続が必要な場合はPremiumが必須となる。Standardでは<namespace>.servicebus.windows.net:5671/443のパブリックエンドポイントを使いつつ、IPアクセス制限でセキュリティを担保する構成が現実的だ。

【症状】同じメッセージが複数回処理される
Lock Durationを超えてもCompleteが届かない場合、ロックが解放されて別のConsumerが同じメッセージを取り出せるようになる。処理の冪等化と、長時間処理向けのRenew Lock実装を検討すること。

【症状】DLQにメッセージが溜まる一方
DLQを読み出す仕組みを用意していない場合に起きる。DLQは自動的には消えないため、DLQ専用のConsumerまたは定期ジョブを設けて対処すること。Azure Monitorのカスタムメトリクスアラートでしきい値を設定し、運用担当者に通知する体制を作ること。

本記事のまとめ

Azure Service Busは、オンプレのActiveMQ・RabbitMQに相当するフルマネージドのエンタープライズメッセージブローカーだ。AWSでのSQS・SNSの組み合わせをAzureでは1サービスで担う。