--- title: "予約管理システムのカスタマイズ｜直せる範囲を4段階に分けて改修と開発を決める" url: "https://www.issoh.co.jp/column/details/16985/" published: 2026-08-26 updated: 2026-08-26 categories: ["Webシステム"] publisher: "株式会社一創" --- # 予約管理システムのカスタマイズ｜直せる範囲を4段階に分けて改修と開発を決める 予約管理システムを使い始めて半年ほど経つと、たいてい同じ壁に当たります。運用は回っているのに、あと一歩だけ製品の想定と自社のやり方がずれている。そこで「カスタマイズできますか」と聞くと、返ってくる答えは製品によってまるで違います。この記事では既製の予約管理システムを直す手段を4段階に分け、何が直せて何が直せないか、費用の桁がどこで変わるかを整理しました。製品の種類と全体像そのものは[予約システムの機能・種類と開発判断を整理した記事](https://www.issoh.co.jp/column/details/12829/)で扱っています。 ## まとめ｜カスタマイズは4段階に分かれ、段階が上がるほど費用の桁が変わる 結論を先に書きます。既製の予約管理システムを直す手段は、管理画面の設定、予約画面の埋め込みと文面、APIとWebhookによる外側からの拡張、そしてコードを足す追加開発の4段階に分かれます。この4つは連続した坂道ではなく、段差のある階段です。段階が1つ上がるたびに費用の桁がひとつ増え、製品側の更新に対する強さが落ちていきます。 段階1と段階2は製品が用意した範囲を使うだけなので、提供元のアップデートで壊れる心配がほとんどありません。段差が大きいのは段階3で、APIの利用そのものが有償オプションとして課金される製品があり、実測した公開料金では参照系のAPI1本が初期110,000円と月額55,000円でした。拡張の開発費とは別に、接続口を開けておくためだけの固定費が毎月乗り続けます。 判断の順番はひとつだけ決めておけば迷いません。まず「変えたいのは値なのか、業務ルールなのか、データの行き先なのか」を切り分ける。値なら段階1で終わり、データの行き先なら段階3、業務ルールそのものなら段階4を疑う。この3分類を先に済ませてから見積を取れば、話が噛み合わないまま数か月を溶かす事態は避けられます。 ## 予約管理システムのカスタマイズという言葉が指す4つの段階と切り分け 最初に言葉を揃えます。「カスタマイズ対応」と書かれていても、指しているものが製品ごとに違うため、同じ言葉のまま話を進めると見積の桁がずれます。 ### 設定変更と受託改修が同じ「カスタマイズ」という言葉で語られている 製品サイトにある「柔軟にカスタマイズできます」は、多くの場合、管理画面でメニューや料金や表示項目を自由に設定できるという意味です。一方、開発会社が言う「カスタマイズ」は、パッケージのソースコードに手を入れて機能を足す作業を指します。前者は契約すればその日から触れて追加費用もかかりません。後者は要件定義から始まり、数十万円から数百万円の見積になります。 この2つが同じ単語で語られているせいで、問い合わせの入口で認識がずれます。販売元に「カスタマイズしたい」とだけ伝えると設定方法の案内が返り、開発会社に同じ言葉を伝えると要件ヒアリングの日程調整が返ってくる。どちらも間違っていません。 ### 直したいものを値・業務ルール・データの行き先の3つに分けて考える 段階を判定する物差しは、直したい対象そのものです。1つ目は「値」で、メニュー名、料金、受付時間、通知メールの文面、フォームの入力項目といった、用意された枠に入れる中身のこと。2つ目は「業務ルール」で、予約が成立する条件、キャンセル料の計算式、複数の資源を同時に押さえる判定など、製品の内部ロジックが決めている部分です。3つ目が「データの行き先」で、予約情報を基幹システムや顧客管理ツールへ渡す、外から在庫を取り込むといった流れを指します。 値なら段階1で終わります。データの行き先なら段階3が主戦場になり、業務ルールを変えたい場合だけが段階4の候補です。ここを混ぜたまま「うちの運用に合わせたい」と伝えると、販売元は値の話だと受け取り、こちらは業務ルールの話をしているつもりで、見積が出てから食い違いに気づきます。 ## 段階1｜管理画面の設定と有償オプションで届く範囲と、その天井 最初の段階は、契約したプランの中で設定を変えるだけの層です。費用は追加でかからず、提供元のアップデートでも壊れません。ここで足りるなら、それ以上の議論はしなくて構いません。 ### 設定で吸収できるのは値の変更で、成立条件そのものには届かない 管理画面の設定で変えられるのは、原則として製品が「変数」として用意した箇所に限られます。予約の受付単位、所要時間、営業日、通知の宛先と文面、予約フォームの追加項目あたりが典型で、この範囲は各社ともかなり広く作られています。設定項目の中身と、管理者側でどこまで決められるかは[予約システムの管理者機能を5領域に分けて整理した記事](https://www.issoh.co.jp/column/details/16977/)にまとめました。 止まるのは、判定そのものを変えたいときです。「同じ顧客が同一週に2回目を予約するときだけ指名料を無料にする」という運用は、料金という値ではなく成立条件の話なので設定欄がありません。キャンセル料の刻みを2段階から4段階へ増やしたい、直前キャンセルだけ承認を挟みたいといった要望も同じ壁です。この壁は製品を乗り換えても同じ場所に現れ、そこが段階4の入口になりました。 ### 有償オプションという中間層があり、実測では月額3,300円から 設定と追加開発のあいだに、提供元があらかじめ用意した有償オプションという層があります。ここを見落としたまま「できないから開発だ」と結論を出す例が少なくありません。実際の価格帯を、公開されている料金表で確認しておきます。ChoiceRESERVE のオプション料金ページ（2026年8月26日実測）には、キャンセル待ちが月額3,300円、時間帯別料金テンプレートが月額3,300円、設備管理が初期55,000円と月額8,800円、予約回数制限機能が初期55,000円と月額8,800円、SSO連携（SAML認証）が初期55,000円と月額33,000円という形で並んでいました。 並べてみると構造が見えます。通知や表示に関する軽いものは月額3,300円の帯、予約の受け入れ制御に関わるものは初期55,000円を伴う8,800円前後の帯、認証基盤との接続は33,000円の帯と、機能の重さに価格帯が対応していました。自社の要望がこの表のどれかに当たるなら、開発の検討前にオプションで済みます。近いものが1つも無い要望は、製品の想定から外れている信号でしょう。製品タイプごとのオプションの傾向は[予約管理システムを3タイプ別に比較した記事](https://www.issoh.co.jp/column/details/16964/)で扱いました。 ## 段階2｜予約画面の埋め込みと文面の改変で残る、更新に弱い部分 2段階目は見た目と文面の層です。自社サイトに予約導線を置くとき、多くの製品は埋め込み用のコードかリンクを配ります。ここで手を入れられる範囲と、入れてはいけない範囲があります。 ### 埋め込みの見た目を外側から上書きすると、提供元の更新で外れる仕組み 埋め込みウィジェットの体裁は、自社サイト側のスタイル指定である程度まで寄せられます。ただしこの手法は、提供元が配信する画面側の構造に依存した指定になりがちです。提供元が画面を作り替えたときに指定が外れ、ある朝ふいにレイアウトが崩れる。この崩れは自社のリリースと無関係に起きるため、原因の特定に時間がかかります。 実務としての線引きははっきりしています。製品が公式に用意した設定項目、つまりテーマ色やロゴや見出し文言の変更で届く範囲なら使ってよい。画面の構造に踏み込む指定は暫定処置として期限を切って使い、恒久的な仕様には数えない。通知文面の改変も同じ層に属し、製品の設定として用意されていることが多いため更新に強い部類でした。通知経路ごとの実装差については[予約管理システムのLINE連携を4方式で比較した記事](https://www.issoh.co.jp/column/details/16971/)を参照してください。 ### 見た目への不満だけが理由なら、改修より先に乗り換えを検討する 段階2の話をしていて、実は要望の中身が「デザインが自社ブランドに合わない」だけということがあります。この場合、改修に費用を投じても投資対効果はほとんど出ません。予約導線の見た目は製品ごとの差が大きく、同じ価格帯でも自社の雰囲気に近いものが見つかるからです。 判断の目安を置きます。直したい箇所が見た目と文面だけで、業務の手順もデータの流れも変わらないなら、まず他製品のデモ画面を3つ触ってください。それで解決するなら乗り換えのほうが安く、速い。見た目の不満と同時に「入力してもらえない項目がある」という機能の話が混ざっているなら、段階1か段階3の課題として切り出します。 ## 段階3｜APIとWebhookで本体の外側に機能を足すときの条件 3段階目が実務上の主戦場です。製品本体には触れず、公開された接続口を通じてデータを出し入れし、足りない処理を自社側で書きます。予約の受付は製品に任せたまま、その前後だけ業務に合わせられるのが利点です。 ### 接続口を開けること自体が有償で、参照系と登録系は別課金になる ここで見落とされやすいのが、APIを使える状態にするまでの費用です。開発費の話が先行しますが、その手前に接続口の利用料があります。同じ ChoiceRESERVE のオプション料金ページ（2026年8月26日実測）では、参照系API（予約データ）が初期110,000円と月額55,000円、参照系API（予約メニュー）も初期110,000円と月額55,000円、登録系API（予約データ）が初期110,000円と月額55,000円という掲載でした。登録系は、外部システムから予約情報を登録・更新・キャンセルできるAPIと説明されています。 注目したいのは、読み取りと書き込みが別のオプションとして値付けされている点です。「予約データを会計へ流すだけ」なら参照系1本で済み、「基幹側で受けた予約を予約システムへ書き戻す」なら登録系が要る。必要な向きを取り違えると、月額が倍になります。設計前にデータが流れる向きと本数を数えてください。この数え方は[予約管理システムのカレンダー連携で同期方式を選び分けた記事](https://www.issoh.co.jp/column/details/16973/)の考え方がそのまま使えます。 ### プラン契約が前提になる製品があり、権限の粒度も2つに分かれている 接続口の開放条件は、有償オプション方式だけではありません。上位プランの契約を前提にする製品もあります。Square の Bookings API のドキュメント（2026年8月26日実測）には、seller-level の予約を作成・更新・キャンセルする前に、対象の事業者が有料の Appointments プランを契約しているか確認する必要があると書かれていました。同じ資料では buyer-level と seller-level で必要な権限スコープが分かれ、seller-level 側にはより広い読み取り権限が要る旨も示されています。 つまり、APIが公開されているという事実と、自社の契約でそれが使えるという事実は別ものです。技術検証を始める前に、いま契約しているプランで対象の操作が通るかを確かめる。ここを飛ばすと、動くコードを書き上げてから契約変更の稟議を出し直すことになります。プランの階層と機能の対応は[予約管理システムの比較記事](https://www.issoh.co.jp/column/details/16964/)で扱いました。 ### 外側に作った拡張も、提供元のAPIバージョン方針に縛られ続ける 段階3には、費用の他にもうひとつ見落とされる負債があります。接続先の仕様が変わることです。Square の場合、APIのバージョンは日付形式で管理され、リクエストのヘッダーで明示指定できる設計になっています。破壊的な変更はバージョンを分けたリリースとして導入されると説明されており、この作りは利用側にとって親切な部類でしょう。 それでも期限からは逃げられません。同社のライフサイクル説明（2026年8月26日実測）では、非推奨はバグ修正が限られて新機能が追加されない段階、廃止はサポート対象外で全てのリクエストに 410 GONE が返る段階と定義され、恒久的な廃止の少なくとも12か月前に非推奨化されるのが通例と記されています。裏を返せば、外側の拡張にはおおむね12か月周期で仕様追従の作業が発生し得るということ。保守要員を決めないまま段階3へ進むと、作った翌年に止まります。実装側の設計と技術選定の勘所は[予約システム開発の進め方を解説した記事](https://www.issoh.co.jp/tech/details/7369/)にまとめています。 ## 段階4｜追加開発とフルスクラッチへ移らざるを得なくなる2つの型 最後の段階は、コードを足す層です。パッケージへの追加開発と、フルスクラッチでの新規構築が含まれます。前の3段階で届かなかったものだけがここへ来ます。 ### 製品のデータモデルに載らない要件は、外側からでは埋められない 段階3で届かないものの正体は、たいてい製品が持つデータの形そのものです。予約が「日時×担当者」で1件と数えられている製品に対して、「担当者と個室と機材の3つが同時に空いているときだけ成立する」という要件を持ち込むと、外側のAPIをいくら叩いても表現できません。空き状況を返す仕組みが1資源しか見ていないからです。 もうひとつの型が、予約と会計の粒度がずれている場合です。1回の来店で複数のメニューを別担当が提供し、支払いは1本にまとめる。こうした構造は製品側が「1予約1明細」で持っていると成立せず、外側で辻褄を合わせようとすると、キャンセルや変更のたびに整合が崩れました。この2つの型に当たったら、作り替えの検討へ移ったほうが結果的に安く済みます。 ### 追加開発は、保守の責任範囲を契約書の4項目で分けてから発注する パッケージへの追加開発を選ぶときに、費用より先に決めておくべきことがあります。作った部分の保守を誰が持つかです。本体は提供元、追加部分は開発会社と分かれるのが一般的ですが、本体のアップデートで追加部分が動かなくなったときの切り分けと費用負担が曖昧なまま契約すると、障害のたびに押し付け合いが起きます。 契約書に入れておく項目は4つです。本体のアップデート時に追加部分の動作確認を誰がやるか、その工数は保守費に含まれるか別途か、本体側の仕様変更で作り直しが要る場合の負担割合、そして追加部分のソースコードの権利と引き渡しの有無。この4つを最初に詰めておけば、数年後の乗り換えのときに身動きが取れます。既製品から作り替えへ移る場合の進め方は[予約管理システム開発](https://www.issoh.co.jp/service/system/reservation/)で相談を受け付けています。 ## カスタマイズ費用が内製化コストを超える分岐点と、見送るべき場面 ここまでの4段階を費用と更新耐性の観点で並べ直し、どこまでなら既製品を直し続けてよいか、どこから作り替えるべきかを条件付きで言い切ります。 ### 段階ごとの費用の桁と、提供元の更新に対する強さを一覧で並べる 下の表は、これまでに挙げた実測値と一般的な相場感を段階ごとに整理したものです。金額はいずれも2026年8月時点の公開情報にもとづく目安で、製品と規模によって上下します。 | 段階 | 直し方 | 費用の目安 | 更新への強さ | | --------- | ----------- | ---------------- | ------ | | 段階1 設定 | 管理画面で値を変える | 追加費用なし | 強い | | 段階1 オプション | 提供元の有償機能を足す | 月3,300円から33,000円 | 強い | | 段階2 見た目 | 埋め込みと文面を寄せる | 数万円から数十万円 | やや弱い | | 段階3 API | 外側から読み書きする | 初期11万円と月5.5万円 | 中くらい | | 段階4 追加開発 | コードを足して直す | 数十万円から数百万円 | 弱い | この表で見てほしいのは金額の絶対値ではなく、段差の位置です。段階1から段階2までは経費の範囲で収まり、段階3で月額の固定費が発生し、段階4で投資判断の対象になります。段差を越えるたびに決裁者が変わるという意味でもありました。 ### 段階3までで既製品を直し続けてよい4条件と、越えたときの計算 既製品を直し続ける判断が成り立つのは、次の4条件を全て満たすときです。第1に、変えたいものが値と文面とデータの行き先に限られ、予約の成立条件そのものは製品の考え方に載っていること。第2に、外部とやり取りするデータの向きが片方向で、接続口が2本以内に収まること。第3に、同時に押さえる資源が1種類であること。第4に、外側の拡張が止まっても予約の受付は製品側で継続できること。この4つが揃うなら段階3までの投資は回収できます。 越えたかどうかは計算で出ます。先ほどの実測値で参照系2本と登録系1本を開けた場合、初期が330,000円、月額が165,000円で年額はおよそ1,980,000円。3年では初期を含めておよそ6,270,000円になりました。これは接続口を開けておくだけの金額で、拡張の開発費と保守費は別勘定です。同等の予約システムを受託開発した場合の初期費用帯と、この3年分は正面からぶつかります。既製品と受託開発を総額で比べる方法は[予約管理システムの費用を3年総額で比較した記事](https://www.issoh.co.jp/column/details/16967/)に譲ります。 ### 作り替えへ移すべき3つの兆候と、そのときに捨てることになるもの 逆に、カスタマイズを見送って作り替えへ移すべき兆候を3つ挙げます。1つ目は、予約の成立条件が複数の資源の組み合わせで決まっており、製品の空き状況の返し方では表現できないとき。2つ目は、接続口の固定費と外側の保守費の合計が3年で受託開発の初期費用帯に並んだとき。3つ目は、外側に作った拡張が業務の中核に入り込み、提供元のバージョン方針に自社の事業計画が縛られる状態になったときです。 3つのうち1つでも当たっていれば、その時点で作り替えの見積を取る価値があります。ただし移行で捨てるものも正直に見ておくべきで、既存データの移行、顧客への告知と再登録の依頼、スタッフの再教育、そして稼働までの数か月は必ず発生しました。だからこそ、兆候が1つ出た段階では比較検討にとどめ、2つ揃った時点で実行に移す。この二段構えが判断を現実的に保ちます。 ## 見積を依頼する前に発注側で固めておく5つの項目と渡し方の順番 最後に実務です。段階3か段階4に進むと決めたあと、見積の精度は発注側が渡す情報の粒度で決まります。上から順に用意すれば、初回の打ち合わせでおおよその方式まで決まります。 - 現在の製品名・プラン・有効中のオプション一覧。契約書と直近の請求書で足ります - 直したい業務を「誰が・どの画面で・何をして・うまくいかない場合どうなるか」の4点で1行にした表を10行ほど。機能名ではなく操作で書きます - 外部システムとの接続で、データが流れる向きと本数、1日あたりの件数、遅れが許される時間。即時反映か一括かで方式も費用も変わります - 移行が必須のデータと、書き出したファイルでの保管に切り替えてよいデータの区別。全件移行の前提は費用が跳ね上がります - 稼働希望日ではなく「この期間だけは切り替えない」という禁止期間。繁忙期に当てると現場の負荷が二重になって失敗しやすくなりました この5点のうち、開発会社が代わりに決められるものはひとつもありません。逆に言えば、ここさえ揃えば方式の提案と概算は数日で返ってきます。接続の実装方式そのものについては[API開発・システム連携](https://www.issoh.co.jp/service/system/api/)の観点から整理できます。 ## よくある質問 ### カスタマイズできる予約管理システムを選べば後で困りませんか？ 「カスタマイズ可能」という表記だけでは判断できません。確認すべきは3点で、設定で変えられる項目の一覧、有償オプションの一覧と価格、そしてAPIの提供条件と料金です。この3つが公開されている製品は、どこまで直せるかを契約前に見積もれます。いずれも問い合わせ扱いの製品は、必要になった時点で価格交渉から始まります。 ### SaaSのAPIを使った拡張は、自社のエンジニアでも作れますか？ 読み取りだけの用途なら、社内で作れる範囲に入ることが多いです。予約データを取得して集計する、社内チャットへ通知するといった処理は外部への影響が限られます。慎重になるべきなのは書き込み側で、外部から予約を登録・変更する処理には失敗時の再実行や重複登録の防止といった設計が要りました。書き込みを含む拡張は、設計だけでも外部の目を入れることをおすすめします。 ### パッケージの追加開発と、フルスクラッチはどちらが安いですか？ 初期費用だけを見れば追加開発が安く済みます。ただし、追加が5件、10件と積み上がった時点で逆転することがあります。追加が増えるほど本体のアップデートのたびに確認する範囲が広がり、保守費が膨らむためです。目安として、追加開発の項目が本体機能の3割を超えたあたりからフルスクラッチとの総額差は縮みました。迷うなら両方の見積を並べて3年の総額で比べてください。 ### カスタマイズした予約システムから、別の製品へ乗り換えられますか？ 乗り換えの難易度は、段階によって大きく違います。段階1と段階2までなら、データを書き出して移すだけなので比較的容易です。段階3まで進んでいる場合、外側の拡張は接続先ごと作り直しになります。段階4まで行っていると、その機能を新しい製品でどう再現するかから検討が要るでしょう。将来の乗り換えを残したいなら、データの受け渡し部分だけを差し替えられる構造にしておくと軽くなります。 ### まず何から手をつければ、無駄な出費を避けられますか？ いま契約している製品のオプション一覧を、上から下まで一度読んでみてください。欲しかった機能が既にオプションとして用意されていた、という結末が実務ではよくあります。見つからなければ、販売元へ「この操作は設定で可能か、オプションで可能か、いずれでもないか」の3択で問い合わせます。この2手順は費用がかからず、開発の検討に入るかを最短で切り分けられました。 ## 関連記事 - [予約システムとは？主な機能・種類と、既製サービスで足りない場合の開発判断を解説](https://www.issoh.co.jp/column/details/12829/)：製品の種類と全体像から確認する場合 - [予約管理システムの比較｜3タイプ別の選び方と既製品で足りなくなる境界線](https://www.issoh.co.jp/column/details/16964/)：製品タイプ別の比較と選定の順番 - [予約管理システムの費用｜料金体系3タイプの内訳と3年総額で見る開発への分岐](https://www.issoh.co.jp/column/details/16967/)：既製と開発の総額を規模別に比べる場合 - [予約システムの管理者機能｜管理画面の要件を5領域に分けて要件書に落とす](https://www.issoh.co.jp/column/details/16977/)：管理画面の要件を書き出す場合 - [予約システム開発の進め方｜自作の設計・技術選定・必須機能と費用を解説](https://www.issoh.co.jp/tech/details/7369/)：実装側の設計と技術選定を見る場合 --- 出典: [予約管理システムのカスタマイズ｜直せる範囲を4段階に分けて改修と開発を決める]()（株式会社一創）