Lovableのセキュリティ事故から学ぶ、AIアプリビルダーの構造的脆弱性

はじめに

2025年、AIアプリビルダー業界で象徴的な出来事があった。「自然言語でアプリが作れる」と評価されていたLovableで、ユーザーが作成したアプリのフロントエンドコードに、Supabaseの認証情報やビジネスロジックが露出していた事案が広く議論されたのだ。

この事案は、単なる「設定ミス」として片付けられるものではない。それは、現在の主流であるAIアプリビルダーが採用しているアーキテクチャ選択そのものに内在する、構造的な脆弱性が表面化した出来事だった。

本記事では、Lovableのケースを起点に、AIアプリビルダーが直面する3つの構造的課題を整理する。そして、これらの課題に対するアーキテクチャ的な回答として、私が開発しているBranch AIの設計判断を共有したい。

技術選定で「フロントエンドで完結させるべきか、サーバーサイドを持つべきか」を悩んでいる開発者、AIアプリビルダーを業務利用しようとしている方、競合プロダクトを設計している方の参考になれば幸いだ。

何が起きたのか:Lovableのケースを技術的に整理する

報じられた内容を技術的な観点で整理すると、以下のような構造が見える。

Lovableは、ユーザーがチャットで指示するだけでWebアプリを生成する。生成されるアプリはReactベースのSPAで、データベースと認証はSupabaseに依存する設計だ。

問題は、生成されたアプリのフロントエンドに、本来サーバーサイドに保護されるべき情報が含まれていたことだ。具体的には以下のような情報がブラウザから可読な状態で配信されていた可能性がある。

データベースへのアクセスキー(Supabase anon key)
認証ロジックの一部
業務ロジックを示すコード(価格計算、権限チェックなど)
API endpointの構造とスキーマ情報

Supabaseは、これらの情報がフロントエンドに露出することを前提に、Row Level Security(RLS)というデータベースレベルの認可機構を提供している。RLSが正しく設定されていれば、anon keyが露出してもデータは保護される。

しかし、RLSの設定はユーザー自身の責任だ。AIが自動生成したRLSポリシーは、複雑なビジネスロジックに対して常に正しいとは限らない。そして、AIが生成したコードを非エンジニアのユーザーが検証することは、現実的に不可能だ。

結果として、「AIが生成したRLSポリシーが想定通りに動いていなかった」「ユーザーがその不備に気づけなかった」という二重の失敗が、データ露出を引き起こした。

典型的なフロントエンド完結型のコード例

以下は、フロントエンド完結型アーキテクチャで生成されるコードの概念例だ。ブラウザの開発者ツールから誰でも閲覧できる。

フロントエンド完結型（ブラウザに露出）

// ブラウザに配信されるJavaScript — 誰でも閲覧可能
import { createClient } from '@supabase/supabase-js'

// データベースの認証情報がフロントエンドに埋め込まれている
const supabase = createClient(
  'https://xxxx.supabase.co',       // DB endpoint — 公開
  'eyJhbGciOiJIUzI1NiIs...'        // anon key — 公開
)

// ビジネスロジックもフロントエンドに露出
async function calculatePrice(item) {
  const { data } = await supabase
    .from('products').select('*')
    .eq('id', item.id)

  // 価格計算ロジックが丸見え
  let price = data[0].base_price
  if (user.plan === 'enterprise') price *= 0.7
  if (item.quantity > 100) price *= 0.85
  return price
}

Branch AIのサーバーサイドアプローチ

対照的に、Branch AIでは同じ処理がサーバーサイドで実行される。フロントエンドはAPIを呼ぶだけで、ロジックもキーも一切露出しない。

Branch AI（サーバーサイドで実行）

# router.py — サーバー上で実行。ブラウザからは見えない
from fastapi import APIRouter
from models_myapp import get_product, get_user_plan

router = APIRouter()

@router.post("/calculate-price")
def calc_price(body: dict):
    product = get_product(body["product_id"])
    plan = get_user_plan(body["user_id"])

    # 価格計算ロジックはサーバー内部に閉じている
    price = product["base_price"]
    if plan == "enterprise": price *= 0.7
    if body["quantity"] > 100: price *= 0.85
    return {"price": price}

フロントエンド（APIを呼ぶだけ）

// index.html — ロジックもキーもない。結果を受け取るだけ
async function getPrice(productId, quantity) {
  const res = await fetch(`/api/myapp/calculate-price`, {
    method: 'POST',
    headers: {'Content-Type': 'application/json'},
    body: JSON.stringify({ product_id: productId, quantity: quantity })
  })
  const data = await res.json()
  document.getElementById('price').textContent = data.price + '円'
}

構造的課題1: 信頼境界の曖昧さ

ここで注目すべきは、これがLovable固有の問題ではないということだ。

Webアプリケーションのセキュリティ設計の基本原則として、「フロントエンドは信頼してはならない」という鉄則がある。ブラウザで動くコードは、エンドユーザーが任意に改変できる。開発者が意図したロジック通りにフロントエンドが動く保証はない。

この原則を踏まえると、業務に使うアプリケーションでは、本質的に重要な処理はすべてサーバーサイドで実行する必要がある。価格計算、権限チェック、データバリデーション、業務ルールの適用、こういった処理は、フロントエンドで補助的に行うことはあっても、最終的な判断はサーバーで下す。

ところが、現在の主流のAIアプリビルダー(Lovable、Bolt、v0など)は、この鉄則と相性が悪い。これらのツールは「フロントエンドのコードを生成する」ことを主軸にしており、サーバーサイドのビジネスロジックを構造的に持ちにくい。

代わりに採用されているのが、フロントエンド + BaaS(Backend as a Service)構成だ。SupabaseやFirebaseのようなBaaSが、データベースと認証を提供する。ビジネスロジックは、BaaS側のRLS、Edge Functions、Cloud Functionsなどに分散する。

この構成は、シンプルなアプリには適している。ランディングページ、お問い合わせフォーム、ToDoリスト、こういったアプリでは十分機能する。

しかし、業務アプリのような複雑なビジネスロジックを扱うアプリでは、信頼境界が曖昧になる。「このロジックはフロントエンドで動いていいのか、RLSで守るべきか、Edge Functionに分離すべきか」という判断が、開発者(またはAI)に委ねられる。判断を誤れば、Lovableの事案のような問題が起きる。

アーキテクチャ比較

以下の表は、フロントエンド完結型（従来型AIビルダー）とサーバーサイド型（Branch AI）のアーキテクチャを各観点で比較したものだ。

評価項目	従来型AIビルダー (Lovable, Bolt, v0等)	Branch AI
コード実行場所	ブラウザ（フロントエンド）	サーバーサイド（Python）
コードの可視性	ブラウザから全コード閲覧可能	サーバー内部に閉じる
DBアクセスキー	フロントエンドに露出	サーバー内部のみ
ビジネスロジック保護	ブラウザで実行（改変可能）	サーバーで実行（改変不可）
CSRF対策	ユーザー/AI依存	フレームワークレベルで自動適用
SQLインジェクション対策	BaaS依存（RLS設定次第）	サーバー側でサニタイズ
認証・認可	フロントエンド+BaaS分散	サーバーサイドで一元管理
信頼境界	曖昧（クライアント側に依存）	明確（サーバー=信頼境界）
複雑な業務ロジック	70%問題が顕在化しやすい	バックエンドで一貫管理
セキュリティの体系性	画面ごとに個別実装	全リクエストに自動適用
App Store準拠	WebView制限に抵触リスク	iOS-native（Swift）で準拠

構造的課題2: 70%問題と複雑性の限界

業界では、AIアプリビルダーの「70%問題」が広く認識されている。これは、AIが生成するアプリは「動くものの70%まで」連れて行ってくれるが、本格的な実用には残りの30%を人間が手動で修正する必要がある、という現象を指す。

この30%の壁が顕著に現れるのが、複雑なビジネスロジックを扱う領域だ。複数のユーザーロール、状態遷移、トランザクション処理、データ整合性、外部システム連携、こういった要素が絡むと、AIが一貫したコードを生成し続けることが困難になる。

実際のユーザーの声として、業界の議論で頻出するパターンがある。

「AIにバグを修正してくれと頼んだら、二つの新しいバグを導入してきた」

「プロジェクトが20コンポーネントを超えると、AIが早期に確立されたコード規約を忘れ始める」

「複雑な状態管理の問題は、解決される前にクレジットの大部分を食い尽くす」

これらは、特定のAIアプリビルダー固有の問題ではない。LLMが、長いコンテキストを保ちながら一貫した設計判断を続ける能力に、現時点では構造的な限界があるからだ。

問題は、業務アプリこそ、まさにこの「70%問題」が顕在化する領域だということだ。在庫管理、予約システム、決済処理、これらはすべて複雑なビジネスロジックを必要とする。シンプルなランディングページが作れるツールが、業務アプリも作れるとは限らない。

構造的課題3: セキュリティ実装の体系性

セキュリティは、後付けで追加できる機能ではない。アプリケーションの設計の最初の瞬間から、複数のレイヤーで体系的に組み込まれる必要がある。

具体的には、以下のような複数のセキュリティ層が必要だ。

認証層: 誰がアクセスしているかの確認(セッション管理、JWT、OAuth)
認可層: そのユーザーが何をしていいかの判断(RBAC、ABAC)
入力検証層: 受信したデータの正当性確認(バリデーション、サニタイゼーション)
CSRF防御層: クロスサイトリクエスト偽造への対策
SQLインジェクション防御層: パラメタライズドクエリの徹底
XSS防御層: 出力時のエスケープ、CSP
レート制限層: ブルートフォース攻撃、API乱用への対策
ログ・監査層: セキュリティイベントの記録と検知
暗号化層: 通信(TLS)、保存データの暗号化

これらは、互いに独立しているわけではなく、層として重ね合わせることで効果を発揮する。一つの層に穴があっても、他の層が防ぐ、という多層防御の考え方だ。

AIアプリビルダーが生成するコードは、これらすべての層を体系的にカバーすることが構造的に難しい。なぜなら、AIは「ユーザーが指示した機能」を生成することに最適化されており、明示的に指示されないセキュリティ層は、生成されないか、不完全に生成される可能性が高いからだ。

ユーザーが「商品管理画面を作って」と指示したとき、AIは商品管理機能を生成する。しかし、その商品管理画面のCSRF対策、SQLインジェクション対策、適切な認可チェック、こういった層が体系的に実装されているかは、AIの判断と運次第になる。

アーキテクチャ選択がセキュリティを決める

ここまでの分析から見えてくるのは、AIアプリビルダーのセキュリティは、個別の機能実装の問題ではなく、アーキテクチャ選択の問題だということだ。

フロントエンド + BaaS構成は、シンプルさと開発速度に優れる一方、信頼境界が曖昧になり、複雑なビジネスロジックでの一貫性が保てず、セキュリティ層を体系的に組み込みにくい。

代替案として、サーバーサイドを持つアーキテクチャがある。フロントエンドはUIの表示と入力受付に専念し、すべての業務ロジック、認証、認可、データ検証をサーバーサイドで実行する設計だ。

サーバーサイドアーキテクチャの構造的メリット:

信頼境界が明確 — クライアントからの入力は常に検証され、サーバー側のロジックが「真の処理」として機能する。

ビジネスロジックの一元管理 — 価格計算、在庫管理、権限制御などを、サーバー側のコードで一箇所に集約できる。

セキュリティ層の体系的な実装 — フレームワークレベルで、CSRF、SQLインジェクション、認証、レート制限を一括で適用できる。

機密情報の保護 — APIキー、データベース接続情報は、サーバー側に留まり、フロントエンドに露出しない。

Branch AIの設計判断

ここから、私が開発しているBranch AIの設計判断について書く。Branch AIは、上記の構造的課題に対する一つの回答として設計したiOS-nativeのAIアプリビルダーだ。

Branch AIのアーキテクチャは、以下のような特徴を持つ。

iOS-native(Swift)のクライアント: ReactなどのWeb技術をWebView経由で動かすのではなく、純粋なSwiftで実装している。AppleのガイドラインにSwiftUIネイティブとして完全準拠することで、App Store審査も通過している。これは、競合のいくつかがApple Guideline 2.5.2違反でApp Storeから締め出されている現状と対照的だ。

Pythonサーバーサイドアーキテクチャ: ビジネスロジック、データ検証、認証、認可、すべてをPythonで実装したサーバー側で実行する。クライアントはUIに専念する。これにより、信頼境界が明確になる。

Security from Day 1の実装: CSRF対策、SQLインジェクション対策(パラメタライズドクエリの徹底)、認証システム、セキュリティヘッダー、これらを最初の実装段階から組み込んでいる。後付けではなく、初期設計に内在している。

業務アプリへの特化: 汎用的なWebアプリビルダーではなく、業務アプリという領域に特化している。複雑なビジネスロジックを扱う必要がある領域に、最初から最適化された設計だ。

ただし、誤解を避けるために明記しておくと、Branch AIは現時点で完璧なプロダクトではない。ISMSやPマークの認証は取得していない。エンタープライズ向けのアクセス制御や監査ログ機能も、まだ整備途上だ。複雑な業務アプリの生成も、最近のアーキテクチャ見直しで安定化したばかりで、長期的な安定性はこれから検証していく段階だ。

しかし、アーキテクチャレベルでの設計判断は、後から変えることが極めて難しい。最初に「フロントエンド完結型」で作り始めたプロダクトを、途中で「サーバーサイド中心」に変えることは、事実上のリビルドを意味する。Lovableが既存ユーザーを抱えながら、アーキテクチャを大きく変更できない理由はここにある。

Branch AIは、その意味で、構造的な後発優位を持つ立場にあると考えている。先行者が抱える既存の制約から自由に、最初から正しいアーキテクチャを選択できる位置にいる。

業界全体への示唆

最後に、Branch AIに限らず、AIアプリビルダー全般を考える上での示唆を整理したい。

第一に、AIアプリビルダーで業務アプリを作るなら、アーキテクチャを確認することが重要だ。生成されたコードがどこで実行されるか、機密情報がどこに保管されるか、ビジネスロジックがどこで判断されるか、こういった構造を理解した上で、業務に使うかを判断する必要がある。「動いているように見える」ことと、「セキュアに動いている」ことは、別の問題だ。

第二に、シンプルなアプリと業務アプリは、要求されるアーキテクチャが違う。ランディングページや簡単なフォームなら、フロントエンド完結型でも問題ない。しかし、複数ユーザーロール、トランザクション処理、機密データの取り扱いがあるアプリでは、サーバーサイドのビジネスロジックが必須になる。すべてのAIアプリビルダーが、すべてのアプリ用途に適しているわけではない。

第三に、現在のAIアプリビルダー業界は、まだ初期段階にある。「動くアプリが作れる」という段階から、「業務に使える信頼性を持つアプリが作れる」という段階への移行は、これからだ。Lovableのセキュリティ事故は、業界全体がこの移行を真剣に考える必要があることを示すシグナルだった。

第四に、ユーザー側のリテラシーも重要だ。AIアプリビルダーを使うユーザーは、生成されたコードの中身を理解できないことが多い。だからこそ、ツールを選ぶ段階で、アーキテクチャレベルの安全性を確認する必要がある。「便利そうだから使う」ではなく、「自分の業務に必要な安全性を提供できるか」を見極める姿勢が求められる。

おわりに

Lovableのセキュリティ事故は、AIアプリビルダー業界にとって、ある種の転換点だった。それまで「便利さ」「速さ」が訴求されていた業界に、「信頼性」「セキュリティ」という新しい評価軸が加わった。

この転換は、業界全体にとって健全な方向だと思う。AIで誰でもアプリが作れる時代だからこそ、その背後にあるアーキテクチャの選択が、ますます重要になる。

Branch AIは、この変化の中で、アーキテクチャレベルの誠実さを軸にプロダクトを作っている。完璧ではないし、まだ初期段階のスタートアップだ。しかし、「最初から正しいアーキテクチャで作る」という姿勢は、長期的に意味があると信じている。

業務アプリを作りたい方、AIアプリビルダーを比較検討している方、この議論に興味を持った技術者の方、もし試してみたいと思ったら、Branch AIを実際に触ってみてほしい。フィードバックも歓迎だ。

そして、Branch AIを使うかどうかに関わらず、「アーキテクチャの選択がセキュリティを決める」という視点を、AIアプリビルダーを評価する際の一つの軸として持っていただければ嬉しい。

本記事は、Lovableに対する批判ではなく、業界全体の構造的課題を分析する目的で書かれています。Lovableは優れたプロダクトであり、その普及が業界全体の発展に貢献していることに敬意を払います。本記事の議論は、AIアプリビルダー全般に共通する技術的課題に焦点を当てています。