ShopifyのAIエージェント基盤から見る、EC運用自動化の次の論点

2026年6月3日2026年6月10日

ShopifyまわりのAIは、商品説明を少し速く書く段階から、EC運用そのものをAIエージェントに渡す段階へ寄っています。ここで見たいのは「すごいAIが出た」という話ではありません。注文、在庫、返品、割引、商品データ、チェックアウトのようなECの中枢に、AIがどう安全に触るかです。

Shopifyのエンジニアリングブログでは、Slack上で動く社内エージェントRiver、その下で動くAquifer、Shopify Flowを自然言語から作るSidekick向けエージェント、Universal Commerce Protocol（UCP）などが続けて説明されています。別々の話に見えますが、実務では同じ線上にあります。AIに「文章」ではなく「業務操作」を任せるなら、ログ、権限、サンドボックス、評価、失敗時の戻し方が必要になる、という話です。

何が起きたか

Shopifyは2026年5月、社内Slackで動くAIエージェントRiverと、その下で動く内部基盤Aquiferについて公開しました。記事では、Riverは数か月前に導入された社内エージェントで、Shopify全体のマージ済みPull Requestの8件に1件がRiverとの共著だと説明されています。

重要なのはRiverそのものより、Aquiferの設計です。ShopifyはAquiferを、AIエージェントを動かす内部プラットフォームとして説明しています。含まれる要素は、セッション、ハーネス、サンドボックス、ゲートウェイ、永続イベントログ、秘密キーや接続情報を扱うプロキシ、観測パイプライン。かなり地味ですが、ここがないと長時間動くエージェントは仕事になりません。

同じ流れで、Shopify Flow向けの技術記事も出ています。自然言語からShopify Flowを生成するツール呼び出し型エージェントをSidekick向けに微調整し、Shopifyは2.2倍高速、68%低コストになったと報告しています。ただし、記事で本当に大事なのは数字の派手さではありません。ベンチマーク上は同等でも、実ユーザーが使うと35%の差が出た、という部分です。テストで良く見えても、本番では別物になる。

さらにShopifyは、Googleと共同でUniversal Commerce Protocol（UCP）を開発したと説明しています。UCPは、AIエージェントが店舗の機能を発見し、何ができるかを確認し、購入などの取引に進むための標準として位置づけられています。Shopify Dev Docsにも、UCPとShopifyのMCPサーバーを使って、購入者の代わりに安全に動くエージェント体験を作る説明があります。

何が変わったか

ECのAI活用は、商品コピー、FAQ、メール返信の自動化だけでは終わらなくなります。AIが「商品を説明する」だけなら、間違えても人間が直せます。しかしAIが在庫を見て、注文を確認し、返品条件を判断し、割引リンクを作り、チェックアウトへ誘導するなら、話は別です。

その段階では、AIにどの権限を渡すのか、何をログに残すのか、どの操作は人間確認に戻すのか、テスト環境でどう検証するのかを決める必要があります。ShopifyがAquiferでセッション、イベントログ、サンドボックス、ゲートウェイを分けているのは、AIが賢いからではなく、賢く見えるAIでも普通に失敗するからです。

小さなEC事業者にとっては、ここが分かれ目です。AIツールを入れて「商品説明を作れます」で止めるのか。受注、在庫、問い合わせ、レビュー、広告、商品登録の流れまで見て、AIに渡せる作業と渡してはいけない作業を分けるのか。後者に進むなら、AI導入はツール選びではなく業務設計になります。

小さな会社・開発会社・EC運用ではどこに効くか

まず効くのは、EC運用の棚卸しです。日々の仕事を「文章生成」「判断」「操作」「確認」に分けます。商品説明の下書きは文章生成。返品可否の判断は判断。クーポン発行やステータス変更は操作。公開前チェックや在庫差分確認は確認です。この4つを混ぜたままAIに渡すと危ない。

次に、ログの設計です。AIが何を見て、何を判断し、どの操作候補を出したのかが残らないと、あとで直せません。問い合わせ返信なら、参照した注文番号、商品、配送状況、返品ポリシーを残す。商品登録なら、参照したメーカー情報、画像、カテゴリ、価格ルールを残す。開発会社がEC向けAIを作るなら、このログ設計が提案価値になります。

EC運用会社やBPO会社にも関係があります。AIで作業を減らすだけなら、単価の安い自動化に見えます。しかし「AIが見た情報」「人間が確認した箇所」「公開・送信した内容」を残せるなら、品質管理の仕組みとして売れます。少人数チームほど、作業者の記憶に頼る運用から抜けやすくなります。

そのまま真似ると危ない点

Shopifyの事例をそのまま小さな会社に持ち込むのは無理があります。Shopifyは巨大なプラットフォームで、社内基盤、評価環境、ログ、モデル改善の体制を持っています。小さなEC事業者が同じものを作ろうとすると、費用も運用も重すぎます。

危ないのは、機能名だけを真似ることです。「MCPを入れた」「エージェント化した」「サンドボックスを用意した」と言っても、業務上の権限設計がなければ意味がありません。返品処理をAIに任せるのか。割引作成は人間承認にするのか。顧客への送信は誰が押すのか。ここを決めないと、便利なAIではなく、確認しづらい作業者が増えるだけです。

もう一つは評価です。Shopify Flowの記事にあるように、ベンチマークで良く見えても、実ユーザーでは差が出ます。ECでも同じです。社内テストでは問題なく見えた返信文が、実際の顧客対応では冷たく見える。商品説明としては自然でも、薬機法や景表法の観点では危ない。こうしたズレは、実データに近い検証をしないと出ません。

最初にやるなら何か

最初に作るべきなのは、AIエージェントではなく「AIに渡してよいEC業務リスト」です。たとえば次のように分けます。

AIに任せてよい: 商品説明の初稿、FAQ案、レビュー分類、問い合わせ要約、在庫差分の検知
AIが候補を出し、人間が決める: 返品可否、値引き、クーポン発行、クレーム返信、商品カテゴリ変更
最初は人間だけ: 返金、アカウント権限変更、大量メール送信、価格の一括変更、法務・医療・効能に関わる表現

次に、1つだけ検証します。おすすめは問い合わせ対応か商品登録です。どちらも効果が見えやすく、失敗時のリスクを抑えやすい。AIが下書きを作り、人間が確認し、送信・公開した結果をログに残す。この小さな流れを作るだけで、次に在庫確認、レビュー分類、広告文、Shopify Flow生成へ広げやすくなります。

開発会社なら、提案書に「AIで自動化します」と書くより、対象業務、権限、ログ、検証、戻し方を1枚にまとめる方が強いです。AIの性能より、事故らない運用設計を見せた方が、EC事業者は判断しやすい。

monoblo/Sync8実務メモ

このテーマは、EC事業者向けのAI導入でかなり使えます。特にShopifyを使っている会社には、商品データ、問い合わせ、在庫、レビュー、キャンペーン運用のどこからAI化するかを整理する入口になります。

私なら、最初から「AIエージェントで全部自動化」とは言いません。まず、AIが見る情報、AIが作る候補、人間が押すボタンを分けます。ECでは売上に直結する操作が多いので、完全自動化よりも、確認できる半自動化の方が導入しやすいです。

記事として追うなら、今後の論点は3つです。UCPやMCPでAIがEC機能に触る標準化。Sidekickのような管理画面内AIの進化。Aquiferのような長時間エージェント基盤。これは一過性のニュースではなく、EC運用の作り方そのものに効いてきます。

参照元

シェアはこちらから

URLをコピーしました！