AI アプリ開発に向いたAIの選び方

AIアプリ開発では、最初に「試作品を短時間で見たい」のか、「既存のrepositoryを保ったまま機能を追加したい」のかを決めます。前者ならLovable、Bolt、Replitのようなprompt-driven builderが候補になり、後者ならCursorなどの既存codebase向けagentが候補です。選ぶ軸は生成画面の印象だけではありません。データの置き場所、認証、deploy、source codeの所有・移行、権限と秘密情報を誰が管理するかまで先に確かめてください。

要件を「作る速さ」と「運用責任」に分ける

「AIでアプリを作りたい」は、画面を組み立てる作業と、利用者向けのserviceを運用する作業が一つになった検索語です。ログイン画面まで生成できても、authorization、データ保護、障害対応、backupが整ったとは限りません。まず次の問いに答えます。

• 新規の小さな試作か、既存repositoryの変更か

• 利用者は自分だけか、顧客・社内メンバーか

• 保存するデータは公開情報か、個人情報や顧客情報を含むか

• backendを内蔵サービスへ任せるか、既存クラウドへ接続するか

• source codeをGitへ出し、他の環境へ移せる必要があるか

• deploy後の監視、更新、費用を誰が持つか

ここが決まらないまま生成を始めると、見た目は動くのにデータ構造や認証をやり直すことがあります。最初のprototypeは、失ってもよいテストデータと限定したユーザーで作り、production投入の判断と分けます。

方式別の選択表

表は横にスクロールできます

方式・候補	確認しやすい強み	先に確かめる条件
Lovable	chatからweb appを作り、Lovable Cloudにdatabase、auth、file storage等をまとめる選択肢	Cloudと外部backendの境界、export、Git連携、権限、費用
Bolt	browser上で構築し、Bolt Cloudでhosting、database、auth、functions等を扱う経路	Cloud内の管理範囲、既存Supabase等との接続、Gitからの復旧、deploy条件
Replit Agent	workspace内でアプリ作成を進め、databaseやauthなどの機能を組み合わせる方式	deployment、data、secret、team permissions、運用先と課金
Cursor	既存repositoryをIDEで読みながら変更し、Cloud Agentを隔離VMで実行する選択肢	local/cloudの権限差、terminal command、network、diffとtestのreview
自前stack＋coding agent	cloud provider、database、authを自分の既存契約に合わせる	設定・運用責任を自社が引き受けること、生成範囲の検証

この表は同一要件を実測した性能順位ではなく、構成の境界を見るための整理です。各社の機能とplanは更新されます。使いたい機能が今のplanに含まれるか、公式の料金・Helpで確認してください。Built-in backendは初期設定を簡単にしますが、data ownership、migration、backupの責任が消えるわけではありません。

候補を絞る条件

画面と基本動作を短時間で試す場合は、prompt-driven builderから始めます。たとえば、入力フォーム、検索結果一覧、権限のない公開ページなど、使い捨て可能な画面で適合を見ます。早く見えることと、本番品質であることは別なので、productionデータを使う前に保存先と認証を確認します。

一人で社内用の小さなworkflowを試すなら、Replit Agentなどworkspace型の使いやすさが候補になります。個人の試作を組織で使い始める段階では、ownerが個人アカウントのままにならないように、team access、backup、billing、退職時の移管を先に決めます。

既存のcodebaseへ追加する場合は、Cursorのようなrepo-aware環境を候補にします。現在のframework、test、build、branch運用を維持できるかを確認します。Cloud Agentは別VMでtaskを進められると案内されていますが、cloudで実行されるcommand、network、secretへのアクセス、書き戻し方法は利用環境の設定で確認します。

サービスの運用基盤が既にあるなら、UI生成とbackendを切り離します。LovableやBoltなどが既存backendとの接続やsource controlを提供する場合も、どの部分が外部providerに残り、どの部分が自分のrepositoryへ入るかを小さなprototypeで確かめてから選びます。

最初に作る仕様メモ

生成前に、以下のような短いspecを埋めます。これがないと、AIは目に見えるUIへ作業を寄せ、データや権限の要件を空欄のままにしがちです。

利用者：誰が、どの認証方法で使うか

主要操作：利用者が入力し、何を受け取り、どの操作を完了するか

データ：どのfieldを保存し、何を保存しないか

権限：本人、team、adminのどの単位で読取・更新できるか

backend：database、file storage、external APIの所有者

公開範囲：preview、社内、公開serviceのどこか

引き渡し：repository、domain、database export、運用owner

合格条件：画面、権限、失敗時、削除、mobile、testをどう確認するか

例として「社内問い合わせ一覧」を作るなら、prototypeでは架空データを使い、利用者が担当外のrecordをURL変更で読めないことをacceptance criteriaにします。画面が表示されるだけでは完了にせず、認証がない状態、別のuser、削除済みrecordも検証対象に含めます。

出力後の受け入れchecklist

生成物をproductionへ出す前に、最低限次を確認します。

1. Authenticationとauthorizationを分ける。 Loginできることだけでなく、各recordを誰がread / update / deleteできるかをtestします。

2. 秘密情報を確認する。 API keyやdatabase credentialがbrowser bundle、Git history、公開logへ出ていないか調べます。

3. Data flowを図にする。 Formからdatabase、外部API、analyticsまで、送信先と保持者を確認します。

4. 入力を検証する。 空欄、長文、特殊文字、意図しないHTML、繰り返し送信を試します。

5. Failure pathを試す。 network断、API error、権限不足、database unavailableで、誤った成功表示やdata lossが起きないか確認します。

6. テストと差分を読む。 生成したtestが実際の要件を検証するか見て、test / buildを実行し、変更fileをreviewします。

7. 復旧を確認する。 database backup、source control、domain、deploy履歴、退避・復元手順を決めます。

8. 費用を分解する。 builder planだけでなく、hosting、database、storage、外部API、agent usage、team member費用を確認します。

9. 権利と個人情報を確認する。 利用者データや第三者素材を入れる場合は、契約・社内規程・同意条件を確認します。

10. ownerを定める。 deploy後のupdate、incident、account access、billing、domain renewalを誰が担当するか決めます。

「作れた」と「運用できる」の境目

AI生成のprototypeでは、見える一連の操作だけをつなげても、永続化やaccess controlが不完全な場合があります。デモのデータがbrowser local stateだけにあるのか、server databaseに保存されるのかを確認してください。admin画面やAPI endpointが隠れているだけで保護されていない場合もあります。認証とauthorizationは別々に検証します。

また、builder内でdeployできることが、将来の移行容易性を保証するわけではありません。repositoryへsourceを出せるか、database schemaとfileをexportできるか、独自domainや外部backendを使えるか、退会時にどのdataを取得できるかを確かめます。migrationの必要性が低い短命prototypeなら、制約を理解した上で内蔵サービスを使う判断もできます。数年運用するserviceなら、最初の便利さだけでなくdata portabilityとownerを決めます。

AIものさしの判断

試作を最短で見たい人は、prompt-driven builderを小さく試し、prototypeが保存するdataと利用者を限定してください。既存repositoryの変更なら、frameworkとtestを保ったままdiffをreviewできるcodebase向けagentが自然です。どちらを選んでも、authentication、authorization、secret、data flow、復旧、ownerの確認が済むまでは「production ready」と扱わないのが安全です。

二つの候補で迷う場合、同じ仕様メモと架空データを渡し、①必要な画面が出るか、②権限条件を実装できるか、③diffとtestを確認できるか、④sourceとdataを持ち出せるか、⑤費用の単位が予測できるかを比べます。見栄えだけで決めず、運用責任を引き受けられる構成を選んでください。