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

Abstract

【課題】オーバーブッキング可能な予約枠数を精度よく決定すること。【解決手段】本願に係る情報処理装置は、取得部と、推定部と、決定部とを備える。取得部は、所定の予約枠数を有する施設の予約に関する情報である予約情報を取得する。推定部は、取得部によって取得された予約情報に基づいて、予約のキャンセルが発生するリスクであるキャンセルリスクを推定する。決定部は、推定部によって推定されたキャンセルリスクに基づいて施設においてオーバーブッキング可能な予約枠数である過剰枠数を決定する。【選択図】図３

Description

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

従来、旅館、ホテル、飲食店などの施設を利用しようとするユーザは、一般にインターネットや電話などを通じて施設を予約することができる。また、施設事業者は、例えば、予約のキャンセルが発生することを想定して、予約枠数よりも多めに予約を受け入れる、いわゆるオーバーブッキングを行う場合がある。

特開２００３−１９６４０６号公報

ところで、施設事業者がオーバーブッキングを行った場合、利用日において施設を実際に利用する顧客が予約枠数よりも多くなったり、反対に少なくなったりする場合がある。つまり、施設事業者にとって、オーバーブッキング可能な予約枠数を正確に把握することは容易ではない。

本願は、上記に鑑みてなされたものであって、オーバーブッキング可能な予約枠数を精度よく決定することができる情報処理装置、情報処理方法および情報処理プログラムを提供することを目的とする。

本願に係る情報処理装置は、取得部と、推定部と、決定部とを備える。前記取得部は、所定の予約枠数を有する施設の予約に関する情報である予約情報を取得する。前記推定部は、前記取得部が取得した前記予約情報に基づいて前記予約のキャンセルが発生するリスクを推定する。前記決定部は、前記推定部によって推定された前記リスクに基づいて前記施設においてオーバーブッキング可能な予約枠数である過剰枠数を決定する。

実施形態の一態様によれば、オーバーブッキング可能な予約枠数を精度よく決定することができる情報処理装置、情報処理方法および情報処理プログラムを提供することができる。

図１は、実施形態に係る情報処理の説明図である。 図２は、実施形態に係る情報処理システムの構成の一例を示す図である。 図３は、実施形態に係る情報処理装置の構成の一例を示す図である。 図４は、実施形態に係るユーザ情報テーブルの一例を示す図である。 図５は、実施形態に係る予約情報テーブルの一例を示す図である。 図６は、実施形態に係る補償関連情報テーブルの一例を示す図である。 図７Ａは、決定部による過剰枠数の決定処理を示す図である。 図７Ｂは、決定部による過剰枠数の決定処理を示す図である。 図８は、決定部による過剰枠数の決定処理を示す図である。 図９は、実施形態に係る情報処理装置が実行する処理の処理手順を示すフローチャートである。 図１０は、実施形態に係るプログラムを実行するコンピュータのハードウェア構成の一例を示す図である。

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

図１を用いて、実施形態に係る情報処理について説明する。図１は、実施形態に係る情報処理の説明図である。図１では、情報処理装置が予約のキャンセルが発生するリスクを推定し、推定したリスクに基づいてオーバーブッキング可能な予約枠数（以下、過剰枠数と記載する）を決定する情報処理について説明する。

まず、図１に示すように、ユーザが予約サーバに対し施設利用の予約を要求する予約要求を行う（ステップＳ１）。予約サーバは、予約要求を受け付けた場合、施設の予約可能数に空きが有れば、予約要求に基づいて予約要求にかかる予約を登録する（ステップＳ２）。一方、予約サーバは、施設の予約可能数に空きが無ければ、ユーザに対して予約ができない旨を通知する。なお、予約可能数とは、施設が有する予約枠数（例えば、宿泊施設の場合では部屋の数）と、上記した過剰枠数とを合算した数である。また、予約サーバは、施設利用の予約に関する情報である予約情報を情報処理装置へ送信する（ステップＳ３）。

情報処理装置は、予約サーバから予約情報を取得すると、取得された予約情報に基づいて、予約のキャンセルが発生するリスク（以下、キャンセルリスクと記載する）を推定するリスク推定処理を行う（ステップＳ４）。かかるリスク推定処理は、予約毎に行われる。

情報処理装置は、リスク評価モデルを記憶している。情報処理装置は、かかるリスク評価モデルによってキャンセルリスクのスコア（以下、キャンセルスコアＳｃと記載する）を演算することができる。かかるキャンセルスコアＳｃがキャンセルリスクの推定値であり、キャンセルが発生する確率を示す情報である。

リスク評価モデルは、例えば、過去の予約情報を説明変数とし、過去のキャンセルの有無を教師データ（目的変数）として生成される。予約情報には、例えば、予約された施設の地域、予約された施設の利用期間、利用価格、利用される部屋の数や広さの情報が含まれており、これらの情報を説明変数としてリスク評価モデルを生成することができる。

さらに、予約情報から得られる特徴情報に加え、予約したユーザの情報から得られる特徴情報を説明変数としてリスク評価モデルを生成することができる。予約情報には、ユーザの識別情報が含まれており、情報処理装置は、ユーザの識別情報に基づいて、ユーザの属性や行動履歴の情報を取得し、取得したユーザの属性や行動履歴を説明変数とすることができる。なお、予約情報に含まれるユーザの情報に、ユーザの属性や行動履歴の情報が含まれていてもよい。

情報処理装置は、ステップＳ４で推定したキャンセルリスクに基づいて、施設においてオーバーブッキング可能な予約枠数である過剰枠数を決定する（ステップＳ５）。情報処理装置は、例えば、キャンセルが発生する予約枠数の確率分布を用いて過剰枠数を決定することができるが、かかる点については後述する。

情報処理装置は、決定した過剰枠数に基づく提供情報を、予約サーバを介して施設を提供する事業者（以下、施設事業者と記載する）へ送信する（ステップＳ６）。提供情報とは、施設事業者が上記した予約可能数（予約枠数および過剰枠数の合算）を決定するための情報であり、例えば、過剰枠数や予約可能数等の情報を含む。施設事業者は、例えば、過剰枠数の情報を含む提供情報に基づいて、上記した予約可能数を決定する。施設事業者は、１以上の過剰枠数を含む予約可能数を決定した場合、予約サーバに対してオーバーブッキングの許可を要求するオーバーブッキング許可要求を送信する（ステップＳ７）。なお、施設事業者は、決定した予約可能数に含まれる過剰枠数がゼロの場合、オーバーブッキングを許可しない旨を要求するオーバーブッキング不可要求を送信する。

予約サーバは、オーバーブッキング許可要求を受け付けると、オーバーブッキング許可要求にかかる予約可能数を更新する（ステップＳ８）。これにより、施設事業者は、オーバーブッキング可能に予約を受け入れることができる。また、施設事業者は、キャンセルリスクに基づく過剰枠数から最終的な予約可能数を決定することで、施設の利用日における予約枠数の空きを少なくすることができる。また、施設事業者は、利用日において施設を実際に利用する顧客が予約枠数よりも多くなったり、反対に少なくなったりする状況を回避することができる。

このように、実施形態に係る情報処理装置は、キャンセルリスクを用いて過剰枠数を決定することで、過剰枠数を精度よく決定することができる。

なお、上述した例では、提供情報の提供先が施設事業者である場合について示したが、例えば、提供情報の提供先が予約サーバであってもよい。例えば、予約サーバに提供情報を提供した場合、予約サーバは、提供情報に基づいて、施設事業者から送信される予約可能数の可否を判定してもよい。具体的には、予約サーバは、施設事業者で独自に決定した過剰枠数が情報処理装置で決定された過剰枠数を超えていた場合、施設事業者に対して予約可能数を受け付けない旨を通知する。これにより、施設事業者が過剰枠数を多く設定することを防止できる。

図２は、実施形態に係る情報処理システムの構成の一例を示す図である。図２に示すように、実施形態に係る情報処理システム１００は、情報処理装置１と、複数の端末装置２_１〜２_ｎ（ｎは２以上の整数）と、予約サーバ３と、複数の施設装置４_１〜４_ｍ（ｍは２以上の整数）と、情報提供サーバ５とを備える。

これら情報処理装置１、複数の端末装置２_１〜２_ｎ、予約サーバ３、複数の施設装置４_１〜４_ｍ、および情報提供サーバ５は、ネットワーク６を介して有線または無線により互いに通信可能に接続される。ネットワーク６は、例えば、ＬＡＮ（Local Area Network）や、インターネットなどのＷＡＮ（Wide Area Network）である。端末装置２_１〜２_ｎは、ユーザＵ_１〜Ｕ_ｎによって操作される。

以下においては、端末装置２_１〜２_ｎの各々を区別せずに示す場合、端末装置２と記載する。また、施設装置４_１〜４_ｍの各々を区別せずに示す場合、施設装置４と記載し、ユーザＵ_１〜Ｕ_ｎの各々を区別せずに示す場合、ユーザＵと記載する。

端末装置２は、ユーザＵの端末装置であり、スマートフォン、タブレット型端末、ＰＤＡ（Personal Digital Assistant）、パーソナルコンピュータなどのスマートデバイス（通信端末）である。端末装置２は、ブラウザ、施設予約アプリケーションなどの各種のアプリケーションが実行可能である。端末装置２は、ブラウザ、施設予約アプリケーションなどのアプリケーションから、予約サーバ３にネットワーク６を介してアクセスし、各施設事業者が提供する施設を予約することができる。

施設装置４は、施設事業者の装置であり、図２に示す例では、施設事業者毎に設けられる。施設事業者は、例えば、旅館、ホテル、ペンション、飲食店、マッサージ店、歯科医院、美容院などの施設を運営する事業者である。

図２に示すように、予約サーバ３は、通信部５０と、記憶部５１と、制御部５２とを備える。通信部５０は、ネットワーク６との間で情報の送受信を行う通信インターフェイスである。制御部５２は、通信部５０およびネットワーク６を介して、情報処理装置１、端末装置２、および施設装置４の各々との間で各種の情報を送受信することができる。

記憶部５１は、施設予約サービスに必要な各種の情報を記憶する。記憶部５１は、例えば、フラッシュメモリ等の半導体メモリ素子、または、ＨＤＤ（Hard Disk Drive）、光ディスク等の記憶装置である。

制御部５２は、施設装置４から施設情報を取得し、記憶部５１に記憶する。施設装置４の施設情報には、予約可能な施設の情報が含まれる。予約可能な施設の情報は、例えば、施設が宿泊施設である場合、予約可能な部屋の数、各部屋の広さ、各部屋の利用可能人数、各部屋の利用価格などの情報が含まれる。

制御部５２は、端末装置２からアクセスがあった場合、施設の予約をするための施設情報画面の情報を端末装置２へ提供する。端末装置２は、施設情報画面の情報を不図示の表示部に表示する。施設情報画面には、例えば、上述した予約可能な施設の情報が含まれる。ユーザＵは、表示部に表示される施設情報画面を見ながら不図示の入力部への入力によって、施設の予約申請を予約サーバ３へ送信することができる。

制御部５２は、予約申請があった場合、予約申請の対象となる施設の施設装置４へ予約申請の情報を送信する。施設装置４は、予約サーバ３から送信された予約申請の情報に基づいて、予約の可否を判定し、予約が可能であると判定した場合、予約が可能であることを示す情報を予約サーバ３へ送信する。制御部５２は、施設装置４から予約が可能であることを示す情報を取得すると、予約を確定するか否かを問い合わせる情報を端末装置２へ送信する。これにより、端末装置２の表示部には、予約確定ボタンが表示される。

端末装置２のユーザＵが予約確定ボタンを操作すると、端末装置２から予約要求が予約サーバ３へ送信される。制御部５２は、予約要求を受け付けると、現時点で予約済枠数が予約可能数以下であった場合、施設装置４へ予約要求があったことを示す情報を送信する。施設装置４は、予約要求があったことを示す情報を予約サーバ３から取得すると、予約を確定する。なお、制御部５２は、予約済枠数が予約可能数を超えていた場合、ユーザＵの端末装置２へ予約不可の旨を送信する。なお、制御部５２は、予約済枠数が予約可能数を超えていた場合、予約申請を受け付けないようにしてもよく、あるいは、施設情報画面として表示しないようにしてもよい。

また、制御部５２は、予約要求を受け付けると、予約情報を情報処理装置１へ送信する。情報処理装置１へ送信される予約情報には、例えば、予約を行ったユーザＵのユーザＩＤ（identifier）、予約ＩＤ、予約の受付日時、および予約内容の情報が含まれる。予約内容の情報には、例えば、利用期間、施設名、施設の地域、利用人数、利用価格、利用部屋数、および利用する部屋の広さなどの情報が含まれる。

また、制御部５２は、施設装置４からオーバーブッキング許可要求を取得、または、情報処理装置１から提供情報を取得すると、取得した要求または情報に基づいて予約可能数を更新する。

また、制御部５２は、端末装置２から予約のキャンセルがあった場合、キャンセル要求を施設装置４へ送信し、その後、予約がキャンセル済であることを示すキャンセル済情報を取得すると、情報処理装置１へキャンセル情報を送信する。

情報提供サーバ５は、各種情報を情報処理装置１および端末装置２へ提供する。例えば、情報提供サーバ５は、例えば、時事に関する時事情報を提供するニュース提供サービスや、天気予報サービス、検索サービス、ショッピングサービス、路線検索サービス、地図提供サービス、旅行サービス、飲食店紹介サービス、ブログサービス等がある。

図３は、実施形態に係る情報処理装置の構成の一例を示す図である。図３に示すように、情報処理装置１は、通信部１０と、記憶部１１と、制御部１２（コントローラ）とを備える。以下、通信部１０、記憶部１１および制御部１２を具体的に説明する。

通信部１０は、ネットワーク６との間で情報の送受信を行う通信インターフェイスである。制御部１２は、通信部１０およびネットワーク６を介して、端末装置２、予約サーバ３、および情報提供サーバ５の各々との間で各種の情報を送受信することができる。

記憶部１１は、ユーザ情報ＤＢ２０と、予約情報ＤＢ２１と、施設情報ＤＢ２２とを有する。記憶部１１は、例えば、フラッシュメモリ等の半導体メモリ素子、または、ＨＤＤ、光ディスク等の記憶装置である。

ユーザ情報ＤＢ２０は、ユーザＵの情報であるユーザ情報を複数含むユーザ情報テーブルを有する。ユーザＵは、情報処理装置１の運営および管理を行う事業者が提供するサービスのユーザである。かかる事業者が提供するサービスは、ユーザＵに対してオンラインでサービスを提供するオンラインサービスであり、例えば、予約サーバ３の施設予約サイトで提供される施設予約サービス、電子商取引サイトで提供される電子商取引サービス、オークションサイトで提供されるオークションサービス、動画配信サイトで提供される動画配信サービス、ニュースサイトで提供されるニュース配信サービスなどが含まれる。

図４は、実施形態に係るユーザ情報テーブルの一例を示す図である。図４に示すユーザ情報テーブル４１は、「ユーザＩＤ」、「デモグラフィック属性」、「サイコグラフィック属性」、および「行動履歴」などの情報が互いに関連付けられた情報である。

「ユーザＩＤ」は、ユーザＵの識別情報であり、図４に示す例では、ユーザＵ_１、Ｕ_２、Ｕ_３のユーザＩＤとして「Ｕ１」、「Ｕ２」、「Ｕ３」が設定される。かかるユーザＩＤは、上述したオンラインサービスに対するユーザＵのアカウントである。なお、ユーザＩＤは、ユーザＵを識別する情報であればよく、ユーザＵが使用する端末装置２の識別情報をユーザＩＤとしてもよい。例えば、ユーザＩＤは、ＨＴＴＰ（Hypertext Transfer Protocol）クッキーで特定される識別情報であってもよい。

「デモグラフィック属性」は、ユーザＵの人口統計学的な属性の情報である。かかる「デモグラフィック属性」は、例えば、ユーザＵの「性別」、「年齢」などの情報である。「性別」には、ユーザＵが女性である場合には「１」が設定され、ユーザＵが男性である場合には「２」が設定される。また、「年齢」には、ユーザＵの年齢が設定される。なお、「デモグラフィック属性」は、図４に示した属性の例に限られず、ユーザＵの職業、家族構成、年収、住所、出身地、学歴など様々な属性を含んでいてもよい。

「サイコグラフィック属性」は、ユーザＵの心理学的な属性の情報であり、例えば、ユーザＵの価値観、ライフスタイル、性格、嗜好などの情報である。図４に示す例では、属性要素毎に、ユーザＵの嗜好が相対的に高い場合に「１」が設定され、それ以外の場合には「０」が設定される。また、「サイコグラフィック属性」は、図４に示した属性の例に限られず、経済、政治、野球、サッカー、その他スポーツ、スイーツ、パソコン、白物家電、家具など様々な属性を含んでいてもよい。なお、属性の情報は、０と１の２段階に限定されず、３段階以上の値であってもよい。

「行動履歴」は、上述した各種サイトでのユーザＵの行動履歴の情報である。「行動履歴」は、例えば、施設予約サイトでの施設の予約の履歴、電子商取引サイトやオークションサイトでの商品またはサービスの購入履歴、動画配信サイトでの動画の視聴履歴、ニュースサイトで閲覧したニュースの履歴などである。また、「行動履歴」には、各サイトで提供される広告に対するアクション（例えば、クリック）などの情報が含まれる。

予約情報ＤＢ２１は、施設事業者の施設の予約に関する情報である予約情報を複数含む予約情報テーブルを有する。図５は、実施形態に係る予約情報テーブルの一例を示す図である。図５に示す予約情報テーブル４２は、「予約ＩＤ」、「ユーザＩＤ」、「受付日時」、「予約内容」、「キャンセル情報」、および「キャンセルスコア」などの情報が互いに関連付けられた情報である。

「予約ＩＤ」は、予約毎に割り当てられる固有の識別情報である。「ユーザＩＤ」は、ユーザＵ毎に割り当てられる固有の識別情報である。「受付日時」は、予約サーバ３によってユーザＵから予約を受け付けた日時を示す情報である。

「予約内容」は、予約サーバ３によってユーザＵから受け付けられた予約の内容を示す情報である。「予約内容」には、利用期間、施設名、利用人数、施設の地域、利用価格、利用部屋数、利用する部屋の広さなどの情報が含まれる。

利用期間は、ユーザＵが施設を利用する期間である。施設名は、ユーザＵが予約した施設の名称である。利用人数は、施設を利用する人数である。施設の地域は、ユーザＵが予約した施設が位置する地域である。

利用価格は、予約内容に従って施設を利用した場合にユーザＵが施設事業者に支払う額である。例えば、予約された施設が宿泊施設である場合、予約の内容に飲食やマッサージなどが含まれる場合には、利用価格には、宿泊料に加え、食事やマッサージなどの料金が含まれる。また、予約された施設が飲食店の場合、利用価格は、施設内での飲食に必要な価格である。

利用部屋数は、ユーザＵが予約した部屋の数である。利用する部屋の広さは、ユーザＵが予約した部屋の広さである。なお、予約された施設が飲食店の場合、利用部屋数に代えて、利用場所の種別（テーブル席、カウンター席、座敷など）の情報や、利用場所の広さなどが含まれる。

「キャンセル情報」は、予約のキャンセルに関する情報であり、予約のキャンセルの有無を示す情報、および予約のキャンセルが受け付けられた日時であるキャンセル日時の情報を含む。

「キャンセルスコア」は、制御部１２によって演算されるキャンセルスコアＳｃの情報である。図６に示す例では、キャンセルスコアＳｃを便宜上「Ｓｃ１」、「Ｓｃ２」、「Ｓｃ３」などと表しているが、キャンセルスコアＳｃは数値化されたスコアである。

施設情報ＤＢ２２は、各施設に関する情報である施設情報を複数含む施設情報テーブルを有する。図６は、実施形態に係る施設情報テーブルの一例を示す図である。図６に示す施設情報テーブル４３は、「施設ＩＤ」、「施設名」、「予約枠数」、および「予約状況」などの情報が互いに関連付けられた情報である。

「施設ＩＤ」は、施設毎に割り当てられる固有の識別情報である。「施設名」は、施設の名称である。「予約枠数」は、施設が有する予約枠数の上限値である。「予約枠数」は、例えば、宿泊施設の場合、全部屋数であってもよく、あるいは、部屋のグレード（スイートルームか通常の部屋か等）やタイプ（禁煙か喫煙か、シングルベッドかダブルベッドか等）等の区分毎の部屋数であってもよい。つまり、「予約状況」の予約済枠数や過剰枠数についても、全部屋数を基準としてもよく、部屋の区分毎の部屋数を基準としてもよい。

「予約状況」は、施設の予約状況に関する情報である。「予約状況」には、利用日や、予約済枠数、過剰枠数などの情報が含まれる。利用日は、ユーザＵが施設を利用する日である。予約済枠数は、予約サーバ３が受け付けた予約の数を示す。過剰枠数は、オーバーブッキング可能な予約枠数を示す。なお、過剰枠数の情報は、情報処理装置１によって決定された過剰枠数、または、施設事業者によって登録された過剰枠数のいずれかが入力される。

例えば、施設名「施設Ａ」は、利用日が「２０１８／８／３」について、既に「７０
が予約済みであることを示す。また、「施設Ａ」は、過剰枠数が「１０」、すなわち、予約可能数は「１１０」であり、残り「４０」の予約枠数が残っていることを示す。

また、例えば、施設名「施設Ａ」は、利用日が「２０１８／８／４」について、過剰枠数が「１５」であり、予約済枠数が「１１５」である。すなわち、利用日が「２０１８／８／４」については、施設Ａの予約ができない状況であることを示す。

なお、施設情報テーブル４３について、利用日が過ぎた場合、該当する利用日の予約済枠数や過剰枠数は、施設情報テーブル４３から削除される。

制御部１２は、例えば、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、入出力ポートなどを有するマイクロコンピュータや各種の回路を含む。

図３に示すように、制御部１２は、取得部３０と、生成部３１と、推定部３２と、決定部３３と、提供部３４とを備える。かかる取得部３０、生成部３１、推定部３２、決定部３３および提供部３４の機能は、例えば、制御部１２のＣＰＵが制御部１２のＲＡＭ、ＲＯＭ、または記憶部１１に記憶されているプログラムを読み出して実行することにより実現される。

なお、取得部３０、生成部３１、推定部３２、決定部３３および提供部３４は、それぞれ一部または全部がＡＳＩＣ（Application Specific Integrated Circuit）やＦＰＧＡ（Field Programmable Gate Array）等のハードウェアで構成されてもよい。

取得部３０は、予約サーバ３から予約情報、およびキャンセル情報などを取得する。取得部３０は、予約サーバ３から予約情報を取得すると、取得した予約情報を予約情報テーブル４２に追加する。予約情報には、予約ＩＤ、ユーザＩＤ、受付日時、および予約内容の情報が含まれており、これらの情報が予約情報テーブル４２に追加される。また、取得部３０は、予約情報を予約情報テーブル４２に反映するとともに、施設情報テーブル４３の該当する施設ＩＤおよび利用日の予約済枠数をカウントアップする。

また、取得部３０は、予約サーバ３からキャンセル情報を取得すると、取得したキャンセル情報を予約情報テーブル４２に追加する。キャンセル情報には、予約ＩＤ、およびキャンセル日時の情報が含まれており、これらの情報に基づいて、予約のキャンセルが有りを示す情報、およびキャンセル日時の情報が予約情報テーブル４２に追加される。また、取得部３０は、キャンセル情報を予約情報テーブル４２に反映するとともに、施設情報テーブル４３の該当する施設ＩＤおよび利用日の予約済枠数をカウントダウンする。

また、取得部３０は、情報提供サーバ５からユーザＵのユーザ情報を取得することができる。取得部３０は、ユーザ情報を取得すると、取得したユーザ情報をユーザ情報テーブル４１へ追加する。なお、取得部３０は、端末装置２からユーザ情報を取得することもでき、この場合も、取得したユーザ情報をユーザ情報テーブル４１へ追加することができる。

また、取得部３０は、情報提供サーバ５から施設の利用日に発生する外部要因に関する外部要因情報を取得する。外部要因には、例えば、施設における天候や、施設の周辺で行われるイベント、施設が関わる時事等がある。

例えば、施設における天候の情報として、晴れ、雨、曇り等の天気や、降水確率、予想降雨量、風速、気象警報等の情報がある。施設の周辺で行われるイベントとして、開催期間や、開催場所、イベント内容等の情報がある。施設が関わる時事に関する情報として、施設周辺で事件が起きたことを示す情報や、施設や施設周辺の他の施設がブログやＳＮＳ（Social Networking Service）で話題になったことを示す情報、施設を紹介するテレビ放送が行われたことを示す情報等が含まれる。

生成部３１は、記憶部１１に記憶されたユーザ情報および予約情報を用いた機械学習を実行し、予約に対するキャンセルのリスクを評価する学習モデルであるリスク評価モデルを生成する。生成部３１は、生成したリスク評価モデルの情報を記憶部１１に記憶する。

例えば、生成部３１は、予約に対するキャンセルの有無を目的変数（正解データ）とし、予約情報およびユーザ情報から抽出される各特徴情報を説明変数（素性）とする回帰モデルを学習モデルとして求めることができる。予約情報から抽出される特徴情報には、例えば、施設の利用期間、施設名、施設の地域、利用人数、利用価格、利用部屋数、利用する部屋の広さなどがある。

また、ユーザ情報から抽出される特徴情報には、例えば、予約者であるユーザＵの各属性、予約者であるユーザＵの行動履歴などがある。ユーザＵの属性は、上述したデモグラフィック属性やサイコグラフィック属性である。ユーザＵの行動履歴は、サイトへのアクセス履歴、サイトでのサービスや商品の購入履歴などである。

また、生成部３１は、記憶部１１に記憶した予約情報に基づいて、ユーザＵの予約履歴やユーザＵの他の施設の予約状況を説明変数とすることもできる。例えば、ユーザＵによる過去の施設予約のキャンセル率、ユーザＵが同じ期間に複数の施設を重複予約しているか否かの情報などである。

生成部３１は、例えば、予約に対するキャンセルの有無を目的変数（正解データ）とし、予約情報およびユーザ情報から抽出される各特徴情報を説明変数（素性）とする回帰モデルをリスク評価モデルとして求める。例えば、生成部３１は、下記式（１）に示すような回帰モデルをリスク評価モデルとして求める。
ｙ＝ω_１・ｘ_１＋ω_２・ｘ_２＋・・・＋ω_ｎ・ｘ_ｎ ・・・（１）

上記式（１）において、「ｘ」は、予約情報およびユーザ情報から抽出される各特徴情報に対応する説明変数である。「ｙ」は、予約に対するキャンセルの有無であり、予約に対するキャンセルがある場合には、「ｙ」＝「１」になり、予約に対するキャンセルがない場合には、「ｙ」＝「−１」または「０」になる。

また、上記式（１）において、「ω」は、「ｘ」の係数であり、所定の重み値を示す。具体的には、「ω_１」は、「ｘ_１」の重み値であり、「ω_２」は、「ｘ_２」の重み値であり、「ω_ｎ」は、「ｘ_ｎ」の重み値である。このように、上記式（１）は、予約情報およびユーザ情報から抽出された特徴情報に対応する説明変数「ｘ」と、所定の重み値「ω」とを含む変数（例えば、「ω_１・ｘ_１」）を組合せることにより作成される。

なお、生成部３１は、説明変数として扱う情報は、上述した例に限定されない。例えば、生成部３１は、施設の利用日の予測される天候、および施設の利用日の曜日といった情報も説明変数として扱うことができる。例えば、施設の利用日で予測される天候が悪い（例えば、暴風、台風、寒波など）とキャンセルの可能性が高くなるため、施設の利用日で予測される天候を説明変数とすることで、キャンセルリスクの推定精度を高めることができる。

また、生成部３１は、受付日時と利用日時との差を説明変数とすることもできる。これは、受付日時と利用日時との差でキャンセルの確率が変わることがあるためである。例えば、受付日時が利用日時の直前である場合、受付日時が利用日時から離れている場合に比べて、予約がキャンセルされる可能性は低い。そのため、受付日時と利用日時との差を説明変数とすることで、キャンセルリスクの推定精度を高めることができる。

また、生成部３１は、周辺の施設の予約状況（例えば、予約率）、利用日時におけるイベント（音楽イベント、スポーツイベント、コミックマーケットなど）の種類毎の開催の有無などをそれぞれ説明変数とすることもできる。

なお、生成部３１は、全ての施設に共通のリスク評価モデルを生成することもでき、ｎ（ｎは自然数）以上の施設毎や施設の種別（例えば、ホテル、旅館、ペンションなどの宿泊施設の種別、中華、和食、イタリアンなどの飲食店の種別）毎にリスク評価モデルを生成することもできる。また、生成部３１は、季節毎にリスク評価モデルを生成することもできる。また、生成部３１は、ユーザ情報を用いずにリスク評価モデルを生成することもできる。

また、生成部３１は、ＳＶＭ（Support Vector Machine）やその他の機械学習法を用いて、リスク評価モデルを生成することもできる。また、生成部３１は、深層学習（ディープラーニング）の技術を用いてリスク評価モデルを生成することもできる。例えば、生成部３１は、ＤＮＮ（Deep Neural Network）やＲＮＮ（Recurrent Neural Network）やＣＮＮ（Convolutional Neural Network）等の種々のディープラーニングの技術を適宜用いてリスク評価モデルを生成することができる。

推定部３２は、取得部３０によって取得された予約情報に基づいて、キャンセルリスクを推定する。例えば、推定部３２は、取得部３０によって取得された予約情報に含まれるユーザＩＤに関連付けられたユーザＵの属性情報や行動履歴を含むユーザ情報を記憶部１１から抽出する。

そして、推定部３２は、抽出したユーザ情報と取得部３０によって取得された予約情報から抽出される複数の特徴情報を説明変数とする上記式（１）のリスク評価モデルを用いて、キャンセルスコアＳｃを演算することができる。具体的には、推定部３２は、下記式（２）の演算によって、キャンセルスコアＳｃを演算することができる。推定部３２は、演算した結果を予約情報テーブル４２に追加する。
Ｓｃ＝ω_１・ｘ_１＋ω_２・ｘ_２＋・・・＋ω_ｎ・ｘ_ｎ ・・・（２）

決定部３３は、推定部３２によって推定されたキャンセルリスクに基づいてオーバーブッキング可能な過剰枠数を決定する。例えば、決定部３３は、施設の利用日における予約済枠数（図６参照）のキャンセルスコアの平均値を算出し、かかる平均値に基づいて過剰枠数を決定する。

また、決定部３３は、例えば、キャンセルリスクに基づいてキャンセルが発生する予約枠数の確率分布を生成し、かかる確率分布に基づいて過剰枠数を決定する。ここで、図７Ａおよび図７Ｂを用いて、確率分布を用いた過剰枠数の決定処理について説明する。

図７Ａおよび図７Ｂは、決定部３３による過剰枠数の決定処理を示す図である。図７Ａおよび図７Ｂは、横軸にキャンセル数（キャンセルが発生する予約枠数）を示し、縦軸に各キャンセル数の発生確率を示したグラフを示す。なお、図７Ａおよび図７Ｂでは、キャンセルリスクの平均値は同じであることとする。

図７Ａおよび図７Ｂに示すように、決定部３３は、キャンセル数を確率変数とし、予約毎のキャンセルリスクに基づいて各キャンセル数の発生確率を算出し、確率分布にプロットする。

また、決定部３３は、例えば、モンテカルロシミュレーションを用いて確率分布を生成することができる。具体的には、決定部３３は、キャンセルスコアＳｃの演算に用いる各説明変数について、各説明変数のゆらぎ（例えば、気温は、平均ＸＸ℃で、標準偏差ＹＹ℃の正規分布や、天候は、晴れおよび雨の確率比）に応じて、乱数を用いてシミュレーションを行うことで説明変数を生成する。そして、決定部３３は、生成した説明変数を用いたキャンセルスコアＳｃに基づいて全予約（予約済枠数）から生じるキャンセル数を算出する。そして、決定部３３は、算出したキャンセル数を１サンプルし、複数サンプルを集積することでキャンセル数の確率分布を生成する。

ここで、図７Ａおよび図７Ｂに示すように、キャンセルリスクの平均値が同じであったとしても、確率変数であるキャンセル数の発生確率は異なる場合がある。つまり、キャンセルリスクの平均値が同じであったとしても、確率分布の分布形状は異なる場合がある。

具体的には、分布の山がともにキャンセル数「２」であったとしても、図７Ａの分布の山は、図７Ｂの分布の山に比べて急峻な形状となっている。換言すれば、図７Ａの確率分布では、キャンセル数「２」の発生確率Ｐ２ａは、キャンセル数「１」の発生確率Ｐ１ａに比べて顕著に高い。一方、分布の山が緩やかな図７Ｂの確率分布では、キャンセル数「２」の発生確率Ｐ２ｂは、キャンセル数「１」の発生確率Ｐ１ｂに比べてわずかに高い程度である。

つまり、図７Ａの確率分布は、キャンセル数「２」の確率変数が他の確率変数に比べて顕著に起こりやすい確率分布であり、図７Ｂの確率分布は、キャンセル数「２」以外の他確率変数も比較的起こりやすい確率分布であるといえる。

そこで、決定部３３は、かかる確率分布に基づいて過剰枠数を決定する。例えば、図７Ａに示すように、決定部３３は、分布の山であるキャンセル数「２」の発生確率Ｐ２ａと、キャンセル数「１」の発生確率Ｐ１ａとの差分が所定の閾値以上である場合、キャンセル数「２」を過剰枠数として決定する。つまり、図７Ａでは、キャンセル数「２」となる確率が極めて高いため、過剰枠数「２」に決定する。

また、例えば、図７Ｂに示すように、決定部３３は、分布の山であるキャンセル数「２」の発生確率Ｐ２ｂと、キャンセル数「１」の発生確率Ｐ１ｂとの差分が所定の閾値未満である場合、キャンセル数「１」を過剰枠数として決定する。つまり、図７Ｂでは、キャンセル数「２」に比べてキャンセル数「１」も比較的起こりやすいため、安全側をとって過剰枠数「１」に決定する。

このように、決定部３３は、キャンセル数の確率分布を用いることで、オーバーブッキング可能な過剰枠数を精度よく決定することができる。

なお、決定部３３は、上記で決定した過剰枠数について、さらに所定の枠数だけ減らした過剰枠数を最終的な決定値としてもよい。これにより、利用日において実際に施設を利用する数が予約枠数を超えてしまう状況を高精度に回避することができる。

また、決定部３３は、外部要因情報を加味して過剰枠数を決定してもよい。具体的には、決定部３３は、キャンセルリスクおよび外部要因に基づいて過剰枠数を決定する。例えば、決定部３３は、キャンセルリスクと、外部要因との相関をモデル化し、かかるモデルに基づいて過剰枠数を決定する。

具体的には、決定部３３は、キャンセルリスクが所定値の場合に、施設で雨が降ると、キャンセルリスクが所定値よりも高くなることをモデルとして生成する。より具体的には、決定部３３は、降水確率毎、降水量毎、最高気温（あるいは最低気温）毎、風速毎にモデルを生成してもよい。このように、施設の外部要因を加味することで、過剰枠数を精度よく決定することができる。

なお、決定部３３は、キャンセルリスクと外部要因との相関をモデル化する場合に限らず、例えば、推定部３２によって外部要因を加味して推定されたキャンセルリスクを取得することとしてもよい。

なお、決定部３３による過剰枠数の決定処理のタイミングは、任意に行ってよい。例えば、決定部３３は、予約が登録される毎に過剰枠数の決定処理を行ってもよく、あるいは、取得部３０が所定の間隔で外部要因情報を取得し、施設の外部要因に変化がある毎に、過剰枠数を決定してもよい。かかる点について、図８を用いて説明する。

図８は、決定部３３による過剰枠数の決定処理を示す図である。図８では、外部要因である施設の天気予報が晴れから雨に変化した場合の決定処理について説明する。なお、図８の上段のグラフは、天気予報が晴れの場合の確率分布を示しており、決定部３３は、かかる確率分布を用いた場合、過剰枠数「２」に決定していることとする。

図８に示すように、例えば、施設における利用日の天気予報が晴れから雨に変化した場合、決定部３３は、外部要因が晴れの場合の確率分布を、外部要因が雨の場合の確率分布に生成し直す。

そして、決定部３３は、生成し直した確率分布に基づいて過剰枠数を補正する。図８の下段に示す例では、雨の場合の確率分布において、分布の山がキャンセル数「３」にシフトし、かつ、キャンセル数「１」および「２」の発生確率が極めて低くなっている。かかる場合に、決定部３３は、晴れの場合の確率分布に基づき決定された過剰枠数「２」を「３」に補正する。

このように、決定部３３は、施設の外部要因の変化に合わせて過剰枠数を補正することで、例えば、天気予報が晴れから雨に変わった場合にキャンセルが多くなることを想定した過剰枠数を決定できるため、過剰枠数を精度よく決定することができる。

図３に戻って提供部３４について説明する。提供部３４は、決定部３３によって決定された過剰枠数に基づく提供情報を提供する。例えば、提供部３４は、決定した過剰枠数を含む提供情報を施設事業者へ提供する。あるいは、提供部３４は、施設の予約可能数（予約枠数および過剰枠数の合算）を含む提供情報を提供してもよく、予約可能数から予約済枠数を減算した現在予約可能枠数を含む提供情報を提供してもよい。

これにより、施設事業者は、提供情報に基づいて設定すべき過剰枠数を判断できるため、設定すべき過剰枠数を精度よく判断できる。

また、提供部３４による提供情報の提供タイミングは、任意であってよい。例えば、提供部３４は、施設事業者から取得要求を受け付けた場合に、提供情報を提供してもよい。かかる場合、決定部３３は、取得要求を受け付けたタイミングで過剰枠数の決定処理を行い、提供部３４は、かかるタイミングで決定された過剰枠数を含む提供情報を提供する。

これにより、施設事業者が必要とするときに限って提供情報を提供できる、換言すれば
不必要に提供情報が提供されることを防止できる。なお、提供部３４は、施設事業者から取得要求を受け付けた場合に、提供情報を提供する場合に限らず、例えば、施設の外部要因が変化する毎に提供情報を提供してもよい。

また、提供情報の提供先は、施設事業者に限らず、例えば、予約サーバ３であってもよい。例えば、予約サーバ３は、提供情報に基づいて施設情報テーブル４３の過剰枠数を更新する。

図９を用いて、実施形態に係る情報処理装置１が実行する処理の処理手順について説明する。図９は、実施形態に係る情報処理装置１が実行する処理の処理手順を示すフローチャートである。

図９に示すように、提供部３４は、施設事業者から取得要求があったか否かを判定する（ステップＳ１０１）。取得部３０は、施設事業者から取得要求があった場合（ステップＳ１０１，Ｙｅｓ）、予約情報を取得する（ステップＳ１０２）。

つづいて、取得部３０は、施設の外部要因に関する情報である外部要因情報を取得する（ステップＳ１０３）。推定部３２は、取得した予約情報に基づいてキャンセルリスクを推定する（ステップＳ１０４）。

つづいて、決定部３３は、キャンセルリスクおよび外部要因に基づいてキャンセルが発生する予約枠数の確率分布を生成する（ステップＳ１０５）。つづいて、決定部３３は、生成した確率分布に基づいて過剰枠数を決定する（ステップＳ１０６）。

つづいて、提供部３４は、決定部３３によって決定された過剰枠数に基づく提供情報を施設事業者へ提供し（ステップＳ１０７）、処理を終了する。一方、ステップＳ１０１において、提供部３４は、施設事業者から取得要求がなかった場合（ステップＳ１０１，Ｎｏ）、処理を終了する。

上述した実施形態における情報処理装置１は、それぞれ例えば図９に示すような構成のコンピュータ２００がプログラムを実行することによって実現される。

図１０は、実施形態に係るプログラムを実行するコンピュータのハードウェア構成の一例を示す図である。コンピュータ２００は、ＣＰＵ２０１、ＲＡＭ２０２、ＲＯＭ２０３、ＨＤＤ２０４、通信インターフェイス（Ｉ／Ｆ）２０５、入出力インターフェイス（Ｉ／Ｆ）２０６、およびメディアインターフェイス（Ｉ／Ｆ）２０７を備える。

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

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

ＣＰＵ２０１は、入出力インターフェイス２０６を介して、ディスプレイやプリンタ等の出力装置、および、キーボードやマウス等の入力装置を制御する。ＣＰＵ２０１は、入出力インターフェイス２０６を介して、入力装置からデータを取得する。また、ＣＰＵ２０１は、生成したデータを、入出力インターフェイス２０６を介して出力装置へ出力する。

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

コンピュータ２００のＣＰＵ２０１は、ＲＡＭ２０２上にロードされたプログラムを実行することにより、上述した取得部３０、生成部３１、推定部３２、決定部３３および提供部３４の機能を実現することができる。また、かかる取得部３０、生成部３１、推定部３２、決定部３３および提供部３４は、それぞれ一部または全部がハードウェアのみで構成されてもよい。

コンピュータ２００のＣＰＵ２０１は、プログラムを、記録媒体２０８から読み取って実行するが、他の例として、他の装置から、ネットワーク６を介してこれらのプログラムを取得してもよい。なお、ＨＤＤ２０４は、記憶部１１に対応し、記憶部１１と同様のデータを記憶する。また、ＨＤＤ２０４に代えて、ＲＡＭ、フラッシュメモリ等の半導体メモリ素子、または、光ディスク等の記憶装置を用いてもよい。

実施形態に係る情報処理装置１は、取得部３０と、推定部３２と、決定部３３とを備える。取得部３０は、所定の予約枠数を有する施設の予約に関する情報である予約情報を取得する。推定部３２は、取得部３０によって取得された予約情報に基づいて、予約のキャンセルが発生するリスクであるキャンセルリスクを推定する。決定部３３は、推定部３２によって推定されたキャンセルリスクに基づいて施設においてオーバーブッキング可能な予約枠数である過剰枠数を決定する。これにより、オーバーブッキング可能な予約枠数を精度よく決定することができる。

また、推定部３２は、予約毎のキャンセルリスクを推定する。決定部３３は、予約毎のリスクに基づいてキャンセルが発生する予約枠数の確率分布を生成し、当該確率分布に基づいて過剰枠数を決定する。このように、確率分布を用いることで、過剰枠数を精度よく決定することができる。

また、取得部３０は、施設の利用日に発生する外部要因に関する外部要因情報を取得する。決定部３３は、キャンセルリスクおよび外部要因に基づいて過剰枠数を決定する。このように、外部要因を加味して過剰枠数を決定することで、過剰枠数を精度よく決定することができる。

また、外部要因は、施設における天候、施設の周辺で行われるイベントおよび施設が関わる時事の少なくとも一つを含む。これにより、過剰枠数を精度よく決定することができる。

また、取得部３０は、外部要因情報を所定の間隔で取得する。決定部３３は、外部要因に変化がある毎に、過剰枠数を決定する。これにより、施設の外部要因の変化に合わせて過剰枠数を補正できる。

また、情報処理装置１は、提供部３４を備える。提供部３４は、決定部３３によって決定された過剰枠数に基づく提供情報を提供する。これにより、例えば、施設事業者は、提供情報に基づいて設定すべき過剰枠数を精度よく判断することができる。

また、提供部３４は、施設事業者から取得要求を受け付けた場合に、提供情報を提供する。これにより、施設事業者が必要な時に限って提供情報を提供できる、換言すれば、不必要に提供情報が提供されることを防止することができる。

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

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

以上、上記実施形態を用いて本発明を説明したが、本発明の技術的範囲は上記実施形態に記載の範囲には限定されない。上記実施形態に多様な変更または改良を加えることが可能であることが当業者には明らかである。また、そのような変更または改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。

１ 情報処理装置
２，２_１〜２_ｎ 端末装置
３ 予約サーバ
４，４_１〜４_ｍ 施設装置
５ 情報提供サーバ
６ ネットワーク
１０，５０ 通信部
１１，５１ 記憶部
１２，５２ 制御部
２０ ユーザ情報ＤＢ
２１ 予約情報ＤＢ
２２ 施設情報ＤＢ
３０ 取得部
３１ 生成部
３２ 推定部
３３ 決定部
３４ 提供部
４１ ユーザ情報テーブル
４２ 予約情報テーブル
４３ 施設情報テーブル
１００ 情報処理システム

Claims (10)

1. 所定の予約枠数を有する施設の予約に関する情報である予約情報を取得する取得部と、
   前記取得部が取得した前記予約情報に基づいて前記予約のキャンセルが発生するリスクを推定する推定部と、
   前記推定部によって推定された前記リスクに基づいて前記施設においてオーバーブッキング可能な予約枠数である過剰枠数を決定する決定部と
   を備えることを特徴とする情報処理装置。
2. 前記推定部は、
   前記予約毎の前記リスクを推定し、
   前記決定部は、
   前記予約毎の前記リスクに基づいて前記キャンセルが発生する予約枠数の確率分布を生成し、当該確率分布に基づいて前記過剰枠数を決定すること
   を特徴とする請求項１に記載の情報処理装置。
3. 前記決定部は、
   モンテカルロシミュレーションを用いて前記確率分布を生成すること
   を特徴とする請求項２に記載の情報処理装置。
4. 前記取得部は、
   前記施設の利用日に発生する外部要因に関する外部要因情報をさらに取得し、
   前記決定部は、
   前記リスクおよび前記外部要因に基づいて前記過剰枠数を決定すること
   を特徴とする請求項２または３に記載の情報処理装置。
5. 前記外部要因は、
   前記施設における天候、前記施設の周辺で行われるイベント、および、前記施設が関わる時事の少なくとも一つを含むこと
   を特徴とする請求項４に記載の情報処理装置。
6. 前記取得部は、
   前記外部要因情報を所定の間隔で取得し、
   前記決定部は、
   前記外部要因に変化がある毎に、前記過剰枠数を決定すること
   を特徴とする請求項４または５に記載の情報処理装置。
7. 前記決定部によって決定された前記過剰枠数に基づく提供情報を提供する提供部をさらに備えること
   を特徴とする請求項１〜６のいずれか１つに記載の情報処理装置。
8. 前記提供部は、
   前記施設の事業者から取得要求を受け付けた場合に、前記提供情報を提供すること
   を特徴とする請求項７に記載の情報処理装置。
9. コンピュータが実行する情報処理方法であって、
   所定の予約枠数を有する施設の予約に関する情報である予約情報を取得する取得工程と、
   前記取得工程が取得した前記予約情報に基づいて前記予約のキャンセルが発生するリスクを推定する推定工程と、
   前記推定工程によって推定された前記リスクに基づいて前記施設においてオーバーブッキング可能な予約枠数である過剰枠数を決定する決定工程と
   を含むことを特徴とする情報処理方法。
10. 所定の予約枠数を有する施設の予約に関する情報である予約情報を取得する取得手順と、
    前記取得手順が取得した前記予約情報に基づいて前記予約のキャンセルが発生するリスクを推定する推定手順と、
    前記推定手順によって推定された前記リスクに基づいて前記施設においてオーバーブッキング可能な予約枠数である過剰枠数を決定する決定手順と
    をコンピュータに実行させることを特徴とする情報処理プログラム。

Images