サイトコントローラー開発の発注/外注/依頼/委託方法について

サイトコントローラーの発注は、業務と連携条件の整理、発注形態と契約の選定、候補比較と検証の順に進めます。この順で進めると、現場に合った運用につながります。

発注の全体像は、サイトコントローラー開発の完全ガイドにもまとめています。

▼全体ガイドの記事
・サイトコントローラー開発の完全ガイド

Webサービス開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。

サイトコントローラーの発注・外注の意味

サイトコントローラーの発注・外注とは、OTA、自社予約エンジン、旅行会社、PMSの間で在庫・料金・予約をつなぐ仕組みを、外部の会社に依頼することです。

依頼の形としては、既存サービスの導入、追加連携、受託開発があります。

観光庁の「宿泊施設のためのIT活用ハンドブック」でも、予約情報をまとめて管理する仕組みが説明されています。

サイトコントローラーは、複数の予約サイトや自社ウェブサイトの空室・予約状況を集約し、二重予約の防止や空室の配分を支援します（出典：観光庁、令和7年度資料）。

予約業務全体をつなぐ連携基盤の役割

サイトコントローラーは、宿泊予約業務の情報やシステムを連携します。

• 販売情報：客室在庫、料金、プラン、予約・変更・キャンセルを販売先に反映
• 館内業務：PMSを経由した、フロント、清掃、会計への予約連携
• 販売分析：RMSなどを使った稼働率、ADR、リードタイム、キャンセル率の把握
• 連携方式：予約のみの1WAY、在庫・料金も更新する2WAY、詳細な状態を連携する方式

連携項目や反映の方向は製品ごとに異なります。そのため、項目、方向、更新頻度まで確認して比べます。

開発作業と運用設計をまとめて任せられる外注の価値

外注先には、宿泊業務に沿った設計・開発と、運用の準備を頼めます。

• 接続・移行：OTAとの接続条件、部屋タイプやプランの対応、既存予約の移行
• 現場運用：二重入力や、同期に失敗したときの手動更新
• 管理設計：権限、操作履歴、委託する設計・開発・教育・保守の範囲

在庫の正となるシステムと料金変更の責任者は、発注側で決めます。

業務ルールと最終判断は社内に残します。

発注形態の選び方

発注形態は、導入までの速さと施設・部屋数を基準に選びます。OTA・PMSの接続数、独自の料金ルール、社内の保守人材も、判断の材料になります。

標準機能で業務をまかなえるならSaaS、既存機能を活かして不足部分だけ変えるなら追加開発が候補になります。また、販売管理そのものが競争力になる場合は、スクラッチ開発を検討します。

標準SaaS・クラウドサービスの導入

SaaS型では、OTA接続や在庫・料金・予約管理を備えたサービスを契約し、初期設定とデータ移行を行います。

• 導入：自社で設備を構えにくい小規模施設や、短期間で乗り換えたい施設に向く
• 運用負担：OTA仕様やクラウド基盤の更新は、ベンダーの担当
• 標準機能：特殊な共通在庫や独自料金、地域OTA、複雑な団体予約は、再現できないこともある
• 契約条件：対応OTA・PMS、連携項目・間隔、API上限、サポート、データ出力

社内に開発要員を抱えずに始めやすい点も、SaaS型の利点です。

既存パッケージと追加開発の組み合わせ

標準サービスだけでは足りないものの、在庫や予約の基本機能を作り直す必要はない場合に、追加開発を組み合わせます。

• 追加機能：PMSとの2WAY接続や、自社予約への在庫配信
• 施設・社内連携：複数施設をまたぐ横断集計や、予約者情報の社内連携
• 見積内訳：標準機能、設定、追加開発、外部API、移行支援を分けて示す
• 保守条件：API公開範囲、更新時の互換性、追加部分の保守責任

見積の範囲が曖昧なままだと、製品の更新のたびに改修が必要になりやすくなります。そのため、契約書にも条件を残しておきます。

独自の販売管理基盤をスクラッチ開発する形態

業務を標準製品に合わせるより、独自の業務に合わせて開発するほうが適する場合に検討します。

• 適用候補：独自料金や複数ブランドの在庫、独自チャネル、特殊な部屋割り
• 統合範囲：予約から清掃・会計までの業務
• 継続負担：OTA仕様変更への対応、24時間監視、セキュリティ更新、障害復旧
• 引き継ぎ：開発会社を替える場合の移管
• 段階導入：1施設と主要OTAで小さく本番導入し、同期・キャンセル・PMS連携・手動復旧を確かめる

標準製品に合わせる場合と比べて、独自開発が適する範囲を見極めます。

KPIを確認しながら施設を増やすと、発注のリスクを抑えられます。

発注前にRFPと要件を整理する方法

RFPは、候補会社へ発注の前提を伝える文書です。RFPには、現状業務と課題、対象範囲、連携条件を書きます。さらに、成果指標や日程、予算、発注条件も含めます。

候補ごとに前提がずれると、見積を正しく比べられません。そのため、現行の業務と希望する姿は分けて記載します。

現行の予約業務とKPIの洗い出し

まず、施設数、部屋数、部屋タイプ、プラン数、利用しているOTA、旅行会社や電話予約の受け方を一覧にします。PMS、会計、清掃、決済、セルフチェックインとの関係も整理します。

直近の予約・変更・キャンセルを複数確認し、担当者がどの画面へ何回入力しているかを業務フローにまとめます。在庫を確定する場所も、あわせて明記します。

• 作業効率：作業時間と料金更新にかかる時間
• 予約運用：予約の取り込み漏れ、在庫の差異、キャンセル処理の時間
• 販売状況：オーバーブッキングの件数、OTA別の稼働率、ADR、直販比率
• 問い合わせ：件数

導入前の数値がなくても、対象施設と集計方法を決めておけば、導入後の効果を委託先と共有できます。

連携項目と在庫・料金の正の決め方

RFPには、接続先と扱うデータ、更新方式、在庫・料金の基準を、同じ粒度でそろえて書きます。

• 接続先：OTA、自社予約、PMS、旅行会社、RMS、決済、清掃、会計
• 対象データ：予約、変更、キャンセル、宿泊者情報、部屋・プラン・料金・在庫、販売停止、ノーショー
• 連携方式：公式API、CSV、バッチ、手入力のどれにするかと、リアルタイム・数分間隔・日次などの頻度
• 基準システム：PMS、サイトコントローラー、自社予約エンジンのうち、どれを在庫・料金の正にするか
• 例外処理：同時予約の優先順位、重複排除、再送、手動修正後の再同期の方法

在庫や料金の基準が曖昧だと、更新が循環して差異が生まれます。どこを正にするかは、要件の段階で決めておく必要があります。

障害・移行・権限まで含めたRFPの記載

障害時の動き方や、契約終了後のデータの扱いも、RFPに含めておく必要があります。

• 障害対応：検知、通知、再送、手動更新、復旧確認、重複照合
• 繁忙期対応：販売停止を判断する基準と、電話予約の記録先
• 情報管理：担当者別の権限、MFA、IP制限、操作ログ、バックアップ、脆弱性対応
• 委託・終了：再委託先、保存場所、データ返却と消去証明

2026年3月に公表された経済産業省などの指針は、開発・供給・運用側と利用者の役割分担を示しています。

セキュリティも、RFPと見積に含めます。

契約形態の選び方と発注後の管理

契約形態は、要件がどれだけ確定しているかと、変更がどれくらい多いかで選びます。成果物と検収条件が明確な開発なら請負、調査や要件定義、運用支援なら準委任が候補になります。

また、経済産業省のソフトウェア開発委託モデルは、工程ごとに契約を分ける考え方を示しています。企画や要件定義支援を準委任型、外部設計や開発を請負型と位置づけています。

要件が確定した開発の請負契約と検収

請負契約では、完成の基準を決めたうえで、業務シナリオに沿って検収します。

• 機能：在庫、料金、予約変更、キャンセル、重複予約排除、PMS連携
• 管理・品質：権限、操作ログ、帳票、性能、移行データ
• 予約シナリオ：通常予約と同時予約、連泊、部屋変更、料金改定、キャンセル料、ノーショー
• 異常系：APIエラーや再送、繁忙期の大量予約

合格基準と未達時の修正期限・回数、テストデータ、不具合対応は、契約書と仕様書でそろえておきます。

準委任・ラボ型契約の作業範囲と変更管理

準委任やラボ型契約では、調査や要件定義、設計支援、開発チームの稼働、運用支援などの役務を受けます。現場を見ながら仕様を整理する段階に向いています。

作業時間や人員が増えると費用も変わります。そのため、月ごとの稼働予定と担当者、成果物、バックログ、レビューの頻度を、あらかじめ合意しておきます。

また、意思決定者と追加要望の扱いも決めておきます。対象OTAが増えた場合や、PMSのAPIが足りないと判明した場合は、影響範囲と費用を変更要求票で管理します。

保守契約とデータ返却の確認

開発後の保守の範囲と、解約時に返すデータは、別々に決めておきます。

• 保守範囲：問い合わせ、障害調査、修正、OTA変更、更新、バックアップ、監視、復旧
• 対応水準：24時間対応の要否、重大障害の一次回答時間、復旧目標
• 返却データ：予約・顧客・料金履歴、操作ログ、マスタと部屋・プラン対応表
• 返却条件：項目、期間、文字コード、費用、期限、消去証明

CSVだけでは部屋タイプやプランの対応表が付かず、再利用できない場合があります。対応水準は、施設の営業形態に合わせて決めます。

サイトコントローラーの費用相場と見積の内訳

費用は、施設・部屋数に加えて、OTA・PMSの接続数、1WAYか2WAYか、料金・プランの複雑さで変わります。さらに、移行件数や教育、監視、保守も費用に影響します。

月額だけで比べると、初期設定、API連携、データ移行、現地支援などの別料金を見落としがちです。予約エンジン、RMS、セルフチェックインの料金も、比べる際に抜けやすい項目です。

標準SaaSは初期0〜55,000円、月額6,600〜18,000円程度の公開料金例

公開料金の例を見ると、標準SaaSの初期費用と月額を構成ごとに比べられ、構成別の予算感をつかめます。

ねっぱん！サイトコントローラー＋＋の初期設定料は55,000円です。

月額は、5室以下が6,600円、6室以上が10,780円です（出典：楽天トラベルサービス株式会社の公式料金ページ、2026年8月確認）。

Check Innは初期費用が無料で、基本料金は18,000円／月・施設からです。

PMS、サイトコントローラー、自社予約システムを含む利用例では、10室で月額27,000円、30室で35,000円です。

• ねっぱん！サイトコントローラー＋＋：初期と月額の公開料金例
• Check Inn：施設数や連携構成ごとの公開料金例
• 小規模・単体：サイトコントローラーだけの場合で、初期0〜10万円、月額0.7万〜2万円程度
• 複数機能：PMS等を含めた場合で、月額1.8万〜5万円程度

複数施設の運用や分析、RMSを含めると、月額5万〜15万円以上になることもあります。

ただし、Check Innの実際の費用は、契約条件やオプションで変わります（出典：Check Inn公式料金ページ、2026年8月確認）。

追加連携は100万〜500万円、連携基盤は500万〜1,500万円程度という推定目安

追加開発の推定費用と期間は、規模に応じた目安です。予算を検討する際の参考として使います。

• 初期設定・CSV移行：10万〜50万円程度
• 小規模API・PMS連携：1〜3個のAPIやPMS連携を追加する場合で、100万〜500万円程度
• 複数システム基盤：複数のOTA、PMS、自社予約、決済、RMSを含み、500万〜1,500万円程度
• 大規模開発：複数ブランド、多施設、独自の価格エンジン、分析基盤、24時間運用設計を含むと、1,500万〜3,000万円以上の可能性
• 推定期間：標準導入は2週間〜1か月、PMS連携・移行は1〜3か月、独自API・画面・料金ロジックは3〜9か月、基幹刷新級は9〜18か月

これらは、一般的なAPI連携や業務システム開発の工数を基にした目安です。サイトコントローラー独自の公表平均ではありません。

要件を減らしても、費用は同じ割合で下がるとは限りません。ただし、テストと障害対応の工数は、削らないことが大切です。

初期費用とランニング費用を分けた見積の比較

見積では、初期費用と継続費用を分けて書いてもらい、公開料金の例も総額とは区別して見ます。

• 初期費用：要件定義、設定、画面・API開発、移行、テスト、教育、リリース
• 継続費用：利用料、各種連携、決済、監視、保守、サポート、追加施設・ユーザー、データ出力
• AirHost連携例：初期10万円、基本5,000円と1室100円、移行支援22,000円から（出典：AirHost公式料金ページ、2026年8月確認）

AirHostの例は、連携と移行の料金であり、単体の総額ではありません。

ねっぱん！もPMS連携の初期費用や月額を、方式ごとに設定しています。

製品の基本料と連携費を合算して、TCO（総所有コスト）を算出します。

委託先選定と見積比較で確認すべきポイント

委託先は、実績数だけでなく、宿泊業務と接続仕様への理解、稼働後の障害対応力で選びます。特に、同期エラーの復旧や移行を説明できない会社は、慎重に評価します。

OTA・PMSの接続実績とサポート体制

候補会社は、接続実績、サポート条件、導入事例の再現性で確かめます。

• 接続実績：予定するOTA、PMS、予約エンジン、決済、RMSと施設規模
• 製品例：TEMAIRAZUは国内外の販売先、PMS・RMS・チェックインと連携。TL-リンカーンは約6,100施設（出典：各社公式製品情報、2026年8月確認）
• サポート：受付時間、休日、重大障害の一次回答、OTA変更通知、現地支援、教育、マニュアル
• 事例確認：施設・OTA数、手入力、移行範囲、削減作業、障害対応を尋ねる
• TL-リンカーン：旅行会社とネット販売を一元管理し、PMSと2WAYで連携（出典：各社公式製品情報、2026年8月確認）

事例の条件を自社と照らし合わせ、同じ導入効果を再現できるかを判断します。

同じ粒度でそろえた見積と除外項目の比較

見積を比べるには、依頼条件と費用項目をそろえ、除外される範囲も確認します。

• 共通条件：同じRFP、予約シナリオ、接続先一覧を各社へ渡すこと
• 見積項目：要件定義、設計、開発、接続、設定、移行、テスト、教育、保守等
• 比較単位：数量、単価、工数、期間、担当範囲
• 除外確認：PMS設定、OTA接続申請、過去予約移行、現地立ち会い、夜間リリース、障害監視、診断、データ返却、追加施設、仕様変更、消費税、交通費

見積は、除外分を足した「想定最大額」でも比べます。

小規模PoCと受入テストによる現場適合性の確認

候補を2〜3社に絞ったうえで、代表施設と主要OTAを使ってPoCやデモを行います。

• 予約ケース：通常予約、連泊、部屋変更、キャンセル、同時予約、料金改定
• 連携・障害：PMS連携とAPI障害時の再送を、実データに近い条件で検証
• 操作評価：作業時間、入力回数、エラー発見、料金承認、変更履歴、問い合わせやすさ
• 評価体制：実際の操作担当者による評価

観光庁の2026年事例集では、PMSとサイトコントローラーの一元管理や、リモートロック・動画マニュアルによる省力化が紹介されています。

発注側は、自社の課題に同じ効果が期待できるかを、導入後のKPIと受入条件に落とし込みます。

サイトコントローラー発注・外注のよくある質問

判断は、料金だけでなく、施設規模、既存システム、連携項目、運用体制によって変わります。自社の条件に当てはめて確認します。

サイトコントローラーはスクラッチ開発とSaaSのどちらがよいですか？

標準的なOTA・PMS連携を早く導入したいならSaaS、独自料金の計算や多施設共通在庫が競争力に直結するなら、追加開発やスクラッチが候補になります。

まず、SaaSの不足をAPI連携で補えるかを確かめます。そのうえで独自開発の範囲を決めると、過剰投資を抑えられます。

何室くらいからサイトコントローラーの外注効果が出ますか？

一律の室数基準はありません。5室以下でも、複数のOTAを使い、料金や在庫を頻繁に更新する施設なら、手入力を減らす効果が出やすくなります。

100室以上でも、単一のチャネルで変更が少なければ、優先度が低い場合があります。判断の際は、作業時間、取り込み漏れ、オーバーブッキング、販売機会損失を月額と比べます。

RFPには最低限何を書けばよいですか？

施設・部屋数や、OTA、PMS、予約エンジンなどの基本情報を記載します。在庫と料金の正をどこに置くかも、あわせて書きます。さらに、連携項目と頻度、予約・変更・キャンセルの扱いも含めます。

RFPには、移行データや権限、ログ、障害復旧も必要です。さらに、検収、納期、予算、保守条件も含めます。現行の課題と将来の機能は分けて書き、各社が同じ前提で見積を出せるようにします。

見積が安い会社をそのまま選んでも問題ありませんか？

安さ自体は問題ありませんが、対象範囲や連携方式、移行件数を同じ条件で比べることが前提です。テストや保守、障害対応、除外項目も含めて見ます。

初期費用、月額、追加費用、保守費用を含めた3〜5年のTCOと、障害時に現場が止まるリスクを合わせて判断します。

まとめ

施設規模と業務の独自性を見て、SaaS、追加開発、スクラッチのどこまで必要かを判断します。

RFPには、接続条件や在庫・料金の正に加えて、移行、障害復旧、権限、検収、保守、データ返却も記載します。

TCOと復旧力で見る委託先の選び方

標準SaaSは、公開料金の例で初期0〜55,000円、月額6,600〜18,000円程度からです。PMSや自社予約まで含めると、費用は変わります。

追加連携は100万〜500万円、複数システム基盤は500万〜1,500万円程度が推定の範囲です。

金額は、対象範囲や工数、接続仕様、移行、保守を含む個別見積で確定します。

最初に行う現行業務と予約データの整理

直近の予約・変更・キャンセルを確認し、手入力、在庫差異、料金更新、PMS連携、障害対応の状況を書き出します。

デモとPoCでは、使いやすさに加えて、同期遅延、API障害、移行、権限変更も試します。現場で続けて使える仕組みかを確かめておくと、発注後の失敗を減らせます。

▼全体ガイドの記事
・サイトコントローラー開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。