> 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).
# デバイスとユーザーの分類
**Product configuration** の **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)のドキュメントを参照してください。
システムには、主に次の 3 つの分類設定があります：
* **Device location** は、ルールベースのロジックおよび/またはパブリック IP に基づく GeoIP を使用します。システムは GeoIP をフォールバックとして使用します。 Device location により、イベント発生時のデバイスの場所を把握でき、効果的な問題のトラブルシューティングと一貫したサポートが可能になります。 デバイスの位置情報は頻繁に変更されることが想定されます。
* **Device organization** は、カスタムルールセットを使用してデバイスを組織エンティティにマッピングします。これにより、組織構造または支社（例: 米国支社、スイスオフィスなど）ごとにアクセス、コンプライアンス、ハードウェアのライフサイクルを管理できます。 Device location とは異なり、Device organization は時間の経過に対して比較的安定しています。
* **User organization** は、最上位から最下位まで最大 6 レベルを使用して組織階層を定義し、HR 管理ツールのデータと照合して従業員にマッピングします。
{% hint style="warning" %}
**Device and user classification** へのアクセスには、管理者[権限](https://github.com/nexthink/documentation.online-product-documentation/tree/develop/ja_docs/configuring_nexthink/configuring-your-platform/administration/account-management/roles/README.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* としてタグ付けし、位置サイトとして Lausanne を割り当てます。
* 2 番目のルールでは、ローカルサブネット 172.16.0.0/16 に属するすべてのデバイスを *Onsite* としてタグ付けし、ロケーションサイトとして Boston を割り当てます。
* 3 番目のルールでは、その他すべてのデバイスを *Remote* としてタグ付けします。
ルールを満たすには、パターンが対応するフィールドに一致する必要があります。 システムは、テーブルの上から下の順にルールの優先順位を設定します。 テーブルの上部ではデバイスの割り当てをより具体的にし、下部ではより一般的にできます。
* **Field1**: 割り当てに使用する最初のフィールドのデータ（このページの[Field1 および Field2 でサポートされる値](#supported-values-for-field1-and-field2)を参照してください。）
* **Pattern1**: 最初のフィールドのパターン
* **Field2**: 割り当てに使用する 2 番目のフィールドのデータ（このページの[Field1 および Field2 でサポートされる値](#supported-values-for-field1-and-field2)を参照してください。）
* **Pattern2**: 2 番目のフィールドのパターン
* **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** の各フィールドは、文字パターンマッチングをサポートします。 関連する文字列パターンを定義するには、次のワイルドカードを使用します：
* `?` 文字は単一の文字を置き換えます。
* `*` 文字は 0 個以上の文字を置き換えます。
* **ip:** デバイスの最後のパブリック IP アドレス。 このフィールドは、`devices` テーブルの `public_ip.ip_address` [NQL フィールド](/platform/ja/understanding-key-data-platform-concepts/nql-data-model.md)にマッピングされます。\
フィールドのパターンとして、次のいずれかを指定します：
* ドット区切りの 10 進表記による単一の 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 構成ファイルが次の条件を満たしていることを確認してください：
* ファイルサイズが 5 MB 未満であること。
* ファイルエンコーディングが UTF-8 であること。
* フィールド区切り文字がカンマであること。
* フィールド区切り文字は任意で、使用できる区切り文字のタイプは引用符 `"` のみであること。
* ルールまたは行の総数が 40,000 未満であること。
* 一意のサイトの最大数が 5,000 であること。
* テーブルの最終行に、`Field1=name` および `Pattern1=*` の包括ルールが入力されていること。
これらのチェックのいずれかに失敗すると、ファイル選択は以前にアップロードされたファイルに戻ります。 エラーを修正した場合にのみ、アップロードのブロックを解除できます。
{% hint style="info" %}
保存時にプログラムが余分な文字を自動的に追加するのを防ぐため、CSV ファイルの編集には Notepad++ や Sublime Text などのプレーンテキストエディターを使用してください。
{% endhint %}
***
## Device organization の設定
{% hint style="warning" %}
従来の階層を使用している組織は、**Device organization** のカスタムルールセットに移行する必要があります。
移行手順については、Nexthink Community ユーザー向けに提供されている[Entities and Hierarchies to Rule-based Organization](https://edocs.nexthink.com/infinity-transition/detailed-transition-advice/entities-and-hierarchies-to-rule-based-organization)ドキュメントを参照してください。
{% endhint %}
**Device organization** は、組織ルールセットを使用してデバイスを組織エンティティにマッピングし、組織構造に沿ってエンティティをグループ化します。 これにより、組織構造または支社（米国支社、スイスオフィスなど）ごとにアクセス、サポート、コンプライアンス、ハードウェアのライフサイクルを管理できます。
頻繁に変更される Device location とは異なり、Device organization は比較的安定しています。 たとえば、スイス所有のデバイスが複数の国で使用される場合があります。
**Administration > Product configuration > Device and user classification** タブの **Device organization** セクションで：
表形式構造の CSV ファイルを使用して割り当てを設定します。 テーブルの各行には、2 つのパターンとエンティティ名が含まれます。 テーブルには、必要に応じてエンティティのカスタム分類を含めることができます。
{% 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* 米国 アメリカ大陸 名前 * 未割り当て 未割り当て
テーブルの各行には、2 つのパターン、エンティティ名、および任意の追加カスタム分類が含まれます。 ルールを満たすには、パターンが対応するフィールドに一致する必要があります。 システムは、テーブルの上から下の順にルールの優先順位を設定します。 このため、テーブルの上部ではデバイスの割り当てをより具体的にし、下部ではより一般的にする必要があります。
`name` が `device-d100`、`collector_string_tag` が `CH10` のデバイスがあるとします。 このデバイスは、最初と 3 番目の両方のルールに一致します。 システムは `device-d100` ルールを最初に評価するため、デバイスにはエンティティ `FRANCE` およびグローバル地域 `EUROPE` が割り当てられます。
最初の 5 列は必須です：
* **Field1:** 割り当てに使用する最初のフィールドのデータ（このページの[Field1 および Field2 でサポートされる値](#supported-values-for-field1-and-field2-1)を参照してください。）
* **Pattern1:** 最初のフィールドのパターン
* **Field2:** 割り当てに使用する 2 番目のフィールドのデータ（このページの[Field1 および Field2 でサポートされる値](#supported-values-for-field1-and-field2-1)を参照してください。）
* **Pattern2:** 2 番目のフィールドのパターン
* **Entity**: 対象エンティティの名前
必須列に加えて、分類用のカスタム列を最大 6 列追加します。
システムはヘッダー行を使用して分類の NQL ID を作成します。 これらの値にスペースや特殊文字を含めることはできません。 2 行目の値は表示名に対応します。
ヨーロッパ |
| 名前 | device-e\* | | | フランス | アメリカ大陸 |
これらのチェックのいずれかに失敗すると、ファイル選択は以前にアップロードされたファイルに戻ります。 エラーを修正した場合にのみ、アップロードのブロックを解除できます。
{% hint style="info" %}
保存時にプログラムが余分な文字を自動的に追加するのを防ぐため、CSV ファイルの編集には Notepad++ や Sublime Text などのプレーンテキストエディターを使用してください。
{% endhint %}
### **カスタム分類の更新**
組織構造を最も適切に反映する改訂済み CSV ファイルをアップロードして、カスタム分類を更新します。 次のことができます：
* 既存のカスタム分類を削除するには、列全体を削除します。
* 新しいカスタム分類を追加するには、新しい列を含めます。
新しい CSV をアップロードすると、古いカスタム分類はデータモデルから削除され、オートコンプリートで提案されなくなります。
{% hint style="warning" %}
カスタム分類を更新すると、組織データに依存する既存の NQL クエリの結果に影響する可能性があります。 カスタム分類を変更した後は、これらの NQL クエリを確認して更新してください。
[View domain](https://github.com/nexthink/documentation.online-product-documentation/tree/develop/ja_docs/user-guide/administration/account-management/roles/view-domain.md) 権限は、カスタム分類を含む組織データに依存します。 割り当てルールを変更すると、View domain 権限が制限されているユーザーが利用できるデータの範囲に影響する可能性があります。
カスタム分類を変更した後は、View domain アクセスが制限されているプロファイルを必ず更新してください。
{% endhint %}
***
## User organization の設定
**User organization** は、会社の階層またはホラクラシーによって定義された組織の従業員グループにユーザーをマッピングし、HR 管理ツールの値と照合します。
**ユーザー組織フィールド** は、ダッシュボードや調査におけるデータ整理に役立ち、構成およびエンリッチ後は、従業員グループ間のAIツール使用状況を監視するためのカスタムフィルターとして機能します。
{% stepper %}
{% step %}
### **ユーザー組織フィールドの作成**
**Administration > Product configuration > Device and user classification** タブの **User organization** セクションで：
HR 階層またはグループを表すユーザー組織フィールドを最大 6 つ追加します：
* 説明を含む新しいユーザー組織フィールドを追加します。例: **Business unit**。
* システムは作成されたフィールドの **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. **Add a custom field mapping** を選択して、フィールドマッピングのポップアップを開きます。
{% hint style="warning" %}
データマッピングが成功していることを確認するため、エンリッチされたユーザー組織フィールドを検証する必要があります。 以下の手順を参照してください。
{% endhint %}
{% endstep %}
{% step %}
### **ユーザー組織フィールドを検証する**
Investigations から NQL クエリを実行し、特定の人事階層に一致するユーザーグループを集約して、ユーザー組織のカスタムフィールドを検証します。
この例では、`user.organization.#business_unit == "EMEA Finance"` により、ヨーロッパ、中東、アフリカの従業員を正常にクエリできます。
```sql
users
| where user.organization.#business_unit == "EMEA Finance"
```
{% hint style="info" %}
NQL クエリでは、ユーザー組織フィールドは `user.organization.#[your 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.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 のデータがない）ルールベースの位置情報 ✓ 位置情報 ✓
### ユースケース：製品構成フィールドのクエリ execution.crashes during past 7d
| 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.