見えた事実
コンテスト商品には `還元対象` と `no-easy-points` が同時に付いているケースがほとんどです。 つまり、「特別還元の対象だが、Easy Points の通常ポイントは付けない」という運用がすでに行われている可能性が高いです。
この資料は、最初に共有された添付シミュレーター（FWJ Athlete Reward Program_r09.html） のロジックを中心に据えて、 「理想の設計」「いまストアで実際に動いていること」「今すぐ安全に回す方法」「その後の自動化ロードマップ」 を、非エンジニアでも追えるように再構成したビジュアルガイドです。
添付ロジック自体は整理されていて筋が通っています。 ただし、現ストアでは割引とポイントが複数の仕組みで混在しているため、 まずは「月末一括付与」で運用を安定させ、その後で自動化するのが最も安全です。
この資料は、添付ロジックの理解から始まり、現行ストアの実態、月末運用、Appendix の実務資料までを順番に読める構成です。 読みたいスライドを選んで直接移動できます。
シミュレーターが示していた還元ロジックを理解するスライド。
02Shopify 本体、既存アプリ、独自ルールの関係を俯瞰するスライド。
03本番ストア調査で見えた割引・ポイント運用の実態。
04自動値引き、コード値引き、ポイント除外がどう重なっているか。
05今すぐ完全自動化しない理由と、なぜ順番が大事か。
06直近で採るべき現実的な運用方針。
07すでに揃っている分析・説明・運用ファイル。
08安全運用から半自動化、本格自動化へ進む道筋。
09今すぐ確認すべき Gタグの意味と、その先の作業。
A月末ポイント付与の実務手順書。
B実データに基づくポイント付与サンプル。
CGタグ調査の結果と、なぜ業務確認が必要か。
添付シミュレーターの核心は、「目標還元率 N を決め、そのうち 80% を即時値引き、残りを次回利用ポイントで返す」という考え方です。
添付ファイルは、複雑に見えても「即時値引き」と「後から使うポイント」を分けて、全体の還元率を揃える設計です。
`N` は最終還元率、`Z` は値引き後の支払金額、`r` は Shopify 側で設定する整数ポイント率です。
添付HTMLでは、早期申込、会員ランク、競技数のうち一番高い条件を採用し、それを最終的な目標還元率として使います。
| 目標還元率 N | Shopify設定率 r | 実質総還元率 |
|---|---|---|
| 20% | 5% | 20.2% |
| 25% | 7% | 25.6% |
| 30% | 8% | 30.08% |
| 40% | 12% | 40.16% |
これは「細かい小数点をその場で正確に扱えないなら、値引きとポイントを分けて全体の還元率を合わせにいく」という設計です。 考え方としてはかなり合理的で、今回の運用再設計の出発点として使えます。
お客様から見ると「買ったら安くなって、あとでポイントが付く」だけですが、裏側では Shopify 本体、既存アプリ、独自ルールが重なっています。
問題は Shopify 単体ではなく、Shopify 本体と既存アプリと独自運用が重なっていることです。
商品タグ、注文時の割引、顧客の loyalty 情報の3つが重要です。
本番ストアを読み取り調査した結果、割引とポイントの運用はすでにかなり複雑です。ただし、その複雑さは「見える化」できるところまで来ています。
現ストアには既に特別還元用のタグ設計と、複数の割引ロジックが入っています。つまりゼロからではありません。
`還元対象` と `no-easy-points` が同時に付いている点が、月末一括付与へ寄せる根拠です。
コンテスト商品には `還元対象` と `no-easy-points` が同時に付いているケースがほとんどです。 つまり、「特別還元の対象だが、Easy Points の通常ポイントは付けない」という運用がすでに行われている可能性が高いです。
値引きは 1 つの仕組みではありません。 エントリー数に応じた自動値引きと、`spoint3000` のような別のコード値引きが合算されています。 今すぐ全面改修すると、本番の既存運用を壊すリスクがあります。
いまのストアでは、注文時に「自動値引き」と「コード値引き」と「ポイント除外制御」が同時に走っているように見えます。
注文時には 1 つのルールではなく、複数の割引と除外ルールが同時に働いています。
ここを一気に触ると、本番の割引が壊れる可能性があるためです。
対象商品には `コンテストエントリー` `還元対象` `no-easy-points` が付いています。
`1エントリー割引` `2エントリー割引` のような自動値引きが注文に乗ります。
`spoint3000` のようなコードがさらに重なっている注文があります。
Easy Points の通常還元は止めたうえで、別還元を設計しているように見えます。
ロジックが悪いというより、「既に本番で複数の運用が動いている」のが難しさの本体です。だからこそ順番が大事です。
今の問題は「計算式がないこと」ではなく、「既存運用が混在していること」です。
だから、直近は完全自動化よりも、安全な月末運用へ寄せる方が合理的です。
添付ロジックの考え方は活かしつつ、注文時にすべて自動化するのではなく、月末にまとめてポイント付与する方式へ一度寄せます。
月末一括付与なら、本番を止めず、例外注文も人が確認しながら処理できます。
抽出、ベース計算、会員ランク補完、月末付与の4段階に分けて運用します。
還元対象かつ Easy Points 通常付与除外の商品だけを集めます。
競技数、注文日、イベント日から、早期条件と競技数条件を先に計算します。
`G5` などのタグの意味を対応表に入れて、会員ランク由来の還元率を補います。
最終CSVにしたがって、月末にまとめて付与し、翌月から利用可能にします。
ただの検討ではなく、月末運用へ進むためのデータ抽出と説明資料の土台はすでに作成済みです。
今は「考え中」ではなく、すでに分析結果・候補CSV・説明資料まで揃い始めています。
最大の未確定要素は Gタグと会員ランクの対応だけです。
一番大事なのは順番です。「全部直す」ではなく、「安全に運用する → 半自動化する → 本格自動化する」の順に進みます。
ロードマップは、運用の安定化から始めて、段階的に自動化へ進む形です。
いまの複雑な本番運用を、確認なしに一気に置き換えることです。
添付ロジックの理解、本番ストア調査、割引構造の見える化。ここは着手済みです。
会員ランク対応表を作り、毎月のポイント候補CSVを確定させます。
CSVの生成やチェックをさらに自動化し、人的な確認だけで回せる状態に近づけます。
注文時の計算、自動付与、管理画面での確認まで含めた仕組みに拡張します。
次に必要なのは、開発より前に「Gタグの意味を翻訳すること」です。そこが分かれば、最終CSVをかなり具体的に完成できます。
次のボトルネックはコードではなく、業務定義です。Gタグの意味が分かれば運用は一気に前に進みます。
Gタグの意味を業務側で確認し、分かったものだけ対応表へ入れてください。
G5 / G9 / G11 などが、Iron / Steel / Titan のどれに対応するかを業務側で確認します。
現時点では、ストアデータだけでは安全に確定できていません。
shopify-member-rank-map.json にランクと率を入力します。
再生成された CSV が、月末に担当者が使う実務用リストになります。
ここでは「どの画面を押すか」ではなく、担当者が月末にどの順番で何を確認し、どの資料を使って付与額を確定するかを整理します。
月末運用は、抽出して終わりではなく、例外確認と確定判断を含む“締め処理”です。
ルールに沿って確認し、最後の付与額を確定することです。
例: 3月1日 00:00 から 4月1日 00:00 まで。
まず「今月分に含める注文期間」を固定します。
shopify-member-rank-map.json に、`G5` や `G11` がどのランクかを入力します。
集計スクリプトを実行し、 shopify-monthly-points.csv を最新化します。
キャンセル、返金、会員ランク不明、特殊な割引の入った注文がないかを確認します。
`final_point_amount` を基準に、顧客ごとの月次付与ポイントを確定します。
月末に、確定した顧客一覧に対してポイント残高をまとめて反映します。
付与実績のCSVや一覧を保存し、翌月の問い合わせに備えます。
付与済みポイントは翌月から使える状態にし、必要に応じて案内します。
1. 会員ランク対応表
2. 月末ポイントCSV
3. 月末ポイントJSON
4. 運用手順メモ
5. Gタグ調査結果
1. Gタグはどの会員ランクか
2. 返金・取消を今月分から除外するか
3. 特殊なコード値引きが入っていても対象に含めてよいか
4. 翌月利用開始日をいつにするか
実際の注文データをもとに、「月末一括付与ならどのようにポイントを計算する想定か」を具体例で示します。 ここでは、まだ会員ランクが不明なものは「ベース条件だけで計算した暫定値」として扱います。
ここにある数値は、添付ロジックを月末付与へ転用したときの実務イメージです。
会員ランク未確定の注文は、あくまでベース条件だけでの暫定値です。
| 注文番号 | 条件 | 支払後金額 Z | ベースN | 整数率 r | 想定ポイント | 備考 |
|---|---|---|---|---|---|---|
| #8700 | 1競技 / 早期条件あり / G11 | 5,360円 | 30% | 8% | 428pt | G11 の意味が未確定のため、現時点では早期条件ベースの暫定値 |
| #8699 | 1競技 / 早期条件あり / G5 | 5,360円 | 30% | 8% | 428pt | G5 が Steel/Titan などに確定すれば再判定 |
| #8693 | 2競技 / 早期条件あり / 会員タグあり | 13,720円 | 30% | 8% | 1,097pt | 競技数条件は20%だが、早期条件が30%なので30%採用 |
| #8514 | 4競技 / 早期条件あり | 29,920円 | 40% | 12% | 3,590pt | 4競技条件の40%が最優先になるため、会員ランクが不明でも暫定確定しやすい |
2競技なので競技数条件だけなら 20% ですが、イベント日との関係から早期条件が成立しているため、より高い 30% を採用します。 添付ロジックに沿うと、30% に対する Shopify 用整数率は 8% なので、 `13,720 × 8% = 1,097.6` を切り捨てて `1,097pt` という扱いになります。
4競技エントリーは添付ロジック上で 40% が最優先です。 40% に対応する Shopify 用整数率は 12% なので、 `29,920 × 12% = 3,590.4` を切り捨てて `3,590pt` になります。 これは会員ランクが不明でも、かなり確定に近いケースです。
もっとも重要な確認事項だった `Gタグ = 会員ランク` について、ストアデータから検証した結果をまとめます。
Gタグは存在していますが、ストアデータだけでは会員ランクに安全対応付けできませんでした。
業務確認が取れたものだけ対応表へ入れる、という運用が必要です。
現時点では、`G5` `G7` `G8` `G9` `G10` `G11` `G12` を `Novice / Iron / Steel / Titan` に安全に結び付けることはできませんでした。 既存の loyalty データでは、ほとんどが `Default / 1%` であり、Gタグごとの差が見えませんでした。
したがって、Gタグの意味は業務側に確認してから 対応表（shopify-member-rank-map.json） へ入れるべきです。 推測で埋めるのは避け、確認済みのものだけ登録する運用が安全です。
| Gタグ | 3月の候補注文 | FWJカード会員内の件数 | 現時点の判定 |
|---|---|---|---|
| G5 | 4件 | 5件 | ランク不明。業務確認必要 |
| G7 | 2件 | 8件 | ランク不明。業務確認必要 |
| G8 | 2件 | 10件 | ランク不明。業務確認必要 |
| G9 | 9件 | 13件 | ランク不明。業務確認必要 |
| G10 | 1件 | 5件 | ランク不明。業務確認必要 |
| G11 | 1件 | 3件 | ランク不明。業務確認必要 |
| G12 | 2件 | 7件 | ランク不明。業務確認必要 |