Lingo.dev完全ガイド：AI駆動i18nツールキットでコードベースの多言語対応を自動化する方法

Lingo.devの5コンポーネント構成

• Lingo React MCP: AIアシスタントがi18n設定を正確に行えるよう、フレームワーク固有の知識を提供
• Lingo CLI: コマンドライン1つでJSONなど各形式のファイルを翻訳
• Lingo CI/CD: GitHub Actionsによるパイプライン統合で継続的ローカライズを実現
• Lingo API: バックエンドコードから直接呼び出せる翻訳エンジン
• Lingo Compiler: ビルド時にReactコンポーネントを多言語化するアルファ版機能</div>

ロックファイル（i18n.lock）の仕組みが翻訳の差分管理を担う。一度翻訳したコンテンツのハッシュが記録され、次回実行時には変更・追加された箇所のみが処理される。翻訳APIコールを最小化し、コストと処理時間を抑える設計だ。

技術アーキテクチャ：pnpmモノレポとLLM統合の仕組み

Lingo.devはpnpm + turborepoで管理されるモノレポ構成だ。packages/以下に各コンポーネントのソースが格納され、i18n.jsonでサポートする言語ロケールを定義している。

翻訳エンジンは2種類から選択できる。1つ目はLingo.devのクラウドロケールエンジンで、用語集・ブランドボイス・ロケール別指示が永続化され、繰り返しの翻訳でも一貫性が保たれる。研究では用語エラーを16.6〜44.6%削減できることが確認されている。2つ目は自前のLLMで、OpenAI、Anthropic（Claude）、Google Gemini、Mistral、OpenRouter、Ollamaを設定可能だ。

MCPコンポーネント（Lingo React MCP）はAIアシスタントにi18n固有の知識を提供する役割を持つ。Claude Code、Cursor、GitHub Copilot Agents、Codexとの連携に対応している。Next.js、React Router、TanStack Startのi18n設定において、AIアシスタントが実在するAPIを正確に使えるようにするフレームワーク固有の知識を注入する。

インストールとクイックスタート：CLIを使った最初の翻訳

前提条件

# Node.js（LTS推奨）とnpmが必要
node --version
npm --version

# または pnpm を使う場合
pnpm --version

Step 1：CLIのセットアップ

# プロジェクトルートでinitコマンドを実行
npx lingo.dev@latest init

このコマンドを実行すると対話式の設定フローが始まる。翻訳エンジンの選択（Lingo.devクラウドまたは自前LLM）、ソースロケール、ターゲットロケールを指定する。設定結果はi18n.jsonに書き出される。

Step 2：翻訳を実行

# 未翻訳のコンテンツを処理
npx lingo.dev@latest run

初回実行時はすべてのローカライズ対象ファイルが処理され、i18n.lockに翻訳済みコンテンツのハッシュが記録される。2回目以降は差分のみが処理される。

Lingo.devクラウドエンジンを使う場合のi18n.json例

{
  "version": "1.0",
  "locale": {
    "source": "en",
    "targets": ["ja", "zh-Hans", "de", "fr", "ko"]
  },
  "buckets": [
    {
      "include": ["src/locales/en/*.json"]
    }
  ]
}

自前LLMを使う場合の設定例（.env）

# OpenAI を使う場合
OPENAI_API_KEY=sk-...

# Anthropic (Claude) を使う場合
ANTHROPIC_API_KEY=sk-ant-...

# Ollama（ローカルLLM）を使う場合
OLLAMA_BASE_URL=http://localhost:11434

GitHub Actionsによる継続的ローカライズの構築

CI/CDへの統合方法

push時に自動で翻訳を処理するワークフローの設定例：

# .github/workflows/localize.yml
name: Continuous Localization

on:
  push:
    branches: [main]
    paths:
      - 'src/locales/en/**'

jobs:
  localize:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Run Lingo.dev localization
        uses: lingodotdev/lingo.dev@main
        with:
          api-key: $
      
      - name: Commit translated files
        uses: stefanzweifel/git-auto-commit-action@v5
        with:
          commit_message: "chore: update translations [skip ci]"
          file_pattern: 'src/locales/**/*.json'

GitLab CI/CDとBitbucket Pipelinesにも対応している。

GitLab CI/CDの設定例

# .gitlab-ci.yml
localize:
  stage: deploy
  script:
    - npx lingo.dev@latest run
  only:
    - main
  variables:
    LINGODOTDEV_API_KEY: $LINGODOTDEV_API_KEY

Lingo React MCPの設定とAIアシスタント連携

MCP経由のi18n知識提供機能は、AIアシスタントがフレームワーク固有のi18n設定を誤って実装しないよう設計されている。

Claude Codeへの設定

# Claude Codeにlingo MCPを追加
claude mcp add lingo -- npx lingo.dev@latest mcp

Cursor / Cline向けの設定

{
  "mcpServers": {
    "lingo": {
      "command": "npx",
      "args": ["lingo.dev@latest", "mcp"]
    }
  }
}

設定後、AIアシスタントに「Set up i18n for my Next.js App Router project」と指示するだけで、Lingo MCPが提供するNext.js固有のi18n知識をもとに正確な設定が生成される。

Lingo Compiler for React（早期アルファ）

Lingo Compilerはビルド時翻訳という新しいアプローチを取る。従来のi18nではt("key")のような翻訳関数の呼び出しとJSONキーファイルの管理が必要だったが、Lingo Compilerはそれを不要にする。

コンポーネントにプレーンな英語テキストを書き、ビルド時にコンパイラが翻訳済みバリアントを生成する仕組みだ。

// 従来のi18n方式（t()関数が必要）
function Greeting() {
  const { t } = useTranslation();
  return <h1>{t("greeting.title")}</h1>;
}

// Lingo Compiler方式（プレーンテキストで書ける）
function Greeting() {
  return <h1>Welcome to our application</h1>;
}

Next.js（App Router）とVite + Reactをサポートする。withLingo()プラグインをビルド設定に追加するだけで有効化できる。

// next.config.js
import { withLingo } from "@lingo.dev/compiler";

const nextConfig = {
  // ... 既存の設定
};

export default withLingo(nextConfig);

まだ早期アルファ段階であり、本番利用には慎重な評価が必要だが、i18nの開発体験を根本から変える可能性がある。

実践的なユースケース

ユースケース1：既存のReact/Next.jsプロジェクトへの統合

既存のプロジェクトにen.json等の翻訳ファイルが存在する場合、Lingo CLIはそれらをそのまま認識して差分管理を開始できる。lingo.dev initで設定を生成してからlingo.dev runを実行するだけで既存ファイルに対する翻訳処理が始まる。

ユースケース2：マークダウンドキュメントの多言語化

# ドキュメントサイトのMarkdownファイルを翻訳
npx lingo.dev@latest run --include "docs/**/*.md"

技術ドキュメントやREADMEの翻訳にも対応している。マークダウン構造を理解した上で翻訳が行われるため、コードブロックや見出し構造が崩れない。

ユースケース3：POファイルを使うPHPやPythonプロジェクト

WordPressや Djangoなど、POファイル形式でローカライズを管理するプロジェクトにも対応する。gettext形式のPOファイルをそのまま翻訳対象として指定できる。

# POファイルを翻訳
npx lingo.dev@latest run --include "locale/**/*.po"

ユースケース4：モノレポ内の複数パッケージを一括ローカライズ

# プロジェクトルートから全パッケージを処理
npx lingo.dev@latest run --include "packages/**/locales/en.json"

turborepoやNxで管理するモノレポでも、一度のコマンドで複数パッケージの翻訳ファイルを処理できる。

競合・代替ツールとの比較

i18n管理ツールはカテゴリが広く、TMS（Translation Management System）から開発者向けツールまで多岐にわたる。Lingo.devの位置付けを整理する。

Lingo.devの差別化点は、翻訳エンジンとしてのLLM統合、MCPによるAIアシスタント連携、ロックファイルによる差分管理の3点だ。Crowdinなどの従来型TMSは翻訳担当者と承認ワークフロー重視の設計で、開発者が自律的に使うには学習コストが高い。Lingo.devは開発者フローへの統合を優先している。

RAG構築との組み合わせについてはRAGFlowも参考になる。多言語対応とRAGを組み合わせる場合の検索精度は翻訳品質に大きく依存するため、ローカライズエンジンの一貫性が重要になる。

よくある質問・つまずきポイント

Q: lingo.dev init後にどのファイルが翻訳対象として認識されますか？

i18n.jsonのbuckets.includeグロブパターンにマッチするファイルが対象になる。lingo.dev run --dry-runオプション（存在する場合）で事前に確認できる。意図しないファイルが含まれないようグロブパターンは具体的に書くことを推奨する。

Q: 翻訳の一貫性（用語の統一）はどう管理しますか？

Lingo.devクラウドエンジンを使う場合は、Lingo.devのウェブダッシュボードでロケールエンジンに用語集とブランドボイス設定を追加できる。自前LLMを使う場合はシステムプロンプトやfew-shotサンプルで一貫性を担保する設計が必要だ。

Q: 翻訳結果を手動でレビュー・修正できますか？

はい。翻訳されたファイルは通常のテキストファイルとして直接編集できる。修正後にコミットすればi18n.lockに変更が記録され、次回のlingo.dev runでは修正部分の再翻訳は行われない。

Q: 大量のファイルを翻訳するとAPIコストはどれくらいかかりますか？

Lingo.devクラウドエンジンを使う場合はLingo.devの料金体系に依存する。自前LLMを使う場合はそのプロバイダーのトークン料金が適用される。ロックファイルの差分管理により、初回以降は変更箇所のみ処理されるためコストは抑えられる。

Q: プライベートリポジトリでCI/CDを使う際の権限設定は？

GitHub ActionsではLINGODOTDEV_API_KEYをリポジトリのSecretsに設定する。翻訳済みファイルをコミットする場合はGitHub Actionsのデフォルトトークンまたは専用PAT（Personal Access Token）が必要になる。

OSS開発コントリビューションガイド

Lingo.devはOSSとして開発への参加を歓迎している。モノレポ構成の開発環境セットアップ手順は以下の通りだ。

# リポジトリのクローン
git clone https://github.com/lingodotdev/lingo.dev.git
cd lingo.dev

# 依存パッケージのインストール
pnpm install

# テストの実行
pnpm test

# ビルド
pnpm build

PRを作成する際はpnpm newでチェンジセットを追加することが必須要件となっている。非リリース変更（ドキュメント更新など）にはpnpm new:emptyを使う。

まとめ

Lingo.devはGitHubスター5,400超のオープンソースi18nツールキットで、MCP・CLI・CI/CD・API・Compilerの5コンポーネントがローカライズエンジニアリングを包括的にカバーする。

CLIのnpx lingo.dev@latest runコマンドだけで始められ、JSON・YAML・Markdown・CSV・POファイルの差分翻訳が自動化できる。自前LLMとの統合で完全にセルフホスト可能な構成も取れる。GitHub Actions統合による継続的ローカライズは、英語コードベースをグローバル展開する際の人手コストを削減する実用的な選択肢だ。

AIエージェントフレームワーク比較2026で紹介している通り、AIがコード開発をアシストする時代において、i18nのような反復的なエンジニアリング作業の自動化ニーズは高まり続けている。Lingo.devはその流れに沿った実用的なツールだ。

参照ソース

• lingodotdev/lingo.dev - GitHub
• Lingo.dev 公式ドキュメント
• Lingo.dev MCP ドキュメント
• Product Hunt - Lingo.dev
• Retrieval-Augmented Localization 研究