Lovable と Claude の公式統合で、AI 駆動開発の境界は何が変わるか

Lovable と Anthropic が公式の MCP (Model Context Protocol) ネイティブ統合を発表しました。Claude のチャットや Claude Code、Claude Design から Lovable ワークスペースに直接接続でき、プロジェクトの監査・データクエリ・ビルド・デプロイまでを一気通貫で扱えるようになる、という内容です。

私たち Nihonbashi AI Lab は Lovable Solution Partner として、また Claude Code を実務で日常的に使う立場として、発表の翌日に一日かけて実機検証を行いました。本記事では、報道で見える表面と、運用の中で実際に何が変わるか／変わらないかを切り分けて整理します。

公式発表で何が新しくなったのか

Lovable の公式案内 (lovable.dev/mcp、公式公表) によると、新しい統合は次の三方向です。

• Claude チャット ↔ Lovable ワークスペース: 自分の Lovable プロジェクトを Claude に直接読ませ、監査やデータクエリ、新規ビルドの起動が可能
• Claude Code ↔ Lovable: ターミナルから「/build」「/deploy」「/db」等の単一コマンドで Lovable を操作、バックグラウンドエージェント運用も視野
• Claude Design → Lovable: デザインプロトタイプをワンクリックでアプリ化、認証・データベース・本番 URL・AI 機能の追加も含む

接続手順自体は単純で、Claude の「+」から Connectors → Lovable を選んで OAuth 一度で完了します。

「Claude Code から Lovable が見える」の実体

実機検証で確認できた範囲は、想像していたよりも広いものでした。Nihonbashi AI Lab のメインサイトを含む 15 のプロジェクトに対して、Claude Code 側から次のことが一度のコマンドで取得できます。

• プロジェクト一覧、本番 URL、最新コミットの SHA、本番画面のスクリーンショット
• 過去のチャット履歴、編集履歴 (AI による更新と外部からの push を type で判別可能)
• Lovable プロジェクト Knowledge (Lovable AI への custom instructions の全文)
• 流入分析 (UU・PV・参照元・デバイス・国別の breakdown)

特に効くのは、本番画面のスクリーンショットがコマンド一発で取れるようになったことです。これまで dev サーバーでスクリーンショットを撮ろうとすると、ヘッドレスブラウザの制約でタイムアウトすることがあり、目視確認に追加の手間がかかっていました。MCP 経由なら Lovable 側が用意した最新スクリーンショットをそのまま参照でき、検証コストが体感で大きく下がります。

データベースの確認についても、これまで Supabase の SQL Editor をブラウザで開いて 1 行クエリを実行する流れだったところを、Claude Code から直接 SELECT 文を打って結果を JSON で受け取れます。

しかし「Lovable がホスティング屋になる」わけではない

ここで誤解されそうな話を、先に整理します。「Claude Code から Lovable をいじれるなら、Lovable はもう要らないのでは」と思われるかもしれませんが、運用の実体はそうではありません。少なくとも、現時点で 5 つの execution layer は Lovable がまだ強く担っています。

• Supabase のマイグレーション適用: 複雑な migration を本番に適用する経路は Lovable Cloud パイプライン (Lovable chat からの apply) が依然として標準。Claude Code 側からの SQL 直接実行は補助の位置づけ
• Cloud Secrets の管理: Build Secrets と Cloud Secrets の登録は Lovable のセキュアフォーム経由のみ。値は登録後に読み出せない write-only の設計
• Cloudflare Workers ビルド・デプロイ: 本番反映のパイプラインは Lovable Cloud → Cloudflare の経路を経由しており、ローカルからは触れない
• 画像生成や Vertex AI を介した実行: Lovable chat 経由でしか起動できない execution が複数存在
• 「.lovable/skills/」配下のスキル群: Lovable agent が自分で参照するスキル定義ファイルは Lovable 環境内でのみ effective

つまり Lovable は「マネージドな AI app deployment + execution プラットフォーム」であり、Claude Code は「高度なエディタ/エージェント」です。両者は補完関係で、当面どちらも単独では成立しません。

業務の中で何が変わり、何が残るか

Nihonbashi AI Lab では、AI 駆動開発で顧客に提供する価値を「画面作成」ではなく次の 4 軸で説明してきました。

• 業務設計 (どこを Web 化すべきか、どの業務から始めるかの整理)
• データ構造・権限設計 (誰が何を見られるべきか、後から変更できる形で組む)
• AI 活用設計 (要約・検索・分類・レポート生成を現場が使える形で組み込む)
• 運用導線 (公開後の改善サイクル、社内導入、チーム教育)

MCP 統合で自動化が大きく進んだのは、4 軸のうち最後の「運用導線」の確認層です。本番画面の確認、データベース状態の確認、流入分析、編集履歴の読み解きが、人手の往復なしに揃うようになりました。

一方、4 軸のうち前半 3 つは、自動化された層が増えたぶん、人間の判断レイヤーが相対的に価値を増す方向に動いていると感じます。「どの業務から Web 化を始めるか」「データの境界をどこに引くか」「AI に何を任せ、人が何を見るか」といった問いは、ツールが自動的には答えてくれません。

実機検証の副産物として、私たちの場合は複数プロジェクトのワークスペースを横断的に audit できるようになりました。「あるプロジェクトに入っている運用ルールが、別のプロジェクトに展開されていない」という Knowledge ドリフトを、目視に頼らずに検出できる状態は、複数プロダクトを並行で運用している組織にとっては実用的な変化だと考えています。

Nihonbashi AI Lab が支援できること

私たちは Lovable Solution Partner として、また Claude Code を日常運用するチームとして、両者を組み合わせた業務 Web アプリの設計・実装・運用支援を行っています。具体的には次の 4 軸で関わります。

• 業務設計: 何を Web ハブ化すべきか、どの業務から始めるべきかの整理
• データ構造・権限設計: 誰が何を見られるべきか、後から変更できる形で組む
• AI 活用設計: 要約・検索・分類・レポート生成を現場が使える形で組み込む
• 運用導線: 公開後の改善サイクル、社内導入、チーム教育まで

Supabase / Stripe / 認証基盤 / 外部 API との統合や、観測性・課金の設計など、Web アプリを「動くプロトタイプ」から「業務に乗る本番」へ持っていく実装経験と組み合わせて提供します。

公式統合は、これまで暗黙にやってきた運用を表に出しやすくしてくれる発表だと受け止めています。Lovable や Claude Code の導入を検討されている方、すでに使い始めて運用フェーズで悩まれている方、いずれもご相談ください。

本記事と同じテーマを、業務担当者の日々のワークフローがどう変わるかの視点で Zenn にも整理しています。

→ https://zenn.dev/nihonbashi/articles/lovable-claude-mcp-7project-audit