提案と検証
提案と検証
Architectによる変更をテスト、レビューし、ライブトラフィックに展開する方法。
概要
Architectが変更を完了すると、提案として引き渡されます。提案には、変更を含むブランチ、動作を示すテスト、そしてそのブランチをmainへマージするよう求めるマージ提案が含まれます。このページでは、各要素の仕組み、確認場所、提案が会話からライブトラフィックに至るまでの流れを説明します。
提案とは
提案は、既存のバージョニングモデルに基づいて作成されます。
マージ提案は、チームメイトが手動で作成するものと同じ、標準的なElevenAgentsのマージ提案です。別のオブジェクトタイプではありません。
マージ提案は、1つのソースブランチと1つのターゲットブランチを対象とするため、1つの提案には1つの候補ソリューションが含まれます。代替案を比較するには、Architectに各案を別々のブランチに作成するよう依頼してください。各ブランチにはそれぞれ提案が作成され、実験としてトラフィックを分割できます。
Architectはあなたとして操作するため、Architectが作成したマージ提案の作成者はあなたの名前で記録されます。Architectが作成したことを記録するフィールドはありません。チームで把握したい場合は、提案の説明に記載してください。
提案の作成方法
Architectは、何かの修正や改善を依頼したとき、あるいは失敗したテスト、Spotlightの検出結果、トリアージチケットを渡したときに提案を作成します。各ステップでArchitectが呼び出すツールを含む一連の流れは、実例を参照してください。概要は次のとおりです。
- Architectが調査し、ブランチを作成して、そのブランチ上の下書きに変更をステージングします。
- Architectが変更用のテストとシミュレーションを作成し、結果を表示する前に会話内で実行します。
- Architectが公開ダイアログを開きます。差分を確認して公開を選択すると、変更がブランチ上の新しいバージョンとしてコミットされます。
- Architectが
mainへのマージ提案を作成し、ブランチの実際のコミットとテスト実行結果に基づいて説明を記述します。 - 提案のレビュー中に、ライブトラフィックの一部をブランチへ送ることをArchitectが提案します。これには承認が必要です。
どのステップで止めても構いません。公開済みバージョンがあってもマージ提案がないブランチは有用です。自分でテストしたり、あとで提案を作成したりできます。
会話内での検証
Architectは、後から別途開始するステップとしてではなく、変更を作成する過程でテストを作成・実行します。修正では、新しいテストが変更前には失敗し、変更後には成功することを示すのが有効なパターンです。Architectは、元のブランチと変更を含む下書きの両方に対して同じテストを実行できます。
Architectはすべての変更に対して、この変更前後のチェックを自動実行するわけではありません。重要な場合は、たとえば「新しいシミュレーションがmainでは失敗し、ブランチでは成功することを示してから、提案を作成して」と依頼してください。
すべての成功条件を満たすと、テストは成功します。LLMテストでは、エージェントの応答が成功基準を満たしている必要があります。ツール呼び出しテストでは、想定されたツールが想定されたパラメータで呼び出される必要があります。シミュレーションでは、シミュレートされた会話が成功条件を満たしている必要があります。不安定な結果を確認するには、Architectにテストを複数回実行するよう依頼してください。各テストは最大50回繰り返し、成功率を報告できます。
各テストタイプの定義については、テストを参照してください。
提案の確認場所
エージェントを開き、バージョン管理 > 提案に移動します。一覧は、ステータス、作成者（Created by）、レビュー担当者（Awaiting review from、Reviewed by）で絞り込めます。会話内でArchitectが作成した提案は、あなたが作成者として表示されます。
Architectは、提案を作成するとすぐに会話内でその提案へのリンクも返します。
提案の構成
提案ページには、ソースブランチとターゲットブランチ、ステータス、マージ可能かどうか、ソースブランチがターゲットよりどの程度遅れているか、または進んでいるかが表示されます。以下のタブがあります。
概要
変更
テスト実行
会話
説明、ソースブランチ上のコミット・レビュー・コメントのアクティビティタイムライン、コメントボックスを確認できます。サイドバーには、レビュー担当者、推奨レビュー担当者、リンクされたトリアージチケットが表示されます。
Architectが記述する説明には、必ず3つのセクションがあります。概要（各重要な変更とその理由）、テスト（実行したテストと結果、または未実行である旨）、レビュー方法（注目すべき点と、実行するテストまたは試す会話）です。
レビューとマージ
ステータス
マージ提案には、次のいずれかのステータスがあります。
提案がオープン中の場合、各レビュー担当者の最新レビューは承認済みまたは変更をリクエストのいずれかです。「テスト済み」や「レビュー準備完了」といった個別のステータスはありません。テスト結果は、代わりにテスト実行タブに表示されます。
レビューとコメントは、ソースブランチにコミットされた各新しいバージョンとともに、概要タブのアクティビティタイムラインに表示されます。
承認・マージできるユーザー
- 提案の作成者以外であれば、エージェントへの編集者アクセス権を持つ誰でも提案をレビューできます。Architectはあなたとして操作するため、会話内でArchitectが作成した提案は承認できません。チームメイトによる承認が必要です。
- 作成者以外から少なくとも1件の承認があり、かつどのレビュー担当者の最新レビューも変更をリクエストではない場合、提案をマージできます。ワークスペース管理者は承認なしでマージできます。
- 保護されたブランチへのマージには、管理者権限、または管理者からの承認が必要です。
Architectは、マージ提案の承認、コメント、マージ、クローズを行えません。これらのステップは常に人が実行します。レビューのルール全体については、マージ提案を参照してください。
Architectは、依頼され、かつロールにマージ権限がある場合、提案なしでブランチを直接マージできます。承認が必要モードでは、先に確認を求めます。自動承認モードでは求めません。すべての変更をレビュー済みの提案経由にする必要がある場合は、mainでブランチ保護を使用してください。
マージ時に起こること
マージ後に別途公開する必要はありません。マージするとターゲットブランチに新しいバージョンが作成され、そのバージョンはターゲットが受け取るトラフィックの割合に応じてすぐにライブトラフィックを処理します。ターゲットがmainでトラフィック分割が設定されていない場合、すべての通話者が対象となります。
マージにより、次のことも行われます。
- ソースブランチが受け取っていたライブトラフィックの割合をターゲットへ移します。
- デフォルトでソースブランチをアーカイブします。
- 同じブランチからの他のオープン中の提案をすべてクローズします。
- リンクされたトリアージチケットがある場合、それを解決します。
段階的ロールアウト
提案をマージする前に、ライブトラフィックの一部をそのブランチに送信し、実際の通話者に変更を利用してもらうことができます。
トラフィックの割合は常に合計100%である必要があり、ルーティングは会話ごとに決定的です。保護されたmainからトラフィックを移す場合を含め、保護されたブランチの割合を変更するには管理者権限が必要です。トラフィックのデプロイを参照してください。
プロアクティブな提案
Architectは、依頼したとき、または失敗したテスト、Spotlightの検出結果、アラート、トリアージチケットを渡したときに提案を作成します。現時点では、スケジュールに基づいてエージェントをスキャンしたり、自動で提案を作成したりすることはありません。
現在のプロアクティブな流れは、Spotlightと、その後の引き渡しです。Spotlightはエージェントの会話を継続的に監視します。調査候補を含む週次サマリーを作成し、リアルタイムアラートを発生させ、設定変更を推奨します。Spotlightの検出結果を提案に変えるには、次の手順を実行します。
トリアージチケットも同じように機能します。ライブエージェントは会話中にレビュー用の問題をフラグ付けでき、チケットのArchitectと相談を選択すると、その問題の調査が始まります。
Architectの受信トレイにレポートを配信するスケジュール済み自動化は開発中です。Architectページの受信トレイタブは、そのためのプレースホルダーです。