MCPガバナンスとは、仕様変更を誰がどう決めるかの取り決めのことです。

外部のMCPサーバを事務所に入れるかどうかは、機能表ではなく、その仕様が誰の手でどう決まるかを見て判断できます。この記事では、MCPの意思決定構造が2026年時点でどこまで文書化されたかを整理し、外部サーバの採否を判断するための見方を7つに分けて示します。本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、MCPの運営ルールは仕様運営元の公開ドキュメントで確認しています。MCPは現在、Linux Foundation傘下のLF Projects, LLCのプロジェクトとして運営され、コードと仕様はApache License 2.0、ドキュメントはCC BY 4.0で公開されています（出典: 同ページ）。

MCPの意思決定構造は2026年にどこまで文書化されたか

結論から書くと、MCPの決め方は2026年に入って明文化が進み、外部の第三者が読める形になりました。以前は少数の開発者の判断で動いていた部分が、役割・会議体・投票手順としてドキュメントに落ちています。事務所側から見ると、これは採否の判断材料が増えたことを意味します。

MCPのガバナンス文書によれば、技術面の統治は4つの役割に分かれています。最終決定権を持つLead Maintainers、プロジェクト全体の方向を決めるCore Maintainers、ワーキンググループやSDKなど個別領域を預かるMaintainers、そしてIssueやプルリクエストで貢献するContributorsです。Maintainers以上の3階層がまとめてSteering Groupと呼ばれます。2026年9月18日時点で、Lead MaintainersはDavid Soria ParraとDen Delimarskyの2名、Core Maintainersは6名が同ページに実名で掲載されています（出典: 同ページ）。

ここで士業事務所の目から見て意味があるのは、役職が企業ではなく個人に紐づく点です。同ページには、特定企業のための議席は設けず、メンバーシップは所属先ではなく個人に付随すると明記されています。特定ベンダーの都合だけで仕様が曲げられる構造ではない、という説明の根拠がここにあります。もっとも、Core Maintainersの所属先が偏っていないかは公開情報から個別に確認する余地が残ります。

会議のリズムも公開されています。Core Maintainerの会合は隔週で開かれ、提案の議論と採決を行います。加えて、Lead・Core・Maintainerの各グループは3か月から6か月に一度の対面会合を目指すと記載されています（出典: Governance and Stewardship）。仕様が止まっているのか動いているのかを、事務所側が外から推し量れる材料になります。

方向性については、2026年3月9日にLead MaintainerのDavid Soria Parraが公開した2026年ロードマップが現時点の基準です。従来はリリース単位で整理していたものを、優先領域単位に組み替えたと説明されています。優先4領域は、トランスポートの進化とスケーラビリティ、エージェント間通信、ガバナンスの成熟、エンタープライズ対応です。同記事には、優先領域に沿った仕様提案は審査が速く進み、外れたものは審査に時間がかかると明記されています（出典: 同記事）。この優先順位の読み方はMCP新ロードマップの5領域を士業事務所はどう読むかでも扱っています。

外部MCPサーバを事務所に入れる前に見る7つの角度

採否の判断は、ベンダーの説明資料ではなく、仕様側の公開情報と突き合わせて進めると精度が上がります。以下の7つを順に見て、最後に有資格者が判断する形にします。

第1に、そのサーバが依拠する仕様バージョンを確認します。MCPの現行仕様は2025年11月版で、ロードマップ公開時点で新版は出ていないと2026年ロードマップに記載されています（出典: 同記事）。ベンダー資料に載る機能が正式仕様なのか実験的機能なのかで、後方互換の壊れやすさが変わります。

第2に、その機能を担当しているグループの種別を見ます。MCPにはワーキンググループ（WG）とインタレストグループ（IG）の2種類があります。IGは問題の洗い出しと要件収集が役目で、出すものは問題提起や推奨にとどまり、拘束力のある決定はしません。WGは仕様提案や実装という具体的な成果物を出し、拘束力のある決定をします（出典: 同ページ）。検討中の話題なのか、決まりつつある話なのかが、ここで分かれます。

第3に、そのグループが正式に憲章化されているかを見ます。公式ドキュメントに憲章が掲載されているグループは、2026年9月18日時点でWGがAgents、File Uploads、Filesystems、Inspector V2、Interceptors、Registry、SDK、Server Card、Skills Over MCP、Transports、Triggers and Eventsの11、IGがAuthorization、Enterprise、Enterprise-Managed Authorization、Financial Services、Primitive Grouping、Security、Tool Annotationsの7です（出典: modelcontextprotocol.io のドキュメント索引）。憲章のないDiscordチャンネルだけの集まりと、憲章付きのグループでは重みが違います。なお、この本数は随時変わるため、採否検討のたびに現物を見直す扱いが無難です。

第4に、決め方の手順を見ます。WGの合意形成は、まず異議がなければ可決とみなす方式から始まります。提案には期限が示され、軽微な項目は5日以上、重要な項目は10日以上と定められています。WGメンバーは根拠を文書化したうえで異議を出せますが、その際は代替案か解決の基準を示すことが求められます（出典: Working and Interest Groups）。異議が出た場合は正式投票へ移り、定足数はアクティブなWGメンバーの50%、通常案件は単純多数、スコープ変更は3分の2以上と記載されています（出典: 同ページ）。

第5に、透明性の担保を見ます。同ページによれば、グループの会合はすべてコミュニティに開かれ、組織内部だけの非公開会合は認められていません。会合は専用サイトに7日以上前に掲載され、議事録は48時間以内にGitHub Discussionsへ公開すると定められています（出典: 同ページ）。過去の議事録が読めるかどうかは、事務所が後から経緯を検証できるかに直結します。

第6に、継続性を見ます。WGは1月・4月・7月・10月の各末に四半期報告を出し、成果物の進捗、詰まっている項目、メンバーの異動、次の優先事項を報告すると定められています（出典: 同ページ）。同ページには、活動のないWGや成果物を出し切ったWGは退役の対象になるとも記載されています。事務所が依存する機能の担い手が退役に向かっていないかを見る材料になります。

第7に、行き詰まったときの逃げ道を見ます。グループ内で決着しない案件はCore Maintainersへ上申され、当事者と所属が重ならないCore Maintainerが指名されて裁定します。上申には5営業日以内に初期応答を行うと記載されています（出典: 同ページ）。仕様の争点が放置されない仕組みがあるかどうかは、長期利用の前提になります。

この7つを踏んだうえで、事務所として入れるかどうかを決めるのは有資格者です。調査と整理はAIに任せられますが、顧問先データが通る経路を選ぶ判断そのものは、資格者本人が引き受ける形にしておきます。調査の下書きには次のようなプロンプトが使えます。

あなたはMCPサーバの採否を検討する調査担当です。
以下のURLの内容だけを根拠に、事実と推測を分けて整理してください。

[ベンダーの公式ドキュメントURL]
[modelcontextprotocol.io の該当ページURL]

出力形式:
1. このサーバが依拠する仕様バージョン（記載がなければ「記載なし」）
2. 関係するワーキンググループ／インタレストグループ名と、その種別
3. 実験的機能と正式仕様の区別（どちらか判断できない場合はその旨）
4. 認証方式に関する記述の引用（原文のまま、最大3文）
5. 上記から読み取れない事項のリスト

推測で補わないでください。記載がない項目は必ず「記載なし」と書いてください。

一次調査の結果を事務所の判断材料に落とす段階では、次のプロンプトで論点を並べ替えます。

あなたは士業事務所のIT担当です。以下の調査メモをもとに、
外部MCPサーバ導入の判断材料を整理してください。

# 調査メモ
[前のプロンプトの出力を貼る]

# 事務所の前提
- 取り扱う情報: 顧問先の決算書類および従業員名簿（架空のA社を想定）
- 利用者: 有資格者2名、補助者3名

出力形式:
1. 導入した場合に外部へ出る情報の種類（推測は「推測」と明記）
2. 一次情報で確認できていない論点の一覧
3. 有資格者が判断すべき事項と、担当者レベルで決めてよい事項の切り分け
4. ベンダーに確認すべき質問（5問以内）

法的な評価や結論は書かないでください。論点の整理だけを行ってください。

出力はそのまま使わず、有資格者が原典に当たって内容を検証したうえで、事務所の判断として記録に残します。

顧問先資料をMCP経由で流す前に決めておく3つのこと

最初に決めるのは、そのMCPサーバを経由してどの情報が事務所の外に出るか、です。MCPはAIモデルと外部データ・ツールをつなぐ規格なので、接続した瞬間に何がどこへ渡るかが変わります。ここを曖昧にしたまま接続すると、守秘義務の議論が後追いになります。

守秘義務の根拠条文は資格ごとに置かれています。弁護士については弁護士法第23条が、職務上知り得た秘密を保持する権利と義務を定めています。税理士については税理士法第38条が、正当な理由なく税理士業務に関して知り得た秘密を他に洩らし、または窃用してはならないと定め、税理士でなくなった後も同様と続けています。公認会計士については公認会計士法第27条が同趣旨の規定を置いています。いずれも条文が禁じているのは秘密の漏えいと盗用であり、外部サービスの利用そのものを名指しした規定ではありません。だからこそ、どこまでが漏えいに当たるかという線引きが事務所ごとの論点になります。

2つ目に決めるのは、ベンダーのデータ取り扱いをどこまで確認したか、です。MCPは規格であって製品ではないため、入力データを学習に使うかどうかを決めるのは、接続先のサーバを運営する事業者とAIモデルの提供事業者です。規格が安全だからサーバも安全、という読み方は成り立ちません。この点はMCPのセキュリティは実装側の責任 事務所が接続前に潰す7点検で詳しく扱っています。事務所としては、モデル提供事業者のデータ利用ポリシーと、MCPサーバ運営事業者の利用規約の両方を、原文で確認して記録に残す運用が考えられます。

3つ目に決めるのは、顧問先への説明の形です。顧問先の資料を外部サービスに通す場合、どの範囲の情報が、どの事業者に、どの目的で渡るかを説明し、同意を取る運用を採る事務所があります。説明の粒度をサービス名まで書くのか、外部のAIサービスという括りにとどめるのかは、事務所の方針として先に決めておくと、案件ごとにぶれません。契約書や委任状の様式に一文を足す形で運用している例もあります。

事務所規程に落とす際の項目例としては、接続を許可するMCPサーバの一覧と承認者、投入してよい情報の区分、投入前に匿名化する項目、接続の解除手順、利用ログの保存期間あたりが挙がります。規程は作って終わりではなく、四半期ごとに接続先一覧と突き合わせる運用を置いている事務所もあります。MCPの側でWGが四半期報告を出す周期と合わせておくと、仕様側の動きと事務所側の点検を同じリズムで回せます。

補助者が接続作業を担う場合は、承認の線を明文化しておきます。新しいサーバを試すこと自体は補助者が行い、顧問先データを通す判断は有資格者が行う、という二段構えが実務的です。承認記録が残っていないと、後から経緯を説明できません。

ガバナンスの読み違いが招く3つの失敗

1つ目は、インタレストグループの議論を決定事項と読み違える失敗です。IGは問題提起と要件収集が役目で、拘束力のある決定はしないと公式ドキュメントに明記されています（出典: 同ページ）。IGのDiscordで交わされた案を前提に事務所の運用を設計すると、正式な仕様が別の形で固まったときに作り直しになります。決定事項として扱ってよいのは、仕様提案として採択されたものと、正式仕様に入ったものです。

2つ目は、ベンダー資料の企業名を根拠に安心してしまう失敗です。MCPのメンバーシップは個人単位で、企業のための議席はないとガバナンス文書に記載されています（出典: 同ページ）。大手企業の技術者が関与していることと、その企業が仕様の内容に責任を負っていることは別の話です。採否の根拠に企業名を書いた稟議は、後から見返したときに根拠として弱くなります。

3つ目は、退役したグループの成果物に乗り続ける失敗です。同ページ群によれば、活動が長期間ない、あるいは予定した成果物を出し切ったWGは退役の対象になります（出典: Working and Interest Groups）。退役後もコードは動きますが、不具合や仕様変更への追随は止まります。事務所が依存している機能について、担当グループの最新の四半期報告を年に一度は見に行く運用を置くと、乗り換えの判断が遅れにくくなります。接続先の棚卸しの進め方は増えすぎたAIツール契約を年1回棚卸しする 士業事務所の7手順でも整理しています。

確認にかかる工数と、事務所の誰が持つか

出典: 以下の工数は公表統計ではなく、上の7つを順に追った場合の本記事の試算です。外部MCPサーバ1件あたりの一次調査は、おおむね半日弱を見込む形になります。内訳は、仕様バージョンと機能の対応付け、担当グループの憲章と直近の議事録の確認、ベンダーの規約とデータ取り扱いの確認に、それぞれ同程度の時間を配分するイメージです。対象サーバの資料の充実度によって上下します。

担当は、補助者が調査と要約を担い、有資格者が最終判断を行う形が実務的です。調査の下書きは生成AIに任せられますが、原典に当たる工程は人が引き受けます。MCPの側は情報が英語中心なので、翻訳と要約はAIの得意領域です。逆に、議事録の行間を読んでその機能が定着しそうかを判断する部分は、事務所の事情を知っている人でないと精度が出ません。

調査結果の保管場所も先に決めておきます。稟議書に貼り付けただけだと、次に同じサーバを検討するときに再調査になります。接続先ごとに、確認した日付、確認した一次情報のURL、そのとき読み取れなかった論点を1枚にまとめ、接続先一覧と同じ場所に置く運用にしておくと、二度目以降の判断が速くなります。同じ形式で残しておけば、顧問先から質問を受けたときの回答にもそのまま使えます。

ライセンス費用の面では、MCP自体はApache License 2.0で公開されているため規格の利用に費用は発生しません（出典: Governance and Stewardship）。費用が発生するのは、接続先サービスの利用料とAIモデルの従量課金です。稟議には規格の費用ではなく、接続先ごとの実費を積み上げて書く形になります。

なお、WGのリードには週2時間から3時間の関与が求められると公式ドキュメントに記載されています（出典: 同ページ）。事務所が仕様側に意見を出す立場を取るなら、この時間を誰が負担するかを先に決める話になります。

2026年後半にMCPで論点になりそうなこと

ガバナンスの成熟が優先4領域に入っている以上、当面の焦点は権限の委譲です。2026年ロードマップには、現在はすべての仕様提案がCore Maintainerの全面審査を要するためボトルネックになっており、貢献者の階梯を明文化したうえで、信頼されたWGが自領域の提案を受理できる委譲モデルを整えると記載されています（出典: 同記事）。実現すれば仕様の更新は速くなり、事務所側の追随の負担も増える方向に動きます。

もう1つはエンタープライズ対応です。同記事には、監査証跡、SSO連携の認証、ゲートウェイの挙動、設定の可搬性といった課題が挙がる一方、専任のWGはまだ存在せず、多くはコア仕様の変更ではなく拡張として実装される見込みとも書かれています（出典: 同記事）。監査証跡が拡張扱いになるということは、接続先によって取れるログの粒度が揃わない状態が続く可能性を意味します。事務所側では、ログの保存を仕様側に期待せず、自分の側で記録を残す設計にしておくのが現実的な備えになります。

認証まわりでは、所持証明を伴うトークンの提案とワークロードID連携の提案が審査中であることが同記事に示されています。いずれも、接続元が本当にその事務所のシステムかを確かめる方向の議論です。ここが固まると、外部MCPサーバの採否で見るべき項目も変わります。事務所側の実務としては、いま接続しているサーバがどの認証方式を使っているかを一覧にしておくと、仕様が動いたときの影響範囲をすぐ出せます。

もう少し先の話としては、拡張が増えることで生じる選択の難しさが論点になりそうです。コア仕様を軽く保ち、企業向けの要求は拡張で吸収するという方針が2026年ロードマップに示されています（出典: 同記事）。この方針は、基本部分をシンプルに保つ利点がある一方、事務所から見ると、どの拡張に乗るかという判断がもう一段増えることを意味します。拡張ごとに担い手のグループを確認する手間が、これまでの本体仕様の確認に上乗せされる形になります。

よくある質問

MCPガバナンスを事務所が気にする意味はどこにありますか

意味は、外部サーバの寿命と壊れやすさを先読みできる点にあります。誰がどう決めているかが分かれば、その機能が来年も同じ形で動いているかを推し量れます。機能表だけでは、この判断ができません。

ワーキンググループとインタレストグループの違いは何ですか

違いは、拘束力のある決定をするかどうかです。公式ドキュメントによれば、インタレストグループは問題提起と推奨を出すにとどまり、ワーキンググループは仕様提案や実装という成果物を出して拘束力のある決定をします（出典: 同ページ）。

異議が出なければ可決という決め方は乱暴ではありませんか

この方式には期限と異議申し立ての仕組みが組み合わせてあります。軽微な項目は5日以上、重要な項目は10日以上の期間が置かれ、WGメンバーは根拠を文書化して異議を出せます。異議が出れば正式投票へ移ると公式ドキュメントに定められています（出典: 同ページ）。

顧問先の資料をMCP経由でAIに渡すのは守秘義務の観点でどうなりますか

条文が禁じているのは秘密の漏えいと盗用です。税理士法第38条や公認会計士法第27条はその趣旨を定めていますが、外部サービスの利用を名指しした規定は置かれていません。どこからが漏えいかという線引きが論点になるため、接続先のデータ取り扱いの確認と顧問先への説明をどう設計するかが実務上の焦点になります。

特定のベンダーが仕様を握る心配はありませんか

ガバナンス文書には、特定企業のための議席は設けず、メンバーシップは所属企業ではなく個人に付随すると明記されています（出典: 同ページ）。ただし、実際の顔ぶれの所属が偏っていないかは、同ページの氏名一覧から個別に確かめる余地が残ります。

グループの議論はどこで読めますか

会合は専用サイトに7日以上前に掲載され、議事録は48時間以内にGitHub Discussionsへ公開すると公式ドキュメントに定められています（出典: 同ページ）。過去の経緯をたどる場合は、この議事録が出発点になります。

事務所として仕様側に意見を出すことはできますか

できます。仕様提案は誰でも提出でき、ワーキンググループへの参加も開かれていると2026年ロードマップに記載されています（出典: 同記事）。ただしリードを担う場合は週2時間から3時間の関与が想定されているため、事務所内の体制と相談する話になります。

参考文献

• Model Context Protocol Governance and Stewardship
• Model Context Protocol Working and Interest Groups
• Model Context Protocol Blog The 2026 MCP Roadmap
• e-Gov法令検索 弁護士法第23条
• e-Gov法令検索 税理士法第38条
• e-Gov法令検索 公認会計士法第27条

※士業のチカラでは、生成AIの導入支援から運用最適化まで、貴事務所の業務に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://shigyonochikara.jp/contact/