Shopifyアプリ開発は本当に必要か？実装方式と判断基準の設計ガイド

「shopify アプリ 開発」で調べると、Shopify CLI、React、OAuth、Admin API、Webhook、Theme App Extension、公開アプリ審査などの手順が出てきます。手順は重要ですが、実務で先に必要なのは「どう作るか」ではなく、「どこまで作るべきか」です。

受注タグ付けだけならShopify Flowで十分かもしれません。商品ページに動的な表示を足したいだけならTheme App Extensionで済むかもしれません。WMS、会計、CRM、Slack通知をまたぐならAdmin API、Webhook、外部DBが必要です。複数マーチャントに売るなら、billing、審査、サポート、セキュリティレビューまで事業として見ます。

Shopify公式ヘルプのアプリの概要では、アプリはShopify管理画面を強化したり新機能を追加したりするものとして説明され、public appとcustom appに分けられています。パートナー向け公式ページのShopify API を使用したアプリの構築と収益化でも、カスタムアプリ、公開アプリ、CLI、Dev Dashboard、APIスコープ、開発ストア、監視ログ、審査、課金が整理されています。

一方、上位記事として参考になるドコドアのShopifyアプリ開発記事やKIYONOのShopifyアプリ開発手順記事は、開発の流れ、公開/カスタムの違い、CLI、OAuth、Webhook、Theme App Extension、デプロイを把握するには便利です。ただし、「作らない方がよいケース」「Flowや既存アプリで止める境界」「公開後の保守費」は、自社要件に合わせて設計する必要があります。

この記事では、Shopifyアプリ開発のチュートリアルではなく、開発に進む前の判断軸を整理します。2026年7月3日時点の公式情報を前提にしていますが、Shopifyの仕様、審査、billing、スコープ、テンプレートは変わるため、実装時は必ず公式ドキュメントを再確認してください。

Shopifyアプリ開発の最初の判断は「何を作るか」ではなく、「標準機能・既存アプリ・Flow・API連携で足りない理由を説明できるか」です。

まず作らない判断：標準機能・既存アプリ・Flowで足りる条件

Shopifyアプリは作れます。しかし、作った瞬間から保守対象になります。OAuth、APIスコープ、Webhook、DB、個人情報、監視、障害対応、Shopifyの仕様変更、サポート窓口が発生します。

そのため、最初に「作らない判断」を表にします。

要件	まず見るもの	アプリ開発に進む境界
商品ページに注意文、スペック、配送情報を出したい	メタフィールド、テーマ設定、Liquid、既存テーマ機能	外部DBの値や顧客状態に応じて表示を変える必要がある
受注にタグを付けたい	Shopify Flow、標準タグ運用	条件が複雑で、外部システムの状態や独自DBを参照する
高額注文や不正疑いを通知したい	Shopify Flow、Slack/メール通知	通知だけでなく、保留台帳、承認履歴、再実行画面が必要
在庫切れ・低在庫を通知したい	Shopify Flow、在庫アプリ	複数倉庫、モール、WMS、予約在庫をまたいで正本管理する
会計ソフトへ売上を渡したい	会計連携アプリ、iPaaS、CSV運用	返金、手数料、税区分、入金照合、補助科目を独自ルールで処理する
レビュー、ポイント、サブスク、予約販売を入れたい	既存Shopifyアプリ	既存アプリのデータ構造や画面では業務ルールに合わない
商品ページに診断、比較、在庫表示などを追加したい	Theme App Extension、既存アプリ	表示だけでなく、管理画面、設定DB、外部API、サポートが必要
複数ストアに同じ機能を提供したい	公開アプリとして事業検討	審査、billing、ヘルプ、オンボーディング、サポートの採算が合う

公式のAbout Flowでは、Flowはtriggerやactionなどのタスクを通じて業務プロセスを自動化する仕組みとして説明されています。既存記事のShopify FlowでEC運用を自動化する設計ガイドでも、通知、タグ付け、保留、HTTP request、Run historyまで含めた運用設計を整理しています。

アプリ開発に進むのは、Shopify外に正本がある、承認や補正を履歴として残したい、失敗した注文を再実行したい、既存アプリのデータ構造では業務を表せない、複数ストアで同じルールを使いたい、といった条件が重なったときです。「開発できるから作る」ではなく、「作らない選択肢では運用が壊れるから作る」という順番にします。

開発方式の比較：カスタムアプリ・公開アプリ・Theme App Extension・API自動化

Shopifyアプリ開発では、方式の名前が混ざりやすいです。カスタムアプリ、公開アプリ、Theme App Extension、Flow連携、APIだけの連携は、同じものではありません。

アプリ配信に関する公式ドキュメントでは、配信方法は目的と対象マーチャントによって選び、選択後に変更できないと説明されています。custom distributionは基本的に単一ストア向け、または同一Plus組織などの条件付き範囲で使い、public distributionは複数Shopifyストアへ提供する公開アプリです。細かい条件は変わり得るため、実装前に公式を確認してください。

方式	向いているケース	主な実装要素	注意点
標準機能・設定	画面設定、メタフィールド、決済、配送、通知で足りる	Shopify管理画面、テーマ設定	カスタム保守が少ない一方、独自ルールには限界がある
既存アプリ	レビュー、ポイント、予約、サブスク、配送、会計など定番機能	App Storeアプリ、設定、課金	データの持ち方、エクスポート、サポート範囲を確認する
Shopify Flow	タグ付け、通知、保留、軽いHTTP request	trigger、condition、action	複雑なDB状態管理や厳密な再実行には向かない
API連携	WMS、CRM、会計、通知基盤との同期	Admin API、Webhook、外部DB、キュー	認証、スコープ、重複排除、監視、手動復旧が必要
Theme App Extension	商品ページやテーマに動的要素を追加	app block、app embed、metafield	Online Store 2.0テーマ、表示速度、テーマ編集手順を確認する
カスタムアプリ	1社の業務に合わせた管理画面・連携を作る	OAuth、Admin UI、DB、Webhook、権限	単一ストア前提なら販売課金より保守契約で考える
公開アプリ	複数マーチャントに販売するプロダクト	OAuth、billing、App Store listing、審査、サポート	機能開発より、審査、サポート、解約防止、仕様変更対応が重い

App extensions公式ドキュメントでは、app extensionはアプリそのものではなく、アプリの機能をShopifyの特定UIに出す仕組みだと説明されています。つまり、Theme App Extensionを作る場合でも、必要に応じてアプリ本体、設定画面、DB、OAuth、デプロイ、監視は別に考えます。

Theme App Extensionの公式チュートリアルでは、merchantがLiquidやコードに触れず、テーマに動的要素を追加できる仕組みとして説明されています。Online Store 2.0テーマ、JSON template、app block、app embed、メタフィールドなどの前提を確認してから設計します。

要件定義で決めるデータモデル・画面・権限

アプリ開発の要件定義では、画面一覧から入るより、データ、画面、権限、運用を同時に決めます。

設計項目	決めること	例
データモデル	Shopify ID、外部ID、状態、履歴、設定をどう持つか	order_id、external_order_id、sync_status、last_error
Shopify側の正本	どの項目をShopifyで更新し、どの項目を外部から戻すか	商品説明はShopify、SKUと在庫はWMS
アプリ側DB	Shopifyにない業務状態を保存するか	承認状態、連携履歴、再実行キュー、担当者メモ
管理画面	誰が何を見て、何を操作するか	未連携注文一覧、エラー再実行、設定、ログ
スタッフ権限	EC担当、CS、倉庫、管理者の操作範囲	設定変更は管理者、再実行は運用担当
顧客データ	氏名、メール、住所、電話、注文履歴を扱うか	必要最小限にし、保持期間と削除手順を決める
監査ログ	変更者、変更前後、再実行履歴を残すか	誰が返金連携を再実行したか
サポート導線	障害時に誰へ、何を添えて問い合わせるか	注文ID、Webhook ID、エラーコード、発生時刻

特にアプリ側DBは慎重に決めます。Shopifyから取得できるデータを何でも保存すると、個人情報、同期ズレ、削除要求、セキュリティレビューの負荷が増えます。一方で、連携状態や外部IDを持たないと、Webhook再送時に二重登録を防げません。

たとえば注文連携アプリなら、DBには次のような情報を持つことが多いです。個人情報を増やすのではなく、再実行と突合に必要なキーを中心にします。

テーブル	主な項目	目的
shops	shop domain、access token参照、plan、installed_at	インストール店舗と設定を管理する
order_syncs	shopify_order_id、external_id、sync_status、last_error	外部システムとの対応と再実行を管理する
webhook_deliveries	webhook_id、topic、received_at、payload_hash、status	Webhookの受信証跡と重複排除を行う
audit_logs	actor、action、target_id、before/after	設定変更や手動再実行の責任を残す

既存記事のShopify API連携の設計方法では、受注、在庫、顧客、会計の正本と同期イベントを整理しています。アプリ開発でも、DB設計はその延長です。

Shopify CLIと開発環境の基本

Shopifyアプリを実際に作る段階では、公式のScaffold an appを確認します。2026年7月3日時点では、Shopify CLIでReact Router templateを使ってアプリを作る流れが、多くのアプリの推奨pathとして説明されています。

公式チュートリアルでは、shopify app initで新規アプリを作り、shopify app devで開発ストアへ接続し、ローカル開発サーバーとトンネルを使ってインストール・プレビューします。

shopify app init
shopify app dev

ただし、これは「アプリを作ることが決まった後」の話です。さらに、公式ページでは、単純な既存システム接続でAPI credentialsだけが必要な場合はDev Dashboardでアプリを作る選択肢にも触れられています。管理画面UIが不要なAPI連携なら、フルのReact Routerアプリを先に立てる必要がない場合があります。

開発環境で確認すること	判断
管理画面UIが必要か	設定画面、ログ画面、再実行画面が必要ならアプリUIを作る
APIだけでよいか	単一ストアのサーバー連携だけならDev Dashboard中心も検討する
開発ストアで再現できるか	決済、配送、在庫、顧客データ、テーマをテスト用に用意する
stagingとproductionを分けるか	本番用アプリ、検証用アプリ、環境変数を分ける
app extensionを含むか	CLIのextension生成、UID、deploy/release手順を確認する

Shopify公式のデプロイ概要では、React Router templateが認証、セッション管理、Webhook handling、環境設定などの主要要件を自動で扱うと説明されています。一方で、ホスティング、環境変数、DB、秘密情報、ログ、バックアップ、CI/CDは開発側の責任です。

OAuth・スコープ・Admin API/GraphQL・Webhook設計

アプリ開発で最も軽視してはいけないのは、認証と権限です。

API access scopes公式ドキュメントでは、すべてのアプリは承認プロセスで特定のストアデータへのアクセスを要求すると説明されています。OAuth画面でmerchantに見える権限は、信頼と審査に直結します。

項目	設計で決めること	よくある失敗
OAuth	どのタイミングで承認し、再インストール時にどう処理するか	古いtokenを使い続け、権限変更後に失敗する
スコープ	read_orders、write_productsなど必要最小限にする	将来使うかも、で広い権限を要求する
protected customer data	氏名、住所、メール、電話、注文情報を扱う理由を明確にする	顧客データを過剰取得し、審査や削除対応が重くなる
Admin API/GraphQL	商品、注文、顧客、在庫、メタフィールドの取得・更新範囲を決める	画面に必要な項目と同期に必要な項目が混ざる
Webhook	topic、重複排除、HMAC検証、キュー、再実行を決める	受信した瞬間に外部APIまで同期し、タイムアウトや二重登録を起こす
API version	利用バージョン、更新確認担当、テスト周期を決める	半年後に非推奨変更で突然壊れる

顧客情報を扱う場合は、Shopify公式のprotected customer dataも確認します。氏名、住所、メール、電話のように個人を直接識別する項目は、取得理由、最小化、保管、削除、レビューの対象になります。公開アプリでは特に、データ保護要件を実装前から設計に含めます。

Webhookは、アプリの運用安定性を左右します。Webhook公式ドキュメントでは、特定イベントをnear-real-timeで受け取り、Shopifyデータと同期したり、イベント後の処理を動かしたり、継続的なpollingの代替にしたりできると説明されています。

ただし、Webhookは「注文が来たら外部APIをすぐ呼ぶ」だけでは不十分です。

Webhook設計	必要な判断
topic	orders/create、orders/updated、products/updateなどを業務イベントから選ぶ
HMAC検証	Shopifyから来たpayloadかをraw bodyで検証する
重複排除	Webhook ID、resource ID、外部IDで二重処理を防ぐ
キュー	Shopifyへの応答と外部システム同期を分ける
再実行	一時障害、SKU未登録、会計項目不足を分類する
reconciliation	Webhook欠損や長時間障害に備え、Admin APIで差分確認する

Webhookの受信基盤は、Shopify Webhookの実装設計でも詳しく整理しています。アプリ開発では、初回機能の中にログと再実行を含めるべきです。

Shopifyアプリの品質は、初回インストール時に動くかではなく、権限変更、Webhook再送、API制限、顧客データ削除、仕様変更に耐えられるかで決まります。

公開アプリのbilling・審査・サポート要件

自社ストア専用のカスタムアプリと、複数merchant向けの公開アプリは、まったく別の事業です。

About app distributionでは、public distributionは複数Shopifyストアにインストール可能で、承認が必要です。一方、custom distributionは主に特定ストアや同一Plus組織など限られた範囲で使われ、Billing APIでmerchantへ課金できない制約があります。配信方法は選択後に変更できないため、早い段階で決める必要があります。

項目	カスタムアプリ	公開アプリ
対象	1社・1ストア、または限定された組織内ストア	複数merchant
価値	個別業務に合わせた実装	汎用課題をプロダクトとして解く
課金	開発費・保守費・運用支援で考えやすい	App Store billing、プラン、従量課金、解約対応を設計
審査	App Store審査は基本不要なことが多いが機能別要件は確認	App Store審査、listing、privacy、support、performanceが必要
サポート	契約先の担当者と運用手順を決める	不特定多数の問い合わせ、オンボーディング、障害報告が必要
仕様変更	1社の運用に合わせて調整	既存merchantを壊さない移行と互換性が必要

公開アプリでは、課金も設計対象です。Shopify公式のAbout billing for your appでは、Shopify App PricingがApp Store公開アプリのデフォルトかつ推奨の課金方式として説明されています。無料、月額、年額、従量課金などのプランだけでなく、アップグレード、ダウングレード、解約、請求イベント、サポート説明まで考えます。

審査・listingも軽くありません。App Store best practicesでは、OAuth、権限、setup、機能品質、billing、performance、listing、security、privacy、supportなどの観点が整理されています。公開アプリを作るなら、コードより先に次の表を埋めます。

公開アプリ要件	事前に決めること
対象merchant	どの業種・規模・Shopifyプラン向けか
初回設定	インストール後、何分で価値が出るか
課金	free plan、trial、月額、従量、外部課金の有無
サポート	問い合わせ窓口、対応時間、障害時の通知方法
データ保護	取得する顧客データ、削除要求、保持期間、監査ログ
解約時処理	token無効化、Webhook解除、保持データ削除、merchantへの説明

公開アプリは「カスタムアプリを少し汎用化したもの」ではありません。販売、審査、運用、サポート、継続課金まで含むプロダクトです。

デプロイ・監視・障害対応・セキュリティレビュー

Shopifyアプリは、Shopify上だけで動いているわけではありません。アプリサーバー、DB、キュー、外部API、ログ基盤、通知、ホスティング環境が必要になります。

領域	最低限決めること	事故例
デプロイ	production/staging、環境変数、rollback、app version	検証用tokenで本番へ接続する
DB	バックアップ、暗号化、マイグレーション、個人情報の保存範囲	schema変更でWebhook処理が落ちる
監視	HTTP 5xx、Webhook失敗、キュー滞留、API rate limit、DB容量	注文連携が夜間に止まって朝まで気づかない
セキュリティ	secret管理、OAuth state、CSRF、HMAC、権限、監査ログ	token漏えい、偽Webhook、過剰権限
個人情報	取得最小化、保持期間、削除要求、ログマスキング	エラーログに住所や電話番号が残る
保守	API version、Shopify changelog、依存ライブラリ更新	四半期更新や脆弱性対応が後回しになる

監視は後付けではなく、初期リリース範囲に入れます。

監視項目	アラート条件	初動
アプリHTTPエラー	5xx増加、OAuth callback失敗	直近デプロイ、環境変数、Shopify statusを確認
Webhook受信数	急に0、急増、HMAC失敗増加	subscription、topic、secret、Shopify側障害を確認
キュー滞留	待機job増加、処理遅延	外部API停止、rate limit、worker停止を確認
外部同期失敗	WMS、会計、CRMへの失敗が一定数超過	エラー分類し、再実行可能か人の補正が必要か分ける
protected data / billing	削除要求未処理、plan不整合	保持データとShopify側の課金状態を突合する

セキュリティレビューでは、OAuthとWebhookだけでなく、スタッフ権限、DBアクセス、ログ閲覧権限、サポート担当者が見られる顧客情報まで含めます。アプリ管理画面に「便利だから全注文を検索できる」機能を入れるなら、その検索画面の権限、監査ログ、マスキング、削除手順も必要です。

判断チェックリスト

最後に、Shopifyアプリ開発に進む前のチェックリストを置きます。

チェック項目	OKなら進める	NGなら戻る先
標準機能で足りない理由を説明できる	何が標準機能では無理か明確	メタフィールド、テーマ、設定を再確認
既存アプリで足りない理由を説明できる	データ、権限、運用、保守で不足が明確	App Store、料金、エクスポート可否を再調査
Flowで足りない理由を説明できる	再実行、DB、複雑な状態管理が必要	Flowのtrigger/actionで再設計
配信方法を後から変えない前提で決めた	custom/publicの制約を理解	公式distributionを再確認
データ正本が決まっている	商品、注文、在庫、顧客、会計の責任が明確	API連携設計へ戻る
スコープを最小化できている	必要なread/writeと顧客データが説明できる	要件を削り、権限を再整理
Webhookの復旧設計がある	重複排除、キュー、DLQ、再同期がある	Webhook基盤を先に設計
公開アプリの採算が見える	billing、審査、サポート、マーケまで含めて成立	カスタムアプリや受託実装に戻る
保守費が見積もられている	Shopify更新、障害対応、依存更新の担当がいる	初期開発費だけの見積もりをやめる

このチェックを通過できないなら、まだアプリ開発に入らない方がよいです。開発を遅らせるのではなく、後から作り直すコストを減らすためです。

まとめ

Shopifyアプリ開発は、Shopify CLIで雛形を作るところから始めると、判断を誤りやすくなります。

最初に見るべき順番は、標準機能、既存アプリ、Shopify Flow、Admin API/GraphQL連携、Theme App Extension、カスタムアプリ、公開アプリです。

標準機能や既存アプリで足りるなら、無理に作らない方がよいです。Flowで通知やタグ付けができるなら、まず運用ルールを整えるべきです。API連携が必要なら、データの正本、OAuth、スコープ、Webhook、DB、個人情報、監視、再実行まで設計します。公開アプリに進むなら、billing、App Store審査、listing、サポート、解約、仕様変更対応を事業として見ます。

Shopifyアプリ開発の成果物は、コードだけではありません。どの方式を選び、どこを作らず、どのデータを持ち、どの権限を要求し、失敗時に誰が直せるかまで決めた設計そのものです。

Bitlightでは、Shopifyの標準設定、既存アプリ、Flow、API連携、Webhook、Theme App Extension、カスタムアプリ、公開アプリの境界を、業務要件から整理します。受注、在庫、顧客、会計、通知、テーマ拡張、サポート運用まで含めて、作るべき範囲と作らない範囲を一緒に設計できます。