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

IVR（自動音声応答システム）を導入する際、多くの企業はクラウド型のSaaSサービスを選択し、Web上の管理画面から自社で音声ガイダンスやコールフローを設定して運用しています。しかし、金融機関や官公庁のように厳格なセキュリティ要件が課される業種や、独自の基幹システムと複雑に連携させたい企業、あるいは業界特有の多岐にわたる分岐シナリオを必要とする現場では、既製のクラウド型サービスでは対応しきれず、自社要件に完全に合わせてゼロから構築するフルスクラッチ・オーダーメイド開発を選択するケースがあります。とはいえ、フルスクラッチ開発はクラウド型に比べて費用・期間ともに大きく膨らむため、「どのようなケースであればフルスクラッチを選ぶべきなのか」「費用相場はどれくらいか」「開発を発注する際にどのような点を確認すべきか」を正しく理解しておくことが、投資判断を誤らないために欠かせません。

本記事では、IVR開発のフルスクラッチ・オーダーメイド開発に焦点を当て、クラウド型SaaSとの比較、フルスクラッチが向いているケース、費用相場、開発・運用時のリスク、契約形態の選び方、レガシー環境からの移行アプローチ、そして発注時に確認すべきチェックリストまでを、具体的な数値とともに体系的に解説します。これからIVRの本格的な刷新・新規開発を検討している方はもちろん、パッケージ導入との判断に迷っている担当者、あるいは老朽化した既存設備の入れ替えを検討している担当者にとっても、実務に役立つ判断軸が身に付く内容です。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

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

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

フルスクラッチ（オンプレミス）開発と、現在主流のクラウド型IVRパッケージでは、カスタマイズ性・開発期間・費用感において大きな違いがあります。カスタマイズ性については、クラウド型が「サービス仕様の範囲内」での設定にとどまるのに対し、フルスクラッチ開発は理論上、自社要件に合わせて無制限かつ自由なカスタマイズが可能です。開発・導入期間については、クラウド型が最短即日〜数週間で稼働できるのに対し、フルスクラッチ開発は要件定義から設計・開発・テスト・導入までに数ヶ月〜1年以上の長期間を要します。費用感については、クラウド型が初期費用0円〜30万円程度、月額数千円〜数万円で運用できるのに対し、フルスクラッチ開発は初期費用が50万円〜数千万円規模となり、月額の維持・保守費用も数万円〜数十万円に上ります。この比較からもわかる通り、フルスクラッチ開発は「投資に見合うだけの明確な理由」がある場合にのみ選択すべき手法であり、安易に「自由度が高いから」という理由だけで選ぶべきではありません。

莫大なコストと時間をかけてでもフルスクラッチ開発を選択すべきケースには、いくつかの明確な条件があります。第一に、金融機関や官公庁など、個人情報や機密データを扱う組織で、社内の閉域網（独自のネットワーク環境）にシステムを構築し、厳格なセキュリティポリシーを適用しなければならない場合です。第二に、自社独自の顧客管理システム（CRM）や販売管理データベースなどと、リアルタイムかつ複雑なデータ連携を行いたい場合です。プッシュ操作で入力された情報をもとに、外部のデータベースを即座に参照して個別の案内を返すような高度な処理を実現したい場合、既製のクラウド型パッケージでは対応できないことがあります。第三に、業界特有の専門的で多岐にわたる分岐シナリオが必要な場合や、数百チャネル（回線）規模の同時着信を処理する専用システムを構築したい大規模なケースです。これらの条件に当てはまらない場合は、クラウド型パッケージの活用を優先的に検討することをお勧めします。逆に言えば、「なんとなく自由度が高そうだから」「他社もオリジナルのシステムを持っているから」といった曖昧な理由でフルスクラッチを選んでしまうと、クラウド型であれば数週間で得られたはずの効果を、数百万円のコストと数ヶ月〜1年の期間をかけて追いかける結果になりかねません。発注前には、自社が本当にクラウド型パッケージでは実現できない要件を抱えているのかを、情報システム部門だけでなく、実際に電話対応を行う現場責任者も交えて厳密に洗い出すプロセスを設けることが重要です。

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

フルスクラッチ開発の初期費用は、プロジェクトの規模によって数百万円から数千万円規模になることが珍しくありません。この初期費用には、サーバーやネットワーク機器の購入費に加え、電話網（PBXやSIPプロトコルなど）に関する専門知識とWebアプリケーション開発の両方のスキルを持つエンジニアの人件費（開発費）が重くのしかかります。運用開始後も、月額数万円〜数十万円の保守費用に加え、サーバーの電気代、システムの定期メンテナンス、障害発生時の対応にかかる社内エンジニアの「見えにくい運用コスト」が継続的に発生する点も、投資判断の際に見落とされがちなポイントです。予算計画を立てる際には、初期の開発費用だけでなく、少なくとも5年程度の運用期間を見据えたトータルコスト（TCO：Total Cost of Ownership）で比較検討することが重要です。仮に初期費用1,500万円・年間保守費用が初期費用の15%（225万円）というモデルケースで試算すると、5年間の総コストは初期費用と合わせて約2,625万円となり、同期間クラウド型を利用した場合の総コスト（月額数万円としても5年間で数百万円程度）と比較して、数倍から十数倍の開きが生じることになります。この差額に見合うだけの独自性・セキュリティ要件・連携要件が本当に自社にあるのかを、投資対効果の観点から冷静に見極めることが求められます。

フルスクラッチ開発の費用は、大きく「要件定義・設計費」「開発・実装費」「テスト・導入費」「機器・インフラ費」に分解できます。特にIVR開発では、電話網に関する専門知識（PBX・SIP・電話交換の仕組み）とアプリケーション開発スキルの両方を持つエンジニアが必要となるため、一般的なWebシステム開発と比較して、対応可能な技術者の絶対数が少なく、人件費の単価が高くなりやすい傾向があります。また、音声ガイダンスの制作費（プロナレーターによる収録や、専門の制作会社への依頼費用）や、既存のPBX・回線設備との接続テストにかかる工数も、フルスクラッチ開発ならではの費用項目として見積もりに含めておく必要があります。見積もりを取る際には、これらの内訳が明確に提示されているか、そして自社の要件がどこまで反映された金額なのかを、複数の開発会社に確認することが重要です。一般的な受託開発における人月単価の目安として、プログラマークラスで月60万〜100万円程度、電話網・PBX連携の設計経験を持つシステムエンジニアで月80万〜120万円程度、要件定義から全体設計まで担う上級エンジニア・アーキテクトで月120万〜250万円程度が一つの参考値になります。たとえば、要件定義から本稼働まで半年程度のプロジェクトで、上級エンジニア1名・SE2名・PG2名という体制を組んだ場合、人件費だけで数千万円規模に達することも珍しくなく、見積書の金額の大部分が人件費であることを理解しておくと、費用の妥当性を判断しやすくなります。

開発時・運用時のリスク

フルスクラッチ開発特有の大きなリスクとして、まず挙げられるのが属人化とブラックボックス化です。開発を担当した社内エンジニアや特定のベンダーに知識とノウハウが集中してしまうため、その担当者が異動・退職すると、他の誰も仕様を把握できなくなり、ちょっとした音声シナリオの変更すら困難になるリスクがあります。第二に、セキュリティ対応の自己責任化が挙げられます。クラウド型であればベンダー側がOSやソフトウェアのアップデートを継続的に行いますが、フルスクラッチの場合は、脆弱性対策（セキュリティパッチの適用）などをすべて自社の責任で継続的に行う必要があります。第三に、開発期間の長期化による機会損失のリスクです。要件を自由に詰め込める反面、要件が肥大化しやすく（いわゆるスコープクリープ）、開発工程が当初の想定より長期化することで、変化の速いビジネス環境において導入の遅れがそのまま機会損失につながる恐れがあります。これらのリスクを踏まえ、フルスクラッチ開発を選択する場合は、仕様書やソースコードのドキュメント整備、複数名でのナレッジ共有体制の構築を、契約時にあらかじめ組み込んでおくことが重要です。特に、開発を委託した1社のみに保守も依存する体制は、そのベンダーの経営状況や体制変更（撤退・買収・担当者の大量離脱など）によって、自社のコールセンター機能そのものが立ち行かなくなるリスクをはらんでいます。可能であれば、設計書・ソースコード・運用マニュアルを自社側でも保管し、有事の際には別のベンダーに引き継げる状態を維持しておくことが、長期運用における事業継続性の観点から望ましい対応です。

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

フルスクラッチ開発をベンダーに発注、あるいは自社で設計する際には、以下の要件を明確に定義し、確認しておくことが重要です。

まず確認すべきは、既存のPBXやCRMとの連携範囲・連携方式（API連携かゲートウェイ経由か）が明確に定義されているかという点です。あわせて、IVRだけで自動化したい業務範囲と、人間（オペレーター）に転送する明確な「逃げ道」のフローが設計に組み込まれているかも重要な確認事項です。IVRですべてを完結させようとする設計は、顧客満足度の低下につながるリスクが高いため、発注段階で必ずこの点を仕様書に盛り込むよう依頼しましょう。また、想定している同時着信数のピーク値と、その1.5倍程度の余裕を見た負荷設計になっているか、繁忙期やキャンペーン時にアクセスが集中しても通話品質が劣化しないかという非機能要件も、要件定義書に数値として明記してもらうことが望ましい対応です。

クレジットカード決済など機密性の高い情報を扱う業務でIVRを利用する場合、PCI DSS（クレジットカード業界のセキュリティ基準）の準拠範囲が明確になっているかを確認する必要があります。IVR基盤のみが対象なのか、管理画面やAPI、日々の運用業務まで含むのかによって、必要な対策の範囲が大きく変わります。あわせて、通話録音データやシステムログ、管理画面などに機密情報（カード番号など）が残存しない・通過しない「非保持化」設計になっているかも、決済関連の業務でIVRを利用する場合には特に厳密に確認すべきポイントです。決済情報を扱わない業種であっても、氏名・住所・契約内容といった個人情報がプッシュ操作や通話録音を通じてシステムに蓄積されるため、個人情報保護法に沿ったデータの保管期間・アクセス権限管理・廃棄手順が仕様書に明記されているかを確認しておくことをお勧めします。

顧客の入力エラー、タイムアウト、想定外の操作が発生した際に、再案内・再入力を促すフローが定義されているかも重要な確認項目です。誤操作が一定回数続いた場合に自動的にオペレーターへ転送する、あるいは営業時間外である旨を案内した上で折り返し予約を受け付けるといった、例外パターンごとの挙動を仕様書レベルで具体的に取り決めておくことで、稼働後の想定外のクレームを未然に防げます。加えて、障害発生時の対応時間（24時間365日の対応が可能か）、緊急連絡ルート、復旧目標時間（SLA）が明示されているかを確認しましょう。将来的に他拠点への展開や、着信回線（チャネル）の大幅なスケールアップが必要になった場合に、柔軟に対応できる設計になっているかも、長期的な運用を見据えて発注段階で確認しておくべきポイントです。加えて、開発会社を選定する際には、電話網・PBX連携を含むIVR開発の実績が具体的にどの程度あるか、類似業界・類似規模のプロジェクトを手掛けた経験があるかを必ず確認しましょう。一般的なWebシステム開発の実績は豊富でも、電話交換の仕組みやSIPプロトコルに関する知見が乏しいベンダーに発注してしまうと、要件定義の段階から手戻りが発生しやすくなります。これらのチェックリストを踏まえて複数の開発会社から相見積もりを取り、単純な金額の比較だけでなく、体制・実績・保守サポートの手厚さまで含めて総合的に判断することが、フルスクラッチ開発を成功させる鍵となります。

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

フルスクラッチ開発を発注する際は、費用や技術要件だけでなく、どのような契約形態で進めるかも成否を大きく左右します。また、すでに稼働している古いオンプレミスIVRやPBX一体型の設備を刷新する場合には、段階的な移行計画を立てておくことが、業務を止めずに切り替えるための重要なポイントになります。

フルスクラッチ開発の契約形態には、大きく分けて「請負契約」と「準委任契約」の2種類があります。請負契約は、あらかじめ定めた仕様・成果物を完成させることを開発会社が約束する契約形態で、予算と納期の見通しが立てやすい一方、要件定義後に仕様変更が発生すると、追加費用や納期の見直しが発生しやすいという特徴があります。既存のPBXや回線設備との連携要件、必要な機能がすでに明確に固まっている場合は、請負契約でしっかりと成果物を定義してから発注するスタイルが適しています。一方、準委任契約は、実際にかかった工数（時間・人月）に応じて費用が発生する契約形態です。IVRは実際に稼働させてみないと分からない要素（音声の聞き取りやすさ、メニューの使い勝手など）が多いため、要件を固めきれない段階から着手し、パイロット運用の結果を見ながら仕様を柔軟に調整していきたい場合には、準委任契約でアジャイル的に進める方が現実的な選択となることがあります。どちらの契約形態を選ぶにしても、仕様変更が発生した際の影響範囲調査・工数見積もり・承認・実施という変更管理プロセスを、契約時にあらかじめ明文化しておくことが、後々のトラブルを防ぐ最大のポイントです。

すでに長年稼働している古いオンプレミスPBXやIVR一体型設備を刷新する場合、いきなり全回線を新システムに切り替えるのではなく、段階的な移行アプローチを取ることがリスク低減の観点から強く推奨されます。具体的には、まず一部の回線や特定の時間帯だけを新システムに接続し、既存システムと並行稼働させながら動作を検証する期間を設け、問題がないことを確認してから全面切り替えを行う進め方が一般的です。移行にあたっては、現行システムに設定されている音声ガイダンスの文言、コールフローの分岐ルール、転送先の電話番号一覧などを事前に棚卸しし、新システムへの設定移行に漏れがないかを入念にチェックする必要があります。特に長年の運用の中で、担当者の異動や退職によって「なぜこの設定になっているのか」が分からなくなっている分岐ルールが残っているケースも多く、移行を機に不要になった選択肢を整理し、シンプルな構成に組み直す好機と捉えることもできます。また、切り替え当日は想定外のトラブルに備え、旧システムへすぐに切り戻せる体制を確保しておくことも、業務への影響を最小限に抑える上で欠かせない準備です。加えて、旧システムを保守してきたベンダーや社内担当者に対して、これまでの運用で蓄積されたノウハウ（よくある問い合わせ内容、繁忙期の着信傾向、過去に発生したトラブルとその対処法など）を新しい開発会社へ引き継ぐヒアリングの機会を設けておくことも重要です。長年の運用の中で暗黙知として蓄積されていた勘所が引き継がれないまま新システムに切り替わってしまうと、旧システムでは起きなかったはずの初歩的なトラブルが再発し、せっかくのフルスクラッチ投資の価値を損なうことになりかねません。

まとめ

本記事では、IVR開発のフルスクラッチ・オーダーメイド開発について、クラウド型SaaSとの比較、フルスクラッチが向いているケース、費用相場、開発・運用時のリスク、そして発注時の確認ポイントまでを体系的に解説しました。クラウド型は初期費用0〜30万円・月額数千円〜数万円・最短即日〜数週間で導入できるのに対し、フルスクラッチ開発は初期費用50万円〜数千万円規模・月額数万〜数十万円・数ヶ月〜1年以上という大きな差があり、金融機関等の高セキュリティ要件、独自基幹システムとの深い連携、大規模かつ特殊なコールフロー要件がある場合にのみ選択すべき手法です。属人化やセキュリティ対応の自己責任化、要件肥大化による長期化といったリスクを踏まえ、システム連携範囲・オペレーターへの逃げ道・PCI DSS準拠範囲・障害対応SLAといった発注時のチェックリストを押さえておくことが、投資に見合う成果を得るための第一歩です。あわせて、要件が明確に固まっているなら請負契約、パイロット運用を通じて仕様を柔軟に調整したいなら準委任契約というように契約形態を使い分けること、そしてレガシー環境からの刷新であれば並行稼働期間を設けた段階的な移行計画と旧システムのノウハウ引き継ぎを行うことが、切り替えに伴うトラブルを防ぐ鍵となります。自社がフルスクラッチを選ぶべき明確な理由があるかを見極めた上で、複数の開発会社に具体的な要件を提示して見積もりを取ることから始めることをお勧めします。

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

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

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

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

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

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。