Microsoft Learn MCP Serverとは｜使い方と3ツールの中身・常駐コストを実測して解説

AIコーディングアシスタントにAzureやMicrosoft 365のことを聞くと、存在しないSDKメソッドを自信満々に返してくることがある。Microsoft Learn MCP Server は、その穴を公式ドキュメントの実物で埋めるためにMicrosoftが公開している認証不要のリモートMCPサーバーだ。この記事では使い方を押さえたうえで、実際にエンドポイントへ接続して「ツールは何個で、常駐コストはいくらで、1回の検索で何バイト返ってくるのか」「日本語クエリで日本語ドキュメントは返るのか」を測った結果を示す。

MCPそのものの仕組みから確認したい場合はMCPサーバーの作り方2026年完全ガイド：TypeScript・Python両対応チュートリアルを先に読むと、以下の「ツール定義がコンテキストを食う」という話が理解しやすい。

Microsoft Learn MCP Serverとは——インストールしない種類のMCPサーバー

MCPサーバーというと npx や docker でローカルにプロセスを立てるものを想像しがちだが、Microsoft Learn MCP Server はその逆で、Microsoftが運用しているHTTPエンドポイントに繋ぐだけのリモートサーバーだ。手元では何も動かない。

ライセンスは注意点がある。GitHubのリポジトリ表示もAPIも CC-BY-4.0 しか返さないため「ドキュメント用ライセンスのリポジトリ」に見えるが、実際には LICENSE-CODE が別に置かれていて、そちらは MIT だ。コンテンツ（ドキュメント）に CC-BY-4.0、コードに MIT を適用する Microsoft のドキュメント系リポジトリで一般的な構成である。リポジトリ内の cli/package.json も "license": "MIT" を宣言している。

なお、このリポジトリはサーバー本体の実装ではない。中身は CLI（@microsoft/learn-cli・実行ファイル名 mslearn）、3つのAgent Skill（microsoft-docs / microsoft-code-reference / microsoft-skill-creator）、各種エージェント向けのプラグイン定義（.claude-plugin / .codex-plugin / .agents）、そして .mcp.json である。サーバーのソースコードは公開されていない——公開されているのは「繋ぎ方」と周辺ツールだ。ここは正直に押さえておきたい。

同梱されている cli/ は npm に @microsoft/learn-cli として公開されており、実行ファイル名は mslearn。npmレジストリを確認すると latest は 0.1.0（2026-03-16 公開）で、ほかに preview と dev のタグが切られている。バージョン番号が示すとおり、CLIはまだ初期段階だ。MCPサーバー本体（バージョン1.0.0）とは成熟度が違う点に注意したい。

skills/ に置かれた3つのAgent Skillは、MCPとは別系統の提供手段である。microsoft-docs と microsoft-code-reference はドキュメント参照の作法をエージェントに教えるもので、microsoft-skill-creator はスキルそのものを作るためのメタスキルだ。MCPで繋ぐ以外に「スキルとして読ませる」経路も用意されている、という構成になっている。

何を解決するのか

READMEの主張は明快で「Stop AI Hallucinations（AIの幻覚を止める）」だ。学習データが古いままのモデルが、存在しないAzure SDKのメソッドやパッケージを作り出す問題に対して、一次情報である Microsoft Learn を直接引かせる。汎用のWeb検索と違い、参照先がMicrosoft公式ドキュメントに限定される点をサプライチェーンの観点から利点として挙げている。

Microsoft Learn MCPの使い方——クライアント別の設定

リモートHTTPサーバーなので、設定は「URLを1行書く」だけで済む。リポジトリに含まれる .mcp.json がそのまま最小構成の例になっている。

{
  "mcpServers": {
    "microsoft-learn": {
      "type": "http",
      "url": "https://learn.microsoft.com/api/mcp"
    }
  }
}

Claude Code なら、プロジェクト直下に上記の .mcp.json を置くか、次のコマンドで登録する。

# Claude Code にリモートMCPサーバーとして登録して確認する
claude mcp add --transport http microsoft-learn https://learn.microsoft.com/api/mcp
claude mcp list

VS Code は README にワンクリックのインストールバッジが用意されている（内部的には同じURLを type: http で登録しているだけだ）。Claude Desktop の場合は Settings → Connectors → Add Custom Connector に同じURLを入れる。

呼ばせたいときは明示的に指名する

実運用でつまずきやすいのが「繋いだのに使ってくれない」だ。ツールを持っていてもモデルが自前の知識で答えてしまうケースがあるため、プロンプト側で「Microsoft Learn のMCPで確認して」のように明示的に指名するほうが確実に発火する。READMEが挙げている例示プロンプトも、gpt-5.4 は Azure の EU リージョンで使えるか のようにモデルの学習データでは答えられない鮮度の質問に寄せてある。

公開されている3ツールの中身と常駐コストの実測

ここからが本題だ。initialize → notifications/initialized → tools/list の順にJSON-RPCを投げて、返ってきた内容をそのまま測った。

公開ツールは3個。それぞれの定義サイズは次のとおりだ。

加えて、initialize の応答に instructions が1,545バイト含まれる。これは3ツールの使い分け（Search=広さ／Code Sample=実例／Fetch=深さ）を書いたマークダウンで、多くのMCPクライアントはこれもコンテキストへ載せる。つまり接続しただけで約6.5KBが常駐する。

比較すると、この軽さははっきりしている。Chrome DevTools MCPとは｜使い方と既定29ツールの中身・Playwright MCPとの違いで実測したChrome DevTools MCPは既定29ツール、GitHub MCPとは｜公式MCPサーバーの使い方・86ツール・リモート/ローカル版と権限設計を解説で扱ったGitHub MCPは86ツールだった。3ツールというのは、常時繋ぎっぱなしにしても負担にならない水準である。

1回の検索で何バイト返るのか——呼び出しコストの実測

常駐コストが軽いことと、使ったときに軽いことは別の話だ。実際に各ツールを呼び、返却テキストのバイト数を測った。

接続から検索1回までで、コンテキストに何が積み上がるかを図にすると次のようになる。

読み取れるのはコスト構造が「常駐は軽い・呼び出しは重い」型だということ。ツール定義は6.5KBしかないのに、検索を1回走らせるだけでその約3.5倍がコンテキストに入る。数回検索させれば100KB近くを消費しうる。

サーバーの instructions は各チャンクを「最大500トークン」と説明しており、実測の1件あたり約2.2KBはおおむね整合する（英語テキストで概ね500〜550トークン相当）。返却されるJSONのキーは title / contentUrl / content の3つだけで、余計なメタデータは付かない。設計としては素直だ。

日本語クエリの挙動——ここは日本の開発者に直接効く

日本語で使う以上、最も知りたいのは「日本語で聞いたら日本語のドキュメントが返るのか」だろう。Microsoft Learn は日本語版ドキュメントが充実しているため、期待したくなるところだ。

結論から言うと返らない。

Entra ID の条件付きアクセスを設定する方法 という日本語クエリを投げた結果は次のとおりだった。

・返却10件、日本語タイトルは0件（10件すべて英語タイトル）
・返却された contentUrl にロケール指定が付かない（https://learn.microsoft.com/entra/identity/... の形式で、/ja-jp/ も /en-us/ も含まれない）
・内容自体は正しく、意図した条件付きアクセス関連のページが返っている（検索としては機能している）

つまりクエリの言語は理解するが、返すコンテンツは英語という挙動だ。ロケールなしURLは learn.microsoft.com 側でブラウザの言語設定に応じてリダイレクトされるため、人間がリンクを踏む分には日本語ページに着地しうる。しかしMCP経由でモデルが受け取る content は英語のままである。

実務上の意味は2つある。1つは、モデルには英語の一次情報が入るので回答の精度は落ちないこと。むしろ翻訳の遅れがある日本語版より最新である可能性が高い。もう1つは、読者に提示するURLは自分で日本語版に読み替える必要があること。返ってきた https://learn.microsoft.com/entra/... を https://learn.microsoft.com/ja-jp/entra/... に直せば日本語ページになる。

企業で使うとき、外に出るのは「クエリ文字列」

読み取り専用のドキュメント検索とはいえ、社内利用を検討するなら「何がMicrosoftに送られるのか」は押さえておきたい。プロトコル上、このサーバーに送られるのは次の3つだけだ。

・clientInfo（クライアント名とバージョン。任意の文字列を名乗れる）
・microsoft_docs_search / microsoft_code_sample_search の query 文字列
・microsoft_docs_fetch の url

ソースコードもファイルパスも、エージェントが読んでいるリポジトリの内容も送られない。送信されるのは検索語だけである。ただし検索語には文脈が漏れうる——エージェントが自動生成するクエリは、しばしば作業中の固有名詞（社内サービス名・内部プロジェクト名）を含む。「公式ドキュメントを引くだけだから安全」と考えて全社展開する前に、どんなクエリが実際に飛んでいるかを一度ログで確認することをすすめたい。

認証がないことは導入の容易さと表裏で、利用者単位のアクセス制御も監査ログも存在しないことを意味する。組織として通信を管理したい場合は、MCPクライアント側の設定管理か、ネットワーク側で learn.microsoft.com への到達を制御する以外の手段がない。

コンテキスト消費をどう見積もるか

前掲の実測値から、実務的な目安を出しておく。常駐が約6.5KB、検索1回が約22KB、docs_fetch が1ページ約8.7KBだった。サーバーの instructions は「Search で探す → 必要なら Code Sample → さらに深く要るなら Fetch」という3段のワークフローを指示しているため、素直に従うと1つの調べもので30〜40KBを消費する計算になる。

1回あたりが重いぶん、「とりあえず全部調べさせる」使い方はコンテキストを一気に食う。逆に言えば、常駐が軽いので「繋いでおいて必要なときだけ指名する」運用が最も費用対効果が高い。前述の「明示的に指名しないと発火しにくい」という性質は、この使い方とはむしろ相性がよい。

なお microsoft_docs_fetch はページ全文をマークダウンに変換して返す。実測した条件付きアクセスの概要ページは8,733バイトで、見出し構造（# What is Conditional Access? / ## Overview …）を保ったクリーンなマークダウンだった。HTMLタグやナビゲーションは混ざらない。手順やトラブルシューティングのように途中を飛ばせない文書を読ませたいときは、検索結果の断片ではなくこちらを使うほうが確実だ。

language パラメータは絞り込みではない

microsoft_code_sample_search には language という省略可能なパラメータがある。ツールの説明文は「Optional parameter language can filter results.」と書いており、素直に読めば「指定した言語で絞り込める」と受け取る。実際に測ると、そうではなかった。

python のように Microsoft Learn 上のサンプルが潤沢な言語では9/10まで寄るが、rust のようにサンプルが少ない言語では3/10しか一致しない。挙動としては、指定言語を優先しつつ足りない分を他言語で埋める「順位付けのヒント」と考えるのが実態に合う。

エージェントに language=rust を指定させて「返ってきたコードはRust」と前提を置くと、7割はRust以外を掴むことになる。受け取った側で language フィールドを検証するのが安全だ（返却JSONに各件の language が含まれているので検証自体は容易）。

同じ測定を手元で再現する

ここまでの数値は、特別なツールを使わずに再現できる。MCPのStreamable HTTPはJSON-RPCをPOSTするだけなので、curl で initialize を投げれば instructions とサーバー情報がそのまま返る。

# Microsoft Learn MCP に接続して initialize の応答を見る（認証不要）
curl -s -X POST https://learn.microsoft.com/api/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{
       "protocolVersion":"2025-06-18","capabilities":{},
       "clientInfo":{"name":"probe","version":"1.0"}}}'

応答ヘッダに mcp-session-id が入って返るので、続けて tools/list や tools/call を投げるときはこのヘッダを付ける。セッションIDを引き回せば、本記事の測定値（ツール定義5,012バイト、検索1回22,127バイト等）はそのまま追試できる。

他のMCPサーバーとの違い——「何を取りに行くか」で選ぶ

MCPサーバーは増えすぎて選びにくい。当サイトで実測してきたものと並べると、役割の違いがはっきりする。

Microsoft Learn MCP の位置づけは明快で、書き込みを一切しない読み取り専用のドキュメント検索だ。GitHub MCP のように権限設計を悩む必要がなく、Chrome DevTools MCP のようにローカルでブラウザを起動することもない。副作用がないぶん、導入判断のハードルは全MCPサーバー中でも相当低い部類にある。

同じMicrosoft製でもMicrosoft Powerbi Modeling Mcp：Power BIモデルをAIで自動構築するMCPサーバーは自社のBIモデルを触りに行くもので、対象がまったく違う。両者は競合ではなく併用するものだ。

READMEの主張をどう評価するか

READMEは「100% Trusted & Safe」「Eliminate Hallucinations」と強めに書いている。測った範囲での評価はこうだ。

・参照先が公式に限定されるのは事実。返却された全URLが learn.microsoft.com ドメインだった。汎用Web検索と違い第三者ブログを踏まない点は、主張どおり
・幻覚を「なくす」とまでは言えない。ツールはあくまで正しい一次情報を渡すだけで、それをモデルが正しく使うかは別問題。しかも前述のとおり呼ばせるには明示的な指名が要ることが多い
・「無料・キー不要」は確認できた。認証情報なしで3ツールすべてを実行できている

まとめ——導入判断は「軽さ」ではなく「呼び出しの重さ」で

Microsoft Learn MCP Server は、認証不要・3ツール・副作用なしという点で、MCPサーバーの中でも導入コストが最小級だ。Azure や Microsoft 365 を触る開発者なら、繋いでおいて損はない。

一方で測って分かったのは、軽いのは常駐部分だけだということ。ツール定義6.5KBに対し、検索1回で22〜24KBが返る。加えて、①日本語クエリでも英語ドキュメントが返る ②language は厳密なフィルタではない ③「最大20件」は実測10件 という、説明文と実挙動のズレが3点ある。いずれも致命的ではないが、これらを前提に組んだエージェントは静かに期待外れの結果を返す。繋ぐ前に知っておく価値のある差分だ。

参照ソース

・MicrosoftDocs/mcp — GitHub リポジトリ（README、.mcp.json、LICENSE／LICENSE-CODE、cli/package.json、skills/ を参照） ・Microsoft Learn MCP Server エンドポイント（本記事の測定対象。initialize / tools/list / tools/call の応答はすべて2026-08-07 JSTに取得） ・Model Context Protocol 公式仕様（プロトコルバージョン 2025-06-18 の定義） ・@microsoft/learn-cli — npm（同梱CLIの配布状況。latest 0.1.0）