Shopify×Stripe×Notion 売上/返金/CB 一元化運用ガイド 2026：iPaaS比較・DB設計・自動連携

EC事業の規模が拡大するにつれ、現場を悩ませるのが「情報の断片化」です。Shopifyで注文を確認し、Stripeで決済詳細を追い、さらにチャージバック（支払い異議申し立て）が発生すればメールとダッシュボードを往復する――。こうした非効率な運用は、オペレーションミスを誘発するだけでなく、正確な純利益の把握を困難にします。

本記事では、Shopify、Stripe、NotionをAPIで連結し、売上・返金・チャージバックの全プロセスを「案件ログ」としてNotion上に一元化する、実務者向けの高度な運用アーキテクチャを詳説します。

Shopify×Stripe×Notion連携の技術的優位性と構築メリット

多くの企業が、各ツールのダッシュボードを個別に確認する運用を行っています。しかし、Shopify上の「売上」とStripe上の「入金額」には、決済手数料（Stripe Fee）や通貨換算の差異が含まれており、これらを突合する作業には膨大な工数がかかります。

情報散逸による「隠れコスト」の正体

情報が分散している状態では、以下の3つの隠れコストが発生します。

• 検索コスト：特定の顧客からの問い合わせに対し、Shopifyの注文番号からStripeの決済IDを探し出し、返金ステータスを確認するまでの時間。
• 判断コスト：チャージバックが発生した際、異議申し立てに必要な「配送証明」や「顧客とのやり取り」がどこにあるか分からず、対応が遅れるリスク。
• 集計コスト：月次の営業利益を算出する際、決済手数料を手動で計算・差し引く作業。

これらの課題を解決するために、Notionを「すべての業務判断の起点（Single Source of Truth）」として再定義します。Notionのデータベース機能を活用し、注文ごとに「対応ログ」を自動生成することで、管理画面の往復をゼロにします。

【関連記事】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』

【比較】連携を実現するためのiPaaS（自動化ツール）選定

Shopify、Stripe、NotionをAPI連携させるには、プログラムを記述せずに各SaaSを繋ぐiPaaS（integration Platform as a Service）の活用が現実的です。代表的な2つのツールのスペックを比較します。

比較項目	Make (旧Integromat)	Zapier
特徴	高度な分岐、ループ、データ加工が得意。エンジニア向け。	UIが直感的で、初心者でも構築が容易。
Shopify API対応	GraphQL / REST 双方に対応。詳細な注文データ取得が可能。	主要なトリガーのみ対応。詳細な絞り込みは限定的。
料金プラン	$9/月〜（Coreプラン） ※実行数（Ops）に応じた従量課金	$19.99/月〜（Starterプラン） ※ステップ数に制限あり
API制限対策	スリープ処理やエラーハンドリングを詳細に設定可能。	自動再試行機能があるが、細かい制御は困難。
公式事例	Make導入事例（公式）	Zapier導入事例（公式）

実務においては、Shopifyの複雑な注文メタデータをNotionのプロパティに変換するため、データ加工の自由度が高いMakeの採用を推奨します。

Notionデータベースの設計：売上・返金・チャージバックを統合する

Notionに構築するデータベースは、以下の3つの役割を持たせます。

1. 注文データベース（Master Orders）

Shopifyの「注文作成（Order Created）」をトリガーに、以下の情報を自動保存します。

• Shopify注文ID：注文詳細ページへのURLリンクを数式で生成（例："https://your-store.myshopify.com/admin/orders/" + prop("Order ID")）
• 決済ステータス：支払済、保留、一部返金、返金済、チャージバック発生。
• 純売上（Net Revenue）：注文金額からStripe決済手数料を自動で差し引く関数を適用。

2. 返金・チャージバック管理（Dispute Log）

StripeのWebhook（charge.disputed.created）を検知し、注文データベースの該当レコードを「要対応」フラグに変更、または新しい「異議申し立て」ページを作成します。

Stripe公式情報：チャージバック（異議申し立て）の管理には、Disputeオブジェクトを使用します。異議申し立ての勝率は、提出する証拠の質とスピードに依存します。

【公式URL】Stripe Disputes API

ステップバイステップ：自動連携システムの構築手順

具体的な構築ステップを解説します。ここではMakeを使用した例を挙げます。

ステップ1：Stripe Webhookの設定

1. Stripeダッシュボードの「開発者」→「Webhook」から、MakeのWebhook URLを登録します。
2. 送信するイベントに charge.refunded（返金）および charge.disputed.created（チャージバック発生）を選択します。

ステップ2：Shopify Order IDの紐付け

Stripeの決済データには、Shopifyの注文番号（例：#1001）が metadata 内に格納されています。Makeの「Search Object」モジュールを使用し、このメタデータをキーにしてNotionの既存レコードを検索・特定します。

ステップ3：Notionプロパティの更新

特定したレコードの「ステータス」を更新します。チャージバックの場合、Notionの担当者にメンションを飛ばす通知設定を組み合わせることで、対応漏れを防ぎます。

【関連記事】Shopifyの売上をfreeeに直接連携してはいけない。決済手数料の分解と「月末在庫」を正しく処理するアーキテクチャ

ビジネス規模別 × Shopify×Stripe×Notion連携の設計パターン × データ整合性管理の重点ポイント 早見表

前のセクションでShopify×Stripe×Notionの自動連携システムの構築手順を説明しましたが、「個人・スモールEC」「成長期のD2Cブランド」「多SKU・高頻度取引のECサイト」ではZapier/Make等のiPaaSを使った連携設計の粒度とNotionデータベース構造の最適解が異なります。売上データ・返金・チャージバックを三者のシステムで矛盾なく管理するには規模に応じた設計判断が必要です。規模別の設計パターンとデータ整合性管理の核心をまとめました。

ビジネス規模・取引特性	Shopify×Stripe×Notion連携の設計パターン	Notionデータベースの推奨構造	データ整合性管理の重点ポイント
個人・スモールEC （月間注文数50件以下・SKU数50以下）	Zapierの無料〜スタータープランで「Shopify注文確定→Notionに注文ページ作成→Stripeの決済IDをNotionに紐づけ」のシンプルな一方向フローが最小構成として十分。ZapのトリガーはShopifyの「New Order」のみに絞り、Stripeへの重複確認は手動で週次照合するセミオート方式がZapierのタスク数上限内に収まる設計。返金・キャンセル処理はShopifyの管理画面→Stripeの自動返金→Notionの手動更新という三段階の運用フローで月間数件の返金に対応できる	「注文ID（タイトル型）」「顧客名・メール」「注文金額（Number型）」「決済ステータス（セレクト型：決済完了/返金/チャージバック/未払い）」「ShopifyオーダーURL（URL型）」「StripeペイメントID（Text型）」「注文日（Date型）」「配送ステータス（セレクト型）」の8プロパティが個人ECに最適な軽量構成。顧客別Relationを最初から作ると維持コストが高いため、注文数50件を超えるまでは顧客情報はメールアドレスのみで紐づける設計にする	個人ECでのデータ整合性管理の最重要事項は「Shopifyの注文ID・StripeのPayment IntentIDをNotionの両方のフィールドに記録すること」。後で不一致を調べる際にどちらのIDでも照合できる設計が月次の売上照合作業を大幅に短縮する。Zapierのタスク実行ログを月次で確認して「Zapエラーで同期されなかった注文」がないかをチェックする習慣をつける。個人ECでは月次の「Shopify売上合計 vs Stripe入金合計 vs Notionの記録合計」の3者照合を習慣化することでデータ不整合の早期発見が可能
成長期D2Cブランド （月間注文数100〜500件・定期購入あり）	MakeのプロフェッショナルプランまたはZapierのTeamプランで双方向同期（Shopify←→Notion、Stripe←→Notion）を設計して返金・チャージバックの発生時もNotionが自動更新される仕組みを作る。定期購入（サブスクリプション）はStripeのRecurring PaymentとShopifyのSubscriptions連携の両方からNotionに同期して「定期注文の有効・停止・更新失敗」を一元管理する設計が最重要。MakeのWebhookでStripeのイベント（payment_intent.succeeded / payment_intent.payment_failed / refund.created）をリアルタイムでNotionに反映させる設計が成長期以上で必要になる	「注文ID」「顧客ID（Relation型で顧客マスターと紐づけ）」「注文種別（セレクト型：通常/定期/ギフト）」「決済金額」「決済ステータス」「返金額（Number型）」「チャージバック額（Number型）」「定期購入ID（定期注文のみ・Stripe Subscription ID）」「次回請求日（定期注文のみ）」の二層構造。顧客マスターデータベースを別テーブルで管理してRelationで注文履歴と紐づけることで、顧客ごとの購買頻度・LTV・チャーンリスクをNotionのフィルター機能で分析できる設計にする	成長期ECでのデータ整合性管理の最重要課題は「定期購入の更新失敗（クレジットカード期限切れ等）をNotionでリアルタイム把握してすぐに顧客フォローできること」。Stripeの「payment_intent.payment_failed」イベントをMakeでキャッチしてNotionの定期注文ページのステータスを「更新失敗」に更新してSlackに通知する設計が解約防止の最重要フロー。月次の売上レコンサイルはNotionのデータベースビューでShopify売上・Stripe入金・返金合計を自動集計できるFormulaとRollup設計を整備してから自動化に進む
多SKU・高頻度取引EC （月間注文数500件以上・B2B卸売あり）	注文数500件超ではZapier/Makeのタスク上限コストが高騰するため、ShopifyとStripeのWebhookをGCF（Google Cloud Functions）またはAWS Lambdaでダイレクト受信してNotionのAPIに書き込むカスタム連携アーキテクチャへの移行を検討する段階。Notionの代わりにPostgreSQLやBigQueryをデータウェアハウスとして使いNotionは「経営ダッシュボード参照用」に特化させる設計分離が大規模ECでの実務的な判断になる。B2B卸売は注文単価が高いため「請求書発行（Stripe Invoicing）→入金確認→Notionのインボイス管理DB更新」の専用フローを別途設計する	大規模ECではNotionは「全データの管理場所」から「重要データのダッシュボード参照先」に役割を変える設計が現実的。Notionのデータベースには「今週の注文サマリー」「未払いのB2Bインボイス一覧」「チャージバック案件の対応状況」等の日次・週次で確認が必要なデータのみを集約して、詳細な全注文データはBigQueryやShopify Analyticsで管理する役割分担にする。このレベルになるとNotionはBIダッシュボードの補完ツールとして位置づけて最重要KPIのみを表示するシンプルな設計が運用効率を最大化する	大規模ECでのデータ整合性の最重要課題は「ShopifyのPaymentとStripeのPayment Intentのマッピングが複数の決済方法（クレジットカード/Shop Pay/コンビニ決済等）でずれるケース」。Shopifyが決済方法を切り替えた際にStripeのPayment IDが変わる仕様があるため、注文IDをPrimary Keyとして「Shopify注文ID→StripeのPayment Intent→Stripe Charge→Stripe Refund」の連鎖を追跡できる設計が財務照合の基盤になる。月次の財務クローズでは「Shopify管理画面の売上レポート」「Stripeのペイアウトサマリー」「Notionのサマリー」の3者照合を自動化するスクリプト設計が必要になる
国際EC・多通貨対応 （クロスボーダー・複数通貨・税制対応）	多通貨ECではStripeのMulti-Currency設定（決済通貨とペイアウト通貨の分離）とShopifyのMarkets機能（各国向けの価格・税設定）の連携設計を先に確定してからNotionのデータベース構造を設計する必要がある。Notionの注文データベースに「決済通貨（Text型）」「決済金額（現地通貨）」「日本円換算額（Formula型）」の3フィールドをセットにして、月次の円建て売上レポートをNotionのFormula機能で自動算出できる設計にする。Zapier/MakeでStripeのexchange_rateフィールドを取得してNotionに格納することで当日のレートでの円換算が自動化できる	国際ECのNotionデータベースに「決済国（セレクト型）」「決済通貨」「現地金額」「円換算金額」「税率（各国税制対応）」「VAT/GST番号（B2B取引の場合）」を追加して、国別・通貨別の売上集計をGroupByとFilterで自動化する設計にする。チャージバックリスクが高い国・通貨をセレクトの色分けで表示するビューを作成してリスク管理ダッシュボードとして使う。Stripeの「Radar（不正検知）」のフラグが立った注文をNotionに自動連携して人間がレビューするワークフロー設計が国際ECのリスク管理の基本設計	国際ECでのデータ整合性の最大の課題は「為替レートの違いによるShopify売上・Stripe入金・Notion記録の金額が一致しない問題」。ShopifyとStripeは異なるタイミング（注文時・決済時・ペイアウト時）の為替レートを使うためどちらの金額が「正しいか」を財務ポリシーとして事前に決めてNotionの管理基準にする必要がある。国際税務（各国の売上税・VAT還付等）の処理はStripeのTax機能とShopifyのTax設定を連携させてNotionには「税込/税抜の両方の金額」を記録する設計が税務申告作業を効率化する

この表でShopify×Stripe×Notion連携において最重要の設計原則が「現在の注文件数・ビジネスモデル・管理工数から『今に最適な連携設計』を選んで、規模拡大時にアップグレードしやすい設計を最初から意識すること」です。月間注文50件のEC事業者がエンタープライズ向けのWebhook直接受信アーキテクチャを最初から組む必要はありませんが、Notionのデータベース設計だけは「将来の拡張を見越したフィールド設計（顧客IDのRelation設計等）」を最初から組み込むことで、規模拡大後のデータ移行コストを大幅に削減できます。「今すぐ動くこと」と「将来も維持できること」の両方を意識した段階的な連携設計がShopify×Stripe×NotionのECバックオフィス自動化を成功させる実践的な指針です。

トラブルシューティング：よくあるエラーと解決策

実務運用で必ず直面する「落とし穴」とその回避策をまとめました。

1. APIのレート制限（Rate Limit）

セールの時期など、短時間に数千件の注文が発生すると、Shopify APIやNotion APIの制限に抵触します。

解決策：Makeの「Sleep」モジュールを挿入してリクエスト間隔を調整するか、注文を即時連携せず1時間ごとにバッチ処理で同期する設計に変更します。

2. Webhookの重複実行

ネットワークエラーにより、同じデータが2回送信されることがあります。

解決策：Notion側に「Stripe Event ID」を保存するフィールドを作成し、更新前に「そのIDが既に存在するか」をチェックするフィルターを設定します。

3. データ不一致（アンマッチ）

ゲスト購入などでShopifyのメタデータがStripeに正しく渡らなかった場合、紐付けが失敗します。

解決策：「不一致専用」のNotionビューを作成し、エラーが発生したレコードを自動で格納、担当者が週に一度手動で紐付ける運用をフローに組み込みます。

まとめ：自律駆動するバックオフィス・アーキテクチャ

Shopify、Stripe、Notionを疎結合で連携させることで、EC運営の現場は「情報の確認作業」から解放され、「顧客への価値提供」に集中できるようになります。このアーキテクチャの真価は、単なる自動化ではなく、「誰が、いつ、どの注文に対して、どのような判断を下したか」というコンテキストがNotionに蓄積されることにあります。

また、このデータ基盤は将来的に会計ソフトやBIツールとの連携にも耐えうる拡張性を持っています。経理実務との整合性を重視した設計については、以下のガイドも参考にしてください。

【関連記事】freee会計の「経営可視化・高度連携」フェーズ。会計データを羅針盤に変えるBIとAPI連携術

自社での構築が困難な場合や、より高度なセキュリティ要件（PCI DSS等）に準拠した設計が必要な場合は、公式の導入事例を持つパートナーへの相談を推奨します。

実務導入前に確認すべき「データ整合性」のチェックリスト

ShopifyとStripeを連携させてNotionへ集約する際、システムの仕様上見落としやすいポイントがいくつか存在します。安定稼働のために、以下の3項目を事前にチェックしてください。

• Stripeメタデータの文字数制限：ShopifyからStripeへ渡すメタデータは、1キーあたり500文字、全体で50個までの制限があります。複雑な注文情報をすべて詰め込むことはできないため、Notionへの格納は「Shopify注文ID」をキーとしたルックアップを基本にしてください。
• Notion側のページ編集権限：Make等のiPaaS経由でNotionを更新する場合、インテグレーション（内部公開API）に対し、対象の親データベースだけでなく、関連するリレーション先データベースへの編集権限も付与されている必要があります。
• 返金期限とAPIの挙動：Stripe側で返金処理が可能な期間と、Shopify側の注文ステータスが連動しないケースがあります。実務上は「Stripeで返金不可となった注文のNotionステータスをどう扱うか」の運用ルールも決めておくべきです。

Shopify・Stripe・Notionの役割分担表

各ツールに持たせる「責務」を明確にすることで、万が一のシステムトラブル時も原因の切り分けが容易になります。

機能・責務	Shopify	Stripe	Notion
情報の真実性	注文内容・在庫	決済・送金・異議	対応履歴・判断理由
顧客への通知	購入完了・配送完了メール	領収書・返金通知	（なし）
データの保持期間	半永久（ストア運営中）	法廷保存期間に準拠	任意（業務履歴として）

公式ドキュメント・関連リソース

APIの仕様変更やセキュリティアップデートに対応するため、構築時には必ず以下の公式リソースを最新の状態に保つようにしてください。

• Shopify ヘルプセンター：Webhook の使用
• Stripe API Reference：Metadata（メタデータの仕様）
• Notion Developers：API Reference

また、Notionへの集約だけでなく、現場のオペレーション負荷をさらに軽減したい場合は、モバイル端末から在庫やステータスを更新できる仕組みの検討も有効です。
Excelと紙の限界を突破する「Google Workspace × AppSheet」業務DX完全ガイドでは、現場主導でフロントエンドを構築するヒントを解説しています。

本記事で構築したNotion上のデータ基盤は、将来的にSFAやMAとの連携、あるいは全社的なデータ分析の礎となります。ツールの垣根を超えた全体の設計思想については、
【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』も併せて参照してください。

📚 関連資料

このトピックについて、より詳しく学びたい方は以下の無料資料をご参照ください：