当社の価格設定モデル では、請求可能なユーザーの数は請求要素です。
コストの詳細 まだNew Relicの顧客ではなく、コストに興味がある方は、まず当社のメイン価格設定ページ をご覧ください。
New Relicの既存のお客様で、請求についてお知りになりたい場合は、請求UI を参照してください。組織に複数のアカウントが含まれている場合、組織内のすべてのユーザーを表示するには、プライマリレポートアカウント（通常は組織で最初に作成されたアカウント）に属している必要があります。
請求対象となるユーザー 請求対象ユーザーとは、コアユーザーまたはフルプラットフォームユーザーのいずれかのユーザータイプ を持つユーザーです。ベーシックユーザーは無料です。
ユーザーは、 New Relic組織に請求対象ユーザーとして追加された時点で請求対象になります。請求可能なユーザーがNew Relicにログインしたことがなく、UIにPending inviteタグがある場合でも、請求可能です。
ユーザーの管理 ユーザーを管理する方法については、ユーザー管理 を参照してください。
ユーザーコストの管理 使用量UI を使用すると、請求対象ユーザー数の概要を把握できます。UIで提供されているものより詳細な情報が必要な場合は、使用関連のNRQLクエリ を実行することもできます。
請求対象ユーザーのカウント方法 請求可能なユーザーの請求は、月ごとに行われます。暦月における組織の請求対象ユーザーの数を決定するために、当社はフルプラットフォームユーザーまたはコアユーザーのbillable user type を持つ当該月のユーザーをカウントします。ユーザーのbillable user type は、暦月中にユーザーが設定された最も上位のユーザータイプとして定義されます。UTCタイムゾーンを使用して、暦月の開始と終了を定義します。
実際にどのように機能するかの例：ユーザーが暦月中の任意の時点でフルプラットフォームユーザーとして設定されている場合、その月の課金対象ユーザータイプはfull platform userであり、その月の後半にダウングレードしても変更されません。これは、そのユーザーが一時的にフルプラットフォームユーザーに変更された場合にも当てはまります。
請求対象ユーザーの追加やユーザーのユーザータイプの変更を計画している場合は、これらのルールを念頭に置いてください。ヒント：
請求対象ユーザーを追加したり、ユーザーをアップグレードしたりする場合は、月初にそれを行うといいでしょう。
ユーザーをダウングレードする場合は、月末にダウングレードするといいでしょう。
UTC時間を使用して、各月の開始時点と終了時点を決定します。つまり、例えば太平洋標準時の月末日にユーザーをダウングレードしたい場合、太平洋標準時の午後5時までに変更を行う必要があります。
組織内で同じメールアドレスを持つユーザーは、1人のユーザーとしてのみカウントされます。詳細については、ユーザーの追跡 を参照してください。
新しいユーザーモデル のユーザーの場合：ユーザーは、管理者により請求可能なユーザーとして追加されたときに請求可能です。請求可能なユーザーがNew Relicにログインしたことがなく、UIにPending inviteタグがある場合でも、請求可能です。（初代のユーザーモデル のユーザーの場合、Pending inviteユーザーは請求対象ではありません。）
ユーザーの追加と招待の詳細については、ユーザーの追加 を参照してください。
請求対象ユーザーのコストは、組織の価格設定エディション （Standard、Pro、Enterprise）、またはNew Relicとのカスタム契約によって異なります。
New Relicの組織に最初に請求が開始されると、請求対象ユーザーの数は、月の開始時期に基づいて日割り計算されます。組織がサブスクリプションをキャンセルした場合、最終月には日割り計算が適用されます。
ユーザーダウングレードのルール 使用プラン が従量課金制であるかコミットメント契約であるかによって、フルプラットフォームユーザーをダウングレードできる回数に関するルールは異なります。
従量課金制のダウングレードルール 従量課金制の利用プラン では、ユーザーのダウングレードを制限するルールはありません。ただし、請求の計算 は、ユーザーのアップグレードまたはダウングレードのタイミングに関する決定に影響を与える可能性があります。
コミットメント契約のダウングレードルール ユーザーをアップグレードまたはダウングレードする前に、ユーザーへの請求の仕組み について理解しておいてください。
コミットメント契約 を結んでいる組織の場合、フルプラットフォームユーザーのダウングレードとアップグレードを管理するルールは次のとおりです。
If a full platform user is downgraded to a lower user type in a later month and then returned to a full platform user in a later month, and this downgrade/upgrade cycle happens twice in a contract year, that user will be billed as a full platform user for the remainder of the year, regardless of edits to their user type. ユーザーへの請求の仕組み により、1か月以内に発生するユーザータイプの変更を管理するルールはありません。暦月におけるユーザーの請求対象ユーザータイプは、その月に設定されている最もランクの高いユーザータイプです。
このルールの内容で使用される用語の詳細を以下に説明します。
downgrade とは、1暦月でフルプラットフォームユーザーとしての料金が適用される状態から、後の暦月には下位のユーザータイプ（コアまたはベーシック）としての料金が適用されるか、削除されることです。
upgrade とは、1暦月にはコアユーザー、ベーシックユーザー（または削除済みユーザー）としての料金が適用される状態から、後の暦月にはフルプラットフォームユーザーとしての料金が適用されることです。
contract year とは、契約の開始時点、またはその時点の応当日に開始されます。組織が別の価格設定プランから開始し、コミットメント契約に切り替えた場合、ユーザータイプのダウングレードルールは、お客様がオプトインした日から、契約更新日または契約期間の年間契約応当日のいずれか早い方に適用されます。
ヒント Why do we have rules governing full platform user downgrades/upgrades?
フルプラットフォームのユーザータイプは、長期的な分類を意図しています。当社は、コミットメント契約を作成する際に請求対象ユーザーの見積もりに依拠しており、これらのルールにより、契約上の制限を一貫して実施しています。
ダウングレード制限の例 契約年が3月に始まると仮定します。ユーザーが月によってアカウントタイプを変更するとします。
ユーザーは3月にフルプラットフォームユーザーとして請求されます
ユーザーは4月にベーシックユーザーとして請求されます（downgrade ）
ユーザーは6月にフルプラットフォームユーザーとして請求されます（upgrade ）
ユーザーは7月にベーシックユーザーとして請求されます（downgrade ）
そのユーザーが次の月にフルプラットフォームユーザーに戻った場合、その後再びベーシックユーザーまたはコアユーザーにダウングレードされた場合でも、その契約年度の残りの期間についてフルプラットフォームユーザーとして請求されます。
段階的な価格設定 一部の組織では、請求可能なユーザーの段階的価格設定にアクセスできます。その詳細については、段階的な価格設定 を参照してください。