MCPのSEP(仕様変更提案)プロセスの全体像
MCP仕様への変更提案はSEPという形式で提出します。番号採番からスポンサー選定、Core Maintainerの隔週レビュー、適合テストまでの全ステップをたどります。
SEPとは何か — PRベースのワークフローとの違い
SEP(Specification Enhancement Proposal)は、MCP仕様への変更を提案するための設計文書です。新機能の技術仕様に加えて、その機能が必要な理由(rationale)も書く必要があります。SEPの提出者はコミュニティ内の合意形成に責任を持ち、反対意見も含めて議論の経緯を文書化します。SEPは仕様リポジトリのseps/ディレクトリにMarkdownファイルとして保存され、その改訂履歴自体が提案の歴史的記録になります。
すべての変更がSEPを必要とするわけではありません。バグ修正・誤字訂正・ドキュメントの明確化・既存機能への使用例追加・挙動を変えないスキーマの微修正は、通常のGitHub Pull Requestで十分です。SEPが必要になるのは、新機能やプロトコル変更、後方互換性を壊す変更、ガバナンスやプロセスの変更、そして複数の妥当な解決策があり得て議論を呼びやすい複雑な論点の4パターンです。判断に迷う場合は、着手前にDiscordで質問することが推奨されています。この線引きの狙いは、小さな変更にSEPの重い手続きを課さず、大きな変更に軽いPRの手続きで済ませないことです。手続きの重さを変更の影響範囲に合わせる考え方だと整理できます。提案者にとっての実務的な意味は、PRのように書いて提出すれば終わりではなく、提出後に寄せられる反対意見や代替案への応答まで自分の責任範囲に含めて動く必要がある、という前提の切り替えです。
SEPには4種類ある
SEPは目的に応じて4つのタイプに分かれます。
| タイプ | 用途 |
|---|---|
| Standards Track | 用途プロトコル本体の新機能・実装、または外部の相互運用標準 |
| Informational | 用途新機能を提案せず、設計上の論点やガイドラインを共有 |
| Process | 用途MCPを取り巻くプロセス自体の記述・変更(このガイドライン自体もProcess SEP) |
| Extensions Track | 用途プロトコル拡張の記述。レビュー・承認プロセスはStandards Trackと同じだが、プロトコル本体への追加ではなく拡張であることを示す |
Extensions Trackは、MCPの設計原則が定める「まず拡張で試し、定着したものだけを仕様に取り込む」という考え方の実装形です。プロトコル本体をむやみに太らせず、実験の場を仕様の外に確保する狙いがあります。実装者の視点で見ると、新しいアイデアをいきなりStandards Trackに持ち込むより、まずExtensions Trackとして提案し、実際の利用実績を積んでから本体への統合を目指すほうが、レビューの負荷を分散できる進め方だと言えます。
SEPはどのステータスを辿るか
SEPには8つのステータスがあり、提出から確定まで一方向に近い形で遷移します。
- draft — スポンサーが付き、非公式レビュー中
- in-review — 正式なCore Maintainerレビューの準備が整った状態
- accepted — 承認済み、実装と適合テストの完了待ち
- rejected — Core Maintainerによって却下
- withdrawn — 提出者自身が取り下げ
- final — 実装と適合テストが完了し確定
- superseded — 新しいSEPに置き換えられた
- dormant — 6か月以内にスポンサーが見つからず休眠(復活は可能)
dormantとrejectedは意味が異なります。dormantは単にスポンサーが見つからなかっただけで、アイデア自体が否定されたわけではありません。コミュニティの関心や新しいユースケースが生まれれば、新たにスポンサーを見つけて同じSEPを再始動できます。提出者にとっての実務的な含意は、dormantになった提案をそのまま放置するのではなく、関連する議論が別の場所で再燃したタイミングを見計らって改めてDiscordで呼びかけ直す、という選択肢が常に手元に残っているということです。
提出からFinalまでの実務フロー
まず0000-your-feature-title.mdという仮番号のファイル名でSEPを書き、仕様リポジトリへのPull Requestとして提出します。PRが作成された時点でそのPR番号がSEP番号になり(例: PR #1850なら1850-your-feature-title.md)、ファイル名とヘッダーを更新します。
次に必要なのがスポンサー探しです。提案領域に近いCore MaintainerかMaintainerを1〜2名だけタグ付けし、関連するDiscordチャンネルでPRを共有します。2週間反応がなければ#generalチャンネルで再度呼びかけます。全員にタグ付けするのは避けるべき進め方として明記されています。スポンサーが決まると自身をPRにアサインし、ステータスをdraftに更新します。実際にSEPを書く場面では、自分の変更がどのWorking GroupやInterest Groupの管轄に近いかを先に見極め、そこで日常的に発言しているCore Maintainerを見つけてからタグ付けする順番のほうが、管轄外の相手に声をかけて反応を待つ時間のロスを避けやすくなります。
非公式レビューでスポンサーからの変更依頼に応答したあと、準備が整えばスポンサーがステータスをin-reviewに上げ、2週間ごとのCore Maintainer会議での正式レビューに入ります。ステータスの更新権限は常にスポンサー側にあり、提出者自身が書き換えることはありません。承認・却下・差し戻しのいずれかで決着し、承認後は参照実装(reference implementation)を完成させてfinalに到達します。SDK側の実装は必須ではありませんが、観測可能なプロトコル挙動を伴うStandards Track SEPには適合テスト(conformance test)の追加がfinal到達の条件になります。
SEPに書く8つの項目
SEPの文書構成は8パートに定まっています。
- Preamble — 短いタイトル、著者情報、現在のステータス、SEPタイプ、PR番号
- Abstract — 技術的な課題を約200語で要約
- Motivation — 既存の仕様がなぜ不十分なのか(この項目が弱いと却下される可能性が高いと明記されている)
- Specification — 新機能の構文と意味論の技術仕様。競合する複数の相互運用可能な実装を作れるだけの詳細さが必要
- Rationale — なぜその設計を選んだのか、検討した代替案、コミュニティの合意形成の経緯と異論への応答
- Backward Compatibility — 後方互換性を壊す場合はその内容・深刻度・対処方法
- Reference Implementation —
final到達前に必須(承認前は未完成でも可) - Security Implications — セキュリティ上の懸念点
とくにMotivationは「不十分だと却下される可能性がある」と明記された唯一の項目で、他の7項目より重い扱いです。技術仕様が優れていても、なぜ今それが必要かを説明できないSEPは通りにくい構造になっています。逆に言えば、Motivationさえ強ければSpecificationの細部は非公式レビューの過程で詰めていける余地があるということでもあります。提案者にとっての実務的な含意は、Specificationを細かく書き込む前の段階で、Motivationの草稿だけを先にDiscordで共有し、既存の仕様が本当に不十分だという反応が得られるかを確かめておくことです。ここで反応が薄ければ、詳細設計に進む前に論点自体を見直す判断ができます。
プロトタイプと適合テストは何が要求されるか
SEPが承認される前提として、提案を実証する試作実装が必要です。技術仕様(Specification)がどれだけ詳細に書かれていても、動くものを見せられなければレビュアーは判断材料を持てないという考え方が背景にあります。公式SDKのブランチやフォークでの実装、コアの仕組みを示す単体の概念実証、提案挙動を示す統合テスト、機能を実装したリファレンスサーバーやクライアントのいずれかが該当します。逆に、疑似コードのみ・実装を伴わない設計文書・「動くはずです」という口頭説明は認められません。試作は本番品質である必要はなく、実現可能性を証明し課題を早期に洗い出すためのものです。
承認の判断基準は3点に整理されています。①提案を実証する試作実装があること②MCPエコシステムへの明確な便益があること③コミュニティの支持とコンセンサスがあることです。
観測可能なプロトコル挙動を追加・変更するStandards Track SEPは、finalに到達する前にconformanceリポジトリへの適合テストシナリオのマージも必要です。SEP番号のタグ付けと、SEP内のMUST/MUST NOT・SHOULD/SHOULD NOTの各要件をチェックIDまたは除外理由に対応させるトレーサビリティファイル(sep-NNNN.yaml)の作成が求められます。ProcessとInformationalのSEP、および観測可能な挙動を伴わないStandards Track SEP(ドキュメントの明確化など)はこの要件の対象外です。
却下されても終わりではない
SEPが却下されても、それで終わりではありません。指摘された懸念に対応して再提出する、Discordで却下理由を確認する、別のアプローチで競合SEPを提出する、コミュニティのニーズが変わるのを待つ、のいずれかの道が残されています。今日は却下された提案でも、モデルやエコシステムの前提が変われば数か月後に事情が変わることがあり、却下=永久却下ではない運用です。方向性への不同意は却下の正当な理由にならず、その場合は競合SEPを立てるのが公式な流儀です。オーナーシップの移転(元の提出者が時間や関心を失った、または連絡が取れない場合)も認められていますが、単に方向性に同意できないという理由での移転要求は認められません。移転する場合も、元の著者を共著者として残すことが望ましいとされており、貢献の記録を消さない配慮がここにも表れています。
finalに到達したSEPは、当時の設計判断を記録する歴史的資料として扱われ、その後の仕様変更で内容が古くなっても本文自体は更新されません。仕様が変われば現行の仕様書側が優先されるという注記が各Final SEPページに表示されます。SEPの対象には「後方互換性を壊す変更」が明記されているため、MCP HTTP+SSEの非推奨化のような破壊的な仕様変更も、この4パターンのうちの1つとして審議の対象になります。
まとめ
MCPサーバーやクライアントの実装者が仕様レベルの変更を提案するなら、まず自分の変更がSEPを要する4パターン(新機能・破壊的変更・ガバナンス変更・議論を呼ぶ複雑な論点)に当たるかを確認するのが最初の一歩です。当たるなら、コードを書く前にDiscordで関連するWorking GroupやInterest Groupと話し、スポンサーを見つけてからdraftのPRを立てる順番のほうが、隔週レビューまでの距離が縮まります。MCP Tasksの拡張機能への移行のようなExtensions Trackの変更も、同じ番号採番とステータス遷移のルールに従います。