Admin GraphQL API ／ 2026-07

FulfillmentOrderLineItem に
shippingLine フィールド追加

フルフィルメント注文の行アイテムごとに「どの配送方法で送るか」を直接取得できるように。配送プロファイルをまたいで merge された複雑なケースでも、行単位で正しいキャリアサービスにマッピング可能。

このページの構成
  1. そもそも何が追加されたのか（30秒で理解）
  2. なぜ必要か ： 配送プロファイル merge 問題
  3. 取得できるプロパティ
  4. クエリ例（GraphQL）
  5. 技術者が押さえるべき5つのポイント
  6. 業務に活かせる3つのユースケース
  7. 提案で使える1行サマリ

1そもそも何が追加されたのか

Admin GraphQL API 2026-07 から、FulfillmentOrderLineItem.shippingLine フィールドが利用可能に。
フルフィルメント注文の 「行アイテム単位」 で、紐づく ShippingLine（配送方法）を取得できる。
?

従来 ： FO 単位の deliveryMethod のみ

フルフィルメント注文の「配送方法」しか取れず、行ごとに別の配送サービスが指定されていた場合に原本が分からなくなる。

新 ： 行アイテム単位で shippingLine

各 line item に shippingLine が付随し、行ごとの本来の配送サービス（code／title／source）が個別に取得できる。

2なぜ必要か ： 配送プロファイル merge 問題

Before（行ごとの shipping service が消える） 商品A（Profile X） Standard 配送 商品B（Profile Y） Express 配送 merge 統合された FulfillmentOrder deliveryMethod = ??? 行ごとの違いが消える どのキャリアに渡せばいい？ After（行ごとに shippingLine が保持される） Line A.shippingLine = Standard Line B.shippingLine = Express Line C.shippingLine = Pickup → 行単位で解決
配送プロファイル（Delivery Profile）とは ： 商品ごとに「どの配送方法／料金を出すか」を切り分ける仕組み。冷凍と常温、軽量と重量、ピックアップ商品と発送商品など、性質の違う商品群を別々の配送ルールで売るために使う。
これらが 同じ注文に混在して merge される と、FO 全体の deliveryMethod が代表値になってしまい、原本の per-line 情報が辿れなくなっていた。

3取得できるプロパティ

code

shippingLine.code

配送サービスの内部コード。キャリア側のサービスコードとマッピングする際の主キーとして使える。

title

shippingLine.title

配送方法の表示名。ピッキング指示書・出荷ラベル・倉庫オペ画面に表示する人間可読のラベル。

source

shippingLine.source

この配送方法の出所（キャリア・アプリ・手動入力など）。どのレートプロバイダー由来かを判定して分岐に使える。

※ 上記 3 つは公式記事に明示されているプロパティ。その他のフィールドは ShippingLine 型のリファレンスに準拠（記事内では未列挙）。

4クエリ例（GraphQL）

# Admin GraphQL API 2026-07 query getFulfillmentOrder($id: ID!) { fulfillmentOrder(id: $id) { id lineItems(first: 50) { nodes { id shippingLine { # ← 新フィールド code title source } } } } }
記事内に「if available」という記述があるため、shippingLine は null になり得る前提で実装すること。fallback として FO 全体の deliveryMethod を見るロジックは残しておく。

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

2026-07

1. API バージョン 2026-07 で利用可能

既存アプリで使うには Admin GraphQL のバージョンを 2026-07 以降に上げる必要がある。古いバージョンでは shippingLine フィールドそのものが解決されない。

2. 「行単位」が解決できる

FulfillmentOrder 全体の deliveryMethod ではなく、各 line item に紐づく shipping service を直接取れる。フルフィルメントロジックを 1 段細かい粒度で書ける。

P1 P2

3. delivery profile が混在した注文に効く

配送プロファイルをまたいで FO が merge されたケースで、原本の per-line shipping service を復元できるのが本機能の核心。複数倉庫・複数配送条件のストアほど恩恵が大きい。

null?

4. 「if available」＝ null 許容

必ず値が入る保証はない。null チェック必須。null だった場合の fallback として FulfillmentOrder.deliveryMethod を参照する分岐を残す設計が安全。

code title source

5. キャリアサービスマッピングの主キー候補

記事は code／title／source を「キャリアサービスへの正確なマッピング」用途に挙げている。OMS 側で配送サービスのテーブルを持っているなら、code を主キーに、title を画面表示用、source を経路判定に使うのが素直な分担。

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

USE CASE 1

OMS／3PL 連携で「行ごとに正しいキャリアサービスへ振り分ける」

課題
OMS や 3PL に渡すフルフィルメントデータで、行ごとに違う配送サービス（Standard／Express／Pickup 等）が必要なのに、FO 単位の deliveryMethod しか拾えず手動補正が発生。
打ち手
FulfillmentOrderLineItem.shippingLine.code を行ごとに取得し、3PL の配送サービスマスタにマッピングして API に渡す。
効果
誤配送・運賃ズレ・手戻りの削減。倉庫オペレーターが行ごとのラベルを正確に出せる。
技術メモ
code = 主キー、title = 倉庫ピッキング指示書、source = レートプロバイダー判定 の三分割が素直。
冷凍 Profile X 常温 Profile Y
USE CASE 2

複数 delivery profile を持つストア（冷凍/常温・大型/小物）の出荷自動化

課題
冷凍と常温、大型家具と小物アクセサリ等、配送プロファイルを分けて運用しているストアで、merge された注文の行ごとの配送サービスが追えず、出荷分割が手作業。
打ち手
フルフィルメントアプリ側で shippingLine を行単位で取り、同じ配送サービスの行をグループ化して出荷オーダーを分割生成。
効果
「冷凍便だけ別ラベル」「大型家具便だけ別倉庫」等の自動振り分けが実装ゼロに近い形で実現。
技術メモ
nullable 前提。null の行は FO 全体の deliveryMethod に fallback するブランチを必ず実装。
配送方法別 売上
USE CASE 3

配送方法 × 商品カテゴリ別の収益分析

課題
「Express を選んだ顧客は何を買っているか」「Pickup を選ぶ商品カテゴリの偏り」など、行レベルで配送方法を切った分析が出来なかった。
打ち手
FulfillmentOrderLineItem 単位で shippingLine.title と SKU／カテゴリを結合して BI に送る ETL を構築。
効果
配送 UX 改善の打ち手（Express の品目絞り込み・Pickup 拡大候補の特定など）が定量で語れるようになる。
技術メモ
GraphQL の lineItems 子集合を一括で取得。BigQuery / Snowflake 連携時は code を正規化キーに採用すると後続が楽。

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

「フルフィルメント注文の 行アイテム単位で配送サービス（code／title／source）が取得できる ようになった。
配送プロファイルをまたいで merge された注文でも、行ごとに正しいキャリアへ振り分けられる。
OMS／3PL 連携アプリ・複数 delivery profile 運用ストアの出荷自動化の精度を 1 段上げる API 拡張。」