はじめに
Shopifyのテンプレートエンジン「Liquid」が、AIコーディングエージェントの力で53%の高速化を達成しました。
しかも、20年間にわたって数百人の開発者が改善を重ねてきたコードベースに対してです。
この記事は、以下のような方に向けて書いています。
- Shopifyテーマ開発でLiquidのパフォーマンスが気になっている
- AIエージェントをコード最適化に活用する方法を知りたい
- autoresearchという新しい手法に興味がある
この記事では、Shopify CEOのTobi Lutke氏が実行した「autoresearch」の仕組みと、具体的にどのような最適化が行われたのかを解説します。
autoresearchとは何か
autoresearchは、Andrej Karpathy氏が開発した手法で、AIコーディングエージェントに「数百回の半自律的な実験」を繰り返させるシステムです。
通常のAIコーディング支援は「このコードを直して」「この機能を追加して」のように、人間が具体的な指示を出します。autoresearchは違います。ベンチマークスクリプトを渡して「これを速くしろ」という抽象的なゴールだけを設定し、エージェントが自分で仮説を立て、コードを変更し、テストを実行し、ベンチマークで効果を測定するループを自動で回します。
具体的な流れはこうです。
- エージェントが最適化のアイデアを考える
- コードを変更してコミットする
- テストスイートを実行して正しさを検証する
- ベンチマークで速度を測定する
- 改善されていればキープ、悪化していればリバート
- 1に戻る
このループを120回繰り返した結果、93個のコミットが採用されました。
なぜLiquidが対象だったのか
Liquidは2005年にTobi Lutke氏自身が作ったRubyベースのテンプレートエンジンです。
Shopifyの全ストア、つまり560万以上のアクティブストアで使われています。
20年間で974個のユニットテストが蓄積されており、コードの正しさを保証する基盤が整っていました。
Simon Willison氏が指摘しているように、堅牢なテストスイートの存在がAIエージェントとの協業を可能にする「大きなアンロック」です。
テストがなければ、エージェントが加えた変更が既存の動作を壊していないかを自動で検証できません。
Tobi氏はコーディングエージェント「Pi」を使い、David Cortes氏と共同で開発した「pi-autoresearch」プラグインで実験を管理しました。
実験の状態はautoresearch.jsonlファイルに記録され、どの変更が採用/却下されたかを追跡できます。
53%高速化の中身 ― 具体的に何が変わったのか
PRのタイトルは「Performance: 53% faster parse+render, 61% fewer allocations」。
ThemeRunnerベンチマーク（実際のShopifyテーマテンプレートを現実的なデータでparse+renderする）での結果です。
アプローチの核は「アロケーション駆動」でした。オブジェクトが生成される箇所をプロファイリングし、不要なものを排除し、必要なものは生成タイミングを遅延させる。地味だけど効果的な手法です。
特にインパクトの大きかった最適化を見ていきます。
StringScannerの置き換え
LiquidのパーサーはRubyのStringScannerを使ってトークンを分割していましたが、これをString#byteindexに置き換えました。
シングルバイトのbyteindex検索は、正規表現ベースのskip_untilより約40%高速です。
この変更だけでparse時間が約12%短縮されました。
Shopifyのテーマ開発者にとっての実感としては、テンプレートの読み込みが速くなるということです。
特にセクションやスニペットを大量に使うテーマでは、parse処理の積み重ねが効いてきます。
Splat-freeなフィルター呼び出し
Liquidのフィルター（| dateや| moneyなど）が呼び出されるたびに、*argsによるArray生成が発生していました。
新しいinvoke_singleとinvoke_twoメソッドを導入し、引数が1つまたは2つのケース（全フィルター呼び出しの約90%）でArray生成を回避しています。
小さな整数のto_sキャッシュ
0〜999の整数に対して、事前に計算済みのfrozenな文字列を用意しました。
1回のrenderあたり267回のInteger#to_sアロケーションが不要になりました。Liquidテンプレートではループのインデックスやページネーションの数値表示で頻繁にto_sが呼ばれるため、地味ですが効果的です。
parse_tag_tokenのバイト処理化
{% %}タグが出現するたびに呼ばれていたStringScanner#string=のリセット処理を廃止しました。
テーマによっては878回も呼ばれていた処理です。手動のバイトスキャンに切り替えることで、StringScannerのリセット＋再スキャンのオーバーヘッドを排除しています。
560万ストアに影響するけど、大丈夫なのか？
正直、最初にこのニュースを見たときに思ったのは「怖くない？」でした。
AIが自動生成した93コミットを、560万ストアが使うエンジンにマージする。直感的にはかなりリスキーに聞こえます。
ただ、中身を見ていくと安全策がしっかり積まれていることがわかります。
もう少し具体的に見ていきます。
まず、autoresearchのループ自体が安全装置になっています。
974個のユニットテストが1つでも落ちた時点で、その変更は自動リバートされます。
120回の実験のうち27回が却下されているのは、この仕組みが実際に機能している証拠です。
次に、変更の性質がそもそもリスクが低い。
ロジックの変更（「処理の流れを変える」）ではなく、実装の最適化（「同じ処理をより効率的に書き直す」）です。
StringScannerをbyteindexに変える、配列生成を省く、文字列変換をキャッシュする。入力と出力は一切変わりません。
さらに、これはGitHub上の公開PRです。
Tobi氏がCEOだからといってレビューなしでマージされるわけではなく、コミュニティの目にも晒されています。
とはいえ、リスクがゼロとは言い切れません。
ユニットテストがカバーしていないエッジケースが存在する可能性はありますし、パフォーマンス特性の変化が特定のテーマ構成で予期しない影響を与える可能性もゼロではありません。ただ、それは人間がコードを変更する場合でも同じことです。
テーマ開発者は何もしなくていい
ここが一番嬉しいポイントです。テーマ開発者として、この恩恵を受けるために何かする必要は一切ありません。
Liquidの文法も、フィルターの使い方も、テンプレートの書き方も、何一つ変わっていません。
エンジンの内部実装が効率化されただけなので、既存のテーマコードはそのままで速くなります。
Liquidはサーバーサイドでテンプレートをrenderするため、この高速化はそのままTTFB（Time to First Byte）の短縮につながります。
特にセクションが多いトップページや、コレクションページのようにfor文が多用されるページで効果が出やすいです。
実際にクライアント案件でテーマパフォーマンスの改善に取り組んだ経験からすると、Liquidのparse/render時間はボトルネックの一つとして無視できない部分でした。それが何もせずに53%改善されるのは、率直に言ってありがたいです。
開発者としての学び
この事例から得られる教訓は大きく3つあります。
1つ目は、テストスイートがAI活用の前提条件だということ。
テストがなければ、エージェントがどれだけ賢くても「変更が安全かどうか」を自動で判断できません。
自分のプロジェクトでautoresearchのようなアプローチを試したいなら、まずテストを整えることが最優先です。
2つ目は、「速くしろ」がベンチマーク付きなら実行可能なゴールになるということ。
AIエージェントに曖昧な指示を出すと曖昧な結果が返ってきますが、計測可能な目標とフィードバックループを組み合わせれば、具体的な改善が積み重なります。
3つ目は、20年間触られてきたコードにもまだ改善の余地があるということ。
数百人のコントリビューターが手を入れてきたコードベースで53%の高速化が見つかるのは驚きです。
ただし、これは人間が無能だったのではなく、120回の実験を自動で回すという「量の暴力」によって、個々には小さいが積み重なると大きな最適化が見つかったという話です。
autoresearchを自分のプロジェクトで試すには
autoresearchの手法自体はシンプルなので、自分のプロジェクトにも応用できます。
必要なものは3つです。
- 信頼できるテストスイート（変更の安全性を自動検証）
- ベンチマークスクリプト（改善を数値で測定）
- コーディングエージェント（Pi、Claude Code、Cursorなど）
Tobi氏はPiを使いましたが、ベンチマーク結果をエージェントにフィードバックするループさえ組めれば、どのエージェントでも同様のアプローチは可能です。Karpathyのオリジナルautoresearchリポジトリにセットアップ手順があるので、興味がある方は参考にしてみてください。
さいごに
Shopifyの560万ストアを支えるLiquidエンジンが、AIエージェントの自動実験ループによって53%高速化された。
テーマ開発者としては、既存のコードを一切変更せずにパフォーマンス改善の恩恵を受けられるのが嬉しいポイントです。
それ以上に興味深いのは、autoresearchという手法がコードベースの最適化に対してここまで有効だったということ。
テストとベンチマークさえ整っていれば、自分のプロジェクトでも同じアプローチを試せます。
Shopifyテーマ開発のパフォーマンス改善やAIエージェント活用についてのご相談は、お問い合わせからお気軽にどうぞ。