バンドルはいい加減にすると価格表示と在庫を壊す\n\nバンドルは購入者にはシンプルに見えます。「これを一緒に買うとお得」です。でも実際には価格、税金、プロモ、原価（COGS）、在庫に同時に影響します。明確なルールを定めないと、チェックアウトは正しく見えても、レポートはいつの間にか現実とずれていきます。\n\n最初に起きる問題は大きく分けて二つ：割引が不明瞭になることと在庫数が信頼できなくなること。購入者はバンドル価格を見て、そのうえにプロモコードや「比較価格」、個別割引が重なり、得したか分かりにくくなります。内部ではバンドルが1つのユニットとして売れたのか、複数の商品として売れたのかをシステムが合意していないことがあります。\n\n注視すべき主なリスクは次の通りです：\n\n- 割引が不明瞭：購入者がどれだけ得をしたかわからず、サポートに「請求は正しかったか？」という問い合わせが増え、経理は収益を説明できなくなる。\n- 在庫数の不整合：キットを売ったのにキットSKUしか減らず、構成部品が減らないため部品を過剰販売したり、不必要に在庫が滞留する。\n\nバンドルが見かけ上は利益が出ているようでも、実際には損をしていることもあります。売上をバンドル単位で記録し、コストをコンポーネント単位で追っていない（あるいは追っていない）と、ダッシュボード上の「バンドル粗利」は良好に見えても、高価な部品コストが無視されたり、二重に割引されていたり、返品で想定より多く戻ってきていることがあります。\n\n「正確さ」は次の4つを意味するべきです：\n\n1) チェックアウトが約束と一致している：購入者はバンドル価格と節約額を一貫して確認できる。\n\n2) 売上レポートが説明可能である：実際に何個の各アイテムを動かしたか、どれだけ割引したかを答えられる。\n\n3) 在庫が正直である：バンドルが出荷されれば、倉庫が別々の棚からピックしても、各コンポーネントの正しい数量が引かれる。\n\n4) 返品がデータを壊さない：キットから1点だけ返品があっても、システムは収益、割引、在庫を推測で調整しない。\n\n最初に明確なバンドル価格計算と単一の在庫ルールを決めれば、残りの判断はずっと簡単になります。\n\n## よくあるバンドル／キットの種類（とそれが意味すること）\n\n価格計算を始める前に、まずバンドルの種類に名前を付けてください。種類によって購入者の見え方、マージンの測り方、在庫の動かし方が決まります。\n\nピュアバンドルは「これらは一緒に買わなければならない」タイプです。例：カメラ本体＋レンズ＋バッグ。通常は明確なバンドル価格と、各アイテムを個別に買う場合と比較した割引の説明、毎回一貫した在庫引当が必要です。\n\nミックス＆マッチは「このグループから3つ選んでください」のように、構成が変わるので価格と在庫が複雑になります。ルールとして「何を選んでも同じ価格」にする（単純だがマージンがぶれる）か、「選ばれたアイテムに応じて価格を決める」（透明だが複雑）かを決める必要があります。\n\nキット、マルチパック、アソートは似て聞こえますが挙動は違います：\n\n- キットは異なるSKUをまとめたもので、用途を解決します（スターターキット、修理キット）。購入者はガイダンスと意味のある割引を期待します。\n- マルチパックは同一SKUのまとめ（靴下6足パック）。在庫計算は数量の問題で簡単です。\n- アソートは混合パックで、固定または可変のミックスがあります（お菓子ボックス）。可変の場合は代替ルールが必要です。\n\nバンドルに専用SKUを割り当てるべきなのは、安定したレポートや運用が必要な時です。一般的な理由：\n\n- ピック／梱包用の専用バーコード／ラベルが欲しい。\n- 広告やマーケットプレイスで単一SKUが必要。\n- コンポーネントではなくバンドル単位での売上集計が必要。\n- コンポーネント価格を触らずにバンドル価格だけ頻繁に変えたい。\n\nもし「バンドル」が単なる一時的な割引で、アイテムが別売り可能で週替わりで構成が変わる場合は、カタログはプロモ（チェックアウトでの割引ルール）で扱ったほうがクリーンで在庫の驚きも減ります。\n\n## 割引が明確に見える価格計算\n\n購入者は細かい計算をしないことが多いです。バンドル価格を、別々に買ったらいくらになるのかと比べます。あなたの仕事はその比較を簡単で一貫性のあるものにすることです。\n\nまず、各バンドルに対して2つの価格を定義してください：\n\n- リスト価格（参照）：含まれるアイテムの現在の公開価格の合計（バンドルで指定したバリアントを使う）。\n- バンドル価格（支払額）：実際の販売価格。\n\nそして割引を1つの標準的な方法で計算し、それを守ります：\n\n\n\n\n\nこれが最もシンプルな計算で、ほとんどの購入者が期待する表示と一致します。\n\n端数処理は信頼を失いやすいポイントです。カートに79.99ドルと表示しつつ「20%オフ」と出ると、購入者は計算します。嫌な端数を避けるルールを決めてください。\n\n実用的なルール案：\n\n- バンドル価格は通常の小売パターン（.99など）に丸める。\n- 割引率は丸め前の値から計算し、表示は切り捨てで整数％にする。\n- 「Save $X」を表示する場合は、節約額をセント単位で切り捨てる。\n- しきい値未満の割引（例：1%未満）は表示しない。\n\nオプション付きバンドルはもう一つ判断が必要：最も安い構成で価格表示するか、購入者が選んだ構成で表示するか。例えば「3つのうち1つ選ぶ」キットでは、選ばれたバリアントを基にリスト価格を計算して表示の正直さを保ちます。\n\n最後に、コンポーネント価格が後で変わった場合の扱いを決めます。最もクリーンなのはバンドル価格を独立した決定として扱い、意図的に価格変更するまで固定することです。表示される「比較価格」は現在のコンポーネント価格から再計算します。もし割引が大きく振れるなら、割引が5ポイント以上変動したらレビューを行うトリガーを設定して、顧客に気付かれる前に調整できるようにします。\n\n## マージン計算：利益を測れるようにする\n\nバンドル割引が「良い」かどうかは、利益が見えるかどうかです。まずコンポーネントレベルのCOGS（売上原価）を確定してください。キットの各アイテムには現在の単位コスト（仕入れや製造コスト）と、バンドル専用の追加コスト（特別な包装など）を含めます。\n\nバンドルのCOGSは単純です：各コンポーネントの単位COGS×数量を合計し、包装や取り扱い費を加えます。\n\n\n\n例："Starter Kit"を99ドルで販売する場合。\n\n- コンポーネントAのコスト28ドル、Bは12ドル、Cは8ドル。\n- キットはそれぞれ1つずつ含む。\n- 箱とインサートで3ドル。\n- プロモとして6ドルの送料補助を負担。\n\nBundle COGS = 28 + 12 + 8 + 3 = $51\n\nGross margin $ = 99 - 51 - 6 = $42\n\nGross margin % = 42 / 99 = 42.4%\n\nこれが製品バンドルの基本です：購入者には割引が明確に見え、あなたはマージンを把握できます。\n\nレポーティングのためにバンドル収益をコンポーネントに配分する必要があるかもしれません（カテゴリ別売上、コミッション、税務用）。一般的な方法は各アイテムの単独価格に対する比率で配分することです。Aが合計値の50%なら、バンドル収益の50%をAに割り当てます。配分ルールは一貫させて、月次比較が可能にしてください。\n\n割引を公開する前に、悪いバンドルを防ぐガードレールを設定してください：\n\n- バンドルの最低粗利率（例：35%）\n- 注文ごとの最低粗利金額（低価格帯のキットを守るため）\n- 注文あたりの送料補助の上限（送料でマージンが消えることがある）\n- 組立に時間がかかるキットには梱包やピック作業をCOGSに含める\n\nこれらの小さなコストは急速に大きくなります。特別な包装が必要なら、それを本当のCOGSとして扱ってください。\n\n## 在庫引当モデルで正確さを保つ\n\n価格が約束なら、在庫は真実です。バンドルが売れた瞬間に、在庫システムは「どの物理的なアイテムが棚を離れたか」を素早く答えなければなりません。\n\n### モデルA：販売時にコンポーネント在庫を引く\n\n在庫としてはコンポーネントのみを管理します。バンドルが売れると、必要数の各コンポーネントを差し引きます（例：ボトル1本＋フィルター2個）。バンドルが主に価格上の概念である場合、これが最もクリーンな選択です。\n\nフルフィルメントでピッカーがキットを組み立てる運用と相性が良く、バンドル割引が「送料が安いから稼げているのか、コンバージョンの向上か、実際にマージンがあるのか」を把握しやすくします。\n\n### モデルBとモデルC：キットSKU在庫または仮予約\n\nモデルBはキットを実際に在庫する方法です。事前にキットを組み立てておき、販売時にキットを1つ引く形。組み立て時にコンポーネントを消費するステップが必要で、そうしないとコンポーネント数が合いません。\n\nモデルCは販売やレポート用に仮想のバンドルSKUを持ち、注文時点でコンポーネントを予約する方法です。支払い確定が遅れる場合や売り過ぎを防ぐために予約は有効です。\n\n選び方の簡単な指針：\n\n- 最速のピッキングと一貫した梱包が必要？モデルB。\n- コンポーネントレベルの在庫精度が最優先？モデルA。\n- 売り過ぎ防止とバックオーダー対応が必要？モデルC。\n- バンドルSKUでのクリーンな報告が欲しいがコンポーネントの真実も失いたくない？モデルC。\n- 倉庫の変更を最小限にして柔軟な入れ替えをしたい？モデルA。\n\n複数倉庫がある場合は、実際に出荷する場所から差し引くルールを追加してください。モデルAやCではコンポーネントの選定は倉庫別に行い（倉庫1にチャージャーがあり倉庫2にない可能性）、モデルBでは倉庫ごとにキット在庫を追跡し、移動や組立の作業指示が必要になります。\n\n短い例：スターターキットにマグと蓋が含まれるとします。倉庫Aにマグはあるが蓋がない場合、モデルAでは両方が揃う倉庫に注文をルーティングするか、分割出荷を許す（追加送料を許容する）必要があります。モデルBは完全なキットを在庫している場所だけで販売するので混乱が避けられます。\n\n## カタログと在庫システムでバンドルをモデリングする手順\n\nバンドルが正常に動くためには、カタログと在庫が「何を売っているのか」について合意している必要があります：新しいアイテムか、既存アイテムのセットか。何を追跡し、価格付けし、返品対応するかをまず決めてください。\n\n### シンプルなモデリングフロー\n\n1. バンドルに別SKUを割り当てるか決める。別SKUは別のレポート、バーコード、固有イメージ、異なる返品ポリシーが必要な場合に使う。チェックアウトの便宜だけならコンポーネントのみで良い。\n2. 部品表（BOM）を定義する。すべてのコンポーネントと数量を列挙する（ケーブル、インサート、電池などの“地味”な物も含む）。このBOMが在庫引当の真実のソースになる。\n3. 価格表示と割引ルールを設定する。1つの方法を選んで守る： (a) バンドル価格を示し「合計からこれだけお得」とする、または (b) 割引をコンポーネントに配分してマージン報告をクリーンにする。ここで価格計算を明確に文書化する。\n4. 引当のタイミングを決める。迅速なフルフィルメントで売り過ぎを防ぎたいなら注文時に引く。バックオーダーや注文編集が多いなら出荷時に引く。予約在庫を使うなら、注文時に予約し出荷時に確定で差し引く。\n5. 公開前にエッジケースをテストする。あるコンポーネントの在庫が低い場合、部分出荷、代替、キットの一部返品などを試す。\n\n設定検証の簡単なシナリオ：マグ1個とコーヒーパック2個の「Starter Kit」を売るとします。もしマグが在庫切れでコーヒーパックがある場合、ストアフロントはバンドルをブロックするかバックオーダー表示にするか、少なくともマグを予約せずにコーヒーパックだけ2個を差し引くことがないようにすべきです。\n\nカスタムワークフローを作るなら、Koder.aiのようなツールはバンドルルール（SKU、BOM、引当タイミング）を一度定義し、Webとバックエンドで一貫したカタログと在庫ロジックを生成するのに役立ちます。\n\n## フルフィルメント、代替、返品をややこしくしない方法\n\nバンドルは現場で問題が起き始めると厄介になります：一つが欠品、購入者が差し替えを望む、返品が部分的。最も簡単な方法は、購入者向けの注文表示はシンプルに保ち（バンドルの1行）、フルフィルメントと在庫はコンポーネント単位で追跡することです。\n\nあるコンポーネントが欠品したとき、あらかじめバンドルを部分発送するか全て待つかを決めてください。部分発送を許すなら実際に出荷したものだけ在庫から差し引き、残りは予約して売り過ぎを防ぎます。バンドルの行は「部分出荷済み」と表示されますが、在庫台帳は正確に保たれます。\n\n代替を許可するのは良いですが、無制限にはしないでください。代替は管理された変更として扱い、報告とマージンが保たれるようにします。\n\n- 代替は事前定義したグループ内（同じサイズ、タイプ、コスト帯）に限定する。\n- フルフィルメントには「予定していたコンポーネント」と「出荷したコンポーネント」の両方を記録する。\n- 価格はバンドル価格のまま、明示的な追加料金やクレジットがない限り変えない。\n- 代替が高コストなら、追加コストを記録してバンドルマージンを正確に保つ。\n\n返品には2つの経路が必要です：キット全体の返品と、単一コンポーネントの返品。例：$90で売ったスターターキット（もともとは$100）があって、ボトル($40リスト)とブラシ($60リスト)を含むとします。キット全体が返品されたら、両方のコンポーネントを在庫に戻し$90を返金します。\n\nブラシだけが返品された場合、返金はブラシの単独価格ではなく、支払ったバンドル価格の按分額に基づくべきです。単純で納得しやすい方法はリスト価格比で按分することです。\n\n- 重みを計算：ブラシ比率 = 60 / (40 + 60) = 60%\n- 返金 = $90 × 60% = $54（税ルールに従う）\n- 在庫に戻すのはブラシのみで、マージン報告ではブラシ分のコストのみを逆仕訳する。\n\nこれにより割引表示は明確に保たれ、「無料で戻ってくる」ような誤差を防ぎ、在庫ズレも止められます。\n\n## よくあるミスと罠（回避方法）\n\nバンドルが失敗するのは大抵地味な理由です：カタログルールが不明確で、計算が二重に適用される。直すには価格、マージン、在庫の真実を1つのソースに定めることがほとんどです。\n\n最大の在庫トラップは二重で在庫を引くことです。販売用にバンドルSKUを持つなら、それが「仮想SKU（在庫を持たない）」か「事前梱包SKU（在庫を持つ）」かを決めます。仮想バンドルはコンポーネントのみを差し引くべきで、事前梱包キットはキットSKUのみを差し引き、開封したときにコンポーネントを調整します。\n\n割引が端数のせいで大きく見えることもあります。バンドル価格が$49.99だとクリーンに感じますが、各コンポーネントを個別に丸めると1件あたり数セントずつ差が生まれ、長期ではサポートコストやレポートの混乱につながります。丸めルールを1つ決め、最終的なバンドル価格で一度だけ適用してください。\n\nよくある罠とその対処：\n\n- 梱包やピック作業などの「隠れた」コストを忘れる。バンドルごとの取り扱い費を加える。\n- キット内でバリアント（サイズ、色、地域）を混ぜるがマッピングが不明瞭。各オプションに対して使用するコンポーネントSKUを明確にする。\n- コンポーネントのコストや価格を更新したのにバンドルを再チェックしない。コンポーネントが変わったらマージンレビューをスケジュールする。\n- POSやERPがコンポーネントへの収益配分を別の方法で行う。配分方法を1つ定義して守る（リスト価格比による配分が一般的）。\n- プロモが意図せず重複する（バンドル割引＋クーポン＋自動階層割引）。スタッキングルールを事前に設定する。\n\nコードでロジックを作るなら、実装前にルールを書き出してください。Koder.aiでは、バンドルルール（在庫引当、丸め、割引の重複）を計画モードで定義すると、後でソースコードをエクスポートしたり新しいバンドルを追加したときに挙動を一貫させやすくなります。\n\n## バンドル公開前のクイックチェックリスト\n\nバンドルを公開する前に10分でルールの整合性を確認してください。多くの問題は後で「なぜ損をしているのか？」や「なぜ在庫が合わないのか？」という形で出てきて、その多くは不明瞭な計算に起因します。\n\n購入者向け価格表示から始めます。「Save 15%」と表示するなら、その数字がどこでも同じ参照価格（現在の販売価格、古いMSRPではない）から算出されていることを確認してください。ここでバンドル価格計算が実践で試されます：表示された割引は購入者が検証できる値と一致するべきです。\n\n次に、実際にかかるコストで利益を確認します。商品コスト、手数料、梱包、ピック・フルフィルメント作業、追加の送料などを含めてください。すべてが完璧に行って初めて目標マージンに達するなら、そのオファーはリスクがあります。\n\n在庫はもう一方の柱です。バンドルを別SKUにするか、どのタイミングでコンポーネントを差し引くか、キャンセルや返品でどうなるかを決めてください。在庫ロジックを1文で説明できなければ、実運用で破綻します。\n\n事前チェック項目：\n\n- 割引の検証："you save" 表示とチェックアウト合計が同じ参照価格と丸めルールを使っている。\n- マージン検証：商品コスト、手数料、梱包、フルフィルメント後でも最低マージンを満たす。\n- 在庫検証：バンドルを1つ売ると常に同じコンポーネント数量が差し引かれ、返品やキャンセルで正しく戻る。\n- 低在庫ルール：1つのふるまい（販売をブロック、バックオーダー許可、定義済み代替を提示）を一貫適用する。\n- レポート検証：手作業のスプレッドシートなしで、いくつのバンドルが売れ、いくつのコンポーネントが消費され、バンドルごとの利益が答えられる。\n\nKoder.aiのようなツールで自動化するなら、まずこれらのルールを書き、それを正確に実装して数字が拡大しても安定するようにしてください。\n\n## 例：実数を使ったスターターキット\n\n別売りもしている3つのアイテムで作る"Starter Kit"を想像してください。目的は割引を明確にし、利益をチェックしやすくし、在庫を常に正しく保つことです。\n\n### キット、価格、割引\n\n以下のコンポーネントと価格、コスト（COGS）を仮定します：\n\n- 水筒：リスト価格 $20、COGS $8\n- ジムタオル：リスト価格 $12、COGS $4\n- プロテインシェイカー：リスト価格 $18、COGS $6\n\n別々に買うと顧客は $20 + $12 + $18 = $50 を支払います（これが「合計」リスト値）。\n\nバンドル価格を $42 に設定します。割引は $50 - $42 = $8、割引率は $8 / $50 = 16% です。\n\n購入者に合計とキット価格、節約額を示すのが最もクリアな見せ方です。\n\n### バンドルのCOGSとマージン\n\nバンドルのCOGSはコンポーネントのCOGS合計：$8 + $4 + $6 = $18。\n\nキットの粗利は $42 - $18 = $24。\n\n粗利率は $24 / $42 = 57.1%。\n\nこの1つの数字でバンドルを通常マージンと比較できます。通常ターゲットが60%なら、このキットは少しタイトで、より高いコンバージョンがそれに見合うか検討する必要があります。\n\n### 在庫への影響（キット5個販売、その後一部返品）\n\n初期在庫：水筒40、タオル30、シェイカー25。\n\n5キットを販売。各コンポーネントが5個ずつ差し引かれます：\n\n水筒 40 - 5 = 35、タオル 30 - 5 = 25、シェイカー 25 - 5 = 20。\n\nその後、顧客が1キットのタオルだけを返品。タオルを1つ在庫に戻します（タオル 25 + 1 = 26）。\n\n金銭面では、明確なルールを採ること： (a) キットの部分返品を認めない、または (b) 部分返品は支払ったキット価格の按分で返金する。タオルの単独価格($12)で返金すると、儲かっていたキットが赤字になる可能性があります。\n\n## 次のステップ：ルールを書き出し、可能な限り自動化する\n\nバンドルは全員が同じルールを守るときだけ利益を保ち正確に動きます。スケールして複数チャネルで売る前に、チームが問題時に参照できる簡潔な「バンドルポリシー」を書いてください。\n\n3つの主要項目を平易に含めます：バンドル価格設定と割引表示の方法、在庫の引当方法（バンドルSKU、コンポーネント、または両方）、返品時の扱い（バンドルで返金するかコンポーネントごとか）。\n\n良いポリシーは1ページに収まります。短いチェックリスト例：\n\n- 価格ルール：許容する割引と表示方法（％オフ、固定価格、またはBuy X Get Y）。\n- マージンルール：どのコスト基準を使うかと最低マージン。\n- 在庫ルール：どのタイミングで何を差し引くか、コンポーネント欠品時の対応。\n- 返品ルール：キット全体のみか部分返品を認めるか、開封や欠品時の扱い。\n\n次に、実際の注文でエッジケースをテストします。部分返品、代替、バックオーダー、異なる税区分の混在、月中の価格変更など、各シナリオで1つずつテスト注文を作り、スクリーンショットやメモを保存してシステム更新後も繰り返し検証できるようにします。\n\n月次レビューを設定してマージンドリフトを捕まえてください。コンポーネントコストは静かに変わり、「良い商談」がいつの間にか損失商品になることがあります。トップバンドルのコストと実際マージンを15分で見直すリマインダーで十分なことが多いです。\n\n現在のツールでルールを表現できないなら、必要な機能だけを持つ小さな社内アプリを作ってください（バンドル設定、検証、レポーティング）。Koder.aiならチャットでルールを説明してバックオフィス用ツール（React + Go + PostgreSQL）を生成し、スナップショットとロールバックで安全にロジックを調整できます。
