MCP（Model Context Protocol）でAIと社内システムをつなぐと、業務の自動化は一気に進みます。一方で、これまでは人が画面から操作していた業務システムに、AIがプログラム経由でアクセスする状態が生まれます。つまり、新しい入口を1つ増やすということです。そして実務でよく起きているのは、検証のために立てた仕組みが公開状態のまま残る、という地味な事故です。本記事では、MCPを企業で使うときに押さえるべきリスクの種類と、公開範囲・認証・ログ・データの絞り込みによる対策を、実務の観点で整理します。
MCPのリスクの本質は、AIが「人の代わりにシステムを操作できる状態」をつくることにあります。 従来のシステム連携は、あらかじめ決めた処理を決めた順序で実行するものでした。対してAIエージェントは、状況に応じて自ら判断し、公開された機能を組み合わせて使います。便利さの源泉がそのままリスクの源泉で、想定外の使い方や、意図しないデータの取得が起こりえます。ここを理解しておくと、どこに守りを置くべきかが見えてきます。まずはリスクを具体的に分けて把握しましょう。全体像がつかめれば、過度に恐れて導入を止める必要も、無防備に開く必要もなくなります。
業務システムの権限は、多くの場合「人が画面から使う」前提で設計されています。人であれば常識で判断する範囲も、AIは公開されている機能をすべて使いうる対象として扱います。たとえば「顧客情報を検索できる」権限を渡せば、担当外の顧客まで対象に含まれるのが自然な動作です。人なら「自分の担当だけ」と限定するところを、AIは限定する理由を持ちません。人には自明な「これは触らない」がAIには通じないため、権限の範囲を明示的に絞る必要があります。既存の権限設計をそのまま流用すると、想定より広い範囲が開いてしまいます。AI用の権限を新たに定義し、人の権限とは別に管理する発想が必要です。
MCPを企業で使う際に検討すべきリスクを整理します。いずれもMCPという仕組みの欠陥ではなく、使い方と設計次第で防げるものです。逆に言えば、知らずに進めると気づかないまま抱え込むことになります。5つに分けて確認しておきましょう。自社の構成に当てはめながら読むと、優先して手を打つべき箇所が見えてきます。
検証のために立てたサーバーが外部から到達できる状態のまま残る、というのは典型的な事故です。認証も通信の暗号化もないまま外部から到達できる状態は、セキュリティ関連の報告で繰り返し指摘されてきました。社内利用が前提なら、外部から到達できないネットワーク設計にすることが基本です。しかもこの種の露出は、攻撃を受けて初めて気づくことが多いものです。
リスクを生むのは、多くの場合、外部の攻撃者ではなく自分たちの引き継ぎ漏れです。「動作確認のため一時的に開けた」設定は、担当者が異動すれば誰も把握していない穴として残ります。検証用に立てた環境が、そのまま数年動き続けている例も珍しくありません。検証環境も本番と同じ基準で扱い、期限を決めて閉じる運用にしておくことが、実務では最も効く対策になります。
誰でも接続できる状態では、公開した機能はそのまま社外に開いていることになります。接続元の認証と通信の暗号化は、最低限の前提です。開発の初期に「まず動かす」ために外した設定が、そのまま本番に残るケースが多いため、公開前のチェックが欠かせません。ここはデータ連携のセキュリティ対策の考え方がそのまま当てはまります。公開前のチェック項目として明文化し、担当者が変わっても引き継げる形にしておきましょう。
AIは受け取った文章を指示として解釈しうるため、外部から取り込んだデータの中に紛れ込ませた指示によって、想定外の動作を引き起こされる可能性があります。信頼できない外部の情報源をそのままAIへ渡さない、渡すデータの内容を検証する、といった防御が必要です。「入力は疑う」という原則は、AI連携でも変わりません。とくにWebやメールなど外部由来のデータを扱う経路は注意が必要です。社内文書だけを対象にする設計から始めれば、このリスクは大きく下げられます。対象を広げる際は、情報源ごとに信頼度を評価しておきましょう。
「とりあえず全部使えるように」と広い権限を与えると、問題が起きたときの影響範囲が特定できません。たとえば「在庫を確認して回答する」用途なら、参照だけで足ります。それなのに在庫を更新できる権限まで渡していれば、誤った判断が在庫数を書き換えます。読み取りだけで足りる用途に更新権限を渡していないか、対象データの範囲が広すぎないかを見直しましょう。最小権限の原則は、AI連携でも守るべき基本です。用途ごとに権限を分けておくと、後からの絞り込みも容易になります。1つの共通アカウントで全社データにアクセスできる構成は、避けたい典型例です。
誰が・いつ・どのデータにアクセスし、何を実行したのかが記録されていなければ、問題発生時の調査も、監査への回答もできません。実行ログとアクセス記録を残し、定期的に確認する運用を組み込みます。把握できないものは統制できない、という原則はここでも同じです。ログは事後対応だけでなく、想定外の使われ方を早期に見つける役割も果たします。想定より多い呼び出しや、通常と違う時間帯のアクセスは、見直しのきっかけになります。
公開前に最低限これらを確認します。未確認があれば公開は見送るのが安全です。
| 観点 | 確認すること |
|---|---|
| 到達範囲 | 外部インターネットから接続できない状態になっているか |
| 認証 | 接続元を認証しているか。通信は暗号化されているか |
| 公開範囲 | 公開機能は用途に必要な最小限か。一覧を維持しているか |
| 権限 | 読み取りと更新を分けているか。実行権限が決まっているか |
| データ | 渡す項目は最小限か。個人情報・機密情報は除外/マスキング済みか |
| ログ | アクセスと実行の記録が残り、確認の運用が決まっているか |
| 入力の検証 | 外部由来のデータをそのまま渡していないか |
チェックリストを満たすために、設計段階で組み込むべき考え方を挙げます。運用ルールで補うより、そもそも危険なことができない構造にしておくほうが確実です。次の4つは、いずれも実装の工夫で実現できます。運用の注意喚起に頼らず、仕組みとして担保する発想が重要です。
AIにやらせたいことから逆算し、必要な機能だけを公開します。「将来使うかもしれない」機能を先回りして開けると、管理対象だけが増えていきます。公開した機能は後から絞るほうが難しいため、最小限から始めて必要に応じて足すのが原則です。公開一覧を維持し、追加・削除の履歴を残しておくと監査にも答えられます。半年に一度、使われていない機能を閉じる棚卸しを組み込むのも有効です。
参照系と更新系を別の機能として定義し、更新は対象と条件を絞って開きます。金額や在庫が動く処理は、人の承認を挟む設計から始めるのが無難です。段階的に開くことで、問題が起きたときの影響も限定できます。分けておけば、承認する側も判断しやすくなります。「参照だけなら許可、更新は個別審査」といった運用ルールも設けやすくなります。
AIへ渡す項目は必要最小限にし、個人情報や機密度の高い項目はマスキングしてから渡します。クラウドのAIサービスを使う場合、そのデータは自社の外に出るという前提で項目を選ぶ必要があります。データの絞り込みは、万一の漏洩時の影響を小さくする最も確実な対策です。ここは連携の設計で実装できる部分です。項目を絞る処理を AI側ではなく手前の連携層に置くと、対象システムが増えても同じ方針を適用できます。
AIと業務システムを直結せず、間にデータ連携の層を置くと、そこが制御点になります。渡す項目の絞り込み、マスキング、アクセスの記録、想定外の値の検知を1か所で行えるため、システムごとに個別対応する必要がなくなります。制御点を集約することは、統制のしやすさに直結します。監査で「どこを見れば全体が分かるか」を1か所に示せることも、実務上の大きな利点です。
データ連携について詳しく学ぶ（無料ダウンロード）
AIへ渡すデータを絞り、整えて渡す制御点には、データ連携基盤「ASTERIA Warp」（累計10,000社超）が使えます。100種類以上のアダプターで基幹システム・SaaS・DB・ファイルからデータを取得し、項目単位の絞り込み、コード変換、マスキング処理を経て渡す流れをノーコードで構築できます。実行ログが残るため、いつどの処理が動いたかを追跡でき、想定外の値を検知して処理を止める分岐も設計できます。オンプレミス環境でも動作するため、社内で完結させたい要件にも対応できます。実際に株式会社 スタッフサービス・ホールディングスは個人情報マスキングの共通APIサーバーをWarpで構築し、100万名超の個人情報を保護しながら処理しています。AIに開く前に、渡すデータを制御する仕組みを整えておくことが有効です。
Q. MCPを使うと、なぜ新しいリスクが生まれるのですか？
A. AIが「人の代わりにシステムを操作できる状態」が生まれるためです。従来の連携は決めた処理を順に実行しますが、AIは公開された機能を状況に応じて組み合わせます。人には自明な「これは触らない」が通じないため、権限と公開範囲を明示的に絞る必要があります。
Q. まず何を確認すべきですか？
A. 外部から到達できない状態か、接続元の認証と通信の暗号化があるか、公開機能が最小限か、の3点です。検証環境が公開のまま残るのは典型的な事故なので、本番と同じ基準で扱います。
Q. 外部から取り込んだデータをAIに渡しても大丈夫ですか？
A. 注意が必要です。AIは受け取った文章を指示として解釈しうるため、外部由来のデータに紛れ込ませた指示で想定外の動作を招く可能性があります。信頼できない情報源をそのまま渡さず、内容を検証する仕組みを挟みましょう。
Q. 権限はどう設計すべきですか？
A. 読み取りと更新を別機能として定義し、必要最小限に絞ります。更新は対象と条件を限定し、金額や在庫が動く処理は人の承認を挟む設計から始めます。
MCPのリスクは、AIが人の代わりにシステムを操作できる状態から生まれます。押さえるべきは、意図しない公開・露出、認証と通信保護の不足、悪意ある指示の混入、過剰な権限、ログの不在という5点です。公開前に、到達範囲・認証・公開範囲・権限・渡すデータ・ログ・入力検証をチェックし、未確認があれば公開を見送るのが安全です。対策の要は、公開を最小限にし、読み取りと更新を分け、渡すデータを絞り、間に層を置いて制御点を集約すること。渡すデータを制御する土台には「ASTERIA Warp」も使えます。
▼ AIへ渡すデータの絞り込みとマスキングを試す ASTERIA Warpは全機能を試せる無料体験版をご用意。渡すデータの絞り込みやマスキングも、サーバー準備不要ですぐに体験できます。 |
PM・SE・マーケティングなど多彩なバックグラウンドを持つ「データ連携」のプロフェッショナルが、専門領域を超えたチームワークで「データ活用」や「業務の自動化・効率化」をテーマにノウハウやWarp活用法などのお役立ち情報を発信していきます。
ASTERIA Warp製品の技術情報やTips、また情報交換の場として「ADNフォーラム」をご用意しています。
アステリア製品デベロッパー同士をつなげ、技術情報の共有やちょっとしたの疑問解決の場とすることを目的としたコミュニティです。
