MCPセキュリティ要件とは、外部AI連携の接続審査基準のことです。

事務所がMCP経由で外部のAIツールと接続するとき、確認すべきは認可の方式と暗号化、そしてどこまでの権限を渡すかです。この記事では、OAuth2.1やPKCE、権限の範囲設定といった技術的な論点を、事務所が接続審査に使える7項目に整理します。本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、行政の見解は各府省庁の公表資料で確認しています。MCPの公式仕様は2025年6月18日版から2026年7月28日版にかけて認可まわりの記述を大きく増やしています。事務所側が押さえるべき点も増えています（出典: Model Context Protocol Authorization）。

MCPの認可仕様を取り巻く2026年の状況

MCPの公式仕様は、HTTPベースの通信を使う実装について、認可サーバがOAuth 2.1を実装することを求めています。クライアントとリソースサーバの役割分担も明記されています。MCPサーバはOAuth 2.1のリソースサーバとして振る舞い、MCPクライアントはOAuth 2.1のクライアントとして振る舞う構造です（出典: Model Context Protocol Authorization）。

2026年7月28日版では、認可サーバの発見手段としてOAuth 2.0 Authorization Server Metadata（RFC8414）に加えてOpenID Connect Discoveryのどちらか一方を実装することが求められる形に変わりました（出典: Model Context Protocol Authorization）。クライアント登録の方式も変わっています。動的クライアント登録（RFC7591）は後方互換のために残しつつ、Client ID Metadata Documentsという新しい方式が優先される建て付けです。

権限の範囲を示す仕組みも整理されました。MCPサーバは401応答のWWW-Authenticateヘッダに必要なスコープを含めることが推奨され、403応答でも不足しているスコープを示す仕組みが定義されています。クライアントは一度に必要なスコープをまとめて要求し、段階的な認可の往復を減らすことが求められています（出典: Model Context Protocol Authorization）。

一方で、通信経路の暗号化については、仕様が求めているのは認可サーバの各エンドポイントをHTTPSで提供することと、リダイレクトURIをlocalhostまたはHTTPSに限定することです。相互TLS（mTLS）という語自体は、MCPの公式仕様の本文には登場しません。事務所が導入検討先のベンダー資料でmTLSを見かけた場合、それは仕様が定める最低限の要求ではありません。ベンダーが自社のゲートウェイやエンタープライズ向け接続に、追加で載せている保護層だと理解しておくと、確認の的が外れません。士業のチカラではMCPのSTDIO設計欠陥についても整理しましたが、通信経路の前提はトランスポートの種類によって変わる点は共通しています。

権限の粒度についても、仕様は最小限のスコープ設計を促す方向に寄っています。認可サーバが提示するscopes_supportedは、基本機能に必要な最小限のスコープ集合を示す位置づけです。追加の権限は、運用中に段階的に要求する仕組み（ステップアップ認可）で補う設計になっています。クライアントは直前の認可要求と、今回不足していると言われたスコープの和集合を計算してから再認可に進むことが求められています（出典: Model Context Protocol Authorization）。事務所からすると、最初から広いスコープを一括で許可する設計より、必要になったときに追加で許可を求めてくる設計のほうが権限を見直しやすいという特徴があります。導入検討時にこの段階的な認可の仕組みに対応しているかを聞いておくと、後述するスコープ設計の確認がしやすくなります。

接続審査で確認する7つのチェック項目

ここからは、事務所がベンダーへの質問リストとして使える7項目です。確認の相手は自分の事務所ではなく、接続しようとしているMCPサーバの提供元です。手順の最後には、有資格者が最終確認する工程を置きます。

第一項目は、対応している仕様バージョンと認可の実装状況です。提供元が2026年7月28日版のOAuth 2.1準拠で動いているか、それとも旧版のままかを聞きます。旧版のままだと、後述するPKCEやリソースインジケータの扱いが古い可能性があります（出典: Model Context Protocol Authorization）。

第二項目は、PKCEの実装です。MCPクライアントは認可コードの横取りを防ぐため、OAuth 2.1のセクションに沿ってPKCEを実装することが求められています。事務所側で直接コードを書くわけではありませんが、利用するAIツールのベンダーが自社製MCPクライアントでPKCEを実装しているかは確認材料になります（出典: Model Context Protocol Authorization）。

第三項目は、リソースインジケータ（RFC8707）によるトークンの対象限定です。MCPクライアントは認可リクエストとトークンリクエストの両方に、接続先MCPサーバの正規URIを示すresourceパラメータを含めることが求められています。これにより、あるサーバ向けに発行されたトークンが別のサーバで使い回される事態を防ぐ設計です（出典: Model Context Protocol Authorization）。事務所としては、接続先が複数のMCPサーバを跨いでトークンを使い回していないかを聞く材料になります。

第四項目は、スコープの設計単位です。MCPサーバが持つ機能はtools・resources・promptsという単位（ケイパビリティ）に分かれています。この単位ごとに読み取り専用のスコープと書き込みを伴うスコープを分けて発行できるか、それとも全機能まとめて一つのトークンでしか渡せないかを確認します。分けられない実装だと、事務所側でできる対策は接続そのものを業務単位で分割することくらいです。士業のチカラではAIエージェントの実行制御についても整理しましたが、権限は配る前に区切っておくほうが後の見直しが楽になる点は、MCPのスコープ設計でも共通しています。会計ソフト連携のMCPサーバであれば、残高照会は読み取り専用スコープ、仕訳の登録は書き込みスコープというように分けます。日常業務でログインする担当者には読み取り専用のスコープだけを割り当てておくと、誤操作や権限の過剰付与を避けやすくなります。文書管理システムに接続する場合も、顧問先単位でフォルダを分け、スコープをフォルダ単位で発行できるかを聞く価値があります。

第五項目は、追加のトランスポート層保護です。先述のとおりmTLSはMCP仕様の必須要件ではありませんが、顧問先データを扱う事務所向けの接続では、ゲートウェイ側で相互TLSやIP制限を追加提供しているベンダーもあります。提供元にオプションの有無を聞き、あれば適用範囲（全接続か、特定プランのみか）を確認します。

第六項目は、トークンの有効期間と失効の運用です。仕様は、漏えいの影響を抑えるために認可サーバが短命なアクセストークンを発行することを推奨しています。事務所側で確認すべきは、担当者が退職・異動したときにトークンやリフレッシュトークンをどう失効させるか、その操作を誰が行えるかです（出典: Model Context Protocol Authorization）。

第七項目は、有資格者が最終確認する工程です。ここまでの技術確認はシステム担当者や外部ベンダーとのやり取りで進められますが、どの業務データにどこまでのスコープを渡すかという最終判断は、担当の有資格者が確認する工程を手順に組み込みます。技術要件のチェックリストが埋まっていても、業務上渡してよいデータの範囲を決めるのは有資格者の役割です。具体的には、システム担当者が7項目の確認結果をまとめたシートを作ります。有資格者がそのシートを見ながら、この顧問先のこの業務データは渡してよいかを業務単位で判断する、という二段階の運用が現実的です。技術確認と業務判断の担当を分けておくと、どちらか一方が欠けた状態で接続が進んでしまう事態を防ぎやすくなります。

以下は、ChatGPT・Claude・Geminiでこの7項目を整理する際に使えるプロンプト例です。

あなたは士業事務所のIT担当者です。以下のMCPサーバ提供元からの回答をもとに、
「MCP接続セキュリティ確認7項目」（仕様バージョン/PKCE/リソースインジケータ/
スコープ設計/追加のトランスポート層保護/トークン有効期間と失効/
有資格者確認工程）に沿って、未確認の項目と、次に質問すべき内容を箇条書きで
整理してください。断定的な評価はせず、確認できた事実と未確認の事実を分けて
出力してください。

【提供元からの回答】
{ベンダーからの回答テキストを貼り付け}

以下は当事務所がMCP経由で外部AIツールに接続する際の権限スコープ案です。
tools/resources/promptsの単位ごとに、読み取り専用と書き込みありを分けて
整理し直してください。顧問先ごとに分離できる設計かどうかも論点として
挙げてください。実在する顧問先名は使わず、A社・B社のような仮名で構いません。

【現在のスコープ案】
{現在の権限設計を貼り付け}

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

MCP経由で顧問先の資料をAIツールに渡す場合、守秘義務との関係を事前に整理しておく必要があります。ここでは3つの論点に分けます。

一つ目は、接続先ベンダーのデータ利用ポリシーです。たとえばAnthropicは、商用APIやエンタープライズ向け製品からの入出力について、既定ではモデルの学習に使用しないと説明しています。ただし利用者が明示的にフィードバックを送った場合など、例外にあたるケースがあることも合わせて記載されています（出典: Anthropic Privacy Center）。無料版と商用版でポリシーが分かれている点も含め、接続先ごとに個別に確認する必要があります。

二つ目は、士業ごとの守秘義務の根拠条文と、個人情報保護法側の制限です。弁護士は弁護士法第23条に基づき、職務上知り得た秘密を保持する権利と義務を負います。税理士は税理士法第38条により、正当な理由なく業務上知り得た秘密を漏らし、または窃用してはならないと定められています。個人情報の側では、個人情報保護法第27条が第三者提供の制限を定めています。接続先MCPサーバが外国にある場合は、個人情報保護法第28条の外国にある第三者への提供の制限も論点になります。MCPサーバの運用元がどの国のインフラを使っているかは、接続前に確認しておく事項です。

MCP接続の場合、この論点が通常のクラウドサービス利用と比べてやや見えにくくなる点に注意しておきます。事務所が直接契約しているのはAIツールのベンダーでも、MCPサーバ自体は別の会計ソフト会社や文書管理システム会社が提供しているという構成が珍しくありません。データが実際にどの事業者のサーバを経由するのかを、AIツールとMCPサーバの両方について確認しておかないと、第三者提供や外国提供の論点を見落とすことになります。接続構成図を書き出し、どの区間で誰のサーバを経由するかを可視化しておく作業は、規程を作る前段階として有効です。

三つ目は、顧問先への説明と同意取得の実務です。個人情報保護委員会は2023年6月2日、生成AIサービスの利用に関する注意喚起を公表し、事業者が生成AIサービスに個人情報を含むプロンプトを入力する場合の留意点を整理しています（出典: 個人情報保護委員会 生成AIサービスの利用に関する注意喚起等について）。MCP接続でも構図は同じで、顧問先データを外部のAIツールに渡す前に、顧問契約書や別途の同意書でどこまで説明済みかを事務所内で確認しておく価値があります。

事務所規程に落とし込むなら、接続審査7項目の確認結果を記録する台帳を作り、接続先ごとに対応バージョン・スコープ設計・トランスポート層の追加保護の有無・トークン失効の担当者を一覧にしておく運用例が考えられます。規程の文言自体をどう書くかは各事務所の判断であり、この記事はその運用例を示すにとどめます。

MCP接続でよくある失敗例と回避策

一つ目は、スコープを絞らずに全ケイパビリティを一括で許可したケースです。tools・resources・promptsをまとめて一つのトークンで渡す設計のまま導入し、退職した担当者のアカウントに紐づく認可情報が失効されずに残っていたという報告があります。回避策は、導入時点でスコープを分割できる実装かどうかを確認し、退職・異動のたびに失効作業を行う担当者をあらかじめ決めておくことです。

二つ目は、PKCEに対応していない古いMCPクライアントをそのまま使い続けたケースです。仕様の版が上がっても、社内で使っているツールのバージョンが古いままだと、新しい認可の保護策が効きません。回避策は、接続前に確認した仕様バージョンを台帳に記録し、ベンダー側のアップデート通知を定期的に確認する運用を組み込むことです。

三つ目は、海外にサーバを置くMCP提供元に顧問先データを流したものの、個人情報保護法第28条の外国にある第三者への提供に関する同意取得を後回しにしていたケースです。回避策は、接続先のインフラがどの国にあるかを事前確認の項目に加え、該当する場合は同意取得のフローを先に固めてから接続することです。

四つ目は、複数のAIツールベンダーが同じMCPサーバに接続する構成で、どのベンダーがどのスコープを持っているかを事務所側で把握していなかったケースです。ベンダーが増えるたびに接続を追加していくと、台帳の更新が追いつかなくなりがちです。回避策は、接続先を追加するたびに台帳へ記録する作業をルーティン化し、四半期に一度など定期的な棚卸しのタイミングを決めておくことです。

費用・工数・体制

MCP接続のセキュリティ確認そのものに追加のライセンス費用はかからないことが多いですが、確認作業の工数は見込んでおく必要があります。7項目をベンダーに質問し、回答を台帳にまとめる作業は、1接続先あたり数時間程度を見込む事務所が一般的です。トランスポート層の追加保護（mTLSなど）をベンダーがオプション提供している場合、プランによって追加費用が発生することがあるため、料金表の確認も合わせて行います。

体制面では、技術的な確認をシステム担当者や外部のIT顧問が行い、渡してよいデータ範囲の最終判断を有資格者が行うという役割分担が現実的です。小規模な事務所では、所長自身がこの両方を兼ねることもありますが、その場合でも技術確認と業務判断を意識的に分けて記録しておくと、後から振り返りやすくなります。

接続先が増えるほど、台帳の維持にかかる工数も積み上がります。接続先ごとに7項目の確認シートを作るだけでなく、仕様バージョンが更新されたタイミングで再確認する運用まで含めて工数を見積もっておくと、誰も見直していない接続が放置される事態を避けやすくなります。

仕様が動き続ける前提で何を固めておくか

MCPの認可仕様は2025年6月18日版から2026年7月28日版にかけて、発見手段や登録方式、スコープの扱いまで継続的に更新されています（出典: Model Context Protocol Authorization）。仕様書自体も、今後iss パラメータの扱いをSHOULDからMUSTへ引き上げる予定があると明記しており、事務所側が一度固めた確認項目も定期的な見直しが必要になります。

事務所として固定しておくべきは、個別の技術詳細そのものではなく、確認する項目のフレームワークです。仕様バージョン・認可方式・スコープ設計・トランスポート層の保護・トークン管理・有資格者確認工程という7つの軸は、細部が変わっても審査の型として使い続けられます。IPA（独立行政法人情報処理推進機構）も2026年7月公表の手引書で、外部ツール連携時の権限制御をAIエージェント導入の技術検証項目として挙げており、接続先制御と利用制限の整備を求めています（出典: IPA 生成AI及びAIエージェントを安全に活用するための手引書）。事務所独自の審査項目を作るより、こうした一次情報の更新を定期的に追いかける体制を作るほうが、長期的には工数を抑えられます。外部のMCPサーバをどう選ぶかという観点は、士業のチカラのMCPの仕様は誰がどう決めるのかでも整理しているので、接続先選定の段階から合わせて確認しておくと審査の抜けを減らせます。

よくある質問

MCPのセキュリティ要件はどこで確認できますか

一次情報としては、公式仕様のAuthorizationページが最も詳しく、OAuth 2.1・PKCE・リソースインジケータなどの要求事項がまとまっています。ベンダー資料だけで判断せず、この一次情報と突き合わせる確認作業が有効です。

OAuth2.1とPKCEはいつ必要になりますか

MCPの公式仕様は、HTTPベースの実装で認可を使う場合に認可サーバがOAuth 2.1を実装することを求め、MCPクライアントにはPKCEの実装を求めています（出典: Model Context Protocol Authorization）。ただしSTDIOトランスポートなど、この仕様に従わない実装形態もあるため、接続方式ごとに確認する必要があります。

mTLSはMCPの標準機能ですか

MCPの公式仕様本文にmTLSという語は登場せず、仕様が求めているのはHTTPSによる通信の保護です。mTLSを提供しているベンダーは、独自のゲートウェイやエンタープライズプランに追加で載せている保護層である場合が多いため、標準機能かオプションかを個別に確認する価値があります。

ケイパビリティスコープとは何を指しますか

MCPのtools・resources・promptsという機能単位（ケイパビリティ）ごとに、アクセス範囲を分けて権限を設計する考え方を指します。この記事では、接続審査の第四項目としてスコープの設計単位を確認することを挙げています。

顧問先データをMCP経由で外部AIに渡すのは守秘義務に反しますか

一律の結論は出せず、接続先のデータ利用ポリシーと、顧問先への説明・同意の状況によって論点が変わります。弁護士は弁護士法第23条、税理士は税理士法第38条の秘密保持義務との関係を、個人情報を含む場合は個人情報保護法第27条の第三者提供制限との関係を、それぞれ整理しておく論点になります。

小規模な事務所でも7項目すべて確認する必要がありますか

事務所の規模にかかわらず、確認する項目自体は変わりません。ただし確認にかける時間配分は規模に応じて調整でき、小規模な事務所では所長が技術確認と業務判断を兼ねて短時間で回すことも可能です。

トークンの有効期限はどのくらいが目安ですか

具体的な期間はベンダーの実装によって異なり、この記事で一律の数値を示すことはできません。仕様は漏えいの影響を抑えるために短命なトークンの発行を推奨しているため（出典: Model Context Protocol Authorization）、接続先に発行期間の方針を確認する項目として持っておくとよいです。

仕様が今後変わったら、どう追随すればよいですか

公式仕様のページを定期的に確認し、バージョン表記の更新有無をチェックする運用が基本です。この記事の7項目のフレームワーク自体は、細部の仕様変更があっても審査の型として使い続けられます。

参考文献

• Model Context Protocol Authorization（2026-07-28版）
• e-Gov法令検索 弁護士法
• e-Gov法令検索 税理士法
• e-Gov法令検索 個人情報の保護に関する法律
• 個人情報保護委員会 生成AIサービスの利用に関する注意喚起等について
• IPA 生成AI及びAIエージェントを安全に活用するための手引書（2026年7月）
• Anthropic Privacy Center データの学習利用に関する説明

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