2027/1/1 から「期限切れする」 Offline Access Token が全 Public アプリで必須に

図解 ： Expiring offline access tokens 必須化（2027/1/1〜） Action Required ／ Admin API 2027/1/1 から「期限切れする」 Offline Access Token が全 Public アプリで必須に 非期限トークンは、漏洩したら永久に有効になってしまう。Shopify は全 Public アプリに 60 分で失効＋自動ローテーションする「Expiring Offline Access Token」への移行を義務化する。 このページの構成 30秒サマリ ： 何が・いつ・誰に タイムライン（2026/4 → 2027/1） 対象になるアプリ／ならないアプリ 非期限 vs 期限付 トークンの違い なぜ Shopify はこれを必須にするのか 対応手順（3ステップ） 技術者が押さえるべき5つのポイント 業務に活かせる3つのユースケース 提案で使える1行サマリ 1 30秒サマリ ： 何が・いつ・誰に 2027 年 1 月 1 日以降、全 Public アプリは「期限付 Offline Access Token」を使って Admin API を呼ばないと認証エラーになる。 2026/4/1 から「新規 Public アプリ」だけ必須だったルールが、 既存の Public アプリ含め全部 に拡大される。 いつから 2027 年 1 月 1 日。これ以降に非期限トークンで Admin API を叩くと認証エラーが返る。 誰に 全 Public アプリ。2026/4/1 以前に作ったものも含む。Custom／Dev Dashboard 製／Admin で作成したアプリは対象外。 何をする 既存トークンをコード経由で交換して期限付に切替。マーチャント側の再インストールは不要。 2 タイムライン 〜2026/3/31 どのアプリも非期限OK 2026/4/1 新規 Public は期限付必須 2027/1/1 全 Public で期限付必須 猶予期間 移行推奨期間 期限切れ強制 2027/1/1 以降、未対応のままだと Admin API が「認証エラー」で全死する。 本番アプリの場合、ユーザー影響＝サービス停止に直結。今から残り 7 ヶ月強の前提で移行計画を引くこと。 3 対象になるアプリ／ならないアプリ 対象になる（移行必須） 非期限トークンで Admin API を叩いている Public アプリ 2026/4/1 以前に作られたものも含む。App Store 公開有無は問わず Public 種別が対象。 2026/4/1 以降に作った Public アプリ 既に期限付必須。今回のアナウンスは「既存にも適用拡大する」という後追いルールづけ。 対象外（変更不要） 対象外 Custom アプリ 単一マーチャント向けのカスタムアプリは今回の必須化対象に含まれない。 対象外 Dev Dashboard でマーチャントが作ったアプリ マーチャント自身が Dev Dashboard 上で生成したアプリ。 対象外 管理画面でマーチャントが作ったアプリ Shopify admin から作られたアプリ。 4 非期限 vs 期限付 トークンの違い 項目 非期限（OLD） 期限付（NEW） 有効期間 無期限 60 分 更新 なし 自動ローテーション 漏洩時の影響 恒久的に悪用可能 最大 60 分で失効、影響範囲が極小 2027/1/1 以降の Admin API 認証エラー 正常動作 OAuth ベストプラクティス整合 外れている 準拠 5 なぜ Shopify はこれを必須にするのか マーチャントデータ保護の強化 非期限トークンが漏洩すると永久に有効。これは現代の OAuth ベストプラクティスから外れている。期限付＋自動更新で漏洩窓を 60 分まで縮める。 開発者にも嬉しい「予測可能な更新フロー」 リフレッシュの挙動が常に同じになるので、トークン管理の設計が単純化される。Shopify のテンプレート／公式 API ライブラリでは既に実装済み。 6 対応手順（3ステップ） 1 移行ガイドに沿って既存トークンを棚卸し どのストアの・どのスコープの非期限トークンを保持しているか DB を棚卸し。 2 コード経由でトークン交換 マーチャントの再インストール不要。アプリ側のコードで「非期限→期限付」に交換する。 3 保存ロジック＆Refresh 実装を更新 新しい access_token / refresh_token / expires_at を保存し、Refresh フローを稼働させる。 Shopify 公式の App Template / API Library を使っていれば、Refresh 処理は実装済み。 必要なのは「トークン交換」と「保存ロジックの更新」だけ。フルスクラッチ実装より圧倒的に楽。 具体的な手順は Shopify の migration guide に step-by-step で記載。困ったら dev platform community に相談する導線が用意されている。 7 技術者が押さえるべき5つのポイント 1. 期限は「2027/1/1」、それ以降は認証エラー 猶予なし。非期限トークンで Admin API を叩いた瞬間 auth エラーが返る。本番影響を起こさないために、年末年始のフリーズを跨がない時期での切替が現実的。 2. マーチャントの再インストール不要 既存トークンをアプリ側コードで交換するだけで済む。インストール済みストアへの追加オペレーション依頼は基本不要。営業／CS への通知設計も軽い。 3. 公式 API ライブラリ／テンプレートは対応済み Shopify 公式の Library を使っていれば Refresh ハンドリングは既に内包。自前で OAuth を書いたレガシー実装ほど手数が増える。 4. トークン保存スキーマの更新が必要 access_token 1 カラムから、access_token / refresh_token / expires_at の 3 点セット運用へ。マイグレーション設計と既存レコードのバックフィル方針を決めること。 5. Custom アプリ／マーチャント自作アプリは対象外 影響範囲は「Public アプリ」のみ。 マーチャントが Admin や Dev Dashboard で作ったアプリ、Custom アプリは今回の必須化対象に含まれない ので、案件のアプリ種別を最初に切り分けて影響評価を出すこと。 8 業務に活かせる3つのユースケース USE CASE 1 運用中 Public アプリの「トークン棚卸し＋移行計画」案件 課題 App Store 公開済みの Public アプリで、インストール済みストア数百〜数千件分の非期限トークンを DB に保持している。2027/1/1 までに全部期限付に移行しないとサービス停止。 打ち手 ① 影響範囲調査（Public 判定／対象スコープ／対象ストア数） ② 公式 migration guide に沿った設計レビュー ③ トークン交換バッチ＋オンライン更新の二段構えで移行。 効果 2027/1/1 のサービス停止リスクをゼロ化。マーチャントへの再インストール依頼が不要なので、CS 工数も最小化できる。 技術メモ 本文上は具体的なバッチ運用方法の記載なし。実装時は migration guide を参照し、サンドボックスでまず 1 ストア通すこと。 USE CASE 2 レガシー OAuth 実装の「公式 SDK 移行」リファクタ提案 課題 自前で OAuth フローを実装している古いアプリでは、Refresh フローを新規実装する必要があり、テスト工数が膨らむ。 打ち手 今回の必須化を機に、Shopify 公式 API ライブラリ／App Template に寄せるリファクタを同時並行で実施。トークン関連の責務を SDK に移譲する。 効果 Refresh 実装が SDK 任せになり、テスト範囲が狭まる。今後の OAuth 仕様変更にも追随しやすくなる。 技術メモ SDK 移行と同時にトークン保存スキーマ（access_token / refresh_token / expires_at）の DB マイグレーションも実施する。 USE CASE 3 保有アプリの「2027/1/1 リスクアセスメント」サービス化 課題 事業会社が複数の Public アプリを内製／外注で抱えており、どれが対象でどれが対応済みか把握できていない。 打ち手 アプリ種別（Public／Custom／Dev Dashboard 製）と現在のトークン方式（期限付／非期限）を棚卸しし、移行優先度マトリクスを作成。スプリント計画に組み込む。 効果 2027/1/1 までの 7 ヶ月強で計画的に移行完了させ、年末年始のフリーズ期間を跨いでの慌てた本番対応を避けられる。 技術メモ Custom アプリ・マーチャント作成アプリは対象外なので棚卸し段階で除外。Public のみを工数積算対象にする。 9 提案で使える1行サマリ 「2027/1/1 から全 Public アプリは期限付 Offline Access Token 必須。 未対応のままだと Admin API が認証エラーで全死。 マーチャント再インストール不要・公式 SDK 利用なら Refresh は実装済み、 やることは『トークン交換』と『保存スキーマ更新』の 2 つだけ。」 source ： shopify.dev / changelog / expiring-offline-access-tokens-required-for-all-public-apps-as-of-january-1-2027 generated 2026-05-23