Columns

Shopify Hydrogenの進化史と、この先の⽅向性 ― 独⾃設計からフレームワーク⾮依存の「ツールキット」へ

この記事でわかること

  • → Lady Gaga等の実例に見るHydrogenの可能性
  • → 独自RSC → Remix → React Router 7 という設計思想の変遷
  • → 2026年のツールキット化とVercel参画（Vercel Ship 26）の意味
  • → ベータ／GA時期と「React優先」という現実的な見立て

Shopifyのヘッドレスコマース向け開発基盤「Hydrogen」は、2021年の登場以来、その土台となる設計思想を幾度も大きく作り替えてきました。フロントエンドの技術トレンドを先取りしては軌道修正する、という大胆な意思決定の連続です。本稿では、Hydrogenがどのような道を歩んできたのか、そしてこの先どこへ向かおうとしているのかを、時系列で整理します。

ヘッドレス構成を検討中の事業者の方にとって、「いま採用したら、その技術は数年後どうなっているのか」を見立てるための材料になれば幸いです。

まず、Hydrogenで作られた実例を見てみる

歴史をたどる前に、「Hydrogenで実際にどんなサイトが作られているのか」を押さえておきましょう。机上の比較よりも、実例のほうが「何ができるのか」を直感的に伝えてくれます。

Lady Gaga（ladygaga.com）

最も象徴的な事例のひとつが、Lady Gagaの公式サイトです。従来は編集コンテンツ用のladygaga.comと、Online Store 2.0で作られた米国向けストアshop.ladygaga.comが分かれていましたが、これを1つのHydrogenサイトに統合しました。Hydrogenの柔軟性を活かし、3Dのアルバムショーケースや、ムード（雰囲気）に応じて変化する背景演出といった、通常のテーマでは難しい体験を実現しています。コンテンツ管理にはヘッドレスCMSのSanityを組み合わせ、編集体験とコマースを両立させました。

Shopifyの公式発表によれば、リニューアル直後にカート追加率が128％増、平均注文単価（AOV）が55％増を記録し、サイトはWebby Awardを3部門で受賞しています。「URL設計とフロントエンド体験を自分たちの手で作り込む」というHydrogenの強みが、ブランド体験そのものの価値に直結した好例です。

Allbirds

DTCブランドの草分けであるAllbirdsも、早くからHydrogenを採用してきた代表格です。サイトをHydrogenで刷新し、35カ国のストアフロントを50の実店舗と連携させた構成で運用しているとされます。グローバル展開とオンライン・オフラインの統合という、規模の大きなエンタープライズ用途でHydrogenが使われている例です。

Carhartt WIP（北米）

ワークウェアブランドCarhartt WIPの北米サイトも、Hydrogen＋Sanityの構成で構築された事例として知られています。エディトリアルなコンテンツとECを融合させたい、というニーズはHydrogenとヘッドレスCMSの組み合わせが得意とするところです。

これらに共通するのは、「ブランド独自の世界観や体験を、テーマの制約を超えて作り込みたい」という動機です。Hydrogenがどんな場面で選ばれているのかをイメージしながら、その進化の歴史を読み進めてみてください。

なぜ歴史を振り返る価値があるのか

ヘッドレスコマースは一度構築すると数年単位で運用する資産です。土台となるフレームワークが頻繁に方向転換する場合、その変化にどう向き合ってきたか（破壊的変更の有無、移行のしやすさ）が、長期の運用コストを左右します。Hydrogenはまさに「方向転換を繰り返してきた」フレームワークであり、その歩み方そのものが、今後を占う手がかりになります。

2021〜2022年：Hydrogen v1 ― 独自のReact Server Componentsという賭け

Hydrogenが最初に世に出たのは2021年です。当時の最大の特徴は、React Server Components（RSC）への大胆な賭けでした。Shopify自身が「RSCはHydrogenにおける最大の技術的な賭けだ」と表現していたほどです。

当時の熱量を象徴するのが、Hydrogenがお披露目された開発者向けイベント「Shopify Unite 2021」です。コロナ禍のためオンライン開催となったこのイベントで、CEOのTobi Lütke自身がステージでHydrogen（React）のライブコーディングを披露しました。経営トップが自らReactでコードを書いて見せるという演出は、Shopifyがいかに本気でReact／サーバーサイドレンダリングに賭けようとしていたかを物語っていました。

しかし当時、ReactのRSCはまだ公式実装が本番利用できる段階になく、Shopifyは独自のRSC実装で先行しました。その実装は、クライアントコンポーネントをラップしてレンダリング済みHTMLを再解析するという、いわばリバースエンジニアリングに近い方式で、Shopify自身も「非効率で脆く、ストリーミングもできない」と認めていました。それでも「Hydrogenとしては安定版として扱う」と宣言し、前進を選んだのです。

バンドラには、当時SSR対応がまだβ段階だったViteを、あえてWebpackより採用しています。RSC対応や開発体験の速さを優先した判断でした。

そして2022年6月、Hydrogenで作ったストアフロントを配信するためのホスティング基盤Oxygenが、Shopify Plus向けに正式提供（GA）されます（その後、対象は有料プラン全般へと広がります）。「開発フレームワーク（Hydrogen）」と「ホスティング（Oxygen）」をセットで提供する、という現在まで続く構図がここで生まれました。

2022年末〜2023年：Remixへの全面刷新 ― Hydrogen最大の転換点

Hydrogenの歴史で最も大きな出来事が、2022年10月31日に起こります。フルスタックWebフレームワーク「Remix」のチームがShopifyにジョインしたのです。

これを受けてShopifyは、Hydrogenの土台を独自RSC基盤からRemixベースへと全面的に作り替えるという決断を下します。2023年に登場したこの新バージョンは、設計思想が根本から変わりました。

  • データ取得の方式が変わった：v1ではコンポーネントツリーのあちこち（サーバーコンポーネント内）でデータを取得していましたが、新バージョンではルートごとの「loader」でまとめて取得するRemix流のモデルへ移行しました。
  • サーバー側の状態を優先する設計に：useStateやuseEffect、Contextプロバイダをほとんど使わない構成になり、新しいデモストアは「プロバイダがゼロ」になったほどです。
  • バージョニングの考え方も変更：セマンティックバージョニングをやめ、カレンダーバージョニング（例：2023.1.0）を採用しました。Shopify曰く「技術的にはHydrogen 2は存在しない。次のバージョンは2023.1.0だ」とのことで、いわゆる「v2」は通称にすぎません。

土台が変わる以上、v1からの移行には破壊的変更が伴いましたが、Shopifyは「移行は比較的容易にする」方針を掲げていました。同時に、Remixに依存しない汎用パッケージ@shopify/hydrogen-react（Reactコンポーネント、Storefront APIクライアント、コマース向けツール群）も用意され、Remix以外のReact環境でもHydrogenの部品を使える道が残されました。

2024〜2025年：React Router 7への統合

その後、Remix自体が「React Router 7に統合される」という方針へと進みます。React Router 7はRemixチームが作り上げた、Remix特有の制約を外したルーティング／データ層です。Hydrogenもこの流れに沿い、土台をReact Router 7へと移行しました（Hydrogen 2025系で反映）。

現在の整理としては、「React Router 7がルーティングとデータの土台、その上にHydrogenがコマース機能（Oxygenエッジランタイム、Storefront APIクライアント、カート、分析、Customer Account、B2Bなど）を載せる」という構造になっています。

また、HydrogenはStorefront APIおよびCustomer Account APIのバージョンに四半期ごとに追従しています（例：Hydrogen 2026.4.0はAPIの2026-04に対応）。最新のAPI機能を取り込めるメリットがある一方、四半期更新ゆえに破壊的変更も都度発生するため、継続的な追従作業は前提になります。

2026年6月：フレームワーク非依存の「ツールキット」へ

そして直近の大きな動きが、2026年6月17日に発表された開発者プレビューです。ShopifyはVercelと組み、Hydrogenを「フレームワークではなくツールキット」として再定義する方向を打ち出しました。キーワードは「framework-agnostic（フレームワーク非依存）、runtime-agnostic（ランタイム非依存）、そしてエージェント（AI）対応」です。

具体的には、次のような変化が示されています。

  • 特定のフレームワークに縛られない：Next.js、SvelteKit、Nuxt、Astro、SolidStart、React Routerなど、Reactに限らない複数のフレームワーク向けの実装例が用意される方向です。
  • どのランタイムでも動く：Shopifyの言葉を借りれば「fetchを呼べる環境なら、どこでもHydrogenは動く」。Oxygen、Vercel、Cloudflare Workers、Node、Denoなどが対象です。
  • 提供物がツールキット化：型付きStorefront APIクライアント、カートのプリミティブ、商品・コレクションのヘルパー、金額整形、Shop Pay、同意管理付きの分析、リクエストハンドラ、標準的なイベント／アクション、そしてエージェント向けのスキルなど。

Vercelがオープンソースのデザインパートナーとして参画 ― Vercel Ship 26

Vercel Ship 26（ニューヨーク）のステージに立つShopify VP of Product Vanessa Lee氏と、Vercel CPO Tom Occhino氏

Vercel Ship 26（ニューヨーク）に登壇したShopify VP of Product Vanessa Lee氏（Vercel CPO Tom Occhino氏とともに）。出典：Vercel

この提携は、約2週間後により具体的な形になりました。2026年6月30日にニューヨークで開催された「Vercel Ship 26」（ShopifyのVP of Product Vanessa Lee氏とVercel CPO Tom Occhino氏による対談「Building Agentic Storefronts」が行われました）で、VercelはHydrogenをオープンソースとしてゼロから作り直す取り組みをShopifyと共同で進めていることを発表し、これを「より開かれたWebへの、両社共通の賭け」と位置づけました。作り直されたHydrogenはGitHubの公開プレビューブランチで開発され、ランタイム非依存 ―― Vercelの表現では「JavaScriptが動く場所なら、どこでも動く」―― とされ、Svelte、Nuxt、Next.jsが名指しで挙げられたほか、「独自フレームワークの持ち込み」も想定されています。

課題設定は率直です。「Hydrogenはヘッドレスストアフロントを『作って出す』ことは簡単にしたが、『持ち運ぶ（ポータブルにする）』ことはできなかった」。従来版は特定のフレームワークとランタイムに縛られており、今回の作り直しはそのロックインを取り除くことを狙っています。アーキテクチャ上、新しいHydrogenは3つのレイヤーで整理されています。

  • Core（コア）：これまで各プロジェクトが個別に書いていた、Shopify API向けの共通JavaScriptユーティリティ群。たとえばShopifyのMoneyV2型を標準のIntl.NumberFormatに適合させるformatMoneyのようなヘルパーです。こうした「グルーコード」を一箇所に集約します。
  • Client（クライアント）：カート操作やフォーム処理といった状態・UIロジックを、プロジェクトごとの独自実装ではなく再利用可能なインポートとして提供します（プレビューブランチではReact向けが利用可能）。
  • Server（サーバー）：独自ランタイムに頼るのではなく、各フレームワークがもともと備える機能（キャッシュ、再検証など）を活かすフルスタック統合。このレイヤーは新しいコードというより、主にドキュメント・テンプレート・スキルとして提供される点が特徴で、フレームワーク側の標準的な仕組みを使うという思想です。

デザインパートナーが、Next.jsの開発元であり主要なフロントエンドホスティング事業者でもあるVercelである点そのものが示唆的です。Hydrogenのコマース中核を、Shopify自身のOxygenランタイムから意図的に切り離し、より広いJavaScriptエコシステムへと開いていく方向性を裏づけています。

ここで「何が本当に新しいのか」を正しく押さえておきましょう。実は、Storefront APIと@shopify/hydrogen-reactを使ってNext.jsなど任意のReactフレームワークでストアフロントを組むこと自体は、以前から可能でした。実際、VercelのNext.js CommerceテンプレートはShopifyを既定のバックエンドとして採用してきましたし、Hydrogen自体もShopify公式ドキュメントの範囲でVercel（やNetlify、Fly.io、Cloudflare Workers）にセルフホスト可能でした。競合という構図の裏で、両者のスタックは以前から相互運用できており、本当の摩擦は互換性ではなく、HydrogenがランタイムとしてのOxygenに結びついていた点にありました。今回の新しさは2点あります。ひとつは、Reactにすら縛られず、SvelteKitやNuxtといった非Reactのフレームワークまで視野に入れたこと。もうひとつは、Oxygen以外のランタイムでも動くようになり、「Hydrogen＝Oxygen専用」という結びつきがほどけたことです。

ただし、ここは冷静に受け止める必要があります。これはあくまで開発者プレビューであり、本番環境向けではありません。Shopify自身が「APIは今後変わる」「フレームワークバインディングはこれから増える」「既存のHydrogenは引き続き動作する」と明言しています。現時点での本番の正道は、依然としてReact RouterベースのHydrogenです。プレビューには「Shopify CLIからOxygenへのデプロイはまだ未整備」という但し書きもあります。報じられているスケジュールでは公開ベータが2026年第3四半期、正式版（GA）が2027年第1四半期とされ、プレビューはReact優先での提供です。つまりフレームワーク非依存・マルチフレームワーク対応（Svelte、Nuxt、独自）は、現時点では「出荷済みの現実」というより「宣言された方向性」だと捉えておくのが妥当です。

この先の方向性をどう読むか

歴史を俯瞰すると、Hydrogenの進化には一貫した「解きほぐし（decoupling）」の流れが見えてきます。

  1. フレームワークからの解放：独自RSC → Remix → React Router 7 → そして特定フレームワークに依存しないツールキットへ。
  2. ランタイムからの解放：Oxygen専用 → fetchさえあればどこでも動く設計へ。
  3. AIエージェント対応：ツールキットに「エージェント向けスキル」が含まれるなど、AIが扱いやすい構造を志向。

つまり、これまで「React Router on Oxygen」という固定的な組み合わせだったものが、「コマースの中核機能（Hydrogen）× 好きなフレームワーク × 好きなランタイム」という自由な組み合わせへと広がろうとしています。

一方で、注意すべきは変化の速さそのものです。Hydrogenは5年あまりで設計思想を繰り返し見直しており、その都度、程度の差こそあれ移行作業が発生してきました。最新の方向性は魅力的ですが、プレビュー段階の機能に飛びつくのではなく、安定版を見極めて採用する姿勢が、長期運用では賢明だと言えるでしょう。

まとめ

Hydrogenの歩みは、フロントエンド技術の最前線を取り込み続けるShopifyの姿勢の表れです。独自RSCという賭けから始まり、Remixの取り込み、React Router 7への統合、そしてフレームワーク非依存のツールキット化へ。次に検討すべきは「自社にとって、いつ・どの安定版で採用するのが最適か」という問いです。

参考・出典

※本記事の情報は2026年7月時点のものです。開発者プレビュー段階の機能は、今後仕様が変更される可能性があります。

Columns All