MCPでAIと社内システムを連携する方法｜API・DB・認証設計を解説

「AIから社内システムの情報を検索できるようにしたい」

「CRMや在庫管理システムをAIエージェントから操作したい」

「既存APIをMCP経由でAIへ公開したい」

「社内データをAIへつなぐときの権限管理が不安」

このような場合に検討できるのが、MCP（Model Context Protocol）を利用した社内システム連携です。

例えば営業担当者がAIへ、

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

と依頼したとします。

MCPを利用すると、

AIエージェント
↓
MCP
↓
CRM
↓
ABC社を検索
↓
過去商談を取得
↓
社内資料を検索
↓
AIが商談準備を作成

という構成を作れます。

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

公式ドキュメントでは、MCPサーバーからAIへ主にTools、Resources、Promptsを提供でき、ToolsではAPI呼び出しやデータベース検索などの処理を実行できます。

ただし、企業でMCPを利用する場合に重要なのは、

AIから社内データへ接続できる

ことだけではありません。

誰が
どのデータへ
どの操作まで
アクセスできるか

を既存システムと同じように制御する必要があります。

この記事では、MCPを利用してAIと社内システムを連携する構成、既存APIやデータベースとの接続方法、Toolsの設計、認証・権限管理、導入手順について解説します。

MCPで社内システムを連携するとは

MCPを利用すると、AIから利用できる社内機能を共通の形式で公開できます。

例えば企業内に、

顧客管理システム
CRM
在庫管理システム
販売管理システム
問い合わせ管理
社内文書
ファイルサーバー

があるとします。

従来であれば、

営業AI
→ CRM専用実装

問い合わせAI
→ FAQ専用実装

在庫AI
→ 在庫API専用実装

のように個別接続するケースがあります。

MCPを利用すると、

AIアプリ
↓
MCP Client
↓
MCP Server
├─ 顧客検索
├─ 商談履歴取得
├─ 在庫確認
├─ 注文検索
└─ 社内文書検索
↓
既存社内システム

という形で整理できます。

MCPそのものがCRMやデータベースになるわけではありません。

既存システムとAIの間に、

AIから利用できる共通インターフェース

を作るイメージです。

MCPを導入しても既存システムを作り直す必要はない

すでに業務システムが稼働している場合、

既存REST API

を再利用できます。

例えば現在、

GET /api/customers/{id}

という顧客取得APIがあるとします。

MCP Serverに、

get_customer

というToolを用意します。

内部では、

AI
↓
get_customer
↓
MCP Server
↓
既存REST API
↓
顧客情報

とします。

つまり、

既存システム
→ そのまま

既存API
→ そのまま

AI向けインターフェース
→ MCPを追加

という構成が可能です。

MCPは既存APIを置き換えるものではなく、その上にAI向けの接続レイヤーを追加する方法として利用できます。

MCPとAPIの関係

MCPとREST APIは競合する技術ではありません。

役割が異なります。

項目	REST API	MCP
主な利用者	プログラム	AIアプリ・エージェント
目的	システム間連携	AIとツール・データの接続
機能公開	Endpoint	Tools・Resourcesなど
入力	API仕様	Schema
AIによる発見	別途実装	Tool一覧として発見可能
既存システム利用	本体	APIをラップ可能

例えば、

MCP Tool
↓
REST API
↓
Spring Boot
↓
PostgreSQL

という構成にできます。

そのため、既存システムにAPIが整備されている企業ほど、MCPを追加しやすいケースがあります。

MCPで連携できる社内システムの例

さまざまなシステムを接続できます。

顧客管理・CRM

例えば次のToolsを用意します。

search_customer

get_customer

get_meeting_history

get_sales_history

営業担当者が、

ABC社について教えて

と入力すると、

AI
↓
search_customer
↓
ABC社を特定
↓
get_customer
↓
顧客情報取得
↓
必要ならget_meeting_history
↓
AIが回答

と処理できます。

在庫管理システム

例えば、

search_product

get_inventory

get_stock_history

を用意します。

ユーザーが、

商品Aはあと何個ありますか？

と質問すると、

AI
↓
get_inventory
↓
在庫管理API
↓
32個
↓
AI
↓
「現在32個あります」

と回答できます。

在庫数をAIに推測させず、現在の業務システムから取得することが重要です。

販売管理システム

例えば、

get_order

search_orders

get_sales_summary

を用意します。

先月のABC社の注文をまとめて

という依頼から、

顧客特定
↓
注文検索
↓
注文データ取得
↓
AIが要約

という処理を構築できます。

問い合わせ管理システム

例えば、

search_customer

get_inquiry_history

search_faq

create_reply_draft

を用意します。

問い合わせ
↓
AI
↓
顧客情報確認
↓
過去対応確認
↓
FAQ検索
↓
返信案作成

まで支援できます。

MCPとデータベースを連携する方法

社内システムのデータは、多くの場合データベースに保存されています。

例えば、

PostgreSQL
MySQL
SQL Server
Oracle

などです。

MCPからDBを利用する方法は大きく2つあります。

方法1．既存APIを経由する

おすすめしやすい構成です。

AI
↓
MCP Server
↓
既存API
↓
Service
↓
DB

既存APIに、

権限管理
バリデーション
業務ルール

が実装されている場合、それらを再利用できます。

例えば顧客情報取得時に、

退会済み顧客は表示しない

担当部署以外には表示しない

というロジックがすでにAPIにあれば、そのまま利用できます。

方法2．MCP ServerからDBへ直接接続する

小規模なシステムや専用分析用途では、

AI
↓
MCP Server
↓
PostgreSQL

という構成も可能です。

ただし、

AIが自由なSQLを生成
↓
そのまま本番DBへ実行

という設計には注意が必要です。

例えばAIへ、

execute_sql(sql)

というToolを渡すと、

SELECT

だけでなく、

UPDATE
DELETE
DROP

などを生成する可能性も考える必要があります。

企業システムでは、

get_customer()

search_orders()

get_inventory()

など、用途を限定したToolsの方が制御しやすくなります。

MCPのToolsはAIから外部APIやDB操作などを実行するための仕組みですが、公式仕様でもTool実行についてユーザーが拒否できる仕組みなど、人による制御を設けることが推奨されています。

MCP Toolsは「業務単位」で設計する

既存APIが100個あるからといって、

100 API
=
100 MCP Tools

にする必要はありません。

AIが実際の業務で必要とする単位へ整理します。

例えば顧客管理システムに、

GET /customers/{id}
GET /customers/{id}/contacts
GET /customers/{id}/contracts
GET /customers/{id}/sales

という4APIがあるとします。

そのまま4Toolにする方法もありますが、

get_customer_overview

として必要情報をまとめて取得する方が適切な場合もあります。

Toolが細かすぎる場合

AIが、

顧客基本情報取得
↓
担当者取得
↓
契約取得
↓
売上取得

と4回呼び出します。

API回数やAIの判断回数が増えます。

Toolが大きすぎる場合

一方で、

execute_customer_operation

のような万能Toolに、

検索
更新
削除
契約変更

を全部入れるとリスクが高くなります。

そのため、

AIが理解しやすい

+

権限を制御しやすい

+

業務上意味がある

粒度にします。

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

例えば、

get_customer

と、

update_customer

は分けます。

そして、

get_customer
→ AIが自動実行

update_customer
→ 人が承認

とできます。

さらに、

delete_customer

についてはAIへそもそも公開しない判断もできます。

MCPとRAGを組み合わせる

企業には構造化データだけでなく、大量の文書があります。

例えば、

PDF
マニュアル
社内規程
FAQ
技術資料
過去事例

です。

このような情報はRAGで検索できます。

構成としては、

AIエージェント
↓
MCP
├─ CRM Tool
├─ 在庫Tool
├─ 注文Tool
└─ 社内文書検索Tool
          ↓
         RAG

となります。

質問によって情報源を切り替えます。

例えば、

商品Aは現在何個ある？
→ 在庫API

商品Aの返品条件は？
→ RAG

です。

構造化データと文書データを分ける

この設計は重要です。

例えば、

現在の契約プラン

ならCRMや契約DBから取得します。

一方、

契約変更時の社内手続き

なら社内規程をRAGで検索します。

つまり、

現在値・業務データ
→ API・DB

文章・規程・マニュアル
→ RAG

と分けます。

MCPを使った営業AIの構成例

例えば企業向け営業支援AIを考えます。

ユーザー
↓
AIアプリ
↓
MCP Client
↓
MCP Server
├─ search_customer
├─ get_customer
├─ get_meeting_history
├─ get_sales_history
└─ search_documents
↓
CRM / DB / RAG

営業担当者が、

明日のABC社との商談準備をして

と依頼します。

AIは、

1．ABC社を特定
↓
2．基本情報取得
↓
3．過去商談取得
↓
4．売上履歴取得
↓
5．関連提案資料検索
↓
6．情報を整理
↓
7．商談時の確認事項を作成

と処理します。

人がCRMやファイルサーバーを行き来する時間を減らせます。

MCPを使った社内ヘルプデスクの構成例

例えば、

社員：
VPNへ接続できません

という問い合わせです。

AI
↓
MCP
↓
search_manual
↓
VPNマニュアル取得
↓
AIが案内

さらに端末管理システムと連携できるなら、

get_device

を利用して、

端末OS
VPN設定
端末状態

などを取得する構成も考えられます。

MCPを使った問い合わせ対応の構成例

顧客から問い合わせ
↓
AI
↓
MCP
├─ get_customer
├─ get_contract
├─ get_inquiry_history
└─ search_faq
↓
回答案作成
↓
担当者確認
↓
送信

この場合、

顧客情報
→ CRM

契約内容
→ 契約システム

FAQ
→ RAG

文章生成
→ AI

という役割分担です。

社内システム連携では認証・権限管理が重要

企業向けMCPでは、

接続できるか

だけでは不十分です。

重要なのは、

誰として接続しているか

です。

例えば、

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

営業部長
→ 部門顧客すべて

管理者
→ 全顧客

という既存ルールがあるとします。

MCP経由でも同じルールを維持します。

AI専用の共通管理者アカウントを使わない

例えば、

AI用アカウント
→ 全顧客閲覧可能

としてしまうと、

通常画面ではアクセスできないデータでも、

AI経由なら見える

という問題が発生する可能性があります。

基本的には、

ユーザー
↓
認証
↓
ユーザー権限
↓
MCP Server
↓
社内API

とします。

HTTPベースのMCPでは認可仕様が用意されており、制限されたMCPサーバーへユーザーの代わりにアクセスするための認可フローが定義されています。

企業管理の認証基盤と組み合わせる

MCPでは企業向けの認証・認可も進化しています。

2026年6月にはEnterprise-Managed AuthorizationがStableとなり、組織側のIdentity Providerを利用してMCPサーバーへのアクセスを中央管理する仕組みが公開されています。

企業利用では、

社員
↓
会社の認証基盤
↓
MCP
↓
許可された社内システム

という考え方が重要になります。

最小権限にする

例えば営業AIに必要なのが、

顧客閲覧
商談閲覧

だけなら、

契約変更
顧客削除
請求変更

まで許可する必要はありません。

AIだから特別扱いするのではなく、

通常のアプリケーションと同じ
最小権限

を適用します。

AIへ必要以上のデータを返さない

例えば、

get_customer

でAIが必要なのが、

会社名
担当者
契約プラン

だけなら、

銀行口座
個人住所
生年月日

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

DB
↓
必要項目だけ取得
↓
MCP
↓
AI

とします。

これはセキュリティだけでなく、AIへの入力データ量を減らす点でも有効です。

MCP連携でHuman in the Loopを入れる

Toolsはすべて自動実行させる必要はありません。

例えば、

顧客検索
→ 自動

注文確認
→ 自動

メール下書き
→ 自動

メール送信
→ 人が承認

契約変更
→ 人が承認

データ削除
→ AIには許可しない

とします。

MCPの公式ドキュメントでもToolsはモデルから呼び出せる一方、セキュリティ上、利用者がTool実行を拒否できる状態にすることが推奨されています。

MCP連携のログを残す

本番では最低限、

誰が

いつ

どのMCP Serverへ

どのToolを

どの引数で

実行し

成功したか

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

例えば、

User:
sales001

Tool:
get_customer

customer_id:
ABC001

Result:
success

です。

更新系Toolでは、

変更前

変更内容

承認者

変更後

なども記録します。

MCPと社内システムを連携する手順

1．対象業務を決める

まず、

MCPを導入したい

ではなく、

何の業務を効率化したいか

を決めます。

例えば、

営業担当者が
商談準備に毎回30分かかる

という課題です。

2．必要な情報源を洗い出す

例えば、

CRM
商談履歴
売上データ
提案資料

です。

3．既存APIを確認する

例えば、

CRM API
売上API
文書検索API

があるか確認します。

APIが存在するなら再利用します。

4．MCP Toolsを設計する

例えば、

search_customer

get_customer

get_meeting_history

get_sales_history

search_documents

です。

5．読み取り系だけでPoCする

最初から、

更新
削除
送信

を許可する必要はありません。

検索
↓
閲覧
↓
要約

だけで検証します。

6．認証・権限を追加する

既存システムと同じユーザー権限を適用します。

例えば、

user_id
↓
MCP
↓
既存API
↓
担当顧客だけ返す

とします。

7．実際の業務で評価する

例えば、

商談準備
30分
↓
MCP＋AI
↓
7分

になったかを確認します。

単に、

AIからCRMへアクセスできた

だけでは不十分です。

8．必要なら更新系Toolを追加する

読み取り系で効果と安全性を確認した後、

create_email_draft

update_customer_note

などを追加します。

重要な操作には承認を入れます。

MCP導入で確認したいシステム構成

企業では例えば、

AIアプリ
↓
MCP Server
↓
API Gateway
↓
既存業務API
↓
Service
↓
DB

とできます。

この構成なら、

MCP専用に
業務ロジックを全部作り直す

必要がありません。

既存バックエンドの、

認証
権限
バリデーション
業務ルール

を再利用できます。

リモートMCPサーバーを運用する場合

複数社員から利用する場合、

社員A ─┐
社員B ─┼→ AI → Remote MCP Server
社員C ─┘

という構成になります。

2026-07-28 MCP仕様では、リモート環境で一般的なHTTPインフラへ載せやすいステートレスなコアへ変更され、認可もOAuth/OpenID Connectの実運用により合わせる方向で強化されています。

企業利用では、

HTTPS
認証
権限
ログ
レート制限
タイムアウト
監視

など、通常のWeb APIと同様の運用設計が必要です。

MCPが向いている企業

特に次のような場合は検討しやすいでしょう。

複数の社内システムがある
社内APIが整備されている
AIエージェントを導入したい
複数のAIアプリから同じ社内機能を使いたい
社内データをAIへ安全に公開したい
AI連携部分を共通化したい

例えば、

CRM
在庫
販売
社内文書

をそれぞれ複数AIアプリから利用する場合です。

MCPを使わなくてもよいケース

一方、

Webシステムから
OpenAI APIを一回呼ぶだけ

ならMCPは不要な場合があります。

例えば、

顧客履歴
↓
AIで要約
↓
画面表示

だけなら、

Webシステム
↓
OpenAI API

という構成の方がシンプルです。

また、

毎朝CSVを取得
↓
Slackへ通知

のような決められた処理なら、n8nや通常プログラムの方が適していることもあります。

MCPを利用する価値が大きいのは、

複数のAI
×
複数の外部システム

を接続していくケースです。

MCPと社内システム連携でよくある失敗

既存APIをすべて公開する

AIが必要な機能だけToolsとして公開します。

管理者権限でMCP Serverから接続する

ユーザーごとの権限を引き継げる構成を検討します。

自由SQL Toolを作る

用途ごとに限定したToolsを作る方が安全です。

読み取りと更新を同じToolにする

get

と、

update

を分離します。

最初から自動更新する

まず読み取り・提案から始めます。

MCP化することが目的になる

AI連携によって、

業務時間が何時間減るか

を評価します。

MCPと社内システム連携に関するよくある質問

既存のREST APIをMCPから利用できますか？

可能です。

MCP ServerのToolから既存REST APIを呼び出す構成にできます。

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

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

可能ですが、既存APIに業務ルールや権限制御がある場合は、API経由の方がそれらを再利用しやすい場合があります。

Javaの業務システムとも連携できますか？

可能です。

例えば、

MCP Server
↓
Spring Boot API
↓
PostgreSQL

という構成にできます。

MCP Server自体をJavaで実装する方法もあります。

RAGもMCPから利用できますか？

利用できます。

社内文書検索を一つのToolとしてMCP Serverから公開する構成が考えられます。

AIからデータを更新できますか？

技術的には可能です。

ただし、最初は読み取り専用から始め、更新系処理はHuman in the Loopを入れる方法が安全です。

MCPを導入すればREST APIは不要になりますか？

不要にはなりません。

MCP Serverから既存REST APIを利用できます。

MCPの導入には認証が必要ですか？

社内の機密情報や業務システムへ接続する場合は重要です。

HTTPベースのMCPには認可仕様があり、企業向けの中央管理方式も整備が進んでいます。

hiro-dev-labのMCP・社内システム連携開発

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

例えば、

MCPサーバー構築
既存REST APIのMCP連携
社内システムとのAPI連携
CRM・顧客管理との連携
データベース連携
AI向けTools設計
RAGとの連携
OpenAI APIとの連携
TypeScript・PythonによるAI機能開発
既存JavaシステムとのAPI連携
認証・権限設計
Human in the Loop
小規模なMCP PoC

などを検討できます。

例えば、

既存業務システム
↓
既存REST API
↓
MCP Server
↓
AIエージェント

という形で、現在のシステムを活かしながらAI機能を追加できます。

MCPによる社内システム連携は「既存APIを活かす」と進めやすい

MCPを導入するために、現在のシステムをすべて作り直す必要はありません。

基本的には、

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

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

重要なのは、

AIから社内システムへ
接続できるようにする

ことではありません。

AIに
何を見せて
何を実行させ
何を禁止するか

まで設計することです。

そのため、

1．対象業務を決める
↓
2．必要な社内システムを洗い出す
↓
3．既存APIを確認
↓
4．MCP Toolsを設計
↓
5．読み取り専用でPoC
↓
6．ユーザー認証・権限を適用
↓
7．実業務で効果を測定
↓
8．必要なら更新系Toolを追加
↓
9．重要操作には人の承認を入れる

という順番で進める方法が現実的です。

「既存の社内APIをAIから利用できるようにしたい」

「CRMや業務システムをMCP対応したい」

「AIエージェントと社内データを安全につなぎたい」

「既存システムを活かして小規模なMCP PoCを試したい」

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

MCP・社内システム連携について相談する