確認の失敗と通知の未着は、独立して発生することがあります。メールを受け取っていなくても従業員に有効な割り当てがある場合や、確認要求が証跡を書き込んだ後に後続処理が失敗する場合があります。再試行や書き込みモードの変更前に、どの操作が失敗したかを特定してください。
失敗時の情報を保存する
ハブ、従業員アカウント、ポリシーバージョン、割り当て識別子、エラー文、概算時刻を記録します。エラーの前に受領証や成功メッセージが表示されたかを従業員に確認します。My Policies を再読み込みし、割り当てを再度開いて現在の状態を調べます。最初の要求が処理中の間は、繰り返しクリックしないでください。
通知の問題では、期待していたものが手動リマインダー、自動メール、Teams 通知のどれかを特定します。予定の受信者、キャンペーン、時刻を記録してください。これらはすべて同じ送信者や実装を使用するわけではありません。
確認の失敗を診断する
直接モードでは、ブラウザーが直前のハッシュを読み取り、確認レコードを追加した後、割り当てを更新します。これらの書き込みは別々です。権限、接続、リストのエラーで処理が中断されると、証跡があるのに期待する割り当て状態になっていない場合があります。
サービスモードでは、ブラウザーがサービス接続を使用して設定済みの /api/acknowledge エンドポイントに POST し、その後 SharePoint から作成されたレコードを読み取ります。サービスの可用性、認証、同意、応答形式、保存済みレコードへのアクセスなどによって要求が失敗する場合があります。サービスで正常に書き込まれた後の読み取り失敗は、要求がサービスに到達しなかった場合とは異なります。
管理者は、アカウント、ポリシーバージョン、時刻を手掛かりに、割り当ての確認参照と状態を対応する証跡レコードと比較します。再試行を問題のない状態に見せるために、証跡ハッシュを編集したりレコードを削除したりしないでください。部分保存が確認された場合は、ハブまたはサービスの責任者と管理された修正方法を合意します。

❗ 重要
サービス要求が失敗しても、自動的に直接書き込みへ切り替わることはありません。モード変更は権限と証跡の書き込み経路を変えるため、無害な再試行方法ではありません。最初の操作が部分的に成功している場合、再送信によって追加の証跡が作成されることもあります。
手動リマインダーの未着を診断する
期限超過の手動リマインダーは、サインイン中のユーザーのメールボックスから送信されます。そのアカウントがメールを送信できるか確認し、可能であれば送信済みメッセージを調べます。自動通知用に設定された送信者や通知停止時間帯は、この手動経路を制御しません。
メッセージは割り当てごとに順番に送信されます。一括操作では、一部を送信した後で失敗する場合があります。また、送信後に監査書き込みが失敗することもあります。操作全体を繰り返す前に、処理済みの受信者や割り当てを特定してください。手動リマインダーの手順と制限は KB10524. チームに手動のポリシーリマインダーを送信する方法 を参照してください。
自動メッセージの未着を診断する
- 想定した割り当てが存在することを確認します。対象者プレビューはキャンペーン開始の完了を意味しません。
- 該当するメールまたは Teams の通知設定と、設定された通知停止時間帯を確認します。
- サービス URL と管理者同意の状態を確認します。
- 報告された最終実行情報を確認し、サービス所有者に実際のジョブと配信結果の調査を依頼します。
- 受信者アカウントを確認し、配信は割り当て作成とは別に調査します。
状態エンドポイントは同意と最終実行値を返すことがありますが、チェック成功は、このキャンペーンの通知ジョブが実行されたことやメッセージが配信されたことを証明しません。通知設定を保存しても、外部サービスはデプロイされません。付属の個人用 Teams アプリだけでは、通知ボットがインストールされているとは判断できません。
再試行前に表示された結果を照合する
| 観測した状況 | 管理者が確認すべきこと |
|---|---|
| 従業員は受領証を得たがキャンペーン件数が古い | まず割り当てと証跡の状態を確認します。件数更新は別操作です。 |
| 証跡イベントが存在するが割り当ては未完了 | 証跡書き込み後に割り当て更新が失敗したかを確認します。 |
| サービスは保存済みと報告するがリーダーにエラー | 返されたレコード識別子とクライアントがそれを読めるかを確認します。 |
| 一括エラーの前に一部の手動リマインダーが届いた | 失敗前にどの割り当てのメッセージを送ったかを確認します。 |
| 割り当ては存在するが自動メッセージが届かない | 割り当て作成とは別に、サービス実行と配信を確認します。 |
一つの指標からトランザクション全体の完了を推測しないでください。サービスログの成功、SharePoint の行、ブラウザーの受領証、更新されたキャンペーン件数は、それぞれ異なる段階を表します。複数のリリースで共通するタイトルだけでなく、割り当て、ポリシーバージョン、アカウント、時刻を使って照合してください。
二度目の送信をすでに試した場合は、その事実と概算時刻を管理者に伝えます。処理順序を調査する間はレコードを保存してください。重複に見える証跡イベントを削除すると、チェーンが壊れたり、元の失敗を理解するための情報が失われたりする場合があります。
サポートに渡す情報を整理する
失敗した操作、書き込みモード、ハブとページ、対象アカウント、ポリシーバージョン、割り当て識別子を伝えます。正確なエラーと、ソースを読めたか、送信ボタンが有効になったか、受領証が表示されたかも含めてください。サービスに関する場合は、責任者に時刻と要求・結果の照合を依頼します。認証トークンや秘密情報を引き継ぎ資料に含めないでください。
メッセージ未着の場合は、手動リマインダー、自動メール、Teams 配信のどの経路を期待したかを特定します。割り当て、送信者またはサービス実行について確認済みの内容を含めます。保存された通知設定は配信の証拠ではなく、一方のチャネルでの受信は他方の成功を証明しません。
特定した不具合を修正したら、一括操作を繰り返す前に、一件の管理された操作を試し、その全結果を調べます。原因と残存する部分レコードを理解可能な状態に保ちながら復旧を確認できます。再試行の成功によって以前の経緯の説明が失われないよう、元のインシデント情報を保存してください。
復旧を確認する
既知の割り当てを一つ使用し、正常な確認によって期待する受領証と割り当て状態が得られることを確認します。通知については、サービス所有者または送信者と予定した配信経路を確認し、その後、従業員が割り当てにアクセスできるかを確認します。元のエラーと部分書き込みの調査結果を調査記録に残してください。サービス設定は KB10525. ポリシーサービスに接続して自動通知を設定する方法、受領証の解釈は KB10526. 過去のポリシー確認と受領書を表示する方法 を参照してください。