社内の申請書をアプリにしたい。見積もりを取る前に、まず動くものを見せて話を進めたい。そう考えてLovableにたどり着いた日本企業の担当者が、サインアップの直前でいったん手を止める理由はだいたい同じです。画面が英語だからです。

そして次に、こう検索します。「Lovable 日本語」。ところが返ってくる情報は「日本語で使えます」と「UIは英語です」が混在していて、どちらも間違ってはいないのに、自分の環境で何ができて何ができないのかが分かりません。稟議書に「日本語対応：可」と書いてよいのか、判断がつかないまま止まります。

この記事では、Lovableの日本語対応を「プロンプト」「UI」「ドキュメント・サポート」の3層に分解し、2026年8月31日時点の公式情報と、株式会社100が日本語プロンプトだけで社内ツールを構築した実測にもとづいて整理します。

なぜ「Lovableは日本語で使えるのか」という問いは答えにくいのか？

「日本語対応」という一語には、実務上まったく性質の異なる3つの論点が畳み込まれています。どれを指しているかで答えが正反対になるため、そのまま調べても混乱するだけです。

第一に、AIへの指示（プロンプト）を日本語で書けるか。第二に、Lovableの管理画面そのものが日本語で表示されるか。第三に、公式ドキュメントとサポートが日本語で受けられるか。この3つは提供主体も更新頻度も異なり、片方が「可」でも他方は「不可」ということが普通に起こります。

結論から言えば、この3層の答えは同じではありません。順に見ていきます。

プロンプトは日本語で通じるのか？

実務でいちばん重要なのはここです。AIに何を作らせるかを日本語で書けなければ、そもそも現場に渡せません。翻訳を挟む前提のツールは、社内展開の段階でほぼ確実に止まります。

この点については、日本語で問題なく通ります。Lovableの生成エンジンは自然言語での指示を前提としており、公式のプロンプト・ベストプラクティスも「曖昧なアイデアは曖昧な出力を生み、明確な思考は明確な結果につながる」と述べているとおり、問題になるのは言語ではなく指示の解像度です。

日本語プロンプトだけで、実際にどこまで作れたのか？

一般論だけでは判断材料になりません。株式会社100では、自社の社内向け管理ポータルをLovableで構築する際、最初の設計指示から個別の修正指示まで、すべて日本語のプロンプトのみで進めました。英訳は一度も挟んでいません。

そのとき日本語で渡した指示には、次のようなものが含まれます。左サイドバー固定＋メインコンテンツというレイアウト構造、React Routerによる7ページ分のルーティング、ブランドカラーを16進数で指定したデザイントークンの定義、和文と英字で異なるフォントの使い分け、そして初期表示用データを28件まとめて投入する指示です。いずれも日本語のまま意図どおりに実装されました。

ここから言えるのは、日本語プロンプトの限界は「言語」ではなく「構造化の粗さ」にあるということです。日本語であっても、対象範囲・制約・望む見た目を具体的に書けば結果は安定します。逆に英語で書いても曖昧なら結果は荒れます。

日本語で指示したのに、生成物が英語になるのはなぜか？

日本語で頼んだはずのアプリのボタンが「Submit」になっている、という現象は初期によく起きます。これは日本語が通じていないのではなく、「画面に表示される文言を何語にするか」を指示していないために起きます。

プロンプトの言語と、生成されるアプリのUI言語は別の変数です。Lovableのプロンプトライブラリでも、多言語アプリを作る際はUIテキストの言語を明示し、コードのコメントや変数名は英語で統一する書き分けが推奨されています。実務では、初回プロンプトに「UIはすべて日本語で。ボタン・エラーメッセージ・空状態の文言も日本語」と一文入れておくだけで、あとからの手戻りが大きく減ります。

管理画面（UI）は日本語表示にできるのか？

ここが、日本語対応の3層のうち最も期待と実態がずれるところです。稟議で「全社員が使う」と書くつもりなら、事前に押さえておく必要があります。

2026年8月31日時点で公開情報を確認した範囲では、料金ページ、公式ドキュメント、FAQのいずれも英語のみで提供されており、エディタUIの表示言語を日本語に切り替える設定は、公式ドキュメント上に記載が見当たりません。日本語UIの提供予定についても、公式に告知された情報は確認できていません。

ただし、これを過大に見積もる必要もありません。実際にエディタで日常的に触るのは、チャット入力欄、プレビュー、バージョン履歴、公開ボタンといった限られた要素です。英語のUI用語そのものが障壁になるのは初回の数十分で、そこを越えると、詰まる原因は言語ではなく後述する「指示の書き方」に移ります。

とはいえ、ITリテラシーの幅が広い1,000名規模の組織に一斉展開する場合、この初回の数十分は無視できないコストです。社内向けに日本語の操作手順書を用意するか、伴走パートナーの初期トレーニングで巻き取るかを、展開計画の段階で決めておくべきです。

日本語で精度を落とさないための3原則とは？

日本語プロンプトが不安定に見えるとき、原因の大半は言語ではなく書き方にあります。日本語は主語と目的語を省略できてしまう言語なので、英語で書くより「省略が事故になる」確率が高いのです。ここを補う3つの原則を挙げます。

なぜ主語と対象範囲を省略してはいけないのか？

「ボタンを大きくして」という日本語は、どの画面のどのボタンかを含みません。人間なら文脈で補いますが、AIは補い方を間違えると別の画面まで書き換えます。公式ドキュメントも、変更してよい範囲と触ってはいけない範囲を明示することを推奨し、「境界がないと、小さな依頼が既に動いている部分にまで波及する」と警告しています。

実務では、日本語でも「〜のみを変更し、他は現状維持」という一文を定型で付けるのが有効です。たとえば「注文一覧ページにステータスの絞り込みを追加してください。変更は注文一覧ページのみ。既存のスタイルは変えないでください」という形です。これは英語版の推奨例をそのまま日本語に移したものです。

なぜUI用語は英語のまま渡したほうがよいのか？

「modal」「badge」「tooltip」「breadcrumb」といったUIコンポーネント名は、日本語に訳すと逆に曖昧になります。「吹き出し」はtooltipかpopoverか判別できませんし、「帯」はbannerかbadgeか分かりません。

公式ドキュメントは、UIの語彙が小さく具体的であるほど生成精度が上がると述べています。日本語の文の中に英語のコンポーネント名を混ぜることは、文章としては不格好でも、プロンプトとしては正解です。「ユーザー名とfollowボタンを持つcardを作り、認証済みユーザーにはbadgeを、hover時にはtooltipを表示してください」といった書き方が最も安定します。

大きな変更こそ、なぜPlan modeで日本語のまま設計すべきなのか？

日本語で長い要件を一気に書くと、意図が散らばって生成が発散します。これを防ぐのがPlan modeです。Plan modeはコードを書かずにプロジェクトを調査し、確認質問を返し、編集可能な計画を提示するモードで、公式ドキュメントによればメッセージあたり1クレジット固定で動きます。

実装を担うBuild mode（旧Agent mode）は使用量ベースの従量課金で、変更ファイル数やロジックの複雑さによって消費が変動します。つまり「決める」工程を1クレジット固定のPlan modeで日本語のまま済ませ、合意できた計画だけをBuild modeに流すほうが、結果的にクレジットも時間も節約できます。日本語話者にとっては、往復の確認質問が日本語で返ってくることの安心感も小さくありません。

日本語で使うとき、どこで詰まりやすいのか？

ここまでの原則を踏まえてなお発生する、日本語特有の詰まりどころがあります。頻度が高い順に整理しますが、注目していただきたいのは対処法よりも「原因が言語ではない」という共通点のほうです。いずれも、英語話者が同じ書き方をすれば同じように詰まります。

最後の項目は見落とされがちです。公式ドキュメントは「lorem ipsumのようなプレースホルダーはLovableに反応する材料を与えない」として実コンテンツでの設計を推奨していますが、これは日本語ではさらに切実です。英語のダミー文で組んだレイアウトに日本語を流し込むと、行の高さも折り返しも想定と変わります。最初から実際の日本語文言で作るほうが速いのです。

ドキュメントとサポートが英語であることは、実務にどう効くのか？

3層目の論点です。ここは正直に書きますが、日本語では提供されていません。公式ドキュメント、用語集、実践ガイドはいずれも英語で、コミュニティも英語圏が中心です。

個人利用ならブラウザの翻訳機能で足ります。問題が出るのは組織導入の場面です。情報システム部門にセキュリティ要件を説明するとき、参照すべき一次情報であるセキュリティページ、トラストセンター、データ処理契約（DPA）、プライバシーポリシーがすべて英語だからです。

審査部門から「原文を確認したい」と言われれば英語で読む必要があり、社内説明資料は自前で翻訳することになります。SOC 2 Type II、ISO 27001:2022、GDPRといった枠組みに関する記述を、誤訳せずに稟議資料へ落とす作業は、想像よりも工数を食います。ここを誰が担うのかを決めていないことが、日本企業の導入が止まる典型的なポイントです。

なおEnterpriseプランでは専任のアカウントチームと窓口が付きますが、これも標準は英語です。日本語での一次窓口が必要な場合は、国内パートナー経由という選択肢になります。

日本語環境における本当の壁は、言語なのか？

ここまで整理すると、言語そのものは越えられる壁だと分かります。プロンプトは通り、UIは慣れ、ドキュメントは翻訳できます。にもかかわらず日本企業の導入が止まるとき、原因はたいてい言語の外側にあります。

ひとつは調達です。標準の申し込みはカード決済で、料金ページの表示も外貨建てです。年度予算・請求書払い・年間契約を前提とする日本の購買プロセスとは、そのままではかみ合いません。

もうひとつはデータの扱いです。公式ドキュメントによれば、2026年9月9日以降、FreeプランとProプランの顧客データはLovableのAIモデルの学習に利用される可能性があり、利用者はアカウント設定からオプトアウトできます。一方、BusinessプランとEnterpriseプランのワークスペースデータは契約にもとづき既定で学習対象外です。日本語で情シスに説明すべき最重要事項はここであって、UIが何語かではありません。

三つめは定着です。IPAが2026年7月に公表した国内企業のDX・AI活用動向では、AI導入は着実に広がる一方で、業務効率化の段階から新たな価値創出へ発展させることが課題として示されています。ツールが日本語で使えることと、組織で使われ続けることの間には距離があります。

日本語でLovableを使うメリットとデメリットは何か？

判断材料として、良い面と悪い面を並べておきます。導入可否の議論では、片側だけを見た資料が最も社内の信頼を失います。

この表で最も重要なのは最下段です。上5行は運用の工夫で吸収できますが、調達だけは現場の努力では解決しません。ここは制度の問題だからです。

日本語で相談できる窓口はどこにあるのか？

株式会社100は、Lovableの日本における公式パートナーとして、導入・活用・定着までを日本語で伴走しています。あわせて世界上位1%のHubSpot認定エリートパートナーでもあり、CRMを含む既存の業務データとの接続を前提にした設計ができる点が、単なる再販との違いです。

実務上とくに需要が大きいのは、日本円での請求書払いや年間契約の相談、情報システム部門向けのセキュリティ説明、そして作ったアプリを「使われる状態」にするための業務設計です。詳細はLovable公式パートナーページを、Lovableそのものの全体像はLovableとは？できること・料金・使い方を日本公式パートナーが徹底解説をご覧ください。

よくある質問（FAQ）

日本語でプロンプトを書くと、英語より生成精度が落ちますか？

同じ内容・同じ粒度で書く限り、日本語だから精度が落ちるという公式の記載はありません。差が出るのは、日本語では主語や対象範囲を省略しやすいためです。省略せずに書けば結果は安定します。

すでに英語で作りかけたプロジェクトを、途中から日本語のプロンプトに切り替えても大丈夫ですか？

問題ありません。ただし、その時点で「今後の指示は日本語で行うが、アプリのUI言語は現状のまま」といった前提を一度明示しておくと、文言が意図せず置き換わる事故を防げます。

社内には英語が苦手なメンバーもいます。まず誰から使わせるべきですか？

エディタUIが英語である以上、最初の1人は英語のUI用語に抵抗がない人が向きます。その人が日本語の操作手順書を作り、2巡目以降に広げる進め方が現実的です。全員に同時展開すると、初回の数十分の壁で離脱が集中します。

作ったアプリのエンドユーザーは、英語を目にすることはありますか？

UI言語を日本語で指示していれば、通常は目にしません。ただしエラーメッセージや空状態の文言は指示から漏れやすく、そこだけ英語で残ることがあります。公開前にこの2箇所を確認してください。

日本語のドキュメントやコミュニティは今後提供されますか？

2026年8月31日時点で、日本語での公式ドキュメント提供に関する告知は確認できていません。現時点で日本語の情報を必要とする場合は、国内パートナーの提供する資料やサポートを前提に計画してください。

「日本語対応済み」と稟議書に書いてよいですか？

そのままでは誤解を招きます。「AIへの指示および生成されるアプリのUIは日本語で運用可能。エディタの管理画面と公式ドキュメントは英語」と、3層に分けて記載するのが正確です。監査や情シスの確認が入ったときに、記述の粗さが手戻りを生みます。

翻訳ツールでドキュメントを読ませて社内展開しても問題ありませんか？

運用手順の理解であれば実用的です。ただしセキュリティ要件や契約条件を機械翻訳のまま社内資料に転記するのは避けてください。データ処理契約や学習利用の可否は、誤訳が承認判断を誤らせる領域です。

まとめ：日本語で使えるかを、3層に分けて判断する

Lovableが日本語で使えるかという問いに、単一の答えはありません。プロンプトは日本語で通り、生成されるアプリも指示すれば日本語になります。一方でエディタの管理画面と公式ドキュメントは英語です。この3層を分けて記述できれば、社内の議論は前に進みます。

そして、日本語対応の確認が終わったあとに残る本当の論点は、調達・データの扱い・定着です。言語の壁は数十分で越えられますが、購買プロセスとの不整合は現場の工夫では越えられません。導入検討の初期段階で、そこまでを含めて設計しておくことをおすすめします。

Lovableの日本語での導入相談・デモは株式会社100の問い合わせ窓口で受け付けています。