flutterflow language【2026年版】多言語化の設定手順・料金・Firebase連携

はじめに

FlutterFlowのlanguage設定を使えば、アプリの表示テキストを言語ごとに管理し、多言語アプリを作れます。 ただし、英語の文言を別の言語に置き換えるだけでは、実際の利用体験は安定しません。ボタンの幅、日付や数字の表示、通貨の見え方、権限メッセージ、エラー文、利用規約、通知文まで含めて確認する必要があります。

FlutterFlow公式ドキュメントでは、対応言語の追加、Google Translateを使った一括翻訳、手動修正、LanguageSelector、Set App Language、日付・数字・通貨のローカライズ、公開前のテスト方法が説明されています。FlutterFlowではアプリ側の多言語対応を進められますが、翻訳の品質確認や画面崩れのチェックは開発者側の仕事として残ります。

この記事では、多言語対応が必要な理由とi18n・L10nの基本から始め、language設定の手順、Firebaseを使った翻訳データの管理、翻訳APIとの連携、多言語化が使える料金プラン、AdaloやBubbleとの違い、公開前テストまでを整理します。料金と仕様は2026年9月27日に公式サイトで確認した内容です。

対象言語が1つ増えるだけでも、確認する画面数は大きく増えます。ログイン、オンボーディング、課金、通知、エラー、問い合わせ、退会まで一連の流れを言語ごとに確認するため、最初に翻訳対象の画面一覧を作ることが重要です。MVPの段階から多言語化を意識しておけば、公開直前に大量の文言修正が発生するリスクを減らせます。

FlutterFlowで多言語対応が必要な理由と基本

多言語対応は、どの地域の利用者にどの言語で体験を届けるかを決める設計の作業です。

なぜ多言語対応が必要なのか

利用者は、自分が普段使う言語で表示されるアプリの方が内容を理解しやすく、操作の迷いも少なくなります。英語が分かる利用者でも、料金、解約条件、個人情報の扱いといった重要な説明は母語で読みたいと考えるのが自然です。

多言語対応によって、アプリを届けられる利用者の範囲が広がります。国内向けのアプリでも、在留外国人や海外拠点の従業員が使うなら、英語などへの対応が必要になる場面があります。一方で、対応言語を増やすほど翻訳の確認や問い合わせ対応の負担も増えるため、利用者が多い言語から順に追加すると品質を保ちやすくなります。

i18n（国際化）とL10n（ローカリゼーション）の違い

多言語対応を考えるときは、i18nとL10nという2つの考え方を分けておくと整理しやすくなります。

i18n（Internationalization：国際化）は、アプリを特定の言語や地域に依存しない作りにしておくことです。画面の文言を直接書き込まず翻訳データから読み込む、日付や通貨の表示形式を地域に合わせて変えられるようにする、長い翻訳でもレイアウトが崩れない余白を確保する、といった準備がi18nにあたります。

L10n（Localization：ローカリゼーション）は、i18nで準備したアプリを特定の言語や地域に合わせて仕上げることです。文言の翻訳に加えて、その地域に合う表現や単位、法令に沿った利用規約やプライバシーポリシーの用意も含まれます。

FlutterFlowのLanguages設定はi18nの土台を用意する機能で、L10nにあたる表現や法務面の確認は人が判断します。

FlutterFlowで多言語対応するメリット・デメリット

FlutterFlowで多言語対応を進めると、画面の文言を一覧で管理でき、コードを書かずに翻訳を組み込めます。反対に、機能が使えるプランや、自動翻訳の品質には注意が必要です。

観点	メリット	デメリット・注意点
開発効率	対応言語の追加と文言の翻訳を画面操作で進められる	設定の仕組みを理解するまで学習時間がかかる
翻訳作業	Translate Allで初期翻訳の工数を減らせる	自動翻訳は下書き。専門用語や課金画面は人の確認が必要
表示の地域対応	日付・数字・通貨の表示を言語設定に合わせられる	Combine Textで組み立てた文字列は一括翻訳の対象外
動的データ	Firestoreと組み合わせて翻訳データを管理できる	Firebaseの利用料金とセキュリティルールの設定が必要
料金	1つのプロジェクトで複数言語を管理できる	公式料金ページではOne-Click LocalizationはGrowthプランから

デメリットの多くは、翻訳対象の画面一覧、基準言語、確認担当者を最初に決めておけば抑えられます。

FlutterFlowのlanguage設定でできること

FlutterFlowのLocalizationドキュメントでは、Settings and IntegrationsのLanguagesから対応言語を追加し、Primary Languageを設定する流れが説明されています。基本は、アプリの表示テキストを言語ごとに管理し、自動翻訳と手動修正を組み合わせることです。

設定項目	確認すること
Languages	対応言語とPrimary Language
Translate All	一括翻訳後の手動確認
Fixed	手動で直した翻訳を自動翻訳で上書きさせない
Display Language	実行せずに翻訳後の表示をキャンバスで確認
Predefined Messages	iOSの権限メッセージや認証・アップロード時の定型文の翻訳
Date/Number/Currency	地域別の表示形式の確認

Primary Languageと対応言語の追加

最初に決めるのがPrimary Languageです。公式ドキュメントでは、翻訳を済ませた後にPrimary Languageを変更すると、他言語の既存翻訳が消えると注意されています。 日本語で画面を作り英語へ展開するのか、英語を基準にして日本語を追加するのかを、翻訳作業の前に決めておきます。

Translate Allと手動翻訳の使い分け

Translate Allは初期翻訳を速く進めるには便利ですが、そのまま公開できるとは限りません。商品名、業界用語、ボタン文言、エラー文、課金画面、医療・金融・教育など慎重な表現が必要な箇所は、人が確認します。自動翻訳は下書き、手動翻訳は品質保証と考えると整理しやすくなります。

翻訳は、Language Settingsのページ別一覧から管理するほか、各テキストのプロパティから追加することもできます。手で直した翻訳はFixedにして、次にTranslate Allを実行しても上書きされないようにします。RichTextの静的テキストは翻訳対象になりますが、Combine Textで組み立てた文字列は一覧に表示されずTranslate Allにも含まれないため、動的な文言の扱いには注意します。

翻訳レビューでは、「Next」「Submit」のような短い英語を直訳せず、画面の文脈に合わせた表現にします。

LanguageSelectorとSet App Languageの注意点

LanguageSelectorを使うと、利用者がアプリ内で言語を切り替えられます。現在の言語を表示し、操作すると利用可能な言語の一覧が出る部品で、アプリを再起動せずに表示が切り替わります。オンボーディングや設定画面に置くと、利用者が自分の言語を選びやすくなります。

ただし、初期状態では選んだ言語が次回の起動時に保持されません。言語の選択を残したい場合は、Persist Selectionを有効にします。LanguageSelectorは置くだけで終わりではなく、選択の保持と初回表示の言語までテストすることが重要です。

独自の言語選択画面を作る場合は、Set App Languageアクションで利用者の選択を反映します。このアクションはアプリ内の言語を切り替えるもので、端末のシステム言語は変わりません。

日付・数字・通貨のローカライズ

日付は、yMdやyMMMdのような地域に応じて並びが変わる形式を選ぶと、言語設定に合わせて表示が変わります。金額はDisplay as Currencyを有効にし、通貨記号を空欄にしておくと、地域に合わせた表記になります。固定の書式を指定すると、言語を切り替えても表示が変わらない点に注意します。

FirebaseとFlutterFlowで多言語対応を効率化する方法

Languages設定で管理できるのは、主に画面に固定で表示する文言です。お知らせ、商品説明、よくある質問のように、公開後も内容が変わるテキストはFirebaseと組み合わせると管理しやすくなります。Firebaseとの連携の基本はFlutterFlowのデータベース構築とFirebase連携でも解説しています。

翻訳する対象	向いている方法	更新の反映
ボタン・見出しなどの固定文言	Languages設定（Translate All＋手動修正）	アプリの再公開が必要
お知らせ・商品説明などの運用テキスト	Firestoreに言語別の項目を保存	データを更新すれば反映
利用者の投稿・チャット	Cloud Functions経由で翻訳APIを呼び出す	その場で翻訳

Firestoreで翻訳データを管理する

翻訳データをCloud Firestoreに保存すると、アプリを再公開しなくても文言を更新できます。保存するデータは、たとえば次のように言語コードごとに項目を分けます。

{
  "en": {
    "greeting": "Hello",
    "welcome_message": "Welcome to our app!"
  },
  "ja": {
    "greeting": "こんにちは",
    "welcome_message": "当アプリへようこそ！"
  }
}

FlutterFlow側では、Firestoreのドキュメントを読み込み、現在の言語コードに合う項目を画面に表示します。利用者が選んだ言語をApp Stateに保存しておけば、どの画面でも同じ言語で表示できます。Firestoreは読み書きの回数に応じて料金が発生するほか、誰がデータを書き換えられるかをセキュリティルールで必ず制限します。

Dynamic Links終了後の言語別ストア誘導

以前は、Firebase Dynamic Linksを使って、利用者の言語に合わせたストアページやアプリ内の画面へ誘導する方法が紹介されていました。しかしFirebase公式FAQのとおり、Dynamic Linksは2025年8月25日に終了し、リンクをクリックするとHTTP 404が返るようになっています。

これから言語別の誘導を作るなら、AndroidのApp LinksやiOSのUniversal Linksでアプリ内の画面へ遷移させ、ストア側には各言語の掲載情報を用意する方法が基本になります。

Cloud Functionsで翻訳APIを呼び出す

利用者の投稿やチャットのように、事前に翻訳を用意できないテキストは、Cloud Functions for Firebaseから翻訳API（Google Cloud Translationなど）を呼び出して翻訳します。

Firebase公式ドキュメントの現行の書き方に合わせると、アプリから呼び出す関数は次のようになります。

const {onCall, HttpsError} = require("firebase-functions/https");
const {Translate} = require("@google-cloud/translate").v2;

const translate = new Translate();

exports.translateText = onCall(async (request) => {
  const {text, target} = request.data;
  if (!request.auth) {
    throw new HttpsError("unauthenticated", "ログインが必要です");
  }
  try {
    const [translation] = await translate.translate(text, target);
    return {translation};
  } catch (error) {
    throw new HttpsError("internal", "翻訳に失敗しました");
  }
});

FlutterFlow側では、Cloud Functionsの呼び出しやカスタムアクションで関数を実行し、返ってきた翻訳を画面に表示します。Firebaseの料金プランではCloud Functionsは従量課金のBlazeプランで使う機能とされ、翻訳APIも文字数に応じた料金が別にかかります。金額はCloud Translationの料金ページで確認し、呼び出し回数に上限を設けておくと安心です。

FlutterFlowの料金プラン：多言語対応はどのプランで使える？

多言語アプリを作るうえで最も確認したいのが、どのプランでlanguage設定の機能が使えるかです。2026年9月27日にFlutterFlow公式の料金ページを確認した内容をまとめます。

FreeとBasicでは多言語化機能が使えない

公式料金ページでは、One-Click LocalizationはGrowthプランの機能として記載されており、FreeとBasicの機能一覧には含まれていません。 多言語アプリを本格的に作るなら、Growth以上を前提に予算を組む必要があります。

画面づくりや操作感の確認はFreeで始め、多言語化に進む段階でGrowthへ切り替える流れが無駄のない進め方です。

有料プランの比較

プラン	料金（公式表示）	多言語化	同時編集	主な追加機能
Free	0ドル（初期費用の記載なし・税の扱いは公式記載なし）	機能一覧に記載なし	1名	プロジェクト2、APIエンドポイント2、Web公開
Basic	月39ドル（月払い表示・税の扱いは公式記載なし）	機能一覧に記載なし	1名	無制限のプロジェクト、コード出力、ストア公開
Growth	1席目月80ドル・2席目月55ドル（月払い表示・税の扱いは公式記載なし）	One-Click Localization	2名	GitHub連携、OpenAPI読み込み
Business	1席目月150ドル・2〜5席目月85ドル（月払い表示・税の扱いは公式記載なし）	Growthの機能を含む	5名	Figma読み込み、CLI
Enterprise	個別見積（料金ページに金額の記載なし）	公式サイトで確認	公式サイトで確認	公式サイトで確認

公式料金ページでは年払いにすると約25%安くなると表示されています。初期費用の記載はありません。税の扱いは料金ページに書かれていないため、申し込み画面で確認してください。

アプリの規模と予算に合わせたプランの選び方

個人で1〜2言語のアプリを作るなら、Growthの1席で始められます。翻訳担当と開発担当が同時に作業するなら、2名まで編集できるGrowthか、5名まで編集できるBusinessが候補です。

チームでの開発やFigmaからの画面取り込みが必要な場合はBusiness、6名以上での開発や社内の管理要件がある場合はEnterpriseについて問い合わせます。プランは多言語化の有無だけでなく、編集する人数と公開方法から逆算して選ぶことが重要です。FlutterFlowの基本機能と料金を広く見たい場合は、FlutterFlowとは？ノーコードアプリ開発の使い方・料金・注意点【2026年版】も参考になります。

Adalo・Bubbleとの比較：FlutterFlowの多言語対応の特徴

多言語対応の進め方はツールによって異なります。AdaloとBubbleを例に違いを整理します。

Adaloの多言語対応

Adalo公式ブログの多言語アプリの解説（2026年3月更新）では、FlutterFlowのような言語設定の画面ではなく、最初から多言語を前提に画面とデータを設計する考え方が紹介されています。

実装では、言語ごとの文言をコレクションに保存し、利用者が選んだ言語で表示を切り替える方法がよく使われます。

Bubbleの多言語対応と比較表

Bubbleの公式マニュアルによると、SettingsのLanguagesでApp textsを言語ごとに登録でき、文言をCSVで書き出して翻訳し、読み込み直すこともできます。表示する言語は、URLの指定、ユーザーに保存した言語、アプリの基準言語の順に決まります。

比較軸	FlutterFlow	Bubble	Adalo
言語設定の機能	Languages設定で対応言語を追加	SettingsのLanguagesとApp texts	組み込みの言語設定画面ではなく設計・データで対応
一括翻訳	Translate All（Google Translate）	CSVを書き出して外部で翻訳	コレクションに言語別の文言を用意
言語の切り替え	LanguageSelector・Set App Language	ユーザーの言語項目・URL指定	選んだ言語でデータを絞り込んで表示
向いている用途	iOS・Androidのモバイルアプリ	業務システム・Webアプリ	シンプルなモバイルアプリ

モバイルアプリで多言語化を画面操作中心に進めたいならFlutterFlow、業務システムやWebアプリで言語ごとの文言をCSVで管理したいならBubbleが合います。

公開前テストのチェックポイント

公式ドキュメントでは、端末の言語設定を変えた確認、エミュレーターでの地域設定の確認、長い翻訳による表示崩れの確認、翻訳の正確さの確認が案内されています。

確認項目	見るポイント
端末の言語設定	初回起動時に想定した言語で表示されるか
アプリ内の切り替え	LanguageSelectorで切り替え、再起動後も保持されるか
長文表示	ボタンやカードから文字があふれないか
日付・数字・通貨	地域に合った並びと記号で表示されるか
権限・定型メッセージ	カメラや通知の許可文、エラー文が翻訳されているか
動的なテキスト	Firestoreや翻訳APIから取得した文言が正しい言語で出るか

公開直前には、実際の利用者に近い人にも触ってもらい、言語の切り替え場所が分かるか、エラーのときに次の行動が分かるかを確認します。

まとめ

flutterflow languageを設定するときは、翻訳作業だけでなく、i18nとL10nを分けた言語設計、Primary Language、Translate All、Fixed翻訳、LanguageSelector、Persist Selection、Set App Language、日付・数字・通貨の表示までを一連の流れとして考えます。自動翻訳は便利ですが、公開品質を保つには人によるレビューと端末ごとのテストが欠かせません。

公開後も内容が変わるテキストはFirestoreで言語別に管理し、利用者の投稿のように事前に翻訳できないテキストはCloud Functionsから翻訳APIを呼び出します。Dynamic Linksは終了しているため、言語別の誘導はApp LinksやUniversal Linksで作ります。

料金面では、公式料金ページでOne-Click LocalizationがGrowthプランから記載されている点が最も重要です。FreeやBasicで画面を試し、多言語化に進む段階でGrowth以上へ切り替え、編集する人数や公開方法に合わせてBusinessやEnterpriseも比べてください。Firebaseや翻訳APIの利用料金も別に見込んでおきます。

多言語化は文言の翻訳ではなく、利用者の体験全体の設計です。ノーコード総合研究所では、Bubbleを中心に業務システムやWebアプリの開発を支援しており、多言語対応を含む要件の整理から相談できます。対象国、対応言語、基準言語、翻訳対象の画面、外部連携、公開予定日を整理しておくと、開発範囲を切り分けやすくなります。