---
title: "カスタム条件作成のベストプラクティス"
slug: "best-practices-for-creating-custom-conditions"
abstract: "実験や体験のためにオーディエンスをフィルタリングするためのカスタム条件を作成するベストプラクティスを説明します。"
---
# カスタム条件作成のベストプラクティス

カスタム条件を作成し、複数の条件で使用する際には、以下のベストプラクティスに従うことをお勧めします。

-   **即時呼び出し関数式(IIFE)を使い** 、IIFE内に条件ロジックをカプセル化します。IIFEを使って条件ロジックのローカルスコープを作成することで、変数や関数が誤ってグローバルに露出するのを防ぎ、条件間の競合リスクを減らします。ベストプラクティスを強制するために、すべての条件ロジックがIIFE内に書かれていることを検証します。論理がIIFEにカプセル化されていない場合、保存できません。例えば:
    
    (function() {
     const conditionValue = getConditionValue();
     return conditionValue > 10;
    })();
    
    これにより、すべての条件実装間で一貫性とモジュール性が保証されます。
    
    IIFEを使用する利点は、グローバルな名前空間の汚染を防ぎ、状態ロジックを安全かつ孤立した範囲で即時実行できること、そしてコードをよりモジュール化しデバッグしやすくすることです。
    
-   **可能な限りローカル変数を使用し** 、変数をグローバルではなく関数内でローカルに宣言することで、条件間の変数衝突を防ぎます。これにより、条件間の意図しない上書きや干渉のリスクが減ります。例えば:
    
    (function() {
     let conditionA\_value = getValue();
     // Logic using conditionA\_value
     return conditionA\_value > 0;
    })();
    
-   **条件内でグローバル変数の使用を避けましょう** 。 [特に複数の条件](urn:resource:component:1545761/section-idm234749047534149)を組み合わせる場合は、グローバル変数に頼らないでください。関数パラメータやローカルスコープ変数を使い、分離性と明瞭さを保ちましょう。
    
-   **プレフィックス変数名** - 特定の条件に関連する変数名や関数名に固有のプレフィックスを追加します。例えば、conditionA\_ やconditionB\_ を使って、条件間で似た変数を区別します。これによりコードが読みやすくなり、名前の衝突を避けられます。
    
-   **グローバルオブジェクトの変更は避けてください** 。 window、document、Object.prototypeなどのグローバルオブジェクトを修正または拡張しないでください。これらのオブジェクトの変更は同じ環境で動作する他のJavaScriptに影響を与え、スクリプト間の互換性や安定性を低下させる可能性があります。
    
-   **名前空間共有関数** - 名前空間オブジェクト内に再利用可能な関数をカプセル化する。例えばmyConditionUtils。これにより名前の衝突を防ぎ、共有ロジックを整理しアクセスしやすく保ちます。例えば:
    
    const myConditionUtils = {
     isValid: function(value) {
     return value !== null && value !== undefined;
     },
     parseValue: function(value) {
     return parseInt(value, 10);
     }
    };
    
-   **Minimize dependencies** - 条件付きで外部ライブラリやリソースの使用を制限すること。依存関係は特に複数回読み込まれたり互換性のないバージョンで書かれている場合、競合を引き起こすことがあります。可能な限りコードを自己完結型に保つことを目指しましょう。
    
-   **return文を明示的に定義し、**各条件のJavaScriptコードが異なるキーと値を持つオブジェクトを返すことを確実にしてください。条件間で共有することを明示的に意図していない限り、同一のキーの使用は避けてください。
    
-   **返事型の一貫性を確保する** - 複数の条件を組み合わせる際は、すべての条件が一貫してtrueまたはfalse結果を返すことを確実にしてください。データ型が混在すると予測不能な挙動が起き、デバッグが難しくなります。同様に、値を返す複数の条件を組み合わせて判断しないようにしましょう。これは予測不能な結果につながる可能性があります。
    
-   **[各条件を個別にテスト](https://doc.sitecore.com/personalize/ja/users/sitecore-personalize/developer-center/conditions/test-a-condition/test-a-condition.html "Test a condition")** し、個々の条件の機能を検証してから大きなロジックに統合しましょう。これにより問題を特定し、各条件が期待通りに動作することを確認できます。
    
-   **ドキュメント条件ロジック** - 各条件の目的と機能を文書化します。コメントやドキュメントは、複数の開発者が関わるプロジェクトで特に有効です。例えば:
    
    (function() {
     // This condition checks if the user's age is above 18.
     var userAge = getUserAge();
     return userAge > 18;
    })();
    

> !注カスタム条件で利用可能な顧客データの量は、データ保持の制限の対象となります。Sitecore CDPなしでPersonalizeを使用する場合、直近20件の注文と直近40セッション(90日以内)までアクセス可能です。CDPは、特定されたゲストに対して最大100件の注文と1,000回のセッションまでアクセスを延長します。詳細については、「[Sitecore CDPにおける](https://doc.sitecore.com/cdp/en/users/sitecore-cdp/en/data-availability-in-sitecore-cdp.html)データ制限とデータの可用性[の理解](https://doc.sitecore.com/personalize/ja/users/sitecore-personalize/developer-center/conditions/understanding-data-limits-in-decisioning-and-conditions.html "Understanding data limits in decisioning and conditions")」をご覧ください。