DiDi、Amazon Bedrock で多言語 QA システムを構築

DiDi は AWS と連携し、国際事業グループの顧客体験（CX）部門向けに Amazon Bedrock を活用したインテリジェントなコンタクトセンター品質保証（QA）システムを構築しました。このシステムはスペイン語とポルトガル語に対応し、ライドシェア、フードデリバリー、金融サービスの 3 つの事業ライン全体で QA 機能を運用しています。これまでブラックボックス化していたサードパーティ製ソリューションから、透明性の高い自社開発型の AI アーキテクチャへと移行したものです。

システムは「意図検証」「コンプライアンス評価」「顧客の声（VOC）分析」という 3 つのコアパイプラインで構成されています。DiDi の本番環境での検証では、意図検証の精度が 38% から 86% に向上し、コンプライアンススコアの精度は 90% を超えました。また、VOC 分析によって、従来数時間を要していた手作業による要約を数分に圧縮することに成功しています。

本稿では、DiDi 国際事業グループと AWS がどのようにして Amazon Bedrock 上で透明性の高い自社開発型のコンタクトセンター QA システムを構築し、ブラックボックス化されたサードパーティ製ソリューションから脱却したのかを解説します。また、このシステムを支える「意図検証」「コンプライアンス評価」「顧客の声（VOC）分析」という 3 つのコアパイプラインの詳細と、それぞれの設計思想についても説明します。

その過程で、各通話においてモデルが参照する情報を厳密に制御するという「文脈管理の精度向上」という一つの原則が、主要な成果を導いたこと、そして VOC トレンド分析によって手作業を数分から数時間に圧縮した仕組みについてもお伝えします。

DiDi 国際事業グループについて

DiDi International Business Group（IBG）は、DiDi Global の海外事業部門として、14 カ国・地域でライドシェア、フードデリバリー、金融サービスの 3 つの事業ラインを展開し、数千万人のユーザーにサービスを提供しています。CX 部門では、ライブチャットと電話チャネルを通じて毎月膨大な数のスペイン語およびポルトガル語の問い合わせを処理しており、サービスの質はユーザーの継続利用やブランドへの信頼に直結します。

課題

事業が拡大し QA（品質保証）基準も急速に進化する中、既存のサードパーティ製 QA ソリューションでは透明性と柔軟性が不足していました。DiDi の IBG CX チームは、以下の 4 つの中核的な課題に直面しています。

• QA の判断根拠が追跡できない。QA の判断結果はコンプライアンス監査の結果やサービス改善の優先順位を決定づけます。しかし既存システムは推論プロセスが見えないブラックボックスとして機能しており、処理能力とコストの制約から手動での抜き取り検査しか実施できませんでした。どちらのアプローチも、過去の判断に対する監査証跡を提供するものではありませんでした。

• サービスシナリオの組み合わせが複雑化。カスタマーサポート業務は複数の言語と事業ラインにまたがり、それぞれの組み合わせごとに独自のコンプライアンス基準や QA ルールが適用されています。組み合わせが増えるにつれてルール維持コストが高騰し、一貫性を担保することが困難になっています。

QA 基準の変更に対する対応の遅さ。ビジネスの進化に伴い QA 基準は頻繁に変わります。各変更には QA アナリストの再教育や実行ガイドラインの更新が必要となり、新旧の基準が共存する移行期間が生じて一貫性のない結果を招きます。

傾向の検出における受動的な姿勢。特定の事象タイプが短時間で急増した場合、運用チームはチケットを一つずつ読み込み手動で集計することでしか検知できません。早期の傾向特定とタイムリーな介入はほぼ不可能です。

これらの課題に対処するため、DiDi の IBG CX チームは AWS と連携し、Amazon Bedrock 上で独自の中核となる QA システムを構築しました。同チームが Amazon Bedrock を選定したのには、3 つの理由があります。

第一に、単一の API を通じて多様な基盤モデルへのアクセスが可能で、モデル非依存である点です。これにより、各パイプラインに最適なモデルを選択でき、アーキテクチャを再構築する必要がありません。

第二に、組み込まれたガバナンスとセキュリティ機能により、機密性の高いカスタマーサービスデータを DiDi のネットワーク境界内に保持できます。また、以前のサードパーティ製ソリューションでは不足していた透明性と管理も実現します。具体的には、AWS PrivateLink を活用した Amazon VPC エンドポイントによるプライベート接続、転送中および保存時の暗号化、そして AWS Identity and Access Management (IAM) によるきめ細かいアクセス制御などが含まれます。

第三に、Amazon Bedrock Guardrails が提供するコンテンツフィルタリングや機密情報のマスキングなど、構成可能なセーフティ機能があります。これにより、責任ある AI の実践に沿った QA システム構築の基盤が整います。

ソリューション概要

本システムは Amazon Bedrock 上で3つの専門パイプラインを実装しており、それぞれが異なる QA の次元に焦点を当てています。各判断には必ず完全な推論チェーンが付随します。

意図（Intent）パイプラインでは、オペレーターが割り当てた顧客の問い合わせ理由が適切かどうかを検証します。評価（Evaluation）パイプラインはサービスコンプライアンスの監査とビジネスインサイトの抽出を担当します。また VOC（Voice of Customer）パイプラインでは、大量の類似チケットを集約し、システム全体の傾向を浮き彫りにします。

以下の図は、二重チャネルからのデータ取り込みから前処理を経て、Amazon Bedrock を駆使した3つのパイプラインへと至るエンドツーエンドのシステムアーキテクチャを示しています。

Figure 1: System architecture. Dual-channel data flows through preprocessing into three parallel pipelines powered by Amazon Bedrock, producing structured outputs with full reasoning

前処理層では、ライブチャットと通話データを取得し、共通スキーマに正規化した上で3つの並列パイプラインへ展開します。全体のワークフローは以下の通りです。

• データ取り込みと前処理。 ライブチャットや通話の文字起こし（音声認識を利用）は、チャネル固有の前処理を経て、下流システムで利用可能な統一された会話形式に変換されます。

意図パイプラインでは、オペレーターが割り当てた連絡理由（CR、サブ CR）の正確性を検証し、誤りがある場合は代替分類を推奨します。また、「その他」としてラベル付けされた既存の分類体系に属さないチケットを独立して分析し、分類システムのカバレッジギャップを特定します。

評価パイプラインでは、1 回の大規模言語モデル（LLM）呼び出しで各チケットに対して複数項目のコンプライアンススコアリングとビジネスインサイト（BI）分析を同時に行います。

VOC パイプラインは運用チームからの要請に応じて起動し、特定の時間枠内で類似したチケットのバッチを集約分析して構造化された分析レポートを生成します。

出力では、各パイプラインから得られた構造化結果を提供し、運用チームがクエリや可視化に活用できるようにしています。

システムが大量の実際の顧客会話に対してスコアリングと分類を行うため、責任ある AI の制御機能が組み込まれています。Amazon Bedrock Guardrails を使用して、個人を特定できる情報（PII）などの機密情報をモデルに到達させる前にマスキングし、文脈に基づいた妥当性チェックを適用することで、根拠のない回答を検知して誤った判断を防いでいます。

Guardrails 以外にも、システムの出力を最終的な決定として扱いません。ルールで決定的な基準については、プログラムによる事後検証レイヤーが、生データである会話に対してモデルの判断を再確認します。例えば、報告されたスペルミスの有無は、エージェント自身のメッセージのみを対象に検証され、合格・不合格の判定はモデルが数えた値ではなく、検証済みのカウントに基づいて行われます。

エージェントの応答待ち時間などの計算可能な事実は、コード内で決定論的に導出されてプロンプトに埋め込まれ、モデルに推測させることはありません。すべてのスコアには人間のレビューのために完全な推論チェーンが付属しており、これらの制御機能により、本番環境におけるコンプライアンス判断の監査可能性と信頼性が保たれています。

意図パイプライン：正確な分類のための情報分離

チケット対応中、オペレーターは連絡理由のラベルを付与します。DiDi の連絡理由分類体系（CR Tree）は、広範なカテゴリから始まり、多段階にわたってより細分化されたサブカテゴリへと枝分かれしています。階層が深くなるほど区別は微妙になるため、大規模運用では誤ったラベル付けが避けられません。そのため、システムはこれらのラベルが正確かどうかを自動的に検証し、誤りがある場合は代替案を推奨する必要があります。また、CR Tree 自体も逆方向に監査し、カバー漏れを特定して新しいラベルの提案を行い、QA（品質保証）と分類体系の維持管理の間のループを閉じます。

最も直接的なアプローチは、完全な CR Tree と会話履歴を一度の呼び出しで LLM に渡すことでした。しかしこの方法では精度が期待をはるかに下回る結果となりました。根本原因を突き止めたところ、LLM が選択肢のリスト全体を目にすると、自動的に一つずつ比較し始めてしまうことが分かりました。元のラベルが完全に妥当な場合でも、「わずかにより精密な」代替案を見つけようとする行為が、現在のラベルは誤りだと判断させるトリガーとなってしまうのです。プロンプトの調整を何度繰り返してもこの行動は変わりませんでした。問題はプロンプトの文言ではなく、コンテキスト管理にありました。

チームはこのパイプラインを二つの観点から再設計しました：

タスクの分離

接触理由の確認と「その他」ラベルの分析は本質的に異なるタスクであるため、独立したパスに分割されます。「その他」として分類されたチケットには専用の三段階分析が適用されます。まず、システムは兄弟カテゴリの中により適切なラベルが存在するかを確認します。該当するものが見つからない場合は、完全な CR ツリー（Contact Reason Tree）を検索します。それでも一致しない場合、これはカバレッジの欠落を示すため、システムは新しいラベルの追加を提案します。

情報の分離

標準的な接触理由については、フローがさらに確認フェーズと分類フェーズに分割されます。確認フェーズでは、LLM は現在の接触理由ラベルのみを受け取り、会話内容のみに基づいてそのラベルが妥当かどうかを判断します。検証の結果、不備があると判定された場合にのみシステムは分類フェーズへ移行します。この時点で LLM は完全な CR ツリーと確認フェーズでの推論結果を受け取り、信頼スコアと根拠とともに代替の分類を提案します。

この二段階設計により、DiDi の本番環境における検証で、意図の確認精度が 38% から 86% に向上しました。

評価パイプライン：多言語・複数事業部門対応のための動的アセンブリ

評価パイプラインは、1 回の処理で複数のコンプライアンス項目のスコアリングと、各チケットごとのビジネスインサイトの抽出を同時に行います。言語や事業ドメインの組み合わせが膨大であり、かつ QA（品質保証）基準も頻繁に更新されるため、それぞれの組み合わせごとに個別のプロンプトを用意して維持するのは現実的ではありません。

その解決策として採用されたのが、動的変数注入機能を持つ統一型プロンプトテンプレートです。言語コンテキスト、事業ドメインコンテキスト、そして各評価項目の定義や判定ルールはすべて外部設定ファイルに格納されています。通話時にシステムはチケットのメタデータに基づき、これらを組み合わせて完全なプロンプトを構築します。新しい評価項目、言語、または事業ドメインを追加する際も、設定ファイルを更新するだけで対応可能です。1 つのプロンプトテンプレートで、すべての組み合わせを 1 回の LLM（大規模言語モデル）呼び出しでカバーできます。

以下の図は、評価パイプラインが外部設定を統合して統一プロンプトを組み立て、構造化された出力を生成する仕組みを示しています。

Figure 2: Evaluation pipeline. External configuration dynamically assembled into a unified prompt, processed by Amazon Bedrock to produce structured compliance scores and business insights

以下の例は、外部設定からの動的なプロンプト組み立てと、Amazon Bedrock のツール使用機能によるスキーマ検証済み JSON の強制返却という、2 つの仕組みが連携する様子を簡略化して説明したものです。

import boto3

bedrock = boto3.client("bedrock-runtime", region_name="us-east-1")

MODEL_ID = ""

def build_output_schema(num_criteria):
    """Derive the JSON schema from the checklist size — adding a new
    compliance item requires only a config change, not a code change."""
    criteria = {
        f"criteria_{i}": {
            "type": "object",
            "properties": {
                "reasoning": {"type": "string"},
                "score": {"type": "integer"},  # 0 = pass, 1 = fail
            },
            "required": ["reasoning", "score"],
        }
        for i in range(1, num_criteria + 1)
    }
    return {
        "type": "object",
        "properties": {"scoring": {"type": "object", "properties": criteria}},
        "required": ["scoring"],
    }

def assemble_prompt(criteria_config, language, business_line):
    """Dynamic assembly: one template covers every language x business-line
    combination. Context lives in external config, injected at call time."""
    criteria_block = "\n".join(
        f"CRITERIA_{i}:\n- {c['parameter']}\n- PASS: {c['pass']}\n- FAIL: {c['fail']}"
        for i, c in enumerate(criteria_config, 1)
    )
    return (
        f"You are a customer service quality auditor for DiDi.\n"
        f"LANGUAGE CONTEXT: the conversation is in {language}.\n"
        f"BUSINESS CONTEXT: this is a {business_line} service interaction.\n\n"
        f"SCORING CRITERIA TO EVALUATE:\n{criteria_block}"
    )

def evaluate(transcript, criteria_config, language, business_line):
    system_prompt = assemble_prompt(criteria_config, language, business_line)
    schema = build_output_schema(len(criteria_config))
    response = bedrock.converse(
        modelId=MODEL_ID,
        system=[{"text": system_prompt}],
        messages=[{"role": "user", "content": [{"text": transcript}]}],
        # Tool Use with a forced tool choice constrains the model to emit
        # schema-valid JSON — every score carries its own reasoning chain.
        toolConfig={
            "tools": [{
                "toolSpec": {
                    "name": "output_result",
                    "description": "Output the structured evaluation result",
                    "inputSchema": {"json": schema},
                }
            }],
            "toolChoice": {"tool": {"name": "output_result"}},
        },
        inferenceConfig={"maxTokens": 8192, "temperature": 0.0},
    )
    for block in response["output"]["message"]["content"]:
        if "toolUse" in block:
            return block["toolUse"]["input"]

Amazon Bedrock のツール使用機能は、出力を構造化された JSON に制限し、各スコアには判断とその推論チェーンの両方を含めます。ルール決定型の指標については、システムがプログラムによる事後検証を行い、モデルの意味的な判断を決定論的ロジックで補正します。

本番環境での検証では、コンプライアンススコアの平均精度は 90% を超えました。このパイプラインはまた、問題解決率や顧客満足度といったビジネスインサイトも出力します。すべての判断に推論チェーンが付随するため、QA は双方向の改善メカニズムとなります。担当者たちはなぜそのスコアが付けられたのかを理解し、サービス内容を調整できます。

VOC パイプライン：プロアクティブなトレンド発見のための多段階処理

VOC パイプラインは、特定の時間枠内の大量のコンタクトを分析するためにオンデマンドでトリガーされ、体系的な対応が必要な高頻度の課題を浮き彫りにします。課題は、数千件の会話から効率的に構造化されたインサイトを抽出することです。これらすべてを一度に LLM に読み込ませると、カテゴリが粗雑になりすぎ、重要な詳細が見えなくなってしまいます。

VOC パイプラインでは、並列抽出から課題のクラスタリングを経てレポート生成に至る 3 段階のアプローチを採用し、各段階で LLM に見える情報の範囲を精密に制御します。

並列抽出。各会話で独立して大規模言語モデル（LLM）を呼び出し、構造化された項目（問題タイプ、ユーザーの感情、解決結果、根本原因など）を抽出します。この段階ではチケット処理が自然に並列化可能です。

問題クラスタリング。埋め込みモデルが抽出した問題タイプラベル間の意味的類似度を計算し、「未払いのキャンセル料」と「キャンセル料を支払っていない」などの同義表現を統合します。その後、チケット頻度に基づいて結果をランク付けし、最も影響度の高い問題を浮き彫りにします。この段階では LLM の生成ではなく埋め込み距離と統計的ランキングを利用するため、結果は決定論的で再現可能です。

レポート生成。LLM が高頻度のクラスタから分析レポートを生成します。内容にはエグゼクティブサマリー、課題分析、実行可能な改善推奨事項が含まれます。

例： ラテンアメリカ市場でキャンセル料に関する苦情が短期間に急増した際、運用チームは VOC（Voice of Customer）分析を開始しました。システムは数分以内に多言語会話から主要な根本原因と高頻度のトリガーシナリオを特定し、実行可能な推奨事項を含む構造化レポートを生成しました。この作業は従来、人手による読み込みと要約に数時間を要していました。

結論

今回の協働を振り返り、DiDi のチームは測定可能な成果だけでなく、プロジェクトがもたらした深い教訓についてもまとめました：

「国際事業における多言語・多業種の顧客対応 QA は、スケーリングの大きな課題でした。既存のソリューションはブラックボックスであり、ビジネス基準の変化に応じて迅速に改善することも困難でした。Amazon Bedrock でこのシステムを再構築した結果、QA 判断の透明性が完全に確保されました。意図検証の精度は 38% から 86% に向上し、コンプライアンス評価の精度も 90% を超えました。また、大量のチケットデータに基づく傾向分析が、数時間から数分に短縮されています。このプロジェクトで得た最も重要な教訓は、信頼性の高い LLM アプリケーションを構築する鍵はツールそのものではなく、チームが文脈管理とデータ定義を深く理解しているかにかかっているということです。この能力は外部委託できません。これが今回の協業において得られた最も価値ある成果です。」

— DiDi 国際事業グループ データ分析チーム ラファエル・フア氏

DiDi が構築したインテリジェント QA システムは Amazon Bedrock を基盤とし、第三者のブラックボックスシステムから透明性が高く制御可能な品質保証へと移行しました。この変革は 3 つのパイプラインによって実現されました。

意図検証の精度は 38% から向上し