JP2023075592A - 推定装置、推定方法、学習装置、学習方法、およびプログラム - Google Patents

Abstract

【課題】ユーザの口座残高を参照することなく、支払い方法の変更を好適に提案する推定装置、推定方法、学習装置、学習方法及びプログラムを提供する。【解決手段】ユーザの口座残高を参照することなく、支払い方法の変更を好適に提案する推定システム１において、ユーザ端末装置１０、決済情報サーバ２０、モデリング担当者端末装置３０、ファイルサーバ４０及び運用担当者端末装置５０、によって構成される。モデリング担当者端末装置３０は、クレジットカード決済サービスのユーザのうち、当月に支払い方法を一括払いからリボ払いに初めて変更する確率が高いと想定されるユーザを抽出するためのモデルを作成するモデリング担当者（モデル作成者）によって使用される端末装置であり、例えば、通信部３２と、入出力部３４と、制御部３６と、記憶部３８と、を含む。記憶部３８には、例えば、教師データ３８Ａとモデル構築／運用アプリ１００が記憶されている。【選択図】図１

Description

本発明は、推定装置、推定方法、学習装置、学習方法、およびプログラムに関する。

後払い決済サービスにおいて、口座残高の引き落とし処理を円滑に実行するための技術が知られている。例えば、特許文献１には、複数の口座の残高に応じて、引き落とし処理にかかる口座の残高が不足していた場合に、ユーザに支払い方法の変更を可能にさせる技術が開示されている。

特開２０２０－１０６８９２号公報

特許文献１に記載の技術は、ユーザの複数の口座残高を参照することによって、残高の不足を検知するものである。しかしながら、一般的に、クレジットカードなどの後払い決済サービスにおいては、サービスの管理者は、必ずしもユーザの口座残高を参照することができるとは限らない。その結果、ユーザに支払い方法の変更を好適に提案できない場合があった。

本発明は、このような事情を考慮してなされたものであり、ユーザの口座残高を参照することなく、支払い方法の変更を好適に提案することができる、推定装置、推定方法、学習装置、学習方法、およびプログラムを提供することを目的の一つとする。

本発明の一態様は、後払い決済サービスにおける少なくとも過去の所定期間にわたる決済金額の履歴に対して、前記後払い決済サービスにおける決済後に支払い方法の設定を変更したか否かを示すラベルが付与された教師データに基づいて、前記決済金額の履歴が入力されるとユーザが前記設定を変更する確率値を出力するように学習された学習済みモデルに、前記後払い決済サービスの対象ユーザの決済金額の履歴を入力することで、前記対象ユーザが前記設定を変更するか否かを推定する推定部を備える、推定装置。

本発明の一態様によれば、ユーザの口座残高を参照することなく、支払い方法の変更を好適に提案することができる。

ユーザ端末装置１０、決済情報サーバ２０、モデリング担当者端末装置３０、ファイルサーバ４０、および運用担当者端末装置５０によって構成されるシステム１の一例を示す図である。 ユーザ端末装置１０に表示させるクレジットカード利用情報の一例を示す図である。 クレジットカードの利用に係るタイムラインの一例を示す図である。 ユーザ端末装置１０に通知される支払い方法の変更の提案の一例を示す図である。 学習用決済履歴データ２４Ａおよび推定用決済履歴データ２４Ｂの構成の一例を示す図である。 教師データ３８Ａの構成の一例を示す図である。 モデル構築／運用アプリ１００の機能構成の一例を示す図である。 インターフェース提供部１１０によって提供されるインターフェース画面の一例を示す図である。 インターフェース提供部１１０によって提供される、モデリング担当者モードにおけるインターフェース画面の一例を示す図である。 インターフェース提供部１１０によって提供される、運用担当者モードにおけるインターフェース画面の一例を示す図である。 支払い方法変更推定部１４０によって推定された推定結果の一例を示す図である。 学習済みモデル更新部１６０による学習済みモデル１３０の更新タイミングの一例を説明するための図である。 学習済みモデル１３０が出力する確率値の分布に基づいて閾値Ｔｈ１を設定するための方法の一例を示す図である。 決済情報サーバ２０、モデリング担当者端末装置３０、ファイルサーバ４０、および運用担当者端末装置５０によって実行される処理の流れの一例を示す図である。 変形例に係る教師データ３８Ｂの構成の一例を示す図である。

［実施形態］
以下、図面を参照し、本発明の推定装置、推定方法、学習装置、学習方法、およびプログラムの実施形態について説明する。図１は、ユーザ端末装置１０、決済情報サーバ２０、モデリング担当者端末装置３０、ファイルサーバ４０、および運用担当者端末装置５０によって構成されるシステム１の一例を示す図である。ユーザ端末装置１０、決済情報サーバ２０、モデリング担当者端末装置３０、ファイルサーバ４０、および運用担当者端末装置５０は、互いに協働して以下で説明する処理を行う。

［ユーザ端末装置］
ユーザ端末装置１０は、クレジットカード決済サービス（「後払い決済サービス」の一例である）を利用するユーザによって使用される端末装置であり、例えば、通信部１２と、入出力部１４と、制御部１６と、記憶部１８と、を含む。記憶部１８には、例えば、クレジットカード情報アプリ１８Ａが記憶されている。

通信部１２は、無線通信機やネットワークカード等の通信インターフェースを含む。通信部１２は、決済情報サーバ２０とネットワークＮＷ１を介して互いに通信する。ネットワークＮＷ１は、インターネットやＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）、セルラー網などを含む。入出力部１４は、ユーザ端末装置１０がスマートフォンやタブレット端末である場合、例えば、表示部と操作部とが一体化されたタッチパネルを含む。ユーザ端末装置１０がパーソナルコンピュータである場合、入出力部１４は、例えば、操作ボタンやキーボードなどの入力部と、画像を表示する表示部とを含む。本実施形態において、ユーザ端末装置１０は、例えば、スマートフォンであるものとして説明する。

制御部１６は、ＣＰＵ（Central Processing Unit）などのプロセッサがクレジットカード情報アプリ１８Ａを実行することで実現される。制御部１６は、決済情報サーバ２０から、ユーザ端末装置１０のユーザがクレジットカードを利用した履歴情報を取得し、クレジットカード利用情報としてユーザ端末装置１０に表示させる。本実施形態において、クレジットカード情報アプリ１８Ａは、ユーザがクレジットカード利用情報を閲覧するためのネイティブアプリであるものとするが、Ｗｅｂブラウザであっても良い。

図２は、ユーザ端末装置１０に表示させるクレジットカード利用情報の一例を示す図である。図２において、符号Ａ１は、クレジットカードの請求金額確定日の日付と、ユーザがクレジットカード情報アプリ１８Ａを起動させた日付を表す領域を表す。ここで、クレジットカードの請求金額確定日とは、当月の支払日（例えば、２７日）における支払い金額（口座からの引き落とし金額）の確定日を意味する。ユーザは、支払い当月の請求金額確定日までに支払い方法を変更することにより、当月分の支払い金額を変更（主には減額）することができる。

ここで、支払い方法は、例えば、一括払い、分割払い、リボルビング払い（リボ払い）などを含む。一括払いとは、前月の基準日（例えば、１日）から締め日（例えば、３１日）までの期間に利用されたクレジットカードの合計決済金額を、翌月の支払日に一括で支払う方法である。分割払いとは、前月の基準日から締め日までの間に利用されたクレジットカードの合計決済金額を、返済回数（例えば、３回や６回）を決めて、当該返済回数にわたって分割して返済する方法である。リボ払いとは、前月の基準日から締め日までの間に利用されたクレジットカードの合計決済金額を、一定の返済金額を決めて、複数回（＝合計決済金額／返済金額に相当する回数）にわたって分割して返済する方法である。ユーザは、例えば、ある月にクレジットカードを用いて一括払いで商品を購入した後に、次月の請求金額確定日までに支払い方法を一括払いからリボ払いに変更することによって、次月の支払い金額を減額することができる。

符号Ａ２は、クレジットカードの利用に伴う当月分の請求金額を表す領域を表す。ユーザが、請求金額確定日までに、支払い方法を、例えば、一括払いからリボ払いに変更した場合、当該変更に伴う当月分の支払い金額の減額分は請求金額から減算され、領域Ａ２の表示に反映される。符号Ａ３は、前月のクレジットカードの利用明細を表す情報であり、換言すると、当月分の支払い金額の内訳を表す情報である。図２では、一例として、利用明細は、月日と決済金額に関する情報を含むが、利用明細は、さらに、例えば、利用店舗や購入商品の名称などの情報を含んでもよい。符号Ｂ１は、当月分の請求金額の支払い方法を一括払いからリボ払いに変更するためのボタンを表す。ユーザは、請求金額確定日までにボタンＢ１を押下して、毎月の返済金額を指定することによって、支払い方法を変更することができる。

図３は、クレジットカードの利用に係るタイムラインの一例を示す図である。図３に示す通り、ユーザは、まず前月の基準日（例えば、１日）から締め日（例えば、３１日）までの期間にクレジットカードを利用する。この期間に利用されたクレジットカードの合計決済金額は、当月の１日時点において、当月分の請求金額として仮決定され、図２の領域Ａ２に表示される。ユーザは、クレジットカード情報アプリ１８Ａを用いて、領域Ａ２に表示される当月分の請求金額を確認し、例えば、２０日までに、支払い方法を一括払いからリボ払いに変更するか否かを決定する。２０日までに支払い方法を一括払いからリボ払いに変更した場合、仮決定された当月分の請求金額から、リボ払いへの変更に伴う支払い金額の減額分が減算され、当月分の請求金額として確定される。確定された請求金額は、例えば、２７日に、クレジットカードに紐づくユーザの銀行口座から引き落とされる。

このように、ユーザは、例えば、１日から２０日までの支払い方法変更可能期間において、自身が保有する銀行口座の残高状況に応じて、支払い方法を変更するものである。しかしながら、ユーザは、必ずしも、銀行口座の残高状況や当月分の請求金額を正確に把握しているとは限らない。その結果、銀行口座の残高が当月の引き落とし金額を下回ることによって、引き落とし処理が失敗することがあり得る。

上記の事情を背景にして、後述する運用担当者端末装置５０で実行されるモデル構築／運用アプリ１００は、ユーザの推定用決済履歴データ２４Ｂに基づいて、クレジットカード決済サービスのユーザのうち、当月に支払い方法を一括払いからリボ払いに初めて変更する確率が高いと想定されるユーザを抽出し、決済情報サーバ２０は、例えば、支払い方法変更可能期間における所定日（例えば、１５日）に、抽出されたユーザに対して、支払い方法の変更を提案する通知を送信する。これにより、ユーザは、支払い方法変更可能期間において、自身が保有する銀行口座の残高状況に応じて、支払い方法をより確実に変更することができる。

図４は、ユーザ端末装置１０に通知される支払い方法の変更の提案の一例を示す図である。図４に示す通り、例えば、ユーザがクレジットカード情報アプリ１８Ａを起動させると、決済情報サーバ２０は、起動直後に、支払い方法の変更を提案するメッセージボックスＡ４をユーザ端末装置１０に表示させる。また、例えば、決済情報サーバ２０は、ユーザ端末装置１０にプッシュ通知を送信することによって支払い方法の変更を提案してもよいし、クレジットカード情報アプリ１８Ａに登録されたメールアドレスに支払い方法の変更を提案するメールを送信してもよい。

なお、上記の図２から図４において説明したクレジットカードに係る期日（クレジット利用期間、支払い方法変更可能期間、当月分の請求金額の仮決定日、支払い方法の変更提案日、リボ払い変更可能期限日、当月分の請求金額の確定日、当月分の請求金額の支払い日）の決め方はクレジットカード会社によって如何様にも変更可能であり、本発明の適用上、リボ払い変更可能期間が存在すればよく、その他に特段の制限は存在しない。

［決済情報サーバ］
決済情報サーバ２０は、ユーザによるクレジットカードの決済情報を管理するサーバ装置であり、例えば、通信部２２と、記憶部２４とを含む。通信部２２は、無線通信機やネットワークカード等の通信インターフェースを含む。通信部２２は、ユーザ端末装置１０とネットワークＮＷ１を介して互いに通信するとともに、モデリング担当者端末装置３０および運用担当者端末装置５０とネットワークＮＷ２を介して通信する。ネットワークＮＷ２は、有線又は無線の内部ネットワークである。

記憶部２４は、学習用決済履歴データ２４Ａおよび推定用決済履歴データ２４Ｂを記憶する。図５は、学習用決済履歴データ２４Ａおよび推定用決済履歴データ２４Ｂの構成の一例を示す図である。学習用決済履歴データ２４Ａは、クレジットカードのユーザごとに生成および記憶されるデータであり、例えば、年月に対して、合計決済金額などの情報が対応付けられるものである。合計決済金額は、対応する年月においてクレジットカードが利用された決済金額の合計を示す情報である。本実施形態において、学習用決済履歴データ２４Ａは、支払い方法の変更有無が確定している最終月（すなわち、図５では２０２１年９月）以前の月において、一括払いからリボ払いに支払い方法を変更しなかったユーザについて生成されるものとする。決済情報サーバ２０は、モデリング担当者端末装置３０の要求に応じて、学習用決済履歴データ２４Ａをモデリング担当者端末装置３０にネットワークＮＷ２を介して送信する。

推定用決済履歴データ２４Ｂは、クレジットカードのユーザごとに生成および記憶されるデータであり、例えば、年月に対して、合計決済金額などの情報が対応付けられるものである。学習用決済履歴データ２４Ａとは異なり、推定用決済履歴データ２４Ｂは、支払い方法の変更が可能である最終月（すなわち、図９では２０２１年１０月）の決済履歴データを含むものである。推定用決済履歴データ２４Ｂが、最終月以前の月において、一括払いからリボ払いに支払い方法を変更しなかったユーザについて生成される点は、学習用決済履歴データ２４Ａと同様である。決済情報サーバ２０は、運用担当者端末装置５０の要求に応じて、推定用決済履歴データ２４Ｂをモデリング担当者端末装置３０にネットワークＮＷ２を介して送信する。

なお、図５においては、一例として、学習用決済履歴データ２４Ａおよび推定用決済履歴データ２４Ｂは、合計決済金額に関する情報を６ヶ月分、記録しているが、本発明はそのような構成に限定されず、少なくとも２ヶ月分以上の年月に相当する学習用決済履歴データ２４Ａおよび推定用決済履歴データ２４Ｂが記録されればよい。

［モデリング担当者端末装置］
モデリング担当者端末装置３０は、クレジットカード決済サービスのユーザのうち、当月に支払い方法を一括払いからリボ払いに初めて変更する確率が高いと想定されるユーザを抽出するためのモデルを作成するモデリング担当者（モデル作成者）によって使用される端末装置であり、例えば、通信部３２と、入出力部３４と、制御部３６と、記憶部３８と、を含む。記憶部３８には、例えば、教師データ３８Ａとモデル構築／運用アプリ１００が記憶されている。

通信部３２は、無線通信機やネットワークカード等の通信インターフェースを含む。通信部３２は、決済情報サーバ２０又はファイルサーバ４０とネットワークＮＷ２を介して互いに通信する。入出力部１４は、モデリング担当者端末装置３０がスマートフォンやタブレット端末である場合、例えば、表示部と操作部とが一体化されたタッチパネルを含む。モデリング担当者端末装置３０がパーソナルコンピュータである場合、入出力部１４は、例えば、操作ボタンやキーボードなどの入力部と、画像を表示する表示部とを含む。本実施形態において、モデリング担当者端末装置３０は、例えば、パーソナルコンピュータであるものとして説明する。

制御部３６は、ＣＰＵ（Central Processing Unit）などのプロセッサがモデル構築／運用アプリ１００を実行することで実現される。制御部３６は、決済情報サーバ２０から、各ユーザの学習用決済履歴データ２４Ａを取得するとともに、当該ユーザが、学習用決済履歴データ２４Ａの記録対象の最終月（すなわち、図５では２０２１年９月）の合計決済金額について、支払い方法を一括払いからリボ払いに初めて変更したか否かを示すラベル情報を取得する。この場合の「初めて」とは、学習用決済履歴データ２４Ａが記録対象とする合計決済金額の支払いについて、支払い方法を一括払いからリボ払いに初めて変更することを意味する。制御部３６は、取得した学習用決済履歴データ２４Ａとラベル情報とに基づいて、教師データ３８Ａを生成する。

図６は、教師データ３８Ａの構成の一例を示す図である。図６に示す通り、教師データ３８Ａは、例えば、ユーザごとの学習用決済履歴データ２４Ａと、当該ユーザが学習用決済履歴データ２４Ａの記録対象の最終月の合計決済金額について、支払い方法を一括払いからリボ払いに初めて変更したか否かを示すラベル情報とが対応付けられたものである。ユーザが学習用決済履歴データ２４Ａの記録対象の最終月の合計決済金額について、支払い方法を一括払いからリボ払いに初めて変更した場合、学習用決済履歴データ２４Ａには１がラベル付けされる一方、ユーザが学習用決済履歴データ２４Ａの記録対象の最終月の合計決済金額について、支払い方法を一括払いからリボ払いに初めて変更しなかった場合、学習用決済履歴データ２４Ａには０がラベル付けされる。

モデル構築／運用アプリ１００は、教師データ３８Ａを、例えば、再帰型ニューラルネットワーク（recurrent neural network）を用いて学習することによって、合計決済金額の履歴が入力されると、ユーザが一括払いからリボ払いに支払い方法を初めて変更する確率値を出力するような学習済みモデルを生成する。すなわち、１がラベル付けされた教師データ３８Ａのレコードは学習の正例として機能し、０がラベル付けされた教師データ３８Ａのレコードは、学習の負例として機能する。

図７は、モデル構築／運用アプリ１００の機能構成の一例を示す図である。モデル構築／運用アプリ１００は、例えば、プログラムの機能構成として、インターフェース提供部１１０と、モデル生成部１２０と、学習済みモデル１３０と、支払い方法変更推定部１４０と、支払い方法変更提案部１５０と、学習済みモデル更新部１６０と、を含む。

インターフェース提供部１１０は、モデリング担当者端末装置３０又は運用担当者端末装置５０に、モデル構築／運用アプリ１００を利用するためのインターフェース画面を提供する。図８は、インターフェース提供部１１０によって提供されるインターフェース画面の一例を示す図である。

図８において、符号Ａ４は、モデル構築／運用アプリ１００にログインするためのログインＩＤおよびパスワードを入力するための領域を表す。符号Ａ５は、モデル構築／運用アプリ１００の実行モードを指定するための領域を表す。モデル構築／運用アプリ１００の実行モードは、例えば、モデリング担当者モードと運用担当者モードとを含む。モデリング担当者モードは、モデリング担当者端末装置３０の使用者であるモデリング担当者が、クレジットカード決済サービスのユーザのうち、当月に支払い方法を一括払いからリボ払いに初めて変更する確率が高いと想定されるユーザを抽出するためのモデルを作成するためのモードである。運用担当者モードは、運用担当者端末装置５０の使用者である運用担当者が、作成されたモデルに、推定用決済履歴データ２４Ｂを入力することによって、当月に支払い方法を一括払いからリボ払いに初めて変更する確率が高いと想定されるユーザを抽出するためのモードである。符号Ｂ１は、モデリング担当者モード又は運用担当者モードのいずれかのモードにおいてモデル構築／運用アプリ１００にログインするためのログインボタンを表す。

図９は、インターフェース提供部１１０によって提供される、モデリング担当者モードにおけるインターフェース画面の一例を示す図である。図９のインターフェース画面は、例えば、モデル構築／運用アプリ１００の利用者が、図８のインターフェース画面上でモデリング担当者モードを指定してログインすることによって表示されるものである。

図９において、符号Ａ６は、モデル構築／運用アプリ１００の利用者がモデリング担当者モードでモデル構築／運用アプリ１００にログインしたことを示す情報を表す。符号Ａ７は、モデルを学習するための期間を指定するための領域を表す。図９では、一例として、６ヶ月分の合計決済金額が記録されている教師データ３８Ａに合わせて、学習期間が６ヶ月に指定されている例を表しているが、本発明はそのような構成に限定されず、教師データ３８Ａが記録する合計決済金額の期間に合わせて、任意の期間が学習期間として指定されてもよい。

符号Ｂ２は、領域Ａ７で指定された学習期間に基づいて学習を実行するためのボタンを表す。より具体的には、ボタンＢ２が押下されると、モデル生成部１２０は、指定された学習期間に相当する教師データ３８Ａに基づいて、合計決済金額の履歴が入力されると、ユーザが一括払いからリボ払いに支払い方法を初めて変更する確率値を出力するような学習済みモデル１３０を生成する。生成された学習済みモデル１３０は、モデル構築／運用アプリ１００に同梱され、モデリング担当者によって手動で、又はスクリプト処理によって自動でファイルサーバ４０の記憶部４４にアップロードされる。

［ファイルサーバ］
ファイルサーバ４０は、モデリング担当者によって作成された学習済みモデル１３０を同梱するモデル構築／運用アプリ１００を管理するサーバ装置であり、例えば、通信部４２と、記憶部４４とを含む。通信部４２は、無線通信機やネットワークカード等の通信インターフェースを含む。通信部４２は、モデリング担当者端末装置３０および運用担当者端末装置５０とネットワークＮＷ２を介して通信する。

記憶部４４は、モデリング担当者によってアップロードされたモデル構築／運用アプリ１００を格納し、ファイルサーバ４０は、運用担当者端末装置５０のダウンロード要求に応じて、記憶部４４に格納されたモデル構築／運用アプリ１００を運用担当者端末装置５０に送信する。

［運用担当者端末装置］
運用担当者端末装置５０は、クレジットカード決済サービスのユーザのうち、当月に支払い方法を一括払いからリボ払いに初めて変更する確率が高いと想定されるユーザを抽出し、抽出したユーザに対してリボ払いへの変更を提案する運用担当者によって使用される端末装置であり、例えば、通信部５２と、入出力部５４と、制御部５６と、記憶部５８と、を含む。記憶部５８には、例えば、モデル構築／運用アプリ１００が記憶されている。

通信部５２は、無線通信機やネットワークカード等の通信インターフェースを含む。通信部５２は、決済情報サーバ２０又はファイルサーバ４０とネットワークＮＷ２を介して互いに通信する。入出力部５４は、運用担当者端末装置５０がスマートフォンやタブレット端末である場合、例えば、表示部と操作部とが一体化されたタッチパネルを含む。運用担当者端末装置５０がパーソナルコンピュータである場合、入出力部５４は、例えば、操作ボタンやキーボードなどの入力部と、画像を表示する表示部とを含む。本実施形態において、運用担当者端末装置５０は、例えば、パーソナルコンピュータであるものとして説明する。

制御部５６は、ＣＰＵ（Central Processing Unit）などのプロセッサがモデル構築／運用アプリ１００を実行することで実現される。制御部５６は、ファイルサーバ４０から、モデリング担当者によって作成された最新の学習済みモデル１３０を同梱するモデル構築／運用アプリ１００をダウンロードし、記憶部５８に格納する。制御部５６は、さらに、決済情報サーバ２０から、推定用決済履歴データ２４Ｂをダウンロードし、学習済みモデル１３０に入力することによって、クレジットカード決済サービスのユーザのうち、当月に支払い方法を一括払いからリボ払いに初めて変更する確率が高いと想定されるユーザを抽出する。

図１０は、インターフェース提供部１１０によって提供される、運用担当者モードにおけるインターフェース画面の一例を示す図である。図１０のインターフェース画面は、例えば、モデル構築／運用アプリ１００の利用者が、図８のインターフェース画面上で運用担当者モードを指定してログインすることによって表示されるものである。

符号Ａ８は、モデル構築／運用アプリ１００の利用者が運用担当者モードでモデル構築／運用アプリ１００にログインしたことを示す情報を表す。符号Ａ９は、支払い方法を一括払いからリボ払いに初めて変更するユーザを推定する対象年月を指定するための領域を表す。符号Ａ１０は、クレジットカード決済サービスのユーザのうち、当月に支払い方法を一括払いからリボ払いに初めて変更する確率が高いと想定されるユーザを抽出する閾値Ｔｈ１を調整するためのパラメータを指定するための領域を表す。すなわち、あるユーザの合計決済金額の履歴の入力に対して、学習済みモデル１３０によって出力された確率値が閾値Ｔｈ１以上であるとき、当該ユーザは、当月に支払い方法を一括払いからリボ払いに初めて変更する確率が高いと推定される。閾値Ｔｈ１は、「第１閾値」の一例である。

閾値Ｔｈ１の調整パラメータは、例えば、ＧＤＰ成長率、インフレ率、失業率などのパラメータを含む。モデル構築／運用アプリ１００は、例えば、ＧＤＰ成長率が高ければ高いほど、Ｔｈ１が高くなる傾向で設定し、インフレ率が高ければ高いほど、Ｔｈ１が低くなる傾向で設定し、失業率が高ければ高いほど、Ｔｈ１が低くなる傾向で設定する。図１０では、一例として、ＧＤＰ成長率、インフレ率、失業率などのパラメータを設定する例を表しているが、本発明はそのような構成に限定されず、一般的に、クレジットカードのユーザの経済状況に関係する任意の指標が設定されればよい。これにより、社会の経済状況に応じて、支払い方法を変更するユーザを柔軟に推定することができる。

符号Ｂ３は、領域Ａ９で指定された対象年月に基づいて推定を実行するためのボタンを表す。より具体的には、ボタンＢ３が押下されると、支払い方法変更推定部１４０は、決済情報サーバ２０からダウンロードした推定用決済履歴データ２４Ｂを学習済みモデル１３０に入力し、出力された確率値がＴｈ１以上であるユーザを、支払い方法を一括払いからリボ払いに初めて変更するユーザとして推定する。インターフェース提供部１１０は、推定結果を運用担当者端末装置５０に表示させる。

図１１は、支払い方法変更推定部１４０によって推定された推定結果の一例を示す図である。図１１に示す通り、インターフェース提供部１１０は、運用担当者端末装置５０の画面に、支払い方法変更推定部１４０によって支払い方法を変更すると推定されたユーザＩＤの件数を出力する。インターフェース提供部１１０は、さらに、例えば、支払い方法を変更すると推定されたユーザＩＤのリストを出力するためのボタンＢ４や、支払い方法を変更すると推定されたユーザＩＤのユーザに対して支払い方法の変更を提案するためのボタンＢ５を表示させてもよい。ボタンＢ５が押下された場合、支払い方法変更提案部１５０は、支払い方法の変更を提案するメッセージをユーザ端末装置１０に決済情報サーバ２０を介して送信させてもよい。その場合、図４に示す通り、クレジットカード情報アプリ１８Ａ上に、支払い方法の変更を提案するメッセージボックスＡ４を表示させてもよい。

［学習済みモデルの更新］
モデリング担当者によって作成された学習済みモデル１３０は、例えば、毎月、最新の教師データ３８Ａに基づいて定期的に更新されてもよいし、学習済みモデル１３０による推定精度の劣化に応じて、不定期に更新されてもよい。例えば、決済情報サーバ２０は、支払い方法変更提案部１５０によって支払い方法の変更が提案されたユーザのうち、実際に支払い方法を変更したユーザの割合（コンバージョン率：ＣＶＲ）を計測し、学習済みモデル更新部１６０は、決済情報サーバ２０によって計測されたＣＶＲが閾値Ｔｈ２未満になった場合に、モデル生成部１２０に、最新の教師データ３８Ａに基づいて、学習済みモデル１３０を再生成させてもよい。閾値Ｔｈ２は、「第２閾値」の一例である。

図１２は、学習済みモデル更新部１６０による学習済みモデル１３０の更新タイミングの一例を説明するための図である。図１２は、図６に示される２０２１年９月までの範囲の教師データ３８Ａに基づいて生成された学習済みモデル１３０の精度を表す。図１２に示す通り、２０２１年９月までの範囲の教師データ３８Ａに基づいて生成された学習済みモデル１３０のＣＶＲは、一般的に、時間が経過するにつれて、低下していくことが想定される。そのため、学習済みモデル更新部１６０は、ＣＶＲが閾値Ｔｈ２未満であると判断した場合、モデル生成部１２０に、最新の教師データ３８Ａに基づいて、学習済みモデル１３０を再生成させる。例えば、図１２の場合、２０２２年２月において学習済みモデル１３０のＣＶＲが閾値Ｔｈ２未満であると判断された場合、学習済みモデル更新部１６０は、モデル生成部１２０に、２０２２年１月までの範囲の教師データ３８Ａに基づいて学習済みモデル１３０を再生成させ、２０２２年３月の予測に用いる。

［学習済みモデル１３０ごとの乖離の調整］
上記で説明した通り、学習済みモデル１３０は、例えば、６ヶ月などの所定期間にわたる教師データ３８Ａに基づいて生成されるものであり、教師データ３８Ａの範囲を異なる期間に更新することによって、異なる学習済みモデル１３０が生成されるものである。その場合、学習済みモデル１３０ごとのスケールに乖離が発生することがあり得る。例えば、推定用決済履歴データ２４Ｂの入力に対して、ある学習済みモデル１３０が出力した最大の確率値が０．９である一方、別の学習済みモデル１３０が出力した最大の確率値が０．８である場合、前者の学習済みモデル１３０は、後者の学習済みモデル１３０に比して、過大な値を出力する傾向があり得る。そのため、支払い方法の変更を推定するための閾値Ｔｈ１を一定の値に設定した場合、モデルによっては、閾値Ｔｈ１の値が過大（または過少）であることがあり得る。

上記の事情を背景にして、閾値Ｔｈ１は、学習済みモデル１３０が出力する確率値の分布に基づいて設定されてもよい。図１３は、学習済みモデル１３０が出力する確率値の分布に基づいて閾値Ｔｈ１を設定するための方法の一例を示す図である。図１３は、推定用決済履歴データ２４Ｂの入力に対して、ある学習済みモデル１３０が出力した確率値の分布を表す。図１３に示す通り、閾値Ｔｈ１は、例えば、確率値の分布の平均ａｖｅ＋標準偏差σなどの値に設定されてもよい。これにより、学習済みモデル１３０ごとのスケールの乖離を吸収して、支払い方法を変更するユーザを推定することができる。

また、代替的に、閾値Ｔｈ１の値ではなく、確率値そのものを調整することによって、学習済みモデル１３０ごとのスケールの乖離を調整してもよい。より具体的には、学習済みモデル１３０によって出力された複数の確率値の平均値を、当該複数の確率値の各々から減算し、減算によって得られた値を標準偏差で除算した値と、一定値である閾値Ｔｈ１とを比較してもよい。このようにしても、学習済みモデル１３０ごとのスケールの乖離を吸収して、支払い方法を変更するユーザを推定することができる。

［処理の流れ］
次に、図１４を参照して、決済情報サーバ２０、モデリング担当者端末装置３０、ファイルサーバ４０、および運用担当者端末装置５０によって実行される処理の流れについて説明する。図１４は、決済情報サーバ２０、モデリング担当者端末装置３０、ファイルサーバ４０、および運用担当者端末装置５０によって実行される処理の流れの一例を示すタイミングチャートである。

まず、決済情報サーバ２０は、学習用決済履歴データ２４Ａと、ユーザが学習用決済履歴データ２４Ａの記録対象の最終月の合計決済金額について、支払い方法を一括払いからリボ払いに初めて変更したか否かを示すラベル情報と、をモデリング担当者端末装置３０に送信する（ステップＳ１０）。モデリング担当者端末装置３０は、受信した学習用決済履歴データ２４Ａとラベル情報とに基づいて、教師データ３８Ａを生成する（ステップＳ２０）。

次に、モデリング担当者端末装置３０は、モデル構築／運用アプリ１００を用いて、教師データ３８Ａを学習することにより学習済みモデル１３０を生成する。モデリング担当者端末装置３０は、生成された学習済みモデル１３０をモデル構築／運用アプリ１００に同梱し、ファイルサーバ４０にアップロードする（ステップＳ４０）。次に、ファイルサーバ４０は、モデリング担当者端末装置３０によってアップロードされた学習済みモデル１３０を記憶部４４に保存する（ステップＳ５０）。

次に、運用担当者端末装置５０は、ファイルサーバ４０から、モデル構築／運用アプリ１００をダウンロードするとともに（ステップＳ６０）、決済情報サーバ２０から、推定用決済履歴データ２４Ｂをダウンロードする（ステップＳ７０）。運用担当者端末装置５０は、モデル構築／運用アプリ１００に同梱された学習済みモデル１３０に推定用決済履歴データ２４Ｂを入力することによって、当月に一括払いからリボ払いに支払い方法を初めて変更すると推定されるユーザを抽出する（ステップＳ８０）。

次に、運用担当者端末装置５０は、運用担当者によるモデル構築／運用アプリ１００の操作に応じて、支払い方法の変更を提案するメッセージをユーザ端末装置１０に送信するよう決済情報サーバ２０に依頼する（ステップＳ９０）。次に、決済情報サーバ２０は、ユーザ端末装置１０に、一括払いからリボ払いへの支払い方法の変更を提案し、提案に応じて支払い方法が変更されたか否かのＣＶＲを計測する（ステップＳ１００）。

次に、決済情報サーバ２０は、計測したＣＶＲを運用担当者端末装置５０に通知する（ステップＳ１１０）。運用担当者端末装置５０は、計測されたＣＶＲが閾値Ｔｈ２未満であると判定した場合、モデリング担当者端末装置３０にモデルの更新を依頼する（ステップＳ１２０）。このときの依頼は、運用担当者端末装置５０の使用者である運用担当者によって手動で実行されてもよいし、スクリプト処理などによって自動で実行されてもよい。さらに、モデルの更新は、モデリング担当者端末装置３０の使用者であるモデリング担当者によって手動で実行されてもよいし、スクリプト処理などによって自動で実行されてもよい。これにより、本タイミングチャートの処理が終了する。

なお、上記の実施形態では、教師データ３８Ａは、過去の所定期間にわたる決済履歴データに対して、当該決済履歴データの最終月の合計決済金額について、支払い方法を一括払いからリボ払いに初めて変更したか否かを示すラベル情報を対応付けた情報として、設定されている。しかし、本発明は、そのような構成に限定されず、教師データ３８Ａは、決済履歴データと、当該決済履歴データに係るユーザの年齢および性別の少なくとも一方と、を少なくとも含む組み合わせに対して上記ラベル情報を対応付けた情報として、設定されてもよい。これにより、より多くのパラメータを考慮した学習済みモデルを生成することができる。

さらに、上記の実施形態では、教師データ３８Ａは、一例として、支払い方法の変更有無が確定している最終月を含む直近６ヶ月の決済履歴データを含むものであり、推定の対象となる月ごとの傾向を考慮していない。しかし、本発明は、そのような構成に限定されず、例えば、直近１２ヶ月や２４ヵ月の決済履歴データに対して、ユーザが一括払いからリボ払いに支払い方法を変更したか否かを示すラベル情報を対応付けた情報を教師データ３８Ａとして設定してもよい。また、例えば、教師データ３８Ａは、特徴量として、推定の対象となる月を含んでもよい。これにより、月ごとの傾向を考慮した学習済みモデルを生成することができる。

さらに、上記の実施形態では、一例として、クレジットカードの一括払いからリボ払いに支払い方法を初めて変更するユーザを推定する場合について説明した。しかし、本発明はそのような構成に限定されず、例えば、一括払いから分割払いに支払い方法を変更するユーザを推定するなど、他の変更形式についても、同様に適用することができる。さらに、本発明はクレジットカードの支払い方法の変更に限定されず、例えば、電子決済アプリの支払い方法の変更にも同様に適用することができる。本発明を電子決済アプリに適用する場合、例えば、商品をあと払いで決済したユーザが、あと払い金額の清算（電子決済アプリのチャージ残高からの引き落とし）を、一括清算から分割清算に変更することを予測することなどが考えられる。

上記の実施形態によれば、過去の所定期間にわたる決済履歴データと、当該決済履歴データの最終月の合計決済金額について、支払い方法を一括払いからリボ払いに初めて変更したか否かを示すラベル情報とを対応付けた教師データを学習することによって学習済みモデルを生成し、生成した学習済みモデルに、当月の支払い方法の変更に係る決済履歴データを入力することによって、当月に支払い方法を一括払いからリボ払いに初めて変更するユーザを推定する。これにより、ユーザの口座残高を参照することなく、支払い方法の変更を好適に提案することができる。

さらに、上記の実施形態によれば、モデル構築／運用アプリ１００が、直接、決済情報サーバ２０にアクセスし、推定用決済履歴データ２４Ｂを取得するため、推定用決済履歴データ２４Ｂを提供する専用のＷｅｂサーバを導入する必要がなく、運用の手間を軽減することができる。さらに、上記の実施形態によれば、モデル構築／運用アプリ１００自体が、学習用決済履歴データ２４Ａと推定用決済履歴データ２４Ｂの取得機能を有するため、モデリング担当者にとって、モデルの更新に係る作業負荷を軽減することができる。

［変形例］
上記の実施形態では、教師データ３８Ａとして、合計決済金額の月ごとの推移が記録されている。しかし、本発明は、そのような構成に限定されず、教師データ３８Ａとして、合計決済金額の変化量（より具体的には、前月の合計決済金額と当月の合計決済金額との間の差分）の推移が記録されてもよい。これは、一般的に、あるユーザの合計決済金額の変化量の推移と、当該ユーザが支払い方法を一括払いからリボ払いに初めて変更する確率との間には相関関係があるとする本発明者らの知見に基づくものである。例えば、あるユーザの合計決済金額の前月からの変化量が、過去の所定期間（例えば、６ヶ月）にわたる変化量の移動平均から著しく（例えば、２σ以上）増加している場合、当該ユーザが、支払い方法を一括払いからリボ払いに変更する確率が高くなる事象が観察されている。このような相関関係は、上記の実施形態のように、合計決済金額の推移を教師データとして用いても学習済みモデルに反映させることができるが、合計決済金額の変化量の推移を教師データとして用いることによって、より直接的に学習済みモデルに反映させることができる。

図１５は、変形例に係る教師データ３８Ｂの構成の一例を示す図である。図１５に示す通り、教師データ３８Ｂは、例えば、あるユーザの前月を基準とする合計決済金額の変化量の推移に対して、当該ユーザが教師データ３８Ｂの記録対象の最終月の合計決済金額について、支払い方法を一括払いからリボ払いに初めて変更したか否かを示すラベル情報が対応付けられたものである。ユーザが支払い方法を一括払いからリボ払いに初めて変更した場合、教師データ３８Ｂには１がラベル付けされる一方、ユーザが支払い方法を一括払いからリボ払いに初めて変更しなかった場合、教師データ３８Ｂには０がラベル付けされる。

モデル構築／運用アプリ１００は、教師データ３８Ｂを、例えば、再帰型ニューラルネットワーク（recurrent neural network）を用いて学習することによって、合計決済金額の変化量の推移が入力されると、ユーザが一括払いからリボ払いに支払い方法を初めて変更する確率値を出力するような学習済みモデルを生成する。その他の構成については、上記の実施形態と同様である。

以上、本発明を実施するための形態について実施形態を用いて説明したが、本発明はこうした実施形態に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。

１０ ユーザ端末装置
１２、２２、３２、４２、５２ 通信部
１４、３４、５４ 入出力部
１６、３６、５６ 制御部
１８、２４、３８、４４、５８ 記憶部
１８Ａ クレジットカード情報アプリ
２０ 決済情報サーバ
２４Ａ 学習用決済履歴データ
２４Ｂ 推定用決済履歴データ
３０ モデリング担当者端末装置
３８Ａ 教師データ
４０ ファイルサーバ
５０ 運用担当者端末装置
１００ モデル構築／運用アプリ
１１０ インターフェース提供部
１２０ モデル生成部
１３０ 学習済みモデル
１４０ 支払い方法変更推定部
１５０ 支払い方法変更提案部
１６０ 学習済みモデル更新部

Claims (15)

1. 後払い決済サービスにおける少なくとも過去の所定期間にわたる決済金額の履歴に対して、前記後払い決済サービスにおける決済後に支払い方法の設定を変更したか否かを示すラベルが付与された教師データに基づいて、前記決済金額の履歴が入力されるとユーザが前記設定を変更する確率値を出力するように学習された学習済みモデルに、前記後払い決済サービスの対象ユーザの決済金額の履歴を入力することで、前記対象ユーザが前記設定を変更するか否かを推定する推定部を備える、
   推定装置。
2. 前記決済金額の履歴は、前記所定期間にわたる前記決済金額の推移を示す情報である、
   請求項１に記載の推定装置。
3. 前記決済金額の履歴は、前記所定期間にわたる前記決済金額の変化量の推移を示す情報である、
   請求項１に記載の推定装置。
4. 前記学習済みモデルは、前記決済金額の履歴と、前記ユーザの年齢および性別の少なくとも一方と、を少なくとも含む組み合わせに対して前記ラベルが付与された教師データに基づいて学習されたものである、
   請求項１から３のいずれか１項に記載の推定装置。
5. 前記学習済みモデルは、前記決済金額の履歴と、前記推定を行う対象となる月と、を少なくとも含む組み合わせに対して前記ラベルが付与された教師データに基づいて学習されたものである、
   請求項１から４のいずれか１項に記載の推定装置。
6. 前記推定部は、前記確率値が第１閾値以上である場合に、前記対象ユーザが前記設定を変更すると推定し、
   前記推定部は、社会の経済状況を表す指標値を考慮して、前記第１閾値を決定する、
   請求項１から５のいずれか１項に記載の推定装置。
7. 前記推定部は、前記確率値が第１閾値以上である場合に、前記対象ユーザが前記設定を変更すると推定し、
   前記推定部は、複数の前記所定期間の各々について生成された学習済みモデルによって出力された確率値の分布に基づいて、前記第１閾値を決定する、
   請求項１から６のいずれか１項に記載の推定装置。
8. 前記推定部は、前記所定期間について生成された学習済みモデルによって出力された複数の確率値の平均値を、前記複数の確率値の各々から減算し、減算によって得られた値を前記複数の確率値の標準偏差で除算した値が第１閾値以上である場合に、前記対象ユーザが前記設定を変更すると推定する、
   請求項１から７のいずれか１項に記載の推定装置。
9. 前記推定部によって前記設定を変更すると推定された対象ユーザに対して、前記設定を変更するように前記対象ユーザの端末装置に提案する提案部を更に備える、
   請求項１から８のいずれか１項に記載の推定装置。
10. 前記提案部による提案に応じて、前記設定を変更した対象ユーザの多さを示す指標値を算出し、
    前記指標値が第２閾値未満である場合には、前記所定期間を変更して前記学習を再度行うことにより前記学習済みモデルを更新する更新部をさらに備える、
    請求項９に記載の推定装置。
11. コンピュータが、
    後払い決済サービスにおける少なくとも過去の所定期間にわたる決済金額の履歴に対して、前記後払い決済サービスにおける決済後に支払い方法の設定を変更したか否かを示すラベルが付与された教師データに基づいて、前記決済金額の履歴が入力されるとユーザが前記設定を変更する確率値を出力するように学習された学習済みモデルに、前記後払い決済サービスの対象ユーザの決済金額の履歴を入力することで、前記対象ユーザが前記設定を変更するか否かを推定する、
    推定方法。
12. コンピュータに、
    後払い決済サービスにおける少なくとも過去の所定期間にわたる決済金額の履歴に対して、前記後払い決済サービスにおける決済後に支払い方法の設定を変更したか否かを示すラベルが付与された教師データに基づいて、前記決済金額の履歴が入力されるとユーザが前記設定を変更する確率値を出力するように学習された学習済みモデルに、前記後払い決済サービスの対象ユーザの決済金額の履歴を入力することで、前記対象ユーザが前記設定を変更するか否かを推定させる、
    プログラム。
13. 後払い決済サービスにおける少なくとも過去の所定期間にわたる決済金額の履歴に対して、前記後払い決済サービスにおける決済後に支払い方法の設定を変更したか否かを示すラベルが付与された教師データに基づいて、前記決済金額の履歴が入力されるとユーザが前記設定を変更する確率値を出力するように学習する、
    学習装置。
14. コンピュータが、
    後払い決済サービスにおける少なくとも過去の所定期間にわたる決済金額の履歴に対して、前記後払い決済サービスにおける決済後に支払い方法の設定を変更したか否かを示すラベルが付与された教師データに基づいて、前記決済金額の履歴が入力されるとユーザが前記設定を変更する確率値を出力するように学習する、
    学習方法。
15. コンピュータに、
    後払い決済サービスにおける少なくとも過去の所定期間にわたる決済金額の履歴に対して、前記後払い決済サービスにおける決済後に支払い方法の設定を変更したか否かを示すラベルが付与された教師データに基づいて、前記決済金額の履歴が入力されるとユーザが前記設定を変更する確率値を出力するように学習させる、
    プログラム。

Images