Shopify B2Bのセキュリティ診断：ストアと見積アプリのための40項目チェックリスト

Shopify B2Bストアのセキュリティ診断が答えるべき問いは4つです。誰がどれだけの権限で管理画面に入れるか、バイヤーは何を見て何ができるか、価格はどこで変更できるか、そしてShopifyの外にどんな認証情報とエンドポイントがあるか。 以下の40項目はこの4つに、診断で把握すべきデータを加えたものです。各項目に、根拠となるShopifyの規則と、自分で確かめる方法を添えています。

2026年は、3つの日付によってこれが単なる後片付けではなくなります。2026年1月1日以降、Shopifyの管理画面ではカスタムアプリを新しく作成できなくなりましたが、既存のものは動き続けます。新しい公開アプリは2026年4月1日から有効期限付きのオフラインアクセストークン（expiring offline access token）を使う必要があり、すべての公開アプリは2027年1月1日までに移行しなければならず、それ以降、有効期限のないトークンは認証エラーになります。カスタムアプリとマーチャントが作成したアプリは対象外です。つまりその日以降、ストアに残る長期間有効なトークンこそ、診断で見つけるべきものになります。

このチェックリストはベンダー中立です。これはストア自身の診断であり、アプリベンダーに自社のデータの扱いについて尋ねる質問はShopify B2Bアプリの評価方法にあります。このページではそれを繰り返さず、そちらへリンクしています。書いたのはベンダーであり、自社の回答は別に公開して末尾でリンクしています。

以下のShopifyに関する記述は、別の日付を記していない限り、2026年9月25日にShopify自身のページでAPIバージョン2026-07を対象に確認しました。出典は末尾にあります。

診断の進め方

1. 打ち合わせの前に事実を書き出す。 各スタッフとその権限の一覧、コラボレーターの一覧、インストール済みのアプリと付与されたスコープ、すべてのカスタムアプリ、そして会社の一覧と各担当者の役割です。AとBのセクション、そしてDの大半は、この5つの一覧を読めば答えが出ます。
2. バイヤー側はバイヤーとしてログインして確かめる。 開発ストア、または所在地が2つあり、役割ごとに担当者を1人ずつ置いたテスト用の会社があれば、各役割に何が見えるかを確認できます。
3. すべての行に答えと根拠を記録する。 診断の価値は記録で決まります。次の担当者が、何をいつ確認し、何が見つかったかを読めるようにしてください。

A. 管理画面のアクセス：スタッフ、コラボレーター、二段階認証

#	チェック項目	理由（Shopifyの規則）	確認方法
1	すべてのユーザーで二段階認証が有効になっている	「Shopify Plusプランのストアは、組織内のすべてのユーザーに安全なログイン方法の使用を必須にできます」。ほかのプランでは、各ユーザーが自分のアカウントで有効にする	Plus：組織のセキュリティ設定を確認する。ほかのプラン：各ユーザーに尋ね、有効になっていないアカウントは指摘事項として扱う
2	2つ目の要素をSMSだけに頼っている人がいない	ShopifyはSMSを新規の設定では提供しておらず、既存のアカウントに残っているだけ。サポートされる方法は認証アプリ、セキュリティキー、端末内蔵の認証機能	各管理者に、どの方法を使っているかを尋ねる
3	コラボレーターのアカウントを把握し、範囲を絞っている	コラボレーターはオーナーが承認したパートナー。「必要な権限」を持つ役割を与えられ、「ストアのユーザー数の上限には数えられない」ため、忘れられやすい	コラボレーターの一覧を書き出し、それぞれについてエージェンシー、担当者、役割、契約の終了日を記録する
4	コラボレーターのリクエストコードが出回っていない	「コードを共有したパートナーだけがストアへのアクセスをリクエストできます」。コードは再生成できる	契約が終わったら再生成する
5	退職者は、実質的に使われていないだけでなく削除されている	スタッフとコラボレーターは削除されるまでアクセスを保つ。コラボレーターの削除は取り消せない	スタッフとコラボレーターの一覧を、現在いる人と突き合わせる
6	顧客のエクスポートとデータのリクエストを持つ人が少ない	顧客の「エクスポート」は独立した権限で、「データをリクエスト」はShopifyが注意を促す機密性の高い権限の1つ	それぞれを持つ人を一覧にする。少人数で、理由があるべき
7	下書き注文を作る人が、価格を決めるべき人である	下書き注文の作成・編集には、支払いに関する権限（支払い条件、カードへの請求、支払い済みにする）が少なくとも1つ必要。「割引を適用」は別の権限	下書き注文の作成・編集と割引の適用を持つユーザーごとに、その役割に必要かを確認する
8	営業担当が自分の所在地に制限されている	「割り当てられた会社所在地に権限を制限」は、営業担当が見られるものを顧客、注文、下書き注文、会社に限り、担当の所在地で絞り込む。1つの所在地に営業スタッフは最大10人	営業担当としてログインし、割り当てられていない会社を開こうとしてみる
9	会社の削除が既定の権限になっていない	会社と所在地の削除はそれ自体が独立した権限	それを持つ人を一覧にする
10	「設定を管理」を意図して付与している	webhookやMarketsを含むストアの設定を扱う権限	それを持つ人を一覧にする。管理画面で追加したwebhookは、ストアのデータを外部のURLへ送る

B. バイヤー側：担当者、役割、ログイン

#	チェック項目	理由（Shopifyの規則）	確認方法
11	各担当者に、用が足りる最も狭い役割が与えられている	「注文のみ」：その所在地のために購入し、自分の注文を見る。「ロケーション管理者」：「その所在地ですべての顧客が行った注文」を見て、配送先と請求先の住所を更新できる	担当者を役割とともに書き出す。既定は「注文のみ」とし、所在地ごとに「ロケーション管理者」を名指しで置く
12	主担当者の役割は引き継いだものではなく選んだものである	「主担当者には既定で注文のみの権限が割り当てられます」。多くの場合は問題ないが、バイヤーが必要なものを見られない原因になることもある	各所在地の主担当者を確認する
13	バイヤーのメールボックスを認証情報として扱っている	B2Bのバイヤーは、会社所在地に登録されたメールアドレスとワンタイムコードでログインする。パスワードはない。つまりそのメールボックスを管理する人がバイヤーのアカウントを管理する	担当者のメールアドレスが、特定の個人か管理された共有受信箱であり、退職者のアドレスではないことを確認する
14	バイヤーの会社で人が辞めたら担当者を削除している	担当者は、メールボックスを誰が持っていても、削除されるまで担当者のまま	担当者の見直しをアカウントマネージャーの定例作業に入れ、バイヤー側の管理者に退職者を尋ねる
15	会社の価格はログイン中の会社のバイヤーにだけ表示される	会社所在地に紐づいていないバイヤーは、ログインしていてもD2Cの顧客として扱われ、D2Cの価格を見る	紐づいていない顧客と会社の担当者の両方でログインし、比べる
16	バイヤーが自分で別の所在地に切り替えられない	複数の所在地を持つバイヤーが選べるのは、自分が役割を持つ所在地だけ	所在地を1つだけ持つ担当者でログインし、ほかの所在地が表示されないことを確認する

C. 価格の整合性：価格はどこで設定されるか

BtoBで最も重要なのは「誰かが価格を見られるか」ではなく、「誰かが承認された経路の外で価格を変えられるか」です。Shopify B2Bストアで価格が正当に設定される場所は限られており、それ以外はすべてバイヤーが操作できる入力です。

価格が正当に設定される場所	管理するもの
カタログの価格表と数量別価格	カタログの権限を持つスタッフ
下書き注文の明細と割引	下書き注文と割引の権限を持つスタッフ
Shopifyの割引	割引の権限を持つスタッフ。チェックアウトでShopifyが適用する
カート変換（cart transform）関数の lineUpdate	アプリのサーバー側関数。Plusと開発ストアのみ
アプリ自身のサーバーで決め、上のいずれかに反映したもの	そのアプリ。付与されたスコープの範囲で

バイヤーが値を送る場所	意味すること
明細プロパティ（商品フォームの properties[...]）	顧客自身の入力としてドキュメント化されている。刻印の文字、メモ、アップロード
カート属性、フォームの項目、URLパラメーター	ブラウザが送るものはすべてブラウザで書き換えられる

#	チェック項目	理由	確認方法
17	バイヤーの入力から価格を読むアプリやテーマがない	明細プロパティは顧客が設定するもの。そこから、あるいはカート属性やURLから取った価格は、バイヤーが選んだ価格である	価格アプリや見積アプリごとに、明細の価格がどこから来るのかを尋ねる。カートへ送信するテーマのコードを読む
18	カートでの価格の上書きはサーバー側の関数でのみ行われる	カート変換の lineUpdate は「カートの明細の価格、タイトル、画像を上書き」でき、使えるのはPlusか開発ストアだけ	インストールされたカート変換関数と、それぞれが価格の根拠にしているものを一覧にする
19	利益を守るルールがサーバーで動いている	カートとチェックアウトの検証Function APIは、B2Bのチェックアウトと下書き注文でサーバー側で動く。テーマのコードはバイヤーのブラウザで動く	各ルール（最低数量、発注書番号の必須、所在地の制限）を、カタログ、数量ルール、検証Functionのどれかに対応付ける
20	注文を作成する連携がルールを適用し直している	検証FunctionはCreate Order APIでも注文編集でも動かない	注文を書き込む連携ごとに、バイヤーのルールをどこで強制しているかを尋ねる
21	交渉による割引に承認者がいる	下書き注文には、権限を持つスタッフが付けた価格がそのまま載る	誰が割引を適用できるか、一定額を超えるものに2人目が必要かを確認する
22	請求書のリンクを、想定ではなく実際に試している	Shopifyの請求書のページは、チェックアウトのリンクをメールで送るかメッセージに貼り付ける方法を説明し、先に注文を支払い済みにしないよう注意している。ほかに誰がリンクを開けるか、有効期限があるかは書いていない	ログアウトした状態、プライベートウィンドウ、別の端末で請求書のリンクを開き、見えたものを記録して、自社のバイヤーにとって許容できるかを判断する
23	支払いの前に下書き注文を支払い済みにしない	「支払い済みにする」は支払いの権限。バイヤーが支払う前に支払い済みにすると請求書のリンクが使えなくなり、届いていないお金が記録される	「支払い済みにする」を持つ人を一覧にする

D. アプリ、認証情報、エンドポイント

#	チェック項目	理由（Shopifyの規則）	確認方法
24	各アプリに付与されたスコープがその役割に見合っている	アクセススコープ（access scopes）は「アプリがどのストアデータを読み書きできるかを制御」する。Shopifyはアプリに「必要なデータだけを要求する」よう求めている。書き込みのスコープは読み取りを含む	インストール画面とデータアクセスの画面で各アプリのスコープを読み、アプリの役割で説明がつかない write_ スコープを問いただす
25	設定されたスコープではなく、付与されたスコープを確認した	任意のスコープは「インストール後に別途付与」されるため、アプリが実際に持つものは設定と異なることがある	カスタムアプリは付与されたスコープをクエリする。公開アプリは管理画面のデータアクセスのページを読む
26	長期の注文履歴にアクセスするアプリには理由がある	read_all_orders（既定の60日を超える範囲）にはShopifyの承認が必要	アプリごとに理由を尋ねる
27	すべてのカスタムアプリを担当者とともに棚卸ししている	2026年1月1日以降、管理画面ではカスタムアプリを作成できないが、既存のものは「引き続き動作」する。新しいカスタムアプリはDev Dashboardで作る	カスタムアプリごとに、誰が作ったか、何をするか、今も使われているかを一覧にする
28	長期間有効なトークンを把握し、失効させられる	有効期限のないオフライントークンは「アプリがアンインストールされるかシークレットが失効するまで永続的なアクセス」を与える。カスタムアプリとマーチャントが作成したアプリは2027年の有効期限の規則の対象外	カスタムアプリごとに、アクセストークン（access token）がどこに保存され、誰が読めて、今日失効させるならどうするかを確認する
29	公開アプリが有効期限付きトークンに移行済みか、計画がある	新しい公開アプリは2026年4月1日から、すべての公開アプリは2027年1月1日までで、それ以降、有効期限のないトークンは「認証エラーを受け取る」。有効期限付きトークンの寿命は1時間で、90日有効なリフレッシュトークンが付く	公開アプリのベンダーごとに、移行したかを尋ねる
30	webhookをHMACで検証している	配信ごとに X-Shopify-Hmac-SHA256 が付く。これはアプリのクライアントシークレットで生のボディから計算したbase64のHMAC。生のボディで検証し、定数時間で比較し、失敗したら401を返す	自社のエンドポイントはハンドラーを読む。ベンダーについてはアプリ評価チェックリストの質問として尋ねる
31	webhookのハンドラーが冪等である	配信は重複することがある。X-Shopify-Webhook-Id で重複を排除する	開発ストアで配信を再送し、何も二重に起きないことを確認する
32	アプリプロキシのエンドポイントが署名と所有者を確認している	アプリプロキシのリクエストには、ほかのパラメーターに対する signature が付く。検証のあと、logged_in_customer_id を要求されたデータの所有者と照合する必要がある。ShopifyはCookieを取り除く	バイヤーのデータを返すアプリプロキシのルートごとに、両方の確認を確かめる
33	顧客アカウント拡張が、誰が要求しているかを証明している	拡張のネットワーク呼び出しは、信頼できないオリジンからCORS * で送られる。顧客を証明するのはセッショントークン	拡張のバックエンドごとに、セッショントークンを検証し、ボディで送られた顧客IDや会社IDを決して信用しないことを確認する
34	管理画面で追加したストアのwebhookを把握している	管理画面で作ったwebhookは、入力されたURLへストアのデータを送る	管理画面の設定で作られたwebhookを一覧にする。それぞれに担当者と目的が必要

E. 顧客データと支払い

#	チェック項目	理由（Shopifyの規則）	確認方法
35	カード番号はShopifyのチェックアウトにしか入力されない	「ShopifyはLevel 1 PCI DSSの認定を受けています」。認定の範囲は「ストア、そのショッピングカート、ウェブホスティング」であり、見積フォーム、メールのやり取り、アップロードされたファイルは含まれない	見積フォーム、カスタム項目、アップロード欄に、カード情報の入力を促すものがないか探し、あれば取り除く
36	顧客データを持つアプリがその承認を受けている	氏名、住所、メールアドレス、電話番号は保護された顧客データで、公開アプリがアクセスするにはShopifyの承認が必要	アプリ評価チェックリストのベンダー向けの質問でカバーする
37	アンインストール時の消去を理解している	shop/redact はアンインストールの48時間後に届く。customers/redact はリクエストの10日後、または顧客の最終注文から6か月後。アプリの対応期限は30日	各アプリのドキュメントにある挙動を、これらの日付と並べて記録する
38	ファイルのアップロードが検証され、アクセスが管理されている	バイヤーは図面、仕様書、発注書を依頼に添付する。ファイルはストアが保持するデータになる	アップロードにどんな検証（種類、サイズ、アクティブコンテンツ）があるか、どこに保存されるか、誰がダウンロードできるかを尋ねる
39	顧客のエクスポートに記録が残る	エクスポートとデータのリクエストは設定ではなく権限なので、管理とは誰がそれを持つかである	チェック6と結び付け、エクスポートしたファイルをどこに保存してよいかを決める
40	診断に日付があり、次回が予定されている	上の行のうち2つは公表された日付で変わり（トークンは2027年1月1日）、ShopifyはB2Bの変更を四半期ごとに出す	次の診断をカレンダーに入れる。管理画面のスタッフが変わるたび、新しいアプリを入れるたび、Shopify Editionのたびに実施し直す

認証情報のカレンダー

日付	何が変わったか	何を確認するか
2026年1月1日	Shopifyの管理画面でカスタムアプリを作成できなくなった。既存のものは動き続ける	棚卸しする（チェック27）
2026年4月1日	新しい公開アプリは有効期限付きオフラインアクセストークンが必須に	ストア側の作業はない。ベンダーに関係する
2027年1月1日	すべての公開アプリで有効期限付きトークンが必須に。有効期限のないトークンは認証エラーになる	ベンダーに尋ねる（チェック29）。カスタムアプリとマーチャントが作成したアプリは対象外なので、この日以降はチェック28の重要性が下がるのではなく上がる

廃止されたチェックアウトの仕組み ― checkout.liquid、追加スクリプト、Shopify Scripts ― もセキュリティの問題です。誰も保守していないコードは、誰も見直していないコードだからです。その日付はShopify B2Bの技術的負債にまとめています。

QuotWayの回答はどこにあるか

このチェックリストをどのストアとどのアプリにも使えるように、ここには載せず別に公開しています。セキュリティとデータ保護がQuotWayのデータの扱い、保持、webhookを、サブプロセッサーの一覧が誰が何を処理するかを扱い、QuotWayにできること、できないことが強制と権限に関する質問にプランごとに答えます。割引の承認がどう振り分けられ強制されるかは承認機能のページにあります。見積アプリや価格アプリに尋ねるべき質問はアプリ評価チェックリストに、機能面は50テストの公開チェックリストにあります。プランは料金ページをご覧ください。

この記事のShopify関連の事実はShopify B2Bリファレンスで最新に保っています。

よくある質問

Shopifyのすべてのスタッフに二段階認証を必須にできますか？

できるのはShopify Plusだけです。Plusでは組織としてすべてのユーザーに安全なログイン方法を必須にできます。ほかのプランでは各ユーザーが自分のアカウントで有効にするため、診断では1人ずつ尋ねる必要があります。コラボレーターのアカウントは別で、パートナーはそもそも二段階認証を有効にしないとコラボレーターのアカウントを使えません。

コラボレーターのアカウントはスタッフ数の上限に数えられますか？

数えられません。Shopifyは「コラボレーターはストアのユーザー数の上限には数えられない」と明記しており、これが忘れられやすい理由の1つです。コラボレーターは、パートナーに渡す4桁のリクエストコードで申請され、役割で範囲が決まり、削除すると元に戻せません。

Shopifyのアクセストークンに有効期限はありますか？

有効期限付きのオフラインアクセストークン（access token）の寿命は1時間で、90日間有効なリフレッシュトークンが付きます。新しい公開アプリは2026年4月1日からこれを使う必要があり、すべての公開アプリは2027年1月1日までに移行しなければならず、それ以降、有効期限のないトークンは認証エラーを受け取ります。カスタムアプリと、マーチャントがDev Dashboardや管理画面で作成したアプリは対象外で、その有効期限のないトークンは、アプリがアンインストールされるかシークレットが失効するまで有効です。

Shopifyのwebhookはどう検証しますか？

アプリのクライアントシークレットを使って生のリクエストボディのHMAC-SHA256をbase64で計算し、X-Shopify-Hmac-SHA256 ヘッダーと定数時間で比較します。ボディのパーサーがペイロードに触れる前に検証し、一致しなければ401を返し、処理済みの X-Shopify-Webhook-Id の配信はスキップします。

ShopifyのPCI準拠はBtoBの見積の流れもカバーしますか？

ShopifyはLevel 1 PCI DSSの認定を受けており、その範囲はストア、そのショッピングカート、ウェブホスティングです。見積フォーム、メール、アップロードされたファイルなど、それ以外の場所で集めたカード情報は、その認定が記述する範囲の外にあります。支払いはShopifyのチェックアウトか下書き注文の請求書の中にとどめてください。

バイヤーはカートを通じて価格を変えられますか？

Shopifyが価格として扱うものを通じては変えられません。明細プロパティとカート属性はバイヤー自身の入力なので、リスクはそこから価格を読むアプリやテーマにあります。カートでの価格の上書きはカート変換関数の lineUpdate 操作で、これはサーバー側で、Plusか開発ストアでのみ動きます。

「ロケーション管理者」には見えて「注文のみ」の担当者には見えないものは何ですか？

「ロケーション管理者」は、どの担当者が出したものでも、その会社所在地の注文をすべて見られ、所在地の配送先と請求先の住所を更新できます。「注文のみ」の担当者が見られるのは自分が出した注文です。主担当者は「注文のみ」から始まります。

出典

Shopifyのページ。別記がない限り、すべて2026年9月25日にAPIバージョン2026-07で閲覧：

• 二段階認証とコラボレーターのアカウント
• スタッフの権限の説明
• 会社の担当者、B2Bのログインと顧客アカウント、営業スタッフ（後の2つは2026年9月20日〜23日閲覧）
• アクセススコープと保護された顧客データ（2026年9月20日閲覧）
• オフラインアクセストークン、changelogの新しい公開アプリ（2026年4月1日）とすべての公開アプリ（2027年1月1日）の項目、2026年1月1日以降はレガシーのカスタムアプリを作成できない
• HTTPSでのwebhook配信とアプリプロキシの認証
• 顧客アカウント拡張の機能（2026年9月22日閲覧）
• カート変換、カートとチェックアウトの検証（2026年9月24日閲覧）、明細プロパティ
• 下書き注文の請求書を送る
• ShopifyのPCI準拠