> 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/content-management/custom-trends-management.md). # カスタムトレンド管理カスタムトレンドは標準のNexthinkデータモデルを拡張し、既存データの日次スナップショットを保存して、最大13か月にわたる経時的な変化を確認できます。 {% hint style="info" %} 最大200件のカスタムトレンドを設定できます。 {% endhint %} ## Libraryからインストールしたカスタムトレンド Nexthinkは、Nexthink Libraryから手動でインストールできる一連の事前設定済みカスタムトレンドを提供します。 Nexthinkインスタンス内のNexthink Libraryモジュールに移動し、事前定義されたカスタムトレンドをインストール、管理、および更新します。詳細については、[Nexthink Library](https://docs.nexthink.com/platform/ja/user-guide/nexthink-library) ドキュメントを参照してください。 ## 新しいカスタムトレンドカスタムトレンドを一から作成すると、ニーズやユースケースに応じて必要なデータを表示できます。詳細については、[カスタムトレンドの作成](#customtrendsmanagement-creatingacustomtrend)を参照してください。 ## カスタムトレンドページへのアクセス 1. メインメニューから **管理** を選択します。 2. ナビゲーションパネルの「コンテンツ管理」セクションで **カスタムトレンド** をクリックします。

## カスタムトレンドの管理カスタムトレンド管理ページには、すでに定義されているカスタムトレンドのリストが表示されます。 * テーブルの左上に表示されるカスタムトレンドの合計数を確認します。 * ページ右上の検索ボックスで名前によりカスタムトレンドを検索し、表示結果を絞り込みます。 ### カスタムトレンドリストのフィルタリングリスト上部のフィルターを使用して、作業対象のカスタムトレンドに絞り込みます。フィルター条件: * **作成元**: カスタムトレンドが作成された方法。 * **タグ**: カスタムトレンドに割り当てられたタグ。詳細については、[フィルタリング機能](/platform/ja/getting-started/navigating-the-web-interface.md#navigatingthewebinterface-filteringcapabilities)を参照してください。 ### カスタムトレンドのアクションメニューの使用カスタムトレンドの縦三点アイコンにカーソルを合わせると、次のオプションを含むアクションメニューが表示されます： * **編集**: カスタムトレンド設定の詳細を表示し、名前、説明、NQLクエリを変更します。 * **タグを管理**: [関連付けられたタグ](#customtrendsmanagement-taggingcustomtrends)を追加または削除します。 * **エクスポート**: カスタムトレンドをJSON形式でダウンロードして保存します。 * **削除**: カスタムトレンドを削除します。

### カスタムトレンドのインポートローカルデバイスからJSON形式のカスタムトレンドをインポートするには： 1. **管理 > カスタムトレンド** ページの右上隅にある **インポート** ボタンをクリックします。 2. ハードドライブから複数のJSONファイルを**選択**または**ドラッグ**して、システムにインポートします。インポートされたすべての項目は、カスタムコンテンツとして分類されます。

### カスタムトレンドへのタグ付けタグ付けにより、カスタムトレンドを効率的に整理でき、データをすばやく簡単に移動できます。右側の **タグ** パネルを開いて、次の操作を行います： * パネル上部で特定のタグを検索します。 * 一つ以上のタグを選択して、カスタムトレンドテーブルをフィルタリングします。 **管理 > カスタムトレンド** ページからカスタムトレンドに一つ以上のタグを追加するには： 1. カスタムトレンドにカーソルを合わせてアクションメニューを表示し、**タグを管理** を選択します。 2. **タグを管理** ポップアップでは、次の操作を実行できます： * 新しいタグを入力するか既存のタグを選択して、カスタムトレンドに追加します。 * 特定のタグ項目のアクションメニューを開き、**タグを削除**するかタグの色を変更します。 * タグを削除しても、そのタグが関連付けられているカスタムトレンドから削除されるだけです。 3. または、複数のカスタムトレンドを選択して、一括で**タグを管理**できます。

## カスタムトレンドの作成新しいカスタムトレンドを作成するには： 1. カスタムトレンドページの右上隅にある **新しいカスタムトレンド** ボタンをクリックします。 2. カスタムトレンド設定ページで **名前** と **説明** を入力します。 3. 必要に応じて、NQLの一意の識別子である **クエリID** を調整します。 4. このトレンドデータの意味と目的を他のユーザーが理解できるよう、任意の **説明** を入力します。 5. 日次スナップショットの評価時にNexthinkプラットフォームが実行する **NQLクエリ** を記述します。 {% hint style="info" %} カスタムトレンドを保存すると、NQLクエリとクエリIDの値は変更できなくなることに注意してください。 {% endhint %}

### カスタムトレンド用のNQLクエリの記述クエリを記述する際は、以下のルールに従ってください： * クエリは `devices` 名前空間を対象にする必要があります。 * `devices` で使用できる時間範囲は `past 1d` です。システムに登録されているすべてのデバイスを対象にするには、この時間範囲を省略します。 * クエリには `include` 句を最大二つ、`compute` 句を最大二つ含めることができます。 * イベントコレクションの `include` 句の後で使用できる唯一の時間範囲は `past 1d` です。時間範囲を指定せずにオブジェクトコレクションを含めることができます。 * Nexthinkでは、`compute` 句の結果に適用する `where` 句は使用できません。 * クエリにデバイス名や従業員のメールアドレスなどの個人識別情報（PII）を含めることはできません。 * クエリは、最大二つのメトリクス（数値）と最大五つのプロパティ（文字列、列挙型、またはブール値）を含む `list` 句で終える必要があります。 * システムでは、`as()`、`sort`、`limit`、`summarize`、`countif()`、`sumif()`、`with` のキーワードを使用できません。 {% hint style="warning" %} **日時メトリクスの制限事項** カスタムトレンドは、ネイティブではデータ型の一部のみをサポートしています。ほとんどの場合、これは機能に影響しません。ただし、日時メトリクスはネイティブ型として保存されないため、[NQL time\_elapsed()](/platform/ja/understanding-key-data-platform-concepts/nexthink-query-language-nql/nql-functions/nql-time_elapsed.md) や [NQL datetime関数](/platform/ja/understanding-key-data-platform-concepts/nexthink-query-language-nql/nql-functions/nql-date-time-functions.md) などのタイムスタンプ関数は使用できません。 {% endhint %} システムではデフォルトで、日次スナップショットの評価時に一部のデバイスプロパティを含め、デバイスのコンテキストの一部として保存します。これには次が含まれます： * オペレーティングシステムプラットフォーム * オペレーティングシステム名 * 場所（国、都道府県、場所の種類） * 組織（エンティティ、カスタム組織） ### カスタムトレンドデータに含まれるデバイスについてカスタムトレンドの定義では、アクティビティに基づいてデバイスのセットを指定できます。 * **システムに登録されているすべてのデバイス**（過去30日間にアクティブだったすべてのデバイス。詳細は[データ解像度と保存](/platform/ja/understanding-key-data-platform-concepts/data-resolution-and-retention.md)を参照）を含むスナップショットを保存するには、カスタムトレンドの定義で `devices` テーブルの時間指定を省略します。 {% code lineNumbers="true" %} ``` devices | include … during past 1d | compute … | list … ``` {% endcode %} * **スナップショット取得日にアクティブだったデバイス**を含むスナップショットを保存するには、カスタムトレンドの定義で `devices` の後に `during past 1d` を追加します。 {% code lineNumbers="true" %} ``` devices during past 1d | include … during past 1d | compute … | list …。 ``` {% endcode %} {% hint style="info" %} デバイスの時間枠を指定していない場合、トレンドデータと同じ期間の運用データを比較すると、結果にわずかな差異が生じることがあります。 {% endhint %} ### データ保持の承認 * データ保持チェックボックスを選択し、このトレンドデータが13か月間システムに保存されることを確認します。 * 保存ボタンをクリックして、新しいカスタムトレンドを保存します。 ## カスタムトレンドの使用カスタムトレンドを保存すると、NQLで新しいトレンドデータをクエリできます。最初に、クエリはカスタムトレンド定義を保存した日の前の三日間のデータのみを返します。これにより、設定したカスタムトレンドが期待どおりの形式でデータを返すかを確認できます。 {% hint style="info" %} 過去三日間から計算される初期データには、当日のデバイスコンテキスト情報のみが含まれます。 {% endhint %} システムは毎晩、追加のスナップショットを保存します。スナップショットには、顧客のタイムゾーンで前日の午前零時から計算日の午前零時までに発生したイベントが含まれます。以下は、カスタムトレンドの定義で使用するNQLクエリの例です： {% code lineNumbers="true" %} ``` devices | include execution.crashes past 1d | compute nb_crashes = number_of_crashes.sum() | list nb_crashes , hardware.manufacturer ``` {% endcode %} `| list` 句を使用してトレンド内にメトリクスとプロパティを保存すると、カスタムトレンドテーブル内に新しいフィールドが作成されます。システムは、以下のルールに従って新しいフィールド名を作成します： | カスタムトレンド定義クエリで使用するフィールド | カスタムトレンドテーブル内のフィールド名 | ルールの説明 | | --------------------------------- | ------------------------------- | -------------------------------------------- | | `nb_crashes` | `nb_crashes` | 上記の例の `nb_crashes` など、クエリのカスタムメトリクスは変更されません。 | | `hardware.manufacturer` | `hardware_manufacturer` | ピリオド `.` はアンダースコア `_` に置き換えられます。 | | `device.#custom_field` | `device__custom_field` | 先頭以外のハッシュ `#` はアンダースコア `_` に置き換えられます。 | | `#custom_field` | `#custom_field` | 先頭のハッシュ `#` はカスタムトレンドのフィールド名にそのまま残ります。 | | `device.last_seen.time_elapsed()` | `device_last_seen_time_elapsed` | 関数の括弧 `()` は省略されます。 | 上記の例では、カスタムトレンド定義の `| list` 句で `devices` テーブルの `hardware.manufacturer` フィールドを使用すると、カスタムトレンドテーブルに `hardware_manufacturer` という新しいフィールドが作成されます。カスタムトレンドテーブルは次のようになります： | バケット開始 | … | コンテキスト | メトリック | プロパティ | | ---------------------- | - | -------------- | ------------------- | ------------------------------ | | 19/01/2024 00:00:00 AM | | デバイス1のコンテキスト情報 | デバイス1の `nb_crashes` | デバイス1の `hardware_manufacturer` | | 19/01/2024 00:00:00 AM | | デバイス2のコンテキスト情報 | デバイス2の `nb_crashes` | デバイス2の `hardware_manufacturer` | | 19/01/2024 00:00:00 AM | | デバイス3のコンテキスト情報 | デバイス3の `nb_crashes` | デバイス3の `hardware_manufacturer` | | 19/01/2024 00:00:00 AM | | | …。 | | | 20/01/2024 00:00:00 AM | | デバイス1のコンテキスト情報 | デバイス1の `nb_crashes` | デバイス1の `hardware_manufacturer` | | 20/01/2024 00:00:00 AM | | デバイス2のコンテキスト情報 | デバイス2の `nb_crashes` | デバイス2の `hardware_manufacturer` | | 20/01/2024 00:00:00 AM | | デバイス3のコンテキスト情報 | デバイス3の `nb_crashes` | デバイス3の `hardware_manufacturer` | | 20/01/2024 00:00:00 AM | | | … | | Investigationsでカスタムトレンドデータをクエリするか、ダッシュボードウィジェットを作成してタイムライン上のトレンドを監視できます。カスタムトレンドデータを取得する構文は次のとおりです： {% code lineNumbers="true" %} ``` custom_trend..snapshots ... … ``` {% endcode %} ウィジェットを設定する際は、既存のカスタムトレンドのNQL IDを使用して、特定のメトリクスの経時的な変化を視覚的に表します。

Line chart configuration using a custom trend

### トレンドの関連付けトレンドテーブルは `devices` テーブルに関連付けられています。トレンドデータを取得する際は、この関連付けを利用してデバイスプロパティをクエリに含めることができます。ただし、これらのプロパティは元のテーブルに保存されている間のみ利用できます。詳細については、[データ解像度と保存](/platform/ja/understanding-key-data-platform-concepts/data-resolution-and-retention.md)ページを参照してください。 `hardware_manufacturer` などのカスタムトレンドフィールドは最大13か月保持されますが、関連付けられたデバイスのプロパティは、デバイスがシステムに登録されている間のみ利用できます。デバイスを削除または匿名化した場合、またはデバイスが30日を超えて非アクティブであった場合、デバイスプロパティはトレンドに直接保存されないため、クエリは「-」を返します。これは、カスタムトレンドがデフォルトで保存するデバイスコンテキスト情報には適用されません。この情報も13か月間保持されます（このページの[カスタムトレンド用のNQLクエリの記述](#customtrendsmanagement-writingnqlqueriesforcustomtrends)を参照）。 ## カスタムトレンドの使用の最適化カスタムトレンドを効果的に活用するには、トレンドデータのプロットには、カスタムトレンドの設定とダッシュボード設計という二段階のプロセスがあることを理解する必要があります（詳しい手順については[Live Dashboardsの管理](/platform/ja/user-guide/live-dashboards/managing-live-dashboards.md)を参照）。追跡するすべてのメトリクスに対して、必ずしもカスタムトレンドを作成する必要はないことに注意してください。一つのカスタムトレンドはNQLデータモデルの拡張として機能し、さまざまなメトリクスと集計の組み合わせで長期データをクエリできます。カスタムトレンドの設定と取得について、以下の推奨事項を考慮してください：

可能な場合は、取得時にフィルターと集計を適用する

トレンド定義内ではなく、取得時にデータをフィルタリングし、デバイスに集計を適用することをお勧めします。ハードウェアメーカー別にクラッシュが発生したデバイス数のトレンドラインをプロットする例を考えてみましょう。複数の戦略が可能ですが、すべてが最適とは限りません。 **最適ではない戦略** 最適ではない戦略として、ハードウェアプロバイダーごとにデバイスの集計を含む複数のカスタムトレンド定義を作成する方法があります。次のクエリは、特定のデバイスでクラッシュが発生していない場合はゼロ、少なくとも一回クラッシュが発生した場合は一を示すデバイスのリストを返します。 {% code lineNumbers="true" %} ``` devices | where hardware.manufacturer == "my_provider1" | include execution.crashes past 1d | compute nb_devices = device.count() | list nb_devices ``` {% endcode %} カスタムトレンドデータを取得する際、フィルターは不要です。 {% code lineNumbers="true" %} ``` custom_trend.#name.snapshots during past 300d | summarize my_provider1_with_crashes = nb_devices.sum() by 1d ``` {% endcode %} **最適な戦略** 最適な戦略では、クラッシュ数をメトリクス、ハードウェアメーカーをプロパティとしてスナップショットに記録するカスタムトレンド定義を一つ作成します： {% code lineNumbers="true" %} ``` devices | include execution.crashes past 1d | compute nb_crashes = number_of_crashes.sum() | list nb_crashes , hardware.manufacturer ``` {% endcode %} カスタムトレンドデータを取得する際： * 少なくとも一回クラッシュしたデバイスと、該当するハードウェアプロバイダーをフィルタリングします： {% code lineNumbers="true" %} ``` custom_trend.#name.snapshots during past 300d | where nb_crashes > 0 | where hardware_manufacturer == "my_provider1" | summarize my_provider1_with_crashes = count() by 1d ``` {% endcode %} * または、条件付き集計を使用して少なくとも一回クラッシュしたデバイスのみを集計し、ハードウェアプロバイダーによる追加のグループ化を行います： {% code lineNumbers="true" %} ``` custom_trend.#execution_crashes.snapshots during past 300d | summarize fraction_with_crashes_per_manifacturer = countif(nb_crashes > 0) / count() by 1d, hardware_manufacturer ``` {% endcode %}

二重集計を慎重に使用する

カスタムトレンドでは、カスタムトレンド定義内に集計を組み込むことができます。取得時に、トレンドデータに対して追加の集計を実行することもできます。ただし、スナップショットには定義で使用された集計に関する情報が保持されないことに注意してください（`users` などの一意のオブジェクトに `count()` を使用した場合を除く）。次の例を考えてみましょう。カスタムトレンド定義内のNQLは、特定の日における各デバイスの平均起動時間を含むスナップショットを作成します。 {% code lineNumbers="true" %} ``` devices during past 1d | include device_performance.boots during past 1d | compute boot_duration = duration.avg() ``` {% endcode %} データを取得する際、すべてのデバイスにわたる日次スナップショットの平均を計算できます。 {% code lineNumbers="true" %} ``` custom_trend.#name.snapshots | summarize c1 = boot_duration.avg() by 1d ``` {% endcode %} この場合、avg() 集計が返す結果は、各デバイスの平均値の合計を、起動があったデバイス数で割った値になります。

## スナップショット失敗のトラブルシューティング #### カスタムトレンドログの調査スナップショット計算は、さまざまな理由で失敗することがあります。たとえば、[カスタムフィールド](/platform/ja/user-guide/administration/content-management/custom-fields-management.md)や[組織構造](/platform/ja/user-guide/administration/system-configuration/data-management/environment/product-configuration.md#organization)などの動的データモデルの変更によりカスタムトレンドNQLクエリ定義が正しくなくなった場合や、システムで一時的な障害が発生した場合です。失敗すると、カスタムトレンドデータが不完全になる可能性があります。これらの失敗を理解することは、問題を迅速に解決し、ダッシュボードに表示されるデータの潜在的な問題を可視化するうえで重要です。システムは、計算時刻、ステータス、カスタムトレンドNQL IDなどの詳細を含む各カスタムトレンド計算を `platform.custom_trends_logs` テーブルに保存します。特定のカスタムトレンド計算の失敗原因を調査するには、次のNQLクエリを使用します： ``` platform.custom_trends_logs during past 30d | where status = failure | where details.nql_id ="#my_custom_trend_ID" | list custom_trends_log.time, custom_trends_log.status, details.description, details.n_retries, details.nql_id ``` 常に情報を把握し迅速に対応できるよう、すべてのカスタムトレンドの失敗を検出するモニターを設定することをNexthinkは推奨します。次のモニターNQLクエリと設定を使用します： ``` platform.custom_trends_logs during past 24h | where status = failure | summarize failing_computations = count() by details.nql_id ```

詳細については、[カスタムモニターの作成](/platform/ja/user-guide/alerts-and-diagnostics/managing-alerts/creating-custom-monitors.md)ページを参照してください。 #### トレンドのバックフィル Nexthinkは、予期しない技術的障害によるカスタムトレンドデータの欠落を防ぐ仕組みを使用しています。特定の日のスナップショットの計算と保存に失敗した場合、次の日次計算時に、現在のスナップショットを計算する前に不足データの計算を試行します。この仕組みでは、過去三日間までのデータを復元できるため、問題に対処し、ダッシュボード上のトレンドの連続性を維持するための時間を確保できます。 {% hint style="info" %} 過去の日から計算されたデータには、当日のデバイスコンテキスト情報のみが含まれます。 {% endhint %} ## 権限 * ユーザーロールで **すべてのカスタムトレンドデータを管理** 権限が有効になっている場合、Nexthink Webインターフェイスでカスタムトレンドを作成できます。 * ユーザーロールで **NQLでプラットフォームログを表示** 権限が有効になっている場合、`platform.custom_trends_logs` テーブルにアクセスできます。詳細については、[ロール](/platform/ja/user-guide/administration/account-management/roles.md)ドキュメントを参照してください。 --- # 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/user-guide/administration/content-management/custom-trends-management.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.