「AIでアプリが作れるらしいから、比較してツールを決めておいて」。この一言から始まった調査が、機能一覧の表を作った時点で止まる——という経験をされた方は少なくないはずです。どのツールも「自然言語でアプリが作れる」と書いてあり、丸が並ぶだけで差が見えません。

差が見えない理由は単純です。機能の有無で比べているからです。このカテゴリのツールは、想定している利用者と、開発のどの工程を担うかがそれぞれ違います。同じ土俵に並べれば、当然どれも似て見えます。

この記事では、AIアプリビルダーというカテゴリを定義したうえで、主要ツールの守備範囲を整理し、企業が選定に使うべき5つの基準を示します。価格と機能は2026年9月1日時点で各社の公式ページを確認した内容であり、この領域は更新が速いため、実際の選定時には必ず一次情報を再確認してください。

AIアプリビルダーとは、どのカテゴリを指すのか？

言葉の定義から始めないと、比較対象がずれます。実際、同じ記事の中でコードエディタとアプリビルダーが混在していることは珍しくありません。

本記事では、自然言語による指示からアプリケーションを生成し、動作する状態まで到達できるツールをAIアプリビルダーと呼びます。判定の基準は、コードを書かない人が単独で「動くものを人に見せられるか」です。この基準に照らすと、既存のコードベースを前提としたエディタは別カテゴリになります。

もうひとつの軸が、バックエンドを含むかどうかです。ログイン、データ保存、ファイル添付といった業務アプリに必須の要素を追加契約なしに扱えるかは、実務での使い勝手を大きく分けます。画面だけを生成するツールと、データベースまで面倒を見るツールでは、到達できる距離が違います。

主要ツールは、どう棲み分けているのか？

ここでは代表的な5つを取り上げます。並べ方は優劣ではなく、想定利用者と守備範囲の違いです。自社の状況に近い行を先に見てください。

この表で最初に気づいていただきたいのは、最下段のCursorだけカテゴリが異なる点です。冒頭の定義に照らせばアプリビルダーではありませんが、比較記事に必ず登場するため、あえて含めました。競合ではなく、要件が固まった後に引き継ぐ相手として位置づけるのが実務的です。

もうひとつ、価格欄を横に読むと通貨が揃っていないことが分かります。Lovableはユーロ建ての税込表示、他はドル建てです。日本企業にとっては、この時点で為替と税の扱いが論点になります。機能比較の表には現れませんが、稟議では確実に問われます。

企業が選ぶとき、どの基準で見るべきなのか？

個人利用なら「使いやすいか」で選べます。組織で使う場合、選定を左右するのは別の5点です。順に見ていきます。

基準1：作ったコードは、自社の資産として残るか

最初に確認すべきはここです。ツールから取り出せない成果物は、本番化の段階で必ず作り直しになります。

Lovableは公式FAQでプロジェクトとコードの所有者が作成者自身であると明記し、GitHubとの双方向同期に対応しています。ローカルにクローンして外部エディタで編集した内容も、同期中のブランチにプッシュすれば戻ります。他社ツールでも同様の仕組みを持つものはありますが、対応の粒度は異なるため、選定時には「エクスポートできるか」ではなく「継続的に同期できるか」で確認してください。

この基準が効くのは、検証で終わらせない場合です。試作が資産として残るかどうかは、2年後の意思決定の自由度を決めます。

基準2：学習利用と統制は、契約で担保できるか

情報システム部門の審査で最も時間がかかる論点です。重要なのは「オプトアウトできるか」ではなく「既定でどうなっていて、それが契約で担保されているか」です。

Lovableの公式ドキュメントによれば、2026年9月9日以降、FreeプランとProプランの顧客データはモデル学習に利用される可能性があり、個人がアカウント設定からオプトアウトできます。一方、BusinessプランとEnterpriseプランのワークスペースデータは契約にもとづき既定で学習対象外です。v0ではBusinessで学習オプトアウトが既定、Enterpriseではデータが学習に使われないと記載され、Cursorはプライバシーモードの有効化でコードのデータが学習に使われないとしています。

比較の要点は、設定依存か契約担保かという構造の違いです。数百人が使う環境で「各自が設定する」運用は成立しません。ここは必ず上位プランの条件で比べてください。

基準3：調達の形は、自社の購買プロセスに合うか

機能で選んだ後に購買部門で止まる、という失敗を避けるための基準です。標準プランはいずれもカード決済・外貨建てが前提で、年度予算と請求書払いを前提とする日本の購買とは噛み合いません。

各社ともEnterpriseで条件を個別化する形を取っています。Cursorは請求書・発注書（PO）による支払いを明記し、Boltは柔軟な請求・調達オプションに言及、Lovableは年間コミットメントを伴うカスタム契約価格で、クレジット量・シート上限・年次の請求条件をカスタマイズできるとしています。日本円での請求書払いや年間契約を求める場合は、国内パートナー経由という選択肢もあります。

基準4：導入後、誰が使い続けられるか

見落とされやすい基準です。最も高機能なツールが、最も使われないという結果は珍しくありません。

判断材料は、対象業務を担っている人がそのツールを触れるかどうかです。エンジニア向けに設計されたツールを業務部門に配れば、結局エンジニアが代行することになり、内製化の目的が達成されません。逆に、既にエンジニアが主体の組織で非エンジニア向けツールを選ぶと、既存の開発フローと二重管理になります。

もうひとつが管理画面の言語です。Lovableを含む主要ツールのエディタUIと公式ドキュメントは英語で提供されており、日本語UIの提供は確認できていません。ITリテラシーの幅が広い組織へ一斉展開する場合、初期トレーニングか日本語の操作手順書を誰が用意するかを、展開計画に含めてください。

基準5：既存システム・CRMと繋がるか

業務アプリが単独で完結することはまれです。顧客情報や案件情報を参照できなければ、結局は二重入力の道具になります。

確認すべきは、API経由の接続が可能か、認証情報を安全に保管できるか、そして接続の方式が情報システム部門の審査を通るかです。鍵をフロントエンドに置く構成は、動作はしても審査を通りません。バックエンドの関数経由で扱う設計になっているかを確認してください。

この観点では、組み込みバックエンドを持つツールが有利です。シークレット管理とサーバー側の処理が最初から用意されているため、安全な構成を素直に作れます。

課金モデルの違いは、何を意味するのか？

価格の数字より、課金の構造のほうが導入後の運用を左右します。3つの型があり、それぞれ予算化の難易度が違います。

2行目を選ぶ場合、稟議の書き方が変わります。「月◯円」と書けないため、実測値から積み上げる必要があるからです。試用期間中に対象業務のアプリを1本作り、その消費を記録しておくと、以降の説明がすべてその数字を根拠にできます。Lovableの場合は、構築だけでなくホスティングとバックエンドの稼働、公開後のAI呼び出しも消費対象なので、公開後の実測も併せて取ってください。

あわせて、上限を設定できるかを確認してください。上限があれば「想定外の請求は発生しない」と説明でき、購買部門の懸念の大半はここで解消します。

用途別には、どう選べばよいのか？

ここまでの基準を、よくある状況に当てはめます。自社に近い行から読んでください。

最下段だけは、他の行と評価軸が違います。ここでは生成の品質より、ワークスペース全体を監視できるか、退職者のアカウントが自動で整理されるか、公開できる人を制限できるかといった運用の機能が決め手になります。全社展開を見込むなら、最初の比較の時点で上位プランの条件を並べてください。

比較表に現れない「見えないコスト」は何か？

機能と月額を並べた表には出てこないのに、導入後の総額を左右する項目が3つあります。選定の最終段階では、ここを確認したかどうかで差がつきます。

第一が、公開後の稼働費用です。多くのツールは「作る」ための費用が前面に出ますが、業務アプリは作った後に使われ続けます。Lovableの場合、データベースサーバーの稼働、保存容量、ネットワーク、ストレージ、バックエンド処理、リアルタイム更新のメッセージが継続的に消費対象となります。利用者数に比例するため、導入初月の実績だけで年間を推計すると過小になります。

第二が、後から変更できない選択のコストです。たとえばLovableでは組み込みバックエンドと自前Supabase接続の間に自動マイグレーションがなく、どちらの方向にも移行できません。同様の非可逆な選択は他ツールにも存在します。比較の段階で「何が後から変えられないか」を各社に確認しておくと、将来の作り直しを避けられます。

第三が、レビューの工数です。生成されたアプリは、画面が正しく表示されることと権限設計が正しいことが別問題です。公開時の自動スキャンのような機能を持つツールもありますが、業務上「誰に見せてよいか」の判断は人が担います。実際、2025年に登録されたCVE-2025-48757は生成物の行レベルセキュリティ設定をめぐるもので、NVDの記載には各利用者が自身のアプリのデータ保護に責任を負うという理由でベンダーが争っている旨も併記されています。責任分界の議論は、どのツールを選んでも残ります。

この3項目を月額に足して初めて、比較可能な総額になります。表の数字だけで決裁を取ると、翌年度に説明のつかない差額が出ます。

選定でよくある間違いは何か？

最後に、実際に手戻りを生んでいる判断の型を挙げます。いずれも一見合理的に見えるのが厄介な点です。

第一に、機能数で選ぶこと。このカテゴリでは機能の網羅性より、想定利用者との一致のほうが定着を左右します。第二に、無料枠の大きさで選ぶこと。無料枠は評価のためのものであり、業務データを扱う運用では学習利用の既定値と統制機能が判断軸になります。

第三に、1つに決めようとすること。要件が固まる前の工程と、本番のコードを育てる工程は別のツールが担って構いません。第四に、比較表を作った時点で満足すること。表で差が出ないのはこのカテゴリの性質であり、最終的な判断材料は自社の業務で1本作った実測にしかありません。

ツール選定の壁打ち、情報システム部門向けの説明資料の整備、日本円での法人契約に関するご相談は、株式会社100のLovable公式パートナーページで承っています。

よくある質問（FAQ）

結局どれが一番おすすめですか？

用途によって答えが変わるため、一律の推奨はできません。部門業務のアプリ化で非エンジニアが主体なら組み込みバックエンドを持つツール、既存システムの改修が中心ならエディタ、というのが最も外れにくい判断です。

無料プランだけで比較評価してよいですか？

操作性の比較には使えますが、法人としての判断はできません。SSO、監査ログ、学習利用の既定値といった判断材料が無料プランには含まれないためです。最終判断は上位プランの条件で行ってください。

各社の価格や機能はどのくらいの頻度で変わりますか？

この領域は更新が速く、数か月単位で条件が変わります。本記事の内容も2026年9月1日時点の確認結果です。稟議に載せる数値は、必ず提出直前に各社の公式ページで再確認してください。

社内に「AIが作ったコードは信用できない」という反対意見があります。

反対意見自体は妥当です。生成物がコードである以上、レビュー・テスト・保守の責任は残ります。論点を「使うか否か」ではなく「どの業務まで開放し、どこから人が点検するか」に置き換えると、議論が前に進みます。

選定後、何から着手すべきですか？

部門内で完結し、扱うデータの機微性が低い業務を1つ選び、実際に作ってみてください。IPAが2026年7月に公表した国内企業のDX・AI活用動向でも、AI導入は広がる一方で価値創出への発展が課題とされています。小さくとも数値で語れる成果を先に作ることが、次の意思決定を軽くします。

まとめ：機能ではなく、5つの基準で選ぶ

AIアプリビルダーの比較が決着しないのは、機能の有無で比べているからです。このカテゴリのツールは想定利用者と守備範囲が異なるため、同じ軸に並べれば差は出ません。

企業が使うべき基準は5つです。コードが自社資産として残るか、学習利用と統制が契約で担保されるか、調達の形が自社の購買プロセスに合うか、対象業務の担当者が使い続けられるか、そして既存システムと安全に繋がるか。課金の型（座席・トークン／クレジット・併用）も、予算化の難易度を左右するため合わせて確認してください。

そして最終的な判断材料は、比較表ではなく自社の業務で1本作った実測です。作成にかかったコスト、公開前の権限確認にかかった時間、そして対象業務が本当に形になったかどうか。この3つの数字があれば、どのツールを選んでも社内を説得できます。

Lovableについての詳細はLovableとは？できること・料金・使い方を日本公式パートナーが徹底解説を、選定のご相談は株式会社100の問い合わせ窓口をご利用ください。