IVR開発のフルスクラッチ・オーダーメイド開発について

IVRのフルスクラッチ開発は、要件への適合性、費用、期間を比べたうえで、クラウド型では満たせない要件がある場合に選びます。

方式や費用、リスク、発注・契約・移行まで扱います。刷新や新規開発、パッケージ比較、老朽設備更新の判断に役立つ内容です。全体像はIVR開発の完全ガイドもご覧ください。

▼全体ガイドの記事
・IVR開発の完全ガイド

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

クラウド型SaaS・パッケージ導入との比較

フルスクラッチ（オンプレミス）と、現在主流のクラウド型IVRパッケージでは、特性も投資規模も異なります。クラウド型は、サービス仕様の範囲内で設定を組む形になります。

• カスタマイズ性：フルスクラッチは、自社の要件に合わせて自由に変更できます。
• 導入期間：クラウド型は最短で即日〜数週間で稼働し、フルスクラッチは要件定義から導入まで数ヶ月〜1年以上かかります。
• 費用：クラウド型は初期0円（0万円）〜30万円程度で、月額は数千円〜数万円です。
• フルスクラッチ費用：初期は50万円〜数千万円規模、月額保守は数万円〜数十万円です。

フルスクラッチは、投資に見合う明確な理由がある場合に限って選ぶものです。そのため、自由度の高さだけを理由に選ぶことは避けたいところです。

フルスクラッチ開発が向いているケース

莫大な費用と時間をかけることになっても、クラウド型では満たせない要件があるときに、フルスクラッチが選択肢になります。

• 厳格なセキュリティ：金融機関や官公庁などで個人情報・機密データを扱い、閉域網と厳格な方針が求められます。
• 複雑なデータ連携：独自CRMや販売管理DBとリアルタイムに連携し、個別の案内を返す処理が必要です。
• 特殊なシナリオや規模：専門的で多岐にわたる業界特有の分岐や、数百チャネル（回線）規模の専用処理が必要です。

たとえば、プッシュ入力をもとに外部DBを即時に参照する処理は、既製のクラウド型では対応できないことがあります。

この条件に当てはまらなければ、クラウド型パッケージを先に検討します。

特に、理由が曖昧なままフルスクラッチを選ぶと、クラウドなら数週間で得られる効果のために、数百万円と数ヶ月〜1年を費やしかねません。

発注前に、情報システム部門と電話対応の現場責任者で、クラウド型では実現できない要件を洗い出しておきます。そうしないと、条件に当てはまるかどうかの判断材料がそろいません。

フルスクラッチ開発の費用相場

初期費用は、プロジェクトの規模により数百万円から数千万円規模になることがあります。電話網とWeb開発の両方に詳しいエンジニアの人件費に加え、サーバーやネットワーク機器の購入費がかかるためです。

運用後は、月額数万円〜数十万円の保守費用が発生します。さらに、電気代、定期メンテナンス、障害対応の社内工数も必要です。

予算は初期費用だけでなく、少なくとも5年程度の運用を想定したTCO（総所有コスト、Total Cost of Ownership）で比較します。

モデルケースでは、初期費用が1,500万円、年間保守費用は初期費用の15%にあたる225万円です。この場合、5年間の総コストは約2,625万円になります。

一方、クラウド型は月額数万円でも、同じ期間で数百万円程度です。両者には数倍から十数倍の差が出るため、差額に見合う独自性やセキュリティ、連携要件があるかを見極める必要があります。

費用の内訳と人件費の考え方

IVRの見積もりは、工程ごとの作業費と、サーバーなどの設備費を足し合わせて組み立てられます。

• 要件定義・設計費：必要な機能と全体構成を定めるための費用。
• 開発・実装費：IVRシステムの開発にかかる費用。
• テスト・導入費：動作確認と稼働開始までにかかる費用。
• 機器・インフラ費：サーバーやネットワーク機器などの費用。

IVRでは、PBX・SIP・電話交換とアプリ開発の両方に通じた技術者が必要になります。そのため、一般的なWeb開発と比べて人件費が高くなりやすい傾向があります。

見積もりには、音声ガイダンスの収録や制作会社への依頼費、既存PBX・回線との接続テストの工数も含めます。

人月単価の目安は、プログラマーが月60万〜100万円程度、電話網・PBX連携の経験があるSEが月80万〜120万円程度です。要件定義や全体設計を担う上級エンジニア・アーキテクトは、月120万〜250万円程度が参考値です。

たとえば、半年程度の案件で上級エンジニア1名、SE2名、PG2名を組むと、人件費だけで数千万円規模になることもあります。

見積もりでは、複数社に内訳の明示を求め、自社の要件がどこまで金額に反映されたかを確かめます。

開発時・運用時のリスク

フルスクラッチ特有のリスクには、属人化とブラックボックス化、セキュリティ対応の自社負担、開発長期化があります。

• 属人化：社内担当者や特定ベンダーに知識が集中し、異動や退職の後は仕様把握や音声変更が難しくなる場合があります。
• セキュリティ対応：クラウド型はベンダーがOS等を更新しますが、フルスクラッチでは自社で脆弱性対策やパッチ適用を続ける必要があります。
• 開発の長期化：要件が追加されて範囲が膨らむと導入が遅れ、変化の速い環境で機会を失う恐れがあります。

要件を自由に追加できるため、範囲が膨らむスコープクリープに注意が必要です。そのため、追加の扱いは事前に取り決めておきます。

属人化を防ぐには、契約時に仕様書やソースコードの文書を整え、複数名で知識を共有する体制も組み込みます。

保守を委託先1社だけに頼ると、その会社の撤退や買収、担当者の大量離脱によって、コールセンター機能が止まる恐れがあります。そのため、設計書、ソースコード、運用マニュアルは自社でも保管し、有事に別のベンダーへ引き継げる状態を保ちます。

発注時の確認ポイント・チェックリスト

ベンダーに発注する場合も、自社で設計する場合も、要件を明確に定め、連携・安全性・運用の面から確かめます。

システム連携と業務要件の確認

電話受付で利用者が行き詰まらないよう、システム連携と有人対応は、設計段階で整理しておきます。

• 連携方法：既存PBX・CRMとの範囲と、API連携かゲートウェイ経由かといった方式を明記します。
• 有人対応：IVRで自動化する業務の範囲と、オペレーターへ転送する逃げ道を設計します。
• 負荷設計：同時着信のピーク値と、その1.5倍程度の余裕を、要件定義書に記載します。

IVRだけで完結させる設計は、顧客満足度を下げる恐れがあります。また、繁忙期やキャンペーン時の通話品質も確かめます。

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

扱う情報によって、準拠すべき範囲とデータの管理方法が変わります。カード決済を扱う場合は、特に次の点を確かめます。

• PCI DSS：カード決済では、クレジットカード業界のセキュリティ基準が、IVR基盤・管理画面・API・運用のどこまで対象かを確かめます。
• 非保持化：決済業務では、録音・ログ・管理画面にカード番号などを残さず通過させる設計かを厳密に確認します。
• 個人情報：保管期間、アクセス権限、廃棄手順を仕様書に記載する。

カード決済を扱わない場合でも、氏名・住所・契約内容がプッシュ操作や録音を通じて蓄積されます。

例外処理とサポート・運用保守体制の確認

例外時の顧客対応と障害復旧の条件は、仕様と契約に落とし込んでおくことで、稼働後の混乱を防げます。

• 例外処理：入力エラーやタイムアウト時の再案内と再入力を決めておく。
• 転送・予約：誤操作が一定回数続いたらオペレーターにつなぎ、営業時間外は案内のうえで折り返しの予約を受け付けます。
• 障害対応：対応時間（24時間365日の可否）、緊急連絡ルート、復旧目標時間（SLA）を確かめます。
• 拡張性と実績：拠点や回線が増えても対応できる設計か、電話網・PBX連携を含むIVRの類似案件の経験があるかを確認します。

一般的なWeb開発の実績が豊富でも、電話交換やSIPの知見が乏しいと、要件定義の段階から手戻りが起こりやすくなります。

複数社から相見積もりを取り、体制や実績、保守支援の手厚さも含めて総合的に判断します。

契約形態の選び方とレガシー環境からの移行アプローチ

契約形態は、費用や技術要件と同じく成否を左右します。また、古い設備を刷新する場合は、業務を止めない段階移行も計画に入れます。

請負契約と準委任契約の使い分け

契約は、大きく請負と準委任に分かれます。仕様がどこまで確定しているか、変更の可能性がどの程度あるかによって選びます。

• 請負契約：定めた仕様と成果物の完成を約束し、予算と納期を見通しやすい形です。
• 準委任契約：実際にかかった工数（時間・人月）に応じて費用が発生します。

PBXや回線の連携要件と必要機能が固まっている場合は、成果物を定めた請負契約が適しています。

請負では、要件定義後の仕様変更に追加費用や納期の見直しが生じやすいため、変更時の影響確認が必要です。

ただし、音声の聞き取りやすさやメニューの使い勝手など、稼働前には分からない点が残る場合があります。

要件が固まらず、パイロット運用を見ながら柔軟に調整する場合は、準委任契約でアジャイル的に進める方法もあります。

どちらの契約でも、変更の手順を契約時に明文化しておきます。その手順には、影響調査、工数見積もり、承認、実施を含めます。

レガシー環境からの段階的な移行アプローチ

長年稼働した古いオンプレミスPBXやIVR一体型設備は、一斉切り替えを避け、段階移行でリスクを抑えます。

業務を止めずに移すには、検証、設定の洗い出し、運用知識の引き継ぎを順に進めます。

1. 一部の回線や特定の時間帯だけ新システムにつなぎ、既存環境と並行して動かして、動作を確かめます。
2. 検証で問題がないことを確かめてから、新システムへ全面的に切り替えます。
3. 切り替え当日に備えて、旧システムへすぐ戻せる体制を用意しておきます。
4. 音声ガイダンス、コールフローの分岐、転送先番号を洗い出し、新しい環境への設定漏れがないかを調べます。
5. 異動や退職で理由が分からなくなった分岐も見直し、不要な選択肢を整理すれば、構成を簡素化できる場合があります。
6. 旧ベンダーや社内担当者に話を聞き、問い合わせの傾向、繁忙期の着信、過去の障害と対処法を新しい会社へ引き継ぎます。

運用上の暗黙知が新しい会社に伝わらないと、旧環境では起きなかった初歩的なトラブルが再び起こり、投資価値を損なう恐れがあります。

まとめ

ここまで、クラウド型との比較、適する条件、費用、リスク、発注時の確認点を見てきました。

クラウド型は、初期0〜30万円、月額数千〜数万円で、最短即日〜数週間で導入できます。

フルスクラッチは、初期50万円〜数千万円規模、月額保守数万円〜数十万円で、開発に数ヶ月〜1年以上かかります。

高い安全要件、独自基幹との深い連携、大規模で特殊なコールフローがある場合に、フルスクラッチが検討の対象になります。

属人化、自社での脆弱性対応、要件の肥大化に備えるには、連携範囲と有人転送を確認し、PCI DSSの準拠範囲と障害対応SLAも見ておく必要があります。

要件が明確なら請負、試験運用で仕様を調整するなら準委任を選びます。また、老朽環境では、並行稼働と知識移管を行いながら、段階的に切り替えます。

自社にとって選ぶ理由があるかを見極めたうえで、複数社に要件を示して見積もりを依頼します。

▼全体ガイドの記事
・IVR開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【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を創業。