Shopifyは2026年7月21日、オンラインストアのページ構造をJSONテンプレートではなくLiquidで記述できる開発者プレビューを公開した。新しいblockタグで再利用部品を組み合わせ、partialタグでページの一部だけをサーバー側から更新する。狙いは懐古ではない。商店主がAIアシスタント「Sidekick」に自然言語でテーマ変更を頼み、開発者もコーディングエージェントを使うようになった結果、テーマのファイル構成そのものがAIの編集インターフェースになったのである。
Shopifyが戻そうとしているのは、HTMLとLiquidを上から下へ読めばページの組み立てが分かる状態だ。型付きの引数、検査ルール、リポジトリ内の指示書も同時に整え、AIが間違えたときに具体的なエラーを返す。人間向けの開発体験とAI向けの設計が、同じ方向を向き始めた。
JSONで分かれたページを、一つのLiquidへ
現在のShopifyテーマでは、ページの構造をJSONテンプレートが持ち、各部品の描画をLiquidが担う。JSONはセクションを並べ、セクションのLiquidファイルには設定項目やブロックが入る。商店主はテーマエディタから部品を追加し、順番や見た目をコードなしで変えられる。一方、開発者がページ全体を理解するには、JSONとLiquidを往復し、スキーマからブロックまでをたどらなければならない。
ShopifyのStorefronts担当Product Director、Ben Sehlによると、この分離は2016年にSectionsを導入して以来、商店主へ編集の自由を渡すための合理的な選択だった。ただ、JSONテンプレートは人が設計意図を書き込む場所というより、テーマエディタが保存する構成データになった。AIエージェントにとっても、一つの変更に必要な文脈が複数ファイルへ散らばる。
「Liquid July '26」プレビューでは、新しい{% block %}タグがこの分断を縮める。テンプレートは呼び出すブロック名、引数、内側のHTMLをその場に記述できる。たとえば商品一覧ページなら、外側のコンテナ、見出し、商品カードの繰り返しが一つのLiquidファイルに並ぶ。開発者もエージェントも、ページ構造を上から下へ追える。
これはJSONという形式の否定ではない。問題は、設定データの語彙だけでは商店主が後から望む組み合わせをすべて表せないことにある。ボタンを二つ横に並べたくても、従来方式では開発者が二つ目の設定や両方を収めるブロックを先回りして用意する必要があった。Liquidテンプレートなら、HTMLのdivで二つを包むという局所的な変更で済む。
AIへの説明書が、人間の開発環境も整える
Sehlの公開値では、2026年に入ってから7月21日までにSidekickは2,500万件のテーマ編集に使われ、商店主の5人に1人がAIでテーマを変更している。集計対象や成功率は開示されていないものの、AIによるテーマ操作が実験的な少数利用を越えたことは分かる。Shopifyは、エージェントへ十分な文脈を渡し、誤った出力を検査できるようテーマ開発環境を作り直した。
新しいSkeleton Themeでは、各ブロックの冒頭に{% doc %}を置き、受け取れる引数と型、使用例を記述する。Theme Checkはその宣言と実際の呼び出し、スキーマの食い違いを検出する。Shopifyは契約や構造の検証に加え、複雑さからファイルサイズまでを対象に20個のルールを加えた。存在しない引数をAIが作れば、原因の分からない失敗ではなく修正に使えるエラーを返せる。
リポジトリのAGENTS.mdも同じ役割を持つ。公開中のSkeleton Themeでは、JSONテンプレートやセクションを追加しないこと、表示文字列を翻訳キー経由にすること、ストア内URLをハードコードしないことなどを明記している。個々のファイルから読み取れない設計上の約束を、開発者とエージェントが共有するためだ。
Shopifyの設計が興味深いのは、AIに長い説明を毎回与えるのではなく、コードの近くに契約を置き、機械検査で閉じる点にある。型付きドキュメントと静的検査は以前から人間の開発者が求めてきた仕組みでもある。AI向けの特別なコード層を足すのではなく、人が読み、ツールが検証できる開発環境を整えた。
blockとpartialが変える実装の境界
{% block %}は、既存のテーマブロックをLiquidテンプレートから直接呼ぶ新しい配置方法である。名前付き引数や本文を渡せるため、Reactのpropsやchildrenに近い組み立て方ができる。ただし、ブラウザ上に仮想DOMを置く構成ではない。Liquidがサーバー側でHTMLを生成し、通常のHTMLとWeb Componentsがブラウザ上の動作を受け持つ。
商店主がテーマエディタで自由に追加・並べ替えする領域は、引き続きcontent_forとJSONが担う。テンプレート側が構成を決める場所はblock、エディタ側が決める場所はcontent_for、設定を持たない内部の再利用コードはrenderという分担になる。新タグは既存の部品モデルを捨てず、誰がページ構成を決めるかをコード上で分ける。
もう一つの{% partial %}は、商品一覧やカート件数のように変化する範囲へ名前を付ける。JavaScriptはその名前で新しいサーバーレンダリングHTMLを取得し、対応する領域だけを差し替える。従来はSection Rendering APIの応答をクライアント側のコードでDOMへ結び直していたが、partialでは領域名が取得と置換の契約になる。全ページの再読み込みも、クライアント側で同じ画面を再構築する処理も避けられる。
それでもJavaScriptは消えない。Shopifyの資料は、遅い古い応答が新しい表示を上書きする競合、読み込み中の表示、スクリーンリーダーへの通知を実装側の責任として挙げる。開閉中のメニューなどDOMにしかない状態も、置換後に復元しなければならない。partialが減らすのは部分更新の配線であり、非同期UIに伴う設計とアクセシビリティまで自動化する機能ではない。
93%削減を、そのまま生産性と読まない
Sehlは、新しいベーステーマのコード行数が現行のHorizonより93%少ないと説明した。数字は大きい。だが、両者は同じ完成度のテーマを新旧方式で実装した比較ではない。新しいSkeleton Themeは、ブロック、テンプレート、基本CSSなどに絞った出発点であり、READMEでも「最小」を掲げる。Horizonは豊富な機能とデザインプリセットを含むShopify製テーマの旗艦である。
したがって、93%は新しい構成がどれほど小さく始められるかを示す値であって、移行すれば保守工数が93%減るという測定ではない。ブランド固有のページや部品を作り、スタイルを足せばコードは増える。比較すべきなのは、同じ変更を完了するまでに開くファイル数と修正回数である。検査で捕捉できた誤りや公開後の不具合も測る必要がある。
導入段階にも線を引く必要がある。既存テーマでは、セクションと設定もJSONテンプレートも引き続き動作し、移行は強制されない。新タグを試すには「Liquid July '26」の機能プレビューを選ぶ必要があり、タグの挙動とJavaScriptヘルパーは一般提供までに変わる可能性がある。Shopifyは一般提供日を公表していない。
今回の再設計は、AIがコードを書く量を増やす話より、AIが変更可能な範囲を読めるコードと明示的な契約で囲う試みとして見る方が正確だ。一般提供へ進むかを判断する材料は、派手な行数削減ではない。実際のストアでのテーマ編集で、Sidekickと開発者向けエージェントが少ない手戻りで変更を完了し、その結果をTheme Checkと人間が検証できるかどうかである。