Action Required / Admin GraphQL API

Market-driven shipping
配送設定が「配送プロファイル」から「Markets」へ引っ越す

マーチャントの配送設定が delivery profile API から Markets API へ移動。各マーケットに配送オプションを直接ひも付け、1 つのオプション内で商品・ロケーション条件ごとに料金を出し分ける新方式。feature preview は本日から利用可能。

このページの構成
  1. そもそも何が変わるのか(30秒で理解)
  2. 仕組み図解 : 配送設定はどこへ移るのか
  3. アプリへの影響(4つの変更点)
  4. 従来 vs Market-driven の比較
  5. 移行スケジュール(タイムライン)
  6. 今すぐやること(feature preview 3ステップ)
  7. 技術者が押さえるべき5つのポイント
  8. 業務に活かせる3つのユースケース
  9. 提案で使える1行サマリ

1そもそも何が変わるのか

今まで マーチャントの配送設定は「配送プロファイル(delivery profile)」 に置かれていた。
Market-driven shipping では、それが 「Markets(マーケット)」 に移動する。各マーケットに配送オプションを直接ひも付け、1 つのオプションの中で商品・ロケーション条件ごとに料金を出し分ける方式になる。

従来 : 配送プロファイルに集約

マーチャントの配送設定は delivery profile API 上で管理。料金のばらつきはプロファイルの構造で表現していた。

Market-driven : マーケットに直付け

配送オプションを各マーケットに直接ひも付け。1 オプション内で商品・ロケーション条件により料金を出し分け。チェックアウトの料金挙動が予測しやすくなる。

2仕組み図解 : 配送設定はどこへ移るのか

Delivery Profile API マーチャント配送設定 (今日の merchant delivery profiles) ここから引っ越す 移動 Markets API マーケット別 配送オプション 商品条件で料金を出し分け ロケーション条件で出し分け チェックアウトの配送料金 マーチャント料金(Markets 由来) アプリ提供料金(従来 API のまま並列表示) 両者が同じ画面に並ぶ App Delivery Profile は据え置き
ポイント : 動くのは「マーチャント側」だけ。
移動するのはマーチャント所有の配送設定のみ。アプリが作る配送プロファイル(app delivery profiles)は従来どおり delivery profile API を使い続ける。アプリ提供料金も、新しい体験の中でマーチャント料金と並んで表示される。

3アプリへの影響(4つの変更点)

要対応

1. マーチャント配送設定は Markets API へ

今日の merchant delivery profiles は delivery profile API から Markets API に移動する。マーチャント配送設定を 読み取り/作成/更新 しているアプリは更新が必要。

据え置き

2. App delivery profiles は従来 API のまま

アプリが作成する配送プロファイルは、これまでどおり delivery profile API を使い続ける。ここは変更なし。

据え置き

3. アプリ提供料金は並列表示を継続

app delivery profiles 内で定義された料金は、新体験でもマーチャント料金の隣に引き続き表示される。

強化

4. App delivery profiles がより強力に

一部の商品サブセットだけでなく 全商品を対象にできる ようになる。さらに、アプリのプロファイルへ商品を追加しても マーチャント設定に影響しなくなる

アクションが必要なのは、delivery profile API 経由でマーチャント配送設定を読み書きしているアプリ。 該当する場合はコードの更新が必須。

4従来 vs Market-driven の比較

項目従来Market-driven shipping
マーチャント配送設定の置き場 Delivery Profile 配送プロファイル Markets 各マーケットに直付け
使う API Delivery Profile API Markets API(マーチャント設定分)
料金の出し分け プロファイル構造で表現 1 オプション内 商品・ロケーション条件で分岐
App delivery profiles 対象は商品サブセットのみ/追加がマーチャント設定に波及 全商品を対象可/マーチャント設定に非影響
アプリ提供料金の表示 マーチャント料金と並列 並列表示を継続
チェックアウト料金の予測性 向上 挙動が理解しやすくなる

5移行スケジュール(タイムライン)

2026-07-01本日
feature preview 提供開始。 新しい開発ストアで feature preview を有効化し、既存インテグレーションと料金ロジックを今すぐ検証できる。
2026-10-01ロールアウト開始
Market-driven shipping が マーチャントへの展開を開始。順次オンになっていく。
2027-07-01完全移行
すべてのマーチャントが Market-driven shipping に移行完了 する予定。
ロールアウト開始(2026-10-01)まで 約 3 か月。対象アプリは preview 期間中に検証・改修を終えておくのが安全。

6今すぐやること(feature preview 3ステップ)

1

新しい開発ストアを作成

検証用に新規 development store を用意する。

2

feature preview を有効化

Market-driven shipping の feature preview を ON にする。

3

既存連携と料金ロジックを検証

現行インテグレーションと rate logic が新方式で正しく動くか確認。

詳しい仕組みとアップグレード方法は公式ドキュメント 「Market-driven shipping feature preview」 に記載。preview 環境で挙動を掴んでから本番改修に入るのが定石。

7技術者が押さえるべき5つのポイント

1. 「マーチャント設定」と「アプリ設定」で API が分岐

マーチャント配送設定は Markets API、app delivery profiles は従来の delivery profile API。自分のアプリがどちらを触っているかの棚卸しが最初の一歩。

2. 読み書きしていれば「要対応」

delivery profile API 経由でマーチャント配送設定を read / create / update しているアプリは更新必須。Action Required タグが付く理由はここ。

3. 期限は「開始」と「完了」の2点

2026-10-01 ロールアウト開始、2027-07-01 全マーチャント移行完了。10 月がバックストップと捉え、preview 期間中に検証を終える。

4. App profiles の非破壊化に注目

アプリプロファイルへの商品追加が マーチャント設定に波及しなくなる。従来この副作用を前提に組んでいたロジックがあれば見直しどき。

5. 全商品ターゲティングが解禁

app delivery profiles が 商品サブセットだけでなく全商品を対象にできるようになる。これまで対象を絞る前提で設計していた料金ロジックは、全商品対応を活かす形に再設計できる。まずは新規開発ストアの preview で実挙動を確認するのが確実。

8業務に活かせる3つのユースケース

API
USE CASE 1

配送系アプリ/連携の「API 移行影響アセスメント」

課題
自社アプリや導入済みの配送アプリが delivery profile API 経由でマーチャント配送設定を読み書きしており、そのまま放置すると 10 月以降に壊れるリスクがある。
打ち手
コードを棚卸しし「マーチャント設定を触る箇所(要 Markets API 移行)」と「app delivery profile を触る箇所(据え置き)」を分類。移行が必要な呼び出しを洗い出す。
効果
ロールアウト開始(2026-10-01)前に改修範囲と工数が確定し、後追い対応による障害を回避。
技術メモ
read/create/update のいずれかで merchant shipping settings を触っていれば対象。新規 development store の feature preview で回帰確認。
USE CASE 2

多国展開ストアの「マーケット別 送料設計」の作り直し

課題
複数マーケットに販売しており、配送プロファイル構造で無理やり料金を出し分けていてチェックアウトの送料挙動が読みにくい。
打ち手
各マーケットに配送オプションを直接ひも付け、1 オプション内で商品・ロケーション条件により料金を分岐させる Market-driven 方式へ設計移行。
効果
チェックアウトの料金挙動が予測しやすく・説明しやすくなり、送料まわりの問い合わせや設定ミスを削減。
技術メモ
preview で商品条件・ロケーション条件の分岐を実データで検証。既存の rate logic が新モデルで再現できるか確認する。
App
USE CASE 3

配送アプリの「全商品ターゲティング」対応で機能強化

課題
自社の配送アプリが従来は商品サブセットしか対象にできず、全商品への一律ルール適用に回避策を組んでいた。さらに商品追加がマーチャント設定に波及して事故が起きやすかった。
打ち手
強化された app delivery profiles を使い、全商品を対象にした料金ルールへ再実装。マーチャント設定への非影響を前提に安全に商品を追加。
効果
回避策の削除でコード簡素化、マーチャント設定を壊さない安心感、アプリの適用範囲拡大による訴求力向上。
技術メモ
app delivery profiles は delivery profile API のまま。全商品ターゲティングと非波及の挙動を preview で確認してから本番反映。

9提案で使える1行サマリ

「マーチャントの配送設定が 配送プロファイルから Markets へ引っ越し、各マーケットに配送オプションを直付けして商品・ロケーション条件で料金を出し分ける新方式。
delivery profile API でマーチャント設定を読み書きするアプリは要改修(app profile 側は据え置き+全商品対応で強化)。
feature preview は本日から。2026-10-01 ロールアウト開始・2027-07-01 全移行完了までに検証を。」