公開アプリは2027年1月1日までにログイン方式を変えなければならない。Shopify自身のガイドが「マーチャントが開かないアプリは自動では直らない」と書いている

この記事でわかること

先に結論 3つの日付と、1つの変更壊れ方なぜ、たいていは勝手に直るのか Shopifyが名指しした例外あなたが見ていない間に動いている5本

この記事の目次Contents閉じる開く

プラットフォーム側の期限は、たいてい管理画面のバナーとしてやってきます。この件は違います。宛先はアプリ開発者、書かれている場所はdeveloper changelog、そして実際に不具合を体験するのはあなただけです。

日付、引用、エラー文字列、評価、料金は、2026年9月11日にShopify developer changelog、shopify.devのドキュメント、Shopify Help Center、en-USのShopify App Storeで確認したものです。料金はすべてUSD表記です。

先に結論

日常的に開く画面を持つアプリだけで構成されているなら、この件は勝手に解決し、起きたことにも気づきません。

一度入れたきり開いていないアプリがあるなら — フィード生成、在庫同期、会計連携 — それがまさに、Shopify自身の移行ガイドが「自動では直らない」と書いている対象です。

どのアプリが移行済みかを確認する手段はありません。 App Storeのリスティングにも書かれておらず、管理画面にも出ません。

ただし、トークンより有用なものは確認できます。 そのアプリが今もストアに対してリクエストを投げているかどうかです。そのページはすでに存在しています。

3つの日付と、1つの変更

2025年12月まで、offline access token — アプリが「誰もログインしていない時間帯にも動く」ために保存しておく認証情報 — に有効期限はありませんでした。アンインストールされるまで有効なままです。

Shopifyは2025年12月10日にこれを変更しました。offline tokenは60分で失効する選択肢を持ち、refresh tokenとセットで発行されるようになりました。この時点では追加仕様であり、何も壊れていません。

2026年3月20日、Shopifyは2026年4月1日以降に作成される新規の公開アプリに対して、これを必須化しました。

2026年5月20日、対象がすべての公開アプリへ拡大されます。このchangelogエントリには2つのフラグ（Breaking API ChangeとAction required）が立っており、期日を定める一文があります。2027年1月1日以降、すべての公開アプリはAdmin API呼び出しにexpiring offline access tokenを使わなければならず、それ以降も有効期限なしのトークンを使っているアプリは認証エラーを受け取る、というものです。

対象外が2つ明記されています。custom appは影響を受けません。Dev Dashboardまたは Shopify管理画面でマーチャント自身が作成したアプリも同様です。自社ストア向けに自前の連携を作っている場合、この記事の内容は当てはまりません（ただしその作り方自体は2026年1月に変わりました）。Shopify App Storeから入れたものは、すべて公開アプリです。

現在のトークン有効期間は、Shopifyのaccess tokensリファレンスにこう整理されています。

トークン	有効期間
Expiring offline access token	1 hour（`expires_in` は `3600`）
そのrefresh token	90 days（`refresh_token_expires_in` は `7776000`）
Non-expiring offline access token	期限なし。アンインストールまたはsecret失効まで
Online access token	24時間、またはスタッフがログアウトするまで

つまり移行済みのアプリは、1時間しかもたない認証情報をバックグラウンドで更新し続けます。常時稼働していれば1日最大24回です。refresh token自体も更新のたびにローテーションします。この動きはマーチャント側からは一切見えません。見えないことが、この設計の目的です。

壊れ方

Shopifyは拒否の挙動を具体的に書いています。2027年1月1日以降、有効期限なしのトークンを提示したGraphQL Admin APIリクエストは 403 Forbidden を返し、errors の値に Non-expiring access tokens are no longer accepted for the Admin API という文字列が含まれます。

これは仮の話ではありません。あるChatwootユーザーが2026年5月14日にこの文字列を踏み、issue #14462を起票しています。期限のはるか手前ですが、そのアプリが4月1日以降に作成された新規公開アプリだったためです。ストアの接続は成功し、OAuthフローも完了し、管理画面上は「接続済み」と表示され、そのうえで注文データだけが表示されませんでした。issueには、公式のRubyライブラリが2025年12月に対応版を出したことも記録されています。

エラーコードよりも、この壊れ方のほうが重要です。認証は目に見える形では失敗していません。アプリはインストール済みに見えます。止まったのはデータだけです。

Shopifyの移行ガイドは、マーチャント側の結果を一文で書いています。マーチャントは再認証するまでそのアプリへのアクセスを失う、と。

なぜ、たいていは勝手に直るのか

Shopifyはこの移行が見えないように設計しています。changelogの書き方も率直で、アプリがコード側で既存トークンを交換するのでマーチャントの再インストールは不要、としています。

仕組みは移行ガイドにあります。開発者が対応版をリリースしたあと、インストール済みストアの既存トークンは、マーチャントが次にそのアプリを開いてアプリが新しいトークンを要求したタイミングで、自動的に切り替わります。プロンプトも、ストアごとの作業も、再インストールもありません。

画面を持つアプリ — ページビルダー、レビュー承認画面、問い合わせ受信箱 — なら、これは数日の話です。誰かが開けば、トークンは静かに入れ替わり、期日は無関係になります。

Shopifyが名指しした例外

そして同じページに、こう書かれています。

Cycling on next app open covers most installs, but it gives you no control over timing, and it never covers an app that merchants don't open. （次回のアプリ起動時に切り替える方法はほとんどのインストールをカバーするが、タイミングを制御できず、マーチャントが開かないアプリは決してカバーできない）

そのうえで形態を名指しします。完全にバックグラウンドで動くアプリ、すなわちwebhook consumer、App Proxy backend、Flow action。これらには「待つべきアプリ起動」が存在しない、と。

開発者向けの文章ですが、マーチャントとして読み替えると、自分のアプリ一覧を仕分ける基準になります。自動修復の引き金は「あなたがアプリを開くこと」です。開かないアプリは、その対象外です。

開発者にはもう1つの経路があります。マーチャントのセッションなしに、バックグラウンドジョブから保存済みトークンを切り替えるtoken exchangeの呼び出しです。ただしこちらには警告が付いており、その結果を受け取るのはストア側です。

Cycling is irreversible, and it isn't safe to replay. （この切り替えは不可逆であり、再実行しても安全ではない）

Shopifyは、expiring tokenを発行するのと同じトランザクションで、non-expiring tokenを破棄します。アプリがそのレスポンスを取りこぼした場合、ガイドの表現では、そのストアには使えるトークンが1つも残らず、マーチャントが再認可するまでアプリはAdmin APIを呼べません。移行に失敗しても、古い認証情報に戻るわけではないということです。何も残りません。

あなたが見ていない間に動いている5本

以下のアプリが影響を受けると分かっているわけではありません。トークン方式を公開しているアプリは存在せず、この記事のどの記述も、特定ベンダーの移行状況に対する主張ではありません。ここに挙げた理由は1つだけです。いずれも実際の仕事を、スケジュール、webhook、フィードの上でこなしている — Shopifyのガイドが「アプリ起動では切り替えられない」と書いた、まさにその形だからです。

自分のスタックがこの形なら、連絡すべき相手はこれらのベンダーです。

Matrixify

MatrixifyのShopify App Storeリスティングページ上部。Built for Shopifyバッジと4.9の評価が表示されている

出典: Shopify App Store（Matrixify、2026-09-11時点）

Matrixify（開発元ITissible）はBuilt for Shopifyバッジを持ち、1,611件のレビューで4.9。Free planあり、Basicが$20/month、Bigが$50/month、ファイルあたりの行数で段階が分かれます。

リスティングが打ち出しているのは、自動で繰り返されるスケジュール実行のexport / importジョブです。Google Sheets、FTPサーバー、Excelファイル経由で動きます。夜間の商品エクスポートと週次の仕入先インポートを組んだマーチャントには、何か月もアプリを開く理由がありません。それがこのアプリの価値そのものであり、同時にShopifyが書いた条件そのものでもあります。

syncX: Stock Sync & Inventory

syncX: Stock Sync & InventoryのShopify App Storeリスティングページ上部。Built for Shopifyバッジと4.7の評価が表示されている

出典: Shopify App Store（syncX: Stock Sync & Inventory、2026-09-11時点）

syncX: Stock Sync & Inventory（開発元SyncX）はBuilt for Shopifyで、917件のレビューで4.7。Free planあり、Starterが$7/month、Expertが$10/month。

有料プランの区切りは実行頻度です。Starterは1日1回・最短24時間間隔、Expertは1日12回・最短2時間間隔。リスティングの「Works with」にはShopify FlowとShopify Admin APIが並びます。在庫同期が静かに止まる状況は、目に見えて壊れるより厄介です。在庫数が消えるわけではなく、正しくなくなるだけだからです。

A2X Sync for QuickBooks & Xero

A2X Sync for QuickBooks & XeroのShopify App Storeリスティングページ上部。5.0の評価と月額29ドルからの料金が表示されている

出典: Shopify App Store（A2X Sync for QuickBooks & Xero、2026-09-11時点）

A2X Sync for QuickBooks & Xero（開発元A2X Software Limited）は360件のレビューで5.0。月200注文までの$29/monthから始まり、注文数に応じて$45、$79、$115/monthと上がります。

Shopifyのpayoutデータを QuickBooks Online、Xero、Sage、NetSuiteへ突合します。会計連携アプリを開くのは月次決算のとき、開くとすればの話です。元帳の欠損はたいてい数週間後に経理担当者が見つけ、そこからの復旧は手作業になります。

Simprosys Google Shopping Feed

出典: Shopify App Store（Simprosys Google Shopping Feed、2026-09-11時点）

Simprosys Google Shopping Feed（開発元Simprosys InfoMedia）は4,870件のレビューで4.9。500商品までの$4.99/monthから、カタログ規模で段階が上がります。

Google Shopping、Microsoft Advertising、Meta、Pinterestへ商品フィードを送出し、Performance Maxキャンペーンも管理します。カタログを読めなくなったフィードアプリは、空のフィードを作るのではありません。古いフィードを出し続けます。価格と在庫がストアの実態からずれていき、最初の兆候はアプリのエラーではなく、Merchant Centerの非承認として現れます。

Zapier: Workflow Automation

Zapier: Workflow AutomationのShopify App Storeリスティングページ上部。4.0の評価とFreeプランが表示されている

出典: Shopify App Store（Zapier: Workflow Automation、2026-09-11時点）

Zapier: Workflow Automation（開発元Zapier Inc）は74件のレビューで4.0。リスティングのFreeプランには注記があり（Shopify利用にはZapierの有料プランが必要）、Professionalが$29.99/month、Teamが$103.50/month。いずれもZapier側からShopifyの請求とは別に課金されます。

リスティングの機能欄はscheduled tasks、custom triggers、custom workflows。Shopifyが名指しした形態として最も分かりやすいのがZapierです。Zapの存在意義は「誰も動作を見ていないこと」だからです。

リスティングに書かれていないこと

この記事で確認した6本のApp Storeリスティング — 上記5本にJudge.me Product Reviews Appを加えたもの — のいずれにも、「token」という単語は1回も出てきません。「authenticate」も「OAuth」も同様にゼロです。リスティングは料金、データアクセス、連携先、レビュー履歴を詳細に記載します。認証方式はリスティングの項目ではありませんし、今後項目になると期待する理由もありません。

管理画面にも出ません。データアクセス権限の確認画面が示すのは、そのアプリが何を読み書きできるかであって、どうやって自分を証明しているかではありません。

構造としてはscript tagの期限とまったく同じです。開発者に対して執行されるプラットフォーム変更が、マーチャントが実際に読む画面には現れません。

役に立つページ

使える計器は1つあります。そしてそれは、トークン方式よりも優れています。設定ではなく挙動を測っているからです。

Settings > Apps を開き、アプリ名をクリックしてabout pageを表示し、Activity and permissions セクションを見ます。Help Centerの説明では、このセクションはそのアプリがストアのどの領域を閲覧・編集できるかと、領域ごとの直近のアクティビティ日付を表示します。過去30日間使われていない権限は、Unused access として別枠に表示されます。Recent activity の日付をクリックすると、過去30日間のview / editリクエスト数と、最後のリクエスト日が確認できます。

2時間おきに在庫を書き込んでいるはずのアプリの最終リクエストが3週間前なら、それは何かを示しています。原因が何であれ、です。

1点、知っておくべき制限があります。Help Centerの注記では、activityとpermissionsが記録されるのは現時点ではサードパーティアプリのみで、Shopify製アプリはここに出ません。

今から1月までの運用として妥当なのは、月に一度、普段開かない3〜4本のアプリを開き、直近のアクティビティ日付がそのアプリのスケジュールと整合しているかを確認することです。

ベンダーに聞くこと

質問は1つで、追加の往復は必要ないはずです。

Has your app migrated to expiring offline access tokens for the Admin API, and if not, what is your timeline before January 1, 2027? （貴社アプリはAdmin API向けのexpiring offline access tokenへ移行済みですか。未対応の場合、2027年1月1日までのスケジュールを教えてください）

対応済みのベンダーなら即答します。未対応でも、期日は持っているはずです。どちらも返ってこない場合は、カタログへの書き込み権限を持つアプリに関する他の運用上の質問が返ってこない場合と同じ扱いでよいでしょう。アンインストール時に何が残るかの棚卸しを最新に保つべき理由でもあります。

まとめ

これは開発者側の義務であり、結果を受け取るのはマーチャントです。その非対称性がこの件の本質です。Shopifyは「入口を持つアプリ」なら確実に動く自動移行を設計し、そのうえで自社のガイドに、この仕組みは開かれないアプリには決して届かないと書きました。

認証情報は見えません。リクエストは見えます。2027年1月1日までに見ておくべきアプリは、普段見る理由がないアプリです。

Sources

期限の日付、ドキュメントの引用、App Storeの評価と料金は2026年9月11日に確認しています。ベンダーの移行状況はどこにも公開されておらず、常時変化します。どちらとも断定せず、開発元に確認してください。

Shopifyは2025年8月25日、在庫CSVにBin name列を追加しました。バリアントごと・ロケーションごとに1つのビンを持ち、作成はCSVインポートのみ、Order Printerのピックリストに印字されます。できないのは、Shopifyの外に出ることです。Shopifyのスタッフは開発者フォーラムで2025年10月と2026年1月に、このフィールドへの公開APIアクセスが存在しないと明言し、開発者フォーラムでは2026年6月時点でも未対応のままだと報告されています。この1点がカテゴリ全体の設計を決めています。EasyScanとiPackyはビンをmetafieldに保存し、Bins-USAとShelfPilotは自前のデータベースに保存し、無料アプリのSimple Bin Locationsはmetafieldのビンを注文メモへ複写して納品書に出します。Shopify自身のマルチビンモデル、つまりビン単位の数量とunbinnedQuantityフィールドを持つ構造は、現時点では開発ストア限定のフィーチャープレビューとしてしか存在しません。料金、プランの壁、各アプリがビンデータをどこに置くかを、Shopify App Store、Shopifyヘルプセンター、shopify.dev、Shopifyコミュニティフォーラムで2026年9月18日に確認しています。