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

Abstract

【課題】自動生成ＡＩを用いたサービスにおいて効率的な運用を行うこと。
【解決手段】本発明に係る情報処理装置は、受付部と、判定部と、生成部と、実行部とを備える。受付部は、ユーザが入力した実行指示を示す自然言語の文章を受け付ける。判定部は、受付部によって受け付けられた文章の実行指示と対応する処理を実行させるための実行情報がキャッシュされているか否かを判定する。生成部は、判定部によって実行情報がキャッシュされていないと判定された場合、質問に対する回答を生成するように学習が行われたモデルを用いて、実行情報を生成する。実行部は、キャッシュされている実行情報または生成部によって生成された実行情報を用いて処理を実行する。
【選択図】図１

Description

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

従来、チャットボット等の自動応答サービスが普及しつつある。例えば、かかるサービスは、ユーザが入力した質問と類似する質問およびその回答をデータベースから抽出して、抽出した回答をユーザへ提供する技術が提案されている（例えば、特許文献１参照）。

国際公開第２０１９／１８５５７８号

しかしながら、従来技術では、文章を生成するモデル（いわゆる自動生成ＡＩ）を用いることについては考慮されていなかった。例えば、かかるモデルを利用する場合、プロンプトの量や回数に応じて料金が発生するため、効率的な運用が求められる。

本発明は、上記に鑑みてなされたものであって、自動生成ＡＩを用いたサービスにおいて効率的な運用を行うことができる情報処理装置、情報処理方法および情報処理プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するために、本発明に係る情報処理装置は、受付部と、判定部と、生成部と、実行部とを備える。受付部は、ユーザが入力した実行指示を示す自然言語の文章を受け付ける。判定部は、受付部によって受け付けられた文章の実行指示と対応する処理を実行させるための実行情報がキャッシュされているか否かを判定する。生成部は、判定部によって実行情報がキャッシュされていないと判定された場合、質問に対する回答を生成するように学習が行われたモデルを用いて、実行情報を生成する。実行部は、キャッシュされている実行情報または生成部によって生成された実行情報を用いて処理を実行する。

本発明によれば、ユーザに対して適切なコンテンツを提供することができる。

図１は、実施形態に係る情報処理の一例を示す図である。 図２は、実施形態に係るユーザインタフェースの一例を示す図である。 図３は、実施形態に係る情報処理装置の構成例を示すブロック図である。 図４は、実施形態に係るプロンプト辞書記憶部に格納される情報の一例を示す図である。 図５は、実施形態に係るＡＰＩリクエスト記憶部に格納される情報の一例を示す図である。 図６は、実施形態に係る拡張プロンプトの生成処理の説明図である。 図７は、実施形態に係る拡張プロンプトの生成処理の説明図である。 図８は、実施形態に係る拡張プロンプトの生成処理の説明図である。 図９は、実施形態に係る拡張プロンプトの生成処理の説明図である。 図１０は、実施形態に係る拡張プロンプトの一例を示す図である。 図１１は、実施形態に係る拡張プロンプトに対する回答の一例を示す図である。 図１２は、実施形態に係る回答画面の一例を示す図である。 図１３は、実施形態に係る提供処理の一例を示すフローチャートである。 図１４は、実施形態に係る情報処理装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。

以下に、本願に係る情報処理装置、情報処理方法および情報処理プログラムを実施するための形態（以下、「実施形態」と記載する。）について図面を参照しつつ詳細に説明する。なお、この実施形態により本願に係る情報処理装置、情報処理方法および情報処理プログラムが限定されるものではない。

［実施形態］
〔１．情報処理〕
まず、図１を用いて、実施形態に係る情報処理の一例について説明する。図１は、実施形態に係る情報処理の一例を示す図である。なお、実施形態に係る情報処理は、図１に示す情報処理装置１によって実現される。

図１に示す情報処理装置１は、各ユーザに対して電子マネー決済に関する電子決済サービスが運営するサーバ装置である。本実施形態において、情報処理装置１は、ユーザに対する質問に対して回答を生成する自動応答サービスを提供する。

例えば、情報処理装置１は、電子マネーの利用額に関する質問、クーポンや店舗に関する質問、電子マネーの個人間送金に関する質問等を受け付けることができる。例えば、これらの質問は、複数のＡＰＩ（Application Programming Interface）のうち、いずれかのＡＰＩを実行し、データを取得する必要がある。本実施形態では、後述するように、第２モデルＭ２を利用してＡＰＩリクエスト（ＡＰＩを実行するためのクエリ）の生成を行う。なお、第２モデルＭ２は、ＧＰＴ（Generative Pretrained Transformer）モデルである。

図１に示すユーザ端末１００は、ユーザによって利用される情報処理装置である。ユーザ端末１００は、例えば、スマートフォンや、タブレット型端末や、ノート型ＰＣ（Personal Computer）や、デスクトップＰＣや、携帯電話機や、ＰＤＡ（Personal Digital Assistant）等により実現される。また、ユーザ端末１００は、情報処理装置１、サーバ装置２００によって配信される情報を、ウェブブラウザやアプリケーションにより表示する。なお、図１に示す例では、ユーザ端末１００がスマートフォンである場合を示す。

図１に示すサーバ装置２００は、ユーザ端末１００を用いる電子決済に関する電子決済サービスを提供し、各種の決済を行う情報処理装置である。サーバ装置２００は、取引対象の提供者（事業者）や取引対象が提供されるユーザの口座を管理しており、ユーザからの決済要求に従って、口座間における電子マネーの送金等を行うことで、各種決済を実現する。

ここで、情報処理装置１が実行する提供処理に先立ち、ユーザ端末１００を用いた決済（電子決済）の一例について説明する。なお、以下の説明では、店舗Ａに配置された２次元コード（ＱＲコード（登録商標））であって、店舗Ａを識別する店舗識別情報を示す２次元コードを用いて、ユーザがユーザ端末１００を用いた決済を行う例について説明するが、実施形態は、これに限定されるものではない。以下に説明する決済の一例は、任意のユーザが任意のユーザ端末１００を用いて、任意の店舗にて決済を行う場合においても適用可能である。また、店舗識別情報は、ＱＲコードのみならず、バーコードや所定のマーク、番号等であってもよい。

例えば、ユーザが店舗Ａにて各種の商品やサービスといった決済対象（取引対象）の利用や購入に伴う決済を行う場合、ユーザは、ユーザ端末１００に予めインストールされた決済アプリを起動する。そして、ユーザは、決済アプリを介して、店舗Ａに設置された店舗識別情報を撮影する。このような場合、ユーザ端末１００は、決済対象の価格を入力するための画面を表示し、ユーザ或いは店舗Ａの店員から決済金額の入力を受け付ける。そして、ユーザ端末１００は、ユーザを識別するユーザ識別情報と、店舗識別情報（若しくは、店舗識別情報が示す情報、すなわち、店舗Ａ（若しくは店舗Ａの事業者）を示す情報（例えば、店舗ＩＤ）と、決済金額とを示す決済情報をサーバ装置２００へ送信する。

このような場合、サーバ装置２００は、ユーザ識別情報が示すユーザの口座から、店舗識別情報が示す店舗Ａの口座へと、決済金額が示す額の電子マネーを移行させる。そして、サーバ装置２００は、決済が完了した旨の通知をユーザ端末１００へ送信する。このような場合、ユーザ端末１００は、決済が完了した旨の画面や所定の音声を出力することで、電子マネーによる決済が行われた旨を通知する。

より詳細な例を説明する。例えば、店舗Ａに設置された店舗識別情報は、店舗ごとに設定されるＵＲＬであって、店舗Ａが属するグループを示すグループ識別情報と、そのグループにおいて店舗Ａを識別するグループ店舗識別情報とに紐づけ、サーバ装置２００が参照可能に管理されている。なお、店舗識別情報となるＵＲＬは、サーバ装置２００にアクセスするためのＵＲＬとなる。ユーザ端末１００は、店舗識別情報を撮影すると、撮影した店舗識別情報が示すＵＲＬにアクセスし、ユーザ識別情報を送信する。このような場合、サーバ装置２００は、アクセスされたＵＲＬと対応するグループ識別情報を特定し、特定したグループ識別情報と紐づけられた電子マネーの口座（「ウォレット」と表示する場合がある）を特定する。続いて、サーバ装置２００は、ユーザ端末１００に対して金額入力画面を表示させ、金額を入力させる。そして、サーバ装置２００は、ユーザ端末１００から受けつけたユーザ識別情報と紐づけられたウォレットから、グループ識別情報を特定し、特定したグループ識別情報と紐づけられたウォレットに対して、入力された金額の電子マネーを移動させる。なお、サーバ装置２００は、グループ識別情報およびグループ店舗識別情報とに紐づけられるウォレットに電子マネーを移動させてもよい。

なお、ユーザ端末１００を用いた決済は、上述した処理に限定されるものではない。例えば、ユーザ端末１００を用いた決済は、店舗Ａに設置された店舗端末を用いたものであってもよい。例えば、ユーザ端末１００は、ユーザを識別するためのユーザ識別情報を画面上に表示させる。このような場合、店舗Ａに設置された店舗端末は、ユーザ端末１００に表示されたユーザ識別情報を読み取り、ユーザ識別情報（若しくは、ユーザ識別情報が示す情報、すなわち、ユーザを示す情報（例えば、ユーザＩＤ）と、決済金額と、店舗Ａを識別する情報とを示す決済情報をサーバ装置２００へ送信する。このような場合、サーバ装置２００は、ユーザ識別情報が示すユーザの口座から、店舗Ａの口座へ、決済金額が示す額の電子マネーを移行させ、店舗Ａの店舗端末或いはユーザ端末１００に対し、決済が完了した旨の画面や所定の音声を出力させることで、決済が行われた旨を通知してもよい。

より詳細には、ユーザ端末１００は、ユーザ識別情報とともにサーバ装置２００に対して支払いリクエストを送信する。このような場合、サーバ装置２００は、ワンタイムコードを生成し、生成したワンタイムコードとユーザ識別情報とを紐づけるとともに、ワンタイムコードをユーザ端末１００に送信する。すると、ユーザ端末１００は、画面上にワンタイムコード（すなわち、ユーザを識別する情報）を表示する。このような場合、店舗端末は、ユーザ端末１００に表示されたワンタイムコードを読み取ると、読み取ったワンタイムコードと、グループ識別情報、グループ店舗識別情報および決済金額をサーバ装置２００に送信する。すると、サーバ装置２００は、ワンタイムコードに紐づけられたユーザ識別情報に紐づくウォレットから、グループ識別情報およびグループ店舗識別情報とに紐づけられるウォレットに決済金額分の電子マネーを移動させる。

また、ユーザ端末１００を用いた決済は、ユーザが予め電子マネーをチャージした口座から店舗Ａの口座へ電子マネーを移行させる処理のみならず、例えば、ユーザが予め登録したクレジットカードを用いた決済であってもよい。このような場合、例えば、ユーザ端末１００は、店舗Ａの口座に対して決済金額の電子マネーを移行させるとともに、ユーザのクレジットカードの運用会社（カード会社）に対し、決済金額を請求してもよい。

ところで、近年では、質問に対して回答を生成するように学習されたモデル（いわゆる自動生成ＡＩ）が注目されつつある。本実施形態では、かかるモデルを活用して自動応答サービスを提供する。

このような自動応答サービスでは、ユーザによる質問に対応する処理を実行する必要がある場合に、ユーザが入力した文章を、対応するＡＰＩに対応したフォーマットへ変換する必要がある。

本実施形態では、自動生成ＡＩ（後述する第１モデルおよび第２モデル）を用いて上記のフォーマットの変換を行うこととした。

具体的には、図１に示すように、情報処理装置１は、ユーザ端末１００からユーザによる質問を受け付ける（ステップＳ１）。質問は、自然言語の文章であり、情報処理装置１は、図２にて後述するＵＩを通じて、質問を受け付けることができる。

情報処理装置１は、第１モデルに入力するプロンプトを生成する（ステップＳ２）。なお、第１モデルは、ＧＰＴやＢＥＲＴ（Bidirection Encoder Representation from Transfomers）等のモデルである。また、第１モデルは、内部モデルの一例である。

本実施形態では、情報処理装置１は、第１モデルを用いたプロンプトエンジニアリングを実施し、ユーザによる質問から拡張プロンプトを生成する。なお、プロンプトエンジニアリングは、プロンプトの内容を最適化する処理である。

後述するように、情報処理装置１は、プロンプトを第１モデルに入力することで、拡張プロンプトを生成する。つまり、本実施形態では、第１モデルを利用してプロンプトエンジニアリングを実施することにより、後述する第２モデルＭ２から所望する回答を得ることができる。なお、拡張プロンプトの生成に関しては、図６～図１０を用いて、後述する。

つづいて、情報処理装置１は、生成した拡張プロンプトを情報処理装置１外部の第２モデルＭ２へ入力し（ステップＳ３）、第２モデルＭ２から拡張プロンプトに対応する回答を取得する（ステップＳ４）。上述の拡張プロンプトは、第２モデルＭ２がＡＰＩのフォーマットで回答を生成するような指示文章を含み、第２モデルＭ２から得られる回答は、例えば、ＪＳＯＮ形式のフォーマットとなる。

このように、情報処理装置１は、ユーザによる自然言語の文章を、第２モデルＭ２を用いてＡＰＩのフォーマットであるＪＳＯＮ形式のフォーマットへ変換することができる。つまり、情報処理装置１は、拡張プロンプトに対する第２モデルＭ２の回答をＡＰＩリクエストとして取得することができる。

そして、情報処理装置１は、第２モデルＭ２から取得した回答（ＡＰＩリクエスト）をキャッシュに登録する（ステップＳ５）。例えば、情報処理装置１は、第２モデルＭ２から取得した回答に対し、ユーザによる質問をタグ付けしてキャッシュに登録する。例えば、情報処理装置１は、形態素解析等により、ユーザが入力した質問から単語を抽出し、これらの単語をタグとして、第２モデルＭ２から取得した回答に紐づけてキャッシュに登録する。なお、情報処理装置１は、今回のタグに対応する過去のタグに対応する回答が既にキャッシュに登録されている場合には、キャッシュに登録する処理を省略するようにしてもよい。

その後、情報処理装置１は、第２モデルＭ２から取得した回答に基づき、ＡＰＩリクエストを生成する（ステップＳ６）。ＡＰＩリクエストは、実行情報の一例であり、ＡＰＩを実行するための各種パラメータを含む。

つづいて、情報処理装置１は、ＡＰＩリクエストをサーバ装置２００に対して提供することで、ＡＰＩを実行する（ステップＳ７）。これにより、サーバ装置２００は、情報処理装置１に対して、ＡＰＩリクエストに応じたコンテンツ出力を行う（ステップＳ８）。

この際、情報処理装置１は、ＡＰＩリクエストに対して質問者となるユーザの識別子（例えば、ユーザＩＤ）を付与してサーバ装置２００へ提供する。つまり、情報処理装置１は、外部の第２モデルＭ２に対しては、ユーザの識別情報を渡さずにＡＰＩリクエストを生成する。これにより、情報処理装置１は、ユーザ情報を保護することができる。

そして、情報処理装置１は、サーバ装置２００から取得したコンテンツに基づき、ユーザ端末１００に対して回答を提供する（ステップＳ９）。なお、情報処理装置１がユーザに対して提供する回答の具体例については図１２を用いて後述する。

このように、実施形態に係る情報処理装置１は、第１モデルを用いて、ユーザによる質問文から拡張プロンプトを生成し、生成した拡張プロンプトを第２モデルＭ２に入力することで、第２モデルＭ２からＡＰＩリクエストの回答を取得する。

つまり、情報処理装置１は、ＧＰＴやＢＥＲＴ等のモデルを用いることで、ユーザが入力した自然言語の文章を、ＡＰＩリクエストへ自動的に変換することができる。そして、情報処理装置１は、ＡＰＩリクエストに対応する処理を実行することで、ユーザが入力した自然言語の文章に対応する処理を適切に実行することができる。

また、情報処理装置１は、新たな質問を受け付けた際には、質問内容を示すタグを生成し、タグに基づいてキャッシュから対応するＡＰＩリクエストを検索する。情報処理装置１は、タグに対応するＡＰＩリクエストがキャッシュされていれば、かかるＡＰＩリクエストを用いて処理を実行し、タグに対応するＡＰＩリクエストがキャッシュされていなければ、上述のように第１プロンプトおよび第２プロンプトによって第２モデルＭ２を用いてＡＰＩリクエストを生成し、処理を実行する。

つまり、情報処理装置１は、ＡＰＩリクエストにタグを紐づけてキャッシュに登録することで、第２モデルＭ２の利用頻度を抑えることができる。これにより、第２モデルＭ２の利用料金を抑えることができるので、効率的な運用を行うことができる。

次に、図２を用いて、ユーザから質問を受け付ける際のユーザインタフェースについて説明する。図２は、実施形態に係るユーザインタフェースの一例を示す図である。情報処理装置１は、サーバ装置２００が提供する決済アプリを通じて、ユーザから質問を受け付ける。

図２に示すように、決済アプリのホーム画面ＨＧには、ＱＲコードや各アプリケーションを選択する選択ボタンが表示される。例えば、ユーザが選択ボタンＢを選択すると、ホーム画面ＨＧからトーク画面ＣＧに画面が遷移する。

トーク画面ＣＧは、図２に示すように、機能のチュートリアルが表示されるチュートリアル領域Ｃや、ユーザが質問を選択する想定質問Ｑ、ユーザがテキストで質問を入力する入力領域Ａが表示される。

ユーザが、想定質問Ｑの選択あるいは入力領域Ａに文章を入力することで、情報処理装置１は、ユーザから自然言語の質問を受け付けることになる。そして、情報処理装置１は、質問に対する回答を、チャット形式でトーク画面ＣＧを通じて提供する。

〔２．情報処理装置〕
次に、図３を用いて、実施形態に係る情報処理装置１の構成例について説明する。図３は、実施形態に係る情報処理装置１の構成例を示すブロック図である。図３に示すように、情報処理装置１は、通信部２と、記憶部３と、制御部４とを備える。なお、情報処理装置１は、情報処理装置１を利用する管理者などから各種操作を受け付ける入力部（例えば、キーボードやマウスなど）や、各種情報を表示するための表示部（例えば、液晶ディスプレイなど）を有してもよい。

通信部２は、例えば、ＮＩＣ（Network Interface Card）などによって実現される。通信部２は、４Ｇ（4th Generation）または５Ｇ（5th Generation）などの通信ネットワークと有線または無線で接続され、通信ネットワークを介して、ユーザ端末１００、サーバ装置２００などの各々との間で情報の送受信を行う。

記憶部３は、例えば、ＲＡＭ（Random Access Memory）、フラッシュメモリ（Flash Memory）などの半導体メモリ素子、または、ハードディスク、光ディスクなどの記憶装置によって実現される。記憶部３は、プロンプト辞書記憶部３１と、ＡＰＩリクエスト記憶部３２と、第１モデル記憶部３３とを備える。

プロンプト辞書記憶部３１は、プロンプト辞書を記憶する。プロンプト辞書は、上述した第１プロンプトおよび第２プロンプトに関する辞書である。図４は、実施形態に係るプロンプト辞書記憶部３１に格納される情報の一例を示す図である。

図４に示すように、プロンプト辞書記憶部３１は、「カテゴリ質問文」、「カテゴリ」および「ＡＰＩ質問文」などといった項目の情報を互いに対応付けて記憶する。「カテゴリ質問文」は、ユーザの質問に対応するカテゴリを第１モデルに質問する際の質問文である。なお、カテゴリ質問文の具体例については、図６を用いて後述する。

なお、図４に示す例では、ＡＰＩ質問文がすべて「カテゴリ質問文＃１」で共通している場合について示しているが、プロンプト辞書記憶部３１は、複数パターンのカテゴリ質問文を格納するようにしてもよい。

「カテゴリ」は、ユーザが入力した文章のカテゴリを示す。なお、カテゴリの具体例については、図６を用いて後述する。「ＡＰＩ質問文」は、ユーザの質問に対応する処理を実行するためのＡＰＩの種別や取得すべき値の種別を第１モデルに質問するための文章である。また、ＡＰＩ質問文は、各ＡＰＩに対応する回答のフォーマットを含む。なお、図４の例では、プロンプト辞書記憶部３１は、１つのカテゴリに対して１つのＡＰＩ質問文が対応付けて記憶しているが、１つのカテゴリに対して複数のＡＰＩ質問を対応付けて記憶するようにしてもよい。

図３の説明に戻り、ＡＰＩリクエスト記憶部３２について説明する。ＡＰＩリクエスト記憶部３２は、第２モデルＭ２によって生成されたＡＰＩリクエストを記憶する。なお、ＡＰＩリクエスト記憶部３２は、キャッシュの一例に対応する。

図５は、実施形態に係るＡＰＩリクエスト記憶部３２に格納される情報の一例を示す図である。図５に示すように、ＡＰＩリクエスト記憶部３２は、「タグ」および「ＡＰＩリクエスト」などといった項目の情報を互いに対応付けて記憶する。

「タグ」は、ユーザによる質問内容を示すタグである。「ＡＰＩリクエスト」は、第２モデルＭ２によって生成されたＡＰＩリクエストである。つまり、ＡＰＩリクエスト記憶部３２には、第２モデルＭ２によって新たなＡＰＩリクエストが生成されるたびに、新たなＡＰＩリクエストが蓄積されることになる。

図３の説明に戻り、第１モデル記憶部３３について説明する。第１モデル記憶部３３は、第１モデルを記憶する。上述のように、第１モデルは、自然言語の文章に対して回答を生成するように学習されたモデルであり、ＧＰＴやＢＥＲＴである。本実施形態において、第１モデルは、上述のプロンプトエンジニアリングを行うために利用されるモデルである。

次に、制御部４について説明する。制御部４は、コントローラ（controller）であり、例えば、ＣＰＵ（Central Processing Unit）やＭＰＵ（Micro Processing Unit）などによって、情報処理装置１内部の記憶装置に記憶されている各種プログラム（情報処理プログラムの一例に相当）がＲＡＭを作業領域として実行されることにより実現される。また、制御部４は、例えば、コントローラであり、ＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）などの集積回路により実現される。

図３に示すように、制御部４は、受付部４１と、推定部４２と、判定部４３と、生成部４４と、実行部４５と、提供部４６とを備え、以下に説明する情報処理の機能や作用を実現または実行する。なお、制御部４の内部構成は、図３に示した構成に限られず、後述する情報処理を行う構成であれば他の構成であってもよい。また、制御部４が有する各処理部の接続関係は、図３に示した接続関係に限られず、他の接続関係であってもよい。

受付部４１は、ユーザが入力した実行指示を示す自然言語の文章を受け付ける。上述のように、受付部４１は、サーバ装置２００が提供する決済アプリを通じて、ユーザから自然言語の質問に関する文章である質問文書を受け付ける。

なお、受付部４１は、例えば、電子マネーの送金指示や決済指示などといったサーバ装置２００が提供する各種サービスに対する実行指示をユーザから受け付けるようにしてもよい。

推定部４２は、受付部４１によって受け付けられた文章内容を推定する。例えば、推定部４２は、ユーザが入力した質問文章から自然言語処理によって所定の属性単語を抽出し、抽出した属性単語に基づいて、ユーザが入力した文章内容を推定する。

例えば、ユーザが入力した質問文章が「今月の電子マネーの利用金額を教えて」であるとする。この場合、推定部４２は、「電子マネー」や、「利用金額」を属性単語として抽出する。

そして、推定部４２は、抽出した属性単語をタグとして質問文章に対応付ける。なお、「今月」、「今週」、「今日」などといった日時や期間を示す単語は、ユーザが文章を入力した日時において意味が変化する一方、例えば、「２０２３年」、「２０２３年７月」、「２０２３年７月１日」等の単語は、一意に日時や期間を特定することができる。

そのため、推定部４２は、「２０２３年」、「２０２３年７月」、「２０２３年７月１日」等についてはタグとして質問文章に対応付ける一方、「今月」、「今週」、「今日」等についてはタグとして質問文章に対応付けないようにしてもよい。すなわち、推定部４２は、特定の変数を含む単語についてはタグとして生成しないようにしてもよい。

また、推定部４２は、質問文章からタグを生成するモデルを用いて、質問文章の文章内容を推定し、タグを生成するようにしてもよい。例えば、かかるモデルは、ＢＥＲＴ（Bidirectional Encoder Representation from Transformers）等によって実現することができる。

判定部４３は、受付部４１によって受け付けられた文章の実行指示と対応する処理を実行させるための実行情報（ＡＰＩリクエストに対応）がキャッシュされているか否かを判定する。判定部４３は、推定部４２によって推定された質問文章の内容に基づいて、質問文章の内容に対応するＡＰＩリクエストがキャッシュとなるＡＰＩリクエスト記憶部３２に格納されているか否かを判定する。

具体的には、判定部４３は、推定部４２によって生成されたタグに基づいて、ＡＰＩリクエスト記憶部３２を検索し、ＡＰＩリクエストがキャッシュされているか否かを判定する。例えば、判定部４３は、推定部４２によって生成されたタグと同一のタグが紐づいたＡＰＩリクエストを検索し、ＡＰＩリクエストがキャッシュされているか否かを判定する。

そして、判定部４３は、ＡＰＩリクエストがキャッシュされていないと判定した場合、生成部４４に対してプロンプトの生成指示を出力し、ＡＰＩリクエストがキャッシュされていると判定した場合、キャッシュされているＡＰＩリクエストを実行部４５へ渡す。

生成部４４は、判定部４３によってＡＰＩリクエストがキャッシュされていないと判定された場合、質問に対する回答を生成するように学習が行われた第２モデルＭ２を用いて、ＡＰＩリクエストを生成する。

まず、ＡＰＩリクエストの生成に先立って、生成部４４は、第１モデル記憶部３３に格納された第１モデルを用いて、プロンプトエンジニアリングを実施し、拡張プロンプトを生成する。ここで、図６～図９を用いて、拡張プロンプトの生成処理について説明する。

図６～図９は、実施形態に係る拡張プロンプトの生成処理の説明図である。なお、以下では、ユーザの質問文章が「Did I Spend more this month?」である場合について説明する。

例えば、第１モデルに入力するプロンプトは、上述のユーザの質問文章のカテゴリ、および、質問に対する処理を実行するうえで鍵となる値の種別（Value as the Key）を問い合わせる質問文章と、回答をＪＳＯＮ形式で出力させる指示文章とを含む。

そして、生成部４４は、このようなプロンプトを第１モデルに入力して得られる回答を取得する。例えば、図７に示すように、第１モデルによる回答から、カテゴリＩＤが「０」であり、値の種別が「支出（Spend data）」であることが分かる。

次に、生成部４４は、これらの回答に含まれるカテゴリＩＤや値の種別に基づき、さらに、第１モデルに入力するプロンプトを決定する。例えば、生成部４４は、プロンプト辞書記憶部３１を参照し、カテゴリＩＤや値の種別に基づきＡＰＩ質問文を選択する。

例えば、生成部４４は、プロンプト辞書記憶部３１からカテゴリＩＤが一致するＡＰＩ質問文を選択する。生成部４４は、選択したＡＰＩ質問文から第１モデルに対してさらに入力するプロンプトを生成する。

例えば、生成部４４は、図８に示すプロンプトを生成する。なお、図８に示すプロンプトにおいて、ユーザによる質問部分（Did you spend more this month?）は、各ユーザの質問に置き換えられる。

図８に示すように、ここでのプロンプトは、実行すべきＡＰＩの種別（「normalized metric」）や取得すべき値（「current period statr datetime」、「current period end datetime」、「previous period statr datetime」、「previous period end datetime」）を問い合わせる文章および回答をＪＳＯＮ形式で出力させる指示文章を含む。

生成部４４は、図８に示すプロンプトを第１モデルに入力し、第１モデルから回答を取得する。第１モデルは、このようなプロンプトに対して、例えば、図９に示す回答を出力する。

図９に示すように、第１モデルによる回答は、プロンプトによって指定された「normalized metric」、「current period statr datetime」、「current period end datetime」、「previous period statr datetime」、「previous period end datetime」の各項目に対する回答を含む。

そして、生成部４４は、これらの回答を基に、拡張プロンプトを生成する。図１０は、実施形態に係る拡張プロンプトの一例を示す図である。生成部４４は、例えば、図１０に示すような拡張プロンプトを生成する。拡張プロンプトは、最終的に第２モデルＭ２に入力するプロンプトであり、第２モデルＭ２でＡＰＩリクエストを生成するためのプロンプトである。

図１０に示す例において、拡張プロンプトは、リクエストボディ（request body）に記載された項目の入力、および、ユーザレスポンス（user response）に関する記述の依頼を含む。

そして、生成部４４は、拡張プロンプトを第２モデルＭ２に対して入力し、第２モデルＭ２から拡張プロンプトに対する回答を得る。ここで、図１１を用いて、第２モデルＭ２による出力結果について説明する。図１１は、実施形態に係る拡張プロンプトに対する回答の一例を示す図である。

図１１に示すように、第２モデルＭ２は、ＡＰＩ種別、認証、リクエストボディ、および、ユーザレスポンスの各項目を記述した回答をＪＳＯＮ形式で生成する。つまり、第２モデルＭ２は、ＡＰＩリクエストを回答として出力することになる。

このように、生成部４４は、ユーザによる質問文章を基に、第１モデルを用いてエンジニアリングプロンプトを実施することで、第２モデルＭ２の回答がＡＰＩリクエストとなるような拡張プロンプトを生成することができる。したがって、本実施形態では、ユーザによる質問から適切なＡＰＩリクエストを生成することができる。

図３の説明に戻り、実行部４５について説明する。実行部４５は、キャッシュされている実行情報（ＡＰＩリクエストに対応）または生成部４４によって生成された実行情報を用いて処理を実行する。実行部４５は、実行指示に対応するＡＰＩリクエストがキャッシュされていた場合、対応するＡＰＩリクエストをＡＰＩリクエスト記憶部３２から抽出し、かかるＡＰＩリクエストにユーザＩＤを対応付けてサーバ装置２００へ送信する。

また、実行部４５は、実行指示に対応するＡＰＩリクエストがキャッシュされていなかった場合、生成部４４によって生成されたＡＰＩリクエストに対して、ユーザＩＤを対応付けて対応するサーバ装置２００へ送信する。

これにより、実行部４５は、ＡＰＩリクエストに対応するコンテンツをサーバ装置２００から取得することができる。

そして実行部４５は、生成部４４によって新たに生成されたＡＰＩリクエストに対して、推定部４２によって生成されたタグを対応付けてＡＰＩリクエスト記憶部３２（キャッシュに対応）に登録する。

これにより、情報処理装置１は、新たな質問文章を受け付けた際に、文章の内容が類似していれば、キャッシュに登録された過去のＡＰＩリクエストを活用して、データを取得することが可能となる。

なお、ここでは、第２モデルＭ２によってすべてのＡＰＩリクエストを生成する場合について説明したがが、これに限定されるものではない。例えば、管理者等によって予め生成されたＡＰＩリクエストを予めキャッシュしておくようにしてもよい。

また、情報処理装置１が、ＡＰＩを通じてデータを取得する場合について説明したが、これに限定されるものではない。例えば、対応する回答となる文章やＵＲＬをキャッシュしておくようにしてもよい。

例えば、「パスワードの再設定」に関する質問に対して、情報処理装置１は、「パスワードの再設定」に関するページのＵＲＬを返すようにしてもよい。

提供部４６は、ユーザの質問に対する回答を生成し、質問元となるユーザへ提供する。例えば、提供部４６は、実行部４５によってＡＰＩから取得されたデータを基に、質問に対する回答を生成する。

そして、提供部４６は、トーク画面ＣＧ（図２参照）を通じて、生成した回答をユーザへ提供する。なお、提供部４６は、ＡＰＩから取得したデータをグラフにした回答を生成し、提供するようにしてもよい。

ここで、図１２を用いて、提供部４６が提供する回答画面の一例について説明する。図１２は、実施形態に係る回答画面の一例を示す図である。図１２では、上述の通り、ユーザの質問が「Did I spend more this month」である場合について説明する。

このような質問の入力に対して、実行部４５は、ＡＰＩリクエストをサーバ装置２００（図１参照）へ送信することで、サーバ装置２００からコンテンツを得る。提供部４６は、サーバ装置２００から取得したコンテンツを基に、例えば、図１２に示すテキストやグラフを生成し、ユーザに対して提供する。なお、図１２に示すグラフについては、例えば、所定のＡＰＩリクエストをサーバ装置２００に対して送信することで、サーバ装置２００によって生成されるものとする。

情報処理装置１では、このような一連の処理によって、ユーザの質問に対する回答を提供する。これにより、例えば、情報処理装置１では、ユーザの質問に対して適切な回答を生成し、提供することができる。

〔３．処理フロー〕
次に、図１３を用いて、実施形態に係る情報処理装置１が実行する処理手順について説明する。図１３は、実施形態に係る提供処理の一例を示すフローチャートである。なお、以下に示す処理手順は、ユーザによる質問文章の受け付けをキーとして、情報処理装置１によって繰り返し実行される。

図１３に示すように、情報処理装置１は、ユーザから自然言語の質問文章を受け付ける（ステップＳ１０１）。つづいて、情報処理装置１は、質問内容を示すタグを生成する（ステップＳ１０２）。

次に、情報処理装置１は、タグに基づいてキャッシュを検索し（ステップＳ１０３）、ＡＰＩリクエストがキャッシュにあるか否かを判定する（ステップＳ１０４）。情報処理装置１は、キャッシュ無と判定した場合（ステップＳ１０４；Ｎｏ）、プロンプトを生成する（ステップＳ１０５）。なお、ここでのプロンプトは、第１プロンプトおよび第２プロンプトを含む。

つづいて、情報処理装置１は、モデルから回答を取得する（ステップＳ１０６）。すなわち、情報処理装置１は、第２モデルＭ２からＡＰＩリクエストを取得する。つづいて、情報処理装置１は、ＡＰＩにＡＰＩリクエストを送信し、データを取得する（ステップＳ１０７）。

そして、情報処理装置１は、ユーザによる質問に対する回答を提供し（ステップＳ１０８）、タグとＡＰＩリクエストとを対応付けてキャッシュに登録し（ステップＳ１０９）、処理を終了する。また、情報処理装置１は、ステップＳ１０４の判定において、キャッシュ有りと判定した場合、キャッシュから対応するＡＰＩリクエストを抽出したうえで、ステップＳ１０７の処理へ進む。

〔４．変形例〕
上述した実施形態では、ユーザが文章をテキストで入力する場合について説明したが、これに限定されるものではない。情報処理装置１は、音声等によってユーザから自然言語の文章を受け付けるようにしてもよい。

また、上述した実施形態では、電子マネーに関する質問を受け付ける場合について説明したが、これに限定されるものではない。例えば、ショッピングサイトなど、ＡＰＩを通じてユーザのアカウント情報を取得するその他のサービスに本願発明を適用するようにしてもよい。

また、上述した実施形態では、ユーザから質問を受け付ける場合について説明したが、これに限定されるものではない。例えば、ユーザから送金等の実行指示を受け付けるようにしてもよい。

例えば、ユーザによる文章が「Ａさんに３０００円送金して」であって、「Ａさん」が特定できない場合には、ユーザにＡさんのアカウントを確認したうえで、送金を行うようにしてもよい。

〔５．効果〕
実施形態に係る情報処理装置１は、ユーザが入力した実行指示を示す自然言語の文章を受け付ける受付部４１と、受付部４１によって受け付けられた文章の実行指示と対応する処理を実行させるための実行情報がキャッシュされているか否かを判定する判定部４３と、判定部４３によって実行情報がキャッシュされていないと判定された場合、質問に対する回答を生成するように学習が行われたモデルを用いて、実行情報を生成する生成部４４と、キャッシュされている実行情報または生成部４４によって生成された実行情報を用いて処理を実行する実行部４５とを備える。

また、情報処理装置１は、受付部４１によって文章の内容を推定する推定部４２を備え、判定部４３は、推定部４２によって推定された文章の内容に基づいて、実行情報がキャッシュされているか否かを判定する。

また、実行部４５は、生成部４４によって生成された実行情報を用いて処理を実行する場合、当該実行情報に推定部４２によって推定された文章の内容を付与してキャッシュに登録する。

また、生成部４４は、処理を実行するためのアプリケーションインタフェースの種別と、アプリケーションインタフェースで実行する実行情報の内容とをモデルに問い合わせることで、実行情報を生成する。また、生成部４４は、モデルに対して、アプリケーションインタフェースのフォーマットで実行情報の内容を生成させる。

上述した各処理のいずれかもしくは組合せにより、本願に係る情報処理装置は、自動生成ＡＩを用いたサービスにおいて効率的な運用を行うことができる。

〔６．ハードウェア構成〕
また、上述してきた実施形態に係る情報処理装置１は、例えば図１４に示すような構成のコンピュータ１０００によって実現される。図１４は、実施形態に係る情報処理装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。コンピュータ１０００は、ＣＰＵ１１００、ＲＡＭ１２００、ＲＯＭ１３００、ＨＤＤ１４００、通信インターフェイス（Ｉ／Ｆ）１５００、入出力インターフェイス（Ｉ／Ｆ）１６００、及びメディアインターフェイス（Ｉ／Ｆ）１７００を有する。

ＣＰＵ１１００は、ＲＯＭ１３００またはＨＤＤ１４００に格納されたプログラムに基づいて動作し、各部の制御を行う。ＲＯＭ１３００は、コンピュータ１０００の起動時にＣＰＵ１１００によって実行されるブートプログラムや、コンピュータ１０００のハードウェアに依存するプログラム等を格納する。

ＨＤＤ１４００は、ＣＰＵ１１００によって実行されるプログラム、及び、かかるプログラムによって使用されるデータ等を格納する。通信インターフェイス１５００は、ネットワーク（通信ネットワーク）Ｎを介して他の機器からデータを受信してＣＰＵ１１００へ送り、ＣＰＵ１１００が生成したデータをネットワークＮを介して他の機器へ送信する。

ＣＰＵ１１００は、入出力インターフェイス１６００を介して、ディスプレイやプリンタ等の出力装置、及び、キーボードやマウス等の入力装置（図１４では、出力装置および入力装置を総称して「入出力装置」と記載する）を制御する。ＣＰＵ１１００は、入出力インターフェイス１６００を介して、入力装置からデータを取得する。また、ＣＰＵ１１００は、生成したデータを入出力インターフェイス１６００を介して出力装置へ出力する。

メディアインターフェイス１７００は、記録媒体１８００に格納されたプログラムまたはデータを読み取り、ＲＡＭ１２００を介してＣＰＵ１１００に提供する。ＣＰＵ１１００は、かかるプログラムを、メディアインターフェイス１７００を介して記録媒体１８００からＲＡＭ１２００上にロードし、ロードしたプログラムを実行する。記録媒体１８００は、例えばＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto-Optical disk）等の光磁気記録媒体、テープ媒体、磁気記録媒体、または半導体メモリ等である。

例えば、コンピュータ１０００が実施形態に係る情報処理装置として機能する場合、コンピュータ１０００のＣＰＵ１１００は、ＲＡＭ１２００上にロードされたプログラムを実行することにより、制御部４の機能を実現する。コンピュータ１０００のＣＰＵ１１００は、これらのプログラムを記録媒体１８００から読み取って実行するが、他の例として、他の装置からネットワークＮを介してこれらのプログラムを取得してもよい。

〔７．その他〕
以上、本願の実施形態を説明したが、これら実施形態の内容により本発明が限定されるものではない。また、前述した構成要素には、当業者が容易に想定できるもの、実質的に同一のもの、いわゆる均等の範囲のものが含まれる。さらに、前述した構成要素は適宜組み合わせることが可能である。さらに、前述した実施形態の要旨を逸脱しない範囲で構成要素の種々の省略、置換又は変更を行うことができる。

また、上記実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部又は一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部又は一部を公知の方法で自動的に行うこともできる。この他、上記文書中や図面中で示した処理手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。例えば、各図に示した各種情報は、図示した情報に限られない。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部又は一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。

例えば、上述した情報処理装置は、複数のサーバコンピュータで実現してもよく、また、機能によっては外部のプラットフォーム等をＡＰＩ（Application Programming Interface）やネットワークコンピューティング等で呼び出して実現するなど、構成は柔軟に変更できる。

また、上述してきた実施形態及び変形例は、処理内容を矛盾させない範囲で適宜組み合わせることが可能である。

また、上述してきた「部（section、module、unit）」は、「手段」や「回路」などに読み替えることができる。例えば、取得部は、取得手段や取得回路に読み替えることができる。

１ 情報処理装置
２ 通信部
３ 記憶部
４ 制御部
３１ プロンプト辞書記憶部
３２ ＡＰＩリクエスト記憶部
４１ 受付部
４２ 推定部
４３ 判定部
４４ 生成部
４５ 実行部
４６ 提供部
１００ ユーザ端末
２００ サーバ装置

Claims (5)

1. ユーザが入力した実行指示を示す自然言語の文章を受け付ける受付部と、
   前記受付部によって受け付けられた前記文章の実行指示と対応する処理を実行させるための実行情報がキャッシュされているか否かを判定する判定部と、
   前記判定部によって前記実行情報が前記キャッシュされていないと判定された場合、質問に対する回答を生成するように学習が行われたモデルを用いて、前記実行情報を生成する生成部と、
   前記キャッシュされている前記実行情報または前記生成部によって生成された前記実行情報を用いて前記処理を実行する実行部と、
   前記モデルとは異なるモデルであって、質問に対する回答を生成するように学習が行われた内部モデルを記憶する記憶部と
   を備え、
   前記生成部は、
   前記内部モデルを用いてプロンプトエンジニアリングを実施し、前記プロンプトエンジニアリングによって生成された拡張プロンプトを前記モデルに入力することで、前記実行情報を生成する
   ことを特徴とする情報処理装置。
2. 前記受付部によって受け付けられた前記文章の内容を推定する推定部
   を備え、
   前記判定部は、
   前記推定部によって推定された前記文章の内容に基づいて、前記実行情報が前記キャッシュされているか否かを判定すること
   を特徴とする請求項１に記載の情報処理装置。
3. 前記実行部は、
   前記生成部によって生成された前記実行情報を用いて前記処理を実行する場合、当該実行情報に前記推定部によって推定された前記文章の内容を付与して前記キャッシュに登録すること
   を特徴とする請求項２に記載の情報処理装置。
4. コンピュータが実行する情報処理方法であって、
   ユーザが入力した実行指示を示す自然言語の文章を受け付ける受付工程と、
   前記受付工程によって受け付けられた前記文章の実行指示と対応する処理を実行させるための実行情報がキャッシュされているか否かを判定する判定工程と、
   前記判定工程によって前記実行情報が前記キャッシュされていないと判定された場合、質問に対する回答を生成するように学習が行われたモデルを用いて、前記実行情報を生成する生成工程と、
   前記キャッシュされている前記実行情報または前記生成工程によって生成された前記実行情報を用いて前記処理を実行する実行工程と、
   前記モデルとは異なるモデルであって、質問に対する回答を生成するように学習が行われた内部モデルを記憶する記憶工程と
   を含み、
   前記生成工程は、
   前記内部モデルを用いてプロンプトエンジニアリングを実施し、前記プロンプトエンジニアリングによって生成された拡張プロンプトを前記モデルに入力することで、前記実行情報を生成する
   ことを特徴とする情報処理方法。
5. ユーザが入力した実行指示を示す自然言語の文章を受け付ける受付手順と、
   前記受付手順によって受け付けられた前記文章の実行指示と対応する処理を実行させるための実行情報がキャッシュされているか否かを判定する判定手順と、
   前記判定手順によって前記実行情報が前記キャッシュされていないと判定された場合、質問に対する回答を生成するように学習が行われたモデルを用いて、前記実行情報を生成する生成手順と、
   前記キャッシュされている前記実行情報または前記生成手順によって生成された前記実行情報を用いて前記処理を実行する実行手順と、
   前記モデルとは異なるモデルであって、質問に対する回答を生成するように学習が行われた内部モデルを記憶する記憶手順と
   をコンピュータに実行させ、
   前記生成手順は、
   前記内部モデルを用いてプロンプトエンジニアリングを実施し、前記プロンプトエンジニアリングによって生成された拡張プロンプトを前記モデルに入力することで、前記実行情報を生成する
   ことを特徴とする情報処理プログラム。

Images