MCPとは何か｜仕組みとメリット、自社のどの業務から試すか

AI推進を任され、自分でも情報を集めはじめると、どこを見ても「MCP」という三文字に出くわす。そんな方は多いのではないでしょうか。

解説記事を読むと「AIと外部システムをつなぐ規格らしい」までは理解できます。

ところが、自社で何にどう使うのか、最初の一歩は何かとなると、持ち帰れる記事は多くありません。

仕組みはわかったのに手が動かせない。いまこの段階で足踏みしている担当者が、増えていると感じます。

この記事では、MCPの仕組みと背景、似た概念との違い、つないだときに何が変わるのかを平易に押さえたうえで、部署ごとにあるシステムの業務ごとに「現場で何ができるのか」を具体的な使い方まで記載します。

なお具体例は、AIチャットツールのClaudeに統一して説明します（MCPは他のAIでも使える共通規格です）。

MCPとは何か｜AIと自社システムをつなぐ「標準仕様」

MCPとは｜AIと自社のデータをつなぐ共通の約束ごと

MCP（Model Context Protocol）とは何かを、まず一言でいうと、AIと、自社のデータや業務システムをつなぐときの「共通の約束ごと」です。

提唱したAnthropic社の公式ドキュメントは、次のように定義しています。

"MCP (Model Context Protocol) is an open-source standard for connecting AI applications to external systems."

日本語にすると「AIアプリケーションを外部システムに接続するための、オープンソースの標準規格」となります（出典: What is the Model Context Protocol — modelcontextprotocol.io）。

同じ公式ドキュメントは、これを「AIアプリケーションにとってのUSB-Cポートのようなもの」とも表現しています。
パソコンと周辺機器を、メーカーが違っても同じ形のケーブルでつなげるように、MCPはAIとさまざまなツールを同じやり方でつなぐ。そのようなイメージです。

念のためですが、MCPはAIの機能そのものではなく、つなぎ方の話です。
MCPに対応させたからAIが賢くなるわけではありません。変わるのは、AIが社内のどこまで手を伸ばせるか、その経路の作り方です。

MCPが解決する問題｜つなぎ込みが増えるほど破綻する構造

なぜこうした「共通の約束ごと」が必要になったのか。
背景には、AIと外部システムをつなぐ作業がもともと非常に面倒だった、という事情があります。

Claudeのような生成AIは、学習した知識と、その場で渡された文章だけをもとに答えています。
自社のカレンダーにも、顧客管理システムにも、社内のファイル置き場にもつながっていません。だから「来週の空き時間から打ち合わせ候補を出して」と頼んでも、予定を知らないAIは答えられない。
ここで、AIに社内の情報や業務ツールへ安全にアクセスさせる手立てが必要になったのです。

MCPが登場する前は、この「つなぎ込み」をつなぐ相手ごとに個別開発する必要がありました。
Anthropic社自身も、「新しいデータソースごとに、それぞれ専用の実装が必要になり、本当の意味でつながったシステムを広げていくのが難しかった」と説明しています（出典: Introducing the Model Context Protocol — Anthropic）。

この個別開発での作り方には、つなぐ先が増えるほど負担が跳ね上がるという弱点があります。
接続プログラムは「どのAIから、どのシステムへ」の組み合わせの数だけ必要になります。

3種類のAIから5つのシステムにつなぐなら15本、AIが1つ増えれば5本、システムが1つ増えれば3本が積み増しになる。
しかも作った後も、つなぎ先が仕様を変えるたびに、その本数を追いかけて直し続けることになります。

MCPという共通規格があれば、あるツール用の接続口を誰かが一度作ると、規格に対応したどのAIからも使い回せるようになります。
つなぎ込みを毎回ゼロから作るのではなく、一度作って共有する世界に変わったのです。

MCPの仕組み

MCPの世界は、おおまかに「3つの登場人物」と「3つのサーバーが差し出すもの」で説明できます。

3つの登場人物｜ホスト・クライアント・サーバー

まず、AIを動かしているアプリ本体をホストと呼びます。
Claudeのデスクトップアプリや、AIを組み込んだ業務システムがこれにあたります。いわば、外部とのやり取りを束ねる司令塔です。

次に、つなぎたいシステムの側に置く接続口をMCPサーバーと呼びます。
カレンダー用、会計ソフト用、顧客管理システム用といった具合に、つなぐ相手ごとに用意される窓口だと考えてください。多くは、サービスを提供している会社自身（Googleやfreeeなど）が公式に用意しています。

そして、ホストと一つひとつのサーバーをつなぐ専用回線がクライアントです。
司令塔であるホストは、つなぎたいサーバーの数だけクライアントを持ち、それぞれと一対一の回線を保ちます（出典: Architecture overview — modelcontextprotocol.io）。

たとえば「来週の空き時間を教えて」と利用者がClaudeに頼むと、ホストはカレンダー用のMCPサーバーに「この人の空き時間を教えて」と問い合わせます。
サーバーがカレンダーから予定を取ってきて返すと、Claudeはそれを読みやすい文章に整えて利用者に返す。
利用者からはAIと会話しているだけに見えますが、裏側ではこの受け渡しが起きています。

サーバーが差し出す3つのもの｜できること・見せられる情報・お決まりの頼み方

MCPサーバーがAIに提供できるものは、公式にはTools・Resources・Promptsという3種類に整理されています。それぞれ、業務の言葉に置き換えると次のようになります。

Tools(ツール) は、AIが実際に呼び出して動かせることです。
レコードを更新する、メールを送る、データベースに問い合わせる、といった具体的な操作にあたります。AIが「手を動かせる」のはこのおかげです。

Resources(リソース) は、AIが見せてもらえる情報です。
ファイルの中身、データベースのレコード、システムの応答などの参照データを指します。

Prompts(プロンプト) は、その業務でのお決まりの頼み方を型として用意したものです。
よく使う指示の手順をテンプレート化しておき、誰が使っても同じ品質で頼めるようにする仕組みです。

「サーバーという窓口が、できること・見せられる情報・お決まりの頼み方の3つをAIに差し出している」と理解できれば十分です。

MCPサーバーとは｜つなぎ先ごとに用意される部品と、主な対応サービス

MCPサーバーとは、そのシステムのデータや操作をMCPの形でAIに差し出すプログラムを指します。
つなぎたい相手ごとに1つ必要で、公式に用意されていれば設定だけで使えますし、用意されていなければ自社で作ることになります。

提供のされ方には2通りあります。
利用者のパソコンの中で動かすローカル型と、提供元のクラウド上で動いていて接続設定だけでつなぐリモート型です。

ローカル型は実行環境を自分で用意して動かし続ける必要がある一方、リモート型は指定されたURLを設定してログインするだけで始められます。
試す速さでいえば、リモート型のほうが速いです。

日常的に使われている業務サービスでは、公式提供が次のように進んでいます。

自社で最初に確認するのは、つなぎたいサービスが公式のMCPサーバーを出しているかどうかです。出ていれば、開発を伴わずに試せます。

MCPとAPI・A2Aの違い

MCPを調べていると、API・A2Aという言葉が出てきます。
どれも「AIと外のものをつなぐ」話なので混ざりやすいのですが、つなぐ相手と目的が違います。

MCPとAPIの違い｜設定でつなぐか、接続プログラムを作るか

APIとは、最も一般的なソフトウェア同士がやり取りするための接続方法です。
あるシステムが「この形式で問い合わせれば、この形式で答えを返します」と決めて、公開しているものを指します。

MCPとAPIは、どちらかを選ぶ関係ではありません。
MCPサーバーは、そのサービスのAPIをAIから使える形に包み直して作られます。

違いが出るのは、AIにつなぐまでの手順です。

つなぎたいサービスが公式のMCPサーバーを出しているなら、MCPのほうが早く始められます。出していなくてもAPIが公開されているなら、開発を挟んでAPI連携でつなげます。
そして、どちらも使えない基幹システムが相手なら、データを別の場所に集めてからAIに見せる方法を検討することになります。

どの手段を選ぶかを、つなぐシステムの数とMCP対応の有無から絞り込む手順は、AIと業務システムをつなぐ、自社に合う方法で詳しく整理しています。

MCPとA2Aの違い｜つなぐ相手がシステムか、AI同士か

A2A（Agent2Agent）とは、AIエージェント同士が互いを見つけて、仕事を頼み合うための規格です。

A2Aの公式ドキュメントは、2つの関係を正面から整理しています。
MCPは「AIが個々のツールやリソース、たとえばデータベースやAPIとどうやり取りするか」を定めるもの。
A2Aは「独立したAI同士が対等に協調する方法」を標準化するもので、両者は競合ではなく補い合う関係だとしています（出典: A2A and MCP — A2A Protocol）。

業務の場面に置き換えると、経費精算を担当するAIが会計SaaSにつないで仕訳を確認するのがMCP。
そのAIが承認を担当する別のAIに判断を依頼するのがA2Aです。

1つのAIが複数のシステムを使いこなす段階ではMCPだけで足り、部門ごとに立てたAI同士を連携させる段階になってA2Aの出番が来ます。

部門ごとにAIを立てている段階でなければ、先に手を付けるのはMCPの側です。
複数のAIを協調させる設計そのものについては、AIオーケストレーションとはで整理しています。

なぜ今これほど注目されるのか｜「個人利用」から「組織利用」への分岐点

MCPがここまで注目されているのは、AIの世界で名だたるプレイヤーがこの共通ルールに次々と相乗りしたからです。

主要サービスの対応が揃い、組織で使える前提が整った

公開からの動きは速いものでした。
Claudeだけでなく、ChatGPTもMCPに対応し（出典: modelcontextprotocol.io）、Googleも2025年12月に自社サービスをMCPに対応させたフルマネージドのサーバーを発表しています（出典: Announcing official MCP support for Google services — Google Cloud）。

同じ2025年12月には、AnthropicがMCPをLinux Foundation傘下の中立的な基金（Agentic AI Foundation）へ寄贈し、Anthropic・Block・OpenAIが共同で設立、Google・Microsoft・AWS・Cloudflareなども支援に名を連ねました。
この時点で、公開されているMCPサーバーは1万を超え、開発キット（PythonとTypeScript）の月間ダウンロードは9,700万回以上に達したと公表されています（出典: Donating the Model Context Protocol — Anthropic）。
特定企業の囲い込みではなく、業界全体の共通基盤として中立化が進んだことになります。

この波は日本国内のサービスにも届いています。
会計ソフトのfreeeは2026年3月に公式のMCPサーバー「freee-mcp」を公開し、サイボウズも業務アプリ基盤kintoneの公式MCPサーバーを提供しています（出典: freeeプレスリリース、kintone MCPサーバー — cybozu developer network）。
海外の話だと身構える必要はなく、日々使っている国内SaaSがAIからの接続口を持ち始めている、という現在地です。

個人のチャット利用から、組織の業務フローへ

ではなぜ、この流れが企業にとって重要なのか。MCPは、AI活用のスケールを「個人」から「組織」へ引き上げる接続規格だということです。

多くの企業のAI活用は、社員がClaudeやChatGPTに質問して下書きをもらう、という「個人のチャット利用」の段階にとどまっています。
便利ではあるものの、AIが社内のデータや業務システムを知らないため、できることは個人の手元の作業に閉じてしまいます。

MCPでAIを業務システムにつなぐと、顧客管理システムを読んで提案を組み立てる、会計データを照合する、問い合わせ履歴を参照して回答する、のように、個人の補助ツールだったAIが、組織の業務フローの中で手を動かす存在に変わります。

MCPでつなぐと何が変わるのか｜3つのメリット

では、業務システムにつなぐと具体的に何が変わるのか。

連携の作り込みが一度で済む

公式のMCPサーバーが提供されているサービスなら、自社が作るものはありません。
接続設定と権限を決めるだけで始められます。
つなぎ先が仕様を変えたときの追随も、サーバーを提供している会社の仕事です。

開発費を先に投じてから効果を確かめる、という順序にならずに済むのも、この形だからです。
試すかどうかの判断を、予算の判断とは別で進められます。

AIが最新の社内データを見て答えられる

つないでいないAIは、学習した時点の一般的な知識と、その場で貼り付けた文章しか持っていません。社内の最新の状況を答えさせるには、人が資料を探して、コピーして、貼り付ける作業が毎回必要でした。

MCPでつないだAIは、質問を受けるたびにつなぎ先のシステムへ問い合わせます。
いま登録されている状態を見て答えてくれます。

この違いは、コピーを貼り付ける手間よりも、AIが返す答えの正しさのほうに大きく表れます。
AIがシステムに繋がっていれば、たとえAIへの指示に情報がなくても、AIが自分で必要なデータを必要なところまで取りに行きます。

権限をゼロから作り込まずに済む

AIを社内システムにつなぐと決めた瞬間に出てくるのが、「ある社員が本来見られないデータを、AI経由で見られてしまわないか」という問いです。
ここを自前で設計するとなると、誰にどこまで見せるかの仕組みを作り直すことになります。

公式提供されているMCPサーバーには、つなぎ先のシステムがもともと持っている権限をそのまま引き継ぐものがあります。
Salesforceは自社のMCPサーバーについて、既存の権限設定がそのまま適用され、すべての処理が認証したユーザーとして実行されるため、新しいセキュリティモデルを覚える必要はないと説明しています（出典: Salesforce Hosted MCP Servers Are Now Generally Available）。

営業担当者がAIに聞いても、その担当者が見られる範囲しか返らない。
すでに何年もかけて整えてきた社内の権限設計を、AIのために作り直さずに使える、ということです。

MCPで各現場の何ができるようになるか

MCPを「自分ごと」にするには、抽象的な仕組みの話ではなく、自部門で具体的に何ができるのかが見えている必要があります。 営業・カスタマーサポート・経理・人事・情報システムの5つの領域について、Claudeに何をつないで、どう頼むと、何が返ってくるかという具体のイメージまで踏み込みます。

営業｜顧客管理システムにつないで、商談記録とフォローを一度に

営業でAIがつなぐ相手は、顧客管理システム(CRM)・メール・カレンダーです。 たとえば、顧客管理システムとメール、カレンダーをClaudeにつないだうえで、こう頼みます。

「A社との前回商談の要点を顧客管理システムから出して、私のカレンダーから次回アポの候補を3つ挙げて、フォローメールの下書きまで作って」

するとClaudeは、裏側で顧客管理用のMCPサーバーに過去の商談履歴を問い合わせ、カレンダー用のサーバーで空き枠を調べ、それらをまとめてフォローメールの下書きまで一度に組み立てて返してきます。

これまで「CRMを開いて履歴を読む、カレンダーで空きを探す、メールを書いて日程を書き写す」と人が行き来していた一連の作業が、ひとつの依頼で下書きまで進む、というイメージです。

つなぐ先としては、営業支援ツール側の対応も進んでいます。たとえばSalesforceは、AI機能「Agentforce」をMCPに対応させています（出典: AgentforceがMCPに対応 — セールスフォース・ジャパン）。
「自社は大掛かりな基盤を入れていない」という場合でも入口はあり、国内のスタートアップhomulaは、GmailやSlack、Salesforce、HubSpotなどを数ステップでAIにつなげるMCPプラットフォーム「Agens MCP Hub」を2025年10月に公開しています（出典: homulaプレスリリース — PR TIMES）。

自前で接続口を開発しなくても、設定でつないで小さく試す道が用意されている、ということです。

カスタマーサポート｜問い合わせとFAQにつないで、回答の下ごしらえを任せる

カスタマーサポートでAIがつなぐ相手は、問い合わせ管理(チケット)システム・FAQやナレッジ・顧客管理システムです。 これらをClaudeにつないだうえで、こう頼みます。

「この問い合わせメールを内容で分類して、過去の似た対応とFAQから根拠を拾い、回答ドラフトを作って」

Claudeはチケット用のサーバーで過去の似た対応を探し、FAQを参照し、顧客の契約状況を確認したうえで、根拠つきの回答案を返してきます。
一次対応の下ごしらえをAIが担い、担当者は内容の確認と、判断が要る難しい案件への集中に回れます。

ベテランしか知らなかった過去事例や規程を、AIが毎回横断的に拾ってくるため、誰が一次対応しても抜け漏れが減っていきます。少人数のサポート体制ほど、この恩恵は大きいはずです。

経理｜会計SaaSにつないで、突合と集計の手作業を減らす

経理でAIがつなぐ相手は、会計SaaS・経費精算・スプレッドシートです。
ここは国内SaaSの動きが具体的で、再現性が高い領域です。会計ソフトのfreeeは公式のMCPサーバー「freee-mcp」をOSSとして公開し、会計・人事労務・請求書・販売などの機能をAIから操作できるようにしています。
2026年4月時点で電子契約のfreeeサインまで対応し、約330本のAPIがAIから扱える形になったと公表されています（出典: freeeプレスリリース）。

これをClaudeにつなぐと、こう頼めるようになります。

「今月の未入金の請求書を一覧にして、金額の大きい順に並べて」

Claudeはfreee-mcp経由で会計データに問い合わせ、条件に合う請求書を一覧にして返してきます。
数字を一件ずつ画面で追っていた作業をAIに前処理させ、人は最終的な判断とチェックに集中する。 ただし経理は数字の正確さが命の領域ですから、AIの出力をそのまま確定させず、人が必ず確認する運用を前提に置くことが欠かせません。

人事｜勤怠や社内規程につないで、申請対応と問い合わせを軽くする

人事でAIがつなぐ相手は、勤怠・申請システム・社内規程やマニュアルです。
業務アプリ基盤のkintoneは、サイボウズが公式のMCPサーバーを提供しており、レコードの作成・更新・参照やアプリ設定の操作に対応しています（出典: kintone MCPサーバー — cybozu developer network）。
人事系の申請や台帳をkintoneで管理している企業なら、Claudeにつないでこう頼める素地があります。

「この申請の状況を確認して。あわせて、育児休業の申請手順を社内規程から要約して」

Claudeはkintone用のサーバーで該当レコードを参照し、社内規程をつないでおけば、散らばった文書を横断して該当箇所を示し要点を返します。
担当者が同じ説明を何度も繰り返す状況が減り、制度設計や面談のような、人にしかできない仕事に時間を寄せられます。

情報システム・総務｜文書管理システムにつないで、社内文書を探す時間を減らす

情報システムや総務でAIがつなぐ相手は、文書管理システムと、そこに保管されている契約書・申請書・手順書です。

文書管理サービスのBoxは、公式のリモートMCPサーバーを提供しています。
管理コンソールの統合画面から有効にして使う形で、AIから呼び出せるものには、キーワードでのファイル検索、ファイルの中身の取得、ファイルからの項目の抜き出しなどが含まれます（出典: 利用可能なツール — Box Dev Docs）。

これをClaudeにつなぐと、こう頼めるようになります。

「取引先との契約書のうち、今期中に更新期限が来るものを探して、期限と担当部署を一覧にして」

Claudeは検索ツールで該当しそうなファイルを絞り込み、中身を読んで期限と担当部署を抜き出し、一覧にして返してきます。
どのフォルダに入っているか分からない文書を人が探し回っていた作業が、ひとつの依頼で候補の一覧まで進む、ということです。

情報システムや総務は、他部門の「あの資料はどこですか」を引き受ける側でもあります。
文書の置き場をAIにつないでおくと、聞かれてから探す時間そのものが減っていきます。

5つの領域を一覧にすると、共通の構図が見えてきます。

どの領域も、共通しているのは「決まった手順で、毎日のように触っているデータをまたぐ作業」を任せられる、という点です。
次の章では、ここを判断軸として言語化します。

自社のどの業務から試すか｜優先順位を引く判断軸

業務ごとの具体像が見えてきたところで、最後の問いに進みます。「では、自社はどこから手を付けるべきか」。
すべてを同時に始める必要はなく、むしろ一点に絞って小さく試すほうが現実的です。

候補を比べる3つの軸｜連携の頻度・業務の定型度・効果の測りやすさ

ここでは、候補の業務を比べるための3つの判断軸を用意しました。

一つ目はデータ連携の頻度です。
AIが外部システムにつながって効果を体感しやすいのは、まさに「何度も同じ場所を見に行く」作業です。月に一度しか触らないデータより、毎日参照する顧客情報や会計データのほうが、つないだときの見返りが大きくなります。

二つ目は業務の定型度です。
手順がある程度決まっていて、人によって判断が大きく分かれない作業ほど、AIに任せやすく、品質も安定します。逆に、毎回ゼロから考える非定型の仕事は、最初の一歩には向きません。

三つ目は効果測定のしやすさです。
試した結果を、対応時間・処理件数・差し戻しの回数といった数字で測れる業務を選ぶと、「効果があったのか」を経営層に説明しやすくなります。限られた予算で次の投資判断を仰ぐ立場なら、この測りやすさは最初の業務選びで特に重視したい軸です。

この3つを、候補の業務に当ててみるためのチェックリストにまとめます。多く当てはまる業務ほど、最初の一歩に向いています。

□ その業務で、毎日のように同じデータやツールを触っている
□ 手順がある程度決まっていて、判断が人によって大きく分かれない
□ 試した効果を、時間・件数・回数などの数字で測れる
□ 扱うデータの機微度が低く、外部接続を試しやすい

加えて最初の一歩としておすすめしたいのは、機微度の低い業務から始めることです。
公開資料の整理や社内FAQの検索のように、仮に不具合があっても影響が小さい範囲で1つか2つの連携を試し、運用の手応えと効果を確かめてから広げる。MCPの利点は、「試してみて、合わなければ外す」が設定の範囲で完結することにあります。
重い意思決定を一度で下すのではなく、まずは小さく試して測る進め方をするのがおすすめです。

最初の1業務を決めてから広げる

対象の業務が決まったら、次の順で進めると手戻りが少なくなります。

1. つなぎ先に公式のMCPサーバーがあるかを確認する。
   あれば接続設定だけで始められます。無ければ、同じ業務の中で対応済みの別のシステムに変えるか、API連携での開発を見積もることになります。

2. 参照だけを許す権限でつなぐ。
   レコードの更新やメールの送信といった書き込みは、参照で手応えを確かめてから足していきます。

3. その業務でいちばん頻度の高い依頼を1つ決めて、実際に投げてみる。
   あれもこれもと欲張らず、毎日発生している作業を1つ選びます。

4. つなぐ前と後を、決めておいた数字で比べる。
   対応時間・処理件数・差し戻しの回数のうち、その業務で取りやすいものを1つ選べば十分です。

5. 同じ部署の隣の業務へ広げる。
   部署をまたぐのは、1つ目で運用のルールが固まってからにします。

社内の合意を取る順序としても、この形が通しやすくなります。
数字が1つ出てから2つ目の連携を提案するほうが、まとめて予算を求めるより説明しやすくなります。

試す前に押さえるリスク｜「つなぐ」前提だからこそのガバナンス

これまでの記事でお伝えした通り、MCPはAIを社内システムにつなぐ仕組みです。
だからこそ、つなぐ前に知っておくべきリスクがあります。
便利さの裏側を正しく理解しておくことは、活用を止めるためではなく、安全に広げるための前提です。

MCPサーバーの出自と、報告されている脆弱性

2025年9月、メール配信サービスPostmarkの名前を騙った「postmark-mcp」が出回り、送信されるメールを外部のサーバーにひそかにBCCで送る仕掛けが仕込まれていた事件がありました。

Postmark社は、これが自社の開発でも許可したものでもないと注意喚起を出しています。
作成者は15回のバージョン更新で信用を積み上げたうえで、バージョン1.0.16でこの仕掛けを追加していました（出典: Security Alert: Malicious 'postmark-mcp' Package — Postmark）。

MCPサーバーは、公式が出すものもあれば、第三者が作って公開するものもあります。
出どころの確かでない接続口を安易につなぐと、こうした「正規ツールを装った偽物」をつかまされる危険がある、ということです。

技術的にも、似た性質のリスクが指摘されています。
一つはツールポイズニングと呼ばれるもので、サーバーがAIに渡す「このツールはこう使う」という説明文の中に、人の目には見えにくい形で悪意のある指示を埋め込む手口です。
AIはそれを正規の指示として読んでしまう恐れがあります（出典: MCP脅威モデリング — arXiv（査読前のプレプリント））。

いずれもすでに対策が示されているものですが、「つなぐ相手を選ぶ」ことの重要性を物語っています。

大切なのは、担当者個人の判断で社内データを勝手につなぐ「シャドーAI」を避け、組織のルールの上で試すことだと考えています。

まとめ｜まずは、自社のひとつの業務でつないでみる

MCP（Model Context Protocol）は、AIと自社のデータ・業務システムをつなぐときの「共通の約束ごと」、つまり接続規格です。
AI向けのUSB-Cのように、対応したツールであれば同じやり方でつなげます。
その本質は、AI活用のスケールを個人のチャット利用から組織の業務へ引き上げる点にあります。

似た概念との違いは、つなぐ相手で分けられます。
APIは接続プログラムを自社で作る方法、A2AはAI同士が仕事を頼み合う規格です。
MCPが担うのは、AIと業務システムを設定でつなぐところです。

つないだときに変わるのは、連携の作り込みが一度で済むこと、AIが最新の社内データを見て答えられること、そして社内で整えてきた権限をそのまま使えることの3点です。

営業・カスタマーサポート・経理・人事・情報システムのいずれでも、毎日のように同じデータを触る定型業務ほど、つないだときにできることが見えやすくなります。
だからこそ、データ連携の頻度・業務の定型度・効果測定のしやすさという3つの軸で候補を比べ、機微度の低い業務から1つか2つ、小さく試すのが現実的な第一歩です。
試す前には、つなぐ相手の信頼性と権限の最小化を、組織のルールとして決めておく。

そして何より、MCPは読んで終わりにするより、触ってみるほうが早く腹落ちします。
Claudeに身近なツールをひとつつないで、業務別の章で挙げたような頼み方を自分の業務に合わせて実際に投げてみる。
その小さな一歩が、AI活用を組織のスケールへ広げる入口になるはずです。