> This is a page from the ElevenLabs documentation. For a complete page index, fetch https://elevenlabs.io/docs/llms.txt. For the full documentation in a single file, fetch https://elevenlabs.io/docs/llms-full.txt.

# 実験

実験では、トラフィックの一定割合をバリアントに振り分け、主要な成果への影響を測定し、勝者を本番環境に昇格させることで、プロンプト構造、ワークフローロジック、音声、個性、ツール、ナレッジベースなど、エージェント設定のあらゆる側面で管理されたA/Bテストを実行できます。

> **Note**
>
> 実験は[エージェントのバージョン管理](/docs/ja/eleven-agents/operate/versioning)を基盤に構築されています。
> 実験を実行する前に、エージェントでバージョン管理を有効にする必要があります。

## 実験する理由

体系的な実験がなければ、最適化は直感頼みになります。プロンプトの調整で「良くなった気がする」。ワークフローの調整で自己解決率が「改善するはず」。新しいエスカレーション経路が「より効率的に見える」。

実験は推測を根拠に置き換えます。実際のトラフィックに対して変更をテストし、現実の結果を測定して、機能するものを昇格させます。

## 仕組み

実験は次の4ステップで行います。

#### バリアントを作成

現在のエージェント設定を起点に、新しいブランチを作成します。システムプロンプト、ワークフロー、音声、ツール、ナレッジベース、ガードレール、評価基準など、あらゆる項目を変更できます。各変更はバージョン管理された設定として追跡されます。

エージェント設定の**Branches**タブに移動し、**Create branch**をクリックします。

#### トラフィックを振り分け

バリアントに送るライブ会話の割合を定義します。リスクを抑えるために少ない割合（5～10%）から始め、自信が高まるにつれて増やします。

**Edit traffic split**をクリックし、各ブランチの割合を設定します。割合の合計は必ず100%ちょうどにする必要があります。

![ブランチ間のトラフィック分割を設定](/docs/_fern-img/0d4fd1ae53a2fec09bf7572d4bbf4341c1c183cbf9b3618807f91ede1dd126ee.webp)

#### 影響を測定

[分析ダッシュボード](/docs/ja/eleven-agents/dashboard)を使用して、バリアントのパフォーマンスをベースラインと比較します。ブランチパネルの**See analytics**をクリックすると、ブランチでフィルタリングされたビューに直接移動できます。

![トラフィック分割とマージオプションを含む、メインブランチとバリアントブランチを表示するブランチパネル](/docs/_fern-img/26946acc8b602c4dc66fd1b2312ffbbc09faa83d5b59b6d42ec7538e8ac1d60a.webp)

チームは次のような成果を測定できます。

* CSAT
* 自己解決率
* コンバージョン
* 平均対応時間
* エージェント応答レイテンシの中央値
* エージェントによる解決1件あたりのコスト

#### 勝者を昇格

バリアントが測定可能な改善を示したら、そのトラフィック割合を増やすか、メインブランチにマージして新しいデフォルトにします。完全なバージョン履歴が保持されるため、必要に応じてロールバックできます。

## トラフィックルーティング

トラフィックは割合に応じてブランチ間で分割されます。ルーティングは会話IDに基づく**決定論的**なものであるため、同じユーザーはセッションをまたいでも常に同じブランチに到達します。

デフォルトでは、トラフィックはユーザーベース全体でランダムに振り分けられます。APIを使用して会話を開始する場合は、どのブランチ設定で会話を開始するかを制御することで、特定のコホートを特定のブランチに振り分けられます。

> **Warning**
>
> すべてのトラフィック割合の合計は、必ず100%ちょうどにする必要があります。そうでない場合、デプロイは失敗します。

## ユースケース

実験は、顧客向けワークフローと運用ワークフロー全体で継続的な最適化をサポートします。

#### 顧客体験

改訂したエスカレーションフローが、対応時間を増やさずにCSATを改善するかテストします。
さまざまな挨拶スタイル、共感の度合い、解決戦略を比較できます。

#### 収益

より直接的な口調や異なる適格性判定ロジックがコンバージョンを高めるかテストします。
異議への対応、価格の提示方法、フォローアップのタイミングを試せます。

#### 運用

ツールロジックの変更によって平均対応時間やインフラコストが削減されるか測定します。
さまざまなナレッジベース設定やワークフロー構造をテストできます。

各実験は特定のエージェントバージョンに紐づいているため、すべてのパフォーマンス変化を明確に定義された設定変更に帰属させられます。

## テストできる項目

エージェント設定のあらゆる側面をブランチ間で変えられます。

| カテゴリ          | 例                            |
| ------------- | ---------------------------- |
| **システムプロンプト** | 口調、指示、個性、ガードレール              |
| **ワークフロー**    | ノード構造、分岐ロジック、エスカレーション経路      |
| **音声**        | 音声の選択、TTSモデル、速度設定            |
| **ツール**       | ツール設定、Webhookツールロジック、MCPサーバー |
| **ナレッジベース**   | 異なるドキュメント、RAG設定              |
| **LLM**       | モデルの選択、温度、最大トークン数            |
| **評価基準**      | ブランチごとに異なる成功指標               |
| **言語**        | 言語設定、多言語設定                   |

## ベストプラクティス

#### 仮説から始める

バリアントを作成する前に、何が改善すると予測するか、その測定方法を定義します。たとえば、
「問題の要約を含めるようエスカレーションプロンプトを変更すると、解決率の評価基準が10%改善する」とします。

#### 一度に変更するのは1つだけ

変数を1つに絞ると、パフォーマンス差の原因が明確になります。プロンプト、音声、ワークフローを同時に変更すると、どの変更が結果につながったのか分かりません。

#### まず評価基準を設定する

実験を実行する前に、[成功 評価](/docs/ja/eleven-agents/customization/agent-analysis/success-evaluation)の基準を設定します。これにより、バリアントを客観的に比較するために必要な構造化された指標を得られます。

#### 少ないトラフィック割合から始める

バリアントへのトラフィックを5～10%から始めます。問題が発生した場合の影響を抑えつつ、意味のあるデータを生成できます。

#### 実験に十分な時間をかける

結論を出す前に、十分な数の会話が蓄積されるようにします。サンプルサイズが小さいと、結果の信頼性が低くなります。分析ダッシュボードを監視し、傾向が安定するのを待ちます。

#### 実験を長期間放置しない

実験は速やかにマージまたは破棄します。長期間続くブランチはマージが難しくなり、メイン設定との差が広がる可能性があります。

## 次のステップ

#### [バージョン管理](/docs/ja/eleven-agents/operate/versioning)

基盤となるバージョン管理システム（ブランチ、バージョン、APIリファレンス）について学ぶ

#### [分析](/docs/ja/eleven-agents/dashboard)

分析ダッシュボードで実験のパフォーマンスを監視する

#### [成功評価](/docs/ja/eleven-agents/customization/agent-analysis/success-evaluation)

実験の成果を測定するためのカスタム成功基準を定義する

#### [テスト](/docs/ja/eleven-agents/customization/agent-testing)

ブランチを作成する前に自動テストを設定し、ベースラインを確立する