米国向け注文の税計算が 「実際の出荷元ロケーション」基準になった

図解 ： 米国向け注文の税計算が「出荷元ロケーション」基準に（Shopify Tax × Order Routing） Improvement / Orders 米国向け注文の税計算が 「実際の出荷元ロケーション」基準になった Order Routing（注文ルーティング）が選んだフルフィルメントロケーションを使って税額を計算。ローカルピックアップは受け取り店舗基準。使われた ship-from ロケーションは注文レコードに記録される。 このページの構成 そもそも何が変わったのか（30秒で理解） 仕組み図解 ： 注文が入ってから税額が決まるまで Before / After 比較 ローカルピックアップの扱い 注文レコードに残る「ship-from ロケーション」 記事に書かれていないこと（記載なし一覧） 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が変わったのか 米国の顧客に向けて出荷する注文の 税計算の精度が改善 された。 税額は、 注文ルーティング設定がその注文に対して選んだフルフィルメントロケーション を使って計算されるようになった。 複数ロケーション出荷が正確に 複数拠点からフルフィルメントしている場合、税額が「その注文が実際にどこから出荷されるか」を反映する。 ピックアップは受け取り拠点基準 ローカルピックアップ注文では、ピックアップロケーションを基準に税額が計算される。 記録に出荷元が残る 計算に使われた ship-from ロケーションが注文レコードに表示され、レポートと申告の裏付けになる。 なぜ効くのか ： 米国では 税率が「どこから出荷されたか」に依存しうる 。出荷元が実態とズレていると税額もズレる。今回の変更で、税計算の入力が「ルーティングが実際に選んだ拠点」に揃った。 2 仕組み図解 ： 注文が入ってから税額が決まるまで ポイントは 「税計算がルーティングの結果を入力として受け取るようになった」 こと。税の設定を触るのではなく、 ルーティング設定の質がそのまま税額の正確さになる 。 3 Before / After 比較 項目 これまで 今回の改善後 税計算に使う出荷元 実態とズレうる 各注文の実際の出荷元が反映されていなかった ルーティング準拠 注文ルーティングが選んだフルフィルメントロケーション 複数拠点フルフィルメント 拠点ごとの税率差が正しく反映されないことがある 注文単位 各注文が実際に出荷される場所を反映 ローカルピックアップ 記事に明記なし（改善前の挙動の記述なし） 受取拠点基準 ピックアップロケーションから計算 注文レコード 計算に使われた出荷元の可視化について記述なし 表示される 使用された ship-from ロケーションが出る 対象 — 米国の顧客宛に出荷される注文 必要な作業 — 記載なし マーチャント側の設定手順は記事に記載なし 4 ローカルピックアップの扱い 配送注文 注文ルーティング設定が選んだ フルフィルメントロケーション （＝実際の出荷元）を基準に税額を計算。 ローカルピックアップ注文 ピックアップロケーション （顧客が受け取る拠点）を基準に税額を計算。 ピックアップ拠点が配送用の倉庫と別の州／管轄にある場合、 同じ商品でも受け取り方法によって税額が変わりうる 。BOPIS（店舗受取）を運用しているストアは、受取拠点ごとの税額を実注文で確認しておくこと。 5 注文レコードに残る「ship-from ロケーション」 ※ 上図は記事の記述（「注文レコードに計算で使われた ship-from ロケーションが表示される」「レポートと申告のための記録がより正確になる」）を図解したもので、実際の管理画面のレイアウトを再現したものではない。 6 記事に書かれていないこと（記載なし一覧） 元記事は短いお知らせのため、以下は 推測せず「記載なし」 とする。導入判断の前に自ストアで検証すること。 記載なし オプトインの要否 自動適用なのか、有効化操作が必要なのかの記述はない。 記載なし 対象プラン・対象機能の条件 どのプラン／どの税機能構成で有効になるかの明示はない。 記載なし ロールアウト時期・段階公開 公開日（2026年8月24日）以外の展開スケジュールの記述はない。 記載なし API / GraphQL の変更点 Admin API や Webhook のフィールド追加・変更に関する言及はない。 記載なし 過去注文への遡及 既存注文の税額が再計算されるかどうかは書かれていない。 記載なし 米国以外の国での挙動 記事の対象は「米国の顧客宛に出荷される注文」のみ。 7 技術者が押さえるべき5つのポイント 1. 税設定ではなくルーティング設定が効く 税額の入力が「注文ルーティングが選んだロケーション」になった以上、 ルーティング設定の見直しが税精度の改善作業 になる。税マスタだけ見ていても直らない。 2. 単一拠点ストアは影響が小さい 恩恵が明確なのは 複数ロケーションからフルフィルメントしているストア 。1拠点運用なら出荷元は元々一意なので変化は限定的。 3. 受取方法で税額が変わりうる 配送＝出荷元基準、ピックアップ＝受取拠点基準。 同一カートでも受取方法の選択で税額が動く ことを、フロント表示や見積ロジックの前提に入れる。 4. 監査証跡として ship-from が使える 注文レコードに計算根拠のロケーションが残るため、 税額の差異調査が「どの拠点から出たか」で説明可能 になる。経理からの問い合わせ対応が楽になる。 5. API 仕様・オプトイン条件は元記事に記載なし → 実機確認が必須 Admin API のフィールド追加、既存注文への遡及、対象プラン、有効化操作の要否のいずれも記事に書かれていない。外部の会計 / ERP 連携で税額と出荷元を同期している場合は、 本番反映前に開発ストアで実注文を通して差分を確認 すること。詳細は Shopify ヘルプセンターの注文ルーティングのドキュメントを参照。 8 業務に活かせる3つのユースケース USE CASE 1 米国マルチ倉庫ストアの「税額ズレ」棚卸し 課題 米国内に複数の倉庫／3PL を持ち、注文ごとに出荷元が変わるのに、税額が実際の出荷元を反映していない懸念があった。申告時に自社集計と Shopify の税額が合わない。 打ち手 今回の改善が入った期間の注文を対象に、注文レコードの ship-from ロケーションと税額を突き合わせ、拠点別に税額の傾向を確認する。ズレていた期間との差分を洗い出す。 効果 レポート・申告用データの信頼性が上がり、拠点追加時の税影響も事前に読めるようになる。 技術メモ 過去注文への遡及の有無は記事に記載なし。改善前後で税額の連続性が切れる可能性があるため、比較は日付で区切って行う。 USE CASE 2 BOPIS（店舗受取）導入ストアの税額シミュレーション 課題 店舗受取を提供しているが、受取拠点によって税額がどう変わるかを把握しておらず、顧客からの「表示価格と請求額が違う」問い合わせに即答できない。 打ち手 主要なピックアップ拠点ごとに同一カートでテスト注文を作り、税額を一覧化。カスタマーサポート用の早見表として社内共有する。 効果 問い合わせ一次回答の高速化。受取拠点追加時の税影響も同じ手順で検証できる。 技術メモ ピックアップ注文はピックアップロケーション基準。配送と受取で税額が変わる前提でチェックアウト UI の文言を用意する。 USE CASE 3 会計 / ERP 連携の突合ルールに「出荷元」を追加する 課題 Shopify の注文データを会計・ERP に流しているが、税額の内訳をロケーション単位で持っておらず、州別の集計を手作業で組み立てている。 打ち手 注文レコードに載る ship-from ロケーションを連携項目に加え、税額と一緒に下流へ渡す。突合キーを「注文 × 出荷元」にする。 効果 州別・拠点別の税額集計が自動化され、申告準備の手作業と差異調査の時間を削減できる。 技術メモ API でのフィールド提供有無は記事に記載なし。連携実装前に開発ストアで実データを取得し、取得経路（Admin API / エクスポート）を確定させること。 9 提案で使える1行サマリ 「米国向け注文の税額が、 注文ルーティングが選んだ実際の出荷元ロケーション で計算されるようになった。 店舗受取は受取拠点基準、使われた出荷元は注文レコードに記録される。 複数拠点でフルフィルメントしているストアほど、レポートと申告の正確さが上がる。 」 source ： changelog.shopify.com / shopify-tax-is-now-compatible-with-order-routing published 2026-08-24 ／ Improvement ・ Orders