MCP（Model Context Protocol）は、AIエージェントと社内ツールを標準の形で接続する仕組みです。Anthropicが2024年11月に公開し、2026年時点でOpenAI、Google、Microsoft、Amazonが対応表明しています。
一方で、認証、権限、監査、供給元の信頼といった論点は、多くの企業でまだ整理途中です。
この記事では、MCPを社内AIエージェントで扱う際に確認すべき、認証・セキュリティ・運用の判断軸をまとめます。Claude・OpenAI・Google対応の使い分け、既知の脆弱性、導入前チェックリストまで整理します。
MCPは「多数のAIエージェント × 変化するツール群」を扱う場合に効いてきます。単一アプリの範囲では、関数呼び出しやOpenAPI連携で十分な場合があります。
| 読者の課題 | 最初に見る観点 | 確認すること | 次の行動 |
|---|---|---|---|
| 複数のAIエージェントが同じ社内ツールを叩く | ツール標準化 | MCPサーバー単位で権限と監査が分離できるか | 対象ツールごとにMCPサーバー化する |
| 現行はプロバイダ独自の関数呼び出し | 移植性 | 別モデルへ切り替えると再実装が発生しないか | MCP経由での抽象化を検討する |
| 認証まわりが個別対応で膨らんでいる | 認証の標準化 | IdP（Okta、Entra等）と接続できるか | OAuth 2.1／ID-JAG対応のMCPサーバーへ寄せる |
| 社内から外部MCPサーバーへつなぐ | 供給元の信頼 | 誰が運用し、どの権限を要求するか | 未確認サーバーは接続許可しない |
| 監査・情報漏洩のリスクが読めない | データ露出 | 何がAIへ渡り、どこに残るか | 入力データ種別と保存範囲を先に決める |
MCP（Model Context Protocol）は、AIエージェントが社内ツール、社内データ、外部SaaSに同じ手順で接続するための標準プロトコルです。
Anthropicが2024年11月に公開しました。2025年12月にはAgentic AI Foundation（Linux Foundation配下）へ寄贈され、単一ベンダー製品からコミュニティ標準へ移っています（Wikipedia）。
技術的にはJSON-RPC 2.0を土台にした通信規約です。2026年7月28日版の仕様では、状態を持たないリクエスト／レスポンス型に整理され、サーバーレスやエッジ配置にも寄せやすくなりました（Claude公式ブログ）。
| 用語 | 意味 |
|---|---|
| MCP | AIエージェントとツール・データを標準接続するためのプロトコル |
| MCPサーバー | ツールやデータをMCP形式で公開する側 |
| MCPクライアント | AIアプリやIDEなど、MCPサーバーへ接続する側 |
| ツール呼び出し（Tool Calling） | AIモデルがツールを選び、引数を返す仕組み |
| ID-JAG | 認可を1往復で扱うためのOAuth拡張。2025年9月にIETFで採択 |
| ゴールデンデータセット | 正解例を集めたAI評価用データ |
MCPは1年強で「単なる新しい規格」から「実運用の前提」へ移りました。設計を後回しにすると、認証と監査が個別対応のまま増え続けます。
2026年時点で、Fortune 500企業の28%がMCPを何らかの形で導入したという調査があります（Digital Applied）。
企業向けの数字としては、Stacklokの2026年ソフトウェア調査があります。41%のソフトウェア組織が「限定的またはより広い本番運用でMCPサーバーを利用中」と回答しました（andrew.ooo）。
普及に伴い、次のような論点が現場で顕在化しています。
こうした論点は、モデル選定や単体ツール選定より、運用側の設計課題として扱う必要があります。
「MCPを入れるべきか」は、単独では判断できません。既存の関数呼び出しやOpenAPI連携との比較で決めます。
| 方式 | 一言でいうと | 向くケース | 注意点 |
|---|---|---|---|
| 関数呼び出し（Function Calling） | モデルにツール一覧を渡す最小構成 | 単一アプリ内で完結する少数ツール | プロバイダごとに実装が分岐しやすい |
| OpenAPI連携 | HTTP API仕様書から呼び出しを生成 | 既存REST APIが安定している | 動的なツール追加は苦手 |
| MCP | ツール・データを標準サーバー化して共有 | 多数エージェント × 変化するツール群 | 認証・供給元・監査の設計が必要 |
出典はMarkTechPostを参照。
| 比較軸 | 確認すること | 実務上の意味 |
|---|---|---|
| 移植性 | モデルを切り替えたときに再実装が要るか | 将来のプロバイダ変更コストを左右する |
| ツール発見 | エージェントが動的にツール一覧を取得できるか | ツール追加時に全アプリ改修が要らなくなる |
| 認証統合 | IdPと接続できるか、退職者権限を切れるか | ガバナンスと監査に直結する |
| 供給元管理 | 誰がMCPサーバーを運用・更新するか | 供給網の信頼性が読める |
| 監査ログ | 誰がいつ何のツールを呼んだかを追えるか | インシデント時の切り分けに使える |
MCP対応を判断したあとは、認証、権限、監査、供給元、変更管理を先に決めます。ツール一覧の拡張はその後です。
Anthropicは2026年時点で、企業管理型の認証機能を提供しています。既存IdPグループから権限を継承する「ゼロタッチ接続」がその中心です（Claude Enterprise Managed Auth解説）。
ID-JAGはIETF OAuth Working Groupで2025年9月に採択され、2025年11月にMCP仕様へ組み込まれました。認可を1往復で判定でき、ユーザーへの毎回のOAuth同意プロンプトを減らせます。
MCPは急速に広まった一方、セキュリティ設計は追いつききっていません。普及の速さと安全性は分けて評価します。
MCPの認可仕様はOAuth 2.1を採用していますが、認可の実装自体はサーバー側で任意扱いの部分があります。導入時は、認可を必須にできるかを必ず確認します。
※本記事は2026年7月30日時点の公表情報を基にまとめています。MCP関連ツールの提供機能、認証仕様、脆弱性情報は変更される場合があるため、導入前に公式ドキュメントと最新のセキュリティ情報を確認してください。
MCPは「新しいツール接続方法」ではなく、「AIエージェント運用の基盤設計」として扱うのが自然です。
Blackford TechnologiesのAI開発・実装サービスでは、AI戦略の整理からPoC設計、実装、本番運用までを一貫して支援しています。MCPを扱う場合、次の観点で相談を受けます。
導入検討時の選択肢として、社内AIデータ基盤はDataRoid、既存クラウド活用型はDataRoid Cloud、営業・商談領域のCRM連携はSalesRoidがあります。ただしMCP対応は、業務課題と権限設計から逆算した方が安全に定着します。
一次情報の確認とPoC範囲の切り出しから始め、認証・監査・供給元の設計を先に固める順序をおすすめします。
AIエージェントが社内ツール、社内データ、外部SaaSへ同じ手順で接続するための標準プロトコルです。Anthropicが2024年11月に公開し、2025年12月にLinux Foundation配下のAgentic AI Foundationへ寄贈されました。
MCPはプロバイダ非依存で、複数のエージェント間でツール定義や認証を共有できる点が中心的な違いです。単一アプリで完結する場合は関数呼び出しで十分な場合があり、安定したREST APIの活用はOpenAPI連携が向きます。
対象ユースケースの絞り込みと、認証・権限・監査の設計です。IdP（Okta、Entra等）との接続方式、退職者権限失効、監査ログの保管範囲を先に決め、ツール数の拡張はその後にします。
未確認の第三者コンポーネントとして扱う前提が必要です。供給元、要求権限、更新履歴、監査ログの取り扱いを確認し、業務システムに近い範囲では自社運用または信頼できる提供元に絞ります。
すぐに全社標準にする必要はありませんが、複数のAIツール利用が始まった段階で、認証・権限・監査の方針を決めておくことをおすすめします。後付けの整理よりも、初期段階での方針決めの方が運用負荷を抑えやすいためです。
MCPは、AIエージェントとツール・データを標準の形で接続する枠組みとして、企業運用の前提になりつつあります。
一方で、認証、権限、供給元、監査、既知の脆弱性といった論点は残っています。ツール数の拡張よりも、認証・監査・供給元の設計を先に決める順序が現実的です。
自社での導入可否に迷う場合は、対象ユースケース、扱うデータ、既存クラウド構成、運用責任者を整理したうえで、AI導入の専門家に相談しましょう。
＼MCP導入と社内AIエージェント運用の設計を相談できます／
Blackfordに相談する
