Shopify Storefront MCPで2人・10週間、Redmondが内製したAIコマースエージェントの中身
ユタ州の塩企業RedmondがShopify Storefront MCPを土台に、2人・10週間で本番稼働のAIコマースエージェントを内製。何を作り、何を作らずに済んだのか、そして内製が失敗する条件までEC事業者向けに解説します。
この記事のポイント
- ユタ州で1958年から天然塩を採掘するRedmondが、Shopify Storefront MCPを土台に2人・10週間でAIコマースエージェントを内製し、2026年2月に本番稼働させた
- 商品カタログへのリアルタイム接続をプロトコルが担ったことで、内製側の作業はブランド固有の知識・システムプロンプト・計測の3点に絞り込まれた
- ただし内製は誰にでも勧められる道ではなく、企業の74%が稼働後のAIカスタマー対応エージェントを撤回したという調査もある。判断軸は費用削減ではなく制御の必要性
塩を掘る会社が、10週間でコマースエージェントを作った
Redmondがサポート体制を拡張しつつ完全な制御を手に入れるため、Shopify Storefront MCPを使って10週間で本番稼働のAIコマースエージェントを構築した方法。
www.shopify.comRedmondは1958年から、ユタ州中部の古代の塩床から天然塩を掘り出してきた会社です。兄弟2人が塩を掘るところから始まり、いまではReal Saltや、パンデミック期に伸びた電解質サプリのRe-Lyteを含む10以上のブランドを抱えるまでになりました。事業基盤はShopify Plusです。
その会社が公開したShopifyの事例は、EC事業者にとって珍しく具体的な内容を含んでいます。使っていた管理型のAIカスタマーサービスツールが提供終了になったとき、Redmondには別のベンダーに乗り換えるか、自分たちで作るかの二択がありました。彼らは後者を選び、Shopify Storefront MCPを土台に10週間で本番稼働のAIコマースエージェントを組み上げ、2026年2月に稼働させています。
担当したのは2人です。社内向けのナレッジツールをRAG（検索拡張生成）で作っていたapplied AI developerのPhillip Hinson氏が開発を担い、2018年からRedmondのShopify基盤を見てきた開発チームリードのJeremiah Payne氏が方向づけと意思決定を担当しました。
買わずに作った理由は、コストではなく制御だった
先に誤解を解いておくと、この内製は安く済ませるための判断ではありません。
Redmondの顧客は、成分や原料の調達先について細かい質問を日常的に投げてきます。天然食品を扱う会社にとって、この種の回答の正確さは事業リスクに直結します。ところが当時の管理型AIチャットツールは、システムプロンプトを加盟店に開放していないのが一般的でした。多くの用途ではそれで困らないものの、製品固有の主張に精密なガードレールを敷きたいRedmondにとっては致命的だったと、Hinson氏は事例のなかで述べています。
管理型ツールには、利便性と制御のトレードオフが必ずあります。システムプロンプトもデータソースもカスタマイズできず、慎重な回答が必要だと分かっている製品質問にガードレールを作るのが難しかった。
もうひとつの動機は採用でした。Redmondは多段階の面接と文化適合の確認を重ねる慎重な採用文化を持っており、CS人員を需要の伸びに合わせて増やすことができません。「人を増やさずに顧客体験を伸ばす方法を探していた」というPayne氏の言葉が、内製の出発点になっています。
10週間の内訳と、プロトコルが引き受けた範囲
ここがこの事例の核心です。10週間という期間そのものより、何を作らずに済んだのかのほうが再現性の判断材料になります。
Storefront MCPは、Shopifyの各ストアが https://{shop}.myshopify.com/api/mcp という固有のエンドポイントを持ち、商品検索・カート操作・ポリシー参照といった機能をAIエージェント向けに標準化して公開する仕組みです。Shopifyの開発者ドキュメントによれば、search_catalog や get_product といったツールはGoogleと共同で策定したUCP（Universal Commerce Protocol）のCatalog仕様に準拠しています。つまり「商品データをAIに読ませる」部分は、実装ではなく接続の問題になっています。
Hinson氏はShopifyのMCPリファレンスアプリから着手し、開発ストアに接続してAzureにデプロイするまでにおよそ1日しかかけていません。「USB-Cのようなもので、どこでもだいたい動くべきものだ」という彼の表現は、この体験を端的に示しています。
残りの9週間強が費やされたのは、プロトコルが埋めてくれない部分でした。
| 構成要素 | 担い手 | 内製側の作業量 |
|---|---|---|
| 商品カタログ・カート・ポリシーへのアクセス | Shopify Storefront MCP（店舗ごとのエンドポイント） | 接続設定のみ。開発ストアで応答するまで約1日 |
| アプリの土台・認証・MCPクライアント | ShopifyのMCPリファレンスアプリ | Azureへのデプロイ、CI/CDパイプライン構築 |
| ブランド固有の知識（成分・原料調達・製品主張） | 自前 | 全ブログ・Webページの同期処理とPostgreSQLへの格納 |
| 意味検索 | 自前 | Azure OpenAIで埋め込み生成、ベクトルDBへ格納 |
| 会話の生成と判断 | AnthropicのClaude | システムプロンプト設計、プロンプトキャッシュ実装 |
| 計測とアトリビューション | 自前 | トークン・ツール利用の追跡、多層アトリビューション設計 |
| 本番堅牢化 | 自前 | PKCE認証フロー、ログのサニタイズ、レート制限 |
| 有人対応への引き継ぎ | 自前＋HubSpot | 「Talk to a Human」ボタンとチャットウィジェット連携 |
技術面で目を引くのは、Anthropicのプロンプトキャッシュを実装した判断です。システムプロンプトとツール定義は大きく、かつリクエストごとに変わりません。これをキャッシュすることで、キャッシュヒット時の入力トークンコストが最大10分の1に下がり、AI関連支出は全体で約半分になったとされています。会話AI本体はAnthropicのClaudeが担い、顧客の質問を解釈して検索の要否を判断し、回答を組み立てます。
計測の設計にも思想が出ています。購入とチャット会話の紐づけは、直接のカート追跡から時間窓の相関まで信頼度を分けた多層構造にしたうえで、あえて保守的な条件を選んでいます。「実態より良く見えるデータは要らない」というPayne氏の言葉どおりで、社内向けAIの効果測定で最初に崩れがちな部分に手を打っています。
なお稼働前には、旧ツールの過去9ヶ月分の会話ログをエクスポートして分析し、回答が不十分だった箇所を洗い出しています。地味ですが、これが精度の土台になっています。
休暇中に新商品が追加された日
ライブデータプロトコルの価値がいちばん分かりやすく現れたのは、稼働週の出来事でした。
エージェント稼働の翌日、Redmondは新しいプロテインパウダーを発売します。Hinson氏は家族とメキシコで休暇中でした。同僚から「新商品の知識をもう反映してくれてありがとう」というメッセージが届きますが、彼は何もしていません。Storefront MCPがShopifyのCatalogから新商品を自動的に取得しており、エージェントは公開された瞬間から質問に答えられる状態になっていたのです。
旧来の管理型サービスでは、新商品ごとにコンテンツ更新を手動で起動する必要がありました。この差は運用工数として毎月効いてきます。Shopifyが店舗ごとにMCPサーバーを配備した狙いは、まさにこの同期作業の消滅にあります。
副次的な効果も出ています。Payne氏は4つのShopifyストアを統合する際、顧客・注文の履歴データ移行に有料アプリを検討していましたが、Shopify MCPとClaudeを使って自力で完了させました。さらにWebhookを監視して新規顧客や支払い済み注文を自動移行するミドルウェアまで作っています。チャットボット以外の運用作業にプロトコルが波及した点は、導入検討時に見落とされやすい実利です。
この事例をそのまま真似できるか
ここからは、推進側の物語とは別の角度が必要です。
まず数字の面。事例では稼働後のAnthropic APIトークン費用は「最小限」とされていますが、実額は未開示です。Azureのホスティング費、旧管理型サービスの料金とベンダー名、月間会話件数の具体値、精度の数値も開示されていません。10週間の内部開発工数もコストに含まれていないことは、事例自身が明記しています。旧サービスがホスティング・モデル・サポート・更新を含む一括のサブスクリプションだったのに対し、内製はそれらが分解されるため、比較は単純にはできません。
そして成功率の問題があります。Sinchが10ヶ国2,527人の意思決定者を対象に行った2026年の調査「The AI Production Paradox」では、企業の74%が稼働後のAIカスタマー対応エージェントを撤回または停止したと報告されています。ガードレールが成熟している組織ほど撤回率が高く81%に達するという結果も出ており、これは監視が効いている証拠だと同社は解釈しています。MITのProject NANDAによる「生成AIパイロットの95%が本番到達に至らない」という数字と合わせると、10週間で稼働まで持っていったRedmondはむしろ例外側に属します。
内製を勧めない立場の主張も見ておく価値があります。AIカスタマーサポート製品を提供するIntercomのFinは、build vs buyの整理のなかで、本番品質のAIカスタマーサービスエージェントは初年度30万〜50万ドル規模、年間保守が15万〜25万ドル規模になると見積もっています。ベンダー自身の主張なので割り引いて読む必要はありますが、Gartnerの調査を引きながら「性能不足の原因の62%はデータ準備の不足であり、技術的制約は15%未満」と指摘している点は、Redmondの成功要因とも整合します。Hinson氏自身が「難しいのはAIではなく、教えられるほど自社製品を理解していることだ」と語っているからです。
セキュリティも論点です。MCPは急速に普及した反面、プロンプトインジェクションやツールポイズニング、認証情報の誤用といったリスクが繰り返し指摘されています。RedmondがPKCE認証フロー、ログのサニタイズ、レート制限を「本番堅牢化」として明示的な工程に置いたのは偶然ではありません。この工程を省いた10週間は、別物だと考えるべきです。
EC事業者への示唆
判断軸を整理すると、次の順序になります。
第一に、制御の必要性が本当にあるかを先に問うことです。Redmondが内製に踏み切ったのは、成分や原料調達に関する回答を一字一句管理する必要があったからで、注文状況の問い合わせが大半を占める事業なら、管理型ツールの利便性を捨てる理由は薄くなります。「安くなるから作る」で始めた案件は、上記の失敗率の側に落ちやすいと考えたほうが安全です。
第二に、内製する場合でも作る範囲を先に削ることです。この事例の再現性は、Storefront MCPが商品データ接続を消し、リファレンスアプリが認証とアプリ土台を消したことに支えられています。Shopify以外の基盤でも、commercetoolsをはじめとするMCPサーバー提供の動きは広がっており、自社の基盤に同等の接続層があるかどうかが最初の確認項目になります。
第三に、知識ベースの整備が本体の仕事だという認識です。Redmondが作ったものの中身は、突き詰めれば承認済みコンテンツの同期パイプラインと、それを引くための埋め込み、そして回答を縛るシステムプロンプトです。この3つはAIの流行と無関係に価値が持続し、後からモデルを差し替えても残ります。逆に言えば、社内の商品情報が散逸している状態でエージェントだけ先に作っても、確信を持って間違える機械ができるだけです。
まとめ
Redmondの10週間は、AIエージェント構築の難易度がプロトコルによって下がったことを示す具体例です。同時にこの事例は、下がったのが「接続の難易度」であって「運用の難易度」ではないことも示しています。次の焦点は、同社が予告している未発送注文の返金・キャンセル処理などのトランザクション機能です。情報提供から取引実行へ踏み込むとき、権限設計と例外処理の重さが改めて問われます。AI由来の注文が急増しているShopifyの数字と合わせて、続報を追う価値のある事例です。
