ヘッドレスとは・採用判断
案件でヘッドレスを採用すべきかを、失うものと得るものを並べて判断できる
最終確認: 2026-09
解説
受託の現場でなぜ必要か： この回では、ヘッドレスを採用すべきかを、得るものと失うものを並べて判断できるようになります。
受託では「第一案はテーマ」が基本で、失うものと保守の体制まで見ずに提案すると、公開後に運用が止まります。
ヘッドレスとは、表示の部分だけを自分で作る構成
ヘッドレスとは、画面の表示（フロントエンド）を自前で作り、商品・カート・チェックアウト・注文はShopifyに任せる構成です。
その境界にあるのがStorefront API（ストアの公開データを読み、カートを作るための窓口）です。
チェックアウトは常にShopifyのページで行われ、自作はできません。
失うものと得るもの
失うものは、テーマエディタ（運用者が自分で編集する画面）と、アプリブロックや埋め込みなどのテーマアプリ拡張です。
さらに、sitemap・リダイレクト・robotsなど、オンラインストアが自動でやるSEOまわりも失います。
翻訳アプリなど、テーマがある前提の機能も使えません。
得るものは、UIの完全な自由度、既存サイトやアプリとの統合、複数ブランド・大規模トラフィック・特殊な体験への対応です。
費用と体制の目安
実装期間と保守は、テーマで作る場合の数倍かかります。
公開後もフロントエンド開発者が運用に入れる体制が無い案件では、破綻します。
費用だけでなく「誰が保守するか」を最初に確かめます。
受託ではどう判断するか
まず「テーマ＋Storefront Web Components（既存サイトに商品やカートをHTMLで埋め込む部品）で満たせないか」を検証します。
満たせない理由を文章で書けるときだけ、ヘッドレスを提案します。
「デザインの自由度」だけを理由にしません。
※ ShopifyはShopify Inc.の商標です。本サイトは個人が制作した非公式の学習教材であり、同社の承認・提携・後援を受けていません。記載内容は2026-09時点のものです。料金・上限値・管理画面のラベルは変わるため、作業の前に公式ドキュメントで確認してください。