MCPのガバナンス構造 — Linux Foundation傘下の意思決定の仕組み

MCP(Model Context Protocol)は、Linux Foundation傘下のLF Projects, LLCの下で運営されています。ガバナンス文書は自らを「Model Context Protocol a Series of LF Projects, LLC」と定義しています。意思決定権はLead Maintainer・Core Maintainer・Maintainer・Contributorの4階層に分かれ、席は企業でなく個人に割り当てられます。仕様の決定権を握っているのは誰か、揉めたときに誰が裁くのか、席が空いたらどう埋まるのか。ガバナンス文書とContributor Ladderの原文から追います。

MCPの法人格はどこに置かれているか

MCPは「Model Context Protocol a Series of LF Projects, LLC」という名称の法人格の下で運営されています。商標の使用ガイドラインを含む一般ポリシーはLF Projectsのポリシーページが適用され、ガバナンス自体の変更も、プロジェクト内部の承認だけでは完結しません。この文書の規定に沿って承認された変更は、LF Projects, LLC側の承認も別途必要になります。プロジェクト単体の合意では変えられない層が、意図的に上に置かれている構造です。

コードと仕様への貢献は、原則としてApache License, Version 2.0の下で行われます。Core Maintainerは例外的に別のライセンスを承認できます。ドキュメント(仕様書を除く)はCreative Commons Attribution 4.0 Internationalの下で公開されます。貢献者は著作権を手放しません。新しい貢献の著作権は貢献者自身が保持し続け、プロジェクトへの譲渡は求められない設計です。

商標の扱いも同じ法人格の傘の下にあります。商標の使用ガイドラインは、MCPプロジェクト独自の規定ではなくLF Projectsの一般ポリシーが適用対象です。

4階層のうち、誰が最終的な拒否権を持つか

MCPのガバナンスはPython・PyTorchなどのOSSプロジェクトと似た階層構造を採用しています。

Lead MaintainerはBDFL(Benevolent Dictator for Life)とも呼ばれます。Maintainer・Core Maintainer・Lead Maintainerを合わせた集団が「MCP Steering Group」で、ガバナンス全体の意思決定主体になります。

拒否権は階層ごとに働き方が違います。

くらべる

拒否権の持ち方

多数決で動く

Core Maintainer

Maintainerの決定を、Core Maintainerの多数決で覆せます。Maintainerの任命と解任、争いの裁定も担います。

単独で動ける

Lead Maintainer

Core Maintainerが複数の承認を要する場面でも、1人で決められます。Core MaintainerとMaintainerのどちらの決定にも拒否権を持ちます。Core Maintainerの任命・解任権を持ち、プロジェクトの全インフラの管理者でもあります。判断の理由は公に説明することが求められます。

席が企業でなく個人に付く点も、拒否権の読み方を左右します。技術ガバナンスへの参加は個人単位で、特定企業向けに確保された議席はありません。メンバーシップは雇用主でなく本人に帰属します。

揉めたとき、Lead Maintainerまで上がるのか

拒否権があるからといって、Lead Maintainerが日常的に決めているわけではありません。ガバナンス文書はLead Maintainerを「あらゆる決定を拒否できる」存在として書きます。一方、Contributor Ladderの「Delegation as Default」は、決定を可能な限り低い階層に任せる原則を掲げます。Lead Maintainerが介入するのは、争いのある統治上の決定と、Core Maintainerが合意に至れない場合に限られます。

実際の上がり方は、争点ごとにContributor Ladderのエスカレーション表で決まっています。

Lead Maintainerが2段目に出てくるのは、Maintainer・WG Lead・IG Facilitatorをめぐる争いと、セキュリティ問題だけです。技術的な意見の相違は、表ではCore Maintainerまでです。Core Maintainer同士が割れたときにはじめて、Lead Maintainerが1段目で受けます。

WGとIGの紛争には別の規定もあります。SEP-2149は、当事者と組織的な所属を共有しないCore Maintainerを指名して解決にあたらせると定めています。身内同士の裁定にならないようにする工夫です。

Working GroupとInterest Groupは何のための器か

個別の技術領域を担当する場は、Working GroupとInterest Groupという性格の異なる2つの器に分かれています。Interest Groupは公開の議論を通じて「MCPが取り組むべき課題は何か」を発掘・言語化する場で、Working GroupはSEPや実装コードといった具体的な成果物を作り込む場です。課題の発掘と成果物づくりが別の場で進みます。現在どのグループが動いているかの一覧はWorking Group・Interest Group一覧にまとめています。

Working GroupのリードとInterest Groupのファシリテーターは、Maintainerの資格がなくても務められます。権限は運営の調整にとどまり、仕様の承認権はありません。マージを伴う判断は、Maintainerと組んで進めます。

仕様変更の合意形成はどのように進むか

Core Maintainerグループは隔週で会議を開き、提案を議論・投票します。小規模な提案なら、共有のDiscordサーバー上で議論と投票を完結させることもできます。各Maintainerグループは追加の連絡手段を独自に選べますが、決定とその根拠になった議論は、どのチャンネルで話し合ったかにかかわらずDiscordサーバー上に記録することが求められます。Lead Maintainer・Core Maintainer・Maintainerの集団は、3〜6か月ごとの対面会合も試みます。

仕様への変更提案はSEP(Specification Enhancement Proposal)という形式で提出されます。SEPへの投票権を持つのはCore Maintainerで、正式なレビューも隔週の会議で行われます。番号採番からスポンサー選定、適合テストまでの具体的な手順はMCPのSEPプロセスにまとめています。

SEPのスポンサーになれる範囲は、2つの公式ページで書き方が違います。SEP Guidelinesはスポンサーを「Core MaintainerまたはMaintainer」と定義します。Contributor Ladderは、MaintainerとWorking Group Leadがスポンサーになれると書きます。Working Group Leadは、自分の担当範囲のSEPをトリアージして、ロードマップに合わないものを閉じることもできます。閉じるときは理由を記録する決まりで、著者はCore Maintainerに異議を申し立てられます。

ドキュメントのように専任のメンテナーがいない構成要素は、Core Maintainerの責任範囲に自動的に含まれます。

メンテナーも一般貢献者と同じ手順でコードを変更する

Core Maintainer・Lead Maintainerであっても、リポジトリへ直接変更を加えることは想定されていません。仕様は、Maintainer・Core Maintainer・Lead Maintainerの全員が外部の一般貢献者と同じコントリビューションプロセス(PRを介した変更提案)を使うことを求めています。狙いは意図の可視化です。変更の背景や理由を議論の場に残し、直接コミットでは失われる検討の過程を記録に残します。

Core Maintainerは全リポジトリの管理者権限を持ちます。管理者権限を持つ者が権限をそのまま行使して変更を確定させる経路を、手順の側で塞いでいる格好です。

席はどう埋まり、どう空くか

メンテナーグループへの参加は、専門性と方向性への合致を示した個人にメリットベースで与えられ、任期の定めがありません。誰が承認するかは階層ごとに違います。

Contributor Ladderは、Lead Maintainerを創設者に限った終身の役職と位置づけています。

手順

Lead Maintainerの席が空くときの流れ

1. 1

   退任の通知

   Lead Maintainerが書面で退く意思を示します。通知できない事情があるときは、残りのLead MaintainerかCore Maintainerが「務められない」と判断できます。

2. 2

   残るLead Maintainerが後継を指名

   1人でも残っていれば、その人が後継を指名します。複数残っていれば多数決で決めます。後継が決まるまで、残りのLead Maintainerが統治を続けます。

3. 3

   全員いなくなったらCore Maintainerが選ぶ

   Core Maintainerが30日以内に、多数決で後継を選びます。新しいLead Maintainerが決まるまでは、Core Maintainerの3分の2の賛成で運営します。

席が空くのは交代だけではありません。活動が止まった場合の期間も決まっています。

数字

活動が止まったときにemeritus(名誉)へ移る目安

• Member

  3か月

  貢献が途絶えた場合に移れる

• Maintainer

  6か月

  Core Maintainerのレビュー後。マージ権は失効

• Core Maintainer

  6か月

  Lead Maintainerのレビュー後

Emeritusは過去の貢献を認める状態で、現役の責務も権限もありません。短い再オンボーディングで現役に戻れます。行動規範の違反や長期の不参加では、役職を取り消されることもあります。

現在のリーダーシップ体制

ガバナンス文書は現職の名簿を公開しています。Lead Maintainerは2名、Core Maintainerは6名です。名誉職のEmeritusは4名で、内訳はLead Maintainer Emeritusが1名(MCPの共同発案者)、Core Maintainer Emeritusが3名です。氏名はガバナンス文書の「Current Lead Maintainers」「Current Core Maintainers」「Emeritus」の各節に載っています。

現在のMaintainerとWorking Groupの一覧は、ガバナンス文書自体には列挙されていません。GitHubのMAINTAINERS.mdが参照先です。各段階への到達要件・スポンサーシップ・審査期間といった昇格プロセスの詳細は、Contributor Ladderの解説にまとめています。

企業でなく個人がメンバーシップの単位になっているのはなぜか

個人単位のメンバーシップは、特定企業がガバナンスを恒久的に支配する事態を構造的に防ぎます。拒否権を持つLead Maintainerの椅子は企業に紐づかず、議決権は転職しても本人についていきます。Contributor Ladderも、Maintainerの要件に「特定の雇用主の利益より、MCPの利益を優先して代表できること」を挙げています。Core Maintainerを選ぶときには、本番環境でMCPを使う企業の利用者を含め、エコシステムの幅を代表できているかを考慮するとも書かれています。

ただし、この設計が集中リスクをゼロにするわけではありません。Lead Maintainerは創設者に限られた2名で、後継の指名も現職が握ります。Core Maintainerの任命にはLead Maintainerの承認か直接任命が必要で、Core Maintainerの数も意図的に絞られています。企業単位の支配は防げても、個人単位の集中は構造に残ります。

審査する側も、席に座っている人たちです。Maintainerを承認するのはCore Maintainer、Core Maintainerを承認するのはLead Maintainerで、個々の席の承認を第三者が審査する規定は載っていません。外部の確認が入るのはガバナンス自体の変更(LF Projects, LLCの承認)で、席の承認の歯止めはLead Maintainerに求める判断理由の公開とPR手順です。

メンテナが所属企業でなく個人の立場で標準を保守する点は、MCPだけの話ではありません。MCPに続き、2026年10月22日にはAgent SkillsもAgentic AI Foundationへ寄贈されました。経緯はAnthropicによるAgent Skillsの寄贈にまとめています。

まとめ

MCPをインフラとして採用するかを判断するなら、席が個人に付くことと、後継の手順が文書に定まっていることが、特定ベンダーが仕様を一方的に書き換えられないかを見る材料になります。SEPが通る・通らないの評価基準はMCPの設計原則で扱っています。