期限なしオフライントークンは終了へ 2027年1月1日までに「有効期限付き」へ移行

図解 ： 2027年1月1日までに「有効期限付きオフラインアクセストークン」へ移行を Developer Changelog / 認証・必須対応 期限なしオフライントークンは終了へ 2027年1月1日までに「有効期限付き」へ移行 期限なしのオフラインアクセストークンを使い続ける公開アプリは、App Store から非掲載になり新規インストールもできなくなる。新しく加わった「client credentials access」で、バックエンドだけでアクセスを取り戻せるようになった。 このページの構成 そもそも何が変わるのか（30秒で理解） ペナルティのタイムライン（段階的に厳しくなる） 新機能 ： client credentials access の仕組み 対象になるアプリ／ならないアプリ 期限なし vs 期限付き の比較 移行ガイドの3ステップ 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 そもそも何が変わるのか 期限なし のオフラインアクセストークンを使い続ける公開アプリは、 2027年1月1日まで に 有効期限付き のオフラインアクセストークンへ移行しないと、 Shopify App Store への掲載と新規インストールの受付を続けられなくなる。 これまで ： 期限なしトークン 一度発行されたオフラインアクセストークンが、期限なしで使い続けられる。 これから ： 期限付きトークン 有効期限付きのオフラインアクセストークンを使う。さらに client credentials access で、バックエンドが短命なアクセストークンを新しく取り直せる。 2 ペナルティのタイムライン 1月1日で即停止ではない が、新規獲得はそこで止まる。既存インストールが動くのは 4月1日まで 。その後は対象の Admin API リクエストが 403 になる。 3 新機能 ： client credentials access の仕組み client credentials access ： マーチャントがアプリを開き直すのを待たずに、バックエンドがアクセスを取り戻すための仕組み。 アプリの秘密鍵で署名したリクエスト を使い、 refresh token なしで 新しい短命アクセストークンを取得できる。 トークンの具体的な有効期間、署名方式、エンドポイント仕様は記事に記載なし（移行ガイド側を参照）。 4 対象になるアプリ／ならないアプリ 今回のスケジュール対象 既存の公開アプリ もともと 2027年1月1日の期限の対象だった既存の公開アプリに、今回の段階的スケジュールを適用。 引き続き有効 2026年4月1日以降に作成された公開アプリ この層に対する要件は変わらず有効のまま。 対象外 カスタムアプリ／マーチャント作成アプリ カスタムアプリと、マーチャントが作成したアプリは対象外。 5 期限なし vs 期限付き の比較 項目 期限なしオフライントークン（未移行） 期限付きオフライントークン（移行後） App Store 掲載 1/1 から非掲載 掲載を継続 新規インストール 1/1 からブロック 受付を継続 マーチャント管理画面 1/15 から警告表示 記載なし（警告の対象は未対応アプリのみ） 対象の Admin API リクエスト 4/1 から HTTP 403 継続して利用可 アクセスの回復 — client credentials access 秘密鍵で署名したリクエストで再取得 6 移行ガイドの3ステップ 1 トークン取得処理を更新 期限付きオフラインアクセストークンを取得するように、取得処理を書き換える。 2 既存インストールを移行 すでにインストールされているストアの分も移行する。 3 保存とリフレッシュ処理を検証 トークンの保存方法と、リフレッシュの扱いが正しく動くかを確認する。 具体的な API 名・パラメータ・コード例は記事本文に記載なし。 Shopify の移行ガイド を見ながら進める。 7 技術者が押さえるべき5つのポイント 1. 実質の締め切りは1月1日 API が止まるのは 4/1 でも、App Store 非掲載と新規インストール停止は 1/1 から。新規獲得が止まるので、 4/1 ではなく 1/1 を締め切りとして計画 を立てる。 2. 4月1日以降は 403 が返る 期限なしトークンを使った対象の Admin API リクエストが HTTP 403 になる。どのエンドポイントが「対象」かの細かい範囲は記事に記載なし。 3. 秘密鍵の管理が新しい要件になる client credentials access は アプリの秘密鍵で署名したリクエスト を使う。バックエンドで秘密鍵を安全に保管する設計が要る。 4. refresh token が無くても回復できる マーチャントがアプリを開き直すのを待たずに、バックエンドだけで新しい短命トークンを取得できる。 リフレッシュ失敗時の復旧ルート として使える。 5. 対象はアプリ種別で決まる 今回の段階的スケジュールが適用されるのは 既存の公開アプリ 。2026/4/1 以降に作成された公開アプリの要件はそのまま有効。 カスタムアプリ・マーチャント作成アプリは対象外 。自社で扱うアプリをどの種別か仕分けてから対応範囲を決める。 8 業務に活かせる3つのユースケース USE CASE 1 公開アプリ運営者の「App Store 掲載維持」移行プロジェクト 課題 公開アプリが期限なしオフライントークンのまま。1/1 を過ぎると非掲載になり、新規インストールが止まる。 打ち手 移行ガイドに沿って ① トークン取得処理の更新 → ② 既存インストールの移行 → ③ 保存とリフレッシュ処理の検証 を 1/1 より前に終わらせる。 効果 App Store 掲載と新規インストール受付を続けられる。マーチャントの管理画面に警告（1/15〜）が出るのも、403 による停止（4/1〜）も避けられる。 技術メモ 既存インストールの移行は、本番に入っているストアのトークンが対象。移行の進み具合をストア単位で追えるようにしておく。 USE CASE 2 夜間バッチ・在庫同期など「マーチャント不在」処理の止まらない設計 課題 期限付きトークンにすると、リフレッシュに失敗したときにマーチャントがアプリを開き直すまで、バックエンド処理が止まるおそれがある。 打ち手 client credentials access を復旧ルートとして組み込み、秘密鍵で署名したリクエストで新しい短命トークンを取り直す。 効果 マーチャントの操作を待たずにアクセスが戻り、バックグラウンド処理を続けられる。 技術メモ refresh token なしで取得できる。秘密鍵の保管場所とローテーション手順を設計に含める（具体的な方式は記事に記載なし）。 USE CASE 3 制作会社・代理店による「クライアントのアプリ影響調査」 課題 クライアントのストアで動いているアプリのうち、どれが今回の対象か分からない。1/15 以降、管理画面の警告を見たマーチャントから問い合わせが来るおそれがある。 打ち手 アプリを「既存の公開アプリ／2026/4/1 以降に作成された公開アプリ／カスタムアプリ・マーチャント作成アプリ（対象外）」に仕分けて、影響する範囲を整理する。 効果 対象外のアプリは対応不要と早めに伝えられ、対象の公開アプリは開発元の対応状況を先に確認できる。 技術メモ 自社開発のカスタムアプリは対象外。サードパーティの公開アプリは開発元の移行状況を確認する。 9 提案で使える1行サマリ 「公開アプリは 2027年1月1日までに期限付きオフライントークンへ移行 しないと、App Store 非掲載・新規インストール停止、 4月1日には Admin API が 403 になる。 新しい client credentials access で、バックエンドだけでアクセスを取り戻せる。 」 source ： shopify.dev/changelog / migrate-to-expiring-offline-access-tokens-before-january-2027 原文公開日 2026-10-27