「Lovableでスマホアプリを作れますか」という質問には、2つの意味が混ざっています。スマートフォンで快適に使える業務システムを作りたいのか、App StoreやGoogle Playに並ぶアプリを出したいのか。答えが正反対になるため、まずここを切り分ける必要があります。
この質問が出る場面はだいたい共通しています。工場や店舗、外回りの営業のように、パソコンの前にいない人が使う業務があり、その人たちに使わせる何かを早く作りたい。要件としては妥当ですが、「アプリを作る」という言葉で議論を始めると、ストア申請やネイティブ開発の話に流れて止まります。
この記事では、Lovableでモバイル向けに何が作れて何が作れないのかを公式ドキュメントの記述にもとづいて確定させ、そのうえで業務要件から逆算した選び方を示します。2026年9月10日時点の公式情報にもとづきます。仕様は変更される可能性があるため、判断の前には最新の記載をご確認ください。
結論を先に置きます。作れません。公式が明示的に否定しています。
Lovableの公式FAQには「Does Lovable support mobile app development?」という設問があり、回答は次のとおりです。
Lovable builds web applications, and you can design them to be fully mobile friendly. Lovable does not generate React Native projects. If you want an installable app on phones, there are two common paths: make your published app a Progressive Web App (PWA) that users add to their home screen, or wrap your published app with a tool like Capacitor to submit it to the App Store or Play Store.
ここから確定するのは3点です。第一に、Lovableが作るのはWebアプリケーションであること。第二に、React Nativeのプロジェクトは生成しないこと。第三に、スマートフォンにインストール可能な形にする経路は公式が挙げる2つ、つまりPWA化とCapacitor等でのラップだということです。
公式のプラットフォーム紹介でも、Lovableは自然言語でWebアプリケーションを構築・改善・デプロイするフルスタックのAI開発プラットフォームと説明されています。モバイルアプリ開発ツールとしては位置づけられていません。
検索していると「Lovable モバイルアプリ」という情報に行き当たりますが、これは別の話です。Lovable自身が提供しているモバイルアプリのことで、スマートフォンからLovableを操作してプロジェクトを進めるためのものです。作ったアプリがネイティブアプリになるという意味ではありません。
公式ドキュメントによると、このモバイルアプリでできるのは「Build, prompt, and review your Lovable projects from your phone or tablet」です。新規プロジェクトの開始、既存プロジェクトの継続、音声や画像を使ったプロンプト入力、ビルド完了時の通知受け取りが挙げられています。対応OSはiOS 15以降（iPhoneとiPad）とAndroid 9以降で、ダウンロード自体は無料、プランとクレジットはLovableアカウントと共有されるとされています。
一方で、モバイルアプリではできないことも明記されています。新規アカウントの作成、OAuth連携の接続、Androidでのアプリ内課金は対象外で、詳細なコードレビューやプレビューのツールバー、プレビュー上のインラインコメントは広い画面が必要とされています。さらに「Lovable needs an active connection. There's no offline editing.」とあり、オフラインでの編集はできません。iOSアプリ内で購入したプランは1か月分をカバーし、自動更新はしないという記述もあります。
この混同は社内の議論でも起こります。「Lovableにモバイルアプリがあるらしい」という情報が、「Lovableでモバイルアプリが作れる」に変換されて伝わることがあります。稟議書に書く前に、どちらの話なのかを確認してください。特にiOSアプリ内で購入したプランが自動更新しない点は、経理処理の前提が変わるため、法人での利用では注意が必要です。
2つの経路のうち、業務システムで現実的なのはPWAです。ただし制約を知らずに選ぶと、後から要件を満たせないことが分かります。
PWA（Progressive Web App）は、Webアプリをホーム画面に追加して、ブラウザのアドレスバーなしで全画面表示できる仕組みです。MDNのPWAドキュメントとweb.devのPWA解説に技術的な要件がまとまっています。
業務システムの観点で重要なのは次の点です。ホーム画面のアイコンから起動でき、アプリ切り替え画面に現れるため、利用者からは通常のアプリと同じ操作感になります。ストアの審査を通す必要がなく、更新もサーバー側で完結します。Chrome DevToolsのPWA検証機能で、インストール可能かどうかを開発中に確認できます。
更新がサーバー側で完結する点は、業務システムでは大きな利点です。ストア配布のアプリでは、修正を配るたびに審査と利用者側の更新操作が必要になります。数百人が使う業務アプリで「古いバージョンを使い続けている端末」が混在すると、問い合わせ対応が煩雑になります。
できないことを先に確認しておかないと、要件定義が後戻りします。私たちが業務要件を聞くときに必ず確認するのは3点です。
| 要件 | 確認すべきこと |
| オフラインでの利用 | 電波の届かない場所（倉庫の奥・地下・山間部）で入力する業務があるか。オフライン動作の実装難易度は、要件の深さで大きく変わる |
| 端末機能へのアクセス | バーコード読み取り、NFC、Bluetooth機器との接続、バックグラウンドでの位置情報取得があるか。ブラウザから使える範囲はOSとブラウザのバージョンに依存する |
| プッシュ通知 | 通知が業務の起点になっているか。実装可否と挙動はOSごとに差がある。LovableではFirebase Cloud Messaging連携のドキュメントがある |
この3点のいずれかが業務の中核にある場合、PWAだけでは要件を満たせない可能性があります。そのときにCapacitorでのラップやネイティブ開発を検討します。逆にどれも該当しないなら、PWAで十分です。
実務では、この確認を飛ばして「アプリなんだからオフラインでも動くだろう」と期待されているケースがあります。要件として明示されていないのに前提になっている項目なので、聞き出しておく必要があります。
公式FAQが挙げるもう一つの経路です。ストア配布が必要なケースは限られますが、必要な場合は作業が増えます。
Capacitorは、Webアプリをネイティブアプリの器に包んで、iOSとAndroidのアプリとしてビルドできるようにするツールです。公式FAQの表現では「wrap your published app with a tool like Capacitor to submit it to the App Store or Play Store」となっています。
ここで理解しておくべきなのは、ラップした後の作業がLovableの外側で発生することです。具体的には、iOS向けにはXcodeでのビルドと署名、Android向けにはビルドと署名が必要になり、そのためにApple Developer Programの登録とGoogle Play Consoleのアカウントが必要です。この工程はWeb開発とは別の技能領域です。
コードの取り出しはGit同期で行います。GitHub連携を設定しておけば、生成されたコードが自社リポジトリに入るので、そこからラップの作業に入れます。
Webアプリをそのまま包んだアプリは、審査で指摘を受けることがあります。AppleのApp Store Reviewガイドラインには、アプリが提供する価値と体験に関する要求が含まれており、Webサイトを単に包んだだけのアプリは審査の観点になります。Appleが公開しているガイドラインの概要もあわせて確認してください。
AndroidについてはGoogle PlayのデベロッパープログラムポリシーとPlay Consoleのヘルプで要件を確認できます。
ここで整理しておくと判断が早くなります。ストア配布が必要なのは、社外の一般利用者に配る場合です。社内の従業員だけが使う業務アプリであれば、ストアを経由する必要はありません。むしろストアを経由すると、審査の期間と却下のリスク、更新のたびの手間が加わります。社内利用が前提なら、PWAで配布したほうが速く、運用も軽くなります。
従業員向けにネイティブアプリを配りたい場合は、法人向けの配布手段（各OSの組織向け配布の仕組み）を使う経路もありますが、いずれも情報システム部門側の準備が必要です。この準備工数が、PWAとの比較で最も差が出る部分です。
要件から逆算します。技術の比較から始めると決まりません。
| 業務の状況 | 適した形 | 理由 |
| 社内の従業員が使う。常時通信あり | PWA | ストア審査が不要で、更新がサーバー側で完結する |
| 社内利用だが通信が不安定な現場がある | PWA＋オフライン設計、または既存の業務アプリ | オフライン要件の深さで実装難易度が変わる。要件を先に確定させる |
| バーコード・NFC・Bluetooth機器が業務の中核 | Capacitorでのラップ、またはネイティブ開発 | 端末機能へのアクセス範囲がブラウザでは制約を受ける |
| 社外の一般利用者に配る | ストア配布（Capacitor等でラップ） | 配布経路としてストアが期待される。審査と運用体制が必要 |
| まず要件を確かめたい段階 | Lovableでモバイル対応のWebアプリ | 動くものを早く出して、要件の抜けを実物で洗い出せる |
最後の行が実務では最も多い状況です。要件が固まっていない段階でストア配布を前提に見積もると、金額が跳ね上がって稟議が通りません。まずWebアプリで作って現場に触らせ、そこで「本当に必要だったこと」を確定させてから、配布方式を決める順序が現実的です。
この進め方そのものについてはMVP開発完全ガイド｜企画・費用・検証の進め方と、大企業で失敗する5つの理由で扱っています。要件が固まる前に配布方式を決めることが、手戻りの主な原因になります。
PWAを選ぶ場合も、Webアプリだからといって設計項目が減るわけではありません。むしろ現場で使うアプリ固有の論点が出てきます。
現場の端末が共用か個人持ちかで設計が変わります。共用端末では、ログインの手間が利用率を直接下げます。個人端末では、業務データが個人の端末に残ることの扱いを決める必要があります。
Lovableでは組み込みバックエンド（Cloud）のユーザー認証機能で、メール・電話番号・Google・Apple・Microsoft・SAML SSOに対応しています。既存の社内IDと繋ぐ場合はSAMLシングルサインオンのドキュメントを確認してください。社内IDと繋いでおくと、退職・異動時のアクセス停止が既存の運用に乗ります。
モバイルで使うアプリは、通信環境の影響を受けます。データベースの機能とLovable Cloudをそのまま使うか、自前のSupabaseを使うかは、モバイル要件とは別に決める論点です。判断基準はLovableのデータベースはどう持つ？Cloudと自前Supabaseの選び方で整理しています。
稼働費用の見積もりも必要です。公式のプロジェクト利用状況のドキュメントによると、プロジェクトの使用量は「利用者が増えたとき」および「データやファイルの保存量が増えたとき」に増加するとされています。モバイル向けアプリは利用者数が多くなりやすいため、この点は事前に確認すべき項目です。同ドキュメントでは、Free・Pro・Businessのワークスペースに月次20クレジットのCloud grantと月次4クレジットのAI grantが付与されると記載されています。
スマートフォンから使うアプリは、社外のネットワークからアクセスされます。社内ネットワークに閉じている前提が崩れるため、点検項目が増えます。
Lovableにはセキュリティスキャンの機能があり、セキュリティのベストプラクティスにはフロントエンド・Edge Functions・行レベルセキュリティ（RLS）・認証に関する指針がまとまっています。ただし自動スキャンで代替できない項目があります。認証していない訪問者に何が見えるかの確認は、人が実際に試す必要があります。公開前の具体的な点検項目はLovableのセキュリティは何が危険か？公開前RLS設定チェックリスト23項目で整理しています。
Web公開の一般的なリスクについてはIPAの安全なウェブサイトの作り方が基礎資料として使えます。動作の確認にはログ機能を、大きな変更の前にはPlan modeで実装前に方針を固める運用が有効です。
費用と体制の話として整理しておきます。稟議での比較材料になります。
Web公開だけなら、必要なのはLovableの利用料と稼働費用です。プランと単価は公式のプラン仕様と料金ページで確認できます。
ストア配布を選ぶと、これに以下が加わります。Apple Developer ProgramとGoogle Play Consoleの年額費用、ビルドと署名を行う技能と環境、審査への対応工数、そして更新のたびに発生する審査と配信の作業です。さらに、審査で却下された場合のリスケジュールも見込む必要があります。
業務アプリで社内利用に限るなら、これらはすべて不要な費用です。「アプリを作る」という言葉から自動的にストア配布を想定してしまうと、必要のない工程を最初から抱えることになります。まず配布範囲を確定させ、そこから配布方式を決めてください。
費用の全体像の考え方はAIアプリ開発の進め方・費用・会社選び｜7ステップと発注前チェックリストで扱っています。
作れません。公式FAQに「Lovable does not generate React Native projects」と明記されています。Lovableが生成するのはWebアプリケーションです。スマートフォンにインストールできる形にする場合は、PWA化するか、Capacitor等でラップしてストアに申請する経路になります。
ホーム画面への追加による利用は可能です。ただしPWAで使える機能の範囲はOSとブラウザのバージョンに依存し、プッシュ通知やバックグラウンド処理などは挙動に差があります。通知や端末機能が業務の中核にある場合は、対象とする端末とOSバージョンを先に確定させ、実機で確認してから要件を確定させてください。
ありません。ストア配布が必要になるのは、社外の一般利用者に配る場合です。社内利用であればPWAとして配布したほうが速く、更新もサーバー側で完結します。ストアを経由すると審査期間と却下のリスク、更新ごとの作業が加わります。
要件の深さによります。閲覧のみをオフラインで可能にするのと、オフラインで入力したデータを後から同期するのでは、実装の難易度が大きく変わります。後者は競合の解決（同じデータを複数の端末で編集した場合の扱い）の設計が必要になるため、要件として本当に必要かを先に確認してください。倉庫や地下など通信が届かない場所での入力が業務の中核にある場合は、Lovable以外の選択肢も含めて検討する段階です。
Lovableが提供しているモバイルアプリは、スマートフォンからLovableを操作してプロジェクトを進めるためのものです。作ったアプリがネイティブアプリになるという意味ではありません。この2つは別の話なので、社内で情報が伝わる過程で混同されていないか確認してください。
できます。コードをGit同期で自社リポジトリに置いておけば、そこからCapacitor等でのラップに進めます。ただしラップ後の作業（ビルド・署名・審査対応）はLovableの外側で発生するため、その工程を担う体制が必要です。要件が固まっていない段階では、まずWebアプリで現場に触らせ、配布方式は後から決める順序が現実的です。
個別の判断は審査時点のガイドラインによります。AppleのApp Store Reviewガイドラインには、アプリが提供する価値と体験に関する要求が含まれており、Webサイトを単に包んだだけのアプリは審査の観点になります。ストア配布を前提にする場合は、申請前に最新のガイドラインを確認し、却下された場合のスケジュールも見込んでおいてください。
Lovableが生成するのはWebアプリケーションで、React Nativeのプロジェクトは生成しません。これは公式FAQに明記されている事実です。スマートフォンにインストール可能な形にする経路は、公式が挙げる2つ、つまりPWA化とCapacitor等でのラップです。
業務システムとして現実的なのはPWAです。ストア審査が不要で、更新がサーバー側で完結するため、数百人が使う業務アプリでもバージョンの混在が起きません。一方で、オフライン動作、端末機能へのアクセス、プッシュ通知の3点が業務の中核にある場合は、PWAだけでは要件を満たせない可能性があります。この3点を先に確認してください。
ストア配布が必要になるのは、社外の一般利用者に配る場合です。社内の従業員だけが使うのであれば、ストアを経由する理由はありません。「アプリを作る」という言葉から自動的にストア配布を想定すると、Apple Developer ProgramやGoogle Play Consoleの費用、ビルドと署名の技能、審査対応の工数といった、必要のない工程を最初から抱えることになります。
したがって判断の順序は、①誰に配るのかを確定させる、②オフライン・端末機能・通知の3点を確認する、③それから配布方式を決める、になります。要件が固まる前に配布方式から決めると、見積もりが膨らんで稟議が止まります。
モバイル前提の業務アプリの要件整理や、認証・データ設計を含めた導入のご相談は、株式会社100のLovable公式パートナーページで承っています。
本記事の仕様に関する記述は2026年9月10日時点でLovableおよび各プラットフォームの公式ドキュメントから取得したものです。PWAで利用できる機能の範囲とストアの審査要件は変更される可能性があるため、判断の前には最新の記載をご確認ください。