HubSpotの構築や運用を外注しようとすると、多くの会社が「全部お任せ」か「全部内製」かの二択で考えてしまいます。しかし実際の運用作業を分解してみると、外に出したほうが速くて安全な作業と、外に出した瞬間に壊れはじめる作業がはっきり分かれます。本記事は、この線引きを作業単位で示し、あわせて契約形態と引き継ぎ条件まで具体化するものです。
なお、外注か内製かという判断軸の一般論は「AI導入は外注か内製か」で、支援会社の料金体系と契約形態の全体像は「FDEの料金と契約形態」で扱いました。本記事はHubSpotの構築・運用に限定した具体論です。ライセンス費や必須オンボーディング費を含む導入費用の全体像は「HubSpot導入費用の3層分解」をご覧ください。
〔関連資料〕外注範囲を体制図に落とし込む際は、「HubSpot導入プロジェクト計画テンプレート。費用・期間・体制を着手前に固める」もあわせてご活用いただけます。
公式オンボーディングは「ガイダンス」であり実装代行ではない
最初に、見積もりの前提を誤りやすいポイントを押さえておきます。HubSpotのProfessional以上のプランを契約すると、HubSpot社による公式オンボーディング（導入支援）の購入が必須となりますが、これは設定作業を代行してくれるサービスではありません。
英語版の公式ページには、オンボーディングで提供されるのは戦略面・技術面の「ガイダンス」であり、実行面での追加の支援が必要な場合は認定ソリューションパートナーの起用を推奨する、と明記されています（参照：HubSpot「Marketing Hub Onboarding」(2026年8月時点)）。日本語版のオンボーディング紹介ページでも、提供内容は「技術的なアドバイス」「戦略面のアドバイスと技術的なガイダンス」と一貫して助言型で説明されており、高度なカスタマイズの実践的サポートはソリューションパートナー各社からの提供と整理されています（参照：HubSpot「Service Hubの導入支援」(2026年8月時点)）。
つまり、公式オンボーディングを受けても「手を動かす人」は別に必要です。ここを誤解したまま予算を組むと、契約後に「設定は誰がやるのか」という問題が発覚し、追加の外注費か社内工数が想定外に発生します。外注検討は「公式オンボーディングで足りない実装部分を、誰がどこまで担うか」という問いから始めるのが正確です。
運用作業を10に分解した線引き
「HubSpotの構築・運用」とひとことで言っても、中身は性質の異なる作業の集合です。弊社が構築・運用支援の現場で使っている分解を示します（以下の線引きは弊社の実務知見に基づく見解です）。
| # | 作業 | 推奨 | 理由 |
|---|---|---|---|
| 1 | 初期設計の実装（オブジェクト構成・パイプライン構築） | 外注が合理的 | 設計パターンの引き出しが品質を左右し、初回だけ発生する |
| 2 | データ移行（既存Excel・他CRMのクレンジングと投入） | 外注が合理的 | 重複排除や文字化け対応など技術作業が中心 |
| 3 | 既存システムとのAPI連携・自動化ワークフロー実装 | 外注が合理的 | 専門性が高く、失敗時の影響も大きい |
| 4 | レポート・ダッシュボードの設計と実装 | 外注が合理的 | 集計定義の設計経験がそのまま品質に出る |
| 5 | プロパティ（項目）の意味づけと定義 | 社内が主導 | 「この項目に何を入れるか」は自社の業務そのもの |
| 6 | 取引ステージの定義（各ステージの出入り条件） | 社内が主導 | 営業プロセスの定義を外部に委ねると現場が従わない |
| 7 | 入力ルールの策定と定着運用 | 社内が主導 | 日々の徹底は社内のマネジメントでしか成立しない |
| 8 | メール配信・フォーム作成などの日常運用 | 初期は伴走、段階的に内製へ | 型化しやすく、内製移行の効果が大きい |
| 9 | ユーザー・権限の管理 | 社内で保持（実装支援は可） | アカウント統制は自社ガバナンスの領域 |
| 10 | 定例の運用改善（ボトルネック検知と改修） | 社内と外部の共同 | 数字を読むのは社内、改修の実装は外部が速い |
外注が合理的なのは、専門性が高く、かつ発生が一時的な作業です。逆に5〜7の「項目の意味づけ・ステージ定義・入力ルール」は、外に出すと壊れはじめます（弊社が支援の現場で繰り返し見てきた構図です）。これらは技術作業に見えて、実態は自社の営業プロセスの定義だからです。外部の支援会社がどれほど優秀でも、「商談化の定義は何か」「この項目は誰がいつ入力するのか」を決められるのは自社だけです。ここを丸投げした構築は、リリース直後から現場に使われなくなります。
代行の結果、社内に説明できる人がいなくなる構造
弊社が最も問題だと考えているのは、「全部お任せ」の先にある失敗構造です。構築から運用まで一括で代行に出すと、短期的には楽ですが、1年後に「このレポートの数字の定義を説明できる社員がいない」「項目を1つ足すだけでも外注しないと動けない」という状態になります。経営会議で数字の根拠を問われて誰も答えられなければ、CRMそのものへの信頼が崩れます。これは支援会社の質の問題ではなく、任せる範囲の設計の問題です。上の表で「社内が主導」とした領域だけは、どれほど忙しくても手放さないことをおすすめします（この点は弊社の見解です）。
契約形態は準委任・週次型が合う
外注範囲が決まったら、次は契約形態です。システム開発の外部委託には大きく「請負契約」（成果物の完成に対価を支払う）と「準委任契約」（専門家としての業務遂行に対価を支払う）があり、IPA（情報処理推進機構）が公開する「情報システム・モデル取引・契約書」が両者の使い分けを整理した公的なひな型です（参照：IPA「情報システム・モデル取引・契約書（第二版）」(2020)）。
注目すべきは、そのアジャイル開発版です。IPAは、仮説検証を繰り返しながら仕様を固めていく開発について、「あらかじめ特定した成果物の完成に対して対価を支払う請負契約ではなく、ベンダ企業が専門家として業務を遂行すること自体に対価を支払う準委任契約を前提」とするモデル契約を公開しています（参照：IPA「情報システム・モデル取引・契約書（アジャイル開発版）」(2020)）。
HubSpotの構築はまさにこの性質を持ちます。ステージ定義も項目設計も、実際に運用を始めてから「この定義では現場が回らない」と判明して直すのが普通で、要件が運用開始後に確定していく仕事です。要件を最初に固定する請負契約でこれをやると、変更のたびに追加見積もりが発生し、直したいのに直せない構築になります。弊社が週次の定例で成果を見せながら進める準委任・月額定額型を基本としているのはこのためです（この整理は弊社の見解です。弊社の提供形態はRespectify STUDIOをご覧ください）。
引き継ぎ条件のチェックリスト
最後に、外注する場合に契約前へ確認しておくべき引き継ぎ条件です。支援会社との関係は、いずれ変わります。良い形で内製化するにも、支援会社を切り替えるにも、次の5点が握られているかで難易度がまったく違います（以下は弊社が移管の現場で実際に問題化した点をまとめた実務知見です）。
- スーパー管理者権限の帰属。自社アカウントが常にスーパー管理者を保持していること。支援会社のアカウント経由でしか最上位権限に触れない構成は不可
- 命名規則の共有。プロパティ・ワークフロー・リストの命名規則がドキュメント化され、自社に共有されていること。規則のない大量のワークフローは、引き継いだ側が解読できない
- 設計ドキュメントの納品。オブジェクト構成、ステージ定義と出入り条件、自動化の一覧と依存関係が納品物に含まれること。「HubSpotの画面を見ればわかる」は納品ではない
- 解約時の返却条件。契約終了時に、作成物・カスタムコード・各種資産の所有権と返却手順が契約書に明記されていること
- 属人化の禁止。支援会社側の特定担当者しか触れない領域を作らないこと。定例に自社担当者が同席し、変更内容の説明を受ける運びを契約に組み込む
この5点を初回商談で確認したときの反応は、支援会社の見極めにも使えます。即答できる会社は移管を前提とした健全な設計をしており、言葉を濁す会社は囲い込み型の可能性があります。
まとめ
HubSpotの外注は「全部お任せか、全部内製か」で考えると失敗します。公式オンボーディングはガイダンスであって実装代行ではないという前提に立ち、作業を分解して、初期設計・データ移行・API連携・レポート設計は外部の専門性を使い、項目の意味づけ・ステージ定義・入力ルールは社内が主導する。契約は要件が運用の中で固まっていく性質に合わせて準委任・週次型を選び、権限の帰属とドキュメント納品を含む引き継ぎ条件を契約前に握る。この4点を押さえれば、外注しながら社内に説明できる人が育つ体制を作れます。
自社の場合はどの作業を外に出すべきか判断がつかない、という段階のご相談でも構いません。弊社のRespectify STUDIOでは、週次の定例で進捗と設計意図を共有しながら進める月額定額型の構築・運用支援を提供しています。
外注範囲の線引きを、実際の体制図やスケジュールに落とし込みたい方には、「HubSpot導入プロジェクト計画テンプレート。費用・期間・体制を着手前に固める」もあわせてご活用ください。
個別のご相談は無料相談からお気軽にどうぞ。
