サポート (英語のみ)

製品構成

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

Nexthink の製品と機能全体でデバイスとユーザーの分類を使用して、次のことができます:

  • NQLデータモデルのテーブル—device.organization, device.location, user.organization—を活用して、データのクエリや調査を実行します。

  • 組み込みのダッシュボードや特定のカスタムビジュアライゼーションをソートするためのフィルターとブレークダウンクライテリアを定義します。 AIツールの設定ドキュメントを参照して、カスタムフィルターのユースケース例を確認してください。

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

  • デバイスの場所は、ルールベースのロジックおよび/または公開IPに基づくGeoIPを使用し、システムはGeoIPをフォールバックとして使用します。 デバイスの位置情報によって、イベントの発生時にデバイスがどこにあるかを把握し、効果的な問題解決と一貫したサポートを可能にします。 デバイスの場所は頻繁に変わると想定されています。

  • デバイスの組織は、カスタムルールセットを使用してデバイスを組織のエンティティにマッピングします。これにより、組織構造や支店（たとえば、米国支店、スイスオフィスなど）に応じたアクセス、コンプライアンス、ハードウェアライフサイクルの管理が可能になります。 デバイスの場所とは異なり、デバイスの組織は時間が経つにつれ比較的安定しています。

  • ユーザー組織は、トップレベルから最下層まで最大6つのレベルを使用して組織階層を定義し、HR管理ツールからのデータと一致するように従業員にマッピングします。

管理 > 製品設定 > デバイスとユーザー分類にアクセスするには、管理者権限が必要です。

デバイスの位置情報の設定

デバイスの位置情報は、イベント発生時にデバイスがどこにあるかを把握することができ、リモートの問題を効果的にトラブルシューティングし、一貫したデジタル エクスペリエンス (DEX) を確保するために役立ちます。 イベントは地理的位置と場所のタイプ（オンサイトまたはリモート）によって追跡されます。

Nexthinkは、場所を特定するためにルールベースのロジックを使用し、精度の高さが優先されます。ルールベースの場所が割り当てられない場合、公益IPに基づくGeoIPが代替手段として使用されます。 デバイスの位置情報は頻繁に変更されることが予想されます。

管理 > 製品設定 > デバイスとユーザー分類タブのデバイスの位置情報で：

  1. 地理位置詳細度の設定

  2. ルールベースの位置情報の定義

位置情報の設定細分化

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

ジオロケーション機能はデフォルトで無効になっています（"どの位置データも捕捉しない"）が、ドロップダウンメニューで使用可能なオプションのいずれかに場所の粒度を設定することで有効にできます。

  • 位置データを一切取得しない

  • 公開IPのみ

  • 公開IPと国

  • 公開IP、国、州

  • 公開IP、国、州、都市

ジオロケーション機能を有効にすると、選択した粒度レベルとは無関係にNexthinkプラットフォームがインターネットサービスプロバイダ(ISP)の名前を記録します。

仮想プライベートネットワーク(VPN)を使用するとCollectorが報告する公開IPアドレスに影響します。 ジオロケーションの精度を向上させるには、CollectorとNexthinkインスタンス間のトラフィックをVPNを経由させないほうがよいです。 この機能はどのバージョンのCollectorとも連携し、どの情報もNexthinkプラットフォーム外には送信されません。 Nexthinkは自身のジオロケーションデータベースのインスタンスを持ち、内部的にジオロケーション検索を行います。

ルールベースの位置情報の定義

Nexthinkプラットフォームには、デバイスの所在地を決定するためのルールベースの割り当てプロセスが備わっています。 この機能は非常に設定可能で、ルールを修正して調整できます。

CSVファイルを使用して割り当てを構成し、表形式にします。 テーブルの各行には、2つのパターンとロケーションの割り当てが含まれています。

ルールベースの位置情報の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

詳細については、このページのField1とField2のサポートされる値を参照してください。

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

Field1
Pattern1
Field2
Pattern2
Location Type
Site
地域
国

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

  • 最初のルールは、名前が NXT で始まるローカルサブネット 10.0.0.0/8 に属するすべてのデバイスを Onsite としてタグ付けし、場所サイトローザンヌを割り当てます。

  • 2番目のルールは、ローカルサブネット 172.16.0.0/16 に属するすべてのデバイスを Onsite としてタグ付けし、場所サイトボストンを割り当てます。

  • 3番目のルールは、他のすべてのデバイスを Remote としてタグ付けします。

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

  • フィールド1: 割り当てに使用する最初のフィールドのデータ（このページでフィールド1とフィールド2のサポートされている値を参照）。

  • Pattern1: 最初のフィールド用のパターン

  • フィールド2: 割り当てに使用する2番目のフィールドのデータ（このページでフィールド1とフィールド2のサポートされている値を参照）。

  • Pattern2: 2番目のフィールド用のパターン

  • ロケーションタイプ: 対象場所タイプの名前。 許可された場所タイプの値は次のとおりです。

    • Onsite

    • Remote

    • 不明

  • 場所: デバイスまたはデバイスのあるサイトのカスタム名。

  • 州: デバイスまたはデバイスが所在する場所の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のサポートされる値:

  • name: デバイスのホスト名。

  • collector_tag: Collectorにインストール時に割り当てられるタグ番号。 正確な番号のみ一致します。

  • collector_string_tag: Collectorのインストール時に割り当てられたラベル。 この値はパターンマッチングをサポートしています。

  • configuration_tag: デバイス群を識別するための設定可能なラベル。 このフィールドの値を Enrichment API を使用して設定します。 この値はパターンマッチングをサポートしています。

  • 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フィールドに対応しています。 フィールドのパターンとして、次のいずれかを指定してください：

    • ドット十進法での単一のIPアドレス、例えば: 192.168.10.1

    • 例えば、CIDR表記でのサブネット: 192.168.10.0/24

  • primary_local_ip: プライマリ物理ネットワークアダプタに対するデバイスの最後のローカルIPです。 このフィールドはdevicesテーブルのconnectivity.last_local_ip NQLフィールドに対応しています。 ipフィールドと同様の方法でパターンを指定してください。

  • collector_local_ip: エンドポイントとNexthinkインスタンスの間のトラフィックに使用されるローカルIPです。 このフィールドはdevicesテーブルのcollector.local_ip NQLフィールドに対応しています。 ipフィールドで指定したものと同じ方法でパターンを指定します。

  • wifi_ssid: 主なネットワークアダプターに関連付けられたWiFiネットワーク名(SSID)。 この値はパターンマッチをサポートします。

公衆IPアドレスに基づいたルールを作成する前に、ジオロケーションを有効にしてください。

wifi_ssid タグを使用するには、次の Collectorパラメータ を無効にしてください: ANONYMIZE_WIFI_NETWORK

ルールベースの位置情報のためのCSVファイルの考慮事項

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

  • ファイルサイズは5MB未満です。

  • ファイルのエンコーディングはUTF-8です。

  • フィールドセパレータはカンマです。

  • フィールドの区切り記号はオプションで、許可されている唯一の区切り記号タイプは引用符"です。

  • ルールまたは行の総数は40,000未満です。

  • 最大2,000の一意のサイト。

  • テーブルの最後の行にはField1=nameとPattern1=*のキャッチオールルールが入力されています。

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

保存する際にプログラムが自動的に不要な文字を追加しないように、Notepad++ や Sublime Text といったプレーンテキストエディターを使用してCSVファイルを編集してください。

デバイス組織の設定

古典的な階層を使用している組織は、デバイス組織のカスタムルールセットに移行する必要があります。

移行手順については、エンティティと階層からルールベース組織への移行のドキュメントを参照してください。

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

デバイスの位置情報とは異なり、デバイス組織は安定しています。 例えば、スイス所有のデバイスが複数の国で使用されることがあります。

管理 > 製品設定 > デバイスとユーザー分類タブのデバイス組織で：

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

ルールセットを初めてアップロードする際、CSVファイルのサイズに応じて、データが反映されるまで20〜60分の遅延があります。

デバイス組織ルールセット用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

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

Field1
Pattern1
Field2
Pattern2
エンティティ
地域

グローバル地域

名前

device-d*

フランス

ヨーロッパ

名前

device-1*

カナダ

アメリカ大陸

collector_string_tag

CH*

スイス

ヨーロッパ

collector_string_tag

US*

アメリカ合衆国

アメリカ大陸

名前

*

未割当

未割り当て

テーブル内の各行には、2つのパターン、エンティティの名前、およびオプションの追加のカスタム分類が含まれています。 ルールを満たすためには、対応するフィールドにパターンが一致している必要があります。 システムはテーブルの上から下に向かってルールの優先度を設定します。 これにより、テーブルの上部でデバイスの割り当てをより具体的にし、下部でより一般的にする必要があります。

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

最初の5列は必須です。

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

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

Difference between an NQL ID and a display name

  1. #region はNQL IDです。

  2. グローバル地域は分類の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=org

  • ad_site: デバイスが配置されているActive Directoryサイト。 name, collector_string_tag, dn, ad_site フィールドは文字パターンのマッチングをサポートしています。 関連する文字列パターンを定義するには、次のワイルドカードを使用してください。

    • ? 文字は単一の文字を置き換えます。

    • * 文字は0個以上の文字を置き換えます。

  • ip: デバイスの最後のパブリックIPアドレス（https://github.com/nexthink/documentation.online-product-documentation/blob/develop/ja_docs/user-guide/nexthink-query-language-nql/nql-data-model.mdの public_ip.ip_address を参照）。 フィールドのパターンとして、次のいずれかを指定してください。

    • ドット10進表記の単一のIPアドレス、例: 192.168.10.1

    • 例えば、CIDR表記でのサブネット: 192.168.10.0/24

  • primary_local_ip: プライマリ物理ネットワークアダプターのデバイスの最後のローカルIP（https://github.com/nexthink/documentation.online-product-documentation/blob/develop/ja_docs/user-guide/nexthink-query-language-nql/nql-data-model.mdの connectivity.last_local_ip を参照）。 ipフィールドと同様の方法でパターンを指定してください。

  • collector_local_ip: エンドポイントとNexthinkインスタンス間のトラフィックに使用されるローカルIP（https://github.com/nexthink/documentation.online-product-documentation/blob/develop/ja_docs/user-guide/nexthink-query-language-nql/nql-data-model.md の 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に割り当てられているため、システムは次の割り当てルールを拒否します。

Field1
Pattern1
Field2
Pattern2
エンティティ
地域

グローバル地域

名前

device-d*

フランス

ヨーロッパ

名前

device-e*

フランス

アメリカ大陸

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

保存する際にプログラムが自動的に不要な文字を追加しないように、Notepad++ や Sublime Text といったプレーンテキストエディターを使用してCSVファイルを編集してください。

カスタム分類の更新

組織構造を最適に反映する修正後のCSVファイルをアップロードすることで、カスタム分類を更新します。 次のことができます:

  • 既存のカスタム分類を削除するには、その列全体を削除してください。

  • 新しいカスタム分類を追加するには、新しい列を含めてください。

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

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

ドメインビュー権限は、組織データおよびカスタム分類に依存しています。 割り当てルールを変更すると、ドメインビュー権限が制限されているユーザーが利用できるデータの範囲に影響を与える可能性があります。

カスタム分類の変更後に表示ドメインへのアクセスが制限されたプロファイルを確認してください。

ユーザー組織の設定

ユーザー組織は、企業の階層またはホラクラシーに基づいて、HR管理ツールからの値と一致させてユーザーを組織の従業員グループにマッピングします。

ユーザー組織フィールドを定義するために、管理 > 製品設定 > デバイスとユーザー分類 タブのユーザー組織で：

1

ユーザー組織フィールドを作成する

HR階層またはグループを表す最大6つのユーザー組織フィールドを追加します。

  • 新しいユーザー組織フィールドを、その説明とともに追加します。例：業務部門。

    • システムは作成されたフィールドに対して自動的にNQL IDを生成します：business_unit。

  • 作成されたユーザー組織フィールド項目をドラッグ＆ドロップして、企業の階層に従って順序を設定します。

ユーザー組織フィールドは、グループごとのAIツール使用状況を監視する際のカスタムフィルターとして機能します。 詳細については、AIツールの設定ドキュメントを参照してください。

2

ユーザー組織フィールドを充実させる

作成されたユーザー組織フィールドはデータモデル内で利用可能ですが、値は含まれていません。

データでユーザー組織フィールドを充実させるには、次のオプションのいずれかを使用します。

  • インバウンドコネクタを使用したフィールドマッピング—下の画像を参照—で、WorkdayやSalesforceなどの従業員管理アプリケーションにアクセスし、従業員属性をユーザー組織フィールドにマッピングします。

  • Nexthink エンリッチメントAPIを使用して、外部ソースの属性でユーザー組織フィールドの値を更新します。

  • カスタムフィールド管理を使用して、ユーザー情報を含むCSVファイルをアップロードしてユーザー組織フィールドを更新します。

  • 調査からカスタムフィールドの編集によって、ユーザー情報を手動でアップデートします。

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

Microsoft Entra ID (Azure AD) のコネクタマッピング手順の詳細は、こちらを参照してください。

3

ユーザー組織フィールドの検証

調査からNQLクエリを実行し、特定の人事階層に一致するユーザーグループを集計することで、ユーザー組織のカスタムフィールドを確認します。この例では、business_unit：EMEA Financeです。

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

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

説明:

各デバイスについて、システムはCSVファイル内のルールを見つけようとします。 デバイスがルールと一致する場合、システムは次のいずれかの方法で位置データを取得します。

  • ルールに 位置タイプ および サイト 、状態 、国 フィールドの1つ以上にデータがある場合、システムは関連するフィールドからロケーションデータを取得します。 これらのフィールドのいずれかにデータが含まれている場合、システムはルールベースのロケーションデータを使用し、空のフィールドはクエリに空白の値として表示されます。

  • ルールに 位置タイプ フィールドのみデータがあり、サイト 、状態 、国 のフィールドが空の場合、システムはジオロケーションを使用してロケーションデータを取得します。

さらに詳しい説明は次の表を参照してください:

位置タイプ 内のデータ サイト、状態、または 国 内のデータ、あるいはすべて

位置タイプ 内のデータ いいえ `サイト` 、`状態、` と `国` にデータがありません

ルールベースの位置情報

✓

位置情報

✓

使用事例：製品設定フィールドのクエリ

以下の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

  1. これで、特定のサイトが接続性の悪さに陥りやすいかどうかがわかります。 その場所での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"

カスタム地域と位置タイプごとのDEXスコアを比較

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

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

Last updated

Was this helpful?