Performance Hub ロゴPerformance Hub
サイトのセクション: ドキュメント

調査の例

このページの内容

これらの例では、監査ログを使用してよくある疑問に答える方法を紹介します。各例には、疑問、使用するフィルターとクリック操作、確認すべき点が記載されています。同じ手順はどの種類の拠点でも使用できるため、ご自身の疑問に合わせてフィルターを調整してください。

クイックリファレンス

場所： 設定（左下の歯車アイコン） → 監査ログ

使用できるユーザー： 組織内で、組織管理者など、監査ログと ID & アクセス管理を含むロールが必要です。監査ログを使用できるユーザー を参照してください。

目的： 疑問から、その答えとなるリクエストにたどり着きます

正面入口を解錠したのは誰か

ジムまたはレジャーセンター：正面入口がリモートで解錠され、当番のマネージャーが誰がなぜ解錠したのかを知りたい場合。

  1. Logs タブで Endpoint をクリックし、/api/door-gate-access/* と入力して Apply をクリックします。一覧にはドア/ゲートアクセスのリクエストのみが表示されます。
  2. Range を、解錠が行われた時刻を含むように設定します。
  3. エンドポイントの末尾が /front-entrance/unlock のリクエストをクリックします。

/api/door-gate-access/* で絞り込まれ、正面入口の解錠リクエストが開いている Logs タブ/api/door-gate-access/* で絞り込まれ、正面入口の解錠リクエストが開いている Logs タブ

図 1：すべてのドアのリクエスト。正面入口の解錠リクエストが開いています

確認すべき点： User には、ドアを解錠したユーザー（この例では oscar.tran@example.com）が表示されます。Request POST Body にはそのユーザーが入力した理由 "Member forgot access card" が、Response Body にはドアが解錠されたことが表示されます。

次の手順： ドア/ゲートアクセスの アクセスログ でドア自体の記録を確認します。ここには、モバイルアプリからのものを含め、そのドアでのすべての解錠試行が記録されています。

スタッフがユーザーのロールを変更できなかったのはなぜか

理学療法クリニック：コーディネーターが同僚に新しいロールを付与しようとしたが、うまくいかなかった場合。

  1. Logs タブで Status をクリックし、403 Forbidden を選択します。
  2. ロールを変更した時刻の 403 Forbidden リクエストをクリックします。
  3. AI Error Summary で Generate summary をクリックします。

変更を行ったユーザーにそのロールを割り当てる権限がなかったことを説明する AI Error Summary変更を行ったユーザーにそのロールを割り当てる権限がなかったことを説明する AI Error Summary

図 2：ロールの変更が拒否された理由を説明する要約

確認すべき点： 要約には、そのユーザーが "does not have permission to assign that role" と表示されます。これを Response Body と照合します。Response Body には "You don't have permission to assign this role." と表示されています。Request POST Body には、付与しようとしたロールが表示されます。

次の手順： 組織管理者に変更を依頼するか、そのユーザーのロールを見直します。ユーザーのロールの変更 と ロールテンプレート を参照してください。

予約システムの連携が夜間に同期しなくなった

アクアティックセンターまたは自治体の施設：予約システムからのチェックインが夜間に表示されなくなった場合。

  1. Logs タブで Endpoint をクリックし、/partner/v1/* と入力して Apply をクリックします。
  2. Range を Last 24 hours に設定します。
  3. 各行の先頭にあるステータスを確認し、失敗したリクエストをクリックして Response Body を読みます。

確認すべき点： integrations@example.org からの api-key バッジが付いたリクエストです。この例では、一覧に 429 Too Many Requests（連携が短時間に多すぎるリクエストを送信した）と 503 Service Unavailable が表示されています。失敗が始まった時刻と、その後に成功したリクエストがあるかどうかを確認します。

次の手順： CSVをエクスポート をクリックし、ファイルを連携パートナーに送信して、パートナー側で確認してもらいます。ログのエクスポート と Partner API の エラー ページを参照してください。

Webhook が保存されなかった

カフェ、店舗、ホスピタリティ施設：マネージャーが来訪者の詳細を別のシステムに送信する Webhook を設定したが、保存されなかった場合。

  1. Logs タブで Email をクリックし、マネージャーの完全なメールアドレス（この例では leo.hargreaves@example.com）を入力します。
  2. マネージャーが Webhook を保存したときの 2 つの POST リクエストを探します。同じエンドポイントに対する 400 Bad Request と 201 Created です。
  3. 400 Bad Request をクリックし、次に数分後の 201 Created をクリックして、両者を比較します。

確認すべき点： 400 の Response Body には "url must start with https://" と表示されています。その Request POST Body では、アドレスの先頭に https:// がありません。201 では、マネージャーが https:// を追加しており、Webhook が保存されています。

次の手順： 失敗したリクエストについては、Generate summary をクリックすると、わかりやすい説明が表示されます。AI Error Summary を参照してください。

退職するスタッフは先週何をしたか

オフィスまたはコワーキングスペース：スタッフが退職する前に、そのマネージャーが最近の操作の記録を残したい場合。

  1. Logs タブで Email をクリックし、そのユーザーの完全なメールアドレスを入力します。
  2. Range を Last 7 days に設定します。
  3. すべてのリクエストが読み込まれるように、一覧の最後までスクロールします。エクスポートには読み込まれた行のみが含まれます。
  4. CSVをエクスポート をクリックし、Export をクリックします。

確認すべき点： 読み取りではなく変更です。Method を POST、PUT、PATCH、DELETE に順に設定して、作成、変更、削除を行ったリクエストを確認します。予期しないものがあれば、そのリクエストを開いて Request POST Body を読みます。

次の手順： 退職時にアクセス権を削除します。ユーザーの削除 を参照してください。CSV ファイルは組織のポリシーに従って保管してください。

失敗したリクエストが最も多かった拠点はどこか

複数拠点の事業者：昨日いくつかの拠点で問題が報告され、本社がどこから調べるべきかを知りたい場合。

  1. ダッシュボード タブで、Window をその日を含むように設定します。
  2. Errors Over Time で、エラーが最も多かった区間をクリックします。Logs タブが開き、その時間帯の失敗したリクエストが表示されます。
  3. 施設 をクリックして各拠点を順に選択し、それぞれの失敗したリクエストの数を比較します。

確認すべき点： 他の拠点よりも失敗が大幅に多い拠点や、1 つのエンドポイントに集中している失敗です。その拠点のリクエストをいくつか開き、Response Body を読むか、Generate summary をクリックします。

次の手順： その他のグラフについては ダッシュボード を、組織内の拠点については 施設 を参照してください。