翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# マルチバリアント機能フラグルールについて
<a name="appconfig-creating-multi-variant-feature-flags-rules"></a>

機能フラグバリアントを作成するときは、そのバリアントのルールを指定します。ルールは、コンテキスト値を入力として受け取り、ブール値を出力として生成する式です。例えば、アカウント ID で識別されるベータユーザーのフラグバリアントを選択するルールを定義して、ユーザーインターフェイスの更新をテストできます。このシナリオでは、次の操作を行います。

1. *UI Refresh* という新しい機能フラグ設定プロファイルを作成します。

1. *ui\_refresh* という新しい機能フラグを作成します。

1. バリアントを追加するには、作成後に機能フラグを編集します。

1. *BetaUsers* という新しいバリアントを作成して有効にします。

1. リクエストコンテキストのアカウント ID が、新しいベータエクスペリエンスの表示が承認されたアカウント ID のリストにある場合にバリアントを選択する *BetaUsers* のルールを定義します。

1. デフォルトのバリアントのステータスが **[無効]** に設定されていることを確認します。

**注記**  
バリアントは、コンソールで定義されている順序に基づいて順序付きリストとして評価されます。リストの先頭にあるバリアントが最初に評価されます。指定されたコンテキストに一致するルールがない場合、 はデフォルトのバリアント AWS AppConfig を返します。

が機能フラグリクエスト AWS AppConfig を処理すると、AccountID (この例の場合) を含む指定されたコンテキストが最初に BetaUsers バリアントと比較されます。コンテキストが BetaUsers のルールと一致する場合、 はベータエクスペリエンスの設定データを AWS AppConfig 返します。コンテキストにアカウント ID が含まれていない場合、またはアカウント ID が 123 以外にある場合、 はデフォルトルールの設定データを AWS AppConfig 返します。つまり、ユーザーは本番環境で現在のエクスペリエンスを表示します。

**注記**  
マルチバリアント機能フラグの取得については、「[基本およびマルチバリアント機能フラグの取得](appconfig-integration-retrieving-feature-flags.md)」を参照してください。

## split 演算子について
<a name="appconfig-creating-multi-variant-feature-flags-rules-operators-split"></a>

次のセクションでは、さまざまなシナリオで使用した場合の `split` 演算子の動作について説明します。`split` は、指定されたコンテキスト値の一貫したハッシュに基づいて、トラフィックの特定の割合に対して `true` と評価します。これをよりよく理解するには、2 つのバリアントで分割を使用する次のベースラインシナリオを検討してください。

```
A: (split by::$uniqueId pct::20)
C: <no rule>
```

予想どおり、ランダムな一連の `uniqueId` 値を指定すると、次のようなディストリビューションが生成されます。

```
A: 20%
C: 80%
```

3 つ目のバリアントを追加しつつ、次のように同じ分割割合を使用する場合:

```
A: (split by::$uniqueId pct::20)
B: (split by::$uniqueId pct::20)
C: <default>
```

最終的に、次のディストリビューションになります。

```
A: 20%
B: 0%
C: 80%
```

この予期しないディストリビューションが発生する可能性があるのは、各バリアントルールが順番に評価され、最初の一致によって返されるバリアントが決定されるためです。ルール A が評価されると、`uniqueId` 値の 20% がそれと一致するため、最初のバリアントが返されます。次に、ルール B が評価されます。ただし、2 番目の分割ステートメントに一致するすべての `uniqueId` 値はバリアントルール A によって既に一致しているため、B に一致する値はありません。代わりにデフォルトのバリアントが返されます。

次に、3 番目の例を考えてみましょう。

```
A: (split by::$uniqueId pct::20)
B: (split by::$uniqueId pct::25)
C: <default>
```

前の例と同様に、`uniqueId` 値の最初の 20% はルール A と一致します。バリアントルール B の場合、すべての `uniqueId` 値の 25% は一致しますが、その大半は既にルール A と一致しています。これにより、全体の 5% がバリアント B で、残りはバリアント C を受け取ります。ディストリビューションは次のようになります。

```
A: 20%
B: 5%
C: 75%
```

**`seed` プロパティの使用**  
`seed` プロパティを使用すると、split 演算子が使用されている場所に関係なく、特定のコンテキスト値に対してトラフィックが一貫して分割されるようにできます。`seed` を指定しない場合、ハッシュは*ローカル*で一貫しており、そのフラグに対してトラフィックは一貫して分割されますが、同じコンテキスト値を受け取る他のフラグはトラフィックを異なる方法で分割する可能性があります。`seed` が指定されている場合、各一意の値によって、機能フラグ、設定プロファイル、および AWS アカウント間でトラフィックが一貫して分割されることが保証されます。

通常、お客様は、同じコンテキストプロパティでトラフィックを分割する場合、フラグ内のバリアント間で同じ `seed` 値を使用します。ただし、別の seed 値を使用することが適切な場合もあります。ルール A と B に異なる seed を使用する例を次に示します。

```
A: (split by::$uniqueId pct::20 seed::"seed_one")
B: (split by::$uniqueId pct::25 seed::"seed_two")
C: <default>
```

以前と同様に、一致する `uniqueId` 値の 20% がルール A に一致します。つまり、値の 80% がフォールスルーされ、バリアントルール B に対してテストされます。seed が異なるため、A に一致する値と B に一致する値の間に相関はありません。ただし、分割対象となる `uniqueId` 値の数は全体の 80% に限られ、そのうちの 25% がルール B に一致し、75% は一致しません。これは次のディストリビューションに当てはまります。

```
A: 20%
B: 20% (25% of what falls through from A, or 25% of 80%) 
C: 60%
```