Crowdinとは：翻訳管理をCLIとGitHub連携で開発フローに組み込む手順と料金【CLI 5.5系】

Crowdinは、アプリやWebサイト、ドキュメントの翻訳をクラウド上でまとめて管理する翻訳管理システム（TMS）です。開発者はリポジトリにある翻訳元のファイルをCrowdinへ送り、翻訳者はブラウザのエディタで訳し、仕上がった訳文がファイルとしてリポジトリへ戻ってきます。この記事では、Crowdinが受け持つ範囲と作成後に変えられないプロジェクト種別、料金ページで確認した4プランの価格とホストワードの数え方、2026年11月2日時点で5.5.0が最新のCrowdin CLIの導入とcrowdin.ymlの書き方、GitHubとの同期方法、採用する条件と見送る場面を、公式ドキュメントの記述をもとに実装の順番で整理します。

まとめ：Crowdinを入れる条件と最初に決めるプロジェクト種別・同期の経路

翻訳先が3言語以上あり、画面の文言が毎週のように変わり、社外の翻訳者も作業に加わる。この3つが揃う製品なら、Crowdinを入れる価値があります。翻訳ファイルを開発者が手でやり取りする運用は、言語と更新回数の掛け算で破綻するからです。

着手前に決めるのは2点です。1つはファイルベースか文字列ベースかというプロジェクト種別で、作成後には変更できません。もう1つは同期の経路で、Crowdin側の公式GitHub連携に任せるか、CLIやGitHub Actionで自社のCIから動かすかを選びます。日本語と英語の2言語で、翻訳キーが数十個しかないサイトなら、Crowdinを入れずにリポジトリ内のJSONで管理するほうが安く済みます。

Crowdinの定義｜翻訳ファイルを開発リポジトリの外で管理するTMSの役割

最初に、Crowdinが何を引き受け、何を利用者側に残すのかを確かめます。

翻訳管理システムとしての受け持ち範囲｜翻訳メモリと用語集の位置づけ

Crowdinの役割は、翻訳対象の文字列を取り込み、翻訳者に割り振り、訳文を元の形式で書き出すまでの管理です。CLIのコマンド一覧を見ると、ファイルの送受信のほかにglossary（用語集）、tm（翻訳メモリ）、screenshot（画面写真の紐づけ）、task（翻訳作業の割り当て）が並びます。翻訳メモリは過去の訳文を再利用する仕組みで、同じ文が別の画面に出たときに既存の訳を候補として出します。

Crowdinはアプリに翻訳を組み込む処理までは担いません。画面に訳文を表示するのは、i18nextやAngularのi18nといったアプリ側のライブラリの仕事です。Crowdinはその翻訳ファイルを外から出し入れする管理層にあたります。国際化と地域化の区別はi18nとl10nの違いとAngularでの実装手順で整理しています。

ファイルベースと文字列ベース｜作成後に変更できないプロジェクト種別

プロジェクト作成の説明によると、Crowdinのプロジェクトはファイルベースと文字列ベースの2種類です。作成後に種別とアドレスは変更できないと明記されているため、最初の選択がそのまま運用の形を決めます。

文字列ベースの書き出し形式は、JSON・iOS Strings・Android XMLから選ぶ方式です。リポジトリのファイル構成を正とし、CIで同期するならファイルベースを選びます。後述するGitHub連携の「翻訳元の送信」や「既存翻訳の取り込み」はファイルベース専用です。文字列ベースは、企画担当者が開発者を介さずに文言を直したい場合に向きますが、一部の連携機能が使えないと公式に書かれています。

Crowdinの料金体系｜ホストワードの数え方と無料・Pro・Team・Team+の違い

料金は「誰が何人で使うか」より「何語を何言語に訳すか」で決まります。プランの価格と、上限の数え方を分けて確かめます。

4プランの起点価格｜翻訳者を人数無制限で招待できる有料プランの範囲

Crowdinの料金ページに埋め込まれた価格情報を2026年11月2日に確認したところ、個人・チーム向けの4プランは次の価格でした。組織向けのCrowdin Enterpriseは年払いのみで、価格は個別見積もりです。

同じページのよくある質問では、有料プランなら翻訳者と校正者を人数の上限なく招待できるとしています。費用が人数に比例しない点は、社外の翻訳会社や有志の翻訳者を多く招く案件で利点になる仕組みです。逆に、開発者がGitHub連携やファイル送信を設定する立場になるならTeam以上が前提になります。無料体験はCrowdinがTeamプラン相当で14日間、Enterpriseが30日間です。

ホストワードは単語数×翻訳先言語数｜言語追加で上限に届く見積もり方

各プランの上限を数える単位は、ホストワードです。料金ページの定義は「翻訳対象の単語数×プロジェクトの翻訳先言語数」で、500語のファイルを10言語に訳すプロジェクトなら5,000ホストワードになるという例が載っています。上限はアカウント（Enterpriseでは組織）配下の全プロジェクトの合計に掛かります。

見積もりで外しやすいのは言語の追加です。文言の量が同じでも、翻訳先を3言語から6言語に増やすとホストワードは2倍になります。予算を組むときは、現在の単語数ではなく「1年後の単語数×予定する言語数」で上限を照合するのが見積もりの基準です。Crowdinのバッジを自社サイトに掲げると、個人プランで上限が2倍、組織プランで5,000文字列が加算される制度もあります。オープンソースのプロジェクトは無料プランで申請でき、教育目的ならアカデミックライセンスを申請できます。

Crowdin CLIの導入手順｜crowdin.ymlの記法と翻訳ファイルの送受信

開発フローに組み込む中心はCLIです。GitHub Actionも内部で同じCLIを動かすため、ここで設定ファイルの書き方を押さえておけば、CIへの移行もそのまま通ります。

CLI 5.0のTypeScript化｜Java不要の導入方法と5.5.0の要件

CLI 5.0の告知（2026年8月26日）によると、5系はJavaからTypeScriptへの全面的な書き直しで、Bunで動く単一の実行ファイルとして配布されます。4系までは実行環境にJavaが必要でした。告知に載っているApple Siliconでの計測では、crowdin --versionの起動時間が4系の223ミリ秒から1.6ミリ秒に縮んでいます。

# npm で入れる（npm registry の engines は node 20以上）
npm i -g @crowdin/cli

# macOS は Homebrew
brew tap crowdin/crowdin
brew install crowdin@5

# Windows は WinGet
winget install Crowdin.CrowdinCLI

# 版の確認（2026-11-02 時点の latest は 5.5.0）
crowdin --version

導入方法の説明には、ほかにChocolatey、Docker、Linux向けのパッケージリポジトリ、単体の実行ファイルが並びます。npm registryの記録では5.5.0の公開は10月21日で、ライセンスはMITでした。ソースはCLIのGitHubリポジトリで公開されています。CIのイメージにJavaを入れていたのが4系を使っていた名残なら、5系へ上げる際に外せます。

crowdin.ymlのfiles設定｜翻訳元と出力先のプレースホルダー指定

CLIは、リポジトリ直下のcrowdin.ymlを読んで、どのファイルを送り、訳文をどこへ書き出すかを決めます。設定ファイルの説明に沿って、i18next形式のJSONを英語から日本語・韓国語に訳す構成を書くと次のようになります。

# crowdin.yml（リポジトリ直下に置く）
"project_id_env": "CROWDIN_PROJECT_ID"
"api_token_env": "CROWDIN_PERSONAL_TOKEN"
"base_path": "."
"preserve_hierarchy": true

"files": [
  {
    "source": "/locales/en/**/*.json",
    "translation": "/locales/%two_letters_code%/**/%original_file_name%"
  }
]

sourceは翻訳元ファイルの絞り込み、translationは訳文の書き出し先です。%two_letters_code%はjaやkoのような2文字の言語コードに置き換わり、ほかに%locale%や%android_code%など12種類のプレースホルダーが用意されています。preserve_hierarchyをtrueにしないと、Crowdin上でフォルダ構成が平らにまとめられます。

APIトークンをapi_tokenに直接書くのはやめます。設定ファイルの説明はバージョン管理と連携する場合に認証情報をファイルの先頭に置かないよう求めており、上の例のように_env付きのキーで環境変数名を指すのが安全です。翻訳ファイル自体の構造はi18nextの翻訳ファイル設計とSSR読み込みの実装で扱っています。

翻訳元のアップロードと訳文のダウンロード｜承認済みの訳だけ取り込むCLI指定

日々の同期は、翻訳元を送るupload sourcesと、訳文を受け取るdownload translationsの2つで回ります。送る前にconfig lintで設定ファイルを検査しておくと、パスの書き間違いで空振りするのを防げます。

# 環境変数で認証情報を渡す
export CROWDIN_PROJECT_ID=123456
export CROWDIN_PERSONAL_TOKEN=＜個人アクセストークン＞

crowdin config lint                 # 設定ファイルの検査
crowdin upload sources              # 英語の翻訳元を送る
crowdin status                      # 言語ごとの翻訳・校正の進み具合
crowdin download translations \
  --export-only-approved \
  --skip-untranslated-strings       # 承認済みの訳だけを書き出す

download translationsの説明によると、--export-only-approvedは承認済みの訳だけを書き出すオプションです。--skip-untranslated-stringsと組み合わせないと、未承認の行には翻訳元の英語が入ります。英語の文言が日本語画面に混ざるのを嫌うか、空欄でキーが表示されるのを嫌うかで、アプリ側のフォールバック設定と合わせて決めます。--dryrunを付けると、実際には書き出さずに対象ファイルだけを表示する動作です。

GitHubとの同期方法｜Crowdin側の公式連携とGitHub Actionの使い分け

CLIを手で叩く運用は最初の数回で終わらせ、同期は自動化します。経路は、Crowdin側が定期的にリポジトリを見に行く公式連携と、自社のCIから動かすGitHub Actionの2つです。

公式GitHub連携の仕組み｜l10n_ブランチと1時間ごとの自動同期

GitHub連携の説明によると、公式連携は翻訳対象のブランチごとに、既定でl10n_で始まる翻訳用のブランチを作ります。Crowdinはmainへ直接コミットせず、訳文を載せたプルリクエストを送ってきます。同期の既定の動作は、1時間ごとの自動実行です。

連携を設定したブランチにcrowdin.ymlが無いと、状態が「Not Ready」になって同期されません。個人アクセストークンで接続する場合は、対象リポジトリの管理者権限が必要です。文字列ベースのプロジェクトでは、Crowdinから訳文を書き出すだけのモードしか使えません。翻訳元を自動で取り込むにはファイルベースを選ぶ必要がある、という点が前章の種別選びに効いてきます。

GitHub Action v3.5.0｜pushを契機に翻訳のプルリクエストを作る設定

同期のタイミングを自社で握りたいなら、公式のGitHub Actionを使います。READMEのサンプルに沿って、mainへのpushで翻訳元を送り、訳文をプルリクエストで受け取る設定は次のとおりです。

# .github/workflows/crowdin.yml
name: Crowdin Action

on:
  push:
    branches: [ main ]

jobs:
  synchronize-with-crowdin:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v7

      - name: crowdin action
        uses: crowdin/github-action@v3
        with:
          upload_sources: true
          upload_translations: false
          download_translations: true
          localization_branch_name: l10n_crowdin_translations
          create_pull_request: true
          pull_request_title: 'New Crowdin Translations'
          pull_request_base_branch_name: 'main'
        env:
          GITHUB_TOKEN: ${{ secrets.GH_TOKEN }}
          CROWDIN_PROJECT_ID: ${{ secrets.CROWDIN_PROJECT_ID }}
          CROWDIN_PERSONAL_TOKEN: ${{ secrets.CROWDIN_PERSONAL_TOKEN }}

GitHub releasesの記録では、Actionの最新版はv3.5.0（2026年10月21日）です。READMEは、Crowdin側の個人トークンに付ける権限として、プロジェクトの読み取り、翻訳状況の読み取り、翻訳元と訳文の読み書きを挙げています。公式連携との違いは同期の起点です。公式連携は1時間ごとにCrowdinから来るのに対し、Actionはpushやスケジュールなど自社が決めた契機で動きます。リリース直前に訳文をまとめて取り込みたい案件では、Actionのほうが扱いやすくなります。

CLI 4系から5系へ上げる際の変更点｜pre-translateの改名と出力形式

コマンド名とcrowdin.yml、終了コードは5系でも変わらないため、多くのCIはそのまま動きます。手を入れる必要があるのは、追加の引数を渡しているジョブです。

• 機械翻訳や翻訳メモリで事前に訳を埋めるpre-translateはauto-translateに改名され、別名は残っていません
• --translate-untranslated-onlyは削除され、--scopeで範囲を指定します（未翻訳のみが既定）
• --plainは削除され、全体オプションの--output plainに置き換わりました
• upload sources --cacheのキャッシュの置き場所が、実行ディレクトリからbase_path基準に変わりました

Actionもv3で同じ書き直しを取り込んでおり、READMEはcommandや*_argsで独自の引数を渡している場合だけ上記を見直すよう案内しています。auto-translateの説明では、訳を埋める方法としてmt（機械翻訳）、tm（翻訳メモリ）、aiの3値から選ぶ指定です。機械翻訳とAI翻訳の違いはAI翻訳の仕組みと従来の機械翻訳との違いにまとめています。

Crowdinを採用する条件と見送る場面｜翻訳先の言語数と更新頻度で線を引く

Crowdinは導入すれば翻訳が速くなる道具ではありません。翻訳の受け渡しが詰まっている案件でだけ効きます。

Crowdinを採用してよい条件｜3言語以上・毎週の文言変更・社外翻訳者

採用してよいのは、翻訳先が3言語以上、画面の文言が毎週のように変わる、社外の翻訳者が作業に加わる、の3条件が揃う製品です。この条件では、開発者が翻訳ファイルをメールや共有フォルダで受け渡す運用が、言語数×更新回数ぶんの手作業になります。Crowdinに寄せると、翻訳元の送信と訳文の取り込みがCIの一工程になり、開発者の手から離れます。

ドキュメントの多言語化も向いています。Markdownを翻訳元にし、訳文をプルリクエストで受け取る流れは、Docusaurusでのドキュメントサイト構築のような静的サイトの運用と相性がよいからです。オープンソースなら無料プランで始められる点も、この用途を後押しします。

Crowdinを見送る場面｜2言語で数十キーの小規模サイトとCMS内の翻訳

見送る場面は2つあります。第一に、日本語と英語の2言語で、翻訳キーが数十個しかない小規模サイトです。訳文は開発者がリポジトリ内のJSONを直接直せば足り、Teamプランの月額や設定の手間のほうが大きくなります。

第二に、本文の翻訳がCMSの中で完結するコーポレートサイトです。WordPressなどの記事本文はCMSの多言語機能や翻訳プラグインで管理するのが素直で、Crowdinに出し入れすると管理場所が2つに割れます。Crowdinの守備範囲は、アプリの画面文言やドキュメントのように、ファイルとしてリポジトリに置かれる翻訳です。どこまでを翻訳・地域化の対象にするかはローカライズの対象範囲と実施可否の判断基準で整理しています。

多言語サイトやアプリの構築を外部に依頼する際に決める翻訳の更新経路

Crowdinの初期設定そのものは、crowdin.ymlとワークフローの2ファイルで済む規模の作業です。工数がかかるのは、翻訳元の言語をどれにするか、誰が訳を承認するか、承認前の文言を画面に出すかといった運用の決め事のほうにあります。外部に構築を依頼するなら、プロジェクト種別、同期の経路（公式連携かActionか）、未承認の訳の扱いの3点を要件定義で固めておくと、公開後に翻訳の流れを組み直さずに済みます。

サイト全体の言語やURLの設計は多言語サイト制作の進め方と言語・URL設計の判断基準で解説しています。当社は英語サイト制作・多言語サイト制作として、翻訳管理の仕組みを含めた多言語サイトの構築を受託しています。

よくある質問

Crowdinの導入検討でよく挙がる疑問を、公式の料金ページとドキュメントの記述をもとに整理します。

Crowdinは無料でどこまで使えますか？

料金ページにはFreeプランがあり、翻訳者向けの基本機能を使え、オープンソースのプロジェクトも利用できると書かれています。非公開のプロジェクトを作るにはPro以上が必要です。オープンソースは無料アカウントでプロジェクトを作ってから申請し、教育目的ならアカデミックライセンスを申請できます。認められたライセンスはプロジェクト数・文字列数・メンバー数が無制限です。

Crowdinの公式情報は日本語で読めますか？

公式サイトには日本語版（ja.crowdin.com）があり、製品紹介やデモ予約のページを日本語で読めます。一方、CLIの説明や設定ファイルの仕様など開発者向けのドキュメントは英語が中心です。導入時に読むcrowdin.ymlの項目名やコマンドは英語のまま使うため、本記事のコード例のように英語の仕様に沿って書きます。

CrowdinとLokaliseやPhraseは何が違いますか？

いずれも翻訳管理システムで、翻訳元の取り込み、翻訳者への割り振り、訳文の書き出しという骨格は共通です。違いが出るのは課金の単位と連携の作り方です。Crowdinは翻訳先の言語数を掛けたホストワードで上限を数え、有料プランなら翻訳者の人数に上限がありません。比較する際は、1年後の単語数と言語数で各社の見積もりを取り、GitHub連携が自社のブランチ運用に合うかを確かめます。

APIトークンはどこに保存すればよいですか？

リポジトリに入るcrowdin.ymlには書かず、環境変数に置きます。設定ファイルではapi_token_envに環境変数名を指定し、GitHub ActionならリポジトリのシークレットにCROWDIN_PERSONAL_TOKENとして登録します。トークンには同期に必要な権限だけを付け、翻訳元と訳文の読み書き、プロジェクトと翻訳状況の読み取りに絞るのが、Actionの説明が示す基本形です。

機械翻訳やAIで下訳を作ってから人が直す運用はできますか？

できます。CLIのcrowdin auto-translateで、機械翻訳・翻訳メモリ・AIのいずれかを選んで未翻訳の文字列を埋め、その後に翻訳者がエディタで校正する流れです。--methodにmt、tm、aiを指定し、--skip-approved-translationsを付ければ承認済みの訳は上書きしません。下訳のまま公開しないよう、ダウンロード時は--export-only-approvedと組み合わせます。

関連記事

• i18nextとは：翻訳ファイルの設計と複数形・補間・SSR読み込みの実装手順【v26対応】
• i18n（国際化）とは？読み方・l10nとの違いとAngularでの実装手順【Angular 22】
• Docusaurusとは：ドキュメントサイトの構築手順とバージョン管理・多言語・検索の設定【3.10対応】
• ローカライズとは？翻訳・国際化との違いと対象範囲・実施可否の判断基準
• 多言語サイト制作とは？進め方・費用相場と言語・URL設計の判断基準を解説