星野リゾートは何故18億円も投じて自社予約システムを開発したのかを考察

目次
はじめに
2025年10月、星野リゾートは自社開発による新しい予約システム「FleBOL(フレボル)」を発表しました。
注)FleBOL:Flexible Booking On Lineの略
ChatGPT:
報道によると、その開発投資額は約18億円にのぼるそうです。
一見すると、宿泊予約という限られた領域に対して驚くほどの金額です。
星野リゾートはなぜこれほどのコストをかけて自社開発に踏み切ったのでしょうか。
約18億円という投資額は高いのか?安いのか?果たして何年で回収できるのか?
そのような疑問から背景を掘り下げると、「AI時代」「直販化」「顧客体験」「データ主権」といったキーワードのもと、宿泊ビジネスの中枢を自らの手に取り戻そうとしている姿勢が見えてきました。
“AI予約時代”への先回り(将来の購買導線の変化)
近い将来、旅行予約は人ではなくAIエージェントが条件を会話で受け取り、自律的に検索・予約する形にシフトすると考えられています。
星野リゾートはその未来を見据え、「AIに選ばれる」ために、APIやデータ仕様、在庫提示ロジック、価格制御の主導権を握る必要があると判断。
既存の汎用システムではスピードや柔軟性が足りず、自社開発は“次世代購買体験の基盤投資”であることがうかがえます。
直販強化と“OTA依存”の脱却(流通コスト・主導権の回収)
ホテル業界全体でOTA(オンライン旅行代理店)依存を下げ、直販へ回帰する流れが強まっています。
星野リゾートもこの潮流を踏まえ、顧客との接点を直接持つ「直販チャネル」を最適化。価格や在庫の主導権を自社に取り戻すことで、長期的な利益体質を確立しようとする取り組みと言えるでしょう。
CX(顧客体験)の“不可逆的”改善:変更・組み合わせ自由
星野リゾートでは、予約変更に関する問い合わせが全体の約4割を占めていたといいます。
この課題を解決するため、オンライン上で自己完結できる新たな仕組みを導入。
部屋タイプ/人数/日程/プランの変更を、チェックイン当日9時まで可能にし(チェックイン当日9時まで、日程変更は90日以内で3回まで、事務手数料1,000円)顧客のストレス、キャンセル率、コールセンター負荷の同時削減を狙うものです。
機能分散の解消(PMS・Web・体験の統合アーキテクチャ)
宿泊・食事・アクティビティ・移動といった要素を“動的パッケージ化”し、まるでECサイトのように自由に組み合わせて予約できるようにするため、マイクロサービス/API中心の設計に刷新。
既存のホテルPMSではこの柔軟性が実現できず、自社モデルの設計が必要でした。
キャンセルポリシーの再設計(価格・在庫の弾力化)
新システムでは、キャンセル料の上限を最大30%に引き下げる方針を打ち出しています。
柔軟な予約変更と整合性を保ちながら、需要変動に応じて在庫や価格を最適化できる設計を目指しています。
需要変動に応じた在庫・価格の最適化をシステム側で機動的に回すための土台投資でもあるといえます。
スケールと内製力の強化(恒常的な改善サイクルの内製化)
70超の施設規模があるからこそ、投資回収が見込めます。“予約は生命線”という経営判断のもと、スクラム体制での内製・共創を進め、機能を連続投入できる体制を固めにいっています。
自社主導の開発体制へと移行し、改善サイクルを外注依存ではなく、自社の継続的な資産に変えていく試みです。
詳細分析
さらに詳細な分析・考察を進めます。
■将来の予約導線が“AI主導”になる前提での土台作り
会話で条件を伝えると、AIが自動で条件を組み合わせ、宿泊プランを提案・予約する時代では、在庫や料金、制約条件を機械可読で提示できるかどうかが鍵になります。外部ベンダの汎用エンジンだとAPIやデータ仕様の制約が大きく、新仕様対応のリードタイムがビジネスのボトルネックになるため、自社API設計を握ることは、経営の生命線といえます。
■直販の経済性×データ主権の回復
OTA経由の予約は販管費が高く、顧客データの主導権も失います。
直販に回帰する潮流のなかで、LTV(顧客生涯価値)最大化のための1stパーティデータを自前で蓄積・活用できる設計が必要でした。
■“変更ストレス”の解消が収益性にも効く
オンラインで変更を完結できるようにすることで、顧客満足度の向上はもちろん、アップセル率や再来訪率の改善にも効果があります。
変更対応の自動化は、CX改善・運用コスト削減・収益最大化を同時に実現できる施策です。
■体験の“動的パッケージ化”に耐えるアーキテクチャ
顧客が体験を自由に組み合わせられるようにすることは、顧客単価を引き上げるうえで大きな効果を発揮します。
そこで客室×食事×アクティビティ×移動を動的に組み替えるには、在庫・料金・制約(可用時間/定員/同時予約不可など)の一元モデル化が不可欠です。既製PMSの周辺改修では限界があり、ドメイン知識を踏まえた自社ドメインモデルを設計・保守するほうが長期TCOで優位になりやすいと言えます。
■ルール変更を即座に反映できる
キャンセルポリシーや価格ルールを変更するたびにベンダ調整が必要では、経営スピードが止まってしまいます。
価格・在庫・キャンセル条件は需給環境に即応して改定が発生する領域です。自社でロジックとUI/規約反映を完結できれば、機会損失と実装遅延コストを削減することができます。
■スケールが投資回収を可能にする
70施設以上を束ね、共通基盤に展開できるスケールを持つことで、18億円という投資は「プラットフォーム投資」として十分に回収可能と考えられます。
“18億円”という金額の妥当性(いったんここまでのまとめ)
星野リゾートが開発したのは、単なる「予約フォーム」ではありません。
在庫管理、変更機能、料金ロジック、キャンセル制御、決済、会員統合、多言語対応、AI接続基盤を一体化したシステムです。
つまり、フロントからバックオフィスまでを貫くプラットフォーム再設計であり、外部Saasの寄せ集めでは難しいため、18億円は「インフラ+UX+AI対応+運用資産」のすべてを内包する妥当な投資といえます。
中堅〜中規模ホテル・宿泊事業者が取り得る3つのパターン
星野リゾートのような規模の企業だからこそ可能な戦略である一方で、「自社予約システムの刷新」「顧客体験の再設計」といった課題は、規模を問わず共通しています。
【参考:星野リゾートの公開データ((公開資料の時点は括弧内)】
従業員数:4,922名(2025年7月時点)。
売上規模:公開資料では「Annual Transaction Volume=97.6 Billion JPY(約976億円)」と記載(2025年)。※同社の“取扱高”の表記で、厳密な会計上の売上高とは区別されています。
拠点数(運営施設数):71施設(2025年7月時点)。
※出典はいずれも星野リゾート公式の最新プレスキット(英語版)。REIT(上場投資法人)の数値は別主体のため、本体の従業員数・取扱高とは区別。
ここでは、中堅〜中規模の宿泊事業者が検討できる3つのアプローチをご紹介します。
① 既成SaaS利用(パッケージ型)
想定コスト帯
-
月額・部屋数ベースのサブスクリプション料金:例として「
ホテル向けSaaS料金は、部屋数+機能によって変動」。 -
ウェブサイト開発+予約ウィジェット導入:小規模なら数千ドル~
数万ドル(米ドル)という数字も。 -
導入工数やカスタマイズを少なくすれば、初期費用も抑えられ、「
既成をそのまま使う」ならかなり低コストで開始可能。
メリット
-
実装・ローンチが速い:インフラ構築・
基本機能が既に用意されているため。 -
導入・運用コストが比較的低め&予測可能:
サブスク型であるため予算化がしやすい。 -
ベンダ側で運用・保守・アップデートを担ってくれるため、
ITリソースが少ない場合でも使いやすい。
デメリット
-
カスタマイズに限界がある:細かな業務フローやブランド体験、
独自連携を求めると「できない/コストが跳ね上がる」。 -
他社と“同じ仕組み”になる可能性が高く、差別化が難しい。
-
将来的に「自社要件が変わった」「拡張したい」ときに、
SaaSベンダの仕様制限やコスト増の壁が出る。
検討時のポイント
-
自社の「必須機能」と「どこまで妥協可能か」を棚卸すべき。
-
サブスク料金がどう部屋数・施設数・
機能数でスケールするかを確認。 -
運用&保守(例:多言語対応、API連携、アップセル機能、
変更可能性)をどこまでカバーできるかをチェック。 -
将来拡張(例:アクティビティ予約、ダイナミックパッケージ、
AIエージェント対接)を想定して、「このSaaSで十分か」 を早期に判断。
② ハイブリッド型(SaaS+コア機能自社化)
想定コスト帯
-
基礎機能はSaaSでまかないつつ、予約変更ロジック、部屋/
プラン組み替え、API連携、 自社データ統合などコア領域を自社/カスタム開発で構築。 -
コア開発部分のみを数千万円~1億円クラス(施設数・機能規模・
改修範囲により大きく異なる)に抑える設計も可能。 -
ソースによれば一般的な予約システム開発でも「数万ドル~
数十万ドル」規模という報があり(例:$5,000~$70, 000)
メリット
-
コストを抑えながら、自社の優位性・差別化要件を実装できる。
-
将来の拡張や自社運用を見据え、「鍵となる機能だけ内製化・
他はプロダクト任せ」できるためバランスが取れる。 -
SaaSの立ち上げスピード+内製化による柔軟性が両立可能。
デメリット
-
自社化する部分に対しての設計・運用・保守といった責任が残る。
-
組み合わせ設計が複雑化するため、要件定義/整合性/
データ設計が甘いと「後でコストの塊になる」。 -
将来的にSaaS側の仕様変更があった場合、
カスタム部分との整合戻りが発生しやすい。
検討時のポイント
-
内製化・カスタム化するべき「差別化機能(例:変更自由度、
密なアップセル設計、AIエージェント接続など)」 を明確にする。 -
SaaS部分/
カスタム部分それぞれの運用保守コストも試算する。 -
データ連携・API設計・将来のスケーラビリティを想定して、
構成を“使い捨てにならない”よう設計。 -
SaaSベンダと自社自社化部分がどう連携するか(契約・仕様・
変更余地)を予め確認。
③ 完全自社開発(フルスクラッチ)
想定コスト帯
-
規模・機能・改修期間・施設数・将来展開範囲・
マイクロサービス化・多言語/多通貨対応などによって、数億円〜 数十億円 になる可能性あり。 -
ホスピタリティ業界向けガイドでは「カスタム開発」の例として$
15,000~$150,000といった小~ 中規模ホテル向け目安も存在。 -
しかし、ブランド/チェーン/多施設展開/
複雑な体験設計を前提とすると、今回のように“18億円” という規模も理にかなっている。
メリット
-
ブランド固有の予約・体験設計を完全に制御できる。
-
仕様変更・将来展開・AI対応・データ活用・UX刷新など「
自由度・競争優位性」が最大化される。 -
自社運用ノウハウが蓄積され、「プラットフォーム資産」
として長期にわたる競争力を生む可能性がある。
デメリット
-
初期投資が巨額且つ、回収まで時間がかかる。
-
開発/運用/保守/改修が自社責任で、IT人材・
プロジェクト管理・ガバナンスが不可欠。 -
仕様変更や拡張時の費用・リスク(運用負荷・遅延・バグ)
も大きい。
検討時のポイント
-
投資回収計画(ROI)を明確にする:
直販化によるOTA手数料削減、予約変更率低減、 アップセル率向上、ブランドLTV改善など。 -
内製体制(人材/組織/ガバナンス)を持つかどうか、
また外部協力体制(ベンダ・開発パートナー)をどう設計するか。 -
将来展開(多施設横展開、海外展開、AIエージェント対応等)
を前提とした設計にして、使い捨てにならない構造とする。 -
機能範囲・段階実装(MVP → 機能拡張)を明確にして、コスト管理とリスク低減を図る。
どのパターンを選ぶべきか:中堅宿泊事業者への提言
あなたが中堅企業(例:数施設~十数施設、ブランド化志向あり)
-
まず「差別化要件」「将来どこまで展開したいか」を洗い出す。
予約変更の柔軟性、アクティビティ・ 移動を含めた動的パッケージ、AI/データ活用、 直販率向上など。 -
自社にとって “既成SaaSで十分”か/“将来大きく変えたい”
かを見極める。もし「今は標準機能で十分だが将来伸ばしたい」 というフェーズなら、ハイブリッド型がバランス良い。 -
導入スピードと予算(初期コスト・年間運用コスト)
を適切に見極め、ローンチ時点で“使えない” 機能ばかり作らない。 -
将来展開(施設増/他領域拡張/グローバル化)を念頭に置き、
拡張性・データ統合性・運用体制を初期設計段階で検討する。 -
常に「変更可能な設計」「データの自社所有」「API・
サービス連携可能な構造」にしておく。これが将来の運用コスト・ 技術負債の軽減に直結。
結論:自社で「主導権」を握るという戦略
星野リゾートの18億円投資は、単なる“高額案件”ではありません。
それは「顧客接点とデータ主導権を取り戻すための構造投資」であり、AI時代において“選ばれる宿泊ブランド”になるための布石です。
一方で、中堅・中小規模の宿泊事業者にとっては、必ずしもフルスクラッチ開発が最適解とは限りません。
重要なのは、自社がどこまでをコントロールすべきかを明確にし、“システムを持つ”のではなく、“主導権を持つ”方向に設計することです。
※文中で触れた数値・仕様は報道および公開資料に基づいています。
出典:日経クロストレンド、PRTIMES、BUSINESS INSIDER JAPAN ほか
この記事を書いた人について




