多言語カスタマーサポート Agent：Dify Agent によるツール連携・フォールバック・メモリ管理の実践設計

はじめに

グローバルに事業を展開する企業にとって、多言語でのカスタマーサポートは避けて通れない課題である。従来は言語ごとにサポートチームを編成するか、翻訳ツールを介して対応していたが、LLM の多言語処理能力の向上により、単一の AI Agent で複数言語のサポートを実現するアプローチが現実的になっている。

しかし、多言語カスタマーサポート Agent の設計で最も重要なのは「多言語に対応できるか」ではない。GPT-4o や Claude といったモデルは、プロンプトなしでも多言語の入出力を処理できる。真の設計課題は、ツール呼び出しチェーンの安定性、フォールバック戦略の明確さ、会話メモリの適切な管理の三点にある。

本稿では、Dify の Agent ノードを中心に、エンタープライズ品質の多言語カスタマーサポート Agent を構築するための設計パターンを解説する。

背景と課題

多言語カスタマーサポートの現状

Dify Agent ノードの主要機能

Dify の Agent ノードは、以下の設定項目をネイティブでサポートしている。

全体アーキテクチャ

flowchart TD
    A[ユーザー入力<br>任意の言語] --> B[Dify Agent ノード]
    B --> C{意図判定}
    C -->|FAQ| D[Knowledge Base 検索]
    C -->|注文照会| E[Tool: 注文検索API]
    C -->|配送状況| F[Tool: 物流追跡API]
    C -->|工単作成| G[Tool: チケット作成API]
    C -->|クレーム/感情的| H[Tool: 人間エスカレーション]
    C -->|不明| I[フォールバック: 確認質問]
    D --> J[回答生成<br>入力と同じ言語で]
    E --> J
    F --> J
    G --> J
    H --> K[人間オペレーターに転送]
    I --> J
    J --> L[ユーザーへ返答]

ツール設計の詳細

ツール一覧と定義

Agent の精度は、ツールの「説明文（description）」の品質に大きく左右される。抽象的な説明では LLM が適切なツールを選択できない。

Tool 1: 注文検索

name: search_order
description: |
  顧客の注文情報を検索します。
  以下の場合に使用してください：
  - 顧客が注文番号を提示して状況を確認したい場合
  - 顧客が「注文」「購入」「買った」等のキーワードを含む質問をした場合
  以下の場合は使用しないでください：
  - 注文番号が不明で、顧客が一般的な質問をしている場合
  - 返品・返金に関する質問の場合（create_ticket を使用）
parameters:
  order_id:
    type: string
    required: true
    description: 注文番号（例: ORD-20260412-001）

Tool 2: 物流追跡

name: track_shipment
description: |
  配送状況を追跡します。
  以下の場合に使用してください：
  - 顧客が「届かない」「配送」「いつ届く」等の配送関連の質問をした場合
  - 注文検索の結果、ステータスが「発送済み」の場合
parameters:
  tracking_number:
    type: string
    required: true
    description: 追跡番号

Tool 3: チケット作成

name: create_ticket
description: |
  カスタマーサポートチケットを作成します。
  以下の場合に使用してください：
  - 顧客が返品・返金を希望する場合
  - 商品の不具合を報告する場合
  - Agent では解決できない問題の場合
parameters:
  customer_id:
    type: string
    required: true
  issue_type:
    type: string
    enum: [return, refund, defect, complaint, other]
    required: true
  description:
    type: string
    required: true
    description: 問題の概要（日本語で記載）

Tool 4: FAQ 検索（Knowledge Base）

name: search_faq
description: |
  FAQ ナレッジベースを検索します。
  以下の場合に使用してください：
  - 顧客が製品の使い方、仕様、ポリシーに関する一般的な質問をした場合
  - 注文や配送に直接関係しない質問の場合

Tool 5: 人間エスカレーション

name: escalate_to_human
description: |
  人間のオペレーターにエスカレーションします。
  以下の場合に必ず使用してください：
  - 顧客が明らかに怒っている、または強い不満を表明している場合
  - 法的な言及（訴訟、消費者庁等）がある場合
  - 3回以上ツール呼び出しを試みても解決できない場合
  - 返金額が50,000円を超える場合
parameters:
  reason:
    type: string
    required: true
  priority:
    type: string
    enum: [normal, high, urgent]
    required: true
  conversation_summary:
    type: string
    required: true
    description: これまでの会話の要約

Agent Instruction（System Prompt）の設計

あなたは多言語カスタマーサポートの AI アシスタントです。

【言語ルール】
- ユーザーが使用した言語と同じ言語で回答してください
- 言語の切替が検出された場合は、新しい言語に合わせてください
- 製品名・ブランド名は原語のまま使用してください

【回答構造】
1. まず結論を述べる
2. 次に根拠や状況を説明する
3. 最後に次のアクションを提示する

【ツール呼び出しルール】
- ツールを呼び出す前に、必要なパラメータが揃っているか確認すること
- パラメータが不足している場合は、推測せずユーザーに確認すること
- 1つの質問に対してツール呼び出しは最大3回までとする
- ツール呼び出しが失敗した場合は、エラー内容をユーザーに伝え、
  代替手段を提示すること

【禁止事項】
- 注文のキャンセル・返金の自動実行（チケット作成まで）
- 個人情報（クレジットカード番号等）の取得要求
- 他社製品との比較における他社の誹謗
- 未確認の情報に基づく断定的な回答

【エスカレーション条件】
以下の場合は必ず escalate_to_human を呼び出すこと：
- 顧客の感情が強くネガティブ（怒り、失望、脅し等）
- 法的措置への言及
- 3回のツール呼び出しで解決できない場合
- 自分の回答に自信がない場合

フォールバック戦略の設計

3 層フォールバックモデル

フォールバックとは、Agent が最適な回答を返せない場合の退避戦略である。カスタマーサポートにおいては、「答えられないこと」よりも「誤った対応をすること」の方がはるかに深刻なため、フォールバック設計は最重要事項の一つである。

flowchart TD
    A[ユーザーの質問] --> B{ツール呼び出し<br>条件を満たす?}
    B -->|Yes| C[ツール呼び出し実行]
    B -->|No| D[第1層: Knowledge Base 検索]
    C --> E{成功?}
    E -->|Yes| F[回答生成]
    E -->|No| G[第2層: 確認質問]
    D --> H{該当情報あり?}
    H -->|Yes| F
    H -->|No| G
    G --> I{情報取得成功?}
    I -->|Yes| C
    I -->|No| J[第3層: 人間エスカレーション]

第 1 層: Knowledge Base フォールバック

ツール呼び出しの条件を満たさない場合（注文番号がない、配送情報がない等）、まず Knowledge Base を検索する。FAQ、製品仕様、ポリシー文書などの静的情報で回答できる場合は、ここで完結する。

第 2 層: 確認質問フォールバック

Knowledge Base でも回答が得られない場合、不足情報をユーザーに確認する。

確認質問の例:
- 「注文番号をお教えいただけますか？注文確認メールに記載されています。」
- 「お問い合わせの製品名をお聞かせください。」
- 「いつ頃ご注文されましたか？おおよその日付で構いません。」

重要なのは、不足情報を推測してツールを呼び出さないことである。誤った注文番号で検索すると、他人の情報を返してしまうリスクがある。

第 3 層: 人間エスカレーション

以下の条件に該当する場合は、即座に人間オペレーターにエスカレーションする。

会話メモリ管理

Memory Window の設計

Dify Agent ノードの Memory 設定では、保持する会話ターン数（Window Size）を制御できる。適切な Window Size の設定は、回答品質とコスト・レイテンシのバランスに直結する。

Window Size のトレードオフ

• 大きすぎる場合: トークンコスト増大、レイテンシ増加、無関係な過去情報による回答精度低下
• 小さすぎる場合: 「さっき言った件」が解決できない、同じ情報を再度要求してしまう

長い会話セッションでは、Window Size を超えた会話を要約テキストに変換してコンテキストに含める「要約メカニズム」の併用が有効である。

多言語対応の実装ポイント

言語検出と切替

LLM は入力言語を自動で検出し、同じ言語で回答する能力を持っている。ただし、以下の点に注意が必要である。

Knowledge Base の多言語対応

推奨は 単一 KB（日本語 + 英語）を multilingual Embedding モデルで検索 するアプローチである。multilingual-e5-large や bge-m3 などのモデルは、言語を跨いだ意味検索に対応している。

Agent Strategy の選択

Function Calling vs ReAct

カスタマーサポートの本番運用では、Function Calling を推奨する。ツール呼び出しの精度が高く、予測可能な動作が期待できる。

Maximum Iterations の設定

Agent がツール呼び出しを繰り返す最大回数を制限する。カスタマーサポートでは 3-5 回 を推奨する。

• 3 回未満: 複合的な問い合わせに対応できない
• 5 回超過: 無限ループのリスク、レイテンシの増大、顧客の待ち時間増加

運用モニタリング

監視すべき指標

導入ステップ

まとめ

多言語カスタマーサポート Agent の設計において、言語対応は LLM の基本能力で実現できるため、差別化要因にはならない。真に設計品質が問われるのは、以下の三点である。

1. ツール呼び出しチェーンの安定性: ツールの description を具体的に記述し、呼び出し条件を明確にする
2. フォールバック戦略の明確さ: Knowledge Base → 確認質問 → 人間エスカレーションの 3 層で設計する
3. 会話メモリの適切な管理: シナリオに応じた Window Size の設定と、要約メカニズムの併用

Dify の Agent ノードは、Function Calling / ReAct の選択、ツール定義、Memory 設定、Maximum Iterations をすべて GUI で設定でき、エンタープライズ品質のカスタマーサポート Agent を構築するための十分な基盤を提供している。