建設業のCRM活用ガイド｜元請・協力会社・現場をHubSpotでどう管理するか

「営業支援ツールを入れたが、結局は工事台帳のExcelを見ている」「見積を出した案件のその後が、担当者に聞かないと分からない」——建設業でCRM導入を検討されている方から、こうしたご相談をいただくことがあります。

建設業のCRMとは、発注者・元請・協力会社・現場という複数の登場人物と、引合から施工・検収・請求までの長い時間軸を、1つのデータ構造の上に載せる仕組みのことです。他業種のCRMと決定的に違うのは、受注してからが長く、しかも受注後の主役が営業から工事部門に移る点にあります。ここを設計に織り込まないまま導入すると、営業だけが入力し、工事が始まった瞬間に情報が止まります。

この記事では、建設業でCRMを設計・運用するときの型を整理します。「CRMを入れれば見える化できます」で終わらせず、CRMでやらないほうがいい領域まで正直にお伝えします。

建設会社・工事会社で営業管理やDX推進を担当されている方、施工管理システムとは別に営業側の仕組みを整えたい方に向けた内容です。次の4点がわかります。

• 登場人物をどのオブジェクトに持つか ── 発注者・設計事務所・協力会社を会社オブジェクトでどう区別し、現場をどこに置くかの判断軸を示します
• なぜパイプラインを1本にしてはいけないのか ── 引合〜受注と施工〜検収では管理したい情報も担当部門も違うためです
• 出来高請求と原価を、どこまでCRMで持つか ── 会計・原価管理システムとの線引きをはっきりさせます
• 現場に入力してもらうための設計 ── 項目を減らし、入力の入口を決めることが定着の分かれ目です

読み終える頃には、自社の建設業務のどこをCRMに載せ、どこを既存システムに残すかの判断軸が固まるはずです。ぜひ最後までご確認ください。

建設業でCRMが定着しない3つの構造的な理由

まず、なぜ建設業でCRM導入がうまくいかないことがあるのかを整理します。ツールの機能不足ではなく、業務構造とCRMの標準的な想定がずれていることが原因です。

理由1：案件の起点が1つではない

一般的なBtoB営業では、問い合わせや商談から案件が生まれます。建設業では、指名で声がかかる、既存の元請から下請けとして依頼が来る、設計事務所経由で図面が回ってくる、入札情報から拾う、といった複数の入口が並存します。入口ごとに必要な情報も勝ち筋も違うため、1つのフォームと1つのステージ設計で受け止めようとすると、どの入口の実態も表現できないという状態になります。

理由2：受注後の期間が長く、主役が変わる

受注してから引渡しまで数か月から数年かかることが珍しくありません。この間、案件の主担当は営業から工事部門へ移ります。CRMを「営業が使うもの」と定義してしまうと、受注した瞬間に更新が止まり、翌年の追加工事や改修の提案時に何も情報が残っていないことになります。

理由3：会社の数だけ台帳がある

工事台帳、原価管理表、協力会社名簿、安全書類、見積控え。建設業では業務ごとに台帳が育っており、それぞれに正しい理由があります。CRMを入れるときに「全部を1か所に」と考えると、既存台帳の作り直しになり、プロジェクトが止まります。CRMに載せるのは「関係者と案件の進行」であり、原価や施工の詳細は既存システムに残すという線引きが現実的です。

なお、業界全体の許可業者数は483,823業者（2026年3月末時点、国土交通省「建設業許可業者数調査の結果について」2026年5月15日発表 2026年8月1日確認）とされ、その多くを中小規模の事業者が占めます。大掛かりな基幹システムの入れ替えではなく、既存の台帳を残したまま関係性と進行だけを可視化する進め方が、現実的な選択肢になりやすい環境です。DXの全体像は建設業のDX実践ガイドでも整理しています。

建設業のCRMに登場する「人・組織・現場」をどう持つか

ここからは具体的なデータ構造に入ります。まず全体像を図で示します。

これは特定の企業の実装ではなく、建設業でよく出てくる要素を一般化した設計例です。HubSpotの標準機能とカスタムオブジェクトで組める構成として整理しています。

発注者・元請・協力会社は同じ「会社」オブジェクトに入れる

最初に迷いやすいのが、発注者・元請・協力会社を別々の入れ物にするかどうかです。結論としては、すべて会社オブジェクトに入れ、役割はプロパティーと関連付けラベルで表現する方法をおすすめします。

理由は単純で、同じ会社が案件によって役割を変えるためです。ある現場では元請として発注してくる会社が、別の現場では自社が元請となり協力会社として入ってもらうことがあります。役割を入れ物（オブジェクト）で分けると、その会社のレコードが2つできてしまい、与信情報も担当者も二重管理になります。

役割を関連付けのラベルで持つ方式であれば、会社のレコードは1つのまま、案件ごとに「発注者」「元請」「一次下請」「設計」といった立場を表現できます。関連付けラベルの利用にはProfessional以上のサブスクリプションが必要とされています（HubSpotナレッジベース「レコードを関連付ける」 2026年8月1日確認）。

現場（物件・工事場所）はどこに置くか

建設業のCRMで判断が分かれるのが、現場をどう持つかです。判断の起点は「同じ場所で複数の案件が発生するか」です。

同じ判断の考え方は不動産CRMのデータ設計でも解説しています。物件を独立したレコードにするか顧客の属性にするかという論点は、業種が違っても構造が同じです。

なお、カスタムオブジェクトはMarketing Hub / Sales Hub / Service Hub / Data Hub / Content Hub の各Enterprise、および Smart CRM Enterprise・Revenue Hub Enterprise で利用できる機能とされています（HubSpotナレッジベース「カスタムオブジェクトを作成する」 2026年8月1日確認）。Professionalプランでは使えないため、現場を独立させたい場合はプランの前提から確認が必要です。使うべきかどうかの判断軸はカスタムオブジェクトを使うべきかの判断で整理しています。

職人・担当者はコンタクトで十分か

現場代理人、監理技術者、協力会社の職長といった個人は、コンタクトとして持ちます。ここで無理をして「資格」「保有免許」「安全書類の有効期限」まで持たせようとすると、更新されずに形骸化しがちです。安全書類や資格管理は専用システムの領域であり、CRMには「誰が窓口で、どの会社に所属しているか」までを持たせる割り切りが続きます。

パイプラインは「引合」と「施工」の2本に分ける

建設業のCRM設計で最も効果が出やすいのが、パイプラインの分割です。

1本にまとめると何が起きるか

引合から検収までを1本のパイプラインに詰め込むと、ステージ数が15前後に膨らみます。すると3つの問題が同時に起きます。1つ目は、営業のヨミと工事の進捗が同じ軸に並ぶため、受注確度のレポートが施工中の案件で埋まってしまうことです。2つ目は、部門ごとに見たいステージが違うのにボードが共通になり、どちらの部門にとっても情報が多すぎる画面になることです。3つ目は、失注と工事中止が同じ「クローズ（失注）」に集約され、原因分析ができなくなることです。

分けたときの役割分担

受注ステージに到達したタイミングで施工側の取引を自動生成し、会社・コンタクト・現場の関連付けを引き継ぐ設計にすると、工事部門が改めて入力する手間がなくなります。ステージ設計の具体は工事案件のパイプライン設計で詳しく扱っています。

公共工事と民間工事を分けるかどうか

公共工事と民間工事では、案件の入口（入札公告か指名か）も、意思決定のプロセスも、必要な書類も違います。ただし、最初から分けることをおすすめするわけではありません。公共の比率が全体の1〜2割程度であれば、まずは1本の引合パイプラインで運用し、取引のプロパティーで区別するほうが管理が軽くなります。パイプラインを増やすと、ビューもレポートも権限も増えるためです。分ける判断は、ステージの定義そのものが噛み合わなくなってからで間に合います。

判断の目安としては、「同じステージ名で両方の実態を説明できるか」を確認します。たとえば「見積提出」は民間なら提出日で判定できますが、公共では応札という別の行為になります。ここで説明に無理が出てきたら、分ける時期です。逆に、応札も見積提出の一種として扱えるうちは、プロパティーでの区別で足ります。

既存システムとの役割分担を3つの層で決める

建設業では、CRMを入れる前から複数のシステムが動いています。ここで役割分担を決めずに導入すると、「どこを見ればいいか分からない」という状態が新たに生まれます。

関係性の層はCRMが正、実行の層は既存システムが正。案件進行の層だけが両者にまたがるため、ここの線引きを明文化しておくことが要点です。

リンクで済ませる判断

施工管理システムの案件ページや、共有ストレージのフォルダを、CRMの取引レコードにURLとして持たせるだけでも実用性は大きく変わります。データを同期させるより先に、「その案件の資料はここ」という導線を1本作るほうが、投入する労力に対する効果が高い場面が多くあります。連携の作り込みは、運用が固まってからでも遅くありません。

連携を作るなら「片方向・最小項目」から

双方向の同期は、更新の衝突とループの設計が必要になり、構築も運用も重くなります。まずは「CRMの受注情報を施工管理システムへ渡す」といった片方向・最小項目から始め、必要が明確になったときに広げる。この順序であれば、途中で止めても損失が小さく済みます。

見積・出来高・請求をどこまでCRMで持つか

建設業のCRMで最も相談が多いのが、お金まわりの線引きです。ここは欲張らないほうが結果的にうまくいきます。

CRMに載せるもの、載せないもの

考え方はシンプルで、「営業と経営の意思決定に使う数字」はCRM、「会計上の正となる数字」は既存システムです。CRMを会計の代わりにしようとすると、必ずどちらかが腐ります。会計側との接続方法はCRMと会計システムの連携設計で整理しています。

出来高請求は「請求予定」として持つ

建設業では、契約金額を着手金・中間金・完成時といった複数回に分けて請求します。この分割を取引の金額欄1つで表現しようとすると破綻します。商品項目（ラインアイテム）を請求回ごとに作り、それぞれに請求予定日を持たせる方式であれば、「今月いくら請求予定か」「請求済みなのに入金がない案件はどれか」が1つのレポートで出せます。

ここまでできると、工事部門が把握している出来高と、経理が把握している請求実績のズレが早い段階で見えるようになります。属人的な確認作業が減り、担当者が異動しても同じ画面で引き継げる状態になります。

協力会社ネットワークをCRMで管理する

もう1つ、建設業ならではの使い方が協力会社の管理です。営業先だけでなく、発注先も同じCRMで管理する発想です。

何を持つと役に立つか

協力会社のレコードに持たせて実際に使われるのは、対応可能な工種、対応エリア、稼働可能な時期、直近で一緒にやった現場、単価水準の目安、といった「次に誰へ声をかけるか」を決めるための情報です。逆に、契約書の細目や安全書類の管理をCRMに載せると更新されません。

使われる形にするには一覧ビューを先に決める

協力会社の情報は、レコードを作った瞬間ではなく「探すとき」に価値が出ます。したがって、プロパティーを決める前に「工種×エリアで絞り込んだ一覧」「直近1年で発注実績のある会社」といった見たい一覧を先に決めてしまうほうが、必要な項目が明確になります。プロパティーの決め方はプロパティー設計のベストプラクティスで詳しく扱っています。

発注実績を関連付けから読む

協力会社レコードに「今年の発注額」を手入力すると、必ず更新が止まります。施工側の取引に協力会社を関連付けておけば、その会社に紐づく取引を集計するだけで実績が読めます。手で入れる数字を減らすことが、そのまま情報の鮮度につながるという関係です。

経営が見たい数字から逆算する

ここまでのデータ構造は、最終的にレポートで使われて初めて意味を持ちます。順序としては、レポート要件を先に決めるほうが手戻りが減ります。

まず「毎月の会議で見たい数字」を書き出す

建設業の経営会議でよく出てくるのは、次のような数字です。

この表の右列が、そのままプロパティー設計の要件になります。逆に、項目から考え始めると「あったほうがいいかもしれない」という理由で増え続け、入力されないまま残ります。

集計軸になる項目は必ず選択肢型で持つ

工種やエリアをテキストで入力してもらうと、表記揺れで集計できません。「内装」「内装工事」「内装仕上」が別物として数えられます。集計に使う項目は最初から選択肢型（ドロップダウン）にしておくことをおすすめします。

なお、HubSpotのプロパティーはフィールドタイプの変更に制約があり、後から自由に変えられるわけではありません。集計軸に使う項目の型だけは、最初に決めておく価値があります。

現場に入力してもらうための設計

どれだけ設計が正しくても、入力されなければ意味がありません。建設業は現場作業が中心で、パソコンの前にいる時間が短い職種が多いという前提があります。

入力項目は「レポートに使うもの」だけに絞る

現場に依頼する入力項目は、多くても5〜6項目が現実的な上限です。ステージの移動、出来高の割合、次回訪問予定、特記事項。この程度に絞ったうえで、残りは営業や工務がまとめて入れる分担にします。入力してもらう人と、活用する人を分けて考えることが結構ミソになってきます。

入力の「入口」を先に決める

もう1つ重要なのが、そのレコードは誰がどこで作るのかという点です。引合はメールで来るのか電話なのか、現場からの報告はスマートフォンなのか事務所での代理入力なのか。きれいな設計図があっても、入口が決まっていなければ中身は入りません。まずは入口を1つに固定し、慣れてから増やすほうが定着します。

段階的に広げる

一度にすべてを載せようとすると、初期構築だけで長期化します。現実的には次の順序です。

第1段階だけでも、営業会議の資料作成が不要になるという効果は出ます。まず1本の線を通し、動き始めてから広げる進め方が、結局いちばん現場に残ります。

建設業でAIをどこまで使えるか

HubSpotのAI機能についても触れておきます。2026年時点で建設業の実務に効きやすいのは、次の3つの領域です。

第一に、引合メールの内容から必要情報を抽出し、レコードに整える作業です。図面や仕様書のやり取りが多い業種では、メール本文からの転記だけでかなりの時間が使われています。第二に、打ち合わせ記録の要約とタスク化です。第三に、発注者や元請の企業情報のリサーチです。

HubSpotでは、既成のエージェントとカスタムエージェント、エージェント型ワークフローを一か所で管理する「Agent Hub」が提供されており、Marketing Hub / Sales Hub / Service Hub / Data Hub / Content Hub / Smart CRM の Professional・Enterprise で利用できるとされています（HubSpotナレッジベース「Agent Hubについて理解する」 2026年8月1日確認）。

一方で、正直にお伝えしたい限界もあります。積算の判断、工程の組み替え、安全管理といった建設業の中核業務は、現時点でAIに任せられる領域ではありません。AIが効くのは「記録と整理」であり、「判断」ではないというのが実務での実感です。判断の材料が揃っていない状態でAIを入れても、出てくるのは整った形式の空振りです。AIの前提として、まずデータが1か所に集まっている状態を作るほうが先です。HubSpotのAI全体像はAgent Hubの全体像で扱っています。

よくある質問

建設業のCRM設計について、ご相談の場でよくいただく質問をまとめました。

Q1. 施工管理システムを使っています。CRMは別に必要ですか。

目的が違うため、併用が前提になります。施工管理システムは受注後の工程・原価・写真・書類を扱うのに対し、CRMは受注前の引合と、顧客・協力会社との関係性を扱います。施工管理システムだけでは「見積を出したが受注に至らなかった案件」の記録が残らず、翌年の提案につながりません。逆にCRMで工程管理をしようとすると機能が足りません。連携させる場合も、まずはどちらを正とするかを先に決めることをおすすめします。

Q2. 元請と協力会社を同じ会社オブジェクトに入れると混ざりませんか。

一覧ビューとプロパティーで区別できるため、実務上は混ざりません。会社レコードに「取引区分」のような選択肢型プロパティーを1つ持たせ、案件ごとの立場は関連付けラベルで表現する方式が扱いやすいです。むしろオブジェクトを分けると、同じ会社が両方の顔を持つときにレコードが重複し、名寄せの手間が増えます。

Q3. 引合と施工でパイプラインを分けると、二重入力になりませんか。

ワークフローで受注時に施工側の取引を自動作成し、会社・コンタクト・現場の関連付けと必要なプロパティーを引き継げば、手入力は発生しません。むしろ1本にまとめたほうが、営業に不要な工程ステージ、工事に不要な確度プロパティーが両方の画面に出続けることになります。

Q4. 公共工事の入札情報をCRMで管理できますか。

案件としての管理はできます。入札公告から拾った案件を引合パイプラインの最初のステージに登録し、参加可否の判断・積算・応札までを進捗として持つ形です。ただし、入札情報そのものの収集や、電子入札システムとの連携はCRMの守備範囲外です。情報収集は専用サービスや官公庁サイトで行い、CRMには「参加を検討する案件」だけを登録するのが現実的です。

Q5. どのプランから始めるべきですか。

現場をカスタムオブジェクトで独立させる必要があるかどうかで変わります。現場を取引のプロパティーで持つ設計であれば、Professionalの範囲で引合と施工の2本のパイプライン、関連付けラベル、ワークフローによる自動生成まで組めます。改修・保守で同じ現場に何度も案件が発生する業態であれば、カスタムオブジェクトが使えるEnterpriseが前提になります。判断の順序としては、プランから決めるのではなく、必要なデータ構造を先に描いてから必要なプランを確認するほうが失敗しません。

まとめ

建設業のCRMは、営業案件だけを載せても続きません。要点を整理します。

• 定着しない原因は機能不足ではなく構造のずれ。案件の入口が複数あり、受注後に主役が変わり、既に台帳が育っているという3点を前提に設計する必要があります
• 発注者・元請・協力会社は同じ会社オブジェクトに入れる。役割はオブジェクトではなく関連付けラベルで表現すると、レコードの重複を避けられます
• パイプラインは引合と施工の2本に分ける。管理したい情報も担当部門も違うため、1本にまとめるとどちらの部門にも使えない画面になります
• お金は「意思決定に使う数字」だけCRMに持つ。積算ロジックと会計の正は既存システムに残すのが現実的です
• 入力項目は5〜6項目に絞り、入口を先に決める。設計図がきれいでも、入口が決まっていなければ中身は入りません

最初の一歩としておすすめしたいのは、「直近1年の引合を10件書き出し、どこから来て、誰が判断し、なぜ決まった（決まらなかった）かを並べてみる」ことです。入口の種類と、意思決定の関係者と、失注の理由がその10件に凝縮されています。そこから必要なステージとプロパティーを逆算すると、他社の設計を借りてくるより自社に合ったものになります。

そのうえで、まずは会社・コンタクト・引合パイプラインの3つで1本の線を通し、動き始めてから施工パイプラインと協力会社ネットワークを足していく。この段階的な進め方が現場に残ります。

自社の工事案件や協力会社の管理をどう設計するか具体的に検討したい場合は、StartLinkの無料相談でご相談ください。現状の運用をうかがったうえで、設計の方向性をご提案します。