MCPでAIに社内データを開くと、次に必ずぶつかるのが 「権限」 です。MCPは "つなぐ"を標準化 しましたが、"誰が・どこまで使えるか"は各サーバ任せ のまま。AIエージェントは自律的にツールを呼び連ねるからこそ、境界の設計が問われます。本稿は、なぜ権限制御されたMCPが必要か、いまMCPの権限で起きている課題、Passworkが どんな設計思想で実装したか、そして Claude Tagで実際にどう制御されるのか を、tools/list / tools/call / OAuth 2.1 といった技術要素とともに掘り下げます。

01　なぜ「権限制御されたMCP」なのか ── つないだ瞬間に生まれる問い

MCP（Model Context Protocol）は、LLMアプリと外部システムのつなぎ方を標準化しました。ツール提供側はMCPサーバを一つ実装すれば、Claude でも、他のMCP対応クライアントでも同じように使われる。「AIにとってのUSB-C」と呼ばれる所以です。その仕組みは別稿で解説しました。

ところが、実際に社内データをMCPで開いた瞬間、必ずこの問いが立ち上がります。「このAIは、何を、どこまでできるのか？」

MCPクライアント（＝AIエージェント）は、自然言語を tools/call の連鎖に翻訳して 自律的に動きます。強力です。だからこそ、境界が無ければ ── 「読ませたいだけなのに書き込めてしまう」「特定の人にだけ触らせたいのに全員が触れる」「セットアップした管理者の全権で動いてしまう」といった事故が、自然言語の一言から起こり得ます。

02　いまMCPの権限で起きている3つの課題

「MCPで会話からデータを動かせる」を本番運用に乗せようとすると、権限まわりで次の3つに突き当たります。

共通する根は一つ。MCPは"接続"の標準であって、"認可"の標準ではない。だから権限は、MCPサーバ側で 自分で・明示的に 設計する必要があります。

03　設計思想 ── 権限制御MCPを支える3つの原則

Passworkは、上の4課題に対して、次の3原則で権限を組みました。

原則1 ── 権限は「人に紐づくプロファイル」で持つ

ロール（管理者/一般）という粗い区分ではなく、プロファイルという単位を導入しました。ユーザーはいずれか1つのプロファイルに属し（プロファイル : ユーザー = 1 : N）、プロファイルが権限を持ちます。粒度は2段構え。

• サービス種別ごとの参照 / 更新（salesforce は参照のみ、board は参照＋更新 …）。更新を持てば参照も必ず含む。
• ツール単位の使用可否（そのサービスの各操作を個別にオン/オフ）。

原則2 ── fail-close はサーバ側に置き、クライアントを信用しない

権限判定の最終責任は、MCPサーバ（Passwork） が持ちます。クライアント（Claude 側）の絞り込みは利便性であって、安全性の担保にはしない。MCPは疎結合ゆえどんなクライアントが繋いでくるか分からない。だから、ツール実行の手前で 「許可が無ければ拒否」（fail-close） を必ず通します。

原則3 ── 「誰として繋ぐか」を人の目で確認する

課題①への答えです。MCP接続時のOAuth同意画面で、「どのアプリが・どのユーザーとして・どのスコープで」接続するのかを一度人が確認する。

04　実装の中身 ── tools/list と tools/call でどう効くか

原則を、MCPの2つのメソッドの上でどう効かせているかを具体的に見ます。

tools/list ── 見えるツールを、その人のプロファイルで絞る

接続直後、クライアントは tools/list で「いま使えるツール一覧」を問い合わせます。Passworkはここで、認証済みユーザー（current_user）のプロファイルを見て、参照/更新できないサービスの専用ツールを一覧から落とします。使えないものは、そもそも見せない。

tools/call ── 実行の手前で fail-close に評価する

実際にツールが呼ばれると、実行の 直前 にプロファイルで可否を判定します。汎用ツール（fetch_connector_data / write_connector_data）は引数の connector_id から対象サービスを解決し、読み取りなら参照権限、書き込みなら更新権限を要求。さらにツール単位の明示的な拒否があれば弾きます。許可外なら、「なぜ拒否されたか」を日本語で返す ── クライアントのAIはそれをそのままユーザーに伝えられます。

05　「誰として繋ぐか」を可視化する ── OAuth同意画面

課題①（誰のコンテキストで動くか）への直接の対策が、OAuth 2.1 の同意画面です。

認可の直前に 同意画面 を挟むようにしました。表示するのは ──

• どのアプリが接続しようとしているか（クライアント名）
• どのユーザーとして接続するか（＝以後、そのコンテキストで動く）
• どのスコープか（参照 / 更新）。実際の操作範囲はプロファイル権限に従う旨も明記

もう一点、トークンの性質も統制に関わります。OAuthのアクセストークンは短命＋リフレッシュで失効可能、機械間接続用のAPIキーは失効可能。「誰の名義でMCPを生やすか」を運用ルールにすることが、実は最大の勘所です。管理者名義で全権を生やさない ── これが次章につながります。

06　Claude Tagで実際にどう制御されるか ── Boardの例

ここまでの設計が、Claude（Claude Tag / MCPクライアント）から使うときにどう効くのか。具体的な流れで見ます。

07　まとめ ── MCPは"つなぐ"の次に"どこまで"を持つ

MCPは接続を標準化しました。次に来るのは、「誰が・どこまで使えるか」を、AIエージェント前提で設計することです。

• 権限はプロトコル外。MCPは接続を標準化するが、認可は各サーバが自分で設計する
• プロファイル（人単位・1:N） で、サービス種別の参照/更新＋ツール単位の権限を持つ。既定は許可、制限だけを持たせる
• 安全性の最終担保は サーバ側の fail-close。クライアントは信用しない。エージェント×プロファイルを AND で重ねる
• OAuth同意画面 で「誰として・どのスコープ」を可視化

「会話でデータを動かす」体験を本番に乗せる価値は、派手なUIではなく、"AIにどこまで委ねるかの境界をどこに引くか" という地味な設計判断に宿ります。Praztoは、この境界設計と運用ルールづくりを、お客様の業務に合わせて伴走しています。