企業管理型認可とは、MCPサーバーへの接続可否を自社のIDプロバイダで一括制御する拡張仕様のことです。

職員が新しく入るたびに、会計システム、労務システム、文書管理と、AIツールの接続を一つずつ承認してもらっていないでしょうか。この記事では、MCPの拡張仕様である企業管理型認可（Enterprise-Managed Authorization、以下EMA）が安定版になったことを踏まえ、士業事務所がAIのアクセス権限を一元管理するための手順と、守秘義務の観点から決めておくべき論点を整理します。本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、行政の見解は各府省庁の公表資料で確認しています。EMAはModel Context Protocol公式ブログが2026年6月18日付で安定版化を告知しており、Okta、Anthropic、Microsoftをはじめとする実装が始まっています。

職員ごとの個別承認が限界にきた理由

MCP（Model Context Protocol）は、AIツールと業務システムをつなぐための共通規格です。士業事務所では、会計ソフト、顧客管理、文書管理といった手元のシステムをAIから参照させる用途で導入が進んでいます。事務所の連携基盤としての位置づけはMCPの新ロードマップ公開 士業事務所の連携基盤に効く5つの優先領域で整理しました。

これまでのMCPの認可モデルは、利用者一人ひとりがサーバーごとに接続を承認する設計でした。個人が自分のデータの流れ先を決められるという意味では、消費者向けの用途に向いた設計です。ところが事務所という組織で使うと、この設計は三つの摩擦を生みます。公式ブログはこの点を、職員全員がサーバーごとに個別承認を求められること、セキュリティ担当が一貫した方針を強制できないこと、業務用アカウントと個人アカウントが混ざることの三つとして挙げています（出典: Model Context Protocol Blog「Enterprise-Managed Authorization: Zero-touch OAuth for MCP」）。

士業事務所に引き直すと、この三つはそのまま守秘義務の管理点になります。第一に、補助者が自分の判断で顧問先データを扱うAIツールを接続できてしまう状態は、事務所として入力範囲を統制できていないことを意味します。第二に、退職者が出たときに、どのサーバーへの接続を残したまま辞めたのかを事務所が把握できていないと、アクセス解除の網羅性を説明できません。第三に、業務用と個人用のアカウントが混ざると、顧問先資料が個人契約のクラウドに流れる経路が開きます。いずれも、事故が起きてから調べるのでは間に合わない種類の問題です。

EMAは、この構造を組織のIDプロバイダ（IdP）を判断主体に据えることで組み替えます。管理者が、どの職員グループがどのサーバーに接続してよいかという方針を一箇所で定義し、職員は普段のシングルサインオンでログインするだけで、許可されたサーバーが自動的につながります。公式ドキュメントはこれを、集中管理された方針、シングルサインオン、方針の強制、集中的な失効の四つの性質として説明しています（出典: Model Context Protocol「Enterprise-Managed Authorization」）。

事務所のAIアクセス権限をIdPに寄せる7手順

EMAの技術的な骨格は、IdPが発行するID-JAG（Identity Assertion JWT Authorization Grant）というトークンを、MCPクライアントがMCPサーバーの認可サーバーに提示してアクセストークンに交換する流れです。利用者はサーバーごとの同意画面を経由しません。ID-JAGの仕様自体はIETFで議論されているドラフトが下敷きになっています（出典: Model Context Protocol「Enterprise-Managed Authorization」）。

事務所側の作業に落とすと、次の七つの工程になります。技術用語が並びますが、判断が必要なのは工程1と工程4と工程7で、そこは有資格者が決める領域です。

1. 事務所が使っているIdPを確認する。Microsoft Entra ID（旧Azure AD）やOktaを既に使っているなら、その管理コンソールが起点になります。公式ブログはOktaを最初の対応IdPとして挙げ、OktaのCross App Access（XAA）を通じて提供されると説明しています。IdPを持たず、各職員が個別にGoogleアカウントでログインしている事務所は、ここが未整備なので工程2以降に進めません。
2. 接続先候補のMCPサーバーがEMAに対応しているかを調べる。公式ブログは、Asana、Atlassian、Canva、Figma、Granola、Linear、SupabaseがEMAに対応済みで、Slackなどが対応を進めていると記載しています。会計・税務・労務の国内ベンダーは現時点では名前が挙がっておらず、事務所の主戦場である業務システムがどこまで追随するかは要確認です。
3. 使うMCPクライアント側の対応状況を確認する。公式ブログによれば、Anthropicは共有MCP層に実装し、管理者がClaude、Claude Code、Cowork をまたいで許可を設定できるようになっています。Visual Studio Codeもv1.123でプレビュー対応しています。
4. 職員グループと接続先の対応表を事務所として作る。ここが本丸です。有資格者グループ、補助者グループ、非常勤グループのように分け、それぞれがどのサーバーに接続してよいかを一覧にします。事務所内の階層設計の考え方は士業事務所の生成AI権限設定 有資格者と補助者で分ける5階層のルールで扱っています。
5. IdPの管理コンソールで方針を設定する。グループ所属、ロール、条件付きアクセスの条件に基づいてIdPが可否を判定します。許可のない職員のクライアントには、そもそもトークンが発行されません。
6. 検証環境で、許可された職員と許可されていない職員の双方でログインし、意図どおりに接続と拒否が起きるかを確認する。ここを飛ばすと、方針を書いたつもりで実際は全員が通っている、という状態に気づけません。
7. 退職・異動時の解除手順を事務所の運用文書に書き込む。EMAではIdPで権限を落とせば全クライアント側に即時反映されるため、解除の手順書は、IdPで該当職員のグループを外す、という一行に集約できます。この一行に集約できること自体が、EMAを入れる実務上の最大の利点です。

工程4の対応表づくりは、生成AIにたたき台を作らせると早く進みます。次のプロンプトは、事務所の実態を入力して一覧の骨組みを出させるものです。出力はあくまで案であり、どの区分にどのサーバーを割り当てるかの最終判断は有資格者が行います。

あなたは情報システムの権限設計を支援するアシスタントです。
以下の事務所情報をもとに、MCPサーバーへの接続権限マトリクスの案を作成してください。

【事務所情報】
- 業種: 税理士法人
- 職員構成: 有資格者4名、補助者9名、非常勤の記帳担当3名
- 接続候補のシステム: 会計ソフト、顧客管理、文書管理、社内グループウェア
- 顧問先データの機微度: 決算数値と個人の給与データを含む

【出力形式】
1. 職員区分ごとの行、システムごとの列で、可否と理由を箇条書きで示す
2. 可否の判断が分かれそうな組み合わせを「要検討」として別立てで列挙する
3. 各行に、その権限を与えた場合に想定される情報漏えい経路を1行で添える

※法令上の可否や義務については判断せず、運用上の論点として整理するにとどめてください。
※実在の顧問先名や個人名は出力しないでください。

設定後の検証記録づくりにも生成AIを使えます。次のプロンプトは、検証結果を事務所の記録様式に整える用途です。

あなたは社内文書を整える編集アシスタントです。
以下の検証メモを、監査時に提示できる記録として整形してください。

【検証メモ】
（ここに、誰がいつどのアカウントでログインし、どのMCPサーバーに接続できた／できなかったかを貼る）

【出力形式】
- 検証日時、検証者、対象システム、期待結果、実際の結果、判定 の順に整理する
- 期待どおりでなかった項目を冒頭に集める
- 最後に「未検証のまま残っている組み合わせ」を列挙する

※所見の断定は避け、事実の記録に徹してください。

権限設定の記録を監査証跡としてどう残すかは事務所のAI利用ログを監査証跡にする 保管設計7項目と説明の型で別途整理しています。

顧問先資料の流れ先を一元化するときに決めておく論点

EMAは接続の可否を集中管理する仕組みであって、接続した先で何が起きるかを保証する仕組みではありません。ここを混同すると、IdPで許可した時点で守秘義務の検討が終わったかのような錯覚が生まれます。

まず、根拠条文の確認です。弁護士については、弁護士法第23条が、弁護士および弁護士であった者は職務上知り得た秘密を保持する権利を有し義務を負う旨を定めています。税理士については、税理士法第38条が、正当な理由なく税理士業務に関して知り得た秘密を他に洩らし、または窃用してはならない旨を定めています。八士業それぞれの根拠条文は士業の生成AIと守秘義務 8士業の根拠条文と入力ルールの作り方にまとめています。

次に、個人データの安全管理の観点です。個人情報の保護に関する法律第23条は、個人情報取扱事業者に対し、取り扱う個人データの漏えい、滅失又は毀損の防止その他の安全管理のために必要かつ適切な措置を講じることを求めています。IdPによる権限の集中管理は、この安全管理措置の技術的・組織的な一部として位置づけて説明できる可能性がありますが、それだけで足りるかは事務所の取扱状況によって変わるため、個々の当てはめは有資格者の判断に委ねられます。万一の場合の報告については同法第26条が漏えい等の報告等を定めており、初動の手順は事前に決めておく領域です。

そのうえで、EMA導入時に事務所として決めておきたい論点は三つあります。

第一に、IdPの管理権限を誰が持つかです。EMAは接続可否の判断をIdPの管理者に集約します。裏を返せば、IdPの管理者アカウントを握った人物は、事務所内のどのAI接続も開閉できることになります。この管理者アカウントを補助者に持たせるのか、有資格者に限るのか、二名体制にするのかは、事務所規程に書く価値のある論点です。

第二に、IdPそのもののログをどう保全するかです。公式ドキュメントは、コンプライアンス要件として、すべてのMCPサーバーアクセスについて監査可能な認可の記録が求められる場合をEMAの利用場面に挙げています。記録が残ることと、その記録を事務所が説明可能な形で保管していることは別の話です。保管期間、閲覧できる人、外部に提示するときの様式を先に決めておくと、顧問先から照会が来たときに慌てずに済みます。

第三に、EMA非対応のサーバーをどう扱うかです。国内の会計・労務系ベンダーがEMAに対応するまでの間、事務所には、IdPで集中管理できるサーバーと、従来どおり個別承認するサーバーが混在します。混在期間中は、後者について従来の運用ルールを維持する必要があります。EMAを入れたことで前者だけに目が行き、後者の点検が抜けるのが、いちばん起きやすい漏れです。

顧問先への説明という観点では、EMAの導入は事務所内でAIに触れられる範囲を狭くする方向の変更なので、説明の材料としてはむしろ使いやすいものです。ただし、どのサーバーに何のデータが流れるかを説明できなければ、権限を絞ったという説明だけでは足りません。事務所の入力ルールと合わせて示すのが実務的です。

導入で起きやすい三つのつまずき

一つ目は、IdPが実質的に機能していない状態での導入です。名目上はIdPを契約しているものの、職員が業務システムに個別のIDとパスワードで直接ログインしている事務所は少なくありません。この状態でEMAだけを入れても、IdPを迂回した経路が残るため、集中管理の前提が崩れます。先に、日常の業務システムのログインをIdP経由に寄せる作業が要ります。

二つ目は、権限の分け方が粗すぎて意味をなさないケースです。全職員を一つのグループに入れて全サーバーを許可すると、設定としては完了しますが、統制としては何も変わりません。逆に細かく分けすぎると、日常業務で「つながらない」が頻発し、職員が個人アカウントで迂回する動機を作ってしまいます。最初は職員区分を三つ程度に留め、運用しながら調整するのが現実的です。

三つ目は、検証を省いたまま本番投入することです。方針を書いたつもりで実際には適用されていない、という状態は、外形上は正常に見えるため気づきにくいものです。許可されていないはずの職員アカウントで接続を試み、拒否されることを確認する。この逆方向の検証を一度は通しておくことをおすすめします。

費用と工数、そして誰が担当するか

EMAそのものはMCPの拡張仕様なので、仕様の利用に費用はかかりません。費用が発生するのは、IdP側の契約と、対応クライアント・対応サーバーの利用契約です。既にMicrosoft 365やGoogle Workspaceを事務所で契約していれば、IDの基盤は手元にあることが多く、追加の契約なしに検討を始められる場合があります。Oktaのような専業のIdPを新規に導入する場合は、利用者数に応じた課金が発生します。

工数は、IdPが既に整っている事務所であれば、権限マトリクスの作成に半日から一日、設定と検証に一日程度が目安です。IdPが未整備の事務所では、日常ログインをIdPに寄せる作業が先に入るため、規模によっては数週間単位になります。ここは情報システムに明るい担当者か、外部のベンダーを入れる領域です。

担当については、設定作業と判断を分けて考えるのが実務的です。設定作業は補助者や外部ベンダーでも進められますが、どの職員区分にどのデータ源への接続を許すかという判断は、顧問先との守秘義務を負う有資格者が持つべき領域です。ツール選定時のセキュリティ認証の読み方はAIツール選定でセキュリティ認証をどう読むか 士業の9確認手順で整理しています。

MCPの企業向け整備がどこへ向かうか

EMAが安定版になったことで、MCPは、個人が試す規格から、組織が管理する規格へ一段階進みました。2026年7月28日版の仕様改訂で接続の扱いが大きく変わったことと合わせて見ると、企業利用を前提とした整備が続いていることが読み取れます。仕様改訂の内容はMCPが2026年7月に大改訂 事務所のシステム連携7つの実務影響で扱いました。

士業事務所にとっての論点は、国内の会計・税務・労務ベンダーがEMAに追随するかどうかです。現時点で公式ブログに名前が挙がっているサーバーは、プロジェクト管理やデザインのツールが中心で、日本の士業実務の中核システムは含まれていません。ここが対応しない限り、事務所の権限管理は当面のあいだ二重運用になります。ベンダーとの面談の際に、EMAへの対応予定を確認する項目を加えておくと、選定時の材料が一つ増えます。

もう一つの論点は、IdPの管理者権限が事務所内の新しい急所になることです。従来、事務所の情報管理の急所はサーバー室の鍵と顧客名簿でした。EMAを入れると、そこにIdPの管理者アカウントが加わります。この変化を規程に反映しないまま運用すると、統制の形は整っているのに、実質的な鍵が一人の担当者に集中している、という状態が生まれます。

よくある質問

企業管理型認可を入れれば、顧問先に「AIは安全です」と説明できますか

いいえ、それだけでは説明として不十分です。EMAは、どのMCPサーバーに接続できるかを事務所が一元管理する仕組みであり、接続した先でデータがどう扱われるかは各サーバーとAIベンダーのポリシーによります。顧問先への説明では、接続先の一覧、各接続先のデータ利用方針、事務所の入力ルールを合わせて示すのが実務的です。

職員が五名程度の事務所でも導入する意味はありますか

規模よりも、IdPが整っているかどうかで判断するのが現実的です。既にMicrosoft 365やGoogle Workspaceで職員のアカウントを一元管理しているなら、小規模でも導入の下地はあります。逆に、職員が各自のアカウントで業務システムに直接ログインしている状態であれば、EMAより先にログイン経路の整理から着手することになります。

対応しているMCPサーバーはどれくらいありますか

公式ブログは、安定版化の時点でAsana、Atlassian、Canva、Figma、Granola、Linear、Supabaseが対応済みで、Slackなどが対応を進めていると記載しています（出典: Model Context Protocol Blog）。日本の会計・労務系ベンダーの対応状況は公表資料からは確認できず、要確認です。

ID-JAGとは何ですか

ID-JAGとは、IdPが発行するアイデンティティ主張型のJWT認可グラントのことです。利用者がIdPにログインした際に得た本人性の証明を、MCPサーバーの認可サーバーに提示できる形に変換したものと考えると分かりやすくなります。この交換によって、利用者はサーバーごとの同意画面を経由せずにアクセストークンを得られます。

導入すると、職員が個人のAIツールを使えなくなりますか

事務所が管理するクライアントとサーバーの接続について、IdPが可否を判定するようになります。職員が私物の端末で個人契約のAIツールを使うこと自体を技術的に止める仕組みではないため、そちらは事務所規程と教育で対応する領域が残ります。規程の骨子は士業事務所のAI利用規程テンプレート 全10条の骨子と作り方の手順を参照してください。

退職者のアクセスは本当に一括で止まりますか

公式ドキュメントは、失効はIdPの側で行われ、すべてのMCPクライアントにわたって即時に効力を生じると説明しています。ただしこれはEMA経由で接続しているサーバーに限った話であり、EMA非対応で個別承認しているサーバーが残っていれば、そちらは別途解除する運用になります。解除手順書には、両方の経路を並べて書いておくのが安全です。

監査対応の資料としてどこまで使えますか

IdP側に認可の記録が残ることは、事務所の統制を説明する材料になります。ただし記録が残っていることと、必要な期間・様式で保管していることは別です。保管期間、閲覧権限、外部提示時の様式を事務所で定めたうえで、記録の実物を一度出力して確認しておくことをおすすめします。

参考文献

• Model Context Protocol「Enterprise-Managed Authorization」
• Model Context Protocol Blog「Enterprise-Managed Authorization: Zero-touch OAuth for MCP」（2026年6月18日）
• e-Gov法令検索 弁護士法第23条
• e-Gov法令検索 税理士法第38条
• e-Gov法令検索 個人情報の保護に関する法律第23条
• e-Gov法令検索 個人情報の保護に関する法律第26条
• modelcontextprotocol/ext-auth リポジトリ 仕様原文

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