多言語対応システムの外注設計｜i18n実装を任せる発注時のチェックポイント

グローバル展開を目的とした多言語対応システムの外注は、通常の国内システム開発とは異なる発注設計が求められます。翻訳のコストだけを見積もれば済む案件ではなく、システムの内部構造そのものに「言語や地域を後から追加できる仕組み」を最初から組み込む必要があるためです。この構造を発注時に見落とすと、あとから設計をやり直すことになり、想定の数倍の追加費用と時間が発生します。

とくに難しいのは、発注担当者の多くが「i18n（国際化）」という言葉を初めて扱う場面でこのプロジェクトを任される点です。上長から海外展開の指示を受け、社内には相談できる技術者がおらず、開発会社の営業担当が話す用語もまだ距離があります。翻訳会社と開発会社のどちらに何を頼めばよいかも判然としないまま、発注書のドラフトを求められることも珍しくありません。

多言語対応システムの外注が難しいのは、要件が「翻訳」「表示」「データ構造」「SEO」「運用フロー」など複数のレイヤーにまたがるためです。ひとつのレイヤーだけを見て発注書を書くと、他レイヤーの要件が抜け落ち、公開後に「日本語では動くが英語では文字化けする」「新しい言語を追加するたびに数百万円かかる」といった問題が続発します。

しかし、発注時に押さえるべき要件はある程度パターン化できます。i18n基盤・地域固有要件・翻訳ワークフロー・グローバルSEO・保守運用体制の5領域に整理し、それぞれをRFP（提案依頼書）のチェックリストに落とし込めば、開発会社への発注書は書き始められる状態になります。

本記事では、多言語対応システムを外注する発注担当者が「発注書を書き始められる状態」に到達するための発注設計を体系的に解説します。RFPに含めるべきi18n要件のチェックリスト、開発会社の選定基準、費用構造の考え方、契約後のトラブル予防策まで、発注前・発注時・発注後の時系列で整理していきます。

多言語対応システムを外注する前に押さえる3つの前提

多言語対応システムの外注では、発注書の中身に入る前に押さえておきたい3つの前提があります。「i18nとL10nの違い」「翻訳会社と開発会社の役割分担」「拡張性は初期設計で決まる」という3点です。これらを押さえずに個別の要件を並べても、発注書全体としての一貫性が生まれず、後段の交渉や設計判断で軸がぶれる原因になります。

i18n（国際化）とL10n（地域化）の違い｜発注時に意味する範囲

i18n（Internationalization、国際化）とL10n（Localization、地域化）は、実務ではしばしば混同されますが、発注時には明確に分けて扱う必要があります。

i18nは「システムが多言語・多地域に対応できるようにする基盤設計」を指します。文字列を外部化して差し替え可能にする、日付や通貨のフォーマットを地域ごとに切り替えられる構造にする、といったアーキテクチャレベルの話です。開発会社が主に担当する領域と考えて構いません。

一方L10nは「特定の言語や地域に合わせた翻訳・文化的調整」を指します。英語版のコンテンツを作る、フランス語のUIを翻訳する、地域ごとの慣習に合わせた表記に調整する、といった作業です。翻訳会社や現地スタッフ、社内マーケティングが主に担当します。

発注書では「i18n基盤の実装は開発会社の責務、L10n作業は翻訳会社と社内の連携で回す」といった役割の境界を明示することが重要です。境界を曖昧にしたまま発注すると、翻訳データの管理や更新フローが誰の責任か不明確になり、公開後の運用で滞ります。この整理は業界の技術ガイドでも標準的に共有されており、たとえば SimpleLocalize の技術ガイド では、i18nを「新しいロケールを追加するたびにコード構造を変更しなくてよいように設計するプロセス」と定義しています。

翻訳会社と開発会社の役割分担｜二重発注を避ける切り分け

多言語対応の外注で最も混乱しやすいのが、翻訳会社と開発会社のどちらに何を発注するかという分業設計です。ここが曖昧なまま発注すると、両社に同じ作業を発注してしまう「二重発注」や、逆に「どちらも自分の担当と思っていなかった」という抜け漏れが発生します。

実務では以下のように整理するのが基本形です。

• 開発会社の担当: i18n基盤設計、翻訳キー管理の仕組み、翻訳データを読み込む処理、UIの動的レイアウト対応、RTL（右から左）表示対応、地域ごとの日付・通貨・住所フォーマットの実装、hreflangなどSEO要件の実装
• 翻訳会社の担当: 翻訳文の作成、レビュー、用語集の整備、スタイルガイド策定、翻訳メモリの管理、機械翻訳＋ポストエディットの提供
• 発注側（社内）の担当: 対象言語・地域の決定、翻訳品質の受入基準策定、翻訳フローの意思決定、両社の橋渡し

翻訳データを開発会社と翻訳会社の間でどう受け渡すかの合意（ファイル形式・更新頻度・レビュー体制）は、発注書段階で明文化しておくと後の運用がスムーズになります。ここは「TMS（翻訳管理システム）」の導入要否とも関わるため、後述するRFPチェックリストの中で改めて扱います。

「後から言語を増やせる」は初期設計で決まる｜拡張性を担保する発想

多言語対応システムで最も後戻りが難しいのは、初期リリース後に新しい言語や地域を追加するときの拡張性です。「まずは英語だけ、あとから中国語・韓国語を追加していく」といったフェーズドローンチを想定する場合、初期設計で拡張性を担保しておかないと、言語追加のたびにシステム改修が必要になります。

拡張性を担保するために、初期設計で押さえておきたい観点は以下の3点です。

• 言語コードと地域コードの分離: 「en」だけでなく「en-US」「en-GB」「en-AU」のように、同じ英語でも地域ごとに表記や単位が異なる要件を扱えるようにする
• 翻訳キーの命名規則: あとから見て何のUIか分かる命名にし、機能追加時に既存キーとの衝突を避ける
• フォールバック設計: 特定言語の翻訳が未完成の場合に、どの言語にフォールバックするかを明確にする

これらは発注書で「拡張性要件」として明示すべき項目です。「後から言語を追加できるようにしてください」という抽象的な指示では、開発会社ごとに解釈が分かれ、結果として拡張時のコストが読めなくなります。

発注時に見落としがちなi18n実装の落とし穴

発注書の要件を整理する前に、多言語対応システムでよく見落とされる実装レベルの落とし穴を把握しておくと、要件文言の解像度が上がります。ここで挙げる5つの落とし穴は、いずれも発注時に見落とすと、公開後に大きな後戻りコストを生むものです。

文字列のハードコード放置｜言語ファイル外部化の徹底

最も基本的でありながら見落とされやすいのが、UI上に表示される文字列がコード内にハードコード（直接書き込み）されているケースです。「ログインしてください」「エラーが発生しました」などの表示文言がソースコード内に直接書かれていると、翻訳者はコードを触れず、開発会社が毎回コードを修正する必要が生じます。

発注書では「すべての表示文字列は言語ファイル（リソースファイル）に外部化し、コード内にハードコードしないこと」を明示する必要があります。既存の日本向けシステムを多言語化するリプレイス案件では、まず既存コード内のハードコード文字列を洗い出し、外部化する工数を見積もる作業から始まります。

自動スキャンツールで検出できるケースも多いものの、業務ロジック内に埋め込まれた条件分岐（「日本のときだけこの処理」のような分岐）は手動レビューでしか見つかりません。発注時にはこの棚卸し工数を含めた見積もりを依頼することが重要です。

RTL（右から左）・複数形・日付・通貨フォーマットの見落とし

多言語対応で意外に見落とされるのが、言語ごとの文法的・表記上の違いです。

• RTL（Right-To-Left）: アラビア語・ヘブライ語などは右から左に読むため、UI全体のレイアウトを反転させる必要があります。単純にCSSでdirectionを切り替えるだけでは足りず、アイコンの向き、フォーム部品の配置、進行方向を表す矢印など、細かい要素までRTL対応が求められます
• 複数形処理: 英語は1と2以上で単複が変わりますが、ロシア語は数の範囲によって4種類の変化があります。単純な「1件」「複数件」の切り替えでは対応できないケースがあります
• 日付フォーマット: 「2026/07/21」（日本）、「07/21/2026」（米国）、「21/07/2026」（英国）と地域ごとに順序が異なります
• 通貨フォーマット: 桁区切りの記号（カンマかピリオドか）、通貨記号の位置（数字の前か後か）、小数点の扱いが地域ごとに異なります

これらは対応言語を追加した後で問題が発覚することが多く、発注書段階で「対象地域ごとに要件を明示する」ことで手戻りを防げます。

タイムゾーン・住所形式・電話番号など地域固有要件の未定義

システムの内部データとして日時や住所を扱う場合、地域固有の要件を最初から設計に組み込む必要があります。

• タイムゾーン: サーバー内部の日時はUTCで保持し、表示時にユーザーのタイムゾーンに変換する構造が基本です。日本国内向けシステムをそのまま海外展開すると、日本時間で保存された日時が海外ユーザーには不自然に表示されます
• 住所形式: 日本の「都道府県→市区町村→番地」の順序は世界標準ではありません。米国は「番地→市→州→郵便番号」、英国は「番地→市→郵便番号」と順序も項目も異なります。住所を単一のフィールドで扱うのか、地域別のテンプレートで扱うのかの判断が発注時に必要です
• 電話番号: 国番号の扱い、桁数、区切り記号がすべて地域ごとに異なります。国際電話形式（E.164）を採用するか、国内表記を残すかの方針が要件に必要です

これらは「機能仕様」ではなく「データモデル」に関わる要件のため、途中から変更するとデータベースのスキーマ変更が必要になり、大きな改修になります。発注書段階で明示することが重要です。

hreflang・URL構造・SEO要件の欠落

多言語対応システムがWebサービスやコーポレートサイトの性格を持つ場合、グローバルSEO要件を発注書に含める必要があります。ここが欠落すると、多言語コンテンツを公開してもGoogleが正しく認識せず、検索流入が想定通りに得られません。

hreflangは、同じコンテンツの異なる言語・地域版をGoogleに伝えるためのHTML属性です。実装場所はheadタグ内のlinkタグ、HTTPヘッダー、XMLサイトマップの3通りがあり、サイト規模が大きいほどサイトマップ方式が推奨されます（アウンコンサルティングの解説）。

hreflangの実装は「相互リンク」が必須で、ページAがページBを参照していても、ページBがページAを参照していないとGoogleはシグナルを無視します。この双方向参照を全ページで正しく維持する仕組みが必要で、CMSの構造やページ生成ロジックとの整合が問われます。

URL構造も選択肢が複数あります。サブドメイン方式（en.example.com）、サブディレクトリ方式（example.com/en/）、国別ドメイン方式（example.co.uk）のそれぞれにSEO上のメリット・デメリットがあり、事業戦略と技術要件の両面から選択する必要があります。発注書段階でどの方式を採用するかの方針を示し、開発会社に実装可否を確認しておくことが重要です。

翻訳更新フローの未整備｜属人化と反映遅延

多言語対応システムを本番運用に載せた後、最も現場を疲弊させるのが「翻訳の更新フローが整備されていない」問題です。日本語のUI文言を変更するたびに、他言語版の翻訳を誰がいつ更新するのか、更新した翻訳をどうシステムに反映するのかが決まっていないと、更新のたびに開発会社への都度発注が発生し、反映遅延が積み重なります。

翻訳更新フローは以下の要素で構成されます。

• 翻訳依頼のトリガー: どのイベント（新機能リリース・文言修正・キャンペーン）で翻訳依頼が発生するか
• 翻訳の担当者: 翻訳会社・社内スタッフ・機械翻訳の使い分け
• 反映の手順: 翻訳データをシステムに反映する具体的な手順と権限
• 品質確認: 反映後の見た目・意味の確認をいつ誰が行うか

このフローが属人化していると、担当者の異動時に運用が止まります。発注書段階で「翻訳更新フローの構築」を成果物として含めるか、少なくとも運用フェーズの体制提案を含めることを求めるべきです。

RFPに含めるべきi18n要件チェックリスト｜多言語対応システムの外注書設計

ここからが本記事の中核です。発注書（RFP・要件定義書）に含めるべきi18n要件を、そのまま転記可能なチェックリスト形式で整理します。各項目には「なぜ必要か」と「発注書での指定例」を添えて、発注担当者がドラフトに落とし込みやすい粒度で提示します。

対象言語・地域スコープの定義｜初期リリースと拡張予定の切り分け

まず発注書の冒頭で明確にすべきは、対象言語・地域のスコープです。初期リリースで対応する言語と、将来的に追加予定の言語を切り分けて示すことで、開発会社は拡張性の設計方針を判断できます。

• 初期リリース対象: 具体的な言語コードと地域コードのリスト（例: ja-JP, en-US, zh-CN）
• 拡張予定: 3年以内に追加を検討している言語・地域と、想定されるユーザー数の目安
• 除外条件: 対象外の言語や、対応しない地域固有要件（例: 中東向けRTL対応は今回スコープ外）

発注書での指定例:

本システムは初期リリース時点で日本語（ja-JP）、英語（en-US、en-GB）、簡体字中国語（zh-CN）の4言語に対応する。3年以内にフランス語（fr-FR）、スペイン語（es-ES）、韓国語（ko-KR）の追加を予定しており、新規言語追加時の開発工数を最小化する設計とすること。

文字列外部化・翻訳キー管理方針｜i18nライブラリ・フォーマットの指定

次に、翻訳文字列の管理方式を発注書で示します。この項目を曖昧にすると、開発会社ごとに独自のライブラリや命名規則が採用され、後から翻訳会社と連携する際に整合性が取れなくなります。

• i18nライブラリの指定または方針: 特定のライブラリを指定する場合はその名称、指定しない場合は「業界標準のi18nライブラリを採用すること」と方針を示す
• 翻訳ファイルのフォーマット: JSON、YAML、gettext（PO/POT）、XLIFF などから選択。翻訳会社の対応可否を確認済みのフォーマットを指定する
• 翻訳キーの命名規則: 機能単位・画面単位・種類（ボタン・メッセージ・エラー）などの階層構造を指定する

発注書での指定例:

UIおよびシステムメッセージのすべての表示文字列は、コード内にハードコードせず、翻訳ファイル（JSON形式）に外部化すること。翻訳キーの命名規則は「画面名.要素種類.用途」の3階層とし、命名規則書を成果物に含めること。

タイムゾーン・多通貨・住所形式・電話番号のデータモデル要件

データモデルに関わる要件は、あとから変更するとデータベーススキーマの変更を伴うため、発注書段階で明確にしておきます。

• 日時の内部保持: UTCで保持し、表示時にユーザーのタイムゾーンに変換する構造とすること
• 通貨: 金額データは通貨コード（ISO 4217）とセットで保持し、表示時に地域ごとのフォーマットに変換すること
• 住所: 住所は地域別テンプレートで扱い、単一の自由記述フィールドに詰め込まないこと
• 電話番号: 国際電話形式（E.164）を内部形式とし、表示時に国内表記に変換すること

これらの要件は、開発会社の提案書で「どのようなデータモデル設計を採用するか」の説明を求める根拠になります。

翻訳ワークフロー要件｜翻訳会社との連携設計とTMS導入の要否

翻訳ワークフローに関する要件は、開発会社と翻訳会社の連携設計に直結します。ここを発注書で明示することで、両社の作業境界と受け渡しフォーマットが定まります。

• 翻訳データの受け渡し形式: どのフォーマットで翻訳データを開発会社に納品するか
• TMS（翻訳管理システム）の導入要否: 翻訳メモリ・用語集を管理するTMSを導入するか、独自の仕組みを構築するか
• 翻訳の反映フロー: 翻訳データを受領してから本番反映までのステップ数と所要時間

TMSは翻訳メモリ・用語集の一元管理、翻訳会社との連携、CI/CDパイプラインへの組み込みなどを担うシステムです。導入する場合は開発会社の実装コストが上乗せされるため、翻訳量の見込みとのバランスで判断します。

継続的な言語追加・翻訳更新体制の要件

初期リリース後の継続運用に関わる要件を、発注書段階で明示します。ここが曖昧だと、契約終了後に運用フェーズで「言語追加に想定外の費用がかかる」問題が発生します。

• 新規言語追加の手順書: 新しい言語を追加する際の作業手順を文書化した成果物を求める
• 翻訳更新の頻度と反映SLA: 翻訳の更新頻度と、更新から本番反映までのSLA
• 保守フェーズの費用構造: 言語追加・翻訳更新に関する保守フェーズの費用を、初期見積もりに含めるか別途契約とするかの方針

グローバルSEO要件（hreflang・URL構造・sitemap）

SEO要件は、システムがWebサービスやコーポレートサイトの性格を持つ場合に必須です。

• URL構造の方針: サブドメイン方式・サブディレクトリ方式・国別ドメイン方式のいずれを採用するか
• hreflangの実装方式: linkタグ・HTTPヘッダー・XMLサイトマップのいずれで実装するか、および相互参照の維持方法
• 多言語sitemap: 言語ごとにsitemapを生成するか、統合sitemapで管理するか

発注書での指定例:

多言語コンテンツのグローバルSEO対応として、hreflangタグをXMLサイトマップ方式で実装すること。すべての言語版ページで相互参照を維持し、参照漏れが発生しない仕組みを組み込むこと。URL構造はサブディレクトリ方式（/en/, /zh-cn/ 等）とする。

品質保証要件（RTL検証・多言語UIテスト・パフォーマンス）

多言語対応システムのテスト要件は、通常のシステムテストに加えて言語・地域固有の観点が加わります。

• RTL検証: RTL対応言語がある場合、UI全体のレイアウト反転が正しく動作するかの検証項目
• 多言語UIテスト: 各言語で長文が表示された場合のレイアウト崩れ、フォント表示の確認
• パフォーマンス: 言語切り替え時のロード時間、翻訳ファイルのサイズによる初期表示への影響

これらは受入テストの合格基準として発注書に含めることで、公開後の「英語版だけレイアウトが崩れている」といった問題を回避できます。

多言語対応システム開発会社の選び方｜i18n実装を任せられるパートナーの見極め方

RFPを整えたら、次は発注先の選定です。多言語対応システムの開発は、通常のシステム開発に比べて実績のある会社が限られます。以下の観点で発注候補を評価することで、i18n実装を任せられるパートナーを見極められます。

多言語対応システムの実績確認｜聞くべき質問例

会社紹介資料や営業トークだけでは、実際にi18n基盤を設計・実装した経験があるかを判別しにくいのが実情です。以下のような具体的な質問を提案依頼時に投げることで、実績の解像度を上げられます。

• 過去の対応言語数と地域: 直近3年間で対応した多言語プロジェクトの言語数、地域、業種の内訳
• RTL対応の実績: アラビア語・ヘブライ語などRTL対応の実装経験、その際の設計判断
• 翻訳会社との協業経験: どの翻訳会社と協業したか、どのようなワークフローで運用したか
• 拡張時の対応事例: 初期リリース後に言語追加が発生した際の対応事例と工数実績

これらの質問への回答の具体性から、実装経験の有無を判断できます。「対応可能です」という抽象的な回答しか返ってこない場合は、実際の設計判断を経験していない可能性が高いと考えられます。

i18nライブラリ・フレームワーク選定の考え方

開発会社が採用するi18nライブラリやフレームワークによって、拡張性や保守性が大きく変わります。提案書ではライブラリの選定理由を説明してもらい、以下の観点で評価します。

• メンテナンス状況: 選定したライブラリが継続的にメンテナンスされているか、コミュニティが活発か
• 翻訳ファイルフォーマットの互換性: 一般的な翻訳会社が対応可能なフォーマット（XLIFF、gettext 等）に対応しているか
• CI/CDへの組み込みやすさ: 翻訳更新をCI/CDパイプラインに組み込みやすい構造か

特定のライブラリに強い依存関係を作ると、将来的な移行が困難になります。ロックインリスクを含めた選定理由の説明を求めることが重要です。

翻訳会社・TMSベンダーとの協業実績

多言語対応の外注では、開発会社と翻訳会社の協業がプロジェクト成否を左右します。以下の観点で協業実績を評価します。

• 既存の協業関係: 特定の翻訳会社やTMSベンダーとの継続的な協業関係があるか
• ワークフロー構築の経験: 翻訳データの受け渡しフロー・レビュー体制を構築した経験があるか
• 翻訳会社の紹介可否: 発注側が翻訳会社を選定する際、開発会社側から推奨できる会社があるか

翻訳会社の選定は基本的に発注側の責務ですが、開発会社が過去に協業した翻訳会社を紹介してもらえると、両社間のコミュニケーションコストが下がります。

保守運用フェーズの体制提案｜言語追加・翻訳更新のSLA

初期リリース後の運用フェーズに関する提案は、選定時に必ず確認すべき項目です。以下の観点で提案内容を評価します。

• 言語追加のSLA: 新規言語追加時の対応期間・費用の目安
• 翻訳更新の反映SLA: 翻訳更新依頼から本番反映までの期間
• 障害対応の体制: 多言語対応特有の障害（文字化け、レイアウト崩れ）への対応窓口と時間帯

海外ユーザーがいる場合、障害対応の時間帯設定は事業影響に直結します。「日本時間の営業時間内のみ対応」では海外ユーザーの障害を放置することになるため、時間帯設定の交渉余地を発注時に確認しておきます。

グローバル案件経験の見極め方（時差運用・ドキュメント・多国籍チーム）

多言語対応システムの案件では、開発チームの体制そのものにグローバル対応力が求められる場面があります。以下のような観点で評価します。

• 時差運用の経験: 海外拠点や海外のステークホルダーとの時差運用経験
• 英語ドキュメントの提供: 提案書・設計書・運用手順書を英語でも提供可能か
• 多国籍チームでの開発経験: 多国籍メンバーによる開発チーム構成の経験

海外拠点や海外ユーザーとのコミュニケーションが発生する案件では、日本語のみのドキュメントでは運用が回りません。英語ドキュメントの提供可否は、契約前に確認しておくことが重要です。

費用構造と予算計画｜多言語対応システム外注の相場と拡張時コスト

多言語対応システムの費用は「初期構築費用」「翻訳費用」「運用費用」の3層に分解して考えるのが基本です。それぞれの層で変動要因が異なり、単純に足し合わせるだけでは実際のコストと乖離します。

初期構築費用の内訳｜i18n基盤設計・実装・テスト

初期構築費用は、i18n基盤の設計・実装・テストにかかる費用です。以下の要素で構成されます。

• i18n基盤設計: アーキテクチャ設計、翻訳キー管理方針、データモデル設計
• 既存コードの外部化: 既存システムを多言語化する場合、ハードコード文字列の外部化工数
• UI/UXの多言語対応: レイアウト調整、フォント選定、RTL対応
• 地域固有機能の実装: タイムゾーン・多通貨・住所・電話番号などの地域固有機能
• SEO要件の実装: hreflang、URL構造、多言語sitemap
• テスト: 各言語での動作確認、レイアウト崩れの検証

新規開発とリプレイス（既存システムの多言語化）で費用構造は大きく変わります。新規開発では初めからi18n基盤を組み込むため相対的に効率的ですが、リプレイスでは既存コードの棚卸しと外部化に工数がかかります。

翻訳費用の変動要因｜言語数・専門性・機械翻訳＋ポストエディットの活用

翻訳費用は、対象言語数・翻訳量・専門性の3要素で決まります。一般に、以下のような要因で変動します。

• 言語ペアの相場差: 日本語⇔英語と、日本語⇔希少言語（アラビア語・ヒンディー語など）では単価が変わります
• 専門性の高さ: 医療・法律・技術など専門用語が多い分野では単価が上がります
• 機械翻訳＋ポストエディット（MTPE）の活用: 機械翻訳の一次出力を人間がレビュー・修正する方式で、純粋な人手翻訳より低コストで運用できるケースが増えています

翻訳費用は初期のコンテンツ翻訳だけで完結せず、継続的な更新・追加が発生します。年間の翻訳ボリューム見込みを立て、単価×ボリュームで年間コストを見積もることが重要です。

運用費用（保守・言語追加・翻訳更新）の見積り方

運用費用は、保守・言語追加・翻訳更新の3要素で構成されます。

• 保守: 通常のシステム保守に加え、多言語対応特有の障害対応（文字化け・レイアウト崩れ）が発生します
• 言語追加: 新規言語を追加する際の実装・テスト工数
• 翻訳更新: 既存言語の翻訳を更新する際の実装反映工数

運用費用は月額固定契約と都度発注契約の使い分けが可能です。翻訳更新の頻度が高い場合は月額固定でSLAを担保し、頻度が低い場合は都度発注で柔軟性を持たせるのが実務的な選択です。

拡張時コストを抑える発注設計｜契約時に握るべきポイント

将来の言語追加や機能拡張時のコストを抑えるためには、初期契約時にいくつかの条項を握っておくと有効です。

• 拡張性要件の明文化: 「新規言語追加時の追加工数は既存ライブラリの範囲内で吸収できる設計とすること」といった要件を初期契約に含める
• 単価表の合意: 言語追加・翻訳更新の単価を初期契約時に合意し、都度見積もり交渉を減らす
• 成果物としてのドキュメント整備: 言語追加手順書・保守手順書を成果物に含め、他社での運用継続が可能な状態を作る

初期契約時に単価表や拡張手順書を成果物として合意しておくと、将来の言語追加時に「同じ会社に依頼するしかない」ロックインを避けられます。

発注後に起きがちなトラブルと予防策

契約締結後の実務では、いくつか典型的なトラブルが発生します。事前の発注設計で予防できるものが多いため、パターンを把握して発注書に予防策を組み込んでおくことが重要です。

スコープ・要件変更による追加費用｜変更管理プロセスの合意

多言語対応システムの案件では、初期スコープに含めていなかった地域固有要件が途中で発覚することがよくあります。「アラビア語も追加したいが、RTL対応が初期スコープに入っていない」「中国向けにローカルの決済を組み込みたい」といったケースです。

こうしたスコープ変更を無秩序に受け入れると、追加費用が膨らみます。予防策として、契約時に「変更管理プロセス」を合意しておくことが有効です。変更依頼のフォーマット、影響評価の手順、追加費用の見積もり基準を明文化することで、変更のたびの交渉コストを下げられます。

翻訳品質のブレ｜スタイルガイド・用語集・レビュー体制

翻訳品質は、翻訳者の入れ替わりや翻訳会社の変更によってブレやすい要素です。同じ製品の翻訳なのに、ページごとに文体や用語が異なるといった事象が起きます。

予防策として、以下の3点を発注時に明確にします。

• スタイルガイド: 敬語のレベル、表記統一（英数字の全角/半角、記号の使い方）
• 用語集: 製品固有の用語・ブランド名の訳語を統一
• レビュー体制: 翻訳会社側のレビューと、社内のネイティブスピーカーによる二次レビューの体制

翻訳会社との契約時に「スタイルガイドと用語集の作成と維持」を成果物に含めることで、翻訳者交代時の品質維持が容易になります。

言語追加時の想定外コスト｜初期契約での拡張条項

初期リリース後に新規言語を追加する際、「拡張性は担保する設計にした」と聞いていたのに想定外の追加費用が発生するケースがあります。原因の多くは、初期契約時に「拡張性」の定義が曖昧だったことです。

予防策として、初期契約時に以下を明文化します。

• 言語追加時の工数目安: 単純な言語追加（既存機能の翻訳追加のみ）の工数目安
• 地域固有機能追加時の工数目安: RTL対応・多通貨対応など地域固有機能追加時の工数目安
• 単価の合意: 上記の工数に対する単価または目安金額

この明文化により、言語追加の見積もり交渉時の齟齬を減らせます。

RTL・地域固有要件のテスト漏れ｜受入テスト設計

多言語対応システムで最も見落とされやすいのが、公開後に「特定言語だけレイアウトが崩れている」「特定地域だけ日付表示が誤っている」といったテスト漏れです。開発会社のテスト工程で全言語を網羅していないケースが多くあります。

予防策として、発注書に「受入テストの合格基準」を明示します。

• 全対象言語での動作確認: 初期リリース対象言語すべてで、主要画面の動作確認を実施
• RTL言語でのレイアウト検証: RTL対応言語がある場合、全画面のレイアウト反転を確認
• 地域固有機能の実データ検証: 各地域の実データ（住所・電話番号・郵便番号）でのバリデーション確認

受入テストの合格基準を発注書に明記することで、開発会社側のテスト工程を担保し、公開後の後戻りを防げます。

まとめ｜i18n実装を任せる発注設計の要点

多言語対応システムの外注は、発注時の設計品質がプロジェクト成否を大きく左右します。本記事の要点を発注前・発注時・発注後の時系列で整理すると、以下のようになります。

発注前に押さえる前提

• i18n（基盤設計）とL10n（翻訳・地域化）の違いを理解し、翻訳会社と開発会社の役割分担を明確にする
• 拡張性（後から言語追加できる構造）は初期設計で決まるため、拡張予定を含めて発注時に明示する

発注時に含めるべき要件

• 対象言語・地域スコープの明示（初期リリースと拡張予定の切り分け）
• 文字列外部化・翻訳キー管理方針
• タイムゾーン・多通貨・住所形式・電話番号のデータモデル要件
• 翻訳ワークフローとTMS導入方針
• グローバルSEO要件（hreflang・URL構造・多言語sitemap）
• 品質保証要件（RTL検証・多言語UIテスト）

発注先選定の観点

• 多言語対応システムの過去実績と具体的な質問への回答の解像度
• i18nライブラリ選定の説明力とロックインリスクの回避
• 翻訳会社・TMSベンダーとの協業経験
• 保守運用フェーズの体制とSLA

発注後のトラブル予防

• 変更管理プロセスの事前合意
• スタイルガイド・用語集・レビュー体制の整備
• 言語追加時の工数・単価の初期契約への明文化
• 受入テストの合格基準の明示

多言語対応システムの発注は、要件を細かく整理する作業量が多い分、初期の発注設計に投じた時間が後段のリスクを大きく下げます。本記事で示したチェックリストを起点に、社内で発注書のドラフトを組み立て、複数の開発会社に提案依頼を出して比較検討することで、拡張性と品質を両立するパートナー選定が可能になります。