> For the complete documentation index, see [llms.txt](https://docs.nexthink.com/platform/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nexthink.com/platform/ja/user-guide/administration/system-configuration/data-management/environment/product-configuration.md).
# デバイスとユーザーの分類
**Device and user classification** タブでは、Nexthink テナントでシステムがデバイスとユーザーを分類する方法を指定できます。
Nexthink の製品や機能全体でデバイスとユーザーの分類を使用して、次のことを行えます：
* NQL データモデルテーブル—`device.organization`、`device.location`、`user.organization`—を活用して、データのクエリや調査を実行します。
* 組み込みダッシュボードおよび特定のカスタムビジュアライゼーションを並べ替えるためのフィルターと分類基準を定義します。カスタムフィルターのユースケース例については、[AI ツールの設定](/platform/ja/user-guide/ai-tools/setting-up-and-managing-ai-tools/configuring-ai-tools.md#configuring-custom-filters-for-ai-tools-dashboards)のドキュメントを参照してください。
システムには、主に次の三つの分類設定があります：
* **デバイスの位置情報**では、ルールベースのロジックおよび/または公開 IP に基づく GeoIP を使用します。GeoIP はフォールバックとして使用されます。デバイスの位置情報を使用すると、イベント発生時のデバイスの所在を把握でき、効果的な問題のトラブルシューティングと一貫したサポートが可能になります。デバイスの位置情報は頻繁に変わることが想定されます。
* **デバイスの組織**では、カスタムルールセットを使用してデバイスを組織エンティティにマッピングします。これにより、組織構造や支社（米国支社、スイスオフィスなど）ごとにアクセス、コンプライアンス、ハードウェアライフサイクルを管理できます。デバイスの位置情報とは異なり、デバイスの組織は時間の経過によって比較的安定しています。
* **ユーザー組織**では、最上位から最下位まで最大六つのレベルを使用して組織階層を定義し、HR 管理ツールのデータと照合して従業員にマッピングします。
{% hint style="warning" %}
**Device and user classification** にアクセスするには、管理者[権限](/platform/ja/user-guide/administration/account-management/roles.md)が必要です。
{% endhint %}
フィールド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 でサポートされる値](#supported-values-for-field1-and-field2)を参照）
* **Pattern1**: 最初のフィールドのパターン
* **Field2**: 割り当てに使用する二番目のフィールドのデータ（このページの[Field1 および Field2 でサポートされる値](#supported-values-for-field1-and-field2)を参照）
* **Pattern2**: 二番目のフィールドのパターン
* **Location Type**: 対象ロケーションタイプの名前。使用できるロケーションタイプの値は次のとおりです：
* オンサイト
* リモート
* 不明
* **Site**: デバイスがあるサイトのカスタム名。
* **State**: デバイスがある場所の ISO 3166-2 区分コード。このフィールドを使用して、州、県、カントンなどを指定します。例: スイスのヴォー州の場合: `VD`
* **Country**: デバイスがある国の ISO 3166-1 alpha-2 国コード。例: スイスの場合: `CH`
{% hint style="warning" %}
**State** フィールド内で **Country** コードを重複させないでください。たとえば、ISO 3166-2 によると、フランスのバ＝ラン県の州フィールドは `FR-67` ではなく `67` です。この場合、ルールベースの位置情報は次のようになります：
`primary_local_ip,55.XXX.XX.X/20, Onsite, Illkirch,`**`67, FR`**
{% endhint %}
#### **Field1 および Field2 でサポートされる値**
* **name:** デバイスのホスト名。
* **collector\_tag:** Collector のインストール時に割り当てられるタグ番号。完全一致する番号のみが照合されます。
* **collector\_string\_tag:** Collector のインストール時に割り当てられるラベル。この値はパターンマッチングをサポートします。
* **configuration\_tag:** デバイスのグループを識別する設定可能なラベル。 [Enrichment API](https://docs.nexthink.com/api/enrichment) を使用して、このフィールドの値を設定します。この値はパターンマッチングをサポートします。
* **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 フィールド](/platform/ja/understanding-key-data-platform-concepts/nql-data-model.md)にマッピングされます。\
フィールドのパターンには、次のいずれかを指定します：
* ドット十進表記の単一 IP アドレス（例：`192.168.10.1`）
* CIDR 表記のサブネット（例：`192.168.10.0/24`）
{% hint style="warning" %}
CIDR 表記でサブネットを指定する場合、IP がサブネットのネットワークアドレスを表していることを確認してください。 [#classless-inter-domain-routing-cidr-format-requirements-for-ip-based-rules](#classless-inter-domain-routing-cidr-format-requirements-for-ip-based-rules "mention") を参照してください。
{% endhint %}
* **primary\_local\_ip:** プライマリ物理ネットワークアダプターのデバイスの最後のローカル IP。このフィールドは、`devices` テーブルの `connectivity.last_local_ip` [NQL フィールド](/platform/ja/understanding-key-data-platform-concepts/nql-data-model.md)にマッピングされます。 **ip** フィールドの場合と同じ方法でパターンを指定します。
* **collector\_local\_ip**: エンドポイントと Nexthink インスタンス間のトラフィックに使用されるローカル IP。このフィールドは、`devices` テーブルの `collector.local_ip` [NQL フィールド](/platform/ja/understanding-key-data-platform-concepts/nql-data-model.md)にマッピングされます。 **ip** フィールドの場合と同じ方法でパターンを指定します。
* **wifi\_ssid:** プライマリネットワークアダプターに関連付けられた WiFi ネットワーク名（SSID）。この値はパターンマッチングをサポートします。
{% hint style="info" %}
公開 IP アドレスに基づくルールの作成を開始する前に、位置情報を有効にしてください。
`wifi_ssid` タグを使用するには、次の [Collector パラメーター](/platform/ja/configuring_nexthink/bringing-data-into-your-nexthink-instance/deploying-nexthink-in-non-vdi-environment/installing-collector/windows-collector-references/collector-msi-parameters-reference-table.md#collectormsiparametersreferencetable-optionalparameters)を無効にします: `ANONYMIZE_WIFI_NETWORK`
{% endhint %}
#### ルールベースの位置情報用 CSV ファイルに関する考慮事項
CSV 設定ファイルが次の基準を満たしていることを確認してください：
* ファイルサイズが 5MB 未満である。
* ファイルエンコーディングが UTF-8 である。
* フィールド区切り文字がカンマである。
* フィールド区切り記号は任意であり、使用できる区切り記号は引用符 `"` のみである。
* ルールまたは行の総数が 40,000 未満である。
* 一意のサイトの最大数が 5,000 である。
* 表の最終行に、`Field1=name` および `Pattern1=*` の包括ルールが入力されている。
これらのチェックのいずれかが失敗すると、ファイル選択は前回アップロードしたファイルに戻ります。エラーを修正した場合にのみ、アップロードのブロックを解除できます。
{% hint style="info" %}
保存時にプログラムが余分な文字を自動追加するのを防ぐため、CSV ファイルの編集には Notepad++ や Sublime Text などのプレーンテキストエディターを使用してください。
{% endhint %}
***
## デバイスの組織の設定
{% hint style="warning" %}
従来の階層を引き続き使用している組織は、**デバイスの組織**のカスタムルールセットに移行する必要があります。
移行手順については、Nexthink Community ユーザー向けの[エンティティと階層からルールベースの組織への移行](https://edocs.nexthink.com/infinity-transition/detailed-transition-advice/entities-and-hierarchies-to-rule-based-organization)に関するドキュメントを参照してください。
{% endhint %}
**デバイスの組織**では、組織ルールセットを使用してデバイスを組織エンティティにマッピングし、組織構造に沿ってエンティティをグループ化します。これにより、組織構造または支社（米国支社、スイスオフィスなど）ごとにアクセス、サポート、コンプライアンス、ハードウェアライフサイクルを管理できます。
頻繁に変更されるデバイスの位置情報とは異なり、デバイスの組織は比較的安定しています。たとえば、スイス所有のデバイスは複数の国で使用される場合があります。
**Administration > Product configuration > Device and user classification** タブの **Device organization:** セクションで、次の操作を行います
表形式の CSV ファイルを使用して割り当てを設定します。表の各行には、二つのパターンとエンティティ名が含まれます。表には必要に応じて、エンティティのカスタム分類を含めることができます。
{% hint style="info" %}
デバイス組織ルールで **CIDR** 表記の IP アドレスフィールドを使用する場合、IP 値はサブネットのネットワークアドレスを表す必要があります。
ルールセットを初めてアップロードする場合、CSV ファイルのサイズに応じて、データが入力されるまでに 20 ～ 60 分の**遅延**があります。
{% endhint %}
IP ベースのルールに関する Classless Inter-Domain Routing（CIDR ）形式の要件
サブネット内のホスト IP アドレスを使用して定義された CIDR 範囲は、デバイス組織ルールではサポートされません。 IP 部分は CIDR プレフィックスに一致し、すべてのホストビットが**ゼロ**に設定されている必要があります。
たとえば：
* **有効:** `10.136.16.0/21`
* **無効:** `10.136.16.1/21`
CIDR 範囲がネットワークアドレスから始まらない場合、CSV ファイルはアップロード時に受け入れられますが、デバイスはエンティティに一致しません。
フィールド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 でサポートされる値](#supported-values-for-field1-and-field2-1)を参照）
* **Pattern1:** 最初のフィールドのパターン
* **Field2:** 割り当てに使用する二番目のフィールドのデータ（このページの[Field1 および Field2 でサポートされる値](#supported-values-for-field1-and-field2-1)を参照）
* **Pattern2:** 二番目のフィールドのパターン
* **Entity**: 対象エンティティの名前
必須列に加えて、分類用に最大六つのカスタム列を追加できます。
システムは、ヘッダー行を使用して分類の NQL ID を作成します。これらの値にスペースや特殊文字を含めることはできません。二行目の値は表示名に対応します。
ヨーロッパ |
| 名前 | device-e\* | | | フランス | アメリカ大陸 |
これらのチェックのいずれかが失敗すると、ファイル選択は前回アップロードしたファイルに戻ります。エラーを修正した場合にのみ、アップロードのブロックを解除できます。
{% hint style="info" %}
保存時にプログラムが余分な文字を自動追加するのを防ぐため、CSV ファイルの編集には Notepad++ や Sublime Text などのプレーンテキストエディターを使用してください。
{% endhint %}
### **カスタム分類の更新**
組織構造を最も適切に反映する改訂済み CSV ファイルをアップロードして、カスタム分類を更新します。次のことができます：
* 既存のカスタム分類を削除するには、列全体を削除します。
* 新しいカスタム分類を追加するには、新しい列を含めます。
新しい CSV をアップロードすると、古いカスタム分類はデータモデルから削除され、オートコンプリートでも候補として表示されなくなります。
{% hint style="warning" %}
カスタム分類を更新すると、組織データに依存する既存の NQL クエリの結果に影響する可能性があります。カスタム分類を変更した後は、これらの NQL クエリを確認して更新してください。
[View domain](/platform/ja/user-guide/administration/account-management/roles/view-domain.md) 権限は、カスタム分類を含む組織データに依存します。割り当てルールを変更すると、限定された View domain 権限を持つユーザーが利用できるデータの範囲に影響する可能性があります。
カスタム分類を変更した後は、限定された View domain アクセスを持つプロファイルを必ず見直してください。
{% endhint %}
***
## ユーザーの組織の設定
**ユーザーの組織**では、会社の階層またはホラクラシーで定義された組織の従業員グループにユーザーをマッピングし、HR 管理ツールの値と照合します。
**ユーザー組織フィールド** は、ダッシュボードや調査におけるデータ整理に役立ち、構成およびエンリッチ後は、従業員グループ間のAIツール使用状況を監視するためのカスタムフィルターとして機能します。
{% stepper %}
{% step %}
### **ユーザー組織フィールドの作成**
**Administration** > **Product configuration** > **Device and user classification** タブの **User organization** セクションで：
HR の階層またはグループを表すユーザー組織フィールドを最大六つ追加します：
* 説明を含む新しいユーザー組織フィールドを追加します。例: **事業部**。
* システムは、作成したフィールドの **NQL ID** を自動的に生成します: `#business_unit`。
* NQL クエリでは、このフィールドは `user.organization.#business_unit` として表示されます。
* 作成したユーザー組織フィールド項目をドラッグアンドドロップして、会社の階層に従って並べ替えます。
{% hint style="warning" %}
作成時、user organization fields はデータモデル内に存在しますが、空の状態です。したがって、常に [#enrich-the-user-organization-fields](#enrich-the-user-organization-fields "mention") を実行する必要があります。
{% endhint %}
Nexthink エンリッチメント API
外部ソースの属性を使用してユーザー組織フィールドの値を更新するには、Nexthink [Enrichment API](https://docs.nexthink.com/api/enrichment) を使用します。
<0>ユーザー情報を含む CSV ファイルによるカスタムフィールド\
**Administration** > **Custom Fields** から、ユーザー情報を含む CSV ファイルをアップロードして、作成したユーザー組織フィールドを管理し、値を**更新**します。
[カスタムフィールド管理](/platform/ja/user-guide/administration/content-management/custom-fields-management.md#customfieldsmanagement-updatingcustomfieldsbyimportingacsvfileimportcsv) を参照してください。
調査からのカスタムフィールドの手動更新
**Investigations** から、ユーザー情報を使用してユーザー組織フィールドを手動で更新します。
[カスタムフィールド管理](/platform/ja/user-guide/administration/content-management/custom-fields-management.md#customfieldsmanagement-editingcustomfieldsontheinvestigationspageeditcf) を参照してください
#### **例: Entra ID インバウンドコネクタを使用したユーザー組織フィールドの拡充**
作成したユーザー組織フィールドを、今回は **Entra ID** インバウンドコネクターを使用して充実させるには:
1 — Nexthink で Entra ID (Azure AD) コネクターを構成する
Nexthink で **Entra ID (Azure AD)** コネクタを構成します。ユーザーデータのエンリッチメントに利用できる他のインバウンドコネクタも、フィールドマッピングをサポートしています。
[Nexthink での Microsoft Entra ID（Azure AD）コネクタの設定](/platform/ja/configuring_nexthink/bringing-data-into-your-nexthink-instance/integrating-nexthink-with-third-party-tools/inbound-connectors/connector-for-microsoft-entra-id-azure-ad.md#connectorformicrosoftentraid-azuread-configuringthenexthinkwebinterface-configureentraidconnectortru)を参照してください。
{% hint style="warning" %}
Nexthink のインバウンドコネクタを使用してデータをエンリッチする場合、コネクタの実行スケジュールを可能な限り早い時間に設定してください。これにより、コネクタのスケジュールされた繰り返しによる遅延が最小限に抑えられます。
{% endhint %}
2 — ユーザー組織フィールドを選択した Entra ID フィールド にマッピングします
Entra ID コネクターの構成で、**Field mapping** タブの下にある項目から:
1. **カスタムフィールドマッピングを追加**して、フィールドマッピングのポップアップを開きます。
{% hint style="warning" %}
データマッピングが成功したことを確認するため、エンリッチされたユーザー組織フィールドを検証してください。以下の手順を参照してください。
{% endhint %}
{% endstep %}
{% step %}
### **ユーザー組織フィールドの検証**
Investigations から NQL クエリを実行し、特定の HR 階層に一致するユーザーグループを集計して、ユーザー組織カスタムフィールドを検証します。
この例では、`user.organization.#business_unit == "EMEA Finance"` により、ヨーロッパ、中東、アフリカの従業員が正常にクエリされます。
```sql
users
| where user.organization.#business_unit == "EMEA Finance"
```
{% hint style="info" %}
NQL クエリでは、ユーザー組織フィールドは `user.organization.#[ユーザー組織 NQL ID]` として表示されます。
{% endhint %}
{% endstep %}
{% endstepper %}
***
## NQL フィールドと例 オブジェクトプロパティ イベントコンテキスト 公開 IP の位置情報 device.public_ip.countrydevice.public_ip.state device.public_ip.city – ルールベースのデバイス位置情報 device.location.typedevice.location.sitedevice.location.state device.location.countrycontext.location.type context.location.site context.location.statecontext.location.country ルールベースのデバイス組織 device.organization.entitydevice.organization.#customClassification context.organization.entitycontext.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ルールベースの位置情報 ✓ 位置情報 ✓
### ユースケース: 製品設定フィールドのクエリ 過去 7 日間の execution.crashes
| summarize total_crashes=number_of_crashes.sum() by context.location.country, context.location.state, context.location.site
&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
