MCPガバナンス、ユーザーロールと権限 — 企業にとっての重要性

ほとんどのMCPセットアップに潜む問題

モデルコンテキストプロトコルは、AIエージェントが実際のシステムと対話するためのクリーンなレーンを開きました。最初の波のMCPサーバーはCLIバイナリとして提供されます：開発者のラップトップにインストールし、Claude Desktopをそれに向けるだけで完了します。これは単一のパワーユーザーには機能します。

しかし、企業には機能しません。

会社の中で1人以上がMCPを必要とする瞬間、3つのガバナンスの質問が同時に浮かび上がります：

1. 誰がどのコネクタを使用できますか？
2. 接続後、各ユーザーは何ができますか（読み取り？ 書き込み？ 削除？）
3. 監査証跡はどこにありますか？

CLIベースのMCPサーバーは「バイナリを持っている全員」 / 「APIができることは何でも」 / 「stdout、明日には消える」と答えます。規制されたビジネスにとって、これは厳しいストップです。

これがAnythingMCPが解決するために構築されたギャップです。

MCPコンテキストにおけるガバナンスの意味

クラシックなSaaSにおいて、ガバナンスはユーザー、グループ、ロール、権限および監査ログを意味します。同じ基本的な概念がMCPにも適用されますが、1つの追加の次元があります：ツールです。

MCPサーバーはAIクライアントにツールのリストを公開します。各ツールは独立した機能です — list_invoices、create_quote、delete_account。ツールごとのアクセス制御がない場合、「CRMコネクタ」をユーザーに付与することは、そのコネクタが公開するすべてのツールを付与することを意味します。これは、インターンにログをtailする必要があるからといって、ルートSSHを与えるのと同じです。

AnythingMCPは4つのレイヤーをファーストクラスとして扱います：

すべての呼び出しは4つのレイヤーに対してチェックされ、その後ログに記録されます。

AnythingMCPのガバナンスモデル

ユーザーとSSO

ダッシュボードから手動でユーザーを作成することもできますが、実際に企業顧客が行うのは、既存のアイデンティティプロバイダーを接続することです：

• SAML 2.0 for Okta、Azure AD、OneLogin、Ping、Auth0、Keycloak
• SCIM 2.0 for 自動プロビジョニングとデプロビジョニング（誰かが会社を辞めると、そのMCPアクセスはADアカウントとともに消え、3週間後に運用が対応することはありません）
• グループ → ロールマッピング：ADグループeng-platformは自動的にAnythingMCPのロールdeveloperになります

別のパスワードを回転させる必要もなく、同期を保つためのシャドウユーザーリストも必要ありません。

ロール

ロールは権限の名前付きバンドルです。AnythingMCPは合理的なデフォルト — admin、developer、viewer — を提供し、独自のロールを定義できます。

ロール定義は概念的には次のようになります：

role: finance
description: 財務チーム — どこでも請求書を読み取り、DATEVに投稿
connectors:
  - slug: datev
    tools:
      list_clients: read
      list_invoices: read
      create_booking: write
      delete_booking: off
  - slug: weclapp
    tools:
      list_invoices: read
      list_orders: read
  - slug: sap-erp
    tools:
      "*": off    # 明示的に拒否

ワイルドカード"*"は重要です：後でSAPコネクタに新しいツールを追加すると、財務ロールは自動的にオフを継承します — フェイルクローズであり、フェイルオープンではありません。

コネクタごとのアクセス

最も一般的な企業パターン：チームの境界によってコネクタを分けること。

• 営業はCRMを見ます。
• 財務はERPと会計を見ます。
• エンジニアリングは生産データベースを見ます（読み取り専用）。
• カスタマーサポートはチケッティングシステムを見ます。

各チームのAIエージェント — Claude、ChatGPT、Copilot、どれでも構いません — は、自分のロールが許可するツールのみを見ます。営業担当者がChatGPTに「顧客記録を削除して」と頼んでも、ゲートウェイからはクリーンな拒否が返ってきます。SAPでアクションが半分完了した後に500エラーが返されることはありません。

ツールごとの権限

これはCLIサーバーが一致できない粒度です。

Salesforce用の単一のMCPコネクタは、30以上のツールを公開する可能性があります：list_accounts、get_opportunity、create_opportunity、update_opportunity、delete_opportunity、list_leads、… AnythingMCPは各ツールに対して3つのモードをサポートします：

• read — ツールは呼び出し可能でデータを返しますが、変更はフィルタリングされます
• write — ツールは完全に呼び出し可能です
• off — ツールはエージェントから完全に隠されます（MCPのtools/listレスポンスにも表示されません）

「隠されている」というのが重要な点です。モデルは存在を知らないツールを呼び出すことができません。ロールごとにツールカタログをトリミングすることで、各ユーザーが実際に必要とする最小限の攻撃面を減らします。

監査ログ

すべてのツール呼び出しは行を記録します：誰が、いつ、どのツール、どのコネクタ、どの引数で、何が返されたか（またはどのエラーが発生したか）。ログはあなたのPostgreSQLに存在します — 私たちのクラウドにはなく、第三者のS3にもありません — そして他のテーブルのようにクエリ可能です。

規制された業界（銀行、医療、公的部門）にとって、これがMCPを使用可能にする要因です。「誰かが先四半期に患者記録1234を読み取ったか？」という質問に対して、1つのSQLクエリで答えることができます。

CLIのみのMCPサーバーではこれが不可能な理由

MCPエコシステムは、単一目的のCLIサーバーで溢れています — mcp-server-postgres、mcp-server-githubなど。これらは個人使用には最適です。しかし、以下の4つの理由から、企業ガバナンスには構造的に不可能です：

1. ユーザー概念がない。CLIバイナリは、それを呼び出したOSユーザーとして実行されます。「Mario」と「Anna」は存在せず、ただwhoamiがあります。同じClaude Desktopインストールを共有する2人は、設計上同じMCPアイデンティティを共有します。

2. ツールごとのスコープがない。CLIがquery_databaseを公開すると、バイナリを持つすべてのユーザーが任意のSQLで呼び出すことができます。SELECTのみに制限したり、特定のテーブルに制限したりすることは、バイナリをフォークしない限りできません。

3. 中央監査がない。各バイナリは自分のstdoutにログを記録します。「先週、会社が行ったすべてのMCP呼び出しを表示して」と尋ねる場所はありません。

4. デプロビジョニングがない。誰かが辞めると、バイナリがインストールされたすべてのラップトップを追跡し、資格情報を引き抜く必要があります。実際には、誰もこれを行いません。

これらはCLIサーバーのバグではありません — アーキテクチャに固有のものです。開発者のマシン上で実行されるバイナリは、組織のアイデンティティの概念を持っていません。

ホスティングされたSaaSゲートウェイが逆の問題を抱える理由

もう一つの明白な答えは「ホスティングされたMCPゲートウェイSaaSを使用すること」です。これによりガバナンスの問題は解決されますが、より悪い問題が発生します：あなたの生産資格情報が第三者に存在することになります。

ドイツのGmbHや米国の規制対象の企業にとって、これは通常失敗します：

• コンプライアンス — GDPR、BDSG、HIPAA、SOXは、サービスアカウントの資格情報を第三者に渡すことを複雑に（または禁止）します
• 爆風半径 — SaaSが侵害された場合、すべての顧客の接続された生産システムが一度に露出します
• ベンダーロックイン — 資格情報、監査ログ、ロール定義は、あなたが制御できないシステムに存在します

AnythingMCPは設計上セルフホスティングです。ゲートウェイはあなたのVPC、Kubernetesクラスター、Hetznerボックス、ラップトップ — あなたが望む場所で実行されます。資格情報はあなたの境界を越えることはありません。監査ログはあなたのデータベースに存在します。ガバナンスポリシーは、必要であればあなたのgitリポジトリでバージョン管理されます。

ホスティングされたゲートウェイのガバナンスを、セルフホスティングバイナリの信頼性で得ることができます。

企業にとってこれが重要な理由

企業の購入者に見られる3つのパターン：

パターン1 — セキュリティレビューゲート

パイロットはITまたはイノベーションで始まります。プロジェクトが本番に移行する瞬間、セキュリティレビューが始まり、次のように尋ねます：

• 特定のユーザーのアクセスを取り消すことはできますか？
• どのツールを誰が呼び出したかを証明できますか？
• 資格情報はどこに保存されており、誰がそれを復号化できますか？

CLIサーバーはすべての質問に失敗します。AnythingMCPはダッシュボードのスクリーンショットでそれぞれに答えます。

パターン2 — 法務/コンプライアンスゲート

法務が尋ねます：「規制当局がAI駆動の決定について私たちに召喚状を出した場合、呼び出しのトレイルを生成できますか？」

答えは、タイムスタンプ、ユーザーアイデンティティ、完全なツール引数を含めて「はい」である必要があります。AnythingMCPの監査ログはこれに正確に構造化されています — 各呼び出しはタイムスタンプ、ユーザー、コネクタ、ツール、引数、応答ステータスを持つ行です。法務用にCSVとしてエクスポートするのは1行のクエリです。

パターン3 — クロスチームゲート

1つのチームがMCPを機能させると、さらに3つのチームがそれを望みます。ガバナンスがない場合、各チームは次のいずれかになります：

• 自分のCLIインストールを取得する（中央の監視が失われる）
• 1つのインストールを共有するが、隔離がない（1つのチームのミスが他のチームのデータを壊す）

AnythingMCPは、単一のインスタンスがすべてのチームに安全にサービスを提供できるようにします — 営業はCRMのみを見、財務はERPのみを見、エンジニアリングはメトリクスDBのみを見ます。各チームのAIクライアントは、独自のスコープ付きツールカタログを持つ異なる/mcp URLを取得します。

実用的なセットアップ、エンドツーエンド

AnythingMCPでの典型的な企業展開のステップバイステップは次のとおりです：

1. ゲートウェイをあなたのインフラにデプロイします（Docker、Helm、Railway、DigitalOcean — あなたの選択）。約60秒かかります。

2. SSOを接続します。OktaまたはAzure ADをゲートウェイのSAMLエンドポイントにポイントします。ADグループをAnythingMCPのロールにマッピングします。

3. コネクタを追加します。ダッシュボードから、AnythingMCPをあなたのAPI（OpenAPI URL、WSDL、データベース接続文字列）にポイントします。MCPツールカタログが自動的に生成されます。

4. ロールを定義します。各ロールについて、どのコネクタとどのツールを呼び出せるか（読み取り/書き込み/オフ）を選択します。ワイルドカードはデフォルトでオフなので、後で新しいツールを追加してもアクセスが誤って付与されることはありません。

5. MCPエンドポイントをユーザーに配布します。各ユーザーのClaude / ChatGPT / Copilotクライアントは同じゲートウェイURLを取得します — AnythingMCPは認証されたユーザーのロールに基づいてスコープ付きツールカタログを返します。

6. 監視します 監査ログを通じて。すべての呼び出しはあなたのPostgresに存在します；午後のうちにその上にMetabaseダッシュボードを構築します。

TL;DR — ガバナンスのためのAnythingMCPの理由

ガバナンスがあなたのAIロードマップにあり、セルフホスティングが譲れない場合 — AnythingMCPは両方を提供する唯一の選択肢です。

始めるには

AnythingMCP Cloudでガバナンスモデルを試すことができます（7日間の無料トライアル、クレジットカード不要）または、単一のコマンドでオープンソースビルドをセルフホストできます。どちらも同じRBACエンジンを搭載しています。

→ Cloudで無料で始める
→ GitHubでセルフホスト
→ 企業展開についてチームに相談する