ネイティブ接続とMCP接続、
AIの「見え方」はどう違うか── Outlook環境の企業が Copilot・Claude・HubSpot をどう配置するか
Copilotのように業務インフラと最初からつながっているAIと、MCPで後から接続したAI（Claude等）では、社内データの見え方に差があるのか。差があるとすれば、どちらを、誰に、何のために使うべきか。現場で判断できる形に整理します。
結論を先に
見える範囲は同じ。違うのは「見つけやすさ」。どちらの接続も、ユーザー本人がすでに持っている権限の範囲で動きます。Copilotには見えてClaudeには見えないデータは、原則ありません。
差が出るのは、「何を探せばいいか分からない問い」に答えられるかです。インフラと一体のAIは社内データを事前に索引化しているため、横断的な「発見」が得意。後から接続したAIは、都度取りに行く仕組みのため、検索語に当たったものを深く「読む・判定する・作る」のが得意です。
したがって、乗り換えの判断ではなく配置の判断になります。現場の窓はインフラのAI、判断と構築は汎用AI、商談の正本はHubSpot。
2つのつなぎ方は、仕組みが違う
ある企業の営業現場で、Copilotが5年前のメールから顧客との接点を掘り当てた、という出来事がありました。現場は沸きました。なぜCopilotにはそれができたのか。仕組みを並べると理由が見えます。
- テナント全体のメール・ファイル・会話を、事前に意味検索用の索引に載せておく
- ユーザーの問いを、索引に対して意味で照合する
- 権限のある範囲で、関連度の高いものを横断的に集める
- アプリ（Outlook等）の画面内でそのまま答える
- ユーザーの問いから、AIが「何を検索するか」を決める
- その場で検索・取得のリクエストを発行し、結果を受け取る（事前索引なし、内容の保持なし）
- 受け取った結果を読み、足りなければ検索を重ねる
- 別窓のAIチャットで、他システムの情報と束ねて答える
MCP（Model Context Protocol）は、AIが外部システムを「道具」として呼び出すための共通規格です。Anthropic・Microsoft・HubSpotなど主要各社が対応しており、Copilotも外部データの接続にMCPを使い始めています。つまり「ネイティブかMCPか」は、今後は「索引を持っているか、都度取りに行くか」の違いに収れんしていきます。
違いは5つに絞れる
| 観点 | ネイティブ接続（Copilot等） | MCP接続（Claude等） |
|---|---|---|
| ①索引 | 事前に全体を索引化。横断的な「発見」が得意 | 都度取得。検索語に当たったものを深く処理 |
| ②権限・範囲 | ユーザー本人の権限で、テナント全体 | 同じ。ユーザー本人の権限で、テナント全体（サイト限定は不可） |
| ③一度に扱う量 | 索引済みなので長大なスレッドの要約が速い | 1回の取得に上限。長大なものは何往復かで読む。代わりに複数システムを一つの推論で束ねられる |
| ④書き戻し | アプリ内の操作としてそのまま実行 | 管理者が有効化すれば、メール送信・予定管理・ファイル作成更新まで可（一部の操作は不可） |
| ⑤居場所 | 普段使うアプリの画面の中にいる | 別窓。切り替えの摩擦がある |
②と④は、2026年に入って差がほぼ消えました。残っているのは①③⑤、つまり「発見」か「深掘り」かという得意分野の違いです。
一問で分けられる
「見つけたい」なら、インフラのAI
- 過去の接点・記録の発掘
- 日常のメール処理・返信の下書き
- 会議の要約、決定事項の確認
- 「誰が知っているか」を探す
「判定・実行したい」なら、汎用AI
- メール・CRM・ファイル・Webを束ねた判断
- 提案書・分析レポートなど成果物の作成
- CRMの構築、設定、データの整備
- 「この商談は追うべきか」を基準に照らして判定
先の「5年前の接点発見」は、見事に「見つける」側の仕事でした。ただしその直後に残った問い——「で、この接点は追うべき案件なのか」——は「判定する」側の仕事です。ここには、どのAIを使うかより前に、「良い商談とは何か」という自社の基準が必要になります。
推奨する配置：乗り換えではなく、二層で置く
Outlookを使っている企業が「Claudeに乗り換えるべきか」と悩む必要は、ほぼありません。すでにCopilotが入っているなら、それを現場の窓として活かし、汎用AIは少人数に配置します。
AIの側は、どの会社でも同じものが手に入ります。差がつくのは一番下の層、「何を良い仕事とするか」を自社の言葉で書いてあるかです。 GuildSpotの戦略カルテは、この層を作るための道具です。
自社で確かめる手順
「見え方の差」は、資料を読むより自分の環境で試すのが早い。同じテナントで、同じ問いを両方に投げます。
- 問いを決める。「〇社との過去の接点を、すべて洗い出して」のように、探す場所も語も決まっていないもの。
- 両方に投げる。CopilotとClaude（Microsoft 365コネクタ接続済み）で、同じ文言のまま。
- 3つを数える。見つけた件数、到達した最も古い年代、答えに至るまでの往復回数。
- 次に「判定」の問いを投げる。「この中で、いま追うべき接点はどれか。理由も」。どちらも答えに困るはずです——基準を渡していないから。
- 基準を1文渡してもう一度。「直近2年以内に決裁者との接点があり、かつ当社の対象業種であるものを優先」など。答えが変わる様子を確認する。
手順3で「発見」の差が、手順4〜5で「基準があれば判定できる」ことが体感できます。この2つの体感が、配置を決める根拠になります。
よくある誤解
CopilotとClaude、結局どちらが優秀なのか？
問いの立て方が違います。「発見」はCopilot、「深掘り・判定・作成」はClaude、というのが2026年時点の得意分野です。どちらか一方に全部やらせようとすると、どちらも中途半端になります。
Copilotが入っているなら、Claudeは不要では？
現場全員には不要かもしれません。ただ、HubSpotの構築や分析、複数システムを束ねた判断を担う数名にとっては、別窓であることの摩擦より、推論の深さと組み合わせの自由度のほうが効きます。
汎用AIからHubSpotは読めるだけで、書けないのでは？
変わってきています。Microsoft公開のHubSpotコネクタにも更新を許可する設定が追加されており、Claude側のHubSpot MCPは書き込みに対応しています。どこまで更新できるかは、権限設定と併せて自社で検証したうえで運用範囲を決めるのが安全です。
MCP接続はセキュリティ的に不安では？
主要各社のコネクタは、ユーザー本人に委任された権限で動き、データは元の場所に置いたまま都度取得します。「AIが余計なものを見る」のではなく「本人が見られるものだけをAIも見る」構造です。詳細は当社の別ナレッジ「HubSpot × Gemini MCP接続 セキュリティ評価」も参考にしてください。