成蹊大学理工学研究報告
J. Fac. Sci. Tech., Seikei Univ.
Vol.42 No.1 (2005) pp.13-18

次世代型宿泊予約システムの開発
飯田

善久＊1, 中島 玲子＊2, 宮本 聡子＊2

Development of a Reservation System for Japanese Style Hotels using a New Business ModelYoshihisa IIDA＊1, Reiko NAKAJIMA＊2, Satoko MIYAMOTO＊2,ABSTRACT：The World Wide Web Consortium (W3C) published eXtensive Markup Language (XML)in February 1998. Many organizations (for example, Rosetta Net, OTA), thereafter, began to establish
standard EDI formats using XML in their fields. On the other hand, Ministry of Land, Infrastructure andTransport of Japan started “Visit Japan Campaign” to increase foreign tourists who visit Japan. In
cooperation of this campaign, EC Promotion Organization for Travel Industry began to inspect thebusiness process of Japanese style hotels and proposed a new business model which has and controls
inventory at hotels by themselves. Moreover, it developed a standard format using XML for reservationof Japanese style hotels. This report describes a trial reservation system for Japanese hotels using theproposed new business model and the XML standard.
Keywords：XML, Web service, Reservation system, EDI(Received March 25, 2005)

１．はじめにが進行中であり，その一助として，旅行電子商取引促進機構を中心にして，日本独特の宿泊施設である「旅館」

EDI推進協議会の2004年度の「国内外のEDI 実態調査を対象にして，国内・国外への旅館情報の発信，国内・[1]

報告書」 に，企業間の電子データ交換の81.7%がインタ国外からの旅館の検索・予約処理が可能なようにするたーネットを利用していることが報告されているように，めに，業務プロセスを精査し，企業間電子データ交換の企業活動において今やインターネットは必要不可欠なも標準化が進められている。[4][5]のとなっている。また，インターネットに関する技術標

ここでは，その成果を活用し，新しいビジネスモデル準も次第に整備され，W3Cにより1998年2月にXML1.0がによる宿泊予約システムの提案とその一部機能を実現し制定され，XMLを用いた電子データ交換が次第に使用さた試作システムについて報告する。

れるようになってきている。この場合，業界等を単位と２．現行の宿泊予約システムとその問題点した標準化が必要になり，すでに，パソコン・電子部品業界のロゼッタネット，米国の航空・ホテル・レンタカ
ー等の旅行関連業界のOTA[2]等，多くの業界で標準化作

従来からのいわゆるリアル店舗を持った旅行会社に加業が進められている。更に，それらを推し進め，世界単え，現在では，数多くのWeb サイトから宿泊施設の予約[3]

一市場を目指したUN/CEFACT とOASIS によるbXMLが可能である。利用者から見ると，いつでも，どこからも次第に形を現わし始めている。

でも予約が出来，便利になったことは事実であるが，そ

一方，わが国では外国人旅行者の訪日を促進する「グの反面，システム運営上多くの問題点が発生してきていローバル観光戦略」いわゆる「Visit Japan キャンペーン」る。すなわち，現在の予約システムは，次のような方式によっている。

＊1

経営・情報工学科教授（Professor, Department of InformationSciences）, iida@is.seikei.ac.jp＊2
経営･情報工学科2004 年度卒業研究生(Undergraduate student, Department of Information Sciences)(図１参照)(1) 宿泊施設を運営する｢宿泊事業者｣は，予約事業者（リアル店舗を持つ旅行会社および予約 Web サイトを構−13−

築して予約を受け付ける事業者）に対して，あらかじめ販売してほしい部屋数を申告する。
（これをブロックと呼ぶ）(2) 予約事業者は，提供されたブロックの範囲内では顧客からの予約を自動的に処理することが可能であるが，それを超えた場合は，人手を介して宿泊事業者に空き部屋がないか問合せる必要がある。特に今後海外からの予約を考えると，この方式では時差もあることから対処が困難になると思われる。
図２(3) 予約事業者が顧客から受けた予約に関する情報（予次世代型宿泊予約システム

約日，部屋数，顧客情報等）は，FAX等で宿泊事業3．2者に送られてくるので，宿泊事業者は自社の館内管理システム（PMS : Property Management System）に商品と素材

従来の旅館では，１泊２食で何円，素泊まりでいくら再入力しなければならない。

といった形で宿泊を引き受けるのが通例であったが，日帰り入浴での旅館の利用，最寄りの空港からの送迎バス付きのサービス，あるいは周辺観光地へのツアーの提供といったように旅館のサービスも多様化してきたことを考え，他の業界と同様に，商品とそれを構成する部品（以下，素材という）の概念を取り入れることにした。すなわち，宿泊事業者が提供するものは商品であり，それは部屋素材，食事素材，送迎素材，その他素材から構成さ

図１

現行の宿泊予約システムれているものと考えることにした。さらに連泊等を考え，１日目の食事素材と２日目の食事素材の組み合わせ，すこのような方式を取っているために，ブロックを提供

なわち，利用日次とその日の食事素材IDを持つ食事パタする予約事業者の数が増えると，宿泊事業者は，提供しーン素材という概念を導入した。さらに，食事以外の素たブロックの管理が困難になる，といった問題点も指摘

材についてもそれぞれ部屋パターン素材，送迎パターンされている。（宿泊事業者が各予約事業者に出したブロ素材，その他パターン素材という概念を導入した。商品，ックの合計が，実部屋数より多い場合には，管理が不充

各パターン素材，素材の関係を表わすクラス図を図３に分だとオーバーブッキングになることがある。）

示す。また，部屋素材と食事素材のクラス図を図４に示す。

３．次世代型宿泊予約システム
3．1

システムの概要

前章で述べた現行の宿泊予約の問題点を解決するために，旅行電子商取引促進機構での議論を踏まえて，次のような次世代型宿泊予約システムを提案・構築することにした。（図２参照）すなわち(1) 予約事業者からの要求にしたがって予約業務を行なう処理を，宿泊事業者自身がWebサービスの形で提供する。したがって，日々の予約可能部屋数を管理する在庫データベースは，宿泊事業者自身のシステ
図３

ムで管理する。

商品，パターン素材，素材の関係(2) 予約者に関する情報も，予約事業者からオンライン
3．3で受け取り，自社のPMS へ直接反映する。
(3) 予約事業者，宿泊事業者間でやり取りするメッセー

処理の流れ

顧客が本システムを用いて宿泊施設の予約をする処理

ジは旅行電子商取引促進機構で策定中の標準XML形の流れは以下のとおりである。(図５参照)[4]式 を使用する。

(1)（施設情報の登録）あらかじめ宿泊事業者が作成した−14−

(8)（予約結果照会）予約を取り消す必要が生じた場合，宿泊者の氏名，宿泊日等から予約を検索する必要がある。

図４

素材

自社の施設・設備に関する情報は，予約事業者のデータベースに登録しておく。
(2)（商品情報の登録）宿泊事業者が提供する商品に関する情報も，あらかじめ宿泊事業者が作成し，予約事業者のデータベースに登録しておく。
図５(3)（施設一覧照会）顧客からの宿泊施設に関する照会は，処理の流れ

予約事業者が保持している (1) の情報をもとに検索を行い，結果を顧客に返す。

この処理は，予約時に更新していく予約事業者のデ(4)（在庫照会）顧客が宿泊施設と宿泊日を指定すると，予約事業者システムは，宿泊事業者システムに対しータベースの検索を行なうことで処理可能であり，宿泊事業者とのデータ交換は行なわない。て宿泊日を指定して商品の在庫数を問合せる。宿泊(9) (予約取消処理)上記で検索した結果判明した予約番事業者システムは，Webサービスの形でその日に販号を指定して，予約の取消し処理を行なう。この情報

売可能な全商品の在庫数を回答する。顧客が複数のは，宿泊事業者システムに送られ，宿泊事業者の在庫宿泊施設を指定した場合は，全ての宿泊事業者に対データベースの更新を行なう。

して上記の問い合わせを行なう。

４．試行システムの実装(5)（予約基本処理）上記で表示された商品の中から，顧客が予約したいものを選択し，予約に必要な宿泊日，人数等の最低条件を入力すると，予約事業者システ

前章で述べたモデルとそれによる処理方式は，予約事

ムは当該宿泊施設にその条件を送信する。宿泊事業業者側，宿泊時業者側とも現在用いられているシステム

者システムは，再度，自社の在庫データベースを調では対応できない。そこで，新しい方式を啓蒙し，普及べ，予約が可能ならばその旨を予約事業者に回答すさせるために，試行システムを開発することにした。

る。この状態の予約を「仮予約」と呼ぶ。
4．1(6)（支払い処理）海外からの予約を想定すると，ノーシ

試行システムの構成

ョー（予約をしたのに実際に宿泊しないこと）に対試行システムの構成を図６に示す。予約事業者側のシする対処が必要であるので，現行では行なわれていステムは，顧客（あるいは予約事業者の担当者）がブラない，保証金や料金の支払い方法を宿泊事業者に通ウザから予約に必要な情報を入力し，予約をとる方法が知する処理を追加した。この支払い方法を宿泊事業妥当であると考え，JavaサーブレットによるWebアプリ者が受け入れたならば，仮予約が「本予約」になる。

ケーション方式を採用し，その動作環境としては，(7)（宿泊者詳細情報）最後に，宿泊者全員の氏名，住所Tomcatを利用した。また，予約事業者システムには，宿等の詳細情報を宿泊事業者システムに送信して，予泊事業者から入手した各施設の施設情報と商品情報を保約が完結する。

持している。また，予約処理にしたがって生成される予−15−約情報も更新・保持している。

作成されたXML文書の一例を，図７（次頁）に登録画面

宿泊事業者側のシステムは，3.3節で述べた処理のうち，の一部を示す。商品が，部屋素材と食事素材から構成さ(4)の在庫照会に対する回答，(5)の予約基本処理に対するれていることが理解できるであろう。省略した部分には予約受付，(6)の支払い処理の受付，(7)の宿泊者詳細情報

シーズン別・一部屋あたりの宿泊人数別の料金等が記述の受付，(9)の予約取消処理の受付の５種類のサービスを，されている。また，素材の内容については，別途XMLでWeb サービスの形で常時提供する形でシステムを構築表わされている。表３に食事素材「D41」の例を示す。

した。その動作環境としてはAxis を使用した。したがっこれにより，１泊目と２泊目で異なる宿泊施設に泊まるて，Tomcat サーバで動作する予約事業者側のプログラ商品も容易に表現でき，また素泊まり，夕食のみ，ドリムのいくつかは，Axis クライアントとして宿泊事業者のンクサービス付きといった多種多様な商品の作成が可能提供するWebサービスを利用することになる。になっている。
表１

図６ 試行システムの構成
また，宿泊事業者側では商品の在庫管理を行なう必要があるが，既存のPMS では「商品」という概念を持っていないので，今回の試行システムでは，商品在庫については，商品番号からその商品が利用する部屋を特定し，既存のPMSが持っている部屋在庫データベースを利用することにした。（PMSとしては，アルゴ２１社の「フロントくんWin」を利用した。）図６に示すように，Webサービス提供部が受取ったXMLメッセージを解読し，その情報から商品番号を得てPMSの部屋在庫データベースを更新する。またXMLメッセージで送られてくる宿泊者情報もPMSに転送し，宿泊者データベースを更新する。
ただし，予約情報については，商品データ等PMSが対応していない情報も含まれるので，Axisサーバで保持することにした。
以下本章では，3.3節で述べた処理のうちで，商品情報の登録と予約基本処理の実装を述べることにする。
4．2

商品情報

<Product hotelID="12345" lang="ja" productID="S-0123"><TypeCode>1</TypeCode><ProductName>豪華ディナーコース</ProductName><MinCount>2</MinCount>
商品番号<MaxCount>6</MaxCount><Suppliers><Supplier>成蹊ホテル</Supplier></Suppliers><EffectiveStartDate>2005-01-01</EffectiveStartDate><EffectiveEndDate>2005-12-31</EffectiveEndDate>
部屋パターン素材番号<GuestRoomPattern><GuestRoomPatternID>R1</GuestRoomPatternID><RoomItinerary><ItineraryDate>1</ItineraryDate><HotelID>12345</HotelID>(注1)<RoomTypeID>01</RoomTypeID><StayOfNight>1</StayOfNight></RoomItinerary></GuestRoomPattern>
食事パターン素材番号<MealServicePattern><MealServicePatternID>M1</MealServicePatternID><MealServicePatternVariation><MealServicePatternVariationID>A</MealServicePatternVariationID><Descriptions>フレンチディナーコース</Descriptions><Itinerary>(注2)<ItineraryDate>1</ItineraryDate><MealServiceIDs><MealServiceID mealServiceTypeCode="3">D41</MealServiceID></MealServiceIDs><HotelID>12345</HotelID></Itinerary><Itinerary>(注3)<ItineraryDate>2</ItineraryDate><MealServiceIDs><MealServiceID mealServiceTypeCode="1">B11</MealServiceID></MealServiceIDs><HotelID>12345</HotelID></Itinerary></MealServicePatternVariation></MealServicePattern>
・・・・料金等・・・・</Product>
注1：１泊目の部屋が，ホテルID「12345」の部屋素材「01」であることを示す
注2：１日目の夕食(mealServiceTypeCode=3)の食事素材
が「D41」であることを示す
注3：２日目の朝食(mealServiceTypeCode=1)の食事素材
が「B11」であることを示す

商品情報の登録

各宿泊事業者が提供する商品情報のデータを入力し，旅行商取引促進機構が2003年度に策定した標準の施設情報をXMLフォーマットで提供する機能である。表１に，−16−表２

食事素材の例

4．3

予約基本処理(1) 商品の選択と予約情報の入力<Meals hotelID="12345"><Meal mealServiceID="D41">

3. 3節で述べたように，宿泊日と複数の宿泊施設を指<MealServiceTypeCode>3</MealServiceTypeCode>

定して在庫照会を行ない，その結果表示された商品の<FoodServiceType>西洋料理</FoodServiceType>中から１つの商品を選択して，予約を行なう。図８に<OperationSchedule>

在庫照会を行なった結果の画面の例を示す。

<OperationDays><OperationTimes><OperationTime><Start>17:00</Start><End>21:00</End></OperationTime></OperationTimes></OperationDays></OperationSchedule><Usage><ServiceType>椿</ServiceType></Usage><Features>フランス人シェフによるフランス料理</Features><Services /></Meal>・・・・

図８

在庫照会結果と商品の選択<Meals>D41 は，夕食（MealServiceType=3）で，17時から21時の間に，商品を選択すると，図９の画面が表示されるので，代「椿」という部屋で提供されることを示している。

表者の氏名，連絡先等を入力し，送信ボタンをクリックする。

図７

商品作成画面(一部)

図９

また，表１のProduct 要素の属性にlangを導入し，国外予約要求画面(2) 宿泊事業者に送信されるデータへの商品情報の発信にも対処できるようにしてある。
（送Webサービスに対するメッセージの送信はSOAPを迎素材，その他素材（周辺の観光等）は今回の実装では用いているので，SOAP の枠組みの中に表３に一部を省略した。）

示す旅行商取引促進機構が策定した標準XML 文書を挿入して送信している。

−17−

(3) 宿泊事業者の予約受付機能

予約の可否を知り，その結果を表示する。要素値が前述したように，宿泊事業者システムの「予約受付「HK」で仮予約が出来た場合は，支払い条件を入力すWebサービス」が図８に示した形式の予約事業者からる画面を表示し，予約処理を更に進めることになる。

送られてきたメッセージを解析し，指定された宿泊日

５．開発工程の，指定された部屋タイプを見出し，その部屋タイプの在庫数を指定された部屋数だけ減じた値で，PMS のデータベースを更新する処理を行なっている。

旅行電子商取引促進機構で2003年度に策定した旅館予約のための標準XML をもとにして，試行システムを開表３

予約要求メッセージ発することにしたが，何処までを試行システムに組み込<AcomodationBookingRequest>

むかについて関係者との協議を行い，更に標準XMLの一<DataFrom>1</DataFrom>

部見直し等を行なった。これらの協議はほぼ１週間に１<DataClassification>BookingRequest回のペースで2004年７月〜９の11回実施した。その後，</DataClassification><SystemDate>2005-3-22</SystemDate>

10月から開発に入り，2005年１月までに3.3節に述べた全<SystemTime>13:28:11</SystemTime>

機能の実装に筆者の中島，宮本を中心に約100人・日で開<HotelID>12345</HotelID>

発を完了した。その後，予約事業者，宿泊事業者にデモ<AgentID>98765</AgentID>

ンストレーションを行ない，一部機能の追加等を実施し<Supplier lang="ja">成蹊ホテル</Supplier>

たが，概ね好感を持って受け入れられている。

<ContactCompany lang="ja">宮本旅行株式会社</ContactCompany>

６．おわりに<POS lang="ja">宮本旅行吉祥寺支店</POS><BookingRequests>

予約番号<BookingRequest>

予約要求

本システムは試行システムであるため，セキュリティ<BookingNumber>361</BookingNumber>を考慮していないこと，実際に商品情報を持った宿泊事<BookingStatusCode>NN</BookingStatusCode>

業者数が少ないこと（２事業者），それに伴ってトラン<BookingDate>2005-3-22</BookingDate><BookingTime>13:28:11</BookingTime>

ザクション数が少ないためサーバに要求される性能等の<ProductID>S-0123</ProductID>検討が出来ないことなどが問題点として挙げられる。今予約商品番号<GuestRoomPatternID>R1</GuestRoomPatternID>

後，この試行システムをもとに実用システムの設計に入<MealServicePatternID>M1</MealServicePatternID><CheckinDate>2005-4-10</CheckinDate>

り，開発を進めることを計画中である。

宿泊日本システムの開発は，多くの方々のご協力のもとに行<CheckinTime>17:00</CheckinTime><CheckoutDate>2005-4-11</CheckoutDate>

なわれたが，特に旅行電子取引促進機構の鈴木耀夫氏，<CheckoutTime>10:00</CheckoutTime>松岡道展氏，アルゴ２１の関川信吉氏には大変お世話に<StayOfNights>1</StayOfNights>なった。つつしんで感謝の意を表する。

<TotalRoomCount>1</TotalRoomCount>

部屋数<TotalGuestCount>1</TotalGuestCount>

人数

参考文献

・・・・
</AccomodationBookingRequest>[1] 日本情報処理開発協会・電子商取引推進センター,
上記の減じた部屋数が負になれば予約は不可能であ

国内外のEDI 実態調査報告書-2004-, 2004年3月,

り，正であれば予約が可能であるので，そのいずれか

http://www.ecom.or.jp/jedic/activity/jittai2004n.pdf

を予約事業者に予約回答メッセージとして送信する。

[2] Open Travel Alliance, http://www.opentravel.org/

この予約回答メッセージも機構で標準を定めている。

[3] ebXML, http://www.ebxml.org/

予約可能な場合はBookingStatusCode が「HK」であり，[4] ジェイアール総研情報システム：旅館施設情報提供

不可能な場合は「UC」である点以外は，表３に示したおよび予約業務における業務プロセス及び情報モデ要求メッセージと同一形式である。

ル調査, 2004 年3月[5] 日本情報処理開発協会・電子商取引推進センター,(4) 予約結果の表示

業際電子商取引モデル整備報告書, 経済産業省委託

予約受付の回答XMLメッセージを受け取った予約事業者システムは，BookingStatusCode の要素値により，−18−

調査, 2004年3月