MCP SDK Tierシステムとは — SDKを選ぶ前に確認すべき基準

MCP SDK Tierシステムとは何か

MCP SDK Tierシステムは、公式のModel Context Protocol SDKを機能の完成度・仕様追従の速さ・保守コミットメントの3軸でTier 1〜3に分類する制度です。MCPの仕様策定を担うSDK Working Groupが運用し、SDKごとのIssue対応期限やConformance Tests(適合性テスト)の合格率といった数値基準で機械的に判定します。運用は2026年2月23日に正式公開され、それ以前は各SDKの成熟度を示す公式な物差しがありませんでした。

10言語の公式SDKのうち、どれが本番導入に足るか・どれがまだ実験段階かを見分けるのが本記事の目的です。MCPそのものの仕組みはMCP実用ガイド、個別言語の実装手順はJavaでMCPサーバーを書く手順、Tier 3の3言語の実態はMCPのSwift・PHP・Kotlin SDKは今どこまで使えるかで扱っています。

Tierを分ける8つの基準

Tierは次の8項目で判定されます。うち5項目は数値で表せるため下表にまとめ、残り3項目は表の下で説明します。数値が厳しいほど上位のTierです。

Conformance Testsは、公式のconformanceリポジトリが提供する自動テストスイートで、プロトコルメッセージのやり取りが仕様どおりかを検証します。実験的機能や、SDKが未対応と宣言した仕様バージョンのテストは合格率の計算から除外されるため、「対応する範囲では仕様どおりに動く」ことを保証する仕組みです。「安定版」の定義も明確で、1.0.0以降かつ-alphaや-betaのようなプレリリース識別子が付いていないバージョンを指します。

残り3項目は数値化しにくいため、表とは別に説明します。ドキュメントはTier 1が「全機能に実例付きの網羅的な説明」、Tier 2が「中核機能をカバーする基本的な説明」を要求され、Tier 3には最低ラインがありません。ロードマップは、Tier 1は公開ロードマップが必須、Tier 2はTier 1への到達計画かTier 2に留まる理由の説明が必須、Tier 3には要件がありません。依存ポリシーは、Tier 1・2がともに「公開された更新ポリシー」を必須とし、Tier 3には要件がありません。

Conformance Testsが数えている範囲

合格率の分母は「無条件にすべてのテスト」ではありません。次の4種類は集計から除外されます。①SDKが対応を宣言していない仕様バージョン向けのテスト、②pending・skippedとマークされたテスト、③実験的機能向けのテスト、④SDKが互換性維持を謳っていない限りは、旧仕様との後方互換性を検証するレガシーテスト。加えて、conformanceリポジトリ側でdisputedラベルが付いたテストは、判定に決着が付くまで集計対象から外れます。

この除外ルールがあるおかげで、「まだ対応していない新機能のテストで落ち続けて不当に低いスコアになる」事態を避けられます。裏を返すと、合格率100%という数字は「実装した範囲では仕様どおり」を意味し、「仕様全体を実装済み」を保証するものではありません。実装範囲の広さそのものは、各SDKのドキュメントやリリースノートで別途確認する必要があります。

Issue対応の速さをどう測っているか

Issue対応期限(Tier 1は2営業日、Tier 2は1か月)を正確に計測するため、SDK Working GroupはすべてのSDKリポジトリで共通のラベル運用を要求しています。ラベルは3種類に分かれます。

• Type(1つ選ぶ): bug(不具合)・enhancement(機能要望)・question(質問)。GitHubのネイティブIssue Typeを使っている場合はラベル不要
• Status(1つ選ぶ): needs confirmation・needs repro・ready for work・good first issue・help wanted
• Priority(対応が必要な場合のみ): P0(致命的)・P1(多数のユーザーに影響する重大な不具合)・P2(中程度・価値ある要望)・P3(あれば嬉しい程度)

「一次対応」が指すのはラベル付けとIssueの有効性判断であり、Issue自体の解決ではありません。一方、Tier 1の「7日以内」・Tier 2の「2週間以内」という期限が課されるのはP0ラベルが付いた重大バグに限られます。P0の定義はCVSSスコア7.0以上(High〜Critical)のセキュリティ脆弱性、または接続確立・メッセージ交換・ツール呼び出しのようなMCPの基本操作を止める障害です。

Tierは降格もする

Tierは一方通行の格付けではありません。最新の安定版リリースでConformance Testsが4週間連続で落ち続けると、Tier 1はテストが1件でも失敗した時点でTier 2へ、Tier 2は失敗率が20%を超えた時点でTier 3へ降格します。Issue対応が2か月間放置された場合も降格の対象です。逆にTierを上げたいSDKの保守者は、自己評価→GitHub Issueでの申請→Conformance Tests合格→SDK Working Groupの承認、という4段階の手順を踏みます。

誰がTierを決めているか

Tierの運用主体はSDK Working Groupという専門のワーキンググループです。

担当範囲: Tierの運用(格上げ・格下げの審査、公開済みTierの維持)、公式SDK一覧の管理(新規追加・廃止の審査)、Tier 1向けのリリース計画調整、SDK間の設計パターンの共通化、Conformance Testingプロジェクトとの連携の5つに限定されています。個別SDKの日々のIssue対応・リリース作業・API設計は、そのSDKの保守者の裁量に委ねられており、Working Groupが直接手を出す領域ではありません。

決定権限の階層: Tierの格上げ・格下げはWorking Groupの合意で決まります。Tierの判定基準そのものを変える場合や、新しい言語を公式SDK一覧に加える・退役させる場合は、Working Groupの合意に加えてCore Maintainersの承認が追加で必要です。この権限の分け方が、「Tierという横断的な格付け」と「言語ごとの実装の自由度」を両立させています。

10言語の現在地

2026-07-28版の公式SDK一覧にもとづく、10言語の現在のTierとパッケージ最新版です。

各言語のパッケージレジストリ(npm・PyPI・NuGet・Maven Central・crates.io・RubyGems・Swift Package Manager・Packagist)で確認した値で、バージョンは日々更新されるため実装直前に再確認してください。

この一覧には明確な境界線が見えます。Tier 1(5言語)とTier 2(2言語)をあわせた7言語はすべて安定版(1.0以降)に達しているのに対し、Tier 3の3言語はいずれも1.0未満です。これはTierの数字が恣意的な評価ではなく、「安定版リリース」という機械的に確認できる基準と一致していることを裏付けています。Tierのバッジを見なくても、パッケージのバージョン番号だけである程度の成熟度を推測できるということです。

SDKを選ぶときの判断基準

Tierの数字を実装判断に落とし込むなら、次の3つを順に確認するのが実務的です。

1. 本番の可用性要求: 24時間稼働のサービスに組み込むなら、重大バグが7日以内に直るTier 1が安心材料になります。社内ツールや検証目的ならTier 2・3でも実用上の支障は小さいことが多いです。
2. 必要な言語・プラットフォーム: Apple製アプリ、既存のPHP/Symfony資産、Kotlin Multiplatformのような制約がある場合、Tierより言語の選択肢のほうが優先されます。この場合はTier 3でも選ばざるを得ません。
3. 最新仕様機能への依存度: 新しいプロトコル機能(タスクやMCP Appsのような拡張)をすぐ使いたいなら、6か月以内の追従が約束されるTier 2以上を選びます。Tier 3は対応期限のコミットがないため、機能追加を待つ前提の設計は避けたほうが安全です。

まとめ

MCP SDK Tierシステムは、Conformance Tests合格率・仕様追従期限・Issue対応速度・重大バグ解消・安定版の有無・ドキュメント・ロードマップ・依存ポリシーという8つの基準でSDKを3段階に分類する制度です。現在地は、TypeScript・Python・C#・Go・RustがTier 1、Java・RubyがTier 2、Swift・PHP・KotlinがTier 3で、Tier 1・2をあわせた7言語はすべて安定版(1.0以降)に達している一方、Tier 3の3言語はまだ届いていません。選定では、Tierのバッジを本番可用性要求・必要な言語プラットフォーム・仕様追従の必要性という3つの軸に翻訳して判断すると、実装後の手戻りを避けやすくなります。