INSIGHT
AIの接続先を増やす前に——接続先・権限・変更を管理する
つながること以外に、送り先・権限・変更をどう確かめるか。
AIに予定表、顧客台帳、ファイル保管、社内申請をつなげば、質問から操作までを一つの画面で進められる。接続規格としてMCPという名前を聞くことも増えた。だが、規格名が分かっても、どの事業者のどの入口へ接続し、誰の権限で、何を読み書きできるかは分からない。
新しい接続は、AIに機能を一つ足すだけではない。情報が渡る経路と、業務を変える操作の入口を増やす。さらに提供元がツールを更新すれば、最初に承認した範囲が知らないうちに変わる可能性がある。
接続の採否は規格名やツール名で決めない。接続先、認証に使う主体、許可する操作、送受信する情報、変更時の扱いを一接続ずつ確認する。
「つながる」を六つの事実へ分解する
接続を追加したいときは、まず次の六つを一枚にする。自分で分からない欄は、技術担当やデータ管理者への質問として残す。
- 提供者と所有者：接続機能を提供・保守する組織と、接続先のデータを管理する社内部門
- 入口：接続するサーバー名、URLや接続先識別子、本番・検証の区別
- 認証主体：個人アカウント、共有アカウント、サービス用アカウントのどれで動くか
- 権限：検索、閲覧、作成、更新、送信、削除、実行のどれを許すか。対象範囲はどこか
- 情報：AIから送る依頼・本文・添付・識別子と、接続先から返る内容
- 運用：記録の所在、設定変更者、停止方法、問い合わせ先
たとえば「予定表連携」でも、空き時間だけを読むのか、件名と参加者を読むのか、招待を作成・送信できるのかで影響は違う。「ファイル検索」でも、特定フォルダの閲覧と、全社領域の共有設定変更は同じ承認にできない。
ここではMCPか独自APIかを問わず、この六点を使える。技術担当が接続方法を説明し、データ所有部門が情報範囲を確認し、業務責任者が必要な操作を選ぶ。申請者の「便利になる」という説明だけで、使うアカウントや更新権限を決めない。
ツールの説明や注釈を、権限証明にしない
MCPのTools仕様 では、サーバーがツールの名前、説明、入力スキーマなどをクライアントへ提示し、AIが呼び出せる仕組みが定められている。実装側には、利用者が公開されるツールを理解できる表示や、操作を拒否できる関与を設けることが推奨されている。一方、利用者との確認方法を一つに定める規格ではない。
ツールには、読み取り専用か、破壊的か、同じ操作を繰り返せる性質か、外部へ到達するかを示す注釈が付くことがある。MCPの公式ブログ は、これらをリスクを話すための「ヒント」と説明する。同時に、注釈は動作を保証せず、信頼できないサーバーから来る場合は信頼できない情報として扱う必要があると明記している。
したがって、「read onlyと表示されたから安全」とは決められない。接続時に発行される権限、接続先の実際のAPI、試験で生じた変更、ネットワーク上の通信先を確認する。読み取り操作でも、顧客台帳の広い範囲を取得し、結果を外部へ返せるなら、情報の影響は小さくない。
説明、スキーマ、注釈は確認項目を作る材料である。実際のアカウント権限と動作試験の代わりにはならない。
最小のアカウントと操作から試す
検証用のアカウントと環境は管理担当と用意する。管理者個人のアカウントや、既存の共有アカウントをそのまま使わない。対象業務のための認証主体を決め、接続先のフォルダ、顧客群、予定表などを必要な範囲に絞る。作成と送信、更新と削除を分けられるなら、最初は影響の小さい操作だけを許す。
試すのは正常な呼び出しだけではない。対象外のデータを求めたときに拒否されるか、権限のない変更が止まるか、実行前に対象と変更内容が見えるか、接続を無効にした後に呼び出せないかを確認する。接続先から返った文章に別の操作を促す指示が含まれる場合も、許可外の操作へ進まないかを見る。
記録には、誰の認証で、どの接続先へ、どのツールと引数を送り、何が返り、何が変わったかを残す。ただし、ログへ顧客情報や認証情報を過剰に複製しないよう、記録項目と閲覧者を決める。異常時に見る人がログを開けない、または内容を解釈できないなら、「ログあり」を運用条件の達成に数えない。
追加と更新を、同じ変更手続に載せる
接続は導入後も変わる。ツールの追加、入力項目の変更、書込み機能の追加、認証範囲の拡大、接続先URLの変更、提供者や再委託先の変更があり得る。名前が同じツールでも、できる操作が変われば初回承認の前提は崩れる。
変更通知を受ける窓口を決め、変更前後の差分を六つの事実へ戻す。新しい情報を送るか、新しい対象を読めるか、書込み・送信・削除が増えたか、認証主体が変わるか、記録と停止方法が変わるかを見る。影響がある変更は、業務責任者、データ所有者、システム管理者が、利用範囲と試験を改めて承認する。
提供元の更新通知を受け取れない、または変更を止める設定がない場合は、その制約も承認資料へ載せる。使えるツールを固定・限定できるか、変化を検知したとき接続を止められるかを確認する。できない管理を「担当者が注意する」で置き換えず、許せる情報と操作を狭める判断につなげる。
Microsoft 365のエージェント用ツール管理の案内 は、MCPサーバーを組織へ追加する場面で、申請、審査、承認、権限、監視を管理する例を示している。プレビューなど提供条件や対応クライアントが明示される機能もあり、すべての製品や環境に共通する手順とは読めない。自社で申請から承認、公開、監視までの担当を考える参考にする。
初回承認は接続名に与える永久の許可ではない。接続先、情報、権限、提供者の差分が出たら、その差分を承認してから反映する。
一つの接続を追加する前に、止め方と相談先を確かめる
追加したい接続を一つ選び、対象業務、使う情報、必要な操作を記録する。そのうえで、認証主体、実行前確認、監視・変更通知の窓口、停止を判断する人を担当へ確かめる。不足があれば勝手に設定を補わず、検証用データだけにする、書込みを外すなど、試せる範囲を相談する。
停止を扱う担当は、接続設定を無効にするだけで終わらせない。発行済みの認証情報を失効させ、予定された処理を止め、接続によって作成・変更・共有された対象を確認する。保存済みの入力や出力、接続先の記録がどう扱われるかも見る。利用者には、止めた機能と代わりの業務手順を知らせる。
再開を判断する担当は、原因や変更点を特定し、権限を必要範囲へ戻し、問題となった動作を再試験し、ログと停止方法を確認してからにする。「提供元が直したと言った」だけでなく、自社の接続先、設定、認証主体に変更が反映された証拠を残す。
一つの接続ごとに、送り先・権限・変更を追える状態にする
AIの接続を管理するうえで、MCPという名前を知ることは入口にすぎない。判断に必要なのは、接続先はどこか、誰の認証で動くか、何を送り、何を読み書きし、誰が変更を止められるかである。
まず自分が追加したい一接続について、送り先、必要な情報と操作、不明な設定を一枚にしたい。権限の付与と試験環境は管理担当へ確認し、変更時の連絡先と止め方も聞く。つながった結果だけでなく、誰が変更を扱うかまで分かる接続にしていく。