MCPを本番接続する前に何を確認する？

試験を始める前に、許可する操作だけでなく、禁止する操作、問題発生時に停止する対象、記録に残す項目まで決めます。

この事前条件がそろっていない接続は試験に進めません。条件がそろったら、ダミーデータで設計どおりに動くかを確かめます。

営業部が、AIアプリから顧客管理システム（CRM）の顧客一覧を表示できるよう、MCPで接続するケースを考えます。いきなり本番の顧客データへつなぐのではなく、まずダミーデータだけの試験環境と許可範囲を用意します。

準備ができたら、試験環境で「顧客一覧を表示して」と依頼します。一覧が表示されても、確認できたのは試験環境で接続・閲覧できたことだけです。禁止した更新や送信が拒否されるか、問題発生時に処理が止まるか、操作を追跡できるかも続けて検証します。

本記事でいう社内審査とは、集めた証拠を基に、本番利用へ進めるかを自社のルールで判断する手続きです。試験環境での接続成功はゴールではなく、その判断に必要な検証の開始点です。

本記事では、本番接続の前に次の5つを確認します。

1. 許可する操作と、拒否する操作
2. 誰の権限で、どの接続先まで使うか
3. 使う版と対応機能
4. 長時間処理を取り消した後、実際に処理が止まるか
5. 操作の追跡と、問題時の無効化

1つでも未確認または不合格なら保留します。5つすべてに証拠がそろった場合だけ、社内審査へ進めます。

試験を始める前に、業務担当、システム担当、セキュリティ・審査担当の役割を分けます。

この3者は証拠を確認する担当です。証拠をまとめて審査へ提出する担当と、最終承認者は、自社のルールに従って試験前に決めます。

担当を決めたら、次に試験環境と合格条件を用意します。以下は設定例です。本番の顧客や宛先を使わず、失敗しても戻せる状態で試します。

ここでいう5秒は、取り消し要求を受け付けてから、CRMの更新やメール送信などの実際の処理が止まるまでの上限時間です。本記事の例では、その時間を5秒以内と決めています。5秒はMCPの公式基準ではなく、自社で試験前に決める合格条件の一例です。実際の上限時間は、処理が続いた場合の影響と自社システムの構成に合わせて決めます。

閲覧試験に続けて、CRMの更新試験を行います。顧客一覧を閲覧できたことは、顧客情報を更新してよい根拠にはなりません。

まず、許可する操作と禁止する操作を一覧にします。閲覧できる項目は、顧客名と担当部署だけに限定します。氏名の変更、全件出力、外部送信は拒否します。

次に、更新試験用のダミー顧客について、担当部署だけを変更します。氏名や連絡先、対象外の顧客まで変更できた場合は、権限が広すぎます。

最後はメール送信です。社内のテスト用宛先1件だけを許可し、別の宛先や一括送信は拒否します。影響が大きい操作ほど、許可した操作が成功した記録と、禁止した操作が拒否された記録の両方を残します。

許可範囲の名前より、実際の動きを見ます。 scope（スコープ）と呼ばれる許可範囲の名称は、システムごとに意味が異なる場合があります。「read」という名前だけでは、閲覧だけか、全件出力も含むかは分かりません。

権限だけでなく、どのAIアプリが接続しているかも確認します。アプリを見分ける公開識別子（client_id）は名札に近い情報であり、パスワードではありません。そのため、この情報だけで正規のアプリだとは確認できません。接続時に送られたclient_idとリダイレクト先を、認可サーバーに登録されているアプリ情報と照合します。

業務担当が、許可する操作と禁止する操作の一覧を作ります。システム担当は、同じ利用者と接続先で、許可する操作と禁止する操作の両方を試します。拒否応答だけでなく、CRMや送信待ち行列に影響がないことも確認します。

ここで参照する「仕様」は、接続方法を定めた公式文書です。 2026-07-28版の認可仕様は、MCP公式仕様のうち、HTTPで接続するときの認可方法を定めた章です。「2026-07-28」は記事の更新日ではなく、使用する仕様版を見分けるための日付です。

本記事で「MCP公式」と呼ぶのは、MCPプロジェクトが公開する仕様や文書です。MCPは特定企業だけの製品仕様ではなく、LF Projects, LLC傘下のプロジェクトです。複数のメンテナーが公開された運営ルールに基づいて仕様を管理しており、運営体制と現在の担当者は公式のMCPガバナンスで確認できます。

RFCは、インターネット技術の仕様を公開・保存する文書シリーズです。 OAuth 2.0は、パスワードそのものを相手に渡さず、必要な範囲のアクセス権を委ねるための仕組みです。OAuth 2.0の基本仕様（RFC 6749）は、認可に関わる役割と処理の流れを定めています。アクセストークンの利用方法（RFC 6750）は、アクセストークンをHTTP通信で送る方法を定めています。どちらもIETFの標準化プロセスで作られ、RFC Editorが公式文書として公開しています。

残す証拠は、許可した操作の成功結果と、禁止した操作の拒否結果です。

承認は「この業務で使ってよい」と人が決めることです。認可は「この利用者やシステムに、この接続先で、この操作を許す」とシステムが決めることです。

HTTPで認可を行う場合は、OAuthを使うことがあります。

MCPクライアントは、利用者の依頼を通信に変えるAIアプリ側です。MCPサーバーは、その通信を受けてCRMやメール基盤へつなぐ側です。

一覧を読む権限は、CRMを書き換える権限ではありません。CRMの更新を承認したからといって、顧客へのメール送信まで承認したことにはなりません。場面が変わるたびに、利用者・システムと接続先を見直します。

電子的な通行証の行き先を確かめます。 たとえば、CRMの閲覧用に発行されたアクセストークンが、別のMCPサーバーやメール送信に使えてはいけません。認可では、接続先を示すresourceと、トークンの利用先を示すaudienceを確認します。

比喩だけで判断せず、実際の通信を試します。MCPサーバーが正しい接続先向けのトークンを受け入れ、別の接続先向けのトークンを拒否することを確認します。

MCPサーバー向けのアクセストークンを、CRMやメール基盤のAPI（システム同士の接続口）へそのまま転送してはいけません。接続先システムには、その接続先専用の資格情報か、組織が認めた代理アクセス方式を使います。

接続先の指定は接続先を指定する方法（RFC 8707）を参照します。利用者・システムと接続境界は2026-07-28版の構成仕様で確認します。CRMやメール基盤への転送の注意はセキュリティの公式解説にあります。

企業のID管理でMCPサーバーへのアクセスを一元管理する拡張（Enterprise-Managed Authorization）は、公式ブログで安定版と発表されています。ただし、この拡張は任意であり、MCPクライアントとMCPサーバーの両方が対応しているかを確認します。

残す証拠は、承認内容、認可結果、利用者、接続先を相互に結び、後からたどれる記録です。

使用しているMCP仕様の版によって、確認方法が異なります。最初に、AIアプリとMCPサーバーが採用している仕様の版と、必要な機能への対応状況を確認します。

使用しているMCP仕様が2026-07-28版の場合、各処理依頼（要求）が仕様の版を示します。MCPサーバーは、要求ごとに受け入れるか拒否するかを決めます。

MCPサーバーの対応機能を事前に問い合わせる仕組み（server/discover）も使えます。ただし、最終判断には実際に使う要求と応答を記録します。

使用しているMCP仕様が2025-11-25版以前の場合、初期化時のやり取りで版を決めます。本記事では、2026-07-28版の方式を「新方式」、2025-11-25版以前の方式を「旧方式」と呼びます。自社環境がどちらを使っているかを確認し、新方式では要求ごと、旧方式では初期化時の記録を残します。

閲覧の成功を、更新や送信の証拠にしません。 顧客一覧の要求が受理されても、CRM更新の要求まで受理されるとは限りません。メール送信は、さらに別の要求です。

本記事では、顧客一覧の閲覧、CRMの更新、メール送信という3つの利用場面で確認します。利用場面ごとに版と対応機能を記録し、接続全体に1つの版を書くだけで済ませてはいけません。

確認方法は版管理の仕様を主根拠にします。変更内容は公式の変更点一覧でも確認します。非推奨機能一覧の「最短削除可能日」は、最も早く削除され得る日であり、実際の削除日を示すものではありません。

残す証拠は、新方式なら要求ごとの版と応答、旧方式なら初期化時の要求と応答です。

顧客一覧がすぐ表示されたとしても、大量検索は長く続くことがあります。CRMの一括更新やメール送信では、取り消し後もCRMやメール基盤で処理が続く可能性があります。

時間のかかる処理では、まず取り消し後にCRMやメール基盤の処理が止まったかを確かめます。MCPには、このような処理の状態確認や取り消しに使える任意の拡張機能（Tasks）があります。詳細仕様は草案（Draft）で、利用にはMCPクライアントとMCPサーバーの両方の対応が必要です。

Tasksを使う場合、処理をタスクとして返すかはMCPサーバーが要求ごとに決めます。MCPクライアントは、通常の結果とタスクの結果の両方を処理できる必要があります。

取り消し要求に受付応答が返っても、停止は保証されません。タスク情報や結果の保存期間（ttlMs）は、処理そのものの期限ではありません。

実際に処理が止まるかを、3つの利用場面で確かめます。 閲覧では、画面だけでなくCRMの検索も止まったかを見ます。CRM更新では、更新済み件数と未処理件数を分けて確認します。必要なら元に戻す方法も決めます。

メール送信では、取り消し後に新しい送信が待ち行列へ入らないことを確認します。すでに送信した件数と、まだ送っていない件数も分けて確認します。

タスクの状態表示だけで判断を終えません。実際の処理、CRMやメール基盤の内部で動く処理（ジョブ）、待ち行列、外部への影響を同じ時系列で確認します。

流れはタスク機能の概要で確認します。詳細はタスク機能の草案として読みます。

残す証拠は、取り消しの受付から、実際の処理とCRM・メール基盤への影響が止まるまでの時系列です。

利用者のアカウントを停止しても、発行済みのアクセストークンが有効なまま残る場合があります。さらに、実行中のタスクが続いたり、CRMやメール基盤の資格情報が引き続き有効だったりする可能性があります。

本記事では、問題時に止める対象と確認内容を「停止確認の5項目」として、次のように分けます。

1. 利用者のアカウントを停止します。
2. 付与済みの認可を取り消します。
3. 新しいアクセストークンの発行に使う更新用トークン（refresh token）と、アクセストークンそのものが、それぞれ無効になったかを確認します。
4. アカウント停止・認可取り消し後の新しい要求を拒否できるか試します。
5. 実行中の処理を停止できるか、CRMやメール基盤の資格情報を無効化できるか試します。

トークンを取り消す方法（RFC 7009）に基づく取り消しでも、反映までに時間がかかる場合があります。即時にすべてが止まると決めつけず、「停止確認の5項目」ごとに結果を確認し、記録します。

依頼から結果までを一本につなぎます。 同じ操作について、複数システムの記録を結ぶ相関IDを1回の操作ごとに付けます。利用者の依頼、社内承認、認可判断、MCPの要求、CRMやメール基盤の結果を結びます。

閲覧では、誰が何件を見たかまで追います。CRM更新では、更新前後の値を追います。メール送信では、承認から送達結果までを追います。

トークンの値、顧客データ本文、秘密情報はログへ残しません。操作した利用者・システム、対象、操作、時刻、判断、結果だけを自社方針に沿って残します。

NIST SP 800-207は、システム境界と継続的な確認方法を設計する際の参考にします。MCPへの適合はMCP仕様で、接続設計の安全性は本番と同等の構成を再現した安全な試験環境で確認します。

残す証拠は、相関IDで結んだ操作履歴と、「停止確認の5項目」の試験結果です。

5つの確認項目を合計点で採点するのではありません。1つでも未確認または不合格なら保留し、すべてに証拠がそろった場合だけ社内審査へ進めます。

本記事の例では、顧客一覧の閲覧、CRMの更新、メール送信の順に影響範囲が広がる想定です。前の場面で合格しても、次の場面へ証拠をそのまま持ち越しません。

5項目はいずれも省略できません。未確認や不合格の項目は、その内容を保留理由として記録します。

最後に、読了後すぐに着手する作業を3つに絞ります。

1. 自社の接続計画と安全な試験環境について、5つの確認項目のうち未確認の項目を洗い出します。本番環境や実在する顧客データは使いません。
2. 未確認項目ごとに、確認する担当者と期限を決めます。
3. 不足が残れば保留し、証拠がそろえば社内審査へ進めます。

判断基準は、「つながったか」ではなく、意図した範囲で動き、止まり、追える証拠があるかです。

2026年8月31日時点で、MCP公式仕様・公式拡張仕様・OAuth関連RFC・NIST資料を照合しました。これらは仕様や設計の確認に使う一次資料であり、自社環境の安全性や本番利用の許可を確定するものではありません。

1. MCP Specification 2026-07-28
2. 2026-07-28版の認可仕様
3. 版管理の仕様
4. MCP 2026-07-28版の主な変更点
5. 2026-07-28版の構成仕様
6. MCP セキュリティの公式解説
7. MCP 非推奨機能一覧
8. MCP タスク機能の概要
9. MCP タスク機能の草案
10. RFC 6749
11. RFC 6750
12. RFC 8707
13. MCP Enterprise-Managed Authorization
14. MCP 2026-07-28版の公式発表
15. RFC 7009
16. NIST SP 800-207
17. NIST SP 800-53

仕様や公式資料があることだけでは、自社環境の安全性や本番利用の許可は確定しません。MCPへの適合はMCP仕様で確認します。接続設計の安全性は本番と同等の構成を再現した安全な試験環境で検証し、本番利用は社内審査で判断します。