# Webサービス多言語化の費用相場｜外注の進め方

- 公開日: 2026-10-19
- 監修: 代表取締役 兼 StockSun創業メンバー 板橋 晟星
- URL: https://www.geek-bridge.com/column/web-service-localization-cost

Webサービスの多言語化費用は、既存サービスへ1言語を追加する場合、一般に100万〜300万円、期間は2〜4か月が目安です。画面翻訳だけでなく、日時・通貨・メール・検索・運用まで対象を決め、まず1市場で公開すると予算超過を抑えやすくなります。

## Webサービス多言語化の費用相場と期間

Webサービスの多言語化は、文章を翻訳するだけの作業ではありません。国際化（i18n＝言語や地域を追加しやすくするシステム設計）、翻訳、画面調整、動作確認、公開後の更新体制をまとめて考える必要があります。

さらに海外展開を目的とする場合は、ローカライズ（L10n＝言語だけでなく、対象市場の文化・制度・商習慣に合わせること）も必要です。通貨、日付、住所、電話番号、税、決済手段などへの対応が代表例です。

### 規模別の費用相場

以下は、既存サービスに1言語を追加し、主要な画面や案内文の翻訳・確認を行う場合の一般的な目安です。金額は税別で、専門性の高い大量の翻訳、現地法の調査、新しい決済手段の導入、大規模なデータ移行などは含みません。

| 多言語化する対象 | 費用の目安 | 期間の目安 | 想定される内容 |
|---|---:|---:|---|
| 案内ページ・問い合わせフォーム中心 | 30万〜100万円 | 1〜2か月 | 5〜15ページ程度、1言語、簡単なフォーム調整 |
| 小規模な会員制Webサービス | 100万〜300万円 | 2〜4か月 | 会員登録、ログイン、マイページ、通知メール、管理画面の一部 |
| 中規模のEC・予約・マッチングサービス | 300万〜800万円 | 4〜8か月 | 商品・予約データ、検索、決済、メール、運用機能を含む |
| 大規模・複数国向けサービス | 800万円以上 | 6〜12か月以上 | 複数言語、国別仕様、外部連携、権限、現地向け運用を含む |

同じ画面数でも、表示する文章が固定されているか、利用者や運営者が登録するデータまで翻訳するかで費用は変わります。たとえば、メニュー名だけを英語にする案件と、出品者が登録した商品説明を言語別に管理する案件では、必要な仕組みが異なります。

### 費用を構成する主な項目

| 費用項目 | 一般的な目安 | 発注時の確認事項 |
|---|---:|---|
| 既存システムの調査 | 20万〜60万円 | 文章の管理方法、データ構造、外部連携、改修影響の確認 |
| 国際化設計 | 30万〜100万円 | 言語切り替え、日時・通貨・数値・住所の扱い |
| 画面・サーバー側の改修 | 50万〜250万円以上 | 対象画面、検索、メール、帳票、管理画面を含むか |
| 翻訳・ネイティブレビュー | 20万〜150万円以上 | 文字数、専門性、レビュー回数、用語集の有無 |
| テスト | 20万〜100万円以上 | 言語別表示、端末、ブラウザ、業務フローの確認 |
| 多言語SEO・アクセス計測 | 10万〜50万円 | 言語別URL、検索表示、分析方法の設定 |
| 運用設計・マニュアル | 10万〜50万円 | 翻訳依頼、承認、公開、修正の担当と手順 |

各項目には重複する作業があるため、表の金額を単純に合計するものではありません。特に既存システムの構造が不明な段階では、最初から開発総額を固定するより、調査・設計を先に実施してから本開発を見積もる方が安全です。

公開後も追加費用が発生します。システム保守の増額分は月額3万〜20万円程度、コンテンツ翻訳やレビューは月額5万〜50万円以上が一つの目安です。問い合わせ対応を外国語で行う場合は、カスタマーサポートの人件費や外注費も別途見込んでください。

## 発注前に決める多言語化の対象範囲

費用を抑える基本は、最初からすべてを翻訳するのではなく、対象市場で顧客が利用を完了するために必要な範囲を優先することです。

多言語化には、主に次の3段階があります。

| 対応レベル | 対象 | 向いている目的 | 注意点 |
|---|---|---|---|
| 表示言語の追加 | メニュー、ボタン、固定ページ | 海外利用者への情報提供、需要確認 | 申込みやサポートが日本語のままだと利用につながりにくい |
| 主要業務の多言語化 | 会員登録、検索、申込み、決済、メール | 対象国で実際にサービスを提供する | 管理画面や問い合わせ対応も検討が必要 |
| 市場別ローカライズ | 通貨、税、決済、規約、商習慣、販促 | 対象国で本格展開する | 法務・税務・運用を含むため費用が大きくなる |

### 言語ではなく対象国まで決める

「英語対応」という指定だけでは、開発会社は正確に見積もれません。米国、英国、シンガポールでは、同じ英語でも通貨、税、住所形式、利用規約、一般的な決済手段が異なるからです。

発注前に、少なくとも次の項目を決めます。

- 優先する国・地域と言語
- 法人向けか個人向けか
- 現地で提供する商品・機能
- 表示する通貨と請求通貨
- 現地から利用できる決済手段
- 問い合わせを受ける言語と時間帯
- 対象市場で追う売上・登録数などの指標

### 翻訳する画面とデータを分ける

多言語化の対象は、利用者が見る画面だけではありません。次のように分類すると、見積もり漏れを減らせます。

- 共通UI：メニュー、ボタン、入力項目、エラーメッセージ
- コンテンツ：サービス説明、料金、ヘルプ、よくある質問
- 取引情報：商品、予約枠、注文、請求、キャンセル条件
- 自動通知：会員登録、購入、パスワード再設定、障害通知のメール
- 生成物：領収書、請求書、PDF、CSVなど
- 運営機能：管理画面、審査画面、問い合わせ管理
- 外部連携：決済、地図、配送、本人確認、分析ツール

CMS（＝専門知識がなくてもWeb上の文章や画像を更新できる仕組み）で登録する記事についても、言語別に原稿を持つのか、機械翻訳を使うのかを決めます。利用者が投稿する口コミや商品情報を扱う場合は、原文表示、任意翻訳、自動翻訳のどれにするかも必要です。

### 翻訳方法は重要度で使い分ける

すべてを人が翻訳すると品質は管理しやすい一方、更新のたびに費用と時間がかかります。反対に、すべてを機械翻訳にすると、料金や契約条件などの重要な内容が誤って伝わる可能性があります。

現実的なのは、次のような使い分けです。

| 情報の種類 | 適した翻訳方法 |
|---|---|
| 利用規約、料金、購入・解約画面 | 専門翻訳または人による厳格なレビュー |
| トップページ、機能紹介、広告文 | 翻訳者・現地担当者による表現調整 |
| メニュー、ボタン、エラー文 | 用語集に基づく翻訳と画面上での確認 |
| ヘルプ記事、更新頻度の高い記事 | 機械翻訳と人のレビューの併用 |
| 利用者投稿、口コミ | 必要に応じてオンデマンドの機械翻訳 |

翻訳者へ文章だけを渡すのではなく、どの画面のどの場面で表示されるかも共有します。同じ「登録」という言葉でも、会員登録、商品登録、支払い方法の登録では適切な訳語が異なるためです。

## Webサービス多言語化を外注する手順

外注は、対象市場の決定、既存システムの調査、対象範囲の確定、設計・開発、言語別テスト、段階公開の順に進めます。開発会社へ連絡する前にすべてを確定する必要はありませんが、事業判断とシステム判断を分けて整理しておくことが重要です。

### 1. 対象市場と目的を決める

最初に「なぜ多言語化するのか」を明確にします。海外からの問い合わせに対応したいのか、現地で決済まで完了させたいのかによって、必要な開発範囲は変わります。

目標も、アクセス数だけでなく、登録完了率、問い合わせ数、購入率、継続率など事業成果に近い指標を置きます。需要が不明な段階なら、1言語・1市場・一部機能に絞って検証する方法が適しています。

### 2. 対象となる文章・画面・機能を棚卸しする

画面一覧、メール一覧、帳票一覧、外部サービス一覧を作り、翻訳の要否を記録します。対象外も明記すると、見積もり後の追加費用を抑えられます。

範囲整理の具体的な進め方は、[開発スコープの決め方｜要件定義前の整理手順](https://www.geek-bridge.com/column/development-scope-definition-guide)も参考にしてください。

### 3. 既存システムを調査する

開発会社に、次の点を確認してもらいます。

- 画面の文章を言語ファイルへ切り出せるか
- データベースで言語別の情報を管理できるか
- 日本語を前提とした検索処理になっていないか
- 日時、数値、通貨が日本向けに固定されていないか
- メール、帳票、エラー文がどこで管理されているか
- 外部API（＝他社サービスとデータをやり取りする接続口）が対象国で使えるか
- 文字数が増えたときに画面レイアウトが崩れないか

ソースコードや設計資料が不足している場合、調査に数週間かかることがあります。この費用を省いて概算だけで契約すると、開発開始後に追加改修が判明しやすくなります。

### 4. 要件と運用方法を決める

利用者が登録から購入・解約までどのように進むかを言語別に確認します。国によって本人確認や決済方法が変わる場合は、画面遷移も変わります。整理方法は、[画面遷移図の作り方｜開発依頼前の準備](https://www.geek-bridge.com/column/screen-flow-diagram-guide)で詳しく解説しています。

運用については、次の役割も決めておきます。

- 日本語の原稿を確定する担当者
- 翻訳を依頼する担当者
- 訳文を承認する担当者
- システムへ登録する担当者
- 緊急修正を判断する担当者
- 外国語の問い合わせに回答する担当者

### 5. 設計・開発・翻訳を並行して進める

国際化の仕組みを実装した後、翻訳した文章を組み込みます。翻訳完了を待ってから開発を始める必要はありませんが、用語集と代表的な訳文は早めに用意してください。

文章の長さは言語によって変わります。日本語では収まっていたボタンや見出しが、英語やドイツ語では長くなり、表示が崩れる場合があります。そのため、翻訳は表計算シート上だけで確認せず、実際の画面へ反映して調整します。

### 6. 言語別にテストして段階公開する

通常の動作確認に加え、次の項目を確認します。

- 言語切り替え後も同じページを表示できるか
- 翻訳漏れや日本語の混在がないか
- 文字切れ、改行崩れ、文字化けがないか
- 日付、時刻、数値、通貨が正しく表示されるか
- 検索結果が対象言語で適切に表示されるか
- 登録、購入、解約、返金を完了できるか
- メールや帳票の言語が利用者の設定と一致するか
- 外部サービスが対象国から利用できるか
- 言語別のアクセスや成果を計測できるか

可能であれば、対象言語を母語とする人に一連の操作を依頼します。正しい翻訳でも、その市場で不自然な表現や分かりにくい導線になっていることがあるためです。

## 見積もり比較と開発会社の選び方

多言語化の見積もりは、総額だけでなく「何を翻訳し、どこまでシステムを改修し、誰が品質を確認するか」を比較します。安い見積もりでは、翻訳、管理画面、メール、公開後の更新作業が別料金になっていることがあります。

### 見積書で確認する項目

| 確認項目 | 見るべきポイント |
|---|---|
| 対象言語・地域 | 言語だけでなく対象国が明記されているか |
| 対象画面・機能 | 利用者画面、管理画面、メール、帳票を区別しているか |
| 翻訳範囲 | 文字数、単価、専門分野、レビュー回数が明確か |
| システム改修 | 国際化、データ構造、検索、外部連携を含むか |
| テスト | 端末、ブラウザ、言語、業務シナリオの範囲が明確か |
| 修正対応 | 翻訳修正とプログラム不具合の扱いが明確か |
| 公開作業 | 段階公開、切り戻し、公開後確認を含むか |
| 運用・保守 | 文章更新、言語追加、障害対応の費用が明確か |

翻訳量が確定していない場合は、仮の文字数に基づく概算と、確定後の精算方法を確認します。また、現状調査で追加対応が見つかった場合に、誰が承認して予算を変更するかも決めておきます。

発注予算には、確定した開発費とは別に10〜20％程度の予備費を持たせる方法があります。ただし、予備費を前提に曖昧な契約を結ぶのではなく、変更管理の手順を定めることが先です。

### 開発会社を見極めるチェックリスト

多言語化を依頼する会社は、翻訳会社ではなく、Webサービスの構造と運用を理解できる開発会社を中心に選びます。翻訳会社と開発会社が分かれる場合は、用語、納品形式、修正窓口を調整する担当者が必要です。

- 動的なWebサービスの多言語化経験があるか
- 画面だけでなく、メール・帳票・管理画面まで確認できるか
- 日時、通貨、住所、検索などの地域差を説明できるか
- 翻訳会社や現地レビュー担当者と連携できるか
- 対象範囲と対象外を見積書に明記するか
- 多言語SEOやアクセス計測まで提案できるか
- 言語追加を前提に保守しやすい設計を提案するか
- リリース後の翻訳更新フローを設計できるか
- アカウント、原稿、用語集、ソースコードを発注者へ引き渡すか

発注のご相談を受ける開発会社の立場では、「英語版を追加したい」という相談に対し、対象画面数より先に、対象国、提供機能、決済、問い合わせ対応を確認します。この質問をせずに画面翻訳だけを提案する会社は、事業運用まで見ていない可能性があります。

多言語化の対象範囲や既存システムへの影響が分からない場合は、[開発のご相談はこちら](https://www.geek-bridge.com/#contact)からご相談ください。

### よくある失敗と回避策

| よくある失敗 | 起きる問題 | 回避策 |
|---|---|---|
| 翻訳作業だけを発注する | 日時・通貨・検索・メールが日本仕様のまま残る | 翻訳とシステム改修を分けて棚卸しする |
| 最初から複数言語を同時公開する | 修正箇所が言語数分に増え、検証が遅れる | 事業上の優先度が高い1言語から始める |
| 機械翻訳を無条件で公開する | 料金や契約条件が誤って伝わる | 重要画面は人がレビューする |
| 管理画面を対象外にする | 運営担当者が訳文を更新できない | 更新業務に必要な管理機能を先に決める |
| 問い合わせ対応を準備しない | 質問やトラブルへ回答できない | 対応言語、時間帯、エスカレーション先を決める |
| 公開後の更新方法を決めない | 言語間で料金や機能説明が食い違う | 原文変更から翻訳公開までの手順を作る |
| 対象国の制度確認が遅れる | 規約や決済を公開直前に変更する | 初期段階から法務・税務の専門家へ確認する |

最も多い誤解は、「日本語版が完成しているため、翻訳すれば短期間で公開できる」というものです。既存システムが日本語だけを前提に作られている場合、翻訳より前の構造変更に多くの費用がかかります。初回相談では、翻訳の見積もりとシステム改修の見積もりを分けて提示してもらうと、費用の根拠を比較しやすくなります。

## まとめ

- 既存のWebサービスへ1言語を追加する費用は、一般に100万〜300万円、期間は2〜4か月が目安です
- EC、予約、マッチングなど動的な機能が多いサービスは、300万〜800万円以上になることがあります
- 多言語化は翻訳だけでなく、日時、通貨、検索、メール、帳票、管理画面、運用まで対象にします
- 「英語」だけでなく、対象国、提供機能、決済、問い合わせ対応を先に決めます
- 重要な画面は人がレビューし、更新頻度の高い情報では機械翻訳を併用すると現実的です
- 見積書では、翻訳範囲、システム改修、テスト、公開後の更新費用を分けて確認します
- 最初は1市場・1言語・主要機能に絞り、利用状況を確認してから広げる方法が安全です

## よくある質問

### 既存のWebサービスは後から多言語化できますか？

できます。ただし、画面内に文章が直接組み込まれている場合や、言語ごとの日時・通貨を考慮していない場合は、翻訳前の改修が必要です。まず既存システムを調査し、翻訳作業とシステム改修を分けて見積もることが重要です。

### 機械翻訳だけなら費用を抑えられますか？

翻訳費用は抑えられますが、利用規約、料金説明、購入画面、エラーメッセージなどは人による確認を推奨します。影響の小さいコンテンツは機械翻訳、重要な導線は人がレビューするように使い分けると現実的です。

### 1言語追加にどれくらいかかりますか？

小規模なWebサービスで2〜4か月が一般的な目安です。既存システムが多言語化を考慮していない場合、文章量が多い場合、外部サービスとの連携や現地向け決済が必要な場合は、4〜8か月以上かかることもあります。

### 英語版を作れば海外展開できますか？

英語版は有力な第一歩ですが、対象国によって通貨、税、決済手段、個人情報保護、商習慣、問い合わせ対応が異なります。言語だけでなく、対象国で申込みからサポートまで完結できるかを確認してください。