製造業CPQ導入｜個別受注の見積から製造までつなぐRFP

製造業 CPQ 導入で本当に解決すべき課題は、見積書を速く作ることだけではありません。個別受注や多品種変量生産では、営業が選んだ仕様、技術部門が認めた組み合わせ、原価・価格の前提、顧客へ約束した納期条件を、受注後のBOM、工程、製造指示まで同じ意味で引き継げるかが成否を決めます。画面上では正しい見積でも、製造側が再解釈しなければ動かないなら、ミスと手戻りの入口がデジタル化されただけです。

本稿は、タイ・ASEANで受注生産を行う機械、装置、電機、部品、産業材メーカーの責任者に向け、CPQ（Configure, Price, Quote）の対象範囲、コンフィグレーターのルール、バリアントBOM・ルーティング連携、承認と監査、RFP、90日PoC、受入ゲートを実務の順序で整理します。製品ランキングではなく、どの候補にも同じ質問を行い、同じ証拠で判定するための発注ガイドです。

結論：製造業CPQ導入では「実行可能な構成契約」を作る

CPQの成果を一文で定義するなら、次のようになります。

顧客要求から選ばれた製品構成、適用したルール、価格・原価・納期の前提、承認、構成版を凍結し、受注後のERP・PLM・MESが再解釈せず利用できる構成契約を作る仕組み。

ここでいう契約は法的文書という意味だけではありません。営業、設計、生産技術、調達、工場が同じ構成IDと版を参照し、「何を、どの条件で、どう作るか」を追跡できるデータの約束です。顧客向けPDFはその一つの表示結果にすぎません。

導入前に、少なくとも次の五つを固定します。

1. 構成ルールの正本をCPQ、PLM、ERPのどこに置くか。
2. 見積時点の構成を一意に示す構成ID、版、有効日をどう持つか。
3. 選択仕様をバリアントBOM、工程、購買品、検査条件へどう変換するか。
4. 価格、原価、値引、納期回答を誰が計算し、誰が承認するか。
5. 受注後の変更、失注、再見積、設計変更をどの履歴として残すか。

この五つが曖昧なまま「見積作成時間を短くしたい」と始めると、営業画面は整っても、設計確認のメール、Excelの仕様表、ERPへの手入力が残ります。CPQ導入は見積画面の刷新ではなく、Quote-to-Orderの意思決定をデータとしてつなぐ業務設計です。

CPQシステムを製造業でどう定義するか

CPQはConfigure、Price、Quoteの略です。しかし製造業では三つを別々に理解すると不十分です。

• Configure：属性、選択肢、制約、計算、依存関係を使い、製造可能で販売可能な構成を確定する。
• Price：品目価格だけでなく、オプション、数量、顧客条件、地域、通貨、サービス、値引、必要に応じて原価・粗利の前提を反映する。
• Quote：構成と価格を、版、承認状態、条件、有効期限、添付仕様とともに顧客へ提示できる形にする。

Microsoftの製品構成モデルの公式資料では、属性、制約、計算、BOM行、ルート工程をモデル要素として扱い、構成された製品バリアントに固有のBOMとルートを持たせられる例が示されています。OracleのConfigure-to-Order資料でも、モデル、オプションクラス、実行時に選ぶオプションを使い、選択結果に応じた製造の作業定義を作る考え方が示されています。重要なのは特定製品の機能ではなく、営業の選択が製造可能性と切り離されていない点です。

ただし、すべてのCPQが自動的に製造用BOMや工程を生成するわけではありません。CPQは販売構成を持ち、PLMが設計BOMを持ち、ERPが製造BOMと工程を持つ構成もあります。逆に、ERPのバリアント構成エンジンをCPQから呼ぶ構成もあります。RFPで求めるべきなのは製品名ではなく、「どのシステムがどのルールと成果物の正本か」です。

CPQが担う範囲と担わない範囲を先に線引きする

境界表は機能の押し付け合いを防ぎます。「ERP連携あり」ではなく、作成、変更、承認、失効、再送、照合までをデータ単位で決めます。一般的なAPI設計の詳細は製造業API連携開発の発注ガイドを参照し、本稿ではCPQ固有の構成意味と版管理に集中します。

個別受注の見積自動化で最初にモデル化するもの

CPQ導入チームが最初に行う仕事は、現行見積書をそのまま画面へ移すことではありません。「営業が尋ねる質問」「技術が判断するルール」「製造へ渡す成果物」を分解します。

顧客の言葉を製品属性へ変換する

顧客は「高温で使いたい」「洗浄しやすい」「既設ラインへ入る」「この処理量を満たしたい」と話します。一方、製品側は材質、電源、能力、寸法、保護等級、接続規格、制御方式、検査、ドキュメント言語といった属性で判断します。質問を単なる自由記述にせず、次の三層へ分けます。

1. 用途・環境：処理対象、温度、湿度、粉じん、洗浄、危険区域、設置国。
2. 必要能力：処理量、精度、速度、荷重、可動範囲、稼働時間。
3. 実装条件：電源、エア、通信、設置寸法、搬入制約、上位連携、言語。

入力値は単位を持たせます。「100」という数字だけではなく、100 kg/hなのか100 pieces/minなのかを固定します。表示言語が日本語、英語、タイ語、ベトナム語で変わっても、属性ID、単位、列挙値IDは共通にします。翻訳文をシステム間キーにしてはいけません。

ハード制約、ソフト制約、計算を区別する

ルールには性質があります。

• ハード制約：物理、安全、法令、必須インターフェースなど、違反構成を確定させない。
• ソフト制約：推奨、標準、利益、在庫、納期など、例外承認により進められる。
• 派生計算：入力から容量、数量、寸法、工数、価格要素などを求める。
• 完全性ルール：必須質問、添付図面、顧客確認事項がそろうまで提出できない。

すべてを禁止ルールにすると、例外案件がシステム外へ逃げます。すべてを警告にすると、CPQはチェックリストにしかなりません。例外可能なルールには、理由、承認者、期限、影響するBOM・工程、再利用可否を持たせます。

ルールごとに根拠とOwnerを持つ

「このモーターならこのインバータ」という条件だけでは保守できません。ルールID、説明、条件式、結果、根拠文書、製品ファミリー、適用地域、有効開始・終了、作成者、技術承認者、テストケースを一組にします。

営業担当者の経験則を取り込む場合も、口頭で正しいとされてきた内容をそのまま実装しません。設計標準、過去不具合、原価条件、供給制約と照合し、誰が将来の変更を承認するかを決めます。CPQは暗黙知を可視化しますが、暗黙知の正しさまでは自動で保証しません。

コンフィグレーターとバリアントBOM・ルーティングをつなぐ

製造業CPQで最も重要な受入シナリオは、「見積書が出た」ではなく「同じ構成から製造側の成果物が再現できた」です。

構成スナップショットを注文の基準にする

顧客へ提示した時点で、次を一つのスナップショットとして凍結します。

• 案件ID、見積ID、見積改訂番号。
• 構成ID、構成モデル版、ルール版。
• すべての入力、選択、派生値、除外・例外。
• 価格表版、通貨、為替の扱い、値引、原価参照時点。
• 約束した仕様、数量、納期条件、保証・サービス。
• 技術、営業、財務などの承認状態と日時。
• 生成した見積書、仕様書、関連図面の版。

Microsoftの営業取引資料は、見積をDraft、Active、Revisedなどの状態で管理し、改訂IDを持たせる例を示しています。RFPでは製品用語に依存せず、「顧客に送った版が後から価格表やルール更新で変わらない」「改訂すると新旧差分が追える」という振る舞いを要求します。

販売構成から製造構成への変換表を作る

営業のオプションと部品を一対一に直結できるとは限りません。一つの販売選択が複数部品、追加工、検査、文書を呼び出すことがあります。反対に、複数の顧客選択を組み合わせて一つのサブアセンブリを決める場合もあります。

BOM行だけでなく、工程・リソース・検査も確認します。Oracleの公式資料は、選択したオプションや属性から構成品の作業定義を動的に作る例を説明しています。これはすべての環境で同じ機能を採用すべきという意味ではなく、CPQの受入が部品表だけで終わってはいけないことを示します。

「構成済みだが製造不能」を防ぐ五つの検査

1. 完全性：必須属性、添付、顧客回答がそろっている。
2. 整合性：互いに排他的な選択、能力不足、規格不一致がない。
3. マスタ存在：必要な品目、工程、設備、仕入先、文書が対象工場に存在する。
4. 版の有効性：受注予定日・製造予定日に使える版と有効日になっている。
5. 実行可能性：長納期品、能力、特注設計、試験設備を含む条件を明示した。

CPQが製造可能性を単独で計算しない場合は、ERP、PLM、計画、MESから検査結果を受け取ります。応答不能時に「警告して続行」「見積保存のみ許可」「提出禁止」のどれにするかも決めます。連携停止時に古い値で顧客へ約束することが最も危険です。

ERP・MES・CRM・PLM連携で決めるデータ責任

CPQは複数システムの中央に置かれやすいため、接続数よりデータ責任が重要です。

CRMから受け取り、CRMへ返すもの

CRMは顧客、案件、担当、活動、確度の正本になりやすい一方、構成ルールの正本とは限りません。CPQは案件IDを受け取り、見積番号、構成状態、総額、粗利区分、承認状態、期限、PDFリンクを返します。二重作成を防ぐ一意キーと、案件統合・複製時の扱いを定義します。

PLMとの境界

PLMが製品構成と設計変更を管理する場合、CPQは承認済みの販売可能ビューを使います。開発中部品や未承認ルールを営業へ公開しない制御が必要です。特注案件では、CPQから設計タスクを起票し、PLMで承認された結果を構成版へ戻します。特注結果を標準オプションへ昇格させる判断も別の変更プロセスにします。

Siemensの製品構成資料は、部門横断で共通のバリアント管理基盤を持つ考え方を示しています。採用製品にかかわらず、営業と設計が別々の選択肢名、ルール、版を持たないことが本質です。

ERPとの境界

ERPは品目、顧客条件、価格、在庫、購買、原価、受注、生産の正本となる場合があります。SAPのCPQ連携資料は、バックエンドの製品データや構成・価格サービスを使い、構成可能な見積について見積データと構成データをS/4HANAへ渡す例を示しています。ここから学ぶべきことは、「CPQ内で同じマスタを再構築すればよい」のではなく、既存の構成知識をどこで保守し、どの版を呼んだかを残す必要があることです。

インターフェースには、正常系だけでなく次を含めます。

• 新規、改訂、取消、再開、失注、受注化。
• 同じ要求の再送に対する冪等性。
• 古い構成版や価格版を拒否する競合検知。
• 部分失敗時の再処理と照合。
• 単位、通貨、税、端数、タイムゾーン。
• 人が補正した場合の理由、権限、監査記録。

MESへの引継ぎ

通常、CPQから設備へ直接指示を送る設計は避け、ERP・PLMが受注と製造定義を確定し、MESが現場実行へ展開します。CPQ由来の顧客仕様がMESの作業指示、検査、トレーサビリティへ必要なら、構成IDと要求IDを製造指示へ残します。作業者が自由記述の仕様PDFを読み解くのではなく、対象工程で必要な値と文書が表示される状態を受入条件にします。

受注生産全体の計画・進捗・変更管理は個別受注生産の生産管理ガイドと合わせて設計すると、CPQの終点と生産管理の始点を明確にできます。

承認・監査を「値引承認」だけにしない

CPQの承認は、価格だけでなく技術と約束のリスクを制御します。

承認マトリクスを四つに分ける

金額の閾値だけでなく、ルール例外、粗利帯、納期、地域、製品ファミリー、契約条件を組み合わせます。承認者本人が起票した案件を自己承認できるか、代理承認、期限超過、差戻し、再申請、承認後変更をどう扱うかを決めます。Microsoftのワークフロー資料には、承認、拒否、変更要求、委任、最終承認者、起票者の自己承認禁止といった構成例があります。RFPでは製品名ではなく必要な統制動作として書きます。

監査ログで残すべき内容

• 誰がいつ何を変更したか、変更前後の値。
• どのルール版、価格版、原価時点を使ったか。
• 自動計算と手動上書きの区別、上書き理由。
• どの承認条件が発火し、誰がどの根拠で判断したか。
• 顧客へ送った文書と構成スナップショットの対応。
• 受注化した見積版と、その後の変更依頼。

「最新値だけが見える」ログでは監査になりません。業務担当者が検索・出力でき、保管期間、個人情報、アクセス権、削除手順も定義します。

製造業CPQ導入のRFPに入れる15項目

1. 対象製品ファミリーと除外範囲

売上規模ではなく、オプション数、ルール複雑度、特注率、BOM・工程への影響、利用地域で範囲を表します。PoC対象外も明記します。

2. As-IsとTo-Beの業務シナリオ

新規見積だけでなく、複製、改訂、顧客変更、失注復活、受注後変更、標準化候補の昇格まで記述します。

3. 属性・用語・単位辞書

属性ID、表示名、型、単位、列挙値、翻訳、Owner、参照先を提出物にします。日本語、英語、タイ語の表示が違ってもIDは変えません。

4. ルール管理

ルール種別、版、有効日、根拠、作成・レビュー・承認・公開・失効、テスト、影響分析を要求します。

5. 構成セッション

途中保存、共同編集、排他、コピー、比較、差分、期限、モデル版更新時の再評価を定義します。

6. 価格・原価・粗利

正本、更新頻度、通貨、税、端数、工場、数量、サービス、値引、手動上書き、エラー時の停止条件を書きます。

7. 納期回答

固定リードタイム、品目LT、在庫、能力、外注、設計工数をどこまで使うかを区別します。「納期計算対応」だけでは比較できません。

8. 文書生成

見積、仕様、条件、図面、承認情報、言語、テンプレート版、再生成、電子署名への引継ぎを確認します。

9. バリアントBOM・ルーティング

販売選択から部品、数量、工程、検査、文書、特注タスクへの対応と、未マッピング時の停止を要求します。

10. ERP・PLM・CRM・MES連携

各メッセージの方向、タイミング、一意キー、版、再送、競合、照合、監視、手動復旧、Ownerを記載させます。

11. 承認と職務分離

商務・技術・供給・リスクの条件、代理、期限、エスカレーション、自己承認、承認後変更をシナリオ化します。

12. 権限とセキュリティ

役割、拠点、製品、顧客別アクセス、SSO、管理者操作、API資格情報、バックアップ、ログ、退職者処理を含めます。

13. 性能と可用性

代表構成でのルール評価、文書生成、同時利用、外部応答待ち、タイムアウト、縮退運転を測定条件付きで定義します。

14. 移行と品質保証

Excelや旧システムから何を移し、ルール同値性をどう検証するか、Golden Configurationと回帰テストをどう保守するかを要求します。

15. 運用移管と終了

編集可能なモデル、設定、コード、API仕様、テスト、教材、ライセンス、データ抽出、後継移行、サポート終了時の条件を契約に入れます。

CPQ RFPを比較可能にする回答表

ベンダーへ「標準対応」「カスタマイズ」「連携対応」の三択だけで答えさせると、同じ丸印でも意味が違います。各要件に次の列を持たせます。

製品デモは営業用の成功シナリオではなく、発注者が用意した代表構成で行います。必須オプション欠落、禁止組合せ、旧版、価格サービス停止、承認差戻し、BOM未登録、二重送信も実演対象にします。

90日PoC：一つの製品ファミリーで端から端まで証明する

以下はTOMAS TECHの計画例であり、すべての会社に90日で本番展開を保証するものではありません。対象を一製品ファミリー、代表的な構成、限定した連携に絞り、Go/No-Goの証拠を作るためのPoCです。

PoC対象の選び方

簡単すぎる製品は本番リスクを隠し、最難関製品は基盤評価を特注設計で埋めます。標準オプション、依存ルール、価格差、承認、BOM・工程差、少数の例外を含む中程度の製品ファミリーを選びます。営業量が多く、技術確認の手戻りが見えるものが適しています。

PoCへ本物のマスタを持ち込めない場合、匿名化しても構造、階層、単位、欠損、版の特徴を残します。きれいなサンプルデータだけで合格させません。

受入ゲート：機能一覧ではなく業務証拠で判定する

Gate 1：構成品質

• 必須条件が欠けた構成を提出できない。
• 禁止組合せを理由付きで止められる。
• 推奨外の例外は、理由と承認がなければ確定できない。
• 同じ入力と同じモデル版から同じ結果を再生成できる。
• 旧版で作った見積を開いたとき、無断で新版へ置換しない。

Gate 2：価格・納期の統制

• 価格、原価、通貨、数量、税・端数の前提を追える。
• 手動上書きに権限、理由、差分、承認が残る。
• 外部価格や納期回答が失敗したとき、古い値を正常値として扱わない。
• 顧客へ送った版が後日のマスタ更新で変化しない。

Gate 3：製造引継ぎ

• 受注化した構成IDと版がERP/PLMへ一度だけ登録される。
• 代表構成のBOM行、数量、工程、検査、文書が期待値と一致する。
• 未登録品目・工程・マッピングを検出し、責任者へ戻せる。
• 変更見積と旧製造指示の競合を検知できる。

Gate 4：承認・監査

• 技術、商務、供給の条件ごとに正しい承認経路が動く。
• 起票者、代理、期限切れ、差戻し、再申請を再現できる。
• 承認後の変更は再承認または明示したルールへ従う。
• 操作、ルール、価格、文書、連携の履歴を一つの案件から追える。

Gate 5：運用可能性

• 顧客側管理者が属性、翻訳、ルール、有効日を管理できる。
• 回帰テストが自動または再現可能な手順で実行できる。
• 障害監視、再送、照合、バックアップ、復旧が実演される。
• 教育、権限申請、問い合わせ、変更要求のOwnerが決まっている。

受入表には、要件ID、前提、操作、期待結果、実結果、証拠リンク、欠陥ID、再試験、承認者を持たせます。「デモで動いた」という議事録は証拠になりません。

タイ工場で追加するローカル要件

多言語は画面翻訳ではなくマスタ運用として設計する

営業が英語、日本本社が日本語、工場がタイ語を使う場合、製品名、属性、オプション、警告、見積条件、作業指示まで言語がまたがります。技術IDを共通にし、翻訳のOwner、レビュー、発効日、未翻訳時の表示を決めます。自由翻訳で仕様意味が変わらないよう、用語集を運用成果物にします。

通貨・税・端数の責任を曖昧にしない

THB、JPY、USDなど複数通貨の案件では、為替の時点と出典、価格表通貨、見積表示通貨、原価通貨、端数処理を分けます。税務判断は現地の専門家と社内財務が行い、CPQプロジェクトが独自解釈しません。システムは承認済みルールを再現し、どのルールを使ったかを残します。

本社ルールと現地供給を両立する

本社標準の構成でも、タイで調達できる部品、認証、リードタイム、サービス体制が異なる場合があります。グローバル共通ルールと、工場・販売地域別の差分を分け、同じルールをコピーして各拠点が独自改変する状態を避けます。

BOI情報は適格性を確認して使う

タイBOIはSmart and Sustainable Industryを含む産業高度化の公式情報を公開しています。ただし、CPQ導入が自動的に恩典対象になるわけではありません。投資計画へ含める場合は、申請時点の公告、対象活動、期限、投資内容をBOIまたは専門家へ確認し、記事情報だけで適格性を判断しないでください。

製造業CPQ導入で起きやすい8つの失敗

1. 見積PDFの自動化で完了する

文書は速くなっても、BOM・工程・受注入力が手作業なら、真のボトルネックは残ります。PoCは受注後の製造引継ぎまで通します。

2. 営業ルールと設計ルールを二重管理する

同じ禁止組合せをCPQとPLMへ別々に実装すると、版のずれが発生します。正本と配信方法を一つずつ決めます。

3. 例外を禁止しすぎる

特注案件がメールとExcelへ逃げます。例外を構造化し、承認、影響、再利用判断を記録します。

4. 価格だけリアルタイム、原価は古いままにする

価格・原価・粗利の時点が異なると、承認の意味が崩れます。値の取得時刻と有効性を表示し、再計算条件を決めます。

5. BOMは出るが工程と検査が出ない

オプション追加で組立、検査、ソフト設定が増えても、部品だけでは製造できません。ルーティング、検査、文書、設計タスクまで受入します。

6. ルール変更の回帰テストがない

一つの条件変更が別の製品構成を壊します。Golden Configurationを持ち、正常、禁止、境界、例外を毎回再実行します。

7. 「APIあり」を統合完了とみなす

APIの存在と、業務上安全な再送・競合・照合は別です。構成ID、版、冪等キー、エラー責任まで試験します。

8. PoCの成功条件を後から決める

デモが華やかでも、判定が主観になります。開始前に受入ゲート、許容欠陥、未決条件、Go/No-Go権限を合意します。

FAQ：CPQシステム導入、費用、ERP連携、PoC

製造業向けCPQとは何ですか？

顧客要求から製造可能な構成を選び、価格と条件を計算し、承認済み見積を作る仕組みです。製造業では、構成結果をBOM、工程、検査、受注へ再利用できることが重要です。

CPQと見積システムの違いは何ですか？

一般の見積システムが品目、数量、単価、文書を中心に扱うのに対し、CPQは選択肢の依存、禁止組合せ、派生値、価格条件を構成ルールとして扱います。ただし製品による範囲差があるため、名称ではなく受入シナリオで比較します。

CPQとERPのどちらに製品ルールを置くべきですか？

一律の正解はありません。既存のバリアント構成、PLM、価格、組織能力を踏まえ、正本を一つ決めます。重要なのは二重管理を避け、CPQがどのルール版を使ったか追跡できることです。

CPQはバリアントBOMを自動生成できますか？

製品や構成によります。CPQ内で条件付きBOMを持つ方式、ERP/PLMの構成エンジンを呼ぶ方式、販売構成を渡して下流でBOMを確定する方式があります。RFPでは部品だけでなく数量、工程、検査、文書まで代表構成で確認します。

CPQ導入費用はどう比較しますか？

ライセンスだけでなく、モデル設計、ルール整備、データ移行、ERP/PLM/CRM連携、文書、多言語、テスト、教育、運用、変更、更新、終了時のデータ抽出を同じ期間と範囲で比較します。価格だけの一般化は避け、対象製品ファミリーと連携本数を固定して見積を取ります。

CPQの90日PoCで何を確認しますか？

一つの代表製品で、要求入力、ルール判定、価格、承認、文書、構成版、受注、BOM・工程引継ぎ、異常処理、監査まで端から端で確認します。全社展開の完成ではなく、方式とデータ品質のGo/No-Go判定が目的です。

CPQ RFPで最初に書くべき要件は何ですか？

対象製品、構成ルールの正本、構成ID・版、下流成果物、承認責任、受入シナリオです。画面一覧から始めると、重要なデータ責任が後回しになります。

特注品が多くてもCPQを使えますか？

完全自由設計と標準構成の境界を分ければ使えます。標準選択、計算可能なパラメトリック仕様、技術承認が必要な例外、個別設計を分類し、個別設計はタスクと成果物で管理します。

生成AIで製品ルールを自動作成すべきですか？

文書から候補ルールやテスト案を抽出する補助は可能ですが、物理、安全、原価、供給を含むルールの承認責任は人と組織に残ります。根拠、Owner、版、回帰テストなしに自動公開しない設計が必要です。

まとめ：見積速度ではなく、受注後に再解釈しないことを契約する

製造業CPQ導入は、営業の入力を速くするだけのプロジェクトではありません。顧客要求、製品ルール、価格、承認、構成版、バリアントBOM、ルーティング、検査、製造指示を一つの追跡可能な流れにし、顧客へ約束した内容を工場が同じ意味で実行できるようにするプロジェクトです。

RFPでは機能名を並べるのではなく、代表構成、例外、改訂、連携停止、承認差戻し、BOM未登録を含む業務シナリオと証拠を要求します。90日PoCでは一つの製品ファミリーを端から端まで通し、構成品質、価格・納期、製造引継ぎ、監査、運用可能性の五つのゲートで判定します。

TOMAS TECHでは、タイ工場・販売拠点を含むCPQ構想の段階から、製品ファミリー選定、ルール棚卸し、RFP回答表、ERP/PLM/MES境界、90日PoC、受入ケースまで整理できます。まだ製品を選んでいない段階でも、お問い合わせページからご相談ください。

参考情報

• Microsoft Learn：Product configuration models overview
• SAP Help Portal：SAP CPQ Integration Guide — Technical Overview
• SAP：S/4HANA Sales Order Integration for Quote 2.0
• Oracle：Overview of Configure-to-Order
• Oracle：How You Create a Configured Item Work Definition
• Microsoft Learn：Manage quote, order, and invoice
• Microsoft Learn：Configure approval processes in a workflow
• Siemens：Teamcenter Product Configurator
• Thailand BOI：Smart and Sustainable Industry guide

注記：90日PoC、RFP項目、受入ゲートはTOMAS TECHの計画例であり、すべての製品・会社に同じ期間や成果を保証するものではありません。法令、税務、BOI適格性、契約条件は、対象国・製品・顧客要件に応じて専門家と確認してください。