LASSIC Media らしくメディア
多言語対応開発の外注費用と進め方|i18n・l10nを実務解説
LASSIC IT事業部|元請(プライムベンダー)としてシステム保守・運用を受託
この記事のポイント
- i18n(国際化)とl10n(ローカライズ)は別工程であり、外注範囲の切り分けが費用を左右します。
- 機械翻訳と人手翻訳の使い分け、翻訳管理ツール(TMS)の活用で対応コストを抑えられます。
- 外注先を選ぶ際は技術スタック適合・言語品質・翻訳運用体制の3軸で評価することが大切です。
目次
i18nとl10nの違い — 国際化とローカライズは別工程
多言語対応開発の外注とは、サイトやアプリが複数の言語・地域に対応できるよう、コードの改修・翻訳・レイアウト調整・文化的適合をまとめて外部パートナーに委託する開発形態です。i18n(国際化)とl10n(ローカライズ)の2工程に分かれており、それぞれ役割が異なります。
i18n(internationalization)とは、ソフトウェアの設計・コードを「多言語対応可能な状態」に整備する工程を指します。具体的には、画面に表示される文字列をソースコードから切り離して外部ファイルに集約したり、日付・通貨・数値の形式を地域ごとに切り替えられるようにしたりする作業です。
l10n(localization)は、i18nで整備された枠組みに対して、特定の言語・地域向けの翻訳や文化的適合を流し込む工程です。翻訳文言の作成・レビューだけでなく、ボタンラベルの長さに合わせたUIレイアウト調整、アラビア語やヘブライ語のような右横書き(RTL:Right-To-Left)への対応なども含まれます。
この2工程はそれぞれ必要なスキルが異なります。i18nはエンジニアリングの知識、l10nは翻訳・言語・文化の専門知識が中心となります。外注範囲を切り分ける際には、まずどちらの工程が不足しているかを整理することが出発点になります。
外注すべき対応範囲 — 文言抽出・翻訳・レイアウト・RTL対応
多言語対応開発を外注する際に委託できる範囲は、大きく6つに分類できます。自社のリソースと照らし合わせながら、どの工程をパートナーに任せるかを判断することが大切です。
| 対応範囲 | 内容 | 主な担当スキル |
|---|---|---|
| 文言抽出・外部化 | ソースコード内に埋め込まれた文字列をJSON・POなどのリソースファイルに移管する。 翻訳ワークフローの前提工程。 |
エンジニア |
| 翻訳・用語統一 | UI文言・ヘルプドキュメント・エラーメッセージを対象言語に翻訳する。 ブランド用語集(グロッサリー)と整合させることが重要。 |
翻訳者・言語専門家 |
| レイアウト調整 | 翻訳後に文字列の長さが変わることで崩れるUIを修正する。 ドイツ語・フランス語は英語より20〜30%長くなる傾向があります。 |
フロントエンドエンジニア |
| 日付・通貨・単位 | 地域ごとに異なる日付形式(MM/DD/YYYYとDD/MM/YYYYの違い等)や通貨記号を自動切替する仕組みを実装する。 | エンジニア |
| RTL対応 | アラビア語・ヘブライ語・ペルシア語など右横書きUIへの対応。 CSS・レイアウト・アイコン方向などの全面見直しが必要になります。 |
フロントエンドエンジニア・言語専門家 |
| 翻訳運用・更新管理 | 機能追加のたびに発生する新規文言の翻訳依頼・差分管理・品質レビューを継続的に回す体制の構築。 | PMO・翻訳コーディネーター |
これらすべてを一括で外注するケースもあれば、文言抽出のみ自社エンジニアが行い、翻訳からレイアウト調整を外注するケースもあります。対応言語数が増えるほど、工程の切り分けが費用管理の精度に直結します。
内製で行う場合には、i18nライブラリの選定・リソースファイルの設計・CI/CDへの翻訳ワークフロー組み込みなど、複数の専門領域の知識が必要です。翻訳運用まで含めると、言語ごとにネイティブレビュアーを継続確保する必要があり、体制構築のコストが発生します。
機械翻訳と人手翻訳の使い分け — 品質と費用のトレードオフ
多言語対応で費用に最も直結するのが、機械翻訳(MT:Machine Translation)と人手翻訳をどう組み合わせるかです。近年は機械翻訳エンジンの精度が向上しており、すべての文言を人手翻訳する必要はなくなっています。ただし、用途によって求められる品質水準が異なるため、使い分けの判断が重要です。
| 翻訳方式 | 適した用途 | 留意点 |
|---|---|---|
| 機械翻訳(MT)のみ | 社内向けドキュメント・ログメッセージ・大量の更新頻度が高いコンテンツ | 文脈を誤認することがあり、ブランド表現や法的文書には不向きです。 |
| MT+ポストエディット(MTPE) | 製品UIの主要文言・ヘルプコンテンツ・ECサイトの商品説明 | 人手翻訳に比べて費用を抑えつつ品質を確保できます。 ポストエディターのスキルと工数の見積もりが大切です。 |
| 人手翻訳(ネイティブ翻訳者) | マーケティングコピー・法律文書・医療/金融系コンテンツ・ブランドメッセージ | 費用・納期ともに高めになります。 用語集(グロッサリー)をあらかじめ整備することで品質のばらつきを防げます。 |
実務上は「UIのコアラベルは人手翻訳、エラーメッセージはMTPE、ログは機械翻訳のみ」のように文言をカテゴリ分けして方式を決めるアプローチが費用対効果の面で合理的です。
品質管理の観点では、翻訳メモリ(TM:Translation Memory)を活用すると過去の翻訳資産を再利用できます。同一または類似の文言が再登場した際に自動で流用されるため、翻訳費用の累積削減に貢献します。
翻訳管理ツール(TMS)の役割と費用への影響
多言語対応を継続的に運用するには、TMS(Translation Management System:翻訳管理システム)の導入を検討することが大切です。TMSは翻訳依頼・進捗管理・翻訳メモリ・用語集・機械翻訳APIの統合を一元管理するクラウドツールです。
代表的なTMSとして、Phrase(旧Memsource)、Lokalise、Crowdin、smartlingなどがあります。これらはいずれも開発者向けAPIやGitHub/GitLab連携を提供しており、CI/CDパイプラインへの組み込みも可能です。料金は製品・プランにより幅があるため、各社公式サイトで最新料金を確認することをお勧めします。
TMSを導入することで、翻訳対象ファイルの差分抽出・担当者への自動配信・承認フローがシステム化されます。リリースのたびに手動で翻訳ファイルを管理していた場合に比べ、担当者の作業負担を大幅に軽減できます。
外注先がTMSを提供しているかどうかは選定時の重要な評価軸の1つです。翻訳メモリを自社資産として保持できる契約形態か、外注先変更時に翻訳資産を引き継げるかを事前に確認することが大切です。
多言語対応開発の費用の考え方 — 規模・言語数・品質要件で変わる
多言語対応開発の外注費用は、対応言語数・対象コンテンツ量・品質要件・TMSの利用有無・翻訳方式によって大きく変わります。以下は市場で見られる費用構成のパターンを整理したものです(市場参考値・一次資料ではありません)。
| 費用項目 | 内容 | 費用水準の目安(参考値) |
|---|---|---|
| i18n対応(コード改修) | 文字列外部化・日付通貨形式実装・RTL対応を含む設計・実装工数 | 既存システムの規模・技術スタックにより大きく異なります。 見積もりは案件規模に応じた個別算出が必要です。 |
| 翻訳費用(人手翻訳) | UI文言・ドキュメントの翻訳・ネイティブレビュー | 言語・専門分野・品質ランクにより異なります。 翻訳会社やフリーランス翻訳者への問い合わせで実費を確認することをお勧めします。 |
| 翻訳管理ツール(TMS) | Phrase・Lokalise・Crowdinなどのライセンス費用 | 製品・プランにより幅があります。各社公式サイトの料金ページで最新情報を確認してください。 |
| 翻訳運用(継続) | 機能追加のたびに発生する差分翻訳・品質レビューの継続コスト | 初期費用よりも継続コストが総額を左右することがあります。 翻訳メモリ活用で再利用率を高めることが重要です。 |
費用を見積もる際には「一言語あたりのコスト」だけでなく、「言語数が増えたときのスケール可否」を確認することが大切です。i18n対応さえ適切に行えば、追加言語のl10nコストは段階的に抑えられます。
一方で、i18n対応が不十分なまま多言語展開を始めると、言語を追加するたびにコード改修が発生してコストが累積します。初期設計の段階でi18nの基盤を整えることが、長期的な費用管理につながります。
外注先の選び方 — 技術・言語品質・翻訳運用の3軸で評価
多言語対応開発の外注先を選ぶ際には、技術スタック適合・言語品質・翻訳運用体制の3軸で評価することが実務上の基本です。
軸1:技術スタック適合 — i18nライブラリと開発環境の整合
React・Vue・Flutter・Swiftなど、自社の技術スタックに対応した多言語化ライブラリへの知見を外注先が持っているかを確認します。WebはReact Intl・i18next・Vue I18nなどが代表的ですが、モバイルやWebの違いによって利用ライブラリが異なります。
既存システムへの改修が伴う案件では、現在のコードベースを読解できるかどうかが進捗に直結します。開発言語・フレームワーク・CI/CDツールの環境を事前に共有し、対応可否を確認することをお勧めします。
軸2:言語品質 — ネイティブレビュアーと品質基準の有無
翻訳品質はブランドイメージと直結します。外注先がネイティブ翻訳者によるレビュー工程を持っているか、業界用語に対応したグロッサリーを整備しているかを確認することが大切です。
翻訳の品質基準として、ASTM F2575やISO 17100(翻訳サービス要求事項)を参照基準として採用している会社は、プロセス管理が整備されている可能性が高いです。ただし認証の有無よりも、実際のサンプル翻訳を依頼してレビューする方が実態を把握しやすいです。
軸3:翻訳運用体制 — 更新頻度に合わせた継続対応力
初期リリースだけでなく、継続的な機能追加・コンテンツ更新に対応できる体制があるかを確認します。差分翻訳の依頼フロー・納期・TMSへのアクセス権・翻訳メモリの所有権などは契約前に明確にしておく必要があります。
翻訳メモリが外注先のシステム内に閉じていると、パートナー変更時にコストが発生します。翻訳資産(TMXファイル・グロッサリー)を自社で保持できる契約条件を確認することを強くお勧めします。
進め方の手順 — 要件整理から翻訳運用体制まで5ステップ
多言語対応開発を外注で進める際の典型的な手順を5ステップに整理します。
-
ステップ1:対応言語と優先市場の定義
どの言語・地域を対象とするか、どの順序で展開するかを決めます。日英のみか、追加言語を見越した設計にするかで、i18n基盤の作り方が変わります。 -
ステップ2:i18n基盤の設計・コード棚卸し
現在のコードに埋め込まれた文字列を洗い出し、i18nライブラリの選定と外部化設計を行います。この工程をスキップすると後工程のコストが増大します。 -
ステップ3:TMS導入と翻訳ワークフロー設計
翻訳依頼・レビュー・承認のフローをTMSで設計し、CI/CDパイプラインとの連携を構築します。外注先と翻訳資産の管理方針を合意します。 -
ステップ4:初回翻訳・QA・レイアウト検証
UI文言を対象言語に翻訳し、ネイティブレビューを経てQAを行います。翻訳後の文字列長変化によるレイアウト崩れを端末実機・ブラウザで検証します。 -
ステップ5:継続翻訳運用体制の確立
機能追加のたびに発生する差分翻訳を自動化・定期化し、翻訳品質の維持とコスト管理のPDCAを回します。
ステップ2のi18n基盤整備を後回しにした場合、翻訳を追加するたびにコード改修が必要になるリスクがあります。特に、既存のモノリシックなシステムに多言語対応を後付けする場合は、工数が当初想定より膨らみやすい点に注意が必要です。
外注先の選定はステップ3(TMS導入)の前後に行うことが一般的です。TMS選定と外注先の選定を並行して進め、連携可否を確認することをお勧めします。
まとめ:多言語対応外注を成功させる3つの判断軸
本稿では、多言語対応開発を外注する際のi18nとl10nの違い・対応範囲・翻訳方式・費用の考え方・外注先選定・進め方の5ステップを整理しました。要点を3つに集約すると次の通りです。
第一に、i18n(国際化)とl10n(ローカライズ)は別工程であり、外注範囲を明確に切り分けることが費用管理の精度を高めます。i18n基盤を後回しにすると言語追加のたびにコード改修コストが積み上がります。
第二に、機械翻訳・MTPE・人手翻訳を用途別に使い分け、TMSで翻訳資産を蓄積することが長期的なコスト削減につながります。翻訳メモリの所有権を契約で確保しておくことも大切です。
第三に、外注先は技術スタック適合・言語品質・翻訳運用体制の3軸で評価し、継続的な更新対応力があるパートナーを選ぶことが運用フェーズの安定につながります。
よくある質問
多言語対応開発はどのくらいの期間がかかりますか。
対象範囲・言語数・既存コードの状態によって異なります。i18n基盤が未整備の既存システムへの改修から始める場合は、設計・実装・翻訳・QAを合わせると数か月以上のリードタイムを見込むことが一般的です。新規開発で最初からi18nを設計に組み込む場合は、言語数に応じた翻訳工程が主な作業期間となります。外注先との要件整合と翻訳ワークフローの設計を早期に始めることが納期短縮につながります。
RTL(右横書き)対応はどのような追加工数がかかりますか。
RTL対応はアラビア語・ヘブライ語・ペルシア語(ファルシー語)など一部の言語で必要になります。HTMLのdir属性とCSSのlogical propertiesを活用することで対応できますが、既存のUIコンポーネントが左横書きを前提に設計されている場合は、アイコン方向・フォームレイアウト・アニメーション方向などを全面的に見直す必要があります。追加工数はコンポーネント数と設計の柔軟性に依存するため、対応言語にアラビア語・ヘブライ語が含まれる場合は早期に技術検証することをお勧めします。
機械翻訳だけで公開しても問題ありませんか。
用途によります。社内向けの参考情報や大量ログの自動翻訳には機械翻訳のみでも実用的です。一方、顧客向けのUI文言・マーケティングコピー・法的文書・医療/金融コンテンツでは機械翻訳のみでの公開にリスクが伴います。ブランドイメージへの影響や誤訳による法的問題を防ぐために、少なくともネイティブ翻訳者によるポストエディット(MTPE)を組み合わせることをお勧めします。
翻訳メモリ(TM)と用語集(グロッサリー)はなぜ重要ですか。
翻訳メモリは過去に翻訳された文言を再利用できる仕組みで、同一または類似の文言が再登場した際に自動で流用されます。これにより翻訳費用の累積削減と品質の一貫性維持に貢献します。用語集(グロッサリー)は製品名・ブランド用語・専門用語の表記ルールを定めたもので、複数の翻訳者が関わる場合でも表記のばらつきを防げます。外注先との契約で、これらの資産を自社が保有できる条件を確認しておくことが大切です。
多言語対応の外注先として翻訳会社とIT開発会社のどちらを選ぶべきですか。
対応範囲によって使い分けることをお勧めします。i18n基盤の設計・コード改修・TMS連携が中心であればIT開発会社、翻訳品質・言語対応の幅・翻訳運用体制が中心であれば翻訳会社が強みを持ちます。実務上は、エンジニアリングと翻訳の両方を一貫して担当できるパートナーを選ぶか、IT開発会社と翻訳会社を連携させる体制を構築するケースも見られます。外注先を選ぶ際は、技術・言語・運用の3軸で自社の課題に合った体制かを確認することが大切です。
著者:テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。