MCPを一つ追加したとき、増えた権限を誰が確認するのか？
顧客対応AIへ新しい連携機能を追加するレビューで、開発チームは参照が便利になる変更だと説明します。事業部も、担当者の手間が減ることを期待しています。
ところが接続先を確かめると、情報の参照だけでなく、更新や出力に使える資格情報（接続時に使うIDやトークンなど）が必要になっていました。
これは、ツール追加を審査する架空の場面です。機能名が読取り用に見えることと、裏側で持つ権限が読取りだけであることは一致するとは限りません。
連携を一つ増やす変更を、接続先・操作・資格情報・データ移動が変わる変更として確認します。接続できたという技術的な結果の次に、何を許可したかを、業務と運用の責任者が説明できる状態が必要です。
MCPは、接続を整える仕組みである
MCPは、AIアプリケーションが外部のツールや情報へ接続するための共通の仕組みです。連携の方式を揃えることには意味があるが、採用しただけで接続先の安全性や、自社の許可条件がすべて決まるわけではありません。
同じ方式でつながっていても、実行するツールの機能、置かれる場所、使うID、取り扱う情報は異なります。検索だけをする連携と、顧客情報を書き換える連携では、確認すべき被害も違います。
冒頭のレビューで必要なのは、MCPだから安全か危険かを一括で判断することではありません。追加するものが、どの業務のために、誰の代理で、何に到達し、どんな操作を行うかを明らかにすることです。
MCPの公式文書も、資格情報の扱いや委任など、接続に伴うセキュリティ上の論点を整理しています。実装では採用する版と接続方式に対応する要件を確認する必要があります。
提供元、実行場所、データの行き先を分ける
ツールの提供元が確認できても、実際の実行場所や、その先の接続先が同じとは限りません。利用するアプリ、MCPサーバー、下流のAPI（システム同士がデータや機能をやり取りする接続口）、ログの保存先を区別して見る必要があります。
例えば、会員情報を照会する連携が、自社環境で動くのか、外部のサービスで動くのかによって、確認する契約や運用も変わります。資格情報をどこで管理し、誰が設定を変え、障害時に誰が止めるかを確かめておきましょう。
さらに、呼出しの結果がどこに残るかを見ます。AIに渡る結果だけでなく、ツール側の記録や、失敗時の出力に情報が保存される場合があります。すべての製品で同じ挙動をするとは限らないため、公式仕様と現在の設定を照合します。
委託先へ渡したデータがどこを通るかという、データの流れの把握が、ここでも役立ちます。契約先の名前に加え、実際の処理と保存がどこで起きるかを説明します。新しい台帳の数を増やすことより、既存の管理と接続をつなぐことが重要になります。
誰の依頼を、どのIDで実行するのか
接続できた後は、利用者の権限がどこまで引き継がれるかを確認します。利用者本人の権限で下流を使うのか、共通のサービスIDで動かすのかによって、必要な制約の置き方が変わります。
共通IDを使う構成でも、利用者と対象データを別の仕組みで拘束できる場合はあります。だから、共通IDがあることだけで直ちに不適切と決めません。一方、AIが本人の分だけを選ぶ指示になっていることを、アクセス制御の証拠にはしません。
公式のセキュリティ文書は、MCPサーバー向けに発行されたことを検証せず、受け取ったトークンを下流へそのまま渡す設計を禁止する対象として説明しています。ここでいうトークンは、アクセスの許可に使う資格情報です。単なる接続の便利さを優先せず、発行先や役割を確認する必要があります。
この点を、すべての接続で同じ認証方式を使うべきだという意味にはしません。利用する環境、方式、代理で動く範囲に応じて設計します。自社で独自の認証処理を安易に作るより、採用基盤の公式な方法と要件を確認する方がよいでしょう。
許可したツール名と、許可した操作は同じではない
ツールを使えるようにする承認は、具体的に何を許しているのでしょうか。顧客情報の一件参照なのか、広い条件での検索なのか、更新や外部出力まで含むのかを分けて考えましょう。
機能を大きくまとめると、導入は簡単になるかもしれません。しかし、その一機能へ与えた権限が広ければ、誤動作や不正な誘導が起きたときに届く操作も広がります。業務に必要な機能へ絞る設計を検討する理由になります。
冒頭の想定レビューでは、参照の改善のために更新まで可能な資格情報が必要なのかを問い直します。読取り専用の方式が選べるのか、対象を限定できるのか、機能を分けられるのかを確認します。
選べない場合は、その制約を明示します。名前を読取り専用へ変えて済ませず、権限を持つ場所と制限する場所、残るリスク、業務上の必要性を整理します。導入を決める人が、何を受け入れるかを理解できる必要があります。
更新で変わるものを、再び判断できるか
ツールの追加時に確認しても、その後の更新で提供機能や送信する情報が変わる場合があります。毎回、導入時と同じ内容で評価することはできません。
提供元の変更、接続先の追加、必要な資格情報の拡張、返す項目の増加、実行できる操作の追加などを、再確認の契機として決めておきます。何を変更と見なすかが決まっていれば、担当者も連絡しやすくなります。
逆に、すべての小さな修正を長い会議へ戻す必要はありません。業務被害や許可範囲を変える変更と、それらの前提を変えない変更を分けます。どちらと判断したかの理由を残せば、後から見直すこともできます。
自動更新を使う場合は、変更を誰が把握し、問題が出たらどこまで戻せるかを確認しておきましょう。更新を便利にする仕組みと、評価済みの構成を維持する仕組みを、両方考える必要があります。
使わなくなった連携を、誰が閉じるのか
接続の終了も管理対象です。AIの画面からツールを消しただけで、資格情報や下流の許可が失効したとは限りません。表示を外すことと、実際の経路を閉じることを分けて確認します。
担当者が異動したときや、検証を終えたときに、誰が資格情報を見直すかも決めます。所有者のいない連携が残ると、更新情報や不審な動作の連絡を受ける相手が曖昧になります。
終了時には、使えなくした機能、失効した資格情報、残る記録、必要な保存と削除を整理します。業務上の保存が必要な情報と、接続の継続が必要なことを同一にしません。
Deloitteも、エージェントのIDについて、継続的な把握、委任された権限、ライフサイクルを管理する考え方を示しています。AILとしては、製品の導入日だけでなく、変更と終了を同じ管理の流れへ入れることを提案します。
六つの項目が揃えば、レビューの問いが具体化する
新しい連携を申請するなら、最低限、次の内容を一枚にまとめられるとよいでしょう。
この表の目的は、すべての欄を問題なしで埋めることではありません。わからない部分を特定し、次に確認する相手と、導入の判断へ進める条件を決めることです。仕様上できない制約があれば、それも判断材料になります。
正常な一件が動いた結果に加え、対象外の利用者や操作が拒否される結果も確認します。検証は許可された環境で行い、必要なデータを用意します。接続先が対応している機能と、自社で設定した制約が一致するかを確かめておきましょう。
サーバーの設置場所で、確かめる境界も変わる
同じMCPという名称でも、手元の実行環境で動く接続部品と、外部のサーバーへ接続する方式では、運用上の確認が異なります。規格名だけで通信先や処理の範囲まで決まると思わず、自社で採用する構成を図にして確かめておきましょう。
手元で動く部品なら、どの実行主体で起動し、どのファイルや設定を読めるかを確認します。外部接続なら、誰が接続先を管理し、どこへ情報が送られ、障害時や契約終了時にどう切り離すかが論点になります。いずれも、業務データ側の認可（誰にどの操作を許すかの判断）が不要になるわけではありません。
冒頭の機能追加で、開発担当者が検証用に広い権限を設定していたとします。接続自体は成功しても、その設定を本番へ持ち込んでよいとは限りません。設定を引き渡す担当者と受け取る担当者の間で、検証用と本番用の違いを明示する必要があります。
さらに、提供元がツールの名称や説明を変えた場合も、単なる表示変更と決め付けません。AIがどのツールを選ぶかに影響する情報なら、従来と同じ業務条件で別の操作が選ばれないかを確認しておきましょう。説明の正しさと、実行時に強制される権限は別々の確認対象になります。
この確認を全機能で毎回やり直すと、変更を追えなくなることもあります。接続先、実行主体、許可操作、送信先のどこが変わったかを先に整理し、その変更が触れる経路を優先して再確認します。表示だけの修正と、新しい顧客情報へ届く変更を同じ負担にしない運用が現実的です。
追加を早めるために必要なのは、確認を省くことより、変わった境界をすぐ説明できる資料です。接続が成功した記録の横に、誰が何を許したかを残せれば、更新時の判断も引き継ぎやすくなります。
次の追加申請では、誰を会議に呼ぶか
冒頭の架空のレビューで、参照の改善に更新権限が必要だとわかったなら、開発担当者だけで判断を閉じない方がよいでしょう。対象データの所有者、操作を許す業務責任者、資格情報を管理する担当者を交えて確認します。
セキュリティ部門は、許可範囲と実装・証拠の整合を確かめます。事業部門は、機能の必要性と代替の作業方法を判断します。運用部門は、変更と停止を実行できるかを見ます。同じ会議に参加しても、担う判断は異なります。
最終的に導入する場合は、確認した構成と条件を残します。対象の版、接続先、許可する操作、例外、次に見直す契機がわかれば、後から増えた権限にも気付きやすくなります。
MCPを一つ増やすことは、単なる便利な設定の追加にとどまりません。自社のデータに届く経路を一つ増やす判断でもあります。
参考情報
公表情報の確認基準日：2026年10月22日。実装時は採用する版・方式・製品の公式要件を確認してください。レビュー場面と申請票はAILの想定・提案です。
AILのサービス・プロダクトについて
AILでは、人材育成、実践知の蓄積・活用、導入に向けたコンサルティング、プロダクトの提供を通じて、企業のAI活用を支援しています。自社の課題に合った支援を、サービス紹介ページでご覧いただけます。
AI Librariumについて
本記事は、AI Librarium（アイブリウム）株式会社が発信しています。
AILは、専門家の知見や判断基準を、実務で使えるAI Skillとして届け、研修やコンサルティングを通じて企業の業務変革を支援します。その実践で得られた成果や課題を、AI Skillの改善と人材育成に活かし、次の変革につなげていくことを目指しています。
