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

MCP(Model Context Protocol)の運営主体は、Anthropicでも特定の1社でもありません。公式ガバナンス文書は自らを「Model Context Protocol a Series of LF Projects, LLC」と定義し、Linux Foundationの傘下でルールを回しています。意思決定権はLead Maintainer・Core Maintainer・Maintainer・Contributorの4階層に分かれ、席は企業でなく個人に割り当てられます。仕様の決定権を実際に握っているのは誰で、なぜLinux Foundation傘下という形を選んだのかを、ガバナンス文書の原文から追います。

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の下で公開されます。貢献者は著作権を手放しません。新しい貢献の著作権は貢献者自身が保持し続け、プロジェクトへの譲渡は求められない設計です。

商標の扱いも同じ法人格の傘の下にあります。「Model Context Protocol」という名称やロゴを使う際のガイドラインは、MCPプロジェクト独自の規定ではなくLF Projectsの一般ポリシーが適用対象です。MCPを土台にした製品やサービスを名乗る側にとって、商標利用の可否がプロジェクト単体の判断でなくLF Projects側の統一ルールに従う点は、デューデリジェンスの実務で確認しておく価値があります。

誰が最終的な拒否権を持つか

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

Lead MaintainerはBDFL(Benevolent Dictator for Life)とも呼ばれ、Core Maintainerの任命・解任権も持ちます。Maintainer・Core Maintainer・Lead Maintainerを合わせた集団は「MCP Steering Group」と呼ばれ、ガバナンス全体の意思決定主体になります。重要なのは、この役職が特定企業に紐づく議席ではない点です。技術ガバナンスへの参加は個人単位であり、特定企業向けに確保された議席は存在しません。メンバーシップは雇用主でなく本人に帰属します。

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

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

合意形成はどのように進むか

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

仕様への変更提案はSEP(Specification Enhancement Proposal)という形式で提出されます。誰がSEPを承認するかという最終判断はCore Maintainerグループが握りますが、番号採番からスポンサー選定、適合テストまでの具体的な手順はMCPのSEPプロセスにまとめています。ドキュメントのように専任のメンテナーがいない構成要素は、Core Maintainerの責任範囲に自動的に含まれます。

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

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

メンバーシップの側にも同じ思想が表れています。メンテナーグループへの参加は、専門性と方向性への合致を証明した個人にメリットベースで与えられ、任期の定めがありません。会社を移籍しても議席を保持したまま活動を続けられる一方、実績や信頼を失えばRemoval(解任)の対象になります。地位が任期でなく実績と信頼で更新され続ける設計です。

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

ガバナンス文書は現職のLead Maintainer・Core Maintainerを実名で公開しています。

各段階への到達要件・スポンサーシップ・審査期間といった昇格プロセスの詳細は、ガバナンス文書でなくContributor Ladderが正典です。現在のMaintainer・Working Group一覧はGitHubのMAINTAINERS.mdが参照先になっており、ガバナンス文書自体には列挙されていません。Emeritus(名誉)という肩書きは、Justin Spahr-Summersのような共同発案者を含め、過去の貢献への敬称としてリストに残す位置づけで、現職の4階層とは別枠の扱いです。

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

個人単位のメンバーシップは、特定企業がガバナンスを恒久的に支配する事態を構造的に防ぎます。MCPの提案そのものはAnthropicのエンジニアが起点になることが多いとしても、拒否権を持つLead Maintainerの椅子自体は企業に紐づきません。議決権は転職しても本人についていき、雇用主が変わった瞬間に議席が失われることもありません。個人の実績と専門性を基準に、メリットベースでメンバーシップが与えられる設計です。

ただし、この設計が集中リスクをゼロにするわけではありません。Lead Maintainerはわずか2名で、両者が拒否権を持つ以上、企業単位の支配は防げても個人単位での意思決定の集中は残ります。「誰が席に座るか」を審査するのはCore Maintainerグループ自身であり、外部の第三者機関ではありません。中立性は制度設計によって担保されていますが、審査プロセスそのものへの外部監査までは、ガバナンス文書の記述からは読み取れません。

Lead Maintainer・Core Maintainerの選任基準も、外部の資格試験や投票権を持つ会員制度ではなく、既存メンバーによる指名とスポンサーシップに基づきます。新しくMaintainerを迎える判断そのものが、現職のメンバー集団の合意に依存する内輪の仕組みであることは、個人単位のメンバーシップという制度設計と表裏一体の性質です。

まとめ

MCPのガバナンスはLinux Foundation傘下の法人格の下、Lead Maintainer・Core Maintainer・Maintainer・Contributorという4階層と、企業でなく個人に紐づくメンバーシップで運営されています。仕様変更の最終的な承認権はCore Maintainerグループにあり、ガバナンス自体の変更にはLF Projects, LLC側の承認も必要です。MCPをインフラとして採用するかどうかを判断する側にとって、この構造は「特定ベンダーが将来の仕様を一方的に書き換えられるか」を見極める材料になります。仕様提案の実務プロセスを知りたければMCPのSEPプロセス、SEPが通る・通らないの評価基準を知りたければMCPの設計原則を合わせて参照してください。