CRMの整備が一段落したお客さまから、次にご相談をいただくのは「レポートは揃ったのに、現場が開いてくれない」という話です。ダッシュボードの設計を見直しても解決しないことが多く、私たちは原因を画面の出来ではなく、朝の動線に置いて考えています。営業が今日どの案件から動くかを決める時間に、集計中心の画面は使われていないためです。今回は、HubSpotのデータはそのままに、Lovableで「今日の順番を決める画面」を1つ足すという打ち手を、接続前に決めておくべき条件まで含めて整理します。
HubSpot Japanが2026年2月27日に発表した第7回「日本の営業に関する意識・実態調査2026」（2025年10月30〜31日実施、売り手1,545名・買い手515名）では、働く時間のうち「無駄だ」と感じる時間があると答えた人に無駄だと思う業務を尋ねた結果、1位が「社内会議」で52.4%、2位が「社内報告業務」で38.3%でした。同調査では、この傾向は2024年の結果と比べて大きな違いがないことも示されています。
それでもレポートを整えるのは、報告のためではなく、現場が判断に使えるようにするためです。ところが商談の進捗を尋ねると「確認して後で連絡します」と返ってくる。共有済みのダッシュボードを開けば分かるはずのことが、その場では答えられない状態になっている——この状況は、報告の仕組みが増えても解消しません。
これはダッシュボードの出来が悪いという話ではありません。全体像をつかむ用途であれば、HubSpotの標準機能で十分です。ただし、ダッシュボードも取引をステージごとに並べたパイプラインの画面も、主役は件数と金額の集計であり、「今日どの案件から動くか」という順番までは出てきません。
足りないのは後者です。そして後者は、会社ごとに並べ方の判断基準が違うため、既製のレポートテンプレートでは合わせきれません。
新しいCRMに入れ替える話ではありません。同じHubSpotのデータを、別の並べ方で見せるだけです。営業チームが毎朝開く画面であれば、次の構成が出発点になります。
全体像をつかむ画面は項目が多くなりますが、今日の順番を決めるだけなら6つで足ります。一覧が優先順位に変わるのは、この絞り込みによってです。マネージャー向けに、メンバーごとの追客が止まっている商談を並べる画面も、同じ発想で作れます。
▲ 毎朝開く想定の商談ボード。期限・今週の判断・停滞の3つに分かれ、行ごとに今日動かす理由が出ます。ステージはその場で変えられ、空の項目には印が付きます。画面のデータは接続前のサンプルです。
朝の商談ボードは、見るための画面で終わりません。「今日この会社に電話する」と決めたら、その場でタスクを作る。次回アクション日や確度が空のままの行には印を出し、気づいた場所でそのまま埋める。入力した内容はHubSpotに反映されます。HubSpotの入力画面と行き来しなくて済むことが、未入力項目の削減に直結します。
従業員1,000名規模で営業拠点が分かれている企業ほど、この効果は運用コストの差として出ます。入力ルールの徹底を目的にした通達やリマインドの運用は、拠点数に比例して負荷が増えますが、入力が必要な場所に印を出す設計であれば、拠点が増えても運用の手数は変わりません。項目が埋まらない問題を「教育とルールの徹底」で解こうとして止まっている組織では、動線側を変えるほうが先に効きます。
Lovableは、日本語で「こういうものが欲しい」と伝えるだけで、画面から裏側のデータベースまでWebアプリを生成できるAIツールです。今回使うのはこのうち画面の部分だけで、並べるデータはHubSpotから読み込みます。商談の正本はHubSpotに置いたままにします。
この構成を選ぶ理由は、ガバナンス上の切り分けが素直になるからです。正本を二重に持たないため、どちらが正しいかという議論が発生しません。画面の並び順や項目は、動くものを見ながら何度でも直せます。
構成は、Lovableで作った画面から、サーバー側の処理を通してHubSpotのデータを読み書きする形になります。責任の線引きは次のとおりです。
業務側で設計し切る必要はありません。むしろ、業務側が「見たい形」を動く画面で提示できる状態にしてから情報システム部門に相談するほうが、要件定義の往復は減ります。文書で要望を伝える進め方では、「どの項目をどの順で見たいか」の認識合わせに時間がかかりますが、動く画面があれば、その場で指差して確認できるためです。
2つ目と3つ目は、一次情報で裏が取れる話です。HubSpot側の接続に使う非公開アプリ（Private App）のアクセストークンについて、HubSpotの公式ドキュメントは必要最小限のスコープのみを付与することを推奨しています。読み取りだけで始める運用は、この推奨に沿った形です。Lovable側についても、公式ドキュメントが、APIキーなどの機密値はSecretsとして保存し、暗号化された状態でサーバー側の関数にのみ渡す設計を示しています。フロントエンドのコードに鍵を書かないことが前提です。
つなぐ先を最初にすべて洗い出す必要はありません。確認が必要になるのは、新しい種類のデータを扱う、HubSpot以外のサービスにつなぐ、公開範囲を広げる、という3つの変更が発生したときです。「増やすときに確認する」と先に決めておけば足ります。接続方式ごとの選択肢と設定手順は、Lovable×HubSpot連携でできること10選で詳しく整理しています。
朝の会議で毎回話題になる商談の条件を、1つ書き出すところから始めてみてください。その条件が、そのまま画面の並び順になります。マーケティングなら今週動かす施策を期限と未着手日数で、カスタマーサクセスなら更新日が近いお客さまを上から、と置き換えても同じように設計できます。
Q1. HubSpotのダッシュボードやカスタムレポートでは実現できないのですか？
全体像の把握であればHubSpotの標準機能で十分です。実現しにくいのは、自社独自の判断基準で行の順番を決め、その行に「今日動かす理由」を添え、同じ画面で入力まで完了させる、という組み合わせです。並び順の基準が会社ごとに異なるため、汎用のレポート機能では合わせきれない部分が残ります。
Q2. 商談データがLovable側に複製されてしまいませんか？
今回の構成では画面の部分だけをLovableで作り、データはHubSpotから読み込みます。正本はHubSpotに置いたままで、画面側にデータを溜めない設計にすることが前提条件です。この方針を最初に決めておけば、データの二重管理は発生しません。
Q3. 情報システム部門への相談は、どの段階で必要ですか？
接続前の試作段階では不要です。サンプルデータで動く画面を作り、並び順と項目を固めるところまでは業務側で進められます。相談が必要になるのは、実際にHubSpotへ接続する段階——APIの鍵の保管場所、書き込み権限の範囲、通信許可の設定を決めるときです。動く画面を持って相談に行くほうが、要件のすり合わせは早く終わります。