.NET開発者が押さえるべきMCP C# SDK v1.0の全体像と2025-11-25仕様準拠の意義

.NET開発者が押さえるべきMCP C# SDK v1.0の全体像と2025-11-25仕様準拠の意義

Microsoftが公式に協業メンテナンスを行うMCP C# SDKが、2026年3月5日にv1.0の正式リリースを迎えました。Model Context Protocol（MCP）はLLMと外部データソースやツールとの連携を標準化するオープンプロトコルであり、C# SDKはその.NET実装として位置付けられています。v1.0では2025-11-25版のMCP仕様にフル対応し、認可フローの強化からメタデータの拡充、ツール呼び出しパターンの刷新まで、本番環境での採用を前提とした包括的な機能セットが整いました。ここでは、.NET開発者がまず理解すべきSDKの全体像と、仕様準拠が意味する実務上のインパクトを体系的に整理します。

MCPが解決するLLMコンテキスト連携の3つの課題とプロトコル標準化の背景

大規模言語モデル（LLM）をアプリケーションに組み込む際、従来は3つの共通課題がありました。第一に、各LLMプロバイダーごとにツール呼び出しやコンテキスト受け渡しのインターフェースが異なり、マルチベンダー対応のたびに個別実装が必要だった点です。第二に、社内データベースやファイルストレージなど外部データソースとの接続仕様がバラバラで、統合コストが膨大になっていた点が挙げられます。第三に、認可やセキュリティの標準が不在のため、APIキーの受け渡しやユーザー認証をアプリケーションごとに独自実装していた点も深刻でした。MCPはこれらの課題に対し、JSON-RPCベースのプロトコルとして標準化されたメッセージ形式を定義し、ツール・リソース・プロンプトという3つのプリミティブで統一的なインターフェースを提供します。これにより、サーバー側がMCPに準拠していれば、GitHub CopilotやClaude Desktopなど任意のMCPクライアントから同一のプロトコルで接続できるようになりました。

v1.0で正式対応した2025-11-25仕様の主要変更点7項目の一覧整理

MCP C# SDK v1.0がサポートする2025-11-25版仕様には、開発者が把握すべき主要な変更が含まれています。以下の7項目を押さえておくことで、SDK導入時の設計判断が的確になります。

これらの変更はいずれも独立して採用可能ですが、認可関連の3項目（PRM探索・CIMD・incremental scope）は一体的に設計されており、セキュアなサーバー構築にはまとめて理解することが推奨されます。

プレビュー版からv1.0への移行で解消された破壊的変更5件と対処の実務例

MCP C# SDKは2025年3月の初回プレビュー公開以降、複数のプレビューリリースを経てv1.0に到達しています。この過程で発生した破壊的変更を整理すると、移行作業の見通しが立ちやすくなります。まず、EnumerateToolsAsyncやEnumeratePromptsAsyncなど列挙系メソッドがパブリックAPIから削除され、ListToolsAsync系のページネーション対応メソッドに統一されました。次に、McpClient.SetLoggingLevelがSetLoggingLevelAsyncにリネームされ、非同期パターンが徹底されています。さらに、IsConfiguredEndpointRequest()のURI検証がパスだけでなくホストとスキームの一致まで検証するように厳格化され、一部の既存リクエストが拒否される可能性があります。加えて、McpAuthenticationOptions.ResourceMetadataUriの型がstringからnullable string?に変更されました。最後に、EnumSchemaとLegacyTitledEnumSchemaが廃止扱いとなり、カスタム診断ID MCP9001での抑制が必要です。移行時は、これらの変更箇所をプロジェクト全体でgrepし、コンパイルエラーと警告を一括修正する手順が実務上効率的です。

GitHub Stars 4,000超の開発体制──Microsoft協業とコミュニティ貢献の実態

MCP C# SDKのリポジトリはGitHub上のmodelcontextprotocol/csharp-sdkに公開されており、2026年3月時点でStars数は4,000を超えています。リポジトリの説明には「Maintained in collaboration with Microsoft」と明記されており、MicrosoftのStephen Toub氏やJeff Handley氏をはじめとする.NETチームのコアメンバーが積極的にコミットしています。このプロジェクトの原型は、Peder Holdgaard Pedersen氏が開始した「mcpdotnet」というコミュニティプロジェクトであり、その成果を基盤としてMicrosoft主導の公式SDKに発展した経緯があります。コントリビューションはバグ報告から機能提案、コード貢献まで幅広く受け付けられており、GitHub CopilotのAI支援による自動PRも一部で活用されています。SDKは2025年12月にAnthropicからLinux Foundation配下のAgentic AI Foundation（AAIF）に寄贈されたMCPオープンソースプロジェクトの一部として運営されており、特定企業にロックインされないベンダー中立のガバナンス体制が確保されている点も、企業採用時の安心材料となります。

Apache-2.0ライセンス採用が商用プロジェクトに与えるライセンス選定上の判断基準

MCP C# SDKはApache License 2.0で公開されています。このライセンスは商用利用・改変・再配布を幅広く許容しつつ、特許条項を含むため、コントリビューターからの暗黙的な特許ライセンス付与が保証されます。.NETエコシステムでは、Microsoft自身が.NETランタイムをMITライセンスで公開しているため、MCP C# SDKとの組み合わせでライセンス衝突が起きない点も重要です。Apache-2.0の実務上の要件は、著作権表示とライセンス文の同梱、変更箇所の明示という3点に集約されます。GPLとは異なりコピーレフト条項がないため、MCPサーバーを自社SaaSに組み込んでもソースコード公開義務は発生しません。一方で、Apache-2.0はGPLv2との互換性がないため、GPLv2依存のライブラリと同一バイナリにリンクする構成では注意が必要です。商用プロジェクトでの採用判断においては、法務チームへの確認を前提としつつ、Apache-2.0は最も採用障壁の低いOSSライセンスの一つと評価できます。

認可フロー刷新で変わるMCPサーバー構築──PRM自動探索とCIMD対応の実務的影響

MCP C# SDK v1.0で最も大きな変化の一つが、認可サーバー探索メカニズムの刷新です。2025-11-25仕様では、Protected Resource Metadata（PRM）ドキュメントの公開方法が従来の1方式から3方式に拡張され、クライアントID登録にはCIMDという新たな仕組みが導入されました。さらにincremental scope consentにより、最小権限の原則をOAuthフローに自然に適用できるようになっています。これらの変更は認可設計の根本に関わるため、MCPサーバーを構築するすべての.NET開発者が理解すべき内容です。

Protected Resource Metadata公開の3方式と従来単一方式との柔軟性比較

2025-11-25仕様以前のMCPでは、サーバーがProtected Resource Metadata（PRM）ドキュメントを公開する方法は、WWW-Authenticateヘッダーのresource_metadataパラメータにURLを記載する1方式のみでした。新仕様ではこれに加えて2つの方式が追加されています。第二の方式は、MCPエンドポイントパスから導出される「well-known」URL（例：https://example.com/.well-known/oauth-protected-resource/public/mcp）でPRMを公開する方法です。第三の方式は、ルートのwell-known URL（例：https://example.com/.well-known/oauth-protected-resource）に配置する方法です。3方式が並列で利用可能になったことで、サーバー側はインフラ構成やリバースプロキシの制約に応じて最適な公開方法を選択できます。既存のヘッダーベース方式との後方互換性も維持されているため、段階的な移行が可能である点も実務上の大きな利点です。

well-known URL自動探索の仕組みとクライアント側の実装がゼロになる理由

MCP C# SDKのクライアント実装では、PRM探索プロセスが完全に自動化されています。クライアントがMCPサーバーに接続する際、SDKは内部的に3つのPRM公開方式を順番に試行し、最初に成功した方式でPRMドキュメントを取得します。具体的には、まずWWW-Authenticateヘッダーのresource_metadataパラメータを確認し、見つからない場合はエンドポイント固有のwell-known URLを、それも失敗した場合はルートのwell-known URLを参照するフォールバックロジックが組み込まれています。この自動探索により、クライアント開発者はPRMの取得先を意識する必要がなくなり、認可サーバーの構成が変更されてもクライアントコードの修正は不要です。なお、v0.5.0-preview.1のリリースノートでは、401レスポンスにresource_metadataパラメータが欠落している場合のwell-known URLへのフォールバック処理が追加修正されており、エッジケースへの対応も進んでいます。

CIMDがDynamic Client Registrationより優先される判断基準とフォールバック挙動

2025-11-25仕様では、Client ID Metadata Documents（CIMD）がDynamic Client Registration（DCR）に代わる推奨方式として位置付けられています。CIMDは、クライアントのメタデータをURLベースで公開し、認可サーバーがそのURLを参照してクライアント情報を取得する仕組みです。DCRでは認可サーバーに対してクライアント登録リクエストを動的に送信する必要がありましたが、CIMDではクライアント側が静的なメタデータドキュメントをホストするだけで済むため、実装の複雑さが大幅に軽減されます。MCP C# SDKでは、OAuthオプションでCIMDとDCRの両方を構成可能であり、SDKはまずCIMDを試み、認可サーバーがCIMDをサポートしていない場合にのみDCRへフォールバックします。このフォールバック挙動は自動で行われるため、クライアント開発者は認可サーバーの対応状況を事前に調査する手間が省けます。新規プロジェクトでは原則CIMDを採用し、レガシー認可サーバーとの互換性が必要な場合にのみDCRを有効化する設計が推奨されます。

incremental scope consentで最小権限を実現する段階的スコープ要求の設計例

従来のMCP認可フローでは、クライアントが接続時にすべての権限スコープを一括して要求する設計が一般的でした。しかし、この方式では初回接続時に過剰な権限を求めることになり、ユーザー体験の悪化やセキュリティリスクの増大につながっていました。2025-11-25仕様のincremental scope consentでは、クライアントは初回接続時に最小限のスコープのみを要求し、追加の権限が必要になった時点で差分スコープを段階的に要求できます。MCP C# SDKのクライアント実装では、この仕組みが自動で処理されます。具体的には、MCPサーバーが特定の操作に対して401または403レスポンスを返し、WWW-Authenticateヘッダーのscopesパラメータで必要なスコープを示すと、SDKが自動的に不足スコープを抽出し、認可フローを再開します。MCP仕様では、スコープの選択戦略としてMinimum（新規スコープのみ）、Recommended（既存＋新規）、Extended（既存＋新規＋関連）の3段階が定義されており、サーバー側の要件に応じて適切な戦略を選択する必要があります。

401/403レスポンス時の自動スコープ抽出が失敗する3つのパターンと回避策

incremental scope consentの自動処理は強力ですが、特定の条件下で期待通りに動作しないパターンが存在します。第一のパターンは、サーバーがWWW-Authenticateヘッダーにscopesパラメータを含めずに403を返すケースです。SDKはscopesパラメータからスコープを抽出するため、このパラメータが欠落していると追加認可のトリガーが発動しません。サーバー実装時には、403レスポンスにinsufficient_scopeエラーと必要スコープを必ず含めるよう徹底する必要があります。第二のパターンは、JWTトークン内のスコープクレームの表現形式がサーバーの期待と異なるケースです。トークン発行者によってスコープの格納場所やフォーマットが異なるため、MCP C# SDKの認証ハンドラがスコープをClaimsに変換する際の挙動を事前にテストすることが重要です。第三のパターンは、認可サーバーがincremental consentをサポートしていない場合です。この場合、差分スコープの要求自体がエラーとなるため、最初から全スコープを要求するフォールバック設計をクライアント側に組み込んでおく対策が有効です。

URL mode elicitationとサンプリング内ツール呼び出しが拓くセキュアなAI対話設計

MCP C# SDK v1.0では、サーバーとエンドユーザー間の対話をより安全かつ柔軟に設計するための2つの重要機能が追加されました。URL mode elicitationは機密情報の受け渡しをMCPクライアントの外側で完結させる仕組みであり、サンプリング内ツール呼び出しはLLMが応答生成中にサーバー提供のツールを実行できる機能です。これらを組み合わせることで、従来は実現困難だったセキュアかつインタラクティブなAI対話パターンが構築可能になります。

Form modeとURL modeの2種elicitationを用途別に使い分ける判断フロー

MCPのelicitation機能には、Form mode（インバンド）とURL mode（アウトオブバンド）の2種類が存在し、用途に応じた使い分けが重要です。Form modeは、サーバーがJSON Schemaで定義した入力項目をクライアントのUI上に表示し、ユーザーから文字列・数値・ブール値・列挙型などの構造化データを収集する方式です。一般的な設定値の確認やパラメータの選択など、機密性の低い情報収集に適しています。一方、URL modeはサーバーが指定したURLにユーザーのブラウザを誘導し、MCP クライアントを経由せずにサーバーとユーザーが直接やり取りする方式です。APIキーの入力、サードパーティサービスの認可、決済情報の入力など、機密データがクライアント側のログやLLMコンテキストに残るリスクを排除すべき場面で使用します。判断の基準は明確で、収集するデータがクライアントを通過しても安全であればForm mode、機密情報であればURL modeを選択します。MCP仕様では、機密情報の収集には必ずURL modeを使用するよう明記されています。

APIキー・決済情報をクライアント経由させないURL mode実装の具体的コード例

URL mode elicitationの実装では、サーバー側とクライアント側それぞれに必要な設定があります。サーバー側では、McpServerのElicitAsyncメソッドを使用し、ElicitRequestParamsのModeを"url"に設定した上で、ユーザーを誘導するURLと一意のElicitationIdを指定します。クライアント側では、McpClientOptionsのCapabilities.ElicitationにUrlElicitationCapabilityを設定し、ElicitationHandlerを登録します。ハンドラ内ではMode判定を行い、URL modeの場合はユーザーにURLとメッセージを提示し、ブラウザで開くよう促す処理を実装します。サーバー側のURLで何を行うかはMCPの範囲外であり、たとえばOAuth認可画面の表示やStripeの決済フォームなど、任意の処理が可能です。ユーザーがURL先での操作を完了した後、サーバーは任意でnotifications/elicitation/complete通知を送信でき、クライアントはこの通知をトリガーとして後続処理を実行する設計が推奨されます。

サンプリングリクエストにツールを含める手法とMicrosoft.Extensions.AI連携の実務例

2025-11-25仕様で追加されたサンプリング内ツール呼び出しは、MCPサーバーがクライアントに対してLLMの応答生成を要求する際、その応答生成中にLLMが使用できるツールを同時に提供できる機能です。Microsoftはこの機能を「仕様における最も強力な追加の一つ」と位置付けています。実装面では、MCP C# SDKのMicrosoft.Extensions.AIパッケージとの統合が鍵となります。この統合により、MCPのサンプリングリクエストで提供されたツールをIChatClientのツール呼び出し機能にシームレスにマッピングでき、サーバーとクライアントの双方で実装の複雑さが大幅に軽減されます。具体的なシナリオとしては、データ分析MCPサーバーがクライアントにサンプリングを要求する際、SQLクエリ実行ツールやグラフ生成ツールを提供し、LLMが分析の過程で必要に応じてこれらのツールを呼び出すといったワークフローが実現可能になります。

ElicitationHandlerの共通化設計──Mode判定分岐で陥りやすい実装ミス3選

MCP C# SDKでは、Form modeとURL modeのelicitationが単一のElicitationHandlerで処理されます。ハンドラ内でElicitRequestParamsのModeプロパティを判定し、それぞれの処理に分岐させる設計です。この共通ハンドラ設計では、3つの実装ミスが頻出します。第一は、Modeプロパティのnullチェックを怠るパターンです。requestParams自体がnullの場合や、Modeが想定外の値で渡されるエッジケースに対し、デフォルトのElicitResultを返すガード節を最初に配置する必要があります。第二は、URL modeでUrlプロパティの存在確認をせずにブラウザ起動処理を実行するパターンです。ModeがURLであってもUrlがnullである不正なリクエストに対する防御が不可欠です。第三は、Form modeでの入力バリデーション不足です。サーバーがRequestedSchemaで指定したスキーマに対し、ユーザー入力がそのスキーマに適合しないままacceptアクションで返却してしまうと、サーバー側で後続処理が失敗します。これらのミスは、単体テストでmockのElicitRequestParamsを各パターンで生成して検証することで効率的に防止できます。

elicitation/complete通知の受信ハンドラ登録で非同期フローを安全に完了させる手順

URL mode elicitationでは、ユーザーがブラウザ上で操作を完了するまでの時間が不定であるため、非同期フローの管理が重要になります。MCP C# SDKでは、サーバーがURL先での操作完了を検知した時点でnotifications/elicitation/complete通知を送信できます。クライアント側では、McpClientのRegisterNotificationHandlerメソッドを使用してこの通知の受信ハンドラを登録します。具体的な手順としては、まずツール呼び出し前にハンドラを登録し、通知受信時にペイロードをElicitationCompleteNotificationParamsにデシリアライズして完了状態を確認します。その後、ツールの再呼び出し（リトライ）を実行することで、URL先で入力された情報を反映した結果を取得できます。注意点として、RegisterNotificationHandlerはIAsyncDisposableを返すため、await usingで適切にスコープを管理しないとハンドラのリークが発生します。また、通知はオプション機能であるため、すべてのサーバーが送信するとは限らず、タイムアウトベースのフォールバック設計を併用することが実務上の安全策です。

長時間リクエスト処理とTasks実験機能を活かした堅牢なHTTP運用の設計指針

MCPはメッセージベースのプロトコルであり、本来は時間制限を持ちませんが、HTTP上で運用する場合はタイムアウトの問題が避けられません。2025-11-25仕様では、SSEストリームの再接続メカニズムが大幅に改善され、サーバー主導での接続切断が可能になりました。さらに実験機能としてTasksが追加され、長時間処理の状態追跡と結果の遅延取得が標準化されています。ここでは、これらの機能を活用してHTTP環境でも堅牢に動作するMCPサーバーを設計するための指針を解説します。

SSE初期イベント＋Event IDによる再接続メカニズムと旧仕様との信頼性比較

旧仕様でも、サーバーがSSEイベントにEvent IDを含めることでクライアントの再接続は技術的に可能でしたが、実際にこれを実装するサーバーは少数でした。その理由は、ストリーム開始時点からすべてのEvent IDに対する再開をサポートする必要があり、実装負荷が高かったためです。また、サーバー側から主体的に接続を切断する手段がなく、クライアントの切断を待つしかありませんでした。2025-11-25仕様では、このメカニズムが根本的に改善されています。サーバーはSSEストリームを開く際、まずEvent IDを含む空のイベントを送信し、任意でRetry-Afterフィールドを付与します。この初期イベント送信後、サーバーはいつでもストリームを切断できます。クライアントはEvent IDを使って再接続できるため、データの欠損リスクが大幅に低減されます。旧仕様との最大の違いは、サーバー主導の切断が正式にサポートされた点であり、リソース管理とスケーラビリティの観点で大きな改善です。

Retry-Afterフィールド活用でサーバー主導切断を実現する実装手順5ステップ

MCP C# SDKで長時間リクエストのサーバー主導切断を実装する手順を5ステップで整理します。

1. MCPサーバーのHTTP設定で、SSEストリームのイベントストアを構成する。DistributedCacheEventStreamStoreの使用が推奨される
2. リクエスト処理開始時に、Event IDを含む空の初期SSEイベントをクライアントに送信する。この際、Retry-Afterフィールドで推奨再接続間隔を秒単位で指定する
3. サーバー側の処理が継続している間、進捗通知をSSEイベントとして送信する。各イベントにはインクリメンタルなEvent IDを付与する
4. サーバーリソースの制約やアイドルタイムアウトに基づき、サーバー側からSSEストリームを切断する。クライアントは最後に受信したEvent IDを保持している
5. クライアントが再接続リクエストを送信した際、Event IDに基づいて未送信のイベントから再開する。イベントストアに該当イベントが残っている限り、データの欠損なく処理を継続できる

この手順の要点は、初期イベントの送信とイベントストアの構成を確実に行うことです。Retry-Afterの値はサーバーの処理特性に応じて調整し、短すぎると不要な再接続が増加し、長すぎると応答遅延が発生する点に留意してください。

DistributedCacheEventStreamStoreによるSSEストリーム永続化と3種TTL設定の指針

MCP C# SDKは、SSEイベントストリームの永続化手段としてDistributedCacheEventStreamStoreを提供しています。このストアはIDistributedCacheインターフェースを基盤としているため、Redis、SQL Server、NCache など任意の分散キャッシュプロバイダーと組み合わせて使用できます。TTL（有効期限）の設定はDistributedCacheEventStreamStoreOptionsで4種類のパラメータが用意されています。個別イベントに対してはEventSlidingExpiration（スライディング有効期限）とEventAbsoluteExpiration（絶対有効期限）の2種、ストリームメタデータに対してはMetadataSlidingExpirationとMetadataAbsoluteExpirationの2種です。運用上の指針としては、イベントのスライディング有効期限を処理の最大想定時間の2倍程度に設定し、絶対有効期限をその3倍程度に設定する方法が安全です。メタデータは個別イベントより長く保持し、セッション終了後もクライアントが一定期間再接続できる猶予を持たせます。メモリ消費の観点では、すべてのイベントを保持するのではなく、最終結果と重要な中間ステータスのみを選択的に保存する戦略も有効です。

Tasks実験機能の5段階ライフサイクルと終端状態遷移で注意すべき設計制約

Tasks機能は2025-11-25仕様の実験機能として導入されており、MCP C# SDKでは[Experimental("MCPEXP001")]属性が付与されたAPIとして提供されています。Tasksはツール呼び出しやサンプリングリクエストを非同期タスクとして実行し、その状態をポーリングで確認、結果を後から取得できる仕組みです。タスクのライフサイクルは5つのステータス値で構成されます。初期状態の「created」から、処理が進行中の「working」、ユーザー入力を待機する「inputRequired」を経て、終端状態である「completed」「failed」「cancelled」のいずれかに遷移します。設計上の重要な制約として、最後の3つの終端状態は不可逆であり、一度終端状態に到達したタスクは他の状態に遷移できません。この制約を考慮し、タスクが失敗した場合は同一タスクをリトライするのではなく、新規タスクを作成する設計が必要です。タスクサポートの有効化にはサーバー側でタスクストアの構成が必要であり、タスクの作成・状態管理・クリーンアップをタスクストアが一元的に担います。

メモリ肥大化を防ぐイベントストリーム保持戦略──時間ベース・選択的保存の比較

SSEイベントストリームの永続化では、メモリの無制限な増加が運用上の最大のリスクです。MCP C# SDKのドキュメントでは、3つの保持戦略が推奨されています。第一の「セッション終了時削除」は、クライアントがDELETEリクエストでセッションを終了した際にRunSessionHandlerで検知し、関連するストリームデータをすべてクリーンアップする方式です。即座にメモリを解放できる反面、セッション終了後の再接続に対応できません。第二の「時間ベースの有効期限」は、前述のDistributedCacheEventStreamStoreのTTL設定を活用する方式であり、設定だけで自動的に古いデータが削除されるため運用負荷が最も低くなります。第三の「選択的保存」は、最終結果や重要なマイルストーンイベントのみを保存し、中間的なプログレス通知は破棄する方式です。ストレージ使用量を最小限に抑えられますが、デバッグ時に中間状態を追跡できなくなるトレードオフがあります。実務的には、時間ベースの有効期限をデフォルトとして適用し、高トラフィック環境では選択的保存を併用する二段構えの設計が効果的です。

3種NuGetパッケージの選定基準とMCPサーバー／クライアント構築の最短導入手順

MCP C# SDKは3種類のNuGetパッケージとして配布されており、プロジェクトの要件に応じて適切なパッケージを選択する必要があります。最小構成のクライアント実装から、DI統合を活用したフル機能のサーバー構築、ASP.NET CoreベースのHTTPサーバーまで、段階的にパッケージを追加していく設計が可能です。ここでは、各パッケージの責務と選定基準、そして最短で動作するMCPサーバーの導入手順を具体的に示します。

ModelContextProtocol.Coreが最適な場面──依存関係を最小化したい軽量プロジェクト例

ModelContextProtocol.Coreは、MCP C# SDKの最も軽量なパッケージです。MCPクライアントのAPI、低レベルサーバーAPI、およびプロトコルの型定義のみを含み、外部依存を最小限に抑えた構成となっています。このパッケージが最適なのは、依存関係の増加を極力避けたいプロジェクトです。具体的には、既存のDIコンテナを使用しない小規模なコンソールアプリケーションでMCPクライアントを利用する場合や、独自のホスティング基盤を持つプロジェクトでMCPの型定義のみを参照したい場合が該当します。また、ライブラリやフレームワークを開発する際に、利用者に不要な依存を強制しないためにCoreパッケージのみを参照するケースも有効です。ただし、CoreパッケージだけではMicrosoft.Extensions.Hostingとの統合やDI拡張メソッドが使えないため、本格的なサーバー構築やASP.NET Coreアプリケーションへの組み込みには上位パッケージが必要になります。パッケージ選定時は「最小で始めて必要に応じて上位パッケージに移行する」アプローチが推奨されます。

ModelContextProtocolパッケージのDI統合がホスティング設計を効率化する仕組み

ModelContextProtocolパッケージは、Coreパッケージを参照しつつ、Microsoft.Extensions.HostingおよびMicrosoft.Extensions.DependencyInjectionとの統合機能を追加した中間層パッケージです。HTTP サーバー機能が不要なほとんどのプロジェクトにはこのパッケージが最適とされています。DI統合の最大のメリットは、AddMcpServer()拡張メソッドを通じてMCPサーバーのすべてのコンポーネントをDIコンテナに登録できる点です。これにより、ツールクラスのコンストラクタインジェクション、ロギング、構成管理、ヘルスチェックなど、.NETのホスティング基盤が提供する機能をMCPサーバーからシームレスに利用できます。たとえば、MCPツールが外部APIクライアントやデータベースコンテキストに依存している場合、DIコンテナ経由で自動的に注入されるため、テスト時のモック差し替えも容易です。Microsoft.Extensions.Hosting.Abstractionsへの依存があり、バージョンはSDKのリリースに応じて更新されるため、既存プロジェクトとの依存関係の整合性を確認する必要があります。ターゲットフレームワークは.NET 8以上および.NET Standard 2.0が対応しています。

ModelContextProtocol.AspNetCoreによるHTTPサーバー構築で必要な追加設定4項目

ModelContextProtocol.AspNetCoreは、ASP.NET Coreアプリケーション上でHTTPベースのMCPサーバーを構築するためのパッケージです。中間のModelContextProtocolパッケージを参照しているため、DI統合機能もすべて利用可能です。HTTPサーバーとして動作させるには、4つの追加設定が必要です。第一に、AddMcpServer()にチェインする形でWithHttpTransport()を呼び出し、HTTPトランスポートを有効化します。第二に、app.MapMcp()でMCPエンドポイントをASP.NET Coreのルーティングに登録します。第三に、認証が必要な場合はMcpAuthenticationOptionsを構成し、OAuthフローの設定を行います。第四に、SSEストリームの永続化が必要な場合はDistributedCacheEventStreamStoreなどのイベントストアを登録します。注意点として、このパッケージは2026年3月時点でNuGet上のバージョンがまだプレビュー段階にあり、本体のModelContextProtocolパッケージはv1.0が正式リリース済みである一方、AspNetCoreパッケージは安定版のリリーススケジュールを確認の上で導入を判断する必要があります。

dotnet addからMapMcpまで10行で動くMCPサーバーの最小構成コード例

MCP C# SDKでは、わずか数行のコードでHTTPベースのMCPサーバーを起動できます。最小構成の手順は、まずパッケージの追加から始まります。コマンドラインでdotnet add package ModelContextProtocol.AspNetCoreを実行し、次にProgram.csを記述します。WebApplication.CreateBuilder(args)でビルダーを生成し、builder.Services.AddMcpServer().WithHttpTransport().WithToolsFromAssembly()でMCPサーバーの登録とツールの自動検出を設定します。var app = builder.Build()の後、app.MapMcp()でエンドポイントをマッピングし、app.Run()で起動します。ツールの定義は、クラスに[McpServerToolType]属性を、メソッドに[McpServerTool]属性と[Description]属性を付与するだけです。WithToolsFromAssembly()がアセンブリ内のこれらの属性を自動検出して登録するため、個別のツール登録コードは不要です。この最小構成はローカル開発やプロトタイピングに最適であり、ここから認証やイベントストアの設定を段階的に追加していく開発フローが効率的です。

.NET 8以上のターゲットフレームワーク要件と既存プロジェクト移行時の互換性確認手順

MCP C# SDKの対応フレームワークは、.NET 8.0以上および.NET Standard 2.0です。.NET 8は長期サポート（LTS）リリースであり、2026年11月までサポートが継続されるため、新規プロジェクトでの採用に適しています。.NET Standard 2.0もサポートされているため、.NET Frameworkとの互換性が必要なプロジェクトでもCoreパッケージの型定義を参照することは可能です。ただし、AspNetCoreパッケージのHTTPトランスポート機能を利用するにはASP.NET Coreの最新機能が必要であり、実質的に.NET 8以上が要件となります。既存プロジェクトへの移行時に確認すべき互換性項目としては、ターゲットフレームワークのバージョン、既存のDIコンテナとの競合有無、NuGetパッケージの依存ツリーにおけるバージョン衝突、そしてASP.NET Coreミドルウェアパイプラインとの統合順序が挙げられます。特にMicrosoft.Extensions.Caching.AbstractionsやMicrosoft.Extensions.Hosting.Abstractionsなど、SDKが依存するMicrosoft.Extensions系パッケージのバージョンが既存プロジェクトと競合する場合があるため、NuGetの依存ツリーを事前に確認しバージョンを統一する必要があります。

Python・TypeScript SDKとの機能差と.NETプロジェクトでC# SDKを選ぶ判断材料

MCPは言語非依存のプロトコルであり、公式SDKはPython、TypeScript、C#、Java、Go、Rustの6言語で提供されています。どのSDKもJSON-RPCベースの同一プロトコルを実装しているため、異なる言語のサーバーとクライアントを自由に組み合わせることが可能です。しかし、言語ごとのエコシステム成熟度、仕様追従速度、開発体験には差があります。ここでは、他言語SDKとの比較を通じて、.NETプロジェクトでC# SDKを選択する合理的な判断材料を提供します。

公式6言語SDK対応状況の横断比較──機能完成度・仕様追従速度・Stars数の一覧

2026年3月時点のMCP公式SDKの状況を横断的に整理します。

Stars数ではPythonが圧倒的ですが、これはAI・ML分野でPythonが主流であることの反映です。C# SDKはMicrosoftの直接的な関与により、仕様追従速度と.NETエコシステムとの統合品質で差別化されています。SDKの選択はチームの主力言語と既存のインフラ構成に基づいて判断すべきであり、Stars数だけで優劣を判断することは適切ではありません。

TypeScript SDKのv2移行計画とC# SDK v1.0安定版を今選ぶメリット3点

TypeScript SDKは2026年Q1に安定版v2のリリースが予定されており、v1.xは本番環境向けの推奨バージョンとして位置付けられています。v2出荷後もv1.xには最低6ヶ月間のバグ修正とセキュリティアップデートが提供されますが、メジャーバージョン移行に伴う破壊的変更への対応が今後発生します。一方、C# SDK v1.0は2026年3月に正式リリースされたばかりの安定版であり、この時点で選択するメリットは3つあります。第一に、v1.0として安定化されたAPIは今後の破壊的変更リスクが低く、本番環境への投入に適しています。第二に、2025-11-25仕様にフル対応しているため、最新のMCP機能をすべて利用できます。第三に、Microsoftの.NETチームが直接関与しているため、Semantic Kernel、Azure Functions、ASP.NET Coreなどの.NETエコシステムとの統合が最も自然に行えます。TypeScriptチームが移行作業に時間を費やす間に、C# SDKは安定した基盤で開発を進められる点が実務上の大きなアドバンテージです。

Python FastMCPのデコレータ方式とC#属性ベース方式の開発体験の違い

Python SDKでは、FastMCPフレームワークが公式に統合されており、デコレータ方式でMCPツールを定義します。Pythonの@toolのようなデコレータでメソッドをマーキングし、型ヒントとPydanticモデルでスキーマを自動生成する設計です。一方、C# SDKでは属性（Attribute）ベースの方式を採用しています。クラスに[McpServerToolType]、メソッドに[McpServerTool]と[Description]属性を付与する点は、ASP.NET CoreのControllerやMinimal APIに慣れた.NET開発者にとって直感的です。開発体験の違いとして最も顕著なのは、型安全性の扱いです。Pythonの型ヒントは実行時には強制されず、バリデーションはPydanticが担当します。C#ではコンパイル時の型チェックにより、スキーマ不整合がビルドエラーとして検出されます。また、C#のDI統合により、ツールクラスへのサービス注入がコンストラクタインジェクションで自然に行える点は、Python版のFastMCPにはない強みです。ただし、プロトタイピング速度ではPythonのデコレータ方式が優位であり、最小限のコードで素早くサーバーを立ち上げたい場面ではPythonが適しています。

Semantic KernelやAzure Functionsとの親和性でC# SDKが有利になる実務シナリオ

C# SDKが他言語SDKに対して最も明確な優位性を持つのは、Microsoftの AI・クラウドエコシステムとの連携が必要なシナリオです。Semantic Kernelは、Microsoftが開発するAIオーケストレーションフレームワークであり、C#で書かれたMCPサーバーのツールをSemantic Kernelのファンクション呼び出しにシームレスに統合できます。Azure Functionsとの連携では、Microsoft.Azure.Functions.Worker.Extensions.Mcpパッケージが提供されており、サーバーレス環境でMCPツールをホストできます。ただし、このAzure Functions拡張はプレビュー段階にあり、VS Code以外のクライアントからの利用には制約が報告されている点に注意が必要です。また、Microsoft.Extensions.AIパッケージとの統合により、MCPのサンプリングリクエストで提供されたツールをIChatClientのインターフェースに自然にマッピングできます。これらの統合は他言語SDKでは実現困難であり、既存の.NETアプリケーション資産を活かしたAI機能の追加において、C# SDKは最も合理的な選択肢となります。

クロス言語相互運用が保証されるJSON-RPC準拠の仕組みと混在構成の設計例

MCPの根幹であるJSON-RPC 2.0プロトコルにより、すべての公式SDKは完全な相互運用性を持っています。つまり、C#で構築したMCPクライアントからPythonで構築したMCPサーバーに接続する、またはその逆の構成が何の追加作業もなく動作します。この相互運用性を活かした混在構成は、実務的に有効なパターンです。たとえば、データサイエンスチームがPython FastMCPでMLモデル推論ツールをMCPサーバーとして公開し、バックエンドチームがC# SDKで構築したMCPクライアントからそのツールを呼び出すという構成が考えられます。トランスポート層ではstdioがローカル開発向け、HTTP＋SSEが本番環境向けとして位置付けられており、いずれのトランスポートでも言語間の相互運用は保証されます。設計上のポイントは、MCPサーバーとクライアントの言語選定を独立して行えることです。各チームが得意な言語でMCPサーバーを構築し、統一されたMCPプロトコルで接続する「ポリグロットMCP」は、MCPの標準化がもたらす最大の実務的価値の一つです。

既存ASP.NET Coreアプリへの段階的統合とMicrosoft.Extensions.AI連携の実装戦略

MCP C# SDKの価値が最も発揮されるのは、既存の.NETアプリケーション資産をAI機能で拡張するシナリオです。ASP.NET CoreのWebアプリケーションに対して、MCPサーバー機能を最小限のコード変更で追加できる設計がSDKの大きな強みです。ここでは、段階的な統合アプローチとクラウドデプロイの考慮事項、そして継続的なバージョンアップの方針を実務観点で整理します。

AddMcpServer＋WithHttpTransportの2行追加で既存Webアプリに統合する最小手順

既存のASP.NET Coreアプリケーションへの MCP統合は、DIの登録とルーティングの追加という2つのステップだけで実現できます。まず、builder.Services.AddMcpServer().WithHttpTransport()をサービス登録セクションに追加し、MCPサーバーのコンポーネントをDIコンテナに登録します。次に、app.MapMcp()をエンドポイント構成セクションに追加し、MCPプロトコルのHTTPエンドポイントをルーティングパイプラインに組み込みます。この2行の追加により、既存のAPIエンドポイントやRazor Pagesなどの機能に影響を与えることなく、同一アプリケーション内でMCPサーバーが稼働します。既存のサービスクラスやリポジトリパターンで構築されたビジネスロジックは、MCPツールからDIコンテナ経由でそのまま利用可能です。これにより、すでに存在する認証ミドルウェア、ログ基盤、ヘルスチェック機構などの横断的関心事をMCPサーバーが自動的に共有できるため、新規にインフラを構築する必要がありません。

McpServerToolType属性によるツール自動登録で既存サービスを再利用する設計例

MCP C# SDKのツール登録メカニズムは、属性ベースの自動検出を採用しています。WithToolsFromAssembly()メソッドを使用すると、SDKがアセンブリ内のすべてのクラスをスキャンし、[McpServerToolType]属性が付与されたクラスの[McpServerTool]メソッドを自動的にMCPツールとして登録します。この仕組みを活用すれば、既存のサービスクラスをラップするMCPツールクラスを作成するだけで、既存のビジネスロジックをMCPツールとして公開できます。たとえば、既存の在庫管理サービスIInventoryServiceをコンストラクタで受け取り、[McpServerTool]属性を付与したメソッドから呼び出すツールクラスを作成します。[Description]属性でメソッドの説明を付与すると、LLMがツールの用途を理解して適切に呼び出す確率が向上します。各メソッドのパラメータにも[Description]属性を付与することで、パラメータの意味もLLMに伝達できます。この属性ベースの設計により、既存コードベースへの侵食を最小限に抑えながら、段階的にMCPツールを追加していく開発フローが実現します。

Azure Container AppsとApp Serviceへのリモートデプロイで異なる構成上の判断基準

MCP C# SDKで構築したHTTPベースのMCPサーバーをリモート環境にデプロイする際、AzureではContainer AppsとApp Serviceが主要な選択肢になります。判断基準を整理すると、以下の観点が重要です。Azure Container Appsは、コンテナベースのデプロイに対応しており、スケールイン・スケールアウトの自動制御が強力です。MCPサーバーの負荷が変動する場合や、マイクロサービスアーキテクチャの一部として運用する場合に適しています。一方、Azure App ServiceはASP.NET Coreアプリケーションのネイティブサポートが充実しており、既存のCI/CDパイプラインやデプロイスロットをそのまま活用できます。MCPサーバーが既存のWebアプリケーションの一部として統合されている場合は、追加のインフラ変更なしにデプロイ可能です。SSEストリームの永続接続が必要な場合、Container Appsのデフォルトのタイムアウト設定やロードバランサーの挙動を確認する必要があります。いずれの環境でも、MCPサーバーはASP.NET Coreの標準的なWebアプリケーションとして動作するため、環境固有のMCP対応は原則不要です。

GitHub Copilot・Claude Desktop連携を見据えたMCPサーバー公開時の認証設計5原則

MCPサーバーを外部のAIクライアントに公開する際、認証設計は最も慎重に扱うべき要素です。GitHub CopilotやClaude Desktopなどの主要なMCPクライアントとの連携を想定した認証設計の5原則を以下に整理します。第一に、MCP認可仕様に準拠したOAuthフローを実装し、独自の認証方式を避けることです。標準準拠により、任意のMCPクライアントからの接続を受け付けられます。第二に、CIMDによるクライアントID管理を採用し、DCRはフォールバック用途に限定することです。第三に、incremental scope consentを活用し、初回接続時の権限要求を最小限に抑えることで、ユーザーの離脱を防ぎます。第四に、URL mode elicitationで機密情報の入力をクライアント外で処理し、LLMコンテキストへの漏洩を防止することです。第五に、セッションIDのみに依存した状態管理を避け、MCP認可で取得した認証情報（JWTのsubクレームなど）に基づいてユーザーを識別することです。MCP仕様のセキュリティベストプラクティスでは、セッションIDだけにユーザー状態を紐付ける設計は明確に禁止されています。

v1.0導入後のバージョンアップ方針──v1.1.0の差分確認と段階的移行で避ける失敗例

MCP C# SDKはv1.0リリース後も活発に開発が続いており、NuGet上にはv1.1.0が公開されています。バージョンアップ方針の策定にあたっては、セマンティックバージョニングの原則を踏まえ、マイナーバージョンの更新は後方互換性が維持される前提で計画を立てます。v1.0からv1.1.0への更新では、新機能の追加とバグ修正が中心であり、既存のAPIに破壊的変更は含まれていません。ただし、移行時に避けるべき失敗パターンが3つあります。第一は、複数のMCP関連パッケージ（Core、本体、AspNetCore）のバージョンを不揃いのまま更新するケースです。依存関係の整合性が崩れ、ランタイムエラーの原因になります。第二は、実験機能（MCPEXP001）のAPIを本番コードで広範に使用しているケースです。実験機能は将来のバージョンで変更・削除される可能性があるため、本番利用は限定的にとどめるべきです。第三は、テスト環境でのバージョンアップ検証を省略するケースです。MCPサーバーの挙動は認可フローやSSEストリームなど外部通信に依存する部分が多いため、統合テストでの検証が不可欠です。バージョンアップは「テスト環境で全機能を検証→ステージング環境で負荷テスト→本番環境に段階ロールアウト」の3フェーズで行うことが推奨されます。