デバイスとユーザーの分類

Device and user classification タブでは、Nexthink テナントでシステムがデバイスとユーザーを分類する方法を指定できます。

Nexthink の製品や機能全体でデバイスとユーザーの分類を使用して、次のことを行えます：

• NQL データモデルテーブル—device.organization、device.location、user.organization—を活用して、データのクエリや調査を実行します。
• 組み込みダッシュボードおよび特定のカスタムビジュアライゼーションを並べ替えるためのフィルターと分類基準を定義します。カスタムフィルターのユースケース例については、AI ツールの設定のドキュメントを参照してください。

システムには、主に次の三つの分類設定があります：

• デバイスの位置情報では、ルールベースのロジックおよび/または公開 IP に基づく GeoIP を使用します。GeoIP はフォールバックとして使用されます。デバイスの位置情報を使用すると、イベント発生時のデバイスの所在を把握でき、効果的な問題のトラブルシューティングと一貫したサポートが可能になります。デバイスの位置情報は頻繁に変わることが想定されます。
• デバイスの組織では、カスタムルールセットを使用してデバイスを組織エンティティにマッピングします。これにより、組織構造や支社（米国支社、スイスオフィスなど）ごとにアクセス、コンプライアンス、ハードウェアライフサイクルを管理できます。デバイスの位置情報とは異なり、デバイスの組織は時間の経過によって比較的安定しています。
• ユーザー組織では、最上位から最下位まで最大六つのレベルを使用して組織階層を定義し、HR 管理ツールのデータと照合して従業員にマッピングします。

Device and user classification にアクセスするには、管理者権限が必要です。

---

デバイスの位置情報の設定

デバイスの位置情報を使用すると、イベント発生時のデバイスの所在を把握でき、リモートの問題をトラブルシューティングし、一貫したデジタルエクスペリエンス（DEX）を確保できます。イベントは、地理的な場所とオンサイトまたはリモートのロケーションタイプによって追跡されます。

Nexthink は、精度のために推奨されるルールベースのロジック、または公開 IP に基づく GeoIP を使用して位置情報を特定します。ルールベースの位置情報を割り当てられない場合は、GeoIP がフォールバックとして使用されます。デバイスの位置情報は頻繁に変わることが想定されます。

Administration > Product configuration > Device and user classification タブの Device location セクションで、次の操作を行います：

1. 位置情報の詳細度を設定する
2. ルールベースの位置情報を定義する

位置情報の詳細度の設定

Nexthink は、GeoIP データベースおよび Collector を実行しているシステムの公開 IP アドレスを参照して、インターネット上のデバイスの位置を特定できます。

位置情報機能はデフォルトで無効（「位置情報データを取得しない」）ですが、ドロップダウンメニューで位置情報の詳細度を選択することで有効にできます。

• 位置データを一切取得しない
• 公開IPのみ
• 公開IPと国
• 公開 IP、国、州
• 公開 IP、国、州、都市

位置情報機能を有効にすると、選択した詳細度にかかわらず、Nexthink プラットフォームはインターネットサービスプロバイダー（ISP）の名前を記録します。

仮想プライベートネットワーク（VPN）の使用は、Collector によって報告される公開 IP アドレスに影響します。位置情報の精度を向上させるには、Collector と Nexthink インスタンス間のトラフィックを VPN 経由でルーティングしないことをお勧めします。この機能はすべてのバージョンの Collector で動作し、Nexthink プラットフォーム外に情報が送信されることはありません。 Nexthink は独自の位置情報データベースインスタンスを保持しており、内部で位置情報の検索を実行します。

ルールベースの位置情報の定義

Nexthink プラットフォームには、システムがデバイスの位置を特定できるルールベースの割り当てプロセスがあります。この機能は高度に設定可能であり、ルールを変更して調整できます。

表形式の CSV ファイルを使用して割り当てを設定します。表の各行には、二つのパターンと位置情報の割り当てが含まれます。

ルールベースの位置情報ルールで CIDR 表記の IP アドレスフィールドを使用する場合、デバイス組織ルールと同じ CIDR 形式の要件が適用されます。 デバイスとユーザーの分類 を参照してください。

ルールベースの位置情報用 CSV ファイルの例

カンマ区切りの割り当てテキストファイルの例：

Field1,Pattern1,Field2,Pattern2,Location Type,Site,State,Country
primary_local_ip,10.0.0.0/8,name,NXT*,Onsite,Lausanne,VD,CH
primary_local_ip,172.16.0.0/16,,,Onsite,Boston,MA,US
name,*,,,Remote,,,

詳細については、このページのField1 および Field2 でサポートされる値を参照してください。

上記のテキストファイルにある割り当てルールを示す表：

フィールド1	パターン1	フィールド2	パターン2	ロケーションタイプ	サイト	地域	国
primary_local_ip	10.0.0.0/8	名前	NXT*	オンサイト	ローザンヌ	VD	CH
primary_local_ip	172.16.0.0/16			オンサイト	ボストン	MA	US
名前	*			リモート

• 最初のルールでは、ローカルサブネット 10.0.0.0/8 に属し、名前が NXT で始まるすべてのデバイスを Onsite としてタグ付けし、位置情報サイトとしてローザンヌを割り当てます。
• 二番目のルールでは、ローカルサブネット 172.16.0.0/16 に属するすべてのデバイスを Onsite としてタグ付けし、位置情報サイトとして Boston を割り当てます。
• 三番目のルールでは、その他すべてのデバイスを Remote としてタグ付けします。

ルールを満たすには、パターンが対応するフィールドに一致する必要があります。システムは、表の上から下への順序でルールの優先順位を設定します。表の上部ではデバイスの割り当てをより具体的にし、下部ではより一般的にできます。

• Field1: 割り当てに使用する最初のフィールドのデータ（このページのField1 および Field2 でサポートされる値を参照）
• Pattern1: 最初のフィールドのパターン
• Field2: 割り当てに使用する二番目のフィールドのデータ（このページのField1 および Field2 でサポートされる値を参照）
• Pattern2: 二番目のフィールドのパターン
• Location Type: 対象ロケーションタイプの名前。使用できるロケーションタイプの値は次のとおりです：

  • オンサイト
  • リモート
  • 不明
• Site: デバイスがあるサイトのカスタム名。
• State: デバイスがある場所の ISO 3166-2 区分コード。このフィールドを使用して、州、県、カントンなどを指定します。例: スイスのヴォー州の場合: VD
• Country: デバイスがある国の ISO 3166-1 alpha-2 国コード。例: スイスの場合: CH

State フィールド内で Country コードを重複させないでください。たとえば、ISO 3166-2 によると、フランスのバ＝ラン県の州フィールドは FR-67 ではなく 67 です。この場合、ルールベースの位置情報は次のようになります：

primary_local_ip,55.XXX.XX.X/20, Onsite, Illkirch,67, FR

Field1 および Field2 でサポートされる値

• name: デバイスのホスト名。
• collector_tag: Collector のインストール時に割り当てられるタグ番号。完全一致する番号のみが照合されます。
• collector_string_tag: Collector のインストール時に割り当てられるラベル。この値はパターンマッチングをサポートします。
• configuration_tag: デバイスのグループを識別する設定可能なラベル。 Enrichment API を使用して、このフィールドの値を設定します。この値はパターンマッチングをサポートします。
• dn: Collector が報告するデバイスの識別名。デバイスは Active Directory ドメインの一部である必要があります。 Collector が報告する識別名の形式は、最も具体的な属性から最も一般的な属性の順に、カンマで連結された attribute=value 要素の標準的なシーケンスです。例: CN=ex01,OU=Computers,DC=example,DC=org
• ad_site: デバイスが配置されている Active Directory サイト。 name、collector_string_tag、dn、ad_site のフィールドは文字パターンマッチングをサポートします。関連する文字列パターンを定義するには、次のワイルドカードを使用します：

  • ? 文字は一文字を置き換えます。
  • * 文字はゼロ文字以上を置き換えます。
• ip: デバイスの最後の公開 IP アドレス。このフィールドは、devices テーブルの public_ip.ip_address NQL フィールドにマッピングされます。 フィールドのパターンには、次のいずれかを指定します：

  • ドット十進表記の単一 IP アドレス（例：192.168.10.1）
  • CIDR 表記のサブネット（例：192.168.10.0/24）

CIDR 表記でサブネットを指定する場合、IP がサブネットのネットワークアドレスを表していることを確認してください。 デバイスとユーザーの分類 を参照してください。

• primary_local_ip: プライマリ物理ネットワークアダプターのデバイスの最後のローカル IP。このフィールドは、devices テーブルの connectivity.last_local_ip NQL フィールドにマッピングされます。 ip フィールドの場合と同じ方法でパターンを指定します。
• collector_local_ip: エンドポイントと Nexthink インスタンス間のトラフィックに使用されるローカル IP。このフィールドは、devices テーブルの collector.local_ip NQL フィールドにマッピングされます。 ip フィールドの場合と同じ方法でパターンを指定します。
• wifi_ssid: プライマリネットワークアダプターに関連付けられた WiFi ネットワーク名（SSID）。この値はパターンマッチングをサポートします。

公開 IP アドレスに基づくルールの作成を開始する前に、位置情報を有効にしてください。

wifi_ssid タグを使用するには、次の Collector パラメーターを無効にします: ANONYMIZE_WIFI_NETWORK

ルールベースの位置情報用 CSV ファイルに関する考慮事項

CSV 設定ファイルが次の基準を満たしていることを確認してください：

• ファイルサイズが 5MB 未満である。
• ファイルエンコーディングが UTF-8 である。
• フィールド区切り文字がカンマである。
• フィールド区切り記号は任意であり、使用できる区切り記号は引用符 " のみである。
• ルールまたは行の総数が 40,000 未満である。
• 一意のサイトの最大数が 5,000 である。
• 表の最終行に、Field1=name および Pattern1=* の包括ルールが入力されている。

これらのチェックのいずれかが失敗すると、ファイル選択は前回アップロードしたファイルに戻ります。エラーを修正した場合にのみ、アップロードのブロックを解除できます。

保存時にプログラムが余分な文字を自動追加するのを防ぐため、CSV ファイルの編集には Notepad++ や Sublime Text などのプレーンテキストエディターを使用してください。

---

デバイスの組織の設定

従来の階層を引き続き使用している組織は、デバイスの組織のカスタムルールセットに移行する必要があります。

移行手順については、Nexthink Community ユーザー向けのエンティティと階層からルールベースの組織への移行に関するドキュメントを参照してください。

デバイスの組織では、組織ルールセットを使用してデバイスを組織エンティティにマッピングし、組織構造に沿ってエンティティをグループ化します。これにより、組織構造または支社（米国支社、スイスオフィスなど）ごとにアクセス、サポート、コンプライアンス、ハードウェアライフサイクルを管理できます。

頻繁に変更されるデバイスの位置情報とは異なり、デバイスの組織は比較的安定しています。たとえば、スイス所有のデバイスは複数の国で使用される場合があります。

Administration > Product configuration > Device and user classification タブの Device organization: セクションで、次の操作を行います

表形式の CSV ファイルを使用して割り当てを設定します。表の各行には、二つのパターンとエンティティ名が含まれます。表には必要に応じて、エンティティのカスタム分類を含めることができます。

デバイス組織ルールで CIDR 表記の IP アドレスフィールドを使用する場合、IP 値はサブネットのネットワークアドレスを表す必要があります。

ルールセットを初めてアップロードする場合、CSV ファイルのサイズに応じて、データが入力されるまでに 20 ～ 60 分の遅延があります。

IP ベースのルールに関する Classless Inter-Domain Routing（CIDR）形式の要件

サブネット内のホスト IP アドレスを使用して定義された CIDR 範囲は、デバイス組織ルールではサポートされません。 IP 部分は CIDR プレフィックスに一致し、すべてのホストビットがゼロに設定されている必要があります。

たとえば：

• 有効: 10.136.16.0/21
• 無効: 10.136.16.1/21

CIDR 範囲がネットワークアドレスから始まらない場合、CSV ファイルはアップロード時に受け入れられますが、デバイスはエンティティに一致しません。

デバイス組織ルールセット用 CSV ファイルの例

カンマ区切りの割り当てテキストファイルの例：

Field1,Pattern1,Field2,Pattern2,Entity,region
,,,,,Global Region
name,device-d*,,,FRANCE,EUROPE
name,device-1*,,,CANADA,AMERICAS
collector_string_tag,CH*,,,SWITZERLAND,EUROPE
collector_string_tag,US*,,,UNITED STATES,AMERICAS
name,*,,,Unassigned,Unassigned

上記のテキストファイルにある割り当てルールを示す表：

フィールド1	パターン1	フィールド2	パターン2	エンティティ	地域
					グローバル地域
名前	device-d*			フランス	ヨーロッパ
名前	device-1*			カナダ	アメリカ大陸
collector_string_tag	CH*			スイス	ヨーロッパ
collector_string_tag	US*			アメリカ合衆国	アメリカ大陸
名前	*			未割り当て	未割り当て

表の各行には、二つのパターン、エンティティ名、および任意の追加カスタム分類が含まれます。ルールを満たすには、パターンが対応するフィールドに一致する必要があります。システムは、表の上から下への順序でルールの優先順位を設定します。このため、表の上部ではデバイスの割り当てをより具体的にし、下部ではより一般的にする必要があります。

name が device-d100 であり、collector_string_tag が CH10 のデバイスがあるとします。このデバイスは最初と三番目のルールの両方に一致します。システムは device-d100 ルールを先に評価するため、このデバイスにはエンティティ FRANCE とグローバル地域 EUROPE が割り当てられます。

最初の五つの列は必須です：

• Field1: 割り当てに使用する最初のフィールドのデータ（このページのField1 および Field2 でサポートされる値を参照）
• Pattern1: 最初のフィールドのパターン
• Field2: 割り当てに使用する二番目のフィールドのデータ（このページのField1 および Field2 でサポートされる値を参照）
• Pattern2: 二番目のフィールドのパターン
• Entity: 対象エンティティの名前

必須列に加えて、分類用に最大六つのカスタム列を追加できます。

システムは、ヘッダー行を使用して分類の NQL ID を作成します。これらの値にスペースや特殊文字を含めることはできません。二行目の値は表示名に対応します。

1. #regionID は NQL ID です。
2. Region は分類の NQL ID の表示名です。

Field1 および Field2 でサポートされる値

• name: デバイスのホスト名。
• collector_tag: Collector のインストール時に割り当てられるタグ番号。システムは完全一致する番号のみを照合します。
• collector_string_tag: Collector のインストール時に割り当てられるラベル。この値はパターンマッチングをサポートします。
• configuration_tag: デバイスのグループを識別する設定可能なラベル。 Enrichment API を使用して、このフィールドの値を設定します。この値はパターンマッチングをサポートします。
• dn: Collector が報告するデバイスの識別名。デバイスは Active Directory ドメインの一部である必要があります。 Collector が報告する識別名の形式は、最も具体的な属性から最も一般的な属性の順に、カンマで連結された attribute=value 要素の標準的なシーケンスです。例: CN=ex01,OU=Computers,DC=example,DC=org
• ad_site: デバイスが配置されている Active Directory サイト。 name、collector_string_tag、dn、ad_site のフィールドは文字パターンマッチングをサポートします。関連する文字列パターンを定義するには、次のワイルドカードを使用します：

  • ? 文字は一文字を置き換えます。
  • * 文字はゼロ文字以上を置き換えます。
• ip: デバイスの最後の公開 IP アドレス（NQLデータモデル の public_ip.ip_address を参照）。フィールドのパターンには、次のいずれかを指定します：

  • ドット十進表記の単一 IP アドレス（例：192.168.10.1）
  • CIDR 表記のサブネット（例：192.168.10.0/24）
• primary_local_ip: プライマリ物理ネットワークアダプターのデバイスの最後のローカル IP（NQLデータモデル の connectivity.last_local_ip を参照）。 ip フィールドの場合と同じ方法でパターンを指定します。
• collector_local_ip: エンドポイントと Nexthink インスタンス間のトラフィックに使用されるローカル IP（NQLデータモデル の collector.local_ip を参照）。 ip フィールドの場合と同じ方法でパターンを指定します。
• wifi_ssid: プライマリネットワークアダプターに関連付けられた WiFi ネットワーク名（SSID）。この値はパターンマッチングをサポートします。

公開 IP アドレスに基づくルールの作成を開始する前に、位置情報を有効にしてください。

wifi_ssid タグを使用するには、次の Collector パラメーターを無効にします: ANONYMIZE_WIFI_NETWORK

デバイス組織ルールセット用 CSV ファイルに関する考慮事項

CSV 設定ファイルが次の基準を満たしていることを確認してください：

• ファイルサイズが 5MB 未満である。
• ファイルエンコーディングが UTF-8 である。
• フィールド区切り文字がカンマである。
• フィールド区切り記号は任意であり、使用できる区切り記号は引用符 " のみである。
• 空の文字列または - のエンティティ値および分類値がない。
• エンティティ値および分類値の最大長が 50 文字である。
• ルールまたは行の総数が 40,000 未満である。
• ファイル全体の個別エンティティの総数が 2,000 未満である。
• カスタム分類列の総数が 6 を超えない。
• 表の最終行に、Field1=name および Pattern1=* の包括ルールが入力されている。
• 同じエンティティを複数のカスタム分類に属させることはできません。エンティティ値が複数行に表示される場合、その分類はすべての行で同一でなければなりません。

例: エンティティ FRANCE が二つの異なる行で EUROPE と AMERICAS の両方に誤って割り当てられているため、システムは次の割り当てルールを拒否します。

フィールド1	パターン1	フィールド2	パターン2	エンティティ	地域
					グローバル地域
名前	device-d*			フランス	ヨーロッパ
名前	device-e*			フランス	アメリカ大陸

これらのチェックのいずれかが失敗すると、ファイル選択は前回アップロードしたファイルに戻ります。エラーを修正した場合にのみ、アップロードのブロックを解除できます。

保存時にプログラムが余分な文字を自動追加するのを防ぐため、CSV ファイルの編集には Notepad++ や Sublime Text などのプレーンテキストエディターを使用してください。

カスタム分類の更新

組織構造を最も適切に反映する改訂済み CSV ファイルをアップロードして、カスタム分類を更新します。次のことができます：

• 既存のカスタム分類を削除するには、列全体を削除します。
• 新しいカスタム分類を追加するには、新しい列を含めます。

新しい CSV をアップロードすると、古いカスタム分類はデータモデルから削除され、オートコンプリートでも候補として表示されなくなります。

カスタム分類を更新すると、組織データに依存する既存の NQL クエリの結果に影響する可能性があります。カスタム分類を変更した後は、これらの NQL クエリを確認して更新してください。

View domain 権限は、カスタム分類を含む組織データに依存します。割り当てルールを変更すると、限定された View domain 権限を持つユーザーが利用できるデータの範囲に影響する可能性があります。

カスタム分類を変更した後は、限定された View domain アクセスを持つプロファイルを必ず見直してください。

---

ユーザーの組織の設定

ユーザーの組織では、会社の階層またはホラクラシーで定義された組織の従業員グループにユーザーをマッピングし、HR 管理ツールの値と照合します。

ユーザー組織フィールド は、ダッシュボードや調査におけるデータ整理に役立ち、構成およびエンリッチ後は、従業員グループ間のAIツール使用状況を監視するためのカスタムフィルターとして機能します。

1

ユーザー組織フィールドの作成

Administration > Product configuration > Device and user classification タブの User organization セクションで：

HR の階層またはグループを表すユーザー組織フィールドを最大六つ追加します：

• 説明を含む新しいユーザー組織フィールドを追加します。例: 事業部。

  • システムは、作成したフィールドの NQL ID を自動的に生成します: #business_unit。
  • NQL クエリでは、このフィールドは user.organization.#business_unit として表示されます。
• 作成したユーザー組織フィールド項目をドラッグアンドドロップして、会社の階層に従って並べ替えます。

作成時、user organization fields はデータモデル内に存在しますが、空の状態です。したがって、常に デバイスとユーザーの分類 を実行する必要があります。

2

ユーザー組織フィールドのエンリッチメント

ユーザー組織フィールドをデータでエンリッチするには、次のオプションのいずれかを使用します：

<0>インバウンド コネクタ—<1>以下の例をご覧ください</1></0>

インバウンドコネクタを使用すると、Microsoft Entra ID、Workday、Salesforce などの従業員管理アプリケーションからデータを取得し、従業員属性を作成済みのユーザー組織フィールドにマッピングできます。

インバウンドコネクタを使用してユーザー組織フィールドを拡充する方法を確認するには、次を参照してください:

• このページのデバイスとユーザーの分類を参照してください。
• インバウンドコネクターのセットアップ手順を段階的に確認するには、How to set up and manage inbound connectors トレーニングを完了してください。

遅延を最小限に抑えるため、インバウンドコネクターのスケジュールされた繰り返しに依存してデータが強化されることから、インバウンドコネクターが可能な限り早いタイミングで実行されるように設定してください。

Nexthink エンリッチメント API

外部ソースの属性を使用してユーザー組織フィールドの値を更新するには、Nexthink Enrichment API を使用します。

<0>ユーザー情報を含む CSV ファイルによるカスタムフィールド</0>

Administration > Custom Fields から、ユーザー情報を含む CSV ファイルをアップロードして、作成したユーザー組織フィールドを管理し、値を更新します。

CSVファイルをインポートしてカスタムフィールドを更新する を参照してください。

調査からのカスタムフィールドの手動更新

Investigations から、ユーザー情報を使用してユーザー組織フィールドを手動で更新します。

Investigationsページでのカスタムフィールドの編集 を参照してください

例: Entra ID インバウンドコネクタを使用したユーザー組織フィールドの拡充

作成したユーザー組織フィールドを、今回は Entra ID インバウンドコネクターを使用して充実させるには:

1 — Nexthink で Entra ID (Azure AD) コネクターを構成する

Nexthink で Entra ID (Azure AD) コネクタを構成します。ユーザーデータのエンリッチメントに利用できる他のインバウンドコネクタも、フィールドマッピングをサポートしています。

Nexthink での Microsoft Entra ID（Azure AD）コネクタの設定を参照してください。

Nexthink のインバウンドコネクタを使用してデータをエンリッチする場合、コネクタの実行スケジュールを可能な限り早い時間に設定してください。これにより、コネクタのスケジュールされた繰り返しによる遅延が最小限に抑えられます。

2 — ユーザー組織フィールドを選択した Entra ID フィールド にマッピングします

Entra ID コネクターの構成で、Field mapping タブの下にある項目から:

1. カスタムフィールドマッピングを追加して、フィールドマッピングのポップアップを開きます。

1. Nexthink Custom field で、作成したユーザー組織フィールドを選択し、対応する Entra ID field. にマッピングします

   • ユーザー組織フィールドは、デフォルトで Nexthink Custom field ドロップダウンに Organization → [ユーザー組織フィールド名] として表示されます。この例では、Organization → Business unit です。
   • NQL クエリでは、ユーザー組織フィールドは user.organization.#[ユーザー組織 NQL ID] として表示されます。この例では、user.organization.#business_unit です。

詳細については、フィールドマッピングを参照してください。

データマッピングが成功したことを確認するため、エンリッチされたユーザー組織フィールドを検証してください。以下の手順を参照してください。

3

ユーザー組織フィールドの検証

Investigations から NQL クエリを実行し、特定の HR 階層に一致するユーザーグループを集計して、ユーザー組織カスタムフィールドを検証します。

この例では、user.organization.#business_unit == "EMEA Finance" により、ヨーロッパ、中東、アフリカの従業員が正常にクエリされます。

users
| where user.organization.#business_unit == "EMEA Finance"

NQL クエリでは、ユーザー組織フィールドは user.organization.#[ユーザー組織 NQL ID] として表示されます。

---

NQL フィールドと例

位置情報と所有権のフィールドは、データモデル内で二つのレベルで使用できます：

• デバイスまたはユーザープロパティとして: フィールドは、現在のユーザーまたはデバイスの組織単位、およびデバイスの位置情報を返します。
• イベントコンテキストとして: コンテキストフィールドは、イベント発生時の組織単位と位置情報を返します。

次の表に、対応するフィールドをまとめます。

	オブジェクトプロパティ	イベントコンテキスト
公開 IP の位置情報	device.public_ip.country device.public_ip.state device.public_ip.city	–
ルールベースのデバイス位置情報 * 表の下にある説明を参照	device.location.type device.location.site device.location.state device.location.country	context.location.type context.location.site context.location.state context.location.country
ルールベースのデバイス組織	device.organization.entity device.organization.#customClassification	context.organization.entity context.organization.#customClassification
ユーザーの組織	user.organization.#customClassification	–

説明:

システムは各デバイスについて、CSV ファイル内のルールを検索します。デバイスがルールに一致する場合、システムは次のいずれかの方法で位置情報データを取得します：

• ルールに Location Type と、Site、State、Country の一つ以上のフィールドのデータがある場合、システムは該当フィールドから位置情報データを取得します。これらのフィールドのいずれかにデータが含まれている場合、システムはルールベースの位置情報データを使用し、空のフィールドはクエリで空の値として表示されます。
• ルールに Location Type フィールドのデータのみがあり、Site、State、Country フィールドが空の場合、システムは位置情報を位置データとして使用します。

詳細については、次の表を参照してください：

	Location Type にデータあり Site、State、Country のいずれか、またはすべてにデータあり	Location Type にデータあり データなし：Site、State,、Country
ルールベースの位置情報	✓
位置情報		✓

ユースケース: 製品設定フィールドのクエリ

次の NQL の例では、製品設定機能を使用します。

Salesforce ユーザーの地理的分布

Salesforce ユーザーの地理的分布を確認します：

web.events
| where application.name == "Salesforce*"
| summarize Number_of_users = user.count() by context.location.country, context.location.state, context.location.site
| sort Number_of_users desc

イベント発生時のデバイス位置情報を使用した実行クラッシュの調査

過去 7 日間にすべてのデバイスで発生した実行クラッシュ数を調査して、地理的な傾向の可能性を特定します。 context.location を使用して、実行クラッシュ発生時のデバイス位置情報を確認します。このクエリは、イベント発生時のデバイス位置情報を保存する context.location フィールドからデータを取得します。

過去 7 日間の execution.crashes
| summarize total_crashes=number_of_crashes.sum() by context.location.country, context.location.state, context.location.site

イベントコンテキストと現在のデバイス位置情報を使用した WiFi ネットワーク品質の調査

1. context.location を使用する次のクエリにより、過去に接続不良イベントが発生したサイトを確認します。次のクエリは、イベント発生時のデバイス位置情報を保存する context.location フィールドからデータを取得します：

connectivity.events during past 3d
| where (connectivity.event.wifi.signal_strength.avg.rating !in [good, null] and context.location.site != null)
| summarize n_devices = count() by connectivity.event.wifi.signal_strength.avg.rating, context.location.site

1. これで、特定のサイトで接続不良が発生しやすいかどうかがわかります。潜在的な根本原因を確認するため、その場所における WiFi 品質をアダプタータイプ別に分類して見てみましょう。これを行うには、次のクエリで device.location を使用します：

connectivity.events during past 1h
| where device.location.site == "site_with_bad_history"
| summarize n_devices = count() by connectivity.event.wifi.signal_strength.avg.rating, connectivity.event.primary_physical_adapter.type

組織エンティティによるデバイスのフィルタリング

組織内の特定部分を対象にするため、entity でデバイスをフィルタリングします：

devices 
| where organization.entity == "SWITZERLAND"

組織単位によるユーザーのフィルタリング

組織内の特定部分を対象にするため、#team でユーザーをフィルタリングします：

users
| where organization.#team== "Product"

カスタム地域とロケーションタイプによる DEX スコアの比較

組織全体でデジタルエクスペリエンスの一貫性を確保するため、#region と location.type で DEX スコアを分類します。

dex.scores during past 7d
| summarize c1 = value.avg() by context.organization.#Region, context.location.type