宿泊予約サイトを用いた地域特性の調査

　現在、宿泊予約サイトの普及により日本国内のほぼ全ての宿泊施設の情報はインターネット上で閲覧できる。宿泊予約サイトとは、インターネット上で宿泊の予約ができるWebサービスである。従来の一般的な宿泊予約方法である電話予約と比べて24時間予約可能な利便性や、ポイントが貯まる等の点から現代において最も多く利用される宿泊予約の方法であると言える。古くはJTBやHISなど旅行会社のサービスをオンライン化したものであったが、現在ではじゃらんや楽天トラベルなどのオンライン専用のものが日本国内では一般的とされている宿泊予約サイトである。宿泊予約サイトは、宿泊希望の日にちなどを入力することで条件に合った宿泊施設の一覧を表示する。さらに宿泊客が入力した情報を使い宿泊予約の手続きを代行する。（図1）

　宿泊予約サイトからは様々な情報が得られる。その中でも本研究では宿泊施設の総合評価とユーザーレビューの文字数に着目しデータ収集及び分析を行う。総合評価とは、食事や温泉・立地などの要素を実際に宿泊したユーザーが考慮し、全ての要素を総合的に判断した宿泊施設に対する評価である。ユーザーレビューとは、宿泊した際に感じた満足な点や不満な点が書かれている宿泊客によるコメントである。総合評価とユーザーレビューは実際には以下の図2の様なデータである。

　図2を見て分かる様に、ユーザーレビューは実際の部屋の清潔さやそれに対する従業員の対応の様子といった情報が記載されている。宿泊施設の公式サイトだけでは知り得ない情報が得られるので、宿泊予約をする際にはユーザーレビューは非常に参考になるものである。一方総合評価はユーザーレビューほど詳細な情報を含んではいないが、宿泊施設の評価を☆の数で知る事が出来る。よって総合評価は簡易的に宿泊施設の評価を知りたい時に有用である。本研究では、これら総合評価とユーザーレビューの二つのデータを一つの宿のパラメータとして設定し、地域ごとにデータ収集する。そのデータをクラスタ分析することで地域特性の分析を行う。分析の結果、各地域ごとにクラスタ構造に違いが見られた。さらにクラスタ分析の結果を考察する事で各地域の客層などが見えてくる事が分かった。

2.　準備

2.1.　楽天トラベル

2.1.1.　楽天トラベルとは

　楽天トラベルは日本国内の代表的な宿泊予約サイトの一つであり、宿泊施設の予約のみでなく高速バスやレンタカーの予約も可能な旅行に関する総合予約サイトである。図3は楽天トラベルのホーム画面である。楽天会員でなくとも利用する事ができるが、楽天会員であれば各種予約の決済の度に楽天スーパーポイントを貯める事ができる。

　本研究では、この楽天トラベルから総合評価とユーザーレビューのデータを収集し分析を行う。研究対象として重要なのは、APIを公開している点である。

2.1.2.　楽天トラベルでの宿泊予約の方法

　本節では、楽天トラベルを用いて実際に宿泊施設を検索する様子を説明する。前提条件として、宿泊地は兵庫県のJR三ノ宮駅周辺で宿泊人数は二人、日程は2019年3月4日から一泊とする。

　まずは楽天トラベルのホーム画面のキーワードを探すの項目から駅名にチェックを入れて三ノ宮駅と入力。（図4）

　続いて他の検索条件を入力する画面（図5）に宿泊日程・人数などを入力する。なお、表示順序をここで設定しておくことが推奨される。そうする事で目的の宿泊施設を見つけやすくなる。今回は料金の安い順に設定する。

　図6は図5の条件で検索を行った結果の一部である。楽天トラベルではこの様に最低限の検索条件を入力することで希望にあった宿泊施設の情報の一覧を見る事ができる。

　さらに、各宿泊施設のお客様の声の項目をクリックする事で総合評価とユーザーレビューが閲覧できる。（図7）

図7. ホテルリブマックス神戸三宮の総合評価とユーザーレビュー

　この様に楽天トラベルでは希望の宿泊条件を入力する事で条件に合った宿泊施設の情報を閲覧できる。

2.2.　楽天トラベル系API

　APIはURLを指定する事で目的のデータを取得するものである。だが今回は楽天が公開しているURLを指定せずにパラメータを指定するだけでデータが取得できる楽天トラベル系APIのWebページを使用する。楽天トラベル系APIには図8の通り七つの種類がある。取得できるデータの例として施設情報や空室状況、その他にも地区コードや宿のランキングを取得することができる。本研究で用いるのは楽天トラベル施設検索APIと楽天トラベル地区コードAPIの二つである。楽天トラベル施設検索APIでは、特定地域の宿泊施設のデータを一度に最大で30件取得できる。楽天トラベル地区コードAPIではデータを収集したい地域のパラメータとなる楽天トラベル地区コードを取得できる。これら二つの使い方や詳細については3章で説明する。

3.　データ分析の手法

3.1.　データの収集方法

　本節では楽天トラベル施設検索APIと楽天トラベル地区コードAPIを用いて宿の総合評価とユーザーレビューのデータを収集する手法について述べる。

　まず始めに、Rakuten Developersのページから各地域の楽天トラベル地区コードを取得する。具体的な手順は以下の通りである。

1.　Rakuten Developersの楽天トラベル地区コードAPIのページを開く。（図9）

3.　パラメータの左をlargeclasscode、右をjapanに設定する。（図10）

　以下の図11は楽天トラベル地区コードの取得結果の一部である。取得したデータは"データの種類"："データの値"といったJSONでの表記となっている。

　続いて楽天トラベル施設検索APIで宿泊施設の情報を収集する。具体的な手順は以下の通りである。

1.　Rakuten Developersの楽天トラベル施設検索APIのページを開く。（図12）

3.　データを収集したい地域の楽天トラベル地区コードをパラメータに入力する。（図13）

　以上のパラメータ設定で、日本の北海道札幌市内の札幌・新札幌・琴似エリアを指定した事になる。多くのエリアはlargeClasscodeからsmallClasscodeまでの指定で良い。しかし細かく分類されている一部のエリアはdetailClasscodeを指定する必要がある。

図13. APIテストフォームのパラメータ入力例（札幌・新札幌・琴似エリア）

　図14は札幌・新札幌・琴似エリアを指定し、データを取得した結果の一部である。一つの宿につき宿名、電話番号、住所に加えて宿泊客の評価とユーザーレビューなどが取得できる。本研究ではこのデータの中から総合評価（review Average）とユーザーレビューを記録していく。なお、ユーザーレビューは宿ごとに最新１件のレビューが表示される。図14では一つの宿のデータが表示されているが、実際には30件の宿のデータを同時に取得している。こうして得られた30件全ての宿泊施設の総合評価と最新レビューのデータを収集し、地域ごとにまとめる。

　なお、宿泊施設によってはユーザーレビューが正常に取得できない場合がある。図15は京都　嵐山温泉　渡月亭という旅館のデータである。ユーザーレビューの項目を見ると"null"と表示されていてデータが取得できていない事が分かる。

　楽天トラベルにて同旅館を検索すると図16の様に161件のユーザーレビューが確認できた。この事から楽天トラベル施設検索APIでデータ取得に失敗する原因は宿泊施設のユーザーレビューが一件も存在しないという事では無く、何か別の原因によるものであると考えられる。レビュー内容も図17の様に特別なものではなく、他の正常にレビューを取得できている旅館との差異は無いように思える。

図16. データ取得に失敗した宿泊施設の楽天トラベルでの検索結果

3.2.　情報の可視化

　楽天トラベル施設検索APIによって各エリアごとに宿のreview Averageとuser Reviewの文字数を取得し、横軸を最新レビューの文字数、縦軸を総合評価（review Average）として散布図を描くと以下の図18の様になる。グラフ右端に点のまとまりがあるが、これは取得できるレビュー文字数の上限が100文字であることによってどのグラフにも自然と発生するものである。

　以降は日本の各地域を呼称する際に、簡単の為以下の様に呼称する。

札幌・新札幌・琴似エリア　　　　　　　　　　　　　　　　　　→　札幌エリア

洞爺・室蘭・登別エリア　　　　　　　　　　　　　　　　　　　→　洞爺エリア

青森・浅虫温泉エリア　　　　　　　　　　　　　　　　　　　　→　青森エリア

秋田エリア　　　　　　　　　　　　　　　　　　　　　　　　　→　秋田エリア

山形・蔵王・天童・上山エリア　　　　　　　　　　　　　　　　→　山形エリア

上越・糸魚川・妙高エリア　　　　　　　　　　　　　　　　　　→　上越エリア

水戸・笠間エリア　　　　　　　　　　　　　　　　　　　　　　→　水戸エリア

つくば・土浦・取手エリア　　　　　　　　　　　　　　　　　　→　つくばエリア

大宮・浦和・川口・上尾エリア　　　　　　　　　　　　　　　　→　大宮エリア

新橋・汐留・浜松町・お台場エリア　　　　　　　　　　　　　　→　新橋エリア

東京駅・銀座・秋葉原・東陽町・葛西エリア　　　　　　　　　　→　東京エリア

横浜エリア　　　　　　　　　　　　　　　　　　　　　　　　　→　横浜エリア

銚子・旭・九十九里・東金・茂原エリア　　　　　　　　　　　　→　銚子エリア

甲府・湯村・昇仙峡エリア　　　　　　　　　　　　　　　　　　→　甲府エリア

諏訪湖エリア　　　　　　　　　　　　　　　　　　　　　　　　→　諏訪湖エリア

浜松・浜名湖・天竜エリア　　　　　　　　　　　　　　　　　　→　浜松エリア

名古屋駅・伏見・丸の内エリア　　　　　　　　　　　　　　　　→　名古屋エリア

四日市・桑名・湯の山・長島温泉エリア　　　　　　　　　　　　→　四日市エリア

京都駅エリア　　　　　　　　　　　　　　　　　　　　　　　　→　京都エリア

大阪駅・梅田・ユニバーサルシティ・尼崎エリア　　　　　　　　→　大阪エリア

神戸・有馬温泉・六甲山エリア　　　　　　　　　　　　　　　　→　神戸エリア

高松・さぬき・東かがわエリア　　　　　　　　　　　　　　　　→　高松エリア

高知・南国・香南・伊野エリア　　　　　　　　　　　　　　　　→　高知エリア

岡山エリア　　　　　　　　　　　　　　　　　　　　　　　　　→　岡山エリア

倉敷・総社・玉野・笠岡エリア　　　　　　　　　　　　　　　　→　倉敷エリア

下関・宇部エリア　　　　　　　　　　　　　　　　　　　　　　→　下関エリア

博多・キャナルシティ・海の中道・太宰府・二日市エリア　　　　→　博多エリア

別府・日出エリア　　　　　　　　　　　　　　　　　　　　　　→　別府エリア

宮崎エリア　　　　　　　　　　　　　　　　　　　　　　　　　→　宮崎エリア

那覇エリア　　　　　　　　　　　　　　　　　　　　　　　　　→　那覇エリア

4.　最新レビューの文字数―総合評価グラフのクラスタ構造

　図19と図20は三章で述べた手法で別府エリアと東京エリアの宿の総合評価と最新レビューの文字数を可視化したグラフである。

　図19の別府エリアは最新レビューの文字数40と100にクラスタがあるように見える。このうち40文字付近のクラスタを中間文字数クラスタと呼ぶ。一方、図20の東京エリアは最新レビューの文字数100のクラスタはあるが、40のクラスタは見えず、中間文字数クラスタが生じていない。

　本研究ではこの様に最新レビューの文字数－総合評価グラフにおけるクラスタ構造に着目し、クラスタ構造とエリアの関係を導き出す事を考えた。

　その他、データ収集を行ったエリアのグラフを以下に示す。

5.　クラスタ分析による実験

5.1.　実験内容

　各地域におけるクラスタ構造を詳細に分析する為、クラスタ分析を行う。クラスタ分析にはRapidminerを用いる。まずは三章で行ったのと同様の方法で各地域ごとの宿泊施設の総合評価と最新レビューの文字数を取得する。その上でクラスタ分析を行う事で、各エリアのデータがいくつのまとまりに分類できるか、つまりはクラスタ構造が確認できる。図49の様に別府エリアのグラフはクラスタ数が2であると即時に判断できる。しかし図50の東京エリアの様な広範囲に点が散布しているグラフはクラスタ数を求める事が困難である為、クラスタ分析を行う必要がある。

　Rapidminerを用いたクラスタ分析の手順は以下の通りである。ProcessのOperatorの配置と配線は図51の通りである。

※事前準備として、Import Dataで分析したいエリアのデータを全てRapidminerに読み込んでおく

②分析する変数（今回はreview Aと最新レビューの文字数）を選択する。

　Parametersのattribute filter typeをsubsetに指定し、Select Attributesで分析する変数を選択する。

　Parametersのattribute filter typeをsubsetに指定し、Select Attributesで②で選択した変数を指定する。

　ParametersのEdit Listでattribute nameを二つ定義する。（p1とp2とする）

　続いてp1とp2の計算式を入力する。それぞれの電卓のアイコンをクリックしてp1はpc_1、p2の計算式はpc_2に指定する。

※pc_1とpc_2とは、主成分分析の結果生成された新たな二つの変数PC1とPC2を表している。（図52）

　filter typeをsubsetに指定し、Select Attributesで分析する変数を選択する。

　Parametersのattribute filter typeをsubsetに指定し、Select Attributesでp1とp2を選択する。

　クラスタ数を求めるには、①～⑦の手順以降に以下の作業を行う。

1.　⑦のClustering（k-means）のParametersのkを2に指定する。（図53）

　図54の通りグラフの中央でデータが二分されており、正常にクラスタ分析が行われている事が確認できる。なお、正常にクラスタ分析ができているかは明らかに近接したデータが異なるクラスタに分類されている状況が発生しているかどうかで判断する。

3.　Clustering（k-means）のParametersのkを3に指定し、再びProcessを実行して結果を表示させる。

　k=3に設定すると、k=2の時には一つのクラスタだった右側のデータが二つのクラスタに分けられている事が図55から分かる。明らかに近接したデータが異なるクラスタに分類されている様な状況は発生していないのでこちらも問題なくクラスタ分析できていると言える。

4.　Clustering（k-means）のParametersのkを4に指定し、再びProcessを実行して結果を表示させる。

　図56を見るとグラフ左側のデータが二つのクラスタに分けられている事が分かる。正常にクラスタ分析できているかの判断は保留する。

5.　Clustering（k-means）のParametersのkを5に指定し、再びProcessを実行して結果を表示させる。

　図57はk=5で東京エリアのクラスタ分析を行った結果であるが、矢印で指し示した付近で明らかに近接したデータが異なるクラスタに分類されている事が確認できる。これは正常にクラスタ分析ができているとは言えず、このことから東京エリアのクラスタ数が5ではないと言える。

6.　k=3とk=4のクラスタ分析の結果を見てどちらが適切か判断する。

　クラスタ数を求めるには、正常にクラスタ分析ができるkの値の最大値を求める事が必要である。現時点で正常にクラスタ分析ができているとされるkの値の最大値は3である。判断を保留にしたk=4のグラフが正常にクラスタ分析できていると判断できれば東京エリアのクラスタ数は4という事になる。だがk=4のグラフが正常にクラスタ分析できていない場合は東京エリアのクラスタ数は3であるという結果になる。k=4のグラフ（図56）では左側のデータ群を二つに分けているが、これは自然な分け方ではないと判断し、k=4のクラスタ分析の結果は不適切であると結論づける。

　よって、東京エリアのクラスタ数は3である。この様にk-means法を用いてkの値を2から1づつ上げていき、正常にクラスタ分析が行われるkの最大値を求める事で各エリアのクラスタ数を求める。

5.2.　実験結果

　クラスタ分析を行った地域とその結果を表1に示す。なお、以降は各地域を呼称する際に○○エリアと呼称せず○○と呼称する。

表1.クラスタ分析の結果

k=2のエリア	洞爺、秋田、横浜、甲府、京都、大阪、岡山、高松、下関、別府、宮崎、那覇
k=3のエリア	札幌、青森、山形、上越、水戸、つくば、大宮、東京、諏訪湖、浜松、四日市、名古屋、神戸、倉敷、高知、博多
k=4のエリア	銚子
k=5のエリア	新橋

5.3.　考察

　表1を見ると、同じ東京都でも東京はk=3なのに対して、新橋のクラスタ数は5と異常に多い事が分かる。東京は主に東京駅周辺のエリアであり、新橋は新橋駅周辺のエリアである事から二つのエリアは立地的にはあまり差が無い。だがクラスタ数が3と5で大きく差がある事から東京エリアの客層と新橋エリアの客層には何らかの違いがあると考えられる。

　k=2のエリアを見ると、観光地として有名な京都が含まれている。他にも横浜と大阪を除けば洞爺・甲府・別府・宮崎・那覇などの観光地としての印象が強いエリアが目立つ。一方でk=3のエリアは札幌・東京・名古屋・博多などの人口が多くビジネス客が多く存在すると考えられるエリアが分類されている。

　よってクラスタ分析の結果、以下の3つの仮説が立てられる。

1.　同じ都道府県内の近接したエリアでもクラスタ数に差が出る場合がある。

2.　クラスタ数が少ないエリアは、観光地である傾向がある。

3.　ビジネスユーザーが多く存在するエリアはクラスタ数が多くなる傾向がある。

5.4.　付録

　今回の実験でクラスタ分析を行った地域のクラスタの様子を以下に示す。

6.　おわりに

　本研究では、楽天トラベル施設検索APIを用いて日本の各地域の宿泊施設の総合評価と最新レビューの文字数のデータを収集し、Rapidminerを用いてクラスタ分析を行う事で地域特性を分析した。

　クラスタ分析の結果、クラスタ数で各地域における違いが見られ、これによりユーザーの特性が分かる事が見えてきた。本研究ではユーザーレビューの文字数を用いた分析しか行っていないが、レビューの内容も分析する事で各地域におけるユーザー分布を確認できる可能性がある。各地域にはどういった客層があるのかを調査し、本研究で得られたクラスタ数のデータと照らし合わせる事で客層とクラスタ数の関係性をより明確にすることが今後の課題である。