MCP(Model Context Protocol)とは、AIと社内のシステムやデータをつなぐための共通規格のこと。AIがSFA・メール・カレンダー・ファイルなどを「道具」として使うときの、接続のしかたを定めている。
営業の現場にとっての意味は、SFAに記録した営業データを、使いたいAIから直接読み書きできるようになること。これまで個別の開発が必要だったAIとSFAの連携が、共通の方法で行えるようになった。
ただし、つなげば成果が出るわけではない。AIが読むのはSFAに記録されたデータであり、権限の設計を誤れば誤操作や情報漏えいの原因にもなる。この記事では、MCPの仕組みと他の連携方式との違い、営業業務別の活用例、導入の手順、そしてSFAをつなぐときの権限とセキュリティの注意点までを整理する。
MCPとは
MCPは、Anthropicが2024年11月に公開したオープンな規格。AIアプリと外部のシステムの間で、どのようにデータをやり取りし、どのように操作を呼び出すかを定めている。
2025年12月には、Linux Foundationのもとに設立されたAgentic AI Foundationへ寄贈された。同団体はAnthropic・Block・OpenAIが共同で設立し、Google・Microsoft・AWSなどが支援している。MCPは特定の企業に依存しない共通規格として運営されている(出典:Anthropic「Donating the Model Context Protocol and establishing the Agentic AI Foundation」)。
同じ発表によれば、MCPはChatGPT・Cursor・Gemini・Microsoft Copilot・Visual Studio Codeなどで採用され、公開されている稼働中のMCPサーバーは1万を超える。
たとえるなら「共通の差し込み口」
MCPの役割は、機器をつなぐ端子の規格にたとえられることが多い。端子の形がそろっていれば、どのメーカーの機器でも同じケーブルでつなげる。
MCPも同じで、システム側がMCPの形で「差し込み口」を用意すれば、MCPに対応したどのAIからでも同じ方法でつなげる。AIごとに別々の接続を作る必要がなくなるのが要点。
MCPの仕組み
MCPは、3つの役割で構成される。
| 役割 | 中身 | 営業での例 |
|---|---|---|
| ホスト | 利用者が操作するAIアプリ | 営業担当者が使うAIのチャット画面 |
| クライアント | ホストの中で、MCPサーバーとの接続を受け持つ部分 | AIアプリに組み込まれた接続機能 |
| サーバー | システムのデータや機能をMCPの形で公開する部分 | SFAやメール、カレンダーのMCPサーバー |
利用者がAIに「今週停滞している案件を出して」と頼むと、AIはSFAのMCPサーバーに問い合わせ、返ってきたデータをもとに答えを組み立てる。
サーバーが公開するもの
MCPサーバーは、主に3種類のものをAIに公開する。
| 種類 | 中身 | 営業での例 |
|---|---|---|
| ツール | AIが呼び出せる操作 | 案件を検索する、活動記録を登録する、レポートを作る |
| リソース | AIが読める情報 | 顧客情報、案件の一覧、商談の議事録 |
| プロンプト | 決まった作業の手順のひな形 | 週次報告の作成手順、商談前の確認手順 |
AIは、サーバーが公開しているツールの一覧と説明を読み、指示に合うものを選んで使う。どのツールを公開するかはサーバー側が決めるため、AIにさせたくない操作は、そもそも公開しなければよい。
つなぎ方:手元の接続と、ネットワーク越しの接続
MCPの接続には、大きく2つの形がある。
| 形 | 仕組み | 主な用途 |
|---|---|---|
| 手元の接続 | 利用者のパソコンの中で、AIアプリがMCPサーバーを直接起動して通信する | 個人のファイルや、開発者の作業環境 |
| ネットワーク越しの接続 | インターネットなどを経由して、別の場所で動くMCPサーバーと通信する | SFAなどのクラウドサービス |
SFAのようなクラウドサービスをつなぐ場合は、ネットワーク越しの接続になる。この場合、MCPの仕様ではOAuthを土台にした認証の仕組みが定められており、利用者は自分のアカウントで接続を許可する。誰の権限でつながっているかが明確になるため、利用者ごとの閲覧権限をAIからの操作にも適用しやすい。
API連携・RAG・Function Callingとの違い
AIと社内のデータをつなぐ方法は、MCP以外にもある。それぞれの違いを整理する。
| 方式 | 仕組み | 向いていること | 弱いところ |
|---|---|---|---|
| API連携 | システムごとの呼び出し方に合わせて個別に開発する | 決まった処理を確実に動かす | つなぐ組み合わせごとに開発が要る |
| RAG | 文書を検索し、関係する部分をAIに渡して答えさせる | マニュアルや過去資料からの回答 | データの更新や操作はできない |
| Function Calling | AIが呼び出す関数を、AIの提供元ごとの形式で定義する | 特定のAIで特定の処理を呼ぶ | AIの提供元ごとに定義が異なる |
| MCP | AIとシステムの接続方法を共通の規格にする | 複数のAIと複数のシステムをつなぐ | 権限と安全性の設計が要る |
MCPはAPIを置き換えるものではない。多くのMCPサーバーは、内部でシステムのAPIを使っている。MCPは、APIの上に「AIから使うための共通の入口」を載せると考えると分かりやすい。
RAGとも競合しない。マニュアルや提案書の検索はRAGで、案件データの集計や記録の登録はMCPで、と組み合わせて使える。たとえば「この顧客に近い業種の受注事例を探して、提案の骨子を作って」という指示なら、受注事例の案件をMCPでSFAから絞り込み、その提案書の中身をRAGで検索する、という組み合わせになる。
営業でMCPが注目される理由
営業の領域でMCPが注目される理由は3つある。
1. 営業データが複数のシステムに分かれている
営業の情報は、SFA・メール・カレンダー・チャット・ファイル共有などに分かれている。AIにこれらをまとめて扱わせるには、システムごとに接続を作る必要があった。MCPなら、それぞれのシステムがMCPサーバーを持っていれば、AIから同じ方法で使える。
2. 使うAIを後から選び直せる
AIモデルの性能と価格は、短い周期で入れ替わる。特定のAIに合わせて連携を作り込むと、より良いAIが出ても乗り換えにくい。用途によってAIを使い分けたい場合もある。文章の作成に強いAI、表の集計に強いAIを使い分けても、データ側の接続は1つで済む。MCPでつないでおけば、AIを変えても、データ側の接続はそのまま使える。
3. 個別開発の費用と時間を減らせる
AIとSFAを連携させるたびに個別の開発をすると、費用も時間もかかる。MCPに対応したSFAを使えば、AIアプリの設定でつなぐだけで始められる場合がある。
SFAがMCPに対応すると何が変わるか
SFAは、これまで人が入力し、人が見るためのシステムだった。画面の見やすさや操作のしやすさが、主な価値だった。
MCPに対応すると、SFAはAIが読み、AIが使うデータの土台にもなる。人がSFAの画面を開いて探し、集計し、転記していた作業を、AIへの指示で済ませられるようになる。
| 観点 | これまで | MCP対応後 |
|---|---|---|
| 情報の探し方 | 画面を開き、検索条件を指定して探す | AIに自然な言葉で尋ねる |
| 集計 | レポートを作り、条件を設定する | 「フェーズ別の金額を出して」と頼む |
| 記録 | 商談後に画面へ入力する | 議事録やメモからAIが下書きし、人が確認して登録する |
| 他システムとの連携 | 連携ごとに開発・設定する | MCPに対応したシステム同士をAIがまたいで使う |
当社は2025年10月、SFA「GoCoo!」の正式リリースにあわせて、MCPサーバー接続によるAI連携への対応を発表した(お知らせ)。その際に掲げた考え方が、SFAは「人が使う」時代から「AIが使う」時代へというもの。AIがSFAのデータを読み解き、自社の勝ちパターンを学ぶには、まず営業データを蓄積する場所が要る、という位置づけ。
もっとも、人がSFAの画面を使わなくなるわけではない。案件の全体を一覧で眺める、記録を確かめて直す、といった作業は引き続き画面で行う。変わるのは、探す・集計する・転記するといった作業の多くが、AIへの指示に置き換わること。画面は「確かめて直す場所」、AIは「探して下書きする手段」という役割の分担になる。
営業業務別の活用例
SFAをMCPでAIにつないだときに、任せられる作業を業務別に整理する。
| 業務 | AIへの指示の例 | AIが使うデータ |
|---|---|---|
| 商談準備 | 「明日訪問するA社のこれまでの経緯と、確認すべき点をまとめて」 | 活動履歴・案件・議事録 |
| 活動記録 | 「この議事録から活動記録を作って、次回アクションも入れて」 | 議事録・案件 |
| フォロー | 「最終接触から30日以上たっている提案中の案件を出して」 | 案件・活動履歴 |
| パイプライン確認 | 「今月受注予定の案件をフェーズ別に、金額つきで一覧にして」 | 案件 |
| 着地見込み | 「今四半期の着地見込みを、確度別に集計して」 | 案件・過去の受注実績 |
| 報告 | 「今週のチームの活動をまとめて、所見を3点書いて」 | 活動履歴・案件 |
| 失注の振り返り | 「直近半年の失注理由を集計して、傾向を説明して」 | 案件・失注理由 |
| 経営分析 | 「商材別・チャネル別の受注額の推移を出して」 | 案件・取引の記録 |
どの例も、SFAに記録されたデータの範囲でしか答えられない。次回アクションが記録されていなければフォロー対象は出ないし、失注理由が自由記述でばらばらなら傾向は読めない。
最初に試すなら
最初に試すなら、パイプライン確認と商談準備がよい。どちらも読み取りだけで完結し、答えが正しいかを人がすぐに確かめられる。日常的に発生するため、効果も実感しやすい。
逆に、経営分析や失注の振り返りは、データの量と質が十分にそろってから取り組むほうがよい。データが少ないうちに傾向を尋ねると、偶然の偏りを傾向と取り違えるおそれがある。
指示と動きの具体例
MCPでつないだAIが、実際にどのように動くかを4つの場面で示す。
マネージャーの月曜の朝
マネージャーが「先週から動きのない案件を、担当者別に出して。金額の大きい順で」と頼む。AIはSFAのMCPサーバーで案件を検索し、最終更新日と金額で絞り込み、担当者ごとの表にして返す。マネージャーは表を見て、会議で取り上げる案件を決める。
これまでは、レポートの条件を設定するか、担当者に状況を聞いて回る必要があった。
営業担当者の商談前
営業担当者が「午後のB社との商談の準備をしたい。前回までの経緯と、相手が気にしていた点をまとめて」と頼む。AIは活動履歴と議事録を読み、時系列の要約と、前回の宿題、確認すべき論点を返す。
経緯の確認に使っていた時間が、論点の検討に回る。
週次の報告
マネージャーが「今週のチームの活動と案件の動きをまとめて、報告の下書きを作って」と頼む。AIは活動件数・新規案件・フェーズの進んだ案件・受注と失注を集計し、所見を添えた下書きを作る。マネージャーは所見を直して提出する。
営業企画の失注分析
営業企画の担当者が「直近半年で失注した案件を、失注理由と競合別に集計して。前の半年と比べて増えた理由を説明して」と頼む。AIは案件の失注理由と競合の項目を集計し、期間ごとの差を表にしたうえで、増えた理由の候補を挙げる。担当者は、候補のうち確かめるべきものを選び、現場への聞き取りにつなげる。
失注理由が決まった選択肢で記録されていれば、この集計は数秒で済む。自由記述のままなら、AIが文章を読んで分類することになり、精度が落ちる。
4つの場面に共通するのは、AIが探して集計し、人が判断して直すという分担。
複数のシステムをまたいで使う
MCPの利点が最も出るのは、複数のシステムを同時につないだとき。
| 組み合わせ | できること |
|---|---|
| SFA×カレンダー | 今週の訪問予定ごとに、案件の状況と前回の経緯をまとめる |
| SFA×メール | 顧客とのメールのやり取りを読み、活動記録の下書きを作る。フォローメールの下書きを作る |
| SFA×チャット | チームのチャットに、停滞案件の一覧や週次の集計を流す |
| SFA×ファイル共有 | 過去の受注案件の提案書を探し、新しい提案の下書きの参考にする |
| SFA×会計・販売管理 | 受注後の請求・入金の状況を案件と突き合わせる |
たとえば「来週の訪問予定ごとに、相手先の案件の状況と前回のメールの要点をまとめて」という指示は、カレンダー・SFA・メールの3つを読まなければ答えられない。MCPでそれぞれがつながっていれば、AIが3つをまたいで1つの答えにまとめる。
ただし、つなぐシステムが増えるほど、AIが触れられるデータの範囲も広がる。つなぐ前に、どのシステムのどのデータまでをAIに見せるかを決めることが欠かせない。
MCPと営業AIエージェントの関係
MCPとあわせて語られることが多いのが、営業AIエージェント。両者の関係を整理しておく。
- 営業AIエージェント:目的を受け取り、手順を組み立て、道具を使って作業を進めるAIの仕組み
- MCP:そのエージェントが「道具」を使うときの、接続の規格
エージェントは、道具が使えなければ何もできない。SFAの案件を読む、カレンダーの予定を確かめる、メールの下書きを作る、といった動きは、それぞれのシステムに接続できて初めて可能になる。MCPは、その接続を共通の方法にした。
つまり、エージェントの能力は、MCPでつながっている道具の数と、その道具が持つデータの質で決まる。どれだけ賢いAIでも、SFAに記録がなければ営業の仕事は手伝えない。
導入の進め方
SFAをMCPでAIにつなぐときは、次の順で進める。
1. 任せたい作業を決める
最初は、読み取りだけで完結する作業を選ぶ。商談前の要約、停滞案件の洗い出し、集計と報告の下書きなど。書き込みを伴う作業は後に回す。
2. データを確認する
任せたい作業に必要なデータが、SFAに記録されているかを確かめる。次回アクションや失注理由が空欄だらけなら、先に記録のルールを整える。
3. 権限を決める
AIに読ませる範囲と、書き込ませる範囲を決める。利用者ごとの閲覧権限をAIにも引き継げるかを確認する。
4. 一部の利用者で試す
マネージャーや一部のチームで試し、AIの答えが正しいかを人が確かめる。誤りがあれば、指示の書き方か、データの記録に原因がある。
5. 書き込みと対象を広げる
読み取りで効果が確認できたら、活動記録の下書きなど、人の承認を挟む書き込みに広げる。つなぐシステムも1つずつ増やす。
立場ごとの使い方
SFAをMCPでAIにつないだときの使い方は、立場によって違う。
| 立場 | 主な使い方 | 期待できること |
|---|---|---|
| 経営層 | 商材別・チャネル別の受注推移、着地見込みを尋ねる | レポートを待たずに、必要なときに数字を確かめられる |
| 営業マネージャー | 停滞案件の洗い出し、担当者別の活動の偏りの確認、報告の下書き | 状況の確認より、打ち手の判断に時間を使える |
| 営業担当者 | 商談前の経緯の要約、議事録からの活動記録の下書き、フォロー対象の確認 | 記録と準備の時間が減り、商談に時間を回せる |
| 営業企画・マーケティング | 失注理由や受注の傾向の分析、リードの経路別の成果の集計 | 分析のためのデータ抽出の手間が減る |
| 情報システム部門 | 接続の管理、権限の設定、操作記録の確認 | AIの利用を管理された形で広げられる |
立場ごとに、AIに見せてよい範囲は違う。経営層には全社の数字を、営業担当者には自分とチームの案件を、と分けるには、前述のとおり利用者の権限をAIにも引き継げることが前提になる。
権限と書き込みの設計
MCPでAIにSFAを使わせるときに、最も重要なのが権限の設計。次の考え方で組み立てる。
| 設計 | 内容 | 理由 |
|---|---|---|
| 読み取りから始める | 最初は読み取りのツールだけを公開する | 誤った書き込みの影響を受けない |
| 書き込みは承認制にする | AIは変更案を示し、人が承認してから反映する | 誤りを人が止められる |
| 利用者の権限を引き継ぐ | AIが参照できる範囲を、依頼した人の閲覧権限と一致させる | 見てはいけない情報が答えに混ざらない |
| 削除は公開しない | レコードの削除はAIに許可しない | 取り返しのつかない操作を避ける |
| 操作を記録する | 誰の依頼で、何を読み、何を変えたかを残す | 問題が起きたときに追える |
| 複製したデータにつなぐ | 本番のSFAではなく、複製したデータの上でAIを動かす | 本番の運用に影響を与えない |
とくに「利用者の権限を引き継ぐ」は見落とされやすい。AIに管理者の権限でつないでしまうと、一般の担当者がAIに尋ねただけで、本来は見られない案件や金額が答えに含まれてしまう。
セキュリティで気をつけること
MCPは便利な一方で、新しい種類のリスクも持ち込む。導入前に次の点を確認したい。
信頼できないMCPサーバーをつながない
MCPサーバーは誰でも作って公開できる。出所の分からないサーバーをつなぐと、AIを通じてデータが外部に送られるおそれがある。業務でつなぐサーバーは、提供元と管理者を確かめ、社内で許可したものに限る。
データに紛れ込んだ指示に注意する
AIは、読み込んだデータの中に書かれた文章を、指示と取り違えることがある。たとえば顧客から届いたメールの本文に、AIへの不正な指示が紛れ込んでいる場合。外部から届いた文章を読ませる作業では、書き込みや送信をAIに直接させないのが基本。
接続の資格情報を管理する
MCPサーバーへの接続には、認証の情報が使われる。個人が勝手に接続を作ると、誰がどのデータにアクセスしているか分からなくなる。接続の作成と解除は、情報システム部門などの管理者が行う形にする。
外部への送信を止める
メールやチャットの送信をAIに許可すると、誤った相手に誤った内容が送られるおそれがある。最初は下書きまでにとどめ、送信は人が行う。
MCPを活かすためのデータの準備
MCPでつないだAIの答えの質は、SFAのデータの質で決まる。つなぐ前に、次の3点を整えておきたい。
| 準備 | 内容 | 整っていないと起きること |
|---|---|---|
| 記録を1か所に集める | 顧客・案件・活動をSFAに集約する | AIが材料を見つけられない |
| 項目の意味をそろえる | フェーズ・確度・失注理由などを選択式にし、定義を決める | 集計や比較の結果がずれる |
| 重複をなくす | 同じ会社や担当者の重複したレコードを統合する | 同じ顧客が別々に数えられる |
AIは、項目の名前と中身から意味を推測して答える。「確度A」が担当者によって違う意味で使われていれば、AIの集計も同じようにずれる。人が読んでも分かりにくいデータは、AIが読んでも分かりにくい。
記録の集約と定着については、SFAと連携したほうが良いツールと連携のメリット や 営業活動でデータ分析をする方法 も参考になる。
費用と体制の考え方
MCPそのものは公開された規格で、規格を使うこと自体に費用はかからない。費用がかかるのは、規格の両側にあるものと、運用の体制。
| 区分 | 中身 | 確認すること |
|---|---|---|
| AIアプリ | 利用者が使うAIアプリの利用料 | 業務利用の契約で、入力したデータの扱いが明示されているか |
| MCPサーバー | SFAなどのMCP対応。製品に含まれるか、別の契約や開発が要るか | 対応範囲と、追加費用の有無 |
| データの整備 | 記録の集約、項目の定義、重複の統合 | 社内の工数として見込んでいるか |
| 運用 | 接続と権限の管理、利用ルールの更新、効果の確認 | 担当者と、使える時間を決めているか |
見落とされやすいのは、データの整備と運用の2つ。製品の費用は見積で比べられるが、この2つは社内の工数として表に出にくい。
体制は、大きく作る必要はない。営業部門で使い方と効果を確かめる担当と、情報システム部門で接続と権限を管理する担当の2者がいれば始められる。営業部門だけで進めると権限の管理が甘くなり、情報システム部門だけで進めると使われない。両者で決めておくことが、長く使うための前提になる。
社内ルールの作り方
MCPでAIをSFAにつなぐ前に、社内の利用ルールを決めておく。決めておきたいのは次の5点。
| 項目 | 決めること |
|---|---|
| 使ってよいAIアプリ | 業務で使うAIアプリと、契約の形態(データの扱いを確認したもの) |
| つないでよいMCPサーバー | 社内で許可したサーバーの一覧と、追加するときの手続き |
| AIに渡してはいけない情報 | 個人情報や契約上の機密など、AIに読ませない範囲 |
| 出力の確認 | 顧客に届くもの、記録に残るものは、人が確認してから使う |
| 送信と書き込み | 送信は人が行う。書き込みは承認を挟む |
ルールは細かく作り込むより、最初は短く決めて、運用しながら足すほうが守られる。試行の段階で起きた問題をルールに反映していけばよい。
効果の測り方
SFAをMCPでAIにつないだ効果は、作業時間の変化で先に確かめる。受注などの結果は、効果が出るまで時間がかかるため。
| 指標 | 測り方 |
|---|---|
| 集計・報告にかかる時間 | 導入前後に1〜2週間、作業時間を記録して比べる |
| 商談前の準備時間 | 担当者への聞き取り、または作業の記録 |
| 活動記録の登録率 | 活動のうち、SFAに記録された割合 |
| 停滞案件の件数 | 次回アクション日を過ぎたまま更新されていない案件の数 |
| AIの答えの修正率 | AIの出力のうち、人が直した割合 |
最後の「修正率」は、データの質を測る指標にもなる。修正が多い業務は、指示の書き方か、SFAの記録に問題がある。
MCP対応のSFA・営業ツールを選ぶ観点
MCPに対応したSFAや営業ツールは増えている。選ぶときは、「MCP対応」と書かれているかだけでなく、次の点を確かめる。
| 観点 | 確かめること |
|---|---|
| 公開されるツールの範囲 | 読み取りだけか、書き込みもできるか。削除まで公開されていないか |
| 権限の引き継ぎ | 利用者ごとの閲覧権限が、AIからの操作にも適用されるか |
| 承認の仕組み | 書き込みの前に人の確認を挟めるか |
| 操作の記録 | AIからの操作が記録され、後から確認できるか |
| 対応するAIアプリ | 自社で使っている、または使いたいAIアプリからつなげるか |
| 接続の管理 | 接続の作成・解除を管理者が一元的に行えるか |
| データの集約 | 他のシステムのデータも取り込み、1か所で扱えるか |
最後の「データの集約」は重要。MCPでつなげるのは、そのSFAに入っているデータまで。営業データが他のシステムに分かれたままなら、AIが読める範囲もその分だけ狭くなる。
既存のSFAを使い続けたままMCPを試す方法
すでに別のSFAを使っていて、乗り換えずにAIを試したい場合もある。方法は大きく2つ。
1. 使っているSFAのMCP対応を確かめる
使っているSFAがMCPに対応していれば、そのままつなげる。対応している範囲(読み取りだけか、書き込みもできるか、権限を引き継げるか)を、前述の観点で確かめる。
2. データを複製して、MCPに対応した基盤に載せる
使っているSFAがMCPに対応していない、または本番環境にAIをつなぐことに不安がある場合は、SFAのデータを別の基盤に複製し、その基盤をMCPでAIに公開する方法がある。
この方法なら、既存のSFAの設定や運用を変えずに済む。AIが触れるのは複製したデータなので、本番のデータを誤って書き換えるおそれもない。複製の際に、散らばっていた項目や重複したデータを整理できる利点もある。
よくある誤解
「MCPに対応すれば、AIが勝手に売上を上げてくれる」
MCPはつなぐための規格であり、成果を生むのはデータと使い方。記録が不十分なら、AIは正しい答えを出せない。
「MCPを使うと、全データをAIの提供元に渡すことになる」
AIが読むのは、指示に応じてMCPサーバーから取り出したデータに限られる。ただし、取り出したデータはAIモデルに送られて処理されるため、AIアプリの利用規約やデータの扱いは別途確認が必要。
「MCPはエンジニアのためのもの」
自社のシステムをMCPに対応させる開発にはエンジニアが要る。一方、MCPに対応したSFAを使う側は、AIアプリの設定でつなぐだけで始められる場合がある。
「APIがあればMCPは要らない」
APIがあれば、AIとの連携を個別に開発することはできる。ただし、AIやシステムが増えるたびに開発が要る。MCPは、その組み合わせごとの開発を減らすための規格。
導入でよくある失敗
1. つないだだけで終わる
接続の設定を済ませても、誰が何に使うかが決まっていなければ、使われないまま終わる。最初の業務と利用者を決め、使った結果を確かめる場を設ける。
2. 管理者の権限でつないでしまう
試しにつなぐときに、管理者のアカウントで接続しがち。そのまま利用者を広げると、全員が管理者と同じ範囲のデータをAIを通じて見られる状態になる。試行の段階から、利用者本人の権限でつなぐ。
3. データの記録が追いついていない
AIに尋ねても、答えが「データがありません」や不正確なものばかりになる。原因はAIではなく、SFAの記録の抜け。記録の定着を先に進めるか、議事録から活動記録を起こすなど、記録そのものをAIで補う使い方から始める。
4. いきなり書き込みまで任せる
最初から記録の登録や更新をAIに任せると、誤った値が入ったときに気づきにくい。誤りが積み重なると、SFAのデータそのものが信頼されなくなる。書き込みは、読み取りで効果を確かめた後に、承認を挟んで始める。
まとめ
- MCPは、AIと社内のシステム・データをつなぐ共通規格。2024年11月にAnthropicが公開し、2025年12月にAgentic AI Foundationへ寄贈された
- 構成はホスト・クライアント・サーバー。サーバーがツール・リソース・プロンプトを公開し、AIが選んで使う
- APIを置き換えるものではなく、APIの上に「AIから使うための共通の入口」を載せるもの。RAGとも組み合わせられる
- SFAがMCPに対応すると、SFAは「人が使う」システムから「AIも使う」データの土台になる
- 営業では、商談準備・活動記録・フォロー・パイプライン確認・報告などを自然な言葉の指示で任せられる
- 読み取りから始め、書き込みは承認制、利用者の権限を引き継ぎ、操作を記録する
- 答えの質はデータの質で決まる。記録の集約と項目の定義を先に整える
GoCoo! SFAはMCPサーバーに対応しており、営業データをMCPで公開して、Claude・GPT・Geminiなど使いたいAIとつなげられます。既存のSFAを使い続けたままAIを試したい場合は、本番環境に触れずに複製したデータの上で動くGoCoo! Agentもあります。どの業務からAIに任せられるか、現在のデータの置き場所を伺ったうえでご提案します。