HigLabo
最新記事
Model Context Protocolの普及はなぜ情シスの承認業務を増やすのか──Coveo・Lucidworks・KetryxのMCP対応で「つなげば使える」が危なくなる理由
Model Context Protocolで接続が簡単になるほど、情シスの承認は軽くならない
MCP（Model Context Protocol）の広がりにより、生成AIは外部サービスや社内データとつなぎやすくなりつつあります。結論から言うと、この流れは現場の利便性を高める一方で、情シスの承認業務やAI接続先管理の負荷を増やしうるものです。
なぜなら、接続の難しさが下がるほど、接続先の妥当性や権限設計、監査可能性を事前に見極める必要が増えるからです。便利になった分だけ、承認時に確認すべき論点はむしろ広がります。
この記事では、なぜ「接続が簡単になるほど審査が重くなるのか」を、Coveo・Lucidworks・KetryxのMCP対応という動きを手がかりに整理します。あわせて、情シスやAIガバナンス担当者が実務で何を確認すべきかも具体的に見ていきます。
「MCP対応ならすぐ使える」が歓迎されるのは、接続コストを下げるから
MCPが注目される理由は明快です。従来はAIと業務システムをつなぐたびに、個別のAPI連携や認証設計、データ受け渡しの調整が必要でした。
MCP対応が進むと、この接続部分をある程度そろった形で扱えるため、導入スピードが上がりやすくなります。現場から見れば、「試したいのに連携が重い」という壁が下がるわけです。
たとえば営業は検索基盤につないで提案資料を探したいですし、開発は文書やチケットを横断参照したいはずです。ChatGPT EnterpriseやClaudeのような生成AIを社内検索基盤や業務システムと併用する場面でも、この接続しやすさは魅力になります。
MCPは「AIの賢さ」を直接増やす技術というより、「AIが使える業務の範囲」を広げる技術だと捉えたほうが実態に近いでしょう。この点は公式仕様リポジトリを見るとイメージしやすくなります。
GitHub
ただし、ここで見落とされやすいのが、接続のしやすさと承認のしやすさは同じではないという点です。むしろ接続が簡単になるほど、誰が何につながるのかを事前に見極める必要は増えていきます。
Coveo・Lucidworks・KetryxのMCP対応が示すのは、承認対象となる接続先の拡大
今回の論点が重要なのは、MCP対応が単なる1社の話ではないからです。検索・発見、エンタープライズサーチ、品質・コンプライアンスといった異なる領域で、接続対象が広がり始めています。
Coveoでは、公式ドキュメント上で、MCPを通じてLLMアプリケーションやAIエージェントからCoveoの機能を利用するための案内が示されています。企業内外の情報をまたいで探す用途と、MCPの相性がよいことがうかがえます。
Lucidworksも、公式ページで、AIアシスタントをエンタープライズデータへ接続する文脈でMCPを案内しています。個別連携を減らせる可能性がある点は注目に値します。
Ketryxでは、公式発表ページでMCPに関する提供を案内し、コンプライアンス関連データへの接続を支援する構成を示しています。規制産業の文脈までMCPが入り始めている点は、情シスにとって見逃せません。
ここで重要なのは、MCP対応によって増えるのが「便利な接続先」だけではないことです。実際には、機密情報、規制情報、意思決定の根拠になる情報への入口も増えます。
情シスにとっては、APIが1本増える話ではありません。審査対象となる業務リスクの範囲そのものが広がる話です。
承認業務が重くなる本当の理由は、接続数ではなく許可と統制の設計にある
情シスの負担が増える理由を、単純に「連携数が増えるから」と捉えると本質を外します。本当の論点は、どの接続を許し、どの範囲まで操作を認めるかという許可の設計です。
たとえば同じ検索基盤への接続でも、閲覧だけ許すのか、要約まで許すのか、別システムへの書き込みまで含むのかでリスクは大きく変わります。AIは自然言語で命令できるため、利用者本人が意識しないまま権限の強い操作に近づく可能性もあります。
このため承認フローでは、最低でも次のような観点が必要です。
- AIが参照できるデータの範囲
- AIが実行できる操作の範囲
- 利用者ごとの権限継承の仕組み
- 誤応答や誤操作が起きた際の停止方法
NISTのAI RMFは、Govern、Map、Measure、Manageといった中核機能でAIリスクを整理する枠組みを示しています。MCPそのものの資料ではありませんが、承認条件や接続先統制を整理する際の参考になります。
つまり、情シスが承認するのは「接続していいか」だけではありません。「どんな条件なら接続してよいか」を設計する仕事が増えるのです。
「つなげば使える」が危ないのは、責任分界と監査可能性が見えにくくなるから
MCP時代に厄介なのは、事故の原因が一か所に見えにくいことです。問題が起きたとき、AIモデルの回答品質が悪かったのか、接続先データが古かったのか、権限設定が広すぎたのか、利用部門の運用が雑だったのかを切り分けにくくなります。
これは情シスの説明責任を重くします。なぜなら、導入時に承認した以上、「どこまで想定していたのか」が後から問われるからです。
とくに外部SaaS、社内検索基盤、品質管理システムのように複数の責任主体が絡む場合、責任分界点を文書で持っていないと運用で詰まります。標準化された接続方法があることと、その接続を安全に運用できることは別問題です。
監査や統制の観点では、SOC 2はサービス組織の統制に関する第三者保証の枠組みとして参考になります。ただし、報告対象の範囲外である自社の接続設定や運用の安全性は別途確認が必要です。
https://www.aicpa-cima.com/resources/landing/system-and-organization-controls-soc-suite-of-services
「MCP対応だから安心」という見方は危険です。正確には、「標準化された接続方法があるので導入しやすい」のであって、「そのまま安全に運用できる」とは言えません。
承認フローで最低限見るべき4点は、データ・権限・ログ・停止条件
実務で承認フローを回すなら、確認項目は絞ったほうが機能します。MCP連携では、少なくともデータ、権限、ログ、停止条件の4点を必須項目にするのが現実的です。
まずデータです。個人情報、営業秘密、規制対象情報が含まれるかを分類し、AI経由で参照させてよい範囲を明確にします。もし分類が曖昧なら、その接続は先送りにしたほうが安全です。
次に権限です。ユーザー本人の権限をそのまま継承するのか、AI用に別の制限をかけるのかを決めます。ここが曖昧だと、便利さの代わりに過剰権限を抱え込みます。
3つ目はログです。誰が、いつ、どの接続先に、何を問い合わせ、どんな操作が実行されたのかを追跡できる必要があります。OWASPのLLMアプリケーションに関する資料も、脅威やリスクを整理する参考になります。
最後は停止条件です。誤動作や情報露出の疑いが出たとき、どのチームがどの手順で連携を止めるのかを事前に決めておきます。止め方が決まっていない接続は、承認しないというルールも十分に合理的です。
全面禁止でも全面解放でもなく、先に接続を分類して台帳で運用する
MCP対応サービスが増えるほど、情シスがすべてを個別精査していては追いつきません。だから必要なのは、全面禁止でも全面解放でもなく、接続の種類を先に分類する考え方です。
たとえば、公開情報のみを読む接続は低リスクです。一方で、社内機密を横断検索する接続、承認済み文書を書き換えうる接続、規制対応の証跡に触れる接続は高リスクとみなせます。
この分類を先に作れば、承認の速度と安全性を両立しやすくなります。実際の運用では、次のような三段階でも十分機能します。
- 低リスク: 読み取り専用、公開情報中心、停止が容易
- 中リスク: 社内情報を参照、ログ必須、部門長承認あり
- 高リスク: 書き込み可、規制情報あり、情シスと法務の共同承認
要するに、MCP時代の情シスはブレーキ役だけでは足りません。接続を安全に設計し、通してよいものを素早く見極める交通整理役になる必要があります。
便利さが増すほど、承認は遅さの象徴ではなく安全装置になります。MCPの普及で本当に問われるのは技術力そのものより、接続を分類し説明できる運用設計力です。利用中または検討中のMCPサーバーを棚卸しし、登録・承認・監査の運用台帳を先に作っておくことが、最初の実務対応になります。