従業員数千人規模で、基幹システムと取引先・外部サービスとの連携をBizTalk Server 2020で長年運用してきた製造業や金融機関の情報システム部門は少なくない。日々の運用では、その連携基盤がAzure Service Busとの通信にSBMP（Service Bus Messaging Protocol）という古いプロトコルを使っていることを、担当者はほとんど意識してこなかったはずだ。
Microsoftは2026年9月30日、Azure Service Busのレガシープロトコルであり、旧SDK 3種（WindowsAzure.ServiceBus、Microsoft.Azure.ServiceBus、com.microsoft.azure.servicebus）のサポート終了と合わせて、SBMPのサポートを終了する[1]。ここで技術的に使えなくなるのはSBMPプロトコルだけで、ライブラリ自体は期限後も動作する。WindowsAzure.ServiceBusはAMQPであれば引き続き利用でき、残る2つも「使い続けられるが、サポートと更新の対象外になる」とMicrosoftは明記している[1]。BizTalk Server 2020のSB-Messagingアダプタ（Service Busへの接続を担う標準機能）はこのSBMPに依存しているため、対応を怠ると本番の連携メッセージングが期限日を境に動かなくなる。
期限まで1ヶ月を切った今、必要なのは「今も動いているから大丈夫」という判断の見直しである。本稿では、何が廃止されるのか、BizTalk環境での実務的な対応、そして日本企業特有の保守契約・稟議プロセスを踏まえた優先順位の付け方を整理する。
予備知識
- SBMP（Service Bus Messaging Protocol）: Azure Service Busが提供してきた独自の通信プロトコル。.NET Framework時代の古いSDKが内部で使用する。
- AMQP（Advanced Message Queuing Protocol）: メッセージング分野の標準プロトコル。現行のAzure Service Bus SDKはこちらを標準採用している。
- BizTalk Server: Microsoftのオンプレミス型統合基盤（EAI/ESB）。社内外システム間のメッセージ連携やデータ変換を担う。
- SB-Messagingアダプタ: BizTalk ServerからAzure Service Busへ接続するための標準アダプタ。
プロトコルやSDKが変わっても腐らない、メッセージング統合の設計原則を体系的に学べる古典。
何が終わるのか：SBMPと3つの旧SDK
Microsoftが2026年9月30日に区切りを置くのは、SBMPプロトコルのサポートと、3つの旧SDKライブラリのサポートである。具体的には.NET向けのWindowsAzure.ServiceBus、.NET向けのMicrosoft.Azure.ServiceBus、Java向けのcom.microsoft.azure.servicebusで、いずれも現行のAzure SDKガイドラインに準拠していない旧世代のライブラリだ[1]。
重要なのは、この2つが同じ「廃止」ではない点だ。サービス側で受け付けられなくなるのはSBMPプロトコルのみで、Microsoft.Azure.ServiceBusとcom.microsoft.azure.servicebusは期限後も動作し続ける（サポートと更新が止まるだけで、ソースコードはGitHubで公開されており自前で修正を当てることもできる）。WindowsAzure.ServiceBusもAMQPを使う限り動き続ける[1]。つまり本当の期限リスクは「SBMPを使っている経路」に限定され、そこを特定できれば作業範囲は大きく絞れる。
あわせて見落としやすいのが、Service Busを使っていない場合の影響だ。Azure Event Hubsはかつてこのライブラリを使っていたため、Event Hubsで WindowsAzure.ServiceBus を参照しているなら、Service Busと無関係でもライブラリの移行が必要になる[1]。
影響が大きいのは、これらのSDKをアプリケーションコードで直接参照しているケースと、BizTalk Server 2020のSB-MessagingアダプタのようにSBMPを内部で使用する製品を利用しているケースの両方だ。特にBizTalkは、更新されずに長期間稼働し続けるシステムの代表格であり、開発担当者が異動・退職した後もアダプタの内部実装まで把握している人材が社内にいないことが珍しくない。
BizTalkのような長期稼働システムに手を入れる際、壊さずに変更する具体的な手順を学べる一冊。
解決の方向性：BizTalk向けホットフィックスとAMQP移行
Microsoftは、BizTalk Server 2020のSB-MessagingアダプタにAMQP対応を追加するホットフィックスを提供している[2]。これを適用すれば、アダプタはAMQP経由でAzure Service Busへ接続できるようになり、SBMP廃止後も連携を継続できる。適用後はAMQPが既定のトランスポートになる[2]。
実務上の律速はここにある。このホットフィックスはダウンロードセンターに置かれておらず、サポートケースを起票してKB5091379を要求するか、Microsoftのアカウントチームに連絡して入手する。対象はBizTalk Server 2020のCU6とCU7に限られ、Microsoftは「9月を十分に前倒しして適用し、非本番環境で検証すること」を求めている[2]。CU5以前を使っている場合は、まずCUの適用から数える必要がある。
独自にSDKを参照しているアプリケーションについては、SBMPを使っているなら現行のAzure Service Bus SDK（Azure.Messaging.ServiceBus）への書き換え、またはAMQPへの切り替えが必要になる[1]。
移行の実務は大きく3段階に分かれる。まず、社内のどのシステムがSBMPまたは旧SDKに依存しているかを棚卸しする。次に、BizTalkであればサポートケースでホットフィックス（KB5091379）を入手し、検証環境に適用してAMQP経由での接続を確認する。最後に、本番環境へ適用し、SBMP経由の通信が実際に発生していないことをログで確認する[2]。
| 依存先 | 対応内容 | 想定作業ボリューム |
|---|---|---|
| BizTalk Server 2020のSB-Messagingアダプタ | 修正プログラム適用＋AMQP接続の検証 | 中（検証環境でのテストが必要） |
| 独自アプリの旧SDK直接参照 | 現行SDKへのコード書き換え・再デプロイ | 大（コード変更とリグレッションテスト） |
| Azure WCF Relay | 対応不要（Microsoftは同ライブラリのWCF Relayとの組み合わせについて「追って通知があるまでサポートを継続する」と明記）[1] | なし |
| Event Hubsでの WindowsAzure.ServiceBus 参照 | Azure.Messaging.EventHubs への移行 | 中（Service Bus未使用でも対象になる）[1] |
数百のWebアプリをAzure App Serviceで運用し、年次のセキュリティ監査を受ける企業のプラットフォーム担当者は、2026年後半に複数のランタイムが立て続けにサポート終了を迎える事態に向き合うことになる。対象はAzure Ap[…]
具体施策：残り1ヶ月の点検チェックリスト
期限まで日数が限られる中、優先すべきは「まだ気づいていないSBMP依存」の発見だ。BizTalk以外にも、古いバッチ処理やレガシーな.NET Framework 4.x系アプリケーションが、意識されないままWindowsAzure.ServiceBus SDKを参照しているケースがある。ネットワーク監視やAzure側の接続ログを確認し、SBMPプロトコルでの接続が実際に発生しているかを特定するのが確実な出発点になる。
残り期間で最低限つぶすべき項目は次の5つになる。
- コードベースを
WindowsAzure.ServiceBus/Microsoft.Azure.ServiceBus/com.microsoft.azure.servicebusの3語で全文検索し、参照箇所を洗い出す[1] - Event Hubs 側で
WindowsAzure.ServiceBusを参照していないか確認する（Service Bus未使用でも移行対象になる）[1] - BizTalk Server 2020のCUレベルを確認する（ホットフィックスの対象はCU6・CU7のみ）[2]
- サポートケースを起票してKB5091379を要求する（入手経路がこれしかないため、ここが最も日数を食う）[2]
- 非本番環境でホットフィックスを適用し、AMQPが既定トランスポートになった状態で連携を通しで検証する[2]
Microsoft Entra ID（旧Azure AD）の動的メンバーシップグループで部署や役職ごとにTeamsとSharePointの権限を配り、年1回の内部監査でアクセス権の棚卸し証跡を求められている。数千人規模の企業でID基盤を預[…]
SIerの保守契約と稟議サイクルが移行を遅らせる構造
海外のクラウドネイティブな組織であれば、AMQPへの移行はアプリケーションチームが数日で完結させられる作業に近い。しかし日本企業の多くは、BizTalkを含むオンプレミス統合基盤の保守をSIerに委託しており、SB-Messagingアダプタへの修正プログラム適用も、契約範囲内の「軽微な変更」か「追加の作業依頼」かによって、対応スピードが大きく変わる。追加の作業依頼と判断されれば、見積もり取得から稟議承認までに数週間を要することも珍しくない。
内部統制の観点でも違いがある。海外では緊急性の高い変更を「まず適用し、事後に記録する」運用が許容されやすいが、日本企業では変更管理プロセス上、事前の承認記録がなければ本番適用自体ができない場合がある。監査対応を考えると、今回のような期限付き廃止案件は、通常の変更管理フローとは別に「緊急対応」の位置づけで扱えるかどうかが鍵になる。
| 観点 | 海外の典型的な動き | 日本企業で起きやすいこと |
|---|---|---|
| 対応の起点 | アプリケーションチームが即座に着手 | SIerへの作業依頼と見積もり取得が先に必要 |
| 承認プロセス | 緊急変更として事後報告も許容 | 変更管理プロセス上、事前承認が必須なことが多い |
| 依存箇所の把握 | コードベースの静的解析で機械的に検出 | 属人化した知識に依存し、棚卸しに時間がかかる |
IT部門担当者の次の一手は、SBMP・旧SDK依存の棚卸しをまず自社で始め、SIerへの作業依頼を並行して出すことだ。決裁側の判断材料は、9月30日という動かせない期限を踏まえ、通常の稟議サイクルを待たずに緊急対応枠で予算を確保できるかどうかになる。
まとめ
Azure Service BusのSBMPサポート終了は、2026年9月30日という動かせない期限を持つ[1]。止まるのはSBMP経路に限られるが、BizTalk Server 2020のSB-Messagingアダプタはまさにそこに乗っている。ホットフィックスはサポートケース経由でしか入手できず（KB5091379、対象はCU6・CU7）、その起票から検証までを逆算すると残り時間は見た目より短い[2]。IT部門担当者の次の一手は、依存箇所の棚卸しと検証環境でのテストだ。決裁側にとっての判断材料は、通常の稟議サイクルではなく緊急対応枠でこの移行を予算化できるかという点になる。連携基盤が突然止まってから対応するのでは遅い。
よくある質問（FAQ）
Q. うちはBizTalkを使っていないが、影響はあるか？
A. これら3つのSDKを参照していても、期限で止まるのはSBMPを使っている経路だけだ[1]。ただしサポートと更新は打ち切られるため、移行計画自体は必要になる。またAzure Event Hubsで WindowsAzure.ServiceBus を参照している場合は、Service Busを使っていなくてもライブラリの移行が要る[1]。まず社内のコードベースでこれらのSDK名を検索することが出発点になる。
Q. SBMPが廃止されると具体的に何が起きるか？
A. 2026年9月30日以降、SBMPプロトコルでの接続がAzure Service Bus側で受け付けられなくなる[1]。SBMPを使っているシステムは接続エラーとなり、メッセージの送受信ができなくなる。一方、同じライブラリでもAMQPで接続していれば期限後も通信自体は継続する[1]。
Q. 移行にはどれくらいの期間が必要か？
A. BizTalkの修正プログラム適用だけであれば検証込みで数週間程度が目安だが、独自SDKを参照するアプリケーションのコード書き換えは規模次第で数ヶ月かかる場合もある。残り期間を踏まえ、優先順位付けが重要になる。
出典
[1] https://techcommunity.microsoft.com/blog/messagingonazureblog/some-azure-service-bus-sdk-libraries-will-be-retired-on-30-september-2026%e2%80%94migrat/3917853[2] https://techcommunity.microsoft.com/blog/integrationsonazureblog/service-bus-sbmp-retirement-what-biztalk-server-2020-customers-need-to-know/4513155
