稟議書の最終確認をしている段階で、多くの担当者が一度だけやることがあります。ツール名に「評判」を足して検索するのです。機能も料金もセキュリティ資料も揃えた。それでも、承認者に「これ、実際のところどうなの」と聞かれたときに答えられる材料が欲しい。
ところが検索して出てくるのは、絶賛か酷評のどちらかに寄った記事です。「もう開発会社は要らない」と書いてある記事と、「危険だから使うべきでない」と書いてある記事が並んでいて、どちらも自社の状況には答えていません。
この記事では、Lovableの評価が割れる理由を、検証可能な事実だけを使って分解します。株式会社100は日本公式パートナーですが、その立場で書けない不都合な点こそ、ここでは明示します。誇張した推奨は、稟議を通したあとに必ず跳ね返ってくるからです。
個人の感想の前に、検証可能な指標から始めます。資金調達と収益の数字は、少なくとも「一過性の流行で終わるか」の判断材料にはなります。
TechCrunchの2026年8月12日の報道によれば、LovableはMenlo VenturesとScaleup Europe Fundが主導するシリーズCで4億ドルを調達し、評価額は133億ドルとなりました。2025年12月のラウンドが3億3,000万ドル・評価額66億ドルだったため、約8か月で評価額が2倍以上になった計算です。同報道では、2026年6月時点で年間収益ランレートが5億ドルに達したとされています。会社側の発表は公式ブログにあります。
これは「良いツールである」ことの証明ではありません。資金調達額と製品の実用性は別の話です。ただし、企業が3年契約を結ぶ際に気にする「サービスが数年後に存続しているか」という論点については、一定の材料になります。逆にいえば、この数字を根拠に品質を語る記事は、論点をすり替えています。
肯定的な評価は、ほぼ一点に集約されます。要件が固まる前に、動くものが出てくるという点です。
従来の業務システム開発では、要件定義を終えてから実装に入るため、動くものを見られるのは数か月後でした。使ってみて「思っていたのと違う」と分かるのは、費用がほぼ確定した後です。Lovableのようなツールが変えたのはこの順序で、先に動くものを出し、それを見ながら要件を確定できます。
もうひとつが、成果物がコードとして残る点です。公式FAQはプロジェクトとコードの所有者について作成者自身であると明記しており、GitHubへの同期にも対応しています。ノーコードツールで作ったものがそのツールから出せないのに対し、資産として持ち出せる構造になっているという違いです。
組織で使う観点では、統制機能が短期間で厚くなった点も評価されています。セキュリティセンター（Business以上）、SSO、EnterpriseでのSCIM・監査ログ・データレジデンシーなど、大企業の審査項目に対応する機能が揃ってきています。
ここが本題です。批判の中身を正確に把握しないまま導入すると、同じ問題を自社で再現することになります。
最も重い指摘は、生成されたアプリの権限設計に関するものです。NVDに登録されたCVE-2025-48757は、2025年5月30日に公開され、生成されたサイトの行レベルセキュリティ（RLS）ポリシーが不十分なため、遠隔の認証されていない攻撃者が任意のデータベーステーブルを読み書きできる可能性があるとしています。対象は「2025年4月15日までのLovable」で、CVSS 3.1の基本値は9.3、深刻度はCriticalです。
ただし、この登録には重要な但し書きが付いています。NVDの記載によれば、この件はベンダーによって争われており、その理由として「Lovableプラットフォームの各利用者が、自身のアプリケーションのデータを保護する責任を引き受けている」ことが挙げられています。
この争点は、責任分界の問題として読むべきです。ツールが安全な既定値を提供すべきなのか、利用者が権限設計を行うべきなのか。実務的には、どちらの立場を取るにせよ「公開前に権限を確認する工程を誰かが担う」ことが必要だという結論は変わりません。ここを空欄にしたまま現場に配ることが、実際の事故の原因になります。
なお現在は、公開ダイアログを開くとBasic Scanが自動実行され、RLSポリシーのリンティングやデータベースの設定ミスを検査します。条件を満たす検出結果は自動修正の対象になるとされ、より詳細なエージェント型のコードレビューであるDeep Scanも手動で実行できます。いずれも手動実行では無料でクレジットを消費しません。2025年時点の批判をそのまま現在の評価として引くのは正確ではありませんが、自動検査が業務判断まで代替するわけでもありません。
妥当です。公式ドキュメントによれば、クレジットはアプリを計画・生成・編集するBuild usage、ホスティングと組み込みバックエンドを動かすCloud usage、公開後のアプリが実行時に呼ぶAI gateway usageの3種類で消費され、いずれも使い方によって変動します。
とくに実装を担うBuild modeは使用量ベースで、変更ファイル数やロジックの複雑さ、コード探索量によって消費が変わります。指示が粗ければ手戻りが増え、そのまま費用に跳ね返る構造です。「同じものを作ったのに人によって費用が違う」という不満は、この仕組みから生じています。
緩和策はあります。Plan modeはメッセージあたり1クレジット固定で、コードを書かずに計画を提示します。「決める」工程を固定費で回せば変動幅は小さくなります。また課金体系は2026年6月13日にビルド用とCloud/AI用のクレジット残高が統合され、メンバー別・プロジェクト別・用途別に支出を可視化するページが提供されるようになりました。それでも「月額固定」ではない点は変わりません。
評判の記事に書かれにくい、しかし導入後に効く制約が3つあります。いずれも公式ドキュメントに明記されている事実です。
第一に、エディタのUIと公式ドキュメントは英語です。2026年9月1日時点で、UI表示言語を日本語に切り替える設定は公式ドキュメント上に記載が見当たりません。AIへの指示は日本語で通り、生成されるアプリのUIも指示すれば日本語になりますが、管理画面と一次情報は英語です。
第二に、バックエンドの選択は後から変えにくい構造です。公式ドキュメントによれば、組み込みバックエンド（Cloud）と自前のSupabase接続の間には自動マイグレーション機能がなく、どちらの方向にも移行できません。スキーマの再構築とデータの手動移行が必要になります。最初の選択が後を縛るということです。
第三に、残高がゼロになるとビルドが止まるだけでなく、公開済みアプリのAI機能が動作しなくなり、組み込みバックエンドに依存するアプリは一時停止することがあります。データベース・ストレージ・認証のデータは保持されますが、利用者から見ればアプリは止まっています。
絶賛と酷評が同時に成立している理由は、評価者が見ている用途が違うからです。同じツールについて語っているようで、前提が噛み合っていません。
割れ方には規則性があります。3つの軸で整理すると、自分がどちらの評価に近い立場かを判断できます。
| 軸 | 好意的評価になりやすい立場 | 批判的評価になりやすい立場 |
|---|---|---|
| 用途 | 社内向け業務アプリ・検証用プロトタイプ | 外部公開の本番サービス・基幹システム |
| 体制 | 権限設計を確認できる人が組織内にいる | 作った本人しか触れる人がいない |
| 期待 | 要件確定を早めるための道具と捉えている | 開発工程そのものの代替と捉えている |
この表で決定的なのは3行目です。「開発が要らなくなる」と期待して導入すると、レビューも保守も設計されないまま本番に出て、事故が起きます。そして事故の原因は、ツールの品質ではなく期待の設定にあります。逆に「要件を早く固めるための道具」と位置づけた組織では、期待と実態が一致するため評価は安定します。
パートナーとして再販するだけでなく、自社の業務でも使っています。そこで実際に効いた点と、期待外れだった点の両方を書きます。
効いたのは、日本語プロンプトのみで社内向け管理ポータルを構築できた点です。左サイドバー固定のレイアウト構造、7ページ分のルーティング、ブランドカラーを16進数で指定したデザイントークン、和文と英字で異なるフォントの使い分け、初期表示用データの一括投入まで、すべて日本語の指示で意図どおりに実装されました。英訳は一度も挟んでいません。
期待外れだったのは、最初の設計を粗いまま進めたときの手戻りです。保持するデータの項目と選択肢を言語化せずに画面から作り始めると、項目を1つ足すだけで画面もデータベースも作り直しになります。これはツールの欠点というより、従来の開発でも同じことが起きる話ですが、「速く作れる」という感覚があるぶん、設計を飛ばす誘惑が強く働きます。
結論として、Lovableは設計を不要にする道具ではなく、設計の検証を速くする道具でした。この認識のずれが、そのまま評価の割れ方に対応していると考えています。
導入直後の評価と、1年後の評価は一致しません。そして下がるときの原因は、ほぼ決まっています。ツールの性能ではなく、運用の設計です。
最も多いのが、作った本人の異動です。アプリは業務に組み込まれたまま残り、中身を説明できる人がいなくなります。障害が起きたときに復旧できず、「あのツールは使えない」という評価に変わります。防ぐ方法は単純で、作る前に保守担当を登録することです。
次に多いのが、点検されないまま増えることです。セキュリティセンターでは各プロジェクトの最終スキャン日時が表示され、未点検のプロジェクトを検出できます。半期ごとの棚卸しに、この一覧を組み込むだけで状況は大きく変わります。認証・準拠の状況はトラストセンターで確認できます。
三つめが、作れる状態のまま使われないことです。IPAが2026年7月に公表した国内企業のDX・AI活用動向では、AI導入は着実に広がる一方で、業務効率化の段階から新たな価値創出へ発展させることが課題として示されています。導入の成否を決めるのは、ツールの評判ではなく、業務をどう変えるかの設計です。
判断を単純化するために、条件で切ります。自社がどちらに当てはまるかを先に確かめてから、費用の議論に進んでください。
| 観点 | 向いている | 現時点では向いていない |
|---|---|---|
| 作る対象 | 紙・Excelで回る部門業務、社内ダッシュボード、検証用の試作 | 会計・給与など基幹の中核、決済処理そのもの |
| 体制 | 権限設計を確認できる人がいる、保守担当を決められる | 作った人しか触れず、異動時の引き継ぎ計画がない |
| 調達 | 従量課金を上限設定込みで受け入れられる | 月額固定でなければ稟議が通らない |
| 言語 | 管理画面が英語でも運用できる、または伴走支援を使う | 全社員が日本語UIで自走する前提が必須 |
| データ | Business以上を契約し、学習利用を契約で除外できる | Free・Proのまま業務データを扱わざるを得ない |
右列に2つ以上該当する場合、導入そのものを見送るというより、該当項目を先に解消するほうが建設的です。とくに最下段は、2026年9月9日以降、Free・Proの顧客データがモデル学習に利用される可能性がある一方、Business・Enterpriseのワークスペースデータは契約にもとづき既定で学習対象外であるため、プランの選択だけで解消できます。
他人の評判は、自社の条件を反映していません。最終的な判断材料は、自社の業務で1本作ってみた結果にしかありません。
確かめるべきは3点です。第一に、対象業務が本当に形になるか。第二に、作成にどれだけのクレジットを消費したか。第三に、公開前の権限確認を誰がどれだけの時間で行えるか。この3点の実測があれば、稟議でも社内説明でも、他人の評判に依存せずに話せます。
無料で試す場合、Freeプランは1日5クレジット・暦月30までという枠があります。6日分の枠をどう配分するかを先に決めてから触ると、判断材料が残ります。
導入可否の壁打ち、情報システム部門向けの説明、日本円での法人契約のご相談は株式会社100のLovable公式パートナーページで承っています。
Lovableの評価が割れるのは、品質にばらつきがあるからではなく、評価者の用途と期待が異なるからです。社内向け業務アプリと検証用プロトタイプという用途では評価が安定し、外部公開の本番サービスや基幹システムを期待した立場では厳しい評価になります。
不都合な事実も明確です。生成物の権限設計をめぐる責任分界はCVEとして登録され、ベンダーが争う形で残っています。費用は従量で変動し、バックエンドの選択は後から変えられません。管理画面と一次情報は英語です。
一方で、公開前の自動スキャン、セキュリティセンター、SSOやSCIMといった統制機能は短期間で整備されました。したがって判断すべきは「評判が良いか」ではなく、自社の用途・体制・調達・言語・データの5条件に合うかどうかです。合わない項目があるなら、そこを先に解消してから導入してください。
Lovableの全体像はLovableとは？できること・料金・使い方を日本公式パートナーが徹底解説を、個別のご相談は株式会社100の問い合わせ窓口をご利用ください。