LASSIC Media らしくメディア
生成AIエージェントのMCP対応・ツール連携を外注
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- 生成AIエージェントを社内のDB・SaaSツール・独自APIに接続する際、個別実装を重ねると保守コストが積み上がりやすくなります。
- MCP(Model Context Protocol)は、この接続方法をAnthropicが標準化した規格で、主要なAIアプリやツールが対応を進めています。
- ツール連携の実装には認可・監査の設計が伴うため、内製と外注の切り分けが検討材料になります。
目次
生成AIエージェントのMCP対応とは、社内システムとの接続を標準化する規格
MCP(Model Context Protocol)とは、生成AIエージェントを社内のデータベース・SaaS・独自APIなど外部システムに接続するための標準規格を指します*2。Anthropicが2024年11月25日に公開したオープンソースの仕様で*1、電子機器をつなぐUSB-Cのように、AIアプリと外部システムの接続方法を統一する狙いがあります*2。
本稿で扱うMCPは、社内文書を検索して回答精度を高めるRAG(検索拡張生成。社内文書などを参照して回答精度を高める手法)や、AIエージェント開発全般とは範囲が異なります。RAGは主に検索対象のデータ整備を扱うのに対し、MCPはツール実行・データ取得・対話テンプレートの受け渡し方法そのものを標準化する規格です。
Claude Desktop・Claude CodeだけでなくChatGPTやVisual Studio Code、Cursorといった開発ツールもMCPへの対応を進めています*2。標準規格である以上、一度実装したMCPサーバーは複数のAIアプリから再利用できる点が特徴です*2。
2024年11月、AnthropicがMCPをオープンソースで公開した背景
MCPが生まれた背景には、生成AIモデルが情報サイロやレガシーシステムの内側に閉じ込められているという課題があります*1。データソースごとに専用の連携コードを書く方式では、接続先が増えるほど開発と保守の負荷が積み上がります*1。
Anthropicはこの課題に対し、MCPの仕様とSDK(ソフトウェア開発キット)をオープンソースで公開しました*1。仕様自体はAnthropic以外の企業も自由に実装でき、開発者はデータソースごとに個別実装を重ねる必要がなくなります*1。
公開から日を置かず、MCPは開発ツールやAIアプリの間で採用が広がりました*2。標準化のメリットは開発者だけでなく、AIアプリやエンドユーザー側にも及ぶと位置づけられています*2。
Host・Client・Serverが担う役割とJSON-RPCによるやり取り
MCPはHost・Client・Serverという3つの参加者で構成されます*3。MCP Host(AIアプリ)は接続先のMCP Serverごとに専用のMCP Clientを生成し、Serverとの通信を維持します*3。
ローカルで動くMCP Serverは主にSTDIO(標準入出力)方式で1つのClientと接続し、リモートのMCP Serverは複数のClientから同時に利用されるHTTP方式が使われます*3。この違いは通信経路の選び方にすぎず、やり取りするデータの形式そのものには影響しません*3。
MCPの内部はデータ層とトランスポート層の2層に分かれます*3。データ層はJSON-RPC(手続き呼び出しをJSON形式でやり取りする軽量な規格)2.0を用いてツール・データ・対話テンプレートの受け渡しを定義し、トランスポート層は接続確立や認証など通信経路そのものを扱います*3。
Tools・Resources・Promptsで実現するツール連携の中身
MCP Serverが提供できる機能は、Tools・Resources・Promptsという3つの要素に整理されています*3。Toolsはファイル操作やデータベース照会のように、AIエージェントが呼び出せる実行可能な関数です*3。
Resourcesはファイルの内容やデータベースの記録など、コンテキストとして参照できるデータそのものを指します*3。Promptsは対話の型を定めた再利用可能なテンプレートで、システムプロンプトや入力例の受け渡しに使われます*3。
AIエージェントはまずtools/listのような一覧取得の呼び出しで利用可能な機能を把握し、必要な機能をtools/callで実行します*3。この一覧は動的に更新される仕組みのため、機能追加のたびにAIエージェント側の実装を変更する必要はありません*3。
既存の連携方式と並べると、MCPの位置づけが分かりやすくなります。
| 項目 | MCP対応 | 独自API連携 | RAG |
|---|---|---|---|
| 目的 | 外部データ・ツールへの標準接続 | 個別システムごとの専用連携 | 社内文書検索による回答精度の向上 |
| 実装の再利用性 | サーバー1つを複数のAIアプリから利用可能*2 | 接続先ごとに個別実装が必要 | 検索基盤ごとに個別実装が必要 |
| 認可の扱い | OAuth 2.1準拠の標準フローを規定*4 | 実装ごとに個別設計 | 検索基盤側の認可に依存 |
| 主な用途 | ツール実行・DB照会・SaaS操作*3 | 個別API呼び出し | 文書・ナレッジの検索拡張生成 |
いずれの方式も生成AIを外部の情報・機能とつなぐ手段ですが、標準化の範囲と認可の扱いが異なります。既存のRAG基盤や個別API連携をすでに持つ場合は、置き換えではなく併用を検討する余地があります。
OAuth 2.1準拠の認可設計——社内API接続で問われるセキュリティ
MCPの認可はHTTPベースの通信を対象とし、実装するかどうかは規格上任意です*4。STDIO方式のローカルServerでは、この認可フローに従わず環境変数などから認証情報を取得する設計が推奨されています*4。
リモートのMCP Serverに認可を実装する場合、OAuth 2.1(認可の業界標準規格)をベースに、認可サーバーのメタデータ発見や動的クライアント登録といった仕組みを組み合わせます*4。MCP ClientはHTTPリクエストのAuthorizationヘッダーにBearerトークンを付与してMCP Serverへアクセスします*4。
認可コードの横取りを防ぐPKCE(認可コードを検証コードと結び付ける仕組み)や、トークンの利用先を限定するリソースパラメータの実装も規格で定められています*4。これらは社内のDB・SaaS・独自APIをAIエージェントに開放する際の、最低限のセキュリティ要件と位置づけられます*4。
見落としやすい落とし穴——トークンパススルーと権限範囲の絞り込み
MCP Serverが受け取ったトークンを検証せずにそのまま下流のAPIへ渡す「トークンパススルー」は、規格上明確に禁止されています*5。検証を省くと、レート制限やアクセス監視といった既存のセキュリティ制御を回避されるおそれがあります*5。
トークンパススルーが起きると、下流システムのログにMCP Server以外の発信元が記録され、監査ログの追跡が難しくなります*5。侵入調査や権限管理の実効性が損なわれる点は、社内システム連携における失敗コストとして無視できません*5。
第三者のAPIを中継するMCP Serverでは「confused deputy(混乱した代理人)問題」も指摘されています*5。静的なクライアントIDのまま動的登録を許可すると、利用者の同意を経ずに認可コードを奪われる経路が生まれます*5。
権限設計では、最初から広い権限(files:*やadmin:*のような包括スコープ)を割り当てないことも重要です*5。段階的に必要な権限だけを要求する設計にすると、トークン漏えい時の影響範囲を絞り込めます*5。
内製と外注の分かれ目——MCPサーバー実装に必要な工数
MCPサーバーの実装自体は、公開されているSDKを使えば土台の部分は組み立てられます*3。判断が分かれるのは、既存の社内システムに合わせた認可設計と、Tools・Resourcesの権限範囲を適切に絞り込む部分です。
内製で担うには、MCPのプロトコル仕様、OAuth 2.1の認可フロー、接続先となる社内DB・SaaS・API側の権限設計という複数領域の知識が要ります*3*4。既存の運用担当者が通常業務と並行して対応する場合、認可設計やトークン監査の検証に割ける時間が限られる場合があります。
専門パートナーに委託する場合は、MCPサーバーの実装からOAuth 2.1準拠の認可設計、権限スコープの段階的な絞り込みまでを一括して依頼できるかどうかが選定の分かれ目になります*4*5。
接続対象が社内の複数システムにまたがる場合や、Tools経由で書き込み・実行系の操作まで許可する場合は、権限設計の見直しに時間を要します。現状のシステム構成を棚卸ししたうえで、内製・外注の切り分けを検討することが実務的です。
まとめ：MCP対応で押さえる3つの判断軸
本稿ではMCP(Model Context Protocol)の仕組みと実装のポイントを、公式情報をもとに整理しました。要点は3つに集約できます。第一に、MCPはAIエージェントを社内システムやツールにつなぐ標準規格で、2024年11月にAnthropicが公開しました*1。第二に、Tools・Resources・Promptsによるツール連携には、OAuth 2.1準拠の認可設計とトークンパススルーの回避が欠かせません*4*5。第三に、認可設計や権限スコープの絞り込みに必要な工数は接続先の数や操作範囲で変わり、内製と外注の判断材料になります。
よくある質問
MCPはClaude以外の生成AIでも使えますか。
MCPはAnthropicがオープンソースで公開した標準規格のため、Claude以外の生成AIでも利用できます*1。実際にChatGPTやVisual Studio Code、Cursorなど主要なAIアプリ・開発ツールもMCPへの対応を進めています*2。
MCPサーバーは自社で構築する必要がありますか。
自社で新規に構築するとは限りません*3。ファイルシステムやデータベースなど汎用的な用途では、公開されている参照実装のMCPサーバーを利用できる場合があります*3。自社固有の業務システムに接続する部分だけを独自に実装するのが一般的です*3。
既存のRAGや独自API連携とMCPは何が違いますか。
RAG(検索拡張生成)は主に社内文書などの検索対象データを整備し、回答の精度を高める手法です。MCPはツールの実行・データの取得・対話テンプレートの受け渡し方法そのものを標準化する規格で、検索に限らずAIエージェントの行動範囲を広げる用途に使われます*3。
社内システムに接続する際の認可はどう設計すればよいですか。
MCPの認可はOAuth 2.1をベースに、認可サーバーのメタデータ発見・動的クライアント登録・Bearerトークンの利用といった仕組みを組み合わせて設計します*4。STDIO方式のローカル接続では、この認可フローの代わりに環境変数などから認証情報を取得する設計が推奨されています*4。
MCPサーバーが受け取ったトークンを社内APIにそのまま渡してもよいですか。
受け取ったトークンをそのまま下流のAPIに渡す「トークンパススルー」は、規格上明確に禁止されています*5。MCPサーバーは自分自身に発行されたトークンであることを検証したうえで、必要な権限だけを使って社内APIにアクセスする設計が求められます*5。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Anthropic「Introducing the Model Context Protocol」（2024年11月25日）（https://www.anthropic.com/news/model-context-protocol）
- *2 出典：Model Context Protocol「What is the Model Context Protocol (MCP)?」（https://modelcontextprotocol.io/introduction）
- *3 出典：Model Context Protocol「Architecture overview」（https://modelcontextprotocol.io/docs/learn/architecture）
- *4 出典：Model Context Protocol「Authorization」（Specification 2025-06-18）（https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization）
- *5 出典：Model Context Protocol「Security Best Practices」（Specification 2025-06-18）（https://modelcontextprotocol.io/specification/2025-06-18/basic/security_best_practices）
