コールセンターのAIエージェントの発注は、対象業務を絞り、有人対応の条件を決めたうえで、RFPとPoCで確かめてから本開発へ進みます。
発注形態は業務の独自性や既存システムとの連携量で選び、手順や費用、契約は段階ごとに決めていきます。
AIシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「AIシステム開発の完全ガイドブック」で詳しく解説しています。
コールセンターのAIエージェントの概要

コールセンターのAIエージェントは、顧客の発話や入力を理解して、社内ナレッジや業務システムを参照します。そのうえで、回答や検索、記録、処理を自律的に進める仕組みです。
IVRやシナリオ型ボットは、あらかじめ決めた選択肢を案内します。一方、AIエージェントは、複数の意図を含む質問や、前の発話を踏まえた会話にも対応しやすい点が特徴です。
4つの基本機能
機能は、応答、オペレーター支援、通話後の処理、品質評価の4つに分けると、それぞれの役割を比べやすくなります。
- 自動応答:FAQ案内、受付、予約変更、本人確認後の照会を処理します。
- オペレーター支援:会話中に、マニュアルや回答候補、次の確認項目を提示します。
- 後処理の自動化:通話を文字起こし・要約し、CRMへ記録します。
- 品質評価:全件または大量の通話を分析し、評価基準への適合やNGワードの有無を見ます。
従来のIVR・シナリオ型ボットとの違い
IVRは「1を押してください」のように、電話を適切な窓口へ振り分けます。シナリオ型ボットは、用意した質問と回答には強いものの、想定外の言い換えや複合的な相談には弱い傾向があります。
AIエージェントは、音声認識、LLM、検索を組み合わせ、業務APIや音声合成などとも連携して動きます。状況に応じて次の行動を選べますが、自由度が高いほど誤回答のリスクも増えます。
発注時は、AIに任せる範囲と、決定論的なルールで固定する範囲を分けて設計します。
AIエージェントの発注形態の選び方
発注形態は、既製サービス、個別開発、両者の中間のいずれかから選びます。
判断材料は、業務の独自性、既存システムとの連携量、セキュリティ要件です。さらに、将来の拡張性や、社内に運用できる人材がいるかも確認します。そのうえで、価格だけでなく、導入後に自社で改善できる範囲まで含めて選びます。
既製のAIコンタクトセンターを導入する形態
クラウド型サービスは、問い合わせ件数が多く、FAQ回答や要約などの標準機能で目的を達成できる場合に適しています。
- 導入負担:初期開発を抑えつつ、機能更新やインフラ運用は提供会社に任せられます。
- 技術検証:音声とチャットの環境を、短期間で試せます。
- 個別処理:独自の本人確認や基幹処理では、追加開発費と制約の確認が必要です。
AWSは2026年1月、日本語設定を含むAIエージェントのスターターキットを案内しました(出典:AWS「Amazon Connect アップデート まとめ – 2026年1月」、2026年)。これにより、音声・チャット環境を試せる選択肢が増えています。
個別開発やフルスクラッチで構築する形態
個別開発を選ぶときは、対応する業務の範囲と、導入に必要な体制をあわせて検討します。
- 適する条件:複雑な業務ルール、オンプレミスのPBX、独自CRM、厳格な監査要件がある場合は候補になります。
- 設計範囲:自社業務に合わせて、認証、検索、エスカレーション、CRM記録を設計できます。
- 工数:要件定義とテストの工数は大きくなります。
- 開発会社の経験:AIモデルだけでなく、電話網、業務システム、データ保護を一体で設計した実績があるかを確認します。
標準サービスと個別開発を組み合わせる形態
実務では、音声基盤や会話分析にクラウドサービスを使う方法があります。また、ナレッジ、業務API、エスカレーションだけを個別開発するハイブリッドも現実的です。
標準機能で早く検証しながら、差別化につながる業務処理に投資できます。ただし、標準機能と追加開発の境界、サービス変更時の影響、データの移行可否は、提案書に明記してもらいます。
発注・外注の進め方

まず現場の課題を業務単位に分け、RFP(提案依頼書)で複数社に同じ条件を示します。発注から運用までは、次の順に進めます。
- 現状把握と対象業務の選定
- 要件整理とRFPの配布
- 提案・見積比較とPoC
- 正式開発と運用改善
現状業務と自動化対象の整理
自動化の対象は、現場の状況と業務ごとの特徴を見たうえで決めます。
- 現状指標:入電数、曜日・時間帯、問い合わせ分類、平均処理時間(AHT)、後処理時間(ACW)を確認します。
- 応対指標:一次解決率(FCR)、顧客満足度(CSAT)、放棄呼、転送率も把握します。
- 業務分類:定型で正解が明確な業務、情報検索が必要な業務、判断や交渉が必要な業務、本人確認や決済を伴う業務に分けます。
- PoCの対象:最初は定型で正解が明確な業務から選ぶと、誤回答の影響を抑えながら効果を検証しやすくなります。
RFPに書く成果物・連携・評価基準
コールセンターAIの提案を比べるには、業務要件だけでなく、PBX・CRM連携や有人対応の条件もRFPでそろえておく必要があります。
- 業務条件:背景・目的、対象チャネル・業務、想定会話、利用者、対応時間。
- 環境と納品:既存PBX・CTI・CRM、利用可能なデータ、セキュリティ。日程、納品物、運用体制、予算。
- 応対要件:有人切替条件、回答不能時の表現、根拠表示。ログ保存期間、評価用テストデータ。
- 配点例:機能適合性30点、連携・セキュリティ25点、PoC計画15点。運用・保守15点、費用15点。
配点を設けると、安さだけの比較を防げます。
回答精度はデータや質問で変わるため、正答率だけで判断しません。そのため、重要質問の誤答率と有人転送の適切さ、応答遅延、ログの追跡可能性も評価します。
PoCの検証と本開発への移行
検証内容と評価条件は、PoCを始める前に整えておきます。
- 評価セット:本番同様のデータを無制限に使わず、代表的な問い合わせを集めて作ります。
- テスト内容:定型質問、言い換え、方言、割り込み、沈黙を評価します。
- 追加のテスト内容:感情的な発話、複数意図、回答不能な質問も含めます。
- 終了条件:デモが動くかどうかより、対象業務の自動完結率、誤案内率、有人転送率を導入前と比べられる状態にします。
- 比較指標:レイテンシやオペレーターの作業時間も比較できるようにします。
PoCの結果を見て、効果とリスクを確かめたうえで、本開発へ進みます。
開発・構築で確認する技術と運用のポイント
AIエージェントの構築は、LLMを選ぶだけでは完了しません。RAG、STT、TTSといった要素のほか、電話網やCRM、認証基盤、監視基盤もつなぎます。
誤回答や障害が起きたときの業務手順も、あらかじめ設計しておく必要があります。そのため、技術構成と運用は一体で検討します。
RAGとナレッジの整備と運用
RAGの回答品質を保つには、検索対象となる情報と、その更新方法の両方を整える必要があります。
- RAGの役割:回答生成前にFAQや規程、商品情報を検索し、根拠としてAIへ渡します。
- ナレッジ管理:古い情報の廃止、適用期間、対象商品を管理します。回答責任者と更新頻度も管理対象です。
- データ整備:表計算ファイルをそのまま入れるより、見出しと本文を整理したmdやtxtに変換します。
- 検索評価:質問と回答の単位を明確にすると、検索結果を評価しやすくなります。
- 更新運用:週次で誤答を見直し、ナレッジを更新する運用も委託範囲に含めます。
ボイスボットのVUXとPBX・CTI連携
音声対応では、回答内容に加えて、聞き取りやすさと会話のテンポも設計します。
- 会話体験:バージイン、沈黙時のタイムアウト、聞き返し、発話の重なりを試します。
- 応答遅延:STT・LLM・TTSの往復を測ります。短く先に返し、検索結果を後から補う方法もあります。
- 電話連携:SIP・VoIPのルーティング、録音、転送情報を確認します。画面ポップアップやオンプレミス用音声ゲートウェイも対象です。
数秒の遅延でも、電話では不自然な間になりやすいため、実際の応答テンポをテストします。
AWSの公開試算では、国内通話3,000件・平均4分などで月額377.95ドルの例があります(出典:AWS「基本的なコンタクトセンターを利用するためのクラウド構成と料金試算例」、2025年2月時点)。
電話番号や録音保存、AIのほか、連携開発と保守も、それぞれ別に変動します。そのため、個別の前提を確認します。
機密情報の保護とAI障害時のBCP
通話には、氏名や住所、口座情報、カード情報などが含まれる可能性があります。そこで、保護策と障害時の対応を先に決めておきます。
- データ保護:保存場所、学習利用、アクセス権限を確認します。暗号化、削除期限、再委託、監査ログも対象です。
- 機密情報対策:PCI DSS相当の業務では、音声認識時の検知・マスキング、画面非表示、DTMF入力を比較します。
- 障害時の代替:シナリオ型ボット、有人窓口、折り返し受付への切り替えを決めます。
外部LLM APIや音声基盤が停止した場合に備えて、復旧目標時間(RTO)、復旧時点(RPO)、障害監視を定めます。
手動運用へ切り替える責任者は、RFPと契約書に記載しておきます。障害時に判断が遅れないよう、体制も整えます。
AIエージェント開発・構築の費用相場と内訳
コールセンターのAIエージェント開発費用は、既製サービスの設定だけなら数十万円からです。複数システムをつなぐPoCなら数百万円です。さらに、本番の音声自動応答・CRM連携・監視・運用設計まで含めると、数百万円から1,000万円超になることがあります。
これは概算の金額で、公定価格ではありません。対象チャネルと問い合わせ量、音声品質によって変わります。また、データ整備や連携数、セキュリティ、保守期間でも変わります。
見積書では、総額だけでなく工程と前提条件を分けて確認します。内訳が明らかになると、提案どうしを比べやすくなります。
要件定義・データ整備・連携で変わる初期費用
初期費用には、業務ヒアリングと要件定義、会話設計、プロンプトやガードレールの設計が含まれます。加えて、FAQやマニュアルの整理、RAG構築も対象になります。
費用には、STT・TTS設定、PBX・CTI・CRM連携、認証が含まれます。テスト、教育、リリース支援も含まれます。特に、古いFAQを洗い出す作業や、評価用の正解データを作る作業は、見落とされやすい工数です。
ナレッジが不十分なままでは、高性能なモデルを選んでも回答品質は安定しにくくなります。そのため、データ整備の範囲を見積もりで確認します。
従量課金と運用費に分けたランニングコスト
ランニングコストは、従量課金と運用費に分けて確認します。
- 従量費:AI・音声・電話番号、録音・文字起こしの保存、検索基盤を確認します。
- 運用費:監視、保守、ナレッジ更新、精度評価、問い合わせ対応を見ます。
Amazon Connectの公開価格は音声1分0.038ドル、チャット1メッセージ0.010ドルです(出典:AWS「Amazon Connect Customer Pricing」、2026年確認)。ただし、地域や通信事業者、プランによって変わります。
Azure Speechのテキスト読み上げは、処理文字数が課金単位です(出典:Microsoft Learn「Text to speech overview」、2026年確認)。そのため、会話量に加えて、応答文の長さも費用に影響します。
見積を比べるには、月間通話分数、平均発話長、同時接続数をそろえます。録音保存期間とモデル利用量も、同じ前提で比べます。
軽量モデルを定型分類に使い、高性能モデルを例外処理に限る方法があります。また、録音保存期間を業務要件に合わせると、品質を保ちながら従量費を抑えられます。
契約形態と見積比較で失敗しないためのポイント

要件が変わりやすいPoCと、成果物を確定しやすい本番開発とでは、適した契約が異なります。そのため、工程ごとに契約と責任を整理します。
契約形態が曖昧なままだと、追加費用が出たときにどこまでを誰が受け持つか、成果物をどう検収するか、改善作業をどう扱うかで問題が起きがちです。見積の段階で、範囲を明確にしておきます。
PoCの準委任と本番の請負の使い分け
工程ごとに、作業の変わりやすさと成果物の確定度を見て、契約形態を選びます。
- 準委任:作業内容が変わりやすいPoCや要件探索では、稼働に対する契約が使いやすい場合があります。
- 請負:成果物と検収条件を確定できる工程で検討します。対象は画面、API、連携仕様、テスト項目などです。
- 組み合わせ:要件定義・PoCは準委任、本開発の一部は請負、運用改善は月額準委任にできます。
回答精度は無条件に保証させず、対象データ、評価セット、合格基準で条件を定めます。再学習や修正の回数、モデル変更時の扱いも定義します。
知的財産権、学習データの利用範囲、ログやプロンプトの所有権も確認します。再委託や秘密保持、個人情報の扱いに加えて、障害時対応と終了時のデータ返却も対象です。
見積の前提・成果物・除外範囲の比較
3社程度から見積を取る場合は、同じRFPと評価セットを渡し、比較する項目をそろえます。
- 費用内訳:初期費、月額固定費、従量費。追加開発単価、保守費、クラウド費、電話料金。
- 成果物と前提:各工程の工数・担当・納期。対象は要件定義、会話設計、ナレッジ、連携です。テスト、教育、リリースも含みます。
- 除外範囲とリスク:ナレッジ更新、PBX連携、有人転送、障害時の代替運用の有無。
- デモ検証:回答不能、割り込み、誤認識。本人確認失敗、クレーム、システム停止。
最安の提案が最適とは限りません。除外範囲や簡易な設計は、導入後の追加費用や現場の負担につながります。
デモの際は、担当者が想定リスクを具体的に説明できるかも見ます。
委託先の業務と運用の実績による選び方
AIモデルの説明だけでなく、業務と運用の実績を複数の観点から比べます。
- 技術・業務経験:コールセンター理解、音声基盤、CRM・CTI連携、セキュリティ、保守。
- 運用体制:提案・実装責任者、障害時の連絡時間、ナレッジ更新担当、現場教育の有無。
- 導入事例:導入前後の指標、対象業務、運用期間、失敗と改善策、数値の定義と測定期間。
自社に近い問い合わせ量や業界規制、システム構成の事例を優先します。社名や導入機能だけで判断しないようにします。
導入後の改善とKPIの委託範囲
AIエージェントは、リリース後も会話ログから誤答や離脱を見つけ、ナレッジと会話設計を更新していく必要があります。その仕組みが定着すると、効果が安定します。
自動化率だけを追うと、顧客に無理な自己解決を促す可能性があります。そのため、顧客満足度やオペレーターの心理的安全性を損なわない設計が必要です。
AIと人の役割分担
AIには、定型質問や営業時間・手続きの案内、要約を任せます。検索や品質チェックも、AIが担う範囲です。人には、例外判断や感情的な相談、補償や契約変更を任せ、カスハラへの介入や最終承認も人が担う設計が基本です。
業界や業務によって、自動化の上限は異なります。たとえば、BtoCの大量定型業務では、高い自動化を狙える場合があります。
金融・保険では40〜60%、医療・公共など高配慮領域では20〜40%程度を、現実的な目安として検証する考え方があります。
AHT・ACW・FCR・CSATの組み合わせによる測定
KPIは定義をそろえたうえで、複数の指標で導入前後を比べます。
- 基本指標:AHTは平均処理時間、ACWは通話後の後処理時間、FCRは一次解決率、CSATは顧客満足度。
- 成果と影響:自動応答率と転送率に加えて、AHT・ACWが下がったか、FCRが上がったかを確認します。再入電、苦情、回答時間、離職意向も見ます。
- 比較条件:導入前の4〜8週間を基準に、業務・時間帯・顧客属性別で追跡します。
2025年の京葉銀行向け検証では、RAGだけの正答率は58%でした。さらに、ユーザー確認技術を加えると、正答率は86%に向上したと日立が公表しています(出典:日立「京葉銀行のコールセンター業務における生成AI活用の検証」、2025年)。
モデルの選定に加えて、回答確認や有人エスカレーションを含む仕組み全体で、品質を改善します。
コールセンターのAIエージェント外注に関するよくある質問
外注を検討する際によく寄せられる質問に答えます。自社の業務やデータ量によって、最適解は変わります。
ここで示す目安はRFPのたたき台として使い、最終的にはPoCと見積で確認します。
AIエージェントの開発費用はどのくらいですか?
既製サービスの設定だけなら数十万円から、PoCや個別連携では数百万円です。本番開発と運用設計まで含めると、1,000万円を超えることもあります。
費用は、通話量や連携システム、データ整備によって変わります。セキュリティや保守の範囲も、費用に影響します。見積は、初期費用と月額・従量費を分けて取得します。
いきなり本番導入せずPoCを実施したほうがよいですか?
はい。音声品質や正答率、有人転送を確認するため、対象業務を絞ったPoCが有効です。既存システムとの連携や顧客の反応も、あわせて確かめられます。
開始前に、評価セットと合格基準を決めておきます。本番へ進む条件、改善して再検証する条件、見送る条件も定めておくと、検証が長引きにくくなります。
AIエージェントの委託先はどのように選べばよいですか?
AIのデモだけでなく、コールセンター業務や音声基盤の実績を確認します。CRM・CTI連携、セキュリティ、運用改善の実績も見ます。RFPには、同じ条件で回答してもらいます。
費用、成果物、追加費用の条件を比べます。保守、障害対応、ナレッジ更新、現場教育も比較します。自社に近い事例の担当者から、具体的な説明を受けます。
まとめ:発注前に確認するチェックリスト
コールセンターのAIエージェントを外注するときは、まず自動化したい問い合わせと、人へ切り替える条件を決めます。
次に、現状のKPIとデータを整理します。そのうえで、RFPには対象業務、PBX・CRM連携、RAGの条件を書き、セキュリティ、BCP、評価基準も共有します。
発注形態は既製サービス、個別開発、ハイブリッドから選びます。PoCで効果とリスクを確かめてから、本番へ進みます。
発注前に確認する項目
確認項目は、対象業務と自動化の上限、有人エスカレーションです。さらに、次の項目も確認します。
- RFPと評価セット
- STT・LLM・TTSの構成
- PBX・CTI・CRM連携
RAGとナレッジの更新、機密情報のマスキング、障害時の代替運用も確認します。費用では初期費用・従量費・保守費を見ます。契約では、知的財産やデータ返却の扱いも見ます。
これらを見積書と契約書に反映できる委託先であれば、価格だけでなく導入後の運用まで見通して比べられます。
参考ソース
本記事の最新動向、費用、事例の参考ソースは、AWS「Amazon Connect アップデート まとめ – 2026年1月」、AWS「基本的なコンタクトセンターを利用するためのクラウド構成と料金試算例」、AWS「Amazon Connect Customer Pricing」、Microsoft Learn「テキスト読み上げの概要」、日立「京葉銀行のコールセンター業務における生成AI活用の検証」です。料金や機能は更新されるため、発注時には各公式ページと提案書の記載を照合します。
▼RFP作成前に読みたい無料ホワイトペーパー
・AIシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>


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