Shopifyエージェンシー向け

Shopify B2Bアプリの評価方法：エージェンシーとソリューションアーキテクトのための質問

著者 Jahangir Alam · 2026年9月20日 · 約15分で読めます

最終確認日: 2026年9月20日
Shopify API: 2026-07
対象読者: クライアントのためにB2Bアプリを審査するShopifyエージェンシー、開発者、ソリューションアーキテクト
範囲: B2B、見積、価格、バイヤーポータルに関わるあらゆるShopifyアプリ。回答を照合できるShopifyの仕組み

クライアントに安心して提案できるShopify B2Bアプリとは、Shopify自身のオブジェクト（会社、所在地、カタログ、下書き注文）を並行するオブジェクトではなくそのまま使い、ストアと顧客アカウントを注入コードではなく拡張機能で拡張し、必要なデータだけを保持してShopifyの必須ウェブフックで消去し、サポート対象のGraphQL APIバージョンを使ってスロットリングとウェブフックの再試行を扱い、そしてこれらの回答を主張するのではなく証明できるアプリです。

以下の53の質問は、エージェンシーが半日で確認できるようにグループ分けし、それぞれに自分で答えを検証する方法を添えています。ベンダーのページは何にでもイエスと言うからです。

このチェックリストはベンダー中立です。見積依頼アプリ、卸売価格アプリ、バイヤーポータルアプリ、独自開発のいずれにも当てはまり（そもそも購入すべきかは判断ガイドの仕事です）、自社の回答を別途公開しているベンダーが書いたものです。末尾にリンクがあります。トライアルの後ではなく前に使ってください。質問の大半はドキュメント、開発ストア、ブラウザのネットワークタブで答えが出ますし、出ないものこそ書面で尋ねるべき質問です。

評価の進め方

まずドキュメントから答える。データ保持、APIバージョン、アンインストール時の挙動を文書化しているアプリはそれについて考えたことがある。していないアプリは営業の場で記憶から答える。
開発ストアにインストールする。開発ストアは無料でB2Bに対応しており、アプリの課金もテスト課金になるため、以下の「本当にそうなるか」の質問はすべてクライアントのストアなしで確認できる。会社を2つ、所在地を3つ、1商品が重複する2つのカタログ、Net 30の所在地と下書き注文のみのチェックアウトの所在地を用意する。
残りの質問は書面で尋ね、回答をプロジェクトと一緒に保管する。「アンインストール時に何が消えるか」の答えはチャットのメッセージではなく、クライアントのデータ処理記録の一部だ。アプリを選んだら、公開前に実行するのは50項目の公開テストプラン。

A. ネイティブ適合

最もコストが高い間違いは、Shopifyがすでに所有しているものをアプリが作り直すことです。Shopifyに置くものと見積レイヤーに置くものがその理由で、以下がその質問です。

質問	なぜ重要か	検証方法
顧客モデルとしてShopifyの会社、会社所在地、会社連絡先を使っているか。それとも独自の「アカウント」か	カタログ、支払い条件、免税、チェックアウト設定はすべてShopifyの所在地に紐づく。並行するアカウントモデルはそれら全部を複製する	Shopify管理画面で会社を作り、アプリが再入力なしにそれを表示するか確認。アプリのレコードやエクスポートに会社IDと所在地IDがあるか探す
価格表を持たず、所在地のカタログ価格を読んでいるか	所在地は複数のカタログを持てて最安が表示される。数量別価格は価格を固定しカタログのパーセンテージ調整を外す。コピーはどちらも知りようがない	テスト商品に1つの所在地向けの2つのカタログ価格を付け、アプリが起点にする価格を確認。依頼時に `contextualPricing` で価格を解決しているか尋ねる
承諾された見積は、バイヤーの所在地と連絡先付きで、会社向けのネイティブな下書き注文になるか	`purchasingEntity` 付きで作成した下書き注文は所在地の条件とチェックアウト設定を引き継ぐ。個人向けに作ったものは引き継がない	テスト見積を変換して管理画面で下書き注文を開く。顧客だけでなく会社、所在地、連絡先が載っているべき
合意価格は下書き注文の明細に届くか。それとも割引で偽装しているか	交渉済み単価は明細の `priceOverride` に入るべきもの。割引コードはレポートを変え、削除もできる	交渉済み価格の見積を変換し、下書き注文を読む。明細価格と適用割引を比べる
所在地のShopify支払い条件を適用するか、独自の条件を持つか	条件はShopifyが回収する。アプリ独自の「支払い条件」は2つ目の売掛システム	変換された下書き注文の支払い条件を所在地の設定と照合する
Basic、Grow、Advancedで動作するか。それともPlusを確認しているか	B2Bは2026年4月2日から全プランにある。機能ではなくプラン名で判定するアプリは古い	B2Bを有効にしたPlus以外の開発ストアにインストールし、会社対応の機能を試す
前受金をShopifyが提供する範囲でのみ提供しているか	前受金はPlusの機能（`DraftOrderInput.deposit`）。Basicストアで前受金を約束するアプリは、Shopifyが回収できないものを約束している	前受金がどこで回収されるか尋ねる。唯一の正解は下書き注文のShopifyチェックアウトで、Plusに限る
商品の適格性（どの商品を、どの数量で見積依頼できるか）はサーバーで強制されているか。それともストアで隠しているだけか	隠されたボタンはルールではない。URLを知るバイヤーは何でも送信できる	ブラウザのネットワークタブでフォームのリクエストを編集し、除外商品の依頼を送信する。サーバーが拒否すべき
バリエーションではない明細（特注サイズ、サービス、セットアップ費用）を独自の価格、課税フラグ、配送フラグ付きで追加でき、カスタム明細として下書き注文に届くか	実際の見積にはカタログにない明細がある。下書き注文はまさにそのフラグを持つカスタム明細に対応している	テスト提案で1つ追加して変換する。下書き注文の明細にバリエーションがなく、フラグが付いていることを確認する

B. ストア

質問	なぜ重要か	検証方法
ストアへの統合はテーマアプリ拡張機能（セクション内のアプリブロック、オーバーレイ用のアプリ埋め込みブロック）か、それともテーマファイルに注入したコードか	拡張機能はマーチャントがテーマエディターで追加・削除でき、何も残さない。注入コードは手作業で除去する必要があり、テーマ変更で壊れる	テーマエディターでセクションの「アプリ」と「テーマ設定 > アプリ埋め込み」を見る。次にテーマのLiquidファイルでアプリ名を検索する
インストール後にアプリ埋め込みは有効化されているか。マーチャントはそれを知っているか	アプリ埋め込みブロックは「アプリのインストール後は無効化」されており、テーマエディターで有効にする必要がある。初日に壊れて見えるアプリはたいていこれ	インストールし、何かを触る前に「テーマ設定 > アプリ埋め込み」を確認する
すべてのページで何を読み込み、どれだけ重いか	テーマアプリ拡張機能のShopify推奨上限は圧縮後JavaScript 10 KB、CSS 100 KB。Built for Shopifyはアプリが「ストアのLighthouseパフォーマンススコアを10ポイント以上下げてはならない」と定めている	ネットワークタブをアプリのドメインで絞って商品ページを開く。アプリ埋め込みのオン・オフでLighthouseを実行する
テーマの更新や新しいテーマへの切り替えを生き残るか	アプリブロックはセクション単位で配置されるため新しいテーマにはない。アプリ埋め込みはテーマごとにテーマエディターで有効化する。テーマファイルに注入されたものはまったく引き継がれない	テーマを複製して公開し、何が動くか確認する。次に新しいテーマで試す
ヘッドレスのストアフロントではどうなるか	テーマアプリ拡張機能はオンラインストアが描画するLiquidで、Hydrogenや独自のストアフロントは何も描画しない。ヘッドレスのB2BはバイヤーのトークンとcompanyLocationIdでコンテキスト化したStorefront APIで動くため、アプリには独自のAPIかコンポーネントの経路が必要	ヘッドレス統合ガイドを求める。答えが「うちのアプリブロック」なら、経路は存在しない
依頼の経路はJavaScriptなしで動くか。アクセシブルか	見積依頼はフォームであり、JavaScriptの中にしか存在しないフォームは支援技術やスクリプトブロック時に失敗する	JavaScriptを無効にして依頼を送信する。フォームにアクセシビリティチェックをかける
価格を非表示にするなら、どの層か	見た目の非表示は価格要素をボタンに置き換えるだけで、ページソース、メタタグ、構造化データに数字が残る。検索エンジン対応の非表示はサインアウトした訪問者が受け取るHTMLから価格を取り除くもので、アプリはテーマ自身のマークアップを削除できないため、一度きりのテーマ編集が必要	サインアウト状態で商品ページのソースを表示し、価格を検索する。アプリが非表示をどう検証するか尋ねる

C. 顧客アカウントとバイヤー

質問	なぜ重要か	検証方法
現行の顧客アカウントを前提としているか。顧客アカウントを有効化していないストアではどうなるか	従来の顧客アカウントは2026年2月26日に廃止され、B2Bには対応していなかった。バイヤー体験は現行のアカウント内か、アプリが提供するホスト型ページにある	顧客アカウント未有効のストアが何を得るか尋ねる。正直な答えは「ホスト型ポータル」か「何もない」
アカウント内の体験は顧客アカウントUI拡張機能か	拡張機能はShopifyのログイン下でShopifyのアカウント内（注文一覧、注文状況、プロフィール、フルページ）で動き、バンドル上限は64 KB（フルページは128 KB）。それ以外は外部へのリンクにすぎない	テストバイヤーでサインインし、アプリのページがアカウント内にあるか別ドメインかを見る
ゲストには何が提供されるか	ネイティブB2Bは所在地に紐づく連絡先にしか価格を見せない。アカウントを持つ前に尋ねるバイヤーはファネルの入口	サインアウトして見積を依頼する。バイヤーへの連絡方法と、顧客ができた時に見積が紐づくかを確認する
複数の所在地を持つバイヤーを理解しているか	3つの所在地を持つ連絡先はチェックアウト前に1つを選ぶ。見積は個人ではなく所在地に属するべき	テスト連絡先に2つの所在地を与え、それぞれから見積を依頼する
バイヤーは見積と注文の履歴を1か所で見られるか	バイヤーは履歴から再注文する。バイヤーが行かない場所に履歴を置くアプリは見えないのと同じ	変換後にバイヤーのアカウントページで見積と結果の注文の両方を確認する

D. データ、プライバシー、ライフサイクル

質問	なぜ重要か	検証方法
どのデータを、どのリージョンに保存するか	氏名、住所、メール、電話番号は保護対象の顧客データ。所在地はクライアントにとって契約上の問題	プライバシーポリシーと再委託先リストを読む。リージョンを尋ねる
保護対象顧客データの承認を受けているか。どのレベルか	Shopifyは公開アプリにアクセスを許可する前に審査する。レベル2（氏名、住所、電話、メール）は暗号化バックアップ、環境分離、アクセスログ、インシデント対応方針を要求する	Partner Dashboardのアクセス状況とレベルを尋ねる。知らないアプリはやっていない
保持ポリシーは何か。マーチャントは変更できるか	添付ファイルと生成文書は蓄積する。保持期間はストレージコストではなくデータ保護の統制	保持のドキュメントを読む。ファイルがスケジュールで削除されるか確認する
マーチャントはすべてをエクスポートできるか	クライアントはいつか離れる。見積、バージョン、承認は一緒に持ち出せるべき	開発ストアでエクスポートを実行して開く
`shop/redact` が届いたとき、何が、いつ消去されるか	Shopifyはアンインストールの48時間後に `shop/redact` を送り、アプリはストアのデータを消去しなければならない。先に復旧期間を設けるアプリもある	正確な挙動と期間を尋ねる。ドキュメントと一致すべき
`customers/redact` と `customers/data_request` をどう扱うか	削除ウェブフックは削除リクエストの10日後、または顧客の最終注文から6か月経過後に届く。アプリの対応期限は30日。App Storeのすべてのアプリが3つとも実装しなければならない	顧客消去で何が削除され、データリクエストで何が返るかを尋ねる
アップロードされたファイルは検証されるか	見積の添付ファイルは認証されていないバイヤーからのアップロード	何を検査しているか尋ねる。ファイル種別とアクティブコンテンツの検証が正直な答え。マルウェアスキャンを謳うならスキャナー名を伴うべき
データ処理契約と再委託先リストはあるか	クライアント自身のプライバシー通知で名前を挙げる必要がある	契約前に両方を求める

E. APIと信頼性

質問	なぜ重要か	検証方法
GraphQL Admin APIか、レガシーのRESTか	REST Admin APIは「2024年10月1日以降レガシーAPI」であり、2025年4月1日以降の新しい公開アプリはGraphQLのみ。新しいB2Bフィールドは先にGraphQLに来る	アプリが今どのAPIを使っているか尋ねる。計画ではなく
どのAPIバージョンに固定し、どうアップグレードするか	Shopifyは四半期ごとにバージョンをリリースし、各バージョンを最低12か月サポートする。サポート外のバージョンは警告なしに「繰り上げ」られる。アプリはバージョンとアップグレード周期を答えられるべき	現在のバージョンを尋ね、2026年9月20日時点のサポート対象（2025-10、2026-01、2026-04、2026-07）と照合する
スロットリングされたときどう振る舞うか	Admin APIはStandardで毎秒100ポイント、Advancedで200、Plusで1,000、Commerce Componentsで2,000、クエリあたり1,000ポイントが上限で、バケットが空になると429を返す。`throttleStatus` を無視する一括処理は同じストアの他のアプリまで失敗させる	一括処理と同期がどうバックオフするか尋ねる。回答に `throttleStatus` を考慮した再試行があるか見る
どのウェブフックに依存し、取りこぼしたときどうなるか	Shopifyは失敗した配信を「4時間で8回」再試行し、その後サブスクリプションを削除する。配信は「常に保証されるわけではない」。`orders/create` だけで支払い済み注文を知るアプリは、いつか1件取りこぼす	Shopify自身が推奨するように、定期的にShopifyから取得する照合ジョブがあるか尋ねる
ウェブフック配信は検証され、重複排除されているか	HMAC検証と `X-Shopify-Webhook-Id` による重複無視は最低限。二重処理された `orders/create` は見積を二度支払い済みにしうる	直接尋ねる。ヘッダー名を含むイエス・ノーで答えられる
見積から注文への変換は冪等か	再試行されたリクエストや2つ目のワーカーが1つの承諾に2つの下書き注文を作りうる。対策は変換ごとの冪等キーと `draftOrderCreate` 前の排他	開発ストアで変換を続けて2回起動し、下書き注文の数を数える
管理画面は最新のApp Bridgeとセッショントークンで埋め込まれているか	Shopifyは埋め込みアプリにセッショントークンを要求し、「サードパーティCookieやローカルストレージを避ける」よう求めている。Built for Shopifyは最新のApp Bridgeを要求する	サードパーティCookieをブロックしたシークレットウィンドウでアプリを開く
どのアクセススコープを、なぜ要求するか	App Store要件3.2は必要なスコープだけを要求すること。`write_orders` や `read_all_orders` には理由が必要	インストール画面のスコープ一覧を読み、スコープごとの理由を尋ねる
クライアントはどう連携するか。Shopify Flowのトリガーとアクション、独自API、送信ウェブフック。それぞれ正確に何を公開するか	ERPとCRMの質問はここで答えが出る。「Flowがある」はトリガーとフィールドの一覧なしには何も意味しない	すべてのトリガー、アクション、フィールドを列挙したリファレンスページを求める
チェックアウトや顧客アカウントの拡張機能があるなら、レイテンシはどれくらいか	Built for Shopifyはチェックアウトのリクエストにp95で500ms以下を要求する	数値を尋ねる。推定ではなく計測される

F. 運用

質問	なぜ重要か	検証方法
営業担当は承認が必要な価格を承認なしで送れるか	画面上のリマインダーにすぎない「承認必須」は統制ではない。自動化も回避できないように、チェックは送信経路のサーバー側で実行されるべき	開発ストアでポリシーを設定し、営業担当アカウントから送信を試みる。次にアプリの自動化経由でも試す
営業担当は自分の見積を承認できるか	職務分掌は監査人が最初に尋ねること	営業担当を承認者にして試す
承認者ごとの上限とエスカレーションは表現できるか	「10％まで、それ以上はマネージャー」がよくあるポリシー	設定してみる。できないなら、それが答え
見積が期限切れになると承諾リンクは機能しなくなるか	承諾できてしまう期限切れの提案は価格の穴	開発ストアで1日の有効期限を設定し、翌日にリンクを試す
提案はバージョン管理され、送信後は変更不可か	バイヤーが受け取った文書は商取引の記録。送信済み提案をその場で編集するアプリは、何が合意されたか語れない	送信してから編集を試みる。アプリは新しいバージョンかカウンターを強制すべき
すべての状態変化に実行者とタイムスタンプ付きの監査証跡があるか	1年後の「この価格を誰が承認したか」	2人のユーザーで5つの操作を行い、ログを読む
役割はShopifyスタッフとどう対応するか	Shopifyの営業スタッフ権限は営業担当が見られる会社レコードを決め、アプリの役割は見積に対して何をしてよいかを決める。両者は矛盾せず組み合わさるべき	Shopifyスタッフを1つの所在地に制限し、アプリが何を見せるかを確認する
文書には何が載るか	発注書番号、条件、有効期限、明細ごとの価格、バージョン番号。クライアントが必要なら署名欄	開発ストアでPDFを生成し、クライアントの要件と項目を照合する
バイヤーは一部の明細を承諾して残りを開いたままにできるか。そのとき注文には何が含まれるか	複数明細の案件が丸ごと成約することはまれ	テストで4行中2行を承諾し、下書き注文を読む
サポートモデルは何か	時間、チャネル、応答目標、ステータスページ、開発者の緊急連絡先が最新かどうか	リスティングを読んで尋ねる

G. 商務

質問	なぜ重要か	検証方法
どの機能がどのプランにあり、その区分はShopifyの機能に従うか、プラン名に従うか	クライアントのプランとアプリのプランは別々の関門。どちらも明示されるべき	料金ページを読む。次にPlus以外のB2B開発ストアで確認する
Built for Shopifyか。それが何を証明するか分かっているか	バッジは上記のストアパフォーマンス規則、p75での管理画面Web Vitals（LCP 2.5秒、CLS 0.1、INP 200ms）、有料プランのアクティブストアからの純インストール50件以上、レビュー5件以上、最新のApp Bridgeを要求する。技術的な健全性とある程度の普及を証明するが、B2B機能を評価するものではない	リスティングのバッジを確認する。それでもこのリストの残りを実施する
クライアントが支払う前に、開発ストアで構築全体を証明できるか	エージェンシーの構築は本番ストアのトライアルより長くかかる	有料機能が開発ストアで動くか尋ねる
離れるときに何が戻ってくるか	エクスポート形式、下書き注文と注文が残るか（残るべきだ。Shopifyのものだから）、アプリが何を保持するか	エクスポートを実行し、アンインストールのドキュメントを読む

よくある質問

Built for Shopifyは実際に何を保証しますか

計測可能な3項目と普及のしきい値1つです。アプリがストアのLighthouseスコアを10ポイント以上下げないこと、管理画面が75パーセンタイルでWeb Vitalsを満たすこと、チェックアウトのリクエスト（あれば）のp95が500ms未満であること、有料プランでの純インストール50件以上とレビュー5件以上があること。会社を使っているか、カタログ価格を読んでいるか、承認を強制しているか、データを適切に消去しているかは確認しません。判定ではなくフィルターとして扱ってください。

テーマにコードを注入するアプリは除外すべきですか

新規構築なら、拡張機能モデルでは実現できない明確な理由がない限りイエスです。テーマアプリ拡張機能はマーチャントがテーマエディターで追加・削除できます。注入コードは手作業で探して除去する必要があり、テーマが変わると壊れ、テーマ更新後にアプリが「動かなくなった」原因はたいていこれです。

アプリにShopify Plusは必要ですか

Shopify自身がPlusに限定しているもの（無制限のカタログ、カタログの直接割り当て、前受金、部分支払い）についてだけです。会社、所在地、カタログ、数量ルール、数量別価格、支払い条件、下書き注文は2026年4月2日以降すべてのプランにあるため、会社対応の見積にPlusを要求するアプリは機能ではなくプラン名を見ています。プランマトリクスに全リストがあります。

コードを読まずに「サーバー側で強制」を検証するには

アプリの画面ではないクライアントから、ルールが禁じることをやってみてください。ブラウザのネットワークタブでフォームのリクエストを別の商品IDで再送して除外商品の依頼を送る、営業担当アカウントから承認が必要な提案を送る、期限切れ見積のリンクで承諾する。サーバーがそれぞれを拒否すれば、ルールは本物です。このパターンはリストのあらゆる「XはYを回避できるか」の質問に当てはまります。

アプリ独自のAPIについては

独自のAPIがないアプリが失格になるわけではありません。連携ニーズの大半はShopify Flowのトリガーとアクション、そして変換が生むShopify注文で満たされます。重要なのは、ベンダーがどれに当たるかを明言し、トリガーが何を公開するかを列挙し、ロードマップを機能として説明しないことです。

QuotWayの回答はどこにありますか

このリストがどのアプリにも使えるよう、ここには載せず別に公開しています。QuotWayにできること、できないことが機能と強制に関する質問にプランごとに答え、セキュリティとデータ保護がデータ、保持、ウェブフックの質問に答えます。B2B機能ページと料金がネイティブ適合とプラン区分の行をカバーします。他のアプリに対してやるのと同じように、このリストを当ててください。

出典

Shopifyのページ。いずれも2026年9月20日に確認：

QuotWayがこれをあなたのストアでどう扱うかをご覧ください。

機能を見る Shopifyに無料でインストール

← 記事一覧