Visual Studio Code 1.140 は、2026 年 9 月 30 日に公開され、Copilot を管理されたエージェント実行へとさらに進めています。Microsoft のリリースノートでは、専用の Copilot ハーネス、実験的なマルチフォルダーセッション、リモートタスク委任、HydraFusion オーケストレーション、既定の Auto モデル選択階層に対するエンタープライズ制御が説明されています。
CTO とエンジニアリングリーダーにとって、示される方向性は明確です。エージェントファーストの開発には、ワークロード分離、実行配置、モデルオーケストレーション、エンタープライズポリシーに関する判断が必要になりました。これはエディターの設定ではなく、プラットフォームの課題です。
1. マルチフォルダーセッションによるエージェント作業の分離
概要
Microsoft によると、VS Code 1.140 ではマルチフォルダーセッションの実験的サポートが追加されています。異なるチャットで別々のフォルダーまたは worktree を使用でき、関連するターミナル、タスク、コード変更、プルリクエストの状態を分離できます。
これは単なる別のチャットタブではありません。エージェントセッションの作業コンテキストを囲む境界です。
重要な理由
セッション間でファイル、ターミナル、タスク状態を共有すると、並行するエージェント作業に運用上の曖昧さが生じる可能性があります。マルチフォルダーモデルは、別々の worktree が並行変更に対する制御を向上させるかをテストする仕組みをプラットフォームチームに提供します。
重要な理由： チームは、既存のブランチ、worktree、コードレビュー、プルリクエストの慣行に照らしてこの機能を評価すべきです。実験的な分離を、これらの制御の代替として扱うべきではありません。
有用なパイロットでは、共有フォルダーのワークフローと別々のフォルダーまたは worktree を比較し、開発者がターミナル、タスク、コード変更を正しいチャットに明確に帰属させられる箇所を検証します。判断すべき点は、この分離によってレビューを断片化せずに調整オーバーヘッドを削減できるかどうかです。
2. Copilot ハーネスによるエージェントセッションの標準化
概要
Microsoft の VS Code 1.140 リリースノートによると、GitHub Copilot のエージェント動作は専用ハーネスを介して実行されるようになりました。Microsoft は、この変更により、VS Code と他の Copilot ツール全体でエージェントセッションが一貫して動作することを意図していると述べています。
このハーネスは、目に見えるワークフロー変更の背後にあるアーキテクチャ上の要点です。
重要な理由
ツール間の一貫性により、エージェントワークフローは運用しやすくなりますが、ベンダーが報告する一貫性には依然としてローカルでの検証が必要です。チームは、承認済みの Copilot 利用環境全体で同じ代表的なタスクを比較し、実行または結果の違いを文書化すべきです。
CTO 向け： 重要な変化は、1 つのエディターに埋め込まれた機能から、複数の Copilot ツールにまたがることを意図したエージェントワークフローへの移行です。この方向性により、所有責任は開発者プラットフォーム機能へ移っていきます。
したがって、標準化はインストールだけを対象にすべきではありません。チームには、許容可能なエージェント動作、レビュー要件、ツール間でセッションが異なる結果を生成した場合のエスカレーション経路について、共通の定義が必要です。
3. リモートタスク委任が配置判断を追加
概要
Microsoft によると、Agents ウィンドウは適切なリモートホストにタスクを委任できます。ホスト選択では、オペレーティングシステム、メモリ、CPU、負荷などのマシン特性を考慮できます。
これは、エージェントワークフロー内から行うリモートワークロード配置です。
重要な理由
委任により、どのホストがどの条件でエージェントタスクを受け取るべきかという、キャパシティとガバナンスの判断が導入されます。リリースノートは選択特性を説明していますが、提供された調査情報では、これらの特性をエンタープライズの内部ポリシーへどのように対応付けるべきかは示されていません。
重要な理由： プラットフォームチームは、広範な導入前に対象となるホストクラスを定義すべきです。オペレーティングシステム、メモリ、CPU、負荷は有用な配置入力ですが、アクセスやワークロード所有権に関する組織ルールの代替にはなりません。
承認済みのリモートホストで、範囲を限定したタスクから始めてください。そのうえで、選択動作がチームのキャパシティモデルに合致するか、開発者が委任された作業の実行場所を理解できるかを判断します。
4. HydraFusion によるモデルと改訂の調整
概要
Microsoft は、VS Code 1.140 で HydraFusion をリサーチプレビュー機能として導入しました。リリース情報によると、速度、コスト、品質のバランスを取ることを目標に、批評や改訂を含むモデル選択とワークフローステージを調整します。
これは単一モデルの強化ではありません。モデルとワークフローステップをまたぐオーケストレーションです。
重要な理由
HydraFusion により、オーケストレーション層が開発体験の明示的な部分になります。エンタープライズチームにとっては、協調した選択と改訂によって、追加のワークフロー複雑性を正当化できる結果が得られるかという評価課題が生まれます。
重要な理由： 速度、コスト、品質は競合する運用基準です。管理された評価では、HydraFusion をチームの現在のワークフローと比較する前に、各タスククラスでどの基準が重要かを定義すべきです。
おそらく最も重要な点は、この方向性です。エージェントファーストの開発は、1 つのモデルにプロンプトを与えることに限定されません。複数のステップにわたって選択、批評、改訂を行うシステムへと移行しています。
5. エンタープライズ制御による既定 Auto 階層のガバナンス
概要
Microsoft によると、VS Code 1.140 では、モデル選択で使用する既定の Auto 階層を構成するためのエンタープライズ制御が追加されています。提供された調査情報では、この制御の設定キーや追加の構成詳細は特定されていません。
ポリシーの対象領域は存在しますが、利用可能な証拠は、より具体的な構成指針を裏付けるものではありません。
重要な理由
自動モデル選択は、チームによるコスト、品質、監督の捉え方に影響します。構成可能な既定値はエンタープライズ管理者に制御点を与えますが、同時に明示的なポリシー判断も必要とします。
IT リーダーにとっての意味： Auto 階層を既定として承認するのか、評価グループに限定するのか、内部レビューまで保留するのかを文書化してください。エディターの既定値が、偶然に組織の AI ポリシーになることを避けるべきです。
規制産業では、モデル選択のガバナンスは譲れません。直ちに取るべき行動は、既定値の所有責任を割り当て、変更を承認できる人物を定めることです。
結論
VS Code 1.140 は、Copilot エージェントワークフローをより広範なプラットフォーム管理の課題へと変えます。マルチフォルダーセッションは分離を導入し、専用ハーネスはツール間の一貫性を目指し、リモート委任は配置判断を追加し、HydraFusion はオーケストレーションをプレビューし、Auto 階層はエンタープライズポリシーの対象領域を追加します。
エンタープライズチームにとっての意味
セッション分離をパイロットする。 代表的なリポジトリでマルチフォルダーセッションをテストし、別々のフォルダーまたは worktree がタスク所有権を明確にするかを確認します。
ハーネスの一貫性を検証する。 内部テストなしにベンダー報告の一貫性を受け入れるのではなく、承認済みの Copilot ワークフローをツール間で比較します。
リモート委任を制約する。 チームがオペレーティングシステム、メモリ、CPU、負荷に応じてエージェントタスクをルーティングする前に、対象となるリモートホストを定義します。
プレビュー評価を分離する。 HydraFusion は、明示的な速度、コスト、品質の基準を備えたリサーチプレビュー評価として扱います。
モデルポリシーの所有責任を割り当てる。 既定の Auto 階層を誰が制御するか、変更をどのようにレビューするかを決定します。
エージェントファーストはトレンドではなく、進む方向です。エンタープライズの課題は、その方向をガバナンス可能にすることです。
Happy Coding!