最初の1回は驚くほどうまくいきます。問題はその後です。「ここを少し直して」と3回頼んだころには、最初に気に入っていた部分まで変わっていて、どこをどう戻せばいいのか分からなくなる。Lovableを触り始めた人のほぼ全員が、この壁に当たります。

そして多くの場合、原因は「AIの性能」ではありません。指示の書き方です。何を変えてよくて何を変えてはいけないかを書いていないため、AIは触ってよい範囲を自分で推測し、推測を外します。

この記事では、Lovableの公式ドキュメントに記載された原則と、株式会社100が自社の社内ツールをLovableで構築した際に実際に使った指示の構造をもとに、手戻りを減らすプロンプトの型を整理します。

なぜ生成結果はブレるのか？

ブレの原因を「AIが賢くないから」と片づけると、対策が打てません。実際には、指示の情報量が足りないときにAIが空白を埋めた結果として、意図と違うものが出てきています。

公式のプロンプト・ベストプラクティスは、この点を「曖昧なアイデアは曖昧な出力を生み、明確な思考は明確な結果につながる」と表現しています。つまり、出力の質は入力の解像度の関数だという立場です。

もうひとつの原因が、変更範囲の未指定です。公式ドキュメントは、境界を示さなければ「小さな依頼が、すでに動いている部分にまで波及する」と明確に警告しています。3回目の修正で全体が崩れる現象は、まさにこれが積み重なった結果です。

初回プロンプトに必ず入れるべき4つの要素とは？

最初の1本をどう書くかで、その後の反復回数が決まります。公式ドキュメントは、プロンプトを送る前に「何を作るか」「誰のためか」「なぜ使うか」「重要なアクションは何か」の4点に答えることを推奨しており、この工程を飛ばすことを「何を描くか決めずに絵を描き始めるようなもの」と表現しています。関連する考え方は実践ガイドにも整理されています。

業務アプリに翻訳すると、押さえるべき要素は目的・画面・データ・制約の4つになります。この4つが揃っているかどうかは、書き終えたプロンプトを読み返せば機械的に判定できます。

4つのうち最も省略されやすいのが「データ」です。画面のイメージは語れても、保持する項目とその選択肢まで言語化している人は多くありません。しかしここが曖昧だと、後から項目を1つ足すだけで画面もデータベースも作り直しになります。

実例：社内ポータルを1本のプロンプトで立ち上げたときの構成

抽象論だけでは再現できないので、実際の構成を示します。株式会社100が自社の社内向け管理ポータルをLovableで構築した際、初回プロンプトは次のブロックで組み立てました。すべて日本語です。

冒頭に「何のための、誰が使うツールか」を2〜3行で置きました。次に「今回のスコープ」として、この1本で作る範囲を5項目に限定し、中身の実装は次のメッセージ以降で行うと明記しています。続いてデザイン仕様として、配色を16進数で列挙し、和文と英字で使い分けるフォント、カードの角丸と枠線の値まで指定しました。さらにナビゲーション項目とルーティングを列挙し、最後に初期表示用のデータを構造化した形で丸ごと貼り付けています。

この構成の要点は3つあります。第一に、1本目で全部を作らせず「骨格だけ」と範囲を切ったこと。第二に、感覚語ではなく具体値でデザインを指定したこと。第三に、データを後から入れるのではなく最初から実データで渡したことです。

3つめは公式ドキュメントの推奨とも一致します。「lorem ipsumのようなプレースホルダーは、Lovableに反応する材料を与えない」とされており、実コンテンツで設計するほうが余白も行間も現実に即した結果になります。日本語の場合、この差はさらに大きくなります。英語のダミー文で組んだレイアウトに日本語を流し込むと、折り返しも行の高さも変わるからです。

修正は、なぜ「1回1変更」でなければならないのか？

反復の局面でクレジットと時間を最も浪費するのが、1つのメッセージに複数の修正を詰め込む書き方です。3つ頼んで2つが期待どおり、1つが外れたとき、外れた1つを直す指示がさらに他の2つに影響します。

これを避ける書き方は単純で、変更対象と変更禁止範囲を毎回書くことです。公式ドキュメントは次の形の例を挙げています。「注文一覧テーブルにステータスで絞り込めるフィルターを追加してください。変更は注文ページのみ。既存のスタイルは変更しないでください」。日本語でもこの構造をそのまま使えます。

また、細部の修正では文章で指示するより、プレビュー上で対象要素を指定するほうが正確です。公式ドキュメントも「特定の箇所を変えたいときは、指し示すほうが再プロンプトより優れる」と述べています。文章での再指示は、対象の特定に情報量を使ってしまうためです。

Plan modeとBuild modeは、どう使い分けるのか？

大きな変更を思いつくまま投げると、意図の解釈がずれたまま複数ファイルが書き換わります。この事故を構造的に防ぐのが、実装前に計画を出させる仕組みです。

公式ドキュメントによれば、Plan modeはコードを書かずにプロジェクトのファイルやデータベース、ログを調べ、確認質問を返し、編集可能な構造化された計画を提示します。消費はメッセージあたり1クレジット固定です。一方のBuild mode（旧Agent mode）は実装を担い、使用量ベースで、変更ファイル数やロジックの複雑さ、コード探索量によって消費が変動します。

したがって合理的な使い分けはこうなります。何を作るか決まっていない段階、複数の設計案を比べたい段階、原因を調査したい段階はPlan mode。方針が固まった実装、バグ修正、複数ファイルにまたがるリファクタリングはBuild modeです。「決める」を固定費で回し、「作る」だけを従量に流す、と覚えると迷いません。

もうひとつ有効なのが、プロンプトの末尾に確認質問を促す一文を足す方法です。公式ドキュメントは「この機能について私が何を望み、どう思い描いているかを完全に理解するために必要な質問を、私にしてください」という一文を推奨しています。日本語でもそのまま機能します。

狙った見た目を出すには、どんな語彙を使えばよいのか？

デザインの指示は、最も感覚的になりやすく、最も結果がブレる領域です。「きれいに」「モダンに」では、何も指定していないのとほとんど変わりません。

公式ドキュメントは、minimal（最小限）、expressive（表現力のある）、cinematic（映画的）、playful（遊び心のある）、premium（上質な）といった語彙をLovableが解釈すると明記しており、これらは「飾りではなく、タイポグラフィ、余白、影、角丸、配色に実際に影響する」と説明されています。そして「言葉が具体的で主張が強いほど、結果は良くなる」とされています。

実務では、この語彙に具体値を組み合わせるのが最も安定します。トーンを2語で指定し、配色は16進数で、角丸と枠線は数値で渡す。感覚と実数の両方を渡すことで、解釈の幅が狭まります。ブランドガイドラインがある企業では、この方法で社内基準に合致した画面を初回から出せます。

業務アプリでは、どう書けばよいのか？

ここまでの原則を、実際の業務パターンに落とします。以下はそのまま使える出発点ですが、目的・画面・データ・制約の4要素を自社の実態に置き換えてから送ってください。

申請・承認フローをアプリ化する場合

紙やメールで回っている申請は、最も効果が出やすい対象です。承認の段階数と差し戻しの扱いを最初に書き切ることが要点になります。

「経費申請の社内アプリを作ってください。利用者は申請者と承認者の2種類です。申請者は、日付・費目（交通費／会議費／消耗品）・金額・目的・領収書画像を入力して提出します。承認者は未承認一覧を見て、承認または差し戻しコメント付きの差し戻しができます。ステータスは下書き／申請中／承認済み／差し戻しの4つ。UIはすべて日本語で、ボタン・エラーメッセージ・空状態の文言も日本語にしてください。」

点検記録・台帳を置き換える場合

Excel台帳の置き換えでは、入力のしやすさと検索性が評価を分けます。項目を列挙するだけでなく、入力方法まで指定してください。

「設備点検の記録アプリを作ってください。点検者はスマートフォンから、設備ID・点検日・点検項目5件の判定（良／要観察／不良）・所見・写真を登録します。設備IDは一覧から選択、判定はラジオボタン、点検日は既定で当日にしてください。管理者向けに、設備別・期間別で絞り込める一覧画面を用意してください。UIはすべて日本語で。」

集計ダッシュボードを作る場合

ダッシュボードは、指標を先に決めないと「なんとなくグラフがある画面」になります。何を意思決定するための画面かを冒頭に書いてください。

「部門長が週次の進捗を確認するためのダッシュボードを作ってください。上部に主要指標のカードを4枚（総件数・進行中・今週期限・完了率）、その下にステータス別の内訳、最下部に期限が近い順の一覧を配置します。配色は#1C1917を本文、#E89B80を強調に使い、カードは白背景に1pxの枠線、角丸12px、影なしのフラットにしてください。UIはすべて日本語で。」

同じ前提を毎回書かずに済ませるには、どうすればよいのか？

ここまでの型を実践すると、初回プロンプトはそれなりの長さになります。配色、フォント、UI言語、命名の方針。これを人ごと・案件ごとに書き直していては、組織で使うツールになりません。

Lovableには、こうした前提を一度登録して繰り返し参照させる仕組みがあります。ナレッジ機能にプロジェクトの背景や制約を記述しておけば、以降のプロンプトでその都度書き直す必要がなくなります。ワークスペース単位で知識を共有する使い方も公式ブログで紹介されており、チームで同じ前提を持たせる用途に向きます。

デザインの標準化については、料金ページによればデザインシステムはPro以上、デザインテンプレートはBusiness以上の機能です。ブランドガイドラインを持つ企業が複数人で使う場合、この差はプラン選定の判断材料になります。

運用上の要点は、ナレッジに何を書くかです。おすすめは「変わらないこと」だけを書くことです。配色、フォント、UI言語、禁止事項。案件ごとに変わる要件を書き込むと、別のプロジェクトで足枷になります。

プロンプトの巧拙は、コストにどう跳ね返るのか？

手戻りは時間だけの損失ではありません。Lovableは使用量に応じてクレジットを消費するため、指示の粗さはそのまま費用に変換されます。ここを経営に説明できると、プロンプト標準化の投資対効果が語れます。

公式ドキュメントによれば、クレジットはアプリを計画・生成・編集するBuild usage、ホスティングと組み込みバックエンドを動かすCloud usage、公開後のアプリが実行時に呼ぶAI gateway usageの3つで消費されます。プロンプトの質が直接効くのは1つめです。

そしてBuild modeは使用量ベースで、変更ファイル数やロジックの複雑さ、コード探索量によって消費が変わります。範囲を切らない指示は、AIに広くコードを探索させ、余分なファイルを書き換えさせます。つまり「変更禁止範囲を1行書く」ことは、品質対策であると同時にコスト対策でもあるということです。

組織で運用する場合、プランによってはメンバーごとのクレジット上限を設定できます。個人の書き方に依存するリスクを、上限設定と標準プロンプトの両輪で抑えるのが現実的です。

やってはいけない書き方は何か？

公式ドキュメントの推奨を裏返すと、避けるべき書き方が見えてきます。いずれも「間違い」ではなく「情報量が足りない」書き方であり、悪意なく誰もがやってしまう点が厄介です。

最上段の「ページ全体を1本で」は、初回の骨格作成に限っては例外です。先に挙げた社内ポータルの例のように、範囲を「骨格のみ」と明示し、中身は次のメッセージ以降と宣言する場合には有効に働きます。禁じられているのは、範囲を切らずに全部を一度に求めることです。

日本語で書くとき、特に注意すべき点は？

日本語プロンプト自体は問題なく通ります。ただし日本語は主語と目的語を省略できてしまうため、英語で書くより「省略が事故になる」確率が高いという性質があります。

実務的な対策は2つです。ひとつは、対象を必ず名詞で書くこと。「大きくして」ではなく「注文一覧ページの検索ボタンを大きくして」と書きます。もうひとつは、UIコンポーネント名を英語のまま使うことです。modal、badge、tooltip、breadcrumbといった語は、和訳すると逆に曖昧になります。「吹き出し」ではtooltipかpopoverか判別できません。用語の対応は公式の用語集で確認できます。

また、生成されるアプリのUI言語は、プロンプトの言語とは別の変数です。日本語で指示しても、明示しなければボタンが英語で生成されることがあります。初回に「UIはすべて日本語で。ボタン・エラーメッセージ・空状態の文言も日本語」と一文入れておくのが確実です。

よくある質問（FAQ）

プロンプトはどのくらいの長さが適切ですか？

長さの基準はありません。目的・画面・データ・制約の4要素が揃っているかで判断してください。初回の骨格作成では長くなり、以降の修正では1変更に絞るため短くなるのが自然な形です。

同じプロンプトを送っても毎回結果が違うのはなぜですか？

生成には揺らぎがあります（公式ドキュメント参照）。再現性を高めたい場合は、配色や寸法を数値で指定し、変更禁止範囲を明示してください。感覚語だけの指示ほど揺らぎが大きくなります。

途中でうまくいかなくなったとき、最初からやり直すべきですか？

その前に、直前の変更を戻して切り分けてください。複数の変更をまとめて送っていた場合は、1つずつ分けて再実行すると原因が特定できます。作業の区切りごとにバージョンを保存しておくと、この復旧が容易になります。

プロンプトを社内で共有・標準化する意味はありますか？

あります。とくに初回プロンプトの骨格と、変更禁止範囲を書く定型文は、共有すると組織全体の手戻りが減ります。公式のプロンプトライブラリを出発点に、自社の配色や用語を反映した版を作るのが現実的です。

業務仕様や実データをプロンプトに貼っても問題ありませんか？

プランによって扱いが異なります。公式ドキュメントによれば、2026年9月9日以降、FreeプランとProプランの顧客データはAIモデルの学習に利用される可能性があり、アカウント設定からオプトアウトできます。BusinessプランとEnterpriseプランのワークスペースデータは契約にもとづき既定で学習対象外です。実データを扱う前に、自社のプランと設定を確認してください。

エンジニアがいない部門でも、この型で運用できますか？

初回の骨格作成と日常の修正は可能です。ただし公開前の権限確認は別スキルであり、他人のデータが見えないことは動作確認では分かりません。作る人と点検する人を分けてください。組織的に点検を仕組み化する場合は、Enterpriseプランの定期セキュリティスキャンや監査ログ、および公式のセキュリティ情報を参照してください。

プロンプトを英語に翻訳したほうが精度は上がりますか？

同じ情報量で書く限り、翻訳する必要はありません。翻訳の手間をかけるより、その時間で対象範囲と制約を1行足すほうが、結果への影響は大きくなります。

まとめ：プロンプトの質は、書く前の思考の質で決まる

Lovableで手戻りが増える原因は、AIの性能ではなく指示の情報量にあります。初回は目的・画面・データ・制約の4要素を揃え、範囲を「骨格のみ」と切る。修正は1メッセージ1変更に絞り、変更してよい範囲と触ってはいけない範囲を毎回書く。大きな判断はPlan modeで固定費のうちに済ませる。

デザインは感覚語と具体値の組み合わせで指定し、日本語では主語と対象を省略しない。UIコンポーネント名は英語のまま渡す。この6点を守るだけで、反復回数もクレジット消費も目に見えて減ります。前提の共有はナレッジ機能に寄せ、個人差は組織向けの統制機能で吸収するのが、規模が大きい組織での定石です。

社内標準としてのプロンプト設計、業務要件からの落とし込み、そして作ったアプリを組織で運用可能な状態にするまでのご相談は、株式会社100のLovable公式パートナーページで承っています。Lovableの全体像はLovableとは？できること・料金・使い方を日本公式パートナーが徹底解説をご覧ください。