製品構成
製品構成内の「デバイスとユーザーの分類」タブは、Nexthinkテナント内でシステムがデバイスとユーザーを分類する方法を決定することができます。
Nexthinkの製品と機能を通じてデバイスとユーザーの分類を使用します:
データを照会し調査を実行するために、NQLデータモデルの表—
device.organization, device.location, user.organizationを活用します。組み込みダッシュボードや特定のカスタム可視化をソートするためのフィルタと分解基準を定義します。 カスタムフィルタの使用例については、AIツールの構成の文書を参照してください。
システムは3つの主要な分類構成を提供します:
デバイスの場所は、ルールベースのロジックや公開IPに基づくGeoIPを使用します—システムはバックアップとしてGeoIPを使用します。 デバイスの場所はイベント時にデバイスの位置を把握することを可能とし、効果的な問題解決と一貫したサポートを可能にします。 デバイスの場所は頻繁に変わると予想されます。
デバイスの組織は、組織的エンティティにデバイスをマッピングするためにカスタムルールセットを使用し、組織構造または支店ごとにアクセス、コンプライアンス、ハードウェアライフサイクルを管理できます（たとえば、米国支店、スイスオフィスなど）。 デバイスの場所とは異なり、デバイスの組織は時間とともに変わることはほとんどありません。
ユーザーの組織は、最高レベルから最低レベルまで6つのレベルを使用して組織の階層を定義し、従業員にマップします—あなたの人事管理ツールからのデータを一致させます。
管理 > 製品構成 > デバイスとユーザーの分類へのアクセスには管理者権限が必要です。
デバイスの位置の構成
デバイスの場所により、イベント時にデバイスがどこにあるかを把握することが可能になり、リモートの問題のトラブルシューティングを支援し、一貫したデジタル体験（DEX）を確保します。 イベントは、地理的な場所と場所タイプによりオンサイトまたはリモートで追跡されます。
Nexthinkは、ルールベースのロジック—精度が必要な場合に推奨されています—または公開IPに基づくGeoIPを使用し、ルールベースの場所を割り当てられない場合のバックアップとして使用します。 デバイスの場所は頻繁に変わると予想されます。
管理 > 製品構成 > デバイスとユーザーの分類タブから、デバイスの場所の下で:
ジオロケーションの詳細を設定します。
ルールベースの場所を定義します。
ジオロケーションの詳細設定
Nexthinkはインターネット上のデバイスの場所を、GeoIPデータベースとCollectorを実行しているシステムの公開IPアドレスを参照して決定することができます。
ジオロケーション機能はデフォルトで無効になっており（"位置データを一切記録しない"）、ドロップダウンメニューから利用可能なオプションの1つに詳細度を設定することで有効にできます。
位置データを一切取得しない
公開IPのみ
公開IPと国
公開IP、国、州
公開IP、国、州、都市
ジオロケーション機能を有効にすると、選択した詳細度に関係なく、Nexthinkプラットフォームはインターネットサービスプロバイダー（ISP）の名前を記録します。
仮想プライベートネットワーク（VPN）を使用すると、Collectorが報告する公開IPアドレスに影響します。 ジオロケーションの精度を向上させるためには、CollectorとNexthinkインスタンス間のトラフィックをVPN経由でルーティングしない方が最適です。 この機能はCollectorの任意のバージョンで動作し、情報がNexthinkプラットフォーム外に伝送されることはありません。 Nexthinkにはジオロケーションデータベースの独自のインスタンスがあり、内部でジオロケーション検索を実行します。
ルールベースの場所の定義
Nexthinkプラットフォームは、デバイスの場所を決定するためのルールベースの割り当てプロセスを提供します。 この機能は非常に設定可能で、ルールを変更することで調整できます。
CSVファイルをタブ形式で使用して、割り当てを設定します。 テーブルの各行には2つのパターンと場所の割り当てが含まれます。
ルールベースの位置ルールでCIDR表記を使用する場合、デバイス組織ルールと同じCIDR形式の要件が適用されます。 https://docs.nexthink.com/platform/#classless-inter-domain-routing-cidr-format-requirements-for-ip-based-rules, CIDR形式の要件についてはこちらを参照してください。
ルールベースの場所のCSVファイルの例
カンマ区切りの割り当てテキストファイルの例:
サポートされているField1とField2の値については、このページのこちらを参照してください。
上記のテキストファイルからの割り当てルールを示す表:
primary_local_ip
10.0.0.0/8
名前
NXT*
Onsite
Lausanne
VD
CH
primary_local_ip
172.16.0.0/16
Onsite
Boston
MA
US
名前
*
Remote
最初のルールは、nameが_NXT_で始まるローカルサブネット10.0.0.0/8に属するすべてのデバイスに_オンサイト_タグを付け、場所をLausanneに割り当てます。
2番目のルールは、ローカルサブネット172.16.0.0/16に属するすべてのデバイスに_オンサイト_タグを付け、場所をBostonに割り当てます。
3番目のルールは、その他のすべてのデバイスに_リモート_タグを付けます。
ルールを満たすには、パターンが対応するフィールドに一致する必要があります。 システムはテーブルの上から下へのルールの優先順位を確立します。 テーブルの最上部でデバイスの割り当てをより具体的にし、下部でより一般的にすることができます。
Field1: 割り当てに使用される第1のフィールドのデータ（このページのこちらを参照してください。）
Pattern1: 第1のフィールドのパターン
Field2: 割り当てに使用される第2のフィールドのデータ（このページのこちらを参照してください。）
Pattern2: 第2のフィールドのためのパターン
Location Type: ターゲットの場所タイプの名前。 許可される場所タイプの値は:
オンサイト
リモート
不明
サイト: デバイスまたはデバイスが配置されている場所のカスタム名。
状態: デバイスまたはデバイスが配置されている場所のISO 3166-2区分コード。 このフィールドを使用して州、県、郡などを示します。 例として、スイスのヴォー州:
VD国: デバイスまたはデバイスが配置されている場所のISO 3166-1 alpha-2国コード。 スイスの場合:
CH
国コードを状態フィールド内で重複しないようにしてください。 例として、ISO 3166-2によれば、バス＝ランフランスの地所フィールドは67であり、FR-67ではありません。 この場合、ルールベースの場所は次のようになります:
primary_local_ip,55.XXX.XX.X/20, Onsite, Illkirch,67, FR
Field1とField2に対するサポートされる値:
名前: デバイスのホスト名。
コレクター_タグ: コレクターのインストール中に割り当てられたタグ番号。 正確な番号のみが一致します。
コレクター_文字列_タグ: コレクターのインストール中に割り当てられたラベル。 この値はパターンマッチングをサポートします。
構成_タグ: デバイスのグループを識別するための構成可能なラベル。 このフィールドの値を[エンリッチメントAPI]に利用して設定します(https://docs.nexthink.com/api/enrichment)。 この値はパターンマッチングをサポートします。
dn: Collectorが報告するデバイスの識別名。 デバイスはActive Directoryドメインの一部でなければなりません。 Collectorが報告する識別名の形式は、もっとも特定からもっとも一般的な属性までの
属性=値要素の標準接続シーケンスです。 例として:CN=ex01,OU=Computers,DC=example,DC=orgad_サイト: デバイスが配置されているActive Directoryサイト。 名前, コレクター_文字列_タグ, dn, ad_サイトフィールドは文字パターンマッチングをサポートします。 関連する文字列パターンを定義するために、次のワイルドカードを使用します:
?文字は単一の文字を置き換えます。*文字はゼロまたは複数の文字を置き換えます。
ip: デバイスの最後の公開IPアドレス。 このフィールドは
public_ip.ip_addressNQLフィールドにマッピングされます。 フィールドのためのパターンとして、以下を指定します:ドット十進法での単一のIPアドレス、例:
192.168.10.1CIDR表記のサブネット、例:
192.168.10.0/24
CIDR表記を使用してサブネットを指定するとき、IPがサブネットのネットワークアドレスを表していることを確認してください。 CIDR形式の要件についてはこちらに準拠してください。
プライマリ_ローカル_ip: プライマリ物理ネットワークアダプタのデバイスの最後のローカルIP。 このフィールドは
connectivity.last_local_ipNQLフィールドにマッピングされます。 ip フィールドで指定する方法と同じように、パターンを指定します。コレクター_ローカル_ip: エンドポイントとNexthinkインスタンス間のトラフィックに使用されるローカルIP。 このフィールドは
collector.local_ipNQLフィールドにマッピングされます。 ip フィールドで指定する方法と同じように、パターンを指定します。WiFi_ssid: プライマリネットワークアダプタに関連するWiFiネットワーク名（SSID）。 この値はパターンマッチングをサポートします。
公開IPアドレスをベースにしたルールを構築し始める前にジオロケーションを有効にしてください。
wifi_ssid タグを使用するには、次の コレクターパラメータを無効にしてください: ANONYMIZE_WIFI_NETWORK
ルールベースの場所のためのCSVファイルの考慮事項
CSV構成ファイルが以下の基準を満たしていることを確認してください:
ファイルサイズは5MB未満です。
ファイルエンコーディングはUTF-8です。
フィールドセパレーターはカンマです。
フィールドデリミタはオプションであり、引用符
"のみが許可されるデリミタタイプです。ルールまたは行の総数は40,000未満です。
一意のサイトの最大数は5,000です。
表の最後の行には
Field1=nameとPattern1=*のキャッチオールルールが入力されています。
これらのチェックのいずれかが失敗した場合、ファイル選択は以前にアップロードされたファイルに戻ります。 エラーを修正した場合のみ、アップロードを解除できます。
保存時にプログラムが余分な文字を自動的に追加しないようにするために、Notepad++ や Sublime Text などのプレーンテキストエディタを使用してCSVファイルを編集してください。
デバイスの組織の構成
クラシックな階層を使用している組織は、デバイスの組織カスタムルールセットに移行する必要があります。
移行ステップについては、エンティティと階層からルールベースの組織へ の文書を参照してください。
デバイスの組織は、組織ルールセットを使用してデバイスを組織的エンティティにマップし、組織構造に沿ってエンティティをグループ化します。 これにより、組織構造や支店（米国支店、スイスオフィスなど）別にアクセス、サポート、コンプライアンス、ハードウェアライフサイクルを管理できます。
頻繁に変更されるデバイスの場所とは異なり、デバイスの組織は比較的安定しています。 たとえば、スイス所有のデバイスが複数の国で使用されることがあります。
管理 > 製品構成 > デバイスとユーザーの分類タブから、デバイスの組織の下で:
CSVファイルをタブ形式で使用して、割り当てを設定します。 テーブルの各行には2つのパターンとエンティティ名が含まれます。 テーブルにはエンティティのカスタム分類を任意に含めることができます。
デバイスの組織ルールで CIDR 表記のIPアドレスフィールドを使用する場合、IPの値はサブネットのネットワークアドレスを表す必要があります。
最初にルールセットをアップロードするとき、CSVファイルのサイズに応じて、データの集計には20から60分の遅延が発生します。
IPベースの規則に用いるクラスレスインタードメインルーティング（CIDR）形式の要件
サブネット内のホストIPアドレスを使用して定義されたCIDR範囲は、デバイス組織ルールには対応していません。 IP部分はCIDRプレフィックスと一致し、すべてのホストビットはゼロに設定される必要があります。
たとえば：
有効な例:
10.136.16.0/21無効な例:
10.136.16.1/21
CIDR範囲がネットワークアドレスから始まらない場合、CSVファイルはアップロード時に受け付けられますが、デバイスはエンティティに一致しません。
デバイス組織ルールセットのCSVファイルの例
カンマ区切りの割り当てテキストファイルの例:
上記のテキストファイルからの割り当てルールを示す表:
Global Region
名前
device-d*
FRANCE
EUROPE
名前
device-1*
CANADA
AMERICAS
collector_string_tag
CH*
SWITZERLAND
EUROPE
collector_string_tag
US*
UNITED STATES
AMERICAS
名前
*
Unassigned
Unassigned
表の各行には、2つのパターン、エンティティ名、およびオプションで追加のカスタム分類が含まれています。 規則を満たすには、パターンが対応するフィールドと一致する必要があります。 システムは、表の上から下への優先順位で規則を評価します。 これは、表の上でデバイス割り当てをより具体的にし、下ではより一般的にすることを要求します。
例えば、name が device-d100 で、collector_string_tag が CH10 のデバイスを持っているとします。 このデバイスは、最初の規則と三番目の規則の両方に一致します。 システムが device-d100 の規則を最初に評価するため、デバイスはエンティティ FRANCE とグローバル地域 EUROPE に割り当てられます。
最初の5列は必須です：
Field1: 割り当てに使用する最初のフィールドのデータ（このページのField1およびField2のサポートされる値を参照してください。）
Pattern1: 最初のフィールドのパターン
Field2: 割り当てに使用する第二のフィールドのデータ（このページのField1およびField2のサポートされる値を参照してください。）
Pattern2: 第二のフィールドのパターン
Entity: ターゲットエンティティの名前
必須列に加えて、最大6つのカスタム列を分類に追加できます。
システムはヘッダー行を使用して分類のNQL IDを作成します。 それらの値にはスペースや特殊文字を含めることはできません。 第二行の値は表示名に対応しています。
#region はNQL IDです。
Global Region は分類のNQL IDの表示名です。
Field1およびField2のサポートされる値:
name: デバイスのホスト名。
collector_tag: Collectorインストール中に割り当てられたタグ番号。 システムは正確な番号のみを一致させます。
collector_string_tag: Collectorインストール中に割り当てられたラベル。 この値はパターンマッチングをサポートします。
configuration_tag: デバイスグループを識別する構成可能なラベル。 このフィールドの値はEnrichment APIを使用して設定します。 この値はパターンマッチングをサポートします。
dn: Collectorによって報告されたデバイスの識別名。 デバイスはActive Directoryドメインの一部でなければなりません。 Collectorによって報告される識別名の形式は、
属性=値の要素がカンマで接続され、最も具体的な属性から最も一般的な属性への順である。 例:CN=ex01,OU=Computers,DC=example,DC=orgad_site: デバイスが位置するActive Directoryサイト。 name、collector_string_tag、dn、および ad_site のフィールドは、文字パターンマッチングをサポートします。 関連する文字列パターンを定義するには、以下のワイルドカードを使用します:
?キャラクターは1文字を代用します。*キャラクターは0文字以上を代用します。
ip: デバイスの最後のパブリックIPアドレス（NQLデータモデル の
public_ip.ip_addressを参照）。 フィールドのパターンとして以下のいずれかを指定します:ドット10進表記の単一IPアドレス、例:
192.168.10.1CIDR表記のサブネット、例:
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の両方に誤って割り当てられているため、以下の割り当てルールはシステムによって拒否されます。
Global Region
名前
device-d*
FRANCE
EUROPE
名前
device-e*
FRANCE
AMERICAS
これらのチェックのいずれかに失敗した場合、ファイルの選択は以前にアップロードしたファイルに戻ります。 エラーを修正することでアップロードのブロックを解除できます。
保存時にプログラムが自動的に余分な文字を追加しないように、Notepad++ や Sublime Text などのプレーンテキストエディタを使用してCSVファイルを編集してください。
カスタム分類の更新
組織構造を最適に反映した改訂版のCSVファイルをアップロードすることにより、カスタム分類を更新します。 次の操作を行うことができます：
既存のカスタム分類を削除するには、列全体を削除します。
新しいカスタム分類を追加するには、新しい列を追加します。
新しいCSVがアップロードされると、古いカスタム分類はデータモデルから除外され、オートコンプリートによる提案はされなくなります。
カスタム分類の更新は、組織データに依存する既存のNQLクエリの結果に影響を与える可能性があります。 カスタム分類の変更後、これらのNQLクエリをレビューおよび更新することを確認してください。
ドメインの表示権限は、カスタム分類を含む組織データに依存します。 割り当てルールの変更により、限定されたドメイン表示権限を持つユーザーに利用可能なデータの範囲が影響を受ける場合があります。
カスタム分類の変更後、限定されたドメインアクセス権を持つプロファイルを必ず見直してください。
ユーザー組織の構成
ユーザー組織 は、会社の階層またはホラクラシーとして定義された組織の従業員グループにユーザーをマッピングし、人事管理ツールからの値に一致させます。
ユーザー組織フィールドを定義するには、管理 > 製品構成 > デバイスとユーザーの分類 タブの ユーザー組織 から：
ユーザー組織フィールドを作成
HR階層またはグループに相当する最大6つまでのユーザー組織フィールドを追加できます：
新しいユーザー組織フィールドを追加し、その説明を含めます。例： 事業部門。
システムは、作成されたフィールドに対して自動的に NQL ID を生成します：
business_unit。
作成されたユーザー組織フィールドアイテムをドラッグアンドドロップして会社の階層に従って並べ替えます。
使用例：ユーザー組織フィールドは、従業員グループごとのAIツール使用状況を監視するカスタムフィルターとして機能します。
新しいフィールドがデータモデルに追加されるため、[#ユーザー組織フィールドを充実させる](product-configuration.md#enrich-the-user-organization-fields "mention")必要がありますが、その値は存在しません。
Nexthinkのインバウンドコネクタをデータの充実化のために使用する場合、コネクタを可能な限り早く実行するようにスケジュールします。 これにより、コネクタの設定された繰り返しによる遅延が最小化されます。
ユーザー組織フィールドを充実させる
ユーザー組織フィールドをデータで充実させるためには、以下のオプションを使用してください：
インバウンドコネクタを使用したフィールドマッピング—以下の画像を参照して、WorkdayやSalesforceなどの従業員管理アプリケーションにアクセスし、従業員属性をユーザー組織フィールドにマッピングします。
遅延を最小にするために、インバウンドコネクタの実行を可能な限り早い時間に設定し、データの充実がコネクタの設定された繰り返しに依存するようにします。
Nexthink Enrichment APIを使用して、外部ソースからの属性でユーザー組織フィールドの値を更新します。
カスタムフィールド管理を使用して、ユーザー情報を含むCSVファイルをアップロードしてユーザー組織フィールドを更新します。
調査ページからカスタムフィールドの編集を行い、手動でユーザー情報を使用してユーザー組織フィールドを更新します。
以下の例では、Entra ID用のインバウンドコネクタを使用して、ユーザー組織フィールド—事業部門—を選択された Entra IDフィールド にマッピングします。
フィールドマッピング手順の詳細については、Microsoft Entra ID (Azure AD) コネクタを参照してください。
ユーザー組織フィールドの検証
ユーザー組織のカスタムフィールドを、人事階層と一致するユーザーのグループを集計するNQLクエリを使用して検証します。ここでは、business_unit: EMEA Financeを例にしています。
NQLフィールドと例
データモデルには、2つのレベルで場所と所有権のフィールドが利用可能です:
デバイスまたはユーザーのプロパティ: フィールドは、現在のユーザーまたはデバイスの組織ユニットとデバイスの場所を返します。
イベントコンテキスト: コンテキストフィールドは、イベント時の組織ユニットと場所を返します。
以下の表は、対応するフィールドの概要を示しています。
パブリックIPのジオロケーション
-device.public_ip.countrydevice.public_ip.statedevice.public_ip.city
–
ルールベースのデバイスロケーション * 表の下の説明を参照
device.location.typedevice.location.sitedevice.location.statedevice.location.country
context.location.typecontext.location.sitecontext.location.statecontext.location.country
ルールベースのデバイス組織
device.organization.entitydevice.organization.#customClassification
context.organization.entitycontext.organization.#customClassification
ユーザー組織
user.organization.#customClassification
–
説明:
各デバイスについて、システムはCSVファイル内のルールを探します。 デバイスがルールに一致する場合、システムは以下のいずれかの方法でロケーションデータを取得します:
ルールが
Location TypeとSite,State,またはCountryフィールドの1つ以上にデータを持つ場合、そのフィールドからロケーションデータを取得します。 これらのいずれかのフィールドにデータが含まれている場合、システムはルールベースのロケーションデータを使用し、空のフィールドはクエリで空の値として表示されます。ルールが
Location Typeフィールドのみにデータがあり、Site,State,およびCountryフィールドが空の場合、システムはジオロケーションを使用してロケーションデータを取得します。
詳しくは以下の表を参照してください:
Location Typeデータ
Site, State, Countryまたはすべてにデータ
Location Typeデータ
なしのデータ Site, State, Countryにデータ
ルールベースの位置情報
✓
位置情報
✓
使用例: 製品構成フィールドのクエリ
次のNQL例では、製品構成機能を使用しています。
Salesforceユーザーの地理的分布
Salesforceユーザーの地理的分布を見つけてください:
デバイスのイベント時におけるロケーションを用いた実行クラッシュの調査
過去7日間のすべてのデバイスでの実行クラッシュ数を調査し、地理的な傾向を見つけます。 実行クラッシュ時のデバイスの位置を確認するためにcontext.locationを使用します。 このクエリは、context.locationフィールドからデータを取得し、イベント時のデバイスの位置を保存します。
イベントコンテキストと現在のデバイスロケーションを使用してWiFiネットワーク品質を調査する
次のクエリを使用し、過去に悪い接続イベントがあったサイトを
context.locationを用いて確認します。 このクエリは、イベント時のデバイスの位置を保存するcontext.locationフィールドからデータを取得します:
これで、特定のサイトが悪い接続に悩まされているかどうかがわかります。 その場所でWiFiの品質をアダプターの種類に分けて確認し、潜在的な根本原因を探します。 これを行うために、次のクエリは
device.locationを使用します:
組織エンティティによるデバイスのフィルタリング
エンティティによってデバイスをフィルタリングし、組織の特定の部分内で対象とします:
組織単位によるユーザーのフィルタリング
#チームによってユーザーをフィルタリングし、組織の特定の部分内で対象とします:
カスタムの地域とロケーションタイプによるDEXスコアの比較
DEXスコアを#regionとlocation.typeで分解し、組織全体でデジタルエクスペリエンスの一貫性を確保します。
Last updated
Was this helpful?