Account Engagement（旧Pardot）からHubSpotへの移行に失敗した話
今回は「Account Engagement（旧Pardot）からHubSpotへの移行に失敗した話」と題して、弊社のツール導入の失敗談をお話しします。
フライクでは、HubSpot（2022〜2023）→Account Engagement（旧Pardot）（2024〜2025年9月）→HubSpot（2025年11月〜）という変遷でマーケティングオートメーションツールを導入しています。
2回目のHubSpot移行では、トップパートナーに依頼したにもかかわらず、Salesforce連携不全・データ移行漏れ・設定ミスとトラブルが続きました。
なぜ、そんなことになったのか。本当の原因はどこにあったのか。
「評判の良いITツールを入れたのに、成果が出ない」
「成果が出ないので違うツールに乗り換えるか、迷っている」
「有名な導入パートナーに頼んだのに、うまくいかなかった」
もし一つでも当てはまるなら、我々の失敗談は他人事ではないかもしれません。
また他のお客様でも同様の失敗が起きないよう、そういった原因の根本を解消すべく、この度フライクはHubSpotパートナーになる決意もしました。
MAやCRMの導入・乗り換えを検討している方、すでに導入したのに成果が出ていない方にこそ読んでほしい内容となっています。ぜひ最後までご覧ください。
第1章 フライクのMAツールの遍歴から学ぶ失敗例
ここではフライクが3年で経験したMAツールの遍歴を、時系列で振り返ります。
何を考えて選び、何でつまずき、何に気づいたのか。失敗の詳細をあえて隠さずに書いていきます。
結論を先に言いますと、「とりあえず」で導入をした瞬間に、お金は溶け始めるということです。
SaaS導入支援を生業にしているフライクが、自社のMA（マーケティングオートメーション）を3年で2回入れ替えて、痛みを伴って学んだ結論です。
①HubSpot期（2022〜2023）：「見やすさと価格」で選んだ最初の一歩
最初にHubSpotを選んだ理由はシンプルでした。見やすさと、価格です。
当時のフライクには、営業とマーケティングの専任担当がいませんでした。
そんな状況で、月額10万円からスタートできるHubSpotは、現実的な選択肢として魅力的だったのです。
導入後の使い方も、メール配信、自社サイトの行動履歴の確認、そこから既存顧客へのアップセル・クロスセル提案に繋げるというような「最低限の使い方」でしたが、それでも十分回っていました。
②Account Engagement期（2024〜2025年9月）：Dreamforceでの感化と、その後の違和感
転機は2023年9月、Salesforceの本拠地でもあるサンフランシスコで開催されたDreamforce 2023への参加でした。
現地でSalesforceの世界観に触れ、「Salesforceと連携できるAccount Engagement（旧Pardot）に移れば、もっと統合的なマーケティング・セールスができるはず」と感じ、移行を決意しました。
しかし、1年以上運用してみると、以下の点にギャップを感じるようになりました。
費用感のギャップ：Account Engagementは月額35万円のプラン。一方でやれることはHubSpotと大きく変わらない
当初の期待が外れた：「Salesforce × Account Engagement だからこそ実現できるAI活用の価値」は、次第に薄れていった
移行を決めた背景には、「Account EngagementとSalesforceに蓄積されるリード・顧客情報を、データ学習×AI活用によって武器にする」という未来像がありました。
ですがChatGPTやClaude Codeをはじめとする生成AIの進化スピードを踏まえると、1つのツール内に閉じたデータ学習を前提とするAI活用は、もはや決定的な差別化要因にはならなかったのです。
「やっぱりHubSpotに戻ろう」と判断したのが、2025年でした。
③HubSpot再移行（2025年7〜10月）：有名パートナーに頼んでも、トラブルは止まらなかった
今回は再移行ということもあり、HubSpotのパートナー制度でトップクラスに位置する有名企業に依頼することを選びました。「トップパートナーであれば、安心して任せられる」と判断したからです。
ですが2回目のHubSpot移行こそ、慎重にいくべきでした。
次のような想定外のトラブルが起きてしまったのです。
Salesforceとの連携が想定通りに動かない：Salesforceのリード・取引先・取引先責任者を残しながらHubSpotと連携させる設定が、何度試しても噛み合わない
データ移行漏れ：移行が完了したと思っていたデータが、後から「実は移っていなかった」と発覚するケースが複数回発生
HubSpot側の設定ミス：プロパティ設計やワークフローで、後から修正が必要な箇所が次々と見つかる。そして考慮漏れも発生し、自社リソースで対応
期間は約4ヶ月。トップパートナーに払った費用は約250万円。
「そこまでの費用を払ったのに、なぜトラブルが発生してしまったのだろう」我々は思案しました。
HubSpotそのものは、本当に良いツールです。直感的なUI、リーズナブルな価格、必要十分な機能。
それなのに初期設定や移行でつまずくと、どんなに良いツールであっても「使えない」という誤った結論になってしまう。
それはあまりにももったいない判断です。
（事実、我々のようにAccount EngagementからHubSpotへの移行で苦戦している会社は、決して少なくないはずです）
そこで我々フライクは「だったら、自分たちがHubSpotのそのパートナーになって、同じように悩んでいるお客様の力になろう」と決意したのです。
④HubSpot再始動（2025年11月〜2026年3月）：自分たちで設計から立て直す
「パートナーに丸投げするのではなく、自分たちでゼロベースで設計からやり直す」
HubSpot営業の言葉を受けて、フライクは方針を切り替えました。
まず、以下の点に着手しました。
ペルソナを再定義：ファネルを設計し直す
ライフサイクルステージを再定義：入力ルール・運用ルールを言語化
地味で時間のかかる作業を、一つずつ積み上げ、その結果HubSpotはようやく「機能するMA」になりました。
具体的に何が変わったのかは、次章以降で詳しく触れたいと思います。
第2章 なぜHubSpot移行は、有名パートナーにお金をかけたのに【失敗】したのか？
第1章では、フライクが3年で経験したMAツール遍歴を時系列で振り返りました。
第2章では、その中でも特に痛みの大きかった「2回目のHubSpot移行」の失敗を、もう少し深く掘り下げます。
予算をかけて、有名パートナーにも依頼したのに、なぜうまくいかなかったのか。
その本当の原因を我々の目線からあらためて問い直そうと思います。
①投資した時間とお金、それでも残ったトラブル
2回目のHubSpot移行で投じたものを整理してみましょう。
期間：約4ヶ月（2025年7〜10月）
費用：HubSpotトップパートナーへの支払い 約250万円
依頼先：HubSpotパートナー制度のトップクラスに位置する有名企業
見ていただいてわかるとおり決して安くない投資です。
社内メンバーの体制としては、代表の大瀧ともう一名という二名体制。
週に1回1時間、パートナーとの定例ミーティングをやりながら随時Slackでの非同期コミュニケーションを実施しました。
期間も、社内リソースの拘束を含めれば事業上の機会損失も無視できない規模でした。
「お金をかけたから安心」「有名なパートナーに頼んだから大丈夫」という前提が、根本から揺らいだ瞬間でした。
②振り返って気づいた「失敗の本質的課題」
冷静に振り返ってみると、移行プロジェクトの各局面で自分たちが下した判断には、ある共通点がありました。
ツール選定の局面：「Account Engagementは合わなかった。やっぱりHubSpotに移行しよう」 → とりあえず、移行する
パートナー選定の局面：「HubSpotのトップパートナーなら、安心して任せられるだろう」 → とりあえず、有名どころに頼む
要件定義の局面：「移行作業はパートナーが進めてくれるはず。こちらは協力すればいい」 → とりあえず、パートナーに任せよう
そう。すべての判断に、「とりあえず」という言葉がついていたのです。
「とりあえず」は、一見すると前向きで、行動的な言葉に聞こえます。「悩むより動こう」「考えるより手を打とう」というニュアンスすらあります。
しかし、実態は逆でした。「とりあえず」は、決めるべきことを決めずに、行動だけを先に走らせる判断だったのです。
③HubSpotパートナーが悪かったわけじゃない
ここまで読んでいただいて察した方もいるかもしれませんが、本質的な
問題は、自分たちがパートナーに渡していた要件そのものにありました。
自社のペルソナはどう定義されているか
ファネルの各ステージはどう動くべきか
ライフサイクルステージは何をもって遷移させるか
どのデータを、どのルールで移行・連携させるか
これらを言語化しないまま、「Account EngagementからHubSpotへ移行してください」とだけ伝えていたのが、今回の失敗を招いた実態でした。
パートナーは「こちらが依頼したことを、技術的に正しく実装する」プロフェッショナルです。
しかし、何を実装すべきかを決めるのは、発注側である私たちの責任です。我々はその責任を、十分に果たしていませんでした。
どんなに優秀なパートナーと伴走しても、設計図のないまま「“とりあえず”移行してください」と頼んだところで“答え”にたどり着くわけがない。
これが、痛みを伴って学んだ“もう一つの真実”でした。
第3章 「とりあえず移行・導入」でお金を溶かすことを食い止める「設計工程」
ここまで読んでいただいた方の中には、「これ、自分の会社（部署）でも起きているかもしれない」と感じた方もいるのではないでしょうか。
フライクで起きた「Account Engagement（旧Pardot）→HubSpot移行における失敗」は、決して特別なものではありません。 むしろ、MAやCRMを導入・乗り換えする多くの会社が、同じ罠にハマっています。
第3章では、そんな「とりあえず」を食い止めるための手段とは何か。フライクが失敗から学び実践したことをここに記します。
①「とりあえず」を食い止めるのは「設計」である
どうすれば「とりあえず」の進行を食い止めることができるのか。
それは、設計をきちんと見直すことです。
ツールを選ぶ前やパートナーに依頼する前のタイミングで以下のことを決めておきましょう。
自社のペルソナとサービスの再定義：自社のサービスは、誰に・何を・どう売るのか？
ファネル設計：案件はどう創出して、どう受注に至るのか？
KPI設計：各ステージの転換率はどう測るのか？
施策マップ：どの施策を、どの優先順位でやるのか？
ツール選定方針：それらを支えるツールは、どう棲み分けるのか？
これらが言語化されていれば、ツール選定もパートナー依頼も、絶対に「とりあえず」では動かなくなります。
「自社にはこの要件があるから、このツールが合う」「この設計を実現できるパートナーはどこか」など、判断軸を持って動けるようになるのです。
② 「設定」に特化したHubSpotパートナーと「設計」を期待したフライクの齟齬
「けどその設計は、誰がやるのか？」当然の問いが浮かぶことでしょう。
実は、ここにもう一つの大きな落とし穴が潜んでいます。
フライクが2回目のHubSpot移行でパートナーに期待していたのは、以下のような領域でした。
要件定義（＝設計）：ペルソナ、ファネル、ライフサイクルステージ、データ移行ルールなどを言語化し、合意形成すること
HubSpot設定：要件定義に基づいて、HubSpotやSalesforceを技術的に正しく設定・構築する業務
つまりフライクは「設計から実装までお願いできる」ことをパートナーに期待していたのです。
ところが多くのHubSpotパートナーは、あくまで「HubSpot設定」のプロフェッショナルということもあり、HubSpotの機能活用、レポートテンプレート、ワークフロー構築といった「実装の話」に特化しているという印象があります。
その結果、何が起きるか。
お互いに「相手がやってくれるはず」のまま、プロジェクトが走り出してしまうことになってしまいました。
③「設計は誰がやるべきなのか」
では、設計は誰がやるべきなのか。選択肢は3つあります。
自社で設計する：理想形。自社のビジネスを一番理解しているのは自社だから。 ただし、マーケティング・セールスの体系的な設計手法がないと、現場の感覚論で終わる。
設定パートナーに丸投げする：一見ラクだが、設計に強いHubSpotパートナーは少ないため、結局「とりあえず」状態に逆戻り。フライクが2回目の移行で踏んだのが、まさにこの轍。
設計と設定を一気通貫で実施できるパートナーと組む：設計工程を専門領域として扱うパートナーに依頼する。設計と設定を両方対応してくれる相手なら、なお良い。
フライクはどうしたかというと、3.設計と設定を一気通貫で実施できるパートナーと組むという選択を取ろうとしました。
ですが、多くのHubSpotパートナーは「設定」に特化している方が多い印象です。
また、マーケティング・セールスの「設計」を専門にするコンサルティング会社は、HubSpotの設定を自社で完結できないことが多く、ましてや「設計」と「設定」ともにこなせるパートナーはごく稀です。
さらに、フライクが直面したように、Salesforceからの移行案件となると、難易度はもう一段上がります。
そこで最終的にフライクが出した結論が、第1章の最後でお話ししたように「自分たちがそのパートナーになろう」でした。
第4章 フライクがHubSpotパートナーになり、「マーケティング・セールス設計」サービスを始めた理由
①「自分たちが理想的なHubSpotパートナーになろう」フライクが踏み込める理由
「設計と設定を一気通貫で」「Salesforce移行にも対応できる」
そんな理想的なパートナーになるのは、簡単なことではありません。それでも、フライクには踏み込める理由がありました。
理由1：SaaS導入支援を生業にしてきた経験
フライクはもともと、Salesforce・Sansan・freee・Boxなど、複数のSaaSを横断的に支援してきた会社です。 HubSpotの構造もSalesforceの構造も、業務レベルで理解しています。だからこそ、両者の違いを踏まえた移行設計ができるのです。
理由2：失敗した当事者である
設計の重要性を、机上の理論ではなく実体験として理解している会社は、そう多くありません。フライクは、3年で2回のMA入れ替えを通じて、設計を抜きにしたツール導入がどれほどコストを溶かすかを身をもって学びました。
そのため「設計を渡せないと何が起きるか」「パートナーに何を求めるべきか」というような「失敗」を当事者として語れることが、フライクの強みになります。
②サービスとして体系化した「マーケティング・セールス設計」
「自社の移行失敗から学んだことを活かせないか」
「フライクと同様の状況に陥ってしまった企業様をなんとか救えないか」
そのような考えから、フライクは新たに「マーケティング・セールス設計」サービスとして体系化しました。
マーケティング・セールス設計：ペルソナ・ファネル・施策優先順位・ツール選定方針までを言語化する
マーケティング・セールス × システム設計：設計をHubSpotやSalesforce上で実現できる形に落とし込む
システム導入：設計通りに動く状態まで、ツールを構築・実装する
マーケティング・セールス伴走支援：導入後、現場で成果が出るまで継続的に伴走する
特にこだわっているのは、「Step1から始める」ことです。
多くの会社がいきなりStep3（システム導入）から始めて失敗します。（我々がまさにそうでした）
その失敗から得た学びを、新たなサービスとして次の会社に届けることにしたのです。
おわりに： 「失敗を、誰かの財産に変えるために」
フライクが3年で約250万円と4ヶ月を費やしたMAツール入れ替えの旅は、 むしろSaaS導入支援を生業にする会社として、本来は隠したい話です。
ですが失敗を一人で抱え込んでも、誰の役にも立ちません。でも、共有すれば、次に同じ道を歩む人の道標になれるかもしれない。それが、この記事を書いた理由です。
ツールを変えても、パートナーを変えても、設計が抜け落ちている限り、同じ失敗を繰り返します。逆に、設計さえ整えば、ツールは本来の力を発揮し、パートナーは本領を発揮してくれます。
フライクは、自分たちの痛みを「マーケティング・セールス設計」というサービスに変えました。「ツール導入の前に立ち止まって、本当に必要な設計を一緒に作る」——それが、私たちが届けたい価値です。
そして、もう一つ大事なことを書かせてください。
HubSpotは、本当に良いツールです。
Salesforceも、Account Engagementも、それぞれに価値があります。問題はツールではなく、設計の有無です。良いツールを「使えないツール」にしないために、私たちは設計から伴走します。
この記事を読んでいる方の中には、フライクと同じつまずきを経験した（あるいは今まさにしている）方もいらっしゃるでしょう。
ツールを変える前に、パートナーを変える前に、まずは設計から見直しませんか？
フライクが届けたいのは、ツール導入の前に立ち止まって考える時間です。設計から始めれば、お金を溶かさずに、本当に成果が出るマーケティング・セールスを作ることができます。
自社で痛みを伴って学んだ「設計から始める」を、同じ罠にハマっている会社に届けるためのサービスを用意しています。
「うちの場合はどうだろう？」と感じた方は、ぜひお気軽にお問い合わせください。まずは現状の課題ヒアリングから、お話ししましょう。
次に同じ道を歩む人を、一人でも減らせたら。それが、私たちの願いです。
▼「無償60分相談会」のお申込はこちら
https://meetings-na2.hubspot.com/ohtaki
