MCPのSEP(仕様変更提案)プロセスの全体像
MCP仕様への変更提案はSEPという形式で提出します。事前議論、スポンサー選定、Core Maintainerの隔週レビュー、適合テストまでの全ステップをたどります。
SEPとは何か — PRベースのワークフローとの違い
SEP(Specification Enhancement Proposal)は、MCP仕様への変更を提案するための設計文書です。新機能の技術仕様に加えて、その機能が必要な理由(rationale)も書きます。提出者はコミュニティ内の合意形成に責任を持ち、反対意見も含めて議論の経緯を文書化します。
SEPは仕様リポジトリのseps/ディレクトリにMarkdownファイルとして置かれ、Gitの改訂履歴が提案の歴史的記録になります。この形式は最初からあったわけではありません。以前はGitHub Issuesで提案を管理しており、内容がissue・外部文書・PRに散らばって、レビューも保管もしにくいという問題がありました。SEP-1850(PR-Based SEP Workflow)がこれをファイルベースに切り替え、SEP番号をそれを導入するPRの番号と一致させました。
すべての変更がSEPを必要とするわけではありません。バグ修正・誤字訂正・ドキュメントの明確化・既存機能への使用例追加・挙動を変えないスキーマの微修正は、通常のGitHub Pull Requestで足ります。SEPが必要になるのは次の4パターンです。
- 新機能やプロトコル変更(新しいAPIメソッド、メッセージ形式の変更、相互運用の標準)
- 後方互換性を壊す変更
- ガバナンスやプロセスの変更
- 複数の妥当な解決策があり得て、議論を呼びやすい複雑な論点
境界が曖昧なときは、着手前にDiscordで質問するよう案内されています。小さな変更に重い手続きを課さず、大きな変更を軽いPRで済ませない、という線引きです。
SEPには4種類ある
SEPは目的に応じて4つのタイプに分かれます。
| タイプ | 用途 |
|---|---|
| Standards Track | 用途プロトコル本体の新機能・実装、または外部の相互運用標準 |
| Informational | 用途新機能を提案せず、設計上の論点やガイドラインを共有 |
| Process | 用途MCPを取り巻くプロセス自体の記述・変更(このガイドライン自体もProcess SEP) |
| Extensions Track | 用途プロトコル拡張の記述。レビューと承認はStandards Trackと同じ流れ |
Extensions Trackの位置づけは、MCPの設計原則から説明がつきます。設計原則には「Standardization over innovation」があり、すでに定着したパターンを仕様にするという立場です。新しいパターンの実験場として拡張を使うことも明記されています。さらに「Convergence over choice」の項では、拡張は収束が試される場所で、仕様は収束を確定させる場所と書かれています。
拡張側の手順は拡張の概要ページにあります。Extensions TrackのSEPは、公式SDKに参照実装を少なくとも1つ作ってからでないとレビューに進めません。拡張には、対応するWorking GroupかInterest Groupも必要です。SEPのガイドラインでは参照実装が必要になるのはFinalの前(承認前は未完成でも可)なので、Extensions Trackだけ着手時点の要求が重い形です。
SEPはどのステータスを辿るか
SEPには8つのステータスがあり、提出から確定まで一方向に近い形で進みます。
- draft — スポンサーが付き、非公式レビュー中
- in-review — 正式なCore Maintainerレビューの準備が整った状態
- accepted — 承認済み、実装と適合テストの完了待ち
- rejected — Core Maintainerによって却下
- withdrawn — 提出者自身が取り下げ
- final — 実装と適合テストが完了し確定
- superseded — 新しいSEPに置き換えられた
- dormant — 6か月以内にスポンサーが見つからず休眠
dormantとrejectedは意味が異なります。
dormantとrejectedの違い
dormant
スポンサーが見つからないまま6か月が過ぎた状態です。アイデアが否定されたわけではなく、新しいコミュニティの関心やユースケースが生まれたときに、スポンサーを見つけてPRを開き直せば復活できます。
rejected
レビューを経てCore Maintainerが却下した状態です。再提出や競合SEPの道は残りますが、指摘された懸念への対応が前提になります。
SEPの索引ページには、ステータスの定義表が別に載っています。そこでのaccepted・finalの説明は「参照実装を待つ」「参照実装が完了」という書き方で、適合テストに触れていません。適合テストの要件は後からSEP-2484で加わったためで、現行のSEPガイドラインの表と食い違って見えるのはこのズレが原因です。実際の判断にはガイドライン側を使います。
提出からFinalまでの実務フロー
SEPが仕様に入るまでの6ステップ
- 1
関連するグループで先に議論する
提出前の議論は必須です。該当するWorking GroupかInterest GroupでDiscordの議論を行います。そのリンク(Discordスレッド・会議メモ・GitHub Discussionのいずれか)はPR説明文に載せます。リンクのないSEPは受理されません。該当グループがなければ、GitHub Discussionsか
#generalで話を始めます。 - 2
仮番号のファイルでPRを出す
0000-your-feature-title.mdという名前で書き、seps/に追加するPRを作ります。リポジトリがPRを受け付けるのはコラボレーターだけです。 - 3
PR番号に合わせて改名する
PRが作成された時点でそのPR番号がSEP番号になります。PR #1850なら
1850-your-feature-title.mdで、ヘッダーも合わせて更新します。 - 4
スポンサーを探す
提案領域に近いCore MaintainerかMaintainerを1〜2名だけタグ付けし、関連するDiscordチャンネルでPRを共有します。2週間反応がなければ
#generalで呼びかけます。全員へのタグ付けは避けます。スポンサーが決まると自身をPRにアサインし、ステータスをdraftにします。 - 5
非公式レビューから正式レビューへ
スポンサーがコメントで変更を依頼し、提出者が応じます。準備が整うと、スポンサーが議論の記録がPRに載っていることを確かめてから
in-reviewに上げます。以降は2週間ごとのCore Maintainer会議で審議されます。 - 6
承認後に仕様変更を足してFinalへ
承認(
accepted)後、提出者がスキーマ変更・仕様の本文・changelogエントリを同じPRに足し、参照実装を仕上げます。観測可能な挙動を伴うStandards Trackでは適合テストのマージも必要です。条件が揃うとスポンサーがfinalにし、PRがマージされます。マージされたSEPは索引に載り、modelcontextprotocol.io/seps/<番号>で読めます。
ステータスを書き換える権限はスポンサー側にあります。提出者は自分でstatusフィールドを触らず、スポンサーに依頼します。更新はSEPのMarkdownファイル(正式な記録)とPRのラベルの両方に反映されます。SDK側の実装はfinalの条件に含まれません。
Working Groupが先に動く理由
事前議論の要件は、Working GroupとInterest Groupの役割分担から来ています。Interest Groupは解決すべき問題を見つけて要件を集める場で、Working GroupはSEPや参照実装という成果物を作る場です。典型的な流れは、Interest Groupで問題を議論し、解く価値を確かめ、Working Groupを作るか加わってSEPを出し、実装する、という順序です。
Working Groupのリードは、グループの範囲に入るSEPをトリアージする役目も持ちます。ロードマップに合わないSEPは、理由を文書に残したうえで閉じることができ、提出者はCore Maintainerに異議を申し立てられます。Core Maintainerまで上がる前に、グループの段階で止まる経路があるわけです。
Core Maintainerの優先事項や設計原則との整合も、通りやすさを左右します。優先度の外にある提案や設計原則と衝突する提案は、審査で遅れたり摩擦が増えたりしやすいと明記されています。優先事項は、ロードマップに反映されているのが通常です。
SEPの変遷 — プロセス自体もProcess SEPで変わってきた
SEPのプロセスは、Process SEPによって繰り返し書き換えられてきました。索引から拾える節目は次のとおりです。
SEPプロセスを変えたProcess SEP
- 2025-07-08SEP-932 ガバナンスの制定
Model Context Protocol Governanceとして、役割の階層が定められました。現行のガバナンスページでは、Lead Maintainer・Core Maintainer・Maintainer・Contributorの4段が示されています。
- 2025-08-05SEP-1302 WG・IGの形式化
Working GroupとInterest Groupがガバナンスに組み込まれました。
- 2025-11-20SEP-1850 PRベースのワークフロー
GitHub Issuesで管理していた提案が
seps/のファイルに移りました。同月28日にDiscordの投票で賛成8・反対0・欠席0で承認されています。 - 2026-03-27SEP-2484 適合テストの要件化
Standards Track SEPがFinalに進む条件に、適合テストのマージが加わりました。
- 2026-04-17SEP-2596 機能のライフサイクルと非推奨
仕様機能のライフサイクルと非推奨の方針がSEPとして定まりました。
SEP-2484が適合テストを求めた動機は、仕様が英語で書かれている点にあります。SDKのメンテナーは英文を読んでコードに直すので、解釈のズレが生じます。参照実装は「実装できる」ことを示すだけで、全実装が満たすべき要件を示しません。適合テストなら、TypeScriptの参照実装を持つSEPでも、別言語のSDK担当者が自分の実装の正しさを確かめられます。SDKの階層制度(SEP-1730)はTier 1で適合テストの合格率100%、Tier 2で80%を求めており、テスト群が仕様に追随し続ける仕掛けが必要でした。
SEPに書く8つの項目
SEPの文書構成は8パートに定まっています。
- Preamble — 短いタイトル、著者情報、現在のステータス、SEPタイプ、PR番号
- Abstract — 技術的な課題を約200語で要約
- Motivation — 既存の仕様がなぜ不十分なのか
- Specification — 新機能の構文と意味論の技術仕様。競合する複数の相互運用可能な実装を作れるだけの詳細さが必要
- Rationale — なぜその設計を選んだのか、検討した代替案、コミュニティの合意形成の経緯と異論への応答
- Backward Compatibility — 後方互換性を壊す場合はその内容・深刻度・対処方法
- Reference Implementation —
final到達前に必須(承認前は未完成でも可) - Security Implications — セキュリティ上の懸念点
Motivationについては、不十分なSEPは即座に却下され得ると書かれています。他の7項目で、却下の可能性が明記されているものはありません。設計原則の「Stability over velocity」にあるとおり、プロトコルへの追加は事実上取り消せない約束です。なぜ今それが必要かの説明が、重く扱われる理由はそこにあります。
また「Capability over compensation」は、モデルが進歩すれば不要になる限界を回避するための恒久的な仕組みを避ける、という原則です。現行モデルが苦手だから必要、という動機だけの提案には、モデルが追いつくまでに不要にならないかという問いが返ってきます。
プロトタイプと適合テストは何が要求されるか
SEPが承認される前提として、提案を実証する試作実装が必要です。次のいずれかが該当します。
- 公式SDKのブランチやフォークでの実装
- コアの仕組みを示す単体の概念実証
- 提案挙動を示す統合テスト
- 機能を実装したリファレンスサーバーやクライアント
疑似コードのみ、実装を伴わない設計文書、口頭の「動くはずです」は認められません。試作は、レビュアーが動かせるよう手順を添えます。本番品質は不要で、実現可能性の証明と課題の早期発見が目的です。設計原則の「Demonstration over deliberation」が、議論より動くものを重んじる姿勢を示しています。
承認の判断基準は3点です。
- 提案を実証する試作実装があること
- MCPエコシステムへの明確な便益があること
- コミュニティの支持とコンセンサスがあること
観測可能なプロトコル挙動を追加・変更するStandards Track SEPは、finalに到達する前に、conformanceリポジトリへの適合テストシナリオのマージも必要です。シナリオにはSEP番号のタグを付け、参照実装に対して合格させます。SEP内のMUST/MUST NOT・SHOULD/SHOULD NOTの各要件は、チェックIDか除外理由に対応させたトレーサビリティファイル(sep-NNNN.yaml)に記録します。
分担も決まっています。スポンサーがシナリオの作成を確保し、トレーサビリティファイルが全要件を覆っていることを確かめます。シナリオのPRの技術的な妥当性はconformanceリポジトリのメンテナーが見ます。テストの書き手は、SEPの提出者でも、SDKのメンテナーでも、コミュニティの貢献者でも構いません。Core Maintainerのレビュー前の起草段階で書くことも歓迎されており、規範的な文言の曖昧さが早期に見つかるためです。
ProcessとInformationalのSEPは、この要件の対象外です。観測可能な挙動を伴わないStandards Track SEPも対象外で、ドキュメントの明確化、検証を伴わないスキーマ注釈、実装の堅牢化の推奨が当たります。
却下されても終わりではない
SEPが却下されても、道は残されています。
- 指摘された懸念に対応して再提出する
- Discordで却下理由を確認する
- 別のアプローチで競合SEPを提出する
- コミュニティのニーズが変わるのを待つ
オーナーシップの移転は、元の提出者が時間や関心を失った、または連絡が取れない場合に認められます。方向性に同意できないという理由での移転は認められず、その場合は競合SEPを提出します。移転する場合も、元の著者を共著者として残すのが望ましいとされています。
finalに到達したSEPは、当時の設計判断を記録する歴史的資料として扱われ、その後の仕様変更で内容が古くなっても本文は更新されません。仕様が変われば現行の仕様書が優先される旨の注記が、各Final SEPのページに表示されます。未確定のSEPの誤りや更新は、SEPのPRに直接コメントします。
後方互換性を壊す変更はSEPの対象です。MCP HTTP+SSEの非推奨化のような破壊的な仕様変更も、この審議を通ります。
実装者が持ち帰る判断
MCPサーバーやクライアントの実装者が仕様レベルの変更を考えるときは、まず上の4パターンに当たるかを見ます。当たるなら、PRを立てる前に該当グループで議論してリンクを残し、スポンサー候補を絞って声をかけます。Extensions Trackの変更は、同じ番号採番とステータス遷移に従います。MCP Tasksの拡張機能への移行がその例で、違いは参照実装を先に求められる点です。