Lokaliseは、アプリやWebサイトの翻訳を「キー」と呼ぶ文字列の単位でクラウド上に集め、翻訳者への割り振りから訳文の書き出しまでを管理する翻訳管理システム（TMS）です。この記事では、Lokaliseのプロジェクト種別とキーの扱い、2026年11月2日に料金ページで確認した4プランの月額と課金の数え方、Go製のCLI（lokalise2、3.1.7が最新）での翻訳ファイルの送受信、公式のpushとpullの2つのGitHub Actionの設定、同じ用途のCrowdinとの選び分けを、公式ドキュメントとGitHubリポジトリの記述をもとに実装の順で整理します。
まとめ：Lokaliseを選ぶ条件とCrowdinとの分かれ目・最初に決める同期の経路
翻訳先の言語が多く、今後も増える見込みがある。翻訳ファイルはJSONやiOSのStringsのようなキーと値の形式で、画面や機能ごとにキーを束ねて管理したい。この2つに当てはまるなら、Lokaliseは候補の筆頭です。料金ページは言語数と翻訳者の人数で課金しないと明言しており、言語を足すほど上限に近づく数え方のサービスより費用の見通しが立てやすくなります。
着手前に決めるのは、プロジェクト種別と同期の経路の2点です。種別はキーと値のファイルなら「Web and mobile」を選びます。同期の選択肢は、Lokalise側のGitHubアプリに任せる方法と、公式のGitHub Actionで自社のワークフローから動かす方法です。月額149米ドルからの価格は、日本語と英語の2言語で翻訳キーが数十個のサイトには重く、その規模ならリポジトリ内のJSONを直接直すほうが安く済みます。
Lokaliseの定義｜キーと値の翻訳ファイルを管理するTMSとプロジェクト種別
最初に、Lokaliseが翻訳を何の単位で持ち、どこまでを受け持つのかを確かめます。
キー単位で翻訳を持つ仕組み｜タグ・プラットフォーム・翻訳メモリの役割
Lokaliseは、翻訳ファイルを取り込むとファイルの中身をキーに分解して保持します。home.titleのようなキー1つに、英語・日本語・韓国語といった言語ごとの訳文がぶら下がる形です。キーにはタグを付けられ、CLIのダウンロードでは--include-tagsで特定のタグのキーだけを書き出せます。後述のGitHub Actionは、このタグにGitのブランチ名を入れてブランチとキーを結びつけています。
キーにはWeb・iOS・Androidといったプラットフォームの属性もあります。CLIのfile downloadの説明によると、--all-platformsを付けない書き出しでは、指定した形式のプラットフォームに属するキーだけが出力されます。アップロード側には翻訳メモリの完全一致を自動で当てる--apply-tmがあり、過去の訳文を再利用できる仕組みです。画面に訳文を表示する処理はアプリ側のi18nライブラリの役目で、国際化と地域化の区別はi18nとl10nの違いとAngularでの実装手順で整理しています。
ファイル形式によるプロジェクト種別｜キーと値の形式と段落単位の文書
プロジェクトの説明によると、Lokaliseのプロジェクトは扱うファイルの形式で種別が分かれます。種別名はWeb and mobileとAd hoc documentsで、キーと値の形式か段落単位の文書かを区別するための名称です。
| 観点 | Web and mobile | Ad hoc documents |
|---|---|---|
| 対象の形式 | JSON・YAML・Strings・XLSX | DOCX・HTML・IDML |
| キーの作られ方 | ファイル内のキーをそのまま使う | 段落を自動でキーに分ける |
| キーの追加 | 翻訳元ファイルにキーを足して送る | 元の文書を直して送り直す |
| 外部連携 | GitHub・WordPress・Figmaに対応 | 文書単位の翻訳に限られる |
キーと値の形式のファイルはWeb and mobileにしか取り込めないと明記されているため、アプリやWebサイトの画面文言はこちらを選びます。公式のGitHub Actionが対象にしているのもWeb and mobileです。Ad hoc documentsは、マニュアルや契約書のように段落で区切られた文書を訳す用途に向きます。
Lokaliseの料金体系｜処理語数と管理者席で決まる4プランの価格と見積もり方
Lokaliseの料金は「何語に訳すか」ではなく「どれだけ訳すか」と「管理する人が何人か」で決まります。価格と数え方を分けて確かめます。
Lokaliseの有料4プラン｜月払いの価格と14日間の無料体験
Lokaliseの料金ページを2026年11月2日に確認したところ、Explorer・Growth・Advanced・Enterpriseの月払いの価格は次のとおりでした。いずれのプランも、クレジットカードの登録なしで14日間の無料体験ができます。
| プラン | 月額（米ドル・月払い） | 料金ページの説明 |
|---|---|---|
| Explorer | 149 | 基本機能を素早く使いたいチーム向け |
| Growth | 379 | 自動化と管理を強めたい拡大期のチーム向け |
| Advanced | 1,049 | 複数製品の複雑な運用を抱えるチーム向け |
| Enterprise | 個別見積もり | 独自のセキュリティと支援が要る組織向け |
料金ページに並ぶのは有料の4プランで、無料で使い続けられるプランは載っていません。Advancedはデモの予約から始まる導線になっています。各プランに含まれる処理語数や管理者席の数は、同じページの機能比較表で確かめてから見積もります。
言語数を増やしても課金が増えない処理語数モデル｜Crowdinとの数え方の差
料金ページのよくある質問は、Lokaliseが翻訳者の席、保存している翻訳の量、言語数には課金しないと説明しています。課金の軸は「処理語数」と「管理者席」の2つです。処理語数はプラットフォーム上で実際に翻訳された翻訳元の単語数で、保存している単語数ではありません。保存量にあたるホストワードは、有料プランなら無制限です。
管理者席は、マネージャー・開発者・コンテンツ作成者が使う席で、プランごとに一定数が含まれ、追加購入もできます。翻訳者と校正者の席は有料プランなら人数無制限です。同じTMSのCrowdinは「単語数×翻訳先言語数」のホストワードで上限を数えるため、言語を3つから6つに増やすと上限の消費も2倍になります。言語を頻繁に足す製品ではLokaliseの数え方のほうが費用が読みやすく、逆に言語は少ないが開発者が大勢設定に触る体制では、見積もりの焦点になるのは管理者席の数です。Crowdinの数え方の詳細はCrowdinの料金体系とCLI・GitHub連携の手順で解説しています。
Lokalise CLI v3の導入｜lokalise2の送信と承認済み訳の取得
開発フローに組み込む土台はCLIです。後述のGitHub Actionも内部でこのCLIを呼び出すため、フラグの意味を押さえておくとActionの設定も読み解けます。
CLI 3.1.7とconfig.yml｜APIトークンを別に渡す設定
CLIはlokalise-cli-2-goリポジトリで公開されているGo製の単体実行ファイルで、コマンド名はlokalise2です。リリース一覧では、2026年11月2日時点の最新が3.1.7（2026年7月14日）でした。3.1.0で非同期ダウンロードが加わっています。
# macOS（Homebrew）
brew tap lokalise/cli-2
brew install lokalise2
# Windows（Scoop）
scoop bucket add extras
scoop install lokalise2
# 版の確認（2026-11-02 時点の最新は 3.1.7）
lokalise2 --versionLinuxはリポジトリのインストールスクリプト、ほかにDockerイメージも配布されています。設定の既定の読み込み先はカレントディレクトリのconfig.ymlで、tokenとproject-idを記載すると毎回の指定が不要です。ただしリポジトリに入るファイルへトークンを書くのは避け、project-idだけを設定ファイルに置き、トークンは実行時に--tokenへ環境変数から渡す形にします。CLIのソースは環境変数を自動では読まないため、シェル側で展開して渡す点に注意が要ります。
file uploadの設定｜言語の指定と非同期処理の完了待機
翻訳元の送信はfile uploadです。file uploadの説明では、--fileと--lang-isoの2つが必須で、1回の実行で1ファイル・1言語を送ります。以下は--lang-isoで言語を指定し、--pollで完了を待つ設定例です。
# 認証情報は環境変数から渡す
export LOKALISE_API_TOKEN=＜APIトークン＞
export LOKALISE_PROJECT_ID=＜プロジェクトID＞
lokalise2 --token "$LOKALISE_API_TOKEN" \
--project-id "$LOKALISE_PROJECT_ID" \
file upload \
--file ./locales/en/common.json \
--lang-iso en \
--include-path \
--detect-icu-plurals \
--poll --poll-timeout 120sアップロードはサーバー側で非同期に処理されるため、CIでは--pollを付けて完了まで待たせます。待ち時間の上限の既定値は30秒で、ファイルが大きい場合に延長するための指定が--poll-timeoutです。--include-pathはフォルダ名を含めたファイル名で登録する指定で、言語別フォルダの構成をLokalise側にも残せます。ICU形式の複数形を使っている場合、その解析に使う指定は--detect-icu-pluralsです。翻訳ファイル側の複数形の書き方はi18nextの翻訳ファイル設計と複数形・補間の実装で扱っています。
避けたいのは--cleanup-modeの安易な指定です。送ったファイルに無いキーを全言語の訳ごと削除する動作で、説明文も事前にプロジェクトのスナップショットを取るよう促しています。
file downloadの設定｜校正済み訳の絞り込みと展開先の指定
訳文の取得はfile downloadです。言語ごとのファイルをZIPで受け取り、--unzip-toで指定したフォルダに展開します。
lokalise2 --token "$LOKALISE_API_TOKEN" \
--project-id "$LOKALISE_PROJECT_ID" \
file download \
--format json \
--original-filenames=true \
--filter-data reviewed \
--export-empty-as skip \
--export-sort a_z \
--unzip-to ./locales--filter-dataは書き出す範囲の絞り込みで、translated・untranslated・reviewedなどを指定できます。reviewedにすると校正済みの訳だけが出力されます。訳の無いキーの扱いは--export-empty-asで決め、emptyは空欄のまま、baseはベース言語の文で埋める、skipはキーごと省く動作です。日本語画面に英語が混ざるのを避けたいならskipにし、アプリ側のフォールバックで既定言語を出す設計と組み合わせます。pull用ActionのREADMEは1万キー×言語を超える規模で非同期モードを必須としており、CLIで同じ規模を扱うなら--asyncを付けます。この場合のダウンロードリンクの有効期間は24時間です。
GitHub Actionsでの同期｜公式push・pullとブランチのタグ管理
手でCLIを叩く運用は検証段階で終え、同期は自動化します。Lokaliseは翻訳元を送るpush用と、訳文を受け取るpull用の2つのGitHub Actionを分けて公開しています。
lokalise-push-action v5.7.0｜翻訳元の差分送信
GitHub Actionsの公式解説は、翻訳を管理する専用のブランチ（ハブブランチ）を決め、Lokaliseのキーにそのブランチ名のタグを付けて対応させる方式を推奨しています。lokalise-push-actionのREADMEに沿って、ハブブランチへのpushで英語の翻訳元を送る設定は次のとおりです。
# .github/workflows/lokalise-push.yml
name: Push to Lokalise
on:
push:
branches: [ lokalise-hub ]
paths: [ 'locales/en/**' ]
permissions:
contents: write
jobs:
push:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v7
with:
fetch-depth: 0
- uses: lokalise/[email protected]
with:
api_token: ${{ secrets.LOKALISE_API_TOKEN }}
project_id: ${{ secrets.LOKALISE_PROJECT_ID }}
base_lang: en
translations_path: locales
file_ext: jsonこのActionが送るのはベース言語のファイルだけです。既定では直近の2コミット（HEADとHEAD~1）を比べて変わったファイルを探すため、fetch-depth: 0で履歴を取得しておきます。初回の実行では全ファイルを送り、完了の印としてlokalise-upload-completeというGitタグをpushします。contents: writeの権限が要るのはこのためです。翻訳ファイルの置き方はlocales/en/*.jsonのような言語別フォルダが前提で、locales/en.jsonのような平らな構成ならflat_naming: trueを指定します。リリース一覧では、v5.7.0の公開日は2026年10月19日でした。
lokalise-pull-action v6.0.0｜タグ別の翻訳PR作成
lokalise-pull-actionは、実行したブランチ名と同じタグを持つキーだけを取得し、差分があればプルリクエストを作ります。翻訳者の作業が終わった時点で手動実行する形が基本です。
# .github/workflows/lokalise-pull.yml
name: Pull from Lokalise
on:
workflow_dispatch:
permissions:
contents: write
pull-requests: write
jobs:
pull:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v7
with:
fetch-depth: 0
- uses: lokalise/[email protected]
with:
api_token: ${{ secrets.LOKALISE_API_TOKEN }}
project_id: ${{ secrets.LOKALISE_PROJECT_ID }}
base_lang: en
translations_path: locales
file_format: json
additional_params: >
{"export_empty_as": "skip", "export_sort": "a_z"}プルリクエストを作るには、リポジトリのSettingsのActions設定でWorkflow permissionsを読み書き可能にし、Actionsによるプルリクエストの作成を許可しておきます。作業用ブランチは既定でlokで始まる名前になり、固定名で同じプルリクエストを更新し続けたい場合に使う指定はoverride_branch_nameです。ベース言語の変更は既定では取り込まれず、含めたい場合はalways_pull_base: trueを指定します。
2026年10月20日公開のv6.0.0には破壊的変更があります。拡張子の照合が大文字と小文字を区別するようになり、jsonとJSONは別の値として扱われます。ベースブランチを解決できないときにmainへ自動で切り替える動作も廃止されました。v5系から上げる際は、file_extの大文字小文字と、ベースブランチの指定を見直します。
GitHubアプリ連携の制約｜App triggersの権限と起点
Actionを使わず、Lokalise側に用意されたGitHub連携で同期する方法もあります。GitHub連携の説明によると、Lokaliseのダウンロード画面にあるApp triggersでGitHubを有効にすると、設定したブランチの最新の版からlokalise-2018-03-12_15-14-13のような日時入りのブランチが作られ、元のブランチへのプルリクエストが届きます。CLIから同じ処理を起動するための指定はfile download --triggers githubです。
違いは権限と起点です。GitHubアプリはリポジトリへの読み書き権限をまとめて求めるのに対し、Actionはワークフローごとにpermissionsで権限を絞れます。Lokaliseのプロジェクトブランチ機能を使っている場合、App triggersを実行できるのはLokaliseのmasterブランチだけという制約です。権限の管理が厳しい組織や、Gitのブランチと翻訳の版を細かく対応させたい案件では、Actionを選びます。
Lokaliseを採用する条件と見送る場面｜Crowdinとの選び分けと言語数の線引き
LokaliseとCrowdinは、翻訳元を取り込み、翻訳者に割り振り、訳文を書き出すという骨格が共通です。選び分けは機能の多さではなく、課金の軸と翻訳ファイルの形で決まります。
Lokaliseを選ぶ条件｜言語数が多くキーとタグで画面単位に管理したい製品
Lokaliseを選んでよいのは、翻訳先が5言語を超えていてさらに増える予定があり、翻訳ファイルがJSONやStringsのようなキーと値の形式に揃っている製品です。言語数に課金しない料金体系なので、市場を広げるたびに契約を見直す必要がありません。キーにタグとプラットフォームを持たせられるため、Web・iOS・Androidで同じ文言を共有しつつ、画面や機能単位で翻訳の進み具合を追う運用にも合います。
Crowdinを選ぶのは、Markdownで書いたドキュメントの翻訳が中心の場合や、オープンソースとして無料プランで始めたい場合です。言語数が2〜3で固定され、翻訳する量のほうが多い製品では、ホストワードで数えるCrowdinの下位プランのほうが安く収まります。App Routerでの多言語化のように画面側の実装から詰める段階なら、next-intlでのルーティングとメッセージ分割の手順を先に決めてからTMSを選ぶと、翻訳ファイルの構成で迷いません。
Lokaliseを見送る場面｜月額149ドルが重い2言語サイトとCMS内の翻訳
見送る場面は2つです。第一に、日本語と英語の2言語で、翻訳キーが数十個の小規模サイトです。最も安いExplorerでも月額149米ドルかかり、開発者がリポジトリ内のJSONを直接直す運用のほうが費用も手間も小さく収まります。
第二に、本文の翻訳がCMSの中で完結するコーポレートサイトです。WordPressの記事本文などはCMSの多言語機能で管理するのが素直で、Lokaliseを挟むと翻訳の置き場所が2つに分かれます。Lokaliseの守備範囲は、アプリの画面文言のようにキーで管理できる翻訳です。どこまでを翻訳と地域化の対象にするかはローカライズの対象範囲と実施可否の判断基準で整理しています。
多言語アプリの構築を外部に依頼する際に決める翻訳の同期経路と承認者
Lokaliseの初期設定は、CLIの設定とpush・pullの2つのワークフローで済む規模の作業です。手間がかかるのは運用の決め事で、ベース言語を何にするか、誰が訳を校正済みにするか、校正前の訳を画面に出すかを先に決めないと、Actionのパラメータを確定できません。外部に構築を依頼するなら、プロジェクト種別、同期の経路（GitHubアプリかActionか）、書き出す訳の範囲（--filter-dataの値）の3点を要件定義で固めておくと、公開後に翻訳の流れを組み直さずに済みます。
サイト全体の言語やURLの設計は多言語サイト制作の進め方と言語・URL設計の判断基準で解説しています。当社は英語サイト制作・多言語サイト制作として、翻訳管理の仕組みを含めた多言語サイトの構築を受託しています。
よくある質問
Lokaliseの導入を検討するときによく挙がる疑問を、公式の料金ページ、ドキュメント、GitHubリポジトリの記述をもとに整理します。
Lokaliseは無料で使えますか？
料金ページに並ぶのはExplorer・Growth・Advanced・Enterpriseの有料4プランで、無料で使い続けられるプランは載っていません。代わりに、すべてのプランでクレジットカードの登録なしに14日間の無料体験ができます。体験期間のうちに、CLIでの送受信と、pushとpullのActionを1往復させて、自社のファイル構成で動くかを確かめておくと、契約後の設定で迷いません。
既存の日本語や韓国語の訳文もまとめて取り込めますか？
取り込めますが、push用のActionは使えません。Actionが送るのはベース言語のファイルだけだと公式解説に書かれているためです。既存の訳文は、CLIのfile uploadを言語ごとに実行し、--lang-isoにjaやkoを指定して送ります。訳文がすでにLokalise上にあるキーを上書きしたい場合は--replace-modifiedを付けます。
GitLabやBitbucketでも同期できますか？
公式のpushとpullのActionはGitHub Actions専用で、公式解説も他のCIではそのまま動かないとしています。GitLabやBitbucketでの同期は、CLIのlokalise2をCIのジョブから呼び出す形です。Lokalise側の連携機能もあり、file downloadの--triggersにはgitlabやbitbucketを指定できます。いずれもプロジェクト設定で連携を有効にしておくことが前提です。
APIトークンにはどの権限が必要ですか？
トークンはユーザー単位で発行され、そのユーザーのプロジェクト権限がそのまま効きます。push用のActionのREADMEは読み書きのできるトークンと、プロジェクトでのファイルアップロード権限を求めています。pull用に必要なのは、読み取りのできるトークンです。CIではトークンをリポジトリのシークレットに登録し、取得だけを行うジョブには読み取り用のトークンを分けて渡すと、漏えい時の影響を狭められます。
機械翻訳やAIで下訳を作る運用はできますか？
下訳の作成にも対応しています。料金ページには、標準のAI・機械翻訳による訳語数と、上位のPro AIによる訳語数が別の枠として並び、各プランに含まれる量は機能比較表で照合する項目です。下訳を人が校正する運用なら、ダウンロード時に--filter-data reviewedを指定し、校正前の下訳を公開しないようにします。機械翻訳とAI翻訳の違いはAI翻訳の仕組みと従来の機械翻訳との違いにまとめています。
