支払い方法なしでも サブスクリプション契約を作成できるように

図解 ： 支払い方法なしでサブスクリプション契約を作成できる（API 2026-04） Admin GraphQL API / 2026-04 支払い方法なしでも サブスクリプション契約を作成できるように API 2026-04 リリース候補（RC）から、契約作成ミューテーションの paymentMethodId が必須でなくなった。支払い方法が無い／失効していても契約データを移行できる。 このページの構成 そもそも何が変わるのか（30秒で理解） 仕組み図解 ： 契約移行の流れ 対象になるミューテーション 従来 vs 2026-04 の比較 利用条件・注意点 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が変わるのか これまでサブスクリプション契約を API で作るには、 有効な支払い方法（ paymentMethodId ）が必須 だった。 2026-04 のリリース候補（RC）からは その項目が必須でなくなり 、支払い方法が「無い」「失効している」契約データもそのまま作成・移行できるようになる。 従来 ： 支払い方法が無いと作れない paymentMethodId が必須項目。カードが失効・欠落している契約は API では作成できず、移行が止まっていた。 2026-04 ： 支払い方法なしでも作れる paymentMethodId は任意に。支払い方法が欠落・失効していても契約を作成でき、移行を完了させられる。 2 仕組み図解 ： 契約移行の流れ この変更の狙いは 「支払い方法の有無で移行が詰まる」状態の解消 。支払い方法が欠落・失効していても、まず契約という器を作れるようにする、という一点に絞られている。 作成後にどう支払い方法を再アタッチするか・課金が走る条件はどうなるか は本記事には記載なし。実装時は下部の docs（サブスクリプション契約の構築方法）で確認すること。 3 対象になるミューテーション 今回 paymentMethodId が必須でなくなったのは、以下の 2 つの契約作成ミューテーション。 対象 subscriptionContractCreate サブスクリプション契約を作成する標準のミューテーション。支払い方法 ID の指定が任意になった。 対象 subscriptionContractAtomicCreate 契約とライン等をまとめて一括（アトミック）に作成するミューテーション。こちらも支払い方法 ID が任意に。 上記 2 つ以外のミューテーション（契約の更新系・支払い方法の差し替え系など）への影響は本記事に記載なし。 4 従来 vs 2026-04 の比較 項目 従来 API 2026-04（RC） paymentMethodId 必須 指定しないと契約を作れない 任意 省略しても契約を作成できる 支払い方法が失効/不在の契約 作成不可 作成可能 移行ユースケース 有効なカードが揃わないと移行が止まる そのまま契約データを移行できる 対象ミューテーション — subscriptionContractCreate / subscriptionContractAtomicCreate 適用バージョン — API 2026-04 リリース候補（RC） 5 利用条件・注意点 API バージョン 2026-04（RC） この挙動はリリース候補（release candidate）版で提供。リクエストで 2026-04 を指定する必要がある。正式 GA 時期・以前バージョンへの反映は記載なし。 課金・与信への影響は記載なし 支払い方法が無い契約で次回課金がどう扱われるか、いつ支払い方法を求められるかは本記事に記述なし。実運用前に docs と挙動検証が必要。 6 技術者が押さえるべき5つのポイント 1. 変わったのは必須/任意だけ paymentMethodId が required から optional になった、という入力スキーマ上の変更。新しいフィールドや別ミューテーションが増えたわけではない。 2. 主目的は「移行」 記事が明示する用途は、支払い方法が欠落・失効した契約のマイグレーション。新規の通常契約フローを変えるための機能ではない。 3. 対象は 2 ミューテーション subscriptionContractCreate と subscriptionContractAtomicCreate の両方。アトミック作成を使う一括移行スクリプトでも効く。 4. RC 版である点に注意 2026-04 はリリース候補。本番採用前に仕様変更リスクを織り込み、リクエストの API バージョン指定を 2026-04 に固定する。 5. 「契約作成後」の支払い方法ハンドリングは別途設計 支払い方法なしで作った契約に、いつ・どうやって支払い方法を紐づけ直すか、その間の課金挙動はどうなるかは本記事に 記載なし 。再アタッチ手順・課金再開フローは docs（サブスクリプション契約の構築方法）と実機検証で詰めること。 7 業務に活かせる3つのユースケース USE CASE 1 外部サブスク基盤 → Shopify ネイティブ契約への一括移行 課題 旧サブスクアプリや外部基盤から移行する際、一部顧客のカードが失効・欠落しており、従来は支払い方法必須で契約を作れず移行が止まっていた。 打ち手 API 2026-04 で subscriptionContractAtomicCreate を使い、 paymentMethodId を省略して契約データだけ先に移行。 効果 支払い方法の有無に関係なく契約を移行でき、顧客・周期・商品情報を Shopify 側に揃えられる。 技術メモ 支払い方法の再登録手順は記事に記載なし。移行後の再アタッチ／課金再開フローは別途設計が必要。 USE CASE 2 失効カードを抱えた既存契約の「データ救済」 課題 カードの有効期限切れで決済が止まった契約が、移行・再構築の対象から漏れて塩漬けになっていた。 打ち手 支払い方法を省いた契約作成で、失効カードの契約もまず Shopify 上に再現。後続で顧客にカード再登録を促す導線を設計。 効果 休眠していた契約を取りこぼさず台帳に載せられ、復活（再課金）に向けたフォローの母集団を確保できる。 技術メモ 支払い方法なし契約での課金挙動は記載なし。再登録後にどう課金が再開するかは要検証。 USE CASE 3 「契約先行・支払いは後で」の段階的オンボーディング設計 課題 移行や登録のフローで「支払い方法が揃うまで契約を作れない」制約が、移行プロジェクトの全体スケジュールのボトルネックになっていた。 打ち手 先に契約だけを作成して台帳を確定させ、支払い方法の収集はキャンペーン／顧客フォローのフェーズに分離。 効果 移行作業と決済情報収集を分離でき、データ移行を先行完了させてプロジェクトを前に進められる。 技術メモ 後工程の支払い方法アタッチ手順は記事に記載なし。docs（サブスクリプション契約の構築方法）を参照のうえ設計する。 8 提案で使える1行サマリ 「API 2026-04 から、契約作成ミューテーションの 支払い方法 ID が任意化 。 支払い方法が失効・不在でもサブスク契約を移行できる ようになり、移行プロジェクトの最大級のボトルネックが外れる。」 source ： shopify.dev / changelog / create-subscriptions-contracts-without-payment-methods generated 2026-04-01