ClassLab環境独自の禁止コーディングルール
CX項目の作成禁止
結論
CX項目を 「入居トリガーでのみ作成する」 ルールに統一し、それ以外のクラス・バッチ・WebService等からの CX項目作成（insert）を 禁止 する。
👉 入居作成経路ごとに CX項目の作成タイミング／内容がズレることで、初回SMSや発信番号などの参照データが不整合になる根本原因を断つため
ルール
| 項目 | 内容 |
|---|---|
| 禁止対象 | CXFields__c の insert（新規作成） |
| 許可される作成元 | 入居トリガーのみ |
| 禁止される作成元 | バッチ、WebService、Managerクラス、API、テストクラス等 |
✅ CX項目の作成は 入居トリガーに一元化 してください。
背景（今回の事象）
スマサポ販路（川商ハウス）で 「0120で発信しているのに、初回SMSに050番号が記載される」 という不整合が発生。
応急対応
- 初回SMS送信制御を「1時間遅延」に設定
- 結果として、0120番号の反映は確認できた
⚠️ ただしこれは 一時的な回避策 に過ぎず、根本原因は未解決
問題の本質
CX項目（CXFields__c）の「作成経路」が複数存在している
現在の実装では、CXFields__c が以下のような 複数の処理から作成 されています。
| 作成元 |
|---|
| 入居トリガー |
| sumasapoImportBatch |
| MailFormWebService |
| CallManagement |
| CXFieldsManager |
| その他バッチ・API・テストクラス |
➡ どの処理から作成されたかによって、以下が異なってしまう状態：
- 作成タイミング
- 初期値の入り方
- 発信番号（FirstCallPhoneNumber__c）の確定タイミング
初回SMSは CX項目を参照しており、タイミング差に弱い
初回SMSの電話番号は CXFields__c.FirstCallPhoneNumber__c を参照している。
しかし：
- CX項目が 「未完成の状態」で作られる
- もしくは 「後から上書きされる」
その結果、SMS生成時点では古い番号（050）が参照される ケースが発生。