海外マーケティング事例
「Stripeは130か国で同じ体験を出せる」——この言い方だと、加盟店の開設国と、顧客の支払い可能国が混ざります。公式のPaymentsページは、越境販売を195か国超・135通貨超とし、ローカルアクワイアリングは46市場と分けて書いています。同じCheckoutでも、裏側は「現地決済手段」「税計算」「現地通貨表示」を別レイヤで積み上げています。本記事では一次情報の数字を先に置き、日本企業が真似すべき設計原則と、今週の実務1点をわかりやすく解説します。数字の出典はすべてStripe公式（Payments／Tax／Docs／Blog）に限定し、二次メディアの国数は使いません。社内の要約メモでも、原文の「46」「195」を置き換えないルールにします。
| 指標 | 公式の言い方（要約） | 混同しやすい読み |
|---|---|---|
| ローカルアクワイアリング | 46市場（direct bank setups） | 「加盟店を46か国にしか置けない＝世界で売れない」 |
| 越境の顧客到達 | 195か国超・135通貨超 | 「195か国すべてで加盟店開設できる」 |
| 決済手段 | 100以上（Optimized Checkout Suite） | 「全手段を自社で個別契約している」 |
| Tax | 計算・徴収100か国超、登録・申告は別枠 | 「税務申告まで全自動で完了」 |
数字の並びは「同じ体験」ではなく、「同じAPI面に、違う規制と通貨を載せる」ための分解です。日本企業が越境を急ぐときも、まずこの分解表を社内で共有した方が安全です。マーケティングが「195か国対応」と書き、法務が「加盟店契約は日本のみ」と返す——この食い違いが、越境キャンペーンの途中で表面化します。
顧客から見ると画面は一つです。加盟店から見ると、国ごとの銀行接続・認証・決済手段の適格性・税ルールが違います。Stripeの設計は、画面側をCheckout／Payment Elementに寄せ、国差をPayment MethodsやTax、通貨表示のレイヤに逃がします。レイヤが分かれているからこそ、国を増やしてもフロントの見た目を作り直さずに済みます。
Zoomの事例コメントでは、自社がネイティブ対応できない国の決済手段をPayment Element経由で出せた、と公式Paymentsページに紹介されています。要点は「各国の決済を個別アプリとして作り直さない」ことです。体験の一貫性は、見た目の統一だけではなく、適格な手段を動的に出すことにあります。BigCommerceや他社のコメントも、ローカル決済を「背景でStripeがやる」前提で語られています。自社が各国の銀行と個別交渉する前提とは、工程表が違います。
公式は、Dashboardで主要決済手段を有効化し、AIモデルが顧客に関連性の高い手段を動的表示する、と説明しています。実験・A/B・ルール設定をノーコードで行い、適格性やメンテをStripe側に寄せる、という書き方です。Link（ワンクリック）やRadar（不正）も同じスイートに載り、決済の周辺機能を別ベンダーに分割しにくくしています。
日本企業が自前で「国別の決済ゲートウェイを増やす」と、接続テストとPCI対応と障害切り分けが国の数だけ増えます。Stripe型に寄せるなら、最初に有効化する手段の上限と、計測KPI（承認率・カゴ落ち・手段別CVR）を決めてから足します。手段を増やしたのに計測が無い状態が、いちばん危険です。週次で「有効手段一覧」と「国別カゴ落ち上位3」を並べると、足しすぎに早く気づけます。手段を増やした週は、必ず同じ週にカゴ落ちの内訳も更新します。
Stripe Taxは、間接税の計算・徴収を100か国超、商品カテゴリは600超、登録支援は90か国超、申告は別プランで90か国超、と製品ページで整理されています。Adaptive Pricingと併用する場合、税計算・報告・請求は統合通貨（integration currency）側で行い、顧客の表示通貨への換算後の金額で税を組み替えない、と公式ドキュメントにあります。換算手数料は非課税の通貨変換コストとして扱い、課税標準に含めない、という整理も同Docsにあります。
ここが日本企業の見落としやすい点です。「現地通貨で見せたから、税も現地の見た目金額で再計算している」と思い込むと、マージンと申告の前提がずれます。越境サブスクでは、表示通貨と課税ベース通貨を社内用語として分けておく必要があります。経理向けの説明資料には、Checkout画面のスクリーンショットではなく、統合通貨の請求ロジックを先に載せた方が誤解が減ります。画面の見た目と課税ベースは、同じ数字に見えなくても正しいことがあります。
Adaptive Pricingは、顧客の現地通貨で価格を提示し、換算と運用をStripe側に寄せる機能です。サブスク向けの公式ブログでは、2025年時点でサブスク取引の80%がいまだ事業のデフォルト通貨で価格設定されていた、と述べています。プレビュー分析（150万セッション）では、サインアップ時のコンバージョン平均+4.7%、オーソリ平均+1.9%、セッションあたりLTV平均+5.4%と報告されています。Runwayの例ではセッションあたりLTV+14%、Adaptive Pricing利用サブスクはサブスクあたりLTVが17.7%多い、とも書かれています。
安定バッファにより、ブラジルの顧客が月R$49.60で始めたら翌月も同じ表示を維持する、という例も公式にあります。為替が大きく動いた場合は更新額が見直される余地がある、と注記されています。日本企業が自前で為替表をメンテするより、まず「デフォルト通貨のまま海外に見せていないか」を確認する方が早いです。特に円建てのまま欧米向けLPを出しているケースは、カゴ落ちの主因が価格そのものではなく「通貨の違和感」である可能性があります。
1つ目は、開設国と販売国をKPIで分けることです。「Stripe導入＝全世界展開完了」ではなく、「加盟店開設が可能な市場」と「Checkoutが届く顧客国」を別指標にします。2つ目は、決済手段の追加をプロダクトロードマップの末尾に置かないことです。手段はマーケティング施策と同じで、出稿前に有効化と計測が必要です。3つ目は、税と通貨の用語を揃えることです。統合通貨・表示通貨・入金通貨が違うと、経理・法務・マーケティングが同じ数字を見て別の結論を出します。
逆にやらない方がよいのは、「全決済手段を一度にON」と「税の申告まで自動化できたと社内宣言」です。公式も申告はプランとパートナー連携で分かれており、計算できた＝申告完了ではありません。越境の初月は、対象国を3つ以内に絞り、手段・税・通貨の三点セットが揃ってから国を増やす方が、障害対応の負荷が読めます。国を増やすたびに、サポート言語と返金ポリシーの更新も同じチェックリストに入れます。チェックリストが未更新の国は、広告の配信対象から外します。
今週の実務1点は、次の1行表です。「SKU／統合通貨の価格／Adaptive Pricing ONか／Tax自動計算ONか／主要販売国／確認日」。例：「年額プラン／JPY 12,000／ON／ON／US・GB・SG／2026-08-20」。空欄の国は「未確認」と書き、広告を出す前に埋めます。
未確認のまま海外キャンペーンを始めると、カゴ落ちの原因が「価格」「決済手段」「税表示」のどれか分からなくなります。表が埋まってから出稿する、が最小ルールです。未確認行が残る国向けの広告は、出稿リストから外す運用にすると事故が減ります。週次で未確認行の件数を数え、ゼロになるまでグロース定例の冒頭議題に残します。
「130か国で加盟店を開ける」は、本記事の一次情報では裏付けません。公式が強調するのは195か国超への販売到達と、46市場のローカルアクワイアリングです。数字の出典を社内Wikiに残すときは、Paymentsページの文言をそのまま引用し、自分の要約語（例：130か国）で置き換えない方が安全です。提案書の「対応国」欄も、開設国と販売国を分けて書くと、後工程の契約レビューが早くなります。開設国が日本のみなら、その事実を一行目に書きます。
また、Adaptive Pricingの改善率はStripeの分析・プレビュー条件です。自社の業種・客単価・既存の現地決済比率で同じ数字になるとは限りません。導入判断は、自社Checkoutのカゴ落ち国別内訳を1週間取ってからで十分です。改善率のスライドをそのまま経営会議に出さず、「自社の未確認国リスト」を先に出す方が議論が前に進みます。リストが空なら、初めて効果検証のA/Bに進みます。効果数字の引用は、出典URLと分析条件をセットで残します。条件なき引用はしません。
A. 「加盟店を開ける市場」と「顧客が支払える国」は別です。公式Paymentsはローカルアクワイアリング46市場、越境販売195か国超・135通貨超と説明しています。最新はstripe.com/globalも併せて確認してください。
A. 終わりません。税計算は統合通貨側、表示通貨は換算後、とドキュメントに分かれています。登録・申告はStripe Taxのプランと対象国に依存します。
A. Checkout／Payment Linksの設定で、有効な決済手段・Adaptive Pricing・TaxのON/OFFを確認します。そのうえで、主要販売国ごとのカゴ落ちを1週間計測します。