翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# ワークスペースヘッダーの通知
## アプリ内通知について
アプリ内通知は、Amazon Connect ヘッダーに表示される画面上のアラートです。Amazon Connect にログインしているユーザーに重要な情報を伝えるための一元的な方法を提供します。通知は管理者とエージェントに送信できます。ユーザーがどのページにいるかにかかわらず、未読メッセージがあるかどうかがヘッダーアイコンに表示されます。
**サポートされているユースケース**
通知は、次のユースケースをサポートしています。
+ 可用性への影響、フェイルオーバーイベント、ポリシーの変更、重要な機能の更新などのシステム通知。
+ トレーニングのリマインダー、スケジュール遵守アラート、チームへの緊急通知など、必要なユースケースのためにチームによって API リクエストで指定されたカスタム組織メッセージ。
## 通知の表示方法
Connect ヘッダーに通知が表示され、未読メッセージ (複数可) を示すアイコンが表示されます。ユーザーはアイコンをクリックしてメッセージを表示します。
通知パネルには以下が表示されます。
+ **優先度インジケータ**: 緊急メッセージを強調する
+ **メッセージコンテンツ**: ローカライズされた文字列あたり最大 500 文字、埋め込みリンクをサポート
+ **既読としてマーク**: ユーザーは、各メッセージの右側にあるアクションメニューをクリックして、既読または未読としてマークできます。
未読の通知は、ドットインジケータとともに太字で表示され、最新から古い順に並べられます。読み取り通知により、視覚的な強調が軽減されます。開いたメッセージに応答する時間がないユーザーは、視覚的なリマインダーとして未読としてマークできます。
通知のデフォルトの可視性期間は 1 週間です。期限切れのメッセージは自動的に削除されます。
## 通知の作成と管理 (API のみ)
すべてのユーザーは追加のアクセス許可なしで通知*を受け取る*ことができますが、送信された通知を作成、編集、削除、表示するには特別なアクセス許可が必要です。
**重要**
通知を作成して送信するには、API アクセス許可が必要です。通知 APIs の活用の詳細については、 [API ガイド](https://docs.aws.amazon.com/connect/latest/APIReference/actions-by-resource.html)を参照してください。
通知を管理する権限を持つユーザーには、きめ細かなアクセスコントロールが適用されます。
+ **タグベースのアクセスコントロール (TBAC)**: TBAC 制限を持つ管理者は、割り当てられたタグに一致する通知のみを作成、編集、または削除できます。また、一致するタグを持つユーザーにのみ通知を送信することもできます。
+ **階層ベースのアクセスコントロール (HBAC)**: 管理者は、階層レベルより下のユーザーに送信された通知のみを作成または管理できます。
チームは次の通知アクションを実行できます。
+ リンクが埋め込まれたリッチテキストメッセージを送信する
+ さまざまな言語でメッセージを翻訳してユーザー設定に合わせる (ローカライズされた文字列あたり最大 500 文字)
+ 各メッセージの期間、「有効期限」、つまり TTL を指定します (デフォルトは 1 週間）。
+ 既存のメッセージの更新または削除
+ 一度に最大 200 ユーザーに送信するか、必要に応じてインスタンス内のすべてのユーザーに送信する
+
**重要**
タグベースのアクセスコントロール (TBAC) の制限または階層ベースのアクセスコントロール (HBAC) の制限がない管理者のみが、インスタンス内のすべてのユーザーに通知を作成できます。
+ 緊急メッセージを高い優先度でフラグ付けして表示しやすくする
### ベストプラクティス
**重要**
個人を特定できる情報 (PII) を含めない
**通知の過負荷を最小限に抑える**
インスタンスあたり最大 500 件のアクティブな通知がサポートされています。通知疲労の可能性を回避するには、以下を実行します。
+ **特定の対象者をターゲットにする**: できるだけ狭いネットをキャストします。
+ **関連する更新の統合**: 複数のメッセージを送信するのではなく、情報を 1 つの通知にグループ化します。
+ **冗長なメッセージの回避**: 新しい通知を作成する前に、既存の通知を更新する方が適切かどうかを検討してください。
+ **適切な優先度の使用**: 真に重要なメッセージの有効性を維持するために、優先度の高いメッセージを予約します。
+ **簡潔なメッセージの提供**: 通知に長いコンテンツではなく、完全なドキュメントへのリンクを含めます。
**進行中の状況を管理する**
複数の更新を生成するイベント (天候の中断やシステムの問題など) については、次の点を考慮してください。
+ 最も関連性の高いステータス変更のみを送信する (例：「インシデント開始」および「インシデント解決済み」)
+ 妥当な間隔でのペース調整の更新 — 急激なメッセージでユーザーを圧倒しないようにする
+ 更新頻度に関する期待の設定 (例：「条件が改善するまで 10 分ごとに更新が送信されます」)
+ ステータス変更ごとに新しい通知を作成するのではなく、更新 API を使用して既存の通知を変更する
*例*: 厳しい天候が IT サポートキュー内の 320 人のエージェントに影響する場合は、影響のある初期アラートを送信します。5 分後、「170 人のエージェントがアクセスできません」という現在のステータスで更新します。定義された間隔で意味のある更新を続行します。
**代替手段を使用するタイミング**
これらのシナリオでは、通知に代わる方法を検討してください。
+ **追跡されたアクション項目の場合**: 通知は CloudTrail 監査を提供しますが、割り当て、追跡、レポート機能を提供するタスク機能ほど堅牢ではありません。通知システムは、配信確認や読み取り受信を提供しません。
+ **データ保持が必要なシナリオの場合**: 通知は TTL の有効期限が切れるか、手動で削除されるまでのみ保存されます。デフォルトの TTL は 1 週間です。
+ **AWS コンソールユーザー**の場合: 通知は Connect ウェブサイトにのみ表示されます。AWS コンソールでのみ作業するユーザーにはアクセスできません。
**受信のテストと検証**
通知をテストするときは、次のガイドラインに従ってください。
+ **広範なデプロイ前にテスト**する: まず小さなグループに送信して、コンテンツとフォーマットを検証します。
+ 通知は作成直後に送信されます。スケジュールされた配信はサポートされていません。
+ **配信の検証**: 受信者リストに自分を含めて、通知が期待どおりに表示されることを確認します。