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

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

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

役割は6つあります。ContributorからLead Maintainerまでの昇格の階段が5段、そこに並行トラックのCommunity Moderatorが加わります。

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

ContributorからMemberへ — 最初の関門

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

Memberに上がるには、複数のコントリビューション実績に加え、マージ済みPRか承認済みコントリビューションが最低1件、単発でない継続的な関与、GitHubの二要素認証が必須です。スポンサーは、異なる組織に所属する既存Member(またはMaintainer)2名か、Core/Lead Maintainer 1名のどちらかです。既存Memberから7日間異議が出ないことも条件に入ります。

承認後の権限は、GitHub組織メンバーシップとtriage権限だけではありません。issueやPRへのアサイン、PR上で/lgtmのような承認・レビューのショートカットコマンドを使う権限、メンバー名簿への掲載、制限付きリポジトリでのPR作成も付きます。Working Group LeadやInterest Group Facilitatorの候補資格も得ます。

責任は、善意で貢献を続けること、割り当てられたissueとPRに応答すること、行動規範に従うこと、可能なら新規コントリビューターのオンボーディングを手伝うことです。

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

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

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

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

責任の中心は次のとおりです。

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

これに加えて、領域のエコシステムと利害関係者に向き合い、実際の使われ方とコミュニティの要望を代表する役目があります。Core Maintainerに届く提案が、練られていてエコシステム全体への影響も踏まえているかを確かめるのも、Maintainerの仕事です。

権限は担当領域でのマージ権限、新しいMaintainerのスポンサー資格、ロードマップ・優先順位づけ議論への参加で、MAINTAINERS.mdに掲載されます。どの貢献経路からでもMaintainerに至れ、担当範囲は貢献の種類に沿って決まります。

Core MaintainerとLead Maintainerの権限差

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

くらべる

Core MaintainerとLead Maintainerの違い

技術面の最終決定

Core Maintainer

Maintainer相当の役割で6か月以上の継続貢献が要件です。任命は、Core Maintainerの過半数の指名とLead Maintainerの承認、またはLead Maintainerによる直接任命です。破壊的変更と主要な仕様改訂の最終承認、SEPの投票権、Maintainerの承認、全MCPリポジトリの管理権限を持ちます。

ガバナンスの最終権限

Lead Maintainer

プロジェクト創設者のために予約された終身の役職で、昇格経路はありません。Core Maintainerが複数の承認を要する場面を単独で実行でき、あらゆる決定への拒否権を持ちます。Core Maintainerの任命と解任、後任の指名も担います。

Core Maintainerの要件には、プロジェクト全体に関わる複雑な判断での実績、組織の壁を越えた信頼、MCPの長期的成功への深いコミットメントも入ります。候補を評価する際は、本番環境でMCPを使うエンタープライズ導入者を含め、エコシステムの広がりを現在の構成が十分に代表しているかを考慮します。

Core Maintainerには、ガバナンスやSEPの判断に加えて、Core Maintainerの会合への出席も求められます。ガバナンスや技術判断への参加が6か月途絶えると、Lead Maintainerのレビューを経てemeritusへ移ることがあります。役割の目立ちやすさから、稼働が減るときは自分から周囲に伝える運用が期待されています。

Lead Maintainerが退任するとき

退任は本人の書面通知で始まります。通知できないときは、残るLead MaintainerまたはCore Maintainerが、継続不能と判断できます。

Lead Maintainerが1人以上残っていれば、残る側が後任を指名します。複数残っていれば多数決です。後任が決まるまでは、残るLead Maintainerが統治を続けます。

誰も残っていなければ、Core Maintainerが30日以内に過半数で後任を決めます。後任が決まるまでの間、プロジェクトはCore Maintainerの3分の2の投票で動きます。

Maintainer資格を問わないWGリードとモデレーター

くらべる

Maintainer資格を問わない2つの役割

調整と進行

WG Lead / IG Facilitator

マージ権限ではなくグループ運営に軸足があります。要件はMember資格、グループのスコープへの継続的な関与、複数視点を公平に代表できる調整力です。グループとその運営者は、Core Maintainer 2名またはLead Maintainer 1名のスポンサーが必要です。

行動規範の運用

Community Moderator

コードの技術貢献ではなく、Code of Conductの運用とコミュニティの健全性を担います。Member資格が最低要件で、Core MaintainerかLead Maintainerのスポンサーで就任します。他の役割との兼任ができます。

WG LeadとIG Facilitatorは、グループ運営には権限がありますが、仕様の承認権限はありません。Maintainer資格を持たない場合、マージ判断はMaintainerと協働します。逆に、この役での実績はMaintainerへの昇格材料になります。

WG LeadはMaintainerと並んでSEPのスポンサーになれ、自分のスコープ内のSEPをトリアージできます。ロードマップに合わないSEPを閉じることも含みますが、閉じるには根拠の文書化が必要で、著者はCore Maintainerに異議を申し立てられます。

Community Moderatorの対応範囲は、Discord・GitHub Discussionsなどの監視、行動規範違反の報告の一次対応、重大な事案のCore Maintainerへのエスカレーションです。権限として、警告、ミュート、一時的なBANを出せます。自分が当事者の事案からは外れ、その事案は直接Core Maintainerに回ります。基準を守れないときや行動規範違反があれば、Core Maintainerが解任できます。

モデレーターとしての経験は、コミュニティの判断が問われる役割で、どの昇格でも実績として数えられます。

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

昇格は自己推薦とスポンサーからの推薦のどちらでも始められ、どちらも同じ扱いです。自己推薦は主体性の表れとして歓迎されています。ただし、必要なスポンサーシップの確保は免除されません。

手順

昇格の4ステップ

1. 1

   推薦

   本人かスポンサーが、推薦用テンプレートでissueを立てます。要件を満たす貢献へのリンクと、スポンサーの確認を添えます。

2. 2

   コミュニティレビュー

   7日間、コミュニティから意見を受け付けます。

3. 3

   決定

   承認権者がレビューして決めます。

4. 4

   オンボーディング

   新しい役割にふさわしいアクセス権とオンボーディングが与えられます。

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

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

WG・IGの紛争には詳細な手順が別にあり、SEP-2149の§1.5に定められています。所属組織を共有しないCore Maintainerを指名して解決に当たらせる仕組みも含まれます。

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

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

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

どれからでも昇格できる

5つの貢献経路

• コード貢献

  SDK開発(TypeScript、Pythonなど)、テスト基盤、ツールと開発者体験の改善です。

• 仕様策定

  仕様テキストのドラフトや改訂、SEPの著者・共著、プロトコル設計への参加、互換性の分析です。

• ドキュメント整備

  ユーザーガイドとチュートリアル、APIドキュメント、アーキテクチャ文書、内容を最新に保つ作業です。

• コミュニティ活動

  新規コントリビューターのオンボーディング、Working Group運営、DiscordやGitHub Discussionsでのサポート、イベントの運営や代表です。

• 品質・セキュリティ

  バグのトリアージと再現、セキュリティレビュー、テストカバレッジの改善、リリースの検証です。

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

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

休眠・退任とemeritusのルール

役割は、一度得れば続くものではありません。貢献が途絶えると、役割ごとに決まった期間でemeritus(名誉)ステータスに移る可能性があります。

自分から降りることもでき、これは「普通で健全なこと」とされています。手順は、関係するリーダー(WG Lead・IG Facilitator・Maintainer・Core Maintainerのうち該当者)への通知、進行中の作業の引き継ぎ、emeritusへの移行です。emeritusは過去の貢献への敬意を示す状態で、継続的な責任も権限もありません。行動規範違反や継続的な不参加では、レビューを経て役割が取り消されることもあります。

SEPのスポンサーはラダーのどこにいるか

提案文書(SEP)を出す人にとって、ラダーはスポンサー探しの地図にもなります。SEPのガイドラインでは、スポンサーはCore MaintainerまたはMaintainerで、MAINTAINERS.mdから領域の近い人を選んで声をかける手順です。一方、ラダーのWG・IGの節には、WG LeadとMaintainerがSEPのスポンサーになれると書かれています。2つのページで挙げる役割が違うので、WG Leadに頼むなら、そのグループのスコープ内か、Maintainerと併せて動く前提で見るのが無難です。

スポンサーが見つからないSEPは、最長6か月待った後にdormant(休眠)になります。却下とは別の扱いで、新しい関心や用途が出てくれば、スポンサーを見つけて再開できます。手順の全体はMCPのSEP(仕様変更提案)プロセスで扱っています。

最初の一段で何ができるか

Contributor段階に正式要件が無いため、所属組織を問わず誰でも始められます。ラダーが挙げる入口は、Contributing Guideを読む、DiscordやGitHub Discussionsに加わる、good-first-issueやhelp-wantedのタグがついたissueに取り組む、Working Groupの会議に出る、の4つです。

「特定の雇用主の利益より上でMCPの利益を代表できること」は、Maintainerの要件に入っています。評価の軸は所属組織ではなく継続的な関与の実績で、Memberへの昇格は、組織をまたいだ2名のスポンサーがそれを裏づける設計です。

まとめ

ラダーは直線の階段と、並行するCommunity Moderator、Maintainer資格を問わないWG/IGリーダーの道を備え、各段に要件・スポンサー・最短期間・休眠ルールがあります。コードに限らない5種類の貢献を組み合わせて積めるので、自分の得意な経路からMemberの要件(マージ済みPR1件と継続的な関与)を目指せます。仕様変更に関わるなら、判断基準の背景にあるMCPの設計原則8箇条を読み解くも合わせて読むと、Maintainer要件の「設計原則への深い理解」の中身が見えてきます。