# 製品構成

製品構成ページでは、特定の機能を有効化し、Nexthink テナント内でシステムがデバイスおよびユーザーをどのように分類するかを決定できます。

## 機能

**構成**サブタブで、Nexthink テナント内の特定の機能の有効化ステータスを変更します。

* **AI ツール:** AI ツールの使用を有効化し、次のことを可能にします:
  * 未承認またはシャドー ツールを含む、組織内での AI 使用状況を明らかにします。
  * チャンピオンや摩擦のある領域を明確にしながら、採用パターンを追跡します。
  * 競争力を維持するために、同業他社と AI 採用状況を比較します。
  * 節約されたと認識される時間や従業員からのフィードバックを通じて、影響を定量化します。
  * 推奨事項に基づいて AI 採用インサイトを活用し、効果的な施策をスケールします。
    * 詳細については、[getting-started-with-ai-tools](https://docs.nexthink.com/platform/ja/user-guide/ai-tools/getting-started-with-ai-tools "mention") を参照してください。
* **Web 検索:** Workspace が精選された外部ソースから情報を取得できるようにし、最新のベンダー ガイダンス、既知の問題、業界のベスト プラクティスを必要とする質問への回答を支援します。
  * 詳細については、[#web-search](https://docs.nexthink.com/platform/ja/search-and-workspace/using-workspace#web-search "mention") を参照してください。

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

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

Nexthinkの製品と機能を通じてデバイスとユーザーの分類を使用します:

* データを照会し調査を実行するために、NQLデータモデルの表— `device.organization, device.location, user.organization` を活用します。
* 組み込みダッシュボードや特定のカスタム可視化をソートするためのフィルタと分解基準を定義します。 カスタムフィルタの使用例については、[AIツールの構成](https://docs.nexthink.com/platform/ja/ai-tools/configuring-ai-tools#configuring-custom-filters-for-ai-tools-dashboards)の文書を参照してください。

システムは3つの主要な分類構成を提供します:

* **デバイスの場所**は、ルールベースのロジックや公開IPに基づくGeoIPを使用します—システムはバックアップとしてGeoIPを使用します。 デバイスの場所はイベント時にデバイスの位置を把握することを可能とし、効果的な問題解決と一貫したサポートを可能にします。 デバイスの場所は頻繁に変わると予想されます。
* **デバイスの組織**は、組織的エンティティにデバイスをマッピングするためにカスタムルールセットを使用し、組織構造または支店ごとにアクセス、コンプライアンス、ハードウェアライフサイクルを管理できます（たとえば、米国支店、スイスオフィスなど）。 デバイスの場所とは異なり、デバイスの組織は時間とともに変わることはほとんどありません。
* **ユーザーの組織**は、最高レベルから最低レベルまで6つのレベルを使用して組織の階層を定義し、従業員にマップします—あなたの人事管理ツールからのデータを一致させます。

{% hint style="warning" %}
**管理** > **製品構成** > **デバイスとユーザーの分類**へのアクセスには管理者[権限](https://github.com/nexthink/documentation.online-product-documentation/blob/develop/ja_docs/configuring_nexthink/configuring-your-platform/administration/account-management/roles/README.md)が必要です。
{% endhint %}

<figure><img src="https://3549141153-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FeLm8O7QKZDn6z806e7Sv%2Fuploads%2Fgit-blob-c0f0922463200f8981547dcc8290e2edb844d761%2Fimage%20(911).png?alt=media" alt=""><figcaption></figcaption></figure>

***

## デバイスの位置の構成

**デバイスの場所**により、イベント時にデバイスがどこにあるかを把握することが可能になり、リモートの問題のトラブルシューティングを支援し、一貫したデジタル体験（DEX）を確保します。 イベントは、地理的な場所と場所タイプによりオンサイトまたはリモートで追跡されます。

Nexthinkは、ルールベースのロジック—精度が必要な場合に推奨されています—または公開IPに基づくGeoIPを使用し、ルールベースの場所を割り当てられない場合のバックアップとして使用します。 デバイスの場所は頻繁に変わると予想されます。

管理 > 製品構成 > デバイスとユーザーの分類タブから、**デバイスの場所**の下で:

1. **ジオロケーションの詳細**を設定します。
2. **ルールベースの場所**を定義します。

### ジオロケーションの詳細設定 <a href="#productconfiguration-geolocationtab" id="productconfiguration-geolocationtab"></a>

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

ジオロケーション機能はデフォルトで無効になっており（"位置データを一切記録しない"）、ドロップダウンメニューから利用可能なオプションの1つに詳細度を設定することで有効にできます。

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

<figure><img src="https://3549141153-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FeLm8O7QKZDn6z806e7Sv%2Fuploads%2Fgit-blob-5c092bc92f05ee0709b4e99590ae003d758dedf5%2Fimage%20(908).png?alt=media" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
ジオロケーション機能を有効にすると、選択した詳細度に関係なく、Nexthinkプラットフォームはインターネットサービスプロバイダー（ISP）の名前を記録します。
{% endhint %}

仮想プライベートネットワーク（VPN）を使用すると、Collectorが報告する公開IPアドレスに影響します。 ジオロケーションの精度を向上させるためには、CollectorとNexthinkインスタンス間のトラフィックをVPN経由でルーティングしない方が最適です。 この機能はCollectorの任意のバージョンで動作し、情報がNexthinkプラットフォーム外に伝送されることはありません。 Nexthinkにはジオロケーションデータベースの独自のインスタンスがあり、内部でジオロケーション検索を実行します。

### **ルールベースの場所の定義** <a href="#productconfiguration-locationtypetab" id="productconfiguration-locationtypetab"></a>

Nexthinkプラットフォームは、デバイスの場所を決定するためのルールベースの割り当てプロセスを提供します。 この機能は非常に設定可能で、ルールを変更することで調整できます。

CSVファイルをタブ形式で使用して、割り当てを設定します。 テーブルの各行には2つのパターンと場所の割り当てが含まれます。

{% hint style="warning" %}
ルールベースの位置ルールでCIDR表記を使用する場合、デバイス組織ルールと同じCIDR形式の要件が適用されます。 <https://docs.nexthink.com/platform/#classless-inter-domain-routing-cidr-format-requirements-for-ip-based-rules>, CIDR形式の要件については[こちら](#classless-inter-domain-routing-cidr-format-requirements-for-ip-based-rules)を参照してください。
{% endhint %}

<figure><img src="https://3549141153-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FeLm8O7QKZDn6z806e7Sv%2Fuploads%2Fgit-blob-a3dc6c26fc117c46d7db5d2cea7e40674161ce3e%2Fimage%20(909).png?alt=media" alt=""><figcaption></figcaption></figure>

### **ルールベースの場所の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,,,
```

{% hint style="info" %}
サポートされているField1とField2の値については、このページの[こちら](#supported-values-for-field1-and-field2)を参照してください。
{% endhint %}

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

<table data-full-width="true"><thead><tr><th>Field1</th><th>Pattern1</th><th>Field2</th><th>Pattern2</th><th>Location Type</th><th>Site</th><th>地域</th><th>国</th></tr></thead><tbody><tr><td>primary_local_ip</td><td>10.0.0.0/8</td><td>名前</td><td>NXT*</td><td>Onsite</td><td>Lausanne</td><td>VD</td><td>CH</td></tr><tr><td>primary_local_ip</td><td>172.16.0.0/16</td><td></td><td></td><td>Onsite</td><td>Boston</td><td>MA</td><td>US</td></tr><tr><td>名前</td><td>*</td><td></td><td></td><td>リモート</td><td></td><td></td><td></td></tr></tbody></table>

* 最初のルールは、nameが\_NXT\_で始まるローカルサブネット10.0.0.0/8に属するすべてのデバイスに\_オンサイト\_タグを付け、場所をLausanneに割り当てます。
* 2番目のルールは、ローカルサブネット172.16.0.0/16に属するすべてのデバイスに\_オンサイト\_タグを付け、場所をBostonに割り当てます。
* 3番目のルールは、その他のすべてのデバイスに\_リモート\_タグを付けます。

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

* **Field1**: 割り当てに使用される第1のフィールドのデータ（このページの[こちら](#supported-values-for-field1-and-field2)を参照してください。）
* **Pattern1**: 第1のフィールドのパターン
* **Field2**: 割り当てに使用される第2のフィールドのデータ（このページの[こちら](#supported-values-for-field1-and-field2)を参照してください。）
* **Pattern2**: 第2のフィールドのためのパターン
* **Location Type**: ターゲットの場所タイプの名前。 許可される場所タイプの値は:
  * オンサイト
  * Remote
  * 不明
* **サイト**: デバイスまたはデバイスが配置されている場所のカスタム名。
* **状態**: デバイスまたはデバイスが配置されている場所のISO 3166-2区分コード。 このフィールドを使用して州、県、郡などを示します。 例として、スイスのヴォー州: `VD`
* **国**: デバイスまたはデバイスが配置されている場所のISO 3166-1 alpha-2国コード。 スイスの場合: `CH`

{% hint style="warning" %}
**国**コードを**状態**フィールド内で重複しないようにしてください。 例として、ISO 3166-2によれば、バス＝ランフランスの地所フィールドは`67`であり、`FR-67`ではありません。 この場合、ルールベースの場所は次のようになります:

`primary_local_ip,55.XXX.XX.X/20, Onsite, Illkirch,`**`67, FR`**
{% endhint %}

#### **Field1とField2に対するサポートされる値:**

* **名前:** デバイスのホスト名。
* **コレクター\_タグ:** コレクターのインストール中に割り当てられたタグ番号。 正確な番号のみが一致します。
* **コレクター\_文字列\_タグ:** コレクターのインストール中に割り当てられたラベル。 この値はパターンマッチングをサポートします。
* **構成\_タグ:** デバイスのグループを識別するための構成可能なラベル。 このフィールドの値を\[エンリッチメントAPI]に利用して設定します(<https://docs.nexthink.com/api/enrichment)。> この値はパターンマッチングをサポートします。
* **dn:** Collectorが報告するデバイスの識別名。 デバイスはActive Directoryドメインの一部でなければなりません。 Collectorが報告する識別名の形式は、もっとも特定からもっとも一般的な属性までの`属性=値`要素の標準接続シーケンスです。 例として: `CN=ex01,OU=Computers,DC=example,DC=org`
* **ad\_サイト:** デバイスが配置されているActive Directoryサイト。 **名前**, **コレクター\_文字列\_タグ**, **dn**, **ad\_サイト**フィールドは文字パターンマッチングをサポートします。 関連する文字列パターンを定義するために、次のワイルドカードを使用します:
  * `?` 文字は単一の文字を置き換えます。
  * `*` 文字はゼロまたは複数の文字を置き換えます。
* **ip:** デバイスの最後の公開IPアドレス。 このフィールドは `public_ip.ip_address` [NQLフィールド](https://docs.nexthink.com/platform/ja/understanding-key-data-platform-concepts/nql-data-model)にマッピングされます。 フィールドのためのパターンとして、以下を指定します:
  * ドット十進法での単一のIPアドレス、例: `192.168.10.1`
  * CIDR表記のサブネット、例: `192.168.10.0/24`

{% hint style="warning" %}
CIDR表記を使用してサブネットを指定するとき、IPがサブネットのネットワークアドレスを表していることを確認してください。 CIDR形式の要件については[こちらに準拠してください](#classless-inter-domain-routing-cidr-format-requirements-for-ip-based-rules)。
{% endhint %}

* **プライマリ\_ローカル\_ip:** プライマリ物理ネットワークアダプタのデバイスの最後のローカルIP。 このフィールドは `connectivity.last_local_ip` [NQLフィールド](https://docs.nexthink.com/platform/ja/understanding-key-data-platform-concepts/nql-data-model)にマッピングされます。 **ip** フィールドで指定する方法と同じように、パターンを指定します。
* **コレクター\_ローカル\_ip**: エンドポイントとNexthinkインスタンス間のトラフィックに使用されるローカルIP。 このフィールドは `collector.local_ip` [NQLフィールド](https://docs.nexthink.com/platform/ja/understanding-key-data-platform-concepts/nql-data-model)にマッピングされます。 **ip** フィールドで指定する方法と同じように、パターンを指定します。
* **WiFi\_ssid:** プライマリネットワークアダプタに関連するWiFiネットワーク名（SSID）。 この値はパターンマッチングをサポートします。

{% hint style="info" %}
公開IPアドレスをベースにしたルールを構築し始める前にジオロケーションを有効にしてください。

`wifi_ssid` タグを使用するには、次の [コレクターパラメータ](https://docs.nexthink.com/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#collectormsiparametersreferencetable-optionalparameters)を無効にしてください: `ANONYMIZE_WIFI_NETWORK`
{% endhint %}

#### ルールベースの場所のためのCSVファイルの考慮事項

CSV構成ファイルが以下の基準を満たしていることを確認してください:

* ファイルサイズは5MB未満です。
* ファイルエンコーディングはUTF-8です。
* フィールドセパレーターはカンマです。
* フィールドデリミタはオプションであり、引用符`"`のみが許可されるデリミタタイプです。
* ルールまたは行の総数は40,000未満です。
* 一意のサイトの最大数は5,000です。
* 表の最後の行には`Field1=name` と `Pattern1=*` のキャッチオールルールが入力されています。

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

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

***

## デバイスの組織の構成

{% hint style="warning" %}
クラシックな階層を使用している組織は、**デバイスの組織**カスタムルールセットに移行する必要があります。

移行手順については、Nexthink Communityユーザー向けに提供されている[ルールベース組織におけるエンティティと階層の移行](https://edocs.nexthink.com/ja/infinity-transition/detailed-transition-advice/entities-and-hierarchies-to-rule-based-organization)のドキュメントを参照してください。
{% endhint %}

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

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

管理 > 製品構成 > デバイスとユーザーの分類タブから、**デバイスの組織**の下で:

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

{% hint style="info" %}
デバイスの組織ルールで **CIDR** 表記のIPアドレスフィールドを使用する場合、IPの値はサブネットのネットワークアドレスを表す必要があります。

最初にルールセットをアップロードするとき、CSVファイルのサイズに応じて、データの集計には**20から60分**の遅延が発生します。
{% endhint %}

<details>

<summary>IPベースの規則に用いるクラスレスインタードメインルーティング（<strong>CIDR</strong>）形式の要件</summary>

サブネット内のホストIPアドレスを使用して定義されたCIDR範囲は、デバイス組織ルールには対応していません。 IP部分はCIDRプレフィックスと一致し、すべてのホストビットは**ゼロ**に設定される必要があります。

たとえば：

* **有効な例:** `10.136.16.0/21`
* **無効な例:** `10.136.16.1/21`

CIDR範囲がネットワークアドレスから始まらない場合、CSVファイルはアップロード時に受け付けられますが、デバイスはエンティティに一致しません。

</details>

<figure><img src="https://3549141153-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FeLm8O7QKZDn6z806e7Sv%2Fuploads%2Fgit-blob-15e33cf3914d0cd21a6dc237b162099af532cc9c%2Fimage%20(910).png?alt=media" alt=""><figcaption></figcaption></figure>

### デバイス組織ルールセットのCSVファイルの例 <a href="#productconfiguration-exampleofacsvfile.1" id="productconfiguration-exampleofacsvfile.1"></a>

カンマ区切りの割り当てテキストファイルの例:

```
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
```

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

<table data-full-width="true"><thead><tr><th width="246">Field1</th><th width="135">Pattern1</th><th width="129">Field2</th><th width="106">Pattern2</th><th width="198">エンティティ</th><th>Region</th></tr></thead><tbody><tr><td></td><td></td><td></td><td></td><td></td><td>Global Region</td></tr><tr><td>名前</td><td>device-d*</td><td></td><td></td><td>FRANCE</td><td>EUROPE</td></tr><tr><td>名前</td><td>device-1*</td><td></td><td></td><td>CANADA</td><td>AMERICAS</td></tr><tr><td>collector_string_tag</td><td>CH*</td><td></td><td></td><td>SWITZERLAND</td><td>EUROPE</td></tr><tr><td>collector_string_tag</td><td>US*</td><td></td><td></td><td>UNITED STATES</td><td>AMERICAS</td></tr><tr><td>名前</td><td>*</td><td></td><td></td><td>Unassigned</td><td>Unassigned</td></tr></tbody></table>

表の各行には、2つのパターン、エンティティ名、およびオプションで追加のカスタム分類が含まれています。 規則を満たすには、パターンが対応するフィールドと一致する必要があります。 システムは、表の上から下への優先順位で規則を評価します。 これは、表の上でデバイス割り当てをより具体的にし、下ではより一般的にすることを要求します。

例えば、`name` が `device-d100` で、`collector_string_tag` が `CH10` のデバイスを持っているとします。 このデバイスは、最初の規則と三番目の規則の両方に一致します。 システムが `device-d100` の規則を最初に評価するため、デバイスはエンティティ `FRANCE` とグローバル地域 `EUROPE` に割り当てられます。

最初の5列は必須です：

* **Field1:** 割り当てに使用する最初のフィールドのデータ（このページの[Field1およびField2のサポートされる値](#supported-values-for-field1-and-field2-1)を参照してください。）
* **Pattern1:** 最初のフィールドのパターン
* **Field2:** 割り当てに使用する第二のフィールドのデータ（このページの[Field1およびField2のサポートされる値](#supported-values-for-field1-and-field2-1)を参照してください。）
* **Pattern2:** 第二のフィールドのパターン
* **Entity**: ターゲットエンティティの名前

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

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

<figure><img src="https://3549141153-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FeLm8O7QKZDn6z806e7Sv%2Fuploads%2Fgit-blob-2c37b838d09276d49544a0396acfe1bc44efb7a9%2Flocation-investigation.png?alt=media" alt="Difference between an NQL ID and a display name"><figcaption></figcaption></figure>

1. **#region** はNQL IDです。
2. **Global Region** は分類のNQL IDの表示名です。

#### **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によって報告される識別名の形式は、`属性=値` の要素がカンマで接続され、最も具体的な属性から最も一般的な属性への順である。 例: `CN=ex01,OU=Computers,DC=example,DC=org`
* **ad\_site:** デバイスが位置するActive Directoryサイト。 **name**、**collector\_string\_tag**、**dn**、および **ad\_site** のフィールドは、文字パターンマッチングをサポートします。 関連する文字列パターンを定義するには、以下のワイルドカードを使用します:
  * `?` キャラクターは1文字を代用します。
  * `*` キャラクターは0文字以上を代用します。
* **ip:** デバイスの最後のパブリックIPアドレス（[nql-data-model](https://docs.nexthink.com/platform/ja/understanding-key-data-platform-concepts/nql-data-model "mention") の `public_ip.ip_address` を参照）。 フィールドのパターンとして以下のいずれかを指定します:
  * ドット10進表記の単一IPアドレス、例: `192.168.10.1`
  * CIDR表記のサブネット、例: `192.168.10.0/24`
* **primary\_local\_ip:** プライマリ物理ネットワークアダプタのデバイスの最後のローカルIP（[nql-data-model](https://docs.nexthink.com/platform/ja/understanding-key-data-platform-concepts/nql-data-model "mention") の `connectivity.last_local_ip` を参照してください）。 パターンを **ip** フィールドと同様に指定します。
* **collector\_local\_ip:** エンドポイントとNexthinkインスタンス間のトラフィックに使用されるローカルIP（[nql-data-model](https://docs.nexthink.com/platform/ja/understanding-key-data-platform-concepts/nql-data-model "mention") の `collector.local_ip` を参照してください）。 パターンを **ip** フィールドと同様に指定します。
* **wifi\_ssid:** プライマリネットワークアダプタに関連付けられたWiFiネットワーク名（SSID）。 この値はパターンマッチングをサポートします。

{% hint style="info" %}
公開IPアドレスに基づいてルールを構築する前に、測位情報を有効にしてください。

`wifi_ssid` タグを使用するには、次の [Collectorパラメータ](https://docs.nexthink.com/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#collectormsiparametersreferencetable-optionalparameters) を無効にしてください： `ANONYMIZE_WIFI_NETWORK`
{% endhint %}

#### デバイス組織 ルールセットに関するCSVファイルの考慮事項 <a href="#productconfiguration-considerations.1" id="productconfiguration-considerations.1"></a>

CSV設定ファイルが次の要件を満たしていることを確認してください：

* ファイルサイズは5MB未満です。
* ファイルのエンコーディングはUTF-8です。
* フィールドのセパレータはカンマ（,）です。
* フィールドデリミタはオプションで、引用符 (`"`) のみが許可されるデリミタタイプです。
* エンティティ値や分類値に空の文字列や `-` は含まれていません。
* エンティティ値および分類値の最大長は50文字です。
* ルールまたは行の総数は40,000以下です。
* ファイル全体での異なるエンティティの総数は2,000以下です。
* カスタム分類列の総数は6を超えていない必要があります。
* テーブルの最後の行には `Field1=name` と `Pattern1=*` を使用した全体を包括するルールが入力されています。
* 同じエンティティが複数のカスタム分類に属することはできません。 エンティティの値が複数の行に表示される場合、その分類はすべての行で同一でなければなりません。

\*\*例: \*\* エンティティFRANCEが異なる行でEUROPEとAMERICASの両方に誤って割り当てられているため、以下の割り当てルールはシステムによって拒否されます。

| Field1 | Pattern1   | Field2 | Pattern2 | エンティティ | Region                                              |
| ------ | ---------- | ------ | -------- | ------ | --------------------------------------------------- |
|        |            |        |          |        | Global Region                                       |
| 名前     | device-d\* |        |          | FRANCE | <mark style="background-color:red;">EUROPE</mark>   |
| 名前     | device-e\* |        |          | FRANCE | <mark style="background-color:red;">AMERICAS</mark> |

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

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

### **カスタム分類の更新**

組織構造を最適に反映した改訂版のCSVファイルをアップロードすることにより、カスタム分類を更新します。 次の操作を行うことができます：

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

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

{% hint style="warning" %}
カスタム分類の更新は、組織データに依存する既存のNQLクエリの結果に影響を与える可能性があります。 カスタム分類の変更後、これらのNQLクエリをレビューおよび更新することを確認してください。

[ドメインの表示](https://github.com/nexthink/documentation.online-product-documentation/blob/develop/ja_docs/user-guide/administration/account-management/roles/view-domain.md)権限は、カスタム分類を含む組織データに依存します。 割り当てルールの変更により、限定されたドメイン表示権限を持つユーザーに利用可能なデータの範囲が影響を受ける場合があります。

カスタム分類の変更後、限定されたドメインアクセス権を持つプロファイルを必ず見直してください。
{% endhint %}

***

## ユーザー組織の構成

**ユーザー組織** は、会社の階層またはホラクラシーとして定義された組織の従業員グループにユーザーをマッピングし、人事管理ツールからの値に一致させます。

ユーザー組織フィールドを定義するには、**管理** > **製品構成** > **デバイスとユーザーの分類** タブの **ユーザー組織** から：

{% stepper %}
{% step %}
**ユーザー組織フィールドを作成**

HR階層またはグループに相当する最大6つまでのユーザー組織フィールドを追加できます：

* 新しいユーザー組織フィールドを追加し、その説明を含めます。例： **事業部門**。
  * システムは、作成されたフィールドに対して自動的に **NQL ID** を生成します： `business_unit`。
* 作成されたユーザー組織フィールドアイテムをドラッグアンドドロップして会社の階層に従って並べ替えます。

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

{% hint style="warning" %}
新しいフィールドがデータモデルに追加されるため、\[#ユーザー組織フィールドを充実させる]\(product-configuration.md#enrich-the-user-organization-fields "mention")必要がありますが、その値は存在しません。

Nexthinkのインバウンドコネクタをデータの充実化のために使用する場合、コネクタを可能な限り早く実行するようにスケジュールします。 これにより、コネクタの設定された繰り返しによる遅延が最小化されます。
{% endhint %}

<figure><img src="https://3549141153-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FeLm8O7QKZDn6z806e7Sv%2Fuploads%2Fgit-blob-d95e5d344491e5bfe3990bae0f84118c4fa9248e%2Fimage%20(995).png?alt=media" alt=""><figcaption></figcaption></figure>
{% endstep %}

{% step %}
**ユーザー組織フィールドを充実させる**

ユーザー組織フィールドをデータで充実させるためには、以下のオプションを使用してください：

* [インバウンドコネクタ](https://docs.nexthink.com/platform/ja/configuring_nexthink/bringing-data-into-your-nexthink-instance/integrating-nexthink-with-third-party-tools/inbound-connectors)を使用したフィールドマッピング—以下の画像を参照して、WorkdayやSalesforceなどの従業員管理アプリケーションにアクセスし、従業員属性をユーザー組織フィールドにマッピングします。
  * 遅延を最小にするために、インバウンドコネクタの実行を可能な限り早い時間に設定し、データの充実がコネクタの設定された繰り返しに依存するようにします。
* Nexthink [Enrichment API](https://docs.nexthink.com/api/enrichment)を使用して、外部ソースからの属性でユーザー組織フィールドの値を更新します。
* [カスタムフィールド管理](https://docs.nexthink.com/platform/ja/user-guide/administration/content-management/custom-fields-management#customfieldsmanagement-updatingcustomfieldsbyimportingacsvfileimportcsv)を使用して、ユーザー情報を含むCSVファイルをアップロードしてユーザー組織フィールドを更新します。
* 調査ページから[カスタムフィールドの編集](https://docs.nexthink.com/platform/ja/user-guide/administration/content-management/custom-fields-management#customfieldsmanagement-editingcustomfieldsontheinvestigationspageeditcf)を行い、手動でユーザー情報を使用してユーザー組織フィールドを更新します。

以下の例では、Entra ID用のインバウンドコネクタを使用して、ユーザー組織フィールド—**事業部門**—を選択された **Entra IDフィールド** にマッピングします。

フィールドマッピング手順の詳細については、[Microsoft Entra ID (Azure AD) コネクタ](https://docs.nexthink.com/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#connectorformicrosoftentraid-azuread-fieldmapping)を参照してください。

<figure><img src="https://3549141153-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FeLm8O7QKZDn6z806e7Sv%2Fuploads%2Fgit-blob-7c7c09aff40488e1e8114b359ca2fed5a2ec8f3a%2Fimage%20(882).png?alt=media" alt=""><figcaption></figcaption></figure>
{% endstep %}

{% step %}
**ユーザー組織フィールドの検証**

ユーザー組織のカスタムフィールドを、人事階層と一致するユーザーのグループを集計するNQLクエリを使用して検証します。ここでは、`business_unit`: EMEA Financeを例にしています。

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

{% endstep %}
{% endstepper %}

***

## NQLフィールドと例 <a href="#productconfiguration-nqlexamples" id="productconfiguration-nqlexamples"></a>

データモデルには、2つのレベルで場所と所有権のフィールドが利用可能です:

* **デバイスまたはユーザーのプロパティ**: フィールドは、現在のユーザーまたはデバイスの組織ユニットとデバイスの場所を返します。
* **イベントコンテキスト**: コンテキストフィールドは、イベント時の組織ユニットと場所を返します。

以下の表は、対応するフィールドの概要を示しています。

<table data-full-width="true"><thead><tr><th width="276"></th><th>オブジェクトプロパティ</th><th>イベントコンテキスト</th></tr></thead><tbody><tr><td><strong>パブリックIPのジオロケーション</strong></td><td><ul><li><code>-device.public_ip.country</code></li><li><code>device.public_ip.state</code></li><li><code>device.public_ip.city</code></li></ul></td><td>–</td></tr><tr><td><strong>ルールベースのデバイスロケーション</strong><br><br>* 表の下の説明を参照</td><td><ul><li><code>device.location.type</code></li><li><code>device.location.site</code></li><li><code>device.location.state</code></li><li><code>device.location.country</code></li></ul></td><td><ul><li><code>context.location.type</code></li><li><code>context.location.site</code></li><li><code>context.location.state</code></li><li><code>context.location.country</code></li></ul></td></tr><tr><td><strong>ルールベースのデバイス組織</strong></td><td><ul><li><code>device.organization.entity</code></li><li><code>device.organization.#customClassification</code></li></ul></td><td><ul><li><code>context.organization.entity</code></li><li><code>context.organization.#customClassification</code></li></ul></td></tr><tr><td><strong>ユーザー組織</strong></td><td><ul><li><code>user.organization.#customClassification</code></li></ul></td><td>–</td></tr></tbody></table>

**説明:**

各デバイスについて、システムはCSVファイル内のルールを探します。 デバイスがルールに一致する場合、システムは以下のいずれかの方法でロケーションデータを取得します:

* ルールが `Location Type` と `Site`, `State,` または `Country` フィールドの1つ以上にデータを持つ場合、そのフィールドからロケーションデータを取得します。 これらのいずれかのフィールドにデータが含まれている場合、システムはルールベースのロケーションデータを使用し、空のフィールドはクエリで空の値として表示されます。
* ルールが `Location Type` フィールドのみにデータがあり、`Site`, `State,` および `Country` フィールドが空の場合、システムはジオロケーションを使用してロケーションデータを取得します。

詳しくは以下の表を参照してください:

<table data-header-hidden data-full-width="false"><thead><tr><th width="266"></th><th></th><th></th></tr></thead><tbody><tr><td></td><td><code>Location Type</code>データ<br><br><code>Site</code>, <code>State</code>, <code>Country</code>またはすべてにデータ</td><td><code>Location Type</code>データ<br><br><strong>なし</strong>のデータ <code>Site</code>, <code>State,</code> <code>Country</code>にデータ</td></tr><tr><td>ルールベースの位置情報</td><td>✓</td><td></td></tr><tr><td>位置情報</td><td></td><td>✓</td></tr></tbody></table>

### 使用例: 製品構成フィールドのクエリ <a href="#productconfiguration-investigateexecutioncrashes" id="productconfiguration-investigateexecutioncrashes"></a>

次のNQL例では、製品構成機能を使用しています。

#### Salesforceユーザーの地理的分布 <a href="#productconfiguration-geographicaldistributionofsalesforceusers" id="productconfiguration-geographicaldistributionofsalesforceusers"></a>

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
```

#### デバイスのイベント時におけるロケーションを用いた実行クラッシュの調査 <a href="#productconfiguration-investigateexecutioncrashes" id="productconfiguration-investigateexecutioncrashes"></a>

過去7日間のすべてのデバイスでの実行クラッシュ数を調査し、地理的な傾向を見つけます。 実行クラッシュ時のデバイスの位置を確認するために`context.location`を使用します。 このクエリは、`context.location`フィールドからデータを取得し、イベント時のデバイスの位置を保存します。

<pre><code><strong>過去7日の実行クラッシュ
</strong>| summarize total_crashes=number_of_crashes.sum() by context.location.country, context.location.state, context.location.site
</code></pre>

#### イベントコンテキストと現在のデバイスロケーションを使用してWiFiネットワーク品質を調査する

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

```
接続.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
```

2. これで、特定のサイトが悪い接続に悩まされているかどうかがわかります。 その場所でWiFiの品質をアダプターの種類に分けて確認し、潜在的な根本原因を探します。 これを行うために、次のクエリは`device.location`を使用します:

```
接続.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
```

#### 組織エンティティによるデバイスのフィルタリング <a href="#productconfiguration-filterdevicesbyorganizationalentity" id="productconfiguration-filterdevicesbyorganizationalentity"></a>

`エンティティ`によってデバイスをフィルタリングし、組織の特定の部分内で対象とします:

```
デバイス
| where organization.entity == "SWITZERLAND"
```

#### 組織単位によるユーザーのフィルタリング <a href="#productconfiguration-filterdevicesbyorganizationalentity" id="productconfiguration-filterdevicesbyorganizationalentity"></a>

`#`チームによってユーザーをフィルタリングし、組織の特定の部分内で対象とします:

```
ユーザー
| where organization.#team == "Product"
```

#### カスタムの地域とロケーションタイプによるDEXスコアの比較 <a href="#productconfiguration-comparedexscoresbycustomregionandlocationtype" id="productconfiguration-comparedexscoresbycustomregionandlocationtype"></a>

DEXスコアを`#region`と`location.type`で分解し、組織全体でデジタルエクスペリエンスの一貫性を確保します。

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