チェックアウトおよび注文ページのURL形式更新ガイド
チェックアウトページおよび注文ステータスページのURL形式が更新されます。ストアID（storeId）セグメントがURLパスから削除され、チェックアウトおよび注文フローは他のストアフロントページとリソースを共有せず、独立したリソースパスを持つようになります。これにより、大規模なプロモーション時のトラフィック急増や他のストアフロントページで問題が発生した場合でも、チェックアウトへの影響が軽減されます。
SHOPLINEは2026年9月19日にすべてのストアのチェックアウトおよび注文ページのURLを完全に切り替えます。この日以降、URL形式は以前のバージョンに戻せなくなります。ほとんどのストアでは特に対応は不要ですが、カスタムコードアプリ、テーマテンプレート、アプリ、301リダイレクト、Open API、またはサードパーティシステムが旧URLパスを解析または依存している場合は、このガイドを参照して技術的な対応を行ってください。
| 重要：通常の顧客アクセス、チェックアウト、ページナビゲーションには影響ありません。旧形式のリンクは自動的に新しいURLにリダイレクトされるため、既に送信したリンクを手動で更新する必要はありません。 |
1. URL形式更新の主な特典
このチェックアウトリンクの更新により、チェックアウトおよび注文ページはより安定した専用のリソースパスを持ち、通常のストアフロントページのトラフィックや障害から分離されます。大規模なプロモーションによるトラフィック急増時や他のストアフロントページで問題が発生した場合でも、チェックアウトページは独自の信頼性を維持し、購入者がよりスムーズに支払いを完了できるようにし、注文の中断や紛失のリスクを減らします。同時に、過去のリンクは自動リダイレクトで引き続き機能するため、マーケティングメール、カートリカバリーメール、既に送信した注文リンクをすぐに再発行する必要はありません。
2. 形式更新の影響
この更新はすべてのストアのチェックアウトページおよび注文ステータスページのURLに適用されます。これまでURLの一部だったストアIDセグメントがパスから削除され、チェックアウトや注文照会に必要な情報のみが残ります。例えば、チェックアウトページのURLは以下のように変更されます：
変更前：
https://{store domain}/1234567890/checkouts/{checkoutToken}
└────┬────┘
storeId、この更新で削除されます変更後：
https://{store domain}/checkouts/{checkoutToken}対応が必要かどうかは、どのページに関わるかではなく、コードがこれらのURLをどのように使用しているかによります：
- 対応が必要：コードがこれらのページURLからコンテンツを解析している場合、例えばページタイプの判別、storeIdやcheckoutTokenの抽出など。この種のコードは変更後に誤った値を取得する可能性があります。
- 対応不要：プラットフォームから提供された完全なリンクをそのまま受け取り直接リダイレクトしているだけで、リンクから何も解析していない場合。このケースは影響を受けません。
カスタムコード、テーマ、アプリ、301リダイレクト、またはサードパーティの統合が旧URLパスを解析または依存している場合は、適応が必要です。詳細は「4. 適応が必要なシナリオ」をご覧ください。カテゴリ別の詳細な内訳があります。
3. フルパス比較
以下の表は各ページの変更前後のパス形式を示しています。「今回変更なし」とマークされた行を除き、すべての行が今回変更されます。
| ページ | 変更前 | 変更後 |
| チェックアウトページ（チェックアウトページ自体を含む） | |
|
| チェックアウトページ（サンキューページ） | |
|
| 注文ステータスページ | |
|
| 処理中ページ | |
|
| 在庫問題ページ | |
|
| レート制限ページ | |
|
| エラーページ（チェックアウト） | |
|
| エラーページ（注文） | |
|
| サブスクリプション再バインドページ | |
storeIDを含まず、変更なし |
storeIdが必要な場合の取得方法：
- ストアのカスタムコード: プラットフォームによって注入されるグローバルオブジェクトから読み取ります。例えば window.Shopline.storeId（「公式ガイド」を参照）。
- Open Platformアプリ: アプリのインストールコンテキストまたはAPIレスポンスからstoreIdフィールドを取得します。詳細は「Open Platformドキュメント」の該当エンドポイントを参照してください。
| 注： この変更後、storeIdセグメントはページのURLから削除されます。URLからstoreIdを解析しないでください。 |
4. 適応が必要なシナリオ
まず、ご自身のコードがどのカテゴリに該当するかを特定してください — Open Platformアプリか、ストアのカスタムコードか？その後、以下の対応表と照らし合わせて確認してください。
4.1. Open Platformアプリ
| シナリオ | 影響あり？ | 対応方法 |
| 現在のページがチェックアウトページ／注文状況ページかどうかをページURLから判定する | 影響あり | 旧フォーマットと新フォーマットの両方に対応したマッチに切り替える（「4.4 コード例：例1」を参照） |
| ページURLからstoreIdを抽出する | 影響あり | URLから解析せず、アプリのコンテキスト／APIレスポンスから取得する（「4.4 コード例：例2」を参照） |
| ページURLからcheckoutToken／orderSeqを抽出する | 影響あり | URLから抽出しない。Open Platform APIを通じて識別子を取得してください。対応していないシナリオはOpen Platformのチケットを提出してください。 |
| WebhookやAPIで返されるcheckout_urlなどのURLフィールドを解析して値を抽出する | 影響あり | このフィールドはリダイレクト用です。値を解析しないでください。storeIdやorderSeqのようなフィールドはOpen Platformドキュメントの該当エンドポイントを確認し、対応していないシナリオはチケットを提出してください。 |
| チェックアウト／注文ページのリンクを手動で構築する | 影響あり | Open Platform APIが返す完全なURLを使用し、自分でパスを構築しないでください（「4.4 コード例：例3」を参照） |
| プラットフォームから完全なリンクを受け取り、それをリダイレクト／表示するだけ | 影響なし | 対応不要 |
| プラットフォームのOpenAPIエンドポイント（/api/...）を呼び出す | 影響なし | APIパスはこの変更の対象外です |
4.2. ストアのカスタムコード（カスタムJS／HTML）
| シナリオ | 影響あり？ | 対応方法 |
| location.pathname を使ってページタイプを判別し、スクリプトを実行するか決定する場合 | 影響あり | 「4.4 コード例：例1」を参照してください |
| location.pathname からインデックスでセグメントを取得する（例：split('/')[1] を storeId として扱う）場合 | 影響あり | 「4.4 コード例：例2」を参照してください。このパターンは変更後に見落とされやすく、取得される値がエラーを出さずに「checkouts」になります |
| パスベースの正規表現でページをグループ化する分析／追跡スクリプト | 影響あり | 「4.4 コード例：例1」を参照してください。また、サードパーティ分析ダッシュボード（例：GA）のページグループ化ルールも確認してください |
| パスに依存するリダイレクトロジックやA/B分割ルール | 影響あり | 「4.4 コード例：例1」を参照してください |
| 純粋なスタイリングのカスタムCSS | 一般的に影響なし | URLベースの条件付き読み込みを使用している場合は、上記のように対応してください |
4.3. 301リダイレクト設定
パス：管理画面 > 設定 > ドメイン > 301リダイレクト
| シナリオ | 影響あり？ | 対応方法 |
| 「リダイレクト元」に /:storeId/checkouts が含まれる場合 | 影響あり | 新しい形式に合うルールを追加してください（「4.4 コード例：例4」を参照） |
| 「リダイレクト先」に /:storeId/checkouts が含まれる場合 | 影響あり | 新しい形式に合うルールを追加してください（「4.4 コード例：例4」を参照） |
4.4. コード例
例 1: ページタイプの判定
誤り:
// 変更後に壊れる: 正規表現が先頭の数字セグメントをハードコードしている
if (/^\/\d+\/checkouts\//.test(location.pathname)) { /* ... */ }
if (location.pathname.split('/')[2] === 'checkouts') { /* ... */ }推奨:
// 古い形式と新しい形式の両方に対応: 先行するものに関係なく "checkouts" セグメント自体のみをチェック
const isCheckoutPage = /(^|\/)checkouts\/[^/]+/.test(location.pathname);
const isOrderPage = /(^|\/)orders\/[^/]+/.test(location.pathname);例 2: storeId の取得
誤り:
// 変更後、"checkouts" を取得してしまう — エラーは発生しないが値が誤っている
const storeId = location.pathname.split('/')[1];推奨:
// プラットフォームから注入されるコンテキストから取得（正確なフィールドは実行時に依存）
const storeId = window.Shopline?.storeId;
// Open Platform アプリ: アプリインストールコンテキスト / APIレスポンスの storeId フィールドを使用例 3: リンクの生成
誤り:
// パスを手動で構築（手動構築はもうどの方法も動作しない）
const url = `https://${domain}/${storeId}/checkouts/${token}`;推奨:
// Open Platform API が返す完全な URL を使用し、直接リダイレクトする
const url = response.checkoutUrl;プラットフォームが返すリンクは常にそのストアで現在有効な形式を反映しているため、切り替え状態を自分で判定する必要はありません。現在の API がカバーしていないシナリオのリンクを生成する必要がある場合は、Open Platform のドキュメントを確認するか、Open Platform チケットを提出してください。
| 注： checkoutToken、orderSeq、storeId のような識別子を URL から解析しないでください。代わりに Open Platform が提供するエンドポイントを使用してください。 |
例 4: 301 リダイレクト設定
元の設定:
// 元の「リダイレクト元」または「リダイレクト先」設定
/example storeId/checkouts追加すべき新しい設定:
// 新しい形式に対応する設定を追加
/checkouts
5. セルフチェックチェックリスト
以下の3つのステップに従い、コードベースを検索して各項目を確認してください。すべての項目が確認されて初めてセルフチェックは完了となります。
ステップ 1: キーワード検索
checkouts orders thank_you stock_problems
processing overload checkoutToken orderSeq storeId
ステップ 2: パターン検索（正規表現）
\/\d+\/checkouts # ハードコードされた数値セグメント + チェックアウト
\/\d+\/orders # ハードコードされた数値セグメント + 注文
:storeId\/checkouts # ルートテンプレート構文
\{storeId\}\/checkouts # テンプレート文字列構文
%s\/checkouts # バックエンドのフォーマット文字列構文
pathname.*split # インデックスでパスセグメントを取得
pathname.*match # パスの正規表現マッチング
location\.pathname # pathnameのあらゆる使用
ステップ3: 各項目の確認
- すべてのページタイプのチェックは、旧フォーマットと新フォーマットの両方をサポートするように更新されました
- storeIdはURLパスから解析されなくなりました
- checkoutToken / orderSeqはURLパスから抽出されなくなりました
- checkout_url フィールドはリダイレクトのみに使用され、値の解析は行われなくなりました
- チェックアウト/注文ページのパスは手動で構築されなくなり、Open Platform APIからの完全なURLが代わりに使用されます
- サードパーティの分析ダッシュボード（例：GA）におけるページグルーピングおよびコンバージョンゴールのパスルールが更新されました
6. よくある質問
Q1: 旧リンクは使えなくなりますか？
いいえ。旧フォーマットのリンクは自動的に新しいURLにリダイレクトされ続け、長期的にアクセス可能です。すでに送信したリンクを手動で置き換える必要はなく、過去のデータ移行も不要です。
Q2: 顧客はこのアップデートに気づきますか？
いいえ。通常の顧客のアクセス、チェックアウト、ページナビゲーションには影響がなく、このアップデートはURLの技術的構造のみを変更します。
Q3: 期限までに適応を完了しなかったらどうなりますか？
2026年9月19日以降、URLフォーマットは完全に新フォーマットに切り替わり、SHOPLINEは元に戻せません。カスタムコード、アプリ、またはサードパーティシステムが旧URLフォーマットに依存してデータを解析している場合、データ処理や機能に問題が発生する可能性があり、これらは多くの場合エラーや空白ページなしに静かに失敗します。統合を確認し、できるだけ早く適応を完了することを推奨します。
Q4: ロールアウト中に両方のフォーマットが同時に存在しますか？
はい。ストアはバッチで切り替わるため、異なるストアが異なる時期に異なるフォーマットを使用することがあります。適応は両方のフォーマットを同時にサポートするように構築し、どちらか一方のチェックとして扱わないでください。
Q5: APIから取得したリンクがストアの現在の切り替え状態と一致しない場合は？
そのまま使用してください。プラットフォームから返されるリンクは常にそのストアで現在有効なページを指しています。フォーマットが切り替え状態と不一致に見えても、プラットフォームが自動的にリダイレクトを処理するため、404は発生しません。
Q6: storeId、checkoutToken、またはorderSeqが必要ですが、URLから取得できません。どうすればいいですか？
該当するエンドポイントのOpen Platformドキュメントを確認してください。カバーされていないシナリオについては、Open Platformのチケットを提出してください。
Q7: OpenAPIのエンドポイントパスは変更されますか？
いいえ。このアップデートは購入者向けページのリンクのみを変更し、APIパスには影響しません。
Q8: APIレスポンスのcheckoutUrlフィールドは変更されますか？
はい。storeIdを含む状態から含まない状態に変更されます。
Q9: サブスクリプションの再バインドページは変更されますか？
いいえ。そのページのパスには元々storeIdは含まれていません。
7. サポートが必要ですか？
影響を受けることを確認したが、適応中に現在のAPIで対応していないシナリオに遭遇した場合や、判断基準についてまだ質問がある場合は、Open Platformのチケットを提出するか、SHOPLINEのSHOPLINE担当者に連絡してサポートを受けてください。
この記事はAIを使用して翻訳されており、不正確な箇所が含まれている可能性があります。最も正確な情報については、元の英語版をご参照ください。