MCPのWorking Group・Interest Group一覧 — 17グループの役割分担

MCPの仕様策定は、Anthropic単独ではなくコミュニティのWorking Group(WG)とInterest Group(IG)が分担して進めています。現在チャーター化されているのは10のWGと7のIGで、認可・レジストリ・SDK・トランスポートといった領域ごとに担当が分かれています。

Working GroupとInterest Groupは何が違うか

MCPコミュニティは2種類の協業フォーマットを使い分けます。IGは「問題を発見し議論する」場、WGは「具体的な解決策を作る」場という役割分担です。

典型的な流れは「IGで問題を議論する → コミュニティの支持があるか検証する → WGを結成・参加して解決策を作る → SEPを提出する → 実装する」という順序です。ただしIGを経由せず、明確な成果物とCore Maintainerのスポンサーがあれば直接WGを提案することもできます。

10のWorking Groupが担当する領域

Working Groupは具体的な仕様変更(SEP)や実装のオーナーです。それぞれの担当領域は次のとおりです。

Skills Over MCPは、2026年2月1日にInterest Groupとして発足し、SEP-2076の議論を経て2026年4月16日にWGへ転換した経緯を持ちます。仕様は現在SEP-2640(Extensions Track)として審議が進んでいます。

7のInterest Groupが担当する領域

Interest Groupは解決策を作る前段階として、問題を洗い出し要件を集める場です。

認可まわりだけでIGが3つ(Authorization・Enterprise・Enterprise-Managed Authorization)に分かれている点は、この分野の要件の広さを示しています。Authorizationが認可全般の受け皿、Enterpriseが企業導入全体のギャップ、Enterprise-Managed Authorizationが特定の拡張仕様の相互運用検証、と守備範囲が明確に切り分けられています。

Interceptors・Registry・SDKの3WGが今ぶつかっている壁

一覧表だけでは伝わらない、各WGが実際に取り組んでいる課題を3つ紹介します。

Interceptors WGが向き合っているのは「M×N問題」です。ツール呼び出し・リソースアクセス・サンプリング・elicitationといったコンテキスト操作を横断的に扱うサイドカーやプロキシ、ゲートウェイが乱立し、それぞれが再利用も相互運用もできない状態になっています。WGはこれをvalidator(検査してpass/failを返す)とmutator(コンテキストのペイロードを変換する)の2種類からなる新しいMCPプリミティブとして標準化します。インプロセス・サイドカー・リモートサービスのいずれの配置形態でも、同じJSON-RPCパターンで呼び出せる形を目指しています。

Registry WGはregistry.modelcontextprotocol.ioで稼働する公式レジストリの運用に加え、任意のレジストリ(公式・非公式問わず)がサーバーメタデータを公開する際のAPI仕様を所有します。サーバーの識別情報・パッケージ・ランタイム設定・機能を記述するserver.jsonスキーマもこのWGが管理し、Server CardがそのSchemaの一貫した部分集合であり続けるようServer Card WGと連携しています。

SDK WGは各言語の公式SDKが仕様に準拠し続けるよう、新しいプロトコルバージョンの実装を横断的に調整するほか、SDK Tiering Systemというティア制度そのものを運営しています。ティア昇格のリクエストをレビューし、降格基準を適用し、公開されているティア一覧を維持するのもこのWGの仕事です。

グループはどう結成され、どう引退するか

新しいWGを結成するには、コーディネーションが必要だと広く認識される課題があることが前提です。そのうえでdocs/community/working-groups/<name>.mdxにチャーターを追加するPRを作成し、Core Maintainerの承認を得るCODEOWNERSゲートを通します。IGの結成はDiscordの専用チャンネルでテンプレートに記入するところから始まり、Core Maintainerがレビューしたうえで、2名以上のCore Maintainerか1名のLead Maintainerによるスポンサーが必要です。

引退にも手続きがあります。WGはLeadかCore Maintainerが理由を添えて引退を提案し、Core MaintainerかLead Maintainerの承認を得ます。一定期間活動がない、または計画していた成果物をすべて完了したWGは自動的に引退の対象になります。IGはCore MaintainerかLead Maintainerが、活動していない、あるいは不要になったと判断すれば引退させられます。いずれの場合もドキュメントはアーカイブされ、チャンネルは非アクティブ扱いになります。

WGとIGはどう連携するか

IGとWGは独立して動くのではなく、IGの議論がWGの仕事に流れ込む設計です。IGが担うのは問題提起・ユースケース・要件ギャップの文書化までで、それをSEPという具体的な成果物に落とし込むのは、チャーターでその領域を担当すると定められたWG側の役割です。どのIGの議論がどのWGへ渡るかはチャーター上で1対1に固定されているわけではなく、テーマに応じて該当WGが引き取ります。Primitive Grouping IGのように、単一の正解パターンを早期に決めず、複数の組織方法を並行して検証してからSEPに反映するという、あえて結論を急がない運営方針を明記しているIGもあります。

WGのメンバーになるには、3か月以上の継続的な参加と、コード・仕様文書・レビューいずれかでの実質的な貢献、既存WGメンバーかLeadからの推薦が必要です。7日間異議がなければ承認されます。逆に3か月連続で参加がないWGメンバーはemeritus(名誉)扱いに移行し、再度活動を示せば復帰できます。

すべてのグループのミーティングは、コミュニティ全体に公開され、少なくとも7日前に予定が公開されます。組織のメンバーだけで行うクローズドな会議は開けません。議題は事前にGitHub Discussionsの「Meeting Notes」カテゴリに公開され、議事録もミーティングから48時間以内に同じ場所へ公開します。頻度そのものはLeadの裁量で、仕様リリースが近いWGなら毎週、探索段階のIGなら月次や非同期中心といった調整が認められています。Discordの#{name}-wgまたは#{name}-igチャンネルと、GitHub Discussionsが共通のコミュニケーション経路です。

WGにはIGにはない報告義務もあります。四半期ごと(1月・4月・7月・10月の末)に、成果物への進捗・ブロックされている項目とエスカレーションの状況・メンバーの異動・次の四半期の優先事項・必要なリソースをまとめた文書をGitHub Discussionsに投稿します。IGにはこの形式の報告義務はなく、チャーターとメンバー一覧を最新に保つことだけが求められます。

参加レベルは全グループ共通で4段階に分かれています。

参加のハードルはIGの方が低く、Observer(閲覧のみ)・Participant(議題提案・非同期投票に参加)から始められます。MCPの仕様変更プロセス全体はMCPのSEP(仕様変更提案)プロセスの全体像で、直近半年の優先領域はMCPの2026年ロードマップで扱っています。

グループ内で意見が割れたときの決着のつけ方

WGの意思決定は3段階で進みます。

まずlazy consensusがデフォルトです。提案には期限(軽微な項目で最低5日、重要な項目で10日)が設定され、沈黙は同意とみなされます。WGメンバーは代替案か明確な解決基準を添えて異議を唱えられ、期限までに異議がなければ提案は成立します。

異議が出た場合は正式な投票に移行します。定足数はアクティブなWGメンバーの50%で、可決には通常議題で単純多数、スコープ変更では3分の2の賛成が必要です。

投票でも決着しない場合は、LeadがCore Maintainerへエスカレーションします。決定の経緯・検討した選択肢・対立点を文書化したうえで持ち込み、Core Maintainerグループが当事者と組織的な利害関係のないCore Maintainerを1名指名して裁定します。初動の返答は5営業日以内が目安です。

スコープの対立(ある話題がチャーターの範囲内かどうか)・権限の対立(そのグループに決定権があるかどうか)・複数WG/IGにまたがる対立・行動規範に関わる懸念・メンバーシップの対立は、グループ内で解決を試みずに直接Core Maintainerへ持ち込む対象と定められています。IGは投票プロセスを持たないため、Facilitatorがゆるやかな合意を探ったうえで、まとまらなければ同じ経路でエスカレーションします。

まとめ

MCPのコミュニティ運営は、問題発見を担う7のInterest Groupと、具体的な仕様・実装を担う10のWorking Groupに分かれています。IGでの議論がWGでの仕様策定に流れ込み、SEPとして実装される、という一方向の流れが基本です。

認可・レジストリ・SDK・トランスポートといった主要領域はすでにWGが担当していますが、認可まわりだけは3つのIGに分かれているように、領域によって粒度がまちまちです。どのグループが何を担当しているかを把握しておくと、SEPの議論を追う際や、自社の要件をどこに持ち込むべきか判断する際の起点になります。