まず、ここだけ

  • ShopifyはSwiftとKotlinのネイティブ回帰に合わせ、エージェントがアプリ挙動を検証できるReflexを構築した
  • 実機もシミュレータも使わず、1つのテストスイートでiOSとAndroidの同期を保つ
  • 中核はViewModelとIntrospection Kit、Transportによるネットワークゼロの強制だ

エージェントが当たり前にコードを書く前提へ、発想を戻した設計

エージェントがデバイスやシミュレータを必要とせず、iOSとAndroidをまたいでアプリの挙動を構築・検証できるようにする

Shopify Engineeringは2026年11月5日、公式ブログでReflexを解説した。きっかけはエージェントが画面を数分で書き上げる一方、その画面が正しく動くことを証明する工程がボトルネックになったことだ。ネイティブ回帰を進める中で、アプリはどう作られるべきかを根本から問い直した。

Reflexは、エージェントがアプリの状態を調べ、操作を実行し、結果を検証するまでの流れをアーキテクチャとして組み込む。著者のThiago Magalhaesは、画面の再構築を小さなチェックポイントと厳格なゲートで進めるHelixと並ぶ取り組みとして位置づけている。

  • エージェントが実機・シミュレータなしで挙動を組み立て、検証できる
  • iOSとAndroidで1つのテストスイートを共有し、同期ズレを防ぐ
  • 公式投稿は約16.7万回表示、1445いいね、2002ブックマークを記録

参照先[1][2]

コードではなくテストを共有する、ViewModelとIntrospection Kitの分業

Reflexの土台は、UIを方程式から外した契約にある。画面側はViewModelにactionを渡し、返ってくるstateを描画するだけの存在になり、ビジネスロジックはUIに依存しない。エージェントはこの契約越しにアプリを扱える。

外からViewModelを観察するのがIntrospection Kitだ。アプリの状態はツリーとして表現され、Transportがその読み書きを運ぶ。UIを起動せずとも、エージェントは構造化された状態をたどって検証できる。

項目内容
対象プラットフォームiOS / Androidのネイティブアプリ
テストの共有単位コードではなくテストスイートを共有
実行環境デバイス・シミュレータ不要
状態の窓口ViewModel（action in, state out）
外部観測Introspection KitがViewModelを外から観察
通信路Transportが状態ツリーの読み書きを運ぶ

参照先[2]

ネットワークゼロを強制し、失敗が読めるテストトロフィー

Reflexはテストの階層をテストトロフィーとして整理し、ネットワークを完全に排除した状態で実行する。外部要因が混ざらないため、落ちた理由が構造として読み取れる。テストは操作の羅列ではなく、ユーザーの一連の旅路のように記述される。

ブログのFAQでは、UIを検証しないテストの価値、XCUITestやEspressoとの併用、Appiumのようなデバイス自動化との違い、そしてオープンソース化の可能性まで踏み込んで論じられている。

  • ネットワークはゼロを強制し、再現性を担保する
  • 失敗は構造として読める形で返る
  • テストはジャーニーのように記述される
  • UIテストやデバイス自動化との役割分担がFAQで整理されている

参照先[2]

Shopify Reflexの公開ページ元のページを別タブで開いて確認できます
『Shopify Reflex』公式ページ・関連リンクを開く ↗

話題の元投稿

作者の投稿や紹介を、X で確認できます。

よくある質問

UIをテストしないテストに価値はあるのか

ReflexはViewModelと状態ツリーを契約として検証する。画面の描画に依存しないため、UIテストより壊れにくく、失敗の原因も読み取りやすいという立場を取っている。

参照先[2]

XCUITestやEspresso、Appiumの代わりになるのか

置き換えではなく役割の違いとして説明されている。デバイス上のUI操作を扱うツールに対し、Reflexはシミュレータなしで挙動と状態を検証する層を担う。

参照先[2]

参考リンク

  1. Shopify Reflex 関連ソース (1)x.com
  2. Shopify Reflex 関連ソース (2)shopify.engineering