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

図解 ： Shopify 公式の PHP / Python アプリパッケージが登場 Developer Changelog / 新パッケージ PHP と Python で Shopify アプリを作る 公式パッケージが v1.0 に到達 リクエスト検証・トークン交換・Admin GraphQL の 3 つを「フレームワーク非依存の部品」として提供。Laravel / Symfony / Django / FastAPI、素の PHP・Python どれでも使える。旧 shopify-api-php / shopify_python_api は非推奨に。 このページの構成 30 秒で理解 ： 何が出たのか 提供される 3 つのプリミティブ 図解 ： リクエストが届いてからの流れ 旧ライブラリ vs 新パッケージ 影響を受ける人／受けない人 導入手順（4 ステップ）とコード例 技術者が押さえるべき 5 つのポイント 業務に活かせる 3 つのユースケース 提案で使える 1 行サマリ 1 30 秒で理解 ： 何が出たのか Shopify が PHP と Python 用の公式オープンソースパッケージ を公開し、両方とも バージョン 1.0 に到達した。 Packagist の shopify/shopify-app-php と PyPI の 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 図解 ： リクエストが届いてからの流れ 検証で得た 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 つのユースケース USE CASE 1 既存の PHP / Python 基幹システムに、Shopify アプリを「後付け」する 課題 社内の基幹・受発注システムが Laravel や Django で動いており、Shopify 連携のためだけに Node.js のアプリを別立てすると、認証・デプロイ・運用の系統が二重になる。 打ち手 既存の PHP / Python プロジェクトに公式パッケージを入れ、必要なプリミティブ（リクエスト検証＋トークン交換）だけを既存ルートに差し込む。 効果 言語・デプロイ基盤を увеличивать せずに Shopify 連携を実装でき、既存チームのスキルセットのまま保守できる。 技術メモ フレームワーク非依存なので Laravel / Symfony / Django / FastAPI / 素の PHP・Python いずれでも可。アプリテンプレートは無いので scaffold は自前。 USE CASE 2 非推奨ライブラリからの「期限なし・段階移行」計画を立てる 課題 稼働中アプリが shopify-api-php / shopify_python_api 依存。動いてはいるが、abandoned / inactive 扱いで セキュリティ修正が来ない 。 打ち手 強制移行も削除日も無いため、README のアップグレードノートに従って ルート単位で少しずつ 新パッケージへ置換する移行計画を組む。まずリスクの高い検証・トークン交換まわりから。 効果 大規模リライトのための開発停止期間を作らずに、セキュリティ修正が届く土台へ移行できる。保守見積りの根拠としても提示しやすい。 技術メモ 期限が無い ＝ 優先度が下がりやすい。「セキュリティ修正が来ない」点を判断材料に、社内で移行時期を明示的に決めておくのが安全。 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 ルートずつ段階移行できる。」 source ： shopify.dev / changelog / build-shopify-apps-in-php-and-python-with-new-official-packages 2026-08-26