Columns2026/07/13

Hydrogen＋Oxygenのメリット・デメリットを正直に語る ― 当社コーポレートサイトをHydrogenで作り直した理由

この記事でわかること

→ Hydrogen＋Oxygenの本当の強み（URL設計の自由・Oxygen無料・会員/セキュリティ強化ほか）
→ 正直に向き合うべき制約（アプリ非互換・テーマエディタ喪失・コスト・保守）
→ AI（Claude Code）が「専門人材が必要」という前提をどう変えるか
→ 当社がコーポレートサイトをHydrogenで作り直した判断軸

Shopifyでヘッドレスコマースを実現する代表的な構成が「Hydrogen＋Oxygen」です。Hydrogenがフロントエンドの開発フレームワーク、Oxygenがそれを配信するサーバー（エッジホスティング）を担います。

「ヘッドレスにすれば速くなる」「自由になる」といった語られ方をしがちですが、実態はもう少し込み入っています。本稿では、Hydrogen＋Oxygenのメリットとデメリットを、できるだけ誇張なく整理します。さらに、見落とされがちなセキュリティの観点や、「どんなユースケースに向いているのか」という判断の指針にも触れていきます。そして最後に、当社（Flagship）のコーポレートサイト自身をHydrogenで作り直し、2026年7月にHydrogen版をリリースするにあたって、私たちが何を重視したのかをお伝えします。

メリット：Hydrogen＋Oxygenの強み

1. URL構造・ルーティングを自由に設計できる

最も明確な強みが、URL構造の自由度です。従来のLiquidテーマでは、URLは/collections・/products・/pagesといった固定パスに縛られ、たとえば/collections/という接頭辞を外すことはできませんでした。

一方Hydrogenでは、React Router（旧Remix）のネストルートやキャッチオール（splat）ルートを使い、任意のURL構造を設計できます。/cartを/bagに、/collectionsを/categoriesや/brand、その他独自の体系に置き換える、といったことが自由にできます。サイトの情報設計やブランド体験、URLの一貫性を重視する場合、これは大きな差になります。

たとえば、サイト内にイベント情報のセクションを設けるとします。Liquidの場合、記事のURLはどうしても/blogs/events/hydrogen-seminarのように/blogs/という接頭辞が付いてしまいます。Hydrogenなら、これを/events/hydrogen-seminarと、余計な文字列を含まない素直なURLにできます。/blogs/や/collections/といった「システム都合の接頭辞」を排除し、サイトの構造をそのまま表す美しいURLを設計できるのは、地味ながら効いてくる利点です。URLは一度公開すると変更しづらい資産であり、ユーザーにとっての分かりやすさ（送られてきたURLを見ただけで、構造や意味を直感的に理解できる）にも、サイト全体の整合性にも影響します。

ここで一点、誤解のないように補足しておきます。言語ごとのURL割り当て――たとえば日本語を/（接頭辞なし）、英語を/en/配下に置く、といった構成自体は、Shopify Markets を使えばLiquidテーマでも実現できます（主言語をルートに、追加言語をサブフォルダに割り当てられます）。当社のHydrogen版サイトも日本語を/、英語を/en/に配置していますが、これ自体はHydrogen固有の利点ではありません。

Hydrogenの本質的な強みは、その先にあります。言語の割り当てにとどまらず、/eventsのような任意のパス構造や、ルーティングのロジックそのものを、自分たちで完全に設計・制御できる点です。「システムが用意したURL体系の範囲で設定する」のではなく、「URL体系そのものをゼロから設計する」ことができる――これがテーマとの本質的な差だと言えます。

ここで補足しておきたいのは、これは単に「見た目に美しいURL」という話ではない、ということです。スマートフォン中心のいまのUIでは、ユーザーがURLそのものを直接目にする機会はむしろ減っており、URLの綺麗さを表面的なメリットとして過大評価すべきではありません。本当に重要なのは、URL構造が「サイトをどういう情報のまとまりとして組み立てるか」という情報設計（インフォメーションアーキテクチャ）そのものを映すという点です。構造化されたコンテンツを提示することが主役になるサイトほど、「どんな構造で情報を持つか」を自分たちで設計できることの価値は大きくなります。URLを自由にできるということは、見た目を整える自由である以上に、サイトの骨格そのものを設計できる自由なのです（この観点は後半の「どんなユースケースに向いているか」でも改めて触れます）。

国内の実例：BONIQ（低温調理器ブランド）

この「URL体系をゼロから設計する」自由度は、実在する国内のHydrogenサイトでも確認できます。低温調理器ブランドBONIQの公式ストア（boniq.store）は、Shopify Hydrogen＋Oxygenで構築された数少ない日本のサイトのひとつで、URL構造を独自に設計しています。

たとえば次のようなURLは、いずれもLiquidテーマでは作れません。

/about/philosophy、/about/recruit ― 会社情報を/about/配下に階層化。Liquidのページは/pages/が必須で、こうした入れ子にはできません。
/journals/development/lowtemperature-cooking ― 読み物コンテンツを3階層かつ独自プレフィックス/journals/で構成。Liquidのブログは/blogs/{ブログ}/{記事}の2階層に固定され、これは不可能です。
/support/faq、/support/warranty-policy ― サポート関連を/support/配下に集約。

BONIQは、コンテンツを「読み物（journals）」「ストーリー（stories）」「会社情報（about）」「サポート（support）」といった自社の都合に合わせた情報設計で構成しています。Liquidが、すべてをpages・blogs・collections・productsという固定の枠に押し込むしかないのとは対照的です。バックエンドはShopifyのまま、フロントのURL体系だけを切り離して自由に設計できる――これがHydrogenの分かりやすい価値の一つです。

2. アプリのような体験を作り込める

ページ遷移が都度のフルリロードではなく、アプリのようなクライアントサイド遷移になります。フロントエンドのレンダリング層を完全に掌握できるため、独自のUI・インタラクション・カスタム404ページなど、体験の細部まで作り込めます。

たとえば当社のHydrogen版サイトでは、3D表現（Three.js）やページ遷移のアニメーション（GSAP）といった、リッチな演出を取り入れています。Liquidテーマでもスクリプトを書けば不可能ではありませんが、Reactのエコシステムと最新のフロントエンド開発環境（Vite、TypeScript、Tailwindなど）をそのまま使えるHydrogenでは、こうした作り込みが格段にやりやすくなります。「テーマの枠組みに表現を合わせる」のではなく、「実現したい表現に合わせて実装する」という発想で開発できる点が、Shopifyテーマベースの制作とは大きく異なります。本質論ではないかもしれませんが、こうした部分における開発者としての体験は、ShopifyテーマよりもHydrogenの方が格段に高いと感じます。

3. Oxygenホスティングが追加料金なしで使える

経済面で見逃せないのが、OxygenホスティングがShopify利用料に含まれている点です。Shopify公式の表現では「Oxygenは有料Shopifyプランで追加料金なしに利用できる」とされ、Basic・Shopify・Advanced・Plus・Pause and Buildの各プランが対象です（Starterプランと開発ストアは対象外）。

転送量（帯域）やリクエスト数による従量課金は公式に記載されておらず、VercelやNetlifyのように「ホスティング費＋転送量」が別途かかる構成と比べると、純粋なホスティングコストの観点では明確に有利です。GitHub連携のCI/CDやプレビューデプロイ、エッジ配信も含まれており、インフラ構築・運用の手間も抑えられます（なおGitHub連携のデプロイはGitHub Actions上で実行されるため、その実行時間にはGitHub側の利用枠・料金体系が適用されます）。

そしてもう一つ、コスト以上に大きいのが、Shopifyの強力なインフラにそのまま乗れるという点です。OxygenはShopifyが運用するグローバルなエッジネットワーク上で動き、世界中のユーザーに近い拠点からコンテンツを配信します。ブラックフライデーのような大規模なトラフィックの波をさばいてきたShopifyの基盤に、自社でサーバーを増強したりスケーリングを設計したりすることなく、追加料金なしで相乗りできるわけです。アクセス急増時の自動スケール、DDoSをはじめとする攻撃への備え、安定した配信――こうした「本来なら自前で多大なコストと専門知識を投じて構築・維持すべきもの」を、Shopifyのプラットフォームの一部として享受できるのは、ヘッドレス化のハードルを大きく下げてくれます。

ただし「無制限」と言い切れるわけではなく、ワーカー（バンドル）サイズ・CPU実行時間・メモリ・ファイルアップロードなどの上限は存在します。もっともこれらは、トラフィックの増加に応じて課金されたり枠が変動したりする従量的な制限ではなく、プラットフォームの仕様として定められた固定の技術的制限です。いずれも1リクエストあたり・1ワーカーあたりの仕様上の制約であるため、通常の運用の範囲では、アクセスが増えたからといって追加費用が発生したり、上限に抵触してサイトが動かなくなったりする性質のものではありません（ただし濫用とみなされる利用は、利用規約に基づきスロットリング等の対象になりえます）。

4. ネイティブのcheckoutと拡張がそのまま使える

Hydrogenはカートからの決済をShopifyネイティブのホスト型checkoutに引き渡します。そのため、Shop Payなどの決済体験はそのまま維持され、Checkout UI extensions（チェックアウト拡張）も、フロントがLiquidかHydrogenかに関わらず同じように機能します。checkoutはShopify側の実行環境でレンダリングされるため、ヘッドレス化の影響を受けません。

裏を返せば、Hydrogenを採用しても、チェックアウト画面そのものを独自のフロントエンドとして作り込むことはできません。決済は常にShopifyがホストするcheckoutで行われ、カスタマイズはその枠内（Checkout UI extensionsやブランディング設定）に限られます。もっともこれは、決済という最もセキュリティ要件の重い領域を丸ごとShopifyに任せられるということでもあり、制約というより設計思想として理解するのが正確です。

5. robots.txt・sitemap.xml・llms.txt まで自分でコントロールできる

意外と見落とされがちですが、検索エンジンやAIに対する「サイトの入口」となるファイルを、Hydrogenでは自分たちの手で完全にコントロールできます。

robots.txtやsitemap.xmlは、Hydrogenでは「ルート（route）」として扱われます。スケルトン（雛形）に最初から用意されており、sitemap.xmlはStorefront APIから商品・コレクション・ページのURLを取得して生成され、ページの追加・削除はおおむね1日以内に自動で反映されます。固定的なテーマ任せではなく、自社のサイト構造に合わせて出力を作り込めるわけです。

ただし「コントロールできる」ことと「実際に作り込む」ことは別である点には注意が必要です。Hydrogenは標準のrobots.txt（Shopifyのデフォルト相当のルール）を最初から備えているため、カスタマイズはあくまで任意です。そのうえで当社のHydrogen版サイトでは、これらを自前のルートとして実装しています。robots.txtは独自のURL構造に合わせたクロール制御に加えて、AIエージェント向けの案内（llms.txtへの参照）やサイトマップの場所を明示するよう構成し、sitemap.xmlは固定ページ・記事・ストアを分けたインデックス形式で自動生成しているほか、通常のサイトマップとは別にAIエージェント向けの専用サイトマップも用意しました。どこまで作り込むかは各サイトの判断に委ねられますが、こうした「入口」を要件に合わせて設計できること自体が、Hydrogenならではの自由度です。

さらに今、重要性が増しているのがllms.txtです。これは、ChatGPTやClaude、Perplexity、GeminiといったAIに対して「このサイトは何者か」を構造化して伝えるためのファイルで、Shopifyは数百万規模のストアに自動配備を進めています。Liquidストアでは設定不要で自動生成される一方、内容を細かく上書きする手段は基本的にありません。これに対しHydrogenではllms.txtもルートとして扱えるため、AIに何をどう伝えるかを自社で設計・上書きできる――これは現状、もっとも実用的なカスタマイズ余地を持つ構成だと言えます。多市場展開やB2B、会員限定カタログなど、自動生成では表現しきれない事情を持つブランドにとって、この自由度は効いてきます（llms.txtそのものの意義については、当社の別コラムでも詳しく解説しています）。

もっとも、これは前述のメリットと表裏一体です。「自分でコントロールできる」ことは「自分で正しく維持する責任がある」ことと同義であり、設定を誤ればSEOやAIからの見え方を損なうリスクもあります。

6. 会員ログインはShopifyに任せ、マイページは自由に作れる

会員機能（マイページ）についても、Hydrogenは「重い部分はShopify、見た目は自分で」という設計思想を貫いています。

ログイン認証そのものは、Shopifyの「顧客アカウント（Customer Accounts）」の仕組みをそのまま使えます。Hydrogenにはこのための専用クライアント（Customer Account API）が組み込まれており、ログイン時はShopifyがホストする認証画面へ遷移し、認証後に自社サイトへ戻ってくる、というOAuthベースの流れになります。これは、メールに届くコードやShopアカウントで認証するパスワードレスの「新しい顧客アカウント」で、パスワードの保管や認証まわりというもっとも神経を使う領域を、自社で実装せずShopifyに任せられるということです。決済と同じく、セキュリティ的に重い部分をプラットフォームに預けられるのは大きな安心材料です。

Shopifyがホストするログイン画面（当社サイト）

当社サイトへのログイン画面

一方で、マイページの画面（注文履歴、プロフィール、配送先住所など）は、自社で自由に作り込めます。データはCustomer Account API経由で取得し、UIは自前のコンポーネントとして実装するため、ブランドの世界観に合わせたマイページを設計できます。「認証はShopifyの堅牢な仕組みに乗りつつ、会員体験のデザインは自分たちの手で」という、両取りができるわけです（実際、当社のHydrogen版サイトのマイページもこの構成で実装しています）。なお、ログイン画面自体はShopifyホストのため見た目の自由度は限定的ですが、裏を返せば作り込む必要がない部分とも言えます。

7. 開発者体験（DX）が大きく向上する

これは見落とされがちですが、開発者にとっての「書き心地」も、HydrogenはLiquidから大きく前進します。後述するとおりHydrogenは習得コストが高い一方で、いざReactに習熟した開発者が触れる場合、その開発体験はモダンで快適です。

型安全性：HydrogenはGraphQLのスキーマから型定義を自動生成できます。クエリやデータにエディタの補完が効き、フィールド名の打ち間違いなどはコンパイル時に検出できます。Liquidにも構文チェック（Theme Check）はあり、文法エラーであればローカルやアップロード時に検出されますが、型の概念がないため、フィールド名の打ち間違いのような誤りはエラーにならず、実行時に空文字として黙って出力されます。誤りに気づくのは画面を描画してから（あるいは気づかないまま）ということが少なくありません。
モダンな開発環境：Vite（保存即反映のホットリロード）、TypeScript、Tailwind、ESLintといった現代的なツールチェーンをそのまま使えます。
コンポーネント指向：UIをReactコンポーネントとして再利用・合成・テストできます。Liquidのセクションやスニペットに比べ、大規模なサイトでも構造を保ちやすくなります。
エコシステムの開放：npmの膨大なライブラリ（前述の3D表現やアニメーションなど）を自由に組み込めます。
AIとの相性：標準的なReact／TypeScriptのコードベースであるため、Claude CodeのようなAIコーディングツールの支援が効きやすく、さらに型チェックが「AIの生成した誤り」に気づくための安全網として働きます。

つまりHydrogenは、「習得のハードルは高いが、超えた先の開発体験は強力で快適」という性格を持ちます。逆にLiquidは「学習は容易だが、できることの天井は低い」。この非対称性は、チームの構成や今後の開発方針を考えるうえで重要な判断材料になります。

8. データ取得・検索を自分で設計できる

商品数が多いサイトでは、「データをどこまで・どう取れるか」が地味に効いてきます。ここでも一点、誤解を解いておきます。

Liquidには取得上限があります。商品ループは既定で50件、paginateタグを使っても1ページ最大250件で、ページ送りは25,000件目までに制限されます。そして取得は「ページの描画時」に縛られ、取得するデータの中身（フィールドやネスト）を自分で制御することはできません。

一方、「Hydrogen（Storefront API）なら無制限に全部取れる」というのは正確ではありません。Storefront API自体も「1リクエスト最大250件」「ページネーションは25,000件目まで」という、Liquidと共通の上限を持っています。この天井そのものは、フロントを変えても同じです。

では何が変わるのか。柔軟性が上がる理由は、上限が外れることではなく、次の3点にあります。

クエリを自分で設計できる：必要なフィールドだけを、ネストした関連データも含めて、カーソルでコード側でまとめて取得し、サーバー側（Oxygen）でキャッシュ・加工できます。「描画時に縛られるページ送り」とは自由度が違います。
Admin APIとバルク処理が使える：Hydrogenはサーバー側で動くため、Storefront APIに無いデータや25,000件を超える全件が必要な場合、Admin GraphQL APIの「バルクオペレーション」で全商品・全注文を非同期に取得できます。Liquidはそもそもこれを呼び出せません。具体的な用途としては、Googleショッピング等へ渡す商品フィードの生成、Algoliaのような外部検索エンジンへの全件インデックス同期、全商品・全注文を対象にした集計データの事前生成などが挙げられます。バルク処理は非同期で完了まで時間がかかるため、リクエストのたびに実行するのではなく、定期ジョブで生成した結果を保存・キャッシュしておき、Hydrogenはそれを配信する、という形が現実解になります。
検索エンジンを自由に選べる：商品検索・絞り込みは、Shopify標準のSearch & Discovery（設定したフィルターはStorefront APIから利用可能）を使うこともできますし、大規模カタログで高速・高機能な検索が必要なら、Algoliaなどの専用エンジンや独自のフィルターロジックに差し替えることもできます。「検索層そのものを自分たちで選択・設計できる」のは、テーマにはない自由度です。

加えて、商品以外の独自の構造化データ（たとえば独自の一覧表や仕様データなど）を持ちたい場合、その置き場所も柔軟です。Shopifyの「メタオブジェクト」として持たせてStorefront APIから取得してもよいですし、自社や外部のAPIから取得して表示することもできます。ここで重要なのは、どのデータソースであっても、Hydrogenのローダー（サーバー側）で取得してレンダリングすれば、その内容は初期HTMLに含まれて配信されるという点です。つまり外部APIから持ってきたデータでも、サーバーサイドレンダリングを通せば、検索エンジンやAIのクローラーにそのまま読み取られます（ブラウザ側だけで取得・描画する方式だと、初期HTMLに載らず、クロールされにくくなります）。データの出どころに縛られず、SEO・AIフレンドリーな状態を保ったまま、自由に情報を構成できるわけです。

もう一つ、セキュリティ面の副次的な利点もあります。Shopifyテーマは外部データの取得に関しては完全にフロントエンド側の仕組みであるため、外部APIを呼び出す場合はブラウザから直接叩くことになり、APIキーの秘匿やCORSといった課題を、間にミドルウェア（プロキシサーバー等）を別途立てて解決するアーキテクチャが必要になりがちです。Hydrogenならサーバーサイド（ローダー）で外部APIを呼び出し、キーも環境変数として秘匿できるため、この種のアーキテクチャ上のオーバーヘッドを抱えずに済みます。

要するに、Hydrogenの強みは「取得上限が消えること」ではなく、「取得のしかた・検索のしかたを、自分たちの要件に合わせて設計できること」にあります。

デメリット：正直に向き合うべき制約

ここまでメリットを8つ挙げてきましたが、項目数の多さに惑わされないでください。以下のデメリットは、ひとつひとつが重く、場合によっては複数のメリットを帳消しにするだけの影響力を持ちます。大切なのは項目の数ではなく、それぞれが自社にとってどれだけ重いかで評価することです。

1. アプリエコシステムの一部が使えなくなる

Shopify App Storeのアプリの多くは、Hydrogenではそのまま動きません。多くのアプリはLiquidテーマへの注入（テーマアプリ拡張やScriptTag）によって機能するため、Liquidテーマ層を持たないHydrogenでは、取り付く先がないのです。レビューウィジェット、アップセルのポップアップ、ロイヤリティ表示、ライブチャットといったUI注入系のアプリが、これに該当します。

Hydrogenで使えるのは、独自のAPI／SDKとReactコンポーネントを提供する一部のアプリ（Klaviyo、Okendo、Recharge、Algolia、Gorgias、Rebuyなど）に限られます。Shopifyは「Hydrogen対応アプリ」を集めた公式コレクションを用意していますが、これは全アプリのごく一部にすぎません。さらに、これらの対応アプリも「インストールするだけ」では済まず、手作業での組み込み開発が必要です。たとえばメール配信のKlaviyoでは、Liquidなら自動取得される「商品閲覧」「カート追加」などのイベントを、Hydrogenでは自前で実装する必要があります。一部のベンダーがヘッドレス対応を上位プランに限定している点にも注意が必要です。

「これまで使っていたアプリ、あるいはこれから入れたいアプリが、Hydrogenで動くのか」は、ヘッドレス化の意思決定において必ず事前に確認すべきポイントです。

2. テーマエディタを失い、コンテンツ運用に別の仕組みが要る

Hydrogenには、Online Store 2.0のビジュアルテーマエディタ（ライブプレビュー）が存在しません。マーケティング担当者がバナーやコンテンツを管理画面から直接編集し、その場でプレビューする、という運用ができなくなります。

これを補うには、別途ヘッドレスCMSやビジュアルエディタ（Sanity、Builder.io、Pack、Storyblok、Weaverseなど）を導入する必要があります。逆に言えば、適切なCMSを組み合わせれば、マーケティングチームが自走できるコンテンツ運用環境を再構築することは可能です。ただしそれは「追加の選定・導入・運用コスト」を意味します。CMSを用意しないままヘッドレス化すると、バナー1枚の差し替えにも開発者の対応とデプロイが必要になり、これはヘッドレス化で「最も後悔しやすいポイント」としてしばしば挙げられます。コンテンツをどう運用するかは、技術選定と同じ重みで最初に設計すべきテーマです。

ただし、CMSの導入は単なる「テーマエディタの代替コスト」にとどまらない面もあります。SanityのようなヘッドレスCMSはコンテンツ管理の専業ツールだけあって、AIエージェントによるエージェンティックな情報更新にも対応するなど、テーマエディタにはない圧倒的な効率をもたらしてくれることがあり、むしろメリットが大きい場合もあります。実際、当社のHydrogen版サイトでも、キャリア関連ページは採用チームが自分たちで編集できるよう、Sanityを導入しています。

3. 開発・保守に専門人材とコストが必要

HydrogenはReact／GraphQL／SSRに精通した開発者を必要とします。Liquidが数日〜数週間で習得できるのに対し、Hydrogenの習得には数ヶ月を要するのが一般的です。結果として、初期構築費・3年総保有コスト（TCO）は、ネイティブのShopify構成のおおむね2〜3倍になるという試算が複数の事業者から示されています（数値はあくまで試算であり、規模により変動します）。

さらに、ヘッドレスストアフロントは「独自のアプリケーション」であり、継続的な保守が永続的に必要です。依存パッケージのセキュリティ対応、フレームワークのアップグレード、四半期ごとのAPI更新への追従など、ローンチ後に保守する体制と予算がなければ、技術的負債が蓄積していきます。

AI（Claude Codeなど）は、この前提をどこまで変えるか

もっとも、この「専門人材が必要」という前提は、AIコーディングツールの登場によって急速に揺らぎつつあります。Claude Codeのようなツールを使えば、足場（プロジェクトの雛形）づくり、コンポーネントの追加、GraphQLクエリの作成、よくあるバグの修正、見た目の調整といった作業は、フロントエンドの専門家でなくてもかなりのところまで進められます。コマースロジックが複雑になりにくいコーポレートサイトのような用途では、特にAIとの相性が良いと感じます。実際、Shopifyが2026年に打ち出したHydrogenの新方向も「エージェント（AI）対応」を掲げており、Hydrogen側もAIで扱いやすくなる方向に進んでいます。

一方で、AIがすべてを肩代わりしてくれるわけではない、というのも正直なところです。SSRやキャッシュ、ハイドレーション周りの込み入った不具合の切り分け、エッジランタイム特有の挙動、パフォーマンス最適化、セキュリティ、そして四半期ごとのAPI破壊的変更への追従――こうした「最後の2割」は、依然として一定の理解を必要とします。AIは、それらしく動くものの本番では破綻するコードを生むこともあり、その誤りに気づける目がなければ、かえって技術的負債を高速に積み上げてしまうリスクもあります。

私たちの見立てとしては、AIによって参入障壁は劇的に下がり、専門特化していないチームでも構築・運用に挑戦できる時代になりつつある、というのが結論です。ただし注意したいのは、保守の責任そのものが消えるわけではなく、「専門家が抱えていた負担」が「AIを使いこなし、その出力を検証する負担」へと形を変えて移動するだけだという点です。本番品質を担保するには、検証を徹底できる運用体制か、要所で専門家が伴走する体制が、引き続き有効です。「AIで作れるから安心」ではなく、「AIで作れる範囲が広がったぶん、どこを自分たちで持ち、どこを任せるかの設計が重要になった」と捉えるのが、現実的だと考えています。

4. 「自動的に速くなる」わけではない

よくある誤解ですが、Hydrogenにすれば自動的に速くなる、ということはありません。Shopify自身のパフォーマンスチームが「デフォルトではHydrogenはLiquidほど速くない」と明言しています。Liquidは長年のランタイム最適化により、標準状態でCore Web Vitalsの通過率が高い傾向にあります。Hydrogenが速さで上回るのは、フルページキャッシュやサブリクエストキャッシュ、データ取得・レンダリングを丁寧に作り込んだ場合に限られます。速さは「自動的に手に入る」ものではなく、「作り込んで獲得する」ものだということです。

セキュリティの観点：Shopifyが守る範囲と、自分たちで守る範囲

ヘッドレス化を検討するうえで見落とされがちなのが、セキュリティの責任分界点です。「自分でフロントを持つ」ということは、「守るべき範囲も一部自分で引き受ける」ということを意味します。ここを整理しておきましょう。

Shopify側が守ってくれる範囲（Hydrogen＋Oxygenで引き継がれる安心）

決済とPCI DSSの範囲：前述のとおり、Hydrogenでも決済はShopifyネイティブのホスト型checkoutに引き渡されます。クレジットカード情報を自社のフロントエンドが直接扱うことはなく、カード情報まわりのもっとも神経を使う領域は、引き続きShopify側の責任範囲にとどまります。これはヘッドレス化における非常に大きな安心材料です。
インフラ層の堅牢性：Oxygenのサーバー基盤のパッチ適用、DDoS対策、スケーリングといったインフラレベルのセキュリティは、Shopifyのプラットフォームが担います。自前でサーバーを立てる場合に比べ、OSやミドルウェアの脆弱性対応に追われる負担が大幅に減るのは明確な利点です。

むしろテーマより強くできる範囲もある

ヘッドレスは「責任が増える」一方で、テーマでは難しかったセキュリティ強化が可能になる面もあります。代表例がコンテンツセキュリティポリシー（CSP）です。HydrogenにはCSPを構築する仕組み（createContentSecurityPolicy）が標準で備わっており、nonce（ワンタイムの識別子）を用いて「許可したスクリプトしか実行させない」厳格なポリシーを敷けます。当社のサイトでもこの仕組みでCSPを適用しています。Liquidテーマの場合、サードパーティアプリが任意のスクリプトをページに注入するため、厳格なCSPの運用は現実的に難しいことが少なくありません。読み込むスクリプトを自分たちで完全に把握・制御できるHydrogenだからこそ、XSS（クロスサイトスクリプティング）への防御を一段高められる、という側面もあるのです。

自分たちで守る必要がある範囲（ヘッドレスで増える責任）

依存パッケージの脆弱性：Hydrogenストアフロントは多数のnpmパッケージの上に成り立つ「独自のアプリケーション」です。依存ライブラリに脆弱性（CVE）が見つかれば、それを追跡し、アップデートする責任は自社側にあります。Liquidテーマ中心の運用では基本的に意識しなくてよかった領域です。
自前コードの脆弱性：独自に実装したReactコンポーネントやAPI連携には、クロスサイトスクリプティング（XSS）などの実装由来の脆弱性が入り込む余地があります。フロントを自由に作れるということは、その安全性も自分たちで担保するということです。
APIトークン・シークレットの管理：Storefront APIの非公開トークンや各種APIキー、環境変数の管理を誤ると、情報漏えいや不正利用につながります。トークンの適切な権限設定、ローテーション、秘匿の徹底が求められます。

整理すると、「カード情報・インフラといった最重量級のリスクはShopifyが引き受けてくれる一方で、アプリケーション層のセキュリティは自社の責任として増える」という構図です。これは前述の「継続的な保守が必要」という話と表裏一体であり、依存パッケージの更新や脆弱性監視を含めて、ローンチ後も運用し続ける体制があってはじめて、ヘッドレスのセキュリティは健全に保たれます。逆に言えば、Shopifyという堅牢なプラットフォームを土台にできるからこそ、自社が集中すべきセキュリティの範囲を、アプリケーション層に絞り込めるとも言えます。

どんなユースケースに向いているか

ここまでを踏まえると、Hydrogen＋Oxygenが向いているケースと、そうでないケースは比較的はっきりしています。

向いているケース

URL設計やブランド体験の作り込みが、事業価値に直結する
中〜大規模で、専任の開発・保守体制と予算がある
標準のテーマでは表現しきれない、独自のフロントエンド体験を実現したい
商品の陳列・販売よりも先に、構造化された情報やコンテンツの提示が主役にあるサイト（コンテンツが起点で、ECはその延長として位置づけられる構成）

特に最後の点は重要です。Liquidは「商品・コレクションを中心に据える」コマース起点の設計思想で組まれているため、情報やコンテンツを主役にしたいサイトでは、どうしてもテーマの枠に窮屈さが生じがちです。これに対しHydrogenは、情報設計（サイトの構造やURL）を自分たちの意図どおりに主役として組み立て、そのうえにEC機能を自然に織り込めます。コーポレートサイトやブランドサイトのように「まず伝えたい情報・世界観があり、物販はその延長にある」構成では、Hydrogenの適性が際立ちます。

慎重に検討すべきケース

予算や納期が限られている
既存サイトが十分に高速で、転換率も健全
単一ブランドでシンプルな運用が中心
ローンチ後に継続して保守する人・体制が用意できない

これらに当てはまる場合は、無理にヘッドレス化せず、ネイティブのShopify（Liquid／Online Store 2.0）で十分なことも多い、というのが正直なところです。ヘッドレスは「新しいから良い」ものではなく、自由度と引き換えにコストと責任を引き受ける選択だからです。

当社がコーポレートサイトをHydrogenで作り直した理由

最後に、当社自身の話をします。Flagshipのコーポレートサイトは、2026年7月にHydrogen版をリリースしました。私たちは、まさに上で挙げた「向いているケース」と「デメリット」の両方を、自社の課題として天秤にかけました。

そもそも、数あるCMSやサイト基盤のなかから土台にShopifyを選んだ理由のひとつが、当社のコーポレートサイトが単なる会社案内にとどまらず、マーチ（グッズ）を販売するEC機能を備えている点にあります。コンテンツ発信と物販を1つのプラットフォームで完結させたい――その点で、コマース機能を標準で備えるShopifyは自然な選択でした。

そのうえで私たちがHydrogenを選んだ最大の理由は、URL構造とフロントエンド体験を自分たちの手で設計したかったからです。コーポレートサイトはコラム記事・事例・サービス紹介など多様なコンテンツを持ち、情報設計とURLの一貫性が、サイトの分かりやすさとブランドの信頼性に直結します。固定的なURL制約から解放され、アプリのような滑らかな体験を提供できること、そして物販（EC）とコンテンツを地続きの体験として設計できることは、私たちにとって明確な価値でした。

同時に、デメリットも承知のうえです。Reactベースの開発・保守は私たち自身が担い、テーマエディタを失う分はコンテンツ運用の仕組みで補い、必要なアプリ連携はAPI経由で実装する。保守し続けられる体制があるからこそ、ヘッドレスという選択に踏み切れたとも言えます。そしてOxygenのホスティングが追加料金なしで使える点は、その意思決定を後押しする要素のひとつでした。

「Hydrogenを採用すべきか」という問いに、唯一の正解はありません。重要なのは、自由度・コスト・保守体制という3つを自社の状況に当てはめて判断することです。当社のHydrogen版サイトも、ぜひその一つの実例としてご覧いただければ幸いです。

参考・出典

本コラムは、Shopify公式ドキュメントおよび各種一次情報（2026年7月時点）をもとに整理しています。コスト等の数値は試算であり、規模や要件により変動します。ヘッドレス化の検討やHydrogenでの構築について相談されたい場合は、お気軽に当社までお問い合わせください。