トレーニング
モジュール
Dynamics 365 Business Central でのアプリケーション言語を使用したエラー処理 - Training
Dynamics 365 Business Central でアプリケーション言語 (AL) を使用してエラーを処理する方法を学びます。
このブラウザーはサポートされなくなりました。
Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。
注意
この設計ガイドは Windows 7 用に作成されており、新しいバージョンの Windows では更新されていません。 ガイダンスの多くは原則として適用されますが、プレゼンテーションと例には 現在の設計ガイダンスは反映されていません。
Windows 7 のエラー メッセージは、既に発生している問題をユーザーに警告します。 これに対し、警告メッセージは、将来問題を引き起こす可能性のある条件をユーザーに警告します。 エラー メッセージは、モーダル ダイアログ ボックス、インプレース メッセージ、通知、吹き出しを使用して表示できます。
一般的なモーダル エラー メッセージ。
有効なエラー メッセージは、問題が発生したことをユーザーに通知し、問題が発生した理由を説明し、ユーザーが問題を解決できるように解決策を提供します。 ユーザーは、エラー メッセージの結果としてアクションを実行するか、動作を変更する必要があります。
適切に記述された便利なエラー メッセージは、高品質のユーザー エクスペリエンスにとって非常に重要です。 エラー メッセージの書き込みが不十分な場合、製品の満足度が低くなります。これは、回避可能なテクニカル サポート コストの主な原因です。 不要なエラー メッセージがユーザーのフローを中断します。
メモ:ダイアログ ボックス、警告メッセージ、確認、標準アイコン、通知、レイアウトに関連するガイドラインは、別の記事で示されています。
それを判断するには、以下の質問を考えます。
不適切なエラー メッセージの特性
迷惑な、役に立たない、書き込みが不十分なエラーメッセージが多数あることは驚くべきではありません。 また、エラー メッセージはモーダル ダイアログを使用して表示されることが多いため、ユーザーの現在のアクティビティが中断され、ユーザーの続行を許可する前に確認される要求が中断されます。
問題の一部は、それを間違って行う方法が非常に多いということです。 羞恥のエラー メッセージ ホールから次の例を考えてみましょう。
不要なエラー メッセージ
正しくない:
Windows XP からのこの例は、これまでで最悪のエラー メッセージである可能性があります。 Windows 自体がシャットダウン中であるため、プログラムを起動できなかったことを示します。 ユーザーがこれについて何もできないか、あるいはこれについてやりたいと思っています(ユーザーは結局Windowsをシャットダウンすることを選択しました)。 また、このエラー メッセージを表示することで、Windows はシャットダウンを防ぎます。
問題を: エラー メッセージ自体が問題です。 エラー メッセージを無視する以外に、ユーザーが行う必要はありません。
主な原因: ユーザーの目標や視点に関係なく、すべてのエラー ケースを報告します。
推奨される代替手段: ユーザーが気にしないエラーを報告しないでください。
"成功" エラー メッセージ
正しくない:
このエラーメッセージは、ユーザーがプログラムの削除直後にWindowsを再起動しないことを選択した結果として発生しました。 プログラムの削除は、ユーザーの観点から正常に行われました。
問題を: ユーザーの観点からエラーはありません。 エラー メッセージを無視する以外に、ユーザーが行う必要はありません。
主な原因: タスクはユーザーの観点から正常に完了しましたが、アンインストール プログラムの観点からは失敗しました。
推奨される代替手段: ユーザーが許容できる条件のエラーを報告しないでください。
完全に役に立たないエラー メッセージ
正しくない:
ユーザーはエラーが発生したことを知っていますが、エラーが何であったのか、何をすべきかは分かりません。 そして、いいえ、それは大丈夫ではありません!
問題を: エラー メッセージは特定の問題を与えるので、ユーザーはそれについて何もできません。
主な原因: ほとんどの場合、プログラムのエラー処理が不十分です。
推奨される代替手段: プログラムに適切なエラー処理を設計します。
理解できないエラー メッセージ
正しくない:
この例では、問題ステートメントは明確ですが、補足的な説明は完全に困惑しています。
問題を: 問題のステートメントまたは解決策は理解できません。
主な原因: ユーザーではなくコードの観点から問題を説明する。
推奨される代替手段: ターゲット ユーザーが簡単に理解できるエラー メッセージ テキストを記述します。 ユーザーが実際に実行できるソリューションを提供します。 プログラマがその場でエラー メッセージを作成しないように、プログラムのエラー メッセージ エクスペリエンスを設計します。
過剰に発生するエラー メッセージ
正しくない:
この例では、エラー メッセージは明らかにすべてのトラブルシューティング手順の説明を試みます。
問題を: 情報が多すぎます。
主な原因: 詳細が多すぎるか、エラー メッセージ内で複雑なトラブルシューティング プロセスを説明しようとしています。
推奨される代替手段: 不要な詳細を避けます。 また、トラブルシューティング ツールは避けてください。 トラブルシューティング ツールが必要な場合は、最も可能性の高い解決策に焦点を当て、ヘルプの適切なトピックにリンクして残りの部分について説明します。
不必要に過酷なエラー メッセージ
正しくない:
プログラムがオブジェクトを見つけることができないことはほとんど致命的に聞こえない。 そして、それが壊滅的であると仮定すると、なぜ応答はOKなのでしょうか?
問題を: プログラムのトーンは不必要に過酷または劇的です。
主な原因: この問題は、プログラムの観点から致命的に見えるバグが原因です。
推奨される代替手段: ユーザーの視点に基づいて言語を慎重に選択します。
ユーザーを非難するエラー メッセージ
正しくない:
なぜユーザーが犯罪者のように感じるのですか?
問題を: エラー メッセージは、ユーザーがエラーを犯したと非難する方法で表現されます。
主な原因: 問題の代わりにユーザーの動作に焦点を当てた、無神経な言い回し。
推奨される代替手段: 必要に応じてパッシブ音声を使用して、問題の原因となったユーザー アクションではなく、問題に焦点を当てます。
Silly エラー メッセージ
正しくない:
この例では、問題ステートメントは非常に皮肉であり、解決策は提供されていません。
問題を: 愚かまたは非セキテーターであるエラー メッセージ ステートメント。
主な原因: コンテキストに注意を払わずにエラー メッセージを作成する。
推奨される代替手段: ライターによって作成および確認されたエラー メッセージを表示します。 エラーを確認するときは、コンテキストとユーザーの心の状態を考慮してください。
プログラマーのエラー メッセージ
正しくない:
この例では、エラー メッセージはプログラムにバグがあることを示しています。 このエラー メッセージはプログラマにとってのみ意味があります。
問題を: プログラムの開発者がバグを見つけるのに役立つメッセージは、プログラムのリリース バージョンに残されています。 これらのエラー メッセージは、ユーザーにとって意味も価値もありません。
主な原因: 通常の UI を使用して自分にメッセージを送信するプログラマ。
推奨される代替手段: 開発者は、製品のリリース バージョンから自動的に削除されるように、このようなすべてのメッセージを条件付きでコンパイルする必要があります。 ユーザーだけがプログラマであるため、このようなエラーをユーザーが理解できるようにしようと時間を無駄にしないでください。
表示が不十分なエラー メッセージ
正しくない:
この例では、多くの一般的なプレゼンテーションの間違いがあります。
問題を: エラー メッセージのプレゼンテーションですべての詳細が間違っている。
主な原因: エラー メッセージのガイドラインを知らず、適用する。 ライターとエディターを使用してエラー メッセージを作成および確認しない。
エラー処理の性質は、これらの間違いの多くが非常に簡単に行えるようにすることです。 ほとんどのエラーメッセージが羞恥のホールの指名者である可能性があることに気づくのは不安です。
適切なエラー メッセージの特性
前の悪い例とは対照的に、適切なエラー メッセージには次があります。
さらに、次の方法で適切なエラー メッセージが表示されます。
これらの特性を持つようにエラー処理エクスペリエンスを設計することで、プログラムのエラー メッセージをエラー メッセージの羞恥のホールから除外できます。
不要なエラー メッセージの回避
多くの場合、最適なエラー メッセージはエラー メッセージでありません。 設計を改善することで多くのエラーを回避でき、多くの場合、エラー メッセージの代わりに優れた方法があります。 通常は、エラーを報告するよりもエラーを防ぐ方が良いです。
回避する最も明白なエラー メッセージは、操作できないエラー メッセージです。 ユーザーが何もせずにメッセージを無視する可能性がある場合は、エラー メッセージを省略します。
一部のエラー メッセージは、ユーザーの観点から問題ではないので排除できます。 たとえば、ユーザーが既に削除中のファイルを削除しようとしたとします。 これは、コードの観点からは予期しないケースである可能性もありますが、ユーザーは望ましい結果が得られるので、このエラーは考慮しません。
正しくない:
このエラー メッセージは、ユーザーの観点からアクションが成功したため排除する必要があります。
別の例として、ユーザーがタスクを明示的に取り消したとします。 ユーザーの観点では、次の条件はエラーではありません。
正しくない:
このエラー メッセージは、ユーザーの観点からアクションが成功したため、削除する必要もあります。
場合によっては、テクノロジではなくユーザーの目標に重点を置くことで、エラー メッセージを排除できます。 その際に、エラーが実際に何であるかを再検討します。 ユーザーの目標、またはそれらを満たすプログラムの能力に問題がありますか? 実際の世界でユーザーの行動が理にかなっている場合は、ソフトウェアでも理にかなっているはずです。
たとえば、eコマース プログラム内で、ユーザーが検索を使用して製品を検索しようとしたときに、リテラル検索クエリに一致するものがなく、目的の製品が在庫切れであるとします。 技術的には、これはエラーですが、エラー メッセージを表示する代わりに、プログラムは次の操作を行うことができます。
ユーザーの要求が妥当である限り、適切に設計された e コマース プログラムは、エラーではなく合理的な結果を返す必要があります。
エラー メッセージを回避するもう 1 つの優れた方法は、最初に問題を防ぐことです。 次の方法でエラーを回避できます。
必要なエラー メッセージの提供
場合によっては、実際にエラー メッセージを提供する必要があります。 ユーザーが間違いを犯し、ネットワークとデバイスが動作しなくなったり、オブジェクトが見つからない、変更されたり、タスクが完了したり、プログラムにバグが発生したりします。 理想的には、これらの問題は発生頻度が低くなります。たとえば、多くの種類のユーザーミスを防ぐためにソフトウェアを設計できますが、これらの問題をすべて防ぐのは現実的ではありません。 また、これらの問題のいずれかが発生すると、役に立つエラー メッセージが表示され、ユーザーはすぐに足に戻ります。
一般的な考え方は、エラー メッセージは最悪のユーザー エクスペリエンスであり、すべてのコストで回避する必要があるということですが、ユーザーの混乱は最悪のエクスペリエンスであり、すべてのコストで回避する必要があると言う方が正確です。 場合によっては、そのコストが役に立つエラー メッセージです。
無効なコントロールを検討してください。 ほとんどの場合、コントロールが無効になっている理由は明らかです。そのため、コントロールを無効にすることは、エラー メッセージを回避するための優れた方法です。 ただし、コントロールが無効になっている理由が明らかでない場合はどうなりますか? ユーザーは続行できません。問題を特定するためのフィードバックはありません。 これでユーザーが停止し、問題を推測するか、テクニカル サポートを受ける必要があります。 このような場合は、コントロールを有効のままにして、代わりに役立つエラー メッセージを表示することをお勧めします。
正しくない:
[次へ] ボタンが無効になっているのはなぜですか? 有効のままにしておき、役に立つエラー メッセージを表示してユーザーの混乱を回避することをお勧めします。
エラー メッセージを表示する必要があるかどうかがわからない場合は、まず、指定する可能性があるエラー メッセージを作成します。 ユーザーがアクションを実行するか、その結果として動作を変更する可能性がある場合は、エラー メッセージを入力します。 これに対し、ユーザーが何もせずにメッセージを無視する可能性がある場合は、エラー メッセージを省略します。
適切なエラー処理のための設計
適切なエラー メッセージ テキストの作成は困難な場合もありますが、プログラムからの適切なエラー処理のサポートがなければ不可能な場合があります。 次のエラー メッセージを考えてみましょう。
正しくない:
プログラムのエラー処理のサポートが不足しているため、問題は本当に不明である可能性があります。
これは非常に不適切に記述されたエラー メッセージである可能性がありますが、基になるコードによる適切なエラー処理の欠如を反映している可能性が高く、問題に関する特定の情報はありません。
特定の操作可能なユーザー中心のエラー メッセージを作成するには、プログラムのエラー処理コードで、特定の高レベルのエラー情報を提供する必要があります。
適切なエラー メッセージは、単なる UI の問題ではない、ソフトウェア設計の問題です。 適切なエラー メッセージ エクスペリエンスは、後で取り組むことができるものではありません。
トラブルシューティング (および回避する方法)
複数の異なる原因に関する問題が 1 つのエラー メッセージで報告された場合のトラブルシューティングの結果。
正しくない:
正確:
1 つのエラー メッセージで複数の問題が報告された場合のトラブルシューティングの結果。
次の例では、アイテムが既に移動または削除されたか、アクセスが拒否されたため、アイテムを移動できませんでした。 プログラムが原因を簡単に特定できる場合、特定の原因を特定するためにユーザーに負担をかけるのはなぜですか?
正しくない:
さて、それはどれですか? 次に、ユーザーはトラブルシューティングを行う必要があります。
プログラムはアクセスが拒否されたかどうかを判断できるため、この問題は特定のエラー メッセージで報告する必要があります。
正確:
特定の原因により、トラブルシューティングは必要ありません。
特定の原因を特定できない場合にのみ、複数の原因でメッセージを使用します。 この例では、項目が移動または削除されたかどうかをプログラムが判断するのが難しいため、複数の原因を含む 1 つのエラー メッセージがここで使用される可能性があります。 ただし、削除されたファイルを移動できなかった場合など、ユーザーが気にする可能性は低いです。 これらの原因では、エラー メッセージは必要ありません。
不明なエラーの処理
場合によっては、問題、原因、または解決策を本当に知りません。 エラーを抑制するのが賢明でない場合は、正しくない可能性のある問題、原因、または解決策を提示するよりも、情報の不足を前もって把握することをお勧めします。
たとえば、プログラムにハンドルされない例外がある場合は、次のエラー メッセージが適しています。
不明なエラーを抑制できない場合は、情報の不足を前面に出す方が良いです。
一方、ほとんどの場合に役立つ可能性が高い場合は、具体的で実用的な情報を提供してください。
このエラー メッセージは、ネットワーク接続が通常問題である場合、不明なエラーに適しています。
適切なメッセージの種類を決定する
一部の問題は、強調と言い回しに応じて、エラー、警告、または情報として表示されます。 たとえば、Web ページが現在の Windows インターネット エクスプローラー構成に基づいて署名されていない ActiveX コントロールを読み込めないとします。
適切なメッセージの種類を特定するには、ユーザーが知る必要がある、または対処する必要がある問題の最も重要な側面に焦点を当てます。 通常、問題によってユーザーの続行がブロックされた場合は、エラーとして提示する必要があります。ユーザーが続行できる場合は、警告として提示します。 そのフォーカスに基づいてメイン命令またはその他の対応するテキストを作成し、テキストに一致するアイコン (標準またはそれ以外の場合) を選択します。 メイン命令のテキストとアイコンは常に一致する必要があります。
エラー メッセージの表示
Windows プログラムのほとんどのエラー メッセージは、モーダル ダイアログ ボックス (この記事のほとんどの例と同様) を使用して表示されますが、他のオプションもあります。
モーダル ダイアログ ボックスにエラー メッセージを配置すると、ユーザーの即時の注意と確認を要求できるという利点があります。 ただし、これは、その注意が必要ない場合の主な欠点でもあります。
ユーザーが [閉じる] ボタンをクリックできるように、ユーザーを中断する必要はありますか? そうでない場合は、モーダル ダイアログ ボックスを使用する代わりの方法を検討してください。
モーダル ダイアログは、ユーザーが問題を続行する直前に確認する必要がある場合に最適な選択肢ですが、多くの場合、そうでない場合は不適切な選択です。 一般に、ジョブを適切に実行する最も軽量なプレゼンテーションを使用する必要があります。
過剰通信を避ける
一般に、 ユーザーは読み取らない、スキャンする。 テキストが多いほど、テキストのスキャンが困難になり、ユーザーがテキストをまったく読まない可能性が高くなります。 その結果、テキストを必須事項まで減らし、必要に応じて段階的な開示とヘルプ リンクを使用して追加情報を提供することが重要です。
多くの極端な例がありますが、もう 1 つの一般的な例を見てみましょう。 次の例では、適切なエラー メッセージのほとんどの属性がありますが、そのテキストは簡潔ではなく、読む動機が必要です。
正しくない:
この例は適切なエラー メッセージですが、オーバーコミットします。
このテキストは本当に何を言っていますか? 次のようなものです。
正確:
このエラー メッセージには基本的に同じ情報がありますが、はるかに簡潔です。
ヘルプを使用して詳細を指定すると、このエラー メッセージには 逆ピラミッド形式 のプレゼンテーションが表示されます。
過剰通信に関するその他のガイドラインと例については、「 ユーザー インターフェイス テキスト」を参照してください。
8 つのことだけを行う場合
使用パターン
エラー メッセージには、いくつかの使用パターンがあります。
Label | 値 |
---|---|
システムの問題 オペレーティング システム、ハードウェア デバイス、ネットワーク、またはプログラムが失敗したか、タスクの実行に必要な状態ではありません。 |
多くのシステムの問題は、ユーザーが解決できます。
![]() この例では、プログラムでユーザー タスクを実行するカメラが見つかりません。 ![]() この例では、タスクを実行するために必要な機能をオンにする必要があります。 |
ファイルの問題 ユーザーによって開始されたタスクに必要なファイルまたはフォルダーが見つからないか、既に使用されているか、予期される形式ではありません。 |
![]() この例では、ファイルまたはフォルダーが見つからなかったため、削除できません。 ![]() この例では、プログラムは指定されたファイル形式をサポートしていません。 |
セキュリティの問題 ユーザーには、リソースにアクセスするためのアクセス許可や、ユーザーによって開始されたタスクを実行するための十分な特権がありません。 |
![]() この例では、ユーザーはリソースにアクセスするためのアクセス許可を持っていません。 ![]() この例では、ユーザーにはタスクを実行する権限がありません。 |
タスクの問題 ユーザーによって開始されたタスクの実行には、特定の問題があります (システム、ファイルが見つからない、ファイル形式、またはセキュリティの問題以外)。 |
![]() この例では、クリップボード データをペイントに貼り付けることはできません。 ![]() この例では、ユーザーはソフトウェア アップグレードをインストールできません。 |
ユーザー入力の問題 ユーザーが、他のユーザー入力と間違っているか一貫性のない値を入力しました。 |
![]() この例では、ユーザーが正しくない時刻値を入力しました。 ![]() この例では、ユーザー入力が正しい形式ではありません。 |
正しくない:
この例では、制約のないテキスト ボックスを制約付き入力に使用します。 代わりにスライダーを使用します。
この例では、吹き出しは、コントロール内で入力の問題を示します。
この例では、コミット ボタンをクリックして見つかったエラーに対してインプレース エラーを使用します。
モーダル エラー メッセージ ダイアログにはタイトル バー アイコンがありません。 タイトル バー アイコンは、プライマリ ウィンドウとセカンダリ ウィンドウの視覚的な区別として使用されます。
エラー アイコンを使用します。 例外:
エラーがモーダル ダイアログ ボックスまたはバルーンを使用して表示されるユーザー入力の問題である場合は、アイコンを使用しないでください。 これは、Windows の励ましのトーンに反します。 ただし、インプレース エラー メッセージでは、小さなエラー アイコン (16 x 16 ピクセル) を使用して、エラー メッセージとして明確に識別する必要があります。
これらの例では、ユーザー入力の問題にエラー アイコンは必要ありません。
この例では、インプレース エラー メッセージには、エラー メッセージとして明確に識別するための小さなエラー アイコンが必要です。
(ユーザー入力の問題ではなく) アイコンを持つ機能に問題がある場合は、機能アイコンをエラー オーバーレイと共に使用できます。 これを行う場合は、エラーの件名として機能名も使用します。
この例では、機能アイコンにエラー オーバーレイがあり、機能がエラーの対象となります。
エラーには警告アイコンを使用しないでください。 これは、多くの場合、プレゼンテーションの厳しさを軽減するために行われます。 エラーは警告ではない。
正しくない:
この例では、警告アイコンが誤って使用され、エラーの深刻さが軽減されます。
その他のガイドラインと例については、「 標準アイコン」を参照してください。
この例では、プログレッシブ開示ボタンを使用すると、ユーザーが必要な場合は詳細にドリルダウンしたり、表示しない場合は UI を簡略化したりできます。
ラベル付けのガイドラインについては、「 プログレッシブ開示コントロール」を参照してください。
このメッセージを再度表示しない
その他のガイドラインについては、「 ダイアログ ボックス」を参照してください。
その他のガイドラインについては、「 ヘルプ」を参照してください。
正しくない:
この例では、ソリューション テキストの代わりにエラー コードが使用されます。
正確:
1234
0xC0001234
正しくない:
-1
-67113524
<error code>
。
この例では、エラー コードを使用して、詳細情報を利用できるエラー メッセージを補完します。
全般
正しくない:
正確:
これらの例では、正しいバージョンはユーザーの言語を話しますが、正しくないバージョンは過度に技術的です。
これらの用語は不要であり、Windows の励ましのトーンに反します。 正しく使用すると、エラー アイコンは問題があることを十分に伝えています。
正しくない:
正確:
正しくない例では、"致命的" と "失敗" という用語は不要です。
正しくない:
正確:
正しくない例では、アクティブな音声を使用してユーザーの責任を負います。
正しくない:
ファイルが見つかりません。
ディスクの空き容量が不足しています。
値が範囲外です。
文字が無効です。
デバイスを使用できません。
これらの問題は、特定の名前、場所、値で解決する方がはるかに簡単です。
正確:
Windows がコンピューターにファイルをコピーするまで待ってください。
正確:
申し訳ございませんが、Fabrikam Backup で回復不可能な問題が検出され、コンピューター上のファイルを保護するためにシャットダウンされました。
正しくない:
正確:
正しくない例では、完全な製品名と商標記号が使用されています。
正確:
この例では、オブジェクト名が引用符で囲まれていない場合、エラー メッセージは混乱します。
その他のガイドラインと例については、「 スタイルとトーン」を参照してください。
タイトル
正しくない:
この例では、タイトルを誤って使用して問題を説明しています。
主要な命令
正しくない:
この例では、エラー メッセージ全体がメイン命令に配置され、読みにくくなっています。
この例では、ファイル名のみが メイン 命令に含まれています。 完全なパスは補足命令にあります。
この例では、ユーザーは Windows エクスプローラーからファイルの名前を変更しています。 この場合、コンテキストから明らかなため、完全なファイル パスは必要ありません。
主な命令テンプレート
フレージングには厳密な規則はありませんが、可能な限り次のメイン命令テンプレートを使用してみてください。
もちろん、メインの指示が文法的に正しく、メインの指示ガイドラインに準拠するように、必要に応じて変更を加えます。
補足説明
正しくない:
この例では、問題とその推奨される解決策が可能ですが、可能性は非常に低いです。
この例では、補足命令は必要ありません。この解決策は、問題ステートメントから簡単に推測できます。
正確:
Windows を再起動するには、[OK] をクリックします。
正しくない:
[OK] をクリックして Windows を再起動します。
正しくない例では、ユーザーは誤って [OK] をクリックする可能性が高くなります。
正しくない:
この例では、ユーザーのネットワーク接続に問題がある可能性が高いので、管理者に連絡する価値はありません。
正しくない:
この例では、エラー メッセージがテクニカル サポートに連絡することを誤って推奨しています。
コミット ボタン
エラーを参照する場合:
例: ドライブ メッセージに CD ディスクがない場合は、ドライブに 新しい CD ディスクを挿入して、もう一度やり直してください。
トレーニング
モジュール
Dynamics 365 Business Central でのアプリケーション言語を使用したエラー処理 - Training
Dynamics 365 Business Central でアプリケーション言語 (AL) を使用してエラーを処理する方法を学びます。
ドキュメント
警告メッセージは、モーダル ダイアログ ボックス、インプレース メッセージ、通知、またはバルーンであり、将来問題が発生する可能性のある条件をユーザーに通知します。
メッセージは、ユーザーがアプリを使用する場合に必要な、または表示する必要があるあらゆる種類のメッセージです。 アプリでエラー、警告、確認、通知を表示する方法について説明します。
確認は、ユーザーがアクションを続行するかどうかを確認するモーダル ダイアログ ボックスです。
通知は、通知領域のアイコンから吹き出しを簡単に表示することで、現在のユーザー アクティビティとは無関係のイベントをユーザーに通知します。