顧客を「実験台」にしない——Nubankが1.4億ユーザー規模で実践するCXエージェントのシミュレーション・スクリーニング

はじめに：AIカスタマーサポートの「出す前に確かめる」という難題

カスタマーエクスペリエンス（CX）エージェントとは、顧客からの問い合わせや苦情に応答するだけでなく、商品やサービスの操作を会話の流れの中でガイドし、タスク完了まで導くAIエージェントを指す。コーディングや数学を解くエージェントほどの深い推論は要求されない一方で、パーソナライズや多言語対応、多ターン会話での意図追随、機密データの取り扱いといった多次元の要件を同時に満たす必要がある。とりわけ金融のような規制産業では、意図検出・複雑な業務ポリシーの遵守・ツール呼び出しの信頼性が同時に問われ、安全性と定性品質のハードルは一般的なエージェント応用より高い。

こうしたエージェントを改善する手段は、これまで実質的に二択だった。第一は人手でテストケースを書き、想定シナリオを網羅的に試す方法である。ただし人間が思いついた範囲しか検証できず、実顧客が遭遇する多様なツール状態が抜け落ちる。第二は本番環境でのA/Bテストで、直接的な効果は測れるものの、顧客をテスト対象の失敗に晒し、信頼を損なうリスクを伴う。サンプルサイズが小さいと得られるシグナルも不安定になる。

本記事で扱うのは、この難題に対するNubankの取り組みをまとめた論文「Screen Before You Serve: Simulation for Production Customer Experience AI Agents at 140M Scale」（arXiv:2609.30137v1）である。舞台はカード配送を担うCard Deliveryエージェントと、その後継でブラジル最高流量のチャットサポートを担うCard Managementエージェント。著者らは、デプロイ前に候補エージェントをスクリーニングするための「仮説駆動型シミュレーションワークフロー」を提示している。

この研究の要点は、シミュレーションを「本番環境の完全な再現」ではなく「意思決定を前に進めるための層」と位置づけたことにある。不完全なシミュレーションであっても、方向性の正しい改善を導けることをライブA/Bテストで実証した点が重要だ。以下の図は、3つの意思決定アプローチの違いを整理したものである。

flowchart TB
  subgraph A["人手テストケース"]
    A1["人間が想定シナリオを作成"]
    A2["網羅性が限定 / ツール状態が欠落"]
  end
  subgraph B["本番A/Bテスト"]
    B1["実顧客で直接効果を測定"]
    B2["顧客を失敗に晒す / 小標本で不安定"]
  end
  subgraph C["オンポリシー × ツール境界シミュレーション"]
    C1["合成顧客＋モックツールで多段ワークフローを再現"]
    C2["顧客露出ゼロで候補を広く探索"]
  end
  A1 --> A2
  B1 --> B2
  C1 --> C2

「CXエージェント」とは何か：普通のチャットボットと何が違うのか

CXエージェントとは、カスタマーエクスペリエンス（CX）を担うAIエージェントのことで、顧客の質問・苦情・サポートニーズに応える「反応型」の対応と、顧客の目的を先回りして会話フローの中でタスク完了へ導く「能動型」の誘導の両方を含む。たとえばカードの再発行や配送状況の確認のように、単に質問に答えるだけでなく、必要な情報を順に聞き出し、社内ツールを呼び出して処理を進め、最後まで会話で完結させることが求められる。この点が、決まった選択肢を提示するだけの従来型チャットボットとの決定的な違いである。

従来型チャットボットは、あらかじめ用意したFAQや選択肢のツリーに沿って応答する。一方CXエージェントは、大規模言語モデル（LLM）を推論の中心に置き、会話の文脈から意図を推定し、複数のツールを段階的に呼び出して処理を組み立てる。コード生成や数学エージェントほどの深い推論は必要としない場面も多いが、要件はむしろ多次元になる。パーソナライズや地域ごとのローカライズ、多ターン会話での意図の追随、氏名・取引履歴・カード情報といった機密データの適切な扱いが同時に問われるからだ。

flowchart LR
  A[顧客] -->|問い合わせ| B(CXエージェント)
  B -->|意図検出| C{反応型か能動型か}
  C -->|反応型| D[質問・苦情への回答]
  C -->|能動型| E[会話フローでタスク完了へ誘導]
  D --> F[ツール呼び出し]
  E --> F
  F --> G[業務ポリシーの遵守チェック]
  G --> H[応答生成・機密データの取り扱い]

この多次元性が、CXエージェントの安全性と定性品質のハードルを、一般的なエージェント応用より高くしている。業務ポリシーに反する案内をしたり、誤ったツール呼び出しで顧客の手続きを壊したりすれば、実害と信頼の低下に直結する。しかも金融など規制産業では、判断の根拠を後から説明できること自体が要件になる。したがって開発の焦点は「動くかどうか」ではなく、「多ターンの会話でエッジケースを正しく処理し、安全に本番へ出せるかをどう確かめるか」に移る。ここに、顧客を失敗に晒さずに事前検証するという後続の議論の必要性がある。

なぜ本番テストだけでは不十分なのか

CXエージェントの品質を確かめる手段は、大きく三つに分かれる。人手でテストケースを書く方法、本番環境でのA/Bテスト、そしてデプロイ前のシミュレーションである。前の二つだけで十分でない理由を、ここで整理しておきたい。

まず人手オーサリング型のテストは、人間が思いついたシナリオしか検証できない。カード再発行の失敗、顧客入力の不備、配送データの不一致といった実顧客が出会う多様なツール状態は、想像の範囲を超えて広がる。テストケースを増やせば網羅性は上がるが、その作成コストは人手に比例し、リリースのたびに追いつかなくなる。

次に本番A/Bテストは、実際の顧客アウトカムを直接測れる点で最も信頼できる。ただし顧客をテスト対象の失敗に晒すという代償を伴う。誤った案内やツール呼び出しの失敗は、そのまま信頼の低下と離脱につながる。加えて、有意な差を検出するには相応のサンプルサイズが必要で、小標本ではシグナルが不安定になり、判断を誤らせる。規制産業では、試行錯誤そのものが説明責任の対象になる。

さらに、シミュレーションを導入する際にも注意が要る。プロンプト駆動の合成ペルソナを使う素朴な手法では、スコアが実態より膨らむ「スコア膨張」や、用意した目標から逸脱する挙動が報告されている。忠実性が確かめられていないシミュレータは、判断を後押しするどころか、誤った方向へ導く。

この整理から見えるのは、三つが代替関係ではなく補完関係にあるということだ。だからこそ問うべきは「どの手法を使うか」ではなく、「顧客を失敗に晒さずに、どこまで候補をふるいにかけられるか」である。次のセクションでは、その問いに答えるオンポリシー×ツール境界モックという設計を見ていく。

シミュレーションの仕組み：オンポリシー × ツール境界モック

シミュレーションの中核は、「合成顧客がエージェントの応答に反応し、ツール出力も合成する」という一点にある。本番バックエンドを呼ばずに、多段のエージェントワークフローを再現できるため、顧客に触れずに何度でもやり直せる。

起点になるのは、シミュレータ（Snowglobe）に与えるエージェント記述とツール定義である。必要に応じてシミュレーションプロンプトや過去会話も渡すと、シミュレータはユースケース、ユーザープロファイル、ツール間の関係、そして軌跡計画を推論する。軌跡計画とは、ある目的を達成するまでにツールをどの順序で呼ぶかの見取り図だ。

実行時にはオーケストレーションエージェントが、ユースケースと対話スタイルの条件に会話を配分する。各会話のペルソナは直前のエージェント応答に条件づけられ、多ターンで対話を進める。会話は、目的達成・到達不能と判定・ターンやツール呼び出し回数の上限のいずれかで終了する。この「オンポリシー」な設計により、エージェント自身の業務ポリシーに従わせたうえで、多ターン特有の失敗が顧客露出前に浮上する。

sequenceDiagram
    participant O as オーケストレータ
    participant P as 合成ペルソナ
    participant A as エージェント被験体
    participant M as モックツール層
    O->>P: ユースケース×対話スタイルを割当
    loop 上限まで
        P->>A: 顧客発話
        A->>M: ツール呼び出し
        M-->>A: シナリオ条件付き合成応答
        A-->>P: 応答
    end

「ツール境界モック」の要点は、共有ワールドステートを持たないことだ。会話ごとに独立したサンドボックスとして扱い、同じレコードを二度問い合わせても、中間アクションなしに状態が変わらないという整合性ルールを守る。たとえばカード配送状況を再確認しても、再発行を実行しない限り同じ結果が返る。これにより、会話をまたぐ矛盾が評価ノイズになるのを防ぐ。

単純なプロンプト合成（ペルソナLLM＋ツール結果LLM）では、ユースケースや対話スタイルの網羅的な制御、軌跡計画、会話をまたぐ整合性の維持ができない。構造化されたオーケストレーションこそが、この手法と素朴なベースラインを分ける差になっている。

「仮説駆動型スクリーニング」という手順

仮説駆動型スクリーニングとは、シミュレーションを「本番の予言」ではなく「展開判断の材料」として使うための手順である。まず現行版（インキュベント）の軌跡を生成し、候補の改訂ごとに同じ条件でシミュレーションを回し、同一の評価スイートで採点する。スコアが事前に定義した合格基準を満たした候補だけが、ライブA/Bテストへと進む。

アルゴリズムの骨子は4段階に整理できる。(1) 現行版Aをシミュレータ構成Sでシミュレートして軌跡T_Aを得る。(2) 各候補改訂ΔについてA'=A+ΔをシミュレートしT_A'を得る。(3) 両者の全軌跡を評価スイートEで採点する。(4) 候補と現行版の比較が事前定義基準Cを満たせばライブA/Bテスト適格とし、満たさなければΔを再評価・改訂する。

flowchart TD
    A[現行版の軌跡を生成] --> B[候補改訂をシミュレート]
    B --> C[同一評価スイートで採点]
    C --> D{事前定義基準Cを満たすか}
    D -- いいえ --> E[改訂を再設計]
    E --> B
    D -- はい --> F[ライブA/Bテストへ]
    F --> G[合格した候補が現行版になり<br/>ベースラインを更新]
    G --> A

重要なのは、この手順を支える設計原則である。各スクリーニングラウンドは反証可能な仮説と事前定義基準Cから導かれる。シミュレータ構成Sは候補間で固定し、ベースラインの更新は候補が現行版になって初めて行う。シナリオの構成は記録し、分布全体を見るランと狙いを定めた標的プローブを分離する。新しい評価器を追加したら、必ずベースラインの軌跡にも適用する。そして、小さすぎる差や曖昧な差はシミュレーションで決めず、ライブ実験に委ねる。

ここで「なぜ本番の完全再現を目指さないのか」という問いに答えておきたい。目的は、展開の可否を判断するのに足る有効な差・有害な差を炙り出すことにある。本番メトリクスの数値を正確に複製することは要求されていない。むしろ忠実性を追い求めすぎると、基準そのものが過剰になり意思決定が止まる。反証可能な仮説と固定条件という規律が、不完全なシミュレーションでも方向性の正しい改善を導ける理由になっている。

シミュレータは信用できるのか：4つの診断（P1〜P4）

合成ユーザーによるシミュレーションを意思決定に使うなら、まず「そのシミュレータは本番をどこまで写せているのか」を測らなければならない。Nubankの検証では、Card Delivery（カード配送）エージェントの実会話8,000件を開発用とテスト用に分割し、各バージョンについて実会話1,000件と合成軌跡250件を比較する4つの診断（P1〜P4）を実施した。結論を先に言えば、シミュレータは会話の「見た目」は忠実ではないが、「バージョン間の良し悪しの順序」は本番とよく一致する。用途を限定すれば十分に信用できる。

P1（会話長統計）では、シミュレーションの会話が実顧客より大幅に長いことが判明した。実顧客は中央値19語・3ターンなのに対し、シミュレーションは中央値111語・6ターンで、25.2%が8ターンという上限に張り付く。長さそのものは忠実ではないが、極端な値の比較には使える。

P2（埋め込み近接性）では、会話を埋め込みベクトルに変換し、合成と本番の分布がどれだけ近いかを測った。全バージョンで、合成と本番の距離は無関係な対照群（オフトピックな会話）より近く、最小コサイン距離は0.035だった。

P3（評価スコア連関）は最も実務的に重要な診断である。5カテゴリの評価器で採点すると、シミュレータは本番の良し悪しの順序を保った（最良V4、最悪V2）。相関はPearson r=0.74、Kendall τ=0.67で、素朴なベースラインはこの順序を反転させてしまう。

P4（ブラインド人手判別）では、専門家7名が本番50件と合成50件を判別した。本番は84%正解できたが、合成は70%正解にとどまり、合成の15件（30%）が本番と誤認された。

flowchart LR
    S[シミュレータ] --> P1[P1 会話長]
    S --> P2[P2 埋め込み近接性]
    S --> P3[P3 スコア連関]
    S --> P4[P4 ブラインド人手判別]
    P1 --> R[4つを補完的に読む]
    P2 --> R
    P3 --> R
    P4 --> R

これらの診断の使い方が肝心である。どれか一つを単独の合格基準にしてはならない。会話長のずれはP3の順序再現性を否定せず、P4の誤認率はP2の分布的な近さを打ち消さない。4つを補完的に読み合わせることで、「このシミュレータは何を根拠づけられ、何を根拠づけられないか」が明確になり、はじめて意思決定の材料として使えるようになる。

事例1：Card Managementのオフライン評価とライブA/Bテスト

シミュレーション主導のワークフローが実際に本番の数値を動かせるかは、Card Delivery（カード配送）の後継にあたるCard Management（CM）で検証された。CMはブラジルで最も流量の多いチャットサポートエージェントであり、バックボーンにはGPT-5.2を用いる。ここでは、オフライン評価で候補を絞り込み、それをライブA/Bテストで最終確認するという二段構えの手順が取られている。

まずオフライン評価では、各バージョンが掲げた明示的な仮説に対し、「人間サポートへの転送が不要だったか」をLLM-as-a-Judge（LLMを審判役として使う自動評価）で二値判定した。この不要転送の失敗率は、V5が16.0%で最小となり、V1の22.4%、V3の28.8%、V2とV4の34.0%を下回った。V5はV1比で6.4ポイントの改善であり、候補の中から最良の構成を顧客に触れさせる前に特定できたことになる。

オフラインで有望と判断された構成は、続くライブA/BテストでCMとCard Delivery（CD）を比較する形で評価された。指標は2つある。SSR（セルフサービス率）は人間サポートを求めずに自力でセッションを完了した割合、tNPS（トランザクションNPS）は事後アンケートの推奨者比率から批判者比率を引いた値である。結果はSSRが+4.90ポイント（95%信頼区間[4.08, 5.71]、n=27.8K）、tNPSが+36.69点（95%信頼区間[32.81, 40.57]、n=2.0K）となり、いずれも大きく改善した。この成果を受けて、CMはブラジルの顧客基盤全体へ展開されている。

flowchart LR
    H[仮説] --> S[オフライン評価<br/>LLM-as-a-Judge]
    S --> V5[V5: 失敗率16.0%で最小]
    V5 --> A[ライブA/Bテスト]
    A --> R[SSR +4.90pp / tNPS +36.69点]
    R --> D[ブラジル全土へ展開]

もう一つの重要な成果が開発サイクルの加速である。シミュレーション層を導入したCMでは、5バージョンを22日で回し、1バージョンあたり4.4日だった。一方、シミュレーションなしで進めたCDは10バージョンに212日を要し、1バージョンあたり21.2日である。これは約4.8倍の高速化に相当する。100軌跡のシミュレーションバッチは平均10分未満で完了するため、顧客を一切晒さずに何度も仮説を試せる点が速度差の源泉になっている。

事例2：オープンウェイトモデルのスクリーニング

オープンウェイトモデル（重みが公開され、自社環境でホスト・微調整できる大規模言語モデル）をCXエージェントのバックボーンに採用できるかは、コスト・レイテンシ・データ主権の観点から規制産業で関心が高いテーマである。しかし本番A/Bテストでモデルを総当たりするのは、顧客を大量の失敗に晒すことを意味する。そこでシミュレーション層が、モデル選定の「ふるい」として使われた。

対象はカード管理エージェントの29構成で、生成されたシミュレーション会話は16,000件を超える。比較されたのはGPT-OSS-120B、Nemotron-3-Super-120B-A12B、Qwen3.5-122B-A10B、Qwen3.6-35B-A3Bの4モデルで、推論設定（推論を有効にするか、どの程度の強さで行うか）と量子化方式も変数に含まれた。評価は4カテゴリの失敗率で行われ、それぞれ「適切な入力収集」（Input）、「カード再発行の妥当性」（Reissue）、「情報取得状況」（Status）、「会話の完結性」（Complete）を測る。

この表が示す通り、単一の全項目最良構成は存在しない。さらに推論設定の効果はモデルと評価基準に依存する。Nemotronでは推論を強めるとCompleteが60.8%から18.0%へ大きく改善する一方、Statusは21.2%から36.4%へ悪化した。ある基準を良くする操作が別の基準を壊すというトレードオフが、顧客露出ゼロの段階で可視化されたことになる。

flowchart TD
    A[29構成のモデル×推論×量子化] --> B[16,000件超の<br/>シミュレーション会話]
    B --> C{4カテゴリで採点}
    C --> D[Input / Reissue / Status / Complete]
    D --> E[トレードオフを分析]
    E --> F[Qwen3.5-122B-A10B<br/>推論ONを出発点に選定]
    F --> G[弱点 Status 35.2% を<br/>プロンプト最適化で補正]
    G --> H[ライブA/Bテスト]
    H --> I[SSR +8.82pp<br/>p95レイテンシ 25%減<br/>tNPSは有意差なし]

選定では、Qwen3.5-122B-A10Bの推論ON構成が出発点とされた。現行構成と比べてInputは3.2ポイント、Completeは15.0ポイント改善し、Reissueはほぼ同等（25.4%対25.2%）だった。唯一の弱点はStatusで、35.2%対2.4%と大きく劣る。この弱点はプロンプト最適化で補正されたうえでライブ検証に進み、結果はSSRが8.82ポイント改善（95%信頼区間[7.95, 9.69]、n=8.4K）、p95レイテンシが25%減少、tNPSは有意差なし（−1.21点、95%信頼区間[−3.97, 1.55]、n=2.3K）であった。シミュレーションは「全基準で最強のモデル」を保証するものではないが、ライブ評価に進めるだけの根拠を候補に与えるという役割を果たしている。

推論設定と量子化：何が効いて何が効かないか

オープンウェイトモデルを本番エージェントに採用するとき、実務者が最初に悩むのは「どのモデルを選ぶか」よりも「そのモデルをどう動かすか」である。推論（reasoning）を有効にするか、重みを何ビットで量子化するか——この2つの設定はデプロイ構成の自由度を大きく左右する。Nubankの検証では、推論設定はスコアを約11ポイント動かす一方、量子化はこのサンプルサイズでは識別できないという対照的な結果が得られた。ここではNemotron-3-Super-120B-A12Bを対象に、3種類の量子化と3段階の推論設定をスイープした追試結果を整理する。

まず用語を確認しておく。推論設定とは、モデルが最終回答を出す前に思考（chain-of-thought）をどれだけ生成するかを制御するパラメータで、off／onのような段階で切り替える。量子化とは、モデルの重みをbf16（16ビット符号付き浮動小数点）からfp8（8ビット浮動小数点）やnvfp4（4ビットの浮動小数点形式）へ圧縮する手法で、メモリと計算コストを下げる代わりに精度が落ちる可能性がある。

推論を上げると何が改善するのか

追試で最も明確だったのは推論設定の効果である。推論をoffからonへ切り替えると、総合スコア（失敗率の集約値であり、低いほど良い）が42.9から31.3へと単調に改善した。この改善を牽引したのは、回答の巧拙ではなく「検索」だった。会話を進めるのに必要な記録をエージェントが取得できた割合は、推論offで16%、推論onで94%へと跳ね上がる。つまり推論は、もっともらしい文章を作るためではなく、ツールを正しく呼ぶべきタイミングを判断するために効いている。

ただし推論が常に良い方向へ働くわけではない。Nemotronでは会話完結性（Complete）が60.8%から18.0%へ改善した一方、情報取得状況（Status）は21.2%から36.4%へ悪化した。推論を強めるほど、ある基準は良くなり別の基準は悪くなるというトレードオフが生じる。

量子化はスコアを動かさない

対照的に、量子化の効果は明確ではなかった。nvfp4・fp8・bf16の3形式でスコア差はそれぞれ2.2／0.8／4.1ポイントにとどまり、これは同じ固定構成を6回反復したときの標準偏差（2.2ポイント）と同程度である。つまり観測された差は、量子化による系統的な劣化ではなく測定のばらつきの範囲内と解釈できる。

xychart-beta
    title "推論設定と量子化が総合スコアに与える影響（低いほど良い）"
    x-axis ["off", "中間", "on"]
    y-axis "総合スコア" 0 --> 50
    line "bf16" [42.9, 38.0, 31.3]
    line "fp8" [43.5, 37.5, 31.8]
    line "nvfp4" [44.0, 38.5, 32.5]

図は傾向を示す概念図。量子化の系列は誤差範囲内でほぼ重なる。

実務への示唆

この結果が示す優先順位は明快である。まず推論設定を調整し、量子化は後回しにしてよい。推論を有効にするだけで必要記録の取得率が16%から94%へ上がるという差は、量子化のばらつきとは桁が違う。そして、こうした設定スイープを大胆に回せるのは、シミュレーションが顧客露出ゼロで反復できるからにほかならない。推論や量子化の組み合わせを本番A/Bテストで確かめようとすれば、各構成が顧客の失敗に直結するリスクを負うことになる。安全な探索空間があるからこそ、地味だが効くパラメータを網羅的に比較できるのである。

導入の教訓と限界

シミュレーション基盤の価値は、顧客を一人も巻き込まずに反復できる点にある。Nubankの導入では、自動評価器が挙動の退行を検出し、ツール呼び出しの失敗や、そもそもツール呼び出し用パーサを備えていない配信構成といった、人手のレビューでは見落としやすい欠陥が本番前に浮上した。一方で、この仕組みが何を検証し、何を検証しないのかを明確にしておかないと、過信が事故につながる。ここでは実運用から得られた教訓と、設計上受け入れた限界を整理する。

工数の大半は「統合」に消える

導入して最初にわかるのは、シミュレーションの推論そのものより、テスト用エージェントを本番構成に接続する統合作業のほうがコストを占めるという事実である。ステージング環境のエージェントは、本番で使われるMCP（Model Context Protocol）スキーマをそのまま再利用しつつ、状態を持つツールについてはスキーマに整合する合成応答を返すように作られる。この構成を維持するには、ツールのスキーマ・サンプル・認証情報・シミュレータのプロファイルを継続的に突き合わせて更新し続ける必要がある。

同様に、シミュレーションが出力するトレース（会話とツール呼び出しの記録）が、本番のスキーマ・識別子・テレメトリの形式と一致していなければならない。ここがずれると、記録のエクスポートや突合作業に手間がかかり、反復速度を上げて得た利益をそのまま食い潰してしまう。統合と整合の保守は、シミュレーション運用の隠れた固定費だと考えるべきである。

ツール境界で意図的に止める

この手法は、状態変化や副作用を伴うツールをモックに置き換え、顧客データを書き換えない。読み取り専用の依存（ナレッジベース検索など）はライブのまま使えるようにするが、境界の線引きは意図的である。その代償として、次の領域は未検証のまま残る。

flowchart LR
    U[合成ユーザー] --> A[エージェント被験体]
    A -->|呼び出し・引数| B{ツール境界}
    B -->|モック| M[合成応答<br/>検証可能]
    B -->|読み取り専用| L[ライブ依存<br/>検索など]
    M -.->|未到達| S[(本番バックエンド<br/>状態・副作用・レイテンシ)]

位置づけの再確認

こうした限界は欠陥ではなく、設計上の割り切りである。シミュレーションの目的は本番環境の完全な複製ではなく、デプロイ判断を前に進めるのに足る差を炙り出すことにある。したがって、シミュレーション単独で結論を出すのではなく、顧客アウトカムを確認するライブA/Bテストと組み合わせて初めて完結する。安全で速い探索層と、最終確認の層を役割分担させる——これが1.4億ユーザー規模で機能した運用の要点である。

この手法が示すCXエージェント開発の未来

Nubankの事例が投げかける最大のメッセージは、顧客を実験台にしない開発ライフサイクルが現実に回るという点である。従来、モデルの差し替え・推論設定の変更・プロンプトの改訂は、いずれも本番トラフィックに載せて初めて効果が分かるもので、失敗のコストを顧客に負わせるしかなかった。シミュレーションをスクリーニング層として挟むと、29構成・16,000件超という規模の探索を顧客露出ゼロで回せる。これは「安全だから試す」のではなく、「安全に試せるから探索の幅を広げられる」という発想の転換である。

flowchart LR
    H[反証可能な仮説] --> S[顧客露出ゼロの<br/>シミュレーション探索]
    S --> G{事前定義基準を満たすか}
    G -->|満たす| L[ライブA/Bで<br/>顧客アウトカムを最終確認]
    G -->|満たさない| H
    L --> R[本番採用・<br/>次期ベースラインへ]
    R --> H

規制産業にとっての含意は、速度と説明責任の両立である。金融のように意思決定の記録が求められる領域では、「なぜこの候補を採用したのか」を仮説と事前定義基準の形で残せること自体が価値になる。評価器の人手によるキャリブレーションを別途報告する透明性設計も、自動採点の結果を無条件に信用しない姿勢の表れだ。

一般化可能性も高い。カード管理のようなドメイン固有で正解が一意に定まらないタスクでも、外部ツールを境界でモックできるエージェントであれば、同じレシピ——仮説・固定したシミュレータ・同一評価スイート——がそのまま当てはまる。逆に、この型が効かないのはツール境界を切れないエージェント、たとえば副作用と不可分に結合した処理を担う場合である。

残された課題も明確だ。バックエンドの挙動・永続状態・副作用は依然として検証の外にあり、シミュレータの忠実性は時間とともに校正し続ける必要がある。評価器そのものの信頼性も、測れば揺れる性質を持つ以上、定期的な監査なしには前提として置けない。シミュレーションは万能の代替ではなく、ライブ評価と組み合わせて初めて完成する意思決定の道具として定着していくだろう。

よくある質問

シミュレーションと本番A/Bテストはどちらを優先すべきですか？

どちらかを選ぶという問いではなく、役割が違うと考えるのが実態に即している。シミュレーションは多数の候補を顧客露出ゼロで広く探索し、有害な差を炙り出す「スクリーニング層」であり、ライブA/Bテストは実際の顧客アウトカムを最終確認する層である。Card Managementの事例でも、オフライン評価で選ばれた候補をライブA/Bで検証する流れが取られていた。小さく曖昧な差はシミュレーションでは判別せず、ライブ実験に委ねるのが設計上の原則になっている。

合成ユーザーは本物の顧客とどの程度似ているのですか？

完全には似ていない、という前提で使う。会話長は実顧客の中央値19語・3ターンに対し、シミュレーションは中央値111語・6ターンと大幅に長く、専門家7名によるブラインド判別でも合成の30%が本番と誤認された程度である。一方で、5カテゴリの評価器で採点した際のバージョン間の良し悪しの順序は本番と高い相関（Pearson r=0.74、Kendall τ=0.67）を示し、方向性の判断には使える。忠実性の絶対値ではなく、相対比較の安定性を信用するのが正しい使い方だ。

ツールをモックすると、何がテストされないまま残りますか？

バックエンドの実際の挙動、レイテンシ、永続状態、副作用である。ツール境界の呼び出しだけを模擬するため、同じレコードを二度問い合わせても中間アクションなしに状態が変わらない整合性ルールは検証できるが、ツール自体の実装品質は別手段に委ねる設計になっている。読み取り専用の依存（ナレッジベース検索など）はライブのまま残せるため、検証範囲は「対話とツール境界」までと明確に線引きされている。

オープンウェイトモデルは本番品質に達しますか？

条件付きで達する。Qwen3.5-122B-A10B（推論ON）はライブA/BでSSR（人間サポートを求めず自力で完了したセッションの割合）を8.82pp改善し、tNPSは有意差なし、p95レイテンシは25%減だった。ただし単一モデルが全評価カテゴリで最良になることはなく、弱点をプロンプト最適化で補正する工程が前提となる。シミュレーションは「全基準で最強」を保証しないが、ライブ評価に値する候補を根拠づける役割を担う。

なぜ量子化より推論設定のほうが重要なのですか？

追試では、推論をoff→onに切り替えると総合スコアが42.9から31.3へ単調に改善し、その主因は必要記録の取得率が16%から94%へ跳ね上がったことだった。一方、量子化（nvfp4 / fp8 / bf16）の差は数ポイントにとどまり、固定構成で6回反復したときの標準偏差と同程度で、このサンプルサイズでは識別できなかった。顧客露出ゼロで設定スイープを回せるからこそ、こうした優先順位を大胆に確かめられる。

まとめ

顧客対応AIエージェント（CXエージェント）の改善において、シミュレーションの価値は「本番環境の複製をつくること」ではなく「顧客に触れる前の意思決定層を用意すること」にある。人手によるテストケース作成は網羅性に限界があり、本番A/Bテストは顧客を失敗に晒す。この二択の間に、合成ユーザーがエージェントの応答に反応し、ツール出力も合成してバックエンドを呼ばずに多段ワークフローを再現するシミュレーションを挟み込むことで、展開判断に必要な情報を顧客露出ゼロで得られる。

この手法が機能する鍵は、忠実性の追求ではなく手順の規律にある。反証可能な仮説を立て、合格基準を事前に定義し、候補間でシミュレータ構成を固定し、同一の評価スイートで採点する。ベースラインは候補が現行版になった時点で初めて更新する。こうした規律が、productionメトリクスの正確な複製という過剰な要求を回避しつつ、判断を前に進める根拠を与える。

一方で、この手法が確かめられない範囲も明確である。ツール境界で意図的に止める設計を採るため、バックエンドの実際の挙動、レイテンシ、永続状態、副作用は未検証のまま残る。合成ユーザーの会話は実顧客より大幅に長く、専門家でも合成の一部を本番と誤認する程度の忠実性である。したがって、シミュレーションはあくまで候補を広く探索して有害な差を炙り出すスクリーニング層として使い、最終的な顧客アウトカムの確認はライブA/Bテストに委ねる。この役割分担を崩さないことが、規制産業で反復速度と説明可能性を両立させる実務上の要点になる。

参考資料

• Screen Before You Serve: Simulation for Production Customer Experience AI Agents at 140M Scale（arXiv）: https://arxiv.org/abs/2609.30137v1
• 論文 HTML 全文: https://arxiv.org/html/2609.30137v1
• Guardrails AI Snowglobe 製品ページ: https://guardrailsai.com/snowglobe
• τ-bench: https://arxiv.org/abs/2406.12045
• τ²-Bench: https://arxiv.org/abs/2506.07982
• SimulatorArena: https://aclanthology.org/2025.emnlp-main.1786/
• RealUserSim: https://arxiv.org/abs/2605.20204
• Generative Agents（Park et al. 2023）: https://arxiv.org/abs/2304.03442
• How reliable is your simulator?（Zhu et al. 2024）: https://arxiv.org/abs/2403.16416
• GEPA: https://arxiv.org/abs/2507.19457

関連記事

• AIエージェントは「客」の味方か「店」の味方か——インセンティブ不整合なマーケットプレイスで購入成功率が78.6%→17.3%に急落するCAVEATの警告
• マネーフォワードが描くフィンテック2.0――クラウド会計からAI資産管理へ、SaaSの次なる進化
• 脱炭素の「実利」への回帰：2026年以降の現実的なGX戦略