MCPコントリビューターラダーの全体像 — メンバーからコアメンテナーへ

MCPコントリビューターラダーとは何か

MCPコントリビューターラダーは、最初のコントリビューションからプロジェクトの技術的リーダーシップまでの役割・責任・昇格基準を定めた文書です(SEP-2148で採択)。ガイドしている原則は4つあります。テニュアだけでは足りず貢献の質で信頼を積む「Earned Trust」、コード・仕様策定・ドキュメント・コミュニティ運営のどれでも昇格につながる「Multiple Growth Pathways」、基準を明文化し一貫して適用する「Transparency」、特定の雇用主の利益を超えてMCP自体にコミットする「Alignment With MCP Goals」です。

役割は主要トラックで6段階あります。

タイムラインは最短値であって保証ではありません。急激な権限昇格からプロジェクトを守るための下限であり、実際の昇格はより時間がかかることもあります。例外はCore Maintainerの明示的な承認と根拠の文書化が必要です。

ContributorからMemberへ — 最初の関門

Contributorには正式な要件がありません。issueを立てる、PRを送る、Working Groupの議論に参加する、ドキュメントを直す、他の参加者を手助けする。ガイドラインに従う限り、どんな貢献も歓迎されます。

Memberに上がるには、複数のコントリビューション実績に加え、マージ済みPRか承認済みコントリビューションが最低1件、単発でない継続的な関与、GitHubの二要素認証が必須です。異なる組織に所属する既存Member 2名、またはCore/Lead Maintainer 1名のスポンサーが要り、既存Memberから7日間異議が出ないことも条件に入ります。承認されるとGitHub組織メンバーシップとtriage権限が付き、Working Group LeadやInterest Group Facilitatorの候補資格を得ます。3か月間コントリビューションが無いとemeritus(名誉)ステータスに移されますが、復帰は簡略化された手続きで済みます。

MemberからMaintainerへ — 領域の運用責任を持つ

Maintainerは特定領域の運用責任を負うスチュワードです。要件は次のとおりです。

• Memberとして6か月以上の質の高い貢献実績
• Working Groupや大きな取り組みでのリーダーシップ実績
• 特定の雇用主の利益より上でMCPの利益を代表できること
• MCPのビジョン・ロードマップ・設計原則への深い理解
• 実運用でのAI統合とモデルとのやり取りのパターンへの理解
• セキュリティとガバナンスのオンボーディング完了

既存のMaintainerまたはCore Maintainerのスポンサーを受け、Core Maintainerの承認で確定します。

Maintainerの責任は幅広く、次の4つに整理できます。

• 担当領域の運用健全性(テストの安定性・ドキュメントの鮮度)の維持
• リリースプロセスとマイルストーン計画の実行
• エスカレーションされた判断への迅速なレビュー
• Memberのメンタリングと将来のMaintainer育成

権限は担当領域でのマージ権限、新しいMaintainerのスポンサー資格、ロードマップ・優先順位づけ議論への参加です。6か月間コントリビューションが無いとCore Maintainerのレビューを経てemeritusへ移り、マージ権限は失効します。復帰にはセキュリティ・ガバナンスのオンボーディングをやり直す必要があります。

Core MaintainerとLead Maintainerの権限差

Core MaintainerはLinux Foundation傘下のガバナンス構造のもとでMCPの技術的方向性について最終決定権を持つ、コミュニティで最も高い信頼レベルの役割です。この役職は意図的に少人数に制限されています。プロジェクトが拡大しても一貫した技術ビジョンを保つためで、帯域幅の問題はCore Maintainerを増やすのではなく、MaintainerやWorking Group Lead、Interest Group Facilitatorへの権限委譲で解決する設計です。

要件はMaintainer相当の役割として6か月以上の継続貢献、プロジェクト全体に関わる複雑な判断での実績、組織の壁を越えた信頼、MCPの長期的成功への深いコミットメントです。任命はCore Maintainerの過半数の指名とLead Maintainerの承認、またはLead Maintainerによる直接任命のいずれかで決まります。候補を評価する際、Core Maintainerは本番環境でMCPを使うエンタープライズ導入者を含め、エコシステムの広がりを現在の構成が十分に代表しているかを考慮します。

Lead Maintainerはプロジェクト創設者のために予約された終身の役職で、昇格経路はありません。Core Maintainerが要求する複数承認を単独で実行できる権限と、あらゆる決定への拒否権を持ちます。もし現職Lead Maintainerが退任すれば、残るLead Maintainerが後任を指名し、誰も残っていなければCore Maintainerが30日以内に過半数で後任を決めます。

並行トラックとしてのWGリードとモデレーター

Working Group LeadとInterest Group Facilitatorは、Maintainer資格を持たなくても就ける役割です。マージ権限ではなく調整と進行に軸足があり、Member資格・グループスコープへの継続的な関与実績・複数視点を公平に代表できる調整力が要件になります。Maintainer資格を持たないLead・Facilitatorはマージ判断の際にMaintainerと協働します。逆にWG Lead/IG Facilitatorとしての実績はMaintainerへの昇格材料として評価されます。

Community Moderatorはコードの技術貢献ではなく、Code of Conductの運用とコミュニティの健全性を担う並行トラックです。Member資格を最低要件に、Core MaintainerかLead Maintainerのスポンサーで就任します。他の役割(Member、Maintainerなど)と兼任可能です。

昇格プロセスとエスカレーション手順

昇格は自己推薦とスポンサーからの推薦のどちらでも始められます。手順は、推薦issueを立てて要件を満たす貢献実績とスポンサー確認を添える → 7日間のコミュニティレビュー期間 → 承認権者による決定 → 新しい役割にふさわしいアクセス権とオンボーディング、の4ステップです。自己推薦した場合でも必要なスポンサーシップの確保は免除されません。

意思決定の前提には「委譲がデフォルト」という原則があります。判断は最も適切な低い階層で下すべきというもので、日常的な判断はMaintainer・WG Lead・IG Facilitatorが担い、Core Maintainerは横断的な課題やプロセス上必須の場面(仕様変更・Maintainer承認など)で介入し、Lead Maintainerは論争になったガバナンス判断やCore Maintainerが合意に至れないときに限って介入します。迷ったら自分の階層で判断して記録に残し、行き詰まったとき・プロジェクト全体に影響するとき・プロセスが明示的に求めるときだけエスカレーションする、という運用です。

そのうえで、意見対立が起きたときのエスカレーション経路も明文化されています。issueの種類ごとに第一次・第二次のエスカレーション先と期限が決まっています。

エスカレーションする側には手順も定められています。判断の経緯・検討した選択肢・対立点を記録したうえで、明確な依頼として決定権者に提示し、決定権者は拘束力のある指示を出す・追加情報を求める・さらに上位へエスカレーションする、のいずれかで応じます。

昇格につながる5つの貢献経路

コントリビューターラダーは「コードを書けるかどうか」だけで評価しません。昇格につながる貢献経路は5種類あると明記されています。

特定の1経路に偏らず、複数の経路を組み合わせて実績を積むこともできます。

昇格した後の可視化も制度化されています。MAINTAINERS.mdのようなコントリビューターリストへの掲載、適切なアクセス権を伴うGitHub team、リリースノートでの謝辞、コミュニティイベントでの登壇機会が、貢献を対外的に示す手段として用意されています。

この階段は日本のエンジニアにも開かれている

MCPコントリビューターラダーは特定企業の社員に限定されていません。Requirements欄にある「特定の雇用主の利益より上でMCPの利益を代表できること」という条件は、逆に言えば個人としての継続的な関与さえあれば、所属組織を問わず評価対象になるということです。Contributor段階に正式要件が無いため、まずは good-first-issue タグのついたissueに手を付けたり、Working Groupの議論を追ったりするところから始められます。日本語話者コミュニティの厚みはまだ薄い領域ですが、SDK実装やドキュメント翻訳、Registry周りの改善提案はいずれもMemberへの実績として数えられる貢献です。

まとめ

MCPコントリビューターラダーは、Contributor・Member・Maintainer・Core Maintainer・Lead Maintainerという直線的な階段と、Working Group Lead/Interest Group Facilitator、Community Moderatorという並行トラックで構成されます。各段階には明文化された要件・スポンサー要件・最短タイムラインがあり、昇格プロセスとエスカレーション経路も期限つきで定義されています。SEPを通じた仕様変更の進め方はMCPのSEP(仕様変更提案)プロセス、その判断基準となる価値観はMCPの設計原則8箇条を読み解くにまとめています。プロトコルの方向性に関わりたいエンジニアにとって、ラダーは「誰が」ではなく「何を継続して積み上げたか」で評価する仕組みです。