問い合わせ対応AIエージェントは、業務整理、PoC、スモールスタート、対象拡大、継続改善の順に進めると、品質と現場の受け入れやすさを本番前に確かめながら広げられます。
まず機能と効果を押さえ、そのうえでRAG構築、費用、見積もりの要点を順に見ていきます。
AIシステム開発の工程ごとの進め方と注意点については、無料ホワイトペーパー「AIシステム開発の完全ガイドブック」で詳しく解説しています。
問い合わせ対応AIエージェントの定義
問い合わせ対応AIエージェントは、生成AIを中心に、社内ナレッジや業務システム、認証機能、有人窓口をつなぐソフトウェアです。受付から解決、あるいは担当者への引き継ぎまでを支援します。
従来のチャットボットは、選択肢やFAQに沿って回答します。一方、AIエージェントは質問の意図を理解し、情報を検索して、許可された範囲で次の処理へ進めます。
4つの基本機能による対応業務の分解
問い合わせへの対応は、顧客接点、オペレーター支援、後処理、品質評価の4つの機能に分けて捉えられます。機能ごとの役割は、次の内容です。
- 顧客接点：Webチャットやメール、音声ボットで質問を受け、営業時間外も一次対応します。
- オペレーター支援：通話中に関連マニュアルを示し、次に確認すべき項目を提案します。
- 後処理：通話の文字起こしと要約、CRMへの記録を自動で行います。
- 品質評価：応対ルールへの適合と解決状況を分析します。
すべてを一度に自動化しなくても構いません。まずは検索支援と要約から始め、低リスクなFAQの自動回答へ広げる進め方もあります。
AIに任せる業務、人が確認する業務、人へ渡す業務を分けておくと、対応品質を保ちやすくなります。
従来のチャットボットやIVRとの違い
従来型の各方式が得意とする応答と、AIエージェントに必要な制御を並べて比べます。
- 従来型チャットボット：登録済みの質問と回答や、シナリオの分岐を正確に返すことが得意です。
- IVR：「1番は注文、2番は解約」のような定型的な振り分けに向いています。
- AIエージェント：表現の違う質問をまとめて扱い、複数の文書を検索して、文脈に応じて回答を変えられます。
自由度が高いぶん、根拠のない回答や誤処理を防ぐ仕組みが欠かせません。そのため、参照先と権限を限定し、判断が必要な場面では人へ渡す窓口として位置づけます。
導入効果を裏付ける事例と数値
効果は自動化率と併せて、平均処理時間、一次解決率、応答待ち時間を測ります。顧客満足度と後処理時間も組み合わせると、効果を多面的に捉えられます。
公開事例は、対象業務も測定条件も異なります。そのため、判断するときは自社の導入前の数値と比べることが欠かせません。
富士通Salesforceサポートデスクの取り組み
富士通のSalesforceサポートデスクは、Agentforceのパイロット検証を経て、月間問い合わせの約15％をAIが対応する体制を目指しています（出典：Salesforce「富士通のSalesforceサポートデスク対応にAgentforceを採用」、2025年）。
注目点は、窓口をAIだけに置き換えず、人とAIのハイブリッドな労働力として設計していることです。自社で導入する際は、次の4点を検討します。
- 目標の立て方：問い合わせ分類ごとに自動化可能な割合を測り、そこから目標を置きます。
- 自動化しやすい質問：製品仕様の確認、営業時間、配送状況のような定型テーマです。
- 人の確認が必要な質問：契約変更、返金、クレームなどは、本人確認や承認を挟む必要があります。
- 併せて測る指標：分類精度と有人切り替え率も測ると、自動化率の数字に説明がつきます。
2026年の導入で重視すべき投資対効果
富士通の2025年調査では、15カ国の経営幹部800人の約8割が、その年のAI投資を強化すると回答しました（出典：富士通「2025年度 富士通CxO調査レポート」、2025年）。
一方で、生成AIを業務に組み込んで本番運用する企業は5％と紹介されています。同調査は、投資意欲と業務運用への移行に差があることを示します。投資効果を見るときは、成果と人員配置への影響を次の観点から整理します。
- ROIの対象：人件費に加えて、放棄呼や応答時間、教育期間を評価します。品質のばらつきやナレッジ更新も対象に入れます。
- 余力の使い方：人員削減だけに使うと、難しい案件を担う人材や教育時間が失われます。
回答精度を支えるRAG構築の実務
RAGは、質問に関連する社内文書を検索し、その内容を生成AIに渡して回答させる構成です。モデルの記憶に頼らず文書を参照するため、更新される製品仕様や社内ルールも扱いやすくなります。
正答率は導入の時点で決まるものではなく、文書形式や検索条件、回答プロンプトを継続して改善し、評価データも更新して保ちます。
ナレッジの表記ゆれ対応と形式変換
検索しやすいナレッジに整えるには、作業を資料整理、表記ゆれ対応、形式変換の3つに分けて進めます。
- 資料整理：FAQやマニュアル、約款などを集め、最新版・適用範囲・担当部署・改訂日を付けます。
- 表記ゆれ：「解約」「キャンセル」「契約解除」などの同義語や、「ログインできない」「サインインできない」を辞書にまとめ、検索漏れを減らします。
- 形式変換：ExcelやPDFをテキストやMarkdownに直し、見出し、条件、例外、更新日が分かる形にします。
表のセルだけを分割すると、条件と回答の関係が失われてしまいます。そのため、表の意味を文章に直してからチャンクに分割します。
古い文書や廃止済みのキャンペーン資料が混ざると、検索結果の品質が下がります。そこで、公開と非公開の区別も管理します。
ナレッジは週次で更新し、問い合わせログから不足しているFAQを足していくと、公開情報の変化にも追随できます。
同義語辞書・チャンク・再ランキングの調整順序
精度が低いときは、モデルを大きくする前に、検索部分を次の順で確かめます。
- 同義語辞書を追加します。
- 取得する文書数を調整します。
- セマンティックランカーなどの再ランキングを試します。
- チャンクの長さと埋め込みモデルを評価データで確認します。
チャンクが短すぎると条件が抜け、長すぎると別のテーマが混ざることがあります。
プロンプトには、根拠文書にない内容を推測しないこと、商品条件を明記すること、不明なときは有人窓口へ案内することを決めておきます。
RagasはRAGの検索と生成を自動評価する研究フレームワークで、回答の正確性や文脈との関連性を測る考え方を示しています（出典：Ragas「Automated Evaluation of Retrieval Augmented Generation」、2023年）。
LLM-as-a-Judgeによる評価の自動化
評価は、データ準備から継続監視までを一続きの流れとして組み立てます。
- 評価データ：匿名化した質問に、正解、許容回答、有人へ渡す条件を添えて用意します。
- 根拠判定：LLM-as-a-Judgeで整合性を判定し、そのサンプルを人がチェックします。
- 監視項目：分類別の正答率、根拠提示率、エスカレーション漏れを追います。
- 回帰テスト：ナレッジ、プロンプト、モデルの変更時に、同じ評価セットを使います。
- 顧客体験：自動化率と併せて、正答率と、お客さまの受け止めを確かめます。
人とAIの協働設計とエスカレーションルール
100％の自動化をめざすより、AIが一次対応し、人が判断や共感を担う運用のほうが現実的です。切り替えの条件と引き継ぎ情報が曖昧だと、AIが会話を引き延ばし、担当者が同じ質問を繰り返すおそれがあります。
本人確認、クレーム、聞き返し超過による切り替え条件
人へ切り替える条件は、本人確認、相談内容、回答の確かさに応じて決めます。
- 本人確認：契約情報、返金、住所変更、決済情報は、確認が終わるまで回答しません。
- 高リスクな相談：怒りや不安、差別的発言、事故、法的責任に関わる内容は、優先して人へ渡します。
- 回答困難時：聞き返しが一定回数を超えたときや、信頼度がしきい値を下回ったときにも切り替えます。
切り替えるときは、顧客の質問と認証状況、AIの回答をCRMに渡します。参照文書と未解決点も併せて渡すと、担当者は履歴を読み直さずに済み、引き継ぎ後のAHTを短縮できます。
自動処理に必要な権限は最小限に絞ります。たとえば、本人確認の結果や権限はAPIから受け取り、画面に表示するだけにします。
オペレーターの心理的安全性を含む要件
現場の負荷を抑えつつ、オペレーターが安心して働けるよう、次の施策を組み合わせます。
- 役割分担：AIが定型質問や検索を担い、人は謝罪や複雑な調整に時間を使います。
- オペレーター支援：通話中のマニュアル提示や要約、応対後の記録を助けます。
- カスハラ対策：怒鳴り声の音声変換、危険な発話の検知と管理者への通知を検討できます。
人員削減だけを目的にすると、難しい問い合わせが人に集中し、現場の負荷が上がるおそれがあります。
導入前には、目的と限界をオペレーターに説明しておきます。あわせて、AIの判定を人事評価に直結させないルールを設けると、利用への抵抗を下げられます。
問い合わせ対応AIエージェントの費用相場とコストの内訳
費用は、FAQ検索だけにするか、CRM・PBX・決済まで連携するかで変わります。次の金額は、2026年時点の機能と工数を積み上げた概算で、市場統計ではありません。
- 既存SaaSの設定：初期100万〜500万円程度です。
- 小規模な個別開発：RAGと管理画面を含み、500万〜1,500万円程度です。
- 本格構築：音声、認証、複数連携を含み、1,500万〜3,000万円以上です。
初期費用は要件定義、RAG、連携、テストで構成
初期費用は、要件定義からテスト、リリース支援までの作業を積み上げて決まります。
- 設計とナレッジ：業務整理と会話設計、ナレッジ整備を行い、RAG、プロンプト、管理画面を作ります。
- 連携と導入：CRM・チケット管理とのAPI連携と、認証・権限の設計を行い、テストや教育、リリースまで担います。
工数を左右するのは、FAQの件数に加えて、文書の状態と問い合わせ分類です。例外処理や既存APIの仕様も、工数に響きます。
音声対応では、音声認識と音声合成、電話基盤の設計が加わります。さらに、録音とリアルタイム処理も設計に含める必要があります。
遅延が長引くと、顧客は話を重ねたり電話を切ったりします。このため、混雑時の応答時間と再生開始までの時間も受け入れ基準に含めます。
月額費用の内訳：LLM、ベクトルDB、音声API、監視
月額費用は、サービスの利用料とは別に、次の費用も分けて見積もります。
- AI・検索基盤：LLMの入出力トークンと埋め込み生成、ベクトルDBの費用を含みます。
- 運用基盤：ログ保管、監視、バックアップ、有人対応の運用費を含みます。
- 音声関連：音声認識・合成と電話回線を計上します。
LLMの料金は、モデルと処理量で変わります。そのため、公式料金表を使い、1件あたりの平均入出力トークンと月間件数から試算します（出典：OpenAI API Pricing、2026年参照）。
月1万件のチャットで入出力を計測すると、通常モデルと高精度モデルの費用と品質を比べられます。検索だけの質問は軽量モデルに、契約条件の説明や要約は高精度モデルに振り分ける方法もあります。
小規模SaaSの月額は数万円から数十万円程度です。ただし、監視や改善、有人支援まで含めると、月額数十万〜数百万円になる場合があります。
ROIの算出方法：削減時間と品質指標の金額換算
ROIは、削減時間と品質面の効果を金額に換算して算出します。
- 月間問い合わせ数、対応時間、人件費単価から削減時間を見積もり、AI月額・保守・ナレッジ更新費を差し引きます。
- 放棄呼による機会損失、教育期間、再問い合わせの改善効果を加えます。
- 初期費用を月次の純効果で割り、投資回収期間を算出します。
ただし、自動化率を上げるために回答基準を緩めると、CSATやFCRが下がり、再問い合わせが増えるおそれがあります。
PoCでは、品質を保ちながら時間を減らせる問い合わせ分類を検証します。初期段階で金額効果を確定させることは、PoCの目的ではありません。
見積もりを取る際のポイント
複数社の見積もりは、制作範囲と運用内容をそろえてから比べます。ナレッジ整備やテスト、リリース後の精度改善が別料金になっていると、初期費用だけでは総額が分かりません。
見積もりを依頼するときは、問い合わせ件数やチャネル、業務を同じ資料で提示します。あわせて、連携先とセキュリティ条件も同じ形式で示します。
要件定義書に書く呼量、チャネル、業務範囲
月間と時間別の件数、繁忙期のピークを記載します。加えて、チャットと電話の比率や平均会話ターン数も書きます。現在のAHT、FCR、CSAT、有人切り替え率も併せて示すと、見積もりの前提がそろいます。
「注文状況」「解約」「返金」などの対象業務を分類したうえで、回答だけにするか、検索・認証・更新まで行うかを明記します。対応外の質問や営業時間外の扱いも、あらかじめ決めておきます。
セキュリティ要件では、データの扱いを次の観点から確かめます。
- データ保護：個人情報やカード番号の自動マスキングとログ暗号化を確かめ、保存期間や権限、学習利用、保管場所も見ます。
- 音声データ：録音と文字起こしを分けて扱い、本人確認の情報は要約ログに残さない設計にします。
API連携、権限、障害時のフェイルオーバーの確認
既存システムとの接続方法と、障害時の継続対応を、設計と見積もりの段階で確かめておきます。
- APIと権限：登録、顧客情報の参照、状態更新、通知をAPI単位で定義し、権限を絞って操作を監査ログに残します。
- 既存環境：古いPBXや独自CRMにAPIがなければ、中継サーバーやRPAも比較します。
- 障害対応：障害時に、別モデル、シナリオ型ボット、有人窓口のどれへ切り替えるかを決めます。
切り替え後に同じ質問を繰り返さないよう、会話履歴は共通の形式で保持しておきます。見積書には、障害対応とバックアップに加えて、復旧目標時間と切り替え訓練も入れておきます。
開発会社の選定基準：AIと業務運用への対応力
発注先は、AIの知識に加えて、業務運用への対応力も含めて選びます。
- 業務理解：問い合わせ業務やCRM、音声基盤、セキュリティ、運用改善の知識を確かめます。
- PoCと引き継ぎ：評価データや引き継ぎ表、更新手順、運用画面を確かめ、プロンプトや検索設定、評価方法の引き継ぎを契約に含めます。
- 開発方式：SaaS、既存製品への追加開発、スクラッチを比べます。SaaSは早く始めやすい一方で、独自機能に制約が出る場合があります。
スクラッチは業務に合わせやすい一方で、モデル変更や脆弱性対応、監視、保守が必要になります。そのため、5年程度の総保有コストで比べます。
失敗しない開発・構築の進め方とKPI設計
開発は、業務整理、PoC、スモールスタート、対象拡大、継続改善の順に進めます。最初の対象には、件数が多く、根拠が整っていて、誤答の影響を限れる業務を選びます。
PoCでは、品質やコスト、現場の受け入れやすさを本番の前に確かめます。AIを動かすこと自体は、あくまで手段です。
低リスクの問い合わせ100〜300件によるPoC
PoCは、過去の問い合わせから匿名化したデータを抽出し、正解と有人切り替えの条件を付けて始めます。
- 評価品質：回答の正確性、根拠の提示、誤答の重大度、切り替えの適切さを記録します。
- 運用指標：応答時間と1件あたりの推定費用も記録します。
- 検証範囲：PoCでは対象を一つのチャネルに絞ります。相談導線を置き、週次でFAQと誤答を見直します。
適切な件数は業務のばらつきで変わります。100〜300件程度を一単位とすると、定型質問と例外を確かめやすくなります。
自動化率が目標に届かなくても、検索時間や後処理時間が減っていれば、次の投資判断に使えます。
自動化率とCX指標を並べて見るダッシュボード
効果を偏りなく把握するため、効率、顧客体験、品質の指標を分けて追います。
- 効率：自動化率、有人切り替え率、平均処理時間、後処理時間、応答開始時間、呼量削減率を見ます。
- 顧客体験：一次解決率、再問い合わせ率、CSAT、放棄率、クレーム率を追います。
- 品質：根拠提示率、誤答率、マスキング漏れ、ルール違反率を確認します。
いずれかの指標が悪化したら、その変更の展開を止めて元に戻せるようにしておきます。たとえば、自動化率が上がってFCRが下がる場合は、顧客の目的を解決できていない可能性があります。
自動回答率が低くても、検索支援でAHTが短縮し、CSATが維持されていれば、支援としては成功です。また、変更ごとの効果は週次で分けて検証します。
本番運用の更新と障害訓練の定例化
運用では更新と障害訓練を定例化し、業務やAIの変化を監視します。
- 更新管理：責任者を決め、ナレッジ、評価データ、モデル、API、権限を定期的に見直します。
- 障害訓練：LLM、検索基盤、CRMの停止や、音声認識の遅延、個人情報検知の誤作動を想定します。固定回答や有人窓口への切り替えと案内文も確認します。
新商品や制度の変更は、公開前にナレッジへ登録し、旧文書との矛盾を確かめます。更新履歴と承認者を記録しておくと、回答の根拠を後から追跡できます。
よくある質問（FAQ）
費用、誤回答、既存システムとの連携について、導入前に知っておきたい考え方をまとめます。
問い合わせ対応AIエージェントの開発費用はいくらですか？
既存SaaSの設定は初期100万〜500万円程度です。RAGや管理画面を含む個別開発は500万〜1,500万円程度で、音声、認証、複数連携を含むと1,500万〜3,000万円以上が目安になります。
金額は、問い合わせ量やナレッジ、既存API、セキュリティ要件によって変わるため、前提条件をそろえて見積もります。
AIの誤回答やハルシネーションは防げますか？
誤回答は完全には防げないため、許可したナレッジだけを検索し、根拠がない場合は回答しない設定でリスクを下げます。さらに、信頼度に応じた有人切り替えと回帰テストも行います。
契約や返金、本人確認など影響の大きい処理には、人の承認や業務システム側の検証を必須にします。
古いCRMやPBXでも連携できますか？
APIがあれば、顧客情報の参照や問い合わせの登録、担当者への通知などを連携できます。APIがない場合は、中継サーバーやファイル連携、RPAを比べます。
認証情報や障害時の再送も、設計に含めます。まずはCRMを更新せず、問い合わせ履歴から回答候補を示す方法なら、影響を抑えて検証できます。
まとめ｜小さく始めて運用で育てる問い合わせ対応AIエージェント
問い合わせ対応AIエージェントは、ナレッジ、認証、CRM、有人対応、品質評価をつなぐ業務基盤です。低リスクの問い合わせからPoCを始め、RAGと役割分担を継続して改善していきます。
費用は初期開発に加えて、LLMやベクトルDB、音声APIの利用料も含めて考えます。監視やナレッジ更新の費用も入れておきます。
自動化率に加えて、AHTやFCR、CSATを追います。誤答率と有人切り替え率も、あわせて見ます。
顧客体験と現場の心理的安全性を守りながら対象を広げます。生まれた余力は、人員削減だけでなく、複雑な相談や改善活動にも振り向けます。
導入前に確認するチェックリスト
問い合わせ分類、最新ナレッジ、有人切り替えの条件、個人情報のマスキング方法は、導入前に決めておきます。CRMやPBXとの連携、障害時の代替手段も確かめます。
PoCの評価指標と、導入後の更新責任者も決めておきます。これらが決まっていれば、初回の相談で見積もりの条件と成功基準を具体的に伝えられます。
本文で参照した公開情報
富士通Salesforceサポートデスクの事例は Salesforce「富士通のSalesforceサポートデスク対応にAgentforceを採用」、AI投資動向は 富士通「2025年度 富士通CxO調査レポート」、コンタクトセンターAIの課題と動向は NEDO「成果発表カタログ」を参照しています。
RAG評価の考え方は Ragas論文、API従量課金は OpenAI API Pricingを参照しています。
▼開発を相談する前に読みたい無料ホワイトペーパー
・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を創業。