LovableやReplitでPOSを構築できるか？UIの先にある「欠けている要素」

ある意味では可能です。POSの定義が「画面に表示されるもの」にとどまるのであれば、LovableやReplitでPOSを構築できます。どちらのツールも、チェックアウト画面、商品グリッド、カートを半日で作ることができ、その見た目は加盟店が実際にお金を支払っている多くのソフトウェアよりも優れているでしょう。しかし、UIの先にある、目に見えないPOSの機能（在庫管理、レポート作成、税務、そして常に100%正確でなければならない決済処理）において、決定的なギャップが生じます。

具体的な内容に入る前に1点お断りしておきます。LovableとReplitは常にアップデートをリリースしているため、以下の詳細は公開時点のものであり、再確認が必要な情報としてお考えください。

LovableとReplitは実際に何を提供してくれるのか？

懐疑派が想定する以上のものを提供してくれます。LovableはフルスタックのWebアプリを生成します。データベース、認証、ファイルストレージを備えたホスト型バックエンドに接続されたReactフロントエンドに加え、オンライン決済用の決済連携機能も含まれます。Replitはサーバーサイドでさらに先を行きます。そのエージェントは、組み込みのデータベース、ホスティング、認証を備えたアプリを構築・ホストするため、サードパーティのサービスを繋ぎ合わせることなくバックエンドロジックを実行できます。

社内ツール、予約ページ、ダッシュボードといった多くのソフトウェアカテゴリにおいて、これらはまさに開発プロセスのすべてをカバーしており、これらのプラットフォームが急速に成長している理由もここにあります。しかし、POSがこのカテゴリに属さないのには理由があります。それは、Webアプリを一発で作成できる最先端モデルであっても、実用的なPOSの構築で行き詰まるのと同じ理由です。難しいのはインターフェースではないからです。

UIの先で何が欠けているのか？

コマースレイヤーです。POSとは、アプリが上に載っている「システム・オブ・レコード（お金と在庫の信頼できる唯一の情報源）」です。どちらのプラットフォームもコマースの基本要素（プリミティブ）を提供していないため、生成されたコードはそれらをゼロから発明しなければなりません。

• 同時実行制御下の在庫管理（2つのレジが同時に販売を行う場合）。在庫数をマイナスするだけのロジックはデモでは動作しますが、土曜日の混雑時に2つのレジが最後の1個を同時に販売した瞬間に破綻します。

• 注文のライフサイクル。一部返金、交換、取り消し、割引は、それぞれ在庫、レポート、決済記録を同時に更新しなければならない状態変化です。1つでも漏れがあれば、数値がズレ始めます。

• 数値が一致するレポート（実際の入金額と1円単位まで一致する合計額）。「ほぼ合っている」程度のレポートは、確定申告の際に簿記上の大きな問題となります。

• 実際の管轄区域のルールに従い、すべてのレシート、返金、レポートに正しく反映される税務ロジック。

AIエージェントは、これら4つすべてについて「それらしい」バージョンを生成します。この「それらしい」ことこそが罠です。壊れたボタンはタップした瞬間に気づけますが、売上照合のバグは、数ヶ月後に会計士が発見するまで目に見えないまま放置されます。

生成されたアプリで実際の決済を受け付けられるか？

オンラインであれば可能です。どちらのプラットフォームも、Webチェックアウトに十分な決済連携を接続できます。しかし、対面決済は全く異なる難しさがあります。対面決済（カード提示決済）には、認定された端末ハードウェアと、PCI DSS準拠（カードデータを扱うすべてのものに適用されるセキュリティルール）が必要です。生成されたコードベース単体でこれを満たすことはできません。認証はアプリではなく、決済プロバイダーのハードウェアとプラットフォームに存在しているからです。不払い紛争、元のカードへの一部返金、チップの調整なども、すべてこの同じ認定レイヤーを介して実行されます。

これは、どのようなツールを使おうとも、すべてのDIYルートが最終的にぶつかる壁です。私たちは、AIモデルがMCPを介して構築できるものとできないものをテストした際にも、同じ結論に達しました。

本番環境で最初に何が壊れるか？

よくある反論として、「生成されたアプリを自分でホスト型データベースと決済連携に繋ぎ合わせればいい」というものがあります。実際にやってみる価値はありますし、限界がどこにあるかを知る最も早い方法です。しかし、自分が「小規模な金融システムの唯一の維持管理者」になったことを理解してください。決済の途中でネットワークが切断されたとき、レシートプリンターがブラウザの対応していないドライバーを必要としたとき、返金処理は決済連携側で完了したのにレポートに反映されなかったとき、電話をかけられるベンダーは存在しません。構築は安価でしたが、所有し維持することには高いコストがかかり、それは最初の本物の決済を受け付けた日から始まります。

結論として、LovableやReplitでPOSを構築できるか？

フロントエンド（本物のインターフェース、本物のロジック）は素早く構築できます。しかし、バックエンド（負荷がかかった状態での在庫管理、売上照合、税務、認定された対面決済）は、エージェントがその場で発明できるコードではないため、生成することはできません。これらはすでに存在していなければならないインフラです。そのため、選択肢は2つに絞られます。そのインフラを自分で再構築して永久に維持し続けるか、あるいはすでに稼働しているコマースインフラの上にチェックアウト画面を生成するかです。後者がFinalのアプローチであり、プロンプトまたは独自のAIツールを使用して、稼働中のコマースバックエンド上にPOSを構築します。

いずれにせよ、AIに構築させる前に適用すべき1つのルールがあります。「そのバグが、ピクセルではなく金銭的な損失をもたらす場合、あなたが構築しているのはUIではなくインフラである」ということです。コマースレイヤーが最初から含まれているチェックアウトの下に何が存在するのかを確認したい場合は、実務における動作の詳細をご覧ください。