HubSpotを使い込んでいる企業ほど、必ず同じ壁に突き当たります。「標準機能では、ここから先が作れない」という壁です。
顧客ごとにカスタマイズされたポータル画面。自社独自の切り口の営業ダッシュボード。リード獲得を目的とした診断ツール。いずれもCRMのデータを使う話でありながら、HubSpotの標準機能の範囲外にあります。従来はここで開発会社に見積もりを取り、数百万円と数か月の見積書を見て断念する——というのが定番の流れでした。
この「あと一歩」を埋める選択肢として現実味を帯びてきたのが、LovableのようなAIアプリビルダーとHubSpotの連携です。LovableはHubSpot向けの公式コネクターを提供しており、コンタクト・会社・取引・チケットの読み書きが可能です。
本記事では、実際に何が作れるのかを10パターンに整理したうえで、多くの解説記事が触れていない「接続方式による制約の違い」と「鍵の取扱い」まで踏み込みます。ここを理解せずに作り始めると、動くけれど情報システム部門の審査を通らないアプリができあがります。
Lovableの基礎は「Lovableとは？」、操作手順は「Lovableの使い方を6ステップで解説」、費用は「Lovableの料金はいくら？」をあわせてご覧ください。
目次
ここが最初の分岐点です。Lovableのコネクター仕様では、接続方式が3つに分かれており、「誰のアカウント権限で繋がるか」が決定的に異なります。
| 接続方式 | 認証 | 権限の主体 | 公開アプリに含まれるか | 向く用途 |
|---|---|---|---|---|
| App＋チャットコネクター | サービスキー | 共有アカウント（全員同一） | 含まれる | リード登録、顧客ポータル、社内ツール |
| アプリユーザーコネクター | OAuth（各ユーザー） | ログインした本人の権限 | 含まれる | 営業個人向けダッシュボード |
| チャットコネクター（MCP） | MCPサーバー | 開発者個人 | 含まれない | 開発時の参照のみ |
とくに重要なのがアプリユーザーコネクターです。Lovableの公式ブログによれば、この方式ではエンドユーザーがHubSpotの画面で自分でサインインして許可を与えるため、HubSpot側の既存権限がそのまま維持されます。「元のツールで見られるレコードはアプリでも見られ、見られないものは見られない」——公式はこう説明しています。パスワードを共有せず、認証情報をアプリ側に保存しない設計です。
営業担当ごとに見えるデータを変えたいなら、この方式一択です。逆に、共有アカウント方式（サービスキー）でこれをやろうとすると、アプリ側で権限制御を自作することになり、事故の温床になります。
チャットコネクター（MCPサーバー）は、公開アプリには含まれず、開発時にAIへコンテキストを与えるだけの仕組みです。HubSpotも公式のMCPサーバーを提供しています。
用途を誤解しやすいので明確にしておくと、これは「作ったアプリがHubSpotと繋がる」ためのものではなく、「作っている最中のAIが、自社のHubSpotの構造を理解する」ためのものです。カスタムプロパティの命名やパイプラインの段階名をAIが把握した状態で開発できるため、指示の精度が上がります。
Lovableの公式ドキュメントによれば、HubSpotコネクターの認証にはサービスキーを使います。これはHubSpotが提供する新しい認証方式で、HubSpot開発者ドキュメントでは「CLIツールや本格的な開発者プラットフォームアプリなしに、REST APIを直接呼び出すための認証情報」と説明されています。
重要な注意点として、サービスキーは2026年8月時点でパブリックベータです（2026年2月10日にベータ提供開始）。仕様変更の可能性があるため、基幹に関わる連携を組む場合はこの点を関係者に共有しておくべきです。
ICP（理想顧客像）の明確な企業ほど効果が高いのがこのパターンです。「CRM移行コストシミュレーター」「自社のデータ基盤成熟度診断」のようなツールをLovableで作り、診断結果の表示と同時にContacts APIでCRMへ登録します。
ここでの本質的な価値は、リード獲得数ではなく獲得したリードに付随する情報量です。従来のホワイトペーパーダウンロードで得られるのは名前と会社名だけですが、診断ツールなら「どの設問にどう答えたか」がカスタムプロパティとして丸ごとCRMに入ります。営業が初回接触の時点で、相手の課題認識を把握した状態で臨める。「資料請求＝営業電話」と警戒する層に対して、個人情報を渡す前に価値を提供できる点も大きな利点です。
「選択内容によって次の質問が変わる」「途中保存して後で再開できる」「入力内容をリアルタイムに検算して見積額を表示する」——こうした条件分岐や動的計算を伴うフローは、標準フォームの守備範囲外です。Lovableで画面を作り、確定した内容だけをCRMへ書き込む構成にすれば、UXを損なわずにデータの一元管理を維持できます。
申込受付、リマインド対象の抽出、当日の受付チェックイン、参加実績のCRM書き戻しまでを1つのアプリにまとめます。とくに当日の受付画面は既製ツールと相性が悪く、Excelでの手作業に逆戻りしがちな領域です。参加実績がコンタクトのプロパティとして即時に反映されれば、翌日のフォロー対象抽出が自動化できます。
HubSpotのレポート機能は強力ですが、「自社独自の指標を、自社独自の並べ方で、経営会議の資料そのままの形で見たい」という要求には応えきれません。Deals APIやCompanies APIで取引データを取得し、必要な集計と可視化を自作すれば、この隙間が埋まります。
このパターンではアプリユーザーコネクター（OAuth）を推奨します。各営業担当が自分の権限でログインすれば、他人の案件が見えてしまう事故を構造的に防げるためです。
商談前に顧客へ送るヒアリングシートをLovableで作り、回答内容を該当する取引（Deal）のプロパティへ書き戻します。営業がメールの本文から情報を転記する手間がなくなるだけでなく、ヒアリング項目が構造化データとしてCRMに蓄積される点が本質です。半年後に「失注案件に共通する事前条件」を分析できるようになります。
会社情報と取引内容を読み出し、自社フォーマットの提案書ドラフトを生成するツールです。Lovableのアプリ内からAIモデルを呼び出す構成にすれば、過去の類似案件を踏まえた文面生成も可能です。ただしアプリ内AI機能はクレジットを追加消費するため、利用頻度から費用を試算してから実装してください（料金の詳細）。
取引状況、契約内容、進行中のプロジェクトの進捗、過去の問い合わせ履歴を顧客自身が確認できるポータルです。BtoBの継続取引において、「今どうなっていますか」という問い合わせの多くは、可視化されていないことが原因で発生します。
このパターンは10選の中で最も慎重な設計を要します。他社の情報が見えてしまえば重大インシデントです。ログイン認証は必須で、行レベルセキュリティ（RLS）の設定と、別アカウントでの実地検証を公開フローに組み込んでください。
Tickets APIを使い、自社の問い合わせ分類・優先度判定ロジックに沿った受付画面を作ります。製品型番の選択、エラーコードの入力、写真の添付といった業種固有の受付項目を持たせつつ、データはHubSpot側で一元管理する構成です。
地味ですが、ICP-A層の企業に最も効くのがこれです。表記ゆれ（「株式会社○○」と「(株)○○」）、重複レコード、必須項目の欠損、更新が止まっているレコード——こうしたデータ品質の問題を検出し、一覧で確認して一括修正するツールです。
AI活用の前提は綺麗なデータ基盤（SSOT）ですが、「掃除する道具」がないために手作業のExcel突合が続いている企業は少なくありません。この用途は社内限定公開で運用できる社内ツールであり、リスクが限定的なため、最初のPoCとして最も推奨できます。
HubSpotのUI ExtensionsおよびCRMカードには、外部URLをモーダル内のiframeとして開くアクションが用意されています。これを使えば、コンタクトや取引のレコード画面から、Lovableで作ったツールを直接起動できます。
ただしここには重要な制約があります。HubSpot公式ドキュメントによれば、サービスキーはUI Extensions内での呼び出しには使用できません。カード側はHubSpotの開発者プラットフォームで別途構築する必要があり、Lovableは「iframeで呼ばれる側」に徹する形になります。10選の中で唯一、エンジニアの関与が前提になるパターンです。
App＋チャットコネクター方式の場合、Lovable公式ドキュメントに記載されている手順は次のとおりです。前提として、HubSpot側でスーパー管理者または開発者ツールへのアクセス権、Lovable側でワークスペース管理者またはオーナー権限が必要です。
crm.objects.contacts.read / crm.objects.contacts.write）手順自体は10分程度で完了します。時間をかけるべきは手順ではなくスコープの設計です。「とりあえず全部にチェック」で進めた連携は、後から権限を絞ろうとしても、どの機能がどのスコープに依存しているか分からなくなり、実質的に絞れなくなります。
これが最重要です。Lovableで作るアプリはフロントエンド中心の構成になりやすく、何も考えずに実装するとAPIキーがブラウザから読める場所に置かれる危険があります。サービスキーが漏れれば、付与したスコープの範囲でCRMデータが第三者に読み書きされます。
対策は明確です。HubSpotへのAPI呼び出しは必ずサーバーサイド（LovableのCloudが提供する関数）経由で行い、鍵はシークレットとして管理すること。ブラウザ側のコードに鍵を含めない。この原則を、実装をAIに依頼する時点でプロンプトに明記してください。あわせてOWASP Top 10の観点でのレビューを公開フローに組み込むことを推奨します。公開前には、セキュリティセンターのシークレット管理項目で、鍵が意図しない場所に露出していないか必ず確認します（スキャンは自動実行されないため、手動での実行が必要です）。
HubSpot公式は、サービスキーについて6か月ごとのローテーション、および漏えい時の即時失効を推奨しています。ローテーションは「即時失効」と「7日間の移行期間つき」の2方式があり、通常は後者を使えばダウンタイムなく切り替えられます。不要になったキーは削除し、リクエストログを定期的に確認してください。
スコープ設計の原則は「読み取りだけで済むなら書き込みを付けない」。ダッシュボード用途ならreadのみで十分です。
App＋チャットコネクターは共有アカウントでの接続です。そのアプリを使う全員が、サービスキーに付与された権限で等しくCRMに触れることになります。「営業担当は自分の案件だけ見られればよい」という要件がある場合、共有アカウント方式では権限制御をアプリ側で自作することになり、実装ミスが情報漏えいに直結します。この要件がある場合は、迷わずアプリユーザーコネクター（OAuth）を選んでください。
公正を期すため、できないこと・注意点を明示します。
| 制約 | 内容 | 回避策 |
|---|---|---|
| Webhook非対応 | サービスキーはWebhookやイベント購読の認証に使えない | HubSpot側の変更を検知したい場合はポーリング設計にするか、別途アプリを構築する |
| UI Extensions非対応 | サービスキーはUI Extensions内の呼び出しに使えない | カード側はHubSpot開発者プラットフォームで構築し、Lovableはiframe側に徹する |
| APIレート制限 | Lovableからの全リクエストがHubSpotのAPI利用上限を消費する | キャッシュ設計、取得件数の最適化、不要なポーリングの抑制 |
| ベータ機能 | サービスキーはパブリックベータで仕様変更の可能性がある | 基幹連携では変更追随の体制を確保しておく |
| カスタムオブジェクト | HubSpotのカスタムオブジェクトはEnterpriseプランの機能 | 下位プランでは標準オブジェクトのカスタムプロパティで代替設計する |
| クラウド／AIクレジット | アプリの稼働とAI呼び出しはLovable側のクレジットを継続消費する | 運用費として恒久的に予算化する |
とくにWebhook非対応は設計に直結します。「HubSpotで取引ステージが変わったら、Lovableアプリ側で即座に何かする」という同期型の要件は、この方式では素直に実現できません。定期的に取得して差分を見るポーリング設計になるため、リアルタイム性の要件は設計前に必ず確認してください。
APIレート制限も無視できません。HubSpotの公式ガイドラインによれば、非公開アプリの上限は次のとおりです。
| プラン | 10秒あたりのバースト上限 | 1日あたりの上限 |
|---|---|---|
| Free / Starter | 100リクエスト | 250,000リクエスト |
| Professional | 190リクエスト | 625,000リクエスト |
| Enterprise | 190リクエスト | 1,000,000リクエスト |
注意すべきは、1日の上限はアカウント内の全アプリで共有される点です。既存の連携（MA、SFA、BIツールなど）がすでに枠を使っている環境では、新しく作るアプリの取得頻度が既存連携を圧迫する可能性があります。導入前に現在のAPI消費量を確認しておくことを強く推奨します。
10パターンを、リスクと着手しやすさで整理すると次のようになります。
| 優先度 | パターン | 理由 |
|---|---|---|
| まず着手 | ⑨データ品質チェックツール | 社内限定・読み取り中心。事故リスクが最も低く、効果が測定しやすい |
| 次に着手 | ①診断ツール、④営業ダッシュボード | 成果指標が明確（リード数・利用率）で、稟議の実績として使える |
| 体制を整えてから | ⑦顧客ポータル、⑩UI Extensions連携 | 外部公開または開発者関与が前提。セキュリティレビュー体制が必要 |
順序を間違える企業が多い領域です。最初に顧客ポータルのような「見栄えのするもの」から入ると、セキュリティ要件の重さに直面してプロジェクトが止まります。社内向けの読み取り専用ツールで成功体験と運用ルールを作ってから、外部公開に進むのが実務上の定石です。
また、どのパターンでも前提になるのがHubSpot側のデータ構造が整っていることです。プロパティの命名が揺れている、使われていないカスタムプロパティが数百ある、パイプラインの段階定義が実態と乖離している——この状態でアプリを作っても、映し出されるのは混乱したデータです。連携は、データ基盤の整備を代替しません。増幅するだけです。
株式会社100は、世界上位1%・日本唯一のHubSpot認定エリートパートナーとして、CRMのデータ基盤設計から業務アプリの内製化、社内定着までを一貫して支援しています。「何を内製し、何を標準機能で賄い、何を作らないか」の切り分けからご相談ください。
REST APIは無料版を含む全プランで利用できるため、連携自体は可能です。ただしプランによってAPIの1日あたり上限が異なり（Free/Starterは250,000、Professionalは625,000、Enterpriseは1,000,000）、カスタムオブジェクトはEnterpriseプランの機能です。
LovableのHubSpotコネクターはサービスキー方式です。サービスキーはREST API専用で、WebhookやUI Extensionsには使えません。これらが必要な場合は、HubSpot側で別途アプリを構築する必要があります。
サービスキーはWebhookの認証に使えないため、HubSpot側の変更をリアルタイムで受け取ることはできません。定期的にAPIを呼び出して差分を確認するポーリング設計になります。厳密なリアルタイム性が要件の場合は、設計段階で別方式を検討してください。
4点です。①API呼び出しは必ずサーバーサイド経由にし、鍵をフロントエンドのコードに含めない、②スコープを必要最小限にする（読み取りで済むなら書き込みを付けない）、③6か月ごとにローテーションする、④公開前にセキュリティセンターのシークレット管理項目を手動で確認する。①が最重要です。
できます。アプリユーザーコネクター（OAuth）を使えば、各ユーザーが自分のHubSpotアカウントでサインインし、HubSpot側の既存権限がそのまま適用されます。共有アカウント方式（サービスキー）で同じことをやるには権限制御の自作が必要になり、事故リスクが高いため推奨しません。
機能面では競合しませんが、APIの1日あたり上限はアカウント内の全アプリで共有されます。既存連携が枠を多く使っている環境では、新規アプリの取得頻度が既存連携を圧迫する可能性があるため、導入前に現在の消費量を確認してください。
MCPサーバー（チャットコネクター）は開発時にAIへ自社HubSpotの構造を理解させるためのもので、公開アプリには含まれません。アプリからHubSpotのデータを読み書きするには、App＋チャットコネクターまたはアプリユーザーコネクターが必要です。
UI ExtensionsまたはCRMカードのiframeアクションを使えば、レコード画面からモーダルで開けます。ただしカード自体はHubSpotの開発者プラットフォームで構築する必要があり、サービスキーはUI Extensions内の呼び出しには使えません。Lovable側は「iframeで呼ばれる側」として実装します。
本記事の仕様・数値は、2026年8月31日時点のLovable公式ドキュメントおよびHubSpot開発者ドキュメントの記載に基づきます。サービスキーはパブリックベータのため仕様変更の可能性があります。実装時は必ず公式ドキュメントで最新をご確認ください。