# 集計およびグループ化（クラシック） Nexthink ソリューションは、定義された階層および時間の二つの次元に沿ってメトリクスデータを集約します。 データを集約するには、メトリクスを Finder で作成するときに設定する *group by* および *aggregate by* オプションも考慮します（メトリクスの種類によってはすべてのオプションが利用可能ではない場合があります）。 階層ノードおよび期間選択と共に、異なる集約およびグループ化のオプションの組み合わせにより、web ダッシュボードで異なる結果が生成されます。 ### 例としての階層 説明の目的で、2 階層のみで構成された場所に基づく非常にシンプルな階層を定義したとします。 * 国（トップレベル） * 都市（エンティティレベル） 我々の架空の組織は、スイス (CH) とスペイン (ES) の二つの国にオフィスがあります。 スイスは、ジュネーブ (GVA) とチューリッヒ (ZRH) の二つの異なる都市にオフィスがあります。 スペインは、マドリード (MAD) とバルセロナ (BCN) の二つの異なる都市にオフィスがあります。 最後に、各都市にデバイスが二台だけあると仮定します。 各デバイスの名前は都市の最初の文字に続き、番号 1 または番号 2 で構成されています。 これは合計で 8 台のデバイスとなります。 | 階層 | 階層 | 階層 | 階層 | 階層 | 階層 | 階層 | 階層 | 階層 | | ---------- | --- | --- | --- | --- | --- | --- | --- | --- | | 国 | CH | CH | CH | CH | ES | ES | ES | ES | | 都市（エンティティ） | GVA | GVA | ZRH | ZRH | MAD | MAD | BCN | BCN | | デバイス | G1 | G2 | Z1 | Z2 | M1 | M2 | B1 | B2 | ### カウントメトリクス オブジェクトの種類に応じて、カウントメトリクスは次のことを考慮します。 * 特定の日にアクティブだったオブジェクトのみ。 * 特定の日における活動状況に関係なく、すべてのオブジェクト。 一部のタイプのオブジェクトでは、アクティブなインスタンスのみをカウントできます。 パッケージの場合、常にすべてをカウントします。 ユーザーとデバイスについては、すべてをカウントするか、アクティブなもののみをカウントするかの選択ができます。 以下の表を参照してください： | アクティブのみ | すべてのオブジェクトのみ | ユーザー選択 | | --------------------------------------------------------------------------------------------- | ----------------------- | ----------------------------------- | | | | | パッケージ以外には、通常その日のアクティブだったオブジェクトのみをカウントすることが有益です。 しかし、変換プロジェクトのような場合には、それらが特定の日にアクティブであったかどうかに関係なく、既に変換条件を満たしているオブジェクトを把握することが重要です。 たとえば、Windows 8 から Windows 10 への移行プロジェクトがある場合、測定日の間アクティブでなかったとしても、既に Windows 10 をインストールしたデバイスを毎日カウントしたいと思うかもしれません。 この方法で、web インターフェースでメトリクスの結果を観察する際、減少しない値を得ることができます。これは、アクティブなデバイスのみを測定した場合には当てはまらないことがあります。 たとえば、典型的な企業では、週末にアクティブなデバイスの数が急激に減少し、平日に再び増加します。 したがって、すべてのオブジェクトをカウントするメトリクスの値は、その日特有のものであり、時間をかけて集約することはできません。 したがって、web インターフェースは、一日を超える期間を選択した場合、これらのメトリクスに関連付けられたウィジェットを表示しません。 また、これらのメトリクスの計算には、利用可能なすべてのオブジェクトをカウントするために、Engine で利用可能なすべての履歴を確認する必要があります。 これらのメトリクスに対し指定できる条件は、フル期間調査と同じです。言い換えれば、それらは活動やイベントに依存することはできません。 アクティブなオブジェクトのみをカウントする場合、追加条件 （\_ ...の条件を満たしているデバイスをカウント） を使用すると、システムが一日を超える期間のメトリクス結果を表示する方法に影響します。 この追加条件を使用して、オブジェクトを以下のいずれかの方法でカウントします。 *最終日* ：選択した期間内でオブジェクトがアクティブであった最後の日（インベントリ目的）、または * *最低一日* ：選択した期間内で（発生を検知するため）。 * プロパティによるグループ化 #### 最初の例として、デバイスの数をカウントし、タイプとOSの両方でグループ化するメトリクスを考えます（**COMPUTE DAILY**セクションで**Group by** ***device type**および**OS version and architecture*** を選択）。 このメトリクスはデバイスのインベントリを作成することを目的としており、インベントリは通常、カタログ化されたオブジェクトの最新の状態に基づいているため、カウントメトリクスの追加条件を最終アクティブ日に選択します（**MATCHING**セクションで\_**最後のアクティブ日**\_における条件を満たすデバイスをカウントしろを選択）。 メトリクス作成のためのその他のオプションはデフォルト設定のままにしておきます。 この例のデバイスは以下のタイプを持ち、次のオペレーティングシステムがインストールされています。 デバイス | デバイスタイプ | OS バージョンとアーキテクチャ | G1 | | ------- | ------------------------------------- | ----------------------------------------------------------------------- | | server | Windows 2012 Server Standard (64 ビット) | G2 | | Desktop | Windows 8.1 Pro (64 ビット) | Z1 | | ノートパソコン | Windows 7 Enterprise SP1 (64 ビット) | Z2 | | Desktop | Windows 8.1 Pro (64 ビット) | M1 | | ノートパソコン | Windows 10 Pro (64 ビット) | M2 | | Desktop | Windows 7 Enterprise SP1 (64 ビット) | B1 | | ノートパソコン | OS X Yosemite 10.10.5 (64 ビット) | B2 | | Desktop | Windows 7 Enterprise SP1 (64 ビット) | デバイスとオペレーティングシステムが変わらなければ、選択された期間に関係なく、システムはメトリクスに対して常に同じグローバル結果を表示します。 | たとえば、Table ウィジェットでカウントメトリクスを表示し、行をオペレーティングシステムごとに、列をデバイスタイプごとに並べると、常に次のグローバル結果が得られます。 OS バージョンとアーキテクチャ | デバイスタイプ | デバイスタイプ | デバイスタイプ | Desktop | | ------- | ------- | ------- | -------------------------------------------------------------------------------------- | | | ノートパソコン | server | Windows 8.1 Pro (64 ビット) | | 2 | 0 | 0 | Windows 7 Enterprise SP1 (64 ビット) | | 2 | 1 | 0 | Windows 2012 Server Standard (64 ビット) | | 0 | 0 | 1 | Windows 10 Pro (64 ビット) | | 0 | 1 | 0 | OS X Yosemite 10.10.5 (64 ビット) | | 0 | 1 | 0 | 次に、リスト中の唯一の Mac OS デバイスである B1 の OS が *Yosemite* から *El Capitan* にアップグレードされたケースを考えましょう。 | このアップグレード後、カウントメトリクスの追加条件の選択が表示される結果に影響を与えます。 相違点は一日を超える期間を表示する場合にのみ現れるので、デバイスが OS をアップグレードした週を選択したウィジェットの結果を見てみましょう。 追加条件として**最後のアクティブ日**を選択した場合、以下の結果を得ます。 OS バージョンとアーキテクチャ | デバイスタイプ | デバイスタイプ | デバイスタイプ | Desktop | | ------- | ------- | ------- | ----------------------------------------------------------------------------------------------------------------- | | | ノートパソコン | server | Windows 8.1 Pro (64 ビット) | | 2 | 0 | 0 | Windows 7 Enterprise SP1 (64 ビット) | | 2 | 1 | 0 | Windows 2012 Server Standard (64 ビット) | | 0 | 0 | 1 | Windows 10 Pro (64 ビット) | | 0 | 1 | 0 | OS X El Capitan 10.11.4 (64 ビット) | | 0 | 1 | 0 | つまり、以前の結果と同じですが、リストの最後の行では **OS X Yosemite 10.10.5 (64 ビット)** が **OS X El Capitan 10.11.4 (64 ビット)** に置き換えられています。 | これは、その週に選択された期間内で Mac デバイスがアクティブであった最後の日に、すでに *El Capitan* バージョンがインストールされていたことを意味します。 ただし、追加条件オプションを **少なくとも一日** に設定したメトリクスを定義した場合、ウィジェットは次の結果を表示します。 OS バージョンとアーキテクチャ | デバイスタイプ | デバイスの種類 | デバイスの種類 | デバイスの種類 | | -------------------------------------- | ------- | ------- | ------- | | | desktop | laptop | server | | Windows 8.1 Pro (64 bits) | 2 | 0 | 0 | | Windows 7 Enterprise SP1 (64 bits) | 2 | 1 | 0 | | Windows 2012 Server Standard (64 bits) | 0 | 0 | 1 | | Windows 10 Pro (64 bits) | 0 | 1 | 0 | | OS X Yosemite 10.10.5 (64 bits) | 0 | 1 | 0 | | OS X El Capitan 10.11.4 (64 bits) | 0 | 1 | 0 | つまり、アップグレードの週に、Macコンピュータは\_Yosemite\_バージョンがインストールされた状態である日もあれば、\_El Capitan\_バージョンがインストールされた日もあったということです。 そのため、テーブルウィジェットに2回表示されます。 したがって、オプション**少なくとも一日**は、本来の明細管理の目的には適していません。 一方で、オプション**少なくとも一日**は、特定の状況を検出するためには有用です。 例えば、選択した期間中に、一日でもリアルタイム保護が無効になっていたデバイスがあったかどうかを知りたいとします。 そのために、デバイスをカウントし、以下の2つの機能のいずれかを実行するメトリックを作成します。 * デバイスをリアルタイム保護の状態でグループ化する * 保護が無効になっているデバイスのみを取得する条件を設定します。 メトリックの追加条件として**少なくとも一日**を選択し、その日ではなく、いずれかの日に保護が無効になっていたデバイスをカウントします。 Nexthinkソリューションは、メトリックの値を計算するときにデバイスのリアルタイム保護の状態を確認します。 同じ日にデバイスのリアルタイム保護をオフからオンに切り替え、夜間計算の前に切り替えた場合、その状況は事前に定義されたメトリックでは検出されません。 一般的に、これはオブジェクトの状態に条件を設定するすべてのメトリックに適用されます。 一方で、イベントに基づく条件が設定されたメトリックは、発生履歴を保持します。 例えば、高リスクのバイナリを実行しているデバイスの数をカウントするメトリックがある場合、システムはどんな場合でも、メトリックの計算中にこれらの実行を確認します。 在庫の例に戻ると、今度はアクティブデバイスだけでなく、すべてのデバイスをカウントした結果を考えてみましょう。 YosemiteからEl Capitanへの移行は変換プロジェクトのように見えるため、すべてのオブジェクトをカウントする方が、アクティブなオブジェクトだけをカウントするよりもおそらく適しているでしょう。 例えば、例のMacノートパソコンがEl Capitanにアップグレードされた後、丸一日オフになったと想像してみてください。 すべてのオブジェクトをカウントするメトリックではその日の結果に例のMacノートパソコンが含まれますが、アクティブデバイスのみをカウントするメトリックでは結果に含まれません。 デバイスやユーザーのカウントメトリックを作成するときには、アクティブなオブジェクトのみをカウントするか、すべてのオブジェクトをカウントするかを慎重に考えてください。 #### 外国カテゴリでのグループ化 Count metrics let you group results not only by the properties of the counted objects themselves but also by categories of related objects (*foreign* categories). この種のグループ化をユーザーをカウントするメトリックを作成して説明します。 メトリックは、外国カテゴリの「所有権」でユーザーをグループ化します。 所有権とは、デバイスのカテゴリであり、次の2つのキーワードがあります。 * **企業用**は、デバイスが会社に属していることを示します。 * **BYOD**は、デバイスがユーザーの個人所有であることを示します。 例の階層から、スイス内のデバイスであるCHノードに焦点を当て、最後の日の使用パターンが次のようであったと仮定します。 * User 1: an employee used a personal computer G1 in Geneva and then traveled to Zurich and used a corporate computer Z1. * User 2: used a personal computer G2 in Geneva. * User 3: used a corporate computer Z2 in Zurich. 夜間の計算中にデータを取得するとき、Portalは以下のデータを内部に保存します。 | ユーザー | エンティティ | 所有権 | | ------ | -------- | --------- | | User 1 | GVA, ZRH | BYOD, 企業用 | | User 2 | GVA | BYOD | | User 3 | ZRH | 企業用 | Note that the system is unable to deduce from this table whether the Corporate device of User 1 is located in Geneva or Zurich (same for the employee’s BYOD device). 安全に行くために、実際の組み合わせが発生しなかった場合も計算に含めるという規則があり、そのためにはすべての可能な組み合わせをユーザーに含めます。 In our example for User 1, only the combinations GVA-BYOD (because of the use of G1) and ZRH-Corporate (because of the use of Z1) actually occur. However, the system counts as well User 1 for the combinations GVA-Corporate and ZRH-BYOD. Thus, displaying the metric in a table widget, with the rows organized by hierarchy and the columns by Device-Ownership, yields the following results for the last day (when CH is selected as the Country of the hierarchy): | | 所有権 | 所有権 | 所有権 | | --- | --- | --- | ---- | | 市 | 全体 | 企業用 | BYOD | | 全体 | 3 | 2 | 2 | | GVA | 2 | 1 | 2 | | ZRH | 2 | 2 | 1 | Note that because of User 1 using computers in both Geneva and Zurich, and because of the additional combinations added by convention, none of the partial results add up to the overall values. すべての階層の値は、階層で分割するためのウィジェット設定で**全体の値を表示**するオプションを選択すると、テーブルウィジェットに表示されます。 #### 比率と閾値に関する考察 比率の計算とそこに基づく閾値を含むカウントメトリックを作成すると、階層の下位レベルを探索するときに、閾値違反がより頻繁に発生します。 その理由は、カウントするオブジェクトが少ないほど比率が極端になりがちだからです。 少数のオブジェクトに関与して閾値違反を引き起こすのを避けるため、チェックボックス**階層ノードで少なくともx個のオブジェクトが影響を受ける場合にのみ有効**を選択し、影響を受けたと見なすための最小オブジェクト数を指定します。 一方で、比率ではなく絶対値に基づいて閾値を設定する場合、閾値違反はより多くのオブジェクトを含むため、階層の上位レベルでより頻繁に発生します。 ### 量メトリック There are two types of quantity metrics: those that measure a countable number of actions (for example, the number of executions) and those that measure a continuous quantity related to the activity of a device (the memory usage, the boot or logon duration, etc.). 両方の量メトリックのタイプでは、測定された量は時間とともに変化します。 したがって、すべての収集された値を集計して、各利用可能な時間枠のウェブインターフェースに最終結果を表示する必要があります。 量メトリックには、結果を集計する4つの方法があります。 * **すべてのデバイスと全期間の合計** * **1日あたりのデバイスごとの平均値** * **1日あたりのデバイスごとの最大値** * **1日あたりのデバイスごとの最小値** すべての量メトリックに対してすべての集計戦略が利用できるわけではありません。 特定のメトリックに対して意味のあるオプションのみが選択可能です。 通常、1日あたりのデバイスごとの平均値と最大値の計算はどんな量メトリックでも利用可能ですが、合計や最小値は特定の種類の量メトリックにのみ意味を持ちます。 いくつかの例を通じて量メトリックの異なる集計オプションを考察してみましょう。 例えば、各デバイスでNexthink Finderの実行回数をカウントするメトリックを考えてみましょう。これは、実行可能ファイル名\_nxfinder.exe\_の条件を持つ、実行回数を計算する量メトリックです。 スペインにある元の例のデバイスのこの週の使用パターンが次のようであると仮定します。 | | | Finderの実行 | Finderの実行 | | --- | ---- | --------- | --------- | | 市 | デバイス | 月曜日 | 火曜日 | | MAD | M1 | 4 | 2 | | M2 | 1 | 1 | | | BCN | B1 | 0 | 1 | | B2 | 1 | 0 | | 異なる集計戦略のメトリックの結果を、最後の日の観点からまず考察してみましょう。 **1日あたりのデバイスごとの最大値: 2** 火曜日にFinderを最も実行したデバイスはM1で、2回実行しました。 **すべてのデバイスと全期間の合計: 4** Results from adding all the executions on Tuesday 2 (M1) + 1 (M2) + 1 (B1) = 4. **1日あたりのデバイスごとの平均値: 1.3** Results from dividing the sum of all executions (the previous value calculated) by the number of devices that participate in the metric 4 / 3 = 1.3. 火曜日の平均を計算するときにB2はカウントされないことに注意してください。なぜなら、それは `nxfinder.exe`を実行する条件を満たしていないからです。 次に、先週を選択したときの結果を考えてみましょう。 週が終わっていないので、システムは月曜日と火曜日のデータしか持っていません。 **1日あたりのデバイスごとの最大値: 4** デバイスM1は月曜日にFinderを4回実行しました。 それは週の間のどのデバイスについても最大です。 **すべてのデバイスと全期間の合計: 10** 火曜日の4回の実行と月曜日の6回の実行を合計すると。 **1日あたりのデバイスごとの平均値: 1.7** 週全体のすべての実行の合計を1日あたりのメトリックの参加デバイスの合計で割った結果。 That is 10 / 6 = 1.7. Note again that neither B1 not counted in on Monday nor B2 is counted in on Tuesday because they do not satisfy the condition of executing `nxfinder.exe`, so we only have three devices each day, making a total of 6 devices for computing the average. 私たちは個々の発生回数をカウントする量メトリックの例を見ました。 Let us now consider a metric based on continuous value; for instance, a metric that computes the **average memory usage per execution** of Finder (as in the previous example, we use a condition on the executable `nxfinder.exe`). ご存知のように、Finderのメモリ使用量は同時に開かれているタブの数によって増加するため、Finderの2つの異なる実行によって使用されるメモリ間には大きな差があると予想されます。 再度、スペインのデバイスについて、現在の週に次の使用パターンがあると仮定します。 | | | Finderのメモリ | Finderのメモリ | | --- | ------ | ---------- | ---------- | | 市 | デバイス | 月曜日 | 火曜日 | | MAD | M1 | 200 MB | 100 MB | | M2 | 実行なし | 200 MB | | | BCN | B1 | 300 MB | 500 MB | | B2 | 400 MB | 400 MB | | 選択された集計方法によると、火曜日のメトリックの結果は次の通りです。 **1日ごとのデバイスごとの最大値: 500 MB** デバイス B1 は火曜日に最も高いメモリ使用量を記録しました。 この値はデバイス上でFinderが使用したメモリの絶対最大値ではなく、実際には1日を通した平均を測定していることに注意してください。 **1日ごとのデバイスごとの最小値: 100 MB** デバイス M1 は火曜日に最も低いメモリ使用量を記録しました。 また、これが一日の平均であるため、Finderが使用したメモリの絶対最小値ではないことに注意してください。 **1日ごとのデバイスごとの平均値: 300 MB** すべてのデバイスの値を合計すると、100 (M1) + 200 (M2) + 500 (B1) + 400 (B2) = 1200 MB になり、4台のデバイスで割ると平均300 MBになります。 先週の結果を確認する場合、以下のようになります。 **1日ごとのデバイスごとの最大値: 500 MB** 火曜日に他のどのデバイスもB1より多くFinderのメモリを使用しなかったので、週の最大は再び500 MBです。 **1日ごとのデバイスごとの最小値: 100 MB** メモリの最小使用量についても火曜日のM1が該当します。 月曜日のM2のメモリ使用量は Finder の実行条件を満たしていないため0としてカウントされません。 したがって、メトリックはM2を考慮に入れていません。 **1日ごとのデバイスごとの平均値: 300 MB** 火曜日の1200 MBに加えて、月曜日の合計 200 (M1) + 300 (B1) + 400 (B2) = 900 MBで、週の総合計2100 MBになります。 月曜日に3台のアクティブなデバイス (M2は実行なし) に火曜日の4台のデバイスを加えた合計7台で割ると、2100 / 7 = 平均300 MBになります。 数量メトリックでは、カウントメトリックと同様に、結果を最大2つの基準でグループ化できます。 数量メトリックはデバイスにのみ関連するため、結果のグループ化基準は属性やデバイスのカテゴリーに基づくことができます（この場合、外国カテゴリーは利用できません）。 **グループ化基準**オプションを設定すると、ダッシュボード内のテーブルウィジェットに表示されるときにメトリックの結果を詳細に分けることができます。これはカウントメトリックに対して示されたのと同じ方法です。 ### トップメトリック トップメトリックは特定の活動への貢献度によって並べられたオブジェクトのリストを提供します。 トップメトリックを定義するときには、次のことを選びます。 * リストに表示するオブジェクトのタイプ。 * リスト内のオブジェクトの総数（トップ10からトップ100まで）。 * そのタイプのオブジェクトにリンクされた活動。 * アクティビティに対する貢献が最も高いまたは最も低いオブジェクトをリストに含める基準。 * アクティビティに対する各オブジェクトの貢献度を計算するための、*集約基準* オプション。 利用可能な集約オプションは、数量メトリックで利用可能なものと似ています。 違いは、それらが必ずしもデバイスに基づいているわけではないため、デバイスを跨ぐことができることです。 例えば、\_最も多くの実行数を持つトップ10 ユーザー\_を計算するメトリックでは、異なるデバイスで同じユーザーによって実行された回数を一つの値に集約します。 したがって、これはトップメトリックの **集約基準** オプションです: * **全期間にわたる合計** * **1日ごとの平均値** * **1日ごとの最大値** * **1日ごとの最小値** 数量メトリックの場合と同様に、すべてのトップメトリックに対してすべての集約の可能性があるわけではありませんが、意味のあるものだけです。 ### 階層によるグループ化 カウントおよび数量メトリックのために指定する**グループ化基準**オプションに加えて、システムは階層によってすべてのメトリック（トップメトリックを含む）の結果を常に集計します。 カウントまたは数量メトリックの定義において1つの**グループ化基準**オプションを選択すると、階層およびグループ化オプションによって結果を分解し、テーブルウィジェットの行と列（または列と行）として配置することが常に可能です。 2つの**グループ化基準**オプションを定義し、テーブルウィジェットの結果を行または列で分解するために一方を選択した場合、もう一方を列または行に選択する必要があります。 この場合、階層によって分解するオプションは利用できません。 それでも、ウィジェットに追加されたメトリックの合計値を表示するオプション（つまり、**メトリック**オプション）を選択し、\_グループ化基準\_のいずれかではなく、階層基準を再び選んで結果を配置することができます。 しかし、トップメトリックには**グループ化基準**オプションがなく、テーブルウィジェットで階層を配置することはできません。 トップメトリックの定義に表示フィールドを追加し、それらがテーブルウィジェットで配置されているのを確認することはできます。 #### 階層ナビゲーション 階層によるメトリックの結果を明示的に分解しないウィジェット（KPI、ラインチャート、および階層で整理されていないテーブルウィジェット）では、webインターフェースの上部の青いリボンにある階層ナビゲーションツールを使って階層構造の異なるレベルでの結果を探索します。 ダッシュボード内のすべてのウィジェットは、階層ナビゲーションツールで選択したノードに結果を適応させます。 階層で結果を分解するテーブルウィジェットは、実際には階層ナビゲーションツールで選択されたノードの直下のレベルに配置されたノード（つまり、その子ノード）によって結果を分割します。 たとえば、元の例の階層を中心に構築されたダッシュボードを考えてみてください。 ダッシュボードを表示している間に、グローバルビューから階層ナビゲーションツールのCHノードに切り替えると、ダッシュボード内のすべてのウィジェットはスイスに関して得られた値に限定された結果を表示します。 さらに、階層によって配置されたテーブルウィジェットは、CHノードの子であるGVAとZRHのノードによって結果を分割します。 ### 時間に沿った集約に関する考慮事項 時間が経過するにつれて、Nexthinkソリューションは日々データを蓄積していきます。 毎晩、システムは過去のデータを収集し、その日と集計します。 しかし、現在の週から現在の月のビューに切り替えると、直感に反する状況が発生する可能性があります。すなわち、現在の月のデータ量が現在の週のデータ量よりも少ない可能性があります。 この状況は、月の境界を最近越えた場合に発生する可能性があります。週が異なる2つの月にまたがることがあるからです。 数量指標に関する以前の例の一つでこれを説明しましょう。 Finderの実行回数を数える指標を再度考え、それをすべてのデバイスと期間全体の**合計によって集計**することを選択したと仮定します。 得られた値を見ると、月曜日にFinderの実行が6回、火曜日に4回ありました。 月曜日が4月30日、火曜日が5月1日で、今日は5月2日であると仮定してください。 したがって、昨日、月の境界を越えました。 | 日付 | 4月30日 | 5月1日 | 5月2日 | | ---- | ----- | ---- | ---- | | 曜日 | 月曜日 | 火曜日 | 水曜日 | | 実行回数 | 6 | 4 | 該当なし | 最も最近の利用可能な日付にナビゲートすると、選択した期間によって結果が異なります: * **日:** 火曜日、5月1日に対応する4回の実行。 * **週:** 10回の実行、月曜日の6回と火曜日の4回の合計。 * **月:** 火曜日、5月1日に対応する4回の実行。 つまり、週は新しい月の前に始まり、まだ進行中なので、現在の週には現在の月よりも多くの日があります。 したがって、週の値が月の値より大きくなることがあります。