翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Amazon Connect でのルーティングの設定
Amazon Connect では、ルーティングは、キュー、ルーティングプロファイル、およびフローの 3 つの部分で構成されています。このトピックでは、キューとルーティングプロファイルについて説明します。フローの詳細については、「[Amazon Connect でのフロー](connect-contact-flows.md)」を参照してください。
キューには、エージェントによる応答を待機している問い合わせが保持されます。単一のキューを使用してすべての着信コンタクトを処理することも、複数のキューを設定することもできます。
キューは、ルーティングプロファイルを介してエージェントにリンクされています。ルーティングプロファイルを作成するときは、次のように指定します。
+ どのキューがその中に入りるのか。
+ あるキューを別のキューより優先させるかどうか。
+ 問い合わせコントロールパネル (CCP) でエージェントが処理するチャネル。
+ エージェントがチャンネルごとに同時に処理できる連絡先の数。
+ 個々のキューが、すべてのチャネルに対応するか、特定のチャンネルに対応しているかどうか。
+ エージェントが手動で優先できる作業は、どのチャネルとキューの組み合わせからのものか。
各エージェントは 1 つのルーティングプロファイルに割り当てられています。
**Topics**
+ [ルーティングの仕組み](about-routing.md)
+ [キュー: 標準およびエージェント](concepts-queues-standard-and-agent.md)
+ [キュー: 優先度と遅延の例](concepts-routing-profiles-priority.md)
+ [キューベースのルーティング](concepts-queue-based-routing.md)
+ [チャネルおよび同時実行](channels-and-concurrency.md)
+ [キューを作成する](create-queue.md)
+ [キューを一時的に無効にする](disable-a-queue.md)
+ [キューの削除](delete-queue.md)
+ [キュー容量を設定する](set-maximum-queue-limit.md)
+ [キューの容量に基づいて問い合わせをルーティングする](route-based-on-queue-capacity.md)
+ [オペレーション時間を設定する](set-hours-operation.md)
+ [ルーティングプロファイルを作成する](routing-profiles.md)
+ [Amazon Connect でのルーティングプロファイルの使用方法](concepts-routing.md)
+ [ルーティングプロファイルを削除する](delete-routing-profiles.md)
+ [キューベースのルーティングを設定する](set-up-queue-based-routing.md)
+ [エージェントの習熟度に基づいてルーティングを設定する](proficiency-routing.md)
# Amazon Connect でのルーティングの仕組み
問い合わせは、以下の要因に基づいてコンタクトセンターを介してルーティングされます。
+ エージェントに割り当てられたルーティングプロファイル。
+ 特定のキューのオペレーション時間
+ フローで定義したルーティングロジック。
例えば、ルーティングプロファイルを使用して、特定のタイプの問い合わせを特定のスキルセットを持つエージェントにルーティングします。必須スキルセットのエージェントが使用できない場合、問い合わせはフローで定義されたキューに配置できます。
次に、Amazon Connect が問い合わせをルーティングするために使用するロジックを示します。
+ キュー内の問い合わせは自動的に優先順位付けされ、次に利用可能なエージェント (最も長く休止していたエージェント) に転送されます。
+ 利用可能なエージェントがない場合、問い合わせは保留状態になります。サービスが提供される順序は、キュー内の時間によって先着順に決定されます。
+ 複数のエージェントが問い合わせに対応可能な場合、デフォルトでは、受信問い合わせは、**[使用可能]** ステータスの期間が最も長いエージェントにルーティングされます。
**ヒント**
キューの優先度と遅延の仕組みについては、「[キュー: 優先度と遅延の例](concepts-routing-profiles-priority.md)」を参照してください。
受信または発信問い合わせを処理すると、エージェントは受信問い合わせ待機リストの一番下に下がります。この計算で発信問い合わせが無視されるように[ルーティングプロファイル](routing-profiles.md)を設定するには、**[発信通話をルーティング順序に影響させない]** オプションをオンにします。組織がエージェントに、発信通話を引き受けてもらい、さらに相応の受信問い合わせを引き受けてもらいたい場合は、このオプションをオンすることを検討してください。
例えば、次のようになります。
+ Joe という名前のエージェントは待機中です。待機列の 3 番目で受信問い合わせを待っています。受信問い合わせであれば顧客と必ず話せますが、発信問い合わせの場合は電話に出てもらえない可能性があるため、発信問い合わせよりも受信問い合わせに対応しています。受信問い合わせであれば、自分の役割を認識してもらえる可能性が高くなります。
+ Joe は手が空いているため、発信問い合わせを行ってバックログを減らしていくことにしました。相手と連絡が取れることもあれば、取れないこともあります。
+ デフォルトでは、Joe が発信問い合わせを行うと、待機列の 3 番目から、受信問い合わせ待機中エージェントのリストの一番下に移動します (10 人のエージェントがいる場合は、10 番目に移動します)。移動する代わりに彼が 3 番目にとどまる必要がある場合は、デフォルト動作を無効にすることができます。
+ ルーティングプロファイルは、1 つのキューが別のキューよりも高い優先度を割り当てられる場合もありますが、キュー内の優先順位は常に、問い合わせがキューに追加された順序で設定されます。
+ コンタクトが属しているキューとチャネルの組み合わせが、ルーティングプロファイルの手動割り当てセクションに**のみ**リストされている場合、そのコンタクトはそのルーティングプロファイルが割り当てられたエージェントには自動的にルーティング**されません**。
## ルーティング転送の仕組み
前のセクションで説明したように、Amazon Connect でキュー内の問い合わせが処理される順序は、キューに入っている時間、ルーティング経過時間の調整、問い合わせの優先度など、複数の要因によって決まります。ただし、問い合わせが転送される場合は、Amazon Connect によるルーティング経過時間の調整が多少異なり、問い合わせがエージェントによって転送されたか、フローまたは API でキュー間で転送されたかなどによって変わります。
次の 2 つのシナリオで、Amazon Connect がルーティングの経過時間をどのように調整するかを示します。
+ **エージェントがクイック接続を使用して問い合わせを転送する**: 問い合わせが最初に時刻 **X** にキューに入れられ、エージェントによって処理されたとします。その後、エージェントが時刻 **Y** にクイック接続を使用して元のキューに戻した場合、次のようになります:
+ 最初にキューに入れられた時刻 **X** は、キューに戻された後、問い合わせが何番目に処理されるかを計算するために使用されます。
+ ルーティング経過時間の調整は、問い合わせがキューに入っている時間を考慮して適用されます。
+ **キュー間の転送**: 問い合わせが時刻 **S** にキューに入れられ、その後、時刻 **T** に別のキューに転送された場合、次のようになります:
+ 新しいクエリ時刻 **T** が、問い合わせが何番目に処理されるかを計算するために使用されます。
+ ルーティング経過時間の調整は、問い合わせがキューに入っている時間を考慮して適用されます。
## 複数のチャネルでのルーティングの仕組み
複数のチャネルを処理するようにルーティングプロファイルを設定するときには、エージェントが既に別のチャネルにいるときにコンタクトを処理できるかどうかを指定する必要があります。これはクロスチャネル同時実行と呼ばれます。
クロスチャネル同時実行を使用する場合、Amazon Connect はエージェントに提示するコンタクトを次のように確認します。
1. エージェントが現在処理しているコンタクト/チャネルを確認します。
1. 現在処理しているチャネルと、エージェントのルーティングプロファイルでのクロスチャネル設定に基づいて、エージェントを次のコンタクトにルーティングできるかどうかを決定します。
クロスチャネル同時実行が設定されている場合に Amazon Connect がコンタクトをルーティングする方法の詳細な例については、「[クロスチャネル同時実行によるコンタクトのルーティング方法の例](routing-profiles.md#example-routing-concurrency)」を参照してください。
## 手動割り当てでのルーティングの仕組み
手動割り当て用にキューとチャネルが一覧表示されているルーティングプロファイルを設定すると、 Amazon Connect はこれらの問い合わせを自動的にルーティングしません。
このルーティングプロファイルが割り当てられたエージェントは、セキュリティプロファイル設定に基づいてエージェントワークスペースのワークリストアプリでキューに入れられたコンタクトを表示し (現在はタスク、E メール、チャットでのみサポート)、自身に割り当てる次の重要な作業項目を決定できます。
## ルーティングの詳細
ルーティングの詳細については、以下のトピックを参照してください。
+ [キュー: 優先度と遅延の例](concepts-routing-profiles-priority.md).
+ [Amazon Connect でのルーティングプロファイルの使用方法](concepts-routing.md)
+ [キューベースのルーティングで、特定のコンタクトセンターのエージェントに顧客をルーティングする](concepts-queue-based-routing.md)
+ [キューベースのルーティングを設定する](set-up-queue-based-routing.md)
# Amazon Connect コンタクトセンターの標準キューとエージェントキュー
キューには 2 つのタイプがあります。
+ **標準キュー**: 問い合わせがエージェントにルーティングされて受け付けられる前に待機する場所です。
+ **エージェントキュー**: エージェントを問い合わせセンターに追加すると自動的に作成されるキューです。
問い合わせは、フローの一部として明示的にエージェントキューに送信された場合にのみ、エージェントキューにルーティングされます。例えば、請求やプレミアムサポートなど、特定の顧客の問題を担当する特定のエージェントに問い合わせをルーティングできます。または、エージェントキューを使用して、エージェントのボイスメールにルーティングすることもできます。
エージェントキューで待機している問い合わせは、標準キューで待機している問い合わせよりも優先順位が高くなります。エージェントキュー内の問い合わせは、優先度が最も高く、遅延はゼロです。
+ 最高優先度: 基本キューに異なる問い合わせがある場合、Amazon Connect は最初に、エージェントキュー内の問い合わせをそのエージェントに割り当てます。
+ ゼロ遅延: エージェントが利用可能な場合、問い合わせは即座にエージェントにルーティングされます。
## メトリクスレポートでのキュー
[リアルタイムメトリクスレポート](real-time-metrics-reports.md)で、標準キュー内とエージェントキュー内にある問い合わせの数をモニタリングできます。次の画像は、リアルタイムメトリクスの [キュー] レポートの例を示しています。[エージェント] テーブルと [エージェントキュー] テーブルが追加されています。以下が示されています。
+ **[BasicQueue]**。これは標準キューです。1 人のエージェント (John) がオンラインであることを示しています。
+ **[エージェント]** テーブル。エージェント John が CCP を **[使用可能]** に設定し、連絡を取る準備ができていることを示しています。スーパーバイザーは、ここからエージェントのステータスを変更できます。例えば、**[オフライン]** に設定します。
+ **[エージェントキュー]** テーブル。John のエージェントキューを示しています。John がオンラインであり、このキューから連絡を取れることも示しています。
![\[[エージェント] テーブルと [エージェントキュー] テーブルを含むキューレポート。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/rtm-standard-and-agent-queues.png)
エージェントが標準キューから問い合わせを取得すると、その問い合わせはエージェントキューに表示されません。問い合わせはエージェントに直接ルーティングされます。
[履歴メトリクスレポート](historical-metrics.md)のデフォルトでは、エージェントキューはキューテーブルに表示されません。これらを表示するには、[**設定**]、[**エージェントキューを表示**] の順にクリックします。
![\[テーブル設定ページのエージェントキューのドロップダウンメニュー。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/hmr-queues-settings-agent-queues.png)
**ヒント**
メトリクス API はエージェントキューをサポートしていません。
## デフォルトのキュー: BasicQueue
Amazon Connect には、[**BasicQueue**] というデフォルトのキューが含まれています。[デフォルトのフロー](contact-flow-default.md)およびデフォルトのルーティングプロファイル (**基本ルーティングプロファイル**) とともに、コンタクトセンターの基本要素であり、これらを使用するとカスタマイズの必要がありません。すぐに使用を開始できます。
# Amazon Connect コンタクトの負荷分散に役立つキューの優先度と遅延の例
このトピックでは、キューの優先度と遅延の設定例をいくつか示し、各シナリオでのコンタクトのルーティング方法について説明します。これらの例を参考に、優先度と遅延機能を使用してコンタクトを負荷分散します。
## 例 1: 優先度が異なっていて遅延が同じ場合
例えば、エージェントの 1 つのグループがセールスルーティングプロファイルに割り当てられているとします。主要ジョブがセールスであるため、セールスキューは優先度 1、遅延 は 0 です。ただし、これらはサポートでも役立つため、キューは優先度 2 で、遅延は 0 です。これを次の表に示します。
| [キュー] | 優先度 | 遅延 (秒) |
| --- | --- | --- |
| セールス | 1 | 0 |
| サポート | 2 | 0 |
セールスキューに問い合わせがない場合、エージェントにはサポートキューの問い合わせが表示されます。
## 例 2: 優先度が同じで遅延が異なる場合
次の表に示すように、サポートキューの優先度を 1、遅延を 30 秒に設定したとします。
| [キュー] | 優先度 | 遅延 (秒) |
| --- | --- | --- |
| セールス | 1 | 0 |
| サポート | 1 | 30 |
これらのエージェントは、セールスキューの遅延が 0 であるため、常にセールスキューから最初に問い合わせを取得します。ただし、**サポート**キューの問い合わせも、30 秒が経過すると優先度 1 として扱われます。そのため、エージェントには、**サポート**キューの問い合わせが表示されるようになります。
## 例 3: 優先度と遅延が異なる場合
サポートルーティングプロファイルのより複雑な例を次に示します。
| [キュー] | 優先度 | 遅延 (秒) |
| --- | --- | --- |
| 階層 1 のサポート | 1 | 0 |
| 階層 2 のサポート | 1 | 0 |
| 階層 3 のサポート | 2 | 20 |
| 階層 4 のサポート | 3 | 80 |
このルーティングプロファイルでは、階層 1 のサポートキューと階層 2 のサポートキューの優先度はそれぞれ 1 であるため、これらのキューの優先度は同じです。
+ エージェントは、次の場合に階層 3 のサポートキューから問い合わせを取得できます。
+ 階層 3 のサポートの顧客が 20 秒以上待っている。
+ かつ、階層 1 のサポートキューまたは階層 2 のサポートキューに問い合わせがない。
+ エージェントは、次の場合に階層 4 のサポートキューから問い合わせを取得できます。
+ 階層 4 のサポートキューの顧客が 80 秒以上待っている。
+ かつ、階層 1 のサポートキュー、階層 2 のサポートキュー、または階層 3 のサポートキューに問い合わせがない。
**優先順位が優先されます** (問い合わせが階層 1 のサポート、階層 2 のサポート、または階層 3 のサポートにあり、20 秒以上待っている場合、エージェントは階層 4 のサポートから問い合わせを取得すると考えるかもしれませんが、そうではありません)。
## 例 4：同じ優先度と遅延
この例では、ルーティングプロファイルに 2 つのキューのみがあり、両方の優先度と遅延が同じです。
| [キュー] | 優先度 | 遅延 (秒) |
| --- | --- | --- |
| セールス | 1 | 0 |
| サポート | 1 | 0 |
このルーティングプロファイルでは、最も古い問い合わせが最初にルーティングされます。これは、最も長い時間アイドル状態のエージェントに送られます。
## 例 5: エージェントがアイドル状態であり、コンタクトが 30 秒の遅延キューに入っている場合
エージェントがアイドル状態で、コンタクトが遅延中 (30 秒の遅延キューで、コンタクトは 15 秒経過) の場合は どうなるでしょうか。
ルーティングプロファイルの **[遅延]** 設定は、X 秒経過しないとこのコンタクトをこのルーティングプロファイルを持つエージェントに提示できないことを意味します。エージェントがアイドル状態かどうかは考慮されません。したがってこの場合、このエージェントには、30 秒以上経過するまでコンタクトは提示されません。
## 例 6: 異なるルーティングプロファイル、同じキュー、異なる優先度の場合
例えば、次のようになります。
| [エージェント] | 優先度 | [キュー] |
| --- | --- | --- |
| エージェント A | 1 | 1 |
| エージェント B | 5 | 1 |
+ **どちらのエージェントも対応できる場合、誰が通話を受けるかは これは ... によって異なります。 **
+ ルーティングでは常に、対応可能な状態になっていた期間が最も長いエージェントへのルーティングが最初に行われます。
エージェント A にはキュー 1 の優先度 1 のプロファイルが、エージェント B にはキュー 1 の優先度 5 のプロファイルが割り当てられています。両方のエージェントが対応可能であるときに、コンタクト Z がキュー 1 に追加されました。この場合、コンタクト Z は常に、対応可能な状態になっていた期間がより長いエージェントにルーティングされます。エージェント B の方が、対応可能な状態になっていた期間が長い場合、コンタクト Z はエージェント B にルーティングされます。
+ キューの優先度は、個々のエージェントにおけるキューの検索に影響するもので、複数の対応可能なエージェントのうちどのエージェントにコンタクトをルーティングするかを決定するものではありません。
例えば、コンタクト Y がキュー 2 にあり、キュー 1 にあるコンタクト Z よりも長くキューで待機しているとします。この場合、コンタクト Y より新しくてもコンタクト Z がエージェント A にルーティングされます。これは、このエージェントのプロファイルでキュー 1 の方が優先度が高くなっているためです。
+ **優先度 5 のエージェントは、優先度の高いエージェントが対応できない場合にのみ通話を受けるのでしょうか? **
いいえ。優先度 5 のエージェントは、自分のほかの優先度キューが空である場合にのみ、そのキューから通話を受けます。エージェントに特定のキューの優先度が設定されている場合、その設定は、ほかのエージェントとの比較に基づいてコンタクトがキューにルーティングされる際には影響しません。ただし、そのエージェント本人のプロファイルにある他のキューとの比較に基づいてルーティングされる際には影響します。
ルーティングプロファイルの優先度と遅延を設定する方法については、「[Amazon Connect でルーティングプロファイルを作成し、キューをエージェントに関連付ける](routing-profiles.md)」を参照してください。
# キューベースのルーティングで、特定のコンタクトセンターのエージェントに顧客をルーティングする
ビジネスでは、エージェントのスキルなどの特定の基準に基づいて、顧客を特定のエージェントにルーティングすることがあります。これはキューベースのルーティングと呼ばれ、スキルベースのルーティングとも呼ばれます。
この適用例としては、航空会社に、英語圏の顧客の予約を処理するエージェント、スペイン語圏の顧客に対応するエージェント、そして 3 番目のグループとして、両方のタイプの顧客に (電話経由のみで) 対応可能なエージェントがいる場合などが挙げられます。
次の図は、実行できる内容を示しています。
+ 複数のエージェントに同じルーティングプロファイルを割り当てる。
+ ルーティングプロファイルに複数のキューを割り当てる。
+ 複数のルーティングプロファイルにキューを割り当てる。
![\[4 つのルーティングプロファイルのグラフィック。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/routing-profile-example2.png)
キューベースのルーティングを設定する手順の概要については、「[キューベースのルーティングを設定する](set-up-queue-based-routing.md)」を参照してください。
# Amazon Connect で問い合わせをルーティングするためのチャネルと同時実行数
エージェントは、Amazon Connect で音声、チャット、タスク、および E メールを処理できます。複数のチャネルを処理するルーティングプロファイルを設定するときには、2 つのオプションがあります。
+ オプション 1: エージェントが既に別のチャネルにいるときでも問い合わせを処理できるように設定します。これは*クロスチャネル同時実行*と呼ばれます。
+ オプション 2: エージェントが完全にアイドル状態の場合に、キューの内容に応じて、音声、チャット、タスク、または E メールが提示されるようにエージェントを設定します。このオプションを選択すると、エージェントが 1 つのチャネルからコンタクトの処理を開始すると、他のチャネルからのコンタクトは提示されなくなります。
クロスチャネル同時実行を使用する場合、Amazon Connect はエージェントに提示するコンタクトを次のように確認します。
1. エージェントが現在処理しているコンタクト/チャネルを確認します。
1. 現在処理しているチャネルと、エージェントのルーティングプロファイルでのクロスチャネル設定に基づいて、エージェントを次のコンタクトにルーティングできるかどうかを決定します。
1. Amazon Connect は、優先度と遅延時間が等しい場合、待機時間が最も長いコンタクトを優先します。複数のチャンネルを同時に評価しますが、先入れ先出しが尊重されます。
クロスチャネル同時実行が設定されている場合に Amazon Connect がコンタクトをルーティングする方法の詳細な例については、「[クロスチャネル同時実行によるコンタクトのルーティング方法の例](routing-profiles.md#example-routing-concurrency)」を参照してください。
複数のチャットを処理するときにエージェントが問い合わせコントロールパネルで得られるエクスペリエンスの詳細については、「[Amazon Connect のコンタクトコントロールパネル (CCP) を使用して、コンタクトとチャットする](chat-with-connect-contacts.md)」を参照してください。
# Amazon Connect 管理ウェブサイトを使用してキューを作成する
このトピックでは、 Amazon Connect 管理ウェブサイトを使用してキューを作成する方法について説明します。プログラムでキューを作成するには、*Amazon Connect API リファレンス*の [create-queue](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/connect/create-queue.html) AWS CLI または [CreateQueue](https://docs.aws.amazon.com/connect/latest/APIReference/API_CreateQueue.html) を参照してください。
**作成できるキューの数はいくつですか。****[Queues per instance]** (インスタンスごとのキュー) のクォータを表示するには、[https://console.aws.amazon.com/servicequotas/](https://console.aws.amazon.com/servicequotas/) で Service Quotas コンソールを開きます。
**キューを作成するには**
1. https://*instance name*.my.connect.aws/ で Amazon Connect 管理者ウェブサイトにログインします。**管理者**アカウント、またはセキュリティプロファイルに **[ルーティング]** - **[キュー]** - **[作成]** のアクセス許可が追加されたアカウントを使用してください。
1. Amazon Connect 管理ウェブサイトのナビゲーションメニューで、**ルーティング**、**キュー**、**新しいキューの追加**を選択します。
1. キューに関する適切な情報を追加し、[**新しいキューの追加**] を選択します。
次の図は、BasicQueue のキュー情報を示しています。
![\[BasicQueue のキューの編集ページ。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/add-a-new-queue.png)
前述した内容について詳しくは、次のトピックを参照してください。
1. [Amazon Connect を使用し、キューのオペレーション時間とタイムゾーンを設定する](set-hours-operation.md)
1. [Amazon Connect にアウトバウンド発信者 ID を設定する](queues-callerid.md)
1. [Amazon Connect で E メールを設定する](setup-email-channel.md)
1. [Amazon Connect を使用してキュー内の問い合わせ数の制限を設定する](set-maximum-queue-limit.md)
1. [Amazon Connect でクイック接続を作成する](quick-connects.md)
キューは自動的にアクティブになります。
1. キューをルーティングプロファイルに割り当てます。詳細については、「[Amazon Connect でルーティングプロファイルを作成し、キューをエージェントに関連付ける](routing-profiles.md)」を参照してください。ルーティングプロファイルは、キューとエージェントを関連付けます。
1. [タグの追加] で、このキューにアクセスできるユーザーを識別、整理、検索、フィルタリング、制御します。詳細については、「[Amazon Connect でリソースにタグを追加する](tagging.md)」を参照してください。
キューの動作については、「[Amazon Connect でのルーティングプロファイルの使用方法](concepts-routing.md)」および「[キューベースのルーティングで、特定のコンタクトセンターのエージェントに顧客をルーティングする](concepts-queue-based-routing.md)」を参照してください。
## キューを作成および管理するための API
キューをプログラムで作成および管理するには、次の API を使用します。
+ [CreateQueue](https://docs.aws.amazon.com/connect/latest/APIReference/API_CreateQueue.html)
+ [DeleteQueue](https://docs.aws.amazon.com/connect/latest/APIReference/API_DeleteQueue.html)
+ [DescribeQueue](https://docs.aws.amazon.com/connect/latest/APIReference/API_DescribeQueue.html)
+ [ListQueues](https://docs.aws.amazon.com/connect/latest/APIReference/API_ListQueues.html)
+ [SearchQueues](https://docs.aws.amazon.com/connect/latest/APIReference/API_SearchQueues.html)
+ [UpdateQueueHoursOfOperation](https://docs.aws.amazon.com/connect/latest/APIReference/API_UpdateQueueHoursOfOperation.html)
+ [UpdateQueueMaxContacts](https://docs.aws.amazon.com/connect/latest/APIReference/API_UpdateQueueMaxContacts.html)
+ [UpdateQueueName](https://docs.aws.amazon.com/connect/latest/APIReference/API_UpdateQueueName.html)
+ [UpdateQueueOutboundCallerConfig](https://docs.aws.amazon.com/connect/latest/APIReference/API_UpdateQueueOutboundCallerConfig.html)
+ [UpdateQueueOutboundEmailConfig](https://docs.aws.amazon.com/connect/latest/APIReference/API_UpdateQueueOutboundEmailConfig.html)
+ [UpdateQueueStatus](https://docs.aws.amazon.com/connect/latest/APIReference/API_UpdateQueueStatus.html)
# Amazon Connect を使用してキューを一時的に無効にする
キューを一時的に無効にすることで、キューへの問い合わせフローをすばやく制御できます。無効にしたキューは、オフラインモードになります。新しい問い合わせはキューにルーティングされなくなります。ただし、すでにキューに入っている既存の問い合わせは、エージェントにルーティングされます。
**[ルーティング]** - **[キュー]** - **[有効/無効]** のアクセス許可が設定されたセキュリティプロファイルを持つユーザーのみが、キューを無効にすることができます。
![\[キュー行の [有効/無効] チェックボックスが選択されているセキュリティプロファイルのアクセス許可テーブル。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/disable-queue.png)
**アクティブなキューを一時的に無効にするには**
1. https://*instance name*.my.connect.aws/ で Amazon Connect 管理者ウェブサイトにログインします。**管理者**アカウント、またはセキュリティプロファイルに **[ルーティング]** - **[キュー]** - **[有効/無効]** のアクセス許可が追加されたアカウントを使用してください。
1. Amazon Connect 管理ウェブサイトのナビゲーションメニューで、**ルーティング**、**キュー**を選択します。
1. 次の図に示すように、無効にするキューの **[ステータス]** を **[無効]** に切り替えます。
![\[[キュー] ページ、[ステータス] トグル。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/disable-queue-power-button.png)
1. 次の図に示すように、**[無効化]** を選択してキューを無効にすることを確定します。必要に応じて、ボタンを **[有効]** に戻すことですぐにキューを有効にできます。
![\[キューの無効化を確定するボックス。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/disable-queue-confirm.png)
# Amazon Connect インスタンスからキューを削除する
Amazon Connect インスタンスからキューを削除するには、次の 3 つの方法があります。
+ Amazon Connect 管理ウェブサイト
1. https://*instance name*.my.connect.aws/ で Amazon Connect 管理者ウェブサイトにログインします。**管理者**アカウント、またはセキュリティプロファイルに **[ルーティング]** - **[キュー]** - **[削除]** のアクセス許可が追加されたアカウントを使用してください。
1. Amazon Connect 管理ウェブサイトのナビゲーションメニューで、**ルーティング**、**キュー**を選択し、削除アイコンを選択します。
![\[[キュー] ページ、[ステータス] オプションと [削除] オプション。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/delete-queue.png)
**重要**
削除したキューを元に戻すことはできません。キューを一時的に無効にするには、ステータスを **[無効]** に切り替えます。
+ [DeleteQueue](https://docs.aws.amazon.com/connect/latest/APIReference/API_DeleteQueue.html) API
+ [delete-queue](https://docs.aws.amazon.com/cli/latest/reference/connect/delete-queue.html) AWS CLI
# Amazon Connect を使用してキュー内の問い合わせ数の制限を設定する
デフォルトでは、1 つのキューに音声、チャット、タスク、E メールの[サービスクォータ](amazon-connect-service-limits.md)まで含めることができます。
+ **インスタンスあたりのアクティブな同時呼び出しの数**
+ **インスタンスあたりの同時実行アクティブチャット数 (SMS を含む)**
+ **インスタンスあたりの同時アクティブタスク**
+ **インスタンスあたりのアクティブな同時 E メールの数**
これらのクォータのいずれかを引き上げるには、クォータの引き上げをリクエストする必要があります。詳細については、「[Amazon Connect サービスクォータ](amazon-connect-service-limits.md)」を参照してください。
特定のキューで許可する問い合わせ数を、許可するクォータ数よりも少なくしたい場合があります。例えば、次のようになります。
+ 解決に平均 15 分かかる複雑な問題に関する通話専用のキューがある場合、キューで許可する通話の数を、**[インスタンスあたりのアクティブな同時通話の数]** 未満に制限できます。これにより、お客様は何時間も待つ必要がなくなります。
+ チャット専用のキューが存在する場合があります。サービスクォータは 100 件ですが、一度に 20 件までのチャットに制限できます。この値を設定して、Amazon Connect がキューにルーティングするアクティブなチャットの数を制限できます。
+ 複数のチャネルを結合するキューで、カスタム値を設定できます。この値に達すると、コンタクトの分布に関係なく、キューは新しいコンタクトの受け入れを停止することに注意してください。例えば、値を 50 に設定し、最初の 50 件のコンタクトがチャットだった場合、このキューには音声通話がルーティングされません。
このトピックでは、このような状況でキューに登録できる問い合わせの数を減らす方法について説明します。
## キューに入れられる問い合わせの数を減らす
同時に[スタンダードキュー](concepts-queues-standard-and-agent.md)に入れられる問い合わせの数を減らすには、スタンダードキューに **[Maximum contacts in queue]** (キュー内の最大問い合わせ数) の制限を設定します。この設定は[エージェントキュー](concepts-queues-standard-and-agent.md)には適用されません。
![\[すべてのチャネルに対してキュー内のコンタクトの最大数を設定するオプション。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/maximum-contacts-in-queue3.png)
**[キュー内の最大コンタクト数]** に数値を入力すると、Amazon Connect は、その数が、サービスクォータのアクティブな同時コンタクト数の合計 (**インスタンスあたりの同時通話数** \$1 **インスタンスあたりのアクティブな同時チャット数** \$1 **インスタンスあたりのアクティブな同時タスク数** \$1 **インスタンスあたりのアクティブな同時 E メール数**) 未満であることを確認します。
**重要**
**[キュー内の最大コンタクト数]** は、クォータを組み合わせた合計数 (**インスタンスあたりの同時通話数** \$1 **インスタンスあたりのアクティブな同時チャット数** \$1 **インスタンスあたりのアクティブな同時タスク数** \$1 **インスタンスあたりのアクティブな同時 E メール数**) 未満に設定する必要があります。
着信とキューに入れられたコールバックは、キューのサイズ制限にカウントされます。
デフォルトのサービスクォータの詳細および引き上げをリクエストする方法については、[Amazon Connect サービスクォータ](amazon-connect-service-limits.md) を参照してください。
**特定のキューに入れられる問い合わせの数を減らすには**
1. ナビゲーションメニューで、[**ルーティング**]、[**キュー**]、[**新しいキューの追加**] の順に選択します。または、既存のキューを編集します。
1. **[Maximum contacts in queue]** (キュー内の最大問い合わせ数) で、**[Set a limit across all channels]** (すべてのチャネルにわたって制限を設定) を選択します。キューがチャット、タスク、および E メールにも使用される場合、すべてのチャネルはすべて同じ最大数に制限されます。
1. ボックスで、キューが満杯と見なされるまでに入れることができる問い合わせの数を指定します。この値は、**インスタンスあたりのアクティブな同時通話数** \$1 **インスタンスあたりのアクティブな同時チャット数** \$1 **インスタンスあたりのアクティブな同時タスク数** \$1 **インスタンスあたりのアクティブな同時 E メール数**の合計を超えることはできません。
![\[キューの最大コンタクト数を設定するための入力フィールドに値 7 が表示されている様子。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/maximum-contacts-in-queue2.png)
## キューがいっぱいになった場合の呼び出しの処理
+ 着信通話: [キューに保存されたコールバックを設定する](setup-queued-cb.md)か、別の緊急時対応を実装するのが理想的です。そうしないと、次の着信にはリオーダー音 (高速のビジートーンとも呼ばれます) が鳴ります。これは、着信番号への転送パスが利用できないことを示します。
+ キューに入れられたコールバック: 次にキューに入れられたコールバックは、エラーブランチにルーティングされます。
## キュー内の連絡先の最大数が 0 に設定されている場合はどうなりますか
**[キュー内の最大問い合わせ数]** を 0 に設定すると、キューは使用できなくなります。動作はキューがいっぱいの場合と同じです。
## キューの最大限界の例外
設定されている **[キュー内の最大コンタクト数]** 限界より多くのコンタクトをキューに追加できる場合があります。
+ キューが容量限界に達してから、この限界がフローに適用されるまでの間に、わずかな遅延が生じる場合があります。この遅延により、その間、特にトラフィックが集中しているときには、着信コンタクトがキューに入れられることがあります。
さらに、Amazon Connect には、以下の例外的なシナリオに備えて、キュー容量の 20% のバッファが含まれています。
+ コンタクトは [キューに入れられたコールバック] に変換され、フローの **[初期遅延]** 設定を使用して X 時にキューに追加されるようにスケジュールされました。しかし、予定時刻になった時点で、ターゲットキューは **[キューの最大容量]** 限界に達していました。このシナリオでは、Amazon Connect では、**[キューの最大容量]** 限界の 20 パーセントのバッファまで、[キューに入れられたコールバック] をキューに入れることができます。
+ 以前は Queue1 に入っていたコンタクトを、フローを介してQueue2 に転送します。しかし、転送を試行すると、Queue2 は既に **[キューの最大容量]** の上限に達していました。このシナリオの場合、Amazon Connect は、Queue2 の **[キューの最大容量]** の上限から最大 20 パーセントのバッファまで、転送の続行を許可します。
+ エージェントは、クイック接続を使用してキューへのコンタクトの手動転送を開始します。しかし、転送を試みたときに、キューは既に **[キューの最大容量]** 限界に達していました。このシナリオの場合、Amazon Connect は、**[キューの最大容量]** の上限から最大 20 パーセントのバッファまで、転送の続行を許可します。
# Amazon Connect を使用し、キューの容量に基づいて問い合わせをルーティングする
キューの容量に基づいてルーティング決定を定義するには、[キューへの転送](transfer-to-queue.md) ブロックを使用して、キューが満杯 ([キュー内の最大問い合わせ数](set-maximum-queue-limit.md)) かどうかをチェックし、それに応じて問い合わせをルーティングします。
[キューへの転送](transfer-to-queue.md) ブロックは[キュー内の最大問い合わせ数](set-maximum-queue-limit.md)をチェックします。制限が設定されていない場合、キューは次のクォータにおける同時実行数の合計によって制限されます。
+ インスタンスあたりのアクティブなタスクの数
+ インスタンスあたりのアクティブな同時 E メールの数
+ インスタンスあたりの同時通話数
+ インスタンスあたりの同時チャット
# Amazon Connect を使用し、キューのオペレーション時間とタイムゾーンを設定する
このトピックでは、 Amazon Connect 管理ウェブサイトを使用して運用時間を設定する方法について説明します。プログラムで時間を設定するには、[「オペレーション時間アクション](https://docs.aws.amazon.com/connect/latest/APIReference/hours-of-operation-api.html)」を参照してください。
キューを設定するときに最初にすべきことは、オペレーション時間とタイムゾーンを指定することです。時間はフローで参照できます。例えば、問い合わせをエージェントにルーティングするときは、最初に [オペレーション時間の確認](check-hours-of-operation.md) ブロックを使用し、次に問い合わせを適切なキューにルーティングします。
![\[オーバーライドを含む [オペレーション時間] ページ。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/hoop-listpage.png)
**Topics**
+ [作成できるオペレーション時間とオーバーライドの数](#howmany-hours)
+ [オペレーション時間を設定する](#set-hoop)
+ [
## 午前 0 時の指定方法
](#set-hours-operation-midnight)
+ [
## 例
](#set-hours-operation-examples)
+ [
## 昼食や他の休憩を追加する
](#add-lunch-breaks)
+ [夏時間](#daylight-savings-time)
+ [
## フローがオペレーション時間を活用する方法
](#use-check-hours-of-operation-block)
+ [オペレーション時間の延長、短縮、休日変則のオーバーライドを設定する](hours-of-operation-overrides.md)
+ [オペレーションの実効時間を示すカレンダーを表示する](view-hours-of-operation-calendar.md)
## 作成できるオペレーション時間とオーバーライドの数
**[Hours of operation per instance]** (インスタンスごとのオペレーション時間) のクォータを表示するには、[https://console.aws.amazon.com/servicequotas/](https://console.aws.amazon.com/servicequotas/) で Service Quotas コンソールを開きます。
## オペレーション時間を設定する
1. Amazon Connect 管理者アカウントまたは**ルーティング - オペレーション時間 -** セキュリティプロファイルの作成アクセス許可を持つアカウントを使用して、管理者ウェブサイトにログインします。
1. ナビゲーションメニューで、[**ルーティング**]、[**オペレーション時間**] の順に選択します。
1. 一連の営業時間を作成するには、**新しい時間のセットを追加**を選択し、名前と説明を入力します。
1. **[タイムゾーン]** をクリックして、値を選択します。
1. **運用時間**を選択して新しい時間を設定します。
1. 必要に応じて **[タグ]** セクションで、このオペレーション時間のレコードにアクセスできるユーザーを識別、整理、検索、フィルタリングするためのタグを追加します。詳細については、「[Amazon Connect でリソースにタグを追加する](tagging.md)」を参照してください。
1. **[保存]** を選択します。
1. これで、これらのオペレーション時間を[キューの作成](create-queue.md)時に指定し、[オペレーション時間の確認](check-hours-of-operation.md) ブロック内でチェックできます。
## 午前 0 時の指定方法
午前 0 時を指定するには、「12:00AM」と入力します。
例えば、時間を午前 10:00 時から午前 0 時に設定する場合は、「10:00AM to 12:00AM」と入力します。これで、コールセンターは 14 時間営業となります。計算式は次のとおりです。
+ 午前 10:00～午後 12:00 = 2 時間
+ 午後 12:00～午前 12:00 = 12 時間
+ 合計 = 14 時間
## 例
**24 時間 365 日のスケジュール**
![\[24 時間稼働するコンタクトセンターの週次スケジュールの例。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/set-hours-of-operation-24x7.png)
**月曜日～金曜日、午前 9:00 時から午後 5:00 時までのスケジュール**
**個々の日に展開する**ボタンを選択します。
日曜日と土曜日をスケジュールから除外します。
![\[コンタクトセンターのスケジュールから数日を削除する例。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/set-hours-of-operation-closed-weekends-remove.png)
## 昼食や他の休憩を追加する
「運用時間」セクションの下部で**「」 \$1 **「時間を追加」を選択して行をさらに作成し、各日内の時間範囲を設定します。たとえば、土曜日の時間が 8～11 時間の場合は、1～5 時間です。
![\[コンタクトセンターのスケジュールに追加された昼休みを示す図。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/hours-of-operation-lunch.png)
ほとんどのコンタクトセンターでは、休憩に時差を設けています。例えば、一部のエージェントが昼食中の間に、他のエージェントは引き続き問い合わせに対応します。これをオペレーションの時間で指定する代わりに、エージェントの Contact Control Panel (CCP) で[エージェントのカスタムステータスを追加](agent-custom.md)できます。
例えば、[**昼食**] という名前のカスタムステータスを作成できます。エージェントが昼食を取る間は、CCP でステータスを [**利用可能**] から [**昼食**] に変更します。この時間中は、問い合わせがエージェントにルーティングされません。エージェントが昼食から戻り、再び問い合わせに対応できるようになったら、ステータスを [**利用可能**] に戻します。
スーパーバイザーは、リアルタイムのメトリクスレポートを使用してエージェントのステータスを変更できます。
詳細については、以下のトピックを参照してください。
+ [Amazon Connect コンタクトコントロールパネル (CCP) にカスタムのエージェントステータスを追加する](agent-custom.md)
+ [コンタクトコントロールパネル (CCP) のエージェントステータス](metrics-agent-status.md)
+ [コンタクトコントロールパネル (CCP) のメトリクスレポートの [エージェントのアクティビティ] ステータスを変更する](rtm-change-agent-activity-state.md)
## 夏時間の間に起こること
Amazon Connect はタイムゾーンを使用して、キューに夏時間が有効かどうかを判断し、夏時間が採用されているすべてのタイムゾーンで、**自動的に調整**を行います。コンタクトが入ると、Amazon Connect はコンタクトセンターの営業時間とタイムゾーンを調べて、指定されたキューにコンタクトをルーティングできるかどうかを判断します。
**重要**
Amazon Connect には、EST5EDT, PST8PDT, CST6CDTなどのオプションが用意されています。例えば、EST5EDT は次のように定義されています。
標準時を使用するときは、[東部標準時 (EST)](https://en.wikipedia.org/wiki/Eastern_Time_Zone) が使用されます。これは協定世界時 (UTC) より 5 時間遅れています。
夏時間を使用するときは、[東部夏時間 (EDT)](https://en.wikipedia.org/wiki/Eastern_Time_Zone) が使用されます。これは協定世界時 (UTC) より 4 時間遅れています。
選択したタイムゾーンを調査して把握しておくことをお勧めします。
### 例
1. コンタクトセンターへのコールまたはチャットが開始されます。
1. Amazon Connect は、現在のコールセンターの営業時間を調べています。
+ コンタクトはタイムゾーン A からです。
+ コールセンターの営業時間は、タイムゾーン B の午前 9 時～午後 5 時です。
+ タイムゾーン B の現在の時刻が午後 2 時の場合、コールまたはチャットはキューに入れられます。
+ タイムゾーン B の現在の時刻が午前 7 時の場合、コールまたはチャットはキューに入れられません。
## フローがオペレーション時間を活用する方法
フローは、問い合わせが ブロックで定義されたオペレーション時間内であるかどうかをチェックするように設定できます。その後、フローは分岐して結果に基づいて別のパスをたどることができます。例えば、オペレーションが再開されたときにコールバックを提供するメッセージが数時間後に再生されます。詳細については、「[オペレーション時間の確認](check-hours-of-operation.md)」を参照してください。
# 標準営業時間を上書きする必要がある日付を特定する
オペレーションが閉鎖される、時間が短縮される、または通常よりも長く開かれる将来の日付の標準営業時間を上書きできます。
**注記**
オペレーションリソースの時間ごとに最大 50 個のオーバーライドを作成できます。これは調整可能なクォータではありません。
**オーバーライドを作成する**
1. **ルーティング**メニューに移動し、**オペレーション時間**を開きます。
1. 名前を選択してレコードを開きます。
1. 「オーバーライド」セクションで******「作成**」を選択します。
**注記**
表示のみのアクセス許可がある場合、このアクションは表示されません。
1. 次のいずれかを選択して、オーバーライドのリストを構築します。
1. **定期的なイベントの追加** — 繰り返しパターンに従う祝日やその他の日付に使用します (毎月の最終金曜日の早期閉鎖など）。
1. **一時時間の作成** — 非標準時間で繰り返し発生せず、設定された時間がその日付/範囲の他のすべての設定よりも優先される必要がある日付に使用します。
1. **別のオペレーション時間からのコピー** - 他のレコードで既に設定されているオーバーライドをまとめるのに便利ですが、変更 (特定の日付の削除など) を行うオプションが必要な場合に使用します。
**注記**
日時のリストを直接設定するのではなく、別のオペレーション時間リソースに設定されたオーバーライドにリンクできます。1 か所で管理されているマスターリストを共有する場合は、このアプローチを使用します。
1. 開いたウィンドウの指示に従います。
1. **適用** を選択して、選択した日付 (複数可) と時間をコミットします。
1. オペレーション時間のリソースページの右上にある**保存**を選択します。
![\[オペレーション時間は、テーブルアクションドロップダウンを上書きします。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/hours-of-operations-overrides.png)
**定期的なイベント**
定期的なイベントを選択した場合:
1. このオーバーライドに意味のある**名前**を指定します。
1. このオーバーライドの**有効日**を選択します。
**注記**
これらの日付は、このオーバーライドを考慮する必要があるかどうかを判断するために Flows によって使用されます。今日の日付がこの範囲の前後になると、オーバーライドは無視されます。
1. オペレーションが**クローズ**か**オープン**かを示します。
1. **繰り返しパターン**を選択します。選択内容に基づいて、追加の詳細を提供できます。
この例では、オペレーションは、曜日に関係なく、毎年特定の日付でクローズされます。
![\[任意の曜日の定期的なイベントを追加するダイアログ。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/add-annual-recurring-hours-of-operation-override.png)
この例では、2 週間ごとに延長時間が設定されています。
![\[隔週の定期的なイベントを追加するダイアログ。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/add-daily-recurring-hours-of-operation-override.png)
**一時的な時間**
一時時間を選択した場合:
1. このオーバーライドに意味のある**名前**を指定します。
1. このオーバーライドの**有効日**を選択します。
**注記**
これらの日付は、このオーバーライドを考慮する必要があるかどうかを判断するために Flows によって使用されます。今日の日付がこの範囲の前後になると、オーバーライドは無視されます。
1. 指定された日付の**時間**数 (複数可) を選択します。これは、標準の曜日スケジュールを置き換えます。
**注記**
繰り返し発生するオープン/クローズオーバーライドは、一時的な時間よりも優先されます。
この例では、オペレーションは 1 日おきに一部時間のみ開いています。
![\[1 日おきに一時的な時間を作成するダイアログ。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/create-temporary-hours-of-operations.png)
**上書きのコピー**
**別のオペレーション時間からコピー**を選択した場合:
1. 親リソースを見つけて選択します。
1. 次に、 をクリックして**リンクを保存します**。
![\[別のオペレーション時間からオーバーライドをコピーするダイアログ。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/copy-hours-of-operation-overrides.png)
リストをコピーした後、オーバーライドレコードは*ソースとは異なります*。これらは、元のリストに加えられた変更の影響を受けません (例えば、勾配デーが閉鎖から半日に変更された場合など）。
**注記**
コピーされたオーバーライドは、50 オーバーライドサービスクォータにカウントされます。
**注記**
代わりにグローバルリストに依存し、上書き日時が自動的に同期されるようにする場合は、コピーするのではなく*リンク*の手順に従います。
**リンクオーバーライド**
オペレーションレコードの 1 時間以内にオーバーライドのリストを設定する代わりに、マスターリストを含む別のリソースにリンクします。たとえば、「親」時間のオペレーションを設定して、グローバル企業休日のリストを格納し、もう 1 つはリージョンでブロックされた日付などを設定できます。親レコードにリンクされている各「子」は、そのオーバーライドを継承します。親が変更されると、子は追加の労力なしで自動的にメリットを得られます。
![\[別のオペレーションテーブルからのリンクオーバーライド。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/linked-hours-of-operations.png)
リンクを作成して、オーバーライドが別のオペレーション時間から継承されるようにするには:
1. レコードを開き、**リンクされたオペレーション時間**セクションに移動します。
1. **リンクを追加する**ボタンを選択します。
![\[別のオペレーション時間からのオーバーライドをリンクするダイアログ。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/link-hours-of-operation-overrides.png)
1. **Inherit **というリンクモードを選択します。
1. ソースオーバーライドリストを提供するオペレーション時間を検索します。
1. **リンクの保存**ボタンを選択します。
1. 必要に応じて操作を繰り返します。
**注記**
親オーバーライドは、50 オーバーライドサービスクォータにはカウントされません。
**注記**
子は最大 3 人の親にリンクできます。これは調整可能なクォータではありません。
**注記**
オペレーション時間のレコードが子になると、子レコード自体を持つことはできません。
上書きを共有するリンクを作成するには:
1. レコードを開き、**リンクされたオペレーション時間**セクションに移動します。
1. **リンクを追加する**ボタンを選択します。
1. **共有**というタイトルのリンクモードを選択します。
1. オーバーライドを提供するオペレーション時間を検索します。
1. **リンクの保存**ボタンを選択します。
1. 必要に応じて操作を繰り返します。
**注記**
同じ親を参照できる子の数には制限はありません。インスタンス内のすべてのオペレーション時間は、同じ親オーバーライドリストを共有できます。
**注記**
オペレーション時間のレコードが親になると、親自体を持つことはできません。
リンクされたリストのオーバーライドのリストは、子レコードから変更することはできません。変更は親レコードからのみ行うことができます。リンクが誤って行われた場合は、削除できます。
オペレーション時間を編集する権限を持つユーザーのサブセットのみが親レコードにアクセスできる場合は、きめ細かなアクセスコントロールを設定できます。詳細については、「[Amazon Connect でタグベースのアクセスコントロールを適用する](tag-based-access-control.md)」を参照してください。
**競合するオーバーライドがある日付**
特定のオペレーション時間のリソースのオーバーライドが相互に競合することがあります。Connect は、次のようにさまざまなタイプに優先順位を付けます。
1. クローズされた定期的なオーバーライドが最初に考慮されます。
1. 次に、定期的なオープンオーバーライドが考慮されます。
1. 次に、一時的な時間を考慮します。
1. 標準のday-of-the-week時間は最終と見なされます。
次の例では、競合する設定が多数ありますが、定期的な閉鎖時間が 1 日全体をカバーするため、他のオーバーライドと営業時間は無視されます。コンタクトセンターは終日閉鎖されます。
![\[その日にクローズするオペレーション時間オーバーライドの例。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/hours-of-operation-overrides-example-1.png)
別の例では、通常、標準営業時間は日曜日には開いていません。ただし、これは特別な例外です。これは、1 年で最も賑わうショッピングデーの 1 日で顧客をサポートすることを会社が重視しているためです。この場合、コンタクトセンターは午前 10 時から午後 10 時まで営業しています。
![\[通常閉鎖された日に開くオペレーション時間オーバーライドの例。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/hours-of-operation-overrides-example-2.png)
最後の例では、コンタクトセンターは午前 8 時にオープンし、正午から午後 4 時にクローズし、午後 8 時にクローズする前に 2 時間再びオープンします。
![\[複数のオーバーライドタイプのオペレーション時間オーバーライドの例。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/hours-of-operation-overrides-example-3.png)
**注記**
顧客に影響を与える設定をテストして、顧客が希望する結果を生成していることを確認します。
**オーバーライドの監査履歴を表示する**
オーバーライドの監査履歴は、**[オペレーション時間]** ページで標準のオペレーション時間の監査履歴とは別に表示されます。各監査レコードは、関連する運用時間レコードの ID を参照します。
![\[オペレーション時間は監査履歴テーブルを上書きします。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/hours-of-operation-overrides-audit-history.png)
**注記**
AWS CloudTrail は、すべてのリソース変更の履歴を追跡します。詳細については、「AWS CloudTrail を使用した Amazon Connect API コールのログ記録」を参照してください。
# オペレーションの実効時間を示すカレンダーを表示する
営業時間とオーバーライドはカレンダーでまとめて確認できます。詳細ページの上部にある**カレンダーで表示**ボタンを選択します。
![\[有効なオペレーション時間のカレンダービュー。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/hours-of-operation-calendar-view.png)
日、週、または月を選択すると、オープン時間およびクローズ時間が表示されます。必要に応じて、オーバーライド名が提供されます。
# Amazon Connect でルーティングプロファイルを作成し、キューをエージェントに関連付ける
このトピックは、管理者とコンタクトセンターのマネージャーを対象としています。 Amazon Connect 管理者ウェブサイトを使用してルーティングプロファイルを作成する方法について説明します。ルーティングプロファイルをプログラムで作成および管理するために使用する API については、「[ルーティングプロファイルを作成および管理するための API](#apis-routing-profiles)」を参照してください。
キューは連絡先の「待機領域」ですが、ルーティングプロファイルはキューをエージェントにリンクします。ルーティングプロファイルを作成するときは、次のように指定します。
+ チャネル: どのチャネル (音声、チャット、タスク、E メール) がこのエージェントグループにルーティングされるか。チャネルの同時実行を許可するかどうか。
+ キュー: どのキューがルーティングプロファイルに含まれているか。あるキューを他のキューよりも優先すべきかどうか。
各エージェントは 1 つのルーティングプロファイルに割り当てられています。ルーティングプロファイルとキューの詳細については、「[Amazon Connect でのルーティングプロファイルの使用方法](concepts-routing.md)」を参照してください。
**作成できるルーティングプロファイルの数はいくつですか。****[Routing profiles per instance]** (インスタンスごとのルーティングプロファイル) のクォータを表示するには、[https://console.aws.amazon.com/servicequotas/](https://console.aws.amazon.com/servicequotas/) で Service Quotas コンソールを開きます。
**ルーティングプロファイルを作成するには**
1. ナビゲーションメニューで、**[ユーザー]**、**[ルーティングプロファイル]**、**[ルーティングプロファイルの追加]** の順に選択します。
1. **[ルーティングプロファイルの詳細]** セクションの **[名前]** ボックスに、検索可能な表示名を入力します。**[説明]** ボックスに、プロファイルの使用目的を入力します。
1. **[チャネル設定]** セクションで、次の情報を入力または選択します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/routing-profiles.html)
1. **[キュー]** セクションに、以下の情報を入力します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/routing-profiles.html)
1. オプションで、リソースタグを追加して、このルーティングプロファイルにアクセスできるユーザーを識別、整理、検索、フィルタリング、制御します。詳細については、「[Amazon Connect でリソースにタグを追加する](tagging.md)」を参照してください。
1. **[保存]** を選択します。
## チャネルおよび同時実行の設定に関するヒント
+ **[チャネルの可用性]** を使用して、プロファイルに割り当てられたエージェントが音声、チャット、タスク、および E メールコンタクトを受けるかどうかを切り替えます。
例えば、プロファイルに 20 個のキューが割り当てられているとします。すべてのキューで、音声、チャット、タスク、E メールが有効になっています。ルーティングプロファイルレベルで [**音声**] オプションを削除すると、プロファイル内のすべてのキューで、これらのエージェントへのすべての音声通話を停止できます。これらのエージェントの音声問い合わせを再開する場合は、[**音声**] を選択します。
+ **[クロスチャネル同時実行]** を使用しているときには、Amazon Connect はエージェントに提示するコンタクトを次のように確認します。
1. エージェントが現在処理しているコンタクト/チャネルを確認します。
1. 現在処理しているチャネルと、エージェントのルーティングプロファイルでのクロスチャネル設定に基づいて、エージェントを次のコンタクトにルーティングできるかどうかを決定します。
1. Amazon Connect は、優先度と遅延時間が等しい場合、待機時間が最も長いコンタクトを優先します。複数のチャンネルを同時に評価する場合でも、先入れ先出しは尊重されます。
「[クロスチャネル同時実行によるコンタクトのルーティング方法の例](#example-routing-concurrency)」を参照してください。
+ プロファイル内のキューごとに、音声、チャット、タスク、E メールのいずれか、またはそのすべてを選択します。
+ キューで音声、チャット、タスク、E メールのすべてを処理するものの、各チャネルに異なる優先度を割り当てる場合は、キューを 2 回追加します。例えば次の図では、音声の優先度は 1 ですが、チャット、タスク、E メールの優先度は 2 です。
![\[チャネルと優先度が異なる 2 つの BasicQueue エントリを示すキュー設定。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/set-channels-and-concurrency-2.png)
## クロスチャネル同時実行によるコンタクトのルーティング方法の例
たとえば、エージェントが次の図に示すチャネル設定を持つルーティングプロファイルに割り当てられているとします。このエージェントには、音声、チャット、タスク、E メールの各コンタクトがルーティングされます。タスク中にクロスチャネルの連絡先を受け取ることができます。
![\[ルーティングプロファイルの作成ページ、チャンネル設定セクション。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/routing-profile-cross-channel-concurrency.png)
エージェントは次のようなルーティング動作を行います。
1. エージェントが完全にアイドル状態であると仮定します。次に、エージェントはチャットを受け入れ、作業を開始します。その間、タスクがキューに入ります。
+ チャットは [**他のチャンネルは許可しない] に設定されています**。
+ そのため、キューにタスクがあっても、そのタスクはこのエージェントには提供されません。
1. 次に、キューにチャットがあります。
+ エージェントの最大チャット同時実行数は2回なので、合計2回のチャットで別のチャットがルーティングされます。エージェントは両方のチャットを引き続き処理します。
1. キューに他のチャットはありません。エージェントは両方のチャットを終了します (ACW を閉じます)。
+ まだキューに待機中のタスクがあります。
+ この時点で、エージェントは再び完全にアイドル状態になるため、タスクがエージェントに提示されます。エージェントがタスクの実行を開始します。
1. 別のチャットがキューに入ります。
+ タスクは [**他のチャンネルを同時に許可する**] に設定されています。そのため、エージェントが既にタスクに取り組んでいる場合でも、チャットを提供できます。
+ チャットはエージェントに転送され、エージェントは1つのチャットと1つのタスクの両方を同時に処理するようになります。
1. 現在、音声通話がキューに入っています。
+ エージェントはまだ 1 つのチャットと 1 つのタスクを処理中です。
+ [**タスク**] が [**他のチャネルを同時に許可**] に設定されていても、エージェントは 1 つのチャットで作業しており、**エージェントがチャット連絡先に参加している間は** **[チャット] は [他のチャネルなし**] に設定されています。そのため、音声通話はエージェントにルーティングされません。エージェントは引き続きチャットとタスクの両方を処理します。
1. エージェントはチャットを完了しますが、引き続きタスクを処理します。
+ 現在はまだエージェントに割り当てられている連絡先はタスクのみで、**タスクは** [**他のチャネルを同時に許可する**] に設定されているため、エージェントに音声通話を提供できます。
+ エージェントが音声通話に応答し、音声通話とタスクの両方を同時に処理するようになりました。
1. 現在、別のタスクがキューに入っています。
+ エージェントは現在、音声通話とタスクに取り組んでいます。もう一度、Amazon Connect がクロスチャネル設定をチェックし、**エージェントが音声コンタクトをしている間は、「Voice」が「他のチャネルなし**」に設定されます。
+ エージェントは音声通話に対応しているため、音声通話が完了するまでタスクは提供されません。
+ また、**タスクは** [**エージェントあたりの最大連絡先数**] が 1 に設定されているため、エージェントが音声通話を処理した後でも、現在のタスクを完了するまでタスクは提供されません。
## ルーティングプロファイルを作成および管理するための API
ルーティングプロファイルをプログラムで作成および管理するには、次の API を使用します。
+ [CreateRoutingProfile](https://docs.aws.amazon.com/connect/latest/APIReference/API_CreateRoutingProfile.html)
+ [DescribeRoutingProfile](https://docs.aws.amazon.com/connect/latest/APIReference/API_DescribeRoutingProfile.html)
+ [UpdateRoutingProfileConcurrency](https://docs.aws.amazon.com/connect/latest/APIReference/API_UpdateRoutingProfileConcurrency.html)
+ [UpdateRoutingProfileQueues](https://docs.aws.amazon.com/connect/latest/APIReference/API_UpdateRoutingProfileQueues.html)
+ [UpdateRoutingProfileDefaultOutboundQueue](https://docs.aws.amazon.com/connect/latest/APIReference/API_UpdateRoutingProfileDefaultOutboundQueue.html)
# Amazon Connect でのルーティングプロファイルの使用方法
ルーティングプロファイルによって、エージェントが受信できる問い合わせのタイプとルーティングの優先度が決定されます。
+ 各エージェントは 1 つのルーティングプロファイルに割り当てられています。
+ ルーティングプロファイルには、複数のエージェントを割り当てることができます。
![\[1 つのルーティングプロファイルにマップされたエージェントのグループを示すグラフィック。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/agents-routing-profile.png)
Amazon Connect では、ルーティングプロファイルを使用することで、大規模なコンタクトセンターの管理を可能にしています。エージェントグループの実行内容をすばやく変更するには、ルーティングプロファイルの 1 か所で更新するだけで済みます。
## デフォルトルーティングプロファイル: 基本ルーティングプロファイル
Amazon Connect には、**基本ルーティングプロファイル**という名前の、デフォルトのルーティングプロファイルが含まれています。[デフォルトのフロー](contact-flow-default.md)およびデフォルトのキュー (**BasicQueue**) とともに、コンタクトセンターの基本要素であり、これらを使用するとカスタマイズの必要がありません。すぐに使用を開始できます。
## ルーティングプロファイルのリンクキューとエージェント
ルーティングプロファイルを作成するときは、次のように指定します。
+ エージェントがサポートするチャネル。
+ エージェントが処理する顧客のキュー。単一のキューを使用してすべての着信コンタクトを処理することも、複数のキューを設定することもできます。キューは、ルーティングプロファイルを介してエージェントにリンクされています。
+ キューの優先度と遅延。
次の画像は、1 つのルーティングプロファイルにマップされたエージェントのグループを示しています。ルーティングプロファイルは、エージェントに複数のチャネルとキューを指定します。
![\[1 つのルーティングプロファイルにマップされたエージェントのグループを示すグラフィック。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/routing-profile-3.png)
# Amazon Connect インスタンスからルーティングプロファイルを削除する
Amazon Connect インスタンスからルーティングプロファイルを削除するには、次の 3 つの方法があります。
+ Amazon Connect 管理ウェブサイト: 左側のメニューで、**ユーザー**、**ルーティングプロファイル**を選択し、削除アイコンを選択します。
![\[[ルーティングプロファイル] ページ、削除オプション。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/delete-routingprofile.png)
**重要**
削除したルーティングプロファイルを元に戻すことはできません。
+ [DeleteRoutingProfile](https://docs.aws.amazon.com/connect/latest/APIReference/API_DeleteRoutingProfile.html) API
+ [delete-routing-profile](https://docs.aws.amazon.com/cli/latest/reference/connect/delete-routing-profile.html) AWS CLI
# Amazon Connect でキューベースまたはスキルベースのルーティングを設定する
キューベースのルーティングを設定する手順の概要を次に示します。
1. [キューを作成](create-queue.md)します。例えば、ルーティングに使用するスキルごとに 1 つずつ作成します。
1. [ルーティングプロファイルを作成](routing-profiles.md)します。
+ このルーティングプロファイルでサポートされるチャネルを指定します。
+ キュー (チャネル、優先度、および遅延) を指定します。
1. [エージェント設定の構成](configure-agents.md)を実行して、それらの設定にルーティングプロファイルを割り当てます。
[フローを作成](create-contact-flow.md)するときに、そのフローにキューを追加します。例えば、問い合わせでスペイン語でエージェントと話すことを選択した場合、その問い合わせはスペイン語の予約キューにルーティングされます。
ルーティングの仕組みとキューベースのルーティングについては、以下のトピックを参照してください。
+ [複数のチャネルでのルーティングの仕組み](about-routing.md#routing-profile-channels-works)
+ [キューベースのルーティングで、特定のコンタクトセンターのエージェントに顧客をルーティングする](concepts-queue-based-routing.md)
# エージェントの習熟度に基づいて Amazon Connect でルーティングを設定する
エージェントの習熟度に基づいてルーティングを設定する手順の概要を次に示します。
1. [コンタクトをエージェントにルーティングするための事前定義された属性を作成する](predefined-attributes.md)
+ ルーティングの指定に使用する事前定義属性を作成します。次の手順で、事前定義属性を個別に使用することも、`AND` や `OR` の演算子を使用して結合することもできます。
1. [Amazon Connect インスタンスのエージェントに習熟度を割り当てる](assign-proficiencies-to-agents.md)
+ 事前定義属性を選択し、エージェントに関連付けることができます。同じキュー内のコンタクトのルーティングステップ要件を満たすすべてのエージェントがマッチングの対象となります。
1. ルーティング条件の設定
+ [ルーティング条件の設定](set-routing-criteria.md) フローブロックを使用して、ルーティング条件を手動または動的に設定できます。
1. キューへの転送
[キューへの転送](transfer-to-queue.md) フローブロックを使用して、問い合わせをキューに転送します。問い合わせが転送されると、Amazon Connect によりルーティング条件が実行されます。
![\[習熟度ルーティングの 4 ステップのチャート\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/proficiency-routing-chart.png)
## エージェントの習熟度をルーティングに使用する方法の例
コンタクトが **[General Inbound Queue]** というキューに入り、Agent1 と Agent2 の 2 人のエージェントが対応可能になるシナリオを想定します。フランス語を話す顧客が、AWS DynamoDB に関するサポートを求めています。同じ問題に関する電話は今回が 2 回目で、エージェントは AWS DynamoDB のエキスパートとのマッチングをお勧めしたいと考えています。カスタマーエクスペリエンスの維持のため、次のルーティング要件に従うことをお勧めします。
+ まず、**[フランス語 (>=4)]** の非常にフランス語に堪能で、**[AWS DynamoDB (>=5)]** のエキスパートであるエージェントを最初の 30 秒で検索します。
+ エージェントが見つからなかった場合、**[フランス語 (>=3)]** の非常にフランス語に堪能で、**[AWS DynamoDB (>=5)]** の高い習熟度を持つエージェントを次の 30 秒で検索します。フランス語の要件を緩めると、要件を満たす適格なエージェントのプールがさらに拡大します。
+ この時点でエージェントが見つからなかった場合、**[フランス語 (>=3)]** のフランス語力で、**[AWS DynamoDB (>=4)]** の習熟度を持つエージェントを探し、エージェントが見つかるまで検索を続けます。ここで、AWS DynamoDB の要件を緩めると、要件を満たす適格なエージェントのプールが拡大します。
**注記**
規制やコンプライアンスに関するユースケースでは、有効期限切れタイマーに **[有効期限なし]** オプションを使用すると、コンタクトに加わるすべてのエージェントが最低要件を満たしていることを確認できます。
**問い合わせを上記の要件に応じてルーティングするには、次の手順を実行します。**
1. **事前定義された属性の作成**: 例えば、**[ユーザー管理]** で、**[事前定義された属性]** として `Technology` を追加して、値の 1 つとして `AWS DynamoDB` を使用する事前定義された属性を追加します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/proficiency-routing.html)
**注記**
**[Connect:French]** は、事前定義された属性としてのシステム属性 **[Connect:Language]** の値として既に利用できます。これをルーティング条件に使用できます。**[Connect:Language]** には、最大 128 の顧客の言語を値として追加することもできます。
1. **ユーザーへの習熟度の関連付け**: 次のとおり、フランス語を話し、AWS DynamoDB に習熟した Agent1 と Agent2 の 2 人のエージェントがいます。**[ユーザー管理]** の **[詳細設定を表示]** で、次の習熟度を Agent1 と Agent2 に関連付けます。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/proficiency-routing.html)
1. **ルーティング条件の設定**: このフローブロックでは、潜在的なインバウンドフローに示されている Lambda 関数を呼び出して作成された JSON を使用して、次のルーティング条件を手動または動的に作成できます。次のルーティング条件を作成します。
1. ステップ 1: connect:Language(connect:French) >=4 **AND** Technology (AWS DynamoDB) >=5 **[30 seconds]**
1. ステップ 2: connect:Language(connect:French) >=4 **AND** Technology (AWS DynamoDB) >=4 **[30 seconds]**
1. ステップ 3: connect:Language(connect:French) >=3 **AND** Technology (AWS DynamoDB) >=4 **[Never expire]**
次の画像は、エージェントの習熟度に応じてルーティングするように設定されたインバウンドフローの例を示しています。このフローには、[AWS Lambda 関数](invoke-lambda-function-block.md)、[ルーティング条件の設定](set-routing-criteria.md)、[作業キューの設定](set-working-queue.md)、[キューへの転送](transfer-to-queue.md)、および [切断/ハングアップ](disconnect-hang-up.md) のブロックが含まれます。
![\[エージェントの習熟度に応じてルーティングするように設定されたフロー。\]](http://docs.aws.amazon.com/ja_jp/connect/latest/adminguide/images/proficiency-routing-example-flow-block.png)
1. **キューへ転送**: 問い合わせが「General Inbound Queue」に転送されると、Amazon Connect はただちにルーティング条件の実行を開始します。問い合わせが Agent1 に接続される前に、次の手順が実行されます。
1. **ルーティングステップ 1**: 最初の 30 秒間は (一致なし)、いずれのエージェントも AWS DynamoDB 習熟度 >= 5 でなかったため、Amazon Connect が一致したエージェントはいません。
1. **ルーティングステップ 2**: 次の 30 秒間は、いずれのエージェントもフランス語と AWS DynamoDB の両方に高い習熟度 (>=4) がなかったため (一致なし)
1. **ルーティングステップ 3**: 前のステップの有効期限が切れるとただちに、Amazon Connect は対応できるエージェントを見つけます。Agent1 (フランス語 3、AWS DynamoDB 4) はフランス語に堪能で、AWS DynamoDB にも非常に精通しています。そのため、この問い合わせが Agent1 とマッチングされます。
キューのリアルタイムメトリクステーブルには[ワンクリックドリルダウン](one-click-drill-downs.md)が提供されており、キューのアクティブな問い合わせに使用されているルーティングステップのリストが表示されます。ルーティングステップ固有のメトリクスの定義は、[Amazon Connect のメトリクス定義](metrics-definitions.md) にあります。
## エージェントの習熟度のための問い合わせレコード、問い合わせイベントストリーム、エージェントイベントストリームの更新
以降のセクションに、習熟度ルーティングのモデルが追加されました。
+ [Amazon Connect の問い合わせレコードのデータモデル](ctr-data-model.md)
+ [Amazon Connect におけるエージェントイベントストリームのデータモデル](agent-event-stream-model.md)
+ [問い合わせイベントデータモデル](contact-events.md#contact-events-data-model)
## よくある質問
+ **キューにはまだ意義がありますか。**
+ はい、キューは現在でも必要です。ルーティング条件は、コンタクトがキューに入れられた場合にのみ有効になります。エージェントの習熟度を使用することにより、キュー内の特定のエージェントをターゲットにするためのコントロールが強化されます。
+ **キューとしてモデル化するのではなく、習熟度としてモデル化すべきなのはどのような場合でしょうか。**
+ これはビジネス上の決定事項です。エージェントの習熟度を使用する際に排除して統合できるキューの数への影響を考慮する必要があります。
+ **エージェントの習熟度はすべてのチャネルで機能しますか。**
+ はい、エージェントの習熟度を使用したルーティングはすべてのチャネルで機能します。
+ **どうすればルーティング条件を排除できますか。**
+ 顧客キューフローを使用してルーティング条件を中断できます。
+ また、ルーティング条件をこの方法で更新することもできます。
+ **キューコンタクトでルーティング条件は何度変更できますか。**
+ ルーティング条件は無制限に変更できます。ただし、最新の 3 つのルーティング条件の更新のみが問い合わせレコードに保存されます。
+ **エージェントの習熟度しても、キューの優先度と遅延は通常どおり機能しますか。**
+ はい、キューの優先度と遅延は、エージェントの習熟度を使用していない環境と同様に機能します。
+ **ルーティング条件の作成でサポートされている演算子はどれですか。**
+ 次のブール値演算子がサポートされています。
+ AND
+ OR
+ 次の比較演算子がサポートされています。
+ >=
+ また、次のような最小習熟レベルと最大習熟レベルの範囲を定義することもできます。
+ connect:English(1-3)
+ connect:Chat(4-4)
+ 式で同じ属性を複数回使用することはできません。例えば、connect:English(1-3) AND connect:English(5-5) は許可されません。
+ NOT (除外) - NOT 演算子を使用して、次のようなルーティング時に特定の習熟度を持つエージェントを除外できます。
+ NOT connect:French(1-5)
+ **事前定義された属性で使用できる文字はどれですか。**
+ 事前定義された属性名と値のパターンは、`^(?!(aws:|connect:))[\p{L}\p{Z}\p{N}_.:/=+-@']+$` です。例えば、文字、数値、空白記号、または `_.:/=+-@'` の特殊文字はすべて使用できます。ただし、先頭を `aws:` や `connect:` にすることはできません。
+ **同じ属性をルーティング条件に複数回追加できますか。**
+ はい、同じ属性を単一のルーティング条件に複数回追加できます。
+ **転送 (クイック接続) をトリガーする際、ルーティング条件を設定することはできますか。**
+ 転送フローで [ルーティング条件の設定](set-routing-criteria.md) ブロックを使用して、転送されたコンタクトセグメントのルーティング条件を設定します。以前のコンタクトのルーティング条件を、エージェントが参加した後に作成された新しいコンタクトセグメントに引き継ぐことはできません。
+ **コンタクトがルーティングされる前にキューから別のキューへ転送された場合、ルーティング条件はどうなりますか。**
+ コンタクトがエージェントに接続する前に転送された場合、ルーティング条件は新しいキューの最初のステップから開始されます。そのため、以前のコンタクトのルーティング基準は、キュー転送によって作成された新しいコンタクトセグメントに引き継がれます。
+ **問い合わせレコードには、マッチングしたエージェントの習熟度のスナップショットが記録されますか。**
+ いいえ、問い合わせレコードにはエージェントの習熟度は含まれません。
+ エージェントイベントストリームには、参加時のエージェントの習熟度のスナップショットが含まれます。
+ **API を使用して熟練度別にエージェントを検索することはできますか。**
+ いいえ、サポートされません。
+ **アクティブな問い合わせの属性を削除するとどうなりますか。**
+ アクティブなコンタクトで使用されている属性は削除できます。ただし、その属性を含むルーティングステップで一致するエージェントが見つからず、コンタクトはルーティング条件の有効期限が切れるまでキューに残ります。
+ この属性を持つすべての新規コンタクトは、コンタクトフロー内の [ルーティング条件の設定](set-routing-criteria.md) ブロックのエラーブランチの取得を開始します。
+ **エージェントが通話を拒否すると、ルーティング条件のステップ数や有効期限はどうなりますか。**
+ ルーティングでは、エージェントがコンタクトを受け入れ、参加が完了すると、参加が完了したものとみなされます。エージェントが問い合わせを拒否した場合、ルーティングエンジンはタイマーが継続して動作する状態で、ルーティング条件に沿って処理を続けます。
+ **このステップを拒否したエージェントは、ルーティングが再び実行された場合にプールに含められますか。**
+ はい、このようなエージェントは、ルーティングが再び実行された場合にプールに含められます。
+ **履歴メトリクスは利用できますか。**
+ いいえ、履歴指標は分析では利用できません。
+ 問い合わせレコード、エージェントイベントストリーム、問い合わせイベントストリームに、必要な情報がすべて含まれています。
+ **ルーティング条件を設定する Lambda 関数のサンプルはどこにありますか。**
+ ルーティング条件を設定する Lambda 関数のサンプルについては、[ルーティング条件を設定するサンプル Lambda 関数](set-routing-criteria.md#set-routing-criteria-sample-lambda-function) を参照してください。
+ **問い合わせがエージェントキューに転送される場合、問い合わせに設定されたルーティング条件はどうなりますか？**
+ ルーティング条件は、エージェントキューに存在する問い合わせには影響しません。ルーティング条件を持つ問い合わせがエージェントキューから標準キューに転送された場合、ルーティング条件はキューの転送によって作成された新しい問い合わせセグメントに転送されます。