合同会社小村ソフト
相談する
メニュー

MSMQはいつまで使えるのか ── 「非推奨ですらない」レガシーキューの移行判断

· · Windows, .NET, C#, MSMQ, メッセージキュー, レガシー技術, 移行, 情報システム

「このシステム、MSMQを使っているんですが、廃止されたって聞きました。すぐ移行しないとまずいですか」──レガシー移行の相談で、ここ1年ほど繰り返し聞かれる質問です。

答えは少しねじれています。MSMQ(Microsoft Message Queuing)は、廃止どころか公式には非推奨にすらなっていません。2026年7月時点で、マイクロソフトの非推奨機能一覧にMSMQの名前はなく、現行のWindowsにもオプション機能として同梱されています。それなのに現場の感覚として「終わった技術」なのは、.NET側の公式なマネージドAPIが閉じているからです。MSMQを扱う標準ライブラリSystem.Messagingは.NET Frameworkにしか存在せず、.NET(Core以降)には移植されませんでした。

つまりMSMQは「明日止まる」技術ではなく、「アプリを.NETへ上げようとした瞬間に壁になる」技術です。この記事では、噂と事実を切り分けたうえで、使い続ける・移行するの判断と、移行先の選び方を整理します。VB6や.NET Frameworkからの移行そのものは「VB6から.NETへの移行実務」「.NET Framework→.NET移行前チェックリスト」で扱っているので、本記事はキューの部分に絞ります。

1. まず結論

  • MSMQは公式には非推奨になっていません。Windowsクライアントの非推奨機能一覧にも、Windows Serverの削除・開発終了機能一覧にも載っていません(2026年7月時点)。12
  • しかし.NETの公式なマネージドAPIはありません。System.Messagingが対象とするのは.NET Framework 1.1〜4.8.1のみで、3 .NET移行時の互換手段であるWindows互換パックにも含まれていません。4 ネイティブWin32 APIをP/Invokeで呼ぶ道は残っていますが、延命手段の位置づけです(3章)。
  • CoreWCFによる移植はありますが、対象はキュー経由のWCFサービス(受け側)の移行に限られ、条件を確認して使う経路です。CoreWCF自体にはマイクロソフトのサポートポリシーがある一方、MSMQトランスポート(CoreWCF.MSMQ)の実装は.NET Framework版System.Messagingのコミュニティ移植に依存しています。5
  • 判断の軸は「アプリを.NETへ上げるかどうか」です。上げるなら、キューも一緒に移行するのが原則です(P/InvokeやCoreWCFで延命する道もありますが、保守負担を引き受ける判断になります)。上げない(塩漬け)なら、.NET Framework 4.8がOSコンポーネントとしてサポートされる間は動かし続ける計画が立てられます。6
  • 移行先の第一候補は、メッセージブローカーではなくデータベースのテーブルキューです。MSMQ+分散トランザクション(DTC)で守っていた整合性は、業務DBと同一トランザクションで処理できるテーブルキューのほうが素直に置き換えられます(5章)。
  • メッセージ形式の棚卸しを最初にやってください。BinaryFormatter系の直列化は.NET 9で実行時から削除されており、7 古いフォーマットのまま新旧併存させると詰まります(6章)。

2. MSMQを30秒で

MSMQはWindowsに同梱されてきたメッセージキュー基盤です。アプリケーションはキューにメッセージを書き、別のアプリケーション(同じマシンでも別のマシンでも)が都合のよいタイミングで取り出します。特徴は次の3点に集約されます。

  • store-and-forward: 送信先が落ちていてもメッセージはローカルに蓄積され、回復後に届く。拠点間の不安定な回線に強い。ただしこの永続性は無条件ではなく、既定の高速(express)メッセージはメモリ上に留まり得て、MSMQサービスやマシンの再起動で失われます。ディスクに永続化されるのは、送信側でRecoverable(回復可能)を指定したメッセージか、トランザクションメッセージです。
  • トランザクション: キュー操作をトランザクションにでき、MS DTC(分散トランザクションコーディネーター)と組み合わせると「キューからの取り出し」と「データベース更新」を1つの分散トランザクションで確定できる。
  • OS同梱: 追加のミドルウェア導入なしで使えたため、2000年代の業務システム、とくに受発注データの連携、帳票の非同期処理、製造現場の工程間連携などで広く採用された。

この「OS同梱で、トランザクションが効いて、オフラインに強い」という組み合わせが優秀だったからこそ、いまも現役で残っています。移行先を考えるときも、この3点のどれを実際に使っているかが判断の中心になります。

3. 事実関係 ── 「廃止された」は正確ではない

順番に確認します。

第一に、MSMQは非推奨リストに載っていません。Windowsクライアントの「Deprecated features」一覧を見ると、NTLMやVBScript、WordPadは載っていますが、MSMQの項目はありません。1 Windows Server側の「Features Removed or No Longer Developed」一覧でも、Windows Server 2025のタブを含めてMSMQは挙げられていません。2 非推奨(deprecated)は「積極的な開発をやめた」という公式宣言であり、その宣言すら出ていない、というのが現在地です。

第二に、System.Messagingは.NET Frameworkで止まっています。リファレンスの対象バージョンは.NET Framework 1.1から4.8.1までで、.NET(Core以降)の版は存在しません。3 .NET Framework専用APIの受け皿であるWindows互換パック(Microsoft.Windows.Compatibility)は、レジストリ・WMI・Windowsサービス・EventLogなど約2万のAPIを提供しますが、その技術領域一覧にメッセージング(System.Messaging)は含まれていません。4 正確に言えば、閉じているのはマネージドAPIです。MSMQのWin32ネイティブAPI(MQSendMessage、MQReceiveMessage など)は現在も文書化されており、.NETからP/Invokeで呼ぶこと自体は可能です。ただしSystem.Messagingが吸収していたフォーマッターやトランザクション連携を自前のラッパーとして書き、保守し続けることになるため、「使い続けるための本命」ではなく「どうしても残す場合の延命手段」の位置づけです。

第三に、WCFのMSMQ連携も同じ壁の中にあります。.NET FrameworkのWCFにはMSMQを下回りに使うバインディングがありましたが、この経路をモダンな.NETで再現しようとすると、コミュニティ主導のCoreWCFに行き着きます。CoreWCFはキュー系トランスポートの一環としてMSMQ対応パッケージ(CoreWCF.MSMQ)を公開していますが、その実装は.NET Framework版System.Messagingライブラリのコミュニティ移植への依存を明示しています。5 動くかどうかで言えば動きますし、CoreWCF自体にはマイクロソフトの公式なサポートポリシーが用意されているので、「完全に野良のライブラリ」というわけでもありません。5 ただし、MSMQトランスポートが依存するSystem.Messagingのコミュニティ移植までが同じ扱いかは別の問題です。採用するなら、使うバージョンがサポートポリシーの対象かと、この依存部分の扱いを確認したうえで判断してください。

まとめると、こうなります。

観点 状態
OS機能としてのMSMQ 存続。オプション機能として現行OSに同梱。非推奨宣言なし12
.NET FrameworkのSystem.Messaging 利用可能。ただし.NET Framework 4.8.1まで3
.NET(Core以降)の公式マネージドAPI 存在しない。互換パックにも含まれない(ネイティブWin32 APIをP/Invokeで呼ぶ道はある)4
コミュニティ移植(CoreWCF.MSMQ等) 存在するが、System.Messagingのコミュニティ移植に依存5
新規採用 推奨できない(公式な将来の道がないため)

4. 「動いているのに問題」の正体

MSMQが絡むシステムの相談は、たいてい障害ではなく移行の見積もりから始まります。問題の正体は、MSMQそれ自体ではなく、MSMQがアプリ全体を.NET Frameworkに縛る錨(いかり)になることです。

.NET Framework 4.8はWindowsのコンポーネントとして扱われ、インストールされているOSのライフサイクルに沿ってサポートされます。6 だから「動き続けるか」という問いには「当面は動き続ける」と答えられます。それでも次の項目は、時間とともに確実に重くなります。

  • 人が採れない・引き継げない。System.MessagingとDTCを説明できる技術者は年々減っています。「ソースも資料もないシステムの保守」で書いた構図の典型例です。
  • ランタイムと新しいライブラリの恩恵が受けられない。新しいC#の構文にはコンパイラの更新だけで.NET Frameworkでも使えるものが多くありますが、ランタイム側の性能改善や新しい標準ライブラリは使えず、.NET Frameworkをサポート対象から外していく最近のパッケージも選べなくなっていきます。
  • 分散トランザクションが移行の最難関になる。MSMQ+DTCの「キュー取り出しとDB更新をアトミックに」という設計は、クラウド系のキューサービスでは再現できません。ここを放置したまま周辺だけ.NET化すると、最後にいちばん硬い芯が残ります。
  • 直列化形式の時限爆弾。古いシステムのメッセージ本文はバイナリ直列化になっていることがあり、BinaryFormatterは.NET 9で実行時から削除されました。7 移行時にメッセージ形式ごと見直す必要があります。

つまり「MSMQはいつまで使えるか」という問いの実務的な答えは、「OSがサポートする限り動くが、移行の難易度は待つほど上がる」です。判断を先送りするにしても、次章の判断表で「どこが難所か」だけは先に把握しておくべきです。

5. 移行先の判断表

移行先は「MSMQの後継製品はどれか」ではなく、実際に使っている性質ごとに選びます。

5.1. まず要件を4つの質問に落とす

  1. キューの相手(受け側の処理)は、自社のデータベースを更新する処理か？
  2. 分散トランザクション(DTC)を使っているか？(トランザクションキュー+DB更新)
  3. 送信側と受信側は別マシン・別拠点か？オフライン耐性(store-and-forward)は本当に使っているか？
  4. メッセージ量は実際どの程度か?(多くの業務システムでは1日数千〜数万件で、これはどの選択肢でも余裕です)

5.2. 判断表

使っている性質 第一候補 理由と注意
同一システム内の非同期処理(受け側はDB更新) DBのテーブルキュー 「メッセージ取り出し」と「業務データ更新」を同一ローカルトランザクションで確定でき、DTCが不要になる。既存のバックアップ・監視・運用がそのまま使える。なお送信側でも「業務データ更新とメッセージ行の追加」を同一トランザクションにでき、こちらはいわゆるOutboxパターン
DTCでキューとDB更新をアトミックにしている DBのテーブルキュー 分散トランザクションをローカルトランザクションに置き換えるのが移行の本質。クラウド系キューはDTCに参加できないため、この要件がある限りブローカー系は遠回りになる
複数システム・複数言語間の疎結合な連携 RabbitMQ(オンプレ) / Azure Service Bus(クラウド可) 配信のファンアウトやルーティングはブローカーの得意分野。RabbitMQは自前運用の負荷(冗長化・更新)を見積もること
拠点間のオフライン耐性(store-and-forward) Azure Service Bus等+再送設計、または拠点側テーブルキュー+同期 MSMQの「送信側ローカルに貯めて後で届く」を透過的に代替する仕組みは少ない。送信側で貯める責務をアプリ側に明示的に持たせる設計に変える
同一プロセス内の生産者/消費者 .NETのChannels等のインメモリキュー そもそもプロセス間キューが不要だったケース。プロセス内で完結させ、永続性が要るならテーブルキューへ
Windowsサービス間のプロセス間通信としてだけ使っている 名前付きパイプ等のIPC ただし置き換えられるのは両者が常に同時に動いている場合だけ。受け側の停止中もMSMQは(expressメッセージでも)送信を受け付けて後で届けるが、パイプは即座に失敗する。停止中の蓄積に頼っているなら、再送・バッファをアプリ側に実装するかキューを残す。選び方は「WindowsのIPC判断表」へ

強調したいのは、中小規模の業務システムではテーブルキューが第一候補になることが多いという点です。メッセージキュー製品の比較記事は「RabbitMQ vs Kafka vs Service Bus」という形になりがちですが、MSMQ世代のシステムがキューに載せているのは多くの場合「同じDBを更新する非同期ジョブ」であり、それはDBのテーブルとポーリング(または通知)で十分に、しかもより単純に実現できます。新しいミドルウェアをひとつ増やすことの運用コスト(監視・冗長化・パッチ・担当者教育)は、中小の体制では特に重くつきます。

6. 移行の実務手順

進め方は、レガシー移行の定石どおり「観測してから動かす」です。

  1. 依存の棚卸し。コードから System.Messaging の参照と MessageQueue の生成箇所を洗い出します。あわせて、WCF構成ファイルの netMsmqBinding / msmqIntegrationBinding、ネイティブAPI(MQSendMessage などの MQ* 関数)やCOM経由の呼び出しも検索してください。System.Messagingを参照していなくてもMSMQに依存している経路はあり得ます。確認する観点は、(a) キューのパス(ローカルかリモートか、プライベートかパブリックか)、(b) トランザクションキューか、メッセージをRecoverableにしているか(どちらでもなければ現行システムは再起動でメッセージが失われる前提で動いている)、(c) フォーマッター(XmlMessageFormatter / BinaryMessageFormatter / ActiveXMessageFormatter)、(d) ジャーナル・配信不能キューの使用、(e) 誰が作成・削除しているか(インストーラーかアプリか)、です。
  2. メッセージ形式を決める。移行後の形式はJSONを既定にします。持ち込んではいけないのは、BinaryMessageFormatterのようなBinaryFormatter系の直列化です。BinaryFormatterは.NET 9で削除済みで、セキュリティ上も推奨されません。7 一方、Protocol BuffersやMessagePackのように仕様が独立して保守されているバイナリ形式を使っているなら、その形式を新システムへそのまま運ぶこと自体は問題ありません。
  3. 受け側から移行する。新しいキュー(たとえばテーブルキュー)を先に用意し、受け側の処理を新キュー対応にしてから、送信側を切り替えます。移行期間中は、旧MSMQから新キューへメッセージを移す小さなブリッジ(これは.NET Frameworkのままでよい)を挟むと、送信側を一斉に切り替えずに済みます。ただしブリッジは「MSMQからの取り出し」と「新キューへの書き込み」の間で落ちると、メッセージを失うか二重に流します。移行元がトランザクションキューなら、MSMQ側をトランザクション受信にして書き込み失敗時に戻せるようにし、新キュー側はメッセージIDで重複を弾ける(冪等な)設計にするのが最低条件です。移行元が非トランザクションキューの場合はこの手が使えません。キューのトランザクション属性は作成時に決まり、後から変えられないためです。その場合は「Peekで読む→新キューへ冪等に書く→書けたことを確認してから取り除く」の順で組みます(取り除く前に落ちても、重複は新キュー側の冪等性が吸収します)。どちらの作り込みも規模に見合わないなら、ブリッジを挟まずに手順5の「空にして切り替え」へ寄せるほうが安全です。
  4. 挙動を固定してから書き換える。キュー処理はタイミング依存のバグが出やすい領域です。移行前に「この入力メッセージならこの結果」という特性テストを用意しておくと、置き換え後の検証が機械的になります(「特性テストで挙動を固定してからリファクタリングする」)。
  5. キューの中身が空の状態で切り替える。メッセージが残った状態での切り替えは、二重処理・欠落の温床です。計画停止でキューを吐き切ってから切り替えるのが、結局いちばん安全で速い方法です。

7. 塩漬けを選ぶ場合の最低条件

「アプリを.NETへ上げる計画がなく、費用対効果からも当面移行しない」という判断は、条件付きで合理的です。その場合の最低条件を挙げます。

  • キッティング・リストア手順にMSMQを明記する。MSMQはオプション機能なので、PCやサーバーの入れ替え時に有効化を忘れると動きません。「Windowsの機能の有効化」またはDISM/PowerShellでの有効化手順を、環境構築手順書に書いておきます。
  • キュー長を監視する。受け側が止まってもエラーにならず溜まり続けるのがキューの性質です。キューの滞留件数の監視と通知は最低限仕込んでください。
  • 構成をドキュメント化する。キューのパス、権限、トランザクションの有無、フォーマッター、ジャーナル設定。これだけで、将来の移行見積もりの精度が大きく変わります。
  • 年1回、判断を見直す。「非推奨リストに載ったか」「OSの更新で挙動が変わっていないか」を年次で確認します。非推奨の告知が出てから動き始めても、この準備があれば慌てずに済みます。

8. まとめ

  • MSMQは2026年7月時点で公式に非推奨になっておらず、OS機能としては存続しています。「廃止済み」という認識は正確ではありません。12
  • 一方でSystem.Messagingは.NET Framework専用のまま止まり、互換パックにも含まれず、.NET(Core以降)への公式な道はありません。CoreWCF自体にはサポートポリシーがあるものの、そのMSMQトランスポートはSystem.Messagingのコミュニティ移植に依存します。345
  • 判断の軸は「アプリを.NETへ上げるか」です。上げるならキューも一緒に移行するのが原則(P/Invoke等での延命は保守負担との交換)、塩漬けなら監視とドキュメントを条件に成立します。6
  • 移行先の第一候補はDBのテーブルキューです。MSMQ+DTCの整合性はローカルトランザクションで置き換えるのが本質で、ブローカー製品の導入はその後に検討します。
  • BinaryFormatter系の直列化は.NET 9での削除により新システムへ持ち込めません。移行時はJSONを既定にしつつ、protobuf等の独立して保守されている形式ならそのままでも構いません。7
  • 受け側→ブリッジ→送信側の順で切り替え、特性テストで挙動を固定してから書き換えるのが、事故らない進め方です。

関連記事

関連する相談領域

合同会社小村ソフトでは、MSMQを含むレガシー構成の棚卸しと移行計画、.NET Frameworkから.NETへの移行、キュー処理を含む業務システムの改修を扱っています。

参考リンク

  1. Microsoft Learn, Deprecated features in the Windows client. Windowsクライアントで積極的な開発が終了した(非推奨の)機能の公式一覧。2026年7月時点の一覧にNTLM、VBScript、WordPad等は掲載されている一方、MSMQ(Microsoft Message Queuing)は掲載されていないこと、および非推奨(deprecated)が「積極的に開発されておらず将来の更新で削除される可能性がある」段階であり削除(removed)とは区別されることについて。 ↩ ↩2 ↩3 ↩4

  2. Microsoft Learn, Features Removed or No Longer Developed in Windows Server. Windows Serverで削除された機能と開発終了(非推奨)機能の公式一覧。Windows Server 2025のタブを含む2026年7月時点の一覧にMSMQが掲載されていないこと、非推奨のコンポーネントもWindows Serverに同梱され続け、製品ライフサイクルに従って本番環境向けにサポートされ、セキュリティ更新と品質更新を受け続けることについて。 ↩ ↩2 ↩3 ↩4

  3. Microsoft Learn, MessageQueue Class (System.Messaging). System.Messaging.MessageQueueクラスのリファレンスが対象とするバージョンが.NET Framework 1.1から4.8.1までであり、.NET(Core以降)向けの版が存在しないことについて。 ↩ ↩2 ↩3 ↩4

  4. Microsoft Learn, Use the Windows Compatibility Pack to port code to .NET. Windows互換パック(Microsoft.Windows.Compatibilityパッケージ)が.NET Framework専用APIへの依存を.NET移行時に補うために約2万のAPIを提供すること、その技術領域一覧(CodeDom、構成、Directory Services、Drawing、ODBC、ACL、WCF、レジストリ、WMI、パフォーマンスカウンター、Windowsサービス、EventLog等)にメッセージング(System.Messaging)が含まれていないことについて。 ↩ ↩2 ↩3 ↩4

  5. CoreWCF project, CoreWCF.MSMQ (NuGet) および CoreWCF 1.4.0 Preview release、Microsoft, CoreWCF Support Policy. CoreWCFがWCFのサーバー側を.NETに移植するコミュニティ主導プロジェクトであり、マイクロソフトが公式なサポートポリシーを提供していること、キュー系トランスポートの一環としてMSMQ対応(CoreWCF.MSMQパッケージ)が公開されていること、そのMSMQ実装が.NET Framework版System.Messagingライブラリのコミュニティ移植に依存していることについて。 ↩ ↩2 ↩3 ↩4 ↩5

  6. Microsoft Learn, .NET Framework official support policy. .NET Framework 4.8がWindowsオペレーティングシステムのコンポーネントとして定義され、インストールされている親製品(OS)のライフサイクルポリシーに従ってサポートされることについて。 ↩ ↩2 ↩3

  7. Microsoft Learn, BinaryFormatter migration guide. BinaryFormatterがセキュリティ上の理由から段階的に廃止され、.NET 9以降はランタイムから実装が削除されて既定では使用できないこと、および移行先としてJSON(System.Text.Json)等の安全な直列化形式が案内されていることについて。 ↩ ↩2 ↩3 ↩4

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

MSMQは廃止されたのですか？
いいえ。2026年7月時点で、Windowsクライアントの非推奨機能一覧にも、Windows Serverの「削除された機能・開発終了機能」一覧にも、MSMQは載っていません。Windowsのオプション機能として現行OSにも同梱されています。「廃止された」という言い方が広まっているのは、.NET側の状況と混同されているためです。MSMQを扱う標準クラスライブラリSystem.Messagingは.NET Frameworkにしか存在せず、.NET(Core以降)には移植されませんでした。つまり正確には「OS機能としては存続しているが、モダンな.NETからの公式な利用手段がない」という状態です。
.NET 8や.NET 10からMSMQを使う方法はありませんか？
公式のマネージドAPIはありません。System.Messagingは.NET Framework 4.8.1までのAPIで、Windows互換パック(Microsoft.Windows.Compatibility)にも含まれていません。MSMQのネイティブWin32 API(MQSendMessageなど)をP/Invokeで呼ぶことは技術的には可能ですが、フォーマッターやトランザクション連携を含むラッパーの自作と保守を引き受けることになります。コミュニティ側では、CoreWCFプロジェクトがMSMQトランスポート用のパッケージ(CoreWCF.MSMQ)を公開していますが、これはキュー経由で呼び出されるWCFサービスをモダンな.NETでホストするためのもの(WCFのサーバー側の移植)であり、System.Messagingの代わりになる汎用のキューAPIでも、送信側クライアントの代替でもありません。実装も.NET Framework版System.Messagingのコミュニティ移植に依存しています。検証や暫定的な延命の選択肢にはなります。CoreWCF自体にはマイクロソフトの公式なサポートポリシーがありますが、このMSMQ実装が依存するSystem.Messagingのコミュニティ移植まで同じ保証があるわけではないため、業務システムの前提に据えるなら、使うバージョンがサポートポリシーの対象かと、依存部分の扱いを確認したうえで判断すべきです。実務的には、アプリを.NETへ上げるタイミングでキューも移行するのが本筋です。
移行先はRabbitMQとAzure Service Busのどちらがよいですか？
その二択の前に、データベースのテーブルをキューにする案を検討してください。MSMQを使う中小規模の業務システムの多くは、キューの相手が自社のデータベースを更新する処理です。その場合、テーブルキューなら業務データと同じローカルトランザクションで「メッセージの取り出し」と「業務データの更新」を確定でき、MSMQ+分散トランザクション(DTC)で実現していた整合性を、より単純な仕組みで置き換えられます。テーブルキューで足りない要件、たとえば複数システム間の疎結合な配信や高いスループットが必要な場合に、オンプレ要件が強ければRabbitMQ、クラウドに置けるならAzure Service Busを検討する、という順番が失敗しにくいです。
当面は.NET Frameworkのまま塩漬けにする判断はありですか？
条件付きでありです。.NET Framework 4.8はWindowsのコンポーネントとしてOSのライフサイクルに沿ってサポートされ、MSMQ自体も非推奨になっていないため、「動き続ける」見込みは立てられます。ただし塩漬けを選ぶ場合は、キッティング手順にMSMQ機能の有効化を明記する、キュー長とジャーナルの監視を仕込む、メッセージ形式と接続構成をドキュメント化する、担当者の異動に備えて回復手順を残す、の4点を最低限やってください。塩漬けの本当のリスクは技術ではなく、「触れる人がいなくなること」です。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。

お問い合わせ
ブログ一覧に戻る