AIのプライシングが請求・収益スタックを凌駕している

スライド。まず、将来見通しに関する記述についてです。念のための措置として、法務チームより、すべてのプレゼンテーションで本記載を共有するよう求められております。逐語的に読み上げはいたしませんので、恐れ入りますが、将来見通しに関する記述に目を通すお時間を少々いただけますと幸いです。結構です。ありがとうございます。続いて、一般的なご案内事項を確認いたします。まず1点目、まだお済みでない方は、チャットタブで自己紹介をお願いいたします。挨拶をしていただき、どちらからご参加いただいているかもお知らせください。次に、リンクおよびリソースのご案内です。「More」をクリックすると、ブラウザ下部に「Resources」が表示されます。こちらから各種リソースをご確認いただけます。なお、最後に、共有したリソースの一部をご覧いただけるリンクもご案内いたします。ご質問については、最後にQ&Aの時間を設けておりますので、その際にまとめて取り上げます。

本セッションは当方で進行いたします。最後に私が戻りまして、Q&Aセクションの進行を担当いたします。ご質問が出てきましたら、遠慮なくチャットにご投稿ください。セッション中に取り上げられなかった場合は、終了後にフォローアップいたします。本セッションは録画しており、終了後のフォローアップメールにてリンクを共有いたします。続いて、投票（アンケート）質問です。ぜひ投票質問にご参加ください。本日のセッションは双方向性が高く、Kathyがテーマを進めている前半では、複数の投票質問をご用意しています。AIのプライシングに関しては、戦略から実際の運用への落とし込みまで、私たち全員が一緒に模索している状況だと認識しています。いくつかの推奨事項を共有いたしますが、正直なところ、この領域は変化のスピードが非常に速いため、私たちも皆さまから学びたいと強く考えています。皆さまそれぞれ進捗段階が異なることから、いくつか簡単な投票を実施し、同業の皆さまがどの位置にいるのか、また何がうまく機能しているのかを把握したいと思います。

引き続きチャットは活発にご利用ください。ご質問やコメントは、思いついたタイミングで随時お寄せください。それでは本日のスピーカーとして、Kathy Pearsonをご紹介します。Kathy、改めてようこそ。前回は、ええと……SSP—SSP AIのセッションでご登壇いただきましたが、本日もご参加いただきます。それでは、Kathyにお渡しします。ようこそ、Kathy。ありがとうございます。Lila、ありがとうございます。それでは本題に入ります。Lilaからもお話があったとおり、本日は請求（Billing）と収益（Revenue）の両方について取り上げます。AIの価格設定におけるシフトとしてこれまでに見られた動き、現在何が起きているのか、そしてそれがシステムにどのような負荷を与えているのかをお話しします。さらに、Xoraが、利用量（Usage）・請求（Billing）・収益認識（Revenue Recognition）を単一のプラットフォームと監査可能なプロセスのもとで連携させることで、そうした負荷の一部をどのように軽減できるかをご説明します。最後に、ライブデモの観点からも確認していきます。

私たちが繰り返し申し上げているとおり、市場の動きは速く、固定サブスクリプションから、従量課金、プリペイド・クレジット、ハイブリッドモデル、そしてAIベースの消費モデルへと移行しています。これらの変化は、これまでになく加速しています。年2回の価格改定ではなく、6か月の間に価格モデルが12回も変わる状況を目の当たりにしているお客様もいらっしゃいます。この柔軟性は、下流の収益に関する論点を生みます。すなわち、「お客様は実際に何を購入し、何を使用したのか」、そして「それをどのように収益認識すべきか」という点です。そこで、最初のアンケート質問です。次のうち、現在販売している、または今後12か月以内に販売予定の価格モデルはどれですか。なお、複数選択が可能です。

ご存じない方のために補足しますと、リソース内にAIの収益化シミュレーターをご用意しています。いくつかの質問に回答いただくと、Xoraでどのような形になり得るかについて、選択肢を追いながらご案内します。ぜひご活用いただきたいツールですので、必ず共有しておきたいと思います。あ、当社の場合はハイブリッドが優勢のようですね。これは想定どおりです。実際、多くのお客様でこの動きが見られます。最初はサブスクリプションで始めて、その後、何らかの従量課金要素を組み合わせたサブスクリプションへ移行し、最終的にあのハイ—そのハイブリッドへと移っていく、という流れです。

利用形態としては、トークン・クレジット、あるいはそういったものが考えられます。従量課金（Pay-as-you-go）の場合もあれば、超過分の利用（オーバーエージ）として扱われる場合もあります。以上が、当社のお客様から実際に見えてきているモデルの種類です。では、あと数秒だけお待ちして、その後この投票を締めて先に進みましょう。はい。次に、その負荷について話すと、

これらのAI従量課金モデルに移行すると、あらゆることがより難しくなっていくのが分かります。難しくなるのは、利用状況データのソースが分散している可能性があるからです。顧客が求める粒度でその利用状況を正確に提示し、かつ正確に請求する必要があり、その整合性も取らなければなりません。収益面では、収益認識をどのように行うべきかという点で、複雑性が増します。すなわち、ハイブリッドモデルにおいてSSPや配分をどのように扱うべきか、さらに場合によっては超過利用（overage）、未使用（breakage）、変動対価（variable consideration）への対応も必要になります。そして、これがシステム間で連携していない場合、二つのシステム間でリスクが生じます――同じ情報が適切に連携・流通していなかったらどうなるのでしょうか。

Xoraに目を向けると、請求および収益のための単一プラットフォームによってリスクが低減され、その起点はXoraの財務を考慮したプロダクトカタログという最初の統制ポイントにあります。商用の課金内容、利用動向、ならびに想定される収益計上パターンを一体として定義することで、下流工程を反復可能なプロセスとして確立できます。これは、プロダクトを作成する時点で、どのように請求し、どのようにレーティングし、そして当該プロダクトについてどのように収益を認識（計上）するかという極めて重要な要素も同時に定義している、という考え方を提供します。さて、もう一つアンケートがあります。えー、本日、ARの従量課金と収益についてはどのように対応されていますか。請求から収益へ移行するプロセスを、どのように運用されていますか。

そして、おそらく今回も、複数になるのではないかと思います。というのも、複数の作業を並行して行っている可能性があるからです。一部はERPで対応し、別の部分は手作業のスプレッドシートで処理している、というケースもあるでしょう。はい。現状を見ると、手作業のスプレッドシートが依然として約40%で第1位です。そして、ええ、それが大半を占めている、あるいは使用状況をトラッキングするために、どこかでカスタム構築したロジックを組み込んでいるケースもあります。ですので、間違いなく、ええ、他の見込み顧客から伺っている内容とも整合しています

私が毎日話をしていることです。誰かと話すたびに、必ずと言っていいほど話題の中心になるのがこれです。では、数秒ほど置いて、先に進みましょう。消費（consumption）について考えると、把握・認識の方法はいくつか存在します。いわゆる「万人に当てはまる唯一の型」はありません。ひとつのやり方で設計することはできますが、その前提となる条件次第では、同じ枠組みの中でも最大で4つの異なる方法で認識する可能性があります。これは、義務（obligation）の性質に依存します。

収益はいつ認識すべきか、また、使用量見積り、ロールオーバー権、または未請求の未収計上が必要かどうか。さらに、「ワンサイズ・フィット・オール」にするのではなく、可変対価を含む期間按分（ratable）など、さまざまなモデルをご用意しており、その中からご利用いただけます。従来のクラシックな従量課金（pay-as-you-go）モデルは、未請求ベース、あるいは、ええと、請求書に記載されたとおりに（請求書に関する実務上の便法を用いて）認識する形から、「認識します。収益認識のドライバーとして、その使用量イベントを使います」という形まであります。したがって、契約の組み立て方と、その基礎となる履行義務が何であるかに応じて、異なるモデルで対応します。それはスタンドレディ（待機）なのか、それとも本当に取引ベースなのか。ではデモに入る前に、最後にもう一つ、皆さまがこの点についてどのあたりで課題感をお持ちかを伺うアンケートを実施します

最も影響するのはどれですか。ご存じのとおり、この通話にはさまざまな役割の方が参加していますが、重要なのは正しい利用データを取得することなのでしょうか。算出することなのでしょうか。そのための価格設定でしょうか。あるいは収益を認識することなのでしょうか。どれでしょうか。そして改めて申し上げますが、これは多くの方がさまざまな場面で痛みを感じているテーマだと承知していますので、こちらで選択肢をいくつかご用意しました。この通話には、私と同じ感覚をお持ちの方がいらっしゃいますね。収益認識を正しく行うことです。[笑] 収益を正しく認識すること。

私のバックグラウンドはレベニュー領域にありますので、はい、それが私たちがここにいる理由です。そこで本日は、両面でそれをどのように実現できるかを見ていきます。Zuora Billing と Zuora Revenue を活用して、収益認識を最も効率的かつコンプライアンスに準拠した形で一体的に進めるにはどうすればよいか、という点です。では、ここを締めて先に進めます。本日ご覧いただく内容としては、設定を行いながら、えー…従量課金のプライシングプランを取り上げ、Zuora Revenue のプロダクトカタログが、その従量要素とそれに対する収益認識をどのように定義するのかを確認します。また、使用量についても見ていきます

が入力されます。実際にはそれは行いません。代わりに、Usage（利用量）とInput（投入量）がどのように定義されているか、未請求（unbilled）をどのように確認できるか、そしてそこで何が起きているのかを見ていきます。その後、収益認識（rev rec）の観点から確認し、いくつか異なるモデルを取り上げます。つまり、消費（consumption）に基づいて真に認識しているのか、期間按分（ratably）で認識しているのか、そして消費量と、それに伴う利用可能なレポーティングを本当に追跡する必要がある、という点を見ていきます。これにより、Zuoraプラットフォームがどのように機能するかのイメージを掴んでいただければと思います。では、ここからデモに入ります。まず開始して、Zuora Billingから始め、プロダクトカタログを開きます。ここに、年次AIクレジット用として設定した料金プラン（rate plan）があります。したがって、プリペイドクレジットを用意しています

金額。これを見ると、このプランを編集して、先に進み、クレジットプランを確認できます。ではここから始めて、いくつかの点を確認します。Zuora Billing では、さまざまな種類のチャージを定義できます。このケースでは、これを前払いチャージとして定義しています。これは前払いモデルのユニットベースの前払いチャージです。そのため、どのモデルを使用するかを定義できます。さらに、その中で下にスクロールすると、設定できる項目がいくつかあります。有効期間を設定できます。これらのクレジットをどれくらいの期間利用できるのか。1か月なのか、四半期なのか、1年なのか。これらのクレジットをどのように日割り計算するかも設定できます。すでに顧客がいる場合

U-サブスクリプションを購入済みで、現在そこに、クレジットベースの項目を追加しています。AIクレジットの収益化を進めていて、サブスクリプション期間の途中から開始するため、日割り計算（プロレーション）が可能です。引き落とし（消費）ルールも設定できるので、複数の項目が同時に動いている場合、この前受金に対してどの順序（優先順位）で消費させるかを決められます。また、ロールオーバー（繰越）の利用も検討できます。どの期間まで繰り越すのか、そして繰越の優先順位をどうするのか。繰越分を先に使ってから他のクレジットを使うのか、あるいはその逆にするのか。そうした設計が可能です。つまり、このチャージ内でルールを設定して柔軟に運用でき、その設定したルールが、結果として次の動作を左右する可能性があります

収益をどのように認識するかです。したがって、ここで収益の部分を見ると、勘定科目は定義しますが、本当に重要なのは、収益認識のトリガーとタイミングを定義することです。このケースでは、消費（利用）に基づいて認識するよう設定しています。Zuora Billing から Zuora Revenue に使用量のトリガーを連携し、それに基づいて前受クレジット（プリペイド・クレジット）について収益を認識します。使用量をトラッキングしつつ、期間按分で認識するように設定することも可能です。これも、期間按分しながらトラッキングするための仕組みの一つです。あるいは、SaaS であれば、注文の有効化（アクティベーション）を起点に、契約期間にわたって収益を認識します。次にドローダウン側ですが、私が使用しているときは

つまり、ここではさまざまな単位（Unit of Measure）を設定できるのですが、私が指摘したいのは、当該クレジットのドローダウン（このケースではAPIコール）の単位が、クレジット自体の単位とは異なる点です。したがって、私はドローダウンレートを設定しています。これは、APIコールなのか、振込（Transfer）なのか、取引（Transaction）なのか——利用量をどのようにカウントするかに応じて、あらゆる種類について完全に設定可能です。そのうえで、ドローダウンレートを設定できますが、差し引き先はあくまでクレジットです。つまり、同一のクレジットプールに対して、異なる項目を用いてドローダウンできる仕組みであり、そのレートを用いて、認識すべき売上高をどの程度にするかを把握します。そして、ここでは、

収益サイドでできることとしては、私のルールに応じて「上限を超えた場合、その超過分は発生したタイミングで直ちに収益認識したい」と設定できます。ここで出てくるのが、未請求見越（unbilled accrual）の考え方です。請求書を発行する前であっても、その利用分（usage）を収益として認識できます。そこまでのプロダクト設定は完了しています。次に必要なのは、実際にその内容に対して契約（contract）やサブスクリプション（subscription）を作成したときに、どう処理が動くのかを設定することです。まさにそこで、サブスクリプションを開いて確認できます。ここでは、先ほどの年次（annual）のサブスクリプションを設定しており、それに紐づくチャージ（charges）も設定済みです。ただ、私が本当にお伝えしたいのは、設定したその残高（balance）について、利用（usage）がどれくらいのペースで消化されているかを、いま追跡しているという点です。なので、もし

有効期間を確認すると、そのドローダウンがどのように発生しているかが分かります。その認識をどのように適用しているのか。そして、それがその取引における収益認識の方法を決定します。このケースでは超過していないため、その明細に対して取り崩しを行っているだけです。ただし、サブスクリプションによっては前倒しとなり、すべてを使い切ってしまう場合もあります。このケースでは、有効期間は四半期単位で、実際には超過しています。したがって8月を見ると、実際にそれをすべて使い切っています。さらに8月を見ると、8月分について未請求があることも確認できます。8月分はまだ請求していませんが、すでに収益を認識しています。必要に応じてそのように設定する場合の話です。これがその機能です

Zuora Billing で発生している内容を取り込み、それを Zuora Revenue 側へ移送していきます。では、Zuora Revenue でこれらの契約を確認してみましょう。移送して、今は Zuora Revenue にいます。契約を確認します。先ほど見ていたのと同じ契約を見てみます。Zuora Revenue 側では、現在その契約が設定されています。契約金額が何かを把握しています。これは 10 万ドルの前受金です。年次で前払い請求しているため、前受金全額を請求済みであることが確認できます。収益認識と残高も確認できます。必要であれば、ハイパーリンクからそのサブスクリプションに戻り、Billing 側で見ていた内容を確認できます。

一方で、ここで本当にお伝えしたいのは、当社が設定しているPoBテンプレートです。Zuora Billingのプロダクトカタログで確認した各ドライバーが、私がどのように収益認識するかを規定しています。したがって、AIクレジットについては、利用実績の取得というイベント時点で認識します。そしてオーバーエイジについては、当該利用料金においてオーバーエイジが発生した場合、その発生時点で認識します。では、その3万7,000の認識はどこで確認できるのか。確認できるのは、消費履歴（consumption history）に移動した場合です。ここでは、各利用料金をすべて、日次でサマリーしたベースで収益に取り込んでいることが分かります。そしてここでは、月次ベースで、私は

認識している売上がどの程度かを確認できます。これらのいずれかの月を確認すると、Zuora Billing から連携された日次の従量課金（Usage）料金が実際に表示されます。このケースでは、複数の日にわたって複数の請求が発生していることが分かり、さらに、それがどのサブプロダクトに対して計上されたものかも確認できます。請求内容はさまざまで、この場合は、複数のアイテムが組み合わさっており、それらのアイテムが日々発生していた形になります。これにより、何が起きているのかをそのレベルの明細で把握できます。これをウォーターフォールの観点、または売上サマリーの観点で見ると、その取り崩し（ドローダウン）を確認できます。

Waterfallでは、期間を通じて何がスケジュールされているか、契約負債残高がいくらか、請求がどのように推移しているかを確認できます。これは、単純に収益認識を行うケースです。契約終了時に失効するルールを設定しておけば、こちらで何もしなくても済みます。有効期間の終了までに利用（usage）を使い切らなかった場合でも、その分を収益認識できます。したがって、現状のbreakageは、有効期間の終了時点で自動的に処理（収益認識）できます。では、期間按分（定額）で収益認識したい場合はどうでしょうか。基礎となる履行義務をスタンドレディ義務（stand-ready obligation）として定義する状況を想定します。この場合は日次で収益認識する必要がありますが、利用状況（usage）はトラッキングしたい。つまり、これは私が今、収益認識しているケースです

異なる取り扱いになります。したがって、この契約を確認すると、現時点では期間按分（ラタブル）で収益認識する前提ですが、その上で変動対価（VC：Variable Consideration）をトラッキングできる可能性があります。これは、使用量（Usage）ベースで月次の収益認識額が日割レートを上回っている場合に対応するため、実施が必要になることがあります。そして、その点は消費履歴（Consumption History）からも、改めて確認できます。毎月、月次の認識額をわずかに上回っていることが分かります。そこで8月は、VC見積りにサインすることができます。その見積りでは、「最終的にどこに着地すると見込むか」を設定できます。するとシステムが、累計のキャッチアップによるキャッチアップ処理を実行します

VC収益がシステム全体の他の項目と整合する形で認識されるように、それを変更します。私はその見積りを変更できます。確認することもできます。取引プライシングの項目を見ると、どのように設定されているかを確認できます。必要に応じて調整したり、時間の経過とともに変更されている場合はその履歴を確認したりすることも可能です。この中のウォーターフォールと収益サマリーを見ると、それが収益にどのような影響を与えたかを、今は確認できます。ウォーターフォールを見ると、毎月のVC収益がいくらかが分かります。したがって、上振れすることが分かっているため、この10万を11万5,000に調整しています。その後は超過分の精算を待ちます。これらは契約終了時にすべて整合（トゥルーアップ）されます。なお、ここまで見てきたのは単一の契約ですが、追加のレポーティングがあります。同じ消費

先ほど見ていた履歴は、私が確認できる「消費（Consumption）ウォーターフォール」です。これは、すべての契約を対象に、月ごとに私の利用状況がどうなっているか――認識（Recognition）ではなく、毎月の利用収益（Usage Revenue）がいくらか――を示してくれます。したがって、期間按分（Ratable）で収益認識しているものも、従量課金（Consumption）で収益認識しているものも、未請求利用分の未収計上（Unbilled Usage Accrual）として収益認識しているものも、すべて含まれます。つまり、その未請求利用分が入ってきたタイミングで表示され、そこに対して請求（Billing）を行ったタイミングではありません。ここまで収益側として話してきましたが、この利用状況のトラッキングは過去にさかのぼって継続されています。ただ、私はその利用状況自体を確認する必要があります。一方で請求側では、私たちが「Consumption Insights」と呼ぶ機能により、同様の内容をより上位の視点でも確認できます。つまり、私はこれを収益として見ています

私の、ええと、消費量の使用状況ウォーターフォールの側面ではあるのですが、請求側にはConsumption Insightsレポートがあり、これを使うと、よりトレンドとして把握できます。つまり、使用量――あるいはクレジット――の消化が非常に速い顧客はどこか、逆に消化が非常に遅い顧客はどこか、そして私の請求がどのようなトレンドで推移しているのかを確認できます。これにより、これまでどのように請求してきたかを把握できるだけでなく、何が起きていたのかについて予測トレンドも得られます。したがって、キャッシュフローの観点で活用できますし、顧客とやり取りする際に「これがいつ発生しますか？」と確認するためにも使えます。先ほどの前払残高と同様に、トップオフについて相談する必要があるのか、利用が進んでいるため解約リスクがあるのか——

・・・の対象となるのでしょうか？相手先は、契約の再交渉のようなものを求めてくるのでしょうか？さらに、「これが予測にどう役立つのか」という観点でも見ています。私たちがここでお伝えしたいのは、AI利用に関する運用モデルとして、柔軟でありながら再現性のある仕組みをご提供できるということです。引き継ぎを減らし、手作業での突合作業や工程を減らし、決算締めまでのリードタイムを短縮できます。利用実績が連携されてくるのを待つのではなく、請求の観点でも収益の観点でも、日々それを可視化できます。では最後の投票に移ります。えーと……あ、方向を間違えました。請求と収益をあわせて見る取り組みについて、皆さまの現在の検討・導入状況はどの段階にありますか？

ああ、そうですね。まだ確信はありません。プロセスを始めたばかりという感じです。皆さまがこちらにいらっしゃるのも、情報を得ようとしているからだと私たちは考えています。はい。情報こそが鍵であり、だからこそ私たちはこのようなウェビナーを開催しています。情報を広く共有し、私たちから皆さまへ、そして皆さま同士（同じことに取り組む同業の方々）ともつながっていただくことを目的としています。では、それを踏まえて、Q&Aに移りましょうか。

承知しました。それでは、いくつかご質問をいただいています。ええと、必要に応じて追加でご質問いただいて構いません。まず最初のご質問です。使用量（Usage）および前受（Prepaid）のドローダウン（Drawdown）仕組みは、標準で提供されるコアの製品機能（Out-of-the-box）に含まれていますか。それとも別途購入が必要な別モジュールでしょうか。もし別モジュールの場合、その価格はどのように確認できますか。結論としては、これはZuora Billingの機能です。Zuora Billing内の別モジュールという扱いではありません。したがって、Zuora Billingをご利用であれば、前受ドローダウンとUsageの機能はZuora Billingに含まれています。…そして、収益認識（Recognition）の部分はZuora Revenueの機能で、これはPOBテンプレートおよび、そのUsageを取り込める機能として、Zuora Revenueに含まれるものです。また、Zuora Revenueのみをご利用の場合でも、外部の消費（Consumption）データを取り込むことは可能です。こちらは– 同じ

ええと、テンプレートをご利用いただけます。次に2つ目のご質問です。収益認識の金額がUsageを下回る場合、VC（変動対価：Variable Consideration）は関係してきますか。通常はいいえ、というのが私たちの見立てです。このケースは、どちらかというとブレケージ（Breakage）の状況に近いです。なお、ブレケージについては、以前に私のチームメンバーのErinがウェビナーで解説しています。一般的に、前受が未消化（Usageが想定より少ない）となった場合でも、最終的には運用次第です。一定期間内で繰り越して利用できるようにするのかどうか、といった運用ですね。繰り越しを認める場合は、消費が継続していくケースが多いです。一方で、消費が下振れした場合のブレケージという考え方があります。ええと、ただしご質問の「定額按分（Ratable）で、かつ下回る」という前提であれば、認識すべき金額を適切に認識していることになるので、必ずしも「下回る」状態にはなりません…VCが関係してくるのは、クレジットを返還する想定があり、その結果として全額を認識しない、という判断をする場合です。

「SKU（エス・ケー・ユー）と価格設定は、請求スケジュール（Billing Schedule）に設定されるのですか？」というご質問ですね。請求スケジュール内です。つまり、価格設定は…プロダクトカタログがあり、そこでリスト価格や、繰り越し時に収益をどのように認識するかといったメカニズムを、ある程度定義します。そのうえで、サブスクリプション側で顧客固有のルールを設定し、その情報を価格設定に使用します。ご質問への回答になっているか不明ですが、位置づけとしてはそのようになります。つまり、プロダクトカタログをベースとして作成しつつ、Zuora Billing内で契約（Contract）やサブスクリプションを作成する際に、顧客固有の情報を設定します。たとえば、10万ドルのクレジットではなく、

前受クレジットが8万ドルになる、といった上書きが可能です。また、2対1のレートでドローダウンするのではなく、1.5対1のレートでドローダウンする、といったことも可能です。次のご質問です。デモでお見せしている内容では、RC（Revenue Contract）に開始時点の初期収益はありますか。ええと、消費（Consumption）に基づいて認識するケースでは、いいえ。すべて繰延（Deferred）に置かれます。定額按分（Ratable）で認識する場合は、一般的なSaaSや定額プロダクトと同様にスケジュールが作成され、そのうえでUsageがトラッキングされます。以上で、ご質問はすべてだったと思います。もう少しお時間を取りますので、何かご質問があれば投稿してください。あ、もう一つ投票がありますね。投票はもう一つ？ あ、はい。[笑] もう一つだけです。チームとのミーティングにご興味があるかどうか、という内容で、「はい」「もしかしたら後ほど」「いいえ、結構です」です。追加で知りたいことがあれば、

ぜひお知らせください。はい。こちらに記載のとおり、Revenue Manager（私のような担当）やCSEなど、Zuora Billingの請求側についてより詳しく知りたい場合にご支援できるメンバーがいます。アカウントチームには、皆さまの理解を支援するためのメンバーが多数います。ありがとうございます。では投票を行っている間に、もう一つご質問が入りました。現在のBillingとRevenue間のダイナミックプライシング連携は非効率で、スケーラビリティにも欠けています。レポーティング目的で、追加の属性値をRevenueへ連携できるようにする計画は、ロードマップにありますか。あると認識しています。Usageレコード自体に、さらに属性を持たせる、という意味ですよね。おそらくそのことを指しているのだと思います。Usageレコードには、たとえばリージョン等の情報を持たせられますし、それらを一部連携することも可能です。おそらく対応する想定ですが、念のため確認のうえ、回答してお戻しします。

それでは、皆さまご参加ありがとうございました。共有したいリソースがいくつかあります。前の…ええと、先ほどCathyが、AIマネタイゼーションの価格設定に関する内容に触れていましたが、QRコードを読み取るか、リソース内のリンクからアクセスできます。それから、ええと、GartnerがZuoraを継続課金（Recurring Revenue）に関する—あ、すみません、違う画面を出していました—。ええと。[笑] そちらに切り替えました。いえいえ、こちらのほうが良いですね。私が話していたのはこれです。はい、はい。こちらがQRコードです。こちらでスキャンするか、リンクをクリックしてください。Moreの中のResourcesにもあります。Cathyが先ほど申し上げたとおり、AI製品をローンチする予定がある場合は、どのように価格設計すべきか一緒に考えましょう。こちらのシミュレーターをご利用ください。いくつか質問に答えると、回答が得られます。ありがとうございます。

そして、もう一つ共有したいリソースとして、GartnerがZuoraを継続課金（Recurring Revenue）向け請求アプリケーションのリーダーに選出した、という点があります。当社は、総合的な収益認識、Usage請求、固定の継続課金、請求書発行（Invoicing）、および決済（Payment）において最高評価を獲得しています。ぜひご覧ください。ええと、とても良いレポートです。こちらも同様に、MoreのResourcesからご確認いただけます。また、ここで聞きそびれたご質問や、チャットでは質問しづらかった内容があれば、Zuoraのアカウントチームまでご連絡ください。担当者より折り返し、必ず回答いたします。それでは改めて、皆さまありがとうございました。