Lovable × n8n 連携｜AIワークフローを自分のアプリに組み込む

n8nは「ノーコードのAIワークフロー基盤」。Lovable側はWebhookを叩くだけで、複雑な分岐・SaaS連携をn8nに任せられます。

アーキテクチャ#

• Lovableフロント → サーバーファンクション → n8n Webhook
• n8nが Slack/Notion/OpenAI 等を組み合わせて処理
• 結果をJSONで返してUI表示

サーバーファンクションの例#

// src/lib/n8n.functions.ts
import { createServerFn } from "@tanstack/react-start";
import { z } from "zod";

export const runWorkflow = createServerFn({ method: "POST" })
  .inputValidator((d) => z.object({ topic: z.string() }).parse(d))
  .handler(async ({ data }) => {
    const url = process.env.N8N_WEBHOOK_URL!;
    const res = await fetch(url, {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify(data),
    });
    return await res.json();
  });

実例ケーススタディ：問い合わせ→Slack→Notion→自動返信の自動化#

1. Lovable側：問い合わせフォームのsubmit時に n8n の Webhook を叩くserver functionを呼ぶ
2. n8n：Webhookノード→Slack通知→NotionにDBレコード作成→Resendで自動返信
3. 失敗時はn8nのError Trigger経由で運営者にメール通知
4. n8nの環境変数にAPIキー類を集約、Lovable側にはWebhook URLとHMACシークレットだけ持たせる

つまずきポイント集#

• 症状：n8nから401返却 → 対処：HMAC署名検証ヘッダを追加。Webhook URLは推測困難なものに
• 症状：本番でだけタイムアウト → 対処：Lovable側はfire-and-forgetにし、n8n内で長時間処理。レスポンス即返し→裏で実行
• 症状：自分のn8nが落ちて連鎖障害 → 対処：n8nの自前ホスティング先のリソース監視＋失敗時のフォールバック（DBに保留→Cronでリトライ）

FAQ追加#

Q. n8n Cloudとセルフホスト、どちらが良い？

ノード数が少なく学習目的ならn8n Cloudが手軽。ノード数が多く外部APIキーを多用する本番運用ならRailway/Renderでセルフホストがコストパフォーマンスで有利です。

Q. Lovable単体で完結すべき処理は？

リアルタイムなUI操作・認証・即時DB書き込みは Lovable 内で完結。バッチ処理・複数SaaS連携・スケジュール処理は n8n に寄せると保守が楽です。