Shopifyのカスタムアプリで見積（RFQ）を開発するか、買うか：2026年に動かし続けるもの

Shopifyでカスタムの見積（RFQ）アプリを開発すべきなのは、見積のワークフローそのものが製品であるとき ― 調達のルール、契約に基づく交渉、どのアプリも出力しない書類 ― で、しかもストアが営業を続ける限り、Shopifyの予定に合わせたアプリの保守に誰かが費用を出すときです。ワークフローが依頼、価格設定、交渉、承認、変換という標準的なループなら、買ってください。1つの構成要素だけが独自で残りが標準なら、違う部分だけを開発してください。この判断で難しいのは、最初の開発であることはまれです。難しいのは前の文の後半です。誰が見ていようといまいと、Shopifyは四半期ごとの予定で変わっていくからです。

ネイティブB2B、見積アプリ、独自開発、CPQは4択の判断です。このページはその独自開発の枝を掘り下げたものです。2026年のカスタムアプリとは何か、ShopifyがどこにPlusの制限を置いているか、Shopify上のRFQシステムを実際に構成する20の要素、稼働中の見積アプリ1つ ― 私たちのもの ― の日付入りの保守記録、そして立ち上げではなく継続的な義務に値段を付けるためのワークシートを扱います。

以下のShopifyに関する記述は、すべて2026年10月7日にShopify自身のページでAPIバージョン2026-10を対象に確認しました。出典は末尾にあります。保守記録はQuotWayによる観察です。1つのアプリの数か月分の記録であり、発生率ではありません。

2026年のShopifyカスタムアプリとは

カスタムアプリとは、「あなたのShopifyストア専用に」作られるアプリです。管理画面での作成が終わってからは、Dev Dashboardで作成・管理し、Shopify CLIで構築して、自分で生成したリンクからインストールします。開発の判断を左右する規則は次のとおりです。

• 配布方法。 カスタム配布では、1つのストア、または1つのShopify Plus組織のストアにインストールします。公開配布はApp Storeへの掲載と審査を意味します。どちらを誰が使うかについて、Shopify自身はこう書いています。「特定のマーチャントやエージェンシーのクライアント向けに作られるアプリの多くは、カスタム配布を使います」。
• 選択は変更できない。 Shopifyによれば、配布方法は一度選ぶと変更できません。同じアプリをあとでほかのマーチャントにも販売するかもしれないエージェンシーは、今決めておく必要があります。
• 審査なし、Billing APIなし。 カスタム配布はアプリ審査を経ず、ShopifyのBilling APIで課金することもできません。エージェンシーはShopifyの外で請求します。
• 管理画面で作成するアプリはもうない。 2026年1月1日以降、Shopifyの管理画面ではカスタムアプリを作成できません。管理画面で作成した既存のアプリは引き続き動作しますが、もともとApp Bridgeもアプリ拡張も使えなかったため、RFQシステムの出発点にはなりません。
• 複数のクライアント、1つのコードベース。 カスタム配布は1つのPlus組織までなので、無関係な複数のストアを担当するエージェンシーは、同じコードからクライアントのストアごとに1つのアプリレコードをデプロイするか（Shopifyのデプロイガイドは、1つのコードベースに複数のアプリレコードを認めています）、公開配布にします。

カスタムアプリで使えるもの、Plusで分かれるもの

機能	カスタムアプリで	Shopify側の制限
Admin GraphQL APIとウェブフック	使える	アクセススコープ。一部のスコープはShopifyの承認が必要（スタッフの識別に使う read_users はPlusまたはAdvancedが必要）
埋め込みの管理画面UI（App Bridge）	使える	-
テーマアプリ拡張（ストアフロントのボタン、ブロック、アプリ埋め込み）	使える	拡張ごとのサイズ上限
顧客アカウントUI拡張（購入者のポータル）	使える	拡張ごとに64 KB、ページ全体は128 KB
情報、配送、支払いのステップのチェックアウトUI拡張	使える	Shopify Plusでのみ利用可能。カスタムアプリに限らず、すべてのアプリが対象
Shopify Functions（検証、カート変換、割引）	使える	カスタムアプリではPlusのストアでのみ利用可能。公開アプリはどのプランでも使える
Shopify Flowのトリガーとアクション	使える	カスタムアプリではPlusのストアでのみ利用可能
Sidekickアプリ拡張	記載なし	ShopifyのSidekickのページは、どちらとも書いていない
Billing API	使えない	カスタム配布では使えない
Built for Shopify	対象外	インストール数とレビューに関する前提条件があるApp Storeのプログラム

Shopifyはアプリ拡張の規則を否定の形で書いています。アプリ拡張が使えないのは、管理画面で作成したアプリだけです。CLIで構築したカスタムアプリは、上の制限の範囲で使えます。

トークン、データ、ホスティング

アクセストークン。 埋め込みアプリはトークン交換（token exchange）で、埋め込みでないアプリは認可コードグラント（authorization code grant）でトークンを得ます。自社の組織内のストアだけに触れるサーバー側の連携は、クライアントクレデンシャルグラント（client credentials grant）を使えます。これはマーチャントの承認画面なしで、24時間有効なトークンを発行します。期限付きオフライントークン（1時間、リフレッシュは90日）は2027年1月1日に公開アプリで必須になりますが、Shopifyは「これはカスタムアプリやマーチャントが作成したアプリには適用されない」としており、それらのトークンはアプリがアンインストールされるか、クライアントシークレットが失効するまで有効なままです。それでも期限付きトークンを選んでください。エージェンシーが持つ無期限の認証情報こそ、ストアのセキュリティ診断が見つけるよう求めているものです。

スコープ。 「リソースに書き込むスコープは、そのリソースの読み取りアクセスも付与する」 ― そしてそのとき、Shopifyの付与済みスコープの一覧には書き込みスコープしか表示されません。この1文が、私たち自身のアプリで本番の不具合を起こしました（後述）。read_orders で読めるのは直近60日分で、それより古い注文には、申請が必要な read_all_orders が要ります。

顧客データ。 レベル1とレベル2の保護対象顧客データは、カスタムアプリには審査なしで「常に利用可能」です。公開アプリには審査が必要です。Shopifyは「すべてのアプリ」に同じ要件を満たすよう推奨しており、ヘルプセンターは「カスタムのレベル2 PIIアプリ」にはGrowプラン以上が必要だと補足しています。3つのコンプライアンスウェブフックはApp Storeの要件ですが、Shopifyは顧客または注文へのアクセスを持つインストール済みのアプリすべてに customers/data_request を送り、マーチャントのデータ保護法はいずれにしても適用されます。ですからカスタムの開発でもハンドラーを実装します。

ホスティング。 「Shopifyがホストするのは拡張のコードだけです」。バックエンド、そのデータベース、キュー、そしてShopifyが呼び出すすべてのエンドポイント ― 5秒でタイムアウトするウェブフックの受信先、ストアフロントのフォームの背後にあるアプリプロキシ ― は、自分で選んで維持するホスティングで動かします。

カスタムアプリで作るRFQシステム：20の構成要素

Shopifyには見積のオブジェクトがありません。下書き注文は更新のたびに丸ごと置き換えられ、1年間編集がないと削除されるので、最後の合意内容は載せられても、その前の交渉は載せられません（下書き注文が見積ではない理由）。それ以外はすべて自分で作ることになります。

#	構成要素	依存するShopifyの機能	難所
1	依頼の受付：ボタン、フォーム、カートからの見積	テーマアプリ拡張。署名付きの送信にはアプリプロキシ	購入者と会社ごとの対象判定を、遅い往復なしで行うこと。テーマの多様さ。ストアフロントの重さ
2	価格の表示	テーマアプリ拡張。価格をHTMLに出さないためのテーマのLiquid条件	CSSやスクリプトでの非表示は見た目だけ（価格を非表示にする方法）
3	見積のレコードと変更不可のバージョン	自前のデータベース	送信したバージョンは変わらない。変更は新しいバージョンになる
4	交渉とカウンターオファー	自前のデータベースと購入者向けの画面	どちらの番か。購入者が選ばなかった明細は失われたのではなく、未決のまま残る
5	開始価格	会社の所在地に対する contextualPricing（2026-10からは auditTrail 付き）	カタログの優先順位。2つ目の価格表は決して持たない（見積の開始価格）
6	合計と金額	自前のコード。Shopify側の計算には draftOrderCalculate	合意した金額を保存する。表示された行を足し直さない
7	承認と監査	自前のデータベース。承認制のスコープによるスタッフの識別	強制はサーバー側で、決定は追記のみ（承認マトリクス）
8	書類	自前のバックエンド	バージョンごとに1つの書類。見積に記載すべき内容
9	メール通知	自前のバックエンドとメール配信サービス	到達率、配信停止、安全な再送
10	購入者ポータル	顧客アカウントUI拡張と、自分でホストするバックエンド	拡張から自前のバックエンドへの認証。アカウントのないゲスト（ポータルの構築）
11	下書き注文への変換	draftOrderCalculate、purchasingEntity 付きの draftOrderCreate、価格の上書き、支払い条件	draftOrderCreate には2026-10でも冪等キーがない（下書き注文をちょうど1件にする）。見積と変換の間のずれ（17の失敗パターン）
12	ウェブフックと突合	orders/*、draft_orders/*、app/* とコンプライアンスのトピック	重複、順序、自分の書き込みより先に届く注文、取りこぼした配信を拾う定期点検
13	管理画面UI	埋め込みアプリ（App Bridge、Polaris）、必要に応じて管理画面ブロック	すべての画面を自分で作り、Shopifyの管理画面の変化に合わせ続けること
14	スタッフの権限	自前のモデル	誰が送信、承認、変換できるか（営業担当による見積）
15	多通貨とマーケット	国ごとのコンテキスト価格。下書き注文の表示通貨	見積時点でレートを固定すること
16	翻訳	拡張ごとのロケールファイルと、自前の文字列	購入者に見えるすべての文字列を、すべての画面で
17	分析	自前のデータベース。Shopifyのレポートは見積を見ない	提示額と承諾額の対比。通貨の構成
18	連携と自動化	Flow拡張（カスタムアプリではPlusのストアでのみ）、自前のAPIとウェブフック、Sidekick拡張	機能ごとにバージョン管理が異なる（基幹システム・CRM・PIMの連携パターン）
19	コンプライアンスとデータ	コンプライアンスウェブフック、保護対象顧客データ	購入者データを持つすべてのテーブルにわたる削除
20	ホスティングと運用	自前のホスティング、データベース、キュー、エラー追跡	Shopifyが呼び出すエンドポイントの稼働。バックアップ。シークレット

規模の目安として、出荷済みの見積アプリ1つ ― 私たちのもの ― の形を、2026年10月7日にリポジトリから読み取って示します。アプリ拡張27個：アプリ埋め込みと4つのブロックを持つテーマアプリ拡張1つ、顧客アカウントUI拡張2つ、管理画面ブロック1つ、Flow拡張19個（トリガー10、アクション3、テンプレート6）、Sidekick拡張3つ。ウェブフックのトピック10個（3つのコンプライアンストピックと、ほかに7つ）。データモデル53個。Plus以外のストアのカスタムアプリなら、19個のFlow拡張はすべて使えません。

カスタムアプリの保守は実際にどう見えるか

これは1つのアプリの記録で、保守担当者がつけているものです。発生率ではありません。ただ、どの項目も私たちの予定ではなく、Shopifyの予定でやってきました。

18日間のShopifyの変更。 2026-10リリースに向けてShopifyに関する事実を確認し直したところ、2026年9月20日から10月7日までの間に、B2Bとアプリの領域で日付のある変更を17件記録しました。その一部です。

• Sidekickがインテントのみの拡張を呼び出し始めた（9月28日）。
• 割引用のアプリインテントが新たに加わった（9月30日）。
• API 2026-10が安定版になり、2027-01がリリース候補に、2025-10は10月16日でサポート終了。
• 下書き注文の割引に関する警告から priceRule が削除され、orderUpdate は配送先住所が変わると税を再計算するようになった。
• マーケットの親子関係が導入された。
• Customer Account APIから lastIncompleteCheckout がなくなった。
• Eventsが一般提供になり、従来のウェブフックと並んだ。
• 購入者が依頼する注文編集が導入された。

同じ確認作業で、私たち自身が公開していた記述を9件訂正しました。ずれていくのはAPIだけではなく、保守する側の理解も同じです。再確認の記録には両方を残しています。

バージョンアップは設定の書き換えではなく、監査です。 API 2026-04から2026-07への移行では40ファイルが変わりました。ライブラリのバージョン、24個すべての拡張設定にあるAPIバージョン、そして再生成したスキーマと、それに対するすべてのAdmin API操作の検証です。Shopifyのchangelogでは、私たちの領域に破壊的変更はありませんでした。それでもスキーマの検証は、最初から無効だった操作を2つ見つけました。存在しないフィールドを要求していた下書き注文の照会（これで突合ジョブの1つが全行で失敗していました）と、誤った引数の形で呼ばれていたミューテーションです。2026-10については、削除・非推奨になったフィールドをコード全体で検索しても何も見つからないので、既知の破損はありません。それでもアップグレードは、その24個の設定とアプリ自身のバージョン固定に手を入れます。

暗黙のスコープ。 9月30日、私たちの支払い条件のチェックは、付与済みスコープに read_payment_terms と write_payment_terms の両方があることを要求していました。両方が付与されているとき、Shopifyは書き込みが読み取りを含むため、書き込みスコープだけを一覧に出します。そのため権限を付与していたストアが、付与していないものとして扱われ、支払い条件付きの見積の変換が、同日に修正版を出すまでブロックされました。テストのフィクスチャは、Shopifyが一度も送らない形式のスコープを使っていました。

変換時の検証エラー。 7月、draftOrderCalculate は形式の正しい会社の見積をすべて「Cannot send both customer and purchasing_entity」で拒否し、2つを排他にするまでそれが続きました。次のエラーは「An issue date is required with net payment terms」でした。ネットの支払い条件には支払いスケジュールが必要なので、変換画面でマーチャントに発行日を尋ねる必要がありました。

ライブラリのセキュリティ勧告。 8月、Shopifyのアプリライブラリに対するセキュリティ勧告（アプリプロキシのHMAC検証）により、修正済みのメジャーバージョンへのアップグレードが必要になりました。私たち自身のプロキシのチェックは影響を受けていませんでしたが、アップグレードにはより新しいNode.jsランタイムと、削除されたプロパティに対応するコード変更が必要でした。

ストアフロントの容量予算。 ストアフロントのスクリプトは、バンドルサイズのチェックで108 KBに抑えています。現在は105,050バイトで、Shopifyが目安とする圧縮後10 KBのおよそ3倍です。2026年半ばに機能を出していく中で、この予算は4週間で10回引き上げられました（それがストアに与える負担）。

スコープと権限。 2026年5月から7月にかけて、要求するスコープは何度も変わりました。

• 存在しないスコープが、デプロイ時の検証で拒否された。
• B2Bのスコープを必須にしたあと、任意に戻した。必須にすると、会社データを閲覧する権限のないスタッフがインストールできなくなったため。
• 制限付きのスタッフ用スコープが、Shopifyの承認なしでは拒否された。
• App Storeへの申請前に、使っていないスコープを2つ削除した。

カスタムアプリが省けるのは、このうちApp Storeに関わる半分だけです。残りは省けません。

予算はこの記録から導けます。最低でも四半期に1回のAPI監査、機能が新しいリソースに触れるたびのスコープと権限の見直し、そして初日からの突合ジョブです。日付のある機能は、Shopify B2Bの技術的負債で1つのカレンダーにまとめています。

コストを決める要因

私たちはコストの金額を公表しません。示せる金額の裏付けになるデータがないからです。ただし要因は数えられ、どれも立ち上げ時の作業ではなく、継続的な義務です。

• 機能の面。 拡張の種類ごと ― ストアフロント、顧客アカウント、管理画面、Flow、チェックアウト ― に、固有の上限とアップグレードの経路があります。
• Plusへの依存。 Functions、カスタムアプリでのFlow拡張、チェックアウトのステップの拡張は、Plusのストアにしかありません。
• ストアと組織。 無関係なストアごとに1つのアプリレコードが要ります。配布方法はあとから変えられません。
• 購入者ポータル。 顧客アカウント拡張と、自分でホストする認証付きのバックエンドです。
• コンプライアンスとデータ。 削除のハンドラーと、すべてのテーブルにわたる保護対象データの保護措置です。
• 連携。 外部システムが1つ増えるごとに、同期、突合、失敗パターンが1つずつ増えます。
• カレンダー。 APIのリリースは年4回で、各バージョンのサポートは最低12か月です。その後は、最も古いサポート対象のバージョンへ警告なしに繰り上げられます。
• 運用。 ホスティング、監視、そしてShopifyが数秒以内の応答を期待するエンドポイントのための待機担当者です。

開発・購入・ハイブリッドのワークシート

表をコピーし、上の一覧の構成要素ごとに1行を作って、クライアントと一緒に埋めてください。

構成要素	開発 / 購入 / ハイブリッド	担当者	Shopifyの機能	継続的な義務	Plusの制限	壊れたときに呼び出される人
依頼の受付			テーマアプリ拡張、アプリプロキシ	テーマとの互換性、スクリプトの重さ	なし
下書き注文への変換			Admin API	冪等性、ずれ、四半期ごとのAPI監査	なし
チェックアウトのルール（たとえば発注書番号の必須化）			Functions	Function APIのバージョン	あり（カスタムアプリの場合）
承認と監査			自前のデータベース、スタッフ用スコープ	強制、スコープの承認	スタッフ用スコープ：PlusまたはAdvanced
…

そのうえで、7つの問いに答えてください。

1. 独自なのはワークフロー全体か、構成要素1つか。 1つならハイブリッドです。
2. ストアが続く限り、四半期ごとのAPI監査に誰が費用を出すか。
3. ストアはPlusか。 設計にFunctions、Flow拡張、チェックアウトのステップの拡張が必要か。
4. ストアはいくつで、組織はいくつか。 カスタム配布は1つのPlus組織までで、この選択は変えられません。
5. 購入者は顧客アカウントの中で操作する必要があるか。 それには拡張と、自分でホストするバックエンドが要ります。
6. コンプライアンス ― 削除のウェブフックと保護対象データの扱い ― は誰が持つか。
7. 出口はどうなるか。 エージェンシーとの関係が終わったら、コード、データ、認証情報は誰が持つか。カスタムアプリのトークンは、ひとりでには失効しないことも忘れずに。

ハイブリッドという選択肢

標準のワークフローにはアプリを買い、独自の部分だけを開発します。基幹システムとの同期、ヘッドレスの受付、出力を人が適用する価格計算サービスなどです。条件は、独自の部分が必要とするイベントとエンドポイントをアプリが公開していることです。ですから範囲を決める前に、そのAPIに何ができないかを確認してください。

例として、QuotWayのREST APIと署名付きウェブフックを正確に書いておきます。Enterpriseプランで利用でき、14日間の無料トライアル中も使えます。APIでできるのは、明細、合計、イベントを含む見積の読み取り、見積依頼の作成、メッセージの投稿、人がすでに価格を付けた提案の送信、書類の一覧取得、分析データの読み取りです。価格の設定や変更、明細の編集、購入者に代わっての承諾や辞退、見積から下書き注文への変換はできません。また、ウェブフックのペイロードに購入者の個人データは含まれません。QuotWay APIで作れるものでは6つの連携を紹介しています。評価チェックリストは、どのベンダーのAPIにも使える確認項目です。プランは料金ページに、API自体の説明はAPIとウェブフックのページにあります。

よくある質問

Shopifyのカスタムアプリとは何ですか？

1つのストア、または1つのShopify Plus組織のストア向けに作るアプリで、Dev Dashboardで作成し、自分で生成したリンクからインストールします。App Storeへの掲載もアプリ審査もありません。2026年1月1日以降、Shopifyの管理画面では作成できなくなりました。

管理画面で作れなくなった今、カスタムアプリはどう作成しますか？

Dev Dashboardでアプリを作成し（UIや拡張があるならShopify CLIを使います）、カスタム配布を選んで、ストア用のインストールリンクを生成します。2026年より前に管理画面で作成したアプリは、引き続き動作します。

カスタムアプリと公開アプリの違いは何ですか？

カスタムアプリは1つのストアか1つのPlus組織にインストールし、審査を経ず、Billing APIは使えず、FunctionsとFlow拡張はPlusでのみ使えます。公開アプリはApp Storeからどのストアにもインストールでき、審査を経て、Shopifyを通じて課金でき、Functionsをどのプランでも使えます。この選択はあとから変えられません。

カスタムアプリでShopify Functionsは使えますか？

使えますが、Shopify Plusのストアに限られます。Flow拡張も同じです。情報、配送、支払いのステップのチェックアウトUI拡張は、すべてのアプリについてShopify Plusでのみ利用可能です。

カスタムアプリにアプリ審査やBuilt for Shopifyは関係しますか？

カスタム配布にアプリ審査はありません。Built for Shopifyは、インストール数とレビューに関する前提条件があるApp Storeのプログラムなので、カスタムアプリには当てはまりません。

カスタムアプリはどうやってアクセストークンを得ますか？

埋め込みアプリはトークン交換、埋め込みでないアプリは認可コードグラントを使います。自社の組織のストアだけを扱うサーバー側の連携は、24時間有効なトークンを発行するクライアントクレデンシャルグラントを使えます。カスタムアプリは2027年の期限付きトークンの義務化の対象外ですが、期限付きを選ぶほうが安全です。

カスタムアプリは誰がホストしますか？

あなたです。Shopifyがホストするのは拡張のコード（テーマブロックとUI拡張）だけです。バックエンド、そのデータベース、Shopifyが呼び出すすべてのエンドポイントは、自分で選んで保守するホスティングで動かします。

Shopifyのカスタム見積（RFQ）アプリの開発費用はいくらですか？

金額は公表していません。コストは、作る機能の面、Plusへの依存、ストアの数、購入者ポータル、コンプライアンス、連携、ホスティングで決まります。そして、ストアが続く限り四半期ごとに行うAPI監査でも決まります。

アプリを買って、独自の部分だけを開発できますか？

できます。ただし、独自の部分が必要とするイベントとエンドポイントをアプリが公開している場合に限ります。まずそのAPIにできないことを確認してください。たとえばQuotWayのAPIはEnterpriseプラン専用で、価格の設定、明細の編集、購入者に代わっての承諾、変換はできません。

出典

Shopifyのページ。すべて2026年10月7日にAPIバージョン2026-10で閲覧：

• カスタムアプリ ―1つのストア専用に作られるアプリ。レベル2の個人データとプラン
• アプリの配布についてと配布方法を選ぶ ―カスタムと公開の違い、1つのPlus組織、変更できない選択、審査なし、Billing APIなし、管理画面で作成したアプリと拡張、「特定のマーチャント向けに作られるアプリの多く」というShopifyの文
• Changelog：2026年1月1日以降、従来のカスタムアプリは作成できない ―2025年10月30日掲載。既存のアプリは引き続き動作
• Shopify Functions ―Functionsを含むカスタムアプリはPlusでのみ
• アプリ向けShopify Flow ―カスタムアプリのFlow拡張はPlusでのみ
• チェックアウトUI拡張 ―情報、配送、支払いのステップはPlus
• 顧客アカウントUI拡張 ―サイズ上限。「Shopifyがホストするのは拡張のコードだけ」
• 認証と認可、クライアントクレデンシャルグラント、オフラインアクセストークン ―トークン交換、認可コード、24時間のクライアントクレデンシャル、カスタムアプリに対する期限付きトークンの適用除外
• アクセススコープ ―書き込みは読み取りを含む。read_all_orders。承認制のスコープ
• 保護対象顧客データとプライバシー法への準拠 ―カスタムアプリでの利用可否。コンプライアンスウェブフック
• APIのバージョン管理と2026-10のリリースノート ―四半期ごとのリリース、サポート期間、繰り上げ、2026-10での変更
• アプリをデプロイする ―ホスティング事業者。1つのコードベースに複数のアプリレコード
• Built for Shopifyの要件 ―インストール数とレビューに関する前提条件があるApp Storeのプログラム

私たち自身の記録：Shopify B2Bリファレンスの2026-10の再確認と、2026年10月7日に読んだQuotWayアプリのリポジトリの履歴。ここでは内部名を使わずに記述しています。