JP7315803B1 - 情報処理装置、情報処理方法、およびプログラム - Google Patents

Abstract

【課題】問い合わせの発生頻度を低減することでサービス向上を図ること。【解決手段】電子決済サービスにおける利用者の決済履歴情報と、前記利用者が前記電子決済サービスの事業者に行った問い合わせの履歴情報とを含む判定用情報を取得する取得部と、前記電子決済サービスにおける利用者の決済履歴情報と、前記利用者が前記電子決済サービスの事業者に行った問い合わせの履歴情報とを含む学習データと、前記利用者が前記事業者に問い合わせを行ったか否かを示す教師データとに基づいて生成された学習済モデルに、前記判定用情報を入力することで、前記判定用情報に係る利用者が将来、前記事業者に問い合わせを行うと予想されるか否かを示す判定結果を出力する判定部と、を備える情報処理装置。【選択図】図７

Description

本発明は、情報処理装置、情報処理方法、およびプログラムに関する。

従来、電子商取引の分野において、コールセンターやメールによる問い合わせへの対応部（人によるものと、自動応答するものを含む）を設けて、利用者の問い合わせに回答するという作業が行われている（例えば、特許文献１）。

特開２０１４－４２１５８号公報

現状の問い合わせへの対応は受け身であり、利用者からの問い合わせを待つのが基本である。問い合わせが発生することにより、電子決済事業者の運用コストが高くなり、運用スピードが低下したり、電子決済事業者の持つデータを用いた新たなサービスを創出するのが難しくなるといった種々の弊害が生じ得る。例えば、コールセンターへの委託には多額のコストがかかり、これを低減することで更なるサービスに投資をすることが可能となる。また、自動応答に関しては、内容を自動的にセグメント化して通知を行うことが行われているが、利用者の課題感を現実的に解決するものが無かった。

本発明は、このような事情を考慮してなされたものであり、問い合わせの発生頻度を低減することでサービス向上を図ることができる情報処理装置、情報処理方法、およびプログラムを提供することを目的の一つとする。

本発明の一態様は、電子決済サービスにおける利用者の決済履歴情報と、前記利用者が前記電子決済サービスの事業者に行った問い合わせの履歴情報とを含む判定用情報を取得する取得部と、前記電子決済サービスにおける利用者の決済履歴情報と、前記利用者が前記電子決済サービスの事業者に行った問い合わせの履歴情報とを含む学習データと、前記利用者が前記事業者に問い合わせを行ったか否かを示す教師データとに基づいて生成された学習済モデルに、前記判定用情報を入力することで、前記判定用情報に係る利用者が将来、前記事業者に問い合わせを行うと予想されるか否かを示す判定結果を出力する判定部と、を備える情報処理装置である。

本発明の一態様によれば、問い合わせの発生頻度を低減することでサービス向上を図ることができる。

電子決済サービスが実現されるための構成の一例を示す図である。 電子決済の大まかな流れを例示したシーケンス図（その１）である。 電子決済の大まかな流れを例示したシーケンス図（その２）である。 第１実施形態に係る決済サーバ１００の構成図である。 利用者情報１７２の内容の一例を示す図である。 加盟店／店舗情報１７６の内容の一例を示す図である。 情報処理装置２００の構成図である。 前処理部２２０とモデル生成部２３０の処理を概念的に示す図である。 推論段階の処理の流れの一例を示すフローチャートである。

以下、図面を参照し、本発明の情報処理装置、情報処理方法、およびプログラムの実施形態について説明する。以下の説明において、アプリケーションプログラムと決済サーバが、協働して電子決済サービスを提供する。以下の説明ではアプリケーションプログラムを決済アプリと称する。電子決済サービスは、店舗における商品やサービスの購買に係る決済をサポートするサービスである。店舗とは、例えば、現実空間に存在する物理的な店舗（実店舗）であるが、電子商取引の仮想店舗を含んでもよい。仮想店舗は、電子決済サービスの運営者とは異なる主体によって提供されるものを含んでもよい。その場合、仮想店舗における買い物の決済の際に、電子決済サービスのインターフェース画面に遷移するように制御される。電子決済サービスにおいて、店舗は、例えば加盟店（ブランド）に属するものとして扱われ、店舗において購買行動が行われた際の決済などの処理は、主として利用者と加盟店の間で行われる。これに代えて、決済などの処理が利用者と店舗との間で行われてもよい。

［電子決済サービス］
図１は、電子決済サービスが実現されるための構成の一例を示す図である。電子決済サービスは、決済サーバ１００を中心として実現される。決済サーバ１００は、例えば、一以上の利用者端末装置１０、一以上の第１店舗端末装置５０、及び一以上の第２店舗端末装置７０のそれぞれとネットワークＮＷを介して通信する。ネットワークＮＷは、例えば、インターネット、ＬＡＮ（Local Area Network）、無線基地局、プロバイダ装置などを含む。

利用者端末装置１０は、例えば、スマートフォンやタブレット端末等の可搬型端末装置である。利用者端末装置１０は、少なくとも、光学読取機能、通信機能、表示機能、入力受付機能、プログラム実行機能を有するコンピュータ装置である。以下の説明では、これらの機能を実現するための構成をそれぞれカメラ、通信装置、タッチパネル、ＣＰＵ（Central Processing Unit）等と称する。利用者端末装置１０では、ＣＰＵ等のプロセッサにより決済アプリ２０が実行されることで、決済サーバ１００と連携して電子決済サービスを利用者に提供するように動作する。決済アプリ２０は、例えば、アプリケーションストアから利用者端末装置１０にインストールされ、カメラ、通信装置、タッチパネルなどを制御する。

第１店舗端末装置５０は、例えば、店舗に設置される。第１店舗端末装置５０は、少なくとも、商品価格取得機能、光学読取機能、プログラム実行機能、通信機能を有するコンピュータ装置である。第１店舗端末装置５０は、いわゆるＰＯＳ（Point of Sale）装置を含み、ＰＯＳ装置によって商品価格取得機能や光学読取機能を実現してもよい。店舗コード画像６０は、店舗に置かれ、ＱＲコード（登録商標）等のコード画像が紙やプラスチックの媒体に印刷されたものである。なお、店舗コード画像６０は、店舗に置かれたディスプレイ（スマートフォンなどの端末装置のディスプレイでもよい）によって表示されてもよい。

第２店舗端末装置７０は、加盟店の運営者によって使用される。第２店舗端末装置７０は、スマートフォンやタブレット端末、パーソナルコンピュータ等である。第２店舗端末装置７０では、加盟店向けインターフェース７２が動作する。加盟店向けインターフェース７２は、加盟店向けアプリであってもよいし、ブラウザであってもよい。加盟店向けインターフェース７２は、加盟店の運営者によるクーポンの設定等を受け付け、決済サーバ１００に送信する。スマートフォンである第２店舗端末装置７０は、加盟店向けアプリを実行することで、店舗コード画像に相当するコード画像を表示したり、利用者端末装置１０が表示するコード画像を読み取ったりする機能を有する。

決済サーバ１００は、利用者端末装置１０または第１店舗端末装置５０から受信した決済情報に基づいて電子決済を実現する。第１店舗端末装置５０は、ＰＯＳ装置と加盟店サーバを含む場合があり、その場合、ＰＯＳ装置から加盟店サーバを介して決済情報が決済サーバ１００に送信される。以下の説明では、これを特に区別せず、第１店舗端末装置５０から決済情報が送信されるものとする。

図２および図３は、電子決済の大まかな流れを例示したシーケンス図である。電子決済には、パターン１とパターン２の二つが存在してよい。

図２に示すパターン１（以下、ユーザスキャンと称する）の場合、決済アプリ２０が起動した状態の利用者端末装置１０が、光学読取機能によって店舗コード画像６０をデコードする（Ｓ１）。店舗コード画像６０には、店舗ＵＲＬ（Uniform Resource Locator）の情報が含まれている。この店舗ＵＲＬは、電子決済サービスのドメインに対して店舗を識別可能な情報が付加されたものであり、決済サーバ１００において加盟店ＩＤや店舗ＩＤ等との対応付けがなされている（後述）。決済アプリ２０は、店舗ＵＲＬとアカウントＩＤを含む第１決済情報を決済サーバ１００に送信する（Ｓ２）。決済サーバ１００は、店舗ＵＲＬに対応する加盟店ＩＤ、店舗ＩＤから、店舗情報（後述）を検索して加盟店名と店舗名の情報を取得し（Ｓ３）、決済アプリ２０に送信する（Ｓ４）。利用者は、加盟店名や店舗名が表示された画面において、決済金額を利用者端末装置１０に入力する（Ｓ５）。そして、利用者端末装置１０は、少なくとも決済金額を含む第２決済情報を生成し、決済サーバ１００に送信する（Ｓ６）。決済サーバ１００は、受信した第２決済情報に基づいて電子決済を行う（Ｓ７）。そして、決済サーバ１００は、決済完了通知（決済完了画面を表示するための情報）を決済アプリ２０に送信し（Ｓ８）、決済アプリ２０は決済完了画面を表示する（Ｓ９）。なお、店舗コード画像６０が店舗に置かれたディスプレイによって表示される場合、店舗コード画像６０には、店舗ＵＲＬだけでなく決済金額の情報が含まれる場合がある。この場合、利用者が決済金額を入力する手順が省略され、第１決済情報に決済金額の情報が含められて決済サーバ１００に送信される。加盟店名や店舗名の情報は、決済完了画面に含めて表示されてよい。

図３に示すパターン２（以下、ストアスキャンと称する）の場合、決済アプリ２０の起動時、決済アプリ２０において支払う操作が行われたとき、自動更新のタイミング（例えば１分おき）になったとき、およびその他のタイミングで、決済アプリ２０はワンタイムコードの発行要求を決済サーバ１００に送信する（Ｓ１１）。決済サーバ１００はワンタイムコードを生成し（Ｓ１２）、決済アプリ２０に送信する（Ｓ１３）。決済アプリ２０は、ワンタイムコードに基づいて生成した、ＱＲコードやバーコード等のコード画像を表示する（Ｓ１４）。利用者は利用者端末装置１０の表示面を第１店舗端末装置５０に翳し（提示し）、第１店舗端末装置５０は、光学読取機能によってコード画像をデコードし、ワンタイムコード等を取得する（Ｓ１５）。そして、第１店舗端末装置５０は、ワンタイムコード、決済金額、加盟店ＩＤ、店舗ＩＤ等を含む決済情報を生成し、決済サーバ１００に送信する（Ｓ１６）。決済金額の情報は、予めバーコード読み取りや手入力等によって取得されている。決済サーバ１００は、受信した情報に基づいて、ワンタイムコードに対応する利用者を特定し、電子決済を行う（Ｓ１７）。そして、決済サーバ１００は、決済完了通知を決済アプリ２０に送信し（Ｓ１８）、決済アプリ２０は決済完了画面を表示する（Ｓ１９）。

なお、上記のいずれか一方のみのパターンで電子決済が行われてもよい。また、図２で説明した「アカウントＩＤ」は、利用者の識別情報として用いられ得る他の情報（例えば電話番号）であってもよい。また、ストアスキャンにおいてワンタイムコードの発行が省略され、決済アプリ２０は、利用者のアカウントＩＤに基づいて生成したコード画像を表示してもよい。その場合、決済サーバ１００は、ワンタイムコードに対応する利用者を特定するのに代えて、アカウントＩＤに対応する利用者を特定する。

また、決済サーバ１００は、情報処理装置２００に各種情報を送信し、情報処理装置２００の処理結果を取得する。図１では情報処理装置２００と決済サーバ１００が別体の装置であるように示しているが、情報処理装置２００は決済サーバ１００の内部機能であってもよい。

［決済サーバ］
図４は、第１実施形態に係る決済サーバ１００の構成図である。決済サーバ１００は、例えば、通信部１１０と、決済コンテンツ提供部１２０と、決済処理部１３０と、情報管理部１４０と、自動応答部１５０と、記憶部１７０とを備える。通信部１１０および記憶部１７０以外の構成要素は、例えば、ＣＰＵなどのハードウェアプロセッサがプログラム（ソフトウェア）を実行することにより実現される。これらの構成要素のうち一部または全部は、ＬＳＩ（Large Scale Integration）やＡＳＩＣ（Application Specific Integrated Circuit）、ＦＰＧＡ（Field-Programmable Gate Array）、ＧＰＵ（Graphics Processing Unit）などのハードウェア（回路部；circuitryを含む）によって実現されてもよいし、ソフトウェアとハードウェアの協働によって実現されてもよい。プログラムは、予めＨＤＤ（Hard Disk Drive）やフラッシュメモリなどの記憶装置（非一過性の記憶媒体を備える記憶装置）に格納されていてもよいし、ＤＶＤやＣＤ－ＲＯＭなどの着脱可能な記憶媒体（非一過性の記憶媒体）に格納されており、記憶媒体がドライブ装置に装着されることで記憶装置にインストールされてもよい。

記憶部１７０は、ＨＤＤやフラッシュメモリ、ＲＡＭ（Random Access Memory）などである。記憶部１７０は、決済サーバ１００がネットワークを介してアクセス可能なＮＡＳ（Network Attached Storage）装置であってもよい。記憶部１７０には、利用者情報１７２、決済コンテンツ情報１７４、加盟店／店舗情報１７６などの情報が格納される。

通信部１１０は、ネットワークＮＷに接続するための通信インターフェースである。通信部１１０は、例えばネットワークインターフェースカードである。

決済コンテンツ提供部１２０は、例えば、Ｗｅｂサーバの機能を有し、電子決済サービスの各種画面を表示するための情報（コンテンツ）を利用者端末装置１０に提供する。決済コンテンツ提供部１２０は、決済コンテンツ情報１７４から適宜、必要なコンテンツを読み出して利用者端末装置１０に提供する。利用者端末装置１０は、決済アプリ２０によってコンテンツが再生された状態で利用者による各種入力を受け付け、前述した決済情報などを決済サーバ１００に送信する。

決済処理部１３０は、利用者端末装置１０または第１店舗端末装置５０により送信された決済情報に基づいて、決済処理を行う。決済処理部１３０は、利用者情報１７２を参照しながら決済処理を行う。

図５は、利用者情報１７２の内容の一例を示す図である。利用者情報１７２は、利用者の登録情報の一例である。利用者情報１７２は、例えば、利用者ＵＲＬ、アカウントＩＤ、電話番号、パスワードの他、メールアドレス、利用者ＩＤ、氏名・住所・生年月日、登録日、チャージ残高、後払い設定、後払い枠、後払い利用額、後払い利用可能額、決済方法設定、銀行口座、クレジットカード番号、チャージ履歴情報、決済履歴情報などの情報が対応付けられたものである。利用者ＵＲＬは、利用者間の送金処理に使用される。電子決済サービスへの新規登録時には、電話番号およびパスワードの登録が必須となる。アカウントＩＤは、決済サーバ１００によって利用者に発行されるものであり、利用者ＩＤは、利用者が任意に設定できる（設定しなくてもよい）ＩＤである。メールアドレス、および氏名・住所・生年月日も同様に、利用者が任意に設定できる（設定しなくてもよい）情報である。登録日とは利用者が電子決済サービスに登録した日（アカウントを作成した日）である。以下、これらの情報が対応付けられた利用者のインスタンス（電子決済口座）のことをアカウントと称する。

チャージ残高は、利用者が予めアカウントに送金することで設定された電子マネーの残高を示す情報である。送金の手段としては、指定業者（銀行）のＡＴＭ（Automatic Teller Machine）からの送金、登録された銀行口座からの送金などがある。後払い設定は、後払いによる電子決済を可能とするための設定が済んでいるか否かを示す情報であり、「済」と「未」のいずれかに設定される。決済方法設定は、その時点において利用者がチャージ残高による電子決済を行うのか、後払いによる決済を行うのかを示す設定情報である。銀行口座とクレジットカード番号のそれぞれは、電子決済サービスに入金可能な銀行口座またはクレジットカード番号の情報（口座番号、カード番号）である。チャージ履歴情報は、利用者が予め電子決済サービスに送金してチャージ残高を増加させた履歴である。決済履歴情報は、利用者が行った決済の内訳（日時、購買行動が行われた店舗の店舗ＩＤ、決済金額、決済方法など）を、決済ごとに示す情報である。

ＦＡＱ問い合わせ履歴は、決済アプリ２０または決済サーバ１００が提供するウェブサイトに入力されるＦＡＱ（Frequently Asked Questions）に対して利用者が行った問い合わせと、それに対する自動応答部１５０の回答の履歴を示す情報である。自動応答問い合わせ履歴は、決済アプリ２０または決済サーバ１００が提供するウェブサイトに入力されるフリーテキストによって利用者が行った問い合わせと、それに対する自動応答部１５０の回答の履歴を示す情報である。

図６は、加盟店／店舗情報１７６の内容の一例を示す図である。加盟店／店舗情報１７６は、例えば、店舗ＵＲＬに対して加盟店ＩＤと店舗ＩＤが対応付けられた第１テーブル１７６Ａと、加盟店ＩＤに対して加盟店名と売上金（前述）が対応付けられた第２テーブル１７６Ｂと、店舗ＩＤに対して店舗ＩＤが対応付けられた第３テーブル１７６Ｃとを含む。加盟店／店舗情報１７６には、これらの情報の他、加盟店または店舗のカテゴリ、店舗の所在地、決済パターン等の情報が含まれてもよい。

情報管理部１４０は、利用者端末装置１０や第２店舗端末装置７０から取得した情報に基づいて、利用者情報１７２および加盟店／店舗情報１７６を管理する。情報管理部１４０は、利用者情報１７２および加盟店／店舗情報１７６について新規レコードの追加、編集、削除などを行う。

自動応答部１５０は、ＦＡＱによる問い合わせに対して、予め定められた回答を利用者端末装置１０に返信する。また、自動応答部１５０は、フリーテキストによる問い合わせに対して、形態素解析、意味解釈等を行って問い合わせを類型化し、類型化された問い合わせに対して予め定められた回答を利用者端末装置１０に返信する。

［電子決済］
決済処理部１３０は、利用者端末装置１０または第１店舗端末装置５０から決済情報が取得されると、利用者情報１７２を参照して当該利用者の「決済方法設定」を取得する。決済処理部１３０は、「決済方法設定」が「チャージ残高」に設定されている利用者に関して、以下のように電子決済を行う。決済処理部１３０は、例えば、利用者ＩＤに対応付けて管理しているチャージ残高を減少させ、加盟店の売上金の項目値を増加させることで、電子決済を行う。加盟店の売上金の項目値は、例えば、それ自体が電子マネーとして使用されるものでは無く、加盟店と電子決済サービスとの取り決めに応じたサイクルで、売上金の項目値に対応する金額が銀行口座に送金される。

決済処理部１３０は、「設定情報」が「後払い」に設定されている利用者に関して、以下のように電子決済を行う。後払いとは、電子決済サービスの運営者とは別主体であるクレジットカード会社との連携による「クレジット払い」とは別枠で設定されるものであり、電子決済サービスの運営者が与信者となって、後払い枠の範囲内でチャージ残高に依存しない電子決済を許容するものである。なお後払いサービスを受けるために、電子決済サービスの運営者が提供するクレジットカードの取得が要求されてよい。後払いで利用された金額は、一か月分まとめて翌月の支払日に、例えば銀行口座からの引き落としによって決済される。この場合、決済処理部１３０は、後払い利用額に決済金額を加算し、後払い利用可能額から同額を差し引くことで暫定決済を行い、締め日になると上記のように当月分の決済を翌月の支払い日に引き落とすための処理を行う、或いはクレジットカード会社の運営者に当該処理を依頼する。なお暫定決済の時点で決済金額が後払い利用可能額を超える場合は、エラー通知が決済アプリ２０に返信される。

［情報処理装置］
図７は、情報処理装置２００の構成図である。情報処理装置２００は、例えば、取得部２１０と、モデル生成部２３０と、判定部２４０と、案内部２５０と、記憶部２７０とを備える。取得部２１０は、前処理部２２０を備える。記憶部２７０以外の構成要素は、例えば、ＣＰＵなどのハードウェアプロセッサがプログラム（ソフトウェア）を実行することにより実現される。これらの構成要素のうち一部または全部は、ＬＳＩやＡＳＩＣ、ＦＰＧＡ、ＧＰＵなどのハードウェア（回路部；circuitryを含む）によって実現されてもよいし、ソフトウェアとハードウェアの協働によって実現されてもよい。プログラムは、予めＨＤＤやフラッシュメモリなどの記憶装置（非一過性の記憶媒体を備える記憶装置）に格納されていてもよいし、ＤＶＤやＣＤ－ＲＯＭなどの着脱可能な記憶媒体（非一過性の記憶媒体）に格納されており、記憶媒体がドライブ装置に装着されることで記憶装置にインストールされてもよい。

記憶部２７０は、ＨＤＤやフラッシュメモリ、ＲＡＭ（Random Access Memory）などである。記憶部２７０は、情報処理装置２００がネットワークを介してアクセス可能なＮＡＳ装置であってもよい。記憶部２７０には、学習用データセット２７２、モデル設定情報２７４、学習済モデル２７６などの情報が格納される。

［学習段階］
以下、情報処理装置２００の各部の機能について、学習段階と推論段階に分けて説明する。学習段階において、取得部２１０は、学習用データセット２７２の元データとなる各種データを決済サーバ１００などから取得する。元データは、例えば、電子決済サービスにおける利用者の決済履歴情報と、利用者が電子決済サービスの事業者に行った問い合わせの履歴情報とを含むものである。また、元データは、決済アプリ２０を介して取得される様々な情報（決済アプリ２０のバージョンデータなどのアプリデータ、決済アプリ２０がブラウザと連携して取得するウェブ閲覧履歴、ＳＮＳデータ、位置データ、電子決済サービスが保有する利用者の個人情報など）を更に含んでもよい。これらの一部が利用されるのに際して、利用者の承諾を得るようにすると好適である。学習用データセット２７２は、学習データ２７２Ａと、教師データ２７２Ｂとが対応付けられたものである（詳しくは後述）。

前処理部２２０は、元データに対して前処理を行い、学習用データセット２７２を生成する。図８は、前処理部２２０とモデル生成部２３０の処理を概念的に示す図である。前処理部２２０は、まず、元データを、正規化処理を行うものとラベルエンコーディング処理を行うものに分類する。なお、正規化処理とラベルエンコーディング処理のそれぞれが行われる元データが存在してもよい。また、元データは、利用者が電子決済サービスの事業者に問い合わせを行ったとした場合、問い合わせよりも前のタイミングで収集された情報に限定されてもよい。

正規化処理とは、例えば、決済エラー回数、キャンペーン時期との相関関係などのように数値で表される元データに対して、平均ゼロ、標準偏差１の分布となるように乗算、除算等を行うことである。

ラベルエンコーディング処理とは、ある事象を表す元データに対して、該当するならば１、該当しないならばゼロといったフラグを、学習データ２７２Ａを構成するベクトルのうち特定の要素の値として設定することである。例えば、前処理部２２０は、ＦＡＱデータや自動応答データを類型化したデータが「○○に関した問い合わせを行った」ことに該当するならば、上記ベクトルのうち、その事象に対応する要素の値を１に設定する。同様に、前処理部２２０は、利用者からの意見を収集した利用者意見データについても、「××に関する意見を投稿した」ことに該当するならば、上記ベクトルのうち、その事象に対応する要素の値を１に設定する。具体的に、電子決済サービスと提携するショッピング事業者の決済が失敗した、キャンペーンでポイントが付与されなかった、電子決済サービスと提携するカードの切り替え時に決済ができなかった、といった事態が上記の「事象」に該当する。

そして、前処理部２２０は、正規化処理を行った結果として得られるベクトルと、ラベルエンコーディング処理を行った結果として得られるベクトルとを結合（コンカチネット）することで、利用者ごとの学習データ２７２Ａを生成する。このように作成された学習データ２７２Ａは、電子決済サービスにおける利用者の決済履歴情報と、利用者が電子決済サービスの事業者に行った問い合わせの履歴情報とを含むものである。また、学習データ２７２Ａは、決済アプリ２０を介して取得される様々な情報を更に含んでもよい。

モデル生成部２３０は、利用者ごとの学習データ２７２Ａと、同じ利用者に関する教師データ２７２Ｂとに基づいて、学習済モデル２７６を生成する。教師データ２７２Ｂは、利用者が電子決済サービスの事業者に問い合わせを行ったか否かを示すデータである。ここでの「問い合わせ」とは、オペレータによる電話対応、自動応答、ＦＡＱのうち一部または全部を含むものである。学習データ２７２Ａの要素数はモデル設定情報２７４により規定されている入力ノードの数に一致する。モデル設定情報２７４は、学習済モデル２７６の元になる機会学習モデルの入力ノード数、出力ノード数、中間ノードの接続態様などを規定する情報である。

モデル生成部２３０は、学習データ２７２Ａを入力データとした場合の機械学習モデルの出力が教師データ２７２Ｂに近づくように、バックプロパゲーションなどの手法により機械学習モデルのパラメータを学習する。機械学習モデルの出力は、当該利用者が今後、上記の「問い合わせ」を行う確率を示す値である。モデル生成部２３０は、「問い合わせ」を行った利用者について機械学習モデルの出力が１に近づき、「問い合わせ」を行わなかった利用者について機械学習モデルの出力が０に近づくように、機械学習モデルのパラメータを学習する。例えば、規定回数、上記の処理を実行した時点での機械学習モデルが、学習済モデル２７６として確定する。

［推論段階］
取得部２１０は、判定部２４０が判定対象とする利用者について、判定用情報を取得する。判定用情報とは、学習データ２７２Ａと同じ元データに基づいて、前処理部２２０が上記説明したのと同じ処理を行った情報である。

判定部２４０は、モデル生成部２３０が生成した学習済モデル２７６に判定用情報を入力することで、判定用情報に係る利用者が将来、電子決済サービスの事業者に問い合わせを行うと予想されるか否かを示す判定結果（問い合わせを行う確率）を出力する。

案内部２５０は、判定部２４０により、電子決済サービスの事業者に問い合わせを行うと予想されることを示す判定結果（例えば、閾値以上の確率）が出力された場合、当該判定結果に係る利用者の利用者端末装置１０に、オペレータによる回答を要さない問い合わせ手法について案内する情報を出力させる。案内部２５０は、決済サーバ１００に、案内の対象となる利用者の識別情報を伝え、決済コンテンツ提供部１２０が上記の案内を決済アプリ２０に表示させる。この表示の態様はプッシュ通知、決済アプリ２０のインターフェース画面内の表示など、種々の態様で有り得る。このとき、案内部２５０は、利用者の属性（年齢層など）に応じて案内の内容（どの態様での問い合わせを推奨するのか）を切り替えてもよい。例えば、高齢者に対しては比較的扱いやすいＦＡＱをプッシュ通知するようにしてよい。

図９は、推論段階の処理の流れの一例を示すフローチャートである。本フローチャートの処理は、例えば一日に一回程度の頻度で、複数の利用者についてまとめて実行される。まず、取得部２１０が、判定用情報の元データを取得する（Ｓ３００）。次に、前処理部２２０が、正規化処理とラベルエンコーディング処理を行って判定用情報を生成する（Ｓ３０２）。次に、判定部２４０が、判定用情報を学習済モデル２７６に入力する（Ｓ３０４）。次に、案内部２５０が、学習済モデル２７６の出力が閾値以上であったか否かを判定する（Ｓ３０６）。学習済モデル２７６の出力が閾値以上であった場合、案内部２５０は、当該判定結果に係る利用者の利用者端末装置１０の決済アプリ２０に、オペレータによる回答を要さない問い合わせ手法について案内する情報を出力させる（Ｓ３０８）。

係る処理を行うことで、問い合わせの発生頻度を低減し、電子決済サービスのサービス向上を図ることができる。前述したように、学習済モデル２７６は、「問い合わせ」を行った利用者について機械学習モデルの出力が１に近づき、「問い合わせ」を行わなかった利用者について機械学習モデルの出力が０に近づくように生成されたものであり、その学習データとして用いられるのは、電子決済サービスにおける利用者の決済履歴情報と、利用者が電子決済サービスの事業者に行った問い合わせの履歴情報とを含むものであるため、有意な結果を出力可能なモデルであることが期待される。この結果、学習済モデル２７６に判定用情報を入力することで、利用者が「問い合わせ」を行うか否かを高精度に推定することができ、「問い合わせ」を行いそうな利用者に対して先回りして種々の案内を行うことも可能となる。この結果、上記のように問い合わせの発生頻度を低減し、電子決済サービスのサービス向上を図ることができる。

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

１０ 利用者端末装置
２０ 決済アプリ
１００ 決済サーバ
１２０ 決済コンテンツ提供部
１３０ 決済処理部
１４０ 情報管理部
１５０ 自動応答部
２００ 情報処理装置
２１０ 取得部
２２０ 前処理部
２３０ モデル生成部
２４０ 判定部
２５０ 案内部
２７０ 記憶部
２７２ 学習用データセット
２７４ モデル設定情報
２７６ 学習済モデル

Claims (6)

1. 電子決済サービスにおける利用者の決済履歴情報と、前記利用者が前記電子決済サービスの事業者に行った問い合わせの履歴情報とを含む判定用情報を取得する取得部と、
   前記電子決済サービスにおける利用者の決済履歴情報と、前記利用者が前記電子決済サービスの事業者に行った問い合わせの履歴情報とを含む学習データと、前記利用者が前記事業者に問い合わせを行ったか否かを示す教師データとに基づいて生成された学習済モデルに、前記判定用情報を入力することで、前記判定用情報に係る利用者が将来、前記事業者に問い合わせを行うと予想されるか否かを示す判定結果を出力する判定部と、
   を備える情報処理装置。
2. 前記判定部により、前記事業者に問い合わせを行うと予想されることを示す判定結果が出力された場合、当該判定結果に係る利用者の端末装置に、オペレータによる回答を要さない問い合わせ手法について案内する情報を出力させる案内部を更に備える、
   請求項１記載の情報処理装置。
3. 前記電子決済サービスにおける利用者の決済履歴情報と、前記利用者が前記電子決済サービスの事業者に行った問い合わせの履歴情報とを含む学習データと、前記利用者が前記事業者に問い合わせを行ったか否かを示す教師データとに基づいて、前記学習済モデルを生成するモデル生成部を更に備える、
   請求項１記載の情報処理装置。
4. 前記取得部は、数値で表される元データに対して、所望の分布を有するように除算または乗算を行う正規化処理と、事象を表す元データに対して、該当するかしないかを示すフラグを、前記学習データを構成するベクトルのうち特定の要素の値として設定するラベルエンコーディング処理とを行う前処理部を更に備える、
   請求項１記載の情報処理装置。
5. 情報処理装置が、
   電子決済サービスにおける利用者の決済履歴情報と、前記利用者が前記電子決済サービスの事業者に行った問い合わせの履歴情報とを含む判定用情報を取得し、
   前記電子決済サービスにおける利用者の決済履歴情報と、前記利用者が前記電子決済サービスの事業者に行った問い合わせの履歴情報とを含む学習データと、前記利用者が前記事業者に問い合わせを行ったか否かを示す教師データとに基づいて生成された学習済モデルに、前記判定用情報を入力することで、前記判定用情報に係る利用者が将来、前記事業者に問い合わせを行うと予想されるか否かを示す判定結果を出力する、
   情報処理方法。
6. 情報処理装置のプロセッサに、
   電子決済サービスにおける利用者の決済履歴情報と、前記利用者が前記電子決済サービスの事業者に行った問い合わせの履歴情報とを含む判定用情報を取得させ、
   前記電子決済サービスにおける利用者の決済履歴情報と、前記利用者が前記電子決済サービスの事業者に行った問い合わせの履歴情報とを含む学習データと、前記利用者が前記事業者に問い合わせを行ったか否かを示す教師データとに基づいて生成された学習済モデルに、前記判定用情報を入力することで、前記判定用情報に係る利用者が将来、前記事業者に問い合わせを行うと予想されるか否かを示す判定結果を出力させる、
   ためのプログラム。

Images