---
title: "ポリシーサービスに接続して自動通知を設定する方法"
description: "サービス接続、管理者の同意、通知チャネル、キャンペーン予定を設定し、管理された試験でバックグラウンド動作を検証します。"
url: https://vitextra.com/ja/support/kb/10525
language: ja
published: 2026-11-08
modified: 2026-11-08
products:
  - "Policy Acknowledgement"
author: "Lidija Reising"
tags: ["ポリシーリマインダーサービス", "自動通知", "管理者の同意", "エスカレーション", "常時実行キャンペーン"]
---

# ポリシーサービスに接続して自動通知を設定する方法

サービス接続、管理者の同意、通知チャネル、キャンペーン予定を設定し、管理された試験でバックグラウンド動作を検証します。

対象者の自動更新、定期リマインダー、エスカレーションには、別のPolicy Acknowledgementサービスコンポーネントが必要です。Policy Adminは接続と通知の設定を保存し、サービスに同意状況を問い合わせることができます。これらのコントロールでサービスが展開されるわけではなく、すべてのバックグラウンドジョブの動作も証明されません。

## サービスの前提条件を揃える

製品管理者アカウントを使用し、そのコンポーネントを担当する組織または提供元から、サービスエンドポイントと展開手順を入手します。フィールドのサンプルアドレスを、準備済みのテナントエンドポイントとみなさないでください。サービスの可用性、アプリケーション権限、配信のトラブルシューティングを誰が管理するか確認します。

SPFx API権限の承認とサービスの管理者同意は別の手順です。まず製品のインストール要件を完了します。サービスが提供またはテストされていない場合、保存されたキャンペーン設定を稼働中の自動化と説明するのではなく、定期動作が利用できないことを記録してください。

## 接続して同意を確認する

1. Policy Adminを開き、**通知**を選択します。
2. **リマインダーサービスURL**に発行されたサービスURLを入力します。
3. **管理者の同意ページを開く**を選択し、権限を持つ管理者でテナントの同意プロセスを完了します。
4. 戻って**同意の確認**を選択します。
5. 結果を確認して設定を保存します。

クライアントはテナント識別子を付けてサービスの`/consent`ルートを開き、`/api/status`に状態を要求します。肯定的な`consentGranted`応答を期待し、報告された`lastRun`を保存できます。これらはクライアントで確認できる統合上の期待値であり、検証済みのサーバー実装の説明ではありません。

![サービス接続と通知設定の確認](https://static.vitextra.com/articles/10525/service-settings-ja.png)
*サービス接続と通知設定の確認*

## チャネルと予定を設定する

**電子メール**、**Microsoft Teams (アクティビティフィードとボット)**、**通知を停止する時間帯の開始（時）**、**通知を停止する時間帯の終了（時）**、**送信者のメールアドレス**を確認します。時刻は0～23の範囲で、通知を控える時間帯の実際の動作はサービスに依存します。ブラウザの設定自体が配信を抑止すると考えず、サービスのタイムゾーン処理を検証してください。

各キャンペーンで、割り当て時通知、期限前の日数、期日通知、期限超過後の繰り返しリマインダー、エスカレーション閾値を確認します。Webパーツはこれらの値を保存します。実際のタイミング、繰り返し抑制、エスカレーション先は、それらを実行するサービスで確認する必要があります。

Teamsへの配信が必要な場合は、必要なアプリを展開し、配信コンポーネントを検証します。**Teams アプリがテナントに追加されました**スイッチは保存されたフラグであり、インストール操作やボットの存在を証明するものではありません。[KB10511. My PoliciesをMicrosoft Teamsに追加する方法](https://vitextra.com/ja/support/kb/10511)を参照してください。Team Complianceの手動メールは別の機能で、これらのサービススイッチには従いません。[KB10524. チームに手動のポリシーリマインダーを送信する方法](https://vitextra.com/ja/support/kb/10524)を参照してください。

## 確認の記録方法を選ぶ

**閲覧確認の記録方法**をチャネル設定とは独立して設定します。Serviceモードに切り替える場合、サービスが試験用の確認を記録できることを確かめてから、**役割**で**保存して権限を適用する**を使ってロール権限を再適用します。モードを保存するだけでは権限は同期されません。保護モデルに依存する前に[KB10509. Policy Acknowledgementのデータ保存：DirectモードとServiceモード](https://vitextra.com/ja/support/kb/10509)を確認してください。

## 設定の証拠と運用の証拠を区別する

クライアントは、設定が保存され、状態エンドポイントが応答を返したことを示せます。これらが答えるのは「サービスが動く」より狭い問いです。どのジョブが展開され、どのアカウントやアプリ権限を使い、失敗した実行をどこで診断できるかをサービス所有者と合意します。Webパーツ画面はサーバー側の全詳細を提供しません。

| 観察 | 裏付けること | まだ必要なテスト |
|---|---|---|
| エンドポイント保存済み | クライアントに呼び出すアドレスがある。 | 可用性、認証、要求した操作。 |
| 同意が付与済みと報告 | 状態応答が同意を報告する。 | 正常な書き込みと必要なジョブの実行。 |
| 最終実行値が表示 | サービスが実行関連の値を提供した。 | どのジョブが、どのキャンペーンを処理し、どう終わったか。 |
| 通知設定が有効 | 要求チャネルが設定された。 | 意図する受信者への実際の配信。 |
| 割り当て作成済み | ハブに従業員の作業が存在する。 | 通知が送信・受信されたか。 |

必要な各機能について簡単な受け入れ記録を残します。たとえば、従業員の受領証は確認経路をテストし、定期リマインダーは別の操作をテストします。一つの経路の成功を、証拠なしに別の経路の承認へ使うべきではありません。

## 後の対象者変更を意図的にテストする

常時実行のシナリオでは、まず初回開始を完了して検証します。その後、適格なテスト従業員に管理された所属変更を行い、それを検出すべき処理実行をサービス所有者に特定してもらいます。作成された割り当てのポリシーバージョン、アカウント、期限を確認し、既存の同じバージョンの割り当てで重複を防ぐべきか調べます。

これは展開の受け入れ手順であり、クライアントがメンバーシップのスケジューラーを動かすという主張ではありません。割り当てが出なければ、「ジョブが実行されなかった」「ユーザーが除外された」「重複が正しくスキップされた」を区別します。キャンペーンを繰り返し作り直す前に関連データを調べます。

通知にも同じ方法を使います。期待するチャネル、受信者、予定を記録し、サービス実行と配信結果を比較します。ユーザーのメールボックスからの手動リマインダーは別の経路で、自動通知設定が機能していることを証明できません。

## 受け入れ確認を行う

既知の受信者による小規模なキャンペーンをテストします。初回の割り当て、定期リマインダー、常時実行が必要な場合は管理された対象者追加、使用する場合は期限超過のエスカレーションを検証します。予定時刻、実際の結果、サービスが報告する実行情報を記録します。メールとTeamsは別々にテストします。

❗ **重要**  
同意チェックの成功は、スケジューラーの健全性、メッセージ配信、証跡保護を証明しません。最終実行の値がない、または古い場合もサービス所有者による解釈が必要です。Webパーツのプロジェクトには別のサーバー実装がなかったため、その権限、スケジュール処理、失敗からの復旧は展開環境で検証する必要があります。

確認に失敗した場合は、設定とエラーの詳細を保持し、サービス所有者に連絡します。失敗した操作を特定せずに、同意、記録モード、権限を繰り返し変更しないでください。記録の失敗と通知の失敗を分けるには[KB10538. 確認の失敗と通知が届かない問題を解決する](https://vitextra.com/ja/support/kb/10538)を使用します。