> 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.

# ElevenAgents Architectの仕組み

## 概要

ElevenAgents Architectの会話は、構築したエージェントと同じエンジン上で動作するリアルタイムのElevenAgents会話です。Architectのツールは、サインイン中のセッションでブラウザ内で実行されます。各ツールはダッシュボードと同じElevenAgents APIを呼び出すため、すべての読み取りと書き込みは自身の権限に照らして確認されます。[権限、承認、下書き](/docs/ja/eleven-agents/operate/architect/authentication)をご覧ください。

## ElevenAgents Architectがデフォルトで把握している情報

各会話の開始時に、Architectは次の情報を受け取ります。

* **アカウントとワークスペース**：プラン、ワークスペース、使用状況。
* **現在地**：開いているページと、エージェント内にいる場合はそのエージェントおよび開いているブランチ。サイドバーでは、Architectはページのスナップショットも取得し、ページが変更された場合は各メッセージの前に更新を受け取ります。
* **エージェントの概要**：エージェント内にいるときにElevenLabsが作成します。エージェント名とオーナー、ブランチとトラフィック分割、過去7日間の通話数、下書きの状態、接続済みエージェント、プロシージャ、テストの設定有無、編集可能なブランチを含みます。
* **エージェントコンテキスト**：エージェントを構築する全員と共有される、エージェントの`agents.md`ドキュメント。[Architectのカスタマイズ](/docs/ja/eleven-agents/operate/architect/customization)をご覧ください。
* **設定**：構築するすべてのエージェントに適用される、個人用の`user.md`ドキュメント。
* **開始元から渡された情報**：たとえば、失敗したテスト、Spotlightの検出事項、トリアージチケットなどです。[会話を開始する](/docs/ja/eleven-agents/operate/architect/entry-points)をご覧ください。
* **このチャット内の以前のメッセージ。**

Architectは、エージェントの完全な設定、トランスクリプト、テスト結果、Spotlightデータ、他のArchitectチャットを最初から保持しているわけではありません。タスクで必要になったときにツールでこれらを読み取ります。これにより各会話に集中でき、Architectは常に古いコピーではなく最新のデータに基づいて作業します。

## 調査と直接指示

Architectは、2種類のリクエストを異なる方法で処理します。

**直接指示**では、たとえば「競合他社の価格に関する会話をブロックするガードレールを追加して」や「最初のメッセージを短くして」のように変更内容を指定します。Architectは関連する設定を読み取り、編集を行い、ステージングした内容を報告します。デフォルトの承認モードでは、エージェント設定の編集は確認なしで下書きにステージングされます。本番トラフィックや共有リソースに影響する操作は、承認まで保留されます。

**調査**では、たとえば「返金に関する通話がエスカレーションされるのはなぜ？」や「返金の解決率を改善するには？」のように、修正内容を指定せずに質問します。Architectは変更を行う前に調査します。

* 調査用の**todoリスト**を作成し、項目が完了するたびにコンポーザーの上部で確認できます。
* 個々のトランスクリプトを読む前に、会話数、トピック、評価結果など、低コストのシグナルから始めます。
* 会話を並行して分析し、発見事項を根本原因別にグループ化します。
* 推論を確認できます。各推論ステップは**Thought for Ns**として折りたたまれ、展開できます。
* 実際に読んだ会話数を含め、発見事項を報告します。サンプルを網羅的なものとして提示することはありません。

### プランモード

大規模な変更では、コンポーザーを**Plan**に切り替えてください（<kbd>Shift</kbd>+<kbd>Tab</kbd>でモードを切り替えられます）。プランモードでは、Architectは読み取り専用ツールで調査し、作成過程を確認できるプランを作成した後、**Approve plan**または**Reject**を求めます。承認するまで変更は行いません。メモ付きでプランを却下すると、Architectは修正して再度確認を求めます。

全画面のArchitectタブでは、プランはコンポーザーの上にあるパネルに表示されます。サイドバーでは、チャット内のカードとして表示されます。

## 実践例：返金の解決率を改善する

この例では、広範な質問からレビュー可能な変更までの一つの会話を追います。会話内に表示される各ステップと対応付けられるよう、ツール名を示しています。Architectは独自にステップを選択するため、実際の会話では順序や詳細が異なる場合があります。

エージェントのArchitectタブから送信するリクエスト：

> 返金の解決率を改善するには？

#### 調査を計画する

Architectはtodoリスト（`write_todos`）を作成します。問題を測定し、失敗した返金に関する
会話を見つけ、根本原因を特定し、修正を提案してテストします。

#### 問題を測定する

Architectはエージェントのトピック（`get_agent_topics`、`get_topics_summary`）を読み取り、返金
トピックとその成功率を確認します。その後、評価に失敗した最近の返金に関する会話をカウントして一覧表示します
（`count_conversations`、`list_conversations`）。

#### 会話を読む

Architectは返金リクエストをトランスクリプトから検索し（`search_conversation_messages`、
`semantic_search_conversations`）、失敗した会話のバッチを並行して分析します
（`analyze_conversation_subagent`）。各分析では、ユーザーの目的、エージェントが誤った箇所、
それが起きたターンを報告します。

#### 根本原因を特定する

Architectは失敗内容を現在の設定（`get_agent_config`、
`list_procedures`、`get_procedure`）と比較します。たとえば次のような結果を報告します。「失敗した返金
通話40件のうち31件で、エージェントは注文番号を尋ねる前に`lookup_order`を呼び出し、エラーになって
エスカレーションしました。」

#### ブランチで変更する

Architectは、本番エージェントから変更を分離するためにブランチ（`create_branch`）を作成します。続いて、
検索の前に注文番号を尋ねるよう返金プロシージャ（`update_procedure`）を編集します。編集内容は、そのブランチ上の
下書きにステージングされます。本番の発信者には何も変更されません。

#### 変更のテストを書く

Architectは、失敗を再現するテストを作成します。注文番号を伝えずに返金を求める発信者のシミュレーション
（`create_simulation_test`）、`lookup_order`が最初に呼び出されないことを確認するツール呼び出しテスト
（`create_tool_test`）、実際に失敗した会話の一つから生成するテスト（`generate_test_from_conversation`）です。
Architectはシミュレーションで副作用のあるツールをモックするため、実際の返金処理は行われません。

#### 変更前後でテストを実行する

Architectは変更なしのエージェントでテストを実行し（元のブランチで`run_tests`、または`include_draft: false`を指定した
`run_agent_tests`）、次に変更を含む下書きで実行します（`run_agent_tests`）。結果を読み取ります
（`get_test_suite_summary`、`get_test_suite_failures`）。想定される結果は、新しいテストが変更前には失敗し、
変更後には成功することです。テストがまだ失敗する場合、Architectは失敗内容を読み取り、変更を調整して
再実行します。

#### 変更を提示する

Architectは根本原因、変更内容、テスト結果を要約し、公開ダイアログ（`request_draft_publish`）を開きます。
差分を確認して**Publish**を選択すると、変更はブランチ上の新しいバージョンとしてコミットされます。
Architectが代わりに公開することはできません。

#### 提案を作成する

Architectはブランチの履歴とマージプレビュー（`get_branch_history`、
`merge_branch_preview`）を読み取り、`main`へのマージ提案（`create_merge_proposal`）を作成します。
説明には、実際のコミットとテスト実行に基づく**Summary**、**Testing**、**How to review**の3つの
セクションが含まれます。Architectはレビュー担当者を提案できます
（`suggest_merge_proposal_reviewers`）が、選択するのはあなたです。

#### 段階的なロールアウトを提案する

Architectは、提案のレビュー中に、本番トラフィックの一部（通常は5%）をブランチに送ることを提案します
（`set_traffic_split`）。これは本番トラフィックを変更するため、承認まで保留されます。

検証は、公開やレビューを求められる前に会話内で行われます。提案がレビュー担当者に届く時点で、変更の根拠となったテストはすでにエージェントに追加され、ブランチ上で実行済みです。レビュー担当者に表示される内容については、[提案と検証](/docs/ja/eleven-agents/operate/architect/proposals)をご覧ください。

> **Tip**
>
> 変更前後のテスト実行は推奨される方法ですが、Architectがすべての変更に対して自動で実行するわけではありません。
> 必ず実行するには、たとえば「新しいテストがmainでは失敗し、ブランチでは成功することを見せて」と直接依頼してください。

![Architectの作業トレース](/docs/_fern-img/a0ac226f441713105d638105f3ca8fd93ad672556b6ae0ae48847d1de8c7ba8d.webp)

## スラッシュコマンド

コンポーザーで`/`を入力すると、現在のページで利用できるコマンドが表示されます。

| コマンド          | 内容                                                       |
| ------------- | -------------------------------------------------------- |
| `/start`      | Architectが目標を把握できるよう、このエージェントのコンテキスト（`agents.md`）を設定します。 |
| `/generate`   | 説明から新しいエージェントを生成します。                                     |
| `/debug`      | 最近失敗した会話をデバッグします。                                        |
| `/test`       | テストを実行し、結果を要約します。                                        |
| `/explain`    | このエージェントの機能をわかりやすい言葉で説明します。                              |
| `/optimize`   | プロンプトと設定の改善案を提案します。                                      |
| `/review`     | エージェントのパフォーマンスを確認し、改善点を見つけます。                            |
| `/branch`     | このエージェント用の新しいブランチを作成します。                                 |
| `/experiment` | ブランチを作成し、A/Bテストとしてデプロイします。                               |
| `/rollback`   | 最近の設定変更を確認し、必要に応じて元に戻します。                                |
| `/remember`   | エージェントの情報をナレッジベースドキュメントとして保存します。                         |
| `/dashboard`  | チャット内にカスタム分析ダッシュボードを作成します。                               |
| `/clear`      | この会話を消去して、新しく開始します。                                      |
| `/feedback`   | このセッションに関する非公開のフィードバックをElevenLabsに送信します。                 |

ほとんどのコマンドは、エージェント内にいる場合にのみ適用されます。`/clear`と`/feedback`は、Architectタブのホームページでは利用できません。

## チャット内のダッシュボード

Architectは会話内にダッシュボードを作成し、たとえば「今週のエスカレーションを理由別に分類して傾向を表示して」のようなデータに基づく質問に答えられます。`/dashboard`を使用するか、直接作成を依頼してください。

Architectはツールでデータを収集し、[コード](#running-code)で整形して、Spotlightと同じメトリックタイル、チャート、リスト、テキストカードで構成されるダッシュボードをレンダリングします。ダッシュボードには次の内容を含められます。

* 見出し値、変化、スパークラインを含む**メトリックタイル**。
* **チャート**：エリア、折れ線、棒、積み上げエリア、ドーナツ、および上位N件の内訳を示すランク付き棒グラフ。
* ステータスラベル、日付、個々の会話などElevenAgents内のページへのリンクを含む**リスト**。
* 分析結果と推奨事項用の**テキストカード**。

全画面のArchitectタブでは、ダッシュボードは会話内にインラインでレンダリングされます。サイドバーでは、チャットの横にあるパネルで開きます。

ダッシュボードのデータは、作成したブラウザタブのメモリ内にのみ保持され、チャットとともに保存されることはありません。ページを再読み込みしたり、別のタブでチャットを開いたり、複数の大きなダッシュボードを作成したりすると、古いダッシュボードではデータの代わりにメッセージが表示されます。Architectに再作成を依頼してください。ダッシュボードは読み取り専用のスナップショットです。フィルターはなく、ライブ更新もされません。

## コードを実行する

Architectは、ツールからのデータをカウント、グループ化、比較する短いPythonプログラムを実行できます。たとえば、数百件の会話にわたる週ごとの解決率を計算できます。コードはブラウザ内のサンドボックスで実行され、Python標準ライブラリのみを使用します。ネットワークアクセス、ElevenLabsアカウントへのアクセスはなく、制限時間は20秒です。コード実行は段階的に提供されており、すべてのワークスペースで利用できるとは限りません。

## 大きなレスポンス

長い会話リストなど、ツールから返されるデータが会話に収まりきらない場合、Architectは完全なレスポンスをブラウザタブのメモリに保持し、要約を使用して作業します。必要に応じて残りを検索・読み取りできます。これが発生した場合は、ツール呼び出しの通知に表示されます。これらのレスポンスが保存またはアップロードされることはありません。