Shopifyテーマの「自由と制約」は、AIでどう変わるか ― Liquidへの原点回帰が示す過渡期

2026年7月、Shopifyの Online Store 担当プロダクトディレクター Ben Sehl 氏が「Liquid: Back to the Future」という一文を公開しました。要点はシンプルで、テーマのページ構造を、JSONテンプレートから“読めるLiquidコード”へ戻すという方向性の宣言です。あわせて developer preview（Liquid July '26）が公開され、新しい {% block %} や {% partial %} といったタグを実際に触れるようになりました。

この動き、機能の話として読むこともできますが、日々Shopifyテーマを触っている立場からすると、もっと大きな「テーマ設計の思想の揺り戻し」に見えます。この記事では、公式が示す未来像を紹介しつつ、実際に構築の現場でコードと格闘してきた視点から、「これは何を変えるのか／変えないのか」を考えてみます。

Shopifyテーマは「自由と制約」の綱引きで進化してきた

Shopifyテーマの歴史は、マーチャントの自由度とコードの可読性という、しばしば相反する2つのバランスを取り直し続けてきた歴史でもあります。ざっくり3つの時代に分けられます。

かつての Timber や初期のテーマは、コレクションテンプレートが100行程度で、コードを読めばページの動きが理解できました。ところが、マーチャントが自分でページを組み替えられるようにするために Sections が導入され、その構成を保存する形式としてテンプレートが JSON になりました。これでマーチャントの自由度は一気に上がりましたが、代償として、1つのページを理解するのに JSON・Liquid・スキーマ・設定・section・block を行き来しないといけない状態になりました。Shopify自身が「JSONテンプレートは手で編集しないように」と警告するほど、コードは“見通せないもの”になっていったわけです。

Horizon はこの流れの到達点で、マーチャントの自由度を突き詰めた結果として、テーマブロックの入れ子など非常に柔軟な構造を手に入れました。ただ、その柔軟性と引き換えに、コードカスタマイズの難易度は一段と上がったというのが、実際に触ってきた率直な感覚です。「どこをどう直せば、この見た目が変わるのか」を掴むまでの探索コストが、確実に増えました。

なぜ「Liquidに戻す」のか ― 設定の語彙には限界がある

Ben Sehl 氏の指摘で最も本質的だと感じたのは、「JSON が悪いのではなく、設定（config）という仕組みは語彙が有限である」という点です。設定駆動のテーマでは、開発者が「マーチャントが将来やりたくなるであろうこと」を先回りして想定し、その分の設定項目やブロックを用意しておかなければなりません。

記事の例がわかりやすいので引用します。ボタンが1つ置かれたセクションがあり、マーチャントが「隣にもう1つボタンを足したい」と考えたとします。設定駆動だと、あらかじめ「2つ目のボタン用の設定」や「複数ボタンを入れられる入れ物」を開発者が用意していないと実現できません。一方、素のHTMLなら <button> をもう1つ書いて <div> で包むだけです。

新しい {% block %} タグは、この思想を体現しています。名前付きパラメータ（Reactでいう props）を受け取り、囲んだ中身（children）を差し込め、{% doc %} で型まで付けられる。それでいて Liquid なので、1つのファイルを上から下へ読めます。「あらゆるマークアップを section や設定にしなくても、合成を明示的に書ける」ようになるわけです。

現場の実感：標準機能をこねくり回すより、独自で作る

この話は、私が最近感じている変化ともよく重なります。以前は「まずはテーマの標準機能の範囲で実現できないか」を第一に考えていました。今もその姿勢は基本ですが、標準の設定を組み合わせて無理やり実現しようとこねくり回すより、独自セクションを作ってしまったほうが早い、と判断する場面が増えてきました。特に、それほど複雑でないものであれば、独自実装のほうが結果的に見通しがよく、有益だと感じています。

AIコーディングの精度が上がってきたことも、この判断を後押ししています。「標準機能の設定の迷路」を探索するより、やりたいことをそのままコードにするほうが、道筋が素直になってきた。Liquid July '26 の方向性は、まさにこの「素直にコードで書く」を正式に後押しするものだと感じます。

ただし本当の難所は「AIの精度」だけではない

とはいえ、手放しで「これで何でも自由に作れる」とは思っていません。難しさは2つあります。1つはAIが正しく実装できるか。そしてもう1つ、こちらのほうが厄介なのですが、指示を出す人間の側が、正しく要件を言語化できるかです。

AIにコードを書かせる方式は、突き詰めると「自然言語で意図を伝え、AIがそれをコードに翻訳する」というワークフローです。ここで、意図が曖昧なままだと、AIもきれいに外します。設定UIの時代は、選択肢が有限だったぶん「選べる範囲」が制約として働き、ある意味で迷いを減らしてくれていました。自由度が上がるほど、今度は「何を作りたいのかを正確に定義する力」が問われます。自由の代償は、要件定義の重さとして跳ね返ってくるわけです。

「何でも新規生成」が最適とは限らない ― 資産の価値

自由度が高まると、「じゃあ全部AIで新規に作ればいい」と思いたくなります。ですが、ここには落とし穴があります。都度ゼロから作るのは、車輪の再発明になりがちだからです。

私たちが育ててきた独自セクション群（社内では「Booster」と呼んでいます）は、まさにこの逆をいく資産です。想定されるさまざまな要望や事象を、あらかじめ先回りして作り込んである。だからこそ、ある程度の要望はその場で即座に叶えられ、案件をまたいで使い回しがきく。作り込みのコストを一度払っておくことで、その後の即応性と再利用性を最大化しているわけです。

つまり、「先回りの作り込み（資産）」と「その場での自由生成（AI）」は、どちらかが正解というものではありません。使い回せる資産があるならそれを活かし、資産で賄えない固有の要望はAIで素直に作る——この見極めこそが、これからの構築の腕の見せどころになりそうです。

snippet ではなく「block」だから、資産を持ち運べる

ここで当然の疑問が湧きます。「ページ構造をLiquidコードに戻すなら、これまで section として作り込んできた資産（Booster）は、使えなくなるのでは?」と。結論から言うと、使えなくなりません。鍵は、新方式での再利用の単位が section ではなく {% block %} であることです。

この違いが決定的です。snippet は「表示の使い回し」しかできず、設定もエディタ連携もないので、Boosterのような機能を持った資産にはなり得ません。もし再利用の手段が snippet しかなかったら、Liquid-first のテーマは「素のHTMLをベタ書きした寄せ集め」にしかならなかったでしょう。

{% block %} は、section が持っていた「機能・設定・エディタ連携」を、JSONテンプレートから切り離して、Liquidコードに直接埋め込めるようにしたもの。いわば「機能の缶詰」です。だから、これまで section で作り込んできた資産は block として持ち運べ、{% doc %} の型契約が付くぶん、むしろ再利用しやすくなる面すらあります。

未来像は「完璧なAI」が前提 ― だから、今はまだ過渡期

Ben Sehl 氏が描く未来像は魅力的です。マーチャントは自然言語でAIに頼み、AIが読めるLiquidコードを生成する。開発者は、ブランドを本当に差別化する部分に集中できる。「マーチャントに必要な柔軟性」と「開発者にふさわしい可読性」を、AIが再び両立させる——という絵です。

ただ、この未来像は「AIが正しく・ブランドに沿って実装できること」を前提としています。だからこそ Shopify は、AIが間違えないための足場を同時に整えています。{% doc %} による型付き契約、20個の新しい Theme Check ルール、曖昧な構文を排する strict parser、テーマにAIへの指示を同梱する AGENTS.md / DESIGN.md。これらはすべて、「AIに自由を任せる」という賭けを成立させるためのガードレールです。

逆に言えば、これだけの足場を丁寧に用意しているということ自体が、「AIの実装はまだ完璧ではない」という現実の裏返しでもあります。私の見立てとしては、この方向性は正しいと感じつつ、今はまだ明確に過渡期だと捉えています。自由と制約のバランスは、AIによって「予測（先回りの設定）」から「実行時の生成」へと確かに移りつつある。けれど、その移行が完了したわけではなく、しばらくは設定駆動のテーマ（Horizon等）と新方式が併存しながら、少しずつ重心が動いていく段階でしょう。

過渡期の実例：block の設定を、マーチャントはどこで変えるのか

「過渡期」を、もう少し具体的な手触りで示しておきます。block を実際に触ると、すぐに1つの疑問にぶつかります。「block に持たせた設定（settings）を、マーチャントは画面でどう変えるのか。そして、その値はどこに保存されるのか」という問題です。

設計思想としての答えは用意されています。block は {% schema %} で設定を定義でき、公式も「テンプレートが決める値はパラメータで、マーチャントが決める値は schema setting で」と使い分けを示しています。つまり、マーチャントが画面で設定を触る体験は、ちゃんと想定されています。

ところが、ここからが過渡期です。Liquidテンプレートに直書きした block の設定値が、どこに保存されるのかが、現時点の公式ドキュメントでは判然としません。従来の JSON テンプレートなら、マーチャントが変えた値は templates/*.json に保存されました。しかし新方式のテンプレートは .liquid、つまりコードであり、変更された値を書き込む場所がそもそも見当たらないのです。

現実解としては、マーチャントの自己編集が重要なページは従来どおり JSON テンプレート／section で作り（新方式とは併存できることが公式に明言されています）、開発者やAIが主導するページを Liquid-first で組む、というハイブリッドに落ち着くのだろうと見ています。「全部を新方式に」ではなく、ページの性格ごとに使い分ける——それが、この過渡期の付き合い方になりそうです。

まとめ ― 過渡期の構築者は、何に向き合うか

Shopifyテーマは、「叶えたい要望を全ては叶えられない」という制約と、「それでも乗り越えたい」という要求のあいだで、ずっと揺れ動いてきました。Liquidへの回帰は、その綱引きに対してAIという新しい変数を持ち込む試みです。作る負担は軽くなり、そのぶん決める（言語化する）負担が増える。自由に生成できるようになるほど、活かせる資産の価値も際立つ。

だとすれば、過渡期を生きる私たちが磨くべきは、次の3つだと考えています。

• 要件を正しく言語化する力：AIへの入力設計そのもの。何を作りたいかを曖昧にしない
• 資産か、新規生成かの見極め：使い回せる作り込みは活かし、固有の要望だけAIで素直に作る
• 境界の設計：どこをマーチャント（やAI）が触ってよい領域にし、どこを固めるか。{% block %} はまさにこの“境界”を定義する道具

「未来への回帰（Back to the Future）」というタイトルは言い得て妙で、コードを読めばストアが理解できた原点に、AIの力を借りて戻ろうとしているわけです。まだ完成された未来ではありませんが、その方向に舵が切られたことは間違いなさそうです。developer preview は今すぐ試せるので、まずは自分の手で {% block %} や {% partial %} を触ってみて、この“過渡期”の手触りを確かめてみることをおすすめします。