MCP活用事例｜freee・HubSpot・NotionをAIでつなぐ連携設計

2026年3月7日
最終更新: 2026年10月12日

この記事の結論

MCPは、AIエージェントが業務ツールのデータや機能を利用するための接続方法です。導入を考えるときは、つなぐツールの数よりも、横断して答えたい問いと、その答えを誰が確認するかを先に決めます。

ブログ目次

売上はfreee、商談はHubSpot、議事録はNotionにある。これらを照らし合わせるたびに画面を開き直しているなら、MCPを使った横断的な参照を検討できます。ただし、接続しただけで取引先や金額が正しく対応づくわけではありません。

MCP（Model Context Protocol）は、AIを利用するアプリケーションと外部のデータソース・ツールを接続するためのプロトコルです。本記事では、freee・HubSpot・Notionを中心に、SlackとGoogle Calendarも含めた活用場面を示し、接続前のデータ整理から権限設定、回答の確認、書き込みを許可する判断までを順に扱います。

この記事でわかること

MCPで複数の業務ツールを扱いたい方に向けて、仕組みだけでなく、最初の対象業務を選ぶ方法と運用を広げる条件を整理します。AIエージェント導入の全体像は「AIエージェントで業務自動化」で解説しています。

MCPの仕組みと従来の連携手段との違い — ホスト・クライアント・サーバーの役割を押さえ、固定した処理と、その都度調べる作業のどちらに使うかを判断できます。
freee・HubSpot・Notion・Slack・Google Calendarの活用パターン — 各ツールに何を問い合わせるか、横断する際にどのデータを照合するかを確認できます。
AIに任せる範囲と人が判断する範囲 — 読み取りから始め、投稿・招待・レコード更新・仕訳登録の前に確認する内容を決められます。
段階的な導入手順と現時点の制約 — 対象業務の選定、接続確認、回答の検証、チーム展開を進める条件がわかります。

MCPとは何か ── AIエージェントとツールの接続口を標準化するプロトコル

最初に、MCPを構成する要素と、ほかの連携方法との使い分けを確認します。業務を選ぶ際は「毎回同じ処理を実行したいのか」「複数の情報源を調べて判断材料を集めたいのか」を分けると、接続方法を選びやすくなります。

ツールごとの個別連携から、共通規格での接続へ

MCPは、AIを利用するアプリケーションと外部ツールの間で、利用できる機能やデータを扱うための共通規格です。AI活用の全体像はAI活用完全ガイドで把握できます。

個別のAPI連携では、取得する項目や実行する処理をツールごとに実装します。仕様や業務要件が変わったときに誰が修正できるか、接続先と処理内容をどこに記録するかも設計事項です。担当者以外が構成を追えない場合は、設定と運用手順を文書化する必要があります。連携を外部に委託するか社内で持つかの判断軸は「AI vs 業務委託」で整理しています。

MCPを使う場合も、接続先が提供する機能、認証方法、保守担当の確認は必要です。共通規格は接続方法を整理する助けになりますが、会計とCRMで取引をどう対応させるかまでは決めません。技術仕様や基本的な仕組みは「MCPとは？Model Context Protocolの仕組みと活用法を徹底解説」で解説しており、ここでは業務への当てはめ方に絞ります。

ホスト・クライアント・サーバーの3要素

MCPを使った接続では、AIを利用するアプリケーション、接続を管理する部分、外部ツールの機能を提供する部分を分けて考えます（出典：Model Context Protocol公式ドキュメント「Introduction」）。

要素	役割	具体例
MCPホスト	AIモデルを動かすアプリケーション	Claude Desktop、Claude Code、Cursor
MCPクライアント	ホスト内でMCPサーバーとの接続を管理する。各サーバーと1対1の接続を保つ	ホストに組み込まれたコンポーネント
MCPサーバー	外部ツールやデータソースとの接続を担うプログラム	freee用、HubSpot用、Notion用など

業務で確認すべきなのは、接続先の名前だけではありません。必要なデータを読めるか、書き込み機能が含まれるか、利用者ごとに権限を分けられるかを、採用するサーバーごとに確かめます。複数のエージェントに役割を分ける場合は、マルチエージェントAIの設計手法も参考になります。

従来のAPI連携・ノーコード自動化との使い分け

処理の目的を先に定めると、方式を選びやすくなります。

方式	動き方	向く業務	向かない業務
API個別連携	決めた処理をコードで実装する	毎回同じ形で大量に流れるデータ同期	要件が頻繁に変わる分析や調査
ノーコード自動化（Zapierなど）	「Aが起きたらBを実行する」固定ルール	条件と処理が明確な定型通知・転記	状況に応じて参照先を変える判断
MCP経由のAIエージェント	自然言語の指示から、AIが参照先と操作を選ぶ	複数ツールを横断する調査・集計・下書き	1件も漏れが許されない基幹データの同期

同じ条件で同じ結果を登録し続ける処理なら、実行条件と結果を固定できる方法を選びます。調べる相手や参照先が依頼ごとに変わるなら、MCP経由で情報を集め、根拠となったレコードを人が確かめる方法が候補になります。RPAとの比較は「AIとRPAの違い・使い分け」で詳しく解説しています。

なぜ会計・CRM・ナレッジの分断が問題になるのか

接続方法を決める前に、現在どこで情報を照らし合わせているかを確認します。会計・CRM・議事録を別々に管理すること自体が問題なのではありません。同じ取引先や案件の情報を比較するときに、対応関係や取得時点が曖昧になることが課題です。

スプレッドシートで突き合わせる運用の限界

freeeの会計情報、HubSpotの商談情報、Notionの議事録をスプレッドシートにまとめている場合は、まず「どの情報を、何の判断に使うか」を書き出します。売上実績と進行中の商談を並べて見たいのか、特定顧客の決定事項を探したいのかによって、必要な接続先は変わります。

次に、取得時点と照合キーを確認します。取引先名だけでは対応づけが曖昧なら、担当者が照合できる識別子や確認手順を決めます。MCPで取得する回答にも参照元と対象期間を示し、人が元データに戻れる形にすると、報告前の確認ができます。

コンタクトから請求までの流れのどこでデータが切れるか

顧客とのやり取りを、コンタクト、取引、顧客対応、請求の順に見て、どの段階で別のツールを開いているかを探します。次の問いは、横断参照の対象を決める出発点になります。

段階	主なツール	データが切れやすい点	MCPで横断したい問い
コンタクト	HubSpot、Slack	問い合わせの共有がチャットだけに残る	「今週の問い合わせと、社内でのやり取りをまとめて」
取引	HubSpot、Google Calendar、Notion	商談の議事録がCRMに紐づかない	「この商談の過去の議事録と次回予定を出して」
顧客	HubSpot、Notion	契約後の対応履歴がナレッジ側に散らばる	「この顧客の導入時の決定事項を教えて」
請求	freee、HubSpot	入金状況が営業側から見えない	「受注済みで未入金の取引はどれか」

表の問いから、自社で実際に確認しているものを選びます。対応するレコードを人が特定できない問いは、接続を増やす前にデータの紐づけ方を見直します。

MCPをつなぐ前にCRM側で決めておくこと

回答を確認できる状態にするため、取引ステージの進行条件、AIに参照させるプロパティ、会計側とCRM側の取引を照合する方法を決めます。担当者によってステージの意味が違う場合は、その定義を先に揃えます。

参照項目は、問いに必要なものから選びます。会計とCRMで取引が一意に対応しない場合は、AIに推測で結びつけさせず、照合できなかったものを別に示すよう依頼します。この状態で回答を検証できてから、次の情報源を加えます。

freee・HubSpot・Notion連携の活用事例

ここでは、会計・CRM・ナレッジの情報をそれぞれどう使うかを見ます。各例を試す際は、接続先が必要な機能を提供しているか確認し、質問への回答と元データを突き合わせてから業務に組み込みます。

freee MCPサーバーで会計データを自然言語で引き出す

freeeの会計情報を参照できる接続を用意する場合、最初は集計結果を登録や送信に使わず、経理担当者が元データと比較する用途から始めます。質問には対象期間、取引の範囲、集計の単位を含めます。

月次売上の確認: 対象月と集計対象を指定して売上を確認し、回答が参照したデータの範囲を確かめます。
勘定科目別の分析: 比較したい科目と期間を指定し、科目の扱いが揃っているかを確認します。
取引先別の集計: 対象の取引先を明示し、同名・名称変更のある取引をどう扱ったかを確認します。
仕訳の作成補助: 取引内容から下書きを作る場合も、勘定科目や金額を経理担当者が確認してから登録します。

利用するMCPサーバーの認証方法と提供機能は、採用する実装で確認します。読み取りで目的を満たせる間は、登録に使う権限を加える必要はありません。

freee会計で確認した決済状況をHubSpot側にも決まった形で反映したい場合は、定型の同期方法を検討します。StartLinkのSync for freeeについては、対象データと利用条件を確認してください。HubSpotマーケットプレイスからインストールする前にも、照合したい取引が対象になるかを確かめます。

HubSpot MCPサーバーで商談・マーケティングデータを読む

HubSpotのデータを参照する場合は、「今月クローズ予定の商談」「提案中の取引」など、検索条件を先に決めます。回答には対象の取引と使った条件を示し、保存済みビューや元レコードと比較できるようにします。マーケティングデータを尋ねる場合も、期間と対象を揃えてから数を比べます。

HubSpotの画面内で行う操作は、HubSpotのAI機能であるBreezeも選択肢になります。次の画像は、関連する取引を更新した画面です。

Breezeが関連取引4件を一括で「お見送り」更新した結果

HubSpot内で完結する依頼なら、まず既存の画面や機能で必要な確認ができるかを見ます。会計や議事録の情報と合わせて調べたい問いがある場合に、MCPでの横断参照を検討します。

Notion MCPサーバーで議事録と社内ドキュメントを参照する

Notionの議事録や社内ドキュメントを参照できる接続では、回答の要約だけでなく、どのページのどの記述を使ったか確認できることが大切です。

過去の議事録検索: 会議名や議題を指定して探し、回答で挙げた決定事項を該当ページで確かめます。
プロジェクト進捗の把握: 対象のデータベースと進捗の定義を決め、更新されていない項目を区別します。
ドキュメント作成: テンプレートを参照して下書きを作り、公開先と内容を担当者が確認します。

議事録で「決定事項」と「検討中の事項」が混在している場合、要約だけで両者を判別するのは困難です。記録する欄を分け、担当者と次のアクションを明示します。検索結果で区別できないものが残る間は、重要な決定を回答だけで確定しない運用にします。

営業担当者がCRMの画面からナレッジを確認する場面もあります。以下は、その画面例です。

HubSpotのレコード上でNotionのページを閲覧できるCRMカード。 — CRMのレコードからNotionのページを開いた状態。ナレッジ側に移動せず、同じ画面で参照できます。

HubSpotの画面からNotionの情報を扱いたい場合は、StartLink開発のSync for Notionも選択肢です。必要な操作と利用条件を確認し、MCPでの参照と画面上での操作のどちらが業務に合うかを決めます。次の画像は、HubSpotワークフローのアクション設定画面です。

引用：Sync for Notion｜ワークフローアクションでNotionページを自動作成

Slack・Google Calendar連携で「伝える」「予定を組む」までつなぐ

情報の参照から投稿や予定作成に進むと、本人以外にも影響します。この節では、Slackでの共有とGoogle Calendarでの調整を例に、下書きや候補の提示で止める場面と、人が実行を確認する場面を分けます。

Slack MCPサーバーで社内コミュニケーションをAIに接続する

Slackの情報を参照できる接続なら、対象チャンネルと期間を指定して、会議後や不在中のやり取りを要約する使い方が考えられます。要約から元の投稿をたどれるようにし、決定事項と提案を区別して確認します。

定型報告を作る場合は、最初に下書きとして表示し、数値の参照元と投稿先を人が見ます。内容が確認できても、チームへの投稿を許可するかは別の判断です。投稿後に誤りが見つかった場合の訂正担当も決めてから、実行範囲を広げます。

Google Calendar MCPサーバーでスケジュールを扱う

予定を扱う接続では、空き枠の参照と招待を伴う予定作成を分けて考えます。

空き時間の検索: 対象者、日付、所要時間を指定し、返された候補を本人が確認します。
会議の作成: 件名、参加者、日時を確認してから、招待を送るか判断します。
1日の予定確認: 参照したカレンダーと日付を確かめ、必要な予定が含まれているか確認します。

顧客を招待する会議は、候補日と参加者を担当者が確認してから送信します。社内会議でも、代理で招待を送る権限と訂正方法が決まっていなければ、候補の提示で止めます。

実践的なMCP統合パターン3選

横断して扱う業務を選ぶ際は、接続できるツールの数ではなく、現場で繰り返している確認作業から始めます。次の表は、何を調べたいかによって接続先を組み合わせる設計例です。

パターン	接続するツール	解消したい手作業	主な利用者
経営ダッシュボードの自然言語化	freee＋HubSpot＋Google Calendar	売上実績とパイプラインの突き合わせ	経営者・事業責任者
営業プロセスの自動化	HubSpot＋Slack＋Google Calendar	商談後の更新漏れ、週次報告の作成	営業マネージャー・営業担当
バックオフィスの統合	freee＋Notion＋Slack	経費精算の入力、月次レポートの作成	経理・管理部門

パターン1: 経営ダッシュボードを自然言語化する

売上実績と商談パイプラインを一緒に確認したい場合は、まず両者の対象期間と集計単位を揃えます。問いが固定しているなら、毎回同じ定義で確認できるダッシュボードを使います。会議中に生じた追加の問いを調べたいなら、MCPで元データを参照し、差の理由を確認する使い方が考えられます。経営データの可視化でも、何を比較して判断するかが設計の出発点になります。

予定情報を合わせる場合も、売上の見通しを予定の有無だけで判断しません。レビュー会議の候補日を探すなど、予定として確認したい目的を明示します。数字が一致しないときは、AIの説明を採用する前に集計条件と対象レコードへ戻ります。

パターン2: 営業プロセスを自動化する

営業では、商談後の記録、次のアクション、週次の共有をつなぐ設計が考えられます。ただし、予定が終了したことだけを根拠に取引ステージを変更しないよう、承認する人と確認材料を決めます。

商談後のフォローアップ: 予定とCRMの情報から更新案を作り、担当者が商談結果を確認してから反映します。
週次営業レポートの作成: 対象期間と集計条件を固定して下書きを作り、元の取引を確認してから共有します。
見込み客のスコアリング連動: 既存のスコア条件に該当する対象を確認し、担当者への連絡や候補日の提示につなげます。

まず更新案と報告の下書きが業務の記録と一致するかを確認します。食い違いがあれば、依頼文だけでなく、ステージの定義やCRMの入力方法も見直します。一致する範囲が明確になってから、実行できる操作を検討します。

パターン3: バックオフィス業務をまとめる

freeeの会計情報、Notionの手順や報告書、Slackの連絡を組み合わせる場合は、経費精算と月次報告を分けて設計します。経費精算では、申請内容から不足情報や確認事項を整理するところを先に試します。仕訳の勘定科目、金額、登録先は経理担当者が判断します。

月次報告では、対象期間と元データを示した下書きを作り、数値を照合してから共有します。誤りが見つかったら、集計条件、取引の分類、参照時点のどこに原因があるかを確認します。同じ原因が続く場合は、投稿範囲を広げる前にデータの扱いを直します。

5ツール統合の設計例と期待できる変化

freee・HubSpot・Notion・Slack・Google Calendarを組み合わせる構成も考えられます。ただし、すべてを一度に接続する必要はありません。横断依頼に必要な情報源を選び、各段階で取得結果と次の操作を確認できる設計にします。

横断依頼が処理される流れ

「財務状況と商談パイプラインを踏まえて、次の事業計画の論点を整理したい」という依頼なら、次の順で進めます。

freeeから、対象期間を指定して売上・費用の実績を参照する
HubSpotから、同じ判断に使う進行中の取引と集計条件を確認する
Notionから、過去の計画と未決定事項を探す
数値の対象期間と取引の対応を人が確かめたうえで、論点の下書きを作る
レビューが必要なら、Google Calendarで空き枠を確認し、候補日時を本人が選ぶ

各段階で参照元を残せば、問い直しや訂正ができます。こうした業務フローの設計は「エージェンティックワークフロー設計ガイド｜AIエージェントの業務自動化を実現する方法」でも解説しています。

Before/Afterで見る変化

導入後の状態を考えるときは、AIの回答だけで判断が完結するものとして扱わず、人が何を確認できるようになるかを見ます。

観点	導入前	導入後
データの確認	各ツールにログインし、画面を切り替えて確認する	AIへの自然言語の質問にまとまる
ツール間の情報	会計とCRMが分かれ、スプレッドシートで突き合わせる	AIが両方を横断し、売上実績とパイプラインをあわせた着地の見通しを出せる
定型業務	レポート作成・集計・通知を人が毎回行う	AIが下書きし、人は確認と判断に時間を使える
引き継ぎ	集計手順が担当者の頭の中にある	依頼文と設定ファイルとして手順が残る

比較する際は、画面を開く回数だけでなく、元データへ戻れるか、照合できない取引を見落としていないか、担当者以外が手順を再現できるかを確認します。これらが満たせない場合は、接続先を増やす前にデータの定義や依頼文を見直します。

AIに任せる範囲と人が判断する範囲

MCPで利用できる操作が増えるほど、実行前に誰が何を見るかを決める必要があります。読み取り、下書き、投稿・更新を別の段階として扱い、それぞれ次へ進む条件を置きます。

読み取りから始め、書き込みは段階的に開放する

最初は、対象の問いに必要な読み取り権限から検討します。商談一覧、議事録、会計情報を参照するときは、回答が使った期間・条件・元レコードを確かめます。必要な情報が読めない場合は、権限を広げる前に接続設定と対象データを確認します。

書き込みを検討する条件は、期間の長さではなく、同じ種類の依頼について担当者が回答を検証でき、訂正すべき箇所と原因を説明できることです。新しい操作を許可するときは対象を絞り、実行前の確認、実行後の読み直し、誤った場合の訂正方法を決めます。

送信・更新の前に人が見る場所を決める

操作ごとの確認担当を決め、下書きから実行へ進む条件を明文化します。

操作	AIに任せる範囲	人が判断する範囲
問い合わせの分類・レコードの要約	分類と要約の作成まで	分類ルールそのものの見直し
社内向けの報告投稿	下書きと投稿（慣れてから）	投稿先チャンネルの決定
顧客向けのメール・招待	下書きと候補日の提示まで	送信の実行
取引ステージ・仕訳の更新	更新案の作成まで	登録の承認
パイプラインやライフサイクルステージの設計	過去データの集計	定義と運用ルールの決定

社内投稿でも、共有先を誤れば訂正が必要です。投稿先、対象期間、元データを確認してから実行します。社外への送信と会計・CRMの更新は、内容を確認した人が実行を判断します。

金額の大きい商談と社外向けの文面は人が書く

重要な商談や顧客向けの連絡では、AIに過去のやり取りや検討事項を整理させ、担当者が文面と提案内容を決めます。相手に伝える事実、約束、次の行動は、参照元を確認したうえで書きます。

下書きを作る場合は、自社の文書ルールと参照してよい情報を指示に含めます。修正が多いときは表現だけを直し続けず、元の記録が不足しているのか、依頼の条件が曖昧なのかを見直します。

MCP導入の実践ステップ

導入は、対象業務を選び、読み取りを確認し、同じ問いを検証してから利用者を広げる順で進めます。次に進む条件を先に決めておくと、接続できたことと業務で使えることを区別できます。

ステップ	やること	次に進む目安
1. 優先順位を決める	接続するツールを1〜2つ選ぶ	最初に解消したい手作業が1つに絞れている
2. セットアップ	MCPサーバーを読み取り専用で接続する	想定した質問に正しいデータで回答が返る
3. ワークフロー設計と検証	繰り返し使う依頼の型を作る	同じ依頼を1〜2週間使い、手直しが減っている
4. チームに広げる	設定と権限を役割ごとに整える	導入した本人以外が同じ手順で使えている

ステップ1: 接続するツールの優先順位を決める

最初に、画面を行き来して答えている問いを一つ選びます。候補を比べる基準は、確認の頻度、ほかのツールとの照合の必要性、元データを人が確認できるかです。

接続先を選ぶ段階では、利用予定のMCPサーバーが必要な読み取り機能を提供し、現在の利用環境で使えるかを確かめます。頻繁に使う問いでも、取引の対応関係が曖昧なら、照合方法を決めてから試します。反対に、一つのツール内で答えられる問いなら、そのツールの既存機能も比較します。

ステップ2: MCPサーバーをセットアップする

採用するホストとMCPサーバーの案内に従って接続を設定します。設定形式や認証方法は利用する組み合わせで確認し、認証情報を共有用の設定ファイルやリポジトリに含めないようにします。

接続後は、対象を特定できる質問で読み取りを試し、回答と元データを比較します。違いが出たら、権限不足、検索条件、データの更新時点を切り分けます。大量のデータを扱う依頼では、各ツールの利用条件を確認し、取得範囲を絞って試します。

ステップ3: ワークフローを設計して検証する

同じ業務で繰り返せる依頼文を作ります。例えば予定と商談を合わせて確認するなら、対象日、商談の条件、回答に含める参照元、確認できない場合の表示方法を指定します。

担当者は回答を元データと比べ、手直しの理由を記録します。期間の解釈を誤るなら依頼文を直し、取引の対応づけで迷うならデータ側のルールを直します。異なる原因を依頼文の追加だけで吸収しようとせず、原因に応じて見直します。担当者が確認手順を説明できる状態になってから、次の依頼や操作へ進みます。

ステップ4: チームに広げる

チームで使う前に、接続するサーバー、役割ごとの権限、依頼文、回答の確認方法を共有します。設定をバージョン管理する場合は認証情報を除き、各利用者の認証は個別に管理します。

導入した本人以外が、同じ問いを実行して元データを確かめられるか試します。再現できない場合は、設定や説明が足りない箇所を直します。書き込みを利用する役割については、承認者と訂正手順も明示してから展開します。

セキュリティ設計と現時点の制約

業務ツールをAIから利用する場合は、どの情報に誰がアクセスできるか、実行内容を後から追えるかを確認します。この節では、権限、記録、処理方式の選択を、接続前に決める項目として整理します。

認証情報とスコープを最小限に保つ

APIキーやトークンを共有用の文書、チャット、リポジトリに載せないようにします。保管方法は利用環境に合わせ、設定を共有するときは秘密情報を含まない形にします。

アクセス範囲は業務上の問いから決めます。HubSpotのプライベートアプリを使う場合は、必要な操作に対応するスコープを設定時に確認します（参考：HubSpot Developers「Private apps」）。コンタクトを読む目的で取引の更新権限まで加える必要があるか、操作ごとに判断します。権限を追加するときは、利用する依頼、承認者、実行後の確認方法を記録します。

監査ログとAPIの上限を運用に組み込む

誰が、いつ、どの接続先で、読み取りまたは書き込みを行ったかを追えるようにします。採用するホストやサーバーで記録できる内容を確かめ、必要な記録が残らない操作は実行範囲に含める前に運用方法を決めます。

APIの利用条件は接続先ごとに確認します。HubSpotを利用する場合は、適用される条件を公式ドキュメントで確認してください（参考：HubSpot Developers「API usage guidelines and limits」）。広い範囲の集計で回答が不完全になるなら、対象を分けて確認するか、既存のレポートで集計した結果を使う方法を検討します。

現時点でMCPが向かないケース

MCPの採用可否は、接続できるかだけで決めず、必要な処理を確認・訂正できるかで判断します。

採用するサーバーの挙動を確認できない場合: 必要な機能、権限、エラー時の結果を検証用の環境で確かめてから、業務データに接続します。
決まった条件で実行したい場合: イベントを契機とする通知や基幹データの同期は、ワークフローや個別のAPI連携と比較します。
複数ツールを同時に更新する場合: 一方だけが更新されたときの扱いを決めます。操作を分け、それぞれの結果を元のツールで確認してから次に進みます。

よくある質問

MCPを導入するのにプログラミングスキルは必要ですか？

必要な作業は、採用するホストとMCPサーバーによって異なります。設定ファイルの編集や認証設定が必要な構成もあるため、利用予定の組み合わせの手順を先に確認してください。社内で扱える人が限られる場合は、接続と更新を誰が担当するか決め、利用者には質問と回答の確認手順を共有します。

MCPで接続したデータのセキュリティはどう考えればよいですか？

まず、扱うデータと利用者を決め、その問いに必要な読み取り権限だけで試します。次に、回答から元データへ戻れるか、アクセスと操作の記録を残せるかを確認します。投稿や更新が必要になったら、実行前に人が確認する内容、実行後の読み直し、誤りを訂正する担当を決めてから権限を追加します。

どのツールからMCP導入を始めるべきですか？

繰り返し確認している問いがあり、回答を元データと比較できるツールから始めます。複数ツールの照合が目的なら、最初に取引先や案件の対応づけを決めます。利用予定のMCPサーバーが必要な機能を提供しているか確認できた段階で、読み取りの検証に進みます。

MCPと従来のAPI連携やZapierなどの自動化ツールとの違いは？

固定した条件と処理で動かす方法に対し、MCPを使ったAIエージェントは依頼に応じて参照先や操作を選ぶ構成にできます。定型の転記や通知なら、条件と結果を固定できる方法を比較します。複数の情報源を調べて下書きや判断材料を作るなら、MCPの利用を検討します。技術的な違いと使い分けの基準は「AIとRPAの違い・使い分け」で解説しています。

社内で複数人がMCPを使う場合、どう管理すべきですか？

役割ごとに必要な接続先と操作を決め、認証情報は利用者ごとに管理します。秘密情報を除いた設定と依頼文に加え、回答の参照元を確かめる手順も共有します。担当者以外が同じ問いを検証できない場合は、権限を広げる前に設定と手順を見直します。

まとめ

MCPを使うと、AIエージェントから複数の業務ツールの情報を参照し、問いに応じて組み合わせる構成を検討できます。導入の出発点は、接続する製品の一覧ではなく、会計・CRM・議事録のどの情報を照合して判断したいかです。

企業様によって最適な形は異なります。進め方は、次の順が基本です。

一つの問いを決める ── 対象データ、照合方法、回答を確認する担当者を決めます。
読み取りを検証する ── 結果を元データと比較できたら、依頼文を整えます。
他の人でも再現する ── 担当者以外も同じ手順で確認できるか試します。
書き込みは条件付きで広げる ── 投稿や更新が必要な場合は、その操作の承認者と訂正方法を決めてから範囲を広げます。

導入の出発点は、接続する製品の一覧ではなく、どの情報を照合して判断したいかです。

このテーマの全記事はAIエージェント運用ガイドでご覧いただけます。

CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。

記事の内容を、そのまま実務に落とし込みたい方向け

無料で相談する資料をダウンロード

株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。

著者情報

今枝 / Imaeda

株式会社StartLink 代表取締役。累計150社以上のHubSpotプロジェクト支援実績を持ち、Claude CodeやHubSpotを軸にしたAI活用支援・経営基盤AXのコンサルティング事業を展開。
HubSpotのトップパートナー企業や大手人材グループにて、エンタープライズCRM戦略策定・AI戦略ディレクションを経験した後、StartLinkを創業。現在はCRM×AIエージェントによる経営管理支援を専門とする。