AIカスタマーサポートについてよく示される「チケットの80%を解決する」「1件あたり$5を節約する」「30秒で返信する」といった数字は、一部の企業では現実ですが、ほかの企業では作り話です。その違いを生むのはモデルではなく、設計です。
2026年に適切に構築されたAIサポートエージェントなら、人だけで対応する場合と同等以上の顧客満足度を保ちながら、人の介入なしで受信チケットの60～75%を実際に解決できます。構築が不十分なエージェントは、ハルシネーションを含む苛立たしい回答を生成し、ソーシャルメディアで話題になります。モデルの選択よりアーキテクチャのほうが重要です。
この記事では、現実的な姿を紹介します。実際に機能するアーキテクチャ、良い回答を生むプロンプト、惨事を防ぐガードレール、そして今なお人が関与すべき部分を解説します。
サポートエージェントの4つの仕事
実用的なAIサポートエージェントは、次の4つを順番に行います。
- チケットを理解する。 顧客が実際に尋ねていることは何か。どのような感情を抱いているか。問題はどのカテゴリーに属するか。
- 適切な背景情報を検索する。 顧客のアカウント、これまでの対応履歴、関連ドキュメント、類似する解決済みチケットを調べます。
- 何をするか決める。 回答する、確認の質問をする、人に振り分ける、アカウントに対してアクションを実行する、のいずれかを決めます。
- 判断を実行する。 返信の送信、質問、エスカレーション、アカウント操作のいずれかを行い、監査のためにすべてを記録します。
失敗したサポートエージェントの大半は、仕事2（実際の顧客情報がない）または仕事3（明確な振り分けロジックがない）でつまずきます。モデル自体が問題になることはほとんどありません。
アーキテクチャ
おおまかな構成は次のとおりです。
受信チケット
↓
[選別エージェント：分類、優先順位付け、振り分け]
↓
[背景情報の収集：顧客データ、履歴、ナレッジベースのRAG]
↓
[推論エージェント：アクションを決定]
↓
[返信作成／アクション実行]
↓
[品質確認]
↓
[送信またはエスカレーション]
各ステップは、それぞれ異なる関心事を扱います。n8n、LangGraphやCrewAIのような専用エージェントフレームワーク、または一連のマイクロサービスとして構築できます。プラットフォームにかかわらず、アーキテクチャのパターンは同じです。
各ステップを順番に見ていきましょう。
ステップ1：選別
選別エージェントは、受信した未加工のチケットを受け取って分類します。
信頼性の高い選別用システムプロンプトは次のとおりです。
あなたは[Company]のカスタマーサポート選別エージェントです。受信した各チケットを次の3つの観点で分類してください。
1. CATEGORY：次のいずれか
- account_access（ログイン、パスワード、MFA、アカウントのロック）
- billing（請求、返金、プラン変更、請求書）
- product_question（操作方法、機能に関する質問、設定）
- bug_report（故障または想定外の動作）
- feature_request（当社にない機能の要望）
- complaint（具体的な技術的問題ではなく、不満を抱いている顧客）
- other
2. URGENCY："critical"（本番環境の停止、請求に関する異議）、"normal"、"low"（情報提供のみ）のいずれか。
3. EMOTIONAL_TONE："calm"、"frustrated"、"very_angry"のいずれか。率直に判断すること。
JSONを出力してください。カテゴリーに確信が持てない場合は、confidenceを0.7未満にしてください。
選別には、高速で安価なモデル（GPT-5の高速版またはClaude Haiku）を使用します。これはパターンマッチングなので、推論モデルは必要ありません。
選別の出力は、次の2つの判断に使われます。
- 緊急度が高いチケットや、非常に怒っている顧客のチケットは、エージェントが処理できる場合でも人に直接送ります。「AIが不満を抱く顧客に誤った回答をした」場合のブランドリスクが高すぎるためです。
- カテゴリーに応じて、後続処理で利用可能にするナレッジベースとツールを決めます。
ステップ2：背景情報の収集
ここで、エージェントの成否の大半が決まります。十分な背景情報がなければ、エージェントは推測するだけのLLMです。
取得すべき背景情報源は3つあります。
顧客データ。 この顧客は誰か。プラン、アカウントの利用期間、最近の活動、支払い状況、未解決の問題を調べます。通常はAPI呼び出しを通じて、CRMまたは製品データベースから取得します。
会話履歴。 この顧客は以前に問い合わせたことがあるか。何について問い合わせ、どのように解決したか。「昨日伝えたばかりなのに」という失敗を避けます。
ナレッジベース（RAG経由）。 ドキュメント、ヘルプセンターの記事、社内手順書を、チケットの内容に対するセマンティック検索で取得します。（RAGの基礎は別の記事で解説しています。）
信頼性の高い背景情報収集パターンは次のとおりです。
チケット[content]をもとに、背景情報を収集してください。
1. メールアドレスで顧客を検索する。見つかった場合は、plan、account_age_days、recent_actions（過去7日間）、open_ticketsを取得する。
2. 顧客のチケット履歴（過去90日間）を検索する。直近のチケットを最大5件、その解決内容とともに取得する。
3. 関連記事をナレッジベースで検索する。セマンティック類似度の上位3件を取得する。記事のタイトル、要約、URLを含める。
4. 類似する問題について、データベース内の解決済みチケットを検索する。上位2件を解決内容とともに取得する。
1つの背景情報オブジェクトにまとめる。
このステップには2～5秒かかりますが、エージェントが扱える情報を大幅に改善します。
ステップ3：推論エージェント
次に、エージェントが何をするか決めます。システムプロンプトは次のとおりです。
あなたは[Company]のカスタマーサポート担当者です。あなたの仕事は、顧客の問題を解決することです。
各チケットについて、次の処理を行ってください。
1. チケットと背景情報を注意深く読む。背景情報には、顧客のアカウント、当社との対応履歴、関連ドキュメントが含まれる。
2. 次のいずれかのアクションを決定する。
- RESOLVE：確信を持てる回答または解決策がある。返信案を作成する。
- CLARIFY：追加情報が必要。確認の質問案を作成する。
- ESCALATE：人による対応が必要。理由を説明する。
- ACT_AND_RESOLVE：利用可能なツールを使ってアカウントに対するアクション（返金、パスワードのリセット、プラン変更など）を実行してから、返信する。
3. 率直で、温かみがあり、有能な印象を与える口調を使う。顧客の言葉遣いに合わせる。決して見下した態度を取らない。謝罪は2回以上しない。「お待ちいただきありがとうございます」は決して使わない。
4. ドキュメントを引用するときは、該当する記事へリンクする。記憶から言い換えない。
5. 顧客が不満を抱いている場合は、そのことを簡潔かつ明確に受け止めてから、解決策へ進む。
6. 次の場合は必ずエスカレーションする。
- 顧客が人との会話を求めている。
- €100 / $100を超える金銭的な異議が関係している。
- 回答に確信がない（確信度が70%未満）。
- 顧客の口調が怒っており、問題が単純な1ステップの解決ではない。
- セキュリティまたはプライバシーに関する懸念がある。
- 当社チームの人物に対する苦情が関係している。
7. 出力は次のJSON形式にする。
{
"action": "<resolve|clarify|escalate|act_and_resolve>",
"confidence": <0.0-1.0>,
"reasoning": "<簡潔な説明>",
"response_draft": "<メール本文>",
"escalation_reason": "<該当する場合>",
"action_to_take": "<act_and_resolveの場合、具体的なアクションと引数>"
}
これがエージェントの中心です。Claude Sonnet 4.5やGPT-5などの高性能なモデルを使用してください。この判断の品質が、体験全体を形作るためです。
ステップ4：アクションの実行
RESOLVEとCLARIFYの場合、アクションは単純で、メールを送信します。
ESCALATEの場合は、エージェントの分析を添えて、人が対応するキュー（Zendesk、Intercom、社内ツール）へ振り分けます。これにより、人は状況を把握した状態で対応を始められます。
ACT_AND_RESOLVEの場合、エージェントはアカウントに対するアクションを実行します。これには慎重な対応が必要です。
- 許可するアクションのリスト。 エージェントに任意のツールを呼ばせてはいけません。「エージェントは€50までの返金、パスワードのリセット、同じプラン系列内でのサブスクリプション階層の変更、依頼に基づくサブスクリプションの解約を実行できる」のように明示します。
- 確認のしきい値。 高額なアクション（€50を超える返金、年間プランのアカウント解約）は、エージェントに確信がある場合でも人による確認を必須にします。
- ログ記録。 すべてのアクションを、エージェントの判断理由とともに記録します。監査証跡は、サポート品質と規制遵守の両方で重要です。
ステップ5：品質確認
送信前の最後のステップは、品質ゲートです。通常は別の安価なAI呼び出しを使って、作成された返信を確認します。
あなたは、AIが生成したカスタマーサポート返信の品質確認担当者です。
元のチケットと返信案をもとに、次の点を確認してください。
1. 返信は顧客の質問に実際に答えているか。
2. 提供された背景情報に基づいて正確か（創作された事実がないか）。
3. 口調は適切か（温かみがあり、率直で、見下した印象や過剰な謝罪がないか）。
4. リンク切れや誤ったリンクがないか。
5. 次の危険な兆候が含まれていないか。
- 提供できないものを約束している
- 当社に責任がないことを謝罪している
- 怒りや皮肉を感じさせる
- 社内用語を使っている
- 内部情報を開示している
出力：APPROVEまたはREVISE（具体的な修正案を添える）。
品質確認がAPPROVEを返した場合は、返信を送信します。REVISEの場合は、自動修正する（安価で高速なモデルで修正案を適用できます）か、人による確認のキューに入れます。
実際には、この品質ゲートにより、メインのエージェントが誤って生成した返信の5～10%を検出できます。コストをかける価値があります。
ナレッジベース：大半のエージェントが失敗する場所
エージェントの品質を最も大きく左右する要因は、ナレッジベースです。ヘルプセンターの情報が古い、矛盾している、または不完全であれば、エージェントは自信を持って誤答します。
実践的な原則を示します。
導入前に監査する。 よくあるチケットの上位100種類を順に確認し、それぞれについてナレッジベースに正しい回答があるか検証します。不足を補い、矛盾を解消し、古い記事を更新します。これは1週間ほどの作業ですが、最も大きな効果を得られる投資です。
検索しやすい構造にする。 記事は短くし、それぞれ1つの問題に焦点を当て、明確なタイトルを付けます。長大な記事は一部しか取得されず、不適切な回答につながります。
明示的な「してはいけないこと」のセクションを含める。 サポートチケットの多くは、顧客が行うべきでない操作について尋ねるものです。ナレッジベースの記事では、「Xをしようとしているなら、それを推奨しない理由と、代わりの方法」を明記する必要があります。
すべての記事に適用条件のタグを付ける。 「無料プランのみ」「EUの顧客のみ」「iOSアプリのみ」といったタグです。エージェントはこれを使って検索結果を絞り込みます。
四半期ごとに更新する。 大半の企業では、時間とともにナレッジベースが現状からずれていきます。四半期ごとにレビューを予定し、担当者が古いコンテンツを確認してフラグを付けるようにします。
重要なエスカレーションパターン
よくある失敗は、すべてをエスカレーションする（怠惰な）エージェント、または決してエスカレーションしない（自信過剰な）エージェントです。エスカレーションパターンを正しく設定してください。
必ずエスカレーションするもの：
- 人による対応を明示的に求めている
- しきい値を超える怒り（特にエージェントが一度不適切に応答した後）
- 実際の金銭に関する異議
- セキュリティまたはプライバシーに関する懸念
- 健康、安全、法律に関する影響
- 同じ問題について、同じ顧客から繰り返し届くチケット
- エージェントの確信度が70%未満のケース
エスカレーションしないもの（価値が低い）：
- ナレッジベースに明確な回答がある単純な質問
- アカウントの基本的な管理（パスワードのリセット、基本的なプロフィール変更）
- 状況の問い合わせ（「返金処理は完了しましたか？」）
- 機能要望（人によるサポートではなく、製品チームへ送る）
中間領域では、エージェントの判断が重要です。次の点を確認できる計測機能を構築してください。エージェントがエスカレーションできたのにしなかった全ケースのうち、顧客から再度問い合わせがあった割合はどれくらいか。エージェントがエスカレーションした全ケースのうち、人が簡単に解決できたものはいくつあったか。
70%という数字の根拠
一般的なSaaSのサポートキューでは、次のように分類できます。
- 20～30%は、ドキュメントに明確に記載された単純な質問です。AIはこれらを適切に処理できます。
- 30～40%は、中程度の複雑さで、エージェントが背景情報と判断を必要とする質問です。強力なナレッジベースと優れたツールがあれば、AIはこれらも適切に処理できます。
- 20～30%は人を必要とします。複雑なトラブルシューティング、感情的な状況、特殊なケース、ポリシー上の判断などです。
- 10～20%は、サポートではなく製品／エンジニアリング部門が対応すべきバグ報告または機能要望です。
AIが処理可能な割合を合計すると、50～70%は現実的です。70%以上を達成している企業は、ナレッジベースとエージェントのツール連携に多額の投資をしています。30%にとどまる企業には、通常、質の低いナレッジベースと汎用的なエージェントしかありません。
顧客が本当に求めているもの
各種調査では、一貫して次の結果が示されています。
- 迅速な解決が最優先です。
- 正確な回答が2番目です。
- 話を聞いてもらえたと感じることも重要ですが、最初の2つほどではありません。
- 人と話すことは、「自分の問題が解決すること」よりはるかに重要度が低くなります。
これはAIサポートにとって朗報です。速度と正確性は、まさにAIが得意とすることだからです。「人と話したい」という感情は、通常、AIが一度失敗した後にだけ生じます。AIによる最初の回答が適切なら、顧客はキューで待つよりAIを好みます。
顧客が心底嫌うのは、エスカレーションのないエージェントのループです。AIと話しても問題が解決せず、AIが試行を続け、人につないでもらえない状態です。これを避けるために、エスカレーションのトリガーを厳密に構築してください。
具体的なパターン
個別対応が重要です。 「Annaさん、Proプランをご利用で、2023年からお付き合いいただいていることを確認しました」は、「お客様、こんにちは」とはまったく異なる印象を与えます。背景情報を活用してください。
待ち時間に言及する。 顧客が返信を30分待ったなら、エージェントは最初の文でそのことに触れるべきです。何事もなかったかのように振る舞ってはいけません。
顧客の言葉を引用する。 「企業名に特殊文字を含むレコードで、インポートが失敗するとお知らせいただきました」と伝えます。エージェントが実際にチケットを読んだことを示せます。
次のステップで締めくくる。 「返金を処理しました。3～5営業日以内に反映されます」とします。「ほかに何かございましたらお知らせください」ではありません。
理由なく謝罪しない。 何が起きたか分かる前に「ご不便をおかけして大変申し訳ございません」と言うと、不誠実に聞こえます。必要な場合に、具体的な内容について一度だけ謝罪してください。
実例
顧客から次のようなメッセージが届きます。
こんにちは。3日間ログインを試していますが、パスワードが間違っていると表示され続けます。2年間使ってきたパスワードなので、正しいはずです。ハッキングされたのではないかと思い始めています。
背景情報を収集した後の、良いエージェントの返信は次のようになります。
Annaさん、こんにちは。
3日間もログインできないのは長すぎます。アカウントを確認したところ、多要素認証が有効になっており、火曜日の朝以降、普段お使いのIPアドレスから10回のログイン失敗が記録されています。最も可能性が高い原因は、ハッキングではなくMFAコードの破損です。ほかの人がアカウントにアクセスした形跡はなく、パスワードも変更されていません。
最も早い解決方法は次のとおりです。
- anna@somecompany.fi宛てにパスワードリセット用リンクを送信しました（たった今送信しました）。
- リンクをクリックし、新しいパスワードを設定してください。
- ログインするとMFAの再設定を求められます。実際に使用する端末で設定してください。
ログイン後に何か不審な点（設定の変更、データの欠落）が見つかった場合は、このメールにご返信ください。セキュリティチームに引き継ぎ、詳しく調査します。
— AI Expertサポート
この返信は率直かつ具体的で、大げさに騒がず顧客の不安を受け止め、実際のアクションを行い、明確な次のステップとエスカレーション経路で締めくくっています。
要点
適切に設計すれば、70%の解決率は現実的です。モデルがボトルネックになることはほとんどありません。重要な4つの要素は次のとおりです。
- 整理され、構造化されたナレッジベース。
- 堅実な背景情報の収集（顧客データ、履歴、ナレッジベースの検索、類似する解決済みチケット）。
- 明確な判断基準とエスカレーションルールを備えた推論エージェント。
- ガードレール（許可リスト、品質確認、監査ログ）。
これらを適切に構築すれば、人が処理する件数を減らしながら、サポート品質を向上できます。構築が不十分なら、顧客を苛立たせる仕組みを生み出します。
2026年の大半のチームは、サポートAIを不用意に導入して悪い結果を招くか、導入を拒んで生産性向上の機会を逃すかのどちらかです。正しい道はその中間にあります。慎重に導入し、測定し、改善してください。幸いなことに、現在では設計パターンが十分に理解され、失敗パターンも回避できるほど詳しく記録されています。
