Tray vs Shopify 2026：HTML、カスタマイズ、連携の限界（と移行すべきタイミング）

要点（BLUF）

Trayは「閉じすぎていて使いものにならない」わけではありません。ただ、立ち上げ期を過ぎたブランドストアや広告主導の運用が必要とするものを、ちょうど止めてしまう程度には閉じています。ストアフロントでのHTMLとJS、テーマの細かなカスタマイズ、そして汎用アプリやGTMを松葉杖にしない連携です。

公式のプランページでは、Lançamento（ローンチ）プランのカスタマイズは ビジュアルエディタ と記載されています。HTMLとCSS が出てくるのは Crescimento（成長）プランからです（Trayのプラン）。HTMLが使えるプランでも、公式ドキュメントはコードを編集する前に 公開中のテーマを複製する よう指示しており、サポートはこうした編集を 支援しません。また pages/、layouts/、configs/ にファイルを 作成・削除することはできません（HTMLの編集、HTMLでの編集）。

比較対象として有用なShopifyは、Liquidのテーマに、エディタではTheme App Extensions、決済ではCheckout UI Extensionsを備えています（Theme App Extensions、Checkout UI Extensions）。コストは重要ですが、ここでは技術的な上限の 結果 であり、中心的な主張ではありません。

---

Trayでストアを運営しているなら、開発者や代理店から次のような言葉を聞いたことがあるはずです。

1. 「色とバナーは変えられますが、そのレイアウトのルールはエディタに収まりません。」
2. 「パートナーのピクセル/スクリプトはGTM経由でしか入れられず、チェックアウトでの発火は保証できません。」
3. 「そのWebhook/独自の同期には、認定アプリとサポートへの問い合わせが必要です。」
4. 「公開中のテーマは編集できません。複製してコピーを直し、再公開する必要があります。」

どれも「Tray嫌い」から出た言葉ではありません。ドキュメントに書かれた制限か、プラットフォームのモデルがもたらす副作用です。この記事の残りでは、これらの制限を HTML/JS、テーマのカスタマイズ、連携 の3つの軸で整理します。Shopifyは、比較によって判断が変わる箇所で対比として登場します。最後に、上限がすでに高くつきすぎていないかを判断する補助として、コストを取り上げます。

---

1. HTMLとJavaScript：Trayが実際に開放しているもの

プランという関門

コードの品質を論じる前に、Tray自身が何を販売しているかを見てください。

出典：tray.com.br/planos。ストアが入門プランで、要件に独自HTMLのランディングページ、商品ページのJSコンポーネント、テンプレートの細かな上書きが含まれるなら、話はエディタではなくプランのアップグレードから始まります。

公式のコード編集フロー

HTMLが使える場合、Trayが文書化している手順は次のとおりです。

1. 公開中のテーマは 編集しない。
2. テーマを 複製する。
3. コピーで Editar HTML（HTMLを編集）を開く。
4. そのあとでコピーを公開する。

ナレッジベースははっきり書いています。カスタマーサービスはこうした編集を 支援しません。自分でプログラミングできるか、誰かに依頼するかのどちらかです（テーマのHTMLを編集する方法）。

実務では、これが3つの摩擦を生みます。

• サイクルが遅い。 本格的な変更はすべて、複製 → 編集 → テスト → 公開という流れになります。モダンなテーマ開発のような、ブランチとプレビューによる継続的な流れにはなりません。
• デグレのリスク。 Twig/HTMLを触ってプラットフォームの必須マーカーを消すと、モジュール、SEO、アナリティクスが壊れます。テーマのドキュメントは、標準化された構造とプラットフォームの動作規約を強調しています（テーマを理解する）。
• ファイルの上限。 HTMLでの編集では、pages/、layouts/、configs/ にファイルを 作成・削除できません。テーマのインストールは 25個 までです（HTMLでの編集）。独自のランディングページ、新しいレイアウト、構造的な設定は「ファイルを作れば終わり」とはいきません。

JavaScriptとサードパーティのスクリプト：GTMが正面玄関

Trayは、Configurações → Integrações → Ferramentas Google（設定 → 連携 → Googleツール）を通じて テーマのHTMLを編集せずにコードを追加する 方法として、Googleタグマネージャーを案内しています（GTMの連携）。GA4、広告、ピクセルには便利です。同時に、これはアーキテクチャ上のサインでもあります。ストアフロントは、head/bodyに自由にコードを差し込める遊び場ではない ということです。

運用でよく痛みが出るのは次の点です。

• Metaピクセル、アフィリエイトのスクリプト、チャット、ヒートマップ、A/Bテストが GTMの中で競合し、発火順序、同意管理、CSP/nonceの問題が起きます。
• チェックアウト、カート追加、購入のイベントは、安定したdataLayerに 依存します。決済ページやアカウントの流れが変わると、ストア側が気づかないうちにタグが壊れます。
• テンプレートの 内側 で動く必要があるスクリプト（ファーストビュー、CLSへの影響、商品のLiquid/Twigの読み取り）は、「GTMだけ」のモデルに収まりません。

Shopifyとの対比。 テーマでは、Liquid + アセット + Theme App Extensionsによって、マーチャントがテーマの途中にコードを貼り付けることなく、エディタからストアフロントにUIとロジックを追加できます（Theme App Extensions）。チェックアウトについては、決済ステップにバラバラのスクリプトを置くのではなく、Checkout UI Extension が公式の方法です（Checkout UI Extensions）。言いたいのは「Shopifyならheadを好き勝手にいじれる」ではありません。ほぼすべてをGTMと複製したHTMLに押し込むのではなく、ストアフロントとチェックアウトを正式な拡張機能で切り分けている、ということです。

---

2. テーマとストアフロントのカスタマイズ

Twig + ビジュアルエディタ：レールの上の自由

TrayのテーマはTwigとHTML、CSS、JavaScript、JSONを使い、ディレクトリ構成はプラットフォームが定めています（テーマを理解する）。ニッチなテーマを作ってテーマストアで販売することもできます。それは同時に、ストアが自由なフロントエンドフレームワークではなく、Trayのレールの上で動くことを意味します。

ビジュアルエディタ（Tema Padrão 3.0などでのセクションのドラッグ＆ドロップ）が得意なこと：

• バナー、商品一覧、ブランド、フッター、お知らせバー
• 開発者なしでのセクションの並べ替え
• HTMLを知らないストア運営者による見た目の調整

得意でない こと：

• 独自のUXを持つ商品レイアウト（サイズ診断、コンフィギュレーター、セット組み立て）
• テーマが公開している範囲を超えた構成のキャンペーンページ
• テーマやストアフロントのAPIが公開する範囲を超えた、クライアント側の状態に依存するコンポーネント
• タイポグラフィ、モーション、コンポーネントをLP、コレクション、チェックアウトで共有する独自のデザインシステム

ストア運営者が日々感じること

正しい問いは「Trayにきれいなテーマはあるか」ではありません。あります。問うべきは、ブランドの要件のうち、どれだけがエディタと許可されたTwigの範囲に、無理やりな回避策なしで収まるか です。

答えが「半分以下」なら、そのストアはすでに、ブランドを加速させるためではなく、プラットフォームを回避するために代理店へお金を払っています。

---

3. 連携：API、Webhook、アプリ、チェックアウト、ピクセル

APIとWebhook

Trayには開発者エコシステムとAPIがあります。通知システム（Webhook）は、認定アプリ に登録されたURLへ、seller_id、scope_id、scope_name、act、app_code、url_notification を含む application/x-www-form-urlencoded 形式の POST を送ります（Tray Developers）。

実務上の意味：

• 「本格的な」連携は アプリ を通すことになり、ストア運営者が管理画面に貼り付ける単独のエンドポイントでは済みません。
• ペイロードは、多くのエンジニアリングチームが標準で想定する型付きのJSONでは ありません。パースを誤ると、同期が黙って止まります。
• 基本（注文、在庫、商品など）を超えるスコープは、多くの場合 有効化 とリトライの規律が必要です。URLが200を返さなければ、プラットフォームは再送します。

ERPやマーケットプレイス連携ハブには十分です。重くなるのは、次のようなことをしたいときです。

• 公開アプリなしの自前の自動化（n8n、独自のワーカー）
• 安定した仕様を持つ、ストアフロントの細かなイベント（view_item、begin_checkout）
• 独自のUIを持つチェックアウト拡張

Shopifyとの対比。 Admin API（REST/GraphQL）、JSONのWebhook、アプリ拡張、成熟したApp Store。ストアフロントにはTheme App Extensions、決済にはCheckout UI Extensions。仕様が公開され、バージョン管理され、サードパーティのアプリ向けに作られているため、エンジニアリングのコストが下がります。

チェックアウト：カスタマイズのブラックホール

チェックアウトは、テーマで「ほぼ開放されている」HTML/JSが 通用しなくなる 場所です。

Trayの典型的な運用では、決済、配送、不正対策はプラットフォームと標準アプリが提供するもので済ませます。ステップごとのカスタマイズ、税務用の追加項目、決済時の標準的なアップセル、重要なステップでの信頼性を高めるUIといった要望は、たいてい次のどれかになります。

• Trayのマーケットプレイスのアプリ
• 壊れやすいトリガーを使ったGTM経由のスクリプト
• または「できません」

Shopifyでは、チェックアウトのカスタマイズは、いつまでも使える checkout.liquid ではなく 公式の拡張機能 へと移っています。テーマのアプリブロックはチェックアウトページには表示され ません。文書化された方法はCheckout UI Extensionです（Theme App Extensions、Checkout UI Extensions）。

有料広告からの流入が多いストアにとって、これは重要です。記録されている平均放棄率は 70.22% で、48% が高すぎる、あるいは後から提示される追加費用を理由に離脱しています（Baymard）。決済ステップの体験をコントロールできないなら、プラットフォームに固定されたファネルに向けて広告を最適化していることになります。

ピクセル、head/body、マーケティングのスクリプト

Trayでの運用のまとめ：

1. 公式に推奨されるのは、テーマのHTMLを使わない 管理画面でのGTM（GTM）。
2. テーマのHTMLは、適切なプラン + 複製 + Twigの構造への注意があって初めて使える。
3. チェックアウトとログインが必要なエリアでは、GTMのプレビューだけでなく 実際の環境で 発火を確認する。

広告運用担当者がCAPI + ピクセル + 重複排除したファネルイベントを必要とするなら、実装予算はすぐに膨らみます。「TrayにGTMがないから」ではなく、GTMは拡張可能なストアフロントとチェックアウトの代わりにはならないから です。

---

4. 実際のコスト：主題ではなく補足

月額料金と販売手数料は重要です。ただ、問題がエンジニアリングの上限であるときに、それだけで判断が決まるわけではありません。

公式の参考情報（表示価格だけで比べない）

この記事で言うTrayの見えないコストは、別のところにあります。

• エディタ/Twigを回避するための 代理店の工数。
• テーマがルールを実現できないから存在する アプリ。
• ファネルを変えるたびに発生する GTMの手直し。
• 失われる実験：単純に実行できないチェックアウトのUX A/Bテスト。

「技術的な回避策」の月額合計がプラットフォームの差額をすでに上回っているなら、移行は技術スタックの好みの問題ではなく、損失を止めるための手段になっています。

---

5. Trayにとどまるべきとき、Shopifyが理にかなうとき

Trayを続けるべきなのは

• 自社サイトは補助で、売上はマーケットプレイスにある。
• ビジュアルエディタ + 公式アプリでブランドの要件を満たせている。
• 商品ページやチェックアウトの独自JS、自前のWebhookに依存していない。
• チームがGTMをスクリプトの正面玄関として受け入れている。

Shopifyを真剣に検討すべきなのは

• ブランドがTrayテーマのレールから外れたストアフロントを求めている。
• 公開中のHTMLにパッチを当てずに、ページの適切な位置にアプリ拡張を置きたい。
• チェックアウトとコンバージョンイベントが広告ROIの中心にある。
• エンジニアリングチームが、モダンな仕様のAPI/Webhookとバージョン管理されたアプリを求めている。
• すでに毎月「回避策の費用」（代理店 + アプリ + 壊れやすいGTM）を払っている。

経験則として、カスタマイズと連携の要件がTrayの文書化している範囲（プラン、テーマの複製、ロックされたフォルダ、GTM、認定アプリ）に 収まらない なら、ドル建ての月額料金の議論は二の次です。

---

6. 判断する前のチェックリスト

感覚ではなく、ストアの事実に基づいて答えてください。

1. あなたのTrayプランは HTML/CSS を開放していますか、それともビジュアルエディタだけですか？（プラン）
2. 前四半期、HTMLを公開するためだけに テーマを複製 したのは何回ですか？
3. どの重要なスクリプトが GTMだけ に依存していて、どれがチェックアウトで壊れましたか？
4. 認定アプリ / Webhookのスコープ が必要で止まった連携はありますか？
5. テーマの制限を 回避するためだけに、代理店やアプリに毎月いくら使っていますか？
6. 自社サイトが売上の原動力ですか、それとも今もマーケットプレイスが80%以上を占めていますか？

2〜5が痛く、6の答えが「自社サイト」なら、上限はすでにコストとして跳ね返っています。

---

まとめ

Trayは、ブラジルでの立ち上げ期やマーケットプレイス中心の運用では今も強力です。2026年に最も重くのしかかる制限は月額料金の表示価格ではありません。プランの関門とコピー運用に縛られたHTML/JS、プラットフォームのレールに乗ったTwigテーマ、そして スクリプトをGTMへ、自動化を認定アプリへ押しやる連携 の組み合わせです。

Shopifyが際立つのは、運用が本当に拡張可能なストアフロントとチェックアウトを必要とする場面です。コストは、技術的な上限を認めたあとで計算に入ってきます。

あなたのストアの診断（今のテーマに収まるものと、すでに回避策になっているもの）が必要なら、プラットフォーム、プラン、行き詰まったカスタマイズの例を2つ添えて、oailton.dev/ja/contato からお問い合わせください。スローガンではなく、要件に基づいて結論をお返しします。