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

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

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

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

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

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

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

---

Device location の設定

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

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

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

1. Geolocation granularity を設定します
2. Rule-based location を定義します

Geolocation granularity の設定

Nexthink は、GeoIP データベースと Collector を実行しているシステムのパブリック IP アドレスを参照することで、インターネット上のデバイスの場所を決定できます。

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

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

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

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

Rule-based location の定義

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

表形式構造の CSV ファイルを使用して割り当てを設定します。 テーブルの各行には、2 つのパターンとロケーションの割り当てが含まれます。

ルールベースの位置情報ルールで 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 としてタグ付けし、位置サイトとして Lausanne を割り当てます。
• 2 番目のルールでは、ローカルサブネット 172.16.0.0/16 に属するすべてのデバイスを Onsite としてタグ付けし、ロケーションサイトとして Boston を割り当てます。
• 3 番目のルールでは、その他すべてのデバイスを Remote としてタグ付けします。

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

• Field1: 割り当てに使用する最初のフィールドのデータ（このページのField1 および Field2 でサポートされる値を参照してください。）
• Pattern1: 最初のフィールドのパターン
• Field2: 割り当てに使用する 2 番目のフィールドのデータ（このページのField1 および Field2 でサポートされる値を参照してください。）
• Pattern2: 2 番目のフィールドのパターン
• 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 の各フィールドは、文字パターンマッチングをサポートします。 関連する文字列パターンを定義するには、次のワイルドカードを使用します：

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

  • ドット区切りの 10 進表記による単一の 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 構成ファイルが次の条件を満たしていることを確認してください：

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

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

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

---

Device organization の設定

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

移行手順については、Nexthink Community ユーザー向けに提供されているEntities and Hierarchies to Rule-based Organizationドキュメントを参照してください。

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

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

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

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

デバイス組織ルールで 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*			米国	アメリカ大陸
名前	*			未割り当て	未割り当て

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

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

最初の 5 列は必須です：

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

必須列に加えて、分類用のカスタム列を最大 6 列追加します。

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

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 の各フィールドは、文字パターンマッチングをサポートします。 関連する文字列パターンを定義するには、次のワイルドカードを使用します：

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

  • ドット区切りの 10 進表記による単一の 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 構成ファイルが次の条件を満たしていることを確認してください：

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

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

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

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

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

カスタム分類の更新

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

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

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

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

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

カスタム分類を変更した後は、View domain アクセスが制限されているプロファイルを必ず更新してください。

---

User organization の設定

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

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

1

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

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

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

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

  • システムは作成されたフィールドの 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 から、ユーザー情報を使用してユーザー組織フィールドを手動で更新します。

インベスティゲーションページ上のカスタムフィールドの編集 を参照してください

例: 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. Add a custom field mapping を選択して、フィールドマッピングのポップアップを開きます。

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 クエリを実行し、特定の人事階層に一致するユーザーグループを集約して、ユーザー組織のカスタムフィールドを検証します。

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

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

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

---

NQL フィールドと例

場所および所有情報のフィールドは、データモデル内の 2 つのレベルで利用できます。

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

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

	オブジェクトプロパティ	イベントコンテキスト
パブリック 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 フィールドからデータを取得します。

execution.crashes during past 7d
| 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 スコアを比較する

組織全体のデジタル Experience の一貫性を確保するために、DEX スコアを #region および location.type 別に分類します。

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