配送先住所を変えたら、 税額も一緒に直るようになる

図解 ： 配送先住所の更新で税額が再計算されるようになる（orderUpdate） Admin GraphQL API / 仕様変更 配送先住所を変えたら、 税額も一緒に直るようになる 2026年8月31日から、未フルフィルの注文で orderUpdate により配送先住所を変更すると、新しい配送先に対して税額が再計算される。これまでは住所だけ更新され、税ラインは元のまま残っていた。 このページの構成 30秒で理解 ： 何が変わるのか 仕組み図解 ： orderUpdate を叩いてからの流れ 再計算されない 2 つのケース 変更前 vs 変更後の比較 適用範囲とタイミング 実装側でやること（3ステップ） 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 30秒で理解 ： 何が変わるのか 2026年8月31日 以降、未フルフィルの注文に対して orderUpdate GraphQL mutation で配送先住所を変更すると、 新しい配送先に対して注文の税額が再計算される 。 これまでは新しい住所は保存されるものの元の税ラインが変更されず、注文の合計金額が「実際の配送先」と一致しない状態になっていた。 従来 ： 住所だけ更新された orderUpdate は新しい住所を保存するが、元の税ラインはそのまま。結果として注文の合計が、実際に発送する宛先と一致しなくなっていた。 今後 ： 財務データも一緒に直る 住所更新の一部として注文の財務データが是正され、合計が配送先に対して正確な状態を保つ。 導入のために必要な変更は無い 。 配送先住所を更新した後は、 他の order edit と同じように 注文を query して taxLines / totalTaxSet / 各種 totals を読み直せばよい。特別な API も追加パラメータも登場しない。 2 仕組み図解 ： orderUpdate を叩いてからの流れ いちばん重要な非対称性 ： 住所変更は 常に成功する 。条件付きなのは 税の再計算だけ 。 つまり「mutation が成功した ＝ 税も直っている」とは限らない。成否ではなく 結果の値 で判断する必要がある。 3 再計算されない 2 つのケース 税の再計算は「安全に適用できるときだけ」実行される。記事で明示されているのは次の 2 ケース。 再計算されない ① 部分的にフルフィル済みの注文 完全に未フルフィル の注文では税額が再計算される。 部分フルフィル の注文では、住所は保存されるが税額は変更されない。 理由 ： 一部の商品はすでに 元の宛先 へ発送済みで、注文全体を新しい住所で再計算すると、そこへ発送されていない分にまで新しい宛先の税が適用され、実際にフルフィルされた内容と合わない合計になってしまうため。 再計算されない ② 注文が編集できない状態 再計算は 注文編集（order editing）の仕組みを通じて 行われるため、 order editing と同じ制約がそのまま適用される 。 注文が編集の対象外である場合、住所は保存されるが税額は再計算されない。 どちらのケースでも 住所変更そのものは成功する 。「住所は新しい／税は古い」という組み合わせは今後も発生し得るので、部分フルフィル注文の宛先変更フローは業務側の運用ルールで補う必要がある。 4 変更前 vs 変更後の比較 項目 これまで 2026年8月31日以降 住所の保存 される される （常に成功） 税ライン（未フルフィル注文） 元のまま 変更されない 再計算 新しい宛先基準 合計金額の整合性 実際の配送先と 一致しない 配送先に対して 正確なまま維持 部分フルフィル注文 税ラインは変更されない 税ラインは変更されない（据え置き） 編集不可の注文 税ラインは変更されない 税ラインは変更されない（据え置き） orders/edited webhook 住所変更では発火しない前提の運用 発火あり 税再計算が起きたとき通知 アプリ側の対応 — 不要 導入のための変更は必要なし 5 適用範囲とタイミング 開始日 2026年8月31日 から適用。 対象 API バージョン すべての Admin GraphQL API バージョン に適用される。特定バージョンへ上げれば回避できる、という類の変更ではない。 webhook orders/edited の購読者は、 住所変更が税の再計算につながったとき に通知を受け取る。 6 実装側でやること（3ステップ） 1 orderUpdate で住所を更新 これまで通り。呼び出し方の変更は不要。 2 注文を query して読み直す taxLines / totalTaxSet / totals を再取得。他の order edit と同じ扱いでよい。 3 orders/edited を受ける側を確認 住所変更起因でも通知が来る。ハンドラが想定外の発火で壊れないか点検。 記事の記載としては 「この変更を採用するために必要な変更はありません」 。上の 2・3 は、新しい挙動に自システムを合わせるための確認作業という位置づけ。 7 技術者が押さえるべき5つのポイント 1. 住所は無条件、税は条件付き アドレス変更は 常に成功 し、条件が付くのは税の再計算のみ。mutation の成否だけを見ていると「税が直ったか」を取り違える。 再取得した値で判定する のが唯一確実な方法。 2. 全 API バージョンに一律適用 バージョン固定で挙動を維持する、という逃げ道が無い。 古い API version を指しているアプリも 8/31 から新挙動になる 。稼働中の全連携を棚卸しする必要がある。 3. orders/edited が新しい経路で飛ぶ これまで「注文編集操作」でしか来なかった通知が、 住所変更起因でも届く 。冪等性・重複処理・在庫や会計への副作用を持つハンドラは、発火頻度が増える前提で見直す。 4. 実体は order editing 経由 再計算は 注文編集の仕組みを通って走る 。したがって order editing の考慮事項がそのまま効く。編集不可の注文では住所だけ保存され、税は据え置きになる。 5. 部分フルフィルは「意図的に」再計算しない バグではなく設計。すでに元の宛先へ出荷済みのユニットに新しい宛先の税を当てると、 実際にフルフィルされた内容と合わない合計 になるため、あえて据え置く。 逆に言えば、宛先変更で税額まで正しく直したいなら 「フルフィル前に住所を確定させる」オペレーション設計 が前提になる。CS 側の対応フローに落とし込む価値がある。 8 業務に活かせる3つのユースケース USE CASE 1 CS の「発送前 住所変更」対応から、手動の税額調整をなくす 課題 顧客からの「引っ越したので送り先を変えて」に対し、住所は API / 管理画面で変えられるが税額が元のまま残り、返金・追加請求を手作業で調整していた。 打ち手 2026年8月31日以降、 完全に未フルフィルの注文 であれば orderUpdate の住所変更だけで税が新しい宛先基準に再計算される。CS 手順書から手動調整の工程を外す。 効果 問い合わせ 1 件あたりの対応工数削減と、金額ズレ起因の再問い合わせ・経理差異の減少。 技術メモ 更新後に注文を query して taxLines / totalTaxSet / totals を読み直し、CS 画面に「更新後の合計」を出す。他の order edit と同じ扱いでよい。 USE CASE 2 OMS / 基幹連携の「税が直らない前提」ロジックを棚卸しする 課題 自社 OMS や受注管理アプリが「住所を変えても税は変わらない」前提で、独自に税額を保持・再計算・上書きしている。8/31 以降は Shopify 側も再計算するため、 二重計算や値の食い違い が起きうる。 打ち手 住所更新を行う全経路を洗い出し、更新直後に Shopify 側の値を再取得して「自前計算値の上書き」を廃止 or 検証モードに切り替える。部分フルフィル注文だけは据え置きになる点も分岐に反映。 効果 財務データの正本を Shopify に一本化。差異調査の工数と、月次締めでの照合コストを削減できる。 技術メモ すべての Admin GraphQL API バージョンに適用 されるため、API version を固定していても影響を受ける。バージョン据え置き＝安全、という判断は成り立たない。 USE CASE 3 orders/edited webhook ハンドラの耐性チェックを 8/31 前に済ませる 課題 会計連携・帳票再発行・在庫引当・通知メールなどが orders/edited をトリガに動いている場合、住所変更起因の新しい発火で 想定外の再処理 が走る恐れがある。 打ち手 8月31日より前に、① 購読中ハンドラの一覧化 → ② 冪等性（同一注文への重複処理耐性）の確認 → ③ 住所変更のみのケースで副作用が許容できるかレビュー、の順で点検する。 効果 切替日以降の障害・二重発行・誤通知を事前に潰せる。既存顧客への「影響ありません」報告の根拠にもなる。 技術メモ 通知が来るのは 税の再計算が発生したとき 。部分フルフィル注文や編集不可の注文での住所変更は再計算が起きないため、この経路では発火しないと読める（記載は「再計算につながったとき通知」まで）。 9 提案で使える1行サマリ 「2026年8月31日から、 未フルフィル注文の配送先変更で税額も自動で正しくなる 。 アプリ側の対応は不要だが、 全 API バージョンに一律適用 ・ orders/edited が新しく飛ぶ ・ 部分フルフィルは据え置き の 3 点だけは事前に確認しておきたい。」 source ： shopify.dev / changelog / updating-an-orders-shipping-address-returns-accurate-financial-data published 2026-07-30 ／ generated 2026-07-30