MCPコネクタのセキュリティ統制は、接続先の性質によって許可の判断基準を分ける設計が実務では成立する。公開APIへの接続と社内システムへの接続では、統制の置き場所と審査の密度が異なる。入口で一律に止めるのではなく、出口で接続先とデータの種類を締めるガードレール型の設計が、業務の速度と統制の実効性を両立させる。

MCPコネクタのセキュリティリスクの正体

MCPコネクタのセキュリティリスクは、接続先へのデータ送信と、接続先から取得したデータの社内持ち込みの2方向に分かれる。リスクの大きさは接続先の性質で変わる。公開APIであれば送信データの範囲が主なリスクとなり、社内システムであれば認証情報の管理と取得データの権限が主なリスクとなる。

送信データのリスクは、AI側から接続先へ何を渡すかで決まる。プロンプトに含まれる個人情報・機密情報が、コネクタを経由して外部サービスへ送られる可能性がある。取得データのリスクは、接続先から何を持ち帰るかで決まる。外部APIから取得した情報が社内の会話履歴に残り、本来アクセス権のない利用者が閲覧できる状態になる可能性がある。

認証情報のリスクは、コネクタが接続先へアクセスするための資格情報の管理範囲で決まる。個人のAPIキーを使えば利用者ごとの権限で接続されるが、組織共通の資格情報を使えば本来アクセスできないはずのデータへ接続できてしまう。リスクの種類を分けて整理すれば、統制の置き場所が明確になる。

公開APIへの接続を許可する判断基準

公開APIへの接続は、送信データの種類と接続先の事業者で許可を分ける。接続先が日本国内の法人であり、プライバシーポリシーと利用規約が日本語で提供されている場合、送信データに個人情報・機密情報が含まれないことを条件に許可する基準が実務では成立している。接続先が海外事業者の場合、データの保存場所・保存期間・第三者提供の有無を確認し、社内のデータ取扱基準と矛盾しないかを審査する。

送信データの範囲は、プロンプトに含めてよい情報の種類で制限する。公開APIへ送信してよいデータは、公開済みの情報・匿名化済みの情報・業務上必要な範囲に限定した非機密情報に限る。個人情報・契約情報・未公開の事業計画を含むプロンプトを、公開APIへ接続するコネクタで実行することを禁止する。この制限は技術的な強制ではなく、利用者への教育と事後の監査で担保する設計が現実的である。

接続先の事業者は、プライバシーポリシーの記載内容で許可を判断する。データの保存期間・利用目的・第三者提供の有無・削除請求への対応が明記されていることを確認する。記載がない場合、または記載が曖昧な場合は、問い合わせで確認するか接続を見送る。確認の結果を記録に残し、同じ接続先への問い合わせを繰り返さない仕組みを作る。

社内システムへの接続を許可する判断基準

社内システムへの接続は、認証方式とデータの権限範囲で許可を分ける。個人の資格情報で接続する場合、利用者本人がアクセスできる範囲のデータしか取得されないため、審査の密度は低くなる。組織共通の資格情報で接続する場合、本来アクセス権のないデータまで取得できるため、審査の密度は高くなる。

個人の資格情報で接続するコネクタは、接続先システムの既存のアクセス制御がそのまま効く。利用者がログインしている状態で、その利用者の権限範囲内のデータだけをコネクタが取得する。この場合、コネクタ自体の審査は接続先の種類とデータの用途に絞られる。接続先が社内の業務システムであり、取得したデータを業務の範囲内で利用する限り、許可の判断は速い。

組織共通の資格情報で接続するコネクタは、誰が使っても同じ範囲のデータを取得できるため、利用者の範囲と取得データの種類を厳密に審査する。利用者を特定の部署・役職に限定し、取得するデータの種類を明示させる。接続先システムの管理者と協議し、コネクタ専用のアカウントを発行し、必要最小限の権限だけを付与する設計が望ましい。アカウントの発行・権限の付与・利用開始の3段階で記録を残す。

統制を入口ではなく出口に置く理由

コネクタの統制を入口（接続の許可申請）ではなく出口（データの送信先とアクセス範囲）に置く理由は、業務の速度と統制の実効性を両立させるためである。入口で一律に審査すれば統制は厳格になるが、業務の立ち上がりは遅くなる。出口で締める設計であれば、接続自体は速やかに許可し、送信データの種類と取得データの範囲を事後に検証する形で統制が成立する。

入口統制の問題は、審査の粒度を事前に決めきれない点にある。接続先の種類は無数にあり、すべてのパターンを想定した審査基準を事前に作ることは難しい。審査基準が曖昧なまま入口で止めれば、申請者は何を書けば承認されるかわからず、審査者は何を根拠に判断すればよいかわからない。結果として審査が滞り、業務が止まる。

出口統制は、接続先の種類ではなくデータの性質で判断する。個人情報が送信されたか、機密情報が取得されたか、権限外のデータへアクセスされたかを、ログと監査で確認する。この設計であれば、接続自体は速やかに許可し、データの扱いが基準を逸脱していた場合に事後で是正する流れが作れる。統制の思想は「入口を止めず出口で締める」ガードレール型である。

コネクタの審査基準を4段階で設計する

コネクタの審査基準は、接続先の性質とデータの種類で4段階に分ける。第1段階は公開APIで非機密データのみを扱う接続、第2段階は公開APIで業務データを扱う接続、第3段階は社内システムへ個人の資格情報で接続する場合、第4段階は社内システムへ組織共通の資格情報で接続する場合である。段階が上がるほど審査の密度を高くする。

第1段階の審査は、接続先の事業者名・サービス名・利用目的を記録する程度で承認する。送信データが非機密であり、取得データが公開情報の範囲に留まるため、リスクは低い。第2段階の審査は、送信データの種類を具体的に列挙させ、個人情報・機密情報が含まれないことを確認する。接続先のプライバシーポリシーとデータ保存場所を記録に残す。

第3段階の審査は、接続先システムの管理者へ通知し、利用者本人の権限範囲でアクセスされることを確認する。取得したデータの利用目的と保存先を明示させる。第4段階の審査は、接続先システムの管理者と協議し、コネクタ専用のアカウントを発行する。アカウントの権限範囲・有効期限・利用者の範囲を文書で定め、定期的に利用状況を監査する仕組みを設ける。

コネクタのログ設計と監査の実効性

コネクタの統制は、ログの取得範囲と監査の頻度で実効性が決まる。記録すべき項目は、接続日時・利用者・接続先・送信データの種類・取得データの種類・エラーの有無である。ログは利用者が改変できない場所へ保存し、監査担当者だけがアクセスできる権限設計にする。

監査の頻度は、コネクタの審査段階で変える。第1段階は四半期ごと、第2段階は月次、第3段階は週次、第4段階は日次で監査を実施する。監査では、送信データに個人情報・機密情報が含まれていないか、取得データが利用目的の範囲内で扱われているか、権限外のデータへアクセスされていないかを確認する。基準を逸脱した利用が見つかった場合、利用者へ是正を求め、再発防止策を記録に残す。

ログの取得には技術的な制約がある。監査に必要な操作記録を取得するためのロールが、社内の承認を得られない場合がある。監査ロールの権限範囲が広すぎると、本来の監査対象以外の情報まで閲覧できてしまうためである。この場合、取得できる範囲のログだけで監査を設計し、取得できない項目は残存リスクとして記録する。監査設計は技術的に取得できるかではなく、その権限が社内で承認されるかで決まる。

統制設計が前提に依存する構造

コネクタの統制設計は、ライセンスの配布範囲・権限モデル・監査体制という前提に依存している。前提が変われば、統制の思想ではなく装置の置き場所を組み替える必要がある。

例えば、有償ライセンスが一部の利用者にしか配布されていない前提では、統制装置を特定の環境へ配置し、その環境を通過する接続だけを許可する設計が成立する。しかし有償ライセンスが対象組織のほぼ全員に配布された場合、統制装置を環境ではなく人とデータの側へ再配置する必要がある。具体的には、セキュリティグループで利用者を区分し、データにラベルと権限を付与し、出口で接続先とアクセス範囲を締める設計へ組み替える。

統制の思想は「入口を止めず出口で締める」ガードレール型を維持しつつ、装置の置き場所だけを前提に合わせて動かす。検証と決定と手順書の順序を崩すと手戻りが発生する。決定を急がせる前に、検証結果を材料として先に出す設計が、実務では成立している。