FulfillmentOrderLineItem に shippingLine フィールド追加

図解 ： FulfillmentOrderLineItem に shippingLine フィールドが追加 Admin GraphQL API ／ 2026-07 FulfillmentOrderLineItem に shippingLine フィールド追加 フルフィルメント注文の行アイテムごとに「どの配送方法で送るか」を直接取得できるように。配送プロファイルをまたいで merge された複雑なケースでも、行単位で正しいキャリアサービスにマッピング可能。 このページの構成 そもそも何が追加されたのか（30秒で理解） なぜ必要か ： 配送プロファイル merge 問題 取得できるプロパティ クエリ例（GraphQL） 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が追加されたのか Admin GraphQL API 2026-07 から、 FulfillmentOrderLineItem.shippingLine フィールドが利用可能に。 フルフィルメント注文の 「行アイテム単位」 で、紐づく ShippingLine （配送方法）を取得できる。 従来 ： FO 単位の deliveryMethod のみ フルフィルメント注文の「配送方法」しか取れず、行ごとに別の配送サービスが指定されていた場合に原本が分からなくなる。 新 ： 行アイテム単位で shippingLine 各 line item に shippingLine が付随し、行ごとの本来の配送サービス（code／title／source）が個別に取得できる。 2 なぜ必要か ： 配送プロファイル merge 問題 配送プロファイル（Delivery Profile） とは ： 商品ごとに「どの配送方法／料金を出すか」を切り分ける仕組み。冷凍と常温、軽量と重量、ピックアップ商品と発送商品など、性質の違う商品群を別々の配送ルールで売るために使う。 これらが 同じ注文に混在して merge される と、FO 全体の deliveryMethod が代表値になってしまい、原本の per-line 情報が辿れなくなっていた。 3 取得できるプロパティ shippingLine.code 配送サービスの内部コード。キャリア側のサービスコードとマッピングする際の主キーとして使える。 shippingLine.title 配送方法の表示名。ピッキング指示書・出荷ラベル・倉庫オペ画面に表示する人間可読のラベル。 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つのポイント 1. API バージョン 2026-07 で利用可能 既存アプリで使うには Admin GraphQL のバージョンを 2026-07 以降に上げる必要がある。古いバージョンでは shippingLine フィールドそのものが解決されない。 2. 「行単位」が解決できる FulfillmentOrder 全体の deliveryMethod ではなく、各 line item に紐づく shipping service を直接取れる。フルフィルメントロジックを 1 段細かい粒度で書ける。 3. delivery profile が混在した注文に効く 配送プロファイルをまたいで FO が merge されたケースで、原本の per-line shipping service を復元できるのが本機能の核心。複数倉庫・複数配送条件のストアほど恩恵が大きい。 4. 「if available」＝ null 許容 必ず値が入る保証はない。null チェック必須。null だった場合の fallback として FulfillmentOrder.deliveryMethod を参照する分岐を残す設計が安全。 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 = レートプロバイダー判定 の三分割が素直。 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 拡張。 」 source ： shopify.dev / changelog / shipping-line-field-now-available-on-fulfillmentorderlineitem generated 2026-05-23