「Lovableは既存システムと連携できますか」。この質問に「できます」と答えると、たいてい次の質問で行き違いが起きます。質問した人が想像しているのは、作ったアプリが業務システムのデータを読み書きすることです。ところがLovableの連携には、それとは別の種類があります。
Lovableのコネクタは3種類あり、それぞれ認証の主体と使える範囲が違います。この違いを押さえずに設計すると、「開発中は動いたのに、公開したアプリでは動かない」という状態になります。原因は設定ミスではなく、選んだコネクタの種類が要件と合っていないことです。
この記事では、Lovableの連携を3種類に整理し、どの要件でどれを選ぶかを示します。あわせて、情報システム部門が統制できる範囲と、プランごとの既定値を公式ドキュメントから確認します。2026年9月10日時点の公式情報にもとづきます。カタログと仕様は更新が続いているため、設計前には最新の記載をご確認ください。
3種類です。名前が似ているため混同されますが、性質が根本的に違います。
違いを分ける軸は2つだけです。認証に使うのが誰のアカウントか、そしてその接続が公開したアプリに含まれるかどうかです。機能の多さではなく、この2軸で分類されています。
設計の場面で先に決めるべきなのは後者です。認証方式は後から変更できる余地がありますが、公開アプリに含まれるかどうかはコネクタ種別そのものの性質なので、選び直すと作り直しになります。
| 種類 | 認証の主体 | 使える範囲 | 誰が使えるか |
| App + chat connectors | 共有アカウント | ビルド中のチャット＋公開したアプリの中 | ワークスペース全体／アプリの訪問者 |
| Chat connectors（MCPサーバー） | 個人アカウント | チャットのみ。公開アプリには含まれない | 接続した本人のみ |
| App user connectors | エンドユーザー各自 | 公開アプリ（各ユーザーの権限で動作） | アプリの各エンドユーザー |
2行目に注目してください。公式ドキュメントはChat connectorsについて「You sign in with your own account, only you can use the connection, and it does not become part of the app you publish.」と明記しています。公開するアプリの一部にはならない、という点が決定的です。
ここが冒頭で述べた行き違いの原因です。開発中にチャットからNotionのドキュメントを読ませて画面を作った場合、それはChat connectorの働きです。公開したアプリがNotionを読み書きする機能にはなりません。
App + chat connectorsです。公式ドキュメントは「Connect a tool like Slack, HubSpot, or Google Sheets once and use it everywhere」と説明しています。一度接続すれば、ビルド中のチャットでも公開アプリでも使えるという設計です。
ただし共有アカウントで動くため、アプリの全ユーザーが同じ権限で対象システムにアクセスします。これが要件と合わない場合があります。たとえば営業担当者ごとに自分の担当顧客だけを表示したいなら、共有アカウントでは実現できません。
その場合に選ぶのがApp user connectorsです。公式ドキュメントには「If each user of your app should instead sign in with their own account and see only their own data, use an app user connector」と記載されています。エンドユーザー各自が自分のアカウントを接続し、そのユーザー自身の権限でアプリが動作します。認証はLovableのコネクタゲートウェイ経由で処理されます。
この選択は、後から変えると作り直しになります。要件定義の段階で「誰の権限でデータを見るのか」を確定させてください。私たちが設計する際は、画面の一覧を作る前にこの1点を決めています。
公式カタログに含まれるサービスは多数あります。ここでは業務システムとの接続で問われやすいものを挙げます。
CRM・営業系ではHubSpot、Salesforce、Pipedrive、Zoho CRMのコネクタページが公開されています。生産性・コミュニケーション系ではSlack、Notion、Google Workspace、Microsoftがあります。
データ基盤側は選択肢が広く、BigQuery、Snowflake、Databricks、Microsoft Fabric、Amazon Redshift、AWS Athena、ClickHouseのページがあります。決済はStripeやChargebee、会計系ではXeroやZoho Booksが並びます。
データウェアハウス系が揃っている点は、社内のデータ活用を考えるうえで重要です。既にBigQueryやSnowflakeに集約されているデータがあるなら、そこを参照する画面を早く作れます。ただし参照先が部門ごとにばらばらな状態では、繋いだ先で数字が合わない問題が起きます。前提となる考え方はSSOT（信頼できる唯一の情報源）とは ─ AI時代のデータガバナンスの基本で扱っています。
HubSpotとの連携で具体的に何ができるかはLovable×HubSpot連携でできること10選｜接続方式・設定手順・セキュリティ要件をエリートパートナーが解説で、デザインの取り込みはLovableとFigma連携｜3つの取り込み方法と再現できる範囲の限界で個別に扱っています。
この2つは扱いが異なります。公式ドキュメントの記述にもとづいて分けます。
n8nはChat connectors（MCPサーバー）として公式に対応しています。 前掲のChat connectorsのページに、プリビルトのコネクタとしてLinear、Jira、Notion、Confluence、Miro、n8n、Amplitude、PostHog、Hex、HeyGen、Sanity、Polar、Sentry、Granola、Confidenceが挙げられており、n8nの用途は「ワークフローやライブデータと連携するアプリ」と説明されています。
ただしChat connectorであるという点に注意してください。前述のとおり、Chat connectorは公開するアプリの一部にはなりません。開発中にn8nのワークフローを参照しながらアプリを作ることはできますが、公開したアプリがn8nのワークフローを実行する構成にはなりません。
一方、Zapierについては、2026年9月10日時点でApp + chatのカタログにもChat connectorsのリストにも専用コネクタを確認できませんでした。「無い」と断定はできませんが、公式ドキュメント上では見つかりません。Zapierと繋ぐ必要がある場合の経路は次項で扱います。
2つの経路があります。
第一に、Any APIです。REST APIを持つサービスであれば、公開・内部を問わず接続できます。Webhookを受ける形の連携であれば、これで足ります。
第二に、カスタムコネクタの作成です。エンドポイント・認証・ナレッジを一度定義すれば、ワークスペースの全員が他のコネクタと同じように接続できるようになります。社内の基幹システムに独自APIがある場合、この形にしておくと部門横断で再利用できます。
チャット側で使うなら、カスタムMCPサーバーの接続という選択もあります。リモートのMCPサーバーをChat connectorとして繋ぎ、社内ツールやプライベートAPIをビルド中の文脈として使う形です。組織内で使えるMCPサーバーを一覧化する場合はMCPレジストリを設定しておくと、メンバーがURLを貼らずに接続できます。
ここで実務的な注意があります。カスタム連携は作れますが、作った後の保守が必要です。接続先のAPIが変わればこちら側も直す必要があり、誰が直すのかを決めていないと放置されます。内製と外注の線引きは社内システムを内製するメリット・デメリット｜外注と比較する判断基準と10のチェック項目で扱っています。
ここが全社導入の可否を分けます。連携は便利ですが、統制なしに配れば社内データが外部サービスへ繋がる経路が無管理に増えます。
公式のコネクタ管理のドキュメントによると、設定できる場所は2つです。ConnectorsのAdmin settingsでコネクタ種別ごとの作成権限を管理し、Privacy & securityでMCP関連のワークスペース全体のスイッチを操作します。ただし前者はBusiness・Enterpriseプラン限定です。
作成権限は3択で、公式の表現では次のとおりです。No one（"effectively disables the connector"＝そのコネクタを実質的に無効化する）、Admins（ワークスペース管理者のみが作成できる）、Editors & admins（editorロール以上のメンバーが作成できる）。
あわせて、コネクタを作成した本人が使用範囲を設定できます。こちらは全プランで、Only you（作成した本人のみ）、Invite specific people（指定した人）、Invite entire workspace（ワークスペース全体）の3択です。
既定値がプランで変わります。これを知らずにEnterpriseへ移行すると、動いていた連携が止まり、障害と誤認されることがあります。
| コネクタ種別 | Free / Pro / Business | Enterprise |
| App + chat | 既定で利用可能 | 既定で「No one」＝実質無効 |
| カスタムコネクタ | 既定で利用可能 | 既定で「Admins」 |
| Chat connectors（リモートMCP） | 既定で有効 | 既定で有効 |
| ローカルMCP | 既定で有効 | 既定で無効 |
1行目と4行目が実務で効きます。Enterpriseでは公開アプリで動くコネクタが既定で止まっているため、管理者が明示的に有効化する必要があります。逆に言えば、統制を先に設計してから開放する順序が既定になっているということです。全社展開を前提にするなら、この設計思想に沿って進めたほうが後戻りがありません。
Chat connectors全体を止めたい場合は、Privacy & securityの「Remote MCP connectors」をOffにします。Enterprise限定の例外として、カスタムMCPサーバーへのLovable static IPsによる接続オプションが挙げられています。接続元IPを固定できると、接続先システム側でIP制限をかけられるため、社内システムに繋ぐ場合の審査が通りやすくなります。
公式の連携セキュリティのドキュメントに、認証情報の保存方法、ゲートウェイ、IP許可リスト、ドメイン制限に関する記述があります。情シス審査ではこのページの内容が問われるため、審査資料に添付する前提で読んでおくと説明が短くなります。
あわせて確認すべきなのがビルドシークレットです。ワークスペースレベルの暗号化された環境変数として、ビルド時に注入される仕組みです。APIキーをコードに直接書く運用を避けるために必要な機能です。
全社展開時の統制設計全般はLovableを全社展開する設計｜SSO・権限・野良アプリ対策の進め方、公開前の点検項目はLovableのセキュリティは何が危険か？公開前RLS設定チェックリスト23項目で扱っています。
要件から逆算します。判断は3つの問いで決まります。
第一の問い。その連携は公開したアプリの中で動く必要があるか。必要ならApp + chat、開発中の参照だけならChat connectorです。ここを間違えると、公開後に動かない状態になります。
第二の問い。誰の権限でデータを見るのか。全ユーザーが同じ権限で見るならApp + chatの共有アカウント、ユーザーごとに自分のデータだけを見るならApp user connectorsです。後から変えると作り直しになります。
第三の問い。接続先は公式カタログにあるか。あればコネクタを使い、無ければAny APIかカスタムコネクタ、チャットで使うならカスタムMCPサーバーです。
この3問に答えると、選択肢は1つに絞られます。逆に、この3問を飛ばして「連携できるかどうか」だけを議論すると、実装してから要件と合わないことが分かります。
加えて、統制側の確認を1つ入れてください。使いたいコネクタ種別が、自社のプランで有効になっているかです。Enterpriseでは App + chat が既定で無効なので、要件が固まっても管理者の設定が必要になります。
最後に、運用の話を1つ加えます。連携は増やすほど便利になりますが、同時に管理対象も増えます。
連携を1つ作るということは、社内データが外部サービスへ流れる経路を1つ作るということです。作った本人は把握していますが、異動や退職の後は誰も把握していません。管理者の統制設定で作成権限を絞れるのは、この構造への対処です。
私たちが棚卸しの台帳を設計する際は、コネクタについて4項目を記録しています。接続先のサービス名、コネクタの種類（App+chat／Chat／App user）、認証に使ったアカウント、そして接続を作成した人と現在の所属です。4項目目を入れているのは、退職者のアカウントで動いている連携を検出するためです。
この管理を人の記憶に依存させると、規模が大きくなった時点で破綻します。現場が自分でアプリを作れる環境では特に、把握できない接続が静かに増えます。同じ構造の問題への対処はLovableを全社展開する設計｜SSO・権限・野良アプリ対策の進め方で整理しています。
Chat connectorを使っている可能性が高いです。公式ドキュメントには「it does not become part of the app you publish」と明記されており、Chat connectorは公開するアプリの一部にはなりません。公開アプリの中で動かす必要がある場合は、App + chat connectorsを使ってください。
App user connectorsを使います。App + chat connectorsは共有アカウントで動作するため、アプリの全ユーザーが同じ権限で接続先にアクセスします。エンドユーザー各自が自分のアカウントを接続する形にすると、そのユーザー自身の権限でアプリが動作します。この選択は後から変更すると作り直しになるため、要件定義の段階で決めてください。
Chat connectors（MCPサーバー）として公式に対応しています。公式ドキュメントでは、n8nの用途を「ワークフローやライブデータと連携するアプリ」と説明しています。ただしChat connectorであるため、公開したアプリがn8nのワークフローを実行する構成にはなりません。開発中に参照する用途になります。
2026年9月10日時点で、App + chatのカタログにもChat connectorsのリストにも専用コネクタを確認できませんでした。Zapierと繋ぐ必要がある場合は、Any APIまたはカスタムコネクタでの接続を検討してください。カタログは更新が続いているため、設計前に公式の最新の一覧をご確認ください。
REST APIがあればAny APIで接続でき、繰り返し使うならカスタムコネクタとして定義できます。ただし接続元IPの制限が必要な場合、Lovable static IPsによる接続オプションはEnterprise限定の例外として記載されています。情シス側でIP制限を要件にしている場合は、プランの選択に影響します。
既定値の違いによるものです。公式ドキュメントによると、EnterpriseではApp + chatコネクタが既定で「No one」に設定されており、実質的に無効な状態から始まります。カスタムコネクタも既定は「Admins」、ローカルMCPは既定で無効です。管理者がAdmin settingsで明示的に有効化する必要があります。
プランと統制の設計次第です。Business・Enterpriseでは作成権限を「No one」「Admins」「Editors & admins」から選べます。全件を管理者経由にすると承認の待ち時間が発生し、現場は回避する方向に動きます。接続先のデータの機微性で分け、機微性の低いものはEditors & admins、社内の基幹システムに繋ぐものは管理者のみ、という配分が実務的です。
管理者の統制設定で作成権限とコネクタごとの有効・無効を管理できます。ただし棚卸しの台帳は自社側で持つことをおすすめします。私たちが設計する際は、接続先のサービス名、コネクタの種類、認証に使ったアカウント、作成者と現在の所属の4項目を記録します。4項目目は、退職者のアカウントで動いている連携を検出するために必要です。
Lovableの連携は3種類あります。App + chat connectorsは共有アカウントで動き、ビルド中のチャットと公開したアプリの両方で使えます。Chat connectors（MCPサーバー）は個人アカウントで動き、チャットのみで機能して公開アプリには含まれません。App user connectorsはエンドユーザー各自が自分のアカウントを接続し、そのユーザーの権限で動作します。
「開発中は動いたのに公開したら動かない」という事象は、設定ミスではなくコネクタ種別の選択によるものです。要件定義では、①公開アプリの中で動く必要があるか、②誰の権限でデータを見るのか、③接続先が公式カタログにあるか、の3問を先に確定させてください。
カタログにはHubSpot、Salesforce、Slack、Notion、Google Workspace、Microsoftといった業務系から、BigQuery、Snowflake、Databricks、Microsoft Fabricといったデータ基盤まで含まれます。n8nはChat connectorとして公式に対応しています。Zapierは2026年9月10日時点で専用コネクタを確認できず、Any APIかカスタムコネクタでの接続になります。
統制面では、コネクタ種別ごとの作成権限をBusiness・Enterpriseで管理できます。Enterpriseでは App + chat が既定で「No one」、ローカルMCPが既定で無効です。統制を設計してから開放する順序が既定になっているため、全社展開ではこの流れに沿うほうが後戻りがありません。
そして連携は、増やすほど管理対象が増えます。接続先・種類・認証アカウント・作成者と所属の4項目を台帳で持ち、退職者のアカウントで動いている連携を検出できる状態にしてください。
既存システムとの接続設計、情シス審査向けの資料作成、日本円での法人契約に関するご相談は、株式会社100のLovable公式パートナーページで承っています。HubSpotとの連携はLovable×HubSpot連携でできること10選、Lovableの全体像はLovableとは？できること・料金・使い方を日本公式パートナーが徹底解説をあわせてご覧ください。
本記事のコネクタ一覧・統制設定・プランごとの既定値は2026年9月10日時点でLovableの公式ドキュメントから取得したものです。カタログと仕様は変更される可能性があるため、設計前には公式の最新の一覧をご確認ください。