# 製品構成 製品構成ページから、次の操作を実行できます: | | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | | *** ## 機能 **構成**サブタブで、Nexthink テナント内の特定の機能の有効化ステータスを変更します。 * **AI ツール:** AI ツールの使用を有効化し、次のことを可能にします: * 未承認またはシャドー ツールを含む、組織内での AI 使用状況を明らかにします。 * チャンピオンや摩擦のある領域を明確にしながら、採用パターンを追跡します。 * 競争力を維持するために、同業他社と AI 採用状況を比較します。 * 節約されたと認識される時間や従業員からのフィードバックを通じて、影響を定量化します。 * 推奨事項に基づいて AI 採用インサイトを活用し、効果的な施策をスケールします。 * 詳細については、[AI ツールの操作](/platform/ja/user-guide/ai-tools/working-with-ai-tools.md)を参照してください。 * **Web 検索:** Workspace が精選された外部ソースから情報を取得できるようにし、最新のベンダー ガイダンス、既知の問題、業界のベスト プラクティスを必要とする質問への回答を支援します。 * 詳細については、[ワークスペースの使用](/platform/ja/user-guide/search-and-workspace/using-workspace.md#web-search) を参照してください。 *** ## デバイスとユーザーの分類 **製品構成**内の **デバイスとユーザーの分類** タブでは、Nexthink テナント内でシステムがデバイスおよびユーザーをどのように分類するかを決定できます。 Nexthinkの製品と機能を通じてデバイスとユーザーの分類を使用します: * データを照会し調査を実行するために、NQLデータモデルの表— `device.organization, device.location, user.organization` を活用します。 * 組み込みダッシュボードや特定のカスタム可視化をソートするためのフィルタと分解基準を定義します。 カスタムフィルターのユースケース例については、[Configuring AI tools](/platform/ja/user-guide/ai-tools/setting-up-and-managing-ai-tools/configuring-ai-tools.md#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 %}
*** ## デバイスの位置の構成 **デバイスの場所**により、イベント時にデバイスがどこにあるかを把握することが可能になり、リモートの問題のトラブルシューティングを支援し、一貫したデジタル体験（DEX）を確保します。 イベントは、地理的な場所と場所タイプによりオンサイトまたはリモートで追跡されます。 Nexthinkは、ルールベースのロジック—精度が必要な場合に推奨されています—または公開IPに基づくGeoIPを使用し、ルールベースの場所を割り当てられない場合のバックアップとして使用します。 デバイスの場所は頻繁に変わると予想されます。 管理 > 製品構成 > デバイスとユーザーの分類タブから、**デバイスの場所**の下で: 1. **ジオロケーションの詳細**を設定します。 2. **ルールベースの場所**を定義します。 ### ジオロケーションの詳細設定 Nexthinkはインターネット上のデバイスの場所を、GeoIPデータベースとCollectorを実行しているシステムの公開IPアドレスを参照して決定することができます。 ジオロケーション機能はデフォルトで無効になっており（"位置データを一切記録しない"）、ドロップダウンメニューから利用可能なオプションの1つに詳細度を設定することで有効にできます。 * 位置データを一切取得しない * 公開IPのみ * 公開IPと国 * 公開IP、国、州 * 公開IP、国、州、都市
{% hint style="info" %} ジオロケーション機能を有効にすると、選択した詳細度に関係なく、Nexthinkプラットフォームはインターネットサービスプロバイダー（ISP）の名前を記録します。 {% endhint %} 仮想プライベートネットワーク（VPN）を使用すると、Collectorが報告する公開IPアドレスに影響します。 ジオロケーションの精度を向上させるためには、CollectorとNexthinkインスタンス間のトラフィックをVPN経由でルーティングしない方が最適です。 この機能はCollectorの任意のバージョンで動作し、情報がNexthinkプラットフォーム外に伝送されることはありません。 Nexthinkにはジオロケーションデータベースの独自のインスタンスがあり、内部でジオロケーション検索を実行します。 ### **ルールベースの場所の定義** Nexthinkプラットフォームは、デバイスの場所を決定するためのルールベースの割り当てプロセスを提供します。 この機能は非常に設定可能で、ルールを変更することで調整できます。 CSVファイルをタブ形式で使用して、割り当てを設定します。 テーブルの各行には2つのパターンと場所の割り当てが含まれます。 {% hint style="warning" %} ルールベースの位置ルールでCIDR表記を使用する場合、デバイス組織ルールと同じCIDR形式の要件が適用されます。 , CIDR形式の要件については[こちら](#classless-inter-domain-routing-cidr-format-requirements-for-ip-based-rules)を参照してください。 {% endhint %}
### **ルールベースの場所の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 %} 上記のテキストファイルからの割り当てルールを示す表:
Field1Pattern1Field2Pattern2Location TypeSite地域国
primary_local_ip10.0.0.0/8名前NXT*OnsiteLausanneVDCH
primary_local_ip172.16.0.0/16OnsiteBostonMAUS
名前*リモート
* 最初のルールは、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]に利用して設定します( この値はパターンマッチングをサポートします。 * **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フィールド](/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がサブネットのネットワークアドレスを表していることを確認してください。 CIDR形式の要件については[こちらに準拠してください](#classless-inter-domain-routing-cidr-format-requirements-for-ip-based-rules)。 {% endhint %} * **プライマリ\_ローカル\_ip:** プライマリ物理ネットワークアダプタのデバイスの最後のローカルIP。 このフィールドは `connectivity.last_local_ip` [NQLフィールド](/platform/ja/understanding-key-data-platform-concepts/nql-data-model.md)にマッピングされます。 **ip** フィールドで指定する方法と同じように、パターンを指定します。 * **コレクター\_ローカル\_ip**: エンドポイントとNexthinkインスタンス間のトラフィックに使用されるローカルIP。 このフィールドは `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` タグを使用するには、次の [コレクターパラメータ](/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" %} 保存時にプログラムが余分な文字を自動的に追加しないようにするために、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 %}
IPベースの規則に用いるクラスレスインタードメインルーティング（CIDR）形式の要件 サブネット内のホストIPアドレスを使用して定義されたCIDR範囲は、デバイス組織ルールには対応していません。 IP部分はCIDRプレフィックスと一致し、すべてのホストビットは**ゼロ**に設定される必要があります。 たとえば： * **有効な例:** `10.136.16.0/21` * **無効な例:** `10.136.16.1/21` CIDR範囲がネットワークアドレスから始まらない場合、CSVファイルはアップロード時に受け付けられますが、デバイスはエンティティに一致しません。
### デバイス組織ルールセットのCSVファイルの例 カンマ区切りの割り当てテキストファイルの例: ``` 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 ``` 上記のテキストファイルからの割り当てルールを示す表:
Field1Pattern1Field2Pattern2エンティティRegion
Global Region
名前device-d*FRANCEEUROPE
名前device-1*CANADAAMERICAS
collector_string_tagCH*SWITZERLANDEUROPE
collector_string_tagUS*UNITED STATESAMERICAS
名前*Unassigned未割り当て
表の各行には、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を作成します。 それらの値にはスペースや特殊文字を含めることはできません。 第二行の値は表示名に対応しています。
Difference between an NQL ID and a display name
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データモデル](/platform/ja/understanding-key-data-platform-concepts/nql-data-model.md) の `public_ip.ip_address` を参照）。 フィールドのパターンとして以下のいずれかを指定します: * ドット10進表記の単一IPアドレス、例: `192.168.10.1` * CIDR表記のサブネット、例: `192.168.10.0/24` * **primary\_local\_ip:** プライマリ物理ネットワークアダプタのデバイスの最後のローカルIP（[NQLデータモデル](/platform/ja/understanding-key-data-platform-concepts/nql-data-model.md) の `connectivity.last_local_ip` を参照してください）。 パターンを **ip** フィールドと同様に指定します。 * **collector\_local\_ip:** エンドポイントとNexthinkインスタンス間のトラフィックに使用されるローカルIP（[NQLデータモデル](/platform/ja/understanding-key-data-platform-concepts/nql-data-model.md) の `collector.local_ip` を参照してください）。 パターンを **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です。 * フィールドのセパレータはカンマ（,）です。 * フィールドデリミタはオプションで、引用符 (`"`) のみが許可されるデリミタタイプです。 * エンティティ値や分類値に空の文字列や `-` は含まれていません。 * エンティティ値および分類値の最大長は50文字です。 * ルールまたは行の総数は40,000以下です。 * ファイル全体での異なるエンティティの総数は2,000以下です。 * カスタム分類列の総数は6を超えていない必要があります。 * テーブルの最後の行には `Field1=name` と `Pattern1=*` を使用した全体を包括するルールが入力されています。 * 同じエンティティが複数のカスタム分類に属することはできません。 エンティティの値が複数の行に表示される場合、その分類はすべての行で同一でなければなりません。 \*\*例: \*\* エンティティFRANCEが異なる行でEUROPEとAMERICASの両方に誤って割り当てられているため、以下の割り当てルールはシステムによって拒否されます。 | Field1 | Pattern1 | Field2 | Pattern2 | エンティティ | Region | | ------ | ---------- | ------ | -------- | ------ | --------------------------------------------------- | | | | | | | Global Region | | 名前 | device-d\* | | | FRANCE | EUROPE | | 名前 | device-e\* | | | FRANCE | AMERICAS | これらのチェックのいずれかに失敗した場合、ファイルの選択は以前にアップロードしたファイルに戻ります。 エラーを修正することでアップロードのブロックを解除できます。 {% 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 %} *** ## ユーザー組織の構成 **ユーザー組織** は、会社の階層またはホラクラシーとして定義された組織の従業員グループにユーザーをマッピングし、人事管理ツールからの値に一致させます。 **ユーザー組織フィールド** は、ダッシュボードや調査におけるデータ整理に役立ち、構成およびエンリッチ後は、従業員グループ間のAIツール使用状況を監視するためのカスタムフィルターとして機能します。 {% stepper %} {% step %} #### **ユーザー組織フィールドを作成する** **Administration** > **Product configuration** > **Device and user classification** タブの **User organization** セクションで: HR階層またはグループに相当する最大6つまでのユーザー組織フィールドを追加できます： * 新しいユーザー組織フィールドを追加し、その説明を含めます。例： **事業部門**。 * システムは作成されたフィールドに対して **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 %} {% endstep %} {% step %} #### **ユーザー組織フィールドを充実させる** ユーザー組織フィールドをデータで充実させるためには、以下のオプションを使用してください： <0>インバウンド コネクタ—<1>以下の例をご覧ください\\ インバウンドコネクタを使用すると、Microsoft Entra ID、Workday、Salesforce などの従業員管理アプリケーションからデータを取得し、従業員属性を作成済みのユーザー組織フィールドにマッピングできます。 インバウンドコネクタを使用してユーザー組織フィールドを拡充する方法を確認するには、次を参照してください: * このページの [#example-enriching-user-organization-fields-using-the-entra-id-inbound-connector](#example-enriching-user-organization-fields-using-the-entra-id-inbound-connector "mention") を参照してください。 * インバウンドコネクターのセットアップ手順を段階的に確認するには、[How to set up and manage inbound connectors](https://learn.nexthink.com/courses/how-to-set-up-and-manage-import-connectors) トレーニングを完了してください。 {% hint style="warning" %} 遅延を最小限に抑えるため、インバウンドコネクターのスケジュールされた繰り返しに依存してデータが強化されることから、インバウンドコネクターが可能な限り早いタイミングで実行されるように設定してください。 {% endhint %}
Nexthink エンリッチメント API 外部ソースの属性を使用してユーザー組織フィールドの値を更新するには、Nexthink [Enrichment API](https://docs.nexthink.com/api/enrichment) を使用します。
<0>ユーザー情報を含む CSV ファイルによるカスタムフィールド\ **管理** > **カスタムフィールド** から、ユーザー情報を含む 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. フィールドマッピングのポップアップを開くために、**カスタムフィールドマッピングを追加** します。 2. **Nexthink カスタムフィールド** の下で、作成したユーザー組織フィールドを選択し、対応する **Entra ID フィールド** にマッピングします。 * ユーザー組織フィールドは、デフォルトで **Nexthink カスタムフィールド** ドロップダウン内の **Organization →** `[your user organization field name]` に一覧表示されます。 この例では、**Organization → Business unit** です。 * NQL クエリでは、ユーザー組織フィールドは `user.organization.#[your user organization NQL ID]` として表示されます。この例では `user.organization.#business_unit` です。 {% hint style="info" %} 詳細については、[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-fieldmapping) を参照してください。 {% endhint %}
{% hint style="warning" %} データマッピングが成功していることを確認するために、強化されたユーザー組織フィールドを検証する必要があります。 以下の手順を参照してください。 {% endhint %} {% endstep %} {% step %} #### **ユーザー組織フィールドを検証する** Investigations で NQL クエリを実行し、特定の人事階層に一致するユーザーグループを集計することで、ユーザー組織カスタムフィールドを検証します。この例では `business_unit`: EMEA Finance です。 ``` users | where user.organization.#business_unit == "EMEA Finance" ``` {% endstep %} {% endstepper %} *** ## 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
ユーザー組織
  • 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 ユーザーの地理的分布を確認します: ``` 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` フィールドからデータを取得します。 
execution.crashes during past 7d
| summarize total_crashes=number_of_crashes.sum() by context.location.country, context.location.state, context.location.site
#### イベントコンテキストと現在のデバイス位置情報を使用して WiFi ネットワーク品質を調査する 1. `context.location` を使用した次のクエリにより、過去に接続不良イベントが発生したサイトを確認できます。 以下のクエリは、イベント発生時のデバイス位置情報を保存する `context.location` フィールドからデータを取得します。 ``` connectivity.events during past 3d | 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` を使用します: ``` connectivity.events during past 1h | 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" ``` #### 組織ユニットでユーザーをフィルタリングする 組織内の特定の領域を対象とするために、`#team` でユーザーをフィルタリングします: ``` users | where organization.#team== "Product" ``` #### カスタム地域およびロケーションタイプ別に DEX スコアを比較する 組織全体でデジタルエクスペリエンスの一貫性を確保するため、DEX スコアを `#region` と `location.type` で分類します。 ``` dex.scores during past 7d | summarize c1 = value.avg() by context.organization.#Region, context.location.type ``` --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.nexthink.com/platform/ja/user-guide/administration/system-configuration/product-configuration.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.