view_keyでカート行を特定できるようになったcartLines変更

8月 10, 2026

API CHANGE

view_keyでカート行を
直接操作できるようになった

cartLinesUpdate / cartLinesRemove が view_key 指定に対応。既存の id 系指定との後方互換も完全に維持。

2026年6月2日、Storefront APIのカート操作ミューテーション2種がview_keyによる行の特定に対応しました。これまでは内部的なidやlineIdsしか使えなかったカート行操作に、フロントエンドが扱いやすいview_keyを直接渡せるようになります。既存の実装は変更不要で、新しい識別子は既存の指定方法と排他的に選択して使います。

WHAT CHANGED

01変更内容の詳細

2つのミューテーションそれぞれに新しい識別子が追加されました。cartLinesUpdateはCartLineUpdateInputの各要素にviewKeyフィールドが追加され、cartLinesRemoveはトップレベルにviewKeysリストが追加されています。いずれも既存のid/lineIdsとは排他的で、同時に指定するとエラーになります。

USE CASES

02業務に活かせる具体ユースケース

課題: ヘッドレスストアのカート実装で、カート行の内部ID（GID）をフロントエンド状態管理に保持し続けるコストが高い
打ち手: view_keyはカート行を一意に表すフロントエンド寄りのキーのため、そのまま状態管理のキーとして利用しカート操作に直接渡せる
効果: GIDとview_keyのマッピングテーブルが不要になり、状態管理コードが簡素化。Stale IDによるエラーリスクも低減
技術メモ: view_keyはcartLinesAddレスポンスなどで取得可能。Storefront API経由でカートを取得する際に各行のview_keyも合わせて取得しておくこと

課題: マルチパネルUIやカスタムUIでチェックボックス選択した複数カート行を一括削除する際、GIDリストの管理が複雑になりやすい
打ち手: UIコンポーネントがview_keyをデータ属性として持ち、cartLinesRemoveのviewKeysリストにそのまま渡す実装に統一する
効果: コンポーネントとAPIの間のID変換層を排除でき、バグの温床になりやすいマッピング処理が減少する
技術メモ: viewKeysとlineIdsは排他的なので、1つのミューテーション呼び出しでどちらか一方のみを使うこと。混在させるとエラー

課題: Shopifyアプリ内でカートを操作する際、セッションをまたいで行IDが変わるケースがあり、削除・更新処理の信頼性が低い
打ち手: より安定した識別子であるview_keyを用いて操作することで、IDの再取得ロジックを削減できる可能性がある
効果: API呼び出し回数の削減と処理の安定化。特に自動化スクリプトやバッチ処理的なカート操作で有効
技術メモ: view_keyの安定性・ライフサイクルの仕様については公式ドキュメントを要確認。元記事には明示的な記載なし

DEVELOPER NOTES