> 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/understanding-key-data-platform-concepts/data-we-collect-and-store.md). # 収集・保存されるデータ ## データカテゴリー Nexthinkは、**オブジェクト**と**イベント**という2種類のデータを区別します。 ### オブジェクト #### インベントリオブジェクト インベントリーオブジェクトは、デジタル環境に関連する物理的または仮想的なアイテムを表します。 オブジェクトには、一度キャプチャされるとほとんど変化しない要素が含まれます。 | オブジェクト | プロパティ | | ------ | ------------------- | | バイナリー | （例：名前、サイズ、バージョン、 …） | | ユーザー | （例：名前、ユーザー名、部門、 …） | | device | （例：名前、CPU、OS、 …） | | … | … | #### 構成オブジェクト 構成オブジェクトは、警告、アプリケーション、キャンペーン、リモートアクションなど、Nexthinkユーザーが構成するすべてのオブジェクトを指します。 | オブジェクト | プロパティ | | ----------- | --------------------- | | モニター | （例：名前、しきい値、優先度、 …） | | キャンペーン | （例：名前、ステータス、トリガー\_方法） | | リモート\_アクション | （例：名前、 …） | | … | … | ### イベント イベントの主な特性は、それが時間にリンクされていることです。 言い換えれば、イベントはIT環境内で特定の時点で発生した何かを表します。たとえば、`execution.events`、`web.errors`などです。 イベントデータはさまざまな目的に役立ちますが、主な違いは**運用**利用と**傾向**観察にあります。 #### 運用データ 運用データを使用して、特定の問題を検出し、診断し、解決します。 これには、従業員のデバイスからキャプチャされたライブイベントと、モニターによってトリガーされたアラートが含まれます。 コンテンツセクションには、以下のようなものがあります。 * `execution.events` * `execution.crashes` * `device_performance.events` * `remote_action.executions` * `alert.alerts` 運用データは、詳細で広範です。 Nexthinkは、このデータを最大で30日間保存します。 さまざまなNexthinkモジュールを通じて運用データにアクセスし、ドリルダウン機能を使用して調査で表示します。 あるいは、調査に直接アクセスし、ビジュアルエディターを使用するか、NQLクエリを作成して運用データを取得します。 #### トレンド トレンドを使用すると、長期間にわたるメトリクスの変動を分析してパターンを観察し、戦略的な決定をサポートできます。 トレンドは、あまり詳細ではなく、最大13か月間保存されます。 これらは、運用イベントデータを1日または7日のサンプル単位で集計し、重要なメトリクスやプロパティに凝縮したものです。 さまざまなNexthinkモジュールは、デフォルトでトレンドデータを保存します。 モジュールのコンテンツを構成し、関連する運用データを十分な期間収集した後にトレンドを観察します。 コンテンツセクションには、以下のようなものがあります。 * ソフトウェアメータリングモジュールでは、最大90日間のデータを表示します。 調査でこのデータをクエリすることもできます：`software_metering.events`。 * リモートアクションモジュールでは、最大13か月間のデータを表示し、調査でこのデータをクエリします：`remote_action.executions_summary`。 * アプリケーションモジュールでは、特定のアプリケーションのデータを最大90日間表示します。 * デジタルエクスペリエンスモジュールでは、最大13か月間のDEXスコアを表示します（このページの[計算済みメトリクス](#precomputed-metrics)も参照してください）。 長期的なデータを捉えるカスタムトレンドを作成し、調査でクエリし、貴重な洞察を得るためにダッシュボードを作成します。 詳細については、[カスタム トレンド管理](/platform/ja/user-guide/administration/content-management/custom-trends-management.md)ドキュメントページを参照してください。 *** ## イベント収集の種類 イベント収集には、**即時型**と**サンプリング型**の 2 種類があります。 ### 即時イベント 即時イベントは、発生した瞬間の出来事を反映します。 これには、クラッシュ、起動、ログインが含まれます。 | イベント | 説明 | 協会 | プロパティ | メトリック | | ------------------------- | -------------- | -------------------- | ------------------ | ---------------------------------------------------------- | | `execution.crash` | バイナリのクラッシュ | user, device, binary | time, binary\_path | cardinality | | `session.login` | デバイスでのユーザーログイン | user, device | time, session\_uid | time\_until\_desktop\_ready, time\_until\_desktop\_visible | | `device_performance.boot` | デバイスの起動 | device | time, type | boot\_duration | | … | … | … | … | … | ### サンプリングイベント サンプリングイベントとは、継続的かつ長期的な活動に関連する動的メトリクスを監視するために不可欠なデータ収集方法を指します。 これは、CPU 使用率、メモリ使用量、プロセストラフィックなど、絶えず変動し、正確なデータ表現には定期的なサンプリングと集計が必要となるメトリクスに特に重要です。 Collector のサンプリングプロセスは 20〜30 秒ごとに頻繁に行われ、高解像度のデータが得られます。 その後、このデータは集計されたタイムスライスに構造化されます。タイムスライスの長さは、データ収集の特定の要件に応じて、5 分または 15 分の場合があります。 これらのタイムスライスにより、データの分析が容易になります。 | イベント | 説明 | 協会 | プロパティ | メトリック | | --------------------------- | ---------------------------------- | -------------- | ---------------------- | ------------------------------------------------------ | | `session.events` | デバイスが Nexthink に報告しているタイミングを示すサンプル | ユーザー、デバイス | protocol、session\_ID、… | RTT、latency、interaction\_time、… | | `execution.events` | 消費リソースを伴うプロセスの実行 | ユーザー、デバイス、バイナリ | | CPU\_time、outgoing\_traffic、memory\_used、… | | `device_performance.events` | デバイスによって消費されるリソース | device | | CPU\_usage、read\_operation\_per\_second、used\_memory、… | | … | … | … | … | … | #### リソース使用率指標 サンプリングされたイベントは、CPU、GPU、NPU の使用量などの動的なメトリクスを時間の経過とともに取得します。\ これらのメトリクスは、分析を容易にするために時間バケット（たとえば、5 分または 15 分間隔）に集計されます。 各時間バケット内のリソースの動作をより包括的に把握できるよう、Nexthink は CPU、GPU、NPU リソース向けに複数種類の使用率メトリクスを提供しています： * **平均使用量**（`*.avg`）: 時間バケット内の典型的な使用率レベルを表します。 このメトリクスを使用して、通常の動作条件を把握します。 * **時間（総消費量）**: 時間バケット内で消費されたリソースの総量を表します。 このメトリクスを使用して、アプリケーションおよびデバイス間のリソース需要を比較します。 さまざまなレベルで： * **アプリケーションレベル**: 特定のバイナリが消費したコンピューティングリソースの量を示します * **デバイスレベル**: デバイス上のコンピューティングリソースの総使用量を示します * **最大使用量**（`max_*`）: 時間バケット内で観測された最高使用率を表します。 このメトリクスを使用して、平均値では確認できない可能性がある短時間のスパイクを特定します。 * **高使用量の継続時間**（`duration_with_high_*`）: 時間バケット内で、使用率があらかじめ定義された高使用量のしきい値を超えた合計時間（秒）を測定します。 このメトリクスを使用して、リソース負荷が持続している期間を検出します。 各メトリクスは、リソースの動作に関する異なる視点を提供します： * **平均使用量**が答える質問: *典型的な負荷はどの程度か?* * **時間**が答える質問：*最も多く消費しているのは誰か？ 需要はどのように比較されるか?* * **最大使用量**が答える質問: *スパイクはどの程度高かったか?* * **高使用量の継続時間**が答える質問: *負荷状態はどのくらい続いたか?* これらのメトリクスを組み合わせることで、次の事項を区別できます： * 高消費のワークロードと低消費のワークロード。 * 最大値は高いが継続時間が短い短時間のスパイク。 * 継続時間が長い持続的な負荷。 これらのメトリクスは CPU、GPU、NPU 全体で一貫したモデルに従うため、異なる処理ユニットを比較分析できます。 #### サンプリングされたイベントの集約 集計時に、システムは類似したイベントをマージし、データ型に応じて異なる関数（合計、平均、パーセンタイルなど）を使用してそのメトリクスを組み合わせます。 Nexthink は、データポイントの値を維持するために最も意味のある集計関数を選択します。 たとえば、`outgoing_traffic` は合計され、`connection_etablishment_time` は平均化されます。 **例 1 - 複数のプロセス** 同じデバイス上で同じユーザーにより、3 つのプロセスで実行されている `chrome.exe` について考えてみましょう。 | 時間 | binary.name | outgoing\_traffic | connection\_establishment\_time.avg | | ------------- | ----------- | ----------------- | ----------------------------------- | | 08:00 - 08:12 | chrome.exe | 15 MB | 6ms | | 08:05 - 08:12 | chrome.exe | 5 MB | 10ms | | 08:10 - 08:14 | chrome.exe | 10 MB | 20ms | データは集計され、08:00 に開始して 08:15 に終了する 15 分間のサンプリングイベントとして保存されます | start\_time | end\_time | binary.name | outgoing\_traffic | connection\_establishment\_time.avg | | ----------- | --------- | ----------- | ----------------------- | ----------------------------------- | | 08:00 | 08:15 | chrome.exe | **30 MB** (15 + 5 + 10) | **12ms** ( (6 + 10 + 20) / 3 ) | 次のように NQL でクエリを実行します： 
execution.events during past 15min
| where binary.name == "chrome.exe"
| list start_time, end_time , outgoing_traffic, connection_establishment_time.avg
**例 2 - デバイス CPU** 特定のデバイスの `cpu_usage` を保存するため、Nexthink Collector は 30 秒ごとに CPU 負荷をサンプリングします。 | 時間 | cpu\_usage | | -------- | ---------- | | 08:00:00 | 80% | | 08:00:30 | 55% | | 08:01:00 | 75% | | … | … | | 08:04:00 | 90% | | 08:04:30 | 95% | 08:00 から 08:05 まで稼働しているデバイスでは、10 個のサンプルが生成されて Nexthink インスタンスに送信され、そこで新しい値に集計されます。 | start\_time | end\_time | cpu\_usage.avg | | ----------- | --------- | ----------------------------------------- | | 08:00 | 08:05 | **82%** (80 + 55 + 75 + … + 90 + 95) / 10 | 次のように NQL でクエリを実行します： 
device_performance.events during past 5min
| list start_time, end_time, cpu_usage.avg
集計により、システムはインサイトを生成する能力を損なうことなく、長期間にわたってデータを保存し、迅速に取得できます。 *** ## 事前計算済みメトリクス 現在 DEX スコアの計算に使用されている事前計算済みメトリクスは、過去 7 日間のデータに基づいています。 DEX スコアは、7 日間全体のデータを考慮する一方で、毎日計算され、計算時刻に対応するポイントイベントとしてデータベースに保存されます。 過去 7 日間のデータに基づいて本日計算された DEX スコア値を取得するには、`dex.scores during past 24h` を使用します。 **例** 貴社では、2024 年 6 月 1 日に、ワークフローを使用した SharePoint の問題の自動修復を導入しました。 修復の開始後に発生したイベントのみを含むアプリケーション DEX スコアを取得するには、2024 年 6 月 8 日以降のスコアをクエリします： ``` users | include dex.application_scores on Jul 8, 2024 | where application.name in ["Sharepoint"] and node.type == application | compute sharepoint_score_per_user = node.value.avg() | summarize sharepoint_score = sharepoint_score_per_user.avg() ``` *** ## Nexthink の使用状況データ Nexthink は、IT 担当者の推測に依存せず、製品およびアカウントロールごとの使用アクティビティを測定するために、`usage.account_actions` NQL テーブルを通じてプラットフォームテレメトリを公開しています。 このプラットフォーム使用状況データセットでは、次のことができます： * 使用されているモジュールと機能を追跡する * 使用状況の傾向を経時的に測定する * 有効化のギャップを検出する * ロール間で使用状況を比較する * ROI の導入状況追跡イニシアチブを支援する。 Nexthink の使用状況テレメトリをクエリするには、**Nexthink の使用状況**への**データモデルの可視性**を持つユーザーロールが必要です。 [https://github.com/nexthink/documentation.online-product-documentation/tree/develop/ja\_docs/configuring\_nexthink/configuring-your-platform/administration/account-management/roles/README.md#data-model-visibility](https://github.com/nexthink/documentation.online-product-documentation/tree/develop/ja_docs/configuring_nexthink/configuring-your-platform/administration/account-management/roles/README.md#data-model-visibility "mention") を参照してください。 プラットフォームの `usage` データは、**調査**やライブダッシュボードなど、NQL をサポートするすべての機能で使用できます。
調査から Nexthink 製品全体の使用状況を一覧表示する Nexthink の使用状況と製品固有の導入状況を一覧表示するには、**調査**で特定の期間に対して `usage.account_actions` NQL テーブルをクエリします。 以下のクエリと画像を参照してください。\ NQL フィールドの詳細については、[NQLデータモデル](/platform/ja/understanding-key-data-platform-concepts/nql-data-model.md#usage) を参照してください。 ``` usage.account_actions during past 7d ``` `usage.account_actions` の調査結果を取得した後： 1. テーブルのフィールド列を確認またはエクスポートして、Nexthink のモジュールおよび機能が特定のタスクの実行に使用される頻度と、その利用者を確認します。 2. ロールおよび機能における導入のギャップを探し、IT 組織内で摩擦が大きい可能性のあるプロセスとの相関を確認します。 導入に関する問題がある場合は、[Nexthink Learn](https://learn.nexthink.com/) の学習パス、評価、および認定プログラムを活用するデジタル導入戦略を実施する必要があります。 {% hint style="info" %} 調査を実行するには、[調査の作成](/platform/ja/user-guide/investigations/creating-investigations.md) を参照してください。 {% endhint %}
ライブダッシュボードから Nexthink の使用状況と導入状況を可視化する Nexthink の使用状況と製品固有の導入状況を可視化するには、**ライブダッシュボード**でウィジェットを構成し、Nexthink `usage.account_actions` のカスタム表現を設定します。 次の例では、製品モジュールなどのフィールド別にプラットフォームアカウント数を分類する**棒グラフ**ウィジェットを表示します。 NQL フィールドの詳細については、[NQLデータモデル](/platform/ja/understanding-key-data-platform-concepts/nql-data-model.md#usage) を参照してください。 棒グラフのクエリ例を参照してください： ``` usage.account_actions during past 60d | summarize no_of_platform_accounts = account.count() by module ``` {% hint style="info" %} 可視化用に利用可能なダッシュボードウィジェットを構成する方法については、[ウィジェットタイプ](/platform/ja/user-guide/live-dashboards/widget-types.md) を参照してください。 {% endhint %}
{% hint style="warning" %} `usage.account_actions` データセットは、Nexthink プラットフォームの導入状況を示します。 セキュリティ関連コンテンツの監査には、代わりに[監査ログ](/platform/ja/security/exporting-audit-logs.md)を使用してください。 `usage.account_actions` のデータ保持に関する詳細は、[データの解像度と保存](/platform/ja/understanding-key-data-platform-concepts/data-resolution-and-retention.md#dataresolutionandretention-retentionperdatacategory) を参照してください。 {% endhint %} **例** プラットフォームの `usage` データは、調査やライブダッシュボードなど、NQL をサポートするすべての機能で使用できます。 以下の例を参照してください。 `usage.account_actions` NQL データセットのその他のユースケースには、次のものがあります：
調査からアクティブユーザーの総数を表示する 過去 30 日間の「アクティブユーザー」の総数を表示するには、**調査**から `usage.account_actions` NQL テーブルをクエリします： ``` usage.account_actions during past 30d | summarize active_user = account.name.count() ``` {% hint style="info" %} NQL フィールドの詳細については、[NQLデータモデル](/platform/ja/understanding-key-data-platform-concepts/nql-data-model.md#usage) を参照してください。 調査を実行するには、[調査の作成](/platform/ja/user-guide/investigations/creating-investigations.md) を参照してください。 {% endhint %}
調査から機能別のアクティブユーザーとアクションを一覧表示する 過去 90 日間の機能別アクティブユーザー数とアクションを表示するには、**調査**から `usage.account_actions` NQL テーブルをクエリします： ``` usage.account_actions during past 90d | summarize active_users = platform.account.account_uuid.count(), actions_per_feature = count() by feature | sort active_users desc ``` {% hint style="info" %} NQL フィールドの詳細については、[NQLデータモデル](/platform/ja/understanding-key-data-platform-concepts/nql-data-model.md#usage) を参照してください。 調査を実行するには、[調査の作成](/platform/ja/user-guide/investigations/creating-investigations.md) を参照してください。 {% endhint %}
{% hint style="info" %} `usage.account_actions` NQL テーブルを利用して、[Nexthink Amplify に固有の使用状況を追跡](/platform/ja/user-guide/amplify/tracking-amplify-usage.md)することもできます。 {% endhint %} *** ## 動的データモデル NQL を使用すると、オートコンプリートまたはビジュアルエディターによって提案されるものの、NQL データモデルのドキュメントには記載されていないフィールドが表示される場合があります。 これらのフィールドは動的データモデルの一部であり、組織の環境に適応するために文書化されたデータモデルを拡張します。 動的フィールドは、複数のソースから取得される場合があります。
カスタムフィールド Nexthink 管理者が作成した、または Nexthink Library からインストールされたカスタムフィールドごとに、Nexthink は対応するインベントリオブジェクトテーブルにフィールドを自動的に追加します。 たとえば、`device` オブジェクト用に作成されたカスタムフィールドは、次のように使用できます： `device.#custom_field_name` ここで、`#custom_field_name` はカスタムフィールドの NQL 識別子です。 詳細については、[カスタムフィールド管理](/platform/ja/user-guide/administration/content-management/custom-fields-management.md)を参照してください。
評価 Nexthink 管理者が構成した評価ごとに、Nexthink は対応するインベントリオブジェクトテーブルにフィールドを自動的に追加します。 評価が構成されているオブジェクトに応じて、次のいずれかとして使用できます： `device..評価` `user..評価` どちらの場合でも、`` は評価が設定されたフィールドの NQL 識別子です。 詳細については、[評価管理](/platform/ja/user-guide/administration/content-management/ratings-management.md#custom-ratings) を参照してください。
カスタムのデバイスおよびユーザー分類 Nexthink 管理者は、デバイスまたはユーザーを組織の構造に割り当てるルールを定義できます。 デフォルトのデータモデルに含まれていない **Business Unit** や **Region** などの組織的なグループ分けを表すために、**カスタム分類** を作成することもできます。 Nexthink 管理者によってカスタム分類が設定されるたびに、Nexthink は対応するインベントリオブジェクトテーブルにフィールドを自動的に追加します。 作成対象のオブジェクトに応じて、カスタム分類は次のいずれかとして利用可能になります。 * `device.organization.#customClassification` * `user.organization.#customClassification` どちらの場合も、`#customClassification` はカスタム組織グループの NQL 識別子です。 詳しくは、[デバイスとユーザーの分類](/platform/ja/user-guide/administration/system-configuration/data-management/environment/product-configuration.md#device-and-user-classification) を参照してください。
特定のリモートアクション実行 公開されたリモートアクションごとに、Nexthink はリモートアクション専用のテーブルを自動的に作成します。 `remote_action.#nql_id_of_the_remote_action.executions` たとえば： * システムまたはライブラリのリモートアクションの場合は `remote_action.get_battery_status.executions` * カスタムリモートアクションの場合は `remote_action.#get_citrix_local_host_cache_status.executions` 入力パラメーターおよび出力パラメーターは NQL フィールドとして利用でき、直接クエリすることができます。 各パラメーターは、そのデータ型に応じた操作をサポートします。 詳細については、[リモート アクションの NQL 機能](/platform/ja/user-guide/remote-actions/remote-actions-nql-examples.md) を参照してください。
特定のキャンペーン回答 公開されたキャンペーンごとに、Nexthink はキャンペーン専用のテーブルを自動的に作成します。 `campaign.#nql_id_of_the_campaign.responses` たとえば： * システムまたはライブラリのキャンペーンの場合は `campaign.dex_score_campaign.responses` * カスタムキャンペーンの場合は `campaign.#my_campaign.responses` 詳細については、[NQLによるキャンペーンの結果の精査](/platform/ja/user-guide/campaigns/campaigns-nql-capabilities/scrutinizing-the-results-of-a-campaign-with-nql.md) を参照してください。
カスタムトレンド Nexthink 管理者によってカスタムトレンドが設定されるたびに、Nexthink はカスタムトレンド専用のテーブルを作成します。 `custom_trend.`.snapshots\` システムはカスタムトレンドデータの毎日のスナップショットを取得し、テーブルに追加します。 スナップショットには個人を特定できる情報（PII）は含まれておらず、最大 13 か月間保持されます。 たとえば： `custom_trend.windows_11_ratio.snapshots` 詳細については、[カスタムトレンド管理](/platform/ja/user-guide/administration/content-management/custom-trends-management.md#customtrendsmanagement-usingcustomtrends) を参照してください。
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://docs.nexthink.com/platform/ja/understanding-key-data-platform-concepts/data-we-collect-and-store.md?ask=&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.