> For the complete documentation index, see [llms.txt](https://help.verkada.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.verkada.com/new-alarms/ja/troubleshoot.md). # アラーム制限の適用 {% hint style="success" %} この記事は新しいアラーム向けのガイドです。参照 [New アラームと Classic アラームの違い](/new-alarms/ja/hajimeni/new-alarms-vs-classic-alarms.md) どのバージョンのアラームをお使いか不明な場合は、こちらをご覧ください。 {% endhint %} サイトが月間15件のVerkada監視アラームの上限を超過した、またはその上限に近づいている場合、サイトはアラーム上限制適用の対象となります。サイトがこの上限を継続的に超えると、システムは適用を有効化し、その月の残りのアラームを [自己監視](/new-alarms/ja/she-ding/configure-an-alarm-response/self-monitored-response-level.md) 対応。 このガイドを使ってアラーム件数を増やしている要因を特定し、削減するための設定変更を適用し、 [適用ポリシー](#alarm-limit-enforcement-policy) とタイムラインを理解します。 *** ### 問題を特定 次を使用してください [アラームイベントレポート](/new-alarms/ja/reptoto/alarm-reports.md) を使ってアラーム履歴を確認し、傾向を特定します。最も多くのアラームを発生させるデバイス、パーティション、または時間帯を確認してください。 {% stepper %} {% step %} **Verkada Command で、すべての製品 > アラーム に移動します。** {% endstep %} {% step %} **左側のナビゲーションで、レポート > アラームイベントを選択します。** {% endstep %} {% step %} **フィルターを使ってレポートを並べ替えます。** * **期間:** 過去30日または90日を選択して、繰り返し発生する傾向を見つけます * **サイト:** 上限を超過しているサイトを選択 * **デバイスタイプ:** アラームの主な発生源を特定 {% hint style="info" %} 繰り返し表示されるデバイスまたはパーティションが、最優先で対処すべき項目です。以下の設定のヒントを使って解決してください。 {% endhint %} {% endstep %} {% endstepper %} *** ### アラーム件数を減らす設定のヒント 以下のセクションでは、アラーム過多の4つの最も一般的な原因と、その修正方法を説明します。 #### 1. カメラトリガーの設定ミス {% tabs %} {% tab title="関心領域（ROI）を調整" %} ROI は、トリガーが監視するカメラフレーム内の領域を定義します。ROI の外側はすべて無視されます。 **重要な理由:** 屋内カメラの視野内にガラス窓やドアがあると、実質的に屋外を見ていることになります。ROI が室内だけをカバーしているように見えても、ガラス越しの反射や見える動きが検知をトリガーすることがあります。これは、最も見落とされやすい設定ミスの1つです。 **適用方法:** カメラのトリガー設定を確認するときは、フレーム内にガラスがないか注意深く確認してください。窓やガラスドアが見える場合は、ROI を狭めてそれらを除外します。 参照 [新しいアラーム用のカメラアラームトリガーイベントを設定](/new-alarms/ja/she-ding/configure-camera-alarm-trigger-events-for-new-alarms.md) 詳細については。 **例：** レストランの前入口付近にあるカメラには、道路に面した大きなガラス窓が含まれていました。人物検知が外を歩く通行人に対して常に発動していました。ROI を狭めて窓を除外することで、問題は完全に解決しました。
* クリックします **例を表示** 過去のトリガーイベントを確認し、トリガー設定とこの警戒設定スケジュールを検証するために
* クリックします **この警戒設定スケジュール** スケジュールを直接確認・調整するために。
{% endtab %} {% tab title="ラインクロッシング " %} Line Crossing は、ゾーン内のどこかに人がいるかどうかを検知するのではなく、フレーム内で定義された線、通常は出入口、ゲート、またはフェンスを人が横切ったときのみイベントをトリガーします。広範囲検知の代わりに、入口では Line Crossing を使用します。 **重要な理由:** 広域人物検知や滞留は、外を通り過ぎる人を含め、周辺にいる誰にでも反応します。Line Crossing は、設定した方向から誰かが実際に保護エリアへ入ったときのみトリガーされます。 **適用方法:** 線は出入口のすぐ内側に、内向きに引きます。（該当する場合）入場遅延と組み合わせ、許可されたスタッフが通過後に警戒解除する時間を確保します。 **例：** 開放駐車場の隣にあるフェンスで囲まれたエリアを監視するカメラが、フェンスを乗り越える人物を検知するために広域人物検知を使用しており、駐車場を通り抜ける人だけで週あたり推定14件のアラームが発生していました。フェンスラインに絞った Line Crossing トリガーに切り替えた結果、推定アラーム件数は0になりました。 | ❌ | ✅ | | --------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | | | | | {% endtab %} | | | {% endtabs %} | | *** #### 2. 許可された活動によってトリガーされるアラーム 過剰なアラームの最も一般的な原因の1つは侵入者ではなく、許可された人です。サイトが警戒設定されていることを知らない清掃スタッフや、予定外の時間に到着する週末スタッフなどです。 **重要な理由:** 通常の運用活動も、それを考慮するようシステムが設定されていないとアラームの問題になります。最も効果的な対策は、それらのユーザーに確実な警戒解除手段を提供することです。 夜間の継続的な活動があるサイトでは、スケジュールされた警戒設定/警戒解除の時間枠だけに頼らないようにします。代わりに、次のオプションを検討してください: * **設定する** [**入退室遅延**](/new-alarms/ja/she-ding/alarm-sites/configure-new-alarms-site-settings.md#delays)**:** 遅延は、誰かがサイトに入ってからアラームが上がるまでの猶予時間です。ユーザーがキーパッドに到達して警戒解除するのに十分な時間を与えます。適切な長さに設定することは、コストゼロで即効性のある設定変更です。 * **入口に BK22 キーパッドを設置:** BK22 キーパッドはアラームのパーティションを警戒設定/警戒解除し、アラームサイトを作動させたことをユーザーに通知します。スタッフが複数の入口を使う場合は、それぞれに適切な [キーコード](/new-alarms/ja/she-ding/alarm-sites/configure-new-alarms-site-settings.md#keycodes) 管理。 * **出力を設置** して、入口で警戒設定状態を表示し、許可されたスタッフが入る前にアラームシステムが有効であることを認識できるようにします。 * **アクセスコントロールで** [**警戒設定/警戒解除**](https://help.verkada.com/new-alarms/configuration/alarm-sites/configure-new-alarms-site-settings#arm-disarm-via-access-control) を入退室時に行うよう、可能な場合は設定し、スタッフがシステム操作を覚えておく必要をなくします。 * **使用する** [**スマートスケジュール**](https://help.verkada.com/new-alarms/configuration/alarm-sites/configure-partitions/smart-schedule-in-new-alarms) は、サイトの閉店時間が一定でない場合に有効です。スマートスケジュールは固定時刻ではなく、アクティビティに基づいてサイトを自動で警戒設定します。 * 次を使用してください **遠隔での警戒設定/警戒解除用の Command Mobile アプリ**、キーパッドの設置が難しいサイトに最適です。 [警戒設定/警戒解除ロール](/new-alarms/ja/hajimeni/roles-and-permissions-for-new-alarms.md#arm-disarm) は、Command 経由でのみ警戒設定/警戒解除する権限を付与するため、サイトスタッフに最適です。 *** #### 3. 人通りの多い屋外エリアが過剰アラームを引き起こす場合 **重要な理由:** 屋外や一般向けのエリアでは通行は避けられず、最初の対応としてアラームを使うと過度なノイズになります。 しきい値の低いイベントではまず [抑止](https://help.verkada.com/new-alarms/configuration/configure-ai-powered-deterrence) を発動し、継続的な滞留のみをアラームへエスカレーションする多段階対応戦略を使用します。 **例：** 抑止は滞留10秒でトリガーされ、2分間継続して滞在した場合にのみアラームへエスカレーションされます。これにより、通り過ぎる人や営業時間を確認する人によるノイズを減らしつつ、実際の脅威は捉えられます。

二段階対応に設定された店舗の外部通路

*** #### 4. システム設定とテストによる意図しないアラーム **重要な理由:** テストと初期設定は、よくあるものの見落とされがちなアラーム件数の原因です。テストを実行すると実際のアラームが発生し、月間上限に算入されます。また、まだ設定中の新しいサイトでは、セットアップ完了前にアラームが発生することがあります。 **セットアップと設定中は:** * 完全に準備が整うまでサイトを警戒解除しておきます。スケジュールされた警戒設定/警戒解除ウィンドウは、センサーやカメラの設定が完了していなくてもサイトを自動で警戒設定する場合があることに注意してください。セットアップが完了したと確信できるまでは、警戒設定は手動のままにします。 * 手動での警戒設定/警戒解除ができない場合は、レスポンスレベルを自己監視に設定し、セットアップ中に発生したアラームが上限に算入されたり出動を引き起こしたりしないようにします。 **センサーをテストする場合:** * 次を使用してください [ウォークテスト](https://help.verkada.com/new-alarms/configuration/alarm-sites/configure-partitions/walk-test-for-sensor-partitions) を使って、実際のアラームを発生させずに、センサーが正しくトリガーされることを確認します。 **設定完了後のテストでは:** * レスポンスレベルを [自己監視](https://help.verkada.com/new-alarms/configuration/configure-an-alarm-response/self-monitored-response-level) に設定し、セットアップを検証している間。 *** ### アラーム上限適用ポリシー 各アラームサイトには、Verkadaが監視するアラームの月間上限が15件あります。サイトがこの上限を2か月連続で超えると、3か月目にエンフォースメントが有効になります。その3か月目に15件目のアラームが発生した後、サイトはその月の残りの期間、自己監視に切り替わります。 その後の月もサイトが15件のアラームを超え続ける場合、適用は継続されます。1か月まるごと上限を下回ると、適用はリセットされます。 {% hint style="warning" %} 追跡は2026年5月1日に開始されます。 {% endhint %} | 月 | ステータス | 内容 | | ---------------------- | ----- | --------------------------------------------------------------------------------------- | | 1か月目: 15件以上のアラーム | 猶予期間1 | サイトが15件を超えます。適用はありません。システムは16件目のアラームで、サイト管理者とアラーム管理者連絡先に警告SMSとメールを送信します。 | | 2か月目（連続）: 15件以上のアラーム | 猶予期間2 | サイトが再び15件を超えます。適用はありません。システムは16件目のアラームで、サイト管理者とアラーム管理者連絡先に警告SMSとメールを送信します。 | | 3か月目以降（連続）: 15件以上のアラーム | 適用中 | システムは、適用が近づいていることを示すために、10件目のアラームで警告SMSとメールを送信します。15件目のアラームの後、その月の残りのアラームは自己監視に切り替わります。 | 上限に算入されるアラーム: * 自己監視対応レベルではないすべてのアラーム。ビデオ確認で却下されたセンサーアラームも含みます 上限に算入されないアラーム: * カメラで却下されたイベント、たとえば *人物未検出* または *条件未達成* * 自己監視対応レベルのアラーム *** ### よくある質問
適用の追跡はいつ開始されましたか？ 追跡は2026年5月1日に開始されました。ポリシーで定められた3か月の猶予期間を考慮すると、サイトが最も早く適用対象になるのは2026年7月で、5月、6月、7月に連続して15件を超えたサイトにのみ適用されます。
適用に関するSMS/メール通知は誰が受け取りますか？ 警告通知はサイト管理者と [アラーム管理者連絡先](/new-alarms/ja/armuno/alarm-admin-contact-requirement.md)に送信されます。アラームサイトの連絡先リストにいるユーザーは、サイト管理者でもある場合にのみこれらの通知を受け取ります。
サイトが適用される前に、警告通知はいくつ送信されましたか？ 適用前の3か月間に、警告を3回送信します: * **1か月目（猶予期間1）:** 16件目のアラームで警告SMS/メールを送信 * **2か月目（猶予期間2）:** 16件目のアラームで警告SMS/メールを送信 * **3か月目以降（適用中）:** 10件目のアラームで警告SMS/メールを送信し、16件目のアラームで適用通知を送信して、サイトが適用中であることを示します。
自己監視対応レベルでは何が起こりますか？ 他のレスポンスレベルとどう違いますか？ 自己監視モードでは、アラーム通知はVerkada監視センターを介さずに直接対応連絡先へ送信されます。他のレスポンスレベルと同じSMS/メールアラートを受け取りますが、緊急サービスに連絡するのか、社内警備を出動させるのか、あるいは単にイベントを記録するのかを含め、対応方法の判断はチームが行います。 参照 [自己監視応答レベル](/new-alarms/ja/she-ding/configure-an-alarm-response/self-monitored-response-level.md) 詳細については。
適用後、サイトはいつ通常状態に戻りますか？ Verkadaは毎月初めにアラーム件数をリセットします。適用中のサイトは翌暦月に監視が再開されます。ただし、翌月にサイトが15件のアラーム上限を超えた場合、その月の残りは自己監視アラーム対応として適用が継続されます。 適用を完全にリセットするには、サイトが15件のアラーム上限を下回る暦月が丸1か月必要です。
サイトが適用中に緊急事態が発生した場合、警察は呼ばれますか？ サイトが適用中で自己監視のとき、どうすれば警察を緊急出動させられますか？ いいえ、適用によりサイトは自己監視になるため、警察は自動では出動しません。出動はご自身で開始できます。 自己監視アラーム通知には、事前認証済みインシデントリンクが含まれており、アラームのインシデントページに直接移動できます。そこから、アラームを解決するか、緊急出動情報セクションで警察に電話するための電話番号を確認できます。
上限に達することなくアラームシステムをテストするにはどうすればよいですか？ 参照 [設定のヒント #4: システム設定とテストによる意図しないアラーム](#id-4.-unintended-alarms-from-system-setup-and-testing) 上記。センサーのテストにはウォークテストを使用し、セットアップを検証している間はレスポンスレベルを自己監視に設定します。
あらゆる方法を試しましたが、それでもアラーム件数を減らすための支援が必要です。 アラームシステムを設置・設定したパートナーに連絡してください。Verkadaサポート、または営業担当者やソリューションエンジニアに問い合わせることもできます。
--- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://help.verkada.com/new-alarms/ja/troubleshoot.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.