MCPの設計原則8箇条を読み解く

MCPの設計原則とは何か

MCPの設計原則は、プロトコルへの提案を評価し、トレードオフを判断し、仕様を進化させる際にCore Maintainerが用いる8つの指針です。プロジェクトを実際に運営してきた経験から導かれたもので、SEP(Specification Enhancement Proposal)や拡張機能(Extensions)を書くコミュニティ向けのガイダンスとして公開されています。SEPの審査で「なぜこの提案は通り、あの提案は通らなかったのか」を説明する共通言語がこの8箇条です。

8つの原則を一覧で見る

残り3原則(Demonstration over deliberation / Pragmatism over purity / Standardization over innovation)は後段で個別に扱います。原則名はすべて「A over B」という対句の形を取り、Bを完全に否定するのではなく、優先順位の置き方を示す構造になっています。表の5原則のうちConvergence・Composability・Stabilityの3つは「何を足すか」より「何を足さないか」に軸足があります。

選択肢を増やさない — Convergence over choice

MCPでは、同じ課題に対して複数の解決策を並立させません。エコシステムを断片化させる複数アプローチをサポートするより、単一のよく設計された経路を選び、事前に難しい決定を引き受けることで、より一貫したプロトコルを届けるという考え方です。この収束のテストの場が拡張機能(Extensions)であり、収束が確定してはじめて仕様本体にコミットされます。つまり、新しい発想はまず仕様の外(拡張)で複数試され、勝ち残った1つだけが本体に取り込まれる二段構えです。仕様に一度取り込まれた解決策を後から別解決策に差し替えるのは、Stability over velocityの制約で事実上できません。だからこそ、本体に入れる前の収束の精度が重視されます。

機能を足す前に組み合わせを疑う — Composability over specificity

MCPが提供するのはresources・tools・promptsという基礎的なプリミティブです。既存の組み合わせで構築できるユースケースのために、新しいプロトコル機能を追加することはしません。「なぜMCPはこの機能を直接サポートしないのか」という問いへの答えは、たいてい「既存の要素から組み立てられるから」です。MCP AppsやMCP Tasksのような拡張機能は、この原則が実際にパターンとして表れたものです。

全参加者で動くことを優先する — Interoperability over optimization

MCPは、能力の異なるクライアント・サーバー・モデルをまたいで動作します。全参加者が同等に高機能な場合にしか機能しない仕様より、段階的に劣化しながらも動く機能を優先します。この考え方を具体化しているのがcapability negotiation(能力交渉)です。参加者が自分の対応範囲を宣言し、プロトコル側がそれに応じて振る舞いを変える仕組みで、最適化より相互運用性を選んだことがこの仕組みに表れています。サーバー実装者にとっての含意は、最新機能に対応した高機能なクライアントだけを想定して設計を固めないことです。対応範囲を宣言できない相手や、限られた機能しか持たないクライアントとつながったときにも壊れずに動く土台を先に用意し、そのうえで高機能なクライアント向けの振る舞いを上乗せする順序で設計すると、この原則に沿った形になります。逆に、特定の実装だけが持つ高度な機能を前提にプロトコルを設計してしまうと、それ以外の参加者が接続した瞬間に動作が破綻するリスクを抱え込むことになります。

追加は簡単、削除はほぼ不可能 — Stability over velocity

MCPほど広く採用されたプロトコルへの機能追加は簡単ですが、そこから何かを削除するのはほぼ不可能です。追加は常に恒久的な約束であり、クライアント実装者にとってのコストになります。「今日のノー」は扉を開けたままにしますが、「今日のイエス」は永遠にそれを閉じます。この原則のもとでは、迅速な出荷に慣れた貢献者にとってMCPのペースはもどかしく感じられるかもしれませんが、持続可能な標準には持続可能な意思決定が要るという立場です。四半期ではなく数十年単位で最適化するという言い方で説明されています。MCPの機能ライフサイクルポリシーが定める3状態と12か月ルールは、この原則を運用の側から支えています。

モデルの成長を前提に待つ — Capability over compensation

モデルはプロトコルより速く改善します。一時的とみられる制約を回避するための恒久的な構造を、MCPは追加しません。制約が消えても複雑さだけが残るからです。これは今日の現実を無視してよいという意味ではありません。弱いモデルが頼り、強いモデルは無視できる任意のコンテキストはコストがかからないため許容されます。ただし、ある提案が主に「今のモデルがそれなしでは苦労するから」存在するなら、コストを払う前にモデルがその必要性を成長で乗り越えるかどうかを問うことになります。実装者がここから学べるのは、モデルの弱さを前提にした複雑な補完ロジックを仕様に持ち込む前に、いったん立ち止まって同じ目的をプロンプトやコンテキストの与え方の工夫で達成できないか検討することです。ある機能がプロトコルレベルの恒久的な変更を本当に必要としているのか、それともモデル側の改善によって数か月のうちに自然に解消される暫定的な課題にすぎないのかを見極める姿勢が、この原則が実装者に求めているものだと言えます。MCP Samplingが2027年までの猶予を経て非推奨に向かう経緯は、この原則が実際に働いた例と重なります。

議論より動くものを見る — Demonstration over deliberation

MCPは理論的な議論より、動く実装を重視します。提案を評価する際、仮説の議論より実際の利用から得られる証拠を優先します。プロトタイプを作り、実験し、実証することを、委員会形式で設計することより推奨します。実装は議論では見えないものを明らかにするという立場です。Demonstration over deliberationは、SEP(Specification Enhancement Proposal)の審査で疑似コードだけの提案が認められないという運用基準そのものです。

理論的な正しさより実務での使いやすさ — Pragmatism over purity

MCPは採用と使いやすさのために実務的なトレードオフを行います。理論的なエレガンスを、実世界での有用性を犠牲にしてまで追求しません。「正しい」設計が実装者にとって摩擦を生むなら、「十分に良い」設計のほうがエコシステムに資するのではないかを検討します。これはある程度の不整合や、歴史的な経緯による例外、後から振り返れば違う選択もあり得た決定を受け入れることを意味します。Stability over velocityが「変えない」ことを求めるのに対し、Pragmatismが問うのは「変えるとしてもどう変えるか」です。

実績のあるパターンだけを標準化する — Standardization over innovation

MCPは、すでに価値が証明されたパターンを標準化します。新しいパラダイムを発明してその採用に期待するのではなく、複数の実装で機能している慣行を見つけて成文化する立場です。新しいパターンを試す場としては拡張機能の利用が推奨されており、それが最終的に標準化につながる道筋になっています。この原則はConvergence over choiceと対になっています。Convergenceが「1つの解決策に収束させる」という結果を求めるのに対し、Standardizationは「どのタイミングで収束させるか」というタイミングを規定します。実績のないアイデアを仕様に急いで取り込まないという点で、両者は同じ慎重さを別の軸から支えています。

この8箇条から何が読み取れるか

8原則を並べると、共通する構図が見えます。Convergence・Composability・Stability・Standardizationの4つは「足すことへの抑制」を異なる角度から支える原則で、Interoperability・Capability・Demonstration・Pragmatismの4つは「足すときの判断材料」を提供する原則です。MCPの設計文化は、追加する側にほぼすべての説明責任を負わせる仕組みだと言えます。何かを追加したい提案者は、単に技術的に実現可能だと示すだけでなく、収束済みであること・組み合わせで代替できないこと・全参加者で動くこと・実装で実証済みであることの4つを、拡張機能というワンクッションを経て証明する必要があります。

SEPの却下理由の多くは、この8箇条のどれか1つに照らして「今はまだ早い」「既存の組み合わせで足りる」と判断された結果です。裏を返せば、提案する側がこの原則を先に自己点検しておくことが、Core Maintainerの隔週レビューを通過する近道になります。

まとめ

MCPサーバーやクライアントの実装で新機能を提案したいなら、コードを書く前にこの8箇条に自分の提案を当てはめてみることが実務上の近道です。既存のresources/tools/promptsの組み合わせで代替できないか、まず拡張機能として試せないか、後方互換性を壊さずに実現できないかを自問するだけで、SEPの審査が求める視点の多くをカバーできます。原則そのものは/community/design-principlesで随時更新されるため、SEPを書く前に最新版を確認する価値があります。