Shopify Editions Spring ’26 開発者（全54項目）
開発者カテゴリーは 全54項目で全10カテゴリー中いちばん多い更新群です。一本に貫く流れは 「開発そのものをAIエージェント前提に作り直す」こと。お気に入りのAIコーディングエージェントから Shopify を正確に扱える AI Toolkit、フレームワークを選ばない 新しい Hydrogen、テーマとアプリ・AIが確実につながる 標準ストアフロントイベント——いずれも「人が手で書く／AIが書く」のどちらでも壊れにくい土台づくりに向いています。開発者向けAPI・ツールが中心のため、ごく一部（Shop 消費者アプリ・WhatsApp 依存の項目）を除き、原則すべて日本でも使えます。
検証ステータスについて：本カテゴリーは 公式ドキュメント（shopify.dev／changelog）ベースで整理しています。Developer Preview（先行公開）や 2026-07 以降提供の項目を含み、実機での挙動確認は限定的です。数値・正式な提供時期は出典先で最新をご確認ください。日本可否は「開発者向けAPIは原則グローバル提供」という前提に基づく判断です。
54項目を並べると、個々の機能改善の奥に一貫した設計思想が見えます。それは「AIエージェントが Shopify を推測ではなく正確に扱えるようにする」こと。AI Toolkit（#01）が公式ドキュメント・GraphQL スキーマ・コード検証をエージェントに渡し、Dev MCP（#24/#25）がそれをトークン効率よく供給する。新しい Hydrogen（#32）は「エージェントファースト」を掲げてフレームワーク非依存に再構築され、標準ストアフロントイベント（#49）はテーマ実装差を吸収してアプリ・AIとの連携を安定させます。
もう一つの軸は「運用負担を Shopify 側に寄せる」方向。App Home UI Extension（#12）でアプリのバックエンドサーバーが不要になり、<shopify-account>（#48）はアカウント導線をテーマ1行に、Shopify App Pricing（#26）は課金まわりを Shopify が代行します。StoreHero 視点：制作・運用の効率に直結するのは AI Toolkit／Dev MCP／メタオブジェクトAPI合理化（#11）／標準イベント。テーマ・アプリ開発のスピードと正確性を一段引き上げる土台で、日本のストア支援でもそのまま使えます。
01お気に入りのAIエージェントにコマースのスキルを（Shopify AI Toolkit）重要度S日本：利用可本カテゴリーの中心+
Claude Code・Codex・Cursor・Gemini CLI・Hermes・VS Code といったお気に入りのAIコーディングエージェントから、Shopify のストアフロント・アプリ・テーマを構築できるようにするツール群です。狙いは明快で、エージェントが Shopify の実装方法を「推測する」のではなく「正しく扱える」ようにすること。“それっぽいが動かない GraphQL”や“古いAPI”を構造的に減らします。
導入は3経路。①プラグイン（推奨）＝対応エージェントに入れると自動更新で常に最新、②エージェントスキル＝GitHub から個別に導入、③Dev MCP サーバー＝認証不要でローカル接続（後述 #24/#25）。Node.js 18+ が前提です。
注意したいのは層の違い。これは「開発フローのエージェント化」であって、買い物客がチャット内で決済まで完結する UCP（Universal Commerce Protocol）とは別の話です。あくまで“作る側”を速く・正確にするツールです。
24Shopify Dev MCP サーバー（トークン最適化＋全APIバージョン対応）重要度A日本：利用可#01の③経路の中身+
AI Toolkit が束ねる3経路のうち ③Dev MCP サーバーの中身です。MCP（Model Context Protocol／AIに外部の知識・ツールを接続する標準規格）でローカルに接続し、AIエージェントに実在する公式ドキュメントと GraphQL スキーマを都度渡します（認証不要）。今回の更新は2点——#24 トークン使用の最適化（ドキュメント全文でなく必要チャンクだけ返す）と、#25 全APIバージョン対応（サポート対象の全バージョンで正確なコンテキストとコード検証を取得）。
主要ツールは3つ：最初に呼ぶ learn_shopify_api、必要箇所だけ抜粋する search_docs_chunks、生成クエリが実在スキーマと一致するか検証する validate_graphql_codeblocks。AIに“幻覚コード”を書かせないための実装上の要です。
AIエージェントを使って、チェックアウト拡張機能やお客様アカウント拡張機能を Polaris Web Components へ移行できる。手作業の移行をAIが肩代わりする。出典 ↗
チェックアウトUI拡張機能のパフォーマンスをAIが検証し、最適化の推奨を提示する。重いチェックアウト拡張の改善に。出典 ↗
32あらゆるスタックで使える全く新しい Hydrogen重要度S日本：利用可Developer Preview+
ヘッドレス（Shopify を在庫・決済の裏側として使い、表側を自前で作る構成）の作り方が大きく変わります。これまでの Hydrogen は React Router（旧 Remix）前提でしたが、新しい Hydrogen は中核機能を SDK として切り出し、フレームワーク非依存に。Next.js・Svelte・Nuxt・Astro など好きなスタックに組み込めます。
もう一つの特徴が「エージェントファースト」。AIエージェント向けのスキルを 12種以上同梱し、AIにヘッドレス開発をさせる前提で設計されています。現在は Developer Preview（本番前の先行公開）段階で、npx @shopify/hydrogen@preview setup から試せます。
49標準のストアフロントイベントとアクション重要度S日本：利用可AI連携の土台+
アプリや外部スクリプト（AIエージェントを含む）が、テーマのカートを正式な作法で読み書きできる共通インターフェースです。従来はカートのHTMLを探し、ボタンの class を推測してクリックする“DOM手探り”が必要で、テーマを更新すると壊れるのが常でした。
標準イベント＆アクションでは、テーマが標準イベントを発火し、アプリ側は Shopify.actions を呼ぶだけ——updateCart()（カートに反映）・openCart()（カートを開く）・getCart()（中身を取得）。テーマ実装差に依存しないため、テーマが変わっても動き続けます。AIエージェントがストアフロントを正しく操作する土台にもなります。
新しいカラーアーキテクチャにより、テーマ全体のカラーパレットをテーマ設定で定義できる。配色の一元管理がしやすくなる。出典 ↗
サインインページへのリンクに login_hint パラメーターを付けると、メールアドレスが事前入力された状態でログイン画面を開ける。離脱を減らす小技。出典 ↗
48お客様アカウントのウェブコンポーネント（<shopify-account>）重要度S日本：利用可テーマに1行+
<shopify-account> というウェブコンポーネントをテーマに1行置くだけで、顧客がストアから離れずにログインやアカウントメニューにアクセスできるようになります。従来は「ログイン状態の判定 → リンクの出し分け → メニュー実装」を手書きしていた部分が、Shopify 管理の1要素に置き換わります（JS 実装・状態管理は不要）。
前提として、ストアでお客様アカウント（新しい認証）が有効であることが必要です。新しいアカウント体験への導線を、テーマに最短で組み込めます。
Shop の API・SDK で、ワンタップ認証（Sign in with Shop）を自前のページに組み込める。機能自体は実装可能だが、Shop アプリの普及が北米中心のため日本での到達はこれから。出典 ↗
お客様アカウントのUI拡張機能から、サブスクリプションの決済方法をネイティブに更新できる（Customer Account UI Extensions — Intents API）。出典 ↗
公開アプリが OAuth 2.0 準拠の有効期限付きオフラインアクセストークンを使うようになる。漏洩時の被害範囲を限定できる。出典 ↗
返品・交換系アプリとサブスク系アプリは、Customer Account API での顧客認証が必須に。認定取得を狙うアプリ開発者向けの要件強化。出典 ↗
12軽量アプリのバックエンドが不要に（App Home UI Extension）重要度S日本：利用可カスタム配布限定+
これまで埋め込みアプリは自分のサーバーで画面を配信し、管理画面に iframe で差し込んでいました。App Home UI Extension は、その土台を Shopify ホスト型に変えます。サーバーを用意・運用せず、UI を書いて配置するだけ。稼働監視・スケール対応といった負担が消えます。
技術スタックは Preact ＋ Polaris web components ＋ Remote DOM（画面の構造を Shopify 側に安全に渡して描画させる仕組み）。バンドル上限は 64KB。現状はカスタムディストリビューション（特定ストア向け配布）限定で、まずは社内ツール的なアプリに向きます。
従量・定額・ハイブリッドの価格設定を Shopify が代行し、請求書発行・回収まで一括で引き受ける。アプリ開発者の請求まわりの実装が大幅に軽くなる。出典 ↗
アプリが所有する宣言型メタオブジェクトにアクセススコープが不要になり、インストール時のデータ移行が容易に。アプリ導入時の摩擦を減らす。出典 ↗
11メタフィールドとメタオブジェクト API の合理化重要度S日本：利用可2026-07以降+
メタオブジェクト（商品やページの外で持つ独自データ構造）の読み書きが、よりシンプルな GraphQL でできるようになります。従来は fields { key value } とフィールドを1個ずつ列挙し、配列や JSON は自分のコードで組み立てる必要がありました。新しい values プロパティでは、構造化された値がまとめて返り、更新（パッチ）も values 起点で部分的に書き換えられます。
結果としてコード量と取り違えが減ります。利用可能になるのは 2026-07 以降の API バージョンの見込みです。
ShopifyQL がドット構文でメタフィールドのディメンション・絞り込みをサポート。カスタムデータを使った分析クエリが書ける。出典 ↗
Shopify Functions でメタオブジェクトを参照し、カスタム割引や商品ルールを強化できる。設定値をコードに埋めずデータ側で管理。出典 ↗
cartToOrderCopyable を有効にすると、チェックアウト完了時にカートのメタフィールドを注文へ自動コピー。カート段階の付帯情報を注文に残せる。出典 ↗
組み合わせ可能な条件ソース・バリエーション条件・除外ルールに対応した自動コレクション。より柔軟な商品の自動分類が可能に。出典 ↗
べき等性（同じリクエストを何回送っても1回だけ反映）により、リトライ時の在庫の二重反映を防げる。在庫連携を組む開発者に効く。出典 ↗
permitsSkuSharing フィールドが廃止され、すべてのフルフィルメントサービスが複数ロケーションに在庫を配置できるように。出典 ↗
エージェントやターミナルから、自動認証付きで Admin API のクエリや Bulk Operations を実行できる。AI Toolkit と組み合わせると強力。出典 ↗
セマンティックバージョニングを採用。マイナー・パッチは自動更新、メジャーはオプトイン。CLI のバージョン管理が明快に。出典 ↗
既存の拡張機能を誤って削除せずに更新できる CI/CD パイプラインを設定できる。事故りやすいデプロイを安全に。出典 ↗
Dev Dashboard でトークンを作成し、CI/CD でアプリのリリースを自動化できる。デプロイの無人化に。出典 ↗
特定フィールドが変更されたときだけ Webhook を実行したり、カスタム GraphQL で必要なデータだけ受け取れる。無駄な発火と受信を減らせる。出典 ↗
アプリ独自のイベントを Shopify に送信し、Dev Dashboard で監視・管理できる。課金連動の土台にもなる。出典 ↗
Dev Dashboard の Webhook 監視が、複数選択での絞り込み・イベント数表示・カスタム時間範囲に対応。障害調査がしやすく。出典 ↗
開発ストア・移行ストア・コラボレーターストアを Dev Dashboard に集約して一元管理できる。出典 ↗
Dev Dashboard の UI・メニューが多言語化され、使い慣れた言語で開発できる。出典 ↗
7つのシステム役割でパートナーチームを管理でき、カスタム役割も作成可能。チーム運用の権限管理に。出典 ↗
アプリの管理画面の Web Vitals と Built for Shopify ステータスを Dev Dashboard で監視できる。出典 ↗
Bulk Operations で Admin API のクエリを最大4倍高速に実行できる。大量データの取得が速くなる。出典 ↗
Polaris（管理画面UIのデザインシステム）のドキュメントが刷新され、コードサンプル・ユースケース・メニュー構成が拡充。出典 ↗
ダッシュボードのチェック機能で、アプリストア申請前に問題を検出・修正できる。審査の往復を減らす。出典 ↗
1つの API（checkoutAndAccountsConfigurationUpdate）で、チェックアウト・お客様アカウント・ログインのブランディングをまとめて制御できる。出典 ↗
Shop Pay や Apple Pay などの高速チェックアウトで、ネストされたカート明細（アドオン商品）に対応。商品ページからアドオンを一緒に購入できる。出典 ↗
カート・チェックアウトのバリデーション機能で請求先住所と PO（発注）番号を照会し、B2B の要件を適用できる。出典 ↗
BXGY（Buy X Get Y）割引で、適用に必要な購入アイテムを前提条件フィールドで指定できる。複雑な条件付き割引が組める。出典 ↗
管理画面のUI拡張機能でディスカウントクラスを管理し、条件付きのUIをレンダリングできる。割引設定画面を独自に作れる。出典 ↗
ディスカウント一覧で一括操作（一括編集）を行う Admin Action 拡張機能を構築できる。大量の割引の運用に。出典 ↗
配達・フルフィルメント・注文ロジックと連携するアプリが、配送と店舗受取が混在する注文への互換性をテストできる（決済カテゴリー #03 の開発者側）。出典 ↗
POS 端末の通信が失われても、拡張機能の実行を継続できる。電波の弱い店舗・イベント会場でも止まらない。出典 ↗
ロケールを考慮した通貨・数値フォーマットと複数形対応で、POS UI 拡張を多言語化できる。出典 ↗
Camera API により、POS UI 拡張で ID スキャン・商品撮影・画像添付ができる。店頭オペレーションの幅が広がる。出典 ↗
チェックアウト・管理画面・お客様アカウント・テーマアプリ拡張に加え、POS UI 拡張の有効化ステータスも App API で照会できる。出典 ↗
レジ中心のAPI・理由コード・POS 拡張ターゲットで、カスタムな現金管理（キャッシュ・マネジメント）の拡張機能を構築できる。出典 ↗
販売チャネルアプリが、表示面（サーフェス）やアカウントごとに複数のチャネル連携を作成できる。出典 ↗
Shop アプリのホームフィード・トップメニュー・商品ページなど、より多くの表示面で Shop Minis（没入型の購買体験）を出せる。機能は構築可能だが、到達する消費者は Shop アプリ普及地域が中心。出典 ↗
インテント（Intents）で、Shop アプリと Shop Mini の間で商品コンテキストを受け渡せる。Shop Minis 開発者向け。出典 ↗
Customer Account API・Admin API を通じて、顧客の WhatsApp マーケティング同意（オプトイン／アウト）を保存・管理できる。WhatsApp 運用が前提。出典 ↗