ユーザーガイド：Comcast Technology Solutionsの財務チームがZuora AIを業務に活用する方法

Comcast Technology Solutionsでは、Chris Skaletは財務を一から作り替えようとしたわけではありません。彼が望んだのは、請求書を1件ずつクリックして確認し続ける作業をやめることでした。Zuora AIを用いた小さく意図的な実験をいくつか重ねた結果、彼のチームは事務作業ではなく分析に時間を割けるようになり、Skaletは「財務は何になり得るのか」について新たな仮説を持つようになりました。

Skaletのアプローチは、AIを活用しつつも主導権を手放したくない財務プロフェッショナルにとって有用なモデルです。すなわち、既知の業務から着手し、ツールに具体的な指示を与え、信頼できる数値と照合して結果を検証し、最終的な本番判断は業務プロセスのオーナーである担当者が担う、という進め方です。

ChrisはZuora AIを、財務の自律的な代替というよりも、有能な同僚として位置づけています。このツールは、調査、説明、クエリ、承認済み業務の実行を支援できますが、財務担当者が文脈を提供し、成果に対する説明責任を引き続き負います。

実務的なワークフローは次のとおりです。

• Ask: 期待する事業成果と、タスクの境界条件を説明する。
• Inspect: AIが特定したデータ、ロジック、クエリ、またはレコードを確認する。
• Validate: 既知の例、信頼できる合計値、または期待される挙動と照合する。
• Decide: 結果が利用可能な状態か、改善が必要か、または先に進めるべきでないかを判断する。

以下のプロンプト例は、Chrisのワークフローを基に調整したものです。有用なプロンプトの型は、「ビジネス文脈＋具体的タスク＋範囲と期間＋期待するアウトプット＋制約または承認ステップ」です。

課題

分散したチーム体制では、セットアップ上の小さな不整合が発生しやすく、手作業では見落としにくいものです。Comcast Technology Solutionsのファイナンスチームで問題となっていたのは、アカウント種別に合致しないコミュニケーションプロファイルが設定されていたことでした。Chrisは、日常的な監査を本番データに対する広範でリスクの高い変更にしてしまうことなく、そうした例外を見つける方法を必要としていました。これはツールにとっても初めての実践的なテストでした。Zuora AIにより大きな領域を任せる前に、結果をレコード単位で全件レビューできる、範囲が限定された低リスクの問いから始めたのです。

ChrisがZuora AIで解決した方法

Chrisは、少数で内容が十分に把握できているアカウントセットを対象に、読み取り専用の比較から着手しました。Zuora AIに対して、想定される「プロファイルとアカウント種別の関係」と一致しないレコードを抽出し、理由を説明し、基礎となるデータには一切手を加えないよう依頼しました。ツールは誤ったプロファイルが紐づいたアカウントを複数提示し、チームはそれらを手作業で修正しました。小さな成果ではありましたが、より高いリスクを伴う領域を任せる前に、このツールが必要な情報を実際に“見えている”ことを確認できたのです。

プロンプト例

[期間]における[アカウントセットまたはアカウント種別]に紐づくコミュニケーションプロファイルを確認してください。各プロファイルをアカウント種別と照合し、不整合に見えるレコードのみを返してください。アカウントID、アカウント名、アカウント種別、現在のプロファイル、想定されるプロファイル、例外の理由を含む表を出力してください。いかなるレコードも変更しないでください。

実行前に検証する

• 照合が意図したアカウント種別のルールに基づいていることを確認する。
• 修正を行う前に、すべての例外を確認する。
• ユーザー権限により意図しない変更が防止されていることを確認する。
• 修正に関する監査証跡、または既存のレビュー手順を維持する。

課題

CTS の一部のお客様では、システムが請求書を生成した後、ドラフト請求書を計上（ポスト）する必要があります。広告配信では、月次の 1 サイクルだけでも数十〜数百件の請求書が発生することがあり、Chris は、締め処理のタイミングであるお客様分を約 60 件、1 件ずつクリックして計上したことを覚えています。「正直、かなり消耗しました」と彼は言います。「その時間があれば、もっと価値のあることに使えますからね。」

Chris が Zuora AI で解決した方法

Chris は Zuora AI に請求書リストを渡し、計上可能な請求書と例外（要対応）を切り分けさせた上で、自分が明示的に承認した請求書だけを計上するようにしました。何を実行するかを決める主体は変わりません。ツールは推測による意図で動くのではなく、あくまで彼の明示的な指示にのみ従って動作しました。消えたのは、手作業のクリック連打そのものと、途中で進捗を見失うリスクでした。

プロンプト例

[customer/account set] と [billing period] について、ドラフトのままで、計上の準備が整っていると思われる請求書を特定してください。請求書ID、アカウント名、請求書日付、金額、ステータス、ブロッキングとなる例外の有無を含む表を返してください。最終リストを私が明示的に承認するまで、計上またはメール送信は一切行わないでください。

リストを確認した後の追指示は、例えば次のとおりです：

上記リストのうち、承認済みの請求書IDのみを計上してください。例外がある請求書、またはドラフト以外のステータスの請求書は除外してください。顧客へのメール送信は行わないでください。計上件数、請求書ID、およびエラーがあればそれも返してください。

実行前に検証する

• 請求書リストと請求期間を確認する。
• 例外がある、または想定外のステータスのレコードを除外する。
• 当該ユーザーおよび環境で、その操作が許可されていることを確認する。
• 確認結果をレビューし、計上件数を承認済みリストと突合する。

課題

請求業務のワークフローには、時間の経過とともにビジネスルールが積み重なっていくことがあります。注文タイプの処理に誤りが生じた場合、財務担当は、未検証の変更を本番環境へ投入することなく、その挙動がどこから生じているのか、そして何を変更すれば是正できるのかを把握する必要があります。この種の問題を診断するには、従来は複数領域の専門知識を重ね合わせ、必要なときに必ずしも呼び出せない担当者を待つことを意味していました。 

ChrisがZuora AIで解決した方法

ChrisはZuora AIに対し、関連するロジックのトレース、現状の挙動の説明、そして期待される結果を得るために必要最小限の変更案の提示を依頼しました。彼はこのツールを用いてサンドボックス上で修正内容を書き換え、テストを実施し、その後、チームで承認された手順に従って検証済みの版を自ら本番環境へ移行しました。彼は依然としてビジネスルールを理解し、期待結果を定義し、何をリリースするかの最終判断も自分で行いました。「思いついたその時間内に修正できるスピードが、すべてを変えるのです」とChrisは語ります。 

プロンプト例

[tenant/environment]の[order type]において、期待される請求結果は[結果の説明]です。現状の挙動を決定しているワークフロー・ロジックをトレースしてください。返してください：1) 該当するルールまたはコード、2) 現状の挙動の説明、3) 提案する最小限の変更、4) 前提条件、5) 下流への潜在的影響。本番環境は変更しないでください。

ツールが変更案を提示した後：

提案された変更に合わせて該当ロジックを書き換えてください。変更前・変更後の挙動を示し、サンドボックス向けにポジティブ、ネガティブ、エッジケースのテストケースを提示してください。依存関係や承認ステップがあれば特定してください。本番環境へのデプロイまたは変更は行わないでください。

実行前に検証する

• 技術的変更を確認する前に、期待されるビジネス成果を定義する。
• 想定シナリオだけでなく、近接するエッジケースもテストする。
• サンドボックスの結果を既知の事例と照合する。
• 必要に応じて、適切な技術担当者またはサポートパートナーと変更内容をレビューする。
• 承認済みの手順を通した場合にのみ、本番環境へ変更を反映する。

課題

月次決算時の分析では、請求書、クレジットメモ、入金、税務レポートからそれぞれ個別に情報を取得し、結果を手作業で突合・統合する必要があることが多く、分析に着手する前の段階で時間を消費してしまいます。

ChrisがZuora AIで解決した方法

ChrisはZuora AIに、請求書、クレジットメモ、入金、税務情報を単一のクエリに統合するよう依頼しました。彼は出力結果を、チームが既に信頼している数値と照合し、差異が出た箇所を特定したうえで、正しい結果がどうあるべきかを説明し、一致するまでAIにクエリの改善を繰り返させました。盲目的に受け入れるのではなく、往復の検証を重ねた結果、出力が一致した時点で、チームは手作業の消込・突合に代わり、信頼できる単一のレポートを得られました。「チームはサマリーをダウンロードしてチェックするのではなく、分析に時間を使えています」とChrisは語ります。「そうした手作業はなくなりました。」

プロンプト例

[期間]について、[アカウント/顧客/製品]単位で請求書、クレジットメモ、入金、税務情報を統合してください。返却内容：1) 突合合計、2) 使用したレコードとフィールド、3) 未突合または重複レコード、4) 差異、5) 想定される原因。結合条件（joins）と前提（assumptions）を説明してください。いかなるデータも変更しないでください。

検証用：

この結果を、以下の信頼できる合計値と比較してください。すべての差異を特定し、想定される原因を説明し、差異がクエリロジックに起因する場合に限りクエリを修正してください。変更内容の記録を明確に残し、最終クエリを再利用可能な形式で返してください。

実行前に検証する

• 合計値を信頼できるソースレポートに突合する。
• 結合（joins）によって発生する重複レコードがないか確認する。
• クエリを拡張する前に、既知の小さなサンプルでテストする。
• クレジット、入金、税務、タイミング差異がどのように表現されているかを確認する。
• 月次決算で繰り返し利用できるよう、最終クエリと検証メモを保管・共有する。

課題

企業がプロダクト領域を追加したり顧客基盤を拡大したりすると、請求業務の複雑さが、その拡大スピードそのものを制約する要因になり得ます。CTSの広告配信事業でも、約300社の顧客を対象に、1アカウントずつ個別にオンボーディングして構築していました。これは時間のかかる手作業で、新規顧客の追加がその都度「単発の作業」になってしまっていました。

ChrisがZuora AIでどのように解決したか

Chrisは、より新しい運用モデルを説明しています。顧客リストから開始し、Zuora AIに不足データの抽出、設定の不整合の検知、例外ケースと標準ケースの切り分けを行わせます。アカウントの作成および変更は、引き続きチームの既存の権限管理とレビューを経て実施されます。AIが行うのは「抽出・提示」であり、「判断」ではありません。

プロンプト例

承認済みの顧客リスト、アカウントテンプレート、ならびに［プロダクトまたは事業部門のルール］を用いて、不足項目、設定の不整合、手動レビューが必要なレコードを特定してください。例外を種類別にグルーピングし、顧客ID、アカウント名、不足または不整合の項目、推奨される次の対応、確信度または根拠を返してください。アカウントの作成または変更は行わないでください。

実行前に検証する

• 元となるリストとアカウントテンプレートを確認する。
• 繰り返し可能な設定と例外を切り分ける。
• プロセスを拡大する前にサンプルをレビューする。
• レコードの作成または変更は権限のあるユーザーのみが実行できるようにする。
• 未解決の例外は、チームの既存の運用プロセスで追跡する。

Chrisのアプローチは慎重かつ実務的です。迅速に成果を確認したい一方で、ツールが既存の統制の範囲内で運用されることも求めています。

同じモデルを適用する際は、以下のガードレールを使用してください。

• サンドボックス環境、または小規模で内容が十分に把握できているサンプルから開始する。
• 明確な指示を用いる。 範囲、期待される結果、除外事項、ならびにツールが実行（アクション）してよいかどうかを明示します。
• 調査と実行を分離する。 変更や投稿を依頼する前に、まずは特定と説明を行うようツールに求めます。
• 信頼できるデータに照らして検証する。 既知の合計値や既知の事例は、出力をチェックするうえで不可欠です。
• ロールベースの権限を遵守する。 閲覧専用ユーザーは、常に閲覧専用のままであるべきです。
• 人間の意思決定者をプロセスに組み込む。 とりわけ、変更が請求結果に影響し得る場合は重要です。
• 最終結果を文書化する。 再現性のため、承認済みのクエリ、変更内容、または照合ロジックを保持します。

ファイナンス部門は、業務運営モデル全体を再設計しなくても着手できます。

1. 完了条件が明確な反復作業を1つ選びます。
2. チームが既に理解している少量のサンプルで検証します。
3. AIに、そのアプローチの説明と例外の洗い出しを求めます。
4. 出力を信頼できる結果と突き合わせ、指示内容を改善します。
5. 何が起き、なぜそうなったのかをチームが説明できるようになってから、適用範囲を拡大します。
6. 本番実行は、既存の権限管理とレビューの対象とします。

Chrisの経験から得られるより大きな示唆は、最良の出発点は最も野心的なタスクではないということです。ファイナンスに安全で目に見える成果をもたらし、文脈の適用、判断、ビジネスインサイトの提供といった、ファイナンスにしかできない業務により多くの余地を生むタスクこそが出発点になります。