情報システム部門に「ClaudeからHubSpotを見られるようにしたい」という依頼が上がったとき、最初に止まるのは技術ではありません。止まるのは「誰のどの権限で、どこまで書き換えられるのか」を説明できないことです。コネクタを1クリックで有効化できてしまうぶん、稟議の場では「止められるのか」「ログは残るのか」「間違えたら戻せるのか」という質問に答えられるかどうかが先に問われます。
株式会社100はHubSpotの認定エリートパートナーとして、CRMを全社の収益プロセスの基盤に据える企業の導入と運用を支援しています。その現場で2026年に入って急増したのが、AIクライアントとCRMの接続方式に関する相談です。HubSpotは2026年4月13日にリモートMCPサーバーを一般提供に切り替え、書き込みを含む操作が標準機能として使えるようになりました（Remote HubSpot MCP server is now generally available）。読み取り専用の実験だった段階と、権限設計を前提にした運用段階とでは、決めるべきことが変わります。
この記事では、HubSpotとClaudeをつなぐ方式が実際には何通りあるのか、それぞれで権限がどこで効くのか、書き込みの承認ルールをどう置くのかを整理します。Agent HubのエージェントとMCPを組み合わせた設計そのものについてはAgent HubとMCP・Claude Codeの設計で扱っているため、本記事は接続方式の選定と権限・承認の設計に絞ります。
目次
「MCPでHubSpotにつなぐ」という一言の中に、実際には性質の異なる4つの経路が混在しています。混在したまま議論すると、片方の制約をもう片方の話として説明してしまい、稟議が通りません。最初に経路を分けて名前を付けます。
整理の軸は2つです。接続を開始するのが誰か（利用者本人か、開発したアプリか）と、処理がどこで動くか（Anthropicのクラウドか、利用者の端末か）。この2軸で分けると、選定の判断がぶれなくなります。
| 経路 | 何を使うか | 認証 | 主な用途 |
|---|---|---|---|
| ① HubSpotコネクタ for Claude | HubSpotが公式提供するディレクトリ掲載コネクタ | ユーザーごとのOAuth（管理者承認あり） | 営業・マーケ部門の個人利用 |
| ② リモートMCPサーバーへの自前接続 | mcp.hubspot.com に任意のMCPクライアントから接続 | 自アカウントで作成したMCPコネクタのOAuth 2.1 + PKCE | Claude Codeや自社ツールからの開発・運用 |
| ③ 開発者向けMCPサーバー（ローカル） | HubSpot CLIが起動するローカルサーバー | CLIの認証情報 | アプリ・CMSの開発作業 |
| ④ HubSpotエージェントから外部MCPサーバーへ | アプリにMCPサーバーコンポーネントを追加（パブリックベータ） | OAuth 2.1認可コードフロー + PKCE | Agent Builderのツールとして外部サービスを呼ぶ |
HubSpotが自社で運用しているMCPサーバーは2種類あります。CRMデータに外部のAIツールを接続するリモートサーバーと、開発作業のためにCLI経由で動くローカルサーバーは、別のものとして提供されています。この2つを同じものとして扱うと、権限の話が噛み合わなくなります。
リモートサーバー側で読み書きできる対象は、コンタクト・企業・取引・チケットといったCRMオブジェクトと、通話・Eメール・ミーティング・ノート・タスクなどのアクティビティです。ユーザー・チーム・レポートライン・オーナー・シートといった組織情報、キャンペーンやランディングページ、ブログ記事などのコンテンツは読み取り専用として扱われます。
私たちがクライアントのポータルで接続検証を行うときは、この「読み取り専用で返ってくる領域」を先に押さえます。組織情報が読めるということは、担当者名・チーム構成・レポートラインがAIクライアント側の文脈に載るということです。人事情報に準じた扱いが必要かどうかを、接続前に情報管理部門と握っておく必要があります。
Claude側の用語では、接続先は「ディレクトリ掲載のコネクタ」「カスタムコネクタ」「デスクトップ拡張機能」に分かれます。HubSpotコネクタは前者で、接続されたサービスの中でデータの取得だけでなくアクションの実行もできます。
見落とされやすいのは、カスタムコネクタの接続元がAnthropicのクラウド基盤だという点です。Claude、Claude Desktop、Cowork、モバイルアプリのいずれでも、接続はローカル端末ではなくAnthropicのクラウドから行われます。社内ネットワークやVPNの内側にあるサーバーには届かず、公開インターネットから到達できる必要があります。
端末側のリソースに触れたい場合は、デスクトップ拡張機能という別系統になります。公式ヘルプはこの違いを、ファイルシステムやクリップボード、ローカルプロセスといったOSレベルのリソースに触れるかどうかで説明しています（When to use desktop and web connectors）。HubSpotのようなクラウドサービスはリモート側、社内の基幹システムに端末経由でしか届かないケースはデスクトップ側、という切り分けになります。
選定の分岐点は機能差ではなく、運用を誰が背負うかです。私たちが提案書で接続方式を書き分けるときは、次の順序で決めています。
①と②を同時に走らせることは禁止ではありませんが、監査の観点では推奨しません。同じユーザーが2経路を持つと、操作ログがコネクタ単位で分かれ、「誰がどの経路で書き換えたか」の追跡が一段増えます。
最も短い経路であるぶん、承認の論点が設定画面の中に埋まっています。設定手順そのものは数分で終わりますが、そこで選ぶ項目が後の運用を決めます。手順と判断を分けて見ていきます。
利用には、アクティブなHubSpotユーザーアカウントとClaudeアカウントに加えて、Anthropicの有料サブスクリプション（Pro、Max、Team、Enterprise）が必要です。HubSpot側は全プロダクト・全プランが対象で、HubSpotの契約を上げる必要はありません。このコネクタ自体は無償で提供されます。費用が発生するのはClaude側の契約だけ、という整理になります。
ユーザー権限の扱いも明確です。スーパー管理者とApp Marketplace Accessを持つユーザーは承認なしで接続でき、それ以外のユーザーはスーパー管理者の承認が先に必要です。HubSpotの権限体系では、CRMオブジェクトの閲覧・編集・削除がそれぞれ「すべて」「チームが所有するもの」「自分が所有するもの」の範囲で設定されます（HubSpot user permissions guide）。この範囲がそのまま接続後の上限になります。権限設計の基礎はHubSpotのユーザー権限に整理しています。
承認プロセスで管理者が選ぶのは、インストールの可否だけではありません。承認時には任意のデータ権限を選べ、アカウント内の誰がインストールできるかも指定できます。つまり「全社で使えるようにするが、取引の金額は見せない」といった絞り込みが、個々の利用者ではなく管理者の手元で完結します。
コネクタがアクセスし得る範囲は、標準CRM（コンタクト、リード、企業、取引、チケット、カスタムオブジェクト）、マーケティング（キャンペーン、ランディングページ、ブログ記事、マーケティングEメール、セグメント）、コマース（商品、見積、請求書など）、アクティビティ（通話、ミーティング、ノート、タスク、Eメール）、設定系（パイプライン、プロパティ、ユーザー、チーム）に及びます。設定系が読み取り専用で含まれる点は、稟議資料に明記しておく価値があります。
削除については、コネクタは閲覧・作成・更新に対応し、削除操作には対応しません。これは運用設計上は大きな安心材料です。一方で「更新」は既存の値を上書きするため、復旧が難しい操作である点は変わりません。削除がないことと、戻せることは別の話です。
利用者はチャット画面の「+」からコネクタを選び、HubSpotのスイッチを入れてからプロンプトを送ります。レコードの作成や更新が提案された場合は、内容を確認してから実行の可否を答える流れになります。公式ナレッジベースは、更新前に必ず承認を求める設定、すなわち書き込み系ツールを「Needs Approval」にしておくことを推奨しています。
一括処理には上限があります。一括操作は一度に10件までです。条件付きプロパティのルールやパイプラインのステージ検証ルールは適用される一方で、関連付けラベルの検証は適用されません。この非対称性は、データの入り口を揃えたい組織にとって重要です。
コネクタでは届かない範囲、たとえば夜間バッチや社内ツールからの呼び出しを設計する場合は、MCPサーバーに直接つなぐ経路を選びます。この経路は認証の実装が利用者側に寄るぶん、権限の設計自由度も上がります。
HubSpotの開発者ドキュメントでは、HubSpotアカウントの「Development」>「MCP Connectors」からコネクタを作成し、名前・説明・リダイレクトURL・アイコンを設定するとクライアントIDとクライアントシークレットが発行される、という手順が示されています（Integrate AI tools with the HubSpot MCP server）。接続確認には get_user_details ツールを呼ぶことが案内されています。
認証はPKCEが必須です。同ドキュメントには、43文字から128文字の code_verifier を生成し、S256方式で code_challenge を導出して認可リクエストに含めること、トークン交換時に code_verifier を送ることが記載されています。MCP Inspectorで検証する場合は、リダイレクトURLに http://localhost:6274/oauth/callback/debug を登録する必要があります。
PKCEが必須である意味を、稟議の言葉に翻訳しておくと説明が早くなります。クライアントシークレットを配布しなくても、認可コードの横取りを防げる方式だという点です。モデルコンテキストプロトコルの仕様自体も、ホストがツールを呼び出す前に明示的なユーザー同意を得るべきだと定めています（Model Context Protocol Specification）。認可の詳細は仕様のAuthorizationに定義されています。
Claude Codeでは、リモートサーバーの追加に claude mcp add --transport http <name> <url> を使い、認証は /mcp コマンドまたは claude mcp login で行います。スコープにはlocal・project・userの3種があり、projectを選ぶと .mcp.json がリポジトリに置かれ、チーム全員に共有されます。
ここは運用ルールを決めておく場所です。.mcp.json をリポジトリに置くこと自体は便利ですが、同ドキュメントはAPIキーやパスワードを直接書かず環境変数や headersHelper を使うよう求めています。私たちがクライアントの開発ルールを整備する際は、プロジェクトスコープは接続先の定義のみ、認証情報はユーザースコープという切り分けを標準にしています。
アプリケーションから直接呼ぶ場合は、Messages APIのMCPコネクタ機能という選択肢もあります。ベータヘッダー mcp-client-2025-11-20 を付ければ、個別のMCPクライアントを実装せずにリモートMCPサーバーへ接続でき、ツールの許可リスト・拒否リストを設定できます。管理者が触れない領域をアプリ側で先に閉じられる点が、この方式の利点です。
検索と取得には明示された上限があります。search_crm_objects で使えるフィルターグループは最大5つ、各グループのフィルターは最大6つで、1ページあたり最大200件、get_crm_objects は1リクエストあたり最大100件のオブジェクトIDが上限です。SQL的なクエリでは結合・別名・サブクエリ・関連付けの辿りが使えません。
センシティブデータを有効化しているアカウントでは、アクティビティや会話のデータがブロックされます。センシティブデータを有効にしたアカウントは、MCPサーバー経由でアクティビティオブジェクトにアクセスできません。医療・金融領域の案件では、この制約が設計の出発点になります。
見積設計の観点では、API全体の使用量上限も併せて見ます。接続方式を増やすほど呼び出しは分散し、ピーク時の失敗が読みにくくなります。私たちが検証環境で負荷を確認するときは、想定の3倍の頻度で同じ問い合わせを流し、エラー時のリトライが二重更新を起こさないかを先に見ます。
「AIにCRMを触らせる」という議論が止まるのは、権限が1か所で決まると思われているからです。実際には4つの層が重なっており、どの層で何を止めるかを決めると、議論が具体的になります。層を上から順に見ていきます。
| 層 | 設定場所 | 止められること | 止められないこと |
|---|---|---|---|
| 1. HubSpotのユーザー権限 | HubSpotのユーザーとチーム設定 | 閲覧・編集・削除の対象範囲（全件／チーム／自分） | 許可済みの範囲内での操作 |
| 2. アプリのスコープと管理者承認 | HubSpotの承認フロー | オブジェクト単位のデータ権限、インストール可能なユーザー | 個々のレコードの指定 |
| 3. Claude側の組織設定 | Organization settings > Connectors | コネクタの有効化、ツール呼び出しの無効化、読み取りのみへの制限 | HubSpot側の権限を超えた拡張 |
| 4. 会話ごとのツール制御 | チャットのSearch and toolsメニュー／承認設定 | 個別ツールの有効・無効、書き込み前の承認 | 利用者が許可した操作の取り消し |
効きます。すべての操作が既存のHubSpotユーザー権限を尊重します。ユーザーはHubSpot上でアクセスを許可されているデータしか見られません。
ここで実務上の問題が1つ浮かびます。権限設計が甘いポータルでは、AI接続によって初めてその甘さが表面化します。全員が全件閲覧できる設定のまま運用してきた組織では、画面上は「探しにくいから見られていない」状態だったものが、自然文の問い合わせ1回で出てくるようになります。接続の是非を議論する前に、権限の棚卸しを先に行うほうが、結果的に早く合意できます。
Team・Enterpriseの管理者は、組織設定からコネクタを有効化し、接続されたサービスが取れるアクションを制限できます。読み取りのみを許可して書き込みを禁止するといった制御も、インタラクティブなコネクタのツール呼び出し自体の無効化もできます。
カスタムコネクタを許可する場合は、追加できる人を限定する設計が前提になります。Teamではオーナーのみ、Enterpriseではライブラリ管理権限を持つ役割のみが追加できます。無償プランでは1つまでという制限があり、有料プランでは個数制限が設けられていません。
セキュリティ上の注意も明記されています。Anthropicの検証を受けていないサーバーに接続する可能性があること、悪意あるサーバーが隠れた指示を含み得ること、サーバー側の更新で挙動が変わり得ることです。ディレクトリに掲載されるコネクタには別途ポリシーが設けられています（Anthropic Software Directory Policy）。社内でカスタムコネクタを解禁する場合は、接続先URLのホワイトリストを情報システム部門で管理する運用を併せて決めてください。
自社でMCPサーバーを作ってHubSpotのマーケットプレイスに載せる場合は、要件が文書化されています。掲載の要件は、mcpUrl がシークレットを含まないHTTPSであること、スコープがアプリの必要権限と一致すること、未解決の重大・高リスク脆弱性がないこと、センシティブデータのスコープが承認されたアプリはMCPコンポーネントを含められないことなどです。
ツールの記述にも基準があります。accessType はデータを変更するツールに write、読み取り専用に readOnly を指定します。初回のフィードバックは10営業日以内に返るとされています。自社アプリを配布する計画がある企業は、この要件を内製ルールとして先取りしておくと、審査でのやり直しが減ります。
読み取りだけなら議論は単純です。難しいのは書き込みで、ここは技術ではなく業務設計の問題になります。私たちがクライアントとルールを決めるときに使っている枠組みを示します。
判断の軸は「間違えたときに誰が気づくか」です。気づく人がいる操作は自動でよく、誰も気づかない操作は承認を挟みます。この軸で分けると、現場の反発が小さくなります。
| 操作 | 推奨 | 理由 |
|---|---|---|
| ノート・タスクの作成 | 自動実行 | 追加のみで既存の値を壊さない。担当者が画面で気づく |
| 通話・ミーティングの記録 | 自動実行 | タイムラインに積まれるだけで、上書きが起きない |
| 取引ステージの更新 | 承認待ち | 予実とフォーキャストに直結する。誤りが後から見えにくい |
| ライフサイクルステージの更新 | 承認待ち | ワークフローの登録条件を連鎖的に動かす |
| 企業・コンタクトの属性更新 | 承認待ち | 上書きされた旧値を人が覚えていない |
| 一括更新 | 承認待ち＋件数制限 | 誤りが件数分だけ増幅する |
コネクタ経由では削除が実行されない一方で、更新による上書きは起こります。HubSpotのプロパティ履歴は保持されるため、1件ずつなら追跡できます。ただし数十件が同時に書き換わった場合、どの値が正だったかを業務側が判断する作業が発生します。
この作業を減らすには、入り口でルールを効かせるのが確実です。プロパティに検証ルールを設定しておけば、形式の崩れた値は入りません。テキスト・電話番号・数値のプロパティでは一意の値を必須にでき、1オブジェクトあたり最大10個まで作成できます。AI接続の前に、主要プロパティの検証ルールを一通り入れておくことをおすすめします。
加えて、書き換えの影響が業務に波及する前に止める仕組みも要ります。私たちがデータ基盤を設計する際は、更新の起点をプロパティ単位で記録し、AI経由の更新だけを抽出できるビューを先に作ります。SSOT（信頼できる唯一の情報源）とデータガバナンスの考え方をAI接続に適用すると、議論が「禁止するか・許すか」から「どこに記録を残すか」に移ります。
運用に乗せる前に、確認すべき記録の場所を決めておきます。HubSpot側はプロパティ履歴とレコードのタイムライン、接続アプリの一覧。Claude側は組織設定のコネクタ一覧と、会話単位のツール呼び出し。この2系統を突き合わせる前提で、インシデント時の手順書を1枚作っておくと、実際に何かあったときの初動が変わります。
記録の粒度に過度な期待はしないでください。「誰がどのプロンプトで何を変えたか」を1画面で追える仕組みは、公式ドキュメントに記載を確認できませんでした。現時点では、HubSpot側の変更記録とClaude側の会話履歴を人が突き合わせる前提で運用設計してください。
CRMデータに触れない経路として、開発作業専用のローカルサーバーがあります。この経路はCRMの権限設計とは無関係なため、情報システム部門の承認フローも別物として扱えます。アプリやCMSの実装を内製している企業には、導入のハードルが最も低い入口です。
利用にはHubSpot CLIのバージョン 8.2.0 以上が必要で、hs mcp setup を実行して対象クライアントを選びます。対応クライアントとしてClaude Code、Codex CLI、Cursor、Gemini CLI、VS Code、Windsurfが挙げられています。このローカルサーバーは2026年2月19日に一般提供となりました（HubSpot Developer MCP server (local) for App and CMS Development Now in GA）。
私たちが開発チームに最初に勧めるのはこの経路です。CRMの本番データに触れずにMCPの扱いに慣れられるため、権限設計の議論と並行して技術検証を進められます。順序を逆にすると、検証が終わるまで稟議が動かない状態になります。
ここまでは「外からHubSpotを見る」話でしたが、方向が逆の経路も用意されています。アプリにMCPサーバーコンポーネントを追加すると、顧客アカウントへのインストール後にAgent Builderのツール選択肢として現れます。この機能は現時点でパブリックベータです。
設定の要点は、hsproject.json のプラットフォームバージョン指定、app/mcp-server/ 配下へのメタファイル配置、そして公開HTTPSで到達できるエンドポイントです。認証はOAuth 2.1の認可コードフローにPKCEを組み合わせる形で、リダイレクトURIは固定値が指定されています。/.well-known/oauth-authorization-server でメタデータを公開する必要もあります。
この方向を選ぶ意味は、AIの実行基盤をHubSpot側に置けることです。利用者ごとのAIクライアント契約に依存せず、HubSpotのエージェントとして配布できます。エージェントの構築についてはAgent Builderの使い方に整理しています。ベータ機能であるため、仕様は変更される可能性があります。
ここまでの内容を、意思決定に使える形にまとめます。どちらが優れているかではなく、組織の状態によって適した入口が違うという整理です。
| 観点 | HubSpotコネクタ for Claude | リモートMCPサーバーへの自前接続 |
|---|---|---|
| 導入の速さ | 設定画面のみで完結 | MCPコネクタ作成とOAuth実装が必要 |
| 管理者の統制 | 承認時にデータ権限を選択 | スコープ設計を自社で定義 |
| 対象ユーザー | 部門の担当者 | 開発・運用チーム |
| 自動化との接続 | 対話が前提 | スクリプト・CIから呼べる |
| 削除操作 | 非対応 | スコープ設計に依存 |
| 追加コスト | Claude側の有料契約のみ | 実装・保守の工数が発生 |
| 向かないケース | 定期実行・大量処理 | 非エンジニア部門への展開 |
私たちが1,000名規模の組織で提案するときは、ほぼ例外なく「③で技術検証、①で部門展開、②で自動化」という順序を取ります。①から始めて成果が出ると、②の投資判断が通りやすくなります。逆に②から始めると、効果を説明する相手が社内にいない状態が続きます。
接続方式の議論と並行して、CRM側の状態を整える作業が必要になります。AIが返す答えの精度は、モデルではなくデータの整い方で決まります。接続する前に見ておく点を挙げます。
第1に、プロパティの意味が1つに定まっているか。同じ「受注金額」が部門ごとに違う定義で使われている状態では、自然文の問い合わせに対して矛盾した答えが返ります。第2に、重複レコードが放置されていないか。同一企業が複数レコードに分かれていると、集計も要約もずれます。第3に、所有者とチームの割り当てが実態と合っているか。権限が実態とずれていると、見えるべき人に見えず、見えてはいけない人に見える状態が生まれます。スキーマの定義・フィールドレベルの権限・検証ルールは、データガバナンスの出発点になります。
この3点は、AI接続の有無にかかわらず価値のある整備です。AI-ReadyなCRMの考え方として整理していますが、要点は「AIのために特別なことをする」のではなく、これまで後回しにしてきた整備が成果に直結するようになった、という点にあります。
HubSpot側は全プロダクト・全プランが対象で、コネクタ自体は無償です。必要なのはAnthropicの有料サブスクリプション（Pro、Max、Team、Enterprise）です。ただしHubSpot側で使える機能はご契約中のプランの範囲に限られるため、たとえばワークフローやレポート機能の有無はそのまま反映されます。
権限を4層で考える枠組み自体は、CRM製品を問わず使えます。ただし各層で何を止められるかは製品ごとに異なり、本記事で挙げた設定項目はHubSpotの公式ドキュメントに基づくものです。当社はHubSpotの認定エリートパートナーであり、他製品のMCP連携について実装の経験に基づく記述はできません。他製品については、各ベンダーの公式ドキュメントが一次情報になります。
HubSpot側では、スーパー管理者が承認プロセスの中でインストールできるユーザーを指定できます。Claude側では、Team・Enterpriseの管理者が組織設定からコネクタの有効・無効とツール呼び出しの可否を制御できます。ユーザー単位で細かく止めたい要件がある場合は、HubSpot側のチーム設計と権限セットで区切るほうが運用が安定します。
論点は3つあります。検証を受けていないサーバーに接続する可能性、悪意あるサーバーが隠れた指示を含む可能性（プロンプトインジェクション）、サーバー側の更新で挙動が変わる可能性です。HubSpot公式のコネクタとサーバーを使う限り接続先は明確ですが、カスタムコネクタを解禁する場合は接続先URLの管理ルールを先に決めてください。
接続自体は可能ですが、制約があります。センシティブデータを有効化したアカウントでは、アクティビティや会話のデータがMCPサーバー経由でブロックされます。カスタムのセンシティブデータプロパティや医療情報にはアクセスできません。該当する場合は、何が返らないかを前提に用途を設計してください。
間に合います。比較対象がない場合は、接続後の1か月を基準期間として扱い、問い合わせ内容の分類と所要時間を記録してください。現実的に測りやすいのは、レポート作成の依頼件数、データ入力の漏れ件数、新任担当者が独力で答えを出せた割合の3つです。接続前のデータがないことを理由に測定を諦めると、次の投資判断で同じ問題が起きます。
全部任せられない理由を、技術ではなく業務の言葉で説明してください。書き込み操作のうち、間違えたときに誰も気づかないものは承認を挟む、という基準が最も伝わります。本記事の操作別の表をそのまま使っていただいて構いません。基準を示すと、議論が「AIを信用するか」から「どの操作が業務上クリティカルか」に移ります。
HubSpotエージェントから外部MCPサーバーを呼ぶ機能は、パブリックベータです。ベータ機能を前提にした稟議は、仕様変更時の代替案をセットで書いてください。当社が計画書を作る際は、ベータ依存の工程を全体の工程から切り離し、仕様が変わっても他の工程が止まらない構成にしています。
この記事で扱った内容を、意思決定の順序として整理します。
接続方式そのものは、どれを選んでも数日で動きます。時間がかかるのは権限と承認の合意形成です。技術検証と合意形成を並行で走らせられるかどうかが、プロジェクト全体の期間を決めます。
株式会社100は、世界上位1%・日本唯一のHubSpot認定エリートパートナーとして、CRMの権限設計からAI接続の運用ルール策定までを支援しています。自社のポータルでどこから着手すべきか具体的にご相談がある場合は、お問い合わせからご連絡ください。
最終更新日: 2026年10月23日（本記事の記載は同日時点の公式ドキュメントに基づきます。仕様・上限・提供条件は変更される可能性があるため、実装前に一次情報をご確認ください）