SkillogyQiitaを読む
コラム一覧に戻る

MCPで何ができる?AIと社内システムをつなぐ仕組みと導入の注意点

生成AIを業務で使い始めると、多くの会社が同じ壁に当たります。ChatGPTやClaudeに質問すれば一般的な答えは返ってきますが、自社の顧客データ、在庫、案件の進捗、社内規程といった「自社の事情」はAIから見えません。結局、担当者が社内システムから情報をコピーして貼り付け、AIの回答をまた社内システムに転記する、という手作業が残ります。

MCP(Model Context Protocol)は、この「AIと社内システムの間の手作業」を減らすための共通規格です。AIアプリケーションと外部のデータ・ツールをつなぐ方式を標準化したもので、2024年11月にAnthropicがオープンソースとして公開し、2025年12月にはLinux Foundation傘下のAgentic AI Foundationに移管されました。現在はClaudeだけでなく、ChatGPT、Gemini、Microsoft Copilot、Visual Studio Codeなどの製品でも採用されています。

一方で、MCPは「つなげば何でも自動化できる魔法」ではありません。AIに社内システムの操作権限を渡すことになるため、権限設計や認証、誤操作への備えを考えずに導入すると、情報漏えいや意図しない更新につながります。また仕様の改定が速く、2026年7月の改定では通信の基本設計が大きく変わりました。

この記事では、MCPで何ができるのか、どういう仕組みで動くのか、社内システムにつなぐときにどこで判断が分かれるのかを、発注・導入を検討する立場から整理します。記事中の仕様情報は2026年10月時点の公式サイト(modelcontextprotocol.io)の内容に基づいており、今後変わる可能性があります。

参考:Introducing the Model Context Protocol/Anthropic

参考:Donating the Model Context Protocol and establishing the Agentic AI Foundation/Anthropic

MCPでできることの全体像

MCPでできることの全体像

MCPを一言で表すと、AIアプリと外部システムの間に置く「共通の差し込み口」です。従来、AIに社内データを読ませたり、外部サービスを操作させたりするには、AIアプリごと、接続先ごとに個別の連携を作る必要がありました。AIアプリが3種類、接続先が5種類あれば、組み合わせの数だけ連携を作り直すことになります。

MCPでは、接続先のシステム側に「MCPサーバー」を1つ用意すれば、MCPに対応したAIアプリであればどれからでも同じ方法で呼び出せます。USBのように規格をそろえることで、つなぐ側とつながれる側を独立して増やせるようにした、と考えると分かりやすいでしょう。

業務の場面に置き換えると、MCPでできることは大きく3つに分かれます。

  • 社内のデータを参照させる(顧客情報、商品マスタ、過去の問い合わせ履歴、社内文書など)
  • 社内システムを操作させる(チケットの起票、予定の登録、データの集計、レポートの作成など)
  • 決まった作業手順をAIに渡す(定型の分析手順、報告書のひな形、チェック項目など)

例えば営業担当者が「今月商談が止まっている案件を一覧にして、担当者ごとに次のアクションを提案して」とAIに頼んだとします。CRMにMCPでつながっていれば、AIがCRMから案件データを取得し、条件で絞り込み、提案文を作るところまでを一続きで処理できます。人がCSVを書き出して貼り付ける工程がなくなります。

ただし、MCP自体は「つなぎ方の規格」であり、AIの判断の質を上げるものではありません。どのデータを見せるか、どの操作を許すか、結果を誰が確認するかは、導入する側が設計する必要があります。

MCPはどういう仕組みで動くのか

MCPはどういう仕組みで動くのか

MCPの仕様では、登場する要素を3つの役割に分けています。発注や社内検討で話がかみ合わなくなるのは、この役割の区別があいまいなときが多いため、最初に押さえておくと便利です。

役割 何をするか 具体例
ホスト 利用者が操作するAIアプリ本体 Claudeのデスクトップアプリ、AI機能付きのエディタ、自社開発のAIチャット画面
クライアント ホストの中で、MCPサーバーとの接続を受け持つ部品 ホストに組み込まれており、利用者が直接触ることは少ない
サーバー 接続先のデータや機能をMCPの形式で提供する CRM用、ファイルサーバー用、社内データベース用などに個別に用意する

社内システムをAIにつなぎたい場合、自社で用意するのは基本的に「サーバー」の部分です。ホストとクライアントは、既製のAIアプリをそのまま使うか、自社のAIアプリに組み込みます。

サーバーが提供する3種類の機能

MCPサーバーがAIアプリに提供できる機能は、仕様上3種類に分かれています。

  • リソース(Resources)は、AIや利用者が参照するためのデータや文書を渡す機能です。
  • プロンプト(Prompts)は、定型の指示文や作業手順のひな形を渡す機能です。
  • ツール(Tools)は、AIが実行できる関数を渡す機能で、検索、登録、更新などの操作がここに当たります。

この中で最も影響が大きいのはツールです。仕様でも、ツールは任意のコード実行に当たるため慎重に扱うこと、ホストはツールを呼び出す前に利用者の明示的な同意を得ることが原則として示されています。参照だけのリソースと、データを書き換えるツールとでは、求められる安全対策の水準がまったく違います。

通信方式と2026年7月の仕様改定

標準の通信方式は2つです。1つは、利用者のPC上でサーバーを起動し、標準入出力でやり取りするstdio方式。もう1つは、ネットワーク越しにHTTPでやり取りするStreamable HTTP方式です。個人のPCで試す段階ではstdio、社内の複数人で共有するサーバーを立てる段階ではStreamable HTTPが中心になります。

2026年7月28日付の仕様改定では、接続ごとのセッションや初期化の手順が廃止され、リクエストごとに必要な情報を持たせる「ステートレス」な設計に変わりました。また、サーバーからAIモデルを呼び出すSampling、ファイルの範囲を伝えるRootsなどの機能は非推奨となり、長時間処理を扱うTasksは拡張機能として切り出されています。非推奨の機能には最低12か月の移行期間を設ける方針も示されました。

発注側にとって重要なのは、仕様の細部よりも「1年前の記事や実装例がそのまま通用するとは限らない」という点です。開発を依頼する際は、どの仕様バージョンを前提に作るのか、改定時に誰が追随するのかを最初に決めておく必要があります。

参考:Specification(2026-07-28)/Model Context Protocol

参考:Key Changes(2026-07-28)/Model Context Protocol

社内システムにつなぐと何が変わるか

社内システムにつなぐと何が変わるか

MCPが効果を出しやすいのは、「人がAIと社内システムの間で情報を運んでいる」業務です。逆に、AIに渡す情報が毎回ほぼ同じで量も少ない業務では、MCPを整備しても手間の削減幅は小さくなります。

業務のタイプ MCPの効果 理由
複数のシステムから情報を集めて判断材料を作る(案件状況の整理、問い合わせの一次調査など) 大きい 収集と転記の手間がそのまま消える
社内文書や過去事例を探して回答を作る 大きい 最新の情報を参照させやすい。ただし検索の精度設計は別途必要
AIの提案をもとにシステムへ登録・更新する 条件付きで大きい 誤登録の影響を抑える確認手順とセットで設計する必要がある
毎回同じ定型文を作るだけの作業 小さい MCPなしでもテンプレートで足りることが多い
判断に厳密な正確性が必要で、誤りが許されない処理(請求金額の確定など) 向かない AIの判断を挟まず、通常のシステム処理で自動化する方が確実

判断の目安として、「その作業で人が実際に時間を使っているのは、情報を集める部分か、判断する部分か」を確認してみてください。集める部分に時間がかかっているならMCPの効果は大きく、判断する部分に時間がかかっているなら、MCPよりも判断基準の整理やデータの整備が先です。

もう1つの見落としやすい点が、データの状態です。CRMの入力が担当者ごとにばらばらだったり、商品マスタに重複があったりすると、AIはその不揃いなデータをもとに答えを作ります。MCPでつなぐ前に、AIに見せるデータがどの程度そろっているかを確認しておくと、導入後に「答えが使えない」という事態を避けられます。

導入前に押さえる注意点

導入前に押さえる注意点

MCPの導入で問題になりやすいのは、技術的な接続よりも、権限と責任の設計です。公式サイトのセキュリティのベストプラクティスでも、権限の範囲や認証の扱いについて多くの注意点が挙げられています。発注側として最低限確認しておきたいのは次の5点です。

1. AIに渡す権限を業務単位で絞る

MCPサーバーが社内システムに対して管理者権限で接続していると、AIはその権限の範囲で何でもできてしまいます。公式のベストプラクティスでも、最初は参照など低リスクの操作に限った最小限の権限から始め、必要になった時点で段階的に権限を広げる考え方が推奨されています。最初は参照のみ、更新は対象のデータと操作を限定して追加する、という順番が安全です。

2. 利用者ごとの認証を前提にする

仕様上、認証の仕組み自体は任意とされていますが、HTTPで接続する場合はOAuth 2.1をベースにした認可の方式が定められています。社内の複数人で使うなら、「誰がAIを通じて何をしたか」が利用者単位で記録される構成にしておくべきです。共通のアカウント1つで接続すると、操作履歴から個人を特定できず、退職者の権限を外すこともできません。なお、別のサービス向けに発行されたトークンをそのまま受け取って下流のAPIに流す「トークンのパススルー」は、仕様で明確に禁止されています。

3. 更新系の操作には人の確認を挟む

AIは指示を取り違えることがあり、外部から取り込んだ文書に紛れ込んだ指示に反応してしまう可能性も指摘されています。データの削除、外部への送信、金額を伴う登録など、取り消しにくい操作は、AIが実行内容を提示して人が承認してから実行する設計にしておくと、誤操作の影響を抑えられます。

4. 第三者製のMCPサーバーの出どころを確認する

公開されているMCPサーバーは多数ありますが、PC上で動かすサーバーは利用者と同じ権限でプログラムを実行します。仕様のベストプラクティスでも、ローカルのサーバーが悪意あるコマンドを含んでいた場合のリスクが具体的に説明されています。提供元が明確か、更新が続いているか、どのデータにアクセスするかを確認し、社内で使ってよいサーバーを一覧で管理しておくと安心です。

5. 仕様改定への追随を誰が担うか決める

前述の通り、MCPの仕様は1年程度で設計の前提が変わるほどの改定が行われています。自社でMCPサーバーを開発する場合、保守契約の範囲に仕様改定への対応を含めるのか、都度見積もりにするのかを決めておかないと、利用しているAIアプリが新しい仕様に移行した時点で接続できなくなるおそれがあります。

参考:Authorization/Model Context Protocol

参考:Security Best Practices/Model Context Protocol

既製のMCPサーバーを使うか、自社で作るか

既製のMCPサーバーを使うか、自社で作るか

接続先がSaaSの場合、提供元が公式のMCPサーバーを用意していることがあります。一方、自社開発の業務システムや社内データベースに接続する場合は、MCPサーバーを自社で用意する必要があります。判断の目安は次の通りです。

状況 おすすめの選択 確認すること
接続先が主要なSaaSで、提供元の公式MCPサーバーがある 公式のサーバーを使う 権限の範囲を絞れるか、利用プランの条件、ログが残るか
接続先がSaaSだが公式のサーバーがなく、APIは公開されている APIの上に薄いMCPサーバーを自社で作る APIの利用制限、どの操作をツールとして公開するか
自社開発の業務システムや社内データベースにつなぐ 自社で作る データベースに直接つなぐか、既存のAPIを経由するか
まず効果を確かめたい段階 参照専用の小さなサーバーで試す 対象業務と効果の測り方を先に決める

自社で作る場合に気をつけたいのは、データベースをそのままAIに見せる設計にしないことです。AIが自由にSQLを組み立てられる構成は手軽に見えますが、重いクエリでシステムが止まったり、見せるべきでない列まで参照されたりします。「今月の未入金一覧を取得する」「顧客IDから対応履歴を取得する」のように、業務の単位でツールを切り出す方が、権限の管理もしやすく、AIの回答も安定します。

進め方としては、次の順番が現実的です。

  1. 手作業で情報を運んでいる業務を1つ選び、現状の所要時間を測る
  2. その業務に必要なデータだけを参照できるMCPサーバーを作り、少人数で試す
  3. 効果が確認できたら、更新系のツールを確認手順付きで追加する
  4. 利用者を広げる段階で、利用者ごとの認証、操作ログ、使ってよいサーバーの管理を整える

最初から全社のシステムをつなごうとすると、権限設計と検証に時間がかかり、効果が見える前に予算を使い切ってしまいがちです。対象業務を1つに絞り、参照から始めることで、MCPが自社に合うかどうかを小さな費用で判断できます。

まとめ

まとめ

MCPは、AIアプリと社内システムをつなぐ方法を標準化した規格です。接続先ごとにMCPサーバーを用意すれば、対応するAIアプリから共通の方法でデータを参照したり、システムを操作したりできるようになります。主要なAI製品が対応を進めており、業務でAIを使う際の前提になりつつあります。

効果が大きいのは、人がAIと社内システムの間で情報を集めて運んでいる業務です。反対に、判断基準が定まっていない業務や、厳密な正確性が必要な処理では、MCPを入れる前に業務やデータの整理が必要になります。

導入にあたっては、AIに渡す権限を業務単位で絞ること、利用者ごとの認証と操作ログを用意すること、取り消しにくい操作には人の確認を挟むこと、第三者製サーバーの出どころを確認すること、仕様改定への追随を誰が担うかを決めることが欠かせません。

明日から始めるなら、まず「社内システムからAIへ、AIから社内システムへ」と人が情報を運んでいる作業を洗い出し、そのうち参照だけで済むものを1つ選んでみてください。その業務の所要時間を測っておけば、MCPを試したときに効果を数字で判断できます。