MCPの設計原則8箇条を読み解く
MCPの仕様変更はConvergence over choiceなど8つの設計原則で評価される。SEPが通る/通らない理由をこの原則から読み解く。
提案が原則とぶつかると審査で何が起きるか
MCPの設計原則は、プロトコルへの提案を評価し、トレードオフを判断し、仕様を進化させるときの指針です。プロジェクトを運営してきた経験から導かれたものです。SEP(Specification Enhancement Proposal、仕様拡張提案)や拡張機能(Extensions)を書くコミュニティ向けに公開されています。
SEPの手順ページには、採択の見込みに直結する一文があります。コアメンテナーの優先事項や設計原則と食い違う提案は、審査で遅れたり、追加の摩擦に遭ったりしやすい、という注意書きです。つまり原則は、却下の条件表ではなく、審査の空気を読むための共通言語と読めます。
8つの原則は「A over B」の対句でできている
| 原則 | 優先するもの |
|---|---|
| Convergence over choice | 優先するもの複数の解決策の並立より、単一の設計 |
| Composability over specificity | 優先するもの専用機能の追加より、基本要素の組み合わせ |
| Interoperability over optimization | 優先するもの最適化より、全参加者での動作 |
| Stability over velocity | 優先するもの開発速度より、後方互換性の維持 |
| Capability over compensation | 優先するもの恒久的な回避策より、モデルの成長 |
| Demonstration over deliberation | 優先するもの議論より、動く実装 |
| Pragmatism over purity | 優先するもの理論上の美しさより、実務での使いやすさ |
| Standardization over innovation | 優先するもの新発明より、実績のあるパターン |
Bを完全に否定する言い方ではありません。迷ったときにどちらへ傾けるかを示す構造です。
そもそもSEPが要る変更か
原則を当てはめる前に、SEPの対象かどうかを分ける必要があります。SEPが要るのは、新しい機能やプロトコルの変更、後方互換性のない変更、ガバナンスや手続きの変更、複数の妥当な解があって議論になりそうな話題です。バグ修正、誤字の訂正、ドキュメントの明確化、既存機能への例の追加、挙動を変えない軽微なスキーマ修正は、SEPを使わず通常のGitHubのプルリクエストで足ります。
SEPに書く項目は、概要、動機、仕様、根拠、後方互換性、参照実装、セキュリティ上の含意です。動機が弱いSEPは、その時点で却下されることがあります。ここで書く根拠には、検討した別案とコミュニティの合意の証拠が含まれ、原則の言葉で自分の案を説明する場所になります。
SEPが通るまでの道筋
原則を知っていても、提案がどの順で審査されるかを知らないと使いどころがつかめません。SEPの手順ページは、次の流れを定めています。
SEPが仕様に入るまで
- 1
関係するグループと先に議論する
提案者は、PRを開く前に該当のワーキンググループ(WG)かインタレストグループ(IG)とDiscordで話し合います。PRの説明にその議論へのリンクが要ります。リンクのないSEPは受理されません。
- 2
スポンサーを見つける
コアメンテナーかメンテナーに声をかけ、スポンサーになってもらいます。2週間返事がなければ
#generalで尋ねる、と書かれています。 - 3
正式レビュー
スポンサーが状態を
in-reviewにすると、コアメンテナーによる審査に入ります。審査は2週間ごとの会議で行われます。 - 4
採択後に実装とテストを仕上げる
採択されても終わりではありません。参照実装を完成させ、観測できるプロトコル挙動を変える提案では適合性テストも必要です。それがそろって
finalになります。
スポンサーが半年見つからないSEPはdormantになります。これはrejectedとは別の状態です。却下ではなく「誰も推してくれなかった」という意味で、関心や用途が変われば、スポンサーを見つけて復活させられます。
コアメンテナーの優先事項は、おおむねプロジェクトのロードマップに反映されていると書かれています。原則だけでなく、提案がその時点の優先事項と重なっているかも、審査での扱いを左右します。SEP自体も、仕様リポジトリのseps/ディレクトリにMarkdownファイルとして置かれ、その改訂履歴が提案の記録になります。
採択の条件は3つです。動くプロトタイプがあること、MCPのエコシステムに明確な利点があること、コミュニティの支持と合意があること。8原則のうち、Demonstration over deliberationは1つ目の条件に直結しています。
原則ごとの読み方
Convergence over choice — 同じ課題の解は1つにする
エコシステムを断片化させる複数のアプローチを並立させず、事前に難しい決定を引き受けて、1本の経路に絞ります。拡張機能は収束を試す場で、仕様本体は収束をコミットする場、と原則ページは書いています。
一度本体に入れた解決策を、後から別の解決策へ差し替えることは、Stability over velocityの制約で難しくなります。本体に入れる前の収束が重く見られるのは、そのためです。
Composability over specificity — 機能を足す前に組み合わせを疑う
MCPが提供するのはresources・tools・promptsという基礎的なプリミティブです。既存の要素から組み立てられるユースケースのために、新しいプロトコル機能は足しません。「なぜMCPはこの機能を直接サポートしないのか」と聞かれたら、答えはたいてい「今ある部品で作れるから」です。
MCP AppsやMCP Tasksのような拡張機能は、そうして出てきたパターンを取り込んだものです。Tasksの移行についてはMCP Tasks拡張への移行で扱っています。
Interoperability over optimization — 全員が高機能とは限らない
MCPはクライアント・サーバー・モデルの能力がばらばらな環境で動きます。全参加者が同じ水準のときだけ成り立つ機能より、段階的に劣化しても動く機能が選ばれます。具体化したものが能力交渉(capability negotiation)で、参加者が対応範囲を宣言し、プロトコルがそれに合わせて振る舞います。
サーバーを作る側に引き直すと、宣言できない相手や機能の乏しいクライアントでも壊れない土台を先に作り、高機能なクライアント向けの振る舞いはその上に載せる順序になります。特定の実装だけが持つ機能を前提にすると、それ以外が接続した瞬間に動かなくなります。
Stability over velocity — 追加は簡単で、削除はほぼ不可能
MCPほど広く使われるプロトコルに足すのは簡単ですが、取り除くのはほぼ不可能です。追加はすべて恒久的な約束で、クライアント実装者の負担になります。原則ページの言い方では、「今日のノー」は扉を開けたままにし、「今日のイエス」は扉を永久に閉じます。
素早い出荷に慣れた人には歯がゆいペースですが、持続可能な標準には持続可能な意思決定が要る、という立場です。最適化の単位は四半期ではなく数十年とされています。削除の側の手順はMCPの機能ライフサイクルポリシーにあり、非推奨の機能は原則として最低12か月、削除の対象になりません。
Capability over compensation — モデルの成長を待つ
モデルはプロトコルより速く良くなります。一時的な限界を避けるための恒久的な構造は、限界が消えても複雑さだけが残るので、足しません。
ただし、弱いモデルが頼り、強いモデルは無視できる任意のコンテキストは、コストがかからないので許されます。問題になるのは、提案の主な存在理由が「今のモデルはこれがないと苦労する」である場合です。そのときは、モデルが先に必要性を乗り越えないかを問います。補完ロジックを入れる前に、その必要性が先に消えないかを問うこと。それが原則の核です。
Demonstration over deliberation — 議論より動くもの
仮説の議論より、実際の利用から得られる証拠を優先します。プロトタイプを作り、試し、見せることが、委員会形式の設計より推奨されています。「実装は、議論では見えないものを明らかにする」という考え方です。
SEPの手順ページでは、これがより具体的です。認められるプロトタイプは、公式SDKの動くブランチ、単体の概念実証、挙動を示す統合テスト、参照サーバーやクライアントなどです。疑似コードだけの提案や、コードのない設計文書は足りません。レビューする人が実行できるよう、セットアップ手順を添えることも求められています。
Pragmatism over purity — 理論より実務
採用のされやすさと使いやすさのために、実務的なトレードオフをします。「正しい」設計が実装者の摩擦になるなら、「十分に良い」設計のほうがエコシステムのためになるのでは、と考えます。ある程度の不整合や、歴史的な経緯による例外、後から見れば別の選択もあり得た決定は、受け入れるということです。
Stability over velocityが「変えない」ことを求めるのに対し、Pragmatismが向き合うのは、変えると決めたときの変え方のほうです。
Standardization over innovation — 実績のあるパターンだけを標準にする
すでに価値が証明されたパターンを標準化します。新しいパラダイムを発明して普及を願うのではなく、複数の実装で機能している慣行を見つけて成文化する立場です。新しいパターンを試す場としては拡張機能が勧められ、それが標準化への道筋になります。
Convergenceが「解決策を1つに絞る」という結果を求めるのに対し、Standardizationは「いつ絞るか」という時機を定めます。実績が出る前の案を急いで仕様に入れないという点で、2つは同じ慎重さを別の軸から支えています。
拡張機能で試してから本体へ
Convergence、Composability、Standardizationの3原則は、拡張機能(Extensions)という経路で実際の運用になっています。拡張機能の概要ページが、仕様本体との違いを示しています。
拡張機能と仕様本体の違い
拡張機能
仕様本体とは独立して進化し、更新は拡張のリポジトリのメンテナーが管理します。更新のたびにコアメンテナーの審査は要りません。常に既定で無効で、開発者が明示的に有効にします。SDKが対応するかどうかは各SDKのメンテナーが決めます。
仕様本体
追加は恒久的な約束になります。SEPの審査はコアメンテナーが担い、最終的な採否の権限も持ちます。
公式の拡張には、認可まわりの拡張、MCP Apps、MCP Tasks、Skills over MCPがあります。実験段階の拡張は、WGかIGに紐づけたうえでexperimental-ext-という接頭辞のリポジトリで育てます。公式に昇格させるときは、通常のSEPの手順(Extensions Track)を通ります。
拡張機能のSEPは、参照実装を公式SDKで少なくとも1つ作ることが、レビューに入る前の条件です。「議論の前に動くもの」という原則が、手順としてここにも出ています。
提案を出す前の自己点検
原則は、提案者が自分に問う形にすると使いやすくなります。次の4つは、原則ページとSEPの手順ページの記述を問いに引き直したものです。
SEPを書く前の4つの問い
今ある部品で作れないか
resources・tools・promptsの組み合わせで実現できるなら、新しいプロトコル機能の根拠が弱くなります(Composability)。
能力が低い相手でも動くか
高機能なクライアントだけを前提にしていないかを見ます(Interoperability)。
動くものがあるか
疑似コードではなく、レビューする人が実行できるプロトタイプが要ります(Demonstration)。
モデルが成長したら要らなくなるか
今のモデルの弱さを埋めるためだけの構造なら、恒久的な仕様に向きません(Capability)。
まとめ
8つの原則は、足すことへの慎重さを軸にした共通言語で、特にStabilityの「いったん入れたら消せない」が全体の重しになっています。提案を書くなら、まず原則の4問で自分の案を点検し、動くプロトタイプと関係グループでの議論の記録をそろえてからSEPを出すのが、審査の流れに沿う順序です。