MCP（Model Context Protocol）で社内システムとAIを連携する方法

なぜ今、社内システムとAIの「接続」が課題になっているのか

ChatGPTをはじめとする大規模言語モデル（LLM）の業務活用が進む中、多くのBtoB企業が共通の壁に直面しています。それは、AIが社内のデータやシステムを「知らない」という問題です。

LLM単体は、インターネット上の公開情報をもとに学習していますが、自社の基幹システム・CRM・社内ナレッジベースといった情報には、原則としてアクセスできません。そのため、「自社の商談履歴をもとに提案書を作成したい」「社内規程に沿った回答をAIに生成させたい」といった業務文脈に即したタスクでは、そのまま使っても期待した精度が出ないケースがほとんどです。

現場では、この問題を回避するために次のようなワークアラウンドが取られています。

• 社内ファイルをダウンロードし、AIツールに手動アップロードする
• 必要な情報をコピーして、プロンプトに貼り付ける
• 担当者が都度、情報を要約・整形してからAIに渡す

これらの方法は、少量・単発の作業であれば機能します。しかし業務量が増えると、情報収集と整形の工数がそのままAI活用のボトルネックになります。また、コピーミスや情報の鮮度の問題も避けられません。結果として、AIに投資しているにもかかわらず、生産性向上の効果が限定的にとどまるという状況が生まれています。

本質的な課題は、業務効率でも使い方でもなく、「AIと社内システムをどう設計として繋ぐか」という接続アーキテクチャの問題です。個別対応を積み重ねるのではなく、AIが社内システムを安全・確実に参照できる仕組みを設計することが、BtoB領域におけるAI活用の核心になりつつあります。

この接続設計の問題に対して、標準的なアプローチとして注目されているのがMCP（Model Context Protocol：モデルコンテキストプロトコル）です。MCPがどのような仕組みでこの課題を解決するのか、次のセクション以降で詳しく整理していきます。

MCP（Model Context Protocol）とは何か――AIとシステムを繋ぐ「共通規格」

MCP（Model Context Protocol）とは、AIが外部のツールやシステムを呼び出すための標準インターフェース規格です。2024年にAnthropic社が提唱し、オープンな仕様として公開されました。

一言で表すなら、「AIと社内システムをつなぐUSB-Cポート」に相当します。USB-Cが登場する以前は、機器ごとに異なるケーブルや規格が乱立していました。MCPはそれと同じ問題をAIの世界で解決しようとしている規格です。

MCPが登場する前の世界――ツールごとに個別実装が必要だった

従来、AIを社内システムと連携させるには、システムごとに専用のコードや接続設定を個別に開発する必要がありました。たとえば、AIに「社内の案件管理システムを参照させたい」「経費精算ツールのデータを読み込ませたい」と考えた場合、それぞれのシステムに合わせた個別のAPIラッパーやプラグインを一から実装しなければなりません。

接続先が増えるたびに開発コストが積み上がり、AIツールを切り替えた際には再実装が発生するケースも少なくありませんでした。この構造では、AIの活用範囲を広げるほど技術的な負債も増えていきます。

MCPが解決すること――AIと複数システムの接続を標準化する

MCPが提供するのは、AIと外部システムの間に共通の「接続口」を設けるという考え方です。MCPの仕様に沿って一度「MCPサーバー」を構築すれば、Claude・ChatGPTなどMCPに対応したAIツールであれば、追加の個別開発なしに接続できるようになります。

これはAPIやプラグインと何が違うのでしょうか。APIはシステム間でデータをやり取りする仕組みそのものですが、AIがAPIを使いこなすには「どのAPIをいつ、どう呼び出すか」を理解させる実装が別途必要です。MCPはその呼び出しのルール自体を標準化しており、AIが自律的に適切なツールを選択・実行できる設計になっています。

意思決定者にとって重要なのは、MCPが「特定のAIベンダーへの依存を減らしながら、社内システムとAIの連携を横断的に設計できる共通基盤」になり得るという点です。

MCPの基本構造――ホスト・クライアント・サーバーの関係を整理する

MCPは「ホスト」「クライアント」「サーバー」という3つの要素で構成されています。それぞれが明確な役割を持っており、誰がどの部分を担うかを把握しておくことが、導入検討の第一歩になります。

MCPホスト――AIが動くアプリケーション側の役割

MCPホストは、AIが実際に動作するアプリケーション層です。たとえば、社員が業務で使うAIチャットツールや、社内向けに構築した生成AIインターフェースがこれにあたります。ホストはユーザーからの問いかけを受け取り、必要な情報を取得するためにMCPクライアントへ処理を渡します。この部分はAIツールのベンダーやシステム開発会社が提供・構築するケースが一般的です。

MCPサーバー――社内システムをAIに公開する窓口

MCPサーバーは、在庫管理システムや顧客データベース、SaaSツールといった社内の既存システムに接続し、AIからの問い合わせに応答する窓口の役割を担います。たとえば、AIが「現在の在庫数を確認してほしい」という指示を受けた場合、MCPサーバーが在庫DBに対してクエリを実行し、結果を返します。MCPサーバーの構築は、社内システムのデータ構造やAPIを把握している担当者または開発パートナーが対応する必要があります。接続先のシステムごとに個別のMCPサーバーを用意するのが基本的な設計です。

MCPクライアント――ホストとサーバーを仲介する通信層

MCPクライアントは、ホストとサーバーの間でリクエストとレスポンスを受け渡す仲介層です。どのMCPサーバーに問い合わせるかの制御や、通信プロトコルの変換を担います。発注者側がこの層を直接意識する場面は少ないですが、複数の社内システムをAIに接続する場合、クライアント層の設計が全体の拡張性を左右します。

3つの要素をシナリオで整理すると、次のような流れになります。

1. 社員がAIチャット（MCPホスト）に「A商品の在庫を教えて」と入力する
2. ホストがMCPクライアントを通じて、在庫DB向けのMCPサーバーへリクエストを送る
3. MCPサーバーが在庫DBに問い合わせ、結果をクライアント経由でホストへ返す
4. AIが取得したデータをもとに回答を生成し、社員に提示する

この構造において、発注側が特に意識すべきはMCPサーバーの構築範囲です。接続したい社内システムの数だけMCPサーバーの設計・開発が必要になるため、どのシステムをAIに繋ぐかを事前に整理しておくことが、スコープと予算の見積もりに直結します。

社内システム別――MCPサーバーの接続パターンと実装イメージ

MCPの構造を理解したうえで、次に考えるべきは「自社のどのシステムに、どのようなMCPサーバーを用意するか」という実装イメージです。システムの種類によって、既製のMCPサーバーがそのまま使えるケースと、カスタム開発が必要になるケースに分かれます。この違いを把握しておくことが、導入計画を立てるうえでの出発点になります。

既製MCPサーバーが使えるSaaSの例――GitHub・Slack・Notionなど

GitHub、Slack、Notion、Google Drive、Confluenceといった主要SaaSについては、OSSコミュニティや公式が提供するMCPサーバーがすでに存在しています。これらは設定ファイルにAPIキーや接続先を記述するだけで動作するため、自社でゼロからコードを書く必要はほとんどありません。

たとえばGitHub向けのMCPサーバーを使えば、AIがリポジトリの内容を参照しながらコードレビューのコメントを生成したり、issueの一覧を要約したりといった操作が可能になります。Notionであればページの読み書きをAIが直接行えるようになり、社内ナレッジの検索・更新を自然言語で指示できます。

こうした既製サーバーを活用することで、MCP AI社内ツールとしての最初の一歩を低コストで踏み出せます。まずは業務で頻繁に参照されるSaaSから接続を試みるのが現実的なアプローチです。

カスタムMCPサーバーが必要になるケース――基幹システム・独自DBへの接続

一方、ERPや販売管理システム、独自構築の社内DBなど、汎用的なAPIを持たないシステムへの接続では、カスタムMCPサーバーの開発が必要になります。これらのシステムはベンダー固有のプロトコルやSQL接続、あるいは社内ネットワーク上にしか存在しないエンドポイントを通じて動作しているためです。

カスタム開発といっても、MCPサーバー自体の構造はシンプルです。「AIからのリクエストを受け取り、対象システムに問い合わせ、結果を返す」という処理を実装するものです。ただし、認証方式・アクセス権限・データの取り扱いルールをシステムごとに設計する必要があるため、MCPサーバー構築の難易度は対象システムの複雑さに比例します。

システム別・接続パターン早見表

以下に、代表的な社内システム類型ごとの接続パターンと、既製サーバーの有無をまとめています。自社の状況と照らし合わせながら、優先的に着手するシステムを検討する際の参考としてください。

MCP SaaS連携の文脈では既製サーバーの活用が先行しやすいですが、業務インパクトが大きいのは基幹システムや社内DBとの接続です。カスタム開発コストはかかるものの、AIが基幹データを直接参照できるようになると、意思決定支援や業務自動化の幅が大きく広がります。

MCPサーバーを構築・接続する際の設計ステップ

MCPサーバーの構築は、コードを書き始める前に意思決定すべき事項が多くあります。ここでは、発注側の担当者が把握しておくべき5つの設計ステップを整理します。各ステップでどのような問いを立てるべきかを中心に説明します。

Step1 ― 接続対象システムの棚卸しと優先順位付け

まず、社内に存在するシステムをリストアップし、AIと連携させる優先順位を決めます。対象の候補としては、基幹システム（ERP・会計）、CRM、社内ナレッジベース、SaaS（グループウェア・チャットツール）などが挙げられます。

このステップで問うべきことは、「どのシステムに繋げると業務上の効果が最も大きいか」「APIやデータ出力の口がすでに用意されているか」の2点です。連携の技術的な難易度と業務インパクトを掛け合わせて、スコープを絞ることが現実的な進め方です。

Step2 ― 認証方式とアクセス権限の設計

MCPサーバーが社内システムにアクセスする際、どのような認証方式を用いるかを決めます。選択肢はAPIキー認証、OAuth 2.0、サービスアカウントなど複数あり、接続先システムが対応している方式に依存します。

また、「誰がどのデータにアクセスできるか」というロールベースの権限設計も必要です。AIが社内全員のデータを参照できる状態は、情報管理の観点から避けるべきケースがほとんどです。

Step3 ― AIに公開するデータ・操作のスコープを絞る

MCPサーバーで「何を公開するか」を明示的に定義します。参照のみを許可するのか、データの書き込みや外部への送信も許可するのかによって、リスクの水準が大きく変わります。

「AIに読ませてよいデータ」と「AIに操作させてよい機能」をリスト化し、最小権限の原則に従って設計することが重要です。機能を絞ることで、後工程のセキュリティ検証も簡潔になります。

Step4 ― ローカル構成とクラウド構成の選択基準

MCPサーバーは、社内ネットワーク内に立てるローカル構成と、クラウド上に配置するクラウド構成の2パターンがあります。社内システムへのアクセスに厳しいネットワーク制限がある場合や、個人情報・機密情報を扱う場合はローカル構成が適しています。一方、複数拠点や外部パートナーとの連携が前提であればクラウド構成が現実的です。

「データをどこに置くか」という判断は、セキュリティポリシーと運用コストの両面から検討する必要があります。

Step5 ― 段階的な検証とパイロット運用の進め方

Model Context Protocol実装の初期段階では、対象システムを1〜2つに絞った小規模なパイロットから始めることが推奨されます。全システムを一度に接続しようとすると、問題発生時の原因特定が困難になります。

パイロット期間中に確認すべき観点は、AIの応答精度、レスポンスタイム、ログ・監査証跡の取得可否、エラー時の挙動の4点です。これらを検証したうえでMCPサーバー構築の手順を横展開することで、導入リスクを抑えながら対象範囲を広げていくことができます。

セキュリティ設計――社内データをAIに繋ぐ際に必ず検討すること

MCPによる社内システム連携を検討する際、セキュリティを「後から考えること」として後回しにしているケースが少なくありません。しかし、AIが社内データに直接アクセスできる構成では、従来のシステム連携とは異なる固有のリスクが生じます。ここでは意思決定者が見落としがちな論点を、設計原則とともに整理します。

AIに「見せるデータ」と「操作させる機能」を分けて設計する

MCPの設計で最初に問うべきは、「AIに何を許可するか」を明示的に定義できているか、という点です。多くの初期実装では、AIエージェントに対して必要以上に広い権限が付与されてしまいます。

整理の起点として、権限を次の2軸に分けて考えることが有効です。

• 読み取り専用のデータアクセス：顧客情報の参照、売上レポートの取得など、AIが情報を「見る」だけの操作
• 書き込み・実行を伴う操作：データの更新・削除、外部APIへの送信、ワークフローのトリガーなど、AIが「動かす」操作

RBAC（Role-Based Access Control：ロールベースアクセス制御）の考え方をMCPサーバーに適用し、AIエージェントが呼び出せるツールをロール単位で制限することが設計の基本です。さらに、書き込み・実行系のツール呼び出しについては、人間の承認ステップを挟む「ヒューマン・イン・ザ・ループ」の承認フローを設けることが推奨されます。AIが自律的に実行できる範囲を狭めることで、操作ミスや意図しないデータ変更のリスクを抑えられます。

外部LLM APIへのデータ送信リスクとオンプレLLMの選択肢

MCPはLLM（大規模言語モデル）とシステムを繋ぐ規格ですが、LLM自体をどこで動かすかは別の判断です。クラウド型のLLM API（OpenAIやAnthropicなど）を使う場合、MCPサーバーが取得した社内データがAPIリクエストに含まれて外部サーバーへ送信されます。

この点について、以下の観点で自社の許容度を確認しておく必要があります。

• 送信されるデータに個人情報・機密情報・秘密情報が含まれるか
• 利用するLLMプロバイダーのデータ利用規約・学習利用ポリシーの内容
• 業界規制（金融・医療・公共など）による外部送信の制約有無

機密性の高いデータを扱う場合は、オンプレミスまたは閉域ネットワーク内で動作するLLM（例：自社サーバー上にデプロイしたオープンソースモデル）との組み合わせが現実的な選択肢になります。性能と機密性のトレードオフを整理したうえで、データの種別ごとに「どのLLMに渡すか」を設計するアプローチが有効です。

ログ・監査設計――誰が何をAIに聞いたかを追跡できるか

社内システムにAIを接続したとき、「誰が・いつ・どのツールを・どのデータに対して呼び出したか」を記録する仕組みがなければ、インシデント発生時の原因追跡ができません。これは、従来のシステムアクセスログと同等の要件です。

MCPの構成では、少なくとも以下のログを取得・保持できる設計にすることが求められます。

• MCPクライアント（AIエージェント）からサーバーへのツール呼び出し履歴
• ツールに渡されたパラメータ（検索クエリ・対象レコードIDなど）
• 操作を実行したユーザーの識別情報
• 実行結果（成功・失敗・エラー内容）

ログの保存期間・アクセス制御・改ざん防止の仕組みも合わせて定義しておくことで、内部監査や規制対応にも耐えられる構成になります。セキュリティ設計は実装後に追加するのが困難な領域です。MCPサーバーの構築フェーズで、ログ・監査要件を仕様に含めることを強く推奨します。

MCPによる社内システム連携の活用シナリオ――導入効果が出やすい業務から始める

MCPの仕組みを理解したうえで次に問われるのは、「どの業務から手をつけると効果が出やすいか」という優先順位の判断です。全社一斉に展開するよりも、業務の性質に合ったユースケースから始める方が、短期間で成果を確認しやすくなります。

社内ナレッジ検索・問い合わせ対応への適用

最初に着手しやすいのは、社内の情報検索や問い合わせ対応の効率化です。規程・マニュアル・FAQ・過去の議事録といったドキュメントをナレッジベースとして整備し、MCPサーバー経由でAIが参照できる状態にすることで、従業員が自然な言葉で質問するだけで必要な情報を引き出せるようになります。

この構成が効果を出しやすい理由は、読み取り専用の操作が中心であるため、セキュリティリスクを抑えつつ比較的シンプルな設計で実装できる点にあります。情報システム部門や人事・総務への社内問い合わせ件数が多い企業ほど、対応工数の削減効果が可視化されやすいです。

CRM・SFA連携による営業支援の自動化

次に効果が出やすいのは、CRM（顧客関係管理）やSFA（営業支援システム）との連携による営業プロセスの自動化です。AIがMCP経由でSalesforceやHubSpotなどの案件情報・商談履歴・顧客属性にアクセスし、提案書のドラフト生成、次のアクション提案、報告書の自動作成などを担うことができます。

営業担当者が日々の入力や報告に費やしている時間は少なくないため、このユースケースはROIを試算しやすく、経営層への説明にも使いやすい点が特長です。読み取りだけでなくデータ更新も伴う場合は、操作権限の設計を事前に明確にしておく必要があります。

複数システムをまたぐ「マルチMCP」構成のイメージ

MCPの強みが最も発揮されるのは、AIエージェントが複数のMCPサーバーを横断して情報を取得・操作するマルチMCP構成です。たとえば、顧客からの問い合わせに対してAIが以下の流れで自律的に処理を進めるシナリオが考えられます。

1. CRMサーバーから顧客の契約情報と過去の問い合わせ履歴を取得する
2. ナレッジベースサーバーから関連するFAQや対応マニュアルを参照する
3. チケット管理システムのサーバーに対応内容を記録・起票する

この一連の処理は、従来であれば担当者が複数の画面を行き来しながら手動で行っていた作業です。マルチMCP構成によって、AIが文脈を保ちながら複数システムをまたいで情報を扱えるようになるため、業務自動化の範囲が大きく広がります。

ただし、接続するシステムが増えるほど設計の複雑性も高まります。まずは1〜2システムとのシングル構成で効果を確認し、段階的に連携範囲を広げていくアプローチが現実的です。

内製・ベンダー委託・SaaS活用――MCPサーバー構築の3つの選択肢

MCPサーバーの構築方法は、大きく3つのパターンに分かれます。①自社エンジニアによる内製、②外部ベンダーへの開発委託、③MCP対応SaaSやプラットフォームの活用です。それぞれにトレードオフがあるため、自社の体制・予算・スピード感に応じた選択が求められます。

3つの調達パターンを比較する――コスト・スピード・保守性

以下の表は、4つの観点から3パターンを整理したものです。

SaaSは導入の手軽さが際立ちますが、接続できるシステムや取得できるデータの範囲がプロバイダーの仕様に縛られます。一方、内製は自由度が高い反面、MCPの仕様変更への追従やセキュリティパッチの適用といった継続的なコストが発生します。

ベンダー委託時に確認すべき要件定義のポイント

MCP開発委託で失敗しやすいのは、「AIに何をさせたいか」ではなく「どのシステムのどのデータを、どの範囲で渡すか」の定義が曖昧なまま開発に入るケースです。発注前に最低限、以下を整理しておくことが重要です。

• 接続対象システムとAPIの有無：既存のREST APIやWebhookが使えるか、新規開発が必要か
• データの読み取り・書き込みの範囲：参照のみか、AIが操作（書き込み）まで行うか
• 認証・認可の設計方針：OAuth2やAPIキー管理をどこで担うか
• 納品物の定義：ソースコードの引き渡しと社内保守を想定するか、保守契約を継続するか

CLANEはMCPを活用した社内システム連携の実装支援を手がけており、要件定義の段階からシステム構成の整理に関与するケースが多くあります。発注側が上記の論点を事前に整理しておくことで、見積もりの精度も上がり、開発後の齟齬も起きにくくなります。

まとめ――MCPによる社内システム連携を進めるための判断軸

MCP（Model Context Protocol）による社内システム連携を検討する際、導入の成否は技術選定よりも事前の判断精度に左右されます。意思決定者が押さえておくべき4つの軸を整理します。

1. 自社のシステム構成を棚卸しする
   ERPやCRM、社内ポータルなど、現在稼働しているシステムとそのAPIの公開状況を一覧化します。REST APIやOAuthに対応しているかどうかが、MCPサーバーの構築難易度に直結します。
2. 最初に繋ぐ業務ドメインを特定する
   導入効果が出やすいのは、情報の検索・集約・起票など繰り返し頻度の高い定型業務です。全社一斉展開ではなく、特定の業務ドメインから始めることでリスクを抑えられます。
3. セキュリティ要件を事前に確認する
   社内データをAIに渡す経路には、認証・認可の設計と通信の暗号化が不可欠です。情報セキュリティポリシーやデータ分類の基準と照らし合わせ、接続可否の判断基準を先に定めておくことが重要です。
4. 構築主体を選定する
   内製・ベンダー委託・SaaS活用のいずれが適切かは、社内のエンジニアリソースと要件の複雑さによって異なります。スモールスタートであればSaaS型のMCP対応ツールの活用が現実的な選択肢になります。

これら4点を整理することで、MCPによる社内システム連携の導入検討を具体的なフェーズへ進めやすくなります。技術の理解と業務要件の整理を並行させながら、優先度の高い領域から着実に取り組むことが、導入効果を引き出す近道です。