ホテル料金最適化をClaude Codeで｜OCC/ADR/RevPAR分析

はじめに:なぜ料金最適化の前段に「Claude Code」なのか

正直、最初は半信半疑でした。レベニューマネジメント(以下RM)は、専用SaaS(IDeaS、Duetto、Atomize、メトロエンジン等)が成熟しており、わざわざCLIエージェントで何をするのか、というのが業界の感覚だと思います。私自身、最初にホテルRM領域でClaude Codeを試したのは、知人から「うちのRM担当が週次会議の資料作りに毎週半日かかっていて、本業のレート設定の時間が削られている」と相談されたのがきっかけでした。

そこから1年ほど、複数の中規模ホテル(50〜120室クラス)の運営チームと一緒に作業して見えてきたのは、「RMツールが出した推奨価格を、人が説明可能な形に落とし込むコスト」が想像以上に重いということでした。GMや支配人は、ツールが「明日は¥18,500」と出してきたとき、なぜそうなのか、何を根拠に動かすのかを部下に説明できないと現場が動かない。OTA担当に「Booking.comだけ-5%にして」と指示するときも、根拠を1分で言語化できる必要があります。営業部に「明日は強気価格で行く」と通すには、過去類似日のADR推移と需要ドライバーを示せないと納得を得られません。

Claude Codeが効くのはまさにこの「データから根拠を組み立てる」部分です。PMS(プロパティ管理システム)からエクスポートしたCSV、サイトコントローラーのOTA別予約データ、近隣イベント情報、天気予報、競合のレートショッパーデータ——これらを統合して「人が読める日本語の根拠書」に変換する作業を、ターミナル上でファイル群を直接いじりながらやれる。専用SaaSのダッシュボードを開いてスクショを撮って週次資料を作る、という手作業がほぼ消えました。データを開く、関連ファイルを参照する、根拠書を作る、保存する、という一連の流れがCLI内で完結するので、ブラウザタブを20個開いて行ったり来たりする必要がなくなります。

もう一つ大きいのは「過去ナレッジの再利用」です。半年前に「お盆繁忙期で台風接近時にどう値付けしたか」を再度参照したいとき、過去の週次レビュー資料をMarkdownでファイル保存しておけば、Claude Codeに「2025-08のお盆期間に台風接近があった日の判断を教えて」と聞けば、関連ファイルを横断して要約してくれます。ExcelやPowerPointだとこの再利用が極端にやりにくい。Markdownファイル群+CLIエージェントの組み合わせは、ホテル現場の意思決定ログ管理にも適しています。

この記事では、その実装パターンを書きます。あくまでClaude Codeは「分析・予測・レポート作成」の補助エージェントであり、最終的な料金決定はGM・レベニューマネージャーが行うという前提です。ここを混同すると、価格戦略が崩れます。AIに値決めを丸投げするのではなく、人がより良い判断を下すための材料を整える役割としてClaude Codeを位置づけるのが本記事の立場です。

そもそもRMの3指標(OCC/ADR/RevPAR)とは

業界外の方のために最低限の用語整理を。

• OCC(Occupancy / 客室稼働率):販売可能客室数のうち、実際に販売できた客室の比率。100室のホテルで70室売れたらOCC 70%。
• ADR(Average Daily Rate / 平均客室単価):販売した客室1室あたりの平均販売単価。客室売上 ÷ 販売客室数。
• RevPAR(Revenue Per Available Room / 販売可能客室1室あたり売上):OCC × ADR、または客室売上 ÷ 販売可能客室数。RMの最重要指標。

業界の最低限の共通言語として、米国ホテル業協会(AHLA)系の解説や、観光庁の「宿泊旅行統計調査」、JNTOの統計レポートでも頻出します(本記事末尾の出典参照)。

RMの本質は「OCC偏重で値下げしてADRを犠牲にしてもいけないし、ADR偏重で強気価格にしてOCCを落としてもいけない」というバランスゲームで、両者の積であるRevPARの最大化が目的になります。Claude Codeにやらせる集計も、必ず3指標セットで出力する設計にしておくと、議論の前提が崩れません。

もう一段進めて、最近の業界ではTRevPAR(Total RevPAR、客室売上だけでなくF&Bや館内売上を含めた総合指標)、GOPPAR(GOP Per Available Room、営業利益ベース指標)も併用されます。本記事は客室単体の最適化に絞りますが、最終的にはホテル全体の収益を見る視点に拡張するのが理想です。Claude Codeに集計させる際も、将来の拡張を見越して「客室売上だけでなくF&B売上の列があれば併記する」と指示しておくと、後段で困りません。

もう一つ、RM指標を扱う上で押さえておきたい補助指標が「ペース(Pace)」と「ピックアップ(Pick-up)」です。ペースは「N日前時点での予約進捗が前年同日と比べてどうか」、ピックアップは「直近X日間で新規に入ってきた予約件数・売上」を指します。RM SaaSではこれらをグラフ表示してくれますが、Claude Codeで日次に「ペースが前年同日比でズレている日付」を異常検出させる運用にすると、SaaSを開かずに早期警戒が回ります。

実装パターン1:PMS抽出データからOCC/ADR/RevPARを自動集計する

最初の典型タスクは、PMSやサイトコントローラーから日次でエクスポートしたCSVを、Claude Codeに渡して指標化させることです。PMSによって列名がバラバラなので、列マッピングを最初に固めておくのがコツです。

私が現場で使っているプロンプトの最小版がこちらです。ファイル名・列名は実際の現場に合わせて差し替える前提です。

あなたはホテルのレベニュー分析アシスタントです。
入力ファイル: ./data/daily_room_sales_2026-05.csv

このCSVには以下の列があります(列名がブレている場合は近い名前を採用してください):
- date (販売日)
- rooms_available (販売可能客室数)
- rooms_sold (販売客室数)
- room_revenue (客室売上、税抜)
- segment (FIT/グループ/OTA/直販/ハウスユース等)

タスク:
1. 日次でOCC・ADR・RevPARを算出する(小数点1位まで)
2. 当該日と「前年同日」「前年同曜日(±3日範囲で最寄り)」「前週同曜日」の3比較を出す
3. RevPARが前年同曜日比 -10%以下、または +15%以上の日を「異常日」として抽出
4. 異常日それぞれについて、考えられる説明仮説を3つ提示する
   (例: 近隣イベント、台風接近、競合の値下げ、休前日の特殊性 等)
5. 出力は ./reports/daily_kpi_2026-05.md にMarkdownで保存

なお、ハウスユース(社用利用・無償)は分母から外し、修学旅行等の超低単価グループは別建てで注記してください。

ポイントは3つ。第一に、前年同曜日比較を必ず入れること。曜日特性が極端に強い業界なので、暦日比較だと全部「異常」になります。たとえば「2026-06-15(月)と2025-06-15(日)」を単純比較すると、月曜と日曜の特性差で全件が異常判定になり、本当の異常を見逃します。前年同日付ではなく前年同曜日(±3日範囲で最寄り)を取るのが、業界の暗黙了解です。第二に、ハウスユースや団体ベース料金などの「分析を歪める客室」をプロンプト段階で除外指示しておくこと。社用ハウスユース・宴会場のキャプティブ客室・修学旅行団体などはADRが極端に低く、混ぜると平均が歪みます。第三に、出力をMarkdownファイル化させることで、後段の週次レビュー資料生成プロンプトから参照できる素材にしておくこと。Markdownで保存しておくと、Gitリポジトリに突っ込んでバージョン管理することも可能になり、過去判断のトレーサビリティが上がります。

これを毎朝、前日確報データに対して走らせる運用にすると、現場の朝会で「昨日のRevPARが前年同曜日比+18%だったのは雨で日帰り客が宿泊に切り替わったからではないか」みたいな仮説が、人が手計算する前にテーブルに乗ります。仮説の精度はまだ粗いですが、議論の起点として十分機能します。私が支援したケースでは、それまで朝会の前半30分が「数字の確認」だけで終わっていたのが、Claude Codeの出力を冒頭で配ることで「仮説の議論」に時間を回せるようになりました。

もう一段の工夫として、「異常日」の定義を社内で明文化してプロンプトに反映しておくと、現場と認識がブレません。あるホテルでは「RevPAR前年同曜日比 ±10%超過」「OCC絶対値 50%以下または95%以上」「ADR前年同月平均比 ±15%超過」の3条件のいずれかを満たす日を異常日と定義しています。この閾値は施設特性によって変えるべきものなので、プロンプトを書くときに必ず現場のRM担当・GMと合意してから固定化してください。

実装パターン2:需要予測マトリクスを組む

RM SaaSの予測エンジンほど精緻ではないにせよ、Claude Codeで「向こう30〜90日の需要強度マトリクス」を作ると、現場のレートデシジョン会議の前裁きに使えます。私が実装している入力変数は以下の5系統です。

• 過去予約データ: 同日(前年・前々年)のOCC・ADR・予約リードタイム分布
• 近隣イベント: コンサート・スポーツ大会・展示会・学会・花火大会など。半径3〜5km、または最寄り駅圏内
• 天候: 気象庁の週間予報・季節予報。リゾートホテルなら特に重要
• 連休カレンダー: 3連休、有給接続による5連休、年末年始、お盆、GW、シルバーウィーク
• 競合料金: 同エリア・同価格帯の競合5〜10軒の公表料金(後述のレートショッパープロンプトで取得)

プロンプト例:

あなたはホテル需要予測アナリストです。
入力:
- ./data/booking_pace_lastyear.csv (前年の同日リードタイム別予約曲線)
- ./data/events_nearby_2026-06_to_08.csv (半径3km以内のイベント情報)
- ./data/weather_forecast_2week.csv (気象庁2週間気温予報)
- ./data/holidays_jp_2026.csv (祝日・連休カレンダー)
- ./data/comp_set_rates_snapshot.csv (競合5軒の本日時点の30日先までの公表料金)

タスク:
1. 向こう30日を「需要強度」(1〜5の5段階)で評価する
   - 5: 完売リスクあり、強気価格推奨
   - 4: 平均超え見込み、徐々に料金を上げる
   - 3: 通常需要
   - 2: 平均未満、需要喚起策の検討
   - 1: 大幅未達、ディスカウントOTA活用やパッケージ造成を検討
2. 各日付について、強度を5項目の入力変数のうち何が押し上げ/押し下げているかを1行で説明
3. 出力は ./reports/demand_forecast_30days.md にテーブル形式で
4. 強度4以上の日と、強度1〜2の日を冒頭サマリにリストアップ

これを走らせると、向こう1ヶ月のヒートマップが手に入ります。完璧な数値予測を求めるのではなく、「人が議論を始めるための叩き台」として使うのが正解です。RM SaaSの推奨価格と比較して、Claude Codeの説明と相違がある日付だけを深掘りする、という運用が一番効きます。

近隣イベント情報の収集は、最初は手作業を覚悟してください。Webスクレイピングで完全自動化したくなる気持ちはわかりますが、コンサート会場・スポーツ施設・展示場・大学・自治体の各サイト構造はバラバラで、安定運用にはコストがかかります。実装支援の現場では「月初に営業担当が30分かけて翌月のイベントを手動で1ファイルにまとめる」運用にしているケースが多いです。30分の手作業を惜しまず、その代わり後段のClaude Codeへの投入とマトリクス生成は全自動化する、というメリハリが現実解です。

連休カレンダーも最初は注意が必要です。日本の祝日法に基づく公式祝日だけでなく、「有給を1日取れば5連休になる飛び石」「土曜が祝日と重なって振替なしになる損失」など、需要を強く左右する要素が暦の中に埋まっています。Claude Codeに「向こう90日の祝日と、有給1日で取れる連休パターン」を出力させる前処理プロンプトを作っておくと、需要強度マトリクスへの投入が楽になります。

天候の扱いも、施設特性で重み付けを変えてください。リゾートホテルや旅館は天候の影響が極大ですが、ビジネスホテルは出張需要が主軸なので天候感度は相対的に低い。プロンプト内で「当ホテルはビジネス特化のため、天候は弱変数として扱う」「リゾート立地のため、天候は強変数として扱う」といったコンテキストを与えるだけで、Claude Codeの説明文の精度が変わります。

実装パターン3:競合ホテル料金のレートショッパー

競合料金監視は、本来は専用レートショッパー(OTA Insight、Lighthouse、Pricepoint等)を使うのが正攻法です。ただ、軽量モニタリングや、特定の競合セットだけを見たい場合は、Claude Codeに「公開料金ページのHTMLを保存しておいたものを順次パースさせる」運用でも回ります。

注意:OTAサイトには利用規約があり、スクレイピングを禁じている場合があります。実装時は、各社の規約・robots.txtを確認し、公式API(BookingやExpediaのアフィリエイトAPI等)があればそちらを優先してください。本記事では、自社が宿泊予約システムから取得できる権限内データ、または各OTAから提供される公式レポート機能の出力をパースする前提で書きます。

あなたはレートインテリジェンス担当です。
入力: ./data/rate_snapshot_2026-05-27.csv
  列: hotel_name, room_type, date, price_jpy, ota_channel, snapshot_time, refundable_flag

タスク:
1. 当ホテル(自社)の各日付・各部屋タイプの料金と、競合5軒の平均・中央値・最安値を比較
2. 「自社が突出して高い/安い」日付を抽出(乖離15%以上)
3. キャンセル可/不可条件で価格帯がどう変わっているかを部屋タイプごとに集計
4. OTA別の価格戦略の傾向を3行で要約
   (例: A社は週末割増が激しい / B社は連泊割が深い / C社は会員価格主導)
5. 出力は ./reports/rate_intel_2026-05-27.md

レートショッパーSaaSと違ってリアルタイム性は劣りますが、「なぜこの価格に動かすべきか」の根拠書面を毎日アップデートできるのは強みです。GMが「うちだけ高すぎないか?」と聞いたとき、即座に該当日のスナップショットを開ける状態を作れます。

競合セット(コンプセット)の選定にもひと工夫が必要です。「立地が近いだけの競合」を全部入れると、客層が違うホテル(例:ビジネスホテルとリゾートホテル)が混ざって参考にならない指標が出ます。基本は「同価格帯・同客層・同立地圏」で5〜10軒を選定するのが定石です。施設特性によっては、「物理的に近い競合5軒」と「同価格帯・遠隔の競合5軒」の2軸で見るケースもあります。Claude Codeへの入力CSVを作る段階で、コンプセットの選定基準を社内で合意しておいてください。

もう一つ重要なのが「キャンセル可否条件での価格比較」です。同じ¥18,000でも、キャンセル不可・全額前払と、無料キャンセル可・現地払では、提供価値が全く違います。Claude Codeに渡すデータには必ず「refundable_flag」「cancel_policy」「payment_timing」列を含め、レポート上でも区別して集計させてください。「うちの方が高い」と思ったら、キャンセル条件で実は有利、というケースは頻繁にあります。

実装パターン4:OTA別の料金戦略レポートを自動生成する

RMで頭が痛いのは、OTA別に最適戦略が異なることです。Booking.comはレートパリティの圧力が強く、楽天トラベル/じゃらんは国内のセール連動性が高く、Agoda/Trip.comは越境需要に強い。直販(自社サイト)は会員プログラムと組み合わせて差別化したい。これらを毎週「どこにいくらで出すか」を決める作業をClaude Codeに支援させます。

あなたはOTAチャネルマネジメント担当です。
入力:
- ./reports/daily_kpi_2026-05.md (前章で生成済のKPI)
- ./reports/demand_forecast_30days.md (前章の需要予測)
- ./reports/rate_intel_2026-05-27.md (前章の競合料金)
- ./data/ota_production_lastmonth.csv (OTA別の生産数: 予約件数・売上・キャンセル率・平均リードタイム)
- ./data/ota_commission_table.csv (OTA別コミッション率)

タスク:
1. OTAチャネルごとに、過去30日の貢献度を「売上」「ネット利益(コミ控除後)」「キャンセル率」で評価
2. 向こう30日の各日付について、推奨する露出戦略を提案
   - 強気需要日: 直販優先、OTAは段階的にクローズ or 値上げ
   - 弱需要日: OTA優先、特に長尾OTAやセール連動OTAに在庫を寄せる
3. レートパリティ条項に抵触しない範囲での差別化案を3つ
   (例: 直販限定の朝食付プラン、会員価格、長期滞在割、特典付与)
4. 出力は ./reports/ota_strategy_weekly.md

レートパリティ(OTA間の価格均等義務)に関する記載は、実際の契約内容をRM担当者が確認した上で運用してください。Claude Codeは契約条項の解釈までは責任を持てません。日本国内では2017年以降の独禁法上の議論や、欧州での「狭義レートパリティ」「広義レートパリティ」の論点もあり、各国・各OTAごとに条件が異なります。直販価格の差別化余地は、ホテル側の交渉力・契約バージョン・国によって大きく変わるので、必ず契約原本に当たってください。

OTA別の特性を整理しておくと、戦略レポートの読み解きが楽になります。Booking.comはグローバル予約と週末旅行客に強く、レビュー数の蓄積でランキングが固定化しやすい。楽天トラベル/じゃらんは国内のセール期間連動性が高く、ポイント還元の影響が大きい。Agoda/Trip.comはアジア圏インバウンドの取り込みに強く、価格弾力性が高い。Expediaはビジネス需要や複数泊の取り込みに使われやすい。直販は「最も利益率が高いが、認知獲得コストが重い」。これらの特性を踏まえて、Claude Codeへ「OTA別の強み・弱みを前提として戦略を組んで」と指示しておくと、出力の質が変わります。

もう一つ、サイトコントローラー(TLリンカーン、ねっぱん、らく通等)経由で各OTAに在庫・料金を配信している場合、配信先制限(クローズアウト・最低宿泊数設定・販売上限設定)を組み合わせることで、レートパリティを維持しながらチャネル別の販売量をコントロールできます。Claude Codeの戦略レポートに「価格は同じだが、配信ルールで差をつける」選択肢を必ず含めるように指示しておくと、契約抵触のリスクを下げられます。

実装パターン5:週次レビュー会議の資料を3分で作る

個人的に一番効率化できたと感じているのがここです。多くのホテルでは週1回、GM・営業・予約・RM担当が集まって「先週の振り返り」「今週の見通し」「来週の戦略」を議論する場があります。この資料を作るのに、従来は担当者が半日くらいかけていました。

Claude Codeに固定構造で生成させると、3分で叩き台が出ます。

あなたはレベニュー会議の資料作成担当です。
入力ファイル(すべて前章までに生成済):
- ./reports/daily_kpi_2026-05.md
- ./reports/demand_forecast_30days.md
- ./reports/rate_intel_2026-05-27.md
- ./reports/ota_strategy_weekly.md

タスク:
週次レビュー資料を以下の固定4ブロック構造で生成してください。
出力先: ./reports/weekly_review_2026-W22.md

ブロック1: 先週KPIサマリ
  - OCC / ADR / RevPAR の週合計と前年同週比較
  - 異常日のハイライト3つまで、原因仮説付き
  - セグメント別(FIT/グループ/OTA/直販)構成比の変化

ブロック2: 今週・来週の需要見通し
  - 需要強度マトリクスから今週・来週の強度4以上の日と1〜2の日をリストアップ
  - 各日付の主要ドライバー(イベント・天候・連休等)

ブロック3: OTAチャネル別ピックアップ
  - 先週の貢献度ランキング(売上・ネット利益・キャンセル率)
  - 今週の推奨露出戦略(強気日/弱需要日のアクション)

ブロック4: 来週の推奨アクション(GM決裁事項)
  - 価格変更を提案する日付と方向性(理由付きで5件まで)
  - OTAキャンペーン参加可否の判断材料
  - リスク事項(予約ペース遅れ・キャンセル増加等の早期警戒)

各ブロックは500字以内に抑え、表を多用してください。
意思決定の責任主体は常にGM・レベニューマネージャー側にあり、
本資料は「議論の素材」として位置づけることを冒頭に明記してください。

この4ブロック構造は、特に最後の「ブロック4:来週の推奨アクション(GM決裁事項)」を必ず最後に置くこと、そして意思決定責任の所在を冒頭で言語化することが効きます。Claude Codeは便利ですが、現場の人間が「AIが言ったから値段を上げました」と言える状態は危険です。会議の議事として残す形を担保しておきます。

運用上の細かい工夫としては、「先週の予測精度評価」を毎週のレビューに必ず入れることをおすすめします。先週時点で「需要強度4」と予測した日が実際にRevPARで強かったのか、外したならなぜ外したのか、を1〜2行記録するだけで、3〜4週間後に予測精度の傾向が見えてきます。需要予測の精度を計測しないと、RM部門の改善サイクルが回りません。Claude Codeに「先週の予測ファイルと今週の実績ファイルを突き合わせて、的中・外れの集計と理由仮説を出して」と毎週指示すれば、評価のループが自動で回り始めます。

会議の時間配分も変わります。私が支援したあるホテルでは、それまで週次レビュー会議が60分かかっていたものが、Claude Code生成資料の導入で40分に短縮されました。短縮された20分は、「来月のキャンペーン企画」「新商品(高単価プラン)の検討」など、人間しかできない上流の戦略議論に振り替えられています。資料作成から戦略議論へ、というシフトが起きるのが本質的な価値です。

レビュー資料のフォーマットを社内で固定化することも重要です。フォーマットを毎回変えると、過去資料との比較がしにくくなり、ナレッジが蓄積されません。「ブロック構造は変えない・テーブルの列も固定・数値の精度(小数点位)も固定」を社内ルール化し、Claude Codeへのプロンプトにも明記しておくと、半年後に「今年4月の連休前と来年4月の連休前を比較する」みたいな縦串分析が一発でできるようになります。

【要注意】Claude Code導入でやりがちな失敗パターン

1年ほど現場で実装支援をしてきて、繰り返し見る失敗パターンを4つ書き残しておきます。

❌ 失敗1:Claude Codeに「最適価格」を直接答えさせる

「明日の価格は?」と聞いて「¥17,800が最適です」と返ってきた値をそのまま入稿する、という運用は危険です。LLMは需要予測の専用エンジンではなく、過去パターンの統計推定と説明文生成の組み合わせで動いています。競合料金監視SaaS・需要予測SaaSの存在意義はまだ消えていません。

⭕ 正解:Claude Codeには「人が判断するための根拠と選択肢」を出させる。「明日の需要強度は4、近隣で◯◯コンサルがあり例年同イベント時はADRが平均+12%。本日時点の予約ペースは前年同日同時刻比+8%。よって推奨レンジは¥17,500〜¥18,500」のように、レンジと根拠で返させる。最終決定は人がする。

❌ 失敗2:PMSデータをそのまま全件投入する

個人情報(宿泊者氏名・連絡先・カード情報)を含むPMSダンプをそのままClaude Codeに渡す事故。これは取り返しがつきません。OTAやPMSの利用規約、自社のプライバシーポリシー、そして宿泊事業者として旅館業法・個人情報保護法上の義務に直接抵触します。

⭕ 正解:PMSからエクスポートする段階で、氏名・連絡先・カード番号・パスポート番号などの個人特定情報を必ず落とす。レベニュー分析に必要なのは「日付・部屋タイプ・販売数・売上・予約経路・リードタイム・連泊数・セグメント」程度の集計データだけです。Claude Codeで前処理スクリプトを書かせるなら、入力時点で個人情報列を除外する処理を最初に固定化しておきます。

❌ 失敗3:競合料金監視で利用規約違反のスクレイピングを実装する

Booking.comやExpediaの公開価格ページをBotで巡回して値を取る、という実装をClaude Codeに依頼すると、技術的にはコードが書けてしまいます。しかし大手OTAの利用規約はスクレイピングを明示的に禁じており、IPブロックやアカウント停止、最悪は法的対応のリスクがあります。

⭕ 正解:OTAのextranet機能で提供されている「マーケットインサイト」「レートインサイト」レポートを公式に取得し、そのCSVをClaude Codeに渡す。または、有料のレートショッパーSaaS(OTA Insight、Lighthouse等)のAPI出力をパースさせる。自社サイトと宿泊予約システムから取れる自社データは自由に使えますが、他社の公開ページは別の話です。

❌ 失敗4:週次レビュー資料を「Claude Codeが作った」という事実を隠す

会議資料の冒頭に「本資料はClaude Codeで生成しました」と書かない運用は、後で必ず揉めます。経営層から「この数字の責任は誰なのか」と聞かれたとき、説明できなくなる。

⭕ 正解:資料冒頭に「叩き台はClaude Codeで生成、最終確認はレベニューマネージャー◯◯」と必ず明記する。AI生成資料であることを隠さず、人が最終確認したという責任の所在を明文化することで、結果的に資料の信頼性が上がります。

RM SaaSとの棲み分けをどう整理するか

「IDeaSやDuettoがあるのに、Claude Codeで何をやるのか」という質問は必ず受けます。私の整理は次の通りです。

• RM SaaS:需要予測・推奨価格算出の数理エンジン。在庫制約・部屋タイプ別最適化など、専門数学に基づく重い計算が強み。
• Claude Code:RM SaaSの出力と、人間系の文脈情報(地域イベント、競合の動き、契約条件、社内の判断ロジック)を統合して、人が読める日本語の根拠書・会議資料・運用ドキュメントに変換するレイヤー。

つまり競合ではなく補完関係です。RM SaaSが「何を売るべきか」を出す層、Claude Codeが「なぜそうするのか・誰に説明するのか」を整える層、と分けると、両方の投資が活きます。

特に中規模(50〜200室)のホテル・旅館だと、RM SaaSのライセンス費用が重く、そもそも導入できていないケースも多い。その場合は、過去予約データのCSVベースで需要強度マトリクスを組むところからClaude Codeで始める、という入口もあります。完璧な予測エンジンを最初から構築するのではなく、「人が判断する材料の準備時間」を半減させることから始めるのが現実的です。

もう一つ、RM SaaSとClaude Codeの組み合わせで威力を発揮するのが「異常検出と説明文生成の分離」です。RM SaaSは数値の異常検出やアラートは得意ですが、その背景にある定性的説明(「近隣でX大学の入学式があり保護者需要が膨らんだ可能性」など)までは生成しません。RM SaaSのアラートCSVを取り込んで、Claude Codeに「アラート対象日それぞれについて、考えられる背景仮説を3つずつ出して」と指示する運用にすると、両ツールの強みが噛み合います。

反対に、Claude Codeに過信しすぎないラインも引いておきます。複雑な在庫制約最適化(複数部屋タイプ・複数日連泊・パッケージ商品の同時最適化)は、整数計画法ベースの数理エンジンが必要で、LLMだけでは荒くなります。「部屋タイプ7種類×30日×3価格戦略の最適組み合わせを出して」のような問題は、RM SaaSや専用のオペレーションズリサーチ系ソルバーに任せるべき領域です。Claude Codeは、その出力を「人が読める言葉に翻訳する層」に徹するのが安全です。

セグメントミックスの最適化:単価だけでなく構成比も見る

RMの上級論点として、「セグメントミックス」(FIT・グループ・OTA・直販・コーポレートなどの構成比)の最適化があります。同じOCC 80%でも、FIT(個人客)主体で構成されているのか、団体ベース料金で埋めているのかでADRが大きく変わり、結果RevPARが変わります。

Claude Codeにセグメント別の月次集計を出させると、「先月は直販比率が下がりOTA比率が上がった結果、コミッション控除後利益が想定より低い」みたいな構造的問題が可視化されます。プロンプト例:

あなたはセグメントミックス分析担当です。
入力: ./data/booking_by_segment_2026.csv (列: month, segment, rooms_sold, revenue_gross, commission_or_discount, notes)

タスク:
1. 月別・セグメント別の構成比(室数ベース・売上ベース・ネット利益ベースの3軸)
2. 前年同月比較で構成比が大きく変動したセグメントを抽出(±5pt以上)
3. 直販比率を1pt上げるとネット利益はいくら増えるかの試算
4. 来月の理想ミックス案を「現状ベース」「OCC優先」「ADR優先」の3シナリオで提示
5. 出力は ./reports/segment_mix_analysis.md

セグメントミックスを意識するようになると、単純な「値下げで埋める」運用から脱却できます。「OCCは少し落ちてもいいから、直販比率を5pt上げてネット利益を確保する」みたいな経営判断ができるようになるのが、データ分析を整備する本当の意味です。

長期ペース管理:30日・60日・90日先のブッキング進捗

もう一つClaude Codeに任せやすいのが、長期ブッキングペースの監視です。ホテル業界では「N日前時点での予約進捗が前年同日と比べてどうか」を継続的に見ることで、需要の早期警戒を行います。これが「ブッキングペース」「リードタイム分析」と呼ばれる領域です。

たとえば「8月のお盆期間のブッキングが、前年同日(現時点で60日前)よりも10%遅れている」と見えれば、まだ手を打つ時間があります。逆に「3週間前時点で前年比+30%」なら、既に強気価格に動かしても完売リスクは低い。Claude Codeで毎週「30/60/90日先の予約ペースが前年比でどうか」を出力させると、議論の起点が早期に動かせます。

あなたはブッキングペース監視担当です。
入力:
- ./data/onthebooks_snapshot_today.csv (今日時点で入っている各日付の予約状況)
- ./data/onthebooks_snapshot_lastyear_sameday.csv (前年の同じリードタイム時点でのスナップショット)

タスク:
1. 30日後・60日後・90日後の各日付について、現時点での予約進捗を前年同リードタイム時点と比較
2. 前年比 -15%以下の日付を「ペース遅延警戒」として抽出
3. 前年比 +20%以上の日付を「強気戦略候補」として抽出
4. 警戒日付それぞれについて、考えられる需要減退要因を3つ仮説提示
5. 出力は ./reports/booking_pace_long.md

ブッキングペース分析の妙味は、「まだ何かをやれる時間」を可視化することです。当日や前日になってからRevPARの低さに気付いても打ち手は限られますが、60日前にペース遅延に気付ければ、キャンペーン投入、OTA露出強化、団体営業強化、レート見直しなど打ち手が複数あります。Claude Codeに毎週月曜の朝にこのレポートを生成させる運用にしておけば、議論が後手に回らなくなります。

導入ステップ:小さく始めて週次会議に組み込む

「Claude Codeを入れてみる」という曖昧な目標は失敗します。週次レビュー会議という具体的なシーンを起点にして、以下の順で組み込むのが私のおすすめです。

1. 第1週:OCC/ADR/RevPARの日次集計プロンプト(実装パターン1)だけ動かす。前年同曜日比較が出るところまで。
2. 第2週:需要予測マトリクス(実装パターン2)を追加。気象庁の週間予報、イベント情報を手動で月初にまとめて投入。
3. 第3週:競合料金監視(実装パターン3)を追加。最初は手作業で取った価格スナップショットCSVから。
4. 第4週:OTA別戦略レポート(実装パターン4)を追加。サイトコントローラーの月次レポートを投入。
5. 第5週:週次レビュー資料統合(実装パターン5)を稼働させ、GM会議で叩き台として使用開始。

1週目から完成形を目指すと挫折します。最低限「前年同曜日比でRevPARが説明できる」状態を作ってから次に進む、という小さな成功体験の積み重ねが効きます。

他業種の「Claude Code × 現場オペレーション」事例も併せて

同じ観光・宿泊・地域経済の文脈で、別アングルの実装パターンも参考になります。レビュー対応の運用についてはホテルの口コミ返信をClaude Codeで整理する事例、観光集客の側面では観光協会の多言語コンテンツ運用事例、需要・供給ギャップを扱う隣接領域として飲食店の需要連動シフト計画事例もあります。料金最適化はあくまでRMの一部であり、口コミ評価・体験設計・周辺集客と一体で考えるとさらに効きます。

FAQ:現場でよく聞かれる質問

Q. PMSと直接連携できますか?

A. Claude Code自体はPMSの公式APIを直接叩く設計ではなく、PMSが提供するエクスポート機能(CSV/JSON)を経由するのが現実的です。PMSベンダーがREST APIを公開している場合は、Claude Codeに「APIクライアントのPythonスクリプトを書かせる」ことは可能ですが、本番運用は社内エンジニアのレビューを必ず通してください。

Q. レベニューマネージャーがいない小規模旅館でも使えますか?

A. むしろ小規模ほど効きます。専任RM担当を雇う余裕がない15〜40室の旅館で、女将や支配人が片手間でRMをやっている場合、Claude Codeの「指標自動集計+前年比較+異常日抽出+簡易な根拠書」だけでも十分価値があります。完璧を求めず、まず「昨日のRevPARが前年比でどうだったか」を毎朝3行で要約させる運用から始めてください。

Q. 個人情報を扱う場合の注意点は?

A. 前述の「失敗パターン2」の通り、PMSダンプを生で投入しないこと。エクスポート時点で個人情報列を落とす運用ルールを社内で固めること。Anthropicの利用規約・データ取り扱いポリシーも事前に確認してください(出典欄参照)。

Q. RM SaaSを既に導入していますが、それでもClaude Codeを入れる意味はありますか?

A. あります。RM SaaSは推奨価格を出してくれますが、「なぜそうなのかをGM・営業・OTA担当に説明する文書」までは作れません。RM SaaSの出力CSVを取り込んで、「今週の推奨価格変更の根拠書」を日本語で生成させるところに価値があります。

Q. 既存のExcelベースの管理から移行する場合、どう進めればいいですか?

A. Excelの構造を変えずに、ExcelをCSV保存してClaude Codeに渡すところから始めるのがおすすめです。フォーマットを大幅に変えると現場が混乱します。Claude Codeが集計した結果を、Excelに戻して上書きする、という運用も可能です(プロンプトで「出力をCSV形式で保存」と指示)。

Q. インバウンド比率が高いホテルですが、為替の影響をどう組み込めますか?

A. 円安・円高は訪日客の購買力を直接動かすため、ADR設定戦略に影響します。プロンプトに「対ドル・対ユーロのレート水準と前年比を考慮し、訪日客の購買力動向を踏まえた価格戦略を提案して」と書いておくと、Claude Codeが為替を変数として組み込んだ説明を返してきます。為替実数値は日銀公表データを月初に投入する運用がおすすめです。為替を踏まえると、欧米客の比率が高い高単価ホテルでは、円安期に強気価格を取りに行く戦略が成り立ちます。

Q. RM SaaSが出した推奨価格と、Claude Codeの説明が矛盾したらどうすればいいですか?

A. これは「気付くべき重要シグナル」です。多くの場合、RM SaaSは数値最適化に強いが、近隣イベントや特殊事情の織り込みが弱い。逆にClaude Codeは説明力が強いが、数理最適化は粗い。両者が矛盾する日付こそ、人が深掘りすべき日付です。私の運用では、矛盾日リストを毎週GMに提出し、最終判断を仰ぐルールにしています。

Q. 旅館特有の「お料理プラン」や「部屋食/食事処」の選択肢が複雑です。これも扱えますか?

A. 扱えます。プラン構造を入力CSVに含めれば、Claude Codeがプラン別の予約傾向・粗利・キャンセル率を分析し、「現状のプランラインナップで売れていないプランの整理」「新プラン造成の候補」を提案できます。ただし、料理素材の調達単価・人件費などのコスト構造は施設ごとに大きく異なるため、原価データを必ずプロンプトに含めてください。原価情報なしで「利益最大化プラン」を提案させると、現場感とズレた回答が出ます。

セキュリティ・コンプライアンスの再確認

最後に、Claude Codeを業務に組み込む上での非機能要件を簡単にまとめます。料金最適化のデータは機密性が高いため、ここを軽視するとリスクが大きい。

• 個人情報を投入しない:前述の通り、宿泊者氏名・連絡先・カード情報・パスポート番号などは絶対に入れない。エクスポート段階で除外する。
• 競合情報の取得経路を確認:OTAの利用規約・robots.txt・契約条項に照らして合法な取得経路を使う。自社サイト・自社の予約システムから取れるデータは自由。
• レートパリティ条項に抵触しない範囲で運用:OTAとの契約条項を確認し、価格差別化の余地と制約を社内で整理。Claude Codeに「契約に抵触しない範囲で」と指示することで保険にはなるが、最終確認は人がやる。
• 生成ログのバックアップ:意思決定の根拠書面は監査証跡として残す。週次レビュー資料はリポジトリ管理・バックアップを推奨。
• 権限管理:Claude Codeへのアクセス権限と、業務システム(PMS・サイトコントローラー)の権限を社内で整理。退職者のアクセス権を残さない。

これらは「Claude Codeだから」というよりは、業務システムを使う上での一般原則です。新ツール導入のタイミングで社内ルールを整備する機会にもなります。

著者プロフィール

佐藤 傑(さとう・すぐる)
株式会社Uravation 代表取締役。X(@SuguruKun_ai)フォロワー約10万人。100社以上の企業向けAI研修・導入支援を提供。著書『AIエージェント仕事術』(SBクリエイティブ)。SoftBank IT連載7回執筆。Claude Codeを業務基盤の中核に据え、観光・宿泊業を含む複数業界の実装支援を行う。

次のアクション

1. 今日10分で:直近1ヶ月分のPMSエクスポートCSVを用意し、本記事の「実装パターン1」プロンプトをそのままClaude Codeに投げて、OCC/ADR/RevPARの自動集計が動くことを確認する。
2. 今週中に:需要予測マトリクス(実装パターン2)を試作し、向こう30日の「需要強度ヒートマップ」を生成してGMにレビューしてもらう。違和感がある日付の修正フィードバックを集める。
3. 今月中に:週次レビュー会議の資料生成(実装パターン5)を本番投入し、資料作成時間が30分→3分になることを実測する。同時に「Claude Codeで叩き台生成、最終確認はRM担当」という責任分界を社内文書化する。

もし「自社のPMSデータでこの実装を回せるか相談したい」「週次レビュー資料の固定テンプレを業務に組み込む伴走をしてほしい」というニーズがあれば、株式会社UravationでClaude Code導入の個別指導・コンサルティングを提供しています。ホテル・旅館業に限らず、観光・宿泊・地域経済領域でのレベニュー業務全般を支援しています。

参考出典

• Anthropic公式 – Claude Code ドキュメント:https://docs.claude.com/en/docs/claude-code/overview
• Anthropic公式 – 利用規約・データ取り扱いポリシー:https://www.anthropic.com/legal/commercial-terms
• 観光庁「宿泊旅行統計調査」(OCC・客室稼働率の公的統計):https://www.mlit.go.jp/kankocho/tokei_hakusyo/shukuhakutokei.html
• 気象庁 – 週間天気予報・2週間気温予報(需要予測の天候変数として使用):https://www.jma.go.jp/bosai/forecast/
• 日本政府観光局(JNTO)統計レポート(訪日需要トレンド):https://www.jnto.go.jp/statistics/data/

※本記事の数値例(「30分→3分」「+18%」等)は実装イメージを伝えるための想定値です。実際の効果は規模・運用体制・データ品質によって大きく異なります。実在ホテル名は使用していません。Claude Codeは分析・レポート生成の補助エージェントであり、最終的な料金決定および対外発信の責任は、各ホテルのGM・レベニューマネージャー・経営層が負うことを前提としています。

関連記事（自動）

• ▸ 【2026年版】観光協会DMOの5言語対応をClaude Codeで効率化
• ▸ ホテルの口コミ返信をClaude Codeで整理｜多言語レビューと改善レポート