【参加レポート Vol.2】Shopify DotDev 2026 — Liquidの未来編：人のためのLiquidは、エージェントのためのLiquidでもある

フロントエンドデベロッパーのRossellaです。Shopify DotDev 2026 参加レポートの第2弾をお届けします。Vol.1ではイベントの全体像と現地のハイライトをお伝えしました。今回からはテーマを一つずつ掘り下げていきます。最初に取り上げるのは、Vol.1のハイライトでも簡単に触れた、テンプレート言語Liquidの方針転換です。

今年のShopify DotDevのセッションの中で、Liquidの未来を扱ったセッションは、当初のスケジュールには載っていませんでした。開催の数日前に追加され、結果として同じ日に2回開催されることになりました。

登壇したのは、ShopifyでOnline Storeを担当するプロダクトディレクター、Ben Sehlです。彼はこの変更について、ポッドキャスト「Liquid Weekly」のインタビューでも語っています。

アプリ開発者向けが中心のラインアップの中で、テーマ開発者に向けた数少ないセッションの一つでした。この記事で少し詳しく書き残しておきたいと思った理由の一つは、そこにあります。

Benが語った内容、それが実務的に何を意味するのか、そして「今すぐ使えるもの」と「まだ形が定まっていないもの」の線引きを整理します。

全体像：LiquidからJSONへ、そして再びLiquidへ

BenがShopifyテーマに惹きつけられたきっかけは、Liquidそのものでした。ひと目で理解できるほどシンプルだったからです。長い間、Mark DunkleyのLiquid Cheatsheetさえあれば、テーマ開発者は十分に生産的に働くことができました。

その後、Sections Everywhereが登場し、JSONテンプレートが導入されました。

このトレードオフは当時としては理にかなっていました。Shopifyにはテーマエディタを動かし、設定サイドバーを機能させるためのシリアライズ形式が必要で、JSONはそのための正しい選択だったのです。

Benの言い方が印象に残っています。「デザインとはトレードオフである」。

Horizonの完全にJSON主導の構造は、その時代には正しい判断でしたが、可読性の面で大きな代償を払うことになりました。かつては1つのLiquidファイルを上から下へ読めば済んだページが、セクション・ブロック・ネストした設定オブジェクトのツリーに分散したロジックになりました。その多くはShopify管理画面のテーマエディタが自動生成したもので、「手動で変更すると上書きされる恐れがある」という警告が付いています。

このトレードオフの具体的なコストは、はっきり見えます。Benが新しいアーキテクチャでコレクションページを作り直したところ、行数はTimber（セクションが存在する前、プラットフォーム初期のShopify純正テーマフレームワーク）と同じになり、HorizonのJSON＋Liquid版が同じページに必要としていた行数を93%削減できました。JSONレイヤーは機能を追加していたわけではなく、純粋なオーバーヘッドだったのです。

そこでShopifyは方針を転換します。ページ構造をJSONから、読みやすいLiquidへ戻すのです。JSONがテーマエディタと設定サイドバーを動かす唯一の現実的な手段だった頃、Horizonは正しい選択でした。しかしその制約は、もはや同じ形では成り立ちません。だから構造がまた動くのです。

ここまでが可読性の観点からの理由です。しかし、この転換の背後にはもう一つ、より大きな力が働いています。ソフトウェアそのものの作り方の変化です。

命令的（インペラティブ）からエージェント的（エージェンティック）へ

命令的なソフトウェアでは、望む結果を得るために、ダイヤルを正確な位置まで回すように、すべてのパラメータを手で設定する必要があります。エージェント的なアプローチはこれを反転させます。「もっと大きな音で」と結果を記述すれば、そこへ至る方法はエージェントが考えるのです。

Benの核心的な主張は、優れた開発者体験は、優れたエージェント体験であるということです。両者は対立しません。Liquidを人が読んで心地よいものにしている性質（小さな語彙、予測可能な構造、平易な英語に近い構文）は、まさにモデルが正しく読み、正しく生成しやすい性質でもあるのです。

以下で紹介するすべて（新しい演算子、JSONではなくLiquidへ移る構造、より厳格なパーサー、型付きドキュメント、Tailwindサポート）は、この一つの考え方に遡ります。

引いて見れば、これがセッション全体の主題です。Shopifyは開発者を犠牲にしてLiquidをAI向けに最適化しているわけでも、その逆でもありません。この2つの目標は同じ方向を指しているという賭けをしているのです。優れたエージェントがうまく使える言語は、偶然ではなく、優れた開発者が使って楽しい言語でもある。以下のすべてを読むうえで、この主題を枠組みとして覚えておく価値があります。

何が変わるのか：Shopifyが注力する3つのこと

Benは取り組みを3つに分類しました。クリーンなコードを書くこと、ガイダンス、フィードバックです。ここからは技術的な詳細も含めて、それぞれに何が含まれるのかを見ていきます。

1. クリーンなコードを書く

Liquidには、ほとんどの言語が当然備えているものが欠けていました。ブーリアン、第一級の変数としての配列とハッシュ、正しい優先順位を持つ中置演算子です。これらの穴を埋めることで、そもそも言語を理解しづらくしていた種類の回避策を積み上げることなく、言語を進化させやすくなります。

{{ 1 + 1 }} => 2
{{ false && false || true }} => true

{% assign array = ["Hello", "world", "isn't", "this", "wonderful?!"] %}

2. ガイダンス

Shopifyは現在、規約に従わないテーマファイルをアップロード時に除外するようになりました。これにより、どのストアに入っていてもテーマの見え方と振る舞いが一貫し、コードに入った人（あるいはエージェント）は誰でも、その形をすぐに認識できるようになります。この一貫性は、いくつかの具体的な仕組みに支えられています。

AGENTS.mdとDESIGN.md。 AGENTS.mdは、テーマ固有の規約と、エージェントが犯しやすい間違い（自動生成されたJSONテンプレートを使わない、ブロック優先の構成、ユーティリティクラスのみのスタイリング、グローバルスコープのDOMアクセス禁止、など）を文書化したベーステーマのガイドです。テーマに触れるどのエージェントも、どの新しい開発者も、同じ地点から始められるようにするために存在します。DESIGN.mdは、テーマのビジュアルアイデンティティをエージェントに伝えるための仕様で、機械可読なデザイントークン（色、タイプスケール、余白、角丸）をYAMLフロントマターとして持ち、それらの値がなぜ存在し、どう適用すべきかを平易な言葉で説明する部分と組み合わせたものです。

JSONではなくLiquidテンプレート、そして新しい{% block %}タグ。 構造をLiquidに戻すことで、エージェント（あるいは開発者）はページ全体の構成を、JSONツリーをたどって再構築するのではなく、1つのファイルで読めるようになります。新しい{% block %}タグは、その構成を明示的にします。ブロックは名前付きパラメータとネストしたコンテンツを受け取ることができ、きちんと閉じタグを持ちます。考え方としてはReactのpropsとchildrenに近いものです。

{% block 'text', tag: 'h1', class: 'mb-2' %}
  {{ collection.title | escape }}
{% endblock %}

{% doc %}タグはこれと組み合わせて、型安全な契約を提供します。型付きの@param定義と、実際に動く@exampleブロックによって、スニペットやブロックはパラメータだけでなく「正しい呼び出しがどういう形か」まで、次に使うエージェントや開発者のために文書化できます。

Tailwind CSSサポートがLiquidテーマにやって来る。 Adam Wathan（Tailwindの作者で、ui.shチームでエージェントがより良い出力を生み出す方法についても多くの時間を費やしてきた人物）が1回目のセッションに同席していました。Shopifyの理由付けはこうです。共有された制約のあるスタイリングの語彙は、個別に作り込んだコンポーネントCSSよりも、人にとってもエージェントにとっても扱いやすい。

Agent Skills。 Benは、Liquidテーマ開発のためのClaude Agent Skillsをまとめたオープンソースのコンパニオンリポジトリ（benjaminsehl/liquid-skills）も公開しており、claude skill install --plugin shopify-theme-skills benjaminsehl/liquid-skills でインストールできます。Claude Codeでテーマ開発をしているなら、直接試してみる価値があります。

3. フィードバック

より厳格なLiquidパーサーは、かつて不正な構文が黙って予測不能な出力を生んでいた、旧「緩いパーサー」の曖昧さを塞ぎます。クリーンさに加えてここでの大きな動機は、エージェントが存在しないLiquid構文を「幻覚」で生成していたことでした。推測すべきエッジケースが少ない言語ほど、モデルが正しく書ける頻度は上がります。

リンターも、出荷前にエラーを捕まえる必要があります。Theme Checkには、契約、ファイル構造、バリデーション、Liquidの複雑さ／ネストをカバーする約20の新ルールが追加されました。そして{% doc %}タグによって、スニペットとブロックに型安全な契約を持たせられるようになりました。パラメータは一致していなければならず、ドキュメントの中に例を直接埋め込むことができます。

2つの大きな機能追加

クリーンなコード、ガイダンス、フィードバックは、言語の品質に関する取り組みです。それとは別に、磨き込みではなく新しい機能であるために、この枠組みから外れる変更が2つあります。そのうちの一つ、partialsは、今回のプレビュー全体の中で最も実用的なニュースと言ってよいでしょう。

partialsによるリアクティブな更新

partialsが登場する前は、カート内の点数のような単純なものを更新するだけでも、Section Rendering APIでヘッダー全体を取得し、morphdomのようなDOM差分ライブラリを走らせて実際に変わった一つの要素を特定し、さらにそれが取りこぼすエッジケースを処理するための追加のJSが必要でした。

Shopifyは新たなライブラリを追加するのではなく依存ゼロを維持したかったため、チームはまずRails Hotwireなど他のパラダイムを検討しました。最終的に行き着いたのが、Chromeチームのブログ記事「Declarative Partial Updates」です。有効なHTMLコメントを境界として使い、仮想DOMも追加のJavaScriptもなしに、ブラウザ自身が再レンダリングできるようにする手法を説明したものです。

更新が必要な領域だけを囲み、その領域の新しいHTMLを取得して差し替えます。

{% partial 'cart-count' %}
  <span>{{ 'cart.count' | t: count: cart.item_count }}</span>
{% endpartial %}

const html = await partials.fetch('cart-items', 'cart-count');
document.startViewTransition(() => partials.apply(html));

partialはサーバーサイドでも引き続きレンダリングされます。Liquidを通して処理され、一部のバリデーションは本当にサーバー側で行う必要があるためです。Benは、戻るボタンを壊さないIntersectionObserverを使った無限スクロールのページを、7行のコードで作れたと語りました。

partialsによって、Shopifyは新しいベーステーマからmorphdomのようなライブラリを完全に外すこともできました。これはJavaScriptペイロード削減のかなりの部分を占めます。Shopifyはこの提案についてChromeチームと直接協働し、現在は主要ブラウザすべてがこのアプローチで足並みを揃えています。それまでの間はpolyfillが利用できます。

これは現在Developer Preview（Liquid July '26）の段階です。APIは確定前に、フィードバックをもとにまだ形を整えているところです。

WebMCP対応のStandard Events and Actions

Standard Events and Actionsが全体像を締めくくります。一般的なストアフロント操作（たとえばカートの更新）のための、共有された型付きの契約です。

const { cart } = await Shopify.actions.updateCart({
  lines: [{
    merchandiseId: variant.id,
    quantity: 1,
  }],
});

この層を標準化することは、WebMCPサポートを可能にするものでもあります。エージェントやツールは、テーマごとに個別の連携を作る代わりに、ストアフロントのアクションを起動し、イベントを読み取るための文書化された手段を得ます。

こちらはすでにリリースされています（changelogを参照）。

今すぐ使えるもの

上記6つの要素を含めて、率直な現状を整理します。付随する2つの要素、テーマエディタそのものと、プロファイリング／デバッグツールは、別途遅れて追いついてくる段階です。

機能	状況	補足
ブーリアン式、中置演算子、配列／ハッシュ	未リリース	changelogやプレビュードキュメントにまだ記載なし。演算子の挙動（右から左へのand/or、括弧なし、算術はフィルタ）は現時点では従来どおり。
Partials（{% partial %}タグ、リアクティブ更新）	Developer Preview（Liquid July '26）	APIは確定前にフィードバックをもとに調整中。
{% block %}タグ／Liquidテンプレート（構造をJSONから移す）	Developer Preview（Liquid July '26）	エージェント的コーディングへの方向性を示す賭けであり、同じ四半期内での移行を求めるものではない。
AGENTS.md／DESIGN.md／Agent Skills	未リリース	執筆時点ではスケルトンテーマのリポジトリに含まれていない。*
Theme Check（新ルール20件）＋Docタグの契約	リリース済み	今日から利用可能。
Standard Events/Actions＋WebMCP	リリース済み（changelog）	エージェント／ツール連携を一貫させるための基盤。
Tailwind CSSサポート	発表済み、リリース日未定	開発者とエージェントが共有するスタイリングの語彙。
新アーキテクチャへのテーマエディタ対応	未対応、年内予定	現時点でコードファーストのテーマをアップロードすると、エディタには「セクションやブロックがありません」と表示される。
プロファイリング／デバッグツール	未対応、年内予定	—

* agents.md.liquidと混同しないでください。こちらは既存の別機能で、ショッピングエージェントがストアのコマース情報を見つけるためのものであり、テーマ向けのコーディングエージェント規約ファイルではありません。

これは正式には「Liquid July '26」Developer Previewで、2026年7月21日付です。自分で試すには、このプレビューを有効にした開発ストアが必要です。Shopifyは出発点としてスケルトンテーマのリリース候補（v2.0.0）も公開しており、Theme Check v3.28.0以降には{% block %}と{% partial %}タグに特化した新しいバリデーションルール（構文エラー、複雑さ、ファイルサイズ、スキーマ構造、引数の整合性）が含まれています。

繰り返し語られた安心材料が一つあります。「Liquid 3.0」は存在しないということです。Shopifyは意図的にこれらにバージョン番号を付けていません。破壊的変更への不要な不安を生まないためです。

これが何を意味するか

開発者の方へ

ここで紹介したものはすべて後方互換です。新しいアーキテクチャは自分のペースで採用できますし、採用しなくても構いません。既存のテーマは完全にサポートされます。一部はすでにプレビューストアでDeveloper Previewとして利用できるため、クライアントとの会話になる前に、手を動かして触り始めることができます。Claude Codeでテーマ開発をしているなら、benjaminsehl/liquid-skillsは今日から始められる具体的で無料の手段です。テーマエディタとプロファイリング／デバッグツールは、土台のアーキテクチャより遅れると考えてください。どちらも「年内」と明言されており、今ではありません。

マーチャントの方へ

何かが壊れるということではありません。現在のテーマは今日とまったく同じように動き続け、何かの対応を求められることもありません。Horizonが置き換えられるわけでもありません。パフォーマンス改善やpartialsのような機能で更新されていきますが、Shopifyに新たなフラッグシップテーマを作る計画はありません。戦略は、堅実なベーステーマとツールを提供し、その上にパートナーやエージェンシーが専門性の高いプレミアムな体験を構築する、というものです。

これが広く行き渡ったときの実務的なメリットは、より速いストアフロント（小さなJSペイロード、少ない依存関係）と、開発者にとっても、Sidekickのようなコパイロットにとっても、正しく手を入れやすいテーマです。

まとめとして、本質的にはこのトピックは、新しい構文の話ではありません。エージェント的な未来に備える最良の方法は、手で触るコードベースを良いものにしてきたものと同じ、すなわちシンプルで読みやすく、きちんと文書化されたコードである、というShopifyの賭けの話です。優れた開発者体験と優れたエージェント体験は、そもそも別々の問題ではなかったということに気づきます。

出典

1. Ben Sehl「Back to the Future with Liquid」：講演メモと関連記事
2. Ben Sehl、Liquid Weeklyポッドキャストインタビュー
3. Liquid Cheatsheet（Mark Dunkley）
4. Agent Skillsリポジトリ：benjaminsehl/liquid-skills
5. ui.sh
6. Shopify changelog：Liquid blockタグ・partialタグのDeveloper Preview