AIニュース最前線
最新ニュースAI日報Hacker日報週報動画AIツールトレンド企業

AIニュース最前線

世界中のAI最新情報を日本語で毎時更新

最新ニュース日報トレンド企業プレミアムRSS
© 2026 ainew.jp特定商取引法に基づく表記
ニュース一覧元記事を開く
GitHub Blog·2026年6月13日 07:26·約13分で読める

GitHub Copilot CLI の委譲先選別機能を強化した理由

#Agentic Systems#Copilot CLI#LLM Orchestration#GitHub
TL;DR

GitHub は Copilot CLI のエージェントシステムにおける不要な委譲を抑制し、並列処理と専門家の活用を最適化する「スマートなサブエージェント委譲」機能を導入して、ツール失敗率を 23% 削減した。

AI深層分析2026年6月13日 08:08
4
重要/ 5段階
深度40%
5
関連度30%
5
実用性20%
4
革新性10%
3

キーポイント

1

委譲の非効率性の特定

単純なタスクでも安易にヘルパーエージェントを起動させることで、ハンドオフのオーバーヘッドや待ち時間が発生し、かえって作業が遅延する問題点を指摘。

2

スマート委譲アルゴリズムの実装

メインエージェントが自身で処理可能な場合は集中し、専門性が真に必要となる場合のみサブエージェントを呼び出す、並列化が可能なタスクは独立して実行するロジックを導入。

3

A/B テストによる実証効果

本番環境でのテストにより、セッションあたりのツール失敗率が 23% 減少し、検索および編集ツールの失敗がそれぞれ 27% と 18% 削減されたことを確認。

4

ユーザー体験の改善

不要なハンドオフと重複検索を減らすことで、P95 で待ち時間が 5%、P75 で 3% 短縮され、品質低下なしに開発効率が向上した。

5

LLM を活用したボトルネック分析

手動レビューに代わり LLM でエージェントの軌跡を分析し、単純なタスクで重複検索が行われる非効率パターンを特定しました。

6

選抜的な委譲ポリシーへの転換

サブエージェントは並列処理や広範な探索に限定し、単発のファイル操作などはメインエージェントが直接処理する方針に変更しました。

7

オーケストレーションの最適化によるパフォーマンス向上

LLM の処理速度を上げるのではなく、不要なサブエージェントへの委譲を減らすことで、信頼性が向上し(ツール失敗が最大27%減少)、応答時間が短縮されました。

影響分析・編集コメントを表示

影響分析

この記事は、単なる機能追加ではなく、AI エージェントシステムにおける「委譲戦略」の最適化という本質的な課題への解決策を示しています。開発者が直面するツール失敗や待ち時間といった実務上のボトルネックをデータで裏付けながら解消した点は、Agentic AI の実用化において極めて重要な示唆を与えます。今後は、複雑なタスク処理におけるリソース配分と意思決定の効率化が、AI ツールの競争力を左右する鍵となるでしょう。

編集コメント

「委譲すれば何でも解決する」という単純な考え方の限界を打破し、エージェント間の連携コストを最適化した点は、実運用における AI ツールの成熟度を示す重要な一歩です。

エージェントシステムにおいて、委任を増やすことが常に良いとは限りません。Copilot CLI に簡単な変更を依頼したと想像してみてください。直接処理する代わりに、リポジトリを検索し、結果を待機して立ち往生するヘルパーエージェントを起動します。本来 1 ステップで完了すべき作業が、3 ステップかかるようになります。不慣れなリポジトリの探索や、コードの独立した領域の確認、メインエージェントが動き続ける間に長時間のコマンドを実行するなど、一部のタスクは専門的なサブエージェントによって真に恩恵を受けますが、委任にはコストがかかります。すべての引き継ぎには調整オーバーヘッド、ツール呼び出し、待機時間が加わります。エージェントがあまりにも容易に委任すると、「支援」がかえって摩擦となり得ます。

私たちは最近、エージェントハネスに対する改善策として「スマートなサブエージェント委任」をリリースしました。これにより、Copilot CLI はより選択的になり、メインエージェントに対して以下のような支援を行います:

  • 自身でより速く進められる場合は集中力を維持する。
  • 専門家が真のレバレッジを生む場合にのみ委任する。
  • タスクが本当に独立している場合、並列処理を行う。

スマートなサブエージェント委任は現在、Copilot CLI の本番トラフィックの 100% に展開されています。今日から利用を開始したい場合は、ターミナルで /update コマンドを実行して GitHub Copilot CLI をバージョン 1.0.42 以降に更新するだけです。

⟦CODE_0⟧

本番環境での A/B テストにおいて、この改善によりセッションあたりのツール失敗数が 23% 減少しました。これには検索ツールの失敗が 27% 減り、編集ツールの失敗が 18% 減ったことが含まれます。また、P95(パーセンタイル 95)での総ユーザー待機時間は 5%、P75(パーセンタイル 75)では 3% 改善され、品質の低下はありませんでした。ここでいう P95 は最も遅い 5% のセッションに近い待機時間を捉え、P75 は典型的なセッションのうち slower な端に位置する待機時間を反映しています。これは、不要な引き継ぎが減り、繰り返される検索が少なくなり、失敗しやすいツールのパスが減り、長時間実行されるコーディングタスク中の待ち時間が短縮されたことを意味します。

本稿では、Copilot CLI における不要な委任(デレゲーション)をどのように特定し、より選択的な委任にするために何を変更したか、そしてそれらの変更がオフライン評価と本番環境での A/B テストを通じてどのように検証されたかを解説します。また、これらの変更がなぜ失敗の減少と待ち時間の短縮につながったのか、そして Copilot CLI を日常的に使用する開発者にとってそれがどのような意味を持つのかも示します。

問題点:委任は強力だが、無償ではない

サブエージェント(Subagents)は、エージェント型 CLI における最も重要な機能の一つです。これにより Copilot は複雑な作業を分解し、並列で調査を実行しながら、メインのエージェントが最終的な回答の調整に集中できるようにします。大規模なコードベースや多段階のエンジニアリングタスクにおいては、これが遅い線形ワークフローと効率的な並列ワークフローとの決定的な違いとなります。

しかし、委任には独自の失敗モードをもたらす可能性があります:

メインのエージェントが単独でより速く完了できる単純なタスクに対する不要な引き継ぎ。

ハンドオフにすでに十分なコンテキストが含まれている場合の探索用サブエージェントの過剰使用。

メインエージェントとサブエージェント間での反復的または重複する検索。

順次委譲、つまりメインエージェントが並列作業の機会として委譲を扱うのではなく、サブエージェントの完了を待ってしまうこと。

失敗しやすいサブエージェントパス、例えば古くなったファイルパス、移動されたファイル、誤った相対パス、およびワークスペースの不整合が含まれます。

imageimage図 1. サンプル:メインエージェントがアイドル状態にある間にサブエージェントによるツール呼び出しの失敗。

私たちの目標は、開発者がレバレッジ(効果的な利用)を生み出す際にサブエージェントを活用し、オーバーヘッド(過剰な負担)となる場合はそれを避け、タスクが独立した実行によって真に恩恵を受ける場合に並列化することです。

問題信号から実装された改善へ

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

imageimage図 2. エンドツーエンドの改善ループ:分析、変更、検証、リリース。

  1. 分析:LLM(大規模言語モデル)による委譲ボトルネックの特定

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

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

  1. 変更点:オーケストレーションポリシーの精緻化

ボトルネックを特定した後、LLM を使用してその診断結果を、より選択的なオーケストレーションポリシー(orchestration policy)へと翻訳するのを支援しました。

Copilot CLI は、焦点を絞った作業を直接処理すべきです:ファイルを見つけ、読み込み、ターゲットを絞った変更を加え、検証することです。デレゲーション(delegation)がより有用となるのは、独立したコンテキストが必要とされたり、広範な探索や並列実行が必要な場合です。

実際には、これは最も狭く効果的なパスから始め、複雑さや不確実性が価値を生む場合にエスカレーションし、タスクが再び焦点を絞った場合には段階を下げることを意味します。サブエージェントは、一時停止ボタンではなく、並列処理のツールとして扱うべきです。Copilot がサブエージェントを開始する際、メインエージェントは単に結果を待つのではなく、独立した作業で進捗を続けるべきです。

サブエージェントが使用される場合、ハンドオフも具体的であるべきです:ユーザーの要求、既知の情報、サブエージェントの所有権、およびメインエージェントが戻りとして必要とする結果の種類。

  1. 検証:オフラインでテストし、オンラインで確認し、その後リリースする

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

最後に、スタッフおよび公開 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 CLI を利用している開発者にとって、これは日々の作業がよりスムーズになることを意味します。単純なタスクは直接処理される可能性が高まり、複雑なタスクでも価値がある場合は専門家の支援が提供され、長時間実行されるセッションも不要な待ち時間を減らしながら進行します。実際には、Copilot CLI は開発者に異なる働き方を求めることなく、より効率的でノイズの少ないものになります。

この変更は意図的に裏側で行われるものです。ワークフロー自体はそのままですが、Copilot CLI は作業の調整がより上手になります:不要な引き継ぎが減り、繰り返される検索作業が少なくなり、失敗するツールパスが減り、長時間実行されるタスクや多段階のタスクでの進捗が速くなります。

次に何をするか

この取り組みは、Copilot CLI がワークフロー全体を通じて適切なモデル、エージェント、およびツールをどのように選択するかを改善するという、より大きな目標に向けた一歩です。利用可能なエージェントやモデルが増えることは Copilot の能力範囲を広げますが、開発者にとっての価値は、ファイルの読み込み、コマンドの実行、イシューからプルリクエストへの移行など、すでに実施している作業に対して Copilot がそれらをいかにうまく適用できるかにかかっています。

タスクが複雑になるほど、その調整(オーケストレーション)の質がより重要になります。最も優れたシステムとは、最も多くを委任するものではなく、いつ直接行動し、いつ委任し、摩擦を加えずに作業を進め続けるかを理解しているものです。

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

Copilot CLI の計画機能、サブエージェントの調整、およびエンドツーエンドの結果測定については、引き続き改善を進めていきます。これには、メインエージェントとサブエージェントの挙動に対する可視性の向上、失敗理由のより深い分析、そしてオーケストレーション品質を評価するためのより強力なプロキシ指標が含まれます。目標はシンプルです:待ち時間を減らし、回避可能な失敗を減らし、すべてのエージェントセッションからより有用な進捗を生み出すことです。

今日から始め、フィードバックをお寄せください

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

すでに試されましたか?皆様のご意見をお聞かせください。CLI セッション内で /feedback コマンドを使用してフィードバックを共有するか、または当社の公開リポジトリでイシューを開いてください。

謝辞

より賢明なサブエージェントへの委任は、Code|AI、Copilot CLI、実験チーム、人間評価チーム、製品チーム間の協力によって実現されました。問題の特定、プロセス設計、結果の検証、そして本番環境への改善導入に貢献いただいた皆様に感謝いたします。

「GitHub Copilot CLI の委任に関する選別性を高める方法」という記事は、最初に The GitHub Blog で公開されました。

原文を表示

In agentic systems, more delegation isn’t always better. Imagine asking Copilot CLI to make a simple change. Instead of handling it directly, it spins up a helper agent that searches the repository, waits on a result, and stalls. Work that should have taken one step now takes three. While some tasks genuinely benefit from a specialist subagent—like exploring an unfamiliar repository, checking an independent area of the code, or running a long command while the main agent keeps moving—delegation isn’t free. Every handoff adds coordination overhead, tool calls, and wait time. If an agent delegates too eagerly, the “help” can become friction.

We recently released an improvement to our agentic harness called smarter subagent delegation. This makes Copilot CLI more selective by helping the main agent:

Stay focused when it can move faster on its own.

Delegate when a specialist creates real leverage.

Parallelize work when tasks are truly independent.

Smarter subagent delegation has now rolled out to 100% of Copilot CLI production traffic. If you want to get started today, simply update GitHub Copilot CLI by running the /update command in your terminal to version 1.0.42 or later.

In a production A/B test, this improvement reduced tool failures per session by 23%, including a 27% reduction in search tool failures and an 18% reduction in edit tool failures. It also improved total user wait time by 5% at P95 and 3% at P75, with no quality regression. Here, P95 captures wait time near the slowest 5% of sessions, while P75 reflects wait time toward the slower end of typical sessions. This means fewer unnecessary handoffs, fewer repeated searches, fewer failure-prone tool paths, and less waiting during long-running coding tasks.

In this post, we’ll walk through how we identified unnecessary delegation in Copilot CLI, what we changed to make delegation more selective, and how we validated those changes through offline evaluation and production A/B testing. We’ll also show why those changes led to fewer failures and less waiting—and what that looks like for developers using Copilot CLI day to day.

The problem: Delegation is powerful, but not free

Subagents are one of the most important capabilities in an agentic CLI. They let Copilot break down complex work, run investigations in parallel, and keep the main agent focused on coordinating the final answer. For large codebases and multi-step engineering tasks, that can be the difference between a slow linear workflow and an efficient parallel one.

But delegation introduces its own failure modes:

Unnecessary handoffs for simple tasks that the main agent could complete faster on its own.

Overuse of exploration subagents when the handoff already contains enough context.

Repeated or overlapping searches across the main agent and subagents.

Sequential delegation, where the main agent waits for a subagent instead of treating delegation as an opportunity for parallel work.

Failure-prone subagent paths, including stale file paths, moved files, incorrect relative paths, and workspace mismatches.

imageimageFigure 1. Example: tool call failure by subagents while main agent is idling.

Our goal: help developers use subagents when they create leverage, avoid them when they add overhead, and parallelize work when the task genuinely benefits from independent execution.

From problem signals to shipped improvement

The way we identified the problem became the way we solved it. Instead of treating agent trajectory analysis, product changes, evaluation, and rollout as separate activities, we used them as one feedback loop: observe the agent behavior, isolate the orchestration bottleneck, make a targeted change, validate it offline, measure it online, and ship only once the end-to-end workflow improved.

imageimageFigure 2. The end-to-end improvement loop: analyze, change, validate, and ship.

  1. Analyze: Let LLMs identify the delegation bottleneck

Instead of manually reviewing agent sessions, we used LLMs to analyze full trajectories and identify where orchestration was helping versus where it was adding overhead. That analysis surfaced a consistent pattern: subagents were sometimes being invoked for tasks that were already narrow, obvious, or fully described in the handoff.

In those cases, the subagent could spend time re-searching the repository even though the main agent already had enough context to act directly. That clarified the improvement target: keep simple discovery-and-edit tasks in the main agent, and reserve subagents for work that is broader, cross-cutting, or naturally parallelizable.

  1. Change: Refine the orchestration policy

After identifying the bottleneck, we used LLMs to help translate that diagnosis into a more selective orchestration policy.

Copilot CLI should handle focused work directly: find a file, read it, make a targeted change, and verify it. Delegation is more useful when the work requires independent context, broad exploration, or parallel execution.

In practice, that means starting with the narrowest effective path, escalating when complexity or uncertainty creates value, and stepping back down when the task becomes focused again. Subagents should be treated as a parallelism tool, not a pause button. When Copilot launches a subagent, the main agent should continue making progress on independent work rather than simply waiting for the result.

When a subagent is used, the handoff should also be specific: what the user asked, what is already known, what the subagent owns, and what kind of result the main agent needs back.

  1. Validate: Test offline, confirm online, then ship

Before broad rollout, we validated the change with automatically generated regression cases and existing benchmarks. This helped confirm that the new delegation guidance reduced avoidable overhead without breaking cases where subagents genuinely add value.

Finally, we moved through staff and public A/B testing, then analyzed production metrics across reliability, responsiveness, subagent workload, and quality. The gains did not come primarily from making individual LLM calls faster. Instead, it reduced orchestration overhead by avoiding unnecessary subagent paths and lowering subagent workload per user.

That end-to-end process let us move from problem signal to shipped improvement while keeping the user experience stable: fewer avoidable handoffs, fewer failure-prone tool paths, and no quality regression.

Outcomes

After rolling smarter subagent delegation to production traffic, we saw measurable percentage improvements across reliability and responsiveness (Table 1):

DimensionMetricDelta

Reliability Tool failures per session 23% reduction

Reliability Search tool failures27% reduction

ReliabilityEdit tool failures18% reduction

ResponsivenessTotal user wait time at P955% lower

ResponsivenessTotal user wait time at P753% lower

QualityQuality metricsNo regression

Table 1. Production A/B test outcomes

MetricDelta vs. controlInterpretation

Failed raw subagent search calls15% reductionReliability – fewer failure-prone subagent search paths.

Average subagent LLM duration per user12% lowerResponsiveness – reduced orchestration overhead per user.

P95 subagent LLM duration per user18% lowerResponsiveness – better worst-case subagent overhead.

Table 2. Directional agent trajectory analysis behind the A/B test outcome

These results show that better orchestration can improve the developer experience even when the visible feature surface doesn’t change. By teaching Copilot CLI when to delegate, when not to delegate, and how to parallelize the right work, we reduced friction in the agent loop itself.

That is the power of GitHub Copilot as a system: the experience gets better not because developers are given more switches to manage, but because Copilot becomes better at allocating models, tools, and subagents behind the scenes.

How this benefits developers today

For developers using Copilot CLI, this should feel like a smoother day-to-day experience. Straightforward tasks are more likely to be handled directly, complex tasks still get specialist help when it adds value, and long-running sessions keep moving with less unnecessary waiting. In practice, Copilot CLI becomes more efficient and less noisy without asking developers to work differently.

The change is intentionally behind the scenes. Your workflow stays the same, but Copilot CLI is better at coordinating the work: fewer unnecessary handoffs, less repeated search work, fewer failed tool paths, and faster progress on long-running or multi-step tasks.

What’s next

This work is one step toward our larger goal of improving how Copilot CLI chooses the right model, agent, and tools across your workflow. While having more agents and models available expands what Copilot can do, the value to developers depends on how well Copilot applies them across the work they are already doing, like reading files, running commands, and moving from an issue toward a pull request.

As tasks become more complex, the quality of that orchestration matters more. The best system is not the one that delegates the most, but the one that knows when to act directly, when to delegate, and how to keep work moving without adding friction.

The next step is making Copilot CLI more adaptive across models, agents, skills, and tools, so developers don’t have to decide whether a task needs a larger model, a specialist subagent, or a procedural skill. Copilot should make that decision based on the task, repository context, policy, and expected outcome.

We will continue improving how Copilot CLI plans work, coordinates subagents, and measures end-to-end outcomes. That includes better visibility into main-agent and subagent behavior, deeper analysis of failure reasons, and stronger proxy metrics for orchestration quality. The goal is simple: less waiting, fewer avoidable failures, and more useful progress from every agent session.

Get started today and share feedback

Update GitHub Copilot CLI by running the /update command in your terminal to version 1.0.42 or later.

Already tried it? We’d love to hear what you think. Share feedback with the /feedback command in a CLI session or open an issue in our public repository.

Acknowledgements

Smarter subagent delegation was made possible by collaboration across Code|AI, Copilot CLI, experimentation, human evaluation, and product teams. Thanks to everyone who helped identify the problem, design the process, validate the outcome, and ship the improvement to production.

The post How we made GitHub Copilot CLI more selective about delegation appeared first on The GitHub Blog.

この記事をシェア

関連記事

GitHub Blog★32026年5月1日 01:09

GitHub Copilot CLI の初心者向けガイド:対話型と非対話型のモード解説

GitHub は、CLI ツール「Copilot CLI」の使い方を紹介するシリーズを開始し、本記事では対話型と非対話型の2つの主要モードの違い、起動方法、およびそれぞれの活用場面について解説している。

LangChain Blog★42026年6月19日 02:32

LangSmith のノーコードエージェントビルダーの紹介

LangChain が提供する LangSmith に、プログラミング不要で AI エージェントを構築できる新機能が導入された。

Vercel Blog★42026年6月17日 09:00

エージェント構築・運用・スケーリングのためのオープンソースフレームワーク「eve」の公開

Vercel が、ファイル構成でエージェントを定義し、耐久性実行やサンドボックス機能などを備えたオープンソースフレームワーク「eve」を一般プレビューとして発表した。

今日のまとめ

AI日報で今日の重要ニュースをまとめ読み

ニュース一覧に戻る元記事を読む