MCPで外部とつなぐ前の確認項目一覧｜権限を絞る決め方

「業務のデータにAIから直接つなぎたい、と現場から申請が来た。何を確認して可否を返せばよいのか」「つないだ後に何が起きるか分からないので、いまは全部断っている」——情報システム部門に届く相談は、この両極に割れます。判断がつかないのは担当者の知識不足のせいではありません。本当は、つないだ瞬間にAIの側で何ができてしまうかが、接続の設定画面を見ただけでは分からないからです。実際、2026年5月に公表された測定研究は、稼働している遠隔の接続先7,973件のうち40.55%が認証なしで道具を外に出していたと報告しています。この記事では、AIを社内ツールや外部サービスにつなぐ規格について、つなぐ前に確かめる項目、権限の絞り方、つないだ後に残す記録、止め方までを順に整理します。

申請を受けたとき、何を根拠に可否を返すか

まず現状の数字を置きます。2026年5月に公開された測定研究は、稼働している遠隔の接続先7,973件を特定し、そのうち40.55%が認証なしで道具を公開していたと報告しました。さらに、委任型の認可を使っていて実際に試験できた119件を調べたところ、全件が1つ以上の不備を抱えており、不備は合計325件、そのうち接続する側がその場で自分を登録できる仕組みに関する不備が96.6%の接続先に影響していました。

この数字は「危ないからやめよう」の根拠ではありません。読み取るべきは別のことです。不備の大半は製品としての作りの良し悪しではなく、認証をかけているか、権限をどこまで渡しているか、登録と同意の手続きをどう組んでいるかという接続の設計の側に集中しているという点です。審査の焦点は、製品の評価ではなく接続の設計に置くべきだ、と数字が示しています。

だから可否は「この製品は安全か」ではなく、3つの問いで返します。この接続で何ができてしまうのか。その操作は誰の名義で実行されるのか。実行した記録はどこに残るのか。この3つに答えられない申請は、製品がどれだけ有名でも通せません。逆に、3つに答えられるなら、無名の接続先でも範囲を絞って通せます。

つなぐと何ができてしまうのか

規格の構造を、審査に必要な範囲だけ押さえます。登場するのは3者です。AIを載せたアプリ、そのアプリの中で接続を担う部分、そして機能を提供する側。機能を提供する側が外に出すものは3種類あります。読ませるためのデータ、定型の指示文、そしてモデルが実際に呼び出せる道具です。審査で数えるのは、この3つ目です。

仕様は道具の危険性をはっきり書いています。「道具は任意のコード実行を意味するので、相応の注意をもって扱わなければならない」という原則が置かれ、あわせて「利用する側は、どの道具を呼び出す場合も明示的な同意を得なければならない」とされています。つまり、道具の一覧がそのまま、この接続でできてしまうことの一覧です。一覧が出せない申請は、その時点で差し戻します。

流れは片方向ではありません。機能を提供する側から、接続を担う側に依頼できる機能もあります。モデルへの問い合わせを依頼する、作業してよい範囲を尋ねる、利用者に追加の入力を求める、といったものです。仕様は、利用者が問い合わせの有無・送られる文面・提供側が見られる結果を制御できるべきだと書いています。外へ出ていく情報の経路が増えるのは、この裏向きの機能のほうです。

審査の前に決めておく2つの線

個別の申請を見る前に、部門として2本の線を引いておきます。1本目は情報の区分です。社外に出してよい情報、社内限りの情報、限られた担当だけが触れる情報の3段に分け、この接続はどこまで触れてよいかを先に決めます。区分を決めずに個別審査を始めると、申請のたびに議論が最初からやり直しになります。

2本目は実行の名義です。接続の先で起きる操作が、共通のアカウントで実行されるのか、申請した本人の資格で実行されるのかを確かめます。共通のアカウントにすると設定は楽ですが、誰が何をしたのかが記録から消えます。仕様も、引換券を素通しさせる作りを禁じる理由の1つに、記録の追跡ができなくなることを挙げています。原則は本人の資格、例外を認める場合は理由と期限を書かせます。

この2本を先に決めておくと、審査の会話が短くなります。「この接続は社内限りの区分まで、名義は本人、書き込みの道具は使わない」と1行で書ければ、あとは確認項目を順に潰すだけです。線を引く作業は接続の審査ではなく、部門の方針決めなので、申請が来る前に済ませておきます。

確認項目1：そもそも認証がかかっているか

最初に見るのは、認証の有無という基本です。冒頭の測定で4割が認証なしだったという事実は、外部の接続先だけの話ではありません。社内で立てた接続先も、手元では動いていたものを社内網に出しただけ、という経緯だと同じ状態になります。試作のときに認証を外し、そのまま本番に出た接続は珍しくありません。

確認は2段で行います。第1に、認証なしの状態で道具の一覧が取得できるか。第2に、書き込みや送信を伴う道具が、認証なしで実行できるか。一覧だけなら実害が小さいと考えがちですが、一覧には社内の業務名や部門名が入ることが多く、道具の名前と説明文だけで社内の構造が読める場合があります。

接続の識別子の扱いも、この段階で見ます。仕様は「認証のために接続の識別子を使ってはならない」と必須で書き、識別子は推測できない値にすること、利用者を特定できる情報と組み合わせて保持することを求めています。識別子さえ分かれば操作できてしまう作りは、仕様に反しています。ここは実装者に確認すれば答えが返る項目なので、申請書の欄にしておきます。

確認項目2：渡す権限の範囲を最小から始める

次に見るのが権限の範囲です。仕様には権限の最小化という節があり、よくある間違いが名指しされています。使える権限を全部並べて公開すること、すべてを意味する包括的な権限を使うこと、将来の確認を省くために無関係な権限を束ねること。この3つはいずれも、審査で見つけたら差し戻す対象です。

推奨されている進め方は段階的です。最初は低リスクの読み取りだけを許し、権限が必要な操作に初めて到達した時点で、その操作に必要な範囲だけを追加で求める。2025年11月25日に公開された現行の仕様では、この必要になった時点で追加の権限を求める仕組みが正式に入りました。前の版である2025年6月18日版からの主な変更の1つです。

広い権限を最初に渡す弊害は2つあります。1つは、引換券が漏れたときに、無関係な道具やデータまで一度に到達されること。もう1つは失効のしづらさで、強い権限の引換券を失効させると、その引換券に依存していた業務が全部止まります。だから申請書には、使う道具の名前と、読み取りか書き込みかの別を書かせます。書けない申請は、まだ設計が固まっていない申請です。仕様も、権限を引き上げた出来事について、要求された範囲と実際に許された範囲を記録に残すよう求めています。

確認項目3：同意の画面が、接続ごとに出るか

仕様が具体的な攻撃として名指ししているものの1つが、代理人の取り違えです。成立条件は4つ挙げられています。第三者の認可の仕組みに固定の識別子で接続していること、接続する側がその場で自分を登録できること、第三者の側が最初の同意のあとに同意の記録を残すこと、そして転送の前に接続ごとの同意を実装していないことです。

起きることは単純です。利用者が一度正規に同意すると、同意の記録が手元のブラウザーに残ります。攻撃者は自分あての戻り先を登録した新しい識別子を作り、利用者にリンクを送ります。利用者がそれを開くと、同意の記録があるため同意画面が出ずに素通りし、認可の引換券が攻撃者の指定した戻り先に届きます。利用者の側から見ると、リンクを1回開いただけです。

確認する内容は2点に絞れます。接続ごとに同意の記録を持ち、第三者へ転送する前にその記録を確認しているか。そして戻り先の宛先を、登録された文字列との完全一致でのみ受け付けているか。仕様は部分一致やワイルドカードによる照合を明確に禁じています。あわせて、引換券の素通しも必須事項として禁じられており、自分あてに発行されていない引換券を受け取ってはならないと書かれています。

• 同意の記録は、利用者が同意画面を承認したあとにだけ作る（前に作ると同意画面が無意味になる）
• 戻り先の照合は完全一致のみ。登録し直さずに戻り先を変えた要求は拒否する
• 自分あてに発行されていない引換券を受け取って転送する作りは、仕様上の禁止事項

確認項目4：手元で動かす接続は、起動命令をそのまま読む

接続先が担当者の端末で動く場合、審査の対象が変わります。端末で実行される以上、その接続は利用しているアプリと同じ権限で動きます。仕様も、ひとつの操作で接続を設定できる仕組みを持つなら、命令を実行する前に同意の手続きを必ず実装しなければならない、と必須で書いています。

同意の画面に何を出すかまで指定されています。実行される命令を、引数や指定値も含めて省略せずに全文表示すること。危険な操作であることを明示すること。承認なしに進めないこと。取り消せること。加えて、管理者権限を使う命令、まとめて削除する命令、外部への送信を伴う命令、想定外のフォルダに触る命令を強調して表示することが推奨されています。省略された起動命令は、審査では読めていないのと同じです。

実務での運用は簡単で、申請書に起動命令の全文と、そこで参照される配布元を書かせます。その1行を読める人が部門に1人もいないなら、その接続はまだ入れる段階にありません。仕様は、隔離した環境で最小の権限で起動すること、ファイル・通信・その他の資源へのアクセスを制限して起動することも推奨しています。

• 起動命令が省略表示のまま、内容を確認せずに承認する
• 試作で認証を外したまま、社内網に出して本番運用に入る
• 使えそうな権限を最初にまとめて渡し、あとで絞る予定にする
• 共通のアカウントで実行させ、誰が操作したかを記録に残さない
• 走査ツールが問題なしと出たことを、可否の根拠として稟議に書く

確認項目5：提供元と、通信の行き先

提供元の見極めは、4つの問いで足ります。誰が作っているか。保守が続いているか（直近の更新と、報告への反応）。不具合や脆弱性の報告先が公開されているか。そして、利用条件に社内データの二次利用が書かれていないか。4つのうち2つ以上が空欄なら、社内限りの区分に触れる接続としては通しません。

見落とされやすいのが通信の行き先です。接続先は、認可の手続きの案内として、こちら側がたどるべき宛先を返してきます。悪意ある接続先は、ここに社内の機器の宛先や、クラウドの資格情報を返す特殊な宛先を書き込めます。こちら側が案内どおりにたどると、外からは届かないはずの場所に自分で取りに行くことになります。

仕様が挙げている対策は3つです。本番では暗号化された経路のみを許すこと。私設の帯域や折り返しの宛先を遮断すること。そして宛先の判定を自作しないことです。表記の細工で判定をすり抜ける手口が知られているためで、外向きの通信を中継する仕組みを1枚挟み、そこで方針を適用するほうが確実です。中継の仕組みは既存の資産を流用できることが多いので、審査の条件に入れやすい項目です。

道具の説明文そのものを信用しない

仕様の基本原則に、審査でいちばん効く一文があります。「道具のふるまいの説明や注釈は、信頼できる提供元から得たものでない限り、信頼できないものとして扱うこと」。説明文はAIが読む文章なので、そこには指示を書けます。説明文は仕様書ではなく、提供元から送られてくる入力です。

ここから運用が2つ決まります。第1に、初回の審査だけでは足りません。説明文は更新のたびに差し替わるので、更新を検知して差分を見る仕組みが要ります。第2に、説明文を読ませて安全かどうかをAIに判定させない。判定させれば、まさにその説明文に書かれた指示の影響を受けます。判定の対象と判定する側が同じ入力を読んでいる構図では、判定は成立しません。

そのうえで、人が確認する範囲を先に決めます。全文を毎回読むのは続かないので、見るのは道具の一覧、要求されている権限の範囲、実行の名義、記録の残り方の4点に絞ります。この4点で説明のつかない変更があったときだけ、説明文の全文に戻ります。承認が必要な操作は、AIの判断ではなく権限と自動の仕掛けで止める。ここは指示文の書き方では代替できません。

接続先からこちらに来る依頼を、どこまで許すか

審査が道具の一覧だけで終わると、裏向きの経路が抜けます。規格には、機能を提供する側から接続を担う側へ依頼できる機能があります。モデルへの問い合わせを頼む、作業してよい範囲を尋ねる、利用者に追加の入力を求める、という3つです。仕様はモデルへの問い合わせは利用者が明示的に承認しなければならないと書き、問い合わせを行うかどうか、送られる文面、提供側が見られる結果を利用者が制御できるべきだとしています。

データの受け渡しにも原則が置かれています。利用者のデータを提供側に見せる前に明示的な同意を得ること、同意なくそのデータを他所へ送らないこと、そして適切なアクセス制御で保護すること。だから業務データを扱う接続では、提供側にどのデータが渡るのかの一覧を、道具の一覧とは別に出させます。道具の名前からは、渡る範囲が読めないことが多いためです。

もう1つ、接続を担う側の実装に確認する項目があります。認可の入り口として案内された宛先を、どう扱うかです。仕様は、許してよいのは暗号化された経路と、開発時に使う折り返しの宛先だけだとし、命令として解釈される特殊な書き方の宛先を拒否することを必須にしています。あわせて、宛先を開く処理に命令解釈の仕組みを使ってはならないとも書かれています。ここは製品側の作りの話なので、提供元への質問票に入れておきます。

接続前チェックリスト

ここまでの項目を、申請を受けたその場で潰せる形に並べます。順番に意味があり、上の3つで落ちる申請は下を見る必要がありません。埋まらない欄がある申請は、審査を保留にして差し戻します。審査する側が推測で埋めた欄は、事故のときに誰の責任か分からなくなります。

• この接続で呼び出せる道具の一覧が提出されているか（読み取りと書き込みの別つき）
• 触れる情報の区分が決まっているか（社外可・社内限り・限定担当のどれまで）
• 操作が実行される名義は本人の資格か。共通のアカウントなら理由と期限があるか
• 認証なしで道具の一覧や実行ができない状態か。識別子を認証代わりにしていないか
• 渡す権限が読み取りから始まり、必要になった時点で追加される設計か
• 接続ごとに同意を記録し、戻り先を完全一致で照合しているか
• 手元で動く接続なら、起動命令の全文と配布元が書かれているか
• 提供元の保守状況と報告先、利用条件の二次利用の記述を確認したか
• 実行の記録がどこに何日残るか、止め方は誰が実行できるかが決まっているか

このうち最後の1行が、実際にはいちばん抜けます。つなぐ判断に議論が集中し、記録と止め方は動き始めてから決めることになりがちだからです。順序を逆にして、記録と止め方が決まらない接続は通さない、という運用にすると、事故のときの復旧時間が桁違いに短くなります。

つないだ後に残す記録の粒度

記録は、多く残せばよいわけではありません。多すぎると保存費用と個人情報の扱いの問題が増え、いざというときに探せません。あとで答えるべき問いから逆算して、粒度を決めます。答えるべき問いは4つです。誰が、どの道具を、どのデータに対して使い、その結果どこに何が出ていったか。

残す項目	粒度の目安	主な用途
接続の許可と変更の履歴	いつ誰が承認し、どの権限を足したか	監査での説明と、権限が広がった経緯の追跡
道具の呼び出し	実行の名義、道具の名前、対象の識別子、成否	事故時の影響範囲の特定
外部へ出た内容	宛先と、送った項目の種類（本文の全文は必須ではない）	情報の流出範囲の確定と、通知の要否判断
道具の一覧と説明文の版	取得日時と差分	説明文の書き換えに気づくため
拒否と失敗の記録	拒否された理由、失敗の種別	権限の絞りすぎと、攻撃の兆候の切り分け

保存期間は、業務の記録の既存の規定に合わせるのが早道です。新しく決めようとすると、決まるまで記録が残らないという最悪の状態が続きます。まず既存の規定を流用して残し始め、半年後に過不足を見直すほうが確実です。あわせて、記録の中に業務データの中身をどこまで含めるかを先に決めておきます。

止め方を先に決める

止め方は、つなぐ前に決めます。事故が起きてから調べ始めると、止めるまでの時間がそのまま被害の大きさになります。止め方は3種類あり、効き方も影響範囲も違うので、どれを誰が実行できるかを表にしておきます。

1つ目は接続そのものを切ること。設定から外すか、通信を遮断します。効きは速いが、正規の業務も同時に止まります。2つ目は権限の失効で、引換券を無効にします。範囲を絞って止められる代わりに、失効の反映に時間差が出る場合があります。3つ目は名義の資格情報を入れ替えることで、最も確実だが、その名義を使っている他の仕組みも巻き込みます。だから最初から名義を分けておく判断が効いてきます。

決めたら、半年に一度は実際に止めてみます。手順書だけでは、権限が足りない、担当が異動している、連絡先が古い、といった問題が見つかりません。止める演習は、つないでいる件数が少ないうちにやるほど安く済みます。演習の記録は、そのまま監査で聞かれる「有効性の確認」の証跡になります。

走査ツールの判定を鵜呑みにしない

接続先の安全性を機械的に判定するツールが増えています。ただし、その出力を可否の根拠にするのは危険です。2026年7月に公開された研究は、公開されている接続先を大規模に集めて動かせる形にした基盤を作り、64,611件（重複を含めると113,927件）を収集しました。そのうち37,288件以上が実際に動かして調べられる状態です。

この基盤で既存の走査ツールを検証した結果が示唆的です。ツールは全体の96.89%を危険と判定しましたが、警告の標本を人手で確認したところ、真陽性は5割に満たなかったと報告されています。さらに、ツールごとに判定が明確に食い違うことも示されました。ほぼ全部を危険と判定する出力は、絞り込みの役には立ちません。

実務での扱いは1つです。ツールの出力は候補を絞る材料として使い、可否の根拠には使わない。危険と出なかったから安全、という向きの推論も同じく成り立ちません。人が見るのは、前の章で挙げた4点だけに絞ります。道具の一覧、権限の範囲、実行の名義、記録の残り方。この4点なら、件数が増えても審査は回ります。

規格は改訂される前提で運用する

この規格は改訂が続いています。現行版は2025年11月25日に公開されたもので、その前は2025年6月18日版でした。改訂で入ったものには、必要になった時点で権限を追加で求める仕組み、認可の仕組みを見つける手順の拡充、接続する側の登録手続きの追加などがあります。安全に関わる指針も、この改訂で更新されています。

重要なのは、仕様自身が限界を明記していることです。基本原則を並べたうえで、規格の水準ではこれらを強制できないと書き、実装する側が同意と認可の仕組みを作り込むべきだとしています。規格に準拠しているという説明は、安全である説明にはならないということです。準拠は前提であって、確認の代わりにはなりません。

運用としては2つ決めます。第1に、版が変わったときに差分を読む担当を置くこと。第2に、既存の接続を再審査する条件を決めておくこと。条件は、版が変わったとき、道具の一覧か説明文が変わったとき、権限の範囲が広がったとき、提供元が変わったとき。この4つのどれかに当たったら、初回と同じ確認項目をもう一度通します。

部門に定着させる手順

最後に、ここまでを部門の運用として回す形にします。属人的に詳しい人が審査している状態だと、その人の異動で止まります。工程を固定し、書類の形を決め、周期を決めるところまでやって初めて定着します。

周期の決め方に迷ったら、既存の資産管理や委託先管理の周期に合わせます。新しい周期を作ると、担当者の負担が増えて最初の1回で止まります。既存の管理業務に相乗りさせるほど、定着の確率は上がります。審査の記録も、既存の台帳の1列として持たせるほうが探しやすくなります。

まとめ

AIを社内ツールや外部サービスにつなぐ規格を審査するとき、見るのは製品の良し悪しではありません。この接続で何ができてしまうのか、その操作は誰の名義で実行されるのか、記録はどこに残るのか。この3つです。稼働している遠隔の接続先7,973件のうち40.55%が認証なしで道具を公開していたという測定は、不備が製品の作りではなく接続の設計に集中していることを示しています。

確認する項目は、仕様が必須として書いている内容をそのまま部門の欄に翻訳できます。認証がかかっているか。権限は読み取りから始まり、必要になった時点で追加される設計か。接続ごとに同意を記録し、戻り先を完全一致で照合しているか。手元で動く接続なら、起動命令が省略なしで確認されているか。そして、道具の説明文は信頼できる提供元から得たものでない限り信用しない、という原則です。

機械の判定に寄りかからないことも決めておきます。走査ツールが96.89%を危険と判定しても、警告の真陽性は5割に満たなかったという実測があります。だから人が見る範囲を先に4点に絞り、それ以外は見ないと決める。説明文を読ませて安全かどうかをAIに判定させるのは、判定される側の文章に判定を委ねることなので採用しません。つなぐ前に、記録と止め方まで決まっているか。この1点が、事故の日の復旧時間を決めます。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。