生成AIでホテルBIはどこまで自社開発できるのか｜競合価格データを活用した分析ツールの内製化【ホテルDX・分析基盤　第3回】

はじめに

自社で分析ツールを作る場合、単に必要な指標を表示するだけでなく、自社で整理した判断基準や業務フローを画面に反映できます。

例えば、カスタマージャーニーをもとに「どの顧客接点を改善するか」「誰が担当するか」「どの業務を見直すか」を整理している場合、顧客接点ごとの予約率や、あらかじめ設定した目標に対する進捗を分析画面の確認項目に反映できます。さらに、一定の基準を下回った場合に、確認すべき項目や事前に定めた対策を表示することも考えられます。

そのため、自社独自のフレームワークを持っている企業では、既製ツールで数値を見るだけでなく、「この状態なら、次に何を確認・実施するか」まで含めた分析画面を設計できることが、自作するメリットの一つになります。

分析画面を作る前に決めること

第1回「ホテルBIは大規模ホテルだけのものなのか」では、Excel＋AIによる確認、生成AIを使った簡易ツール、クラウド分析基盤、専用BIツール・RMSを、規模や用途に応じた選択肢として整理しました。

第2回「ホテルBIに必要なデータとは」では、国内外50社超のBI・RMS・PMS等の製品情報から58の分析パターンを整理しました。その結果、自社データだけで完結する分析が36件ある一方、競合価格の比較や市場ポジショニングなど、外部データを必要とする分析も22件確認されました。

分析画面を設計する前に、価格の見直し、販売制限の変更、競合との位置関係の確認など、支援したい判断を決めます。価格や販売施策を検討する場合は、自施設の予約・稼働・売上に加え、次のような市場・競合データが候補になります。

• 競合施設が提示している価格
• 競合施設の在庫・販売状況
• エリア全体の価格帯
• 曜日、連休、イベント時の価格変化
• 将来の宿泊日に向けた市場価格の推移

従来、独自の分析ツールを作る場合は、要件を整理してシステム会社へ発注する方法が主な選択肢の一つでした。

現在は、Claude Code等を使って競合価格データを読み込み、分析画面を試作する方法も選べます。ただし、利用できるデータや社内の開発・運用体制によって、内製できる範囲は変わります。

本記事では、特定のPMSにおけるデータの出力方法や、個別システムのデータ構造ではなく、自社データと市場データを使って、どのような分析ツールを作れるのかを中心に整理します。

生成AIを使った分析画面の試作工程

自施設の将来の予約進捗と競合価格を比較する場合は、次のような情報を一つの画面にまとめます。

従来、このような画面を作るには、要件を整理したうえで開発会社へ発注し、画面設計、データ処理、実装、テストを進める必要がありました。

Claude Code等を使う場合は、使用するデータ、表示する指標、画面構成、計算条件を指示し、出力されたコードと画面を確認しながら修正します。開発会社への発注前の試作や小規模な内製を行いやすくする使い方です。

試作では、分析内容を固め、その後にデータの更新方法や運用体制を検討します。

競合価格データを使って、どのような分析ツールを作れるのか

ここでは、競合価格データを使って支援できる判断を、四つの分析例に分けて整理します。

Claude Code等生成AIで分析ツールを作る流れ

ここでは、個別のPMSやプログラミング言語に依存しない範囲で、内製する場合の流れを整理します。

1. 分析目的を決める

最初に、作る機能を一つに絞ります。ここでは、自施設の予約進捗と競合価格を宿泊日別に並べ、価格の見直しが必要な日を確認する画面を例にします。

2. 使用するデータを決める

目的を決めた後は、PMS、予約システム、サイトコントローラー、市場データのそれぞれから取得できる項目を確認します。取得できない項目を前提に分析内容を決めると、試作後に設計をやり直すことになります。

表に挙げた項目のうち、実際に取得できるものを確認し、取得できる項目に合わせて分析対象や表示指標を調整します。

3. 最初の画面を試作する

分析目的とデータが整理できたら、Claude Code等に、作成したい画面の概要を指示します。指示内容には、次のような要素を含めます。

最初の試作では、CSVやParquetファイルを読み込み、宿泊日を選択し、自社価格、競合価格、価格推移を表示する機能に絞ります。

試作画面を実データで確認すると、比較に必要な項目の不足、指標定義の違い、追加すべき絞り込み条件、統一が必要なデータ形式が分かります。この段階で不足項目や定義の違いを確認しておくと、本格的な開発後の手戻りを減らせます。

4. 分析条件と計算結果を確認する

生成AIによって画面やコードを作れても、計算結果が正しいとは限りません。以下は確認が必要となる代表的な論点です。実際のデータ項目や集計条件は、利用しているPMSや予約システム、分析目的によって異なります。

AIが作成した処理については、元データの合計値や既存帳票と照合し、計算条件が意図したものになっているかを確認します。

5. 継続運用に必要な機能を確認する

分析画面を継続的に利用する場合は、データ更新、エラー検知、認証・権限、データ保護、バックアップ、障害対応について、実施方法と担当者を決めます。

Excel＋AIは、分析内容を確認する最初の選択肢

小規模なデータを手作業で確認する場合は、ExcelとCopilot等を使って集計やグラフを作る方法もあります。

Excel＋AIは、指標や計算条件、必要なグラフを確認する試作前の手段として使えます。競合価格・在庫を継続取得し、自社データと組み合わせて複数人で利用する場合は、簡易ツールやクラウド分析基盤も比較対象になります。

AIで作れるものと、AIだけでは解決しないもの

市場・競合データの取得処理をAIで試作できても、サイトごとの仕様差への対応、取得条件の変更、bot対策、利用規約の確認は継続して発生します。これらを誰が確認し、修正するかは、試作時点で決めておく必要があります。

競合価格データを継続的に利用する方法には、自社で取得処理を構築する方法、利用可能なAPIを利用する方法、外部の市場データサービスを利用する方法などがあります。それぞれ取得できるデータや運用負担が異なるため、条件を比較して選択します。

簡易ツールからクラウドBIへ

簡易ツールからクラウド分析基盤へ移る目安は、複数施設や複数部門で共通利用すること、データを自動更新すること、利用者ごとに権限や分析軸を変えることが必要になったときです。

QuickSight等を使った具体的なクラウド構成は、第5回で整理します。Claude Code等による簡易ツールとクラウドBIは、単純な優劣ではなく、利用者数、施設数、更新頻度、必要な分析自由度、運用体制によって選択が変わります。

自作と専用ツールを比較する条件

専用BIツールやRMSは、標準機能を短期間で導入し、保守をベンダーへ任せやすい一方、追加できる分析や利用できるデータが製品の対応範囲に制約される場合があります。

生成AIを使うことで、専用ツールを導入する前に、必要な分析を自社で試作して確認する方法も選べるようになりました。

まとめ

生成AIによって分析画面の試作は行いやすくなりましたが、分析内容や運用方法の設計は引き続き人が判断する必要があります。

本当に重要なのはグラフや表を作ることではありません。どの状態になったら価格を変更するのか、販売制限を見直すのか、販促を行うのかといった、ホテルごとの意思決定ルールを定義することです。

専用ツールでは、基本的に製品が用意する指標やロジックをベースに利用することになり、カスタマイズできる範囲は製品によって異なります。

生成AIによって変わったのは、分析ツールを作れるようになったことだけではなく、自社で定めた判断基準や業務フローを、実際の分析画面として検証しやすくなったことです。

次回「第4回　ホテルBIを自作するか、専用ツール(SaaS)を導入するか」は、どのような基準で選ぶべきかを整理します。