Themes / Liquid ・ developer preview

Liquid に {% block %} と {% partial %}
テンプレート 1 枚でページを組み立てる

Liquid July '26 developer preview で 2 つのタグが追加。ページ構造を Liquid テンプレートの中に直接書けるようになり、開発者もコーディングエージェントも「1 か所」を読んで直せる。既存のセクション/テーマ設定/JSON テンプレートはそのまま動く。

このページの構成
  1. 30 秒で理解 : 何が追加されたのか
  2. {% block %} : テンプレートから直接テーマブロックを描画
  3. {% partial %} : 部分だけを JS で更新できる領域
  4. 図解 : Liquid-first でページが組み上がる流れ
  5. 既存テーマとの関係(壊れない)
  6. Theme Check の新ルール
  7. 試す手順(3 ステップ)
  8. 技術者が押さえるべき 5 つのポイント
  9. 業務に活かせる 3 つのユースケース
  10. 提案で使える 1 行サマリ

130 秒で理解 : 何が追加されたのか

Liquid July '26 developer preview は、テーマページを組む「もっとシンプルなやり方」を導入する。
ページ構造を Liquid テンプレートの中に直接置けるようになり、開発者もコーディングエージェントも ひとつの場所ですべてを読んで編集できる。追加されるタグは 2 つだけ

{% block %}

再利用可能なテーマブロックを、テンプレートから直接描画する。ブロック名を指定し、入力(inputs)を渡し、body コンテンツを与える。書き味は {% render %} とほぼ同じ。

{% partial %}

サーバーレンダリングされた HTML の「名前付き領域」を定義する。JavaScript から、ページ全体をリロードせずにその領域だけを更新できる。

この 2 つを組み合わせると、ページの構成を Liquid で行いながら、動的なストアフロント体験も追加できる。レンダリングをクライアントサイドのフレームワークに移す必要がない、というのが今回の主張。

2{% block %} : テンプレートから直接テーマブロックを描画

テンプレート(Liquid) {% block "card" %} inputs(引数)を渡す body コンテンツを渡す {% endblock %} 名前で解決 再利用可能な テーマブロック テーマ側に定義済み 描画された HTML
1

名前を指定する

呼び出したいテーマブロックを名前で指定する。

2

inputs を渡す

そのブロックが受け取る入力値を渡す。

3

body コンテンツを渡す

中身のコンテンツも与えられる。{% render %} とよく似た感覚で書ける。

具体的な構文サンプル(引数の書式・終了タグの有無など)は元記事に記載なし。{% block %} リファレンスを参照すること。

3{% partial %} : 部分だけを JS で更新できる領域

従来 : 全ページ再読み込み 全部を作り直す 改善 partial : 名前付き領域だけ差し替え partial(更新対象) グレー部分はそのまま JavaScript サーバー描画済み HTML を 名前で取り直して差し替え フルリロード不要
ポイントは 「HTML はあくまでサーバー側(Liquid)で描画される」こと。動的な更新のためだけにレンダリングをクライアントサイドフレームワークへ移す必要がない、というのがこのタグの狙い。
更新のトリガー方法・JS API の詳細は元記事に記載なし。{% partial %} リファレンスを参照。

4図解 : Liquid-first でページが組み上がる流れ

Liquid テンプレート ページ構造をここに 直接記述 1 ファイルで完結 {% block %} テーマブロックを描画 {% partial %} 名前付き HTML 領域 サーバー描画 HTML を組み立てる Shopify 側 JS が partial だけ更新

5既存テーマとの関係(壊れない)

観点これまでのテーマアーキテクチャ今回の developer preview
セクション そのまま利用 継続して動作
テーマ設定 そのまま利用 継続して動作
JSON テンプレート そのまま利用 継続して動作
ページ構成の場所 JSON テンプレート+セクション等に分散 追加 Liquid テンプレートに直接置ける
位置づけ 既存アーキテクチャと並存する Liquid-first コンポジションモデル
置き換え(migration)ではなく 追加(alongside)。既存テーマに手を入れずに済むので、「新規ページだけ Liquid-first で作る」といった部分導入がしやすい。

6Theme Check の新ルール

プレビューでは Liquid-first テーマ向けの Theme Check ルールも追加される。検出対象として明示されているのは次の 5 つ。

構文エラー

Liquid の syntax error を検出。

過剰な複雑さ

複雑になりすぎたテンプレートを警告。

肥大化したファイル

サイズが大きすぎるファイルを検出。

{ }

不正な schema 構造

schema の構造が妥当でないケースを検出。

ブロック引数 / schema / {% doc %} の不整合

ブロックに渡している引数、schema の定義、{% doc %} 宣言の 3 者がズレているとき検出する。「ドキュメントと実装の乖離」が lint で落ちるのがこのルールの肝。

ルールの完全な一覧は Theme Check 3.28.0 のリリースノートに記載されている(元記事はそちらを参照するよう案内している)。

7試す手順(3 ステップ)

1

開発ストアを作る

Liquid July '26 developer preview を有効にした development store を作成する。

2

skeleton テーマから始める

skeleton theme の release candidate を出発点にする。

3
tag

または自分のテーマに追加

既存の自前テーマに新しいタグを足して試すこともできる。

これは developer preview。正式リリース時期・本番ストアでの利用可否・後方互換の保証については元記事に記載なし。フィードバックは Shopify developer community で受け付けている、とだけ案内されている。

8技術者が押さえるべき 5 つのポイント

1. 「読む場所がひとつ」が狙い

ページ構造が Liquid テンプレート内に置けるので、開発者もコーディングエージェントも 1 か所を読んで編集できると明記されている。AI に触らせる前提の設計思想が入っている。

2. 動的更新のために SPA 化しない

{% partial %} により、レンダリングをクライアントサイドフレームワークへ移さずに動的なストアフロント体験を追加できる。サーバー描画のままインタラクションを足す路線。

3. 既存アーキテクチャと並存

セクション・テーマ設定・JSON テンプレートは継続して動く。全面移行を迫られないので、新規ページや一部機能から段階的に試せる。

4. lint が同時に強化されている

Theme Check に Liquid-first 向けルールが追加。特にブロック引数/schema/{% doc %} の不整合検出は、テンプレートに構造を書く方式で起きやすい事故を先回りして潰す設計。

PREVIEW

5. 現時点では検証フェーズ。判断材料は 3 つのリファレンス

元記事が案内しているのは developer preview overview / {% block %} リファレンス / {% partial %} リファレンス の 3 点と、Theme Check 3.28.0 リリースノート。構文の詳細・制約・パフォーマンス特性は元記事に記載なしなので、提案前に必ず開発ストアで実物を確認すること。

9業務に活かせる 3 つのユースケース

USE CASE 1

キャンペーン LP を「1 ファイル」で作って回転を上げる

課題
期間限定 LP を作るたびに、JSON テンプレート・セクション・スニペットに構造が分散し、レビューも引き継ぎもファイル横断で追う必要がある。
打ち手
LP 用の Liquid テンプレートを 1 枚作り、{% block %} で既存のテーマブロックを並べてページ構成をその中に書き切る。
効果
構成が 1 か所に集約されるためレビューと差分確認が速い。制作〜公開のリードタイム短縮。
技術メモ
既存のセクション/JSON テンプレートは動き続けるので、この LP だけ Liquid-first という部分適用が可能。まずは開発ストア+skeleton テーマで検証。
USE CASE 2

「一部だけ更新したい UI」を SPA 化せずに実装する

課題
絞り込み結果やカート要約など「ページの一部だけ差し替えたい」要件のために、クライアントサイドフレームワーク導入という重い判断を迫られがち。
打ち手
更新したい範囲を {% partial %} で名前付き領域として定義し、JavaScript からその領域だけを再取得・差し替える。
効果
レンダリングはサーバー(Liquid)のまま。フレームワーク導入に伴う学習コスト・ビルド構成・保守負担を回避できる。
技術メモ
更新をどう発火させるかの具体 API は元記事に記載なし。{% partial %} リファレンスで先に確認してから見積もること。
USE CASE 3

テーマ品質の CI ゲートを Theme Check 3.28.0 で締める

課題
複数人・複数ベンダーでテーマを触っていると、巨大化したテンプレートや、schema と実際に渡している引数のズレが本番でしか露見しない。
打ち手
Theme Check を 3.28.0 に上げ、新ルール(構文エラー/過剰な複雑さ/肥大化ファイル/不正 schema/ブロック引数・schema・{% doc %} の不整合)を CI に組み込む。
効果
「ドキュメントと実装の乖離」がレビュー前に機械的に落ちる。属人的な目視レビューの負荷が下がる。
技術メモ
ルールの完全な一覧は Theme Check 3.28.0 リリースノート参照。既存テーマにいきなり全ルールを適用すると大量に警告が出る可能性があるため、段階的な有効化を推奨。

10提案で使える 1 行サマリ

「Liquid July '26 developer preview で {% block %} と {% partial %} が追加。
ページ構造を Liquid テンプレート 1 枚に書き切れて、一部だけの動的更新も SPA 化なしで実現できる。
既存のセクション/JSON テンプレートは壊れないので、新規ページから部分導入で試すのが現実的。」