MCPサーバーの構築方法｜社内システムとAIエージェントを接続する仕組み

「AIエージェントから社内システムを操作したい」

「MCPサーバーとは何をするサーバーなのか分からない」

「既存APIをMCP対応させるにはどうすればよい？」

「TypeScriptやPythonでMCPサーバーを構築したい」

このような場合に利用できる仕組みがMCP（Model Context Protocol）です。

MCPを利用すると、AIアプリケーションと、

社内API
データベース
CRM
顧客管理システム
在庫管理システム
ファイル
SaaS

などを、共通の方式で接続できます。

例えば営業AIエージェントに、

ABC社との次回商談を準備して

と指示した場合、

AIエージェント
↓
MCP
↓
CRM検索
↓
過去商談を取得
↓
関連資料を検索
↓
結果をAIへ返す

という構成を作れます。

MCPは、LLMアプリケーションと外部データ・ツールを接続するためのオープンプロトコルです。2026年7月28日版の仕様では、MCPサーバーが主にResources・Prompts・Toolsなどの機能をクライアントへ提供する構成になっています。

この記事では、MCPサーバーとは何か、Tools・Resources・Promptsの違い、社内システムとの接続方法、TypeScript・Pythonによる構築方法、認証・セキュリティについて解説します。

MCPとは

MCPはModel Context Protocolの略称です。

簡単に言えば、

AI
と
外部システム
を接続するための共通ルール

です。

従来、AIと外部システムを連携する場合は、それぞれ個別に実装する必要がありました。

例えば、

AI
↓
Salesforce専用連携

AI
↓
Google Drive専用連携

AI
↓
社内CRM専用連携

という形です。

MCPでは、

AIアプリケーション
↓
MCP
↓
各種システム

という共通インターフェースを利用できます。

考え方としては、

USB

に近い部分があります。

USB対応機器であれば共通の接続方式を利用できるように、MCP対応のAIクライアントとMCPサーバーであれば、共通仕様を使って機能を接続できます。

MCPサーバーとは

MCPサーバーは、

AIから利用できる機能やデータを公開するサーバー

です。

例えば自社に顧客管理システムがあるとします。

通常は、

GET /api/customers/{id}

のようなAPIが存在します。

これをAIエージェントから利用したい場合、MCPサーバー側に、

get_customer

というToolを用意します。

処理は、

AI
↓
get_customerを実行
↓
MCPサーバー
↓
社内API
↓
顧客情報取得
↓
MCPサーバー
↓
AI

となります。

つまりMCPサーバーは、

AI
と
既存システム
の橋渡し

を担当します。

MCPのHost・Client・Serverの違い

MCPの構成を理解するために、3つの役割を整理します。

Host

AIアプリケーション全体です。

例えば、

AIチャット
AI IDE
AIエージェントアプリ

などです。

Client

Host内部でMCPサーバーとの通信を担当します。

Server

AIへ利用可能なデータや機能を提供します。

構成としては、

Host
└─ MCP Client
      ↓
   MCP Server
      ↓
   社内API・DB

となります。

MCPの現行仕様でも、Hostは接続を開始するLLMアプリケーション、ClientはHost内のコネクター、Serverはコンテキストや機能を提供するサービスとして整理されています。

MCPサーバーが提供する3つの主要機能

MCPサーバーでは主に、

Tools
Resources
Prompts

を提供できます。

公式の開発ドキュメントでも、この3つがMCPサーバーの主要な機能として整理されています。

それぞれ役割が違います。

Toolsとは

Toolsは、

AIが実行できる機能

です。

例えば、

顧客を検索する

在庫を確認する

注文情報を取得する

メールの下書きを作る

などです。

MCP仕様では、Toolsはモデルが外部システムへ問い合わせたり、APIを呼び出したり、計算などを実行するための機能として定義されています。

例えば、

get_customer

というToolを作るとします。

入力は、

customer_id

です。

AIが、

ABC001の顧客情報を取得

と判断すると、

tools/call
↓
get_customer
↓
MCPサーバー
↓
顧客管理API

という処理になります。

Toolsの具体例

社内CRMなら、

search_customer
get_customer
get_meeting_history

在庫管理なら、

search_product
get_inventory
get_order

問い合わせ管理なら、

get_inquiry
search_faq
create_reply_draft

などが考えられます。

重要なのは、

AIにデータベースを自由操作させる

のではなく、

許可されたToolだけ公開する

ことです。

Toolsでは入力形式を定義する

例えば、

get_customer

なら、

{
  "customer_id": "ABC001"
}

という入力にします。

MCPではToolの入力をJSON Schemaで定義できます。

現行仕様では、Toolにはname・description・inputSchemaなどを設定し、inputSchemaにはJSON Schemaを利用します。

そのため、

customer_idは文字列

quantityは整数

など、AIから受け取る値を制御できます。

Resourcesとは

Resourcesは、

AIやユーザーが参照するデータ

です。

Toolsが、

処理を実行する

ものなのに対して、Resourcesは、

情報を提供する

ものです。

例えば、

商品マニュアル
社内規程
設定ファイル
APIレスポンス
ファイル
データベースから取得した情報

などをResourcesとして公開できます。

例えば、

customer://ABC001

というResourceから、

会社名：株式会社ABC
契約プラン：Business
担当者：田中

という情報を取得するイメージです。

ToolsとResourcesの違い

大まかには、

Resources
→ データを読む

Tools
→ 処理を行う

と整理できます。

例えば、

商品マニュアルを見る
→ Resource

在庫を検索する
→ Tool

メールを送信する
→ Tool

です。

ただし、実際の設計では用途に応じて使い分けます。

Promptsとは

Promptsは、

再利用可能なプロンプトテンプレート

です。

例えば営業担当者向けに、

顧客情報を分析して
次回商談で確認すべき事項をまとめてください

というプロンプトを毎回入力する代わりに、

prepare_sales_meeting

というPromptとして提供できます。

例えば、

顧客ID：ABC001

だけ入力すれば、

顧客情報を確認し、
過去商談を分析し、
次回商談の確認事項をまとめてください。

という定型処理を呼び出せます。

MCPサーバーの構成例

例えば社内営業システムをAIから利用する場合を考えます。

AIエージェント
↓
MCP Client
↓
MCP Server
├─ search_customer
├─ get_customer
├─ get_meeting_history
├─ search_documents
└─ create_email_draft
↓
社内システム
├─ CRM
├─ PostgreSQL
├─ 文書検索
└─ メールAPI

ユーザーが、

ABC社との次回商談を準備して

と入力します。

AIは、

顧客情報が必要

と判断します。

そこで、

search_customer

を実行します。

次に、

過去商談が必要

と判断して、

get_meeting_history

を実行します。

そして必要な情報をまとめて回答します。

MCPと通常のAPIの違い

よくある疑問が、

APIがあるならMCPはいらないのでは？

というものです。

API自体は今後も必要です。

例えば、

GET /customers/ABC001

というAPIをMCPへ置き換える必要はありません。

むしろ、

AI
↓
MCP Server
↓
既存API
↓
業務システム

という構成にできます。

つまり、

API
→ システム同士のインターフェース

MCP
→ AIから利用しやすい共通インターフェース

と整理すると分かりやすいでしょう。

既存APIをそのままMCPから利用する

例えば、

GET /api/customers/{id}

というAPIがすでに存在するとします。

MCPサーバーに、

get_customer

というToolを作り、

get_customer
↓
GET /api/customers/{id}

と接続します。

既存システム全体をMCP対応へ作り直す必要はありません。

MCPサーバーを構築するメリット

AI側の実装を共通化しやすい

MCPを利用しない場合、

AIアプリA
→ 独自API連携

AIアプリB
→ 独自API連携

AIアプリC
→ 独自API連携

となる可能性があります。

MCPサーバーを用意すると、

AIアプリA ─┐
AIアプリB ─┼→ MCP Server → 社内システム
AIアプリC ─┘

という構成を作りやすくなります。

AIへ公開する機能を整理できる

既存APIには、

管理者向けAPI
内部処理用API
外部公開API

などさまざまな機能があります。

AIへ全部公開する必要はありません。

MCPサーバーで、

AIが利用してよい機能だけ

をToolsとして定義できます。

AIエージェントとの相性がよい

AIエージェントでは、

状況を判断
↓
必要なツールを選択
↓
実行
↓
結果を確認

という処理を行います。

MCP Toolsは、この、

AIが利用できるツール

を標準化するために利用できます。

MCPサーバーの通信方法

2026年7月28日版のMCP仕様では、標準トランスポートとして主に、

stdio
Streamable HTTP

が定義されています。

stdio

stdioでは、MCP ClientがローカルプロセスとしてMCP Serverを起動します。

AIアプリ
↓
MCP Client
↓
ローカルMCP Server

という構成です。

例えば開発ツールから、

ローカルファイル
Git
開発環境

などへアクセスする用途と相性があります。

Streamable HTTP

ネットワーク上のMCPサーバーへHTTPで接続する方式です。

AIアプリ
↓
HTTPS
↓
MCP Server
↓
社内API

となります。

企業で、

複数社員
↓
共通MCP Server

として利用する場合は、HTTPベースの構成を検討しやすいでしょう。

2026年7月28日版ではプロトコルコアがステートレス化され、リクエストごとに必要なメタデータを持つ構成になっています。

MCPサーバーをTypeScriptで構築する

MCPには公式SDKが提供されています。

TypeScriptの公式クイックスタートでは、MCPサーバーインスタンスを作成し、Toolを登録する構成が紹介されています。

概念的には、

McpServer
↓
Toolを登録
↓
処理内容を実装
↓
Transportで公開

となります。

例えば、

get_customer

というToolなら、

入力：
customer_id

↓

顧客APIを呼び出す

↓

結果を返す

という処理を実装します。

TypeScriptは、

Next.js
Node.js
REST API
Webシステム

との連携が多い場合にも扱いやすい選択肢です。

MCPサーバーをPythonで構築する

Python用の公式SDKもあります。

公式クイックスタートでは、Python用MCP SDKを利用してサーバーを作成する方法が案内されています。

Pythonは、

AI処理
データ分析
PDF解析
機械学習
Python製社内ツール

などと組み合わせる場合に向いています。

例えば、

AI
↓
MCP
↓
Python
↓
PDF解析

という構成も作れます。

JavaでもMCPサーバーを構築できる？

可能です。

公式MCP開発ドキュメントでは、Python・TypeScriptだけでなくJava、Kotlin、C#、Ruby、Rust、Goなど複数言語向けの実装方法が案内されています。

そのため、既存システムがJavaで構築されているからといって、MCP導入のためにシステム全体をPythonへ移行する必要はありません。

例えば、

AI
↓
MCP Server
↓
Spring Boot API
↓
PostgreSQL

という構成も検討できます。

MCPサーバー構築の手順

1．AIに何をさせたいか決める

最初から、

MCPサーバーを作る

ことを目的にしません。

例えば、

営業担当者が
CRMと商談履歴を探す時間を減らしたい

という課題を設定します。

2．AIへ公開する機能を洗い出す

例えば営業支援なら、

顧客検索
顧客詳細取得
商談履歴取得
提案資料検索

などです。

3．Tools・Resources・Promptsに分類する

例えば、

顧客検索
→ Tool

商談履歴取得
→ Tool

商品マニュアル
→ Resource

商談準備テンプレート
→ Prompt

と整理します。

すべてをToolにする必要はありません。

4．既存APIを確認する

例えば、

顧客検索API
注文検索API
在庫API

がすでに存在するなら、そのまま再利用します。

存在しない場合は、

MCP Server
↓
DB

と直接アクセスする構成も考えられます。

ただし、既存Webシステムがあるなら、

MCP
↓
既存バックエンドAPI
↓
DB

とした方が、既存の業務ルールを再利用しやすいケースがあります。

5．入力Schemaを設計する

例えば顧客検索なら、

customer_name

だけでよいかもしれません。

注文検索なら、

order_id

です。

AIから不要な値を受け取らないよう、入力形式を限定します。

6．返却するデータを必要最小限にする

例えば、

get_customer

で、

顧客テーブル全列

を返す必要はありません。

AIが必要なのが、

顧客名
契約プラン
担当者

だけなら、その情報だけ返します。

7．認証・権限を設計する

企業向けMCPでは重要です。

例えば、

営業A
→ 自分の担当顧客のみ

管理者
→ 全顧客

というルールがあるなら、MCP経由でも同じ制御を適用します。

MCPサーバーの認証

HTTPベースのMCPでは、認可仕様も定義されています。

2026年7月28日版ではHTTPベースの認可についてOAuth系の標準を利用する仕様があり、MCP Serverは保護リソースとしてアクセストークンを検証する構成が定められています。

つまり、

AIだから特別な認証

にするのではなく、

ユーザー
↓
認証
↓
アクセストークン
↓
MCP Server
↓
権限確認

とします。

最小権限を適用する

例えば、

customer:read

と、

customer:write

を分けます。

営業支援AIが顧客情報を確認するだけなら、

customer:read

だけ与えれば十分です。

MCPの認可仕様でも、クライアントが必要以上の権限を要求しない最小権限の考え方が示されています。

読み取りToolと更新Toolを分ける

例えば、

get_customer

と、

update_customer

を別Toolにします。

そして、

get_customer
→ 自動実行可能

update_customer
→ 人による確認必須

とできます。

MCPサーバーで特に注意したいセキュリティ

MCPはAIから外部システムへアクセスできるため、セキュリティ設計が重要です。

MCP仕様自体も、Toolsが任意のコード実行につながる可能性を持つことから、ユーザー同意・アクセス制御・データ保護・Tool利用時の確認を重要な原則として挙げています。

AIへ強すぎるToolを渡さない

例えば、

execute_sql(sql)

というToolをAIへ渡すと、

DELETE
UPDATE
DROP

なども実行できる可能性があります。

代わりに、

search_customer()

get_order()

get_inventory()

など用途を限定します。

更新処理はHuman in the Loopにする

例えば、

AI
↓
update_customer
↓
即更新

ではなく、

AI
↓
更新内容を提案
↓
担当者が確認
↓
更新

とします。

Toolはモデルから自動的に呼び出せる設計ですが、MCP仕様では安全性の観点から、人がTool実行を拒否できる仕組みや確認UIを設けることが推奨されています。

MCPサーバー側でも権限を確認する

AIクライアントから、

このToolを実行してください

と送られてきたからといって、そのまま実行してはいけません。

リクエスト
↓
認証
↓
権限確認
↓
入力チェック
↓
業務処理

とします。

APIキーをAIへ渡さない

例えばCRM APIキーを、

AIのプロンプト

に含める必要はありません。

AI
↓
MCP Tool
↓
MCP Server
↓
Secrets
↓
CRM API

という構成にします。

実行ログを残す

企業利用では、

誰が
いつ
どのToolを
どんな引数で
実行したか

を追跡できるようにします。

例えば、

User: user001

Tool:
get_customer

Input:
customer_id = ABC001

Result:
success

とします。

更新系Toolなら特に重要です。

MCPサーバーとRAGの違い

MCPとRAGも別の技術です。

RAGは、

関連文書を検索して
AIへ渡す

仕組みです。

MCPは、

AIと外部機能を接続する

ためのプロトコルです。

例えば、

AI
↓
MCP Tool
↓
RAG検索API
↓
社内文書

という組み合わせもできます。

つまり、

MCP
├─ CRM Tool
├─ 在庫Tool
└─ RAG Tool

という構成です。

MCPとAIエージェントの違い

AIエージェントは、

何をする必要があるか判断する

側です。

MCPは、

そのために使える機能を提供する

側です。

例えば、

AIエージェント
↓
「在庫確認が必要」と判断
↓
MCP
↓
get_inventory
↓
在庫管理システム

となります。

つまり、

AIエージェント
→ 判断

MCP
→ 接続方法

Tool
→ 実際に利用できる機能

と整理できます。

MCPサーバーを構築した方がよいケース

例えば、

AIから複数の社内機能を利用したい
AIエージェントを開発している
複数AIアプリから同じ機能を利用したい
社内APIをAIへ安全に公開したい
AI向けの共通インターフェースを作りたい

場合です。

特に、

社内APIがすでに存在する

企業では、APIをMCP Toolsとしてラップすることで比較的小さく導入できる可能性があります。

MCPサーバーが不要なケース

例えば、

一つのWebシステムから
一つのAI APIを呼び出すだけ

なら、MCPを使う必要がない場合があります。

Webシステム
↓
OpenAI API

だけで十分です。

また、

決められたバッチ処理

なら通常プログラムやn8nなどの方がシンプルな場合があります。

MCPを導入する目的は、

新しい技術だから使う

ことではありません。

複数AIと複数システムの接続を
共通化したい

場合に検討します。

MCPサーバー構築でよくある失敗

既存APIを全部Toolにする

APIが100個あるから、

100個すべてMCP Toolsとして公開

する必要はありません。

AIが実際に必要とする業務単位で設計します。

例えば、

get_customer
get_contract
get_order

などです。

Toolの粒度が細かすぎる

例えば、

get_customer_name
get_customer_email
get_customer_address

のように細かくしすぎると、AIが何度もToolを実行する必要があります。

場合によっては、

get_customer

で必要な情報をまとめて返した方が効率的です。

Toolの粒度が大きすぎる

逆に、

execute_anything

のような万能Toolはリスクがあります。

AIが利用できる操作範囲を限定します。

権限管理をAI任せにする

あなたが閲覧してよい情報だけ取得してください

というプロンプトだけでは十分ではありません。

MCPサーバー側で権限を確認します。

更新系Toolを最初から公開する

PoCでは、

検索
閲覧
要約

など読み取り系から始める方法があります。

精度を確認してから、

更新
送信
削除

を追加します。

MCPサーバー構築に関するよくある質問

MCPは何の略ですか？

Model Context Protocolの略です。

LLMアプリケーションと外部データ・ツールを接続するためのオープンプロトコルです。

MCPサーバーを作ればAIモデルも必要なくなりますか？

必要です。

MCPサーバー自体が生成AIになるわけではありません。

AIモデル
+
MCP
+
外部システム

を組み合わせます。

REST APIとMCPはどちらを使えばよいですか？

置き換えではありません。

既存REST APIをMCPサーバーから呼び出す構成が可能です。

TypeScriptでMCPサーバーを作れますか？

可能です。

公式TypeScript SDKが提供されており、McpServerへToolなどを登録する形で実装できます。

Pythonでも作れますか？

可能です。

公式Python SDKによる構築方法も提供されています。

Javaの既存システムでもMCPを導入できますか？

可能です。

Java側にMCPサーバーを構築する方法もあれば、TypeScriptやPythonでMCPサーバーを作り、既存Java APIを呼び出す構成もあります。

社内データベースへ直接接続できますか？

技術的には可能ですが、既存業務システムにAPIがある場合は、そのAPIを経由した方が既存の権限制御や業務ロジックを再利用しやすい場合があります。

MCPサーバーには認証が必要ですか？

ローカル用途と社内・外部向け用途で異なります。

HTTP経由で機密データや社内システムへアクセスする場合は、認証・認可を設計することが重要です。MCPにはHTTPベースの認可仕様が定義されています。

hiro-dev-labのMCP・AIシステム開発

hiro-dev-labでは、AIエージェントや生成AIと既存Webシステムを接続する仕組みの構築を支援しています。

例えば、

MCPサーバーのPoC
TypeScriptによるMCPサーバー開発
PythonによるMCPサーバー開発
既存REST APIのMCP対応
社内システムとのAPI連携
データベース連携
AIエージェント向けTools設計
RAGとの連携
OpenAI APIとの連携
Difyとの連携
n8nとの連携
認証・権限設計
Human in the Loop
既存WebシステムへのAI機能追加

などを検討できます。

既存システム全体を作り直す必要はありません。

例えば、

既存Webシステム
↓
既存REST API
↓
MCP Serverを追加
↓
AIエージェント

という形で導入できます。

MCPサーバー構築は「AIに何を許可するか」から設計する

MCPを利用すると、AIとさまざまなシステムを接続できます。

例えば、

AI
↓
MCP
├─ 顧客検索
├─ 商談履歴
├─ 在庫確認
├─ 社内文書検索
└─ メール下書き

という構成です。

ただし、

AIから何でも操作できるようにする

ことが目的ではありません。

重要なのは、

AIが必要な機能だけ
安全に公開する

ことです。

基本的には、

1．AIで効率化したい業務を決める
↓
2．必要なデータ・処理を洗い出す
↓
3．Tools・Resources・Promptsを設計
↓
4．既存APIを再利用
↓
5．MCPサーバーを構築
↓
6．認証・権限を追加
↓
7．読み取り系ToolからPoC
↓
8．実際のAIエージェントで評価
↓
9．必要に応じて更新系Toolを追加

という流れで進めます。

MCPは、AIエージェントが普及する中で、

AI
と
企業システム
をどのようにつなぐか

を考えるうえで重要な技術の一つです。

「既存APIをMCP対応させたい」

「社内システムとAIエージェントを連携したい」

「MCPサーバーをTypeScript・Pythonで構築したい」

「まず一つの社内APIだけMCP化して試したい」

このような段階からでも、お気軽にお問い合わせください。

MCP・AIエージェント開発について相談する