ダッシュボードなしで Lovable アプリをローカライズするにはどうすればいいのか？

Lovable アプリをダッシュボードなしでローカライズするには、ワークフローのすべての要素をリポジトリの中に留めておくことです：コミットされたファイルとしてのメッセージカタログ、ロケールを名前で登録する設定ファイル、そしてそれらをコンパイルするビルド内の CLI ステップです。globalize.now は、このループをあなたの代わりに実行してくれる AI 搭載のローカライゼーションインフラで、あなたのコードベースから文字列を抽出し、キーとロケールファイルを生成し、Git へのプッシュのたびに翻訳を同期します。この連鎖のどこにもブラウザのインターフェースを必要とする箇所はありません。これは、コードを書いているのがエージェントである場合、見た目以上に重要な意味を持ちます。

なぜダッシュボードは AI 主導のワークフローを壊してしまうのか？

それは、あなたのエージェントがダッシュボードを開けないからです。Lovable、Cursor、Claude Code、Copilot はいずれも、同じ2つの領域——リポジトリ内のファイルと、ターミナル内のコマンド——だけを対象に動作します。ダッシュボードはそのどちらでもありません。

このギャップは、もはや単なる好みの問題ではなく、文書化された前提として扱われています。コーディングエージェントにプロジェクトの動作を伝えるための規約である AGENTS.md は、2025年12月、Model Context Protocol とともに Linux Foundation の Agentic AI Foundation に寄贈されました。Linux Foundation 自身の発表によれば、その時点ですでに6万を超えるオープンソースプロジェクトがこのフォーマットを採用しており、その対象は20種類を超える AI コーディングツールにまたがっていました。その根底にある前提は、プロジェクトの指示はエージェントが読めるファイルの中に置くべきだ、というものです。

ログインの向こう側にある翻訳状態は、この前提の外側に置かれています。あなたのエージェントが Lovable アプリに新しいボタンを追加するとき、文字列を追加することはできます。しかし、そのあとどこかにログインして翻訳グリッドの整合性を取ることはできません。結果として、文字列は英語のまま配信され、ズレは積み重なっていき、それに気づくのはドイツにいる一人のユーザーからの報告によって、ということになります。

もう一つ、より静かに進行する問題があります。修正内容がベンダーのインターフェース内にしか存在しない場合、リポジトリはもはや「あなたのアプリが何を語っているか」についての真実の情報源ではなくなります。真実の情報源が2つ存在し、そのうち一方をあなたのツールチェーンが確認できない状態は、いずれ締め切りに追われて発覚するデバッグ問題を抱え込んでいるようなものです。

ダッシュボードなしの Lovable セットアップは、実際にはどのような姿になるのか？

ビルドに必要なのは、4つのファイルと1つのコマンドだけです。Lovableが生成するアプリはReactベースで、従来のViteスタック、あるいはサーバーレンダリング対応のTanStack Startのどちらでも構成されますが、いずれも同じ形になります。

1. configでロケールを定義する。 コミットされた1つのファイルが、他のすべての層が参照するリストになります。

// lingui.config.ts
import { defineConfig } from "@lingui/conf";

export default defineConfig({
  sourceLocale: "en",
  locales: ["en", "de", "es", "fr"],
  catalogs: [
    {
      path: "src/locales/{locale}/messages",
      include: ["src"],
    },
  ],
});

2. メッセージをカタログに抽出する。 lingui extractがソースコードをスキャンし、ロケールごとに1つの.poカタログを書き出します。ディスク上に既にあるものとマージされるため、再実行しても既存の翻訳は失われません。この特性があるからこそ、自動化ループに安心して組み込めます。

npx lingui extract

3. ビルド前にコンパイルする。 lingui compileがカタログをランタイムモジュールに変換します。--strictフラグを付けると、翻訳が欠けている場合にビルドが失敗するようになります。これにより、本番環境で静かに英語表示になってしまう事態を、最初に気づける「ビルド失敗」という形に変えられます。

{
  "scripts": {
    "build": "lingui compile --strict && vite build"
  }
}

4. プッシュ時に同期を走らせる。 ロケールの追加はlocales配列を編集するだけで済むべきで、サポートチケットを起票する話ではありません。globalize.nowはリポジトリを監視し、エージェントが追加した文字列を抽出し、すべてのロケール向けにキーとカタログエントリを生成して、それをコミットで戻します。カタログはプルリクエストの差分として届くので、他の変更と同じようにレビューできます。

各スタックごとの詳しい手順は、Lovable ViteガイドとTanStack Startガイドに掲載しています。

ベンダーがサービスを終了したら、ダッシュボードで管理していた翻訳はどうなりますか?

ベンダーと一緒に消えてしまいます。これは今月の話として決して仮定の話ではありません。LovableなどのAIビルダーアプリ向けに構築されたランタイム翻訳サービスLovalingoは、**2026年8月31日23時59分（中央欧州夏時間）**をもって終了します。新規プロジェクトと新規契約の受付はすでに停止しており、同社自身の終了案内ページには、サービスを取り外す前に自社所有の国際化対応を並行導入すること、そしてロケールルーティング、フォールバック、canonical URL、hreflang、サイトマップの出力を検証することが明記されています。

これはまさに、ワークフローを「借りる」ことと「所有する」ことの違いを、ベンダー自身が正確に言い表している例です。

最後の行には、ベンダーの問題を超えて長く続くSEO上の影響があります。ページ読み込み後に注入される翻訳は、クローラーが読み取るHTMLに確実に含まれるとは限りません。一方、ビルド時にコンパイルされたカタログは確実に含まれます。

自分のLovableアプリがダッシュボードに依存していないか、どう確認すればいいですか?

3つのチェックがあり、いずれも問題があれば明確に失敗として現れます。

ネットワークを確認する。 DevToolsを開いた状態でアプリを読み込み、スクリプトでフィルタして、翻訳ベンダーのドメインへのリクエストがないか確認します。ドイツ語ページがドイツ語として表示される前にサードパーティのスクリプトが読み込まれる必要があるなら、そのドイツ語ページは他社の稼働状況に依存していることになります。

リポジトリを確認する。 configに設定した各ロケールについて、対応するカタログファイルがディスク上に存在し、かつGitで管理されているべきです。git ls-files "src/locales/**"を実行して数を確認してください。空のカタログや存在しないカタログがあれば、文字列がどこか別の場所にあることを意味します。

ビルドを確認する。 CI上で--strictを使ってコンパイルします。翻訳が欠けている場合はデプロイを止めるべきです。あるロケールが不完全なままビルドが通ってしまうと、その欠落は非英語UIの中に英語テキストとして現れます。これはユーザーから「サイトが壊れている」と報告される典型的な失敗パターンです。

既存のベンダーを取り外す前に、この3つのチェックをプレビューデプロイに対して実行してください。取り外した後ではありません。Lovalingo自身が公開している取り外し前チェックリストも同じ点を指摘しています。実際のロケールルートで置き換え先を検証するまで、旧サービスは残しておくべきだということです。この移行パスについては、当社のLovalingo比較記事で詳しく取り上げています。

ダッシュボードがない場合、globalize.nowはどこに位置づけられますか?

i18nランタイムと翻訳エンジンの間の層に位置します。Lingui、i18next、next-intlのようなライブラリはランタイムで翻訳を提供します。DeepLやGPT翻訳のようなエンジンはテキストそのものを生成します。globalize.nowは、その中間にあるもの――キーとロケールファイル――を生成し、コードと同期させて維持します。

その中間層こそ、これまでは人間がインターフェースをクリックして操作する必要があった部分です。だからこそ、そのインターフェースを取り除くことは機能の欠落ではなく、ワークフローの変化なのです。セットアップは一度だけ――globalize.nowでリポジトリを接続すれば、変換結果はプルリクエストとして届きます。エディタ上では、同じセットアップが1つのコマンドで済みます。

npx skills add globalize-now/globalize-skills

Lovable内では、同じ機能がエディタ内スキルとしてインストールされるため、アプリを構築しているエージェントが直接呼び出せます。Starterプランはワークスペースごと月額20ユーロで、月20ユーロ分の翻訳クレジット（約20万語相当）を含み、それを超えた分は同じ文字単価で課金されます。座席課金も言語課金もなく、カード登録不要で5ユーロの登録クレジットも付きます。1つのワークスペース内であれば言語数もプロジェクト数も無制限で、これは5つ目のロケールを追加する場面（5つ目の座席を追加する場面ではなく）で意味を持ってきます。

バイブコーダー向けと開発者向けの周辺ワークフローの詳細、そしてLovable専用のセットアップについてはLovable連携ページをご覧ください。

要点まとめ

Lovableアプリの翻訳は、自分が所有するファイルであり、エージェントが読み取れるリポジトリに置かれ、自分自身のビルドでコンパイルされるべきものです。globalize.nowは、Gitへのプッシュごとにそれらのファイルを最新の状態に保ちます。