製品設定

製品構成のデバイスとユーザーの分類タブでは、Nexthinkテナント内でシステムがデバイスとユーザーをどのように分類するかを決定することができます。

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

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

システムは3つの主な分類設定を提供します。

デバイスの場所は、ルールベースのロジックおよび/または公共IPに基づくGeoIPを使用し、システムはGeoIPをフォールバックとして使用します。デバイスの場所により、イベントの時点でデバイスがどこにあるのかを知ることができ、効果的な問題のトラブルシューティングと一貫したサポートが可能になります。デバイスの場所は頻繁に変更されることが予想されます。
デバイスの組織は、カスタムルールセットを使用してデバイスを組織単位にマッピングし、組織の構造や支店によってアクセス、コンプライアンス、およびハードウェアライフサイクルを管理できます（例: 米国支店、スイスオフィスなど）。デバイスの位置とは異なり、デバイスの組織は時間の経過とともにかなり安定しています。
ユーザーの組織は、最上位から最下位までの6段階で組織階層を定義し、それを従業員にマッピングします。HR管理ツールのデータと一致させます。

管理 > 製品構成 > デバイスとユーザーの分類にアクセスするには管理者権限が必要です。

デバイスの位置の構成

デバイスの場所を使用して、イベントの時点でデバイスがどこにあるかを知り、リモートの問題をトラブルシューティングし、一貫したデジタルエクスペリエンス（DEX）を保証します。イベントは地理的な位置および位置タイプ（オンサイトまたはリモート）によって追跡されます。

Nexthinkは、ルールベースのロジックを使用して位置を特定し、GeoIPはルールベースの位置を割り当てられない場合にフォールバックとして使用されます。デバイスの場所は頻繁に変更されることが予想されます。

管理 > 製品構成 > デバイスとユーザーの分類タブのデバイスの位置の下にある部分で次の設定を行います：

ジオロケーショングランularityを設定します
ルールベースの場所を定義します

ジオロケーショングランularityの設定

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

ジオロケーション機能はデフォルトで無効（"位置データをキャプチャしない"）ですが、ドロップダウンメニューでのオプションを選択することで有効にできます。

位置データを一切取得しない
公開IPのみ
公開IPと国
パブリックIP、国、州
パブリックIP、国、州、市

ジオロケーション機能を有効にすると、選択した粒度レベルに関わらず、Nexthinkプラットフォームはインターネットサービスプロバイダー（ISP）の名前を記録します。

仮想プライベートネットワーク（VPN）を使用すると、Collectorによって報告されたパブリックIPアドレスに影響します。ジオロケーションの精度を向上させるには、CollectorとNexthinkインスタンス間のトラフィックをVPNを通してルーティングしないのが最適です。この機能は、Collectorのバージョンに関係なく機能し、Nexthinkプラットフォーム外に情報が送信されることはありません。 Nexthinkは独自のジオロケーションデータベースを持っており、ジオロケーションのルックアップを内部で実行します。

ルールベースのロケーションの定義

Nexthinkプラットフォームは、デバイスの位置を判断するためのルールベースの割り当てプロセスを備えています。この機能は非常に構成可能で、ルールを修正することで調整できます。

表構造を持つCSVファイルを使用して割り当てを構成します。テーブルの各行には、2つのパターンと位置の割り当てが含まれています。

ルールベースのロケーション用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

このページでフィールド1とフィールド2に対応するサポートされる値を参照してください。

上記のテキストファイルからの割り当てルールを示したテーブル：

Field1

Pattern1

Field2

Pattern2

Location Type

Site

地域

国

primary_local_ip

10.0.0.0/8

名前

NXT*

Onsite

Lausanne

primary_local_ip

172.16.0.0/16

Onsite

Boston

名前

Remote

最初のルールでは、名前が「NXT」ではじまるローカルサブネット10.0.0.0/8に属するすべてのデバイスを「Onsite」とタグ付けし、ロケーションサイトをLausanneに割り当てます。
2番目のルールでは、ローカルサブネット172.16.0.0/16に属するすべてのデバイスに「Onsite」とタグを付け、ロケーションサイトをBostonに割り当てます。
3番目のルールでは、その他のすべてのデバイスを「Remote」とタグ付けします。

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

Field1: 割り当てに使用される最初のフィールドのデータ（このページの Supported values for Field1 and Field2を参照してください。）
Pattern1: 最初のフィールドのパターン
Field2: 割り当てに使用される2番目のフィールドのデータ（このページの Supported values for Field1 and Field2を参照してください。）
Pattern2: 2番目のフィールドのパターン
Location Type: ターゲットロケーションタイプの名前。許可されているロケーションタイプの値は次のとおりです：
- Onsite
- Remote
- 不明
Site: デバイスまたはデバイスがあるサイトのカスタム名。
State: デバイスまたはデバイスが所在する場所のISO 3166-2サブディビジョンコード。このフィールドを使用して、州、県、カントンなどを示します。例として、スイスのVaudの場合：VD
Country: デバイスまたはデバイスが所在する国のISO 3166-1アルファ2国コード。例として、スイスの場合：CH

StateフィールドにCountryコードを重複させないでください。例として、ISO 3166-2に従って、フランスのBas-Rhin県の州フィールドは 67 であり、 FR-67 ではありません。この場合、ルールベースのロケーションは次のように見えるべきです：

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

フィールド1およびフィールド2に対応するサポートされる値：

name: デバイスのホスト名。
collector_tag: Collectorのインストール時に割り当てられたタグ番号。正確な番号のみが一致します。
collector_string_tag: Collectorのインストール時に割り当てられたラベル。この値はパターンマッチングをサポートします。
configuration_tag: デバイスのグループを識別する設定可能なラベル。このフィールドの値はEnrichment APIを使用して設定します。この値はパターンマッチングをサポートします。
dn: Collectorが報告したデバイスの識別名。デバイスはActive Directoryドメインの一部である必要があります。 Collectorが報告した識別名の形式は、最も特定的な属性から最も一般的な属性まで、コンマで結ばれた 属性=値 要素の標準的なシーケンスです。例： 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 フィールドにマッピングされます。フィールドのパターンとして、次のいずれかを指定します：
- ドット10進法表記の単一のIPアドレス、例：192.168.10.1
- CIDR表記のサブネット、例：192.168.10.0/24
primary_local_ip: プライマリの物理ネットワークアダプターのデバイス直近のローカルIP。このフィールドは connectivity.last_local_ip NQLフィールドにマッピングされます。パターンを ip フィールドと同様に指定してください。
collector_local_ip: エンドポイントとNexthinkインスタンス間のトラフィックに使用されるローカルIP。このフィールドは collector.local_ip NQLフィールドにマッピングされます。パターンを ip フィールドと同様に指定してください。
wifi_ssid: プライマリネットワークアダプターに関連付けられているWiFiネットワーク名（SSID）。この値はパターンマッチングをサポートします。

パブリックIPアドレスに基づいたルールを作成する前にジオロケーションを有効にしてください。

wifi_ssid タグを使用するには、次のCollectorパラメーターを無効にしてください： ANONYMIZE_WIFI_NETWORK

CSVファイルに関するルールベースロケーションの考慮点

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

ファイルサイズは5MB未満であること。
ファイルのエンコーディングはUTF-8であること。
フィールドの区切り文字はコンマです。
フィールドの区切り文字は任意であり、引用符 " のみが許可される区切り文字タイプです。
ルールまたは行の総数は40,000未満です。
ユニークなサイトの最大数は2,000です。
キャッチオールルールとして Field1=name および Pattern1=* をテーブルの最後の行に入力します。

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

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

デバイスの配置を構成する

古典的な階層を使用している組織は、デバイス配置のカスタムルールに移行する必要があります。

移行手順については、規則ベースの組織へのエンティティと階層のドキュメントを参照してください。

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

デバイスの位置が頻繁に変わるのとは違い、デバイスの配置は比較的安定しています。例えば、スイス所有のデバイスは、複数の国で使用される可能性があります。

管理 > 製品構成 > デバイスとユーザーの分類 タブのデバイスの組織の下：

表構造を持つCSVファイルを使用して割り当てを構成します。テーブルの各行には2つのパターンとエンティティ名が含まれています。テーブルはオプションでエンティティのカスタム分類を含めることができます。

ルールセットを最初にアップロードしたときは、CSVファイルのサイズに応じて、データのポピュレーションに20〜60分の遅れがあります。

デバイス配置のルールセットのためのCSVファイルの例

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

フィールド1,パターン1,フィールド2,パターン2,エンティティ,地域
,,,,,グローバル地域
名前,デバイス-d＊,,,フランス,ヨーロッパ
名前,デバイス-1＊,,,カナダ,アメリカ
コレクター_ストリング_タグ,CH＊,,,スイス,ヨーロッパ
コレクター_ストリング_タグ,US＊,,,アメリカ合衆国,アメリカ
名前,＊,,,未割り当て,未割り当て

上記のテキストファイルからの割り当てルールを示す表:

フィールド1

パターン1

フィールド2

パターン2

エンティティ

地域

グローバル地域

名前

デバイス-d＊

フランス

ヨーロッパ

名前

デバイス-1＊

カナダ

アメリカ

コレクター_ストリング_タグ

CH＊

スイス

ヨーロッパ

コレクター_ストリング_タグ

US＊

アメリカ合衆国

アメリカ

名前

＊

未割り当て

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

例えば、name が device-d100 で collector_string_tag が CH10 のデバイスがあるとします。このデバイスは、最初のルールと3つ目のルールの両方に一致します。システムはまず device-d100 ルールを評価するため、このデバイスはエンティティ フランス とグローバル地域 ヨーロッパ に割り当てられます。

最初の5つの列は必須です:

フィールド1: 割り当てで使用する第一フィールドのデータ (このページのフィールド1とフィールド2の対応値を参照)
パターン1: 第一フィールドのパターン
フィールド2: 割り当てで使用する第二フィールドのデータ (このページのフィールド1とフィールド2の対応値を参照)
パターン2: 第二フィールドのパターン
エンティティ: ターゲットエンティティの名前

必須列に加え、カスタム分類用に最大6つまでカスタム列を追加してください。

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

Difference between an NQL ID and a display name

#region はNQL IDです。
グローバル地域 は分類のNQL IDの表示名です。

フィールド1とフィールド2の対応値:

名前: デバイスのホスト名。
コレクター_タグ: コレクターのインストール時に割り当てられるタグ番号。システムは正確な番号とのみ一致します。
コレクター_ストリング_タグ: コレクターのインストール時に割り当てられるラベル。この値はパターンマッチをサポートします。
コンフィグレーション_タグ: デバイスグループを識別するための設定可能なラベル。このフィールドの値は、強化API を使って設定します。この値はパターンマッチをサポートします。
dn: コレクターが報告するデバイスの識別名。デバイスはActive Directoryドメインの一部でなければなりません。コレクターが報告する識別名の形式は、最も特定された属性から最も一般的な属性までの 属性=値 要素がカンマで接続されている標準のシーケンスです。例えば、CN=ex01,OU=Computers,DC=example,DC=org
ad_site: デバイスが位置するActive Directoryサイト。名前, コレクター_ストリング_タグ, dn, および ad_site フィールドは文字パターンマッチをサポートします。関連付けられた文字列パターンを定義するために、以下のワイルドカードを使用します。
- ? 文字は単一の文字を代わりにします。
- * 文字はゼロまたは複数の文字を代わりにします。
ip: デバイスの最終公開IPアドレス ( public_ip.ip_address を参照). フィールドのパターンとして以下のいずれかを指定します。
- 例えば、192.168.10.1 といったドット十進表記の単一のIPアドレス。
- 例えば、192.168.10.0/24 といったCIDR表記のサブネット。
プライマリ_ローカル_ip: プライマリ物理ネットワークアダプターのデバイスの最終ローカルIP (connectivity.last_local_ip)。同様にipフィールドに指定したようにパターンを指定します。
コレクター_ローカル_ip: エンドポイントとNexthinkインスタンス間のトラフィック用のローカルIP ( collector.local_ip) ipフィールドに指定したようにパターンを指定します。
wifi_ssid: プライマリネットワークアダプターに関連付けられたWiFiネットワーク名 (SSID)。この値はパターンマッチをサポートします。

{% ヒントスタイル="インフォ" %}

パブリックIPアドレスに基づいたルールを作成する前にジオロケーションを有効にします。

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

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

CSV設定ファイルが以下の基準を満たしていることを確認します。

ファイルサイズは5MB未満です。
ファイルのエンコーディングはUTF-8です。
フィールドセパレーターはカンマです。
フィールドデリミタは任意で、クォート " のみが許可されています。
エンティティ値や分類値に空文字列または - はありません。
エンティティ値と分類値の最大長は50文字です。
ルールまたは行の数は40,000未満です。
ファイル全体での異なるエンティティの合計数は2,000未満です。
カスタム分類列の合計数は6を超えてはなりません。
テーブルの最終行には Field1=name および Pattern1=* を使用した全体一致ルールが入力されています。
同じエンティティが複数のカスタム分類に属することはできません。エンティティ値が複数の行に表示される場合、その分類はすべての行で同一でなければなりません。

例: エンティティフランスが異なる行で誤ってヨーロッパとアメリカの両方に割り当てられているため、システムは以下の割り当てルールを拒否します。

フィールド1

パターン1

フィールド2

パターン2

エンティティ

地域

グローバル地域

名前

デバイス-d＊

フランス

ヨーロッパ

名前

デバイス-e＊

フランス

アメリカ

これらのチェックのどれかが失敗すると、ファイル選択は以前にアップロードされたファイルに戻ります。エラーを修正して初めてアップロードを再開できます。

{% ヒントスタイル="インフォ" %}

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

カスタム分類の更新

組織構造を最も反映した修正版CSVファイルをアップロードしてカスタム分類を更新します。次のことが可能です:

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

新しいCSVがアップロードされると、古いカスタム分類はデータモデルから削除され、自動補完によっても提案されなくなります。

{% ヒントスタイル="警告" %}

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

ドメインの表示の権限は、カスタム分類を含む組織データに依存しています。割り当てルールを変更すると、限定的な閲覧ドメイン権限を持つユーザーが利用できるデータの範囲に影響を与える可能性があります。

カスタム分類の変更後に限定されたドメインアクセスのプロファイルを再確認してください。

ユーザー組織の設定

ユーザー組織は、企業の階層やホラクラシーに従って、HR管理ツールから取得する値と一致する組織の従業員グループにユーザーをマップします。

ユーザー組織フィールドを定義するには、管理 > 製品構成 > デバイスおよびユーザーの分類 タブの下、ユーザー組織 から操作します。

{% ステッパー %} {% ステップ %}

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

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

新しいユーザー組織フィールドを追加し、その説明を含めます。例えば、ビジネスユニット。
- システムは作成されたフィールドに対して自動的にNQL ID を生成します: business_unit。
作成したユーザー組織フィールドをドラッグして、企業の階層に従って並べ替えます。

使用例: ユーザー組織フィールドは、従業員のグループごとにAIツールの使用を監視する際のカスタムフィルタとして機能します。

{% ヒントスタイル="警告" %}

新しいフィールドがデータモデルに含まれていますが、値はないため #ユーザー組織フィールドを充実させることが重要です。

Nexthinkインバウンドコネクタを使用してデータを強化する場合、コネクタのスケジュールを可能な限り早い時間に設定します。これにより、コネクタのスケジュールされた発生によって引き起こされる遅延が最小限に抑えられます。

{% ステップ %}

ユーザー組織フィールドを充実させる

データでユーザー組織フィールドを充実させるには、以下のオプションのいずれかを使用します。

インバウンドコネクタを使ったフィールドマッピング—以下の画像を参照—で、WorkdayやSalesforceなどの従業員管理アプリケーションにアクセスし、ユーザー組織フィールドに従業員属性をマッピングします。
- 遅延を最小限に抑えるため、データの充実はコネクタのスケジュールされた発生に依存するため、インバウンドコネクタをできるだけ早く実行するように設定します。
Nexthink 強化API を使用して、外部ソースからユーザー組織フィールドの値を更新します。
カスタムフィールド管理を使用してCSVファイルをアップロードし、ユーザー組織フィールドを更新します。
調査からカスタムフィールドの編集を行い、ユーザー情報でユーザー組織フィールドを手動で更新します。

以下の例では、Entra IDのインバウンドコネクタを使用して、ユーザー組織フィールド—ビジネスユニット—を選択したEntra IDフィールドにマッピングしています。

Microsoft Entra ID (Azure AD) コネクタのフィールドマッピング手順の詳細を参照してください。

{% ステップ %}

ユーザー組織フィールドを検証する

特定のHR階層に一致するユーザーのグループを集計し、調査からNQLクエリを実行してユーザー組織のカスタムフィールドを検証します—例では、business_unit: EMEAファイナンス。

users
| where user.organization.#business_unit == "EMEAファイナンス"

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

説明:

各デバイスについて、システムはCSVファイル内のルールを見つけようとします。デバイスがルールに一致する場合、システムは以下の方法で位置データを取得します:

ルールが場所の種類と1つ以上のサイト、州、国のフィールドにデータを持っている場合、システムは該当するフィールドから位置データを取得します。これらのフィールドのどれかにデータが含まれている場合、システムはルールベースの位置データを使用し、空のフィールドはクエリでは空の値として表示されます。
ルールが場所の種類フィールドにのみデータを持ち、サイト、州、国フィールドが空である場合、システムはジオロケーションを使用します。

さらに明確にするため、次のテーブルを参照してください:

場所の種類のデータ サイト、州、または国、あるいはすべてのデータ

場所の種類のデータ いいえ サイト、州、および国のデータ

ルールベースの位置情報

✓

位置情報

✓

使用例: 製品設定フィールドのクエリ

次の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ネットワークの品質を調査する

context.locationを使用した次のクエリを使用して、過去の接続の悪いサイトを確認します。次のクエリはイベント時のデバイス位置を格納しているcontext.locationフィールドからデータを取得します:

connectivity.events 過去3日間
| 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

これで、特定のサイトが接続の悪さに陥りやすいかがわかります。可能性のある根本原因を見つけるため、その場所のWiFi品質をアダプタの種類別に分解して見てみましょう。これを行うには、次のクエリでdevice.locationを使用します:

connectivity.events 過去1時間
| 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"

カスタム地域と場所の種類別にDEXスコアを比較する

DEXスコアを#regionと場所の種類で分解して、組織全体でデジタルエクスペリエンスの一貫性を確認します。

dex.scores 過去7日間
| summarize c1 = value.avg() by context.organization.#Region, context.location.type

Last updated 4 hours ago

Was this helpful?