2026年8月31日から、未フルフィルの注文で orderUpdate により配送先住所を変更すると、新しい配送先に対して税額が再計算される。これまでは住所だけ更新され、税ラインは元のまま残っていた。
orderUpdate GraphQL mutation で配送先住所を変更すると、
新しい配送先に対して注文の税額が再計算される。orderUpdate は新しい住所を保存するが、元の税ラインはそのまま。結果として注文の合計が、実際に発送する宛先と一致しなくなっていた。
住所更新の一部として注文の財務データが是正され、合計が配送先に対して正確な状態を保つ。導入のために必要な変更は無い。
taxLines / totalTaxSet / 各種 totals を読み直せばよい。特別な API も追加パラメータも登場しない。税の再計算は「安全に適用できるときだけ」実行される。記事で明示されているのは次の 2 ケース。
完全に未フルフィルの注文では税額が再計算される。部分フルフィルの注文では、住所は保存されるが税額は変更されない。
理由 ： 一部の商品はすでに元の宛先へ発送済みで、注文全体を新しい住所で再計算すると、そこへ発送されていない分にまで新しい宛先の税が適用され、実際にフルフィルされた内容と合わない合計になってしまうため。
再計算は注文編集（order editing）の仕組みを通じて行われるため、order editing と同じ制約がそのまま適用される。
注文が編集の対象外である場合、住所は保存されるが税額は再計算されない。
| 項目 | これまで | 2026年8月31日以降 |
|---|---|---|
| 住所の保存 | される | される（常に成功） |
| 税ライン（未フルフィル注文） | 元のまま 変更されない | 再計算 新しい宛先基準 |
| 合計金額の整合性 | 実際の配送先と一致しない | 配送先に対して正確なまま維持 |
| 部分フルフィル注文 | 税ラインは変更されない | 税ラインは変更されない（据え置き） |
| 編集不可の注文 | 税ラインは変更されない | 税ラインは変更されない（据え置き） |
| orders/edited webhook | 住所変更では発火しない前提の運用 | 発火あり 税再計算が起きたとき通知 |
| アプリ側の対応 | — | 不要 導入のための変更は必要なし |
2026年8月31日から適用。
すべての Admin GraphQL API バージョンに適用される。特定バージョンへ上げれば回避できる、という類の変更ではない。
orders/edited の購読者は、住所変更が税の再計算につながったときに通知を受け取る。
これまで通り。呼び出し方の変更は不要。
taxLines / totalTaxSet / totals を再取得。他の order edit と同じ扱いでよい。
住所変更起因でも通知が来る。ハンドラが想定外の発火で壊れないか点検。
アドレス変更は常に成功し、条件が付くのは税の再計算のみ。mutation の成否だけを見ていると「税が直ったか」を取り違える。再取得した値で判定するのが唯一確実な方法。
バージョン固定で挙動を維持する、という逃げ道が無い。古い API version を指しているアプリも 8/31 から新挙動になる。稼働中の全連携を棚卸しする必要がある。
これまで「注文編集操作」でしか来なかった通知が、住所変更起因でも届く。冪等性・重複処理・在庫や会計への副作用を持つハンドラは、発火頻度が増える前提で見直す。
再計算は注文編集の仕組みを通って走る。したがって order editing の考慮事項がそのまま効く。編集不可の注文では住所だけ保存され、税は据え置きになる。
バグではなく設計。すでに元の宛先へ出荷済みのユニットに新しい宛先の税を当てると、実際にフルフィルされた内容と合わない合計になるため、あえて据え置く。
逆に言えば、宛先変更で税額まで正しく直したいなら 「フルフィル前に住所を確定させる」オペレーション設計が前提になる。CS 側の対応フローに落とし込む価値がある。
orderUpdate の住所変更だけで税が新しい宛先基準に再計算される。CS 手順書から手動調整の工程を外す。taxLines / totalTaxSet / totals を読み直し、CS 画面に「更新後の合計」を出す。他の order edit と同じ扱いでよい。orders/edited をトリガに動いている場合、住所変更起因の新しい発火で想定外の再処理が走る恐れがある。