Shopify APIの更新案内が届いたら｜相談先と対応の進め方

Shopifyのアプリに「APIの更新が必要です」という案内が届いた。けれど、注文はいつもどおり入っているし、管理画面にも変わったところはない。「何を更新するのか。そもそも、自分たちで対応する話なのか」と、戸惑う方もいるのではないでしょうか。

先にお伝えすると、アプリのプログラムを調べて直すのは、提供元や開発会社の仕事です。店舗のご担当者が、APIの仕様書を読み解くところから始める必要はありません。

ただ、今は動いているからと、そのままにしてよい案内でもないのです。Shopify側の変更によって、注文や在庫の連携に影響が出ることがあります。まずは届いた案内を開発担当者へ渡し、今回の更新をお願いできるか、話を始めておくことをお勧めします。

今は動いている。それでもAPIの更新が必要な理由

APIは、アプリとShopifyの間で商品や注文などの情報を受け渡す仕組みです。たとえば、Shopifyに入った注文を倉庫へ送るアプリなら、このやり取りができて初めて、出荷の仕事につながります。店舗の画面からは見えにくいですが、日々の業務を支えている部分です。

Shopifyのバージョン管理対象APIには、3か月ごとに新しい版が公開されます。「2026-07」のような年と月がバージョン名で、安定版のサポート期間は最低12か月。新しい版に合わせてアプリを直し、動作を確かめるための期間が設けられています。

版ごとの利用期限は、Shopifyの公式資料に一覧があります。たとえば2025-10版は日本時間の2026年10月17日0時まで、2026-01版は2027年1月17日0時までです。修正後の動作確認にも時間が必要なので、期限が近い版を使っている場合は、早めに開発担当者へ相談しておきたいところです。使用中の版が分からなくても、届いた案内を見せるところから相談を始められます。

では、期限が来た瞬間にアプリが止まるのかというと、必ずしもそうではありません。利用できなくなった版へのリクエストには、Shopifyが利用可能な最も古い安定版で応答する仕組みがあります。「fall forward」と呼ばれるものです。

誤解しやすいのは、Shopifyが応答を切り替えても、アプリのプログラムまで直してくれるわけではない点です。受け取るデータの形式などが変われば、アプリ側でも修正が必要になります。そのため、画面が動いているかだけでなく、連携先とのやり取りまで調べる必要があります。

仕組みと期限は、Shopify公式「About Shopify API versioning」を要約しています。確認日：2026年10月15日。すべてのAPIが同じバージョン管理方式ではなく、期限や切替の扱いは利用中のAPIによって異なります。

App Storeから導入したアプリなら提供元へ、独自のアプリなら開発会社へ

相談先を考えるときは、そのアプリを誰が提供しているかで分けると分かりやすくなります。App Storeから導入したアプリなら、基本的には提供元が更新を行います。店舗側で操作が必要な場合もあるので、案内に書かれた対応内容が分からなければ、提供元へ問い合わせるのがよいでしょう。

一方、自社用に作ってもらったアプリは、納品後の保守をどう契約しているかによって変わります。「開発した会社が、今回も更新してくれるはず」と思っていても、追加の依頼が必要になることもあります。最初に開発会社へ連絡すれば、今回の対応を任せられるか、費用は別にかかるかという話を進められます。

参考：Shopifyヘルプセンター「アプリについて」。APIへの対応はアプリの開発者が行います。相談先の目安として、上の表にまとめました。

困るのは、以前の担当者が退職していたり、開発会社と連絡が取れなかったりする場合でしょう。そうなると「仕組みが分からないので、次の会社にも説明できない」と思うかもしれません。ですが、説明できるようになるまで、お客様だけで調べる必要はありません。当社でも、残っている資料や普段の使い方から伺い、調査に必要な情報をご案内します。

なお、Shopifyの管理画面に入れれば、どのアプリでも修正できるわけではありません。別のサーバーで動いている連携では、そちらのプログラムを確認することもあります。当社へご相談いただく場合も、何のためにどの権限が必要なのかをご説明してから、共有をお願いしています。

費用と日程をお伝えするために、まず何を調べるのか

相談するときに気になるのは、「いくらかかるのか」「期限までに間に合うのか」ではないでしょうか。ただ、API更新とひと口にいっても、設定の変更で済む部分もあれば、プログラムから直す部分もあります。案内の文面だけで作業日数を決めにくいのは、このためです。

grandworkでは、お客様が保有するShopifyアプリの保守を承っています。ご相談の際は、お使いの業務や現在の構成を伺い、対応できる内容と見積もりをご案内します。詳しい調査が必要であれば、その作業も含めてご説明しますので、技術資料が揃っていないことを理由に、お問い合わせをためらう必要はありません。

調査で知りたいのは、主に次の内容です。開発を担当する側でこれらを調べ、必要な作業と日程をお伝えします。

• 使用中のAPIの種類・バージョンと、その利用期限
• 更新先で変わる仕様と、アプリのどの処理に影響するか
• プログラムの修正、設定変更、再認証など、必要になる作業
• Shopifyから通知を受け取る機能への影響
• 動作確認に使える環境と、本番へ反映できる時期

たとえば、アプリから注文情報を取りに行く処理とは別に、Shopifyから「注文が入りました」と通知を受ける処理があります。この通知の仕組みが「Webhook」です。情報を取りに行く処理だけ試しても、通知をきっかけに動く処理までは確かめられません。両方を使っているなら、調査も両方に必要になります。

開発側では、公式リリースノートや、開発者向け管理画面「Dev Dashboard」の警告・処理の記録などを手掛かりに、変更の影響を調べます。ただ、月末にしか動かない処理もあります。警告が出ていないことだけで判断せず、プログラムと普段の使い方を合わせて見るのは、そのためです。

管理画面の機能は、Shopify公式「Monitor app performance」を参照しています。利用できる項目はアプリの構成によって異なります。

実際の変更例：取得できていた項目がなくなると、コードはどう変わる？

ここまでだと、実際に何を直すのかが見えにくいかもしれません。倉庫への出荷を担う「配送代行サービス」の情報を取得するコードで、変更前と変更後を見てみます。

GraphQL Admin APIの2026-04版では、FulfillmentServiceのpermitsSkuSharingという項目が削除されました。以前は、同じSKUの在庫を複数のロケーションで持てるかを表す設定でしたが、すべての配送代行サービスで有効になるため、この項目を読み書きする必要がなくなりました。

変更前：2025-10版で、この項目も取得していたコード

query ShippingService($id: ID!) {
  fulfillmentService(id: $id) {
    id
    serviceName
    permitsSkuSharing
  }
}

変更後：2026-04版では、削除された項目を取得しない

query ShippingService($id: ID!) {
  fulfillmentService(id: $id) {
    id
    serviceName
  }
}

$idには、調べたい配送代行サービスのIDを渡します。どちらも情報を読むためのコードです。変更前のコードを2026-04版へ送ると、存在しないpermitsSkuSharingを要求しているためエラーになります。変更後は、その項目を外してIDとサービス名を取得する形です。

見た目には、たった1行の削除です。ただ、その値を使って「在庫は一つの倉庫にしかない」と判断していた処理が残っていたら、取得部分だけ直しても十分とはいえません。別の箇所でこの項目を参照していないかを探し、複数の倉庫に在庫がある場合の処理まで見直す必要があります。作成・更新のAPIで同じ項目を送っている場合も修正の対象です。

たとえばテストでは、同じ商品の在庫を倉庫Aに5個、倉庫Bに9個という状態にして、それぞれの倉庫へ正しい数量が連携されるかを確かめます。倉庫別の在庫を扱う処理なのに、合計の14個を片方の在庫として送っていたら、APIとの通信が成功していても業務には使えません。更新作業では、APIのエラーが解消したことに加えて、連携先へ正しいデータが渡ることまで確かめます。

この例は、2025-10版から2026-04以降へ移行し、該当項目を使っているアプリで関係する変更です。すべてのアプリに同じ修正が必要なわけではなく、2025-10版の利用期限と、この項目が削除されたバージョンも別の話になります。

出典：Shopify公式「Removing permitsSkuSharing field from fulfillment service」。項目と型は2025-10版・2026-04版のAPIリファレンスと照合しています。2026年10月1日確認。コードは変更箇所を示す取得クエリの例で、認証・送信処理は省略しています。実ストアへの送信は行っていません。

接続できれば、更新は終わりなのでしょうか

APIにつながり、エラーも出なくなった。それでも、注文や在庫を扱うアプリの動作確認はまだ終わりません。連携先で、注文や在庫が正しく処理されているかまで確かめる必要があります。

たとえば、倉庫へ注文を送る処理が成功していても、明細が一つ抜けていたら、正しく出荷できません。在庫の更新も、数字が変わっただけでは不十分で、意図した商品・拠点の数量が変わっていることまで見て初めて、業務で使えると判断できます。

更新後の動作確認では、こうした受け取り先の結果まで開発側で調べます。アプリの機能によって、確認するところは変わります。

もちろん、すべてのアプリに表の機能があるわけではありません。実際に使っている機能に合わせ、対象データがないときや、処理に失敗したときの動きも試します。テストのつもりで本物の発送通知や決済を発生させては困りますから、テスト用のストアやデータを用意することも、開発側の準備に含まれます。

そのうえで、お客様にお聞きしたいのは普段の使い方です。「月末にだけ動かす」「この倉庫への注文だけは扱いが違う」。こうした事情は、プログラムから読み取れるとは限りません。難しい言葉で説明していただかなくても、日々の仕事のお話が、確認する処理の抜けを防ぐ助けになります。

作業日は、店舗の仕事に合わせて相談します

動作を確かめたら、本番で使っているアプリへ変更を反映します。店舗が忙しい時間帯は避けたいですし、反映後に注文の状態を一緒に確認できる時間も必要ですので、開発側の都合だけでは決められません。当社が作業する場合も、営業への影響を伺いながら日程をご相談します。

あわせて準備しておくのが、不具合が起きたときの戻し方と連絡先です。ただ、APIには利用期限があります。以前のプログラムを戻しても、そのプログラムが使うAPIを利用できなくなっていたら、元どおりには動かないのです。プログラムや設定をどこまで戻せるかは、更新前に開発側で検討しておく必要があります。

すでに送った注文や書き換えた在庫も、プログラムを戻すだけで取り消されるわけではありません。どのデータに影響したか、やり直すと注文が重複しないかまで調べてから対応します。変更内容の記録を残すのは、引き継ぎのためだけでなく、こうした場面で経緯をたどれるようにするためでもあります。

次の更新で、また相談先に困らないように

作業後は、何を変更し、どこまで確かめたのかをお客様にお伝えします。反映日時や更新前後のバージョン、残っている制約も記録しておけば、担当者が変わっても、前回の作業から話を続けられます。

APIの更新は一度で終わるものではありません。継続して保守を任せる場合は、次の期限を誰が確認するかも、契約の中で決めておきたいところです。案内が届くたびに一から相談先を探すより、事情の分かる相手と次の対応を考えられるほうが、運営する側の負担も減らせると思います。

相談先が見つからないときは、分かるところからお聞かせください

最初の話に戻ると、更新案内を受け取った方にお願いしたいのは、APIに詳しくなることではありません。アプリの更新を任せられる相手に、期限が迫っていることを知ってもらうことです。

「以前の開発会社にはもう頼めない」「誰が作ったか分からない」。そんな場合は、当社へご相談ください。アプリの名前、普段使っている業務、届いた案内など、分かるところから伺います。最初のお問い合わせにAPIキーやアクセストークン、顧客データを添付する必要はありません。調査に必要な情報と共有方法は、こちらからご案内します。

当社の保守は、お客様が保有するアプリが対象です。APIや依存ライブラリの更新、仕様変更に伴う修正・動作確認・公開作業について、アプリと運用環境を確認したうえでお引き受けしています。App Storeから導入した他社アプリの場合は、まず提供元へのお問い合わせをお願いします。

サーバーはお客様のアカウントでご用意いただき、作業は営業時間内に対応します。24時間の監視や、稼働率・復旧時間の保証は含まれません。保守を任せたい範囲や運用のご希望も伺ったうえで、当社で対応できるかをご案内します。