CPQ Builder スキル

このスキルが行うこと

このスキルは Configure-Price-Quote 形状のツール向けのパターンを定義しています。ユーザーが入力を設定し、システムがルールを適用して結果を計算し、出力が確認/承認が必要な可能性のある形式化された成果物である、というシステムです。

CPQは製品価格設定に限定されません。同じ構造パターンは以下をカバーしています：

ドメイン	「構成」	「計算」	「出力」
機器販売	製品の選択、オプションの選択	マークアップの適用、合計の計算	販売見積PDF
法律計算機	ケースの詳細入力（収入、期間）	ガイドラインフォーミュラの適用	推定値付きサマリーレポート
保険見積機	保険内容の詳細入力	レートテーブルの適用	プレミアム見積書
ローン適格性判定	財務詳細入力	貸出基準の適用	適格性レター
給付適格性判定	個人情報入力	適格性ルールの適用	給付サマリー
サービス提案	サービスの選択、スコープの設定	労務費の適用	サービス提案

ビルダーはこのスキルを読み、特定のドメインの用語とルールについてDOMAIN.mdを読み、動作するプロトタイプを生成します。DOMAIN.mdはツールがクレーン見積についてか離婚計算についてかを決定します。このスキルはそれに適合する構造パターンを提供します。

このスキルのパターンはデフォルトであり、要件ではありません。 実際のワークフローが標準的なCPQ形状から逸脱する場合――段階が少ない、異なるレイアウト、異なる出力である――パターンを調整してください。各主要セクションは逸脱を明確に名付けています。

---

顧客コンテキスト

Customwareの CPQ顧客は多くのドメインにまたがっています：産業機器ディーラー、カスタムアパレルおよび看板店、食品/飲料卸売業者、専門サービス企業（法律、コンサルティング、デザイン）、IT およびマネージドサービスプロバイダー、建設および職人業、製造業、流通業。CPQパターンはこれらすべてに適合します。

このスキルの例は複数のドメインにまたがっています ――産業機器、サービス、消費財、ソフトウェア、カスタム商品。これは意図的です。パターンはドメイン非依存です。例は類推によって図示します。このスキルを適用する場合、特定の例のドメインを無視して構造パターンを抽出してください。DOMAIN.mdはビルドの特定の語彙、製品、ルール、ロールを決定します。

「単一ガーダークレーンはモーターが必要である」というルールは「カスタムフーディーは印刷方法が必要である」や「マネージドサービス契約はティアが必要である」や「犬用スナックの注文はパッケージサイズが必要である」と同じ形をしています。ルールは「親製品は子コンポーネント選択が必要である」です。そのパターンを構築してください。DOMAIN.mdに単語を入力させます。

顧客プロフィール

Customwareの CPQ顧客は通常 SMB企業（従業員5～50人） で成長の課題を経験しています。彼らは別のCPQシステムから移行していません。彼らは以下から移行しています：

• 制御不能に成長したExcelスプレッドシート（複数のタブ、コピーペースエラー、壊れたフォーミュラ）
• 顧客ごとに手動で編集されるWord文書見積テンプレート
• ボスが返信スレッドで見積を承認するメールベースの承認ワークフロー
• どの製品がどのアクセサリーを必要とするかについての部族知識（シニアレップの頭の中に存在）
• 手入力価格設定で一貫性のない割引を通じて利益幅が低下

プロトタイプの仕事は スプレッドシートより劇的に優れた感覚を与える ことですが、エンタープライズの複雑さを感じさせない ことです。5年間Excelで見積を出していた小さなチームがプロトタイプを見れば、「これはとても速い」と即座に考えるべきです。「これは複雑に見える」ではなく。

このポジショニングはこのスキルのすべての設計判断を形作ります：

• インラインライン編集はEXCELとの比較ポイントです。Excelユーザーは直接編集できるグリッドを期待します。
• ライブ合計は重要です。顧客はフォーミュラで数学をしていました。入力を変更するときに数字が更新されることを期待します。
• ロール限定は印象的です。顧客は「$50Kを超える承認は所有者のみ」がソフトウェアで強制されたことがありません。これは破られた口頭ルールでした。
• ブランド付きPDF出力は印象的です。顧客はWord文書を手動でフォーマットしていました。
• カスタマー向けポータル、AI提案、e-署名統合はこの段階では印象的ではありません。これらは顧客がまだ持っていない問題を解決するエンタープライズの複雑さです。

Salesforceから移行している顧客ではなく、壊れたExcelフォーミュラに疲れた顧客のために構築してください。

---

これは本当にCPQですか？

このスキルのパターンを適用する前に、ワークフローが実際にCPQ形状であることを確認してください。CPQパターンはこれら4つすべてが当てはまるときに適合します：

1. ユーザーが、結果を決定する構造化入力を収集します （構成選択、顧客詳細、要件、財務データ、ケース詳細）。
2. ビジネスルールまたは計算ロジックがそれらの入力を成果物に変換します （マークアップフォーミュラ、ガイドライン計算、レートテーブル、適格性ルール）。
3. 入力と最終化の間の確認または承認ゲートが存在します、または成果物が何らかの関係者確認を通ります（準備者/確認者パターン）。
4. 成果物は引き渡されるように感じます ――顧客、内部関係者、規制機関、下流システムに。

基準1がない場合→これはダッシュボードまたは表示ツールであり、CPQではありません。中止。 基準2がない場合→これはデータ入力フォームであり、CPQではありません。中止。 基準3がない場合→「インテークアンドデリバー」です。CPQパターンを適用しますが、承認セクションをスキップします。 基準4がない場合→これは個人計算機/ユーティリティであり、CPQではありません。中止。

一般的な誤検知：

• 「株価ビューアー」――「見積」という単語がありますが、表示ツールです（基準1がない）
• 確認ステップなしの「税計算機」――ユーティリティであり、CPQではありません（基準3+4がない）
• 価格を持つ「製品カタログ」――表示であり、CPQではありません（基準2+3がない）
• 「フィードバックフォーム」――データ入力であり、CPQではありません（基準2がない）

4つの基準が成立しない場合、以下のパターンを無理に適用しないでください。タスク説明とDOMAIN.mdを使用してfrontend-designの原則から構築してください。

---

ドメインタイプ

ほとんどのCPQ形状のワークフローは2つのドメインタイプのいずれかに該当します。パターンを適用する前に、ビルドがどのタイプであるかを特定してください：

製品ドメイン。 ユーザーは販売可能な製品/サービスを構成します。価格設定は中心的な計算です。出力は明細項目、合計、税、およびターム付きの見積書です。例：機器販売、カスタムアパレル注文、食品/CPG卸売、サービス提案（コンサルティング入札、マネージドサービス）、ソフトウェアライセンス、カスタムパッケージング。

計算機/インテークドメイン。 ユーザーはケース/申請者の詳細を入力します。計算はガイドライン/ルール/レートテーブルを適用します。出力は入力、計算値、免責事項を含むサマリーレポートです。例：配偶者扶養計算機（Clarity Legal）、保険見積機、ローン適格性判定、給付適格性判定。

スキルのパターンは両方に適応します。セクションまたはルールがドメイン固有の場合、このスキルは明確に述べます。

---

最小標準

すべてのCPQビルドはティア1標準を満たす必要があります。ティア2標準はDOMAIN.mdが必要を示すときに構築されます。ティア3機能は完了サマリーでは言及されますが、プロトタイプでは構築されません。

ティア1――交渉不可（すべてのCPQビルド）

これらはプロトタイプをExcel + Wordより劇的に優れたものにする機能です。いずれかが欠けている場合、UIがどれだけきれいかに関わらず、ビルドは不完全です。

1. ダイレクトインラインライン項目編集。 スプレッドシート形式のテーブルで、ユーザーは行を追加し、任意のセルを編集でき、合計がライブで更新されます。「構成フォーム→見積に追加→見積テーブル構築→編集」の往復ではありません。ライン項目テーブルはワークスペースです。下記の「セクションパターン」で標準的な実装を参照してください。

2. バンドル/必須子製品と適切なコンフィギュレーターパターン。 親製品が子コンポーネントを必要とする場合（例：「産業ユニットはモーター選択が必要」、「カスタムフーディーは印刷方法が必要」、「マネージドサービス契約はティアが必要」、「犬用スナックの注文はパッケージサイズが必要」）、子選択は親を構成する一部です。ライン項目は親+選択された子を1つの一貫した項目として表示します。ユーザーが子を忘れる可能性がある2つの別々のライン項目ではありません。4つ以上の構成属性またはカスケード依存関係を持つ製品（典型的な産業機器、カスタム商品、および階層化されたサービスは多くの場合3～4レベル深い）の場合、適切なコンフィギュレーターパターンを使用してください。下記の「製品コンフィギュレーターパターン」でインライン拡張 vs サイドドロワー vs フルページの判断を参照してください。

3. 制約ルールが可視化される。 DOMAIN.mdからのRequires / Excludes / Recommends ルールは、ユーザーに可視である必要があります。サイレントに強制されるのではなく。ユーザーがクレーンを追加すると、UIは「モーター選択が必要（BR-001）」を保存前に表示します。除外された組み合わせを追加しようとすると、UIはルールと根拠を表示します。Excelから来た顧客はルール強制を経験したことがありません。ルールを可視化することが価値の半分です。

4. 割引スタックと可視化された数学。 割引が適用される場合、層状計算を表示します：

定価:                  $15,000.00
ボリューム割引（5%）:      -$750.00
プロモーション割引（3%）:  -$427.50
─────────────────────────────────────
正味価格:              $13,822.50

各割引は行です。数学は透明です。メールスレッドで監査証跡なしに割引を交渉することに慣れた顧客は、価格がどのように達成されたかを正確に確認する必要があります。

5. ライブ見積サマリー。 実行中の合計（小計、税、総合計）はユーザーがライン項目を編集するときにリアルタイムで更新されます。「計算をクリック」ボタンはありません。これはExcelから来る顧客にとって単一の最大の「ワオ」の瞬間です。合計は更新されるだけです。

6. ブランド付き見積書ドキュメント。 生成されたPDF/印刷ビューで、顧客のロゴ、ライン項目テーブル、合計、ターム、および必要な免責事項があります。これは手動でフォーマットされたWord文書に取り代わります。品質バー：実際のビジネスが送信するような見積のように見えるべきです。

7. マルチティア承認ルーティング。 ほとんどのSMBワークフローは2つ以上の承認レベルを持っています（レップが構成→マネージャーが確認→所有者が承認）。単純なケースでもレビュアーと最終署名ロールが少なくとも1つあります。プロトタイプはDOMAIN.mdのステークホルダーマップを尊重するロールベースルーティングを表示する必要があります。ルーティングはリクエストタイプによって分岐することが多いです。例えば、1つの会社は「カスタム構成をシニアレビュアーを通じてルーティング、検査をサービスマネージャーを通じてルーティング、メンテナンスをオペレーションマネージャーを通じてルーティングし、所有者はすべてのパスの最終承認者」かもしれません。その種の条件付きマルチティアルーティングは当たり前です。

8. マルチクォート管理。 ユーザーは複数の見積を同時に進行中です。プロトタイプはステータスインジケーター付きの見積リストを表示する必要があり、フィルタリング/ソートをサポートし、ユーザーが任意の見積をクリックして編集できるようにします。単一見積ワークスペースと「保存されたクオート」サイドバーリストだけではありません。

9. 見積の保存/読み込み/複製。 localStorage バックアップ。ユーザーは新しい見積を作成でき、それを保存でき、保存された見積を読み込むことができ、既存の見積を同様のものの開始点として複製できます。Excelユーザーはタブをコピーしてこれを行います。プロトタイプは彼らに「複製」ボタンを与えます。

10. ロールベース表示とアクション限定。 異なるロールは異なるものを見ます。承認者は「承認」ボタンを見ます。準備者は見ません。機密数字（利益幅、コスト）はアプローバー以外のロールから隠れます。これは顧客が直感的に知っている「ボスだけが利益幅を見ることができる」パターンですが、強制されたことがありません。

ティア2――DOMAIN.mdが正当性を証明するときに構築

これらは価値のある機能ですが、DOMAIN.mdが明確な信号を提供する場合のみ構築する価値があります。

• ガイド付き販売 （複雑な構成のためのステップスルーQ&A）――DOMAIN.mdが顧客との発見フローを説明する場合
• ボリューム/ティア価格 ――DOMAIN.mdがボリュームブレーク、数量ティア、または一括割引を言及する場合
• 顧客向け読み取り専用見積リンク ――DOMAIN.mdが顧客への見積のメール送信/共有を言及する場合
• サブスクリプション/更新処理 ――ドメインがSaaS的で定期収益がある場合
• 1つのビルドの複数の価格設定モデル （コスト足上 + カタログ + カスタム）――DOMAIN.mdが混合価格設定戦略を説明する場合
• 顧客タイプ別の見積書テンプレート ――DOMAIN.mdがオーディエンスごとの異なる出力フォーマットを説明する場合

ティア3――将来の作業（完了サマリーで名付け、構築しない）

これらは本番ビルドに属します、プロトタイプではありません。完了サマリーはそれらを名付けるべきなので顧客は次が来ることを知っています。

• CRM/メール/コール コンテキストからのAI提案見積
• 見積バージョン管理と修正追跡
• サブスクリプション請求ロジックと日割
• CRM/ERP統合（フルスタックフェーズで処理）
• e-署名統合（DocuSign、HelloSignなど）
• 税エンジン統合（Avalara、Vertex）
• 多通貨と動的為替
• セルフサービスカスタマー構成ポータル
• Deal Rooms/ブランド付き提案マイクロサイト
• ネイティブモバイルアプリ

完了サマリーテンプレート

すべてのCPQビルドの完了サマリーは以下を含む必要があります：

## このプロトタイプに含まれるもの

**ティア1（常に構築）:**
- [各ティア1機能が存在することを確認、または特定の機能がない理由をメモ]

**ティア2（このドメイン用に構築）:**
- [構築されたティア2機能のリストとその理由]

## このプロトタイプに含まれていないもの

これはコアCPQワークフローを実演するフロントエンドプロトタイプです。以下の機能は
本番環境で実装されます：

- [顧客の今後のニーズに基づく関連するティア3項目をリスト]

プロトタイプから本番環境へ移行するには、以下を追加してください：実認証、CRM/ERP統合、
e-署名、実PDF生成、および上記のティア3機能。

これは誠実な期待を設定し、より多くが来ることを顧客に示しながら、何が配信されたかを明確にします。

---

このスキルをいつ使用するか

「これはCPQですか？」の4つの基準が成立し、かつ顧客のDOMAIN.mdが以下を含む場合：

クラシックCPQ信号:

• 顧客のために見積/価格設定される製品またはサービス
• 構成オプション（サイズ、モデル、バリアント、材料）
• 製品間の依存関係（requires、recommends、excludes）
• マークアップまたは利益幅ベースの価格設定（コスト足上、ベンダーリスト+パーセンテージ）
• 見積または提案ワークフロー（ドラフト→確認→承認→送信）

より広い「構成-計算-出力」信号:

• 入力を計算出力に駆動する計算機、見積機、または評価ツール
• 入力が計算結果を駆動するガイド付きインテークフォーム
• 結果を生成するためにルールを適用するマルチステップデータ収集
• 出力書類（レポート、サマリー、見積、提案）
• 準備者/レビュアーワークフロー（クライアントが入力→専門家がレビュー）

このスキルを使用しないでください ドメインが主に在庫追跡（ERPスキルを使用）、継続的なプロジェクト実行とフィールド追跡と支払い（trades-builderを使用）、オンライン製品販売（e-commerceスキルを使用）、または顧客関係管理（CRMスキルを使用）について。

---

テンプレート契約

構築を始める前に、テンプレートが提供するものとこのスキルが追加するものを理解してください：

テンプレート（app/layouts/MainLayout.tsx）は付属しています：

• SidebarProvider、Sidebar、SidebarContent、SidebarInset、SidebarTrigger――すでに配線済み
• SidebarContentは 空です ――これはあなたのランディングゾーンです
• ヘッダーの1つのブランドスロット（ロゴプレースホルダー+会社名）
• ヘッダーの右クラスターのModeToggleとユーザーメニュー

このスキルが埋めるもの:

• SidebarContent――選択されたレイアウトに適切なセクションナビゲーション
• ブランドスロット――DOMAIN.mdからのクライアントのロゴと会社名
• ヘッダーの右クラスター――ワークフローが複数のロールを持つ場合、既存のユーザーメニューの前にロール切り替えDropdownMenuを追加
• <main>の<Outlet />――各セクションのルートコンポーネント経由

このスキルはしていません：

• 2つ目のSidebarコンポーネントを追加。1つのサイドバーがあります。
• SidebarContent内にブランドタイルを入れる。ブランドはヘッダーのみに存在します。
• ルートコンポーネント内にMainLayoutをマウント。ルートは<Outlet />でレンダリングされます。レイアウトが親です。ルート内にMainLayoutをマウントすると、重複したサイドバー/ヘッダーが生成されます。
• SidebarProviderを再配線するか、折りたたみ可能な動作を交換。

ワークフローがサイドバーレイアウトに適合しない場合（下記のレイアウトパターン代替を参照）、ビルドは異なるシェルを使用する可能性があります。完了サマリーで逸脱を文書化してください。

---

セクションパターン

デフォルトのCPQワークフローは 3つの論理的フェーズ を持っています：入力の構成、確認/承認、ドキュメント配信。デフォルトUIはこれらを3つまたは4つのセクションにマップします（ユーザーが「確認/編集ライン」の個別段階から利益を得るかどうかによって）。

デフォルトセクション構造（SMB直接編集モデル）

1つのロールが作成から承認を通じて見積を進める場合のSMB CPQの場合（最も一般的なケース）、デフォルトは 3つのセクション です：

1. 見積を編集 ――すべてのライン項目+顧客詳細の直接インライン編集。これがユーザーが90%の時間を費やすプライマリワークスペースです。ライン項目はインラインで追加、編集、削除されます。顧客情報、ターム、およびメモはインラインです。右またはライブ合計以下。
2. 承認 ――確認と承認アクション。最終状態を表示し、限定チェックを実行し、承認アクションを生成します。見積が以前に承認/修正された場合、変更履歴を表示する可能性があります。
3. 見積書 ――成果物。読み取り専用、印刷可能、ブランド形式。

これはv4.3の「構成→見積構築」往復を1つの直接編集表面に折りたたみます。 ほとんどのSMB CPQビルドはこの3セクションモデルを使用すべき です。

4セクション構造（ロール間の引き渡しが存在する場合）

構成とライン項目アセンブリが異なる人によって行われる場合（エンジニアが構成→営業代表が価格設定→マネージャーが承認）、4つのセクションが適切です：

1. 構成 ――エンジニアまたは技術的ロールが製品を指定
2. 見積を構築 ――営業ロールが価格設定、ターム、顧客情報を追加
3. 承認 ――マネージャーロール承認
4. 見積書 ――成果物

DOMAIN.mdが各段階でロール間の本当の引き渡しを説明する場合のみこれを使用してください。ほとんどのSMB CPQは必要としません――1つの人が構成、構築、承認できます。3つのセクションを使用してください。

計算機ドメインセクション構造

計算機/インテークドメイン（Clarity Legalパターン）の場合：

1. 送信詳細 ――インテークフォーム（顧客向け）
2. 計算 ――計算結果（入力から自動生成）
3. 弁護士確認 ――レビュアー向けの承認（弁護士向け）
4. 最終レポート ――配信される出力

構造パターンは同じです。ラベルとコンポーネントはドメインに適応します。

逸脱

ワークフローが確認ゲートを持たない場合、「承認」をスキップしてください （セルフサービスフロー）。見積編集→ドキュメント。 「見積書」をスキップしてください 成果物がドキュメントではない場合（システムへのプッシュ、インライン結果、確認ページ）。 発見フェーズがある場合、見積編集前に「発見/インテーク」を追加してください 。 実際のワークフローに一致するセクション数を選択してください。 パディングして4にしないでください。フィットさせるために切り詰めないでください。

見積セクションの編集――ダイレクトインライン編集（ティア1必須）

見積編集セクションはプライマリワークスペースとして Excel的なライン項目テーブル を使用します。これは製品CPQにとって交渉不可です。

必須動作：

• 各ライン項目は表の行です
• セルはインラインで編集可能です――セルをクリック、値を編集、合計が更新されます
• テーブルの下の「+ ラインを追加」ボタン経由で新しい行を追加（またはユーザーが空のプレースホルダー行をクリックしたときに自動追加）
• 行アクション メニュー経由で行を削除（ゴミ箱アイコン、「削除」オプション）
• 行アクションメニュー経由で行を複製（「複製」オプション）
• ライン当たりの合計が計算されます（数量×単価-割引）
• フッター行がすべてのライン項目全体の小計を計算します
• 割引スタックが小計の下に表示されます（適用可能な場合）
• 税行がDOMAIN.mdが税を言及する場合に表示されます
• 総合計は太字で底部に表示されます

必須列（製品ドメイン）:

#	説明	構成	数量	定価	割引	正味価格	ライン合計	アクション

説明列は製品名を表示します。構成列は選択されたオプション（例：「プレミアムティア――50ユーザー」または「トリブレンド、DTG印刷」）を表示します。必須構成を持つ製品（バンドル/必須子パターン）の場合、行をクリックすると、ユーザーがオプションを選択する前にコンフィギュレータードロワー/ポップオーバーが開きます。構成は一度選択されるとインラインで表示され、クリックして再度編集可能です。

バンドル/必須子製品の必須動作：

DOMAIN.mdが親製品が子コンポーネントを必要とすることを説明する場合――例えば、「産業ユニットはモーター選択が必要」、「カスタムフーディーは印刷方法が必要」、「マネージドサービス契約はティアが必要」、または「犬用スナック注文はパッケージサイズが必要」：

• 親を追加すると、必須子についてのプロンプトが自動的に表示されます
• ライン項目は1つの一貫した項目として表示されます：「[親製品] ― [必須子] ― [バリアント]」
• 価格は集計されます：親ベース価格+子アップチャージ
• 必須子が選択されるまで、ユーザーはラインを保存できません
• 可視ルールインジケーターが表示されます：「[コンポーネント名]選択が必要（BR-001）」

制約ルールの必須動作：

DOMAIN.mdがrequires / excludes / recommends ルールを持つ場合：

• 「Requires」ルールは満足するまでセーブをブロックします。インライン「必須：[説明]」を表示
• 「Excludes」ルールは無効な組み合わせをブロックします。インライン「XをYと組み合わせることはできません。[根拠]」を表示
• 「Recommends」ルールはソフト提案として表示されます。インライン「顧客はこれでよくZを追加します。追加？」を表示
• 各ルールはそのルール ID（BR-001、BR-002）を表示し、ユーザーがソースをトレースバックできるようにします

このように見える制約ルール強制はExcelから来る顧客にとって最大の「ワオ」瞬間の1つです。目立たせてください。

製品コンフィギュレーターパターン

製品が複数の構成属性（3+判断）を持つか、構成がカスケードする場合（レベル1選択がレベル2オプションを決定し、それがレベル3を決定など）、セル内ドロップダウンパターンは十分ではありません。ユーザーは本当のコンフィギュレーターが必要です。

本当の製品構成は多くのドメイン全体で3～4レベル深いことが多いです：

• 産業機器: タイプ→容量→モーター→ホイスト→制御
• カスタムアパレル: 衣服スタイル→生地→サイズセット→印刷/刺繍方法→仕上げ
• ITサービス: サービスティア→ユーザー数→モジュール→SLAレベル→統合
• 食品/CPG卸売: 製品ファミリー→フレーバーまたはバリアント→パッケージサイズ→ケース数→配送コールド/環境温度
• プロフェッショナルサービス: エンゲージメントタイプ→スコープティア→チーム構成→期間→成果物フォーマット
• カスタム看板/パッケージング: 基材→寸法→仕上げ→印刷方法→マウントハードウェア

各レベルが次を制約します。5トン産業ユニットを選択→特定のモーターのみが適合→特定の制御のみがマッチします。トリブレンドフーディー生地を選択→特定の印刷方法のみが互換性あり→特定の仕上げオプションのみ。プレミアムサービスティアを選択→特定のモジュールをアンロック→より高いSLAが必要。図形は同じです。DOMAIN.mdが実際に構成されているものを告げます。

この深さの構成の場合、3つのパターンが適切です。構成の複雑さに基づいて選択されます：

パターンA――インラインで拡張可能な行（2～4属性、カスケードなし）

製品が独立した属性の小数（例：数量、色、サイズ、または1つの構成選択）を持つ場合、ライン項目行はインラインで拡張して属性セレクターを表示します。行をクリック→属性セレクターを表示するために拡張→それらを埋める→行が構成を要約して折りたたまります。

┌─────────────────────────────────────────────────────────────┐
│ 1  [製品名]    [バリアント ▾]    1   $X,XXX.XX  ...     │  ← 折りたたまれた
└─────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────┐
│ 1  [製品名]    [バリアント ▾]    1   $X,XXX.XX  ...     │
│    ┌───────────────────────────────────────────────────┐    │  ← 拡張
│    │ バリアント:   ( ) オプションA    ( ) オプションB │    │
│    │ 数量:        [  1  ]                             │    │
│    │ 説明:        [                              ]    │    │
│    └───────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────┘

使用場面：

• 2～4個の属性合計
• 属性は独立（カスケード依存なし）
• すべての属性が拡張時に視覚的に～200px垂直スペース内に収まります

パターンAに適合する製品の例：サイズと色のT-シャツ、時間と料金の付加サービス、ソフトウェアライセンス座席数、卸売ケース数量選択、1つの仕上げオプションで印刷されたバナー。

パターンB――垂直ステッパー付きサイドドロワー（4～7属性、カスケード許可）

構成がカスケード依存またはカスケード依存性を持つか、4～7属性がある場合、行をクリック→サイドドロワーが右からスライドしスクリーンの～40%をカバーします。ドロワーは各構成レベルを表す左側に垂直ステッパーを持ちます。

                           ┌────────────────────────────────┐
                           │ [製品]を構成する            │
                           │                                │
                           │ ●━━━ ステップ1：基礎        │
                           │ │    [選択された値]           │
                           │ │                              │
                           │ ●━━━ ステップ2：サイジング    │
                           │ │    [選択された値]           │
                           │ │                              │
                           │ ◉━━━ ステップ3：コアコンポーネント │
                           │ │    [ オプションA ]  [ オプションB ] │
                           │ │                              │
                           │ ○━━━ ステップ4：依存選択     │
                           │ │    (ステップ3を最初に完了)   │
                           │ │                              │
                           │ ○━━━ ステップ5：仕上げ      │
                           │                                │
                           │           [キャンセル]  [保存] │
                           └────────────────────────────────┘

ドロワー動作：

• ドロワー内左側の垂直ステッパー（アプリレベルのサイドバーではなく）
• ステップは依存関係が満たされるとクリック可能。満たされないとグレーアウト
• 各ステップのコンテンツはドロワー内ステッパーの右に表示されます
• カスケード依存性：上流選択を変更すると下流選択を無効化して消去（確認トースト付き：「[上流]を変更すると[下流]選択がリセットされます」）
• 「保存」は構成をライン項目にコミット。「キャンセル」は破棄
• ライン項目は構成セクション列にアセンブルされた構成サマリーを表示

このパターンはカスケード構成のために です。パターンBに適合する例：産業機器タイプ/容量/モーター/制御、カスタムアパレル衣服/生地/印刷方法/仕上げ、ITサービスティア/ユーザー/モジュール/SLA、カスタム看板基材/寸法/印刷/マウント。ドロワーはコンフィギュレーターに呼吸スペースを与え、ユーザーを見積ワークスペースコンテキストから連れ出しません。ドロワー内の垂直ステッパーはカスケードを見えるようにしており、アプリレベルのナビゲーションを消費していません。

アプリレベルのサイドバーではなく、なぜドロワー：

• ドロワーはモーダルよりも割り込み的でない感じ
• ユーザーは左で行項目テーブルを見ることができます（コンテキスト）
• ドロワーは外側をクリックして破棄できます（モーダル的「保存してから閉じる」摩擦が避けられます）
• ドロワーはReact Router――開く親ルート、閉じる親に戻る

パターンC――フルページコンフィギュレーター（8+属性、複雑なカスケード）

構成が本当に複雑な場合――8+属性、マルチステージカスケード、図表または可視化を必要とする――コンフィギュレーターはそれ自身のページに値します。「構成」をクリック→/quotes/{id}/lines/{lineId}/configureにナビゲート→トップに水平ステップインジケーター、中央に構成本体、右に要約/プレビューレールのあるフルページ。

┌──────────────────────────────────────────────────────────────────┐
│ ← 見積に戻る                                                      │
│                                                                  │
│ ●━━━━━━●━━━━━━●━━━━━━◉━━━━━━○━━━━━━○                            │
│ ステップ1  ステップ2  ステップ3  ステップ4  ステップ5  確認      │
│                                                                  │
│ ┌─────────────────────────────────┬──────────────────────┐  │
│ │                                     │ これまでに選択：     │  │
│ │  現在のステップのための            │                      │  │
│ │  構成コンテンツ                     │ ステップ1: [値]      │  │
│ │                                     │ ステップ2: [値]      │  │
│ │                                     │ ステップ3: [値]      │  │
│ │                                     │ ステップ4: (選択中)  │  │
│ │                                     │                      │  │
│ │                                     │ 実行中価格：         │  │
│ │                                     │ $X,XXX.XX           │  │
│ └─────────────────────────────────┴──────────────────────┘  │
│                                                                  │
│                          [戻る]  [続行→]                         │
└──────────────────────────────────────────────────────────────────┘

フルページが本当に複雑な構成のために唯一機能するパターンです。トップの水平ステップインジケーターはここで機能します（専用ウィザードフロー）。見積詳細レベルで間違っているところ――ユーザーは本当に各ステップを順序通りに1つずつ、次に移る前に行うので。

使用場面：

• 8+属性
• 構成が視覚的要素を含む（図表、寸法、写真、カラースウォッチ、レイアウトプレビュー）
• 構成に30秒以上かかる――専用フォーカス表面に値します
• 構成結果は「確認してから確定」ステップに値するほど有意

パターンCに適合する例：数十のキャビネット、表面、電化製品、仕上げの決定があるカスタムキッチン。フレーム、ドライブトレーン、ホイール、ブレーキ、アクセサリー、色で構成可能な自転車。モジュール、ユーザーティア、統合、サポートレベル、契約期間があるエンタープライズソフトウェア契約。基材、寸法、構造設計、印刷、仕上げ、数量、配送があるカスタムパッケージング注文。

パターンの選択

製品が2～4個の独立属性を持つ、カスケードなし：
  → パターンA：インライン拡張可能な行

製品が4～7個の属性を持つ、カスケード依存性、構成に<30秒：
  → パターンB：垂直ステッパー付きサイドドロワー

製品が8+個の属性を持つ、視覚/図表コンポーネント、30秒以上：
  → パターンC：水平ステップインジケーター付きフルページコンフィギュレーター

不確実な場合：
  → シンプル見た目製品についてパターンA
  → オプション付き産業機器、サービスについてパターンB
  → パターンC は本当に複雑なコンフィギュレーター用に予約

カスケード依存性ルール

パターンBとCの場合、構成がカスケードするとき：

1. 下流ステップを無効として表示 上流選択が行われるまで。ユーザーが上流ステップ2が空の場合、ステップ4をクリックできないようにしないでください。
2. 上流選択が変更されたとき、下流選択をクリアして確認を表示：「容量を5トンから10トンに変更すると、モーターとホイスト選択がリセットされます。続行？」
3. 各ステップでルール根拠を表示：「利用可能なモーターは、あなたの5トン容量選択に基づいてフィルタリングされています（BR-007）。」フィルタリングルールを見えるようにしてください。
4. 1つのオプションのみ存在するとき自動選択：カスケードが1つの有効な選択に絞られた場合、それを事前選択して注記：「（以前の選択に基づいて唯一の利用可能なオプション）。」

これはカスケードを知的に感じさせ、混乱させません。Excelから来た顧客は多くの場合これらのルールを頭に持っています――「より大きなサイズなら、基本コンポーネントは使用できない」「プレミアムサービスティアなら、埋め込みサポートは含まれる」「食品安全基材なら、水性インクのみ適用される」――そしてルールを明示的に表示することは静かに強制することより比較的に印象的です。

ライン項目の構成サマリー

コンフィギュレーターがコミット後（ドロワー保存、フルページ確認）、ライン項目は構成セクション列にアセンブルされた構成を表示します。3～4深い構成の場合、これは長くなる可能性があります：

[産業機器例]
産業リフト――5トン、40フィトスパン
└─ 標準モーター、タイプ2ホイスト、480V制御、フェストゥーン システム

[カスタムアパレル例]
プレミアムフーディー――トリブレンド、M-XL実行
└─ DTGプリント、4色前面、袖刺繍、ポリバッグ

[ITサービス例]
マネージドサービス――プレミアムティア、50ユーザー
└─ セキュリティモジュール、バックアップモジュール、4時間SLA、Slack統合

この例を簡潔なサマリーテキストとして表示し、「構成を編集」リンク付きでコンフィギュレーターを再開します。行項目テーブルに2～3個以上の属性として各属性を適合させようとしないでください。スケーリングしません。

リファレンス実装パターン:

<table>
  <thead>
    <tr>
      <th>#</th>
      <th>説明</th>
      <th>構成</th>
      <th>数量</th>
      <th className="text-right">定価</th>
      <th className="text-right">割引</th>
      <th className="text-right">正味価格</th>
      <th className="text-right">ライン合計</th>
      <th></th>
    </tr>
  </thead>
  <tbody>
    {lineItems.map((item, i) => (
      <tr key={item.id}>
        <td>{i + 1}</td>
        <td>
          <ProductPicker value={item.productId} onChange={(p) => updateItem(item.id, { productId: p })} />
        </td>
        <td>
          <ConfigurationCell item={item} onChange={(config) => updateItem(item.id, { configuration: config })} />
          {item.requiredRules.map(rule => (
            <RuleIndicator key={rule.id} rule={rule} satisfied={item.satisfiedRules.includes(rule.id)} />
          ))}
        </td>
        <td>
          <Input type="number" value={item.qty} onChange={(e) => updateItem(item.id, { qty: e.target.value })} />
        </td>
        <td className="text-right">{formatCurrency(item.listPrice)}</td>
        <td className="text-right">
          <DiscountCell item={item} onChange={(d) => updateItem(item.id, { discount: d })} />
        </td>
        <td className="text-right">{formatCurrency(item.netPrice)}</td>
        <td className="text-right font-medium">{formatCurrency(item.lineTotal)}</td>
        <td>
          <RowActions onClone={() => cloneItem(item.id)} onRemove={() => removeItem(item.id)} />
        </td>
      </tr>
    ))}
  </tbody>
  <tfoot>
    <tr><td colSpan={7} className="text-right">小計:</td><td className="text-right">{formatCurrency(subtotal)}</td><td /></tr>
    {discountRows.map(d => (
      <tr key={d.id}><td colSpan={7} className="text-right text-muted-foreground">{d.label}:</td><td className="text-right">-{formatCurrency(d.amount)}</td><td /></tr>
    ))}
    {taxRate > 0 && (
      <tr><td colSpan={7} className="text-right">{taxName} ({taxRate}%):</td><td className="text-right">{formatCurrency(taxAmount)}</td><td /></tr>
    )}
    <tr className="font-bold text-lg"><td colSpan={7} className="text-right">合計:</td><td className="text-right">{formatCurrency(grandTotal)} {currency}</td><td /></tr>
  </tfoot>
</table>

<Button onClick={addNewLine}>+ ラインを追加</Button>

顧客情報、支払いターム、有効期日、およびメモは、ライン項目テーブルの下のセクション――同じページ上――として表示されます。別個のルートまたはステップではなく。

---

割引スタックパターン（割引が適用される場合のティア1必須）

DOMAIN.mdが任意の形式の割引（ボリューム、プロモーション、手動、交渉）について言及する場合、ビルドは割引を層状の透明計算として表示する必要があります。

必須可視数学：

定価（5 × $15,000）:      $75,000.00
─────────────────────────────────────
ボリューム割引（5%）:         -$3,750.00
プロモーション割引（3%）:     -$2,137.50
手動割引（$1,000）:          -$1,000.00
─────────────────────────────────────
正味価格:                  $68,112.50
HST（13%）:                $8,854.63
─────────────────────────────────────
合計:                      $76,967.13 CAD

必須動作：

• 各割引は合計スタックの別の行です
• 各行は以下を表示します：割引タイプ、パーセンテージまたは金額、削除されたドル額
• 割引は積層順序で適用します（ボリューム→プロモーション→手動）
• 手動割引はDOMAIN.mdの閾値を超える場合、承認ルーティングをトリガーします
• ユーザーは何が削除されたかとなぜかを見ます。フォーミュラに何も隠されていません。

割引承認閾値：

DOMAIN.mdが割引承認ルールを説明する場合（「15%を超える割引はマネージャー承認が必要」）、プロトタイプはそれらを強制します：

• 閾値下の割引→ユーザーは承認なしに適用できます
• 閾値で/超える割引→ユーザーは適用できますが見積は「承認待ち」ステータスに入ります
• 承認ルーティングはその割引レベルで承認を受ける権限のあるロールにルーティングします

これはSMB企業から「マージンを失う」という最も一般的な不満です。UIでルールを表示することは高価値です。

---

マルチティア承認チェーンパターン（ティア1必須）

ほとんどのSMB CPQワークフローは2つ以上の承認レベルを持っています。プロトタイプはこれを反映する必要があります。

承認チェーン定義

DOMAIN.mdはステークホルダーマップで承認者を説明します。プロトタイプはこのマップからチェーンを導き出します：

• 単一承認者 → シンプルゲート（「[オーナー]からの承認待ち」）
• 順序付き承認者 → チェーン（「[営業マネージャー]から承認、次に[オーナー]」）
• 条件付き承認者 → 見積属性に基づくルーティング（「標準構成について