越境ECとは？サイト制作前に決める販売国・配送・返品の条件

海外から商品を買ってほしいのに、英語ページを作った後で「その国へ送れない」「送料が最後まで分からない」と気づく。越境ECのサイト制作では、この順番の逆転を避けることが大切です。最初に決めるのは言語の数ではなく、誰に何を、どの地域へ、どの条件で販売できるかです。

結論から言うと、販売国・対象商品・配送条件・決済・返品窓口を一枚の表で整理し、商品ページから購入完了まで同じ条件を表示できる範囲で始めるのが現実的です。未確定の配送先へ注文を受ける仕組みを先に開けず、必要なら問い合わせ受付から検証します。翻訳、デザイン、検索向けの設定は、この販売条件を伝えるために組み立てます。

この記事では、越境ECを初めて検討する中小企業の担当者に向け、サイトに載せる情報と制作前に社内で決めることを切り分けます。特定国での販売許可、税務、関税の個別判定を代行する記事ではありません。扱う商品と販売地域に応じた確認事項は、専門家や配送・決済サービスの公式情報で確定してください。

この記事で分かることは、販売条件の整理方法、商品ページと購入画面の役割、言語・通貨・配送国の違い、公開前の確認手順、外注先へ渡す資料の作り方です。架空の商品を使った確認例も掲載しています。実際の注文や決済を実施した事例ではありません。

越境ECサイトは何を売れる状態にするものか

翻訳ページと購入できるサイトの違い

越境ECサイトとは、国や地域をまたぐ販売のために、商品選択、条件確認、注文、支払い、配送後の対応につながる情報と手続きを用意するサイトです。英語の会社紹介を追加するだけでは、購入に必要な条件まではそろいません。反対に、注文を受ける機能を付けても、対象地域や返品の連絡先が分からなければ、購入者は判断できません。

例えば、商品説明の「在庫あり」は、すべての国へ今すぐ配送できるという意味ではありません。倉庫には商品があっても、梱包方法が決まらない地域や、選んだ配送方法で扱えない商品があるかもしれません。サイトでは、商品の在庫と、その購入者へ届けられる条件を分けて扱います。

また、日本語の問い合わせ窓口があることと、購入者の言語で返品を受け付けられることも別です。文章を翻訳した段階で運営できると判断せず、注文後に誰が対応するのかを具体的にしておきます。制作会社だけに任せられない部分を先に見つけると、必要なページと機能が明確になります。

最初にそろえる販売条件の一枚表

制作前には、次のような表を作ります。書けない欄はサイトの機能不足とは限りません。社内判断や外部サービスへの確認が必要な欄として担当者と期限を置きます。

表は横にスクロールして比較できます。

一枚表は公開する約款の代わりではありません。制作担当、販売担当、出荷担当が同じ前提を確認するための作業資料です。ここで「世界中に販売」とだけ記載してしまうと、送料や購入画面の設定が決められません。販売できる範囲を明確にしてから、サイトに載せる表現へ変換します。

注文型と問い合わせ型を選ぶ

最初からオンライン決済まで用意する方法のほかに、条件を確認してから見積もりや注文につなげる方法もあります。どちらが適しているかは、商品価格が固定できるか、送料を自動で判断できるか、販売前の確認が必要かによります。問い合わせ型だから劣るという判断はしません。

表は横にスクロールして比較できます。

購入ボタンがある商品と問い合わせが必要な商品を混ぜる場合は、ページ上で違いを説明します。同じ見た目のボタンで行き先だけを変えると、読者は次の操作を予想できません。「条件を確認して購入へ進む」「配送可否を相談する」のように、操作後に何が起きるかを伝えます。

自社サイトと外部の販売先の役割を比べる

海外へ販売する入口は、自社サイトだけとは限りません。外部の販売サービスを利用する場合も、購入者へ自社の商品情報や問い合わせ先を説明するページを用意できます。どこで注文を受け、どこを商品情報の更新元にするかを決めることが重要です。

表は横にスクロールして比較できます。

外部販売先へ移動するリンクには、移動先で注文することを分かる形で示します。自社サイトの表示価格が販売先の現在価格と異なるなら、そのまま併記してよいかを見直します。複数の販売先を使う場合も、同じ商品がどこで買えるかを整理し、最新の条件へたどれる導線にします。どの構成が売上につながるかは、商品や対象者、実際の流入と購入を見て判断するもので、構成だけでは断定できません。

販売国と商品をどう絞るか

言語と配送国を別の項目として管理する

英語で読む購入者が、同じ国に住んでいるとは限りません。英語ページを開いたことを理由に配送国を自動で確定すると、想定外の条件が適用される可能性があります。言語は情報を読むための選択、配送国は商品を届けるための選択として扱います。

同じように、表示通貨と請求通貨も意味をそろえます。購入者の理解を助ける参考表示なのか、実際にその通貨で請求するのかを明確にします。換算を行う機能を導入する場合も、表示だけが変わるのか、注文時の金額まで変わるのかを確認します。サービス名だけで機能の対応範囲を判断しないでください。

地域の選択を変えたとき、送料や利用できる支払い方法が変わるなら、その変化を画面で伝えます。買い物かごに入れた後に配送国を変更しても、以前の条件が残らないかを確認します。言語切替のたびに商品や買い物かごが失われる場合も、購入者が迷わない案内が必要です。

商品ごとの条件を先に整理する

越境ECでは、すべての商品を一度に掲載するより、説明と配送条件をそろえられる商品から始める判断ができます。選定の基準は、売れそうかどうかだけではありません。仕様を正確に説明できるか、梱包と出荷方法が決まっているか、購入後の質問へ対応できるかも含めます。

サイズ、素材、使用環境、付属品など、購入判断に必要な項目を商品群ごとに決めます。日本語の商品名だけで内容が伝わるとは限りません。型番を残したうえで、何に使う商品なのかを短く説明します。ブランドや独自用語をそのまま翻訳せず、購入者が比較できる仕様の欄を設けます。

食品、化粧品、電気製品など、取り扱いに追加確認が必要な商品を、一般雑貨の例と同じ条件で販売できると判断してはいけません。商品分類、配送サービスの取り扱い、販売先の制度を確認する担当を決めます。本記事の表に記入できたことを、販売条件への適合が確認できた証拠とは扱いません。

対象外の国へ進めない設定を確かめる

販売対象外の地域がある場合は、説明ページへの記載だけでなく、注文画面でも条件が一致しているかを確認します。商品ページに「特定地域のみ配送」と書いてあるのに、購入画面で対象外の国を選べる状態では、注文を受けてからの調整が必要になります。

WooCommerceの公式文書では、配送先に合致する配送ゾーンを設定し、上から順に照合して最初に合致したゾーンを使用する仕組みが説明されています。このような設定がある仕組みでは、対象地域の細かさと設定順が結果に関係します。サイトを作るときは、実際に使う環境の設定と表示を確認します。これはWooCommerceの仕組みの説明であり、別のサービスも同じ動きだという意味ではありません。

対象外への注文を受け付けない場合と、送料を確認して個別案内する場合は区別します。後者では、通常の購入完了と誤解される表示を避けます。問い合わせの受付、見積もりの提示、注文の確定を、それぞれ異なる段階として記録すると、購入者への説明も整理できます。

送料・決済・返品はどこで説明するか

総額の判断に必要な情報を商品ページから案内する

商品価格だけで購入を決められるとは限りません。送料がいつ分かるのか、追加の費用があり得るのか、配達までの見込みをどこで確認できるのかを、購入前に案内します。未確定の負担を「すべて込み」と表現しないことが基本です。

送料が住所や数量によって変わるなら、その条件と確認する場所を示します。商品ページに全地域の料金表を載せる必要があるかは運営方法によりますが、購入画面に進まないと送料の説明自体を見つけられない構成は避けたいところです。別ページへまとめる場合も、商品ページからその案内へ到達できるようにします。

Google Merchant Centerの配送情報に関する公式文書は、配送地域や配送サービスなどを設定する項目を説明しています。商品情報を外部サービスへ掲載する場合は、サイト上の案内と、その掲載先に登録した条件の対応も確認します。サイト内を直しただけで外部の設定まで自動で更新されるとは限りません。使っていない掲載機能の設定を、最初から制作要件へ加える必要もありません。

配送日数は確定情報と見込みを分ける

「翌日発送」と「翌日到着」は違います。注文受付、支払い確認、出荷、配送という段階を分け、どの時点を説明しているのかを明確にします。営業日だけを数える場合や、特定商品で準備期間が異なる場合も、その前提が必要です。

配送会社の目安を引用する場合は、対象地域、配送方法、確認日を記録します。サイト運営側で確認していない到着日を保証しないでください。購入者の住所によって表示を変える機能を使うなら、条件を入力する前に出ている数字が概算であることを説明します。

出荷が遅れる場合の連絡手順も決めます。連絡先が登録されていることと、連絡が届くことは別です。注文確認メールに返信できるのか、問い合わせフォームへ注文番号を記載するのかなど、購入後のやり取りを具体的にします。配送の案内は、購入前の不安解消だけでなく、受注後の運営にも関わります。

支払い状態と注文状態を混同しない

注文を受け付けた直後に、支払いが完了しているとは限りません。使う決済方法によって、確認が必要な段階や失敗したときの表示は異なります。制作時は、購入者に見せる文言と、社内で処理する状態を対応させます。

表は横にスクロールして比較できます。

この表は運用設計の例です。個別の決済サービスの実装仕様を説明するものではありません。採用するサービスの公式仕様を確認し、テスト環境や承認された手順で、画面・注文記録・通知が一致することを確かめます。実際の課金を伴う確認は、関係者の承認範囲を明確にして行います。

返品を案内する窓口と条件を一致させる

返品の可否を短い一文だけで示すと、購入者が必要な手続きを判断できない場合があります。対象となる商品や状態、連絡が必要なタイミング、返送前に確認する内容、費用の扱いなどを、確認済みの範囲で整理します。販売地域や商品によって必要な対応が異なるため、他社の文章をそのまま流用しないでください。

返品案内に書かれたメールアドレスと、問い合わせページの窓口が違う場合は、どちらへ連絡するかを説明します。担当者が使わない窓口を残すと、購入者の申出が届いても対応が進みません。複数言語のページで窓口が変わる場合も、実際に対応できる体制と合わせます。

注文後に初めて返品条件を知らせるのではなく、購入前に読める場所へ用意します。注文画面のリンクも、トップページへ戻るだけのリンクではなく、該当する条件へ到達できるものにします。スマホで別ページを開いた後、商品選択に戻れるかも確認したい点です。

多言語の商品ページをどう設計するか

全文翻訳の前に、共通の商品データを作る

日本語の長い紹介文をそのまま翻訳するより、品番、名称、仕様、付属品、取り扱い上の条件、配送対象を共通の商品データとして整理すると、言語ごとの食い違いを減らせます。文章は言語に合わせて変えても、同じ商品の仕様が別物にならないようにします。

例えば、日本語の仕様欄を更新しても英語の説明が以前のままなら、購入者は古い仕様を前提に注文してしまいます。更新する場所と、各言語へ反映する担当を決めておきます。自動翻訳を使う場合も、数値、単位、固有の仕様名、否定表現は確認対象として残します。

画像に商品説明を焼き込むと、言語ごとの修正が難しくなることがあります。重要な仕様と条件は読み取れる本文として用意し、画像だけに依存しない構成にします。写真や図に説明を添える場合も、何を示しているかが本文と対応していることを確認します。実物と異なる生成画像を商品写真として見せないことも必要です。

言語切替で同じ商品に戻れるようにする

商品詳細を読んでいる途中で言語を切り替えたとき、別言語のトップページへ戻るだけでは、同じ商品を探し直す必要があります。対応する商品ページへ移動できるようにし、未翻訳の商品がある場合は、その状態を分かる形で伝えます。

Google Search Centralは、言語や地域が異なるページの対応を伝えるための方法としてhreflangを説明しています。HTMLで指定する場合は、各言語版が自身を含む対応ページを示し、URLには完全なURLを使用することなどが記載されています。ただし、設定しただけで検索順位や購入が増える保証はありません。

制作担当へは「多言語SEO対応」という言葉だけで依頼せず、同一商品の言語対応、各ページの見出し、検索結果向けの説明、意図したURLと公開設定まで確認対象を具体化します。翻訳のない商品に無理な対応先を作るより、公開する範囲を先に決めることが大切です。

購入画面と通知まで言語の範囲を決める

商品ページが英語でも、入力エラーや購入完了の案内が日本語だけなら、購入者は操作が成功したか判断できないことがあります。翻訳範囲には、ボタン、入力項目、エラー、送料の説明、注文確認、購入後の連絡も含めて検討します。

特に名前、住所、電話番号の入力例は、想定する購入者に合っているかを確認します。日本国内だけの形式を必須にした入力欄で、海外住所を受け付けられるとは限りません。実在の顧客情報を使わず、テスト用の架空データで入力と表示を確認します。住所を送信したり決済したりする試験は、準備された環境と許可された範囲で実施します。

運営側がすべての言語に対応できない場合は、問い合わせ可能な言語や案内方法を明確にします。翻訳ツールの利用を前提に運営する場合も、返品や仕様の重要な確認を誰が担当するかを決めます。見た目の言語数より、購入後まで説明がつながる範囲で公開するほうが、運営上の判断をしやすくなります。

公開前に購入経路をどう確認するか

架空商品で確認表を作る

ここでは、架空の「整理用ケースA」を、対象地域へ販売する想定で確認表を作ります。実際の商品、注文、決済、配送実績ではありません。目的は、表示と条件の不一致を公開前に見つけるための検査項目を示すことです。

表は横にスクロールして比較できます。

この表を実際のサイトへ当てはめるときは、試験日、環境、対象商品、配送先の条件、確認結果、証拠の保存先を追記します。「確認済み」とだけ書くと、どの商品とどの条件を見たのかが分かりません。仕様を変更した場合は、その変更が関係する検査をやり直します。

スマホで本文から購入条件まで通して読む

確認はパソコンの管理画面だけでは完結しません。購入者が使うスマホで、商品名、仕様、価格、配送条件、返品の案内、問い合わせ先まで順番にたどります。表が横に長い場合は、ページ全体が横へ動くのではなく、表の範囲で読めるかを確認します。

画像は比率を保ち、商品や文字が切れないようにします。ボタンが重なったり、固定表示が条件文を隠したりしていないかも見ます。長いページでは、目次やページ内リンクを押した先に、該当する説明が表示されることも確認対象です。

検査の結果は「スマホ対応」という一語ではなく、使った画面幅や端末、ページ、行った操作、見つかった問題を記録します。すべての端末を一度に試すことは難しくても、未確認の範囲を明確にできます。公開直前だけでなく、翻訳や配送条件の変更後にも確認できるようにしておきます。

公開と受注開始を一つの操作にしない

ページを一般公開することと、すべての商品で注文を受け始めることは分けて考えられます。まず商品情報や問い合わせ窓口を公開し、販売条件が確定した商品から購入機能を開く方法もあります。その場合、購入できない商品を「販売中」と誤解させない表示が必要です。

受注を開始するときは、担当者が注文通知を確認できるか、支払いと出荷の処理が分かるか、問い合わせに対応できるかを確かめます。通知設定が保存されているだけで、実際に届いたことまで確認できたとは扱いません。試験で通知を使う場合は、承認された安全な送信先を利用します。

公開後に問題が見つかった場合の停止方法も用意します。対象商品だけを受付停止にするのか、問い合わせへ切り替えるのか、購入者へ何を案内するのかを決めておくと、慌ててサイト全体を変更せずに済みます。変更前の設定と公開ページを保全できる範囲で、必要な部分から対応します。

制作を依頼するとき何を渡すか

見積もり前に渡す資料をそろえる

外注先へは、販売条件の表、対象商品、対応言語、必要な購入方式、出荷と問い合わせの担当をまとめて渡します。現行サイトがあるなら、引き継ぐURLや商品データ、既存の注文・顧客データの扱いも整理します。顧客情報を見積もり資料にそのまま添付する必要はありません。例を示すときは匿名化した項目名や架空データを使います。

機能名を並べるだけでは、どこまでが制作範囲か伝わりません。「多通貨対応」と書くなら、参考表示か実際の請求通貨かを示します。「配送対応」と書くなら、地域別の設定、商品別の例外、購入画面の表示まで含むかを確かめます。必要な動作と確認条件を言葉にすると、提案内容も比較しやすくなります。

表は横にスクロールして比較できます。

制作費だけでなく更新の負担を見る

初期の見積もりだけでは、運営に必要な手間を比較できません。商品追加、仕様変更、翻訳修正、配送条件変更のたびに誰がどこを更新するかを確認します。安く見える構成でも、同じ項目を複数の言語で手作業更新するなら、更新漏れを防ぐ仕組みが必要です。

一方で、最初から複雑な自動化を入れれば解決するとも限りません。商品や販売地域が少ない段階では、更新元を一つにし、確認する担当を明確にするだけで整理できる場合があります。現状の運営人数と更新頻度に合わせ、管理できる範囲を選びます。

月額費用、決済、配送、外部連携などの条件は、利用するサービスと契約内容で確認します。他社の紹介記事にある価格を自社の見積もりへ転用したり、未確認の手数料を固定額として掲載したりしないでください。見積もりの比較では、金額の前提と含まれる作業をそろえることが重要です。

相談の前に、一つの商品を選ぶ

越境EC全体の構想がまとまらないときは、まず代表商品を一つ選び、誰が、どの地域で、何を確認すれば購入できるかを書き出してください。商品説明、送料、返品、購入後の窓口のうち、決まっていない項目が見つかれば、それが制作前に進める作業です。

タゲンゴへの相談では、販売したい地域、代表商品、対応したい言語、現在のサイトの有無、オンライン注文か問い合わせから始めたいかを共有すると、必要なページと導線を具体化しやすくなります。顧客名や実際の注文情報は、最初の相談資料へ含める必要はありません。

まずはお問い合わせから、販売条件のどの部分が決まっていて、どこが未確定かをお知らせください。サイト制作で解決する範囲と、販売・配送・専門確認が必要な範囲を分けて検討します。売上や検索順位を保証するものではありません。

よくある質問

英語ページがあれば海外から購入してもらえますか？

英語ページだけでは、配送先、送料、支払い、返品などの購入条件までは確定しません。情報を読むための言語と、販売可能な地域を分けて決め、購入まで必要な条件が同じ前提で表示されるかを確認します。

最初から複数の国へ販売したほうがよいですか？

対応できる条件がそろう範囲から始める判断ができます。地域を増やすと、配送、表示、問い合わせ対応の確認範囲も増えます。予定する地域ごとに条件を整理し、準備ができていない範囲を購入可能として表示しないことが大切です。

商品ページと購入画面の翻訳は別に考えてよいですか？

制作範囲として分けて管理することはできますが、購入者の操作は連続しています。商品説明が読めても、入力エラーや購入完了が分からなければ迷います。ボタン、入力欄、エラー、通知、購入後の窓口まで翻訳と確認の対象を決めます。

送料が決まっていなくても公開できますか？

商品紹介や問い合わせ受付から始める方法はあります。ただし、そのまま注文を確定できると誤解される表示は避けます。送料の確認が必要なこと、誰がいつ案内するか、どの段階で注文が確定するかを明確にしてください。

出典・確認日・運営者

確認日：2026年11月3日。著者・運営：タゲンゴ編集部。公式文書の説明と、本記事の制作・運営上の提案を区別しています。商品例と確認表は編集上の架空例であり、実注文、顧客事例、決済試験の結果ではありません。

• Google Search Central：言語や地域が異なるページの対応を伝える
• Google Merchant Center：配送設定
• WooCommerce：配送ゾーンの設定