トラブルシューティング

ドア/ゲートアクセスでよくある問題について、症状ごとの対処法を説明します。各項目は「症状 → 原因 → 解決方法」の順に記載しています。状態や拒否理由の意味については リファレンス を、その基になる判定ロジックについては アクセス判定の仕組み を参照してください。

まずアクセスログを確認してください。 「入れない」という報告のほとんどには、アクセスログ に正確な理由が記録された拒否イベントがあります。メンバーの名前で検索し、最新の拒否イベントを確認して、以下の該当するセクションに進んでください。

ドアがオフラインと表示される

症状： ドアカードに オフライン と表示され、メンバーには "Door offline" と表示され、解錠コマンドを送信できません。

原因： ドアコントローラーから 5 分以上応答がありません。デバイスの電源またはネットワークが停止しています。

解決方法：

1. コントローラーに電源が供給され、ネットワーク接続（Ethernet ケーブル / Wi-Fi）があることを確認します。現地での確認事項（インジケーター LED、PoE スプリッター、配線、4G モデルの SIM/アンテナ）については、ハードウェアのトラブルシューティング ページを参照してください。
2. ドアのパネル → Overview タブを開き、Status（最終確認日時）、IP address、稼働時間を確認します。最終確認日時が最近であれば、デバイスの故障ではなくネットワークが断続的に切れている可能性があります。
3. 必要に応じて、コントローラーの電源を入れ直します。
4. より詳しく診断するには、Open in Device Management for advanced configuration から進みます。
5. 複数のドアが同時にオフラインになった場合は、デバイスではなくサイトのネットワークやインターネットに問題がある可能性があります。

ドアがオフラインの間、メンバーのダッシュボードにはサポートの連絡先が表示されるため（デフォルトの Smart モードの場合）、メンバーはあなたに電話で連絡できます。

メンバーが拒否される："You don't have access to this door"

症状： 理由が no_matching_policy_or_grant の拒否イベント。

原因： どの許可パスも通過しませんでした。有効な Access Policy のうち Who、Where、When のすべてに一致するものがなく、ドアを対象とする恒久的な付与や、有効な管理者/連携サービスのウィンドウもありませんでした。

解決方法：

1. Users でメンバーを開き、人物の種類、会員ステータス、同期タグとカスタムタグを、ポリシーの Who と比較します。
2. Where に、そのドアが直接、Access Scope 経由、またはすべての施設のドア経由で含まれていること、そして除外設定で外されていないことを確認します。
3. When を確認します。Anytime であるか、少なくとも 1 つの有効な Weekly/One-time ウィンドウがある必要があります。終了時刻はウィンドウに含まれません。
4. ポリシー同士は OR で結合されますが、各ポリシーでは Who、Where、When のすべてが一致する必要があります。一部だけが一致してもアクセスは許可されません。
5. 必要に応じて、別途恒久的な付与または管理者のウィンドウを使用します。これらは追加的に機能します。

メンバーが拒否される："Your access has been suspended"

症状： 理由が access_disabled の拒否イベント。ユーザーに Disabled バッジが表示されます。

原因： ユーザーのアクセスがオフになっています。これは手動（管理者が Access enabled をオフにした）または自動（連携サービスでメンバーが削除され、パネルに Removed by integration と表示されている、またはソフト削除された）で発生します。

解決方法： ユーザーを開き、Access enabled を再びオンにします。Removed by integration と表示されている場合は、ソースシステムでメンバーを復元します（または行を切り離して、手動でアクセスを有効にします）。

スケジュールされたポリシーでアクセスが許可されない

症状： アプリに今後の利用可能時間が表示される、ログに outside_access_time_window が記録されている、ソースのウィンドウが Stale または Unmapped と表示される、またはアクセスが予期しない時刻に変わる。

解決方法：

1. ポリシーが有効になっていることを確認します。
2. When のスケジュールを調べる前に、同じポリシーの Who と Where を確認します。
3. One-time ウィンドウの場合は、試行時刻を [from, to) と比較します。表示されるタイムゾーンによって、保存された時刻がずれることはありません。
4. Weekly ウィンドウの場合は、IANA タイムゾーン、現地の曜日/時間ブロック、任意の有効期間、夏時間の切り替えを確認します。終了時刻はウィンドウに含まれず、日をまたぐブロックは分割する必要があります。
5. アクセスログの policyId と policyName を使用して、どの名前付きポリシーが評価されたかを確認します。
6. blockAllAccess、Force closed、ユーザーの無効化、ジオフェンス、コントローラーの状態が優先されていないことを確認します。

連携サービスの個別のウィンドウについては、論理スコープのマッピング、ソースのリビジョン、ソースの経過時間、配信の状態も確認します。不明なソースウィンドウ、マッピングされていないソースウィンドウ、期限切れのソースウィンドウはフェイルクローズになりますが、Access Policy や恒久的な付与のパスは削除されません。

古いクライアントでは、互換性のための理由が outside_access_hours であるため、Outside hours と表示されることがあります。アクセスログと新しいクライアントでは outside_access_time_window の詳細が使用されます。

ジオフェンスによる拒否："Move closer" など

症状： 理由が outside_geofence、gps_too_imprecise、または location_unavailable の拒否イベント。

拒否イベントの詳細ダイアログには、報告された座標、精度、距離が表示されます。メンバーが実際に現地にいたかどうかを判断するうえで非常に役立ちます。

解錠コマンドを送信したがドアが開かない（Timed out / Failed）

症状： イベントが Confirmed unlocked ではなく Timed out または Failed で終わります。

原因： コマンドはサーバーに届きましたが、コントローラーが確認しませんでした。ドアの接続が不安定であるか、デバイスに障害があります。

解決方法：

1. ドアのオンライン状態とデバイス情報（Overview タブ）を確認します。特定のドアでタイムアウトが繰り返し発生する場合は、そのドアのネットワークに問題があります。
2. ドアを見ながら、パネルから管理者として Unlock door を試します。
3. Identify device（ビープ音 3 回）を使用して、実際に正しいコントローラーの前にいることを確認します。
4. リレーのカチッという音がするのにドアが開かない場合は、ロック回路に障害があります。ハードウェアのトラブルシューティングの ジャンパーとマルチメーターによるテスト を実施してください。
5. デバイスがオンラインなのに作動しない場合は、デバイス管理の診断を通じてエスカレーションします。

Maintenance mode も確認してください。Force closed に設定されたドアは、仕様によりメンバーに対して施錠されたままになります。Block all access at this door は明示的な blockAllAccess を設定し、メンバーのすべてのポリシー、恒久的な付与、Access Time Window を拒否します。

コントローラーがオンラインなのに正常に応答しなくなった場合は、Remotely reboot device（ドアのパネル → Configuration → Advanced）で再起動できます。ドアは現在のロック状態を維持し、起動中の 1～2 分間はオフラインになります。

メンバーがアプリにサインインできない

症状： コード送信の手順で "No record found" と表示されます。

原因： 入力した電話番号/メールが、Users のどのレコードとも一致しません。

解決方法： Users でそのメンバーの行を探し、識別子を正確に比較します。番号の形式の違い、古いメールアドレス、識別子の未登録がよくある原因です。行を更新します（または、登録されている識別子を使用するようメンバーに伝えます）。各行には電話番号またはメールの少なくとも一方が必要です。

症状： "Too many attempts."

原因： レート制限です。連絡先ごとに 1 時間あたり 5 回のコード要求に加え、ネットワークレベルの制限があります。

解決方法： 時間が経過するまで待ちます。連絡先ごとの制限はセキュリティ対策であり、解除することはできません。

招待の問題

アプリへの招待 → トラブルシューティング の専用の表を参照してください。主な例：Send failed の場合はアドレスを確認して再送信します。一括送信の対象に含まれない場合は、すでに招待済み、アプリを使用済み、メールがない、またはアクセス権がないことが原因です。

同期されたユーザーが見つからない、または情報が古い

症状： メンバー管理システムには存在する人物が Users にいない、またはその詳細が古い。

解決方法：

1. Settings → Sync settings を確認します。ソースは有効になっていますか。対象の連携サービスは有効になっていますか。カードに N removals held back for review と表示されている場合は、大量の削除が管理者のレビュー待ちになっています。
2. Sync activity & troubleshooting を展開してその人物を検索します。スキップ理由から、原因（識別子がない、切り離されている、連携サービスがオフなど）を正確に確認できます。スキップ理由の表 を参照してください。
3. ユーザーの Track source updates トグルを確認します。切り離された行は、ソースから更新されることはありません。
4. 行に Not synced – duplicate と表示されている場合は、別のレコードが同じメールまたは電話番号を使用しています。重複の解消 を参照してください。
5. 毎日の完全同期を待たずに同期を実行するには、Sync now を使用します。
6. Access Time Windows については、ソースの経過時間、リビジョンの結果（updated/idempotent/stale/conflict）、scope_key のマッピングも確認します。取得に失敗した場合は、以前のスナップショットをクリアせず、変更しないままにする必要があります。

自動解錠スケジュールでドアが開かない

症状： スケジュールされた時間帯にドアが開放状態になりません。

解決方法：

1. ドアの Schedule タブを開き、Auto-unlock がオンになっていることを確認します。Next 14 days のプレビューで、ドアが解錠される予定の日時を確認します。
2. 施設のスタッフ常駐時間 を使用している場合は、施設 & システム設定で施設のスタッフ常駐時間と休日の時間を確認します。祝日には、On public holidays の設定によって、ドアが休日の時間に従うか、施錠されたままになるか、休日を無視するかが決まります。
3. Custom schedule を使用している場合は、その日に実際に時間ブロックが設定されていることを確認します。
4. スタッフが 今すぐ施錠 を使用したかどうかを確認します。その場合、カードに Locked by staff until HH:MM と表示されます。Resume schedule でスケジュールを元に戻します。
5. スケジュールの変更は 保存 した後にのみ反映されます。保存するとコントローラーが再読み込みされます（通常 10～15 秒）。
6. Maintenance mode が優先されます。 Force closed に設定されたドアは自動では開きません。
7. 時刻は 施設のタイムゾーン に基づきます。想定外の時刻にウィンドウが作動する場合は、施設のタイムゾーン設定を確認してください。

管理者が設定を変更したのに何も変わらない

症状： ポリシー、ジオフェンス、メッセージを編集しても効果がない。

原因： Settings タブでの変更は、保存バーの 変更を保存 をクリックするまで適用されません。ページから移動しようとすると、変更を破棄するかどうかを確認されます。

解決方法： 変更をもう一度行い、保存します。ポリシーとジオフェンスの変更は、その後の認可の試行から使用されます。アプリ側の設定は、メンバーのアプリが次に更新されたときに反映されます。

関連ページ

• ハードウェアのトラブルシューティング：電源、リレー、ロックの配線の診断
• アクセスログ
• Access Policy のスケジュール
• リファレンス：すべての拒否理由とデフォルト値
• よくある質問