問い合わせ対応のAIエージェント開発/構築の進め方/やり方/流れや方法/手法/工程/手順

問い合わせ対応のAIエージェントは、顧客の質問に答えるだけでなく、ナレッジ検索、本人確認、CRM登録、有人引き継ぎまでを一連の業務として実行する仕組みです。

人手不足や問い合わせの集中に悩む企業では、チャットボットを置くだけでは解決できない課題が増えています。回答の正確性、既存のCRMやPBXとの連携、個人情報の保護、導入後の費用まで設計しなければ、現場に定着するAIエージェントにはなりません。本記事では、問い合わせ対応のAIエージェントの全体像から開発・構築の進め方、2026年時点で検討しやすい費用相場、見積もりの確認ポイント、KPI設計までを順に解説します。

問い合わせ対応のAIエージェントとは何ですか？

問い合わせ対応のAIエージェントとは、生成AIを中心に、社内ナレッジ、業務システム、認証機能、有人窓口をつなぎ、問い合わせの受付から解決または引き継ぎまでを支援するソフトウェアです。従来のチャットボットが決められた選択肢やFAQを返すものだとすれば、AIエージェントは質問の意図を理解し、必要な情報を検索し、許可された範囲で次の処理まで進められます。

基本機能は、顧客接点の自動化、オペレーター支援、後処理の自動化、品質評価の自動化の4つです。顧客接点ではWebチャットやメール、音声ボットが質問を受け、営業時間外も一次対応できます。オペレーター支援では、通話中に関連マニュアルを提示したり、次に確認すべき項目を提案したりします。後処理では通話の文字起こし、要約、CRMへの記録を自動化し、品質評価では応対ルールへの適合や解決状況を分析します。

一度にすべてを自動化する必要はありません。例えば、最初はオペレーターの検索支援と要約から始め、次に低リスクなFAQの自動回答へ広げる方法があります。AIに任せる業務、人が確認する業務、必ず人へ渡す業務を最初に分けることが、問い合わせ対応の品質を守る基本です。

従来型チャットボットは、登録済みの質問と回答の組み合わせや、シナリオの分岐を正確に返すことが得意です。IVRも「1番は注文、2番は解約」のような定型的な振り分けに向いています。一方、AIエージェントは表現が異なる質問をまとめ、複数の文書を検索し、会話の文脈に応じて回答を変えられます。

ただし、自由度が高い分、根拠のない回答や誤った処理を防ぐ仕組みが必要です。AIエージェントを「何でも答える窓口」と考えるのではなく、「許可された情報源を参照し、決められた権限内で行動し、判断が必要なときは人へ渡す窓口」と定義すると、要件が具体化します。

導入効果を裏付ける事例と数値

導入効果は「何％自動化できたか」だけで判断しないことが重要です。問い合わせ対応では、平均処理時間、一次解決率、応答待ち時間、顧客満足度、オペレーターの後処理時間を組み合わせて評価します。公開事例にも大きな成果が見られますが、対象業務や測定条件が異なるため、自社のベースラインと比較して判断する必要があります。

富士通のSalesforceサポートデスクでは、Agentforceのパイロット検証を経て、月間問い合わせ数の約15％をAIエージェントが対応できる体制を目指しています（出典: Salesforce「富士通のSalesforceサポートデスク対応にAgentforceを採用」、2025年）。ここで注目したいのは、AIだけで窓口を置き換えるのではなく、人とAIのハイブリッドな労働力として設計している点です。

自社で同様の成果を目指す場合は、いきなり15％という数字を目標にするのではなく、問い合わせ分類ごとに自動化可能な割合を測ります。製品仕様の確認、営業時間、配送状況のような定型テーマは自動化しやすい一方、契約変更、返金、クレームなどは本人確認や承認が必要です。問い合わせの分類精度と有人切り替え率を併せて測ることで、数字の意味を説明できます。

富士通の2025年調査では、15カ国の経営幹部800人を対象に、約8割の企業がその年のAI投資を強化すると回答しています。一方で、生成AIを業務に組み込んだ本番運用へ移行している企業は5％にとどまると紹介されています（出典: 富士通「2025年度 富士通CxO調査レポート」、2025年）。投資意欲が高い一方、業務設計や運用に移す難しさがあることを示す数字です。

したがって、ROIは人件費削減だけでなく、放棄呼の減少、応答時間の短縮、教育期間の短縮、対応品質のばらつき低減、ナレッジ更新の迅速化まで含めて算出します。自動化で生まれた余力を人員削減だけに使うと、難しい案件を担う人材や教育の時間が失われます。単純な問い合わせをAIに移し、人は共感や複雑な課題解決に集中する設計が、長期的な効果につながります。

回答精度を支えるRAG構築の実務

RAGは、質問に関連する社内文書を検索し、その内容を生成AIに渡して回答させる構成です。モデルの記憶だけに依存しないため、製品仕様や社内ルールのように更新される情報を扱いやすくなります。ただし、RAGを導入しただけで正答率が上がるわけではありません。文書の形式、検索条件、回答プロンプト、評価データを継続的に改善することが必要です。

最初にFAQ、マニュアル、約款、商品仕様、過去の対応記録を集め、最新版、適用範囲、責任部署、改訂日を付与します。「解約」「キャンセル」「契約解除」のような同義語、「ログインできない」「サインインできない」のような表記ゆれを辞書にまとめると、検索漏れを減らせます。古い文書や廃止済みのキャンペーン資料を混ぜたままにすると、検索結果の品質が下がるため、公開・非公開の管理も必要です。

ExcelやPDFをそのまま格納するのではなく、見出し、質問、回答、条件、例外、更新日が分かるプレーンテキストやMarkdownへ変換します。表のセルだけを分割すると条件と回答の関係が失われるため、表の意味を文章に直してからチャンク分割します。ナレッジを週次で更新し、問い合わせログから不足するFAQを追加する運用にすると、公開情報の変化にも追随できます。

精度が低いときは、モデルを大きくする前に検索部分を確認します。第一に同義語辞書を追加し、第二に取得する文書数を調整し、第三にセマンティックランカーなどの再ランキングを試します。そのうえで、チャンクが短すぎて条件が欠けていないか、長すぎて別テーマが混ざっていないかを確認します。埋め込みモデルを更新する場合も、既存の評価データで改善を比較してから切り替えます。

回答プロンプトには、「根拠文書にない内容は推測しない」「対象商品の条件を明記する」「不明な場合は有人窓口へ案内する」といったルールを入れます。RagasはRAGの検索と生成を自動評価する研究フレームワークとして公開されており、回答の正確性や文脈との関連性を継続的に測る考え方の参考になります（出典: Ragas「Automated Evaluation of Retrieval Augmented Generation」、2023年）。

評価用には、実際の問い合わせから匿名化した質問、正解、許容される回答、有人へ渡す条件を用意します。LLM-as-a-Judgeで回答が根拠文書に沿っているかを判定し、最終的には人がサンプルを確認します。評価結果をダッシュボードに出し、質問分類別の正答率、根拠提示率、エスカレーション漏れを追跡すると、改善箇所が見つけやすくなります。

評価はリリース前の一度だけでは不十分です。ナレッジを更新した週、プロンプトを変えた日、モデルを切り替えた日には、同じ評価セットで回帰テストを行います。KPIを自動化率だけにすると、回答数は増えても再問い合わせやクレームが増える可能性があります。正答率と顧客体験を同時に見ることが、運用品質を守ります。

人とAIの協働設計とエスカレーションルール

問い合わせ対応では、100％自動化よりも、AIが一次対応し、人が判断や共感を担うハイブリッド運用が現実的です。有人切り替えの条件を曖昧にすると、AIが会話を引き延ばしたり、担当者が引き継いだ後に同じ質問を繰り返したりします。切り替え条件と引き継ぎ情報を、業務要件として明文化します。

本人確認が必要な契約情報、返金、住所変更、決済情報の照会は、認証が完了するまでAIが答えない設計にします。怒りや不安が強い発話、差別的な発言、事故や法的責任に関わる相談は、クレーム・高感情案件として優先的に人へ渡します。同じ質問を一定回数聞き返した場合や、信頼度がしきい値を下回った場合も、AIが無理に答えず切り替えます。

引き継ぎ時には、顧客の質問、認証状況、参照した文書、AIの回答、未解決の点をCRMへ渡します。担当者が会話履歴を読み直さなくてもよい状態にすると、引き継ぎ後のAHTを短縮できます。自動処理は、本人確認の結果や権限をAPIで受け取り、画面に表示するだけにとどめるなど、最小権限で実装します。

AI導入の目的を人員削減だけに置くと、難しい問い合わせが人に集中し、現場の負荷が上がる可能性があります。AIが定型質問や検索を担うことで、人は謝罪、共感、複雑な調整に時間を使えるようにすることが重要です。通話中のマニュアル提示、要約、応対後の記録支援も、顧客向け自動応答と同じくらい大きな効果があります。

カスハラ対策では、怒鳴り声をリアルタイムに穏やかな音声へ変換する技術や、危険な発話を検知して管理者へ通知する仕組みも検討できます。導入前に現場へ目的と限界を説明し、AIの判定を人事評価に直結させないルールを設けると、利用への抵抗を下げられます。

問い合わせ対応AIエージェントの費用相場とコストの内訳

問い合わせ対応AIエージェントの費用は、FAQ検索だけか、CRM・PBX・決済システムまで連携するかで大きく変わります。2026年時点の実務的な予算目安として、既存SaaSを設定して始める場合は初期100万〜500万円程度、RAGと管理画面を含む小規模な個別開発は500万〜1,500万円程度、音声・認証・複数システム連携を含む本格構築は1,500万〜3,000万円以上を想定します。これは市場統計ではなく、機能と工数から積み上げた概算です。

初期費用には、業務整理と要件定義、会話設計、ナレッジの整備、RAG構築、プロンプト設計、管理画面、CRMやチケット管理とのAPI連携、認証・権限設計、テスト、教育、リリース支援が含まれます。FAQの件数だけでなく、文書の状態、問い合わせ分類、例外処理、既存システムのAPI仕様が工数を左右します。

特に音声対応では、音声認識、音声合成、電話基盤、録音、リアルタイム処理の設計が加わります。発話から回答までのレイテンシが長いと、顧客が話を重ねたり電話を切ったりするため、平均値だけでなく、混雑時の応答時間と再生開始までの時間を受け入れ基準に含めます。

ランニングコストは、AIサービスの月額利用料だけではありません。LLMの入力・出力トークン従量課金、埋め込み生成、ベクトルデータベース、ログ保管、監視、バックアップ、音声認識・音声合成、電話回線、有人対応のオペレーション費を分けて見積もります。LLMの料金はモデルや処理量で変わるため、公式料金表をもとに、1件あたりの平均入力トークン、出力トークン、月間件数から試算します（出典: OpenAI API Pricing、2026年参照）。

例えば、月1万件のチャットで1件あたりの入力・出力を計測し、通常モデルと高精度モデルを使い分けると、品質と費用のバランスを比較できます。検索だけで済む質問は軽量モデル、契約条件の説明や要約は高精度モデルに振り分ける設計も有効です。月額は小規模なSaaSで数万円から数十万円、個別の監視・改善・有人支援まで含めると月額数十万〜数百万円になることがあります。

ROIを計算するときは、月間問い合わせ数に1件あたりの対応時間と人件費単価を掛け、AIで削減できる時間を見積もります。そこからAIの月額費用、システム保守費、ナレッジ更新費を差し引きます。さらに、放棄呼の減少による機会損失の回収、教育期間の短縮、再問い合わせの減少も別の効果として整理します。

投資回収期間は、初期費用を月次の純効果で割って算出します。ただし、自動化率を上げるために回答を甘くすると、CSATやFCRが下がり、再問い合わせが増えます。初期のPoCでは、金額効果を確定させるより、どの問い合わせ分類で品質を保ちながら時間を減らせるかを検証することが大切です。

見積もりを取る際のポイント

複数社から見積もりを取るときは、単価の安さではなく、何を作り、何を運用に含めるかを揃えて比較します。初期費用だけを見て判断すると、ナレッジの整備やテスト、リリース後の精度改善が別料金になり、総額が想定を超えることがあります。問い合わせ件数、チャネル、対象業務、連携先、セキュリティ条件を同じ資料で提示します。

要件には、月間・時間帯別の問い合わせ件数、繁忙期のピーク、チャットと電話の比率、平均会話ターン数、現在のAHT、FCR、CSAT、有人切り替え率を記載します。対象業務は「注文状況」「解約」「返金」のように分類し、回答だけか、検索・認証・更新処理まで行うかを明確にします。対応できない質問、必ず人へ渡す質問、営業時間外の扱いも決めます。

セキュリティ要件では、個人情報やクレジットカード番号が入力された場合の自動マスキング、ログの暗号化、保存期間、アクセス権限、学習利用の可否、データの保管場所を確認します。音声では録音データと文字起こしデータを分けて管理し、本人確認情報を要約ログに残さない設計にします。

CRMやチケット管理と連携する場合は、問い合わせ登録、顧客情報参照、ステータス更新、担当者への通知をAPI単位で定義します。AIに更新権限を与える場合は、対象項目と実行条件を限定し、すべての操作を監査ログへ残します。古いPBXや独自CRMの場合は、APIがない前提で中継サーバーやRPAを使う案も比較します。

外部LLM、音声認識、ベクトルDBなどの障害時には、別モデルへ切り替える、シナリオ型ボットへフォールバックする、全件を有人窓口へルーティングする、といった段階を決めます。切り替え後も顧客へ同じ質問を繰り返させないため、会話履歴を共通形式で保持します。見積書には、障害対応、バックアップ、復旧目標時間、切り替え訓練を含むかを記載してもらいます。

発注先を選ぶときは、LLMの知識だけでなく、問い合わせ業務、CRM、音声基盤、セキュリティ、運用改善を理解しているかを確認します。PoCの成果物がデモ画面だけでなく、評価データ、エスカレーション表、ナレッジ更新手順、運用ダッシュボードまで含むかも重要です。担当者が変わっても改善を続けられるよう、プロンプト、検索設定、評価方法の引き継ぎ条件を契約に含めます。

比較では、SaaSの設定、既存製品への追加開発、個別のスクラッチ開発を同じ条件で並べます。SaaSは早く始めやすく、標準機能の範囲では費用を抑えやすい一方、独自の認証や業務処理に制約が出ることがあります。スクラッチは業務に合わせやすい一方、モデル変更、脆弱性対応、監視、保守を自社または開発会社が担うため、5年程度の総保有コストで比較します。

失敗しない開発・構築の進め方とKPI設計

開発は、業務整理、PoC、スモールスタート、対象拡大、継続改善の順に進めます。最初から全チャネルや全商品を対象にせず、問い合わせ件数が多く、回答根拠が整い、誤答の影響を限定しやすい領域を選びます。PoCの目的はAIを動かすことではなく、品質・コスト・現場受容性を本番前に確かめることです。

PoCでは、過去の問い合わせから匿名化した代表データを抽出し、正解と有人切り替え条件を付けます。件数は業務のばらつきによって変わりますが、100〜300件程度を一つの検証単位にすると、定型質問だけでなく例外も確認しやすくなります。評価結果は、回答正確性、根拠提示、誤答の重大度、切り替えの適切性、応答時間、1件あたりの推定費用に分けて記録します。

本番では、対象チャネルを一つに限定し、AI回答の横に「人へ相談する」導線を置きます。週次でログをレビューし、未回答の質問をFAQへ追加し、誤答を回帰テストへ戻します。自動化率が目標に届かなくても、オペレーターの検索時間や後処理時間が減っていれば、次の投資判断に使える成果です。

効率化指標には、自動化率、有人切り替え率、平均処理時間、後処理時間、応答開始時間、呼量削減率を置きます。CX指標には、一次解決率、再問い合わせ率、CSAT、放棄率、クレーム率を置きます。品質指標には、根拠文書の提示率、誤答率、個人情報マスキング漏れ、ルール違反率を置き、どれか一つが悪化したら改善を止められるようにします。

例えば自動化率が上がったのにFCRが下がった場合、AIが回答を返していても顧客の目的を解決できていない可能性があります。逆にAIの自動回答率が低くても、検索支援によりAHTが短縮し、CSATが維持されているなら、オペレーター支援として成功しています。指標を週次で確認し、ナレッジ更新、プロンプト変更、有人ルール変更の効果を分けて検証します。

本番運用の責任者を決め、ナレッジの改訂、評価データの追加、モデルやAPIの変更確認、アクセス権の棚卸しを定例化します。新商品や制度変更があったときは、公開前にAIへ登録し、旧文書との矛盾を確認します。更新履歴と承認者を残すと、回答の根拠を追跡できます。

障害訓練では、LLM停止、検索基盤停止、CRM連携停止、音声認識遅延、個人情報検知の誤作動を想定します。シナリオ型の固定回答や有人窓口へ切り替え、顧客への案内文を確認します。AIエージェントは導入して終わりではなく、業務・ナレッジ・モデル・コストの変化を監視しながら育てる業務基盤です。

よくある質問（FAQ）

問い合わせ対応のAIエージェントを検討するときに、特に多い質問へ回答します。費用、誤回答、既存システムとの連携について、導入前に確認すべき考え方を整理します。

既存SaaSの設定だけなら初期100万〜500万円程度、RAGや管理画面を含む個別開発なら500万〜1,500万円程度、音声・認証・複数システム連携まで含めると1,500万〜3,000万円以上が一つの目安です。ただし、問い合わせ量、ナレッジの状態、既存システムのAPI、セキュリティ要件によって変わるため、相場だけでなく前提条件を揃えて見積もります。

完全にゼロにはできませんが、許可したナレッジだけを検索するRAG、根拠がない場合に回答しないプロンプト、信頼度に応じた有人切り替え、評価データによる回帰テストでリスクを下げられます。契約、返金、本人確認など影響が大きい処理は、AIの回答だけで完了させず、人の承認や業務システム側の検証を必須にします。

APIが提供されていれば、顧客情報参照、問い合わせ登録、担当者への通知などを連携できます。APIがない場合は、中継サーバー、ファイル連携、RPAなどを比較しますが、認証情報や障害時の再送を含めて設計する必要があります。まずはCRMを更新せず、問い合わせ履歴を参照して回答候補を提示するところから始めると、既存システムへの影響を抑えながら検証できます。

まとめ｜問い合わせ対応AIエージェントは小さく始めて運用で育てます

問い合わせ対応のAIエージェントは、チャットや電話を自動化するだけの製品ではなく、ナレッジ、認証、CRM、有人対応、品質評価をつなぐ業務基盤です。成功のポイントは、低リスクの問い合わせからPoCを始め、RAGの精度を継続的に改善し、AIと人の役割をエスカレーションルールで明確にすることです。

費用は初期開発だけでなく、LLMのトークン課金、ベクトルDB、音声API、監視、ナレッジ更新まで含めて見積もります。自動化率と同時にAHT、FCR、CSAT、誤答率、有人切り替え率を追い、顧客体験と現場の心理的安全性を守りながら対象範囲を広げます。AIに任せる余力は人員削減だけでなく、複雑な相談や改善活動へ再配分することが、長く成果を出す導入方針です。

最後に、対象とする問い合わせ分類、参照する最新ナレッジ、有人へ切り替える条件、個人情報のマスキング方法、CRMやPBXとの連携範囲、LLMや音声APIの障害時の代替手段、PoCの評価指標、導入後の更新責任者を確認します。これらが決まっていれば、開発会社との初回相談でも見積条件と成功基準を具体的に伝えられます。

富士通Salesforceサポートデスクの事例は Salesforce「富士通のSalesforceサポートデスク対応にAgentforceを採用」、AI投資動向は 富士通「2025年度 富士通CxO調査レポート」、コンタクトセンターAIの課題と動向は NEDO「成果発表カタログ」を参照しています。RAG評価の考え方は Ragas論文、API従量課金の確認は OpenAI API Pricingを参照しています。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

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

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

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

執筆者プロフィール

張田谷凌央

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