この記事でわかること
- Model Context Protocol（MCP）が「AI AgentのHTTP」と呼ばれるようになった経緯と、AI Agentが「答えるAI」から「実行するAI」へと役割を変えている背景
- 自社の業務システムが「実行するAI」を受け入れる準備として、権限・監査ログ・連携設計の何を整える必要があるか
- 2026年中に自社が答えるべき論点と、ベンダー選定軸・既存業務システムの両面で取るべきアクション
MCPとは何か
Model Context Protocol（MCP、AI Agentが外部システムやデータと通信するためのオープン標準仕様）は、2024年に Anthropic が公開したプロトコルです。公式ドキュメントは MCP を 「AIアプリケーション向けのUSB-Cポート」 にたとえています（modelcontextprotocol.io）。USB-C が複数の役割（電源・データ・映像）を1つのコネクタ形状に統一したのと同じ構図が、AI Agent と社内のデータベース・SaaS・業務アプリケーション・開発ツールのあいだで起きつつあります。
公開時点では開発者向けの技術仕様にとどまっていたMCPは、2025年後半から2026年にかけて経営層のアジェンダに上がりました。米テクノロジーメディア CIO は2026年2月の記事で、MCPを 「エンタープライズAIのための接続インフラ」 と位置づけています（CIO.com）。ここでいう接続インフラとは、ベンダーごとに個別実装してきた連携を、企業横断の標準仕様の上に乗せ替える役割を指します。MCPは Anthropic の Claude シリーズだけでなく、OpenAI の ChatGPT、Visual Studio Code、Cursor といった主要なAIアシスタント・開発ツールが横断的にサポートしており、業界全体の論点に押し上げています。
なぜ「答えるAI」から「実行するAI」への転換が起きているのか
AI Agent が人や組織の代理として動作するようになり、MCPの中心的な論点は 「AIが何を見られるか」から「AIが何を実行できるか」へ、そしてエンジニアリングの領域から、ガバナンス・ID管理・リスク管理の領域へ と移った——CIO記事はこの2つの転換を並べて整理しています（CIO.com）。身近な ChatGPT や Claude の体験で言えば、「答えるAI」 は文書要約や施策の壁打ちを文章で返してもらう使い方、「実行するAI」 は稟議の起票・勤怠申請・顧客管理ステータスの更新まで業務システム側で動かす使い方を指します。MCPは、後者を成立させるための共通基盤です。
MCPが「AI AgentのHTTP」と呼ばれるのは、HTTPと、その上に乗った標準仕様によってWebサービスが爆発的に増えたのと同じ構図を指しています。ベテランのセキュリティ幹部 Andy Ellis 氏は同記事で、MCPを 「ユニバーサル・コネクター」 と表現し、ゼロから作り直す代わりに既存アプリケーションを束ねて連携させられる性質を持つと指摘しています。AI Agent が業務システムに対して実行する範囲が、共通プロトコルで一気に広がる構図です。
2026年3月公開の MCP Roadmap 2026 は、今年の焦点を通信層・Agent間通信・ガバナンス・エンタープライズ対応の4つに整理し、なかでも「エンタープライズ対応」に監査証跡、シングルサインオン統合認証、ゲートウェイ挙動、設定の可搬性を並べました。これは、MCPが2026年中に「実行できる」段階から、「企業の調達基準と内部統制を通せる」段階へ進もうとしている流れを示していると見ています。
自社の業務システムは「実行するAI」を受け入れる準備があるか
ここから先は、本記事の独自の見立てです。
よくある見方： MCPはAI Agentと外部システムを繋ぐ技術標準の話で、CTO・情報システム部門の判断領域である。自社の業務システム側で何かを準備する必要はない。
実態は： MCPが押し上げた「実行するAI」を業務に組み込む段階では、自社が積み上げてきた業務システムの権限設計・監査ログ・例外処理ルールが、AI Agentの動作範囲を決める前提条件として浮上します。自社の業務システムが「参照される側」だった時代の設計のままでは、「操作される側」として求められる説明責任に追いつかない構図になります。
「実行するAI」を受け入れる準備として、自社の業務システム側で再点検すべき論点は3つあります。
1. AI Agent を「人の代理」として権限設計できているか
MCPの世界では、AI Agent が「営業担当の田中さんの代理として」見積もりシステムを操作する構図が標準になります。このとき、業務システム側の権限設計が 「田中さん本人の操作」と「田中さんの代理として動く AI Agent の操作」を区別して記録できるか が論点です。両者が同じログに混在すると、内部監査・取引先からの照会・規制当局への説明で、自社の説明責任が宙に浮きます。既存のユーザーIDの設計を土台に、AI Agent の動作をエージェント識別子（Agent ID）として並列で記録する仕組みを組み込むことが、現実的な準備になります。
2. AI Agent の「何を、なぜ実行したか」を記録できているか
「答えるAI」の時代、業務システムが残すべきログは「誰が何を参照したか」が中心でした。「実行するAI」の時代には、AI Agent が「誰の代理で、何を、なぜ実行したか」を残す必要があります。AI Agent の「なぜ」は、人間の意思決定とは違い、与えられたプロンプトと参照したコンテキストの組み合わせから推論された結果です。
AI Agent の実行アクション（注文の確定、承認の起票、データの更新など）と、そのアクションを引き起こした実行根拠（どのプロンプトでどのデータを参照したか）をペアで残せる仕組みが、運用上の論点になります。一方だけが残っても、事後の検証は機能しません。
3. AI Agent と人の判断範囲の境界を引けているか
業務システムには、想定外の入力や前提が崩れた場面で人間の判断に戻す例外処理が組み込まれています。AI Agent が業務システムを操作する時代には、 「AI Agent が独力で判断・実行してよい範囲」と「人が判断する範囲」 の境界を業務システム側で引き直す必要があります。
たとえば、与信限度を超える発注、契約条件の特例適用、規制対象データの社外送信などは、AI Agent の動作範囲から外し、必ず人の承認を経由する設計にする論点です。この境界線を業務システム側で持っていないと、AI Agent の動作範囲が現場の運用設計に依存し、自社全体として一貫性のある制御ができません。
ベンダー選定軸はこう変わる
「実行するAI」を業務に組み込む流れは、AIベンダーやSaaSベンダーの選定軸も書き換えます。論点の中心は、統合コストや工数ではなく、情報漏洩リスク に移ります。MCPの普及は、共通プロトコルの利便性と同時に、「出所が確認できないMCPサーバー」 を業務に紛れ込ませる入口を広げてもいるためです。
2025年9月、セキュリティ企業 Koi Security は、メール配信サービス Postmark の名を騙った悪意ある npm パッケージ postmark-mcp を発見しました（koi.ai）。攻撃者は v1.0.0〜v1.0.15 までは純正と同一動作を提供して信頼を積み上げ、2025年9月公開の v1.0.16 で、全送信メールを攻撃者アドレスに BCC コピーする1行のバックドアを仕込みました。週1,500件のダウンロードがあり、推定300組織で企業のメール本文が攻撃者の手元に流れていた構図です。Postmark 公式は「当該パッケージは自社が公開したものではない」と無関係を表明していますが、公式が公開していない名前空間に第三者が同名パッケージを先回りで置ける構造そのものは、ベンダー側の声明だけでは閉じられません（Postmark公式）。
これは、MCPの普及に伴うベンダー選定の論点を 情報漏洩リスク に決定的に押し上げた事例です。AI Agent が業務システムを実行する世界では、AI Agent が呼び出す MCP サーバーの「出所」が、自社の機密情報を扱える権限の入口になります。新規ベンダー選定の評価項目には、(1) MCP対応の有無、(2) MCPサーバーが公式ベンダー提供か第三者パッケージか、(3) 権限・監査ログの標準化レベル——の3点を組み込む必要があります。2026年のMCP公式ロードマップが監査証跡・シングルサインオン統合認証・設定の可搬性をエンタープライズ対応の柱に据えたいま、これらをチェックしないまま調達を進めることは、自社のセキュリティ・ガバナンスの穴をベンダーごとに増やしていく構図と隣り合わせです。
アクションチェックリスト
| アクション | 内容 |
|---|---|
| 業務システムの実行受け入れ準備の点検 | 主要業務システムについて、AI Agentが代理実行する可能性のあるアクション範囲と、それを許容できる権限・監査体制が整っているかを棚卸しする |
| 実行するAI前提の権限・監査ログ設計 | AI Agentが現在のユーザーの代理として動作する前提で、誰の権限で何を実行したかを後から追跡できる仕組みを既存の内部統制に組み込む |
| ベンダーのMCP対応と出所の棚卸し | 主要なSaaS・AIベンダーのMCP対応状況と、社内で使うMCPサーバーが公式提供か第三者パッケージかを一覧化し、新規ベンダー選定の評価項目に組み込む |
「答えるAI」から「実行するAI」への転換に合わせ、業務システムの権限・監査設計の見直しと、AI Agent統合戦略の3年単位の再設計まで支援します。
あわせて読みたい
FAQ
Q: 「実行するAI」と従来の業務自動化（RPA等）はどう違いますか？
従来のRPAは、人間が事前に定義した手順を機械が忠実に再現するアプローチでした。「実行するAI」は、AI Agentがその場の状況（ユーザーの依頼内容、参照したデータ、業務システムの現在の状態）から実行手順を推論する点が異なります。手順を事前にすべて書き起こす必要がない一方で、「なぜその実行に至ったか」が人間にとって完全には予測できないため、権限設計と監査ログの重みが従来のRPA以上に増します。両者は競合ではなく、決まりきった処理はRPA、状況依存の判断を含む処理は「実行するAI」と使い分けるのが現実的です。
Q: 自社で MCP サーバーを内製する必要がありますか？
両方を組み合わせるのが現実的です。自社の独自業務システム（基幹システム、業界固有のデータ連携、ベンダーが提供していない社内ツール）については、内製のMCPサーバーで AI Agent に接続する判断が合理的です。一方、SaaS・パッケージ製品については、ベンダーが公式に提供するMCPサーバーを採用するほうが、保守責任の所在が明確になります。「自社独自の業務は内製、標準的なSaaSはベンダー提供」が基本方針になります。
Q: 「実行するAI」を導入する前に、自社で最初に手をつけるべきことは何ですか？
自社で使うMCPサーバーの 「出所」を確認するところから始める のが現実的です。Postmark-MCP の事例が示したとおり、技術的な権限設計や監査ログをいくら整えても、業務システムに繋ぐMCPサーバーが信頼できない出所だと、それ自体が情報漏洩の入口になります。具体的には、(1) ベンダー公式のドメインまたは公式リポジトリから配布されているか、(2) 配布元が「自社が無関係」と否定したことがないか、の2点を確認するだけで、最低限の関門は通せます。権限・監査・例外処理の議論は、出所確認を通った後で詰めるほうが順序として安定します。
参考リンク
- Model Context Protocol — 公式サイト
- 2026 MCP Roadmap — Model Context Protocol Blog (2026年3月)
- Why Model Context Protocol is suddenly on every executive agenda — CIO.com (2026年2月)
- First Malicious MCP in the Wild: The Postmark Backdoor That's Stealing Your Emails — Koi Security (2025年9月)
- Security Alert: Malicious 'postmark-mcp' npm Package Impersonating Postmark — Postmark (2025年9月)