Developer Changelog / 新パッケージ

PHP と Python で Shopify アプリを作る
公式パッケージが v1.0 に到達

リクエスト検証・トークン交換・Admin GraphQL の 3 つを「フレームワーク非依存の部品」として提供。Laravel / Symfony / Django / FastAPI、素の PHP・Python どれでも使える。旧 shopify-api-php / shopify_python_api は非推奨に。

このページの構成
  1. 30 秒で理解 : 何が出たのか
  2. 提供される 3 つのプリミティブ
  3. 図解 : リクエストが届いてからの流れ
  4. 旧ライブラリ vs 新パッケージ
  5. 影響を受ける人/受けない人
  6. 導入手順(4 ステップ)とコード例
  7. 技術者が押さえるべき 5 つのポイント
  8. 業務に活かせる 3 つのユースケース
  9. 提案で使える 1 行サマリ

130 秒で理解 : 何が出たのか

Shopify が PHP と Python 用の公式オープンソースパッケージを公開し、両方とも バージョン 1.0 に到達した。
Packagist の shopify/shopify-app-phpPyPI の shopifyapp
フルスタックのフレームワークではなく、必要な部品だけを組み合わせて使うプリミティブ集。今日から採用できる。

2 つの新パッケージが GA

PHP は composer、Python は pip で入る。どちらも一般提供(GA)。

フレームワーク非依存

Laravel / Symfony / Django / FastAPI、素の PHP・Python、どのスタックでも動く。

旧ライブラリは非推奨

shopify-api-php は abandoned、shopify_python_api は inactive に。動くが新機能もセキュリティ修正も来ない。

2提供される 3 つのプリミティブ

両パッケージは同じプリミティブを公開する。フレームワーク全体を受け入れる必要はなく、必要なものだけを組み合わせる(compose)設計。

1. リクエスト検証

対象は Webhook、App Home、App Bridge リクエスト、App Proxy リクエスト、そして Checkout / POS / Admin / Customer Account / Flow の各エクステンションからのリクエスト。

2. トークン交換

Token exchange。client credentials と、交換済みアクセストークンのリフレッシュも含む。

3. Admin GraphQL クライアント

自動リトライ処理つきの Admin GraphQL クライアント。

「小さくて明示的」が設計思想: 各プリミティブがセキュアなセットアップの 1 ステップに対応する。だからフローがコード上で見える形になり、自分にとっても AI ツールにとっても理解しやすい、と記事は説明している。

3図解 : リクエストが届いてからの流れ

受信リクエスト App Home / Webhook App Proxy / 各種拡張 Shopify から届く verify... メソッド 面ごとに対応する 検証メソッドを呼ぶ プリミティブ 1 $result shop idToken log / response 検証成功時に得られる値 トークン交換 idToken を アクセストークンへ プリミティブ 2 Admin GraphQL プリミティブ 3
検証で得た shop / idToken をそのまま使うのが正しい使い方。自前でリクエストをパースし直したり、再検証したりしないこと(記事の明示的な指示)。

4旧ライブラリ vs 新パッケージ

項目旧 : shopify-api-php / shopify_python_api新 : shopify-app-php / shopifyapp
ステータス 非推奨 Packagist は abandoned、PyPI は inactive GA v1.0 到達
新機能 来ない 継続的に開発
セキュリティ修正 来ない 提供される
動作 引き続き動く
移行期限 なし 強制移行も削除日も設定されていない。準備ができたときに README のアップグレードノートに従って段階的に移行
アプリテンプレート 無し PHP / Python 用テンプレートは提供されない。自分で scaffold する
旧ライブラリは「動くがセキュリティ修正が来ない」状態。期限は無いが、放置し続けるリスクは時間とともに上がる = 移行は「いつやるか」を自分で決める課題になった。

5影響を受ける人/受けない人

影響あり

PHP / Python で Shopify アプリを作る開発者

新規なら新パッケージを採用。既存アプリは即時対応不要で動き続ける。

影響なし

Node.js / Ruby ライブラリのアプリ

今回の変更で何も変わらない。

変更なし

新規アプリの推奨パス

React Router が引き続き「ほとんどの新規アプリにおける推奨パス」のまま。

6導入手順(4 ステップ)とコード例

記事の「新しい PHP / Python アプリを始める場合」の手順そのまま。

1

パッケージを入れる

自分の言語のパッケージをインストール。

2

プロジェクトを scaffold

好みのフレームワーク/スタックで自分で組む。

3

プリミティブを組み合わせる

例 : リクエストを検証 → トークンを交換。

4

開発ストアで確認

検証が成功し、トークン交換がアクセストークンを返すことを確認。

インストール : PHP
composer require shopify/shopify-app-php
インストール : Python
pip install shopifyapp
PHP の使用例(App Home リクエストの検証)
$shopify = new Shopify\App\ShopifyApp($clientId, $clientSecret);
$result = $shopify->verifyAppHomeReq($request);

検証成功時に $result から得られるもの

$result->shop : 検証済みのショップ
$result->idToken : アクセストークンに交換できる ID トークン
log、およびクライアントに返すための response

扱う面(surface)に応じた verify... を使う

Webhook / App Home / App Bridge / App Proxy / Checkout / POS / Admin / Customer Account / Flow ── 対応するメソッドを選ぶ。得られた値はそのまま使う(自前パース・再検証はしない)。

各パッケージの README が全プリミティブを文書化している。記事は「scaffold するときに README を AI コーディングツールのコンテキストとして渡せる」ことを明示的に想定している。

7技術者が押さえるべき 5 つのポイント

1. フレームワークではなくプリミティブ集

「全部入りフレームワークを採用する」のではなく、必要な部品だけを compose する設計。既存プロジェクトの構造を壊さずに差し込める。

2. 段階的移行(1 ルートずつ)が前提

アプリ全体の書き直しではなく 1 ルートずつ移行できるよう設計されている。旧ライブラリ利用者も強制移行・削除日は無いので、計画的に進められる。

3. 言語間で挙動が揃っている

両パッケージは同じ contract を実装し、同じテストスイートを通る。片方の改善がもう片方にも効く。PHP チームと Python チームで挙動差の議論をしなくて済む。

4. Admin GraphQL の自動リトライは同梱

クライアント側に自動リトライ処理が入っている。自前でバックオフを書いていた箇所は置き換え候補。詳細なリトライ条件は記事に記載なし ── README で確認する。

5. テンプレートが無い = scaffold は自前、README を AI に食わせる想定

PHP / Python 用のアプリテンプレートは提供されない。代わりに README が全プリミティブを文書化しており、AI コーディングツールへのコンテキストとして渡す使い方が公式に想定されている。「小さくて明示的な API = 人にも AI にも読める」という設計意図と一貫している。

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

Laravel Django FastAPI 公式 部品
USE CASE 1

既存の PHP / Python 基幹システムに、Shopify アプリを「後付け」する

課題
社内の基幹・受発注システムが Laravel や Django で動いており、Shopify 連携のためだけに Node.js のアプリを別立てすると、認証・デプロイ・運用の系統が二重になる。
打ち手
既存の PHP / Python プロジェクトに公式パッケージを入れ、必要なプリミティブ(リクエスト検証+トークン交換)だけを既存ルートに差し込む。
効果
言語・デプロイ基盤を увеличивать せずに Shopify 連携を実装でき、既存チームのスキルセットのまま保守できる。
技術メモ
フレームワーク非依存なので Laravel / Symfony / Django / FastAPI / 素の PHP・Python いずれでも可。アプリテンプレートは無いので scaffold は自前。
旧ライブラリ 新 route A 新 route B 新 route C 1 ルートずつ移行
USE CASE 2

非推奨ライブラリからの「期限なし・段階移行」計画を立てる

課題
稼働中アプリが shopify-api-php / shopify_python_api 依存。動いてはいるが、abandoned / inactive 扱いでセキュリティ修正が来ない
打ち手
強制移行も削除日も無いため、README のアップグレードノートに従ってルート単位で少しずつ新パッケージへ置換する移行計画を組む。まずリスクの高い検証・トークン交換まわりから。
効果
大規模リライトのための開発停止期間を作らずに、セキュリティ修正が届く土台へ移行できる。保守見積りの根拠としても提示しやすい。
技術メモ
期限が無い = 優先度が下がりやすい。「セキュリティ修正が来ない」点を判断材料に、社内で移行時期を明示的に決めておくのが安全。
README AI scaffold
USE CASE 3

テンプレートが無い前提で、README を AI に渡して初期構築を高速化する

課題
PHP / Python にはアプリテンプレートが無く、プロジェクトの初期構築を毎回ゼロから設計することになる。
打ち手
各パッケージの README(全プリミティブが文書化されている)を AI コーディングツールのコンテキストとして渡し、自社の標準スタックに合わせた scaffold を生成する。
効果
公式に想定された使い方なので、初期構築の設計コストを圧縮しつつ、プリミティブの正しい組み合わせ方から外れにくい。
技術メモ
各プリミティブがセキュアなセットアップの 1 ステップに対応する設計なので、生成コードのレビューでも「どのステップが抜けているか」が読み取りやすい。最後は開発ストアで検証成功とトークン交換を必ず実機確認する。

9提案で使える 1 行サマリ

「PHP と Python でも公式パッケージで Shopify アプリが作れるようになった(v1.0 GA)。
検証・トークン交換・Admin GraphQL の 3 部品だけを既存の Laravel / Django にそのまま差し込める。
旧ライブラリは非推奨(セキュリティ修正なし)だが期限は無く、1 ルートずつ段階移行できる。」