カスタマーサポートのAIエージェント開発/構築の進め方/やり方/流れや方法/手法/工程/手順

カスタマーサポートAIエージェントの開発は、対象業務と判断ルールを決め、データと連携を整えたうえで、小さく検証してから本番運用へ広げます。対象業務を絞った検証から始めるため、安全性と効果を確かめながら進められます。

カスタマーサポートAIエージェントの定義

カスタマーサポートAIエージェントを中心に、一次回答、照会と受付、記録と分類、オペレーター支援を配置した図。
問い合わせ対応からオペレーター支援まで、活用先が広がります。

カスタマーサポートAIエージェントは、顧客の相談を理解し、社内ナレッジと顧客情報を参照して回答や処理を行います。文章生成のほか、分類や本人確認、注文照会も担います。返品受付やチケット作成、有人への引き継ぎも、その役割に含まれます。

従来のチャットボットとの違い

従来型との違いは、回答だけでなく外部システムの処理まで進める点にあります。回答方法、情報処理、実行範囲、人の承認の順に見ると、その違いがはっきりします。

  • 回答方法:従来型は、登録済みの選択肢やFAQに沿って回答する
  • 情報処理:AIエージェントは、自然文から目的を推定し、複数の情報源を検索する
  • 実行範囲:ルールの範囲内で外部システムを操作し、交換受付の情報を集める
  • 人の承認:返金、契約変更、個人情報開示、クレームの最終判断は人が確認する

たとえば「先週買った商品を色違いに交換したい」という相談では、購入履歴、交換条件、在庫を確認します。そのうえで、AIが実行する操作と、確認を求める操作、人へ渡す処理を事前に分けておきます。

CSで活用できる代表的な業務

CSの活用先は、定型的な問い合わせ対応からオペレーター支援まで幅広くあります。業務ごとにAIが担う範囲を分けると、4つの役割が見えてきます。

  • 一次回答:Webチャットやメールの問い合わせへの回答
  • 照会と受付:注文・配送状況やFAQを調べ、返品・予約変更を受け付ける
  • 記録と分類:問い合わせを分類し、通話やチャットを要約してCRMに登録する
  • オペレーター支援:会話中に関連FAQや社内手順を示し、対応後の記録を補助する

電話では、音声認識と音声合成を組み合わせることで、本人確認や予約変更の一部を自動化できます。

AIとの対話は、人に質問するより心理的なハードルが低い場合があります。日本ロレアルの担当者は、これまで問い合わせをしなかった顧客からも相談が集まり、「隠れたVOC」を得られる可能性について語っています。

エイチ・アイ・エスでは、若年層向けという先入観に反して、60代以上の女性の利用が多いと紹介されています。効果は、人員削減に加えて、顧客理解の深まりでも測ります。

導入事例から見るAIエージェントの効果

導入効果は、AIが受けた件数に加えて、解決率や再問い合わせ率、有人転送率で測ります。平均処理時間や顧客満足度、売上や予約への影響も、あわせて確認します。

自社と規模が違う事例でも、対象業務と改善したKPIを分けて考えれば、PoCの目標に応用できます。

Klarnaの大量処理と短時間解決

OpenAIの公式事例によると、KlarnaのAIアシスタントは稼働初月に230万件の会話を処理し、カスタマーサービスチャットの3分の2を占めました(出典: OpenAI「Klarna’s AI assistant does the work of 700 full-time agents」、2024年)。

これはフルタイム従業員700人分に相当し、解決時間も11分から2分未満へ短縮されたとされています。また、多言語対応や、返品・返金をシステムとつないだ点も参考になります。

DoorDashの転送削減と初回解決率

AWSの事例では、DoorDashがAmazon ConnectとAmazon Lexによる音声セルフサービスを導入しました。

同事例では、転送を49%削減し、初回解決率を12%向上させたと説明されています(出典: AWS「Building a Generative AI Contact Center Solution for DoorDash」、2026年確認)。さらに、年間300万ドルの運用コスト削減にもつながりました。

DoorDashの利用状況からは、音声処理の設計で考えるべき点が2つ見えてきます。

  • 利用場面:移動中の配達員からの電話が多い
  • 設計課題:応答遅延が体験に直結するため、精度とレイテンシを考慮する

国内事例の売上と顧客体験

国内事例では、問い合わせの削減に加えて、購入や集客につながった例もあります。

  • 大丸松坂屋百貨店:ZendeskとAmazon Connectの連携で電話問い合わせ率が76.8%から70.4%へ減少
  • 犬猫生活:ペット知識を学習したAIがフードを提案し、EC購入率が150%に
  • フージャースコーポレーション:LINE予約で導入4か月に100件超を集客

AIエージェントは、コスト削減だけでなく、購入提案や予約受付、VOC収集にも使えます。投資効果は、顧客接点の価値も含めて評価します。

カスタマーサポートAIエージェント開発の進め方

企画・要件定義、データ整備、アーキテクチャ設計、PoCとQA、本番移行と運用改善の順に進む開発工程図。
小さな検証を経て、安全性と効果を確かめながら本番へ進みます。

開発は、対象業務、データ、判断ルール、KPIを決めてから進めます。モデルやツールの選定は、その後に回すのが基本です。

工程は、企画・要件定義、データ整備、アーキテクチャ設計の順に進みます。そのあと、PoCとQAで小さく検証し、安全性と効果を確かめてから対象を広げ、本番移行と運用改善へ進みます。

企画と要件定義での対象業務とKPIの設定

企画段階では、対象業務と評価基準を分けて決めます。

  • 初期対象:問い合わせが多く、回答ルールが明確で損失を限定しやすい業務
  • 有人対応:重大クレーム、返金額決定、法的判断、本人確認不十分な照会
  • KPI:AI対応率だけでなく正答率、解決率、転送率、処理時間などを設定

初期対象には、配送状況、営業時間、パスワード再発行、予約変更があります。KPIには、再問い合わせ率、CSAT、後処理時間、コンバージョンも含めます。

PoCの合格基準には、正答率95%以上や危険な誤回答ゼロ、引き継ぎ時の再説明を不要にすることなどがあります。

SaaS・ローコード・スクラッチの使い分け

開発方式は、既存基盤との相性や必要な独自機能で選びます。SaaS型、ノーコード・ローコード型、スクラッチ・共同開発では、始めやすさや柔軟さ、費用の負担がそれぞれ異なります。

  • SaaS型:短期間で始めやすく、既存のサポート基盤にAIを追加しやすい
  • ノーコード・ローコード型:Difyなどを使うと、柔軟なPoCを作りやすい
  • スクラッチ・共同開発:業務に合わせやすい一方、初期費用と保守負担が大きい

SaaS型は、Zendeskなど既存のサポート基盤にAIを追加する方法です。チケット、ナレッジ、チャネル、分析をまとめやすい点が特徴です。独自ルールやレガシー連携には、制約が出る場合があります。

スクラッチや共同開発は、CRMやCTIに合わせられます。基幹システムや独自認証にも合わせやすい方法です。音声処理や複数エージェントを使う場合に向きます。監査ログや閉域環境を重視する企業にも適しています。

選ぶ際は、自社の技術力や既存APIを確かめ、将来の対象業務やセキュリティ要件も踏まえます。最初はSaaSやローコードで検証し、必要な部分だけ個別開発する方法もあります。

CRM・FAQ連携とRAGの設計

連携の設計では、ナレッジ検索、顧客情報の扱い、既存CRMとの接続を分けて検討します。応答速度も、あわせて考えます。

  • RAG(検索拡張生成):自社ナレッジを検索し、回答の根拠としてLLMへ渡す
  • 顧客情報:ログイン、権限、取得項目、保持期間を分けて扱い、他人の情報は除く
  • CRM・応答:接続方式や照会の待ち時間への対策を要件に含める

対象ナレッジには、FAQや製品仕様、約款があります。配送条件や過去の対応記録も含まれます。

APIのないCRMとつなぐ場合は、中間サーバーや夜間バッチを検討します。RPAや参照専用データマートも候補になります。

注文照会では、キャッシュ期限とタイムアウトを決めます。再試行や処理中の表示も決めておきます。

数秒の遅延でも不満につながるため、モデルの小型化や検索範囲の絞り込み、ストリーミング表示を検討します。

PDFやExcelマニュアルの構造化

LLMを呼び出す部分より、既存マニュアルの整備に時間がかかる場合があります。PDFやExcelでは、条件分岐や例外、担当部署が表やセル色で表されることがあります。適用期間や商品区分も、同じような形で表現される場合があります。

そのまま読み込むと、条件の順序や例外が失われ、誤回答につながります。そこで、構造化では次の作業を行います。

  • 文書分割:業務、質問、手順といった単位に分ける
  • メタデータ付与:見出し、製品、顧客、地域、適用開始・終了日、機密区分、参照URLの情報を持たせる
  • 更新管理:条件と結論を同じ単位にし、更新日・廃止日で古い手順を除外する

ポイント

判断に迷ったら、モデルやツールの選定より前に、対象業務、データ、判断ルール、KPIが決まっているかを確かめてください。安全性と効果を確認できた範囲から、対象を広げるのが基本です。

精度とセキュリティを担保する設計

情報保護と利用記録を中央に置き、情報管理、入力制御、利用環境、監査と本人確認で囲んだ図。
暗号化だけでなく、入力から監査までをまとめて設計します。

カスタマーサポートでは、流暢さよりも正確で安全な回答を優先します。評価は、モデルの一般的な性能に加えて、自社の問い合わせと運用ルールを使って行います。

回答できない質問には無理に答えず、担当者へ引き継ぐ判断も、品質の一部になります。

ゴールデンデータと自動評価によるリリース前の検証

QAでは、問い合わせ例をまとめたゴールデンデータを作り、回答品質を継続的に確かめます。

  • テストデータ:代表例、頻出例、難問、禁止事項、悪意ある入力を含める
  • 評価項目:回答の正しさや根拠、個人情報、不要な約束の有無
  • 自動評価:更新時に同じテストを実行し、別の品質低下を探す

各データには、正答と許容表現を付けます。根拠やエスカレーション条件も、あわせて記しておきます。

誤回答の重大度は、軽微な表現ミス、業務を止める誤案内、金銭・契約・個人情報に関わる重大な誤案内に分けます。重大な誤回答は、ゼロを目標にします。軽微な誤りも、本番後に増えていないかを追跡します。

対応率を上げるために安全基準を下げると、長期的には顧客離れにつながる可能性があります。

権限・ログ・閉域環境を含むセキュリティ設計

通信の暗号化だけでなく、情報管理や利用環境も含めて設計します。監査と本人確認も、同じ設計の中で扱います。

  • 情報管理:暗号化、学習利用しない契約、保存期間、権限、マスキング、監査ログ、多要素認証
  • 入力制御:プロンプトインジェクションに備え、個人・決済情報を絞り、権限を分ける
  • 利用環境:要件に応じて、VPCや閉域接続、国内リージョン、保存場所、GDPRへの対応を選ぶ
  • 監査と本人確認:回答、参照文書、API、承認者を記録し、生体情報の同意と代替策を検討

本人確認では、声紋認証などを補助として使えます。その場合の扱いは、法務・セキュリティ部門と検討します。

ポイント

AIの回答は、一般的な性能だけでなく、自社の問い合わせを使ったゴールデンデータで評価します。個人情報の扱いは、権限やログ、利用環境と一体で決めてください。

人とAIの役割分担の設計

導入の成否は、AIが答えられないときに、人へ自然に渡せるかでも決まります。そのため、AIと人の得意分野を分けて、Human in the Loopとして業務フローに組み込みます。

AIは一次回答と検索を担い、要約や分類も行います。人は共感や交渉を受け持ち、例外の判断や重大なクレーム対応も引き受けます。

エスカレーション条件と引き継ぐ情報の決め方

切り替えは、「AIがわからないとき」だけとは限りません。条件と判断材料を組み合わせて決めます。

  • 切り替え条件:顧客の希望、質問の反復、低信頼度、禁止領域、強い不安や怒り、返金・契約変更の承認
  • 判断材料:意図分類、信頼度、顧客属性、取引金額、感情、会話回数

引き継ぎ後に、顧客へ同じ説明を求めないようにします。そのため、会話履歴や顧客の意図を、確認済みの本人情報とあわせてオペレーターへ渡します。参照FAQも共有します。

AIの提案や未解決の論点、次に必要な処理も共有します。Microsoft Copilot Studioは、有人引き継ぎ時に会話履歴と関連変数を共有し、有人窓口で継続する方法を案内しています(出典: Microsoft Learn「Hand off to a live agent」、2026年確認)。

オペレーター画面とAIの回答根拠

オペレーター画面では、AIの回答の根拠を人が追えるよう、表示する情報と会話の伝え方を設計します。

  • 対応情報:会話履歴、参照ナレッジ、確信度、顧客の目的、推奨策、処理期限を表示
  • 根拠の確認:要約から原文へ戻れるようにし、手動修正も保存する
  • 会話のトーン:AIの伝え方、共感表現、引き継ぎ案内を会話例で検証

原文の確認は引き継ぎミスの防止につながり、手動修正は評価データやナレッジの改善に使えます。また、会話のトーンでは、謝罪の場面で定型文を繰り返すと、不快感を与えることがあります。

ポイント

AIが答えられない場面でも、人へ自然に引き継げるかを確かめながら役割を分けます。引き継ぎでは、会話履歴や確認済みの本人情報を渡し、同じ説明を繰り返させないようにします。

カスタマーサポートAIエージェントの費用相場

2026年時点の費用は、既存サービスを使うか、独自連携やUI開発を行うかで変わります。ここに示す目安は、チャネル1〜2種類、既存FAQの利用、PoCから本番移行までを想定したものです。

金額は、データ量やセキュリティ、音声対応によって上下し、拠点数や外部APIの状況でも変わります。この数字は予算計画の起点として使い、正式な価格は各社の見積もりで確かめます。

SaaS型の費用目安:初期50万〜300万円、月額数万〜数十万円

費用は、初期設定、月額利用、追加機能に分けて確認します。

  • 初期費用:設定、ナレッジ、権限、接続、簡単なシナリオ調整を含め50万〜300万円程度
  • 月額費用:数万円〜数十万円程度。ユーザー数や解決件数で課金される場合がある
  • 追加機能:音声・分析機能などが別料金になる場合がある

Zendeskの料金ページでは、AIエージェントを含むSuite Teamが、エージェント1人あたり月額55ドルからと掲載されています。これは年払いの場合の価格です(出典: Zendesk「Pricing」、2026年確認)。総額は、プランや利用量、導入支援費を合わせて確認します。

ローコード型の費用目安:初期300万〜1,200万円

初期費用には、AIワークフロー、RAG、認証を含みます。さらに、CRMやチケットシステムとのAPI連携を加えます。管理画面や評価環境も含めると、初期300万〜1,200万円程度が目安です。

PoCだけであれば、100万〜400万円程度に収まることもあります。一方で、本番運用に入ると、監視や障害対応が加わり、権限やデータ更新の費用も増えます。

クラウドやモデルAPI、ベクトル検索の費用に加えて、ログ保管や保守運用費も含めます。月額20万〜150万円程度として見込むと、予算の抜け漏れを減らせます。

スクラッチ型の費用:初期1,500万〜5,000万円以上となる場合

スクラッチ開発や大規模な共同開発では、初期費用が1,500万〜5,000万円以上になることがあります。費用は、開発範囲、見積もりの分け方、効果と投資判断の観点から整理して確かめます。

  • 開発範囲:複数チャネル、音声、複雑な本人確認、閉域環境、双方向連携、多言語、監査ログで工数が増える
  • 見積もり:企画、UI、データ整備、連携、評価、審査、教育、移行を分けて、初期費用と月次費用を比較する
  • 効果:人件費に加え、処理時間、夜間対応、再問い合わせ、売上・予約、VOC分析も評価する
  • 試算例:月1万件中2,000件を自動解決し、有人対応が1件500円なら削減効果は月100万円
  • 投資判断:SaaS、モデル、保守、ナレッジ更新費を差し引き、品質維持を条件に判断する

ポイント

費用は、既存サービスか独自連携かで大きく変わるため、まず方式を決めてから目安を見てください。見積もりは、開発費に運用費や利用料を加えて比べます。

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

見積もりは、モデル料金を見る前に、各社の前提をそろえることが先決です。対象業務やデータ整備、連携の範囲を同じ条件で提示してもらい、テストや運用の責任範囲も確かめます。

「問い合わせ対応」の範囲が回答のみか、注文変更や返金まで含むかで、費用は大きく変わります。

RFPに書く業務・データ・連携・評価条件

RFPで提示する条件は、業務の範囲と評価の基準を中心に整理します。残りの項目も、次の一覧のとおり分けて書きます。

  • 業務:件数、チャネル、言語、営業時間、頻出カテゴリ、解決率、処理時間、転送率
  • 利用ツール:CRM、FAQ、CTI、チケット管理システムの一覧にする
  • データと権限:参照する情報、実行・承認操作、人へ渡す条件。ログは匿名化し用途別に分ける
  • 評価と運用:正答率、重大誤回答、応答時間、可用性、監査ログ、保存場所、障害時の切り替え
  • 移行と成果物:PoC・本番条件、会話フロー、データ/API仕様、テスト、運用・更新手順

過去ログは、個人情報をマスキングしたうえで、評価用と学習・検索用に分けて提供します。PoCの完了条件と本番移行条件も分けて、検証範囲をはっきりさせます。

AIだけでなく業務設計と運用を支援できる会社の選び方

会社を比べる際は、提案力や実演を見たうえで、契約条件と運用支援も合わせて確かめます。

  • 業務理解:LLMに加え、サポート業務、連携、セキュリティ、UXを理解している
  • 回答デモ:匿名化ログを使い、正答、回答不能、誤情報、有人引き継ぎを確かめる
  • 導入実績:件数・削減額だけでなく、業務、期間、体制、改善方法を確かめる
  • 契約条件:障害、料金改定、データ・ログ、脆弱性、終了時の返却の扱い
  • 運用支援:ナレッジ更新、月次品質レビュー、四半期の範囲見直し、改善窓口を含める

商品や規約が変わったときは、ナレッジを更新し、回答を再評価します。

安すぎる見積もりの確認項目

金額だけでなく、対象範囲や成果物、日程の前提も比べます。なお、高額でも不要な開発は最適とは限らないため、必須・将来・対象外の範囲を分け、成果物と支払条件も確かめます。

  • 範囲:FAQ登録、マニュアル構造化、API連携、テスト、有人引き継ぎ、監視、更新が含まれるか
  • 要件定義:2〜6週間程度を見込んでいるか
  • 後続工程:データ整備・設計1〜2か月、PoC1〜3か月、本番開発・受入テスト2〜6か月程度を見込んでいるか
  • 納期の前提:長期化要因、次工程への持越し、品質基準、自社作業量

レガシーCRMや音声連携、閉域環境があると、期間が延びやすくなります。

よくある質問(FAQ)

導入の検討では、費用や期間、精度に加えて、人員への影響についても疑問が出やすくなります。そこで、検討段階で多い質問に順に答えます。

カスタマーサポートAIエージェントはどの業務から始めるべきですか?

問い合わせ量が多く、正解を定義しやすい業務から始めます。配送状況、営業時間、予約受付などがその例です。製品の基本仕様も、そうした業務に含まれます。

返金や重大なクレームは、AIの提案を人が承認する方式から始めると、安全性を確認しやすくなります。

AIエージェントの開発費用を抑える方法はありますか?

対象範囲を絞り、SaaSまたはローコードでPoCを行うと、初期投資を抑えられます。

既存FAQやCRMの標準連携を使い、効果が確認できた業務に限って個別開発を行います。テストや権限を省くと本番品質が下がり、監視やナレッジ更新も品質に響きます。そのため、削る対象は慎重に選びます。

AIエージェント導入でオペレーターは不要になりますか?

オペレーターが完全に不要になるとは限りません。AIが一次対応や検索を担い、要約や定型処理も任せると、人は複雑な相談や共感が必要な対応に集中できます。

人員計画は、必要人数だけでなく、対応範囲や後処理時間を含めて見直します。教育期間や顧客満足度も、判断の材料にします。

AIの誤回答を防ぐにはどうすればよいですか?

自社ナレッジに限定したRAGや根拠の表示、禁止事項のルール、信頼度に応じた有人引き継ぎを組み合わせます。

ゴールデンデータで継続的に評価し、商品や規約、FAQを更新した後も回帰テストを行います。重大な誤回答がないことを確かめます。

まとめ

開発では、モデル選定より先に対象業務と人とAIの役割を定めます。参照データや実行権限、KPIも定義しておきます。

マニュアルを構造化してCRMやFAQと連携し、ゴールデンデータでQAを行います。有人引き継ぎまで含めて小さく検証することが、成功の基本です。

導入前に確認するチェックポイント

導入前の確認項目は、業務と品質、データと権限、運用と費用の3つに分けて整理します。

  • 業務と品質:対象・対象外業務、正答率と解決率の定義、有人引き継ぎ条件
  • データと権限:参照ナレッジ、更新担当者、AIの操作権限、ログとアクセス権
  • 運用と費用:障害時の代替手段、初期・月額費用、PoCから本番への移行条件

見積もりは、開発費に加えて、データ整備やテスト、教育、監視を含めて比べます。ナレッジ更新、モデルやクラウドの利用料も対象に入れます。

問い合わせログからのPoC候補の決め方

PoC準備は、問い合わせログの分析から始めます。

  1. 過去3〜6か月の問い合わせを匿名化して分類し、件数、難しさ、業務影響、AI化のリスクを整理する
  2. 効果が見込めて安全に検証できる1〜2業務を選び、正答率、解決率、転送率、応答時間を定義する

AI導入を目的にするより、顧客とオペレーターの体験を改善する業務基盤として設計するほうが、長く使われる仕組みにつながります。

参考ソース: OpenAIのKlarna事例、AWSのDoorDash事例、Zendeskの2026年発表、Microsoft Learnの有人引き継ぎ仕様、Zendesk料金ページ(いずれも2026年8月確認)

会社紹介

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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