> For the complete documentation index, see [llms.txt](https://library.zoom.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://library.zoom.com/technical-library/ja/zoom-workplace/zoom-phone/expert-insights/emergency-services-best-practices/appendix-u.s.regulatory-requirements-karis-law-and-ray-baums-act.md).

# 付録: 米国の規制要件 — Kari's Law と RAY BAUM'S Act

米国の連邦法2つが、マルチライン電話システム（MLTS）の緊急通話を規定しています。Zoom Phone は両方に準拠するよう設計されています。

#### Kari's Law（2018年）

Kari's Law は、ホテルの外部参加者が電話システムで外線用のプレフィックス（例：「9」）のダイヤルを必要としていたために 911 に到達できなかったインシデントを受けて制定されました。この法律は2つの主要な要件を定めています：

**要件1 - 緊急サービスに到達するためのプレフィックス不要。** マルチライン電話システム上の任意のユーザーは、プレフィックス、アクセスコード、またはポストフィックスをダイヤルせずに、911を直接ダイヤルできなければなりません。

**Zoom の準拠方法：** Zoom Phone は、ダイヤルプランの設定に関係なく、911（または国ごとに定義された任意の緊急番号）をデフォルトで緊急通話としてルーティングします。プレフィックスやポストフィックスは不要です。この動作はプラットフォームに組み込まれており、変更できません。

**要件2 - 指定された現地の連絡先に通知する。** 緊急通話が発信されると、システムは施設内の指定された連絡先（例：フロントデスク、セキュリティチーム、安全担当者）にリアルタイムの通知を送信する必要があります。

**Zoom の準拠方法：** Zoom Phone は、組み合わせ可能な4つの通知チャネルを提供します：メール配信リスト、Internal Safety Response Team のコールキュー、Zoom チャットのボットアラート、API Webhook です。これらはアカウントレベルまたはサイトごとに設定できます。

{% hint style="info" %}
**ヒント：** ダイヤル **933** （米国/カナダのみ）をダイヤルすると、実際の公共安全リソースを使用せずに、通知配信を含む緊急通話設定を検証する自動テストサービスに接続できます。
{% endhint %}

#### RAY BAUM'S Act（2019年）

RAY BAUM'S Act は Kari's Law を拡張し、すべての 911 通話に対して PSAP に「配信可能な位置情報」を送信することを義務付けています。配信可能な位置情報は、一次対応者が発信者を見つけられるよう十分に詳細でなければなりません。単なる住所ではなく、具体的な建物、階数、部屋またはスイートまで必要です。

**Zoom の準拠方法：** Zoom Phone は、各ユーザー、電話、位置情報に対して詳細な緊急連絡先を有効にします。Address Line 2 フィールドには、建物、階数、棟、部屋の情報が含まれます。Zoom PSTN 通話を使用する米国/カナダのお客様の声向けには、この配信可能な住所が PIDF-LO プロトコルを介して通話シグナリング内で直接送信されます。ノマディックユーザーの場合、Zoom の位置情報検知が、検出されたネットワーク位置情報に基づいて正しい配信可能な住所を自動的に選択します。

**住所の検証：** 米国/カナダで緊急連絡先を入力または更新すると、Zoom は保存前に自動的に検証します。その他の国では、Zoom のサービスチームが行う手動処理ステップが必要になる場合があります（承認されるまで住所は「保留中」と表示されます）。

<table data-header-hidden="false" data-header-sticky><thead><tr><th>法令</th><th>年</th><th>要件</th><th>Zoom の準拠方法</th></tr></thead><tbody><tr><td><strong>Kari's Law</strong></td><td>2018</td><td>1) 911 にダイヤルするためのプレフィックス不要<br>2) 現地の担当者に通知</td><td>911 は常に緊急通話としてルーティングされます メール、Safety Team のコールキュー、チャットボット、Webhook 通知</td></tr><tr><td><strong>RAY BAUM'S Act</strong></td><td>2019</td><td>PSAP に配信可能な位置情報を送信</td><td>Address Line 2 による詳細な住所（建物/階数/部屋）；米国/カナダでの PIDF-LO 配信</td></tr></tbody></table>

これらの規制の詳細については、 [FCC の MLTS 911 要件ページ](https://www.fcc.gov/mlts-911-requirements)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://library.zoom.com/technical-library/ja/zoom-workplace/zoom-phone/expert-insights/emergency-services-best-practices/appendix-u.s.regulatory-requirements-karis-law-and-ray-baums-act.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
