MCP連携ガイド｜AIと業務システムを安全につなぐ接続設計と実装手順

2026年3月11日
最終更新: 2026年10月18日

この記事の結論

MCPは、AIエージェントが業務システムを呼び出す接続口を標準化するプロトコルです。自社の条件で接続先を選び、小さく始めて、権限と人の承認を設計してから広げることが導入の要になります。

ブログ目次

「CRMの情報を会計ソフトやスプレッドシートに手で転記している」「AIに質問しても、社内システムのデータにはつながっていない」——このような声は、AIと業務システムの間をつなぐ仕組みが無いことから生まれます。

MCP（Model Context Protocol）とは、AIエージェントが外部ツールやデータソースを、安全かつ標準化された方法で呼び出せるようにするプロトコルです。CRM・会計・チャット・ドキュメントをMCPでつなぐと、複数の業務システムを横断して動くAIエージェントを実装できます。

Model Context Protocol（MCP）を使ったAIシステム連携、HubSpot MCP Server、実装パターンの解説です。このカテゴリには21本の記事があります。実務で使える知識を体系的にまとめています。

この記事でわかること

本ページでは、MCPでAIと業務システムをつなぐときの論点を、基本構造から接続設計、セキュリティ、マルチツール構成まで順番に整理します。各テーマの詳細記事への入口としても使えます。

MCPの基本構造とREST APIとの違い — ホスト・クライアント・サーバーの関係と、どちらを使うべきかの判断軸がわかります
HubSpot MCP Serverの位置づけ — コンタクト・会社・取引のデータを、AIからどの段階で扱うかを整理します
スモールスタートの接続手順 — 読み取り専用から始め、書き込みと接続先を段階的に広げる進め方がわかります
セキュリティと権限の設計 — 認証、最小権限、プロンプトインジェクション対策の考え方を確認できます
マルチツール統合と自作サーバーの判断 — freee・Slack・Google Workspace・Notionとの連携パターンと、既存サーバーか自作かの選び方がわかります

この記事を読み終えるころには、自社の業務のうちMCPに任せる範囲と、最初に接続する1つの業務が決められます。まずは、転記や検索に時間がかかっている業務を1つ選ぶところから始めてください。

MCPとは何か｜REST APIとの違いから整理する

MCPは新しい種類のAPIというより、AIエージェントが「どんな道具が使えるか」を知り、それを呼び出すための共通ルールです。まず構成要素を押さえ、そのうえで既存のREST APIとどう使い分けるかを、自社の業務に当てはめて整理します。

MCPを構成するホスト・クライアント・サーバー

MCPは、AIアプリケーション（ホスト）、ホストの中でサーバーとの接続を受け持つクライアント、そして機能を公開するサーバーの3者で構成されます。業務システム側の窓口がサーバー、AIを使う側の窓口がホストとクライアントと捉えると、全体を把握しやすくなります。

サーバーが提供する機能は、Resources（データや文脈）、Prompts（定型のメッセージやワークフロー）、Tools（AIが実行する関数）の3つに整理されています。（出典：Specification - Model Context Protocol）

業務システム連携で中心になるのはToolsです。例えば「HubSpotで会社を検索する」「Slackにメッセージを投稿する」といった操作が、それぞれ1つのツールとしてサーバーから公開されます。

AIがツールを自分で見つけられる仕組み

MCPでは、クライアントがサーバーに「使えるツールの一覧」を問い合わせます。サーバーは、各ツールの名前、何をするかの説明、受け取る入力項目を返します。AIはこの説明を読み、依頼の内容に合うツールを選んで呼び出します。（出典：Tools - Model Context Protocol）

REST APIとの大きな違いは、この「エージェントが自律的にツールを発見し、呼び出せる」点にあります。開発者が呼び出し手順を一つずつ書き込むのではなく、AIが利用可能なツールの説明を読み、状況に応じて選びます。そのため、ツールの説明の書き方が、AIの選択の精度に影響します。

REST APIとMCPの使い分け

本記事では、選択基準を「AIエージェントが自律的に呼び出す必要があるか」と整理します。人がトリガーする処理はREST API、エージェントが判断して動く処理はMCPが適しています。

観点	REST API	MCP
呼び出しの起点	人や既存プログラムが決めたタイミング	AIエージェントが状況に応じて判断
ツールの見つけ方	開発者が仕様書を読んで実装	クライアントがサーバーにツール一覧を問い合わせる
向いている処理	定期同期、フォーム送信後の連携など手順が固定された処理	問い合わせ内容によって参照先が変わる調査・要約・下書き
結果のぶれ	同じ入力なら同じ結果	AIの判断が入るため、同じ依頼でも手順が変わることがある

判断の分かれ目は、処理の手順を事前に書き切れるかどうかです。書き切れる処理はREST APIや既存のワークフローで組み、手順が毎回変わる処理だけをMCP経由でAIに任せます。この順で切り分けると、AIに任せる範囲を必要以上に広げずに済みます。

自社の業務を一覧にして、手順が固定されているものと依頼ごとに変わるものに分けるところが、MCP導入の最初の判断になります。

なぜ業務システム連携にMCPを使うのか

MCPの価値は、AIの性能そのものよりも、分断された業務データをAIからまとめて扱える点にあります。ここでは、手作業の転記が生む課題を起点に、MCPが効く場面と効かない場面を分けて考えます。

スプレッドシートと手作業の転記が生む分断

例えば、CRMの取引情報を会計ソフトに転記し、進捗をチャットで共有し、議事録をドキュメントツールに残している場合、情報が複数の場所に分かれます。この状態では、同じ顧客について「どれが最新か」がわからなくなります。スプレッドシートで管理を補っている場合は、手動の更新が増え、差分も生まれやすくなります。

AIを導入しても、AIが参照できるのが会話に貼り付けた情報だけであれば、この分断はそのまま残ります。MCPは、AIが各システムのデータに直接アクセスする接続口を用意することで、この転記作業そのものを減らす選択肢になります。

一元管理・自動化・可視化をAIからつなぐ

顧客データの置き場所はCRMに集め、決まった処理はワークフローで自動化し、数字はダッシュボードで見る。この土台を整えたうえで、「この会社の過去のやり取りを要約して」「請求に必要な項目が欠けている取引を探して」といった、手順が毎回変わる依頼をMCP経由でAIに任せる構成をおすすめします。データの置き場所が定まっていないままMCPをつなぐと、AIも分散したデータを横断するだけになり、どれが正しい情報かの判断は人に戻ってきます。

MCPが向かないケース

ただし、すべての連携をMCPに寄せる必要はありません。次のような処理は、既存のAPI連携やワークフローのほうが運用しやすいと考えています。

処理の特徴	向いている方法	理由
毎回同じ条件・同じ手順で動く	ワークフロー・REST API	結果が安定し、失敗時の原因も追いやすい
金額や契約に直結し、誤りが許されない	人の操作、または承認つきの連携	AIの判断が入る余地を残さない
参照先や手順が依頼ごとに変わる	MCP	AIがツールを選んで組み合わせられる

自社の業務を書き出し、各業務がこの表のどの行に当たるかを分類してから、MCPに任せる対象を選ぶと、導入範囲が明確になります。例えば、フォーム送信後の担当者通知は1行目、請求金額の確定は2行目、商談前の過去のやり取りの要約は3行目に分類できます。この場合、MCPの候補になるのは3行目の業務です。

HubSpot MCP ServerでCRMを全体フローに組み込む

HubSpot MCP Serverは、CRMデータへのAIアクセスを安全に実現し、コンタクト管理・取引更新・レポート生成をAIエージェントから操作できるようにする仕組みです。大切なのは、AIが触れるデータを顧客との関係の流れのどこに置くかを、自社の営業プロセスに合わせて先に決めることです。

コンタクトから請求までの流れで位置づける

フローの段階	主に扱うデータ	AIに任せやすい作業	人が判断すること
コンタクト	コンタクト・会社	重複候補の洗い出し、会社情報の要約	統合するレコードの最終決定
取引	取引・パイプライン	商談履歴の要約、次のアクションの下書き	ステージの更新、大型案件の提案内容
顧客	会社・チケット	問い合わせ履歴の要約	対応方針の決定
請求	取引と会計データ（freee等）	請求に必要な項目の不足チェック	請求書の発行判断

コンタクト・会社・取引が関連付けられたCRMであれば、AIは1社に紐づく人・商談・問い合わせをまとめて参照できます。逆に、関連付けが不十分なまま接続すると、AIの要約も断片的になります。接続前に、主要な取引に会社とコンタクトが紐づいているかを見て、紐づいていない取引が多ければ先にデータを整えることをおすすめします。

読み取りと書き込みを分けて開放する

AIからCRMを扱うときは、「参照」と「更新」を同じ扱いにしないことがポイントです。検索や要約は間違えても人が気づいて捨てられますが、取引ステージや金額の更新はレポートの数字に直接影響します。

最初は読み取りの用途に限定し、AIの回答の根拠になったレコードを人がたどれる状態で運用します。そのうえで、更新は「下書きを作り、人が承認してから反映する」形で開放していく流れをおすすめします。

CRMの設計が整っていることが前提になる

AIはプロパティの名前や値を手がかりに判断するため、使われていない項目が大量にあるCRMでは、どの項目を見るべきかをAIも取り違えやすくなります。項目は最小限に絞り、取引ステージの定義を社内で共有しておくと、人にとってもAIにとっても読みやすいデータになります。

どの項目を残し、どのステージで何を必須にするかは、業種や営業プロセスによって変わります。汎用的なテンプレートをそのまま使うより、自社の受注の流れに合わせて設計したCRMにAIをつなぐほうが、MCP連携の効果が出やすいと考えています。まずは自社の条件でデータの置き場所を決め、小さな範囲から接続するのが、この章の進め方です。

接続設計の手順｜スモールスタートで段階的に広げる

MCPは接続先を増やすほど便利になりますが、同時に確認すべき権限や失敗の経路も増えます。ここでは、1つの業務から始めて段階的に広げる手順を、各段で次に進む目安とあわせて示します。

4つのステップと次へ進む目安

ステップ	やること	次へ進む目安
1. 対象業務を1つ決める	転記や検索に時間がかかっている業務を1つ選び、使うシステムとデータを書き出す	接続先と扱うオブジェクトの一覧ができている
2. 読み取り専用で接続する	参照だけの権限でつなぎ、検索・要約に使う	AIの回答の根拠になったレコードを人がたどれる
3. 書き込みを限定して開放する	更新は下書きと人の承認を組み合わせて実行する	誤った更新が起きたときの戻し方が決まっている
4. 接続先を追加する	2つ目のシステムをつなぎ、横断する依頼を試す	1つ目の業務が担当者を替えても回っている

各ステップの目安を満たさないまま次へ進むと、問題が起きたときにどの段階が原因かを切り分けにくくなります。目安を満たせない場合は、1つ前のステップに戻り、何が満たせていないかを見て対象業務を絞り直します。例えばステップ2で回答の根拠となるレコードをたどれない回答が続く場合は、参照するオブジェクトを減らすか、CRM側の項目を整理してから再度試します。

運用の例として、商談前の要約を対象業務にする場合は、次のように進められます。ステップ2では、週に1回など決めた頻度で、担当者が要約の根拠レコードを開いて内容と照らし合わせます。ずれが続く場合はステップ3に進まず、参照範囲の見直しを優先します。ずれが少なくなった時点で、次のアクションの下書き作成を、人の承認つきで開放します。

最初の業務の選び方

最初の対象は、「失敗しても影響が小さく、効果が見えやすい業務」が向いています。例えば、商談前に会社の過去のやり取りをまとめる作業は、AIの要約が多少ずれても人が読んで補正でき、時間短縮も実感しやすい業務です。

反対に、請求や契約金額の更新から始めるのはおすすめしません。効果は大きく見えますが、誤りの影響も大きく、検証に時間がかかるためです。

段階的な拡張を「人」ではなく「仕組み」で回す

スモールスタートで作った連携が特定の担当者しか扱えない状態だと、その人が異動した時点で止まります。接続先・権限・承認者・戻し方を1枚の運用ルールにまとめ、新しく担当になった人でも同じ手順で回せるようにしておくことをおすすめします。運用ルールに書けない操作が出てきたら、その操作はまだAIに任せる段階ではないと判断する目安にもなります。

MCPのセキュリティと権限管理の設計

AIエージェントにシステムの操作を任せる以上、認証・権限管理・監査ログの設計は欠かせません。特にプロンプトインジェクションとデータ漏洩の2つのリスクは、接続前に対策を決めておくことが重要です。自社の接続形態に合わせて、必要な対策から順に整えます。

認証方式は接続形態で決まる

MCPでは、サーバーへの接続方法によって認証の考え方が変わります。仕様上も、HTTP経由で接続する場合の認可の枠組みが定められています。（出典：Authorization - Model Context Protocol）

本記事では、判断を次のように整理します。複数人や外部サービスから接続するサーバーは、HTTP経由でOAuthを使う構成を選びます。個人のPCだけで動かす検証用途は、stdioで始めます。stdioで使う場合は、認証情報を設定ファイルに直接書かず、端末ごとに管理された環境変数で渡す運用にしておくと、共有時に流出するリスクを下げられます。

最小権限で始めて棚卸しする

MCPサーバーに渡す認証情報には、その業務に必要な範囲の権限だけを持たせます。例えば会社情報の要約が目的なら、取引の削除や設定変更の権限は不要です。

権限は一度決めたら終わりではありません。接続先を追加するタイミングで、各サーバーに付与している権限を一覧にし、直近の運用で使われていない権限があれば外す、という見直しを手順に組み込んでおくことをおすすめします。接続先を追加しない期間が続く場合も、例えば四半期ごとなど、見直しの時期をあらかじめ決めておくと、権限が広がったまま残ることを防げます。

プロンプトインジェクションとデータ漏洩への備え

プロンプトインジェクションとは、AIが読み込むメールや文書の中に悪意ある指示を紛れ込ませ、意図しない操作をさせる攻撃です。外部から届く問い合わせ文や、第三者が編集できる文書をAIに読ませる構成では、このリスクが高まります。

確認すること	該当する場合の判断	次に設定すること
AIが外部から届いた文章を読むか	読む場合は、同じ会話の中で書き込み系ツールを使わせない	読み取り用と書き込み用で接続を分ける
機密データを扱うサーバーと外部送信できるツールが同時につながるか	つながる場合は、データが外に出る経路がある	外部送信系ツールは人の承認を経てから実行する
誰がいつ何を実行したか追えるか	追えない場合は、書き込みを開放しない	実行ログの保存先と確認担当者を決める

詳しい対策はMCPのセキュリティリスクと対策、組織導入の設計はMCPのエンタープライズ導入ガイドで解説しています。

マルチツール統合の実装パターン

MCPの効果が大きく出やすいのは、CRMだけでなく会計・チャット・ドキュメントを1つのAIから横断して扱うときです。freee・Slack・Google Workspace・Notionとのマルチツール統合により、定型的な確認や下書きの作業をAIエージェントに任せやすくなります。ここでも、自社で使っているツールのうち、1つの業務で必要なものから順に接続します。

CRM×会計（HubSpot×freee）

取引が受注になった後、請求のために同じ情報を会計ソフトへ入力し直している場合、MCPでCRMと会計をつなぐと、受注情報と会計データを照らし合わせる作業をAIに任せられます。例えば「今月受注した取引のうち、会計側に取引先が未登録のものを一覧にして」といった依頼です。

ただし、請求書の発行や金額の確定は、AIの提案を人が確認してから実行する形をおすすめします。会計データは月次の数字に直結するため、AIの役割は不足や不一致の洗い出しまでにとどめ、反映は人が行う線引きが運用しやすいと考えています。

CRM×チャット（Slack）

Slackとつなぐと、チャンネル横断の検索、メッセージ投稿、スレッドの要約をAIから行えます。チャットで交わされた顧客に関する議論を要約し、CRMの記録と並べて確認する、といった使い方です。

投稿系のツールは、誤った内容が社内に広がる経路にもなります。最初は検索と要約だけを有効にし、投稿は特定のチャンネルに限定して開放する進め方をおすすめします。

Google Workspace・Notionとのナレッジ連携

Google WorkspaceではCalendar・Gmail・Sheets・Slidesを、NotionではページやデータベースをAIから扱えます。商談前に予定と過去のメール、社内ナレッジをまとめて確認する、といった横断的な準備に向いています。

MCPとは別の連携方法として、HubSpotの画面上でNotionを直接扱うアプリもあります。次の画面は、HubSpotのレコード画面のサイドバーにNotionページを表示するCRMカードです。

HubSpotのNotionページ閲覧CRMカード（Sync for Notion）

以下の画面は、HubSpotの取引レコードに紐づくNotionのデータベースを表示した連携カードです。

HubSpotデモポータルの取引レコードとNotion DB連携カード（Sync for Notion）

AIに横断検索させたいならMCP、営業担当が日々のCRM画面の中でナレッジを参照したいならCRMカード、というように目的で使い分けると、両者を無理なく組み合わせられます。

StartLinkが開発・提供：NotionとHubSpotを別々に運用していると、顧客情報とナレッジが分断されがちです。StartLinkが開発した連携アプリ「Sync for Notion」なら、HubSpotのCRMサイドバーからNotionのページ・データベースを直接作成・編集・参照でき、コンタクト・会社・取引・チケットに紐づけて一元管理できます。フリープランから試せます。詳しくはSync for Notionをご覧ください。

MCPサーバーの選定と自作の判断

公開されているMCPサーバーは数多くあり、自社の業務に必要なものを選び、複数のサーバーを組み合わせる構成を設計することが実務導入のゴールです。既存のサーバーで足りるのか、自作するべきかを、自社の条件に照らした判断軸で整理します。

既存サーバーを使うか、自作するか

確認すること	既存サーバーを選ぶ	自作を検討する
接続先	提供元が公開しているサーバーがある	社内独自のシステムやデータベース
必要な操作	一般的な検索・作成・更新で足りる	自社固有の業務ルールを処理に組み込みたい
保守体制	提供元の更新に追従するだけで済ませたい	社内にサーバーを保守できる開発者がいる

3つの行のうち「自作を検討する」側に当てはまるものが無ければ、既存サーバーから始めることをおすすめします。自作は自由度が高い一方で、仕様の更新や不具合への対応も自社で抱えることになるためです。まず既存サーバーで小さく始め、足りない操作が具体的に見えた時点で自作を検討する、という順序が進めやすいと考えています。

TypeScript/Python SDKで自作する場合

自作する場合は、公式のTypeScript/Python SDKを使ってサーバーを構築できます。設計の段階で、公開するツールを業務の単位で小さく分け、それぞれに「何をするツールか」が伝わる説明を付けることがポイントになります。AIはツールの説明を読んで呼び出しを判断するため、説明が曖昧だと意図しないツールが選ばれやすくなります。

具体的な実装手順はMCPサーバーを自作する方法で解説しています。

標準化の動向をどう捉えるか

MCPの標準化をめぐっては、OpenAI・Google・Microsoftが参画するAgentic AI Foundationの動きがあります。標準化が進むほど、特定のAIサービスに依存しない接続口として、MCPで作った連携を使い続けやすくなります。

一方で、仕様は更新が続いており、個々のサーバーの対応状況にも差があります。導入時は、利用するサーバーがどの仕様に対応しているかを提供元の情報で見て、運用ルールに記録しておくと、更新時の影響範囲を把握しやすくなります。対応状況が不明なサーバーは、本番の業務に使う前に、読み取り専用の検証環境で動作を確かめてから判断します。

AIと人の役割分担を運用に組み込む

MCPで接続が整っても、AIにどこまで任せるかを決めていなければ、運用は担当者の感覚に依存します。役割の線引きを表にして共有し、誰が担当しても同じ判断ができる状態を目指します。線引きは自社の業務に合わせて決め、運用しながら少しずつ見直します。

AIに任せる処理と人が判断する処理

本記事では、AIの役割をウェブや社内データを調べ、方向性を整理して提案するアシスタントと位置づけ、最終判断は人が持つ形を推奨します。

AIに任せやすい処理	人が判断する処理
問い合わせの分類	パイプラインやライフサイクルステージの定義
レコードや商談履歴の要約	最終的なメール送信の判断
企業情報の調査	大型案件へのアプローチ内容
メールや議事録の下書き	業務ルールの定義とプロンプトの設計
データの不足や不一致の洗い出し	金額・契約に関わる更新の確定

大型案件ほど、AIの調査結果は参考にしつつ、提案や文章は人が組み立てるほうがよいと考えています。

自律実行を避け、承認を挟む

AIがツールを呼び出して外部に何かを送る処理は、送信前に人が内容を見る運用をおすすめします。MCPの仕様でもツール呼び出しを人が拒否できる状態が推奨されているとおり、承認を挟む設計はAI活用を止めるためではなく、安心して範囲を広げるための前提になります。

日本語のビジネス文書を作らせる場合は、丁寧語や社外向けの言い回しのルールをプロンプトに明示しておくと、手直しが減ります。

引き継げる運用にするための記録

連携を担当者個人のノウハウにしないために、次の3点を運用ルールとして残しておくことをおすすめします。

接続しているサーバーと、それぞれに付与している権限
AIに任せる処理と、承認が必要な処理の線引き
誤った操作が起きたときの戻し方と連絡先

この3点が書かれていれば、新しい担当者でも同じ判断で運用を引き継げます。

MCP連携カテゴリの記事一覧

このカテゴリの記事を、目的別に分類しています。自社で先に進めたいテーマに近いグループから読み進めてください。

基礎・比較・標準化

MCPの考え方や、REST APIとの違い、標準化の動きを押さえたい場合は、こちらから読み始めると全体像をつかみやすくなります。

HubSpot・CRM・会計

CRMや会計データをAIから扱う具体的な方法を知りたい場合に向いたグループです。

構築・導入・セキュリティ

サーバーの構築、組織への導入、権限やリスクの設計を進めたい場合に参照するグループです。

業務ツール連携

自社で使っているチャット、ドキュメント、データベース、デザインなどのツールごとに、連携の具体例を確認したい場合のグループです。

よくある質問

Q1. MCP連携は何から読み始めるべきですか？

全体像をつかむなら、まず「MCP vs REST API」で使い分けの考え方を押さえ、次に「MCPサーバーの構築ガイド」「MCPのエンタープライズ導入ガイド」「HubSpot MCP Serverの活用ガイド」の順に読む流れをおすすめします。考え方、実装、導入時の設計、CRMでの具体例と進むため、自社に当てはめやすくなります。

Q2. REST APIで連携済みのシステムも、MCPに置き換えるべきですか？

置き換える必要はありません。毎回同じ手順で動く処理はREST APIやワークフローのまま残し、依頼ごとに参照先が変わる調査・要約・下書きをMCPに任せる組み合わせが運用しやすいと考えています。既存の連携が安定しているなら、それを土台にMCPを追加する形で進めます。その際は、既存の連携が止まっていないかを、MCP追加の前後で見比べて確認すると安心です。

Q3. AIにCRMの更新まで任せても大丈夫ですか？

最初は読み取り専用で始め、更新は下書きを作って人が承認してから反映する形をおすすめします。取引ステージや金額はレポートの数字に直結するため、誤った更新が起きたときの戻し方を決めてから書き込みを開放するのが目安です。

Q4. 関連カテゴリもあわせて読むべきですか？

「AI経営・戦略」「AI実務活用」「AIエージェント運用」もあわせて読むと、MCP連携だけでは補いきれない隣接テーマまで整理できます。カテゴリをまたいで読むことで、導入・運用・組織展開のつながりを把握しやすくなります。

まとめ

MCPは、AIエージェントと外部ツールを標準化されたプロトコルでつなぐ仕組みです。REST APIとの大きな違いはエージェントが自律的にツールを発見・呼び出せる点にあり、手順を書き切れる処理はREST APIやワークフロー、依頼ごとに手順が変わる処理はMCP、という切り分けが選択の基準になります
HubSpot MCP Serverは、コンタクト→取引→顧客→請求の流れのどこでAIを使うかを自社の営業プロセスに合わせて決めてからつなぐと、効果と影響範囲を把握しやすくなります
接続は、対象業務を1つ決め、読み取り専用から始め、書き込みを限定し、接続先を追加する順に、目安を確認しながら小さく広げます
認証・最小権限・実行ログを設計し、プロンプトインジェクションとデータ漏洩への対策を接続前に決めておくことが重要です
freee・Slack・Google Workspace・Notionとのマルチツール統合は、1つの業務で運用が回ってから広げます。既存サーバーで足りるか自作が必要かは、接続先・必要な操作・保守体制の3点で判断します

この記事を読み終えたいま、まずは、転記や検索に時間がかかっている業務を1つ選ぶところから始めてください。

対象業務で使っているシステムとデータを書き出す
読み取り専用の権限でMCPサーバーをつなぎ、検索・要約に使ってみる
接続先・権限・承認者・戻し方を運用ルールにまとめ、次の業務への展開を判断する

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

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

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

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

著者情報

今枝 / Imaeda

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