Azure Service Busのシステム開発の完全ガイド

Azure Service Busは、業務アプリ同士のメッセージを一時保管して受け渡す基盤です。Queueは一つの処理系へ届ける用途、TopicとSubscriptionは複数の処理系へ配る用途に向いています。非同期処理や再送・復旧の設計によって、安定性と開発規模が変わります。

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

Azure Service Busの概要

Azure Service Busは、業務メッセージを一時保管し、複数のアプリケーションへ受け渡すマネージド型メッセージブローカーです。システム間の待ち合わせと再処理を担う仕組みで、画面を持つ業務アプリとは役割が異なります。

送信側と受信側の間にメッセージを保管する場所を置くため、受信側が停止しても送信側は処理を続けやすくなります。あわせて、繁忙時間帯の処理も平準化できます。

ただし、メッセージの到達と業務処理が一度だけ完了することは別です。再送が起きる前提で、重複処理を防ぐ設計が必要です。

Namespace・Queue・Topicの役割

NamespaceはQueueやTopicを収容する管理単位です。ネットワーク制御や料金プラン、監視の設定も、この単位で検討します。可用性やリージョン間の復旧設定についても、同じ単位で考えます。

Queue：原則として一つの処理系がメッセージを受け取ります。
TopicとSubscription：一つのイベントを複数の処理系へ配信します。

たとえば、注文イベントを在庫、配送、分析、通知へ渡す場合は、TopicとSubscriptionで購読先を分けられます。

非同期化で解決できる課題

同期APIだけで注文、請求、在庫引当、メール送信を続けると、一つの処理の遅れが利用者の待ち時間を延ばします。一方、Service Busを間に置くと、注文受付は受付完了のメッセージを保存した時点で応答し、後続処理をワーカーが順に実行できます。

障害が起きた場合も、再試行やDead-letter queueによる隔離ができます。そのため、失敗を見えないまま捨てにくくなります。

Azure Service Busの種類と使い分け

用途の幅と処理の平準化を一望できます。

設計では、まず受信者、許容遅延、再処理の必要性を決めておきます。機能名で選ぶより、業務イベントの性質からQueue、Topic、他のメッセージサービスを選ぶほうが、失敗を減らせます。

Queueに向く、1対1に近い処理分担

Queueは、注文後の請求、画像変換、在庫連携など、一つの処理結果を確定させる業務に向いています。ワーカーを複数使う場合も、各メッセージを一つの処理系が担当する競合コンシューマー型にできます。

Queueは、ピーク時に処理が集中しても、メッセージを一時保管して、平均的な速度で消化できます。

TopicとSubscriptionに向く、複数部門への配信

Topicは、一つのメッセージを複数のSubscriptionへ配信します。注文確定イベントを在庫、配送、売上分析、顧客通知へ分けると、購読先ごとに処理を独立させやすくなります。

ただし、Subscriptionのフィルターに複雑な業務判断を詰め込むと、後から変更するのが難しくなります。そこで、大まかな振り分けはBrokerに任せ、細かなルールは受信側で判断します。

Event Grid・Event Hubsとの違い

短い通知をイベント発生元から配信する場合はEvent Grid、大量の時系列データを取り込む場合はEvent Hubsが候補です。一方、業務メッセージを保持し、処理結果の確認や再試行、Dead-letter運用を重視するなら、Service Busが適しています。

Azureの選択ガイドでも、コマンド転送や再処理を重視する用途として整理されています（出典: Azure Architecture Center、2026年確認）。

ポイント

受け取る処理系が一つで結果を確定させる業務はQueue、複数部門へ配る業務はTopicとSubscriptionが向きます。受信者の数と許容遅延、再処理の要否を先に決めると、選び間違いが減ります。

Azure Service Busを使ったシステム構成例

購読先ごとに後続処理を分ける構成です。

送信元や受信ワーカー、データベースをService Busと合わせて、一つのシステムとして設計します。監視、認証、ネットワークも、同じ設計の中に含めます。

オンプレミスの基幹システムと連携する場合は、通信経路と、障害時にどこまでを誰が受け持つかも明確にします。

注文受付から出荷までの連携例

注文画面は、注文データをデータベースへ保存したうえで、注文確定イベントをTopicへ送信します。各Subscriptionは、在庫引当、出荷指示、メールやアプリ通知を、それぞれ別々に処理します。

処理を独立させておくと、通知サービスの停止時に在庫引当まで巻き戻す必要はありません。一方で、保存と送信を別々に行うと片方だけ成功してしまうため、Outboxパターンやトランザクション境界を検討します。

ワーカー・データベース・監視の組み合わせ

受信ワーカーには、Azure Functions、Container Apps、AKSなどを使えます。少量をイベント単位で処理するならFunctions、常時稼働のコンテナや実行環境を細かく制御するならContainer AppsやAKSが候補です。

監視では、メッセージ数やキューの滞留時間、Dead-letter数を記録します。さらに、受信失敗数、処理時間、再試行回数も含め、「5分以内に請求処理」などの業務上のSLOに結び付けます。

オンプレミスとのハイブリッド連携

常時接続が難しい場合は、Service Busをクラウド上の受け渡し場所として使えます。送信側は接続できるタイミングで送り、受信側の業務システムは復旧後にメッセージを取得します。

ネットワーク障害を吸収できる一方、重複処理の防止、接続資格情報の更新、送受信元の時刻差も設計に含める必要があります。

Azure Service Busシステム開発の進め方

Namespaceの作成やSDKの呼び出しは、開発の一部です。実際には、業務イベント、メッセージ契約、失敗時の復旧、セキュリティ、運用を段階的に検証していきます。

正常系だけでPoCを終えると、本番で起きる重複や滞留を見落としやすくなります。そのため、初期段階から失敗系も試しておきます。

▶ 詳細はこちら：Azure Service Busのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

要件定義で決める項目

要件定義では、イベントごとに送信元と購読先を整理します。あわせて、通常時とピーク時の1秒あたりの件数、サイズ、最大遅延を決めておきます。さらに、保持期間、再送の可否、個人情報の有無も確認します。

処理の成功条件も、早い段階で決めておきます。データベース更新までを成功とするか、外部APIの応答までを成功とするかで、ロック時間、タイムアウト、補償処理が変わります。

仕様が曖昧なまま進めると、工数と費用が1.3〜1.5倍に膨らむ可能性があります。

PoCで確認する失敗シナリオ

PoCでは、受信側が停止している間に送信した場合と、タイムアウト後に再試行した場合の挙動を確認します。同じメッセージが二重に登録されたり、二重に請求されたりしないかも、あわせて試します。

最大配信回数を超えたメッセージがDead-letter queueへ移るか、原因を確認したあとに再処理できるかも試します。また、負荷試験ではピーク時の滞留時間と回復時間を測ります。

設計・実装・テスト・リリース

設計では、メッセージスキーマとバージョンを決めます。Correlation IDと冪等性キーも用意します。次に、再試行間隔、TTL、Dead-letterの扱いを定めます。

実装では、SDKの接続とロック更新、例外の分類を行います。ログのマスキングや、Infrastructure as Codeによる環境差分の管理も、実装の一部として扱います。

テストでは、通信遅延、権限エラー、受信側の停止を再現します。さらに、外部API障害、順序逆転、リージョン障害も試します。本番へ移行する前に、運用手順書とアラートを確認します。

ポイント

要件定義で成功条件と件数を決め、PoCで失敗系を初期段階から試せるかが、進め方の目安になります。正常系だけで終えない体制かを、発注前に見極めるとよいでしょう。

Azure Service Busシステムの費用相場

費用は、Azure利用料と人件費に分けて考えます。人件費は、要件定義から運用設計までの各工程で発生します。さらに、APIやデータベースの改修も見積もりに含めます。監視、ネットワーク、障害対応も、同じ見積もりに入れます。

次に示す金額は、日本国内の受託開発を想定した企画用の目安です。正式な見積もりではありません。

▶ 詳細はこちら：Azure Service Busのシステム開発の見積相場や費用/コスト/値段について

規模別の初期開発費と期間

規模別の目安は、連携先や運用要件によって異なります。

PoC・小規模：Queueを1本から数本使い、再試行と最低限の監視を含む構成で、100万〜300万円、1〜2か月です。
小〜中規模：複数のQueueとTopic、既存APIやDBとの連携、権限、運用画面を含み、300万〜1,000万円、3〜6か月です。
中規模：3〜10連携先、冪等性、監査ログ、負荷試験、Private Endpointを含み、700万〜1,500万円、5〜8か月です。
大規模・基幹：複数業務ドメイン、二地域復旧、データ移行、24時間運用、厳格なSLAまでを含み、1,500万〜5,000万円超です。

大規模案件の期間は8〜12か月で、場合によっては1〜2年かかります。金額は、メッセージ本数よりも連携先数と障害時の要件に強く左右されます。

Azure利用料と周辺インフラ費

全体の月額費用は、Service Bus本体、周辺インフラ、保守を分けて試算します。Azure利用料は、契約、リージョン、為替、利用量によって変わります。

Service Bus：Standard単体は月数千円〜数万円、Premiumの1 Messaging Unitは月5万〜15万円程度です。
複数ユニット・二地域：2ユニットや二地域構成は、月10万〜40万円程度が予算用の概算です。
周辺インフラ：ワーカー、DB、ログ、Private Endpoint、バックアップ込みで、小規模本番は月5万〜20万円です。
中〜大規模インフラ：月20万〜100万円超になる可能性があります。
保守：初期開発費の年15〜25％、または月5万〜50万円以上が目安です。

Azureの価格は契約形態、購入日、通貨の影響も受けるため、発注前に料金計算ツールで再計算しておきます。

保守契約では、監視やSDKの更新、脆弱性対応を範囲に入れます。障害の一次対応やリトライ設定の見直しも、範囲に加えておきます。

見積もりで確認する費用項目

見積書では、要件定義、設計、環境構築を分けて確認します。メッセージ契約、送受信の実装、既存改修、テストも、それぞれ独立した項目として見ます。さらに、監視、運用手順、教育、移行、保守が、別々の金額で示されているかも確認します。

工程配分の目安は、要件定義10〜12％、設計・環境構築22〜24％、実装48〜50％、テスト15〜17％です。比率が極端な場合は、どの作業が対象外なのかを質問します。

ポイント

費用は、連携先数と障害時の要件で大きく変わるため、規模を先に決めて比べます。Azure利用料と保守費を人件費と分けて示してもらうと、前提の差が見えやすくなります。

セキュリティ・障害対策・運用設計

記録から再処理までを段階で追えます。

認証情報を守り、重複を防ぎ、滞留を見つけて復旧できなければ、業務システムとしては不十分です。そのため、セキュリティと運用は要件定義の段階から組み込みます。

Entra ID・RBAC・Private Endpoint

可能な限りManaged IdentityとEntra IDを使い、役割ベースの最小権限を設定します。共有キーを使う場合は、保管場所やローテーション、失効手順を決めておきます。

外部公開を避ける場合は、Private Endpointを使います。仮想ネットワークや名前解決、オンプレミスとの経路も、あわせて設計します。

本文に個人情報を直接入れず、参照IDだけを持たせる方法もあります。これにより、漏えい時の影響を抑えられます。

重複・順序逆転・Dead-letterへの対応

再配信が起きる前提で、重複処理や順序、失敗メッセージの復旧方法を設計します。

受信側の記録：メッセージIDや業務キーで、同じ処理が済んでいないかを判定します。
冪等性：Exactly-onceは前提にせず、データベースの一意制約やOutbox／Inboxと組み合わせます。
順序：注文や顧客単位で順序が重要な場合にSessionsを検討します。並列度が下がる場合があるため、全件には適用しません。
Dead-letter queue：原因分析と再処理に使い、最大配信回数、TTL切れ、形式不正、外部APIの恒久エラーで分類します。
再処理：発見時間と修正後の再送条件をRunbookに記載します。再処理できない場合は、補償処理や担当者確認につなげます。

Geo-Replicationと災害復旧

災害復旧では、複製するデータと許容する遅延・損失を踏まえて方式を選びます。

Geo-Replication：Premiumで、メタデータとメッセージデータを別リージョンへ複製する方式です。
Geo-Disaster Recovery：メタデータは複製するものの、キュー内のメッセージは複製しません。
方式の選択：メッセージを失えない業務は前者、再構成できる場合は後者が候補です。
同期：保護を高められる反面、書き込み遅延が増えます。
非同期：スループットを確保しやすいものの、未複製のデータを失う可能性があります。

どちらの方式も、昇格は運用者が判断して手動で行います（出典: Azure Service Bus信頼性ドキュメント、2026年確認）。

RTO、RPO、許容停止時間は数値で決めておきます。そのうえで、監視や昇格の手順、接続先の確認、復旧後の切り戻しを訓練します。

ポイント

認証の仕組み、重複処理と再処理の手順、災害時の方式は、要件定義の段階で決めておくと後戻りが少なくなります。特にメッセージを失えない業務では、災害復旧の方式を先に選ぶことが求められます。

StandardとPremiumの選び方

低〜中スループットの開発・検証や業務連携では、Standardが候補になります。一方、高スループットや性能の予測可能性が必要な本番では、Premiumを検討します。リソース分離やGeo-Replicationが求められる本番でも、Premiumが候補になります。

最初からPremiumにするかは、ピーク件数と遅延を測って決めます。データ保護や許容停止時間も、あわせて確認すると判断しやすくなります。

Standardが向いているケース

開発・QA環境や、処理量が少ない業務、多少のスロットリングを吸収できる連携では、Standardが使いやすいです。

初期費用を抑えてPoCを始め、負荷試験で滞留や処理時間を把握してから、Premiumへ移行する方法もあります。その際は、本番前に接続数やメッセージサイズを確認します。フィルター数や保持期間の上限も、あわせて押さえます。

Premiumが向いているケース

Premiumは専用Messaging Unitを使うため、共有リソースの影響を受けにくく、性能を見積もりやすいです。

高頻度の業務メッセージや機微な処理を扱う本番では、Premiumが向いています。安定したレイテンシーや、100MBまでの大きなメッセージ、Geo-Replicationが必要な場合にも、候補になります。

ユニット数は1、2、4などの単位で課金されます。その費用は、処理量だけでなく、予測可能性と復旧要件に対するものです（出典: Azure Service Bus料金ページ、2026年確認）。

上限とスロットリングの確認

2026年2月更新のクォータ情報では、同時接続数や受信要求数に上限があります。メッセージのプロパティサイズやSubscriptionのフィルター数にも、上限があります。

AMQPの同時接続数と同時受信要求数は、いずれも5,000とされています（出典: Azure Service Busクォータと制限、2026年確認）。

SDKの接続再利用、ワーカー数、TopicとSubscription数を合わせて試算します。Standardでは、クレジット制スロットリングが起きないかを負荷試験で確かめます。

開発会社・ベンダーの選び方

依頼先は、Service Busの設定ができるかだけでなく、業務理解と既存システム連携まで設計できるかで選びます。セキュリティ、監視、障害復旧についても、同じ観点で確認します。提案の段階で、失敗系の設計を具体的に質問します。

重複処理やDead-letterの運用品質は、知名度や資格の数では見えにくい点です。

Service Busの本番経験の確認

QueueとTopicを使った業務の経験、ピーク件数と最大遅延、テストした失敗の内容を確認します。運用品質は、「Service Busを使える」という説明より、実際の経験で見極めます。

実績を開示できない場合でも、匿名化した構成図、メッセージ契約例、Dead-letter復旧手順、負荷試験の観点を示せるかで、技術力を判断できます。

納品物と運用体制の契約条項

引き継ぎ後も運用を続けられるよう、納品物と保守の責任範囲を契約で明確にしておきます。

開発成果物：ソースコード、Infrastructure as Code、メッセージスキーマ、環境変数一覧を納品対象にします。
運用資料：監視ダッシュボードやアラート条件、Runbook、テスト結果、復旧訓練記録を含みます。
保守対応：一次対応の時間帯、Dead-letter確認の期限、SDKとランタイムの更新、障害原因の報告、再委託先の管理責任を定めます。
個人情報の管理：扱う場合は、アクセス権、ログのマスキング、安全管理措置の確認が必要です。

同じ条件での提案比較

見積もりを比べるときは、連携条件や保守範囲などの前提をそろえてから比べます。

連携条件：連携先数、通常・ピークのメッセージ数、許容遅延、保持期間、再送上限、個人情報の分類をそろえます。
構成・運用：StandardかPremiumか、Private Endpoint、DR、24時間監視の有無を、同じ前提にします。
費用・引き継ぎ：対象外作業、想定利用料、保守範囲、追加変更単価、内製へ引き継げる資料を比べます。

リスクと前提条件が提案に明記されている依頼先ほど、後工程の予算差異を抑えやすくなります。

▶ 詳細はこちら：Azure Service Busのシステム開発でおすすめの開発会社/ベンダー6選と選び方

ポイント

依頼先は、重複処理やDead-letter運用の経験を具体的に示せるかで比べます。見積もりは連携条件と保守範囲をそろえてから費用を見比べると、判断しやすくなります。

発注前に整理するチェックリスト

発注前に情報をそろえておくと、見積もりと提案を比べやすくなります。未確定の項目は「未定」と明示したうえで、確認方法と追加費用を提案側に出してもらいます。

▶ 詳細はこちら：Azure Service Busのシステム開発の発注/外注/依頼/委託方法について

業務・データ・性能の整理

まず、対象業務、送信元、受信先、イベント名を整理します。あわせて、成功条件と失敗時の担当部署も書き出します。

メッセージ1件のサイズや、通常時とピーク時の件数、許容遅延を記載します。保持期間や、個人情報・機密情報の有無も書いておきます。

特に、重複が許されない注文や請求では、冪等性キーと補償処理の方針を発注書に含めます。

運用・復旧・セキュリティの整理

まず、アラートの担当者と判断までの時間を決めます。再処理の手順も、あわせて決めておきます。

RTO・RPO、対象リージョン、手動昇格の権限を確認します。Private Endpoint、ログ保存期間、監査担当も押さえます。

利用料は、Service Busだけでなく、ワーカー、データベース、監視、ネットワーク、バックアップを含めた月額で試算します。

納品・引き継ぎ・将来変更の整理

引き継ぎでは、受け取る資料の範囲を決めておきます。ソースコード、IaC、メッセージスキーマ、テスト仕様書、監視設定が、受領の対象です。Runbook、障害履歴、教育資料についても、範囲を明確にします。

将来、購読先を追加する場合や、別の基盤へ移す可能性も、引き継ぎの際に確認しておきます。特定の担当者に運用が集中しないよう、引き継ぎ期間と操作権限を初期契約に含めます。

Azure Service Busのよくある質問

導入前によく寄せられる疑問に、最後にまとめて答えます。Service Busを採用するかどうかは、処理遅延、再送、整合性、運用責任を許容できるかで判断します。

Azure Service Busはすべての業務システムに必要ですか？

業務システムごとに、Service Busが必要かどうかは変わります。単純な処理で同期応答が必要で、障害時の再送も不要なら、通常のAPI連携のほうが理解しやすいです。

複数処理系の疎結合やピーク負荷の平準化、受信側停止中のメッセージ保持が必要なら、発注側はService Busを検討します。

Service Busなら二重処理は起きませんか？

二重処理が起きる可能性は残ります。受信側の障害やタイムアウトによって、同じメッセージが再配信されることがあるためです。

そのため、メッセージIDや業務キーによる冪等性、一意制約、処理済みの記録、補償処理を組み合わせます。二度届いても結果が一度になるよう、設計しておく必要があります。

小規模なAzure Service Busシステムはいくらですか？

Queueを1〜数本使うPoCの場合、初期開発費は100万〜300万円、期間は1〜2か月が目安です。

複数のAPIやデータベース、監視、再処理、セキュリティを含む実運用なら、300万〜1,000万円程度から検討します。Azure利用料と保守費は、別に見積もります。

連携先数、ピーク件数、DR、24時間対応の有無によって変わるため、金額だけでなく前提条件も合わせて比べます。

オンプレミスのシステムとも連携できますか？

はい、連携できます。クラウド上のQueueやTopicを受け渡し場所にし、オンプレミスの送受信プログラムは必要なときに接続する構成が候補になります。

事前に確認するのは、ファイアウォールや名前解決、接続資格情報です。ネットワーク停止時の再送や、基幹側の重複処理も、あわせて確認します。

最初からPremiumを選ぶべきですか？

高スループットや安定したレイテンシーが必要な場合は、最初からPremiumを検討します。リソース分離や、メッセージデータを含むGeo-Replicationが必要な場合も、Premiumが候補になります。

開発・検証や低〜中負荷の本番で、負荷試験によりStandardの性能を確認できるなら、Standardから始める方法もあります。移行の条件は、メッセージサイズ、ピーク件数、滞留時間などで決めます。

まとめ

Azure Service Busは、業務アプリ同士のメッセージを保管し、処理を非同期化する基盤です。Queueは一つの処理系へ届ける用途、TopicとSubscriptionは複数の処理系への配信に向いています。

Event GridやEvent Hubsとは、通知、ストリーム、業務メッセージのどれを扱うかで使い分けます。

採用判断の観点

採用の判断では、連携先数、ピーク数、最大遅延、保持期間を数値にして比べます。重複処理やDead-letter復旧、セキュリティ、RTO・RPOについても、数値で示せるかを確かめます。

StandardとPremiumは、料金だけでなく、性能の予測可能性やリソース分離、リージョン障害への備えで比べます。費用は、初期開発費、Azure利用料、周辺インフラ費、保守費に分けて考えます。

次に作る資料

まず、業務イベントの一覧を作ります。そのうえで、送信元、購読先、ピーク件数、許容遅延、再送可否、データ分類をまとめた要件シートを作ります。

この資料をもとに、PoCで停止、遅延、重複、Dead-letter、復旧を確かめ、運用体制と費用を見積もります。さらに、実装前に失敗時の責任者と復旧時間を決めておくと、業務への定着につながります。

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
 ・スクラッチシステム開発の完全ガイドブック
 ・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。