GitHub Copilot CLIの委任の選択性を高めた方法

エージェントシステムでは、過剰な委任は必ずしも良いとは限りません。Copilot CLIに簡単な変更を依頼したと想像してください。それを直接処理せずに、ヘルパーエージェントを起動し、リポジトリを検索して結果を待ち、停止してしまいます。1ステップで済む作業が3ステップになってしまいます。しかし、一部のタスクは専門のサブエージェントの恩恵を受けます。例えば、馴染みのないリポジトリの探索、コードの独立した領域のチェック、メインエージェントが動き続ける間に長時間のコマンドを実行する場合などです。委任にはコストが伴います。引き継ぎごとに調整のオーバーヘッド、ツール呼び出し、待機時間が発生します。エージェントが過度に委任すると、「助け」が摩擦になる可能性があります。

私たちは最近、「スマートサブエージェント委任」と呼ばれる改善をリリースしました。これにより、Copilot CLIはより選択的になり、メインエージェントが以下のことを行えるようになります。

• 自分でより速く進められる場合に集中力を維持する。
• 専門家が真のレバレッジを生み出す場合に委任する。
• タスクが真に独立している場合に作業を並列化する。

スマートサブエージェント委任は現在、Copilot CLIの全プロダクショントラフィックに展開されています。今すぐ始めたい場合は、ターミナルで/updateコマンドを実行し、GitHub Copilot CLIをバージョン1.0.42以降に更新してください。

プロダクションA/Bテストでは、この改善によりセッションあたりのツール障害が23%削減され、検索ツール障害が27%、編集ツール障害が18%削減されました。また、P95での総ユーザー待機時間が5%、P75で3%改善され、品質の低下は見られませんでした。ここでP95は最も遅い5%のセッションの待機時間を、P75は典型的なセッションの遅い側の待機時間を示します。これは、不要な引き継ぎ、繰り返しの検索、障害が発生しやすいツールパス、長時間のコーディングタスク中の待機時間が減少したことを意味します。

この記事では、Copilot CLIの不要な委任をどのように特定したか、委任をより選択的にするためにどのような変更を加えたか、オフライン評価とプロダクションA/Bテストを通じてそれらの変更をどのように検証したかを説明します。また、それらの変更が障害の減少と待機時間の短縮につながった理由と、Copilot CLIを日常的に使用する開発者にとってどのような意味を持つかを示します。

問題：委任は強力だが無料ではない

サブエージェントはエージェント型CLIの最も重要な機能の1つです。Copilotが複雑な作業を分解し、調査を並行して実行し、メインエージェントが最終的な回答の調整に集中できるようにします。大規模なコードベースや複数ステップのエンジニアリングタスクでは、これが低速な線形ワークフローと効率的な並列ワークフローの違いになる可能性があります。

しかし、委任は独自の障害モードを導入します。

• メインエージェントが単独でより速く完了できる簡単なタスクへの不要な引き継ぎ。
• 引き継ぎに十分なコンテキストがすでに含まれている場合の探索サブエージェントの過剰使用。
• メインエージェントとサブエージェント間の重複した検索。
• メインエージェントがサブエージェントを待機する順次委任（並列作業の機会を逃す）。
• 古いファイルパス、移動されたファイル、不適切な相対パス、ワークスペースの不一致など、障害が発生しやすいサブエージェントパス。

図1は、メインエージェントがアイドル状態にある間にサブエージェントがツール呼び出しに失敗する例を示しています。

私たちの目標は、サブエージェントがレバレッジを生み出す場合に使用し、オーバーヘッドを追加する場合に回避し、タスクが独立した実行から真に利益を得る場合に作業を並列化できるように開発者を支援することでした。

問題シグナルからリリースされた改善へ

問題を特定した方法が、それを解決する方法にもなりました。エージェントの軌跡分析、製品変更、評価、ロールアウトを別々の活動として扱う代わりに、それらを1つのフィードバックループとして使用しました。エージェントの動作を観察し、オーケストレーションのボトルネックを特定し、的を絞った変更を加え、オフラインで検証し、オンラインで測定し、エンドツーエンドのワークフローが改善された場合のみリリースしました。

図2は、エンドツーエンドの改善ループ（分析、変更、検証、リリース）を示しています。

1. 分析：LLMを使用して委任のボトルネックを特定

エージェントセッションを手動でレビューする代わりに、LLMを使用して完全な軌跡を分析し、オーケストレーションが役立っている場所とオーバーヘッドを追加している場所を特定しました。その分析により、一貫したパターンが明らかになりました。サブエージェントは、すでに狭く、明白で、引き継ぎで完全に記述されているタスクに対して呼び出されることがありました。

そのような場合、サブエージェントは、メインエージェントが直接行動するのに十分なコンテキストをすでに持っているにもかかわらず、リポジトリの再検索に時間を費やす可能性がありました。これにより、改善目標が明確になりました。単純な発見および編集タスクはメインエージェントに保持し、サブエージェントはより広範で、分野横断的、または自然に並列化可能な作業のために予約します。

2. 変更：オーケストレーションポリシーの改良

ボトルネックを特定した後、LLMを使用してその診断をより選択的なオーケストレーションポリシーに変換しました。

Copilot CLIは、集中した作業を直接処理する必要があります。ファイルの検索、読み取り、対象を絞った変更、検証などです。委任は、独立したコンテキスト、広範な探索、または並列実行が必要な場合に役立ちます。

実際には、最も狭い効果的なパスから始め、複雑さや不確実性が価値を生み出す場合にエスカレートし、タスクが再び集中した場合に戻すことを意味します。サブエージェントは一時停止ボタンではなく、並列化ツールとして扱うべきです。Copilotがサブエージェントを起動するとき、メインエージェントは結果を待つだけでなく、独立した作業を続行する必要があります。

サブエージェントが使用される場合、引き継ぎは具体的である必要があります。ユーザーが尋ねたこと、既にわかっていること、サブエージェントが担当すること、メインエージェントが返す必要がある結果の種類です。

3. 検証：オフラインでテスト、オンラインで確認、そしてリリース

広範なロールアウトの前に、自動生成された回帰ケースと既存のベンチマークを使用して変更を検証しました。これにより、新しい委任ガイダンスが、サブエージェントが真に価値を追加するケースを壊すことなく、回避可能なオーバーヘッドを削減することが確認されました。

最後に、スタッフおよび公開A/Bテストを実施し、信頼性、応答性、サブエージェントのワークロード、品質に関するプロダクションメトリクスを分析しました。改善は主に個々のLLM呼び出しの高速化からではなく、不要なサブエージェントパスを回避し、ユーザーあたりのサブエージェントワークロードを削減することでオーケストレーションのオーバーヘッドを減らしたことによるものです。

このエンドツーエンドのプロセスにより、問題シグナルからリリースされた改善へと移行し、ユーザーエクスペリエンスを安定に保つことができました。回避可能な引き継ぎが減り、障害が発生しやすいツールパスが減り、品質の低下はありませんでした。

成果

スマートサブエージェント委任をプロダクショントラフィックにロールアウトした後、信頼性と応答性に関して測定可能なパーセンテージ改善が見られました（表1）。

| ディメンション | メトリクス | 変化 | | --- | --- | --- | | 信頼性 | セッションあたりのツール障害 | 23%削減 | | 信頼性 | 検索ツール障害 | 27%削減 | | 信頼性 | 編集ツール障害 | 18%削減 | | 応答性 | P95での総ユーザー待機時間 | 5%減少 | | 応答性 | P75での総ユーザー待機時間 | 3%減少 | | 品質 | 品質メトリクス | 劣化なし |

表1：プロダクションA/Bテストの結果

| メトリクス | 対照群との差異 | 解釈 | | --- | --- | --- | | 失敗した生のサブエージェント検索呼び出し | 15%削減 | 信頼性：障害が発生しやすいサブエージェント検索パスの減少 | | ユーザーあたりの平均サブエージェントLLM持続時間 | 12%低下 | 応答性：ユーザーあたりのオーケストレーションオーバーヘッドの削減 | | ユーザーあたりのP95サブエージェントLLM持続時間 | 18%低下 | 応答性：最悪ケースのサブエージェントオーバーヘッドの改善 |

表2：A/Bテスト結果の背後にある方向性エージェント軌跡分析

これらの結果は、可視的な機能面が変わらなくても、より良いオーケストレーションが開発者エクスペリエンスを向上させることを示しています。Copilot CLIにいつ委任するか、いつ委任しないか、そして適切な作業をどのように並列化するかを教えることで、エージェントループ自体の摩擦を減らしました。

これがGitHub Copilotのシステムとしての力です。開発者が管理するためのスイッチを増やすのではなく、Copilotが舞台裏でモデル、ツール、サブエージェントをより適切に割り当てるようになることで、エクスペリエンスが向上します。

開発者にとっての今日の利点

Copilot CLIを使用する開発者にとって、これはよりスムーズな日常体験を意味します。単純なタスクは直接処理される可能性が高く、複雑なタスクは価値がある場合に専門家の助けを得られ、長時間のセッションは不要な待機時間を減らして進み続けます。実際には、Copilot CLIは開発者が異なる方法で作業することを要求することなく、より効率的でノイズが少なくなります。

この変更は意図的に舞台裏で行われています。ワークフローは変わりませんが、Copilot CLIは作業の調整が向上します。不要な引き継ぎ、繰り返しの検索作業、失敗したツールパスが減り、長時間または複数ステップのタスクでの進行が速くなります。

今後の展開

この作業は、Copilot CLIがワークフロー全体で適切なモデル、エージェント、ツールを選択する方法を改善するという、より大きな目標への1つのステップです。より多くのエージェントとモデルが利用可能になることでCopilotの能力は拡大しますが、開発者にとっての価値は、Copilotがファイルの読み取り、コマンドの実行、issueからプルリクエストへの移行など、すでに行っている作業にそれらをどのように適用するかにかかっています。

タスクが複雑になるにつれて、そのオーケストレーションの品質がより重要になります。最良のシステムとは、最も多く委任するシステムではなく、直接行動すべき時、委任すべき時、そして摩擦を加えずに作業を進める方法を知っているシステムです。

次のステップは、Copilot CLIをモデル、エージェント、スキル、ツールにわたってより適応的にすることです。これにより、開発者はタスクが大規模なモデル、専門のサブエージェント、または手続き的スキルを必要とするかどうかを決定する必要がなくなります。Copilotは、タスク、リポジトリコンテキスト、ポリシー、および期待される結果に基づいてその決定を行うべきです。

私たちは、Copilot CLIが作業を計画し、サブエージェントを調整し、エンドツーエンドの結果を測定する方法を引き続き改善していきます。これには、メインエージェントとサブエージェントの動作の可視性向上、障害原因のより深い分析、およびオーケストレーション品質のためのより強力なプロキシメトリクスが含まれます。目標はシンプルです。待機時間の短縮、回避可能な障害の削減、そして各エージェントセッションからのより有用な進捗です。

今すぐ始めてフィードバックを共有しましょう

ターミナルで/updateコマンドを実行し、GitHub Copilot CLIをバージョン1.0.42以降に更新してください。

すでにお試しですか？ぜひ感想をお聞かせください。CLIセッションで/feedbackコマンドを使用するか、公開リポジトリでissueを開いてください。

謝辞

スマートサブエージェント委任は、Code|AI、Copilot CLI、実験、人間評価、製品チームの協力により実現しました。問題の特定、プロセスの設計、結果の検証、および改善のプロダクションへのリリースに貢献したすべての方々に感謝します。