小ネタ：Microsoft 公式の Release Communications MCP で Azure Updates / M365 Roadmap を聞けるようになってた

こんにちは、MCP を増やしすぎると自分でも何が公式で何が自作か分からなくなるアーキテクトのやまぱんです 😅

補足コメントや質問、いいね、拡散、ぜひお願いします 🥺！
間違っていたら 優しく 教えてください！

今日は小ネタです。

Microsoft が Microsoft Release Communications MCP Server を公式に出してくれていました。
これで、Azure Updates と Microsoft 365 Roadmap は、まず公式 MCP に聞けばよさそうです。

公式ドキュメントはこちらです。

今回の対象はこの 2 つです。

• Microsoft 365 Roadmap

• Azure Updates

私はこれまで、自分の環境で azure-updates や m365-update の独自 MCP / 拡張を使っていました。
でも公式 MCP が出たなら、少なくともこの 2 つは 「もう自前で抱えなくてよくない？」 という気持ちです。

この記事では、入れ方と実際に聞いてみた結果を軽くメモします。

TL;DR

• Microsoft 公式の Release Communications MCP Server が公開された
• 対象は Azure Updates と Microsoft 365 Roadmap
• 認証不要 / 追加ライセンス不要 で使える
• VS Code では mcp.json に HTTP サーバーを 1 件追加するだけで試せる
• 私の環境では、独自の azure-updates と m365-update は外して、公式 mrc-mcp に寄せることにした

何が出たの？

今回出たのは、Microsoft 公式の Microsoft Release Communications MCP Server です。

私にとって大きかったのは、次の 2 系統の公開情報を AI クライアントから直接引けるようになったことでした。

• Microsoft 365 Roadmap
• Azure Updates

これまでブラウザでロードマップサイトや Azure Updates のページを見に行っていた情報を、Copilot や MCP 対応クライアントから直接問い合わせやすくなりました。

ここで嬉しかったのは、Microsoft 公式 だという点です。
独自 MCP を作ると、API 仕様変更や同期処理、キャッシュ、配布方法まで面倒を見る必要があります。
今回はそこを公式が持ってくれます。

要件

前提はかなりシンプルです。

• 認証不要
• 追加ライセンス不要
• 公開情報のみ対象

認証もライセンス追加も要らないので、まず 1 回試すところまでは入りやすいです。

エンドポイント

公式の MCP エンドポイントはこれです。

https://www.microsoft.com/releasecommunications/mcp

この URL はブラウザーで直接開く用途ではありません。
公式ドキュメントにもある通り、手でアクセスすると 405 Method Not Allowed になることがあります。

VS Code での設定

VS Code なら、ユーザープロファイルの mcp.json に 1 件追加すれば OK です。

Windows のユーザーレベル設定ファイルは次です。

%APPDATA%\Code\User\mcp.json

私の環境ではグローバルに効かせたかったので、ワークスペースではなくユーザー側に入れました。

設定はこれだけです。

{
  "servers": {
    "mrc-mcp": {
      "type": "http",
      "url": "https://www.microsoft.com/releasecommunications/mcp"
    }
  }
}

すでに他の MCP を使っているなら、既存の servers の中にこの 1 件を足す形です。

追加後は VS Code を再読み込みして、MCP: List Servers で mrc-mcp が見えればだいたい OK です。

GitHub Copilot CLI での設定

これは VS Code だけの話ではなく、GitHub Copilot CLI 側でも使えます。

CLI 側の設定ファイルは次です。

~/.copilot/mcp-config.json

私の環境では、ここもローカルの azure-updates から公式 mrc-mcp に切り替えました。

書く内容は VS Code 側とほぼ同じです。

{
  "mcpServers": {
    "mrc-mcp": {
      "type": "http",
      "url": "https://www.microsoft.com/releasecommunications/mcp"
    }
  }
}

VS Code 側と CLI 側の両方で同じ公式エンドポイントを使う形にしておくと、どこで聞いても同じ系統の情報を取りにいけます。

使えるツール

公式ドキュメントでは、次の 4 つのツールが公開されています。

• get_recent_azure_updates
• get_azure_update_by_id
• get_recent_roadmaps
• get_roadmap_by_id

クライアントによっては、表示名にプレフィックスが付いたり、若干名前が変わって見えることがあります。
でも役割としては、一覧取得 2 つ と ID 指定の詳細取得 2 つ です。

URL はどこまで返る？

ここは少しだけ注意です。

公式 MRC MCP は、一覧と詳細の構造化データを返してくれます。
VS Code の Copilot Chat では、プロンプトで URL 付きと伝えると、回答に参照 URL を添えられました。

ここは 2 つに分けて見た方がよさそうです。

まず、MCP サーバーの生データとしては、URL 専用フィールドが常に入るわけではありませんでした。
Azure 側の get_azure_update_by_id では URL フィールドは見当たらず、M365 側も moreInfoUrls が空の項目がありました。

一方で、Copilot への依頼として「参照 URL 付きで」と書けば、回答には URL を添えられました。
Azure Updates は id から更新ページを引けますし、M365 Roadmap も Roadmap ID を searchterms に入れれば参照できます。

Azure も M365 Roadmap も、回答として URL 付きで扱えました。
ただし、毎回同じ形で URL フィールドが返るというより、ID や moreInfoUrls をもとに参照 URL を添える、という理解が近そうです。

もし回答に URL を安定して含めたいなら、次のどちらかをやっておくと安心です。

• プロンプトで「機能 ID と利用可能な URL も含めて」と明示する
• カスタム instructions で「参照元 URL を可能な限り添える」と決めておく

実際に試した

私の環境では、VS Code 側の mcp.json と GitHub Copilot CLI 側の ~/.copilot/mcp-config.json を公式 mrc-mcp 構成に寄せて、いくつかクエリを試しました。

GitHub Copilot CLI でも、起動時に次のように MCP サーバーが読み込まれていました。

GitHub MCP Server: Connected
Environment loaded: 2 custom instructions, 5 skills, 4 MCP servers

この状態で、CLI からも mrc-mcp のツールが呼ばれていました。

Azure Updates 側

たとえば、こんな聞き方が通りました。

azure update で更新された VM や VNET 関連機能を一覧にして URL つきで！

このときは、最初のキーワード検索では拾いきれなかったので、Compute / Networking カテゴリから取り直していました。
CLI の出力を見ると、次のように mrc-mcp の Azure Updates ツールを呼んでいます。

get_recent_azure_updates (MCP: mrc-mcp)
get_azure_update_by_id (MCP: mrc-mcp)

結果として、VM 系 2 件と VM 周辺 1 件が取れました。
VNET 直球の更新は、今月更新分では見当たりませんでした。

• Azure Dl/D/E v7 Virtual Machines が GA

• Azure Reserved Virtual Machines Instances for select VM series の retirement

• Azure Premium SSD v2 Disk が Japan West の 3 Availability Zones で利用可能に

新機能だけでなく retirement 情報も同じ流れで見えるので、運用や影響確認にも使いやすそうでした。
検索語で取りきれないときにカテゴリ側から取り直せるのも、Agent に任せると楽なところです。

Microsoft 365 Roadmap 側

Microsoft 365 Roadmap 側では、Purview で試しました。
CLI には次のように投げました。

Microsoft 365 ロードマップで今月更新された Purview 関連機能を一覧にして URL つきで！

このときも、CLI は mrc-mcp の Microsoft 365 Roadmap ツールを呼んでいました。

get_recent_m365_roadmaps (MCP: mrc-mcp)
get_m365_roadmap_by_id (MCP: mrc-mcp)

結果は、2026 年 5 月に更新された Microsoft Purview 関連の Roadmap が 23 件 でした。
URL は公式 Roadmap の Feature ID 直リンクとして付けられました。

たとえば、こんな項目です。

• Data Loss Prevention - DLP Policy Change Insights with Security Copilot

• Microsoft Purview: eDiscovery - Enhancement of Loop and Copilot Pages in Review and Export

• Microsoft Purview: Data Security Investigations - Introducing OCR support

Azure Updates も M365 Roadmap も、URL 付きで聞けばちゃんと読者に渡せる形まで持っていける、という感触です。

途中でこんなのも作ってました

実は公式 MCP が出る前、私は Azure Updates 側も M365 側も自前でなんとかしようとしていました。

Azure Updates 側は、ローカルに MCP サーバーを立てて、mcp.json から azure-updates として呼び出す構成にしていました。
動くには動くんですが、ビルド済みファイルの場所やデータ取得元の変更を自分で見続ける必要があります。

M365 側については、途中で自分でもこんな拡張を作っていました。

• M365 UPDATE MCP

中身としては、Microsoft 365 Roadmap をローカルに同期して、Copilot Chat から検索できるようにした VS Code 拡張です。
SQLite のローカル全文検索、起動時の自動同期、参照 URL の整形などを入れていて、当時はそれなりに便利でした。

でも、今回の公式 MCP が出たことで、「そこまで自前で持たなくてもよくなった」 というのが今の気持ちです。

この話の面白いところは、過去に作ったものが無駄だった、ではないんですよね。
当時は必要だったし、だから作った。
でも公式が出たなら、そこに素直に寄せる方が軽い。
今回は、Azure Updates のローカル MCP サーバーも、M365 Roadmap の自作拡張も、まず公式 MRC MCP に寄せる整理でした。

小ネタだけど嬉しかったところ

私がいちばん楽になったのは、独自 MCP を維持する理由が 1 つ減ったこと です。

これまで独自で持っていた MCP / 拡張は、便利ではあったんですが、どうしても次の面倒がありました。

• データ取得元の追従
• ローカル DB や同期処理のメンテ
• VS Code 拡張としての配布
• mcp.json への登録や差し替え

公式 MCP が出たことで、Azure Updates と M365 Roadmap に関しては、少なくとも 「まず公式を使う」 でよくなりました。

保守対象が 2 つ減るだけで、だいぶ気が楽です。

私の環境ではここを置き換えた

今回、私のユーザー設定では次の 2 つを公式 mrc-mcp に寄せました。

• Azure Updates → 公式 MRC MCP に置き換えやすい
• Microsoft 365 Roadmap → 公式 MRC MCP に置き換えやすい

今回の公式 MCP が見ているのは、Azure と M365 の release communications です。
なので、私の環境でも整理対象は azure-updates と m365-update の 2 つだけでした。

• mrc-mcp を追加
• 既存の azure-updates を削除
• 既存の m365-update を削除

私は、公式で置き換えられるところだけ先に寄せる 方針にしました。

全部まとめて消すのではなく、境界をはっきりさせて整理した方が安全でした。

こんな人にはよさそう

• すでに VS Code で MCP を触っている人
• Azure Updates や M365 Roadmap を Chat から直接聞きたい人
• 独自 MCP やローカル API ラッパーを減らしたい人
• 「まずは公式を優先したい」派の人

注意点

使ってみて、先に知っておいた方がよさそうだと思ったのはこのあたりです。

• Azure と Microsoft 365 の話題を 1 プロンプトに混ぜない方が安定する
• 「最新の update」「ロードマップ」「Teams 機能」みたいに、何を引きたいかを明示 した方がツールが呼ばれやすい
• ツールが呼ばれない場合は、Agent モードやツール選択を見直す

実際に試したときも、「Teams の今月更新分を出して」のように製品名と観点を一緒に書いた方が安定していました。
このへんは、公式ドキュメントのトラブルシューティングにも沿っています。

まとめ

Microsoft 公式の Release Communications MCP Server が出たことで、Azure Updates と Microsoft 365 Roadmap は公式 MCP に寄せやすくなりました。

私は今回、実際にグローバルの mcp.json に入れて試してみて、Azure Updates 側も M365 Roadmap 側も普通に引けるところまで確認しました。
そのうえで、独自の azure-updates と m365-update は外して、mrc-mcp に寄せる方針にしました。

M365 側は途中で自分でも拡張を作っていましたが、それでも今は 公式があるなら公式に寄せたい です。
保守対象が減るのは、やっぱり気持ちがいいです。

こういうの、機能が増えたというより、持ち物が減ったのが嬉しい んですよね。

なお、D365 や Power Platform 向けのものも過去に少し作っていましたが、そこは今回の公式 MCP の対象ではありません。
なので今回は、Azure Updates と Microsoft 365 Roadmap を公式に寄せるところまでに絞っています。

参考

• Microsoft Release Communications MCP Server の概要 - Microsoft Learn

• Add and manage MCP servers in VS Code

• M365 UPDATE MCP - Visual Studio Marketplace

• Microsoft 365 Roadmap

• Azure Updates