昨日のことのように覚えている。HubSpotがクライアントのニーズに対応しきれなくなった瞬間だ。それは2023年のこと、Shoreditchの活気あるテックスタートアップだった。HubSpotを使ったプロジェクトの真っ最中に、クライアント特有のセールスファネルが四角いペグを丸い穴に無理やり入れようとしているのに気付いた。ツールが柔軟性に欠けていたのだ。彼らには何かカスタムなもの、成長に応じて進化するものが必要だった。だから私は頭から飛び込んで、オーダーメイドのCRM開発を始めた。Node.jsからAirtableまで、あらゆるツールを使い、それぞれが手袋のようにぴったり合うように調整した。目からウロコだった。
HubSpotが限界に達した実際の兆候
私が話すほとんどのエージェンシーオーナーは、問題がHubSpotにあることに気づいていません。問題はプロセスか、チームか、データの品質管理だと思っています。ほとんどの場合、そうではありません。
私が注視する兆候は次の通りです：
- セールスチームが、HubSpotが「技術的には」対応しているけれど、実際にはできていないものを追跡するために第二のスプレッドシートを作成している
- HubSpotの階層に支払うのは、実際に使用している1つか2つの機能にアクセスするためだけだ
- 開発者がカスタムコード化されたワークフロー拡張を2つ以上書いている
- HubSpotのネイティブダッシュボードが必要なデータを結合できないため、レポート作成にはGoogle Sheetsへのエクスポートが必要だ
- ピーク時間帯にHubSpotの標準エンドポイントのAPIレート制限に達している
最後のポイントは過小評価されている。2024年中盤、B2Bロジスティクスのクライアントを担当していたが、彼らは1日40,000件以上の連絡先更新をサードパーティ統合経由で実行していた。HubSpotのAPI制限がキューイング遅延を引き起こし、自動化アウトリーチが同期から外れた。彼らはずっと運用チームのせいだと思い込んでいた。問題はプラットフォームにあったのだ。
自分自身に問いかけるべき素直な質問はこれだ：あなたのビジネスロジックをCRMに合わせて曲げているのか、それともCRMがあなたに合わせて曲がっているのか。前者なら、すでに後れを取り始めている。
数字が実際に合う時
カスタムCRMビルドは初期投資が高い。ごまかすつもりはない。スコープが明確で実績のあるチームであれば、複雑さ、統合、モバイルレイヤーを含めるかどうかによって、£25,000から£120,000の範囲になる。
しかしHubSpotのEnterpriseティアは月額£3,600以上だ。年間£43,200で、これはアドオン前、Ops Hub前、別途支払っているサードパーティコネクター前だ。3年で考えると、所有していなく、コアで修正できないプラットフォームに£130,000以上を費やしていることになる。
数字は多くの人が予想するより素早くシフトする。
コード一行目を書く前に、適切なアーキテクチャを選択する
これが最も高くつく失敗を目にする場所だ。アーキテクチャを決めずに構築を始めて、その後6ヶ月間リファクタリングに費やす人たちがいる。Seahawk は 2024年初頭に、クライアントがモノリシックな Laravel 設定で既に CRM の構築を開始していたフィンテック案件を抱えていた。我々が関与する前に、データ関係性についての仮定が3階層深くまで埋め込まれていた。最初の4週間は構築ではなく、それを解きほぐすのに費やした。
最初に重要となるアーキテクチャ上の決定は2つだ。
モノリス vs. サービス指向アーキテクチャ
ある規模未満の CRM 構築(例えば、並行する社内ユーザーが500人未満)では、構造化されたモノリスは今でも完全に問題ない。Rails、Laravel、Django だ。最高の意味で退屈している。素早く動くことができ、機能をシップしている最中にサービス間通信をデバッグするはめにはならない。
サービス指向アーキテクチャは、独立してスケールする必要がある、本当に異なるドメインを持つときに意味をなす。例えば CRM が、顧客向けポータルとリアルタイムデータ、独立した分析エンジン、モバイルアプリを駆動する場合だ。その時点で、関心事を分離することが報われる。
マイクロサービスが最新に聞こえるからといって、誰かに売り込まれてはいけない。£60k かけるべき構築が £25k のモノリスで十分な場合を見すぎている。
リレーショナル vs. ドキュメントストア
CRM データのほとんどは本質的にリレーショナルだ。連絡先は企業を持つ。企業は案件を持つ。案件は活動を持つ。PostgreSQL はこれを異常に良く処理し、JSON サポートは大幅に成熟して、ドキュメントストアの柔軟性を、リレーショナル整合性を放棄することなく得られるようになった。
MongoDB は、連絡先レコードがユーザーベース全体で構造が著しく一貫性を欠く場合に意味をなす。一部のビジネスではこれが実際のシナリオだ。ほとんどの場合、そうではない。
2026年の私のデフォルト：PostgreSQL、他に証明されるまでは常にPostgreSQL。
2026年に実際にお勧めするテックスタック
理論的な答えはここにはありません。これは今、私が実際に構築するものです。
- バックエンド：Node.js with Fastify または Python with FastAPI。具体的にはFastifyはCRMバックエンドでは過小評価されすぎています。Expressより高速で、スキーマ検証が組み込まれており、プラグインエコシステムは2022年以降かなり成熟しています。
- データベース：PostgreSQL 16、Node.jsの場合はPrismaをORM として、Pythonの場合はSQLAlchemy。すべてのためにSQL を手書きしないでください。6ヶ月後に自分自身に感謝するでしょう。
- 認証：Auth0 または Clerk。2026年に認証を自分で構築することは、私が本当に理解できない選択肢です。Clerkは特にマルチテナント組織サポートが最初からあるものには、私の常用選択肢になっています。
- フロントエンド：Next.js 14+ with App Router。サーバーコンポーネントへのシフトは、本当に内部ツールがエンドユーザーにとってどれほど高速に感じるかを変えました。
- メール/通信レイヤー：トランザクショナルメールには Resend、必要に応じてSMSには Twilio。どちらも適切なAPIと妥当なレート制限を備えています。
- バックグラウンドジョブ：Redis上の BullMQ。CRMは多くの非同期作業を行います：同期、スコアリング、リマインダー。信頼できるキューが必要です。
- 検索：フルテキストの連絡先/企業検索がコア機能の場合、Meilisearch を早期に追加してください。自己ホスト可能で、高速で、Elasticsearchを実行するよりもはるかに簡単です。
これは、私が対処するカスタムCRMビルドの85%に対する完全なスタックです。残りの15%はモバイルやリアルタイム要件があり、React NativeやWebSocketsが含まれます。
データ移行：誰もが過小評価するパート
正直に言うと、データ移行はプロジェクトが静かに脱線するところです。ビルドではなく、移行です。
HubSpotから移行する場合、エクスポートは思ったより複雑になると覚悟してください。HubSpotのデータモデルは暗黙的なアソシエーションが多くあります。コンタクトと企業間のアソシエーションはエクスポートCSVでは常にクリーンではありません。カスタムプロパティは表示ラベルと一致しない内部フィールド名で出力されます。ディールステージは数値IDで参照され、手動でクロスリファレンスする必要があります。
中規模のHubSpotインスタンス（例：50,000コンタクト、10,000ディール）の場合、最小でも4週間の専任移行作業を予算化します。これには以下が含まれます：
- すべてのカスタムプロパティを監査およびマッピングする
- トランスフォーメーションスクリプトを作成する（Pythonはこれに優れており、特にpandasは複雑な中間ステップに最適です）
- カットオーバー前に少なくとも2週間並行システムを実行する
- ロールバックを計画する。常にロールバックを計画してください。
並行実行をスキップすると、後悔することになります。私のあるクライアントは金曜日の午後にハードカットオーバーを実行しました。月曜日までに3つのデータ整合性の問題が見つかり、解決に2週間かかりました。本番システムでのことです。そのような人にならないでください。
カスタムビルドで本当に重要な連携
CRMは独立して存在することはない。何かに接続する必要が常にある。統合に時間を費やす主な領域は以下の通りだ。
財務と請求
ほとんどのUKベースのクライアントにはQuickBooksかXeroを使う。どちらも堅牢なAPIを持っている。重要なのは真実の方向性だ。CRMが取引価値の源泉か、それとも会計システムか？どちらかを選べ。明確な権限のない双方向同期は、夜11時にデバッグするのが本当に苦しい競合につながる。
カレンダーとコミュニケーション
Google WorkspaceとMicrosoft 365は必須だ。GoogleのCalendar APIはよく文書化されており信頼できる。Microsoft Graph APIは強力だが習得曲線が急だ。予算は適切に配分せよ。
マーケティングオートメーション
HubSpotの一部、特にマーケティング側を保持しつつ、営業CRMを置き換えたいというのがよくある要望だ。それは完全に有効なハイブリッドアプローチだ。HubSpot APIを使ってコンタクト更新と取引ステージの変更をマーケティングリストに戻す。データコントラクトが明確に定義されている場合はうまく機能する。
ビルド対バイ対ハイブリッド：判断を下す
これは常に聞かれる。普遍的な答えはないが、私が使うフレームワークはある。
購入する対象（HubSpot、Salesforce、Pipedrive）を選ぶべき場合：営業プロセスが比較的標準的で、CRM を使用するチームが 20 人未満であり、数ヶ月ではなく数週間で運用を開始したい場合です。
カスタムビルドを選ぶべき場合：真に独自のデータ関係またはワークフロー ロジックを持っている、社内の独自システムとの深い統合が必要である、または 36 ヶ月間のプラットフォーム コストがビルド見積もりを超えると計算した場合です。
ハイブリッドの場合：HubSpot のようなプラットフォームに付属するマーケティング オートメーションとブランド統合が必要だが、コア CRM ロジックは自分たちが管理できる場所に置く必要がある場合です。これは人々が認めるより一般的です。2025 年に SaaS クライアント向けにこのモデルを運用しましたが、カスタム CRM がすべての取引ロジックと契約管理を処理し、HubSpot はマーケティング ハブのままでした。2 つの間のクリーンな API コントラクト。非常にうまく機能しました。
最悪の結果は、HubSpot が行うことをまったく同じように複製するが、さらに悪い、カスタム CRM を 9 ヶ月かけて構築することです。それは起こります。通常、カスタムビルドの決定が分析的ではなく感情的に下された場合です。
よくある質問
カスタム CRM ビルドは実際にどのくらい時間がかかりますか？
現実的なタイムライン：基本的な連絡先管理、取引追跡、基本的なレポート機能を備えたリーン MVP には、2～3 人のチームでおよそ 10～14 週間かかります。複数の統合、カスタム レポート、モバイル レイヤーを備えたフル機能ビルドは 6～9 ヶ月に達します。複雑なものに対して 4 週間の見積もりを提示する人は、コーナーをカットするか、プロジェクトを適切にスコープしていません。
カスタム CRM をセルフホストしてコストを低く保つことはできますか？
はい、多くのクライアントにとって正しい決定です。Render や DigitalOcean マネージド データベース クラスターのような何かで適切に設定されたセットアップは、インフラストラクチャ コストを予測可能に保ちます。月額 £80 のホスティングで 10,000 人以上の連絡先にサービスを提供している CRM を見てきました。変動コストはサーバー料金ではなく、メンテナンスと更新です。
カスタム CRM を構築するときにチームが犯す最大の失敗は何ですか？
未来の可能性を見据えた構築ではなく、現在の状況に合わせた構築をしているチームを数多く見てきました。AI駆動型のリード スコアリング、予測的なパイプライン予測、フル機能のモバイルアプリなどを設計している一方で、基本的な連絡先の重複排除さえもまだ完成していません。つまらないものから正しく始めるべきです。重複排除、データ検証、監査ログ、ユーザー権限。これらは地味で、絶対に必要不可欠なものです。それ以外はすべてオプションであり、これらが堅牢になるまでは不要です。
HubSpotから本当に移行するのは難しいですか？
ドキュメントの説明より難しく、Salesforceより簡単です。主な摩擦はカスタムプロパティ、ワークフロー ロジック、メール シーケンス履歴です。連絡先とディール データ自体はかなりきれいにエクスポートされます。ワークフロー ロジックで予期しない問題が発生する可能性があるため、対策を講じてください。HubSpot ワークフローには、他の場所に記載されていないビジネス ルールがエンコードされていることが多く、移行の途中になって初めて発見されます。
あのShoreditchプロジェクトを振り返ると、明らかなことがある。既製品のソリューションでは要件を満たさないことがある。カスタムCRM開発は単なる最後の手段ではなく、通常を超えて一歩進む覚悟のある企業にとっての積極的な選択だ。ビジネスが成長すれば、それを支えるツールも成長する必要がある。適切なCRMはあなたの可能性を引き出す鍵になるが、それはあなたのためだけに作られたようなものであるべきだ。そしてときには、袖をまくり上げて一からやり直す必要がある。
関連記事：2026年のAI検索キーワードリサーチ：それは何か、従来型がなぜ、技術的SEO、およびAI検索。