Developer / Storefront MCP非推奨(Deprecation)

Storefront MCP の「ポリシー・FAQ 検索」ツールが非推奨に
UCP MCP の ask_business へ 2027/1/15 までに移行

search_shop_policies_and_faqs は ask_business に置き換え。エンドポイント・リクエスト形式・レスポンス形式がすべて変わるため、AI エージェント側のコード修正が必要。

このページの構成
  1. そもそも何が変わるのか(30秒で理解)
  2. 新旧の構成図解 : どこからどこへ移るのか
  3. 移行スケジュール
  4. 旧ツール vs 新ツールの比較
  5. リクエスト/レスポンスの形
  6. 移行手順(5ステップ)
  7. 技術者が押さえるべき5つのポイント
  8. 業務に活かせる3つのユースケース
  9. 提案で使える1行サマリ

1そもそも何が変わるのか

Storefront MCP サーバーの search_shop_policies_and_faqs(ストアのポリシー・FAQ 検索ツール)が非推奨になった。
後継は UCP MCP の ask_business。買い手の質問に対して、ストアのナレッジベースとポリシーをもとに文章で回答するツール。

これまで : search_shop_policies_and_faqs

Storefront MCP(https://{shop}.myshopify.com/api/mcp)上のツール。2027 年 1 月 15 日までは維持されるが、ドキュメントは今後すべて Ask MCP を参照する。

これから : ask_business

UCP MCP(https://{shop-domain}/api/ucp/mcp)上のツール。UCP の ask ケイパビリティ(dev.ucp.common.ask)を実装している。

2新旧の構成図解 : どこからどこへ移るのか

AI エージェント (あなたの実装) 旧ルート 新ルート(移行先) Storefront MCP サーバー https://{shop}.myshopify.com/api/mcp search_shop_policies_and_faqs 非推奨 UCP MCP サーバー https://{shop-domain}/api/ucp/mcp ask_business 実装: dev.ucp.common.ask 回答の根拠 ナレッジベース ストアのポリシー
エンドポイントのホスト表記も変わる点に注意 : 旧は {shop}.myshopify.com、新は {shop-domain}。パスも /api/mcp → /api/ucp/mcp に変わる。

3移行スケジュール

2026/11/11 非推奨を発表 ドキュメントは Ask MCP 参照へ 移行期間(旧ツールも維持) この間に ask_business へ切り替える ! 2027/1/15 旧ツールの維持期限 以降の扱い:記載なし
記事の表現は「2027 年 1 月 15 日まで維持される(maintained until)」。期限後に即停止されるのか、どのような挙動になるのかは記載なし。期限前の移行完了を前提に計画すること。

4旧ツール vs 新ツールの比較

項目旧 : search_shop_policies_and_faqs新 : ask_business
サーバー Storefront MCP UCP MCP
エンドポイント https://{shop}.myshopify.com/api/mcp https://{shop-domain}/api/ucp/mcp
エージェント識別 記載なし 必須 全リクエストに meta で ucp-agent.profile
質問の渡し方 記載なし ask.query(+任意で ask.context)
返ってくるもの (新ツールとの対比から)ナレッジベースの事実やポリシー本文に相当する生データ ※詳細な形式は記載なし 文章の回答 result.structuredContent.answer.plain
提供有無の確認 記載なし tools/list でエージェントプロファイルごとに確認
ステータス 非推奨 2027/1/15 まで維持 推奨 ドキュメントの参照先

5リクエスト/レスポンスの形

リクエスト(エージェント → ストア) meta ucp-agent.profile(全リクエスト必須) ask.query 買い手の質問 ask.context(任意) 買い手の文脈:国・希望言語 など ask_business UCP MCP レスポンス(ストア → エージェント) result └ structuredContent └ answer └ plain : 文章の回答 返らないもの ナレッジベースの生の事実 ポリシー全文
図はフィールドの位置関係を示したもの。meta の正確な JSON 構造や ask.context に入れられる項目の一覧は記事に記載なし。詳細は Ask MCP のドキュメント(https://shopify.dev/docs/agents/ask)を参照。

6移行手順(5ステップ)

1

呼び出し先を切り替える

ツール呼び出しを ask_business に変更し、エンドポイントを https://{shop-domain}/api/ucp/mcp に更新。

2

meta にプロファイルを載せる

全リクエストに ucp-agent.profile を持つ meta を付与。プロファイルは dev.ucp.common.ask を宣言していること。

3
?

質問と文脈を詰め替える

質問は ask.query、国や希望言語などの任意の文脈は ask.context に入れる。

4

レスポンス解析を直す

回答は result.structuredContent.answer.plain の文章。旧レスポンスをパースしていたコードは要修正。

5

tools/list で提供有無を確認

そのストアが自分のエージェントプロファイルに対して ask_business を提供しているかを tools/list で確認。

旧ツールは 2027/1/15 まで維持されるので、新旧を並行稼働させて回答品質を比較してから切り替える余裕がある。

7技術者が押さえるべき5つのポイント

URL

1. ホストとパスが両方変わる

旧 {shop}.myshopify.com/api/mcp → 新 {shop-domain}/api/ucp/mcp。URL を組み立てるロジックで myshopify ドメイン前提にしている場合は、ホストの扱いも見直す。

2. エージェントプロファイルが前提になる

全リクエストに meta の ucp-agent.profile が必須。プロファイルは dev.ucp.common.ask を宣言していなければならない。プロファイルの準備が移行の最初のブロッカーになりうる。

3. 「検索結果」から「回答」に変わる

ask_business が返すのは文章の回答(answer.plain)で、ナレッジベースの生データやポリシー全文ではない。生データを加工・引用していた実装は設計から見直しが必要。

4. 買い手の文脈を渡せる

ask.context で国や希望言語などの買い手の文脈を任意で渡せる。エージェントが持っているロケール情報をそのまま渡す配線を用意しておくとよい。

?

5. ストアごとに提供有無が違う前提で組む

記事は「tools/list でストアが自分のエージェントプロファイル向けに ask_business を提供しているか確認せよ」としている。全ストアで常に使えるとは限らない前提で、呼び出し前のツール存在チェックを組み込むのが安全。提供されない場合の挙動・条件は記載なし。

8業務に活かせる3つのユースケース

旧 新
USE CASE 1

既存の購買支援エージェント/チャットボットの期限内移行

課題
Storefront MCP の search_shop_policies_and_faqs で返品・配送ポリシー等の質問に答えるエージェントを運用中。2027/1/15 の維持期限が迫る。
打ち手
エンドポイント・meta(ucp-agent.profile)・ask.query・レスポンス解析の 4 点を改修し、期限前に新旧を並行稼働して回答を比較してから切り替える。
効果
期限切れによる回答停止リスクを回避。ドキュメントが Ask MCP 基準になるため、今後の保守も公式情報に沿って行える。
技術メモ
改修範囲の棚卸しは「旧ツール名を呼んでいる箇所」と「旧レスポンスをパースしている箇所」の 2 系統で grep するのが早い。
JA/EN
USE CASE 2

越境ストアの問い合わせ対応で「国・言語」を踏まえた回答にする

課題
複数の国の買い手が来るストアで、配送・返品ポリシーの質問に対し、買い手の国や言語を意識した回答を返したい。
打ち手
エージェントが把握している買い手の国・希望言語を ask.context に入れて ask_business を呼ぶ。
効果
買い手の文脈を回答生成側に渡せるため、エージェント側で文脈ごとの分岐ロジックを自前で持つ必要が減る(回答への反映度合いは記載なし。要検証)。
技術メモ
ask.context に入れられる項目の正式な一覧は記事に記載なし。Ask MCP ドキュメントで確認してから実装する。
tools/ list
USE CASE 3

複数ストア横断のエージェントで「使えるストアだけ使う」設計にする

課題
多数のストアに接続するエージェントで、ストアごとに ask_business が提供されているか分からず、呼び出し失敗の扱いが曖昧。
打ち手
接続時に tools/list を叩き、ask_business があるストアだけ呼び出す。無いストアでは「ポリシーはストアのページで確認してください」等の案内に切り替える。
効果
存在しないツールを呼ぶ失敗を事前に避けられ、買い手体験が安定する。
技術メモ
提供有無は「エージェントプロファイルに対して」判定されるため、プロファイルを変えた場合は再確認が必要。tools/list 結果のキャッシュ期間の目安は記載なし。

9提案で使える1行サマリ

「Storefront MCP のポリシー・FAQ 検索は非推奨。2027/1/15 までに UCP MCP の ask_business へ移行が必要。
変わるのはエンドポイント・エージェントプロファイル必須化・ask.query 形式・“検索結果”ではなく“文章の回答”が返る点。
期限内に新旧を並行稼働して検証し、切り替えましょう。」