高度な設定 - 進入キー無効化
進入キー無効化を使用すると、特定の条件で待機キーと進入キーを選択的に無効化して、訪問者が待機順維持または進入パスで保護されていても再待機しなければならないように保証できます。タイマーベースの無効化では、ユーザー範囲の指定設定を通じて進入キーのみ、または待機キーと進入キーの両方を無効化できます。このガイドでは、無効化メカニズム、使用事例、および構成オプションについて説明します。
概要
進入キー無効化は、特定のビジネス条件で訪問者が新しいキーを受け取り、再待機しなければならないようにキーを強制的に無効化するメカニズムです。無効化対象は、無効化タイプと設定によって異なります：URLベースの無効化は進入キーのみを無効化し、タイマーベースの無効化はユーザー範囲の指定設定に応じて進入キーのみ、または待機キーと進入キーの両方を無効化できます。この機能は、待機順維持および進入パスと一緒に動作して、アクセスパターンに対する細かい制御を提供します。
無効化が必要な理由
待機順維持および進入パスが訪問者が順番を失わないように保護して優れたユーザー体験を提供しますが、再待機を強制する必要があるビジネスシナリオがあります：
- 公平なアクセス制御: 重要な段階ですべての訪問者が再待機するように保証
- 負荷管理: 特定の時間にパスを無効化してサーバー負荷を制御
- URLベースの制限: 異なるサービスエンドポイント間でのパス共有を防止
- イベント段階の移行: 異なるイベント段階に移動するときに再待機を強制
無効化される項目
進入キー無効化は2種類のキーに影響を与えます：
1. 待機キー（待機順に使用）:
- 無効化されるとき: 待機順維持が迂回されます
- 効果: 訪問者が待機順を失い、待機列の最後から開始しなければならない、待機順維持期間と関係なく
- 使用事例: 待機順維持が有効化されていても公平な再待機を強制
2. 進入キー（サービス進入に使用）:
- 無効化されるとき: 高度な設定 - 進入パスが迂回されます
- 効果: 訪問者が待合室を通じて再待機しなければならない、進入パス有効期間と関係なく
- 使用事例: 重要なサービス段階または特定のURLに対して再待機を強制
動作方法
進入キー無効化は、シンプルな原則で動作します：無効化条件が満たされるとキー再発行を強制。これは、訪問者が以前に発行されたキーに依存できず、待合室を再度通過しなければならないことを保証します。
技術的原則
無効化条件を満たすキーは強制的に無効化され、システムが新しいキーを発行します、待機順維持期間または進入パス有効期間と関係なく。無効化対象は、無効化タイプと設定によって異なります：
- URLベースの無効化: 特定のURLにアクセスしたユーザーの進入キーのみが無効化されます
- タイマーベースの無効化: ユーザー範囲の指定設定に応じて異なる動作をします
- 進入済みのユーザーのみ: サービスに進入したユーザーの進入キーのみを無効化（再発行）（待機中のユーザーの待機キーは影響を受けません）
- 待機中のユーザーから: サービスに進入したユーザーの進入キーと待機中のユーザーの待機キーの両方を無効化（再発行）（待機中のユーザーも待機列の最後から再待機）
- 待機キー無効化時: 待機順維持が有効化されており、待機順維持期間と関係なく、接続が切断されてから再接続する訪問者は以前の待機順を失い、最後から開始
- 進入キー無効化時: 進入パスが有効化されており、進入パス有効期間内にいても、無効化条件が満たされると訪問者は進入パス有効期間と関係なく再待機しなければならない
進入キー無効化は2種類の無効化条件を提供します：
1. URLベースの無効化
訪問者が特定のURLにアクセスするときにキーを無効化します。
使用事例例: 選択的アクセス制御がある複数ページイベント
次のようなセグメント化されたイベントがあると仮定します：
- トリガールール:
/event/1、/event/2、/event/3パスが待合室トリガー - 進入パス: 1時間有効期間
- ビジネス要件:
/event/3を除くすべてのイベントページは進入パスを許可するが、/event/3は常に再待機が必要でなければならない
シナリオタイムライン:
午前10:00 訪問者が /event/1 に進入、進入キー受信
→ 進入パスが午前11:00まで1時間有効
午前10:15 訪問者が /event/2 にアクセス
→ 進入パスがまだ有効
→ 待機列なしで直接進入 ✓
午前10:30 訪問者が /event/3 にアクセス
→ URLベースの無効化がトリガー
→ 進入キーが無効化
→ 待合室を再度通過しなければならない ✗
午前10:31 訪問者が待機後、新しい進入キー受信
→ /event/3 にアクセス許可 ✓
構成:
無効化したいサービスパスの完全なURLパス（プロトコルを含む）を入力してください：
https://example.com/event/3
技術的詳細:
- UTI（URLトリガー統合）環境で動作
- 完全なパス一致が必要（プロトコル + ドメイン + パス）
- セグメントごとに1つのURLのみ構成可能
- 基本制御セグメントでのみ使用可能（区間制御セグメントではサポートされていません）
2. タイマーベースの無効化
特定の時点以前に発行されたキーを自動的に無効化します。無効化対象はユーザー範囲の指定設定によって決定されます。
使用事例例: 重要な段階でのイベント公平性
次のようなイベントがあると仮定します：
- 進入パス: 基本的に1時間有効期間
- 複数のイベントページ（
/event/1、/event/2、/event/3）が1時間以内に自由な探索を許可 - 重要な要件: 午後2:00以降、すべての訪問者はイベント公平性のために再待機しなければならない
シナリオタイムライン:
午後1:00 訪問者が /event/1 に進入、進入キー受信
→ 進入パスが午後2:00まで有効
午後1:30 訪問者が /event/2 に移動
→ 進入パスがまだ有効
→ 直接進入 ✓
午後1:45 訪問者が /event/3 に移動
→ 進入パスがまだ有効
→ 直接進入 ✓
午後2:00 タイマーベースの無効化がトリガー
→ 予約時間以前に発行されたキーが無効化
午後2:05 訪問者がすべてのイベントページにアクセス試行
→ 午後2:00にキーが無効化
→ 待合室を再度通過しなければならない ✗
構成:
-
無効化時間設定（最小: 1分解像度）:
無効化時間: 午後2:00 -
ユーザー範囲の指定:
- 進入済みのユーザーのみ: 予約時間以前にサービスに進入したユーザーの進入キーを無効化（再発行）します。待機中のユーザーの待機キーは影響を受けません。
- 待機中のユーザーから: 予約時間以前にサービスに進入したユーザーの進入キーと進入のために待機中のユーザーの待機キーの両方を無効化（再発行）します。
動作方法:
- システムが各キーが発行された時点を構成された無効化時間と比較
- 無効化時間以前に発行されたキーは、ユーザー範囲の指定設定に応じて無効化されます（待機順維持期間/進入パス有効期間と関係なく）
- 無効化時間以降に発行されたキーは正常動作
- 進入済みのユーザーのみ選択時: サービスに進入したユーザーの進入キーのみが無効化（再発行）され、再進入時に待合室を通過しなければならない。待機中のユーザーの待機キーは影響を受けません
- 待機中のユーザーから選択時: サービスに進入したユーザーの進入キーと待機中のユーザーの待機キーの両方を無効化（再発行）して、待機中のユーザーも待機列の最後から再待機しなければならない
結合された無効化
URLベースおよびタイマーベースの無効化を一緒に使用して、複雑なアクセス制御シナリオに対応できます：
例: URLおよび時間制限が両方あるイベント
構成:
- URL無効化: https://example.com/event/critical-phase
- タイマー無効化: 午後2:00
動作:
- 午後2:00以前: /event/critical-phaseのみ再待機が必要
- 午後2:00以降: すべてのページが再待機が必要
構成
基本動作
URLベースおよびタイマーベースの無効化は独立した設定として、個別に有効化または無効化できます：
- URLベースの無効化 OFF（デフォルト）: URLベースの無効化が発生しません
- タイマーベースの無効化 OFF（デフォルト）: タイマーベースの無効化が発生しません
- 2つの機能を独立して有効化できます
- 無効化が無効化されると、キーはそれぞれの進入パス有効期間に応じて有効です
有効化された場合:
- 各アクセス試行で無効化確認が発生
- 有効化された無効化条件を満たすキーが即座に無効化されます
- 新しいキーは待合室を通じて受け取る必要があります
構成ステップ
基本制御セグメントを作成または編集するときに進入キー無効化を構成できます：
- セグメント設定に移動（作成または編集モード）
- 高度な設定セクションに移動
- 無効化方法を有効化（両方とも独立して有効化可能）:
- URLベースの無効化を有効化/無効化
- タイマーベースの無効化を有効化/無効化
- 無効化条件を構成:
- URLベース: 有効化された場合、完全なURLを追加
- タイマーベース: 有効化された場合、次の設定を構成
- 無効化時間設定（最小: 1分解像度）
- ユーザー範囲の指定を選択:
- 進入済みのユーザーのみ: サービスに進入したユーザーの進入キーを無効化（再発行）
- 待機中のユーザーから: サービスに進入したユーザーの進入キーと待機中のユーザーの待機キーの両方を無効化（再発行）
- 構成を保存: 設定を適用
基本制御セグメント:
- URLベースおよびタイマーベースの無効化の両方が使用可能
区間制御セグメント:
- タイマーベースの無効化のみ使用可能
- URLベースの無効化はサポートされていません（UTI/トリガールールサポートなし）
ベストプラクティス
URLベースの無効化を使用するタイミング
URLベースの無効化を使用する場合:
- 異なるページが異なるアクセスレベルを要求
- 一部のページがより重要で、新しい待機列が必要
- 進入パスがあっても特定のページに対するユーザーアクセスを防止したい
- 選択的アクセス制御がある複数ページイベント
例示シナリオ:
- ライブストリーミングイベント: メインページは進入パスを許可し、Q&Aページは再待機が必要
- 多段階販売: 閲覧は進入パスを許可し、購入ページは再待機が必要
- 階層別アクセス: 無料コンテンツは進入パスを許可し、プレミアムコンテンツは再待機が必要
タイマーベースの無効化を使用するタイミング
タイマーベースの無効化を使用する場合:
- 特定のイベント時間に公平性が重要
- 予約された間隔でサーバー負荷を制御する必要がある
- イベント段階が固定された時間に移行
- 定期的な再検証を強制したい
ユーザー範囲の指定選択ガイド:
- 進入済みのユーザーのみ: サービスに進入したユーザーの進入キーのみを無効化して再進入時に再待機させ、待機中のユーザーの待機キーは維持して順番を保存したい場合
- 待機中のユーザーから: サービスに進入したユーザーの進入キーと待機中のユーザーの待機キーの両方を無効化して、予約時間にすべてのユーザーが公平に再待機するようにしたい場合
例示シナリオ:
- ライブイベント: 公演時間に再待機を強制（待機中のユーザーから推奨）
- 限定リリース: 初期ラッシュ期間後にパスを無効化（進入済みのユーザーのみで十分な場合があります）
- 予約されたセール: 各セール段階に新しい待機列が必要（待機中のユーザーから推奨）
- イベント移行: 再待機と一緒にウォームアップからメインイベントに移動（待機中のユーザーから推奨）
2つの方法を結合
複雑なイベントシナリオは、結合された無効化の利点を受けます：
イベント構造:
- ウォームアップ段階（午前10:00 - 午前11:00）: プレミアムコンテンツに対するURLベースの無効化
- メインイベント（午前11:00 - 午後12:00）: 午前11:00にタイマーベースの無効化
- Q&A段階（午後12:00 - 午後1:00）: Q&A URLに対するURLベースの無効化
構成:
- URL無効化:
* https://example.com/event/premium
* https://example.com/event/qa
- タイマー無効化: 午前11:00
注意事項
ユーザー体験の考慮:
- あまりにも頻繁に無効化すると、ユーザーをフラストレーションさせる可能性がある
- 可能な場合、ユーザーに無効化タイミングを伝達
- 公平性と使いやすさの間のバランスを維持
システム負荷のモニタリング:
- 再待機ユーザーの急増が急増を作成する可能性がある
- 過負荷を避けるために無効化タイミングを計画
- 無効化時間設定前にトラフィックパターンを考慮
徹底的にテスト:
- 無効化トリガーが期待通りに動作するか確認
- 待機順維持および進入パスの組み合わせでテスト
- ユーザーが再待機が必要であることを理解しているか確認
他の機能との相互作用
待機順維持との相互作用
待機順維持が有効化され、進入キー無効化がトリガーされるとき：
- URLベースの無効化: 進入キーのみが無効化されるため、待機キーは影響を受けません。待機中のユーザーの待機順は維持されます。
- タイマーベースの無効化:
- 進入済みのユーザーのみ: サービスに進入したユーザーの進入キーのみが無効化（再発行）されるため、待機キーは影響を受けません。待機中のユーザーの待機順は維持されます。
- 待機中のユーザーから: サービスに進入した、または進入のために待機中のユーザーの待機キーと進入キーの両方を無効化（再発行）して、ユーザーが待機順を失い、最後から開始しなければなりません。待機順維持期間内にいても、キー無効化が優先順位を持ちます。
- 新しいキー発行: 無効化されたキーの場合、ユーザーが新しいキーを受け取り、後ろから待機列に参加しなければなりません。
優先順位: 無効化 > 待機順維持（待機キーが無効化される場合にのみ適用）
進入パスとの相互作用
進入パスが有効化され、進入キー無効化がトリガーされるとき：
- 進入キーが無効化される: ユーザーが進入パス権限を失う
- 進入パス有効期間が迂回される: 進入パス有効期間内にいても、無効化が優先順位を持つ
- 再待機が必要: ユーザーが待合室を再度通過しなければならない
優先順位: 無効化 > 進入パス
結合された保護シナリオ
シナリオ1: 進入パス期間中のURL無効化
進入パス: 1時間有効性
URL無効化: /critical-page
タイムライン:
10:00 AM → 進入パスが付与
10:30 AM → /normal-page にアクセス（進入パス有効）
10:45 AM → /critical-page にアクセス（URL無効化がトリガー、再待機が必要）
シナリオ2: 待機順維持期間中のタイマー無効化
待機順維持期間: 5分
タイマー無効化: 午前10:28
ユーザー範囲の指定: 待機中のユーザーから
タイムライン:
10:25 AM → ユーザー接続切断（待機順 #50 が維持）
10:28 AM → タイマー無効化がトリガー（待機キーが無効化）
10:29 AM → ユーザー再接続（タイマーが既にトリガー）
→ 最後から再待機しなければならない
シナリオ3: タイマー無効化 - 進入済みのユーザーのみ
タイマー無効化: 午後2:00
ユーザー範囲の指定: 進入済みのユーザーのみ
タイムライン:
1:30 PM → ユーザーA: サービス進入完了（進入キー保持）
1:45 PM → ユーザーB: 待機中（待機キー保持、順番 #10）
2:00 PM → タイマー無効化がトリガー
→ ユーザーA: 進入キーが無効化（再進入時に待機が必要）
→ ユーザーB: 待機キーが維持（順番 #10 が維持）
検証
シンプルなテストで進入キー無効化機能を確認できます：
設定:
- 30分有効期間で進入パスを有効化
- 進入キー無効化を有効化（URLまたはタイマーベース）
- 無効化条件を構成
テストステップ:
午前10:00 訪問者がサービスに進入、進入キー受信
→ 進入パスが午前10:30まで有効
午前10:15 訪問者がサービスにアクセス
→ 進入パスがまだ有効
→ 直接進入 ✓
午前10:20 無効化条件が満たされる（URLアクセスまたはタイマートリガー）
→ 進入キーが無効化
午前10:25 訪問者がサービスアクセス試行
→ 進入キーが無効化
→ 待合室を再度通過しなければならない ✗
→ 再待機、新しい進入キー受信
午前10:26 訪問者が新しいキーでサービスアクセス
→ 直接進入 ✓（新しい進入パスが発行）
これが証明するもの:
- 無効化が進入パス有効期間よりも優先順位を持つ
- 無効化されたキーは再利用できない
- ユーザーが待合室を通じて新しいキーを受け取る必要がある
- 成功した再待機後、新しい進入パスが発行される
FAQ
待機順維持または進入パスなしで無効化を使用できますか？
はい、無効化は独立しています。しかし、無効化は待機順維持および進入パスと一緒に使用するときに最大の効果を発揮します。これらの保護をいつ迂回するかについての細かい制御を提供するためです。
無効化を複数回トリガーするとどうなりますか？
無効化はイベントベースです：キーが確認され、無効化条件を満たすたびに無効化されます。複雑なシナリオのために、複数の無効化条件（URL + タイマー）を結合できます。
有効化した後、無効化を無効化できますか？
はい！進入キー無効化を無効化することは、即座に適用されるリアルタイム変更です。無効化されたキーは無効状態で維持されますが、無効化を無効化した後に発行された新しいキーは正常動作します。
無効化はすべての統合タイプで動作しますか？
URLベースの無効化はUTI（URLトリガー統合）で動作します。タイマーベースの無効化はすべての統合タイプ（UTIおよびCBI）で動作します。
待機キーと進入キーを別々に無効化できますか？
タイマーベースの無効化では、ユーザー範囲の指定設定を通じて選択できます：
- 進入済みのユーザーのみ: サービスに進入したユーザーの進入キーを無効化（再発行）します。待機中のユーザーの待機キーは影響を受けません。
- 待機中のユーザーから: サービスに進入した、または進入のために待機中のユーザーの待機キーと進入キーの両方を無効化（再発行）します。
URLベースの無効化の場合、進入キーのみが無効化されます（URLにアクセスしたユーザーの進入キーのみが無効化）。
関連する構成オプションについては、高度なタイミング、待機順維持、および高度な設定 - 進入パスドキュメントを参照してください。