DiDiコンタクトセンターQA、Amazon Bedrockでブラックボックスを置き換える

DiDiは、意図判定の精度がわずか38%にとどまっていた不透明な品質保証ツールを置き換えた。新たなDiDiコンタクトセンターQAシステムにより、この数値は86%まで向上したという。

同社はInternational Business Group向けに、AWSとともに代替システムを構築した。配車、フードデリバリー、金融サービスにまたがるスペイン語とポルトガル語のサポート会話を処理する。コンプライアンスの評価や、新たに発生する顧客の苦情の検出も行う。

これは、企業がカスタマーサポートに大規模言語モデルを追加する、よくある事例以上のものだ。DiDiは重要な社内統制を外部ベンダーから、自社チームが検証・変更できるアーキテクチャへ移した。したがって争点は、不透明な外部委託自動化と、透明性のある内製AIの対比にある。

AWSとDiDiは2026年9月8日、コンタクトセンターQAのケーススタディでこのシステムを公開した。性能指標の大半はDiDiによる本番環境での検証に基づくものであり、独立した監査は受けていない。

それでも、この結果は注目に値する。限定的なコンテキスト、決定論的なチェック、構造化出力が、プロンプトを繰り返し書き換えること以上に重要となり得ることを示している。

DiDiコンタクトセンターQAで変わったこと

DiDiは一つのモデルを別のモデルに置き換えたのではない。品質保証を、役割と必要な証拠が異なる3つの統制されたパイプラインに分割した。

第1のパイプラインは意図を検証する。カスタマーサービス担当者は各会話に問い合わせ理由を割り当て、それによって案件はDiDiの階層型分類ツリーに位置付けられる。システムは、割り当てられた理由が顧客の話した内容と一致しているかを確認する。

ラベルが誤っているように見える場合、パイプラインは代替案を提案する。また、既存のカテゴリが適切と思われなかった「Other」とラベル付けされた会話も調べる。こうしたケースは、分類体系そのものの欠落を明らかにする可能性がある。

第2のパイプラインはコンプライアンスを評価する。同一の会話から運用上のインサイトを抽出しながら、複数の品質基準を採点する。DiDiによれば、本番検証における平均コンプライアンス採点精度は90%を超えた。

第3のパイプラインはVoice of Customerデータを分析する。Voice of Customer、すなわちVOCとは、顧客の問題、感情、結果、繰り返される原因に関する集約された証拠を指す。DiDiは、運用チームが進行中の傾向を理解する必要がある際に、このパイプラインをオンデマンドで利用する。

ライブチャットの記録と電話の文字起こしは、まず前処理レイヤーに入る。通話から得られた音声テキスト化の出力は、チャットで使用するものと同じ会話形式へ正規化される。生成された記録は、その後、該当するQAパイプラインを通過する。

この共通スキーマは重要だ。音声とチャットの違いによって、下流の分析コンポーネントごとに独自の取り込みロジックを実装する必要があってはならない。このシステムは、チャネル処理と、その後に続く推論タスクを分離している。

両社によると、DiDiの国際事業は14の国と地域にまたがる。サポート組織は、3つの事業領域で数千万人のユーザーを対象に、スペイン語とポルトガル語の会話を処理している。

この規模では、手作業によるレビューで確認できるやり取りは一部に限られる。しかし、外部委託という選択肢にも問題があった。DiDiによれば、従来のシステムは過去の判断を説明したり、迅速な変更を支援したりするのに十分な推論過程を開示していなかった。

コンプライアンス評価の失敗は、コーチング、監査、運用上の優先順位に影響する可能性がある。誤った意図ラベルは、顧客がなぜ支援を必要としているのかに関するレポートを歪めかねない。説明不能な判断は、したがって開発者にとって単に不便なだけではない。

新システムは、各モデル判断に推論の連鎖を付与する。レビュアーはスコアの根拠を確認し、元の会話を調べ、適用されたルールと判断を比較できる。

この追跡可能性が、この記事の中心的な緊張関係を生む。システムをDiDiの内部に取り込むことで可視性と統制は向上するが、同時にDiDi自身が検証、セキュリティ、設定、継続的な精度に責任を負うことになる。

DiDiはいま、結果を形作る定義を所有している。その定義が不完全または誤っていた場合の結果も、自ら負う。

より多くのプロンプト調整よりコンテキスト分離が有効だった理由

報告された最大の精度向上は、指示を増やすことではなく、適切なタイミングでモデルに提示する情報を減らしたことから得られた。

DiDiの初期の意図検証設計は、直感的なアプローチに従っていた。会話の横に問い合わせ理由の完全なツリーを配置し、担当者が選択したラベルをモデルに評価させた。

モデルは選択されたラベルを、利用可能なすべての代替案と比較した。わずかにでもより正確に見えるカテゴリを見つけると、本来は妥当な選択であっても拒否する傾向があった。

この挙動は過剰修正を生んだ。最良のラベルを探すよう求められたモデルは、既存のラベルが許容できるかを問われたモデルとは異なる振る舞いをする可能性がある。一つのプロンプト内でこれらの判断を組み合わせたことで、その違いが曖昧になった。

DiDiによれば、複数回のプロンプト調整では問題を解決できなかった。チームは、モデルに誤った判断環境を与えていたと結論付けた。

再設計された意図パイプラインは、検証と分類を分離している。検証段階では、モデルに会話と担当者の現在の問い合わせ理由だけを与える。そのラベルがやり取りに妥当に適合するかを判断する。

完全な分類ツリーは、この段階では隠されたままだ。この情報分離により、モデルはより狭い問いに答える前に、わずかに優れた代替案を探すことを防げる。

検証に失敗した場合にのみ、分類段階が開かれる。モデルはその時点で、完全な分類体系と第1段階の推論を受け取る。別のカテゴリを推奨し、信頼度スコアと根拠を提示する。

DiDiは「Other」ラベルを、独立した3段階のプロセスで扱う。システムはまず、適切な一致を見つけるために兄弟カテゴリを検索する。ローカルの分岐で答えが見つからなければ、次にツリー全体を検索する。

どちらの検索でも適切なカテゴリが得られない場合、パイプラインは分類体系上の欠落の可能性を特定する。会話を不適切な既存バケットに無理に割り当てるのではなく、運用担当者にラベルの追加を提案できる。

DiDiによれば、この2段階設計により意図検証の精度は38%から86%へ向上した。同社が示した本番検証に基づけば、48ポイントの上昇となる。

この仕組みは、エンタープライズAIチームに実践的な教訓をもたらす。より多くのコンテキストが、必ずしもより良いコンテキストとは限らない。選択肢を増やすことで、モデルが解いているように見えるタスク自体が変わる可能性がある。

これは、多くのエンタープライズ向けプロンプトが効率のために複数の判断を組み合わせているから重要だ。一つのリクエストで、会話の分類、結果の正当化、ポリシー準拠の確認、案件の要約、アクションの推奨をモデルに求めることがある。

目的を一つ追加するごとに、指示と証拠が互いに干渉する機会も増える。また、コンテキストのどの部分が回答を変化させたのかを開発者が容易に特定できないため、障害分析も難しくなる。

DiDiのアプローチは代わりに、コンテキストをアプリケーションアーキテクチャの一部として扱う。従来のソフトウェアが変数と状態へのアクセスを制御するのと同様に、チームは各判断時点でどの情報を可視化するかを決める。

この設計は、より明確な障害境界も生み出す。疑わしい検証結果は第1段階に属する。質の低い代替ラベルは第2段階に属する。カテゴリの欠落は分類体系のガバナンスに属する。

これは、多段階システムが常に単一のプロンプトを上回るという普遍的な主張ではない。段階を追加するごとに、レイテンシ、運用の複雑さ、監視すべきコンポーネントが増える。

DiDiは、サンプル数、クラス分布、信頼区間、言語別および事業領域別の性能を公表していない。こうした欠落は、他のコンタクトセンターQAシステムとの比較を制限する。

それでも、報告された変化は企業における一般的な慣行に疑問を投げかける。チームは期待に届かないモデルの挙動に対し、しばしば指示を増やすか、基盤モデルを切り替えることで対応する。DiDiは代わりに情報の流れを変えた。

これはより深い形のプロンプトエンジニアリングだ。責任を巧みな文言から、システム設計、データ定義、明示的な判断境界へ移している。

内製システムが外部委託AIに圧力をかける

DiDiが第三者QAベンダーに突き付ける最も強い課題は、モデル精度の主張ではない。判断ロジックが戦略的インフラになったという主張だ。

外部委託プラットフォームは実装作業を減らせる。文字起こし、評価、ダッシュボード、ワークフローを一つのマネージド製品にまとめることができる。購入者は、すべてのコンポーネントを自ら維持する必要がない。

しかし、ベンダーが判断に至った過程を開示しなければ、その利便性は制約となる。DiDiによれば、以前のソリューションは十分な監査証跡なしにQA判断を下していた。

基準の変化に伴い、この制約はさらに深刻になった。配車サービスにおけるスペイン語サポートが、金融サービスにおけるポルトガル語サポートと同じ基準を使用するとは限らない。新しいポリシーは、さらに組み合わせを増やす。

ベンダーが管理する実装では、こうした基準が本番環境に反映されるまでに、カスタム変更、再トレーニング、製品アップデートが必要になる場合がある。その間、新旧のルールが共存する可能性がある。

DiDiはポリシー定義を外部設定へ移した。評価パイプラインは一つのプロンプトテンプレートを使用し、各チケットに応じて言語、事業領域、基準定義、合格ルール、不合格ルールを挿入する。

別の基準を追加するために、言語ごとのプロンプトをすべて書き直す必要はない。運用担当者が設定を更新すると、アプリケーションは会話を受け取った際に必要なコンテキストを組み立てる。

パイプラインは、一回のモデル呼び出しで複数のコンプライアンス項目を評価する。また、問題解決や顧客満足度に関する指標を含む、構造化されたビジネスインサイトも返す。

Amazon Bedrock Tool Useは、応答を定義済みのJSON構造に制約する。各採点項目には判断と、それに付随する根拠が含まれる。該当するtool-use機能により、アプリケーションは期待するツール入力を記述し、結果として得られる構造化データを処理できる。

構造化出力が解決するのは、応答形式の問題だけだ。有効なJSONであっても、基礎となるスコアが正しいとは保証されない。そのためDiDiは、生成後に決定論的なチェックを加えている。

例えば、モデルはスペルミスの可能性を特定できる。アプリケーションコードは、そのうち担当者のメッセージ内の誤りだけを数え、検証済みの数に定義されたしきい値を適用する。

システムは応答待機時間もコードで計算する。モデルにタイムスタンプから推測させるのではなく、それらの値をプロンプトに挿入する。

このハイブリッドパターンでは、意味的な判断を言語モデルに、計算可能な事実を従来のソフトウェアに割り当てる。直接計算で再現可能な回答を得られる場面で、確率的な生成を用いることを避ける。

この区別は、内製アプローチの中心にある。DiDiは、どの判断がモデルに属し、どれがコードに属し、どれが業務設定に依存するかを検証できる。

このアーキテクチャでは、Amazon Bedrockも使用している。これは同サービスが共通インターフェースを通じて複数の基盤モデルを提供するためだ。DiDiによれば、モデルの選択を変更しても、各パイプラインを別のプロバイダー固有の統合に合わせて再構築する必要はない。

モデルのポータビリティには依然として限界があります。モデルごとにプロンプトやスキーマの解釈が異なるため、モデルを切り替える際には改めて評価が必要です。共通APIは統合作業の一部を減らせますが、挙動まで互換にするものではありません。

セキュリティも、別の重要な論点です。顧客との会話には、氏名、連絡先、金融情報、位置情報、機微な苦情が含まれる場合があります。これらの記録をAIワークフローへ移すことで、統治が必要なシステムの範囲は広がります。

DiDiによると、この導入ではAWS PrivateLinkを介したVPCエンドポイント、暗号化、きめ細かなIdentity and Access Management制御を利用しています。AWSの文書では、プライベート接続を使えば、インターネットゲートウェイやパブリックIPアドレスを経由せずにBedrockへ接続できると説明されています。

このシステムでは、モデル推論の前にAmazon Bedrock Guardrailsも適用されます。個人を特定できる情報をマスキングし、十分な根拠がない回答を検出するためのコンテキスト・グラウンディングチェックを使用します。

AWSはGuardrailsについて、機微情報、禁止トピック、望ましくないコンテンツなどを対象に、プロンプトと応答を評価するポリシーだと説明しています。ガードレール制御では、設定されたポリシーに従ってコンテンツをブロックまたはマスキングできます。

こうした対策によってガバナンス業務が不要になるわけではありません。DiDiは引き続き、顧客データに関するアクセス、保持、エスカレーション、レビュー、地域別の取り扱いルールを定義する必要があります。

同じ負担はビジネスロジックにも当てはまります。透明性のあるシステムを自ら所有することは、その分類体系、評価基準、検証セット、監視プロセスを維持することを意味します。同社はベンダーの不透明性と引き換えに、社内での説明責任を引き受けたことになります。

したがって、サードパーティベンダーは二方向から圧力を受けます。マネージド製品の利便性に匹敵しつつ、企業顧客が重要な判断を信頼できるだけの根拠、設定可能性、制御性を提供しなければなりません。

その答えが、ソースコードの全面開示である必要はありません。ベンダーは、判断のトレース、バージョン管理されたルール、評価ツール、エクスポート可能な結果、モデル出力と決定論的チェックのより明確な分離を提供できます。

DiDiの事例は、単純な精度ダッシュボードだけではもはや不十分であることを示唆しています。購入者はますます、各スコアがどのモデル、プロンプトのバージョン、ポリシー定義、後処理ルールによって生成されたのかを知る必要があります。

この要件により、可観測性はプロダクト機能へと変わります。また、十分なエンジニアリング能力と高度に専門化された業務を持つ企業にとって、社内所有の魅力も高まります。

精度の数値だけでは分からないこと

報告された改善は重要ですが、公開情報だけでは、あらゆる市場、言語、カテゴリー、あるいは変化するポリシーにおけるシステムの性能を立証することはできません。

38%と86%の意図判定に関する数値は、DiDiの本番環境での検証に基づくものです。AWSの記事では、テストした会話数や、評価者が正解をどのように定義したかは開示されていません。

また、スペイン語とポルトガル語それぞれの精度も示されていません。アクセント、地域ごとの語彙、サポートチャネル、事業ライン、分類の深さによって、性能は異なる可能性があります。

クラスのバランスも重要です。一般的な配車サービスの質問が大半を占めるデータセットでは、全体として高いスコアが出ても、頻度の低い金融サービス関連ケースでの弱い結果が隠れる可能性があります。

同じ注意は、90%を超えるコンプライアンス評価にも当てはまります。公開資料には、含まれる基準の数、各基準が同じ重みで扱われたか、人間が意見の不一致をどう解決したかは記載されていません。

精度は、エラーごとのコストの違いも隠し得ます。スペル違反の誤検出は不便なだけですが、規制対象の金融サービス行為に関する誤った評価は、より重大な結果を招く可能性があります。

したがって本番評価では、単一の平均値だけでなく、個別基準ごとの適合率と再現率を追跡するべきです。人間のレビュー担当者と自動化システムの判断の不一致も監視する必要があります。

推論トレースはレビュー担当者が判断を調査する助けになりますが、証明ではありません。言語モデルは、誤った回答に対してももっともらしい説明を生成できます。

決定論的な検証レイヤーは、測定可能な事実に関するこのリスクを低減します。しかし、すべてのポリシー判断を計算に変換できるわけではありません。口調、解決の質、共感、文脈上の適切さには、依然として解釈が必要です。

Guardrailsにも別の制約があります。機微情報をフィルタリングし、グラウンディングを検査できますが、AWS自身も基盤となる保護機能の変化に応じて継続的な検証を推奨しています。設定済みの制御を恒久的な保証と見なすべきではありません。

特に異議のあるスコアや高リスクの基準については、人間による監督が引き続き必要です。レビュー担当チームには、個別の判断と基礎となるルールの両方を修正できる異議申し立て経路が必要です。

公開された説明には、運用上の測定値も欠けています。モデルのレイテンシー、処理コスト、上書き率、レビュー担当者の作業負荷、エスカレーションを要した会話の割合は報告されていません。

こうした数値は、モデル精度の向上がより良い運用につながるかを明らかにするはずです。正確なシステムであっても、応答が遅すぎる、手動修正が頻繁に必要になる、全量処理時にコストが高くなる、といった課題を抱える可能性があります。

他の導入事例との比較は、有益な視点を加えます。金融サービス企業Empowerは以前、Bedrockを基盤とする別のQA導入について、毎日数千件のトランスクリプトを処理していると説明しました。

同社の自動QAシステムは、Amazon Connect Contact LensとBedrockを組み合わせたものです。Empowerによると、QAのカバレッジを20倍に拡大し、レビュー時間を数日から数分へ短縮しました。

両者の実装を直接比較することはできません。EmpowerはAWSのコンタクトセンタースタックから得た事前に匿名化済みの文字起こしを利用した一方、DiDiは独自の前処理と3つのパイプライン構成を説明しています。

それでも両事例は、同じ競争上の方向性を示しています。企業は、より多くの会話をレビューし、評価を説明可能にし、顧客の問題と運用上のアクションの間にある時間差を短縮したいと考えています。

DiDiの独自性は、失敗した設計についても説明している点にあります。分類体系全体を1回の呼び出しに投入した結果、プロンプトを繰り返し調整したにもかかわらず、意図検証の精度は低調でした。

この失敗により、この事例は単なるベンダーの成功談よりも有用になります。モデルへのアクセスだけでは、信頼できる品質保証を実現できないことを示しているからです。

残る不確実性は、保守に関するものです。分類体系は変化し、顧客行動は移り変わり、ポリシー文言も進化します。モデル提供事業者も、利用可能なバージョンや支援機能を更新します。

DiDiには、各言語、チャネル、事業ライン、高リスク基準から代表例を維持する、バージョン管理された評価セットが必要になります。そうでなければ、ある領域での設定改善が、別の領域の性能を静かに低下させる恐れがあります。

同様のシステムを構築するチームは、各リリースを支える証拠を保存すべきです。検索可能なエンジニアリングナレッジベースは、生成された説明をグラウンドトゥルースとして扱うことなく、要件、テスト結果、プロンプトバージョン、インシデントレビューを結び付けられます。

この実践は、透明性が持つ本来の価値を支えます。チームが何を、なぜ変更し、新しいバージョンがどのような性能を示したかを再構成できる場合にのみ、可視性は有用になります。

次の試金石は、DiDiが統制を拡張できるかどうか

DiDiのアーキテクチャがQAのための持続的な運用システムとなるのか、それとも公開検証が限られた成功事例にとどまるのかは、3つのシグナルによって決まります。

第一のシグナルは、追加の言語と事業ラインにおける性能です。DiDiは、現在のカバレッジを超えてシステムを拡張する計画を示しています。

この拡張は、動的設定が本当に保守作業を抑えられるかを試すことになります。新しい言語では、翻訳済みの指示を追加するだけでは済みません。地域固有の表現、文化的期待、文字起こしの誤り、異なるポリシー要件が持ち込まれる可能性があります。

新たな導入先でも精度が安定すれば、その結果はDiDiのコンテキスト管理に関する主張を強化するでしょう。大幅な低下が見られれば、現在の改善が既存のスペイン語・ポルトガル語の検証環境に大きく依存していることを示唆します。

第二のシグナルは、パイプライン間の統合です。DiDiは、意図検証、コンプライアンス評価、VOC分析をより深く接続する計画です。

現在、それぞれのパイプラインには明確な目的があります。統合によって、苦情トレンドが不足している分類を明らかにし、繰り返される分類失敗が分類体系を更新し、コンプライアンスの発見事項がコーチングに反映されるフィードバックループを作り出せます。

一方で、エラーも拡散し得ます。不正確な問題クラスターが分類体系の変更に影響を与え、その変更が意図チェックや経営レポートに影響する可能性があります。

したがって、統合の成功にはプロベナンスが必要です。下流のすべての推奨事項は、それを生み出した会話、抽出フィールド、設定バージョン、モデル出力へのリンクを保持すべきです。

第三のシグナルは、精度を超えた運用上の証拠です。今後の開示では、人間による上書き率、偽陽性の傾向、処理レイテンシー、レビュー時間、カテゴリー別の性能を含めるべきです。

こうした測定値は、初期検証期間の後もシステムが有用であり続けるかを示します。また、購入者が自社所有アーキテクチャとマネージドコンタクトセンター製品を比較する助けにもなります。

VOC分析は、最も明確な直近の試験を提供します。DiDiは、ラテンアメリカ市場全体でキャンセル料に関する苦情が急増したことを説明しています。運用スタッフが分析を開始すると、多言語の会話がクラスター化され、数分以内に構造化されたレポートが作成されました。

このパイプラインは、各会話からフィールドを並列に抽出することから始まります。これらのフィールドには、問題の種類、センチメント、結果、考えられる根本原因が含まれます。

次に、埋め込みモデルが問題ラベル間の意味的類似性を測定します。埋め込みは、関連する意味を互いに近くに配置する数値表現であり、異なる表現の苦情をシステムが統合できるようにします。

この段階では、生成出力ではなく、距離計算と頻度ランキングが用いられます。DiDiによると、この設計によりクラスタリングは決定論的かつ再現可能になります。

レポート生成時に言語モデルへ渡されるのは、高頻度のクラスターのみです。より小さく構造化された証拠セットから、エグゼクティブサマリーの作成、課題の特定、アクションの提案を行います。

このパイプラインもまた、情報分離を適用しています。モデルは、何千件もの生の会話を1つの過大なプロンプトで受け取ることはありません。各段階が、次の判断に必要な証拠を絞り込みます。

DiDiによると、このプロセスは以前は数時間かかっていた作業を数分に短縮しました。今後の報告で、運用チームの対応が速くなったか、あるいは顧客への繰り返しの被害を防げたかが示されれば、この主張はさらに説得力を増すでしょう。

目標は速度だけではありません。根本原因が誤った迅速なレポートは、リソースを誤った対策へ振り向ける可能性があります。

最も強力な導入は、より速い検出を測定可能な成果と結び付けるでしょう。たとえば、再問い合わせの減少、問題解決の改善、苦情の再発率低下、ポリシー問題のより迅速な修正などが考えられます。

開発者にとって、当面の教訓は、プロンプトを磨き込む前にモデルの境界を設計することです。各呼び出しに必要な証拠、スキーマを必要とする出力、コードで計算すべき事実を決めてください。

エンタープライズの購入者も、ベンダーに同じ明確さを求めるべきです。バージョン管理されたルール、監査可能な判断、カテゴリー別の検証、エスカレーションワークフロー、会話データの機微性を反映したアクセス制御を要求してください。

ナレッジワーカーも、このパターンがサポート領域を超えて広がるため、関心を持つべきです。文書を分類し、作業を評価し、繰り返し発生する問題を要約するあらゆるシステムは、無関係な選択肢を見たり、互換性のないタスクを組み合わせたりすると、問題を抱える可能性があります。

したがってDiDiのコンタクトセンターQAは、モデル性能と同じくらい組織力を問う試金石でもある。同社は判断レイヤー全体を外部委託するのではなく、コンテキスト、定義、検証を自ら担っている。

言語、ポリシー、モデルが変化しても、この主体的な取り組みは安定した成果を生み出せるのか。注視すべきは、拡大に関する指標、パイプラインをまたぐ証拠の追跡可能性、そして人間による上書き率だ。これらのシグナルが、透明性の高いエンタープライズAIが長期的にブラックボックスを上回れるかどうかを示すだろう。