MCPとAPIの使い分け｜BtoBデータ連携とAI統制の判断基準
MCPとAPIはBtoBのデータ連携で役割が異なります。AIエージェントに何を渡すかという文脈設計の観点から、選択の判断基準、設計手順、統制のチェックリストをマーケティング責任者向けに整理します。
公開 2026年10月2日
結論：まず「接続」と「文脈」を分けて考える
MCPとAPIは競合する技術ではなく、担う層が違います。APIは「システム同士をつなぐ約束事」、MCPは「AIモデルに文脈を渡す約束事」として整理すると判断が速くなります。마ーケティング部門が最初に決めるべきは、どちらを採用するかではなく、AIに何を見せて何を見せないかという範囲の定義です。
言い換えれば、連携方式の議論に入る前に、取り扱うデータの定義と責任の所在を文書化しておく必要があります。ここが曖昧なまま接続だけを進めると、応答の根拠が追えない仕組みが先に出来上がります。
※本記事は2026年10月時点の情報をもとに作成しています。
MCPとAPIとは：役割の違いを定義する
APIとは、アプリケーション同士が決められた形式でデータをやり取りするための接続仕様です。リクエストとレスポンスの形が固定され、認証・権限・レート制限といった運用ルールが伴います。MA、CRM、SFA、フォーム基盤の連携は長くこの方式で組まれてきました。
MCP（Model Context Protocol）とは、AIモデルが外部のデータやツールを文脈として参照するための取り決めです。AIエージェントが「どの情報源を、どの条件で参照してよいか」を宣言的に扱う点が、従来の個別実装との違いになります。
両者は置き換え関係ではありません。APIが下層の接続を担い、MCPはその上でAIに渡す文脈の範囲を決める層として重なります。したがって議論の順序は、①データの正本はどこか、②誰が参照してよいか、③AIにどこまで渡すか、の順になります。
どちらを軸にするかの判断基準
判断は既存システムの成熟度とAI活用の段階で変わります。下表を自社の現状に当てはめてください。
| 自社の状態 | 中心に置く方式 | 先に着手すること |
|---|---|---|
| CRM/MAの項目定義が揺れている | API中心 | 正本データの一元化と項目の統廃合 |
| 連携は安定、AI活用は検証段階 | APIを維持しMCPを部分適用 | 参照範囲の限定と検証用の評価基準づくり |
| 複数のAIエージェントが並行稼働 | MCPを前提に設計 | 権限・ログ・監査の共通ルール整備 |
| 対象業務が1つ、関係者も少数 | 既存APIのみ | 無理に方式を増やさない |
重要なのは、技術選定の前に「誰のどの判断を速くしたいのか」を一文で書けることです。書けない場合、どちらを選んでも運用で止まります。マーケティング側の具体論はマーケティング部門向けの整理も合わせてご確認ください。
AIに渡す文脈の設計手順
文脈設計は、データの粒度と更新頻度で分類すると破綻しにくくなります。手順は次の4段階です。
- 参照させる情報源を列挙し、正本と写しを区別する
- 公開可否を3段階（公開可／条件付き／不可）で付与する
- AIが回答に使ってよい範囲を文書化する
- 範囲外の質問が来たときの受け渡し先を決める
| 情報種別 | 更新頻度 | AI参照の扱い |
|---|---|---|
| 製品仕様・料金体系 | 低〜中 | 登録資料を根拠に参照可 |
| 導入条件・前提環境 | 中 | 条件付きで参照、断定表現を避ける |
| 商談履歴・個別見積 | 高 | 原則不可、担当者へ引き継ぐ |
4段階目の「受け渡し」を省くと、曖昧な回答がそのまま残ります。引き継ぎのルール設計はMQLの引き渡しとSLAの考え方が参考になります。
統制とログ：何を記録すれば運用できるか
統制は、記録すべき項目を先に決めるところから始まります。接続方式が何であれ、後から検証できない仕組みは運用に耐えません。
| 記録項目 | 目的 | 確認の頻度 |
|---|---|---|
| 参照した資料とその版 | 回答根拠の追跡 | 随時 |
| 回答できなかった質問 | 資料の不足箇所の特定 | 週次 |
| 担当者へ引き継いだ文脈 | 営業側の初動の整合 | 週次 |
| 権限設定の変更履歴 | 範囲外参照の防止 | 月次 |
週次の確認は、マーケティングと営業の双方が同じ画面を見る場として設計します。片方だけが見る運用は形骸化しやすい傾向があります。回答範囲の決め方はAI回答のガバナンスでも整理しています。
よくある失敗のパターン
接続先を増やすことが目的になる。 参照できる情報源が多いほど良いと考え、項目定義の整理を後回しにする形です。直し方は、最初の対象業務を1つに限定し、情報源を3つ以内に絞ることです。
「不可」の定義がない。 公開可の範囲だけを決め、答えてはいけない範囲を書かないパターンです。不可リストを先に作り、該当時の引き継ぎ文面まで決めておきます。
ログを取るだけで見ない。 記録は残っているが、誰がいつ確認するかが決まっていない状態です。週次の確認担当と、確認結果を資料修正に戻す経路を明文化します。
方式の刷新でCPL課題を解こうとする。 連携方式は流入や単価の構造には直接触れません。費用の見方はAI活用とCPL・ROIの考え方を参照してください。
この進め方が向いていないケース
次の条件に当てはまる場合、本記事の進め方は適しません。
- 公開してよい資料が社内に整理されておらず、作成の目処も立っていない
- 対象業務が1つで、担当者が手作業で完結している
- データの正本が複数システムに分散し、どれが正しいか合意できていない
- 法務・情報セキュリティの確認プロセスが未設置
これらの状態では、まず資料と項目定義の整備が先です。接続の設計から入ると、整備されていない前提がそのまま仕組みに写ります。小規模な検証から始める場合の進め方はPoCの進め方にまとめています。
よくある質問
MCPを使えばAPI連携は不要になりますか。
なりません。APIはシステム間の接続を担い、MCPはAIに渡す文脈の範囲を扱う層です。多くの場合、両方が併存します。
どちらから着手すべきですか。
既存のデータ項目が安定していないなら、API側の整理が先です。項目定義が固まっていれば、参照範囲を限定した検証から始められます。
マーケティング部門が決めるべきことは何ですか。
公開してよい資料の範囲、答えてはいけない質問の定義、引き継ぎ先の3点です。技術選定より先に文書化します。
情報システム部門との役割分担はどうなりますか。
接続と権限は情報システム部門、資料の中身と回答範囲はマーケティング部門が持つ分担が一般的です。週次の確認を共同で行う形にします。
まとめ
MCPとAPIは、担う層が異なる別の取り決めです。選択の前に、正本データの所在、公開してよい範囲、答えない範囲、引き継ぎ先を文書化してください。この4点が決まれば、方式の議論は短く済みます。
統制の要点は、記録する項目と、記録を見る頻度と、見た結果を資料に戻す経路を決めることです。関連する整理はナレッジ記事一覧にまとめています。
UniAgentは、Webサイト上で登録資料を根拠に説明とヒアリングを行い、担当者へ文脈を付けて引き継ぐAIです。