ECサイトの多言語対応では、RFPや要件定義書に、対象言語と追加の順番、翻訳の使い分けと更新運用、多言語SEOの範囲を書いておくことが欠かせません。物流・関税・海外決済といった越境ECの要件ではなく、翻訳方針・言語追加計画・多言語SEOといった多言語化そのものの要件化に集中します。
要件が曖昧だと見積もりがばらつき、追加費用や手戻りの原因になります。全体像はEC多言語対応の完全ガイドで確認できます。
Webサービス開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
多言語対応の要件定義の進め方
多言語対応の要件定義は、機能の細部より先に、「なぜ多言語化するのか」という目的の確認から始めるのが鉄則です。
目的が海外売上の柱づくりなのか、すでに届いている海外からの問い合わせへの対応なのかによって、対象言語も投資規模も変わります。
目的が曖昧なまま機能リストを作ると、使われない言語に翻訳維持費を払い続ける事態を招きます。そのため、要件定義の出発点は、目的とKGI（最終目標指標）を言語化することです。
対象言語と追加順を決める言語追加計画
多言語対応の要件定義で最初に、そして最も重要なのが「対象言語と追加の順番」を決める言語追加計画です。最初から複数の言語を要件に盛り込むと、翻訳維持費という固定費が一気に積み上がり、売上が追いつかないまま利益を圧迫します。
成功事例に共通するのは、言語を段階的に増やす進め方です。この段階計画をRFPに明記すると、ベンダーも現実的な構成で提案でき、見積もりが過大になりません。
言語追加計画を要件化するときは、フェーズごとに追加条件を添えて書くのがコツです。さらに、後から言語を追加できる拡張性を非機能要件として求めておくと、初期は英語のみでも、将来の中国語追加がスムーズになります。
要件定義の段階で「いつ・どの条件で・どの言語を足すか」を描いておくことが、先行投資による赤字化という典型的な失敗を防ぎます。
フェーズは、たとえば次の2段階に分けて書けます。
- 第1フェーズ：対象言語は英語のみ
- 第2フェーズ：月商100万円に到達したうえで、アクセス解析で需要が確認できた言語を追加
翻訳方針と品質基準の言語化
翻訳方針では、どのページを機械翻訳で済ませ、どのページを人力翻訳で磨くかという強弱を決め、要件として書き込みます。
一般的には、商品説明・購入導線・送料や返品ポリシーといった売上判断に関わる箇所を人力翻訳にし、お知らせや利用規約など購入に直接関わらない箇所は機械翻訳ベースとする構成が、コストと品質を両立させます。
この方針が明記されていれば、英語化を50万円前後に抑えた見積もりが出やすくなります。
翻訳に求める品質は、商材の性質によって変わります。次の2つの型に分けて考えます。
- 直感で買える商材：食品や日用品で、機械翻訳ベースでも成立しやすい
- 仕様の正確さが購入の前提となる商材：精密機器や専門商材で、人力翻訳の比重を高める必要がある
たとえば、要件定義書に「対象商材は専門用語が多く、型番・仕様の表記は人力でネイティブチェックを行う」といった品質基準を書いておくと、翻訳の作り込み度合いについての認識のズレを防げます。
翻訳方針と品質基準は、見積もりの妥当性を判断する重要な物差しになります。
機能要件と非機能要件への落とし込み
目的・言語計画・翻訳方針が固まったら、それを機能要件と非機能要件に落とし込みます。多言語対応の機能要件は「翻訳管理」「言語切り替え・表示」「多言語SEO」の3層で整理すると、漏れが出にくくなります。
非機能要件には、表示速度や将来の言語追加に耐える拡張性、翻訳更新の運用負荷といった、目に見えにくいが運用を左右する条件を書き込みます。
機能要件と非機能要件の両方を要件定義書に明記すると、過不足のない見積もりを引き出せます。
多言語SEO要件の機能要件への明記
多言語対応の要件定義で最も抜け落ちやすいのが、hreflangや言語別URLといった多言語SEOの要件です。翻訳と言語切り替えだけを要件に書いて発注すると、「翻訳はできたが海外の検索で見つけてもらえない」という事態に陥ります。
機能要件には、多言語SEOの項目と言語切り替えの挙動を具体的に書き込みます。
- 多言語SEO：hreflangの全ページへの自動出力、言語別のサブディレクトリ型URL、言語ごとのタイトルタグとメタディスクリプション
- 言語切り替えの挙動：言語自動判定で強制転送しない、切り替え時は同一商品の別言語ページへ遷移する、切り替えメニューを常時表示する
多言語SEOと言語切り替えの挙動は、翻訳の質と同じくらい集客と購入率を左右します。書いておかないと、ベンダーの解釈次第になり、後でユーザー体験を損ねるため、要件定義書に漏らさず記載します。
翻訳維持費と運用体制の非機能要件への記載
多言語対応の要件定義では初期費用に目が行きがちですが、本当に注意すべきは翻訳維持費という継続コストです。商品の追加や価格改定のたびに各言語の翻訳を更新する必要があり、この運用負荷は言語数に比例して増えます。
維持費の目安は、英語のみで月3〜8万円、中国語追加で月8〜15万円、全世界対応で月20〜30万円です。そのため、要件定義の段階で「許容できる月次維持費の上限」を明示しておくことが欠かせません。
運用体制は、次の2点を非機能要件に書き込みます。
- 更新の担い手：社内で回すか、ベンダーに継続委託するか
- 自動化の範囲：機械翻訳による更新で、どこまでを賄うか
運用体制が曖昧だと、公開後に翻訳が古いまま放置され、せっかくの多言語サイトが信頼を失います。そこで、要件定義書に「原文更新時の翻訳追従フローと担当」を明記すると、運用が回る前提の見積もりを引き出せます。
初期費用だけでなく、3〜5年というECサイトの寿命を見据えた運用費まで含めて要件化することが、健全な投資判断につながります。
RFPに盛り込む項目とベンダー選定
要件が固まったら、それをRFP（提案依頼書）にまとめてベンダーに提示します。
RFPは「自社が何を実現したいか」と「どう提案してほしいか」を一つの文書に整理したもので、これがあると複数社の提案を同じ土俵で比較できます。逆に、RFPなしで口頭ベースで相談すると、各社が異なる前提で見積もりを出すため、金額だけ見ても比較になりません。
多言語対応のRFPには、言語計画・翻訳方針・機能要件・維持費の上限を漏らさず盛り込みます。
多言語対応RFPに必須の記載項目
多言語対応のRFPに盛り込むべき項目を整理すると、まず次の2つです。
- 目的とKGI：なぜ多言語化するか、何をもって成功とするか
- 言語追加計画：第1フェーズの対象言語と、次の言語を追加する条件（月商などの閾値）
翻訳方針では、機械翻訳と人力翻訳の使い分けと、商材特性に応じた品質基準を書きます。機能要件では、翻訳管理・言語切り替え・多言語SEOの3層について、具体的な項目を示します。
非機能要件では、表示速度や言語追加の拡張性、翻訳更新の運用フローと担当を押さえます。維持費は、許容できる月次の翻訳維持費の上限を示しておきます。
これらを書き込んでおくと、各社の提案を金額だけでなく実現方法まで含めて比較でき、見積もりのブラックボックスを解消できます。
さらに、RFPには「見積もりの内訳を翻訳と機能開発、SEO設定、運用保守に分けて提示してほしい」という要望も書いておきます。多言語対応の費用が一式でまとめられていると、どこにいくらかかっているかが分からず、追加要件が出たときの単価も不透明になります。
内訳の提示を求めることで、同じ「英語化50万円」でも、その内訳が機械翻訳ベースなのか全ページ人力なのかが見え、妥当性を判断できるようになります。
多言語対応に強いベンダーの見極め方
RFPへの提案を受けたら、ベンダーの見極めに入ります。まず確認したいのは、いきなり全言語ではなく、英語先行で段階的に増やす進め方を提案できるかです。
最初から多言語をフルで作り込もうとする提案は、維持費の観点で警戒すべきです。
機械翻訳と人力翻訳の使い分けを具体的に設計できるか、自社の商材特性に応じた翻訳品質を提案できるかを見ます。
hreflangや言語別URLといった多言語SEOの実装実績があるかも確認します。
また、翻訳更新の運用までフォローできるパートナーかどうかも、重要な判断材料です。商品追加や価格改定のたびに発生する翻訳更新を、どんな仕組みと体制で回すかまで提案に含めているベンダーは、運用フェーズまで見据えています。
要件定義の前提となる必要機能の一覧については、後述の関連記事もあわせてご覧ください。
riplaは、フルスクラッチ受託と国内開発の知見をもとに、次の2点で支援しています。
- 要件面の支援：自社の商習慣や既存システムに合わせた、多言語対応の要件の組み立て
- 翻訳運用の設計：段階的な言語追加を前提にした設計
まとめ
ECサイトの多言語対応の要件定義は、まず、対象言語と追加の順番、翻訳方針を発注側が言語化することから始まります。そのうえで、翻訳維持費の上限と多言語SEOの範囲を決めます。
英語1言語から段階的に増やす言語計画をRFPに明記し、機械翻訳ベースに重要ページの人力翻訳を組み合わせた翻訳方針を書きます。
維持費の上限を設定し、hreflangや言語別URLを機能要件に盛り込みます。
これらを揃えることで、各社の提案を同じ土俵で比較でき、英語化50万円前後という見積もりの妥当性も判断できるようになります。
要件定義で大切なのは、それを「発注側の防衛策」として使う視点です。要件を詳細に書き込むほど、認識のズレに起因する追加費用や手戻りを防げます。
とくに翻訳維持費という継続コストがかかる多言語対応では、初期費用だけでなく運用費まで含めて要件化することが、先行投資による赤字化を防ぐ鍵になります。
riplaはフルスクラッチ受託と国内開発を組み合わせ、発注側に寄り添った要件整理とRFP作成を一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
▼RFP作成前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。