AWS・Microsoft Azure・Google CloudでホテルBIを構築｜構成要素・選定条件・導入の進め方を解説【ホテルDX・分析基盤　第5回】

自社データと市場データを継続的な意思決定につなぐ分析基盤

はじめに

第4回「ホテルBIを自作するか、専用ツール(SaaS)を導入するか」では、ホテルBIを自作するか専用ツール（SaaS）を導入するかについて、ホテル独自の判断基準をどこまでシステム化するかという観点から整理しました。第5回では、その判断基準を日常業務で使い続けるための分析基盤について、「自社データと市場データ」をクラウド上で保存、処理、可視化する際の考え方を整理します。

クラウドBIを活用した分析基盤の構築

Amazon QuickSight、Microsoft Power BI、Google CloudのLookerなどのBIツールは、主にデータの分析と可視化を担います。※

ホテルBIを継続して運用する場合は、データの収集、定義の統一、加工、権限管理も含めて設計します。

構成の規模は、利用するデータ、更新頻度、施設数、利用者数、必要な権限によって変わります。最初から大規模に構築せず、対象とする施設、データ、分析テーマを限定して始め、運用状況を確認しながら段階的に対象を広げる方法もあります。

※製品や利用方法によっては、データ接続、加工、モデリングなどの機能も含まれます。

ホテルBIのクラウド基盤は、4つの層で考える

本記事では、クラウド分析基盤とその運用を、データ保存、処理・分析、可視化、意思決定・業務の4つの層に分けて整理します。前半の3層は一般的なデータ基盤の構成要素であり、4層目は第4回で扱った判断基準と業務上の対応を結び付けるために、本記事独自の整理として加えています。

4つの層に分けると、自社で管理する範囲と、製品や外部サービスへ任せる範囲を整理できます。

最初に決めるのはクラウド製品ではなく、運用条件

例えば、1施設で月次分析を行う場合と、複数施設の予約進捗と市場価格を毎日更新する場合では、必要なデータの保存容量や更新処理、権限設定が異なります。

クラウド（AWS・Microsoft Azure・Google Cloud）ごとの代表的な構成

次の表は、各クラウドで保存、処理・分析、可視化を担う代表的なサービスの例です。実際の構成は、データ量、更新方法、既存環境、必要な機能によって異なるため、製品の優劣や標準構成を示すものではありません。

いずれのクラウドでも、保存、処理・分析、可視化を複数のサービスで分担する構成が考えられます。既存環境によっては、表にないサービスや他社製品を組み合わせる構成もあります。

クラウドを選ぶ際は、サービスの比較だけでなく、既存契約、認証基盤、データの保存場所、運用担当者のスキル、利用者が日常的に使う環境を確認します。

参照：

AWS公式ドキュメント「Authorizing connections to Amazon Athena」：QuickSight、Athena、S3の接続と権限。

Microsoft Learn「Power BIを使用してAzure Data Lake Storage Gen2のデータを分析する」「Power BIを使用してAzure Synapse Link for Dataverseデータを視覚化する」：Power BIとAzure Data Lake／Synapseの接続例。
URL：https://learn.microsoft.com/ja-jp/power-apps/maker/data-platform/export-to-data-lake-data-powerbi
URL：https://learn.microsoft.com/ja-jp/power-apps/maker/data-platform/azure-synapse-link-powerbi

Google Cloud公式ドキュメント「Google BigQuery | Looker」：LookerとBigQueryの接続。

ホテルでのクラウドBIの導入事例

BWH Hotelsの事例

AWS Business Intelligence Blogでは、BWH Hotelsが、従来利用していたIBM CognosからAmazon QuickSightを中心とするAWSのデータ・分析環境へ移行した事例が紹介されています。2021年の事例では、Amazon S3のデータレイク、Amazon Redshift、AWS Lambda、AWS Glueを組み合わせ、QuickSightをBIのフロントエンドとして利用する構成が説明されています。また、宿泊後アンケートや第三者の競合ベンチマークツールなど、従来は別に管理していたデータもQuickSightへ統合していました。

2023年に公開されたAWSの続編記事では、BWH Hotelsについて、24,000人の登録ユーザーと8,000人の月間アクティブユーザーがQuickSightを利用し、Revenue Management向けに約20～30種類のダッシュボードを運用していると紹介されています。さらに、利用者の拡大後もデータ定義、利用ルール、トレーニングを管理しているとされています。この事例は、大規模なBI利用では、ダッシュボードの構築だけでなく、定義や利用ルール、教育を含む運用設計が重要になることを示しています。

その他の事例（Accor Luxury & Premium Brands、Remington Hospitality）

ホテル業界では、AWSとQuickSight以外の構成も確認できます。Accor Luxury & Premium BrandsはTableau Cloudで100を超えるホテルのレポートを集約し、Remington HospitalityはMicrosoft Power BIを基盤とする独自BIプラットフォームを運用しています。これらの事例からも、採用する製品は異なっても、複数施設のデータを集約し、共通の指標で確認できる環境を整える点は共通していることが分かります。

参照：

AWS Business Intelligence Blog「Best Western slashes analytics costs, improves operations worldwide using Amazon QuickSight」（2021年3月16日）

AWS Business Intelligence Blog「BWH Hotels scales enterprise business intelligence adoption while reducing costs with Amazon QuickSight」（2023年6月2日）

Tableau Customer Story「Accor Luxury and Premium Brands deploys Tableau Cloud to improve business performance across hundreds of hotels」

Remington Hospitality「Best-In-Class Business Intelligence: REMi」

AWSにおけるS3、Athena、QuickSightを使った基本構成例

ホテルBIの構成例として、Amazon S3、Amazon Athena、Amazon QuickSightを組み合わせた場合の構成と運用の流れを確認します。

AWSの公式ドキュメントでは、AthenaはS3内のデータを標準SQLで直接分析するサービスとされ、QuickSightからAthenaと関連するS3バケットへ接続する方法が案内されています。

生成AIは、基盤の上で判断支援に利用する

生成AIは、分析結果の要約、変化点の説明、担当者が確認すべき項目の整理、次の対応候補の文章化などに利用できます。一方、数値条件に基づく確認対象の抽出や判定は、SQLやBIの計算ロジックで処理した方が、条件と結果を検証しやすい場合があります。生成AIを利用する場合は、参照するデータと指標の定義、出力を確認する担当者を決めたうえで、第3回と第4回で整理した分析業務へ適用します。

クラウドやBI製品に組み込まれたAI機能を使う方法と、自社で生成AIサービスを組み合わせる方法があります。どちらの場合も、AIが参照するデータと指標の定義をそろえます。価格変更や販売制限などの業務へ反映する前に、担当者が元データと出力内容を確認できるようにすると、AIが提示した内容の妥当性を確認し、実行するかどうかを判断しやすくなります。

継続運用で必要になる設計

本番運用に入る前に確認すべきポイントを次の表に整理します。

市場データについては、取得対象、更新頻度、履歴、提供形式、利用条件を、分析画面の設計とは分けて確認します。BI画面が完成していても、競合価格・在庫を継続して取得できなければ、市場データを使った分析が行えません。

どこから始めるか

シリーズの内容に沿って進める場合は、第2回の『ホテルBI分析一覧（Ver0.1）』から優先する分析を一つ選び、第4回で整理した判断基準と結び付けます。その分析に必要なデータと更新条件を決め、限定した範囲から構築を始めます。

分析目的から必要なデータ、更新条件、構成を順に決めると、導入する製品と実際の用途が合致しているか事前に確認しやすくなります。

まとめ

ホテルBIの構成を検討する際は、利用する製品だけでなく、対象とする分析、データの更新条件、社内で管理できる範囲を確認します。これらを整理したうえで、既存環境や保守体制に合うクラウドとサービスを検討します。

データ保存、処理・分析、可視化、意思決定・業務の4層のうち、どこまでを自社で管理するかは、分析目的、データ、更新頻度、権限、保守体制によって変わります。

クラウド製品を先に選ぶのではなく、分析目的、必要なデータ、更新条件、判断基準、運用体制を整理し、その条件に合う構成を選ぶことが重要です。

弊社の「データ連携・システム連携」をはじめとする市場データサービスを検討する場合は、対象施設、取得条件、更新頻度、履歴、提供形式に加え、自社のPMSデータや判断基準と接続できるかを確認します。