緊急通報

ユーザーに代わって、未対応の緊急通報インシデントを確認済みにします。ユーザーが対応中であることを記録し、それ以上のエスカレーションを止めることができます。確認済みにできるのは未対応（open）のインシデントのみです。

必ず最初に確認してください。 confirm なしで呼び出してインシデントを取得し、何を確認済みにするのかをユーザーに伝え、同意を得てから confirm: true を付けて再度呼び出してください。

ワークフロー内やエージェントから使う場合は、施設の対応計画でワークフローによるアラームの確認、解決、発報が許可されている場合にのみ機能します。インシデントをクローズするには duress_resolve_incident を使用します。

施設の緊急通報ボタンを読み取ります。ステータス（バッテリー、最後の受信、最後のテスト）、完全なプロフィール（ラベル、部屋、ゾーン、設置方法、連携したカメラ、ドア、スクリーン、ミュート中のアラート、監視の状態）、連携できる対象、押下を中継するスクリーン、新しく追加したボタンのセットアップテストが含まれます。

バッテリー: low は 30% 以下（早めに交換）、critical は 20% 以下（すぐに交換）です。battery と lastSeenAt が null の場合は、まだどのスクリーンもボタンを受信していません。時刻は ISO 形式です。

Actions:

• status: ボタンのステータスです。各ボタンのゾーン、部屋、バッテリー、スクリーンが最後に受信した日時、最後にテストした日時を返します。「緊急通報ボタンは動作していますか？」「どのボタンの電池交換が必要ですか？」
• list: ボタンのプロフィールです。各ボタンの完全なプロフィール（duress_buttons_write の update で変更できる項目）に加え、信号、過去 1 日間に受信したスクリーン、監視の状態、待機中のセットアップテストを返します。
• link_options: 連携オプションです。ボタンと連携できる施設のカメラ、ドア、スクリーン、アクセスゾーン（duress_buttons_write の update で使う ID）を返します。
• receivers: ボタンの受信機です。ボタンの信号を受信して押下を中継する施設のディスプレイスクリーンと、それぞれがオンラインかどうかを返します。ボタンを受信できるものがない場合、ready は false です。
• setup_test: セットアップテストです。新しく追加したボタンのセットアップテストの状態（waiting（最初の押下はテストのみ）、received、expired、ended、none）と、追加後にスクリーンが受信したかどうかを返します。deviceSerialNumber が必要です。

施設の緊急通報ボタンを変更します。新しいボタンの追加、プロフィール（ラベル、部屋、ゾーン、設置方法、メモ、連携したカメラ、ドア、スクリーン、アクセスゾーン、ミュート中のデバイスアラート）の変更、スタッフが見つけられるようにボタンを鳴らす操作、新しいボタンのセットアップテストを終了して運用を開始する操作、ボタンの削除を行えます。

update で指定しなかったフィールドは値を維持し、null を指定するとクリアされます。現在のプロフィールは duress_buttons_read の list で確認してください。

Actions:

• update: ボタンを更新します。ボタンが登録されている施設でプロフィールを保存します（その施設で緊急通報設定の権限が必要です）。zone は 001～999 で、施設内で一意である必要があります。alertsMutedUntil（ISO、最大 30 日先）を指定すると、バッテリーとオフラインのアラートをミュートします。deviceSerialNumber が必要です。
• locate: ボタンを鳴らします。スタッフが見つけられるように、ボタンを 30 秒間鳴らして点滅させます（バッテリー低下を報告し続けるボタンなど）。近くのスクリーンがコマンドを送信するため、スクリーンの受信範囲内にある必要があります。未対応のアラームがある間は使用できません。deviceSerialNumber が必要です。
• go_live: 新しいボタンの運用を開始します。新しく追加したボタンのセットアップテストを今すぐ終了し、次の押下から実際のアラームになります。先に duress_buttons_read の setup_test で確認してください。施設でデバイス管理または緊急通報設定の権限が必要です。deviceSerialNumber が必要です。確認を求めます。
• remove: ボタンを削除します。ボタンと施設のペアリングを解除してプロフィールを削除し、ゾーンを解放します。未対応のアラームがある間は使用できません。施設でデバイス管理が必要です。deviceSerialNumber が必要です。確認を求めます。
• add: ボタンを追加します。ボタンに印字されたシリアル番号で、新しい緊急通報ボタンを施設に登録します。既定では、今後 30 分以内の最初の押下はテストのみになります（setupTest）。施設には、緊急アラームの監視がオンのスクリーン、または IoTゲートウェイが必要です。施設でデバイス管理が必要です。deviceSerialNumber が必要です。確認を求めます。

施設で実行中の緊急通報テストを今すぐ終了し、次の押下から実際のアラームになります。結果は、通常のテストと同様に約 10 分後に届きます。

緊急通報アラームのインシデント（スタッフが緊急通報ボタンを押した、またはワークフローが発報したもの）を読み取ります。一覧、1 つのインシデントのタイムラインと配信、事後分析レポート、アラーム前後の CCTV 映像を取得できます。

ステータス: open（まだ誰も確認していない）、acknowledged（誰かが対応中）、resolved（クローズ済み。disposition は genuine、false_alarm、test、unknown のいずれか）。active は open または acknowledged を意味します。テストのインシデント（isTest）はボタンテストによるものです。testType 'unplanned' は、実際のアラームとして発報され、対応者がテストとして解決したものです。

配信ステータス: sent、acknowledged（受信者が確認済み）、failed（error を参照）、shadow（ドライラン。何も送信されていない）。監視センターへの配信は monitoringCentre にも集計されます。結果には人の名前が含まれますが、電話番号やメールアドレスは含まれません。時刻は ISO 形式です。

Actions:

• list: インシデントを一覧表示します。新しい順に並びます。scope: facility（既定。指定した施設または接続中の施設）または organisation（参照できる組織内のすべての施設。既定は施設の組織）。
• get: インシデントを取得します。ステータス、押されたボタン、タイムライン（押下、エスカレーション、確認、メモ）、すべての通知または監視センターへの配信試行とその結果を返します。incidentId が必要です。
• report: インシデントレポートです。事後分析用に、インシデント、確認と解決までの秒数、到達したステップ、すべてのタイムラインエントリー、チャネルごとの送信内容と失敗した内容、映像が保持されたかどうかを返します。duress_incidents_write の add_note と組み合わせて、事後分析をインシデントに記録できます。incidentId が必要です。
• footage_previews: アラーム映像です。アラーム映像に含まれる各カメラのステータス、フレーム数とクリップ数、アップロード済みのクリップ、押下に最も近いフレーム（posterSeconds）を返します。cameraId を指定すると、そのカメラのみと、すべてのフレームの Unix 秒（frameSeconds）を返します。施設で CCTV が必要です。incidentId が必要です。
• footage_frame: アラーム映像のフレームです。アラーム映像からタイムラプスのフレームを 1 つ画像として返します。映像が保持されている場合は保持されたコピー、それ以外の場合はアラームの時間枠内のライブフレームです。seconds には footage_previews で取得した posterSeconds または frameSeconds の値を指定します。incidentId、cameraId、seconds が必要です。

アラーム自体には触れずに、緊急通報インシデントを変更します。名前の設定、スタッフのメモの追加、前後の CCTV 映像の保持または解放を行えます。誰にも通知されません。確認、解決、対応者への連絡には、duress_acknowledge_incident、duress_resolve_incident、duress_post_update を使用します。

Actions:

• rename: インシデントに名前を付けます。後で見つけやすいようにインシデントに名前を付けます（例: "正面カウンターでの攻撃的な来訪者"）。空または null の名前を指定すると名前が削除されます。名前は緊急通報コンソールとレポートに表示されます。incidentId が必要です。
• add_note: メモを追加します。インシデントのタイムラインにメモ（ユーザーが確認した内容や対応した人など）を追加します。どのステータスでも追加できます。メモはスタッフのみに表示され、インシデントは変更されません。ユーザーの言葉で書き、先に文言をユーザーに確認してください。incidentId と note が必要です。
• keep_footage: アラーム映像を保持します。解決済みの実際のアラームの前後の CCTV 映像を、通常の録画とともに削除されないように、対応計画の分数とカメラを使って保持します。アップロード後、数分以内に実行されます。テスト、未対応のアラーム、すでに保持または解放された映像には使用できません。incidentId が必要です。
• release_footage: 保持した映像を解放します。アラーム用に保持した映像を放棄します。クリップは通常の保持期間に戻り、保持したフレームは削除されるため、通常の録画の期限が切れると閲覧できなくなります。施設で緊急通報設定の権限が必要です。incidentId が必要です。確認を求めます。

緊急通報アラームのロックダウンを解除します。ロックされたドアから再び入れるようになります。アラームのステータスに関係なく機能します。

最初に確認してください。 confirm なしで呼び出してロックダウンを確認し、ユーザーに伝え、同意を得てから confirm: true を付けて再度呼び出してください。

緊急通報アラームに対応している人々に最新情報を投稿します（例: "警察が向かっています"、"安全が確認されました。対象者は立ち去りました"）。投稿は対応者のアラームページと緊急通報アプリに表示され、実際のアラームの場合は、対応計画により、そのアラームについてすでに SMS を受け取った全員に SMS で送信することもできます。最新情報は、アラームの解決後 24 時間まで投稿できます。

最初に確認してください。 confirm なしで呼び出してインシデントを確認し、正確な文言をユーザーに示し、同意を得てから confirm: true を付けて再度呼び出してください。スタッフのみが見るべき内容には、代わりに duress_incidents_write の add_note を使用します。

ボタンが押されたときと同様に、施設で実際の緊急通報アラームを発報します。対応計画が実行され（関係者への通知、エスカレーションとリマインダー、対応アクションの実行）、アラームにはこのワークフローによって理由とともに発報されたことが表示されます。

• reason: 何が起きたか。例: "裏口のドアがこじ開けられました"（最大 200 文字）。
• deviceSerialNumber: 任意。位置情報として使うボタンです。指定した場合にのみ、そのボタンのゾーンとともに監視センターにも通知されます。

対応計画でワークフローによるアラームの確認、解決、発報が許可されている施設で、ワークフローのステップとしてのみ使用できます。このワークフローのアラームが未対応の間は新たに発報せず、代わりにそのアラームを返します。

施設、ブランド、または組織の緊急通報のコンプライアンスレポートです。対応時間（P50/P95）、disposition 別のインシデントと誤報率、テストの実施率と期限切れの施設、ボタンの稼働率、監視センターへの配信成功率、インシデントごとのエクスポートが含まれます。さらに、1 つの施設の最新アラームで未配信のアラートも取得できます。

日付は施設の現地時間で、400 日を超える期間は短縮されます（range.capped）。実際のインシデントとテストのインシデントは別々に集計されます。期間はミリ秒単位です（p50Ms、p95Ms）。ブランドのレポートは、組織全体へのアクセス権がない限り、アクセスできる施設のみが対象です（scope.restrictedToAccessibleFacilities）。

Actions:

• overview: 緊急通報レポートの概要です。合計、月別の推移、組織別、ブランド別、施設別の指標（incidents、testCoverage、deviceUptime、deliveries）を返します。施設はページング対応です。
• compliance_summary: 緊急通報のコンプライアンスの概要です。コンプライアンス PDF の内容として、期限切れの施設を含むテストの実施率、ボタンの稼働率、配信成功率、最近のテスト（testHistory）、施設ごとの最後のテスト、訓練、実際のアラームと各ボタンの稼働率を返します。施設はページング対応です。
• incident_export: 緊急通報インシデントのエクスポートです。インシデントごとに 1 行、古い順に、CSV エクスポートと同じ列（施設、テストか実際か、ステータス、disposition、現地時刻、確認と解決までの秒数、確認者と解決者、ボタン、配信数）を返します。
• delivery_problems: 未配信のアラームアラートです。施設の最新のアラームまたはテスト（テストの時間枠全体を含む）と、届かなかったアラートをチャネル別に返します。すべて届いた場合、problems は null です。その施設で緊急通報または緊急通報設定の権限が必要です。

緊急通報インシデントを解決します。アラームをクローズし、エスカレーションを止め、結果を記録します。未対応と確認済みのインシデントを解決できます。

• disposition: genuine（実際の緊急事態）、false_alarm、test、unknown のいずれか。
• note: 何が起きたか。実際のアラームの場合は必須です。

必ず最初に確認してください。 confirm なしで呼び出してインシデントを取得し、どのアラームをどの結果でクローズするのかをユーザーに伝え、同意を得てから confirm: true を付けて再度呼び出してください。

ワークフロー内やエージェントから使う場合は、施設の対応計画でワークフローによるアラームの確認、解決、発報が許可されている場合にのみ機能します。

緊急通報の設定を読み取ります。対応計画（施設またはブランドのテンプレートで、誰に、どの順序で、どの方法で通知するか）、アラームエンジンが実際に使う解決済みの計画、追加できる人とロール、デバイスアラート（バッテリー、オフライン、受信範囲、配信の問題）、ブランドの連絡先ルールと計画のステータス、ブランドまたは組織のボタンの概要、アラームを監視センターに送る方法が含まれます。

施設は、ブランドの（なければ組織の）テンプレートに従うか、追加の連絡先で拡張するか（mode extend）、独自の計画に置き換えます（mode replace）。設定の変更は duress_settings_write で行います。時刻は ISO 形式です。

Actions:

• response_plan: 対応計画です。施設で適用されている計画（effective）と各レベルの内容（sources: facility、brand、organisation）、または brandId のみを指定した場合はブランドのテンプレートを返します。連絡先は保存されたとおりの形式で、そのまま編集して保存し直せます。
• resolved_plan: 解決済みの計画です。施設でアラームエンジンが連絡する相手を段階ごとに返します。ロールは人に展開され、各人に連絡できるチャネル、遅延、アラームの前に修正すべき警告が含まれます。名前のみで、電話番号やメールアドレスは含まれません。
• contact_options: 連絡先オプションです。施設の計画（その施設で緊急通報設定の権限が必要）、または brandId のみを指定した場合はブランドのテンプレートに、ブランドの連絡先ルールを適用したうえで追加できる人とロールを返します。
• device_alerts: デバイスアラートです。バッテリー低下、オフラインのボタン、受信範囲の喪失、配信の失敗について誰に通知するか（各レベルのルールと施設の解決済みの受信者）、または brandId のみを指定した場合はブランドのルールを返します。
• contact_rules: ブランドの連絡先ルールです。ブランド内の施設が計画に追加できるロールを返します。allowAllExcept は一覧のロールを非表示にし、manual は一覧のロールのみを提示します。ブランドの計画の編集と同じ権限が必要です。brandId が必要です。
• plan_status: ブランドの計画のステータスです。ブランド内の各施設について、テンプレートに従っているか、拡張しているか、独自の計画を持っているか、追加した連絡先の数、計画の警告を返します。brandId が必要です。
• buttons_summary: ボタンの概要です。ブランドまたは組織内のすべての施設について、ボタン数、バッテリーとオフラインの件数、次回と前回のテストを返します。ブランドとカスタマイズおよび組織の概要のデータです。
• monitoring: 監視センターへのルーティングです。アラームを施設から送る方法として、eaAlarmType が none、cid（eaAlarmProvider を経由した監視センターへの通報）、relay（eaRelayModel を経由した有線パネル）のいずれかと、使用できるプロバイダーを返します。

緊急通報の設定を変更します。対応計画（施設、またはブランドや組織のテンプレート）、デバイスアラート、ブランドの連絡先ルール、アラームを監視センターに送る方法が対象です。通知される相手が変わるため、すべての変更で確認を求めます。

facilityId（既定: 接続中の施設）、brandId、organisationId のいずれかを指定します。施設の計画には、その施設で緊急通報設定の権限が必要です。テンプレートには、緊急通報設定の権限を持つ組織管理者、またはブランドの場合はそのブランド内のすべての施設での緊急通報設定の権限が必要です。先に duress_settings_read で読み取ってください。

Actions:

• save_response_plan: 対応計画を保存します。押下から afterSeconds 後に通知される連絡先の段階（昇順。通常、最初は 0）、ackRequired、reminders、responseActions を設定します。施設は代わりに、追加分でテンプレートを拡張することもできます（mode extend）。指定しなかったフィールドは保存済みの値を維持し、responseActions はアクションごとにマージされます。確認を求めます。
• remove_response_plan: 対応計画を削除します。このレベルで保存された計画を削除します。施設は再びテンプレートに従い、ブランドは組織のテンプレートに戻ります。確認を求めます。
• save_device_alerts: デバイスアラートを保存します。このレベルのデバイスアラートのルールを置き換えます。ルールは最大 10 件で、それぞれがイベントと連絡先（push、sms、email）のセットです。duress_settings_read の device_alerts で読み取ったルール ID を維持してください。rules が必要です。確認を求めます。
• remove_device_alerts: デバイスアラートを削除します。このレベルのデバイスアラートのルールを削除し、再び 1 つ上のレベルに従うようにします。確認を求めます。
• save_contact_rules: ブランドの連絡先ルールを保存します。ブランドの施設が計画に追加できるロールを設定します。allowAllExcept は roleIds を非表示にし、manual は roleIds のみを提示します。すでに保存されている連絡先は残り、解決済みの計画は更新されます。brandId、mode、roleIds が必要です。確認を求めます。
• save_monitoring: 監視センターへのルーティングを保存します。アラームの送信先として、eaAlarmType に none、cid（duress_settings_read の monitoring に一覧表示されるプロバイダーの 1 つを eaAlarmProvider に指定）、relay（eaRelayModel）のいずれかを設定します。施設で緊急通報設定の権限が必要です。eaAlarmType が必要です。確認を求めます。

緊急通報アラームのために施設をロックダウンします。ロックダウンが解除されるまで（duress_lift_lockdown またはコンソールから）、すべてのドアから入れなくなります。1 つのアラームで実行できるロックダウンは 1 回だけです。

テストまたは解決済みのアラームには使用しないでください。施設でドア/ゲートアクセスが必要です。

最初に確認してください。 confirm なしで呼び出してインシデントを確認し、すべてのドアがロックされることをユーザーに伝え、同意を得てから confirm: true を付けて再度呼び出してください。

施設で緊急通報テストを今すぐ開始します。終了するまで、すべての押下は実際のアラームではなくテストになります:

• walk: スタッフが各ボタンを押します。対応計画の最初のステップのみに TEST と表示して通知されます。
• drill: 対応計画全体が TEST と表示して実行されます。

施設のテスト連絡先には開始が通知され、終了から約 10 分後に結果が届きます。テストは施設ごとに一度に 1 つだけです。早めに終了するには duress_end_test を、事前にテストを予約するには duress_tests_write を使用します。

最初に確認してください。 confirm なしで呼び出し、durationMinutes の間は押下で実際のアラームが発報されないことをユーザーに伝え、同意を得てから confirm: true を付けて再度呼び出してください。ワークフロー内やエージェントから使う場合は、施設の対応計画でワークフローによるアラームの確認、解決、発報が許可されている場合にのみ機能します。

緊急通報ボタンのテストを読み取ります。テストを予約するスケジュール（walk、comms、drill。1 回限りまたは繰り返し。組織、ブランド、施設が対象）、各施設で作成されるテストの時間枠（scheduled、active、completed、cancelled、および臨時のテスト）、時間枠の結果（押されたボタンと押されなかったボタン、通知された相手、監視センターの信号、確認時刻）が含まれます。

テストを予約、変更、キャンセルした人は含まれず、配信の受信者は伏せられます。時刻は ISO 形式で、localDate と localStartTime は施設のタイムゾーンです。テストの予約や変更は duress_tests_write で、今すぐ開始するには duress_start_test を使用します。

Actions:

• schedules: Test schedules です。scope に facility（既定。その施設が対象となるすべてのスケジュールで、施設がスキップまたは置き換える共有スケジュールも含む）、brand（brandId）、organisation（既定: 施設の組織）を指定します。最近変更されたものから順に並びます。
• windows: テストの時間枠です。施設の from から to までのテストの時間枠（既定は約 1 週間前から 1 か月先まで）、または organisationId のみを指定した場合は、組織の施設全体の今後の時間枠を返します。
• results: テストの結果です。時間枠とその結果を返します。送信後は保存された結果、テスト実行中はリアルタイムで計算された結果（walk テストのチェックリスト）、スケジュール済みまたはキャンセルされた時間枠の場合は null です。施設で緊急通報が必要です。startsAtKey が必要です。

緊急通報テストのスケジュールを予約、変更、キャンセルし、1つの施設が共有スケジュールにどう従うかを設定し、今後のテスト時間枠を1つだけキャンセルします。どの変更も今後の時間枠を予約または書き換え、関係者にメールを送信するため、いずれも確認を求めます。

スケジュールには、対象全体に対する Duress Configuration が必要です（組織全体のスケジュールには組織管理者が必要です）。時刻は各施設のタイムゾーンです。まず duress_tests_read でスケジュールと時間枠を確認してください。今すぐテストを開始するには duress_start_test を使用します。

アクション:

• create_schedule: テストスケジュールを予約します。target 内のすべての施設で約1年先までの時間枠を予約し、予約確認メールを送信します。name、type、target、startDate、localStartTime、recurrence が必要です。name、type、target、startDate、localStartTime、recurrence が必要です。確認を求めます。
• update_schedule: テストスケジュールを変更します。省略したフィールドは現在の値のままです。今後の時間枠は書き換えられ（開始済みのものはそのまま）、関係者に変更通知が届きます。以降は結果に含まれる ownerScope を使用してください。ownerScope、scheduleId が必要です。確認を求めます。
• cancel_schedule: テストスケジュールをキャンセルします。スケジュールとその今後の時間枠をキャンセルし、キャンセルをメールで通知します。独自のコピーを持つ施設ではそのコピーが残ります。ownerScope、scheduleId が必要です。確認を求めます。
• set_facility_override: 1つの施設について共有スケジュールを変更します。mode は follow（この施設で再び共有スケジュールを実行）、skip（この施設では停止）、own（この施設では schedule から作成したコピーに置き換え）のいずれかです。その施設での Duress Configuration のみが必要です。ownerScope、scheduleId、mode が必要です。確認を求めます。
• cancel_window: テスト時間枠を1つキャンセルします。施設で予定されているテストを1つキャンセルし（スケジュールは継続します）、その関係者にメールを送信します。施設での緊急通報の権限が必要です。実施中のテストは代わりに duress_end_test で終了します。startsAtKey が必要です。確認を求めます。

警察や救護者を入れるためなど、緊急アラームに対してドアを解錠します。対象は押されたボタンに紐付いたドア、それがなければ対応計画のドアです。すべてを解錠するには doorIds を省略し、一部だけの場合はそれらを列挙します。各解錠はインシデントのタイムラインとアクセスログに記録されます。

テストアラームや解決済みのアラームには使用しないでください。施設でのドア/ゲートアクセスの権限が必要です。

まず確認してください。 confirm なしで呼び出して解錠されるドアを確認し、ユーザーに伝えたうえで、同意を得たら confirm: true を付けて再度呼び出します。