customerPaymentMethodRemoteCreate で 「支払い方法の識別子」が必須項目に

File writes aren't being approved, so I'll deliver the generated HTML here for you to save (the target path per the ingest slug convention is `site/public/raw/260401_payment-method-identifier-now-required-for-customerpaymentmethodremotecreate.html`). ```html 図解 ： customerPaymentMethodRemoteCreate で支払い方法の識別子が必須に（2026-07） Admin GraphQL API 2026-07 customerPaymentMethodRemoteCreate で 「支払い方法の識別子」が必須項目に API バージョン 2026-07 から、Stripe・Authorize.net・Braintree の入力で支払い方法の識別子フィールドが必須になる。スキーマ上は任意だったが、実際の決済処理には元々必要だった項目。スキーマを実態に合わせる変更。 このページの構成 30秒で理解 ： 何が変わるのか 影響を受ける3つのフィールド（ゲートウェイ別） 仕組み図解 ： なぜ「必須化」なのか 自分の対応が必要か判定する 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 30秒で理解 ： 何が変わるのか API バージョン 2026-07 以降、 customerPaymentMethodRemoteCreate ミューテーションを Stripe / Authorize.net / Braintree の入力で使うとき、 支払い方法の識別子フィールドが必須 になる。 これらは従来スキーマ上は任意だったが、決済処理には元々必要な値。スキーマを実態に合わせる変更。 これまで ： スキーマ上は任意 識別子を渡さなくても スキーマ検証は通った 。しかしその支払い方法は決済処理に使えず、機能しない状態で作成されていた。 これから ： スキーマ上も必須 識別子が無いとミューテーションが 検証段階で弾かれる 。「機能しない支払い方法が黙って作られる」状況を、最初から防げる。 2 影響を受ける3つのフィールド（ゲートウェイ別） 必須化されるのは、ゲートウェイごとに次の3フィールド。自分が連携しているゲートウェイの行だけ確認すればよい。 ゲートウェイ 入力タイプ（Input） 必須になるフィールド Stripe RemoteStripePaymentMethodInput paymentMethodId 必須 Authorize.net RemoteAuthorizeNetCustomerPaymentProfileInput customerPaymentProfileId 必須 Braintree RemoteBraintreePaymentMethodInput paymentMethodToken 必須 paymentMethodId Stripe 側の支払い方法 ID customerPaymentProfileId 顧客の支払いプロファイル ID paymentMethodToken Braintree の支払い方法トークン 3 仕組み図解 ： なぜ「必須化」なのか 「スキーマでは任意」だが「実行時には必須」というズレが、これまで存在していた。今回の変更はそのズレを解消する。 つまりこの変更は 新しい制約の追加ではなく、もともとあった実行時の要件をスキーマに明文化したもの 。Shopify の説明も「API スキーマを既存のランタイム要件に合わせる」変更だとしている。 4 自分の対応が必要か判定する 対応不要 すでに識別子を渡している 現状 customerPaymentMethodRemoteCreate 呼び出し時に該当の識別子フィールドを渡しているなら、 変更は不要 。そのまま 2026-07 に上げてよい。 要対応 識別子を渡していない 2026-07 を採用する前に 、自分のゲートウェイに対応する識別子を入力に含めるよう連携を更新する。更新せずに 2026-07 へ上げると、ミューテーションが弾かれる。 影響範囲は customerPaymentMethodRemoteCreate を Stripe / Authorize.net / Braintree のリモート入力 で使っている連携のみ。それ以外の作成経路への影響や、過去に識別子なしで作成済みの支払い方法の扱いについては、本記事に 記載なし 。 5 技術者が押さえるべき5つのポイント 1. トリガーは API バージョン 2026-07 必須化が効くのは 2026-07 以降を指定したリクエスト 。それより前のバージョンを使っている間は従来どおり（スキーマ上は任意）。アップグレードのタイミングが分岐点。 2. 対象は3ゲートウェイの3フィールドだけ Stripe の paymentMethodId 、Authorize.net の customerPaymentProfileId 、Braintree の paymentMethodToken 。自分が使うゲートウェイの値だけ確認すればよい。 3. 「任意 → 必須」のスキーマ変更 スキーマ定義上 optional だったフィールドが non-null（required）に変わる。コード生成や型チェックを使っている場合、生成物の更新で コンパイル段階で抜け漏れを検出 できる。 4. 未対応のまま上げると検証エラー 識別子を渡していない連携が 2026-07 に上がると、ミューテーションが弾かれる。 バージョン採用前に テスト環境で必須フィールドが入っているか確認するのが安全。 5. 機能しない支払い方法を「作る前に」防げる これまでは識別子なしでも作成自体は成功し、 決済処理の段になって初めて使えないと分かる 遅延した失敗だった。必須化により、作成リクエストの時点で失敗するため、ユーザーがチェックアウトで詰まる前に問題に気づける。データ品質と障害の早期発見の両面でメリットがある。 6 業務に活かせる3つのユースケース USE CASE 1 2026-07 アップグレード前の事前点検チェックリスト化 課題 定期的な API バージョンアップで、どの連携が壊れるか把握できておらず、上げてから障害に気づく。 打ち手 customerPaymentMethodRemoteCreate の呼び出し箇所を洗い出し、Stripe/Authorize.net/Braintree それぞれで識別子を渡しているかを点検項目に追加。テスト環境を 2026-07 に上げて検証する。 効果 本番アップグレード前に要対応箇所を特定。チェックアウトで顧客が決済できない事態を未然に防ぐ。 技術メモ 対象は3フィールドのみ（ paymentMethodId / customerPaymentProfileId / paymentMethodToken ）。grep で呼び出しを機械的に拾える。 USE CASE 2 「黙って失敗していた」連携バグの掘り起こし 課題 リモート作成した支払い方法が一部で決済に使えず、原因が特定できないまま放置されていた。 打ち手 今回の必須化が示すとおり「識別子なしで作成 ＝ 機能しない」が確定情報になったため、過去の連携実装で識別子を渡し漏れていないかを調査の起点にする。 効果 これまで原因不明だった決済不能の一因を切り分けられる。実装を是正すれば再発を防止。 技術メモ 過去に識別子なしで作成済みの方法の挙動・是正方法は記事に記載なし。実データでの挙動は別途検証が必要。 USE CASE 3 型生成 ＋ CI でバージョン差分を自動検知する基盤づくり 課題 Shopify の API バージョン更新のたびに、必須化などの破壊的変更を手作業で追っていて漏れる。 打ち手 スキーマからの型生成を 2026-07 に固定し、required になったフィールド（今回の3つ等）を型エラーとして CI で検出する仕組みに組み込む。 効果 「optional → required」系の変更を人手のレビューに頼らず機械的に検出。今後の同種変更にも横展開できる。 技術メモ 本記事は管理画面手順ではなくスキーマ定義の変更。型生成・lint のパイプラインに乗せやすい性質の変更。 7 提案で使える1行サマリ 「API 2026-07 から customerPaymentMethodRemoteCreate の支払い方法識別子が必須に。 Stripe / Authorize.net / Braintree の3フィールドだけの話で、すでに渡していれば対応不要。 実態に合わせたスキーマ明文化なので、未対応の連携をバージョンアップ前に点検しておけばよい。」 source ： shopify.dev/changelog/payment-method-identifier-now-required-for-customerPaymentMethodRemoteCreate published 2026-04-01 ``` 保存先（ingest のスラッグ規則に一致）: `site/public/raw/260401_payment-method-identifier-now-required-for-customerpaymentmethodremotecreate.html` ファイル書き込みの許可が下りなかったため内容をここに出しました。私が直接ファイルを作成してよければ許可してください。記事に明記のない範囲（過去に識別子なしで作成済みの支払い方法の扱い・他の作成経路への影響）は「記載なし」と明示し、推測は入れていません。