Developer Changelog / 認証・必須対応

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

期限なしのオフラインアクセストークンを使い続ける公開アプリは、App Store から非掲載になり新規インストールもできなくなる。新しく加わった「client credentials access」で、バックエンドだけでアクセスを取り戻せるようになった。

このページの構成
  1. そもそも何が変わるのか(30秒で理解)
  2. ペナルティのタイムライン(段階的に厳しくなる)
  3. 新機能 : client credentials access の仕組み
  4. 対象になるアプリ/ならないアプリ
  5. 期限なし vs 期限付き の比較
  6. 移行ガイドの3ステップ
  7. 技術者が押さえるべき5つのポイント
  8. 業務に活かせる3つのユースケース
  9. 提案で使える1行サマリ

1そもそも何が変わるのか

期限なしのオフラインアクセストークンを使い続ける公開アプリは、2027年1月1日までに有効期限付きのオフラインアクセストークンへ移行しないと、
Shopify App Store への掲載と新規インストールの受付を続けられなくなる。
∞

これまで : 期限なしトークン

一度発行されたオフラインアクセストークンが、期限なしで使い続けられる。

これから : 期限付きトークン

有効期限付きのオフラインアクセストークンを使う。さらに client credentials access で、バックエンドが短命なアクセストークンを新しく取り直せる。

2ペナルティのタイムライン

1 2027年1月1日 App Store から非掲載 新規インストールをブロック 既存インストールは 4/1 まで稼働 2 2027年1月15日 マーチャントの管理画面に 警告を表示 停止リスクと取れる対応を案内 3 2027年4月1日 対象の Admin API リクエストが HTTP 403 期限なしトークン使用時 段階的なペナルティ(未対応アプリ向け)
1月1日で即停止ではないが、新規獲得はそこで止まる。既存インストールが動くのは 4月1日まで。その後は対象の Admin API リクエストが 403 になる。

3新機能 : client credentials access の仕組み

アプリのバックエンド マーチャントの操作を待たない 秘密鍵で署名したリクエスト refresh token は不要 Shopify 署名を検証 新しい短命アクセストークン アクセスを回復
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. 実質の締め切りは1月1日

API が止まるのは 4/1 でも、App Store 非掲載と新規インストール停止は 1/1 から。新規獲得が止まるので、4/1 ではなく 1/1 を締め切りとして計画を立てる。

403

2. 4月1日以降は 403 が返る

期限なしトークンを使った対象の Admin API リクエストが HTTP 403 になる。どのエンドポイントが「対象」かの細かい範囲は記事に記載なし。

3. 秘密鍵の管理が新しい要件になる

client credentials access はアプリの秘密鍵で署名したリクエストを使う。バックエンドで秘密鍵を安全に保管する設計が要る。

4. refresh token が無くても回復できる

マーチャントがアプリを開き直すのを待たずに、バックエンドだけで新しい短命トークンを取得できる。リフレッシュ失敗時の復旧ルートとして使える。

5. 対象はアプリ種別で決まる

今回の段階的スケジュールが適用されるのは既存の公開アプリ。2026/4/1 以降に作成された公開アプリの要件はそのまま有効。カスタムアプリ・マーチャント作成アプリは対象外。自社で扱うアプリをどの種別か仕分けてから対応範囲を決める。

8業務に活かせる3つのユースケース

2027 1/1 1/15 4/1
USE CASE 1

公開アプリ運営者の「App Store 掲載維持」移行プロジェクト

課題
公開アプリが期限なしオフライントークンのまま。1/1 を過ぎると非掲載になり、新規インストールが止まる。
打ち手
移行ガイドに沿って ① トークン取得処理の更新 → ② 既存インストールの移行 → ③ 保存とリフレッシュ処理の検証 を 1/1 より前に終わらせる。
効果
App Store 掲載と新規インストール受付を続けられる。マーチャントの管理画面に警告(1/15〜)が出るのも、403 による停止(4/1〜)も避けられる。
技術メモ
既存インストールの移行は、本番に入っているストアのトークンが対象。移行の進み具合をストア単位で追えるようにしておく。
batch
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 で、バックエンドだけでアクセスを取り戻せる。」