VS Code 1.144、ノートPCを閉じても続くコーディングセッションへ

机で開発の仕事を始め、別の端末で進み具合を確認し、後で戻って差分を読む。有用なのは、同じ指示と見える判断を持った一つの継続的な仕事です。端末を変えるたび会話を組み直すことも、開発者にかかる作業負担です。

VS Code 1.144は2026年10月28日に安定版として公開されました。 リリースノートには、エージェントセッションの継続性とリモート管理に加え、個別にプレビューや実験的とされる機能も含まれます。クラウドセッションはGitHubの基盤で動き、開発用ノートPCがオフラインでも続行できます。公式リリースノート。

本記事では、操作するクライアントと実行場所の違い、Agent Host Protocolの役割、実際にコードをレビューする引き継ぎを通じて継続セッションを評価する方法を説明します。

Visual Studio Code 1.144 の公式リモート環境スクリーンショット。 Used with permission from Microsoft. 画像ソース · ライセンスと画像に関する注意.

ウィンドウを閉じることと、実行処理の停止は別

コーディング インターフェイスには、メッセージ、ファイル、承認リクエストが表示されます。タスクを実行するプロセスは別の場所に存在する可能性があります。これらの役割が分離されれば、ホストとその環境が利用可能な状態であれば、インターフェイスを閉じてもタスクを放棄する必要はありません。

Microsoftの10月28日のUniverse概要は、セッション、ハーネス、モデル、ファイル、ターミナルを管理する独立したプロセスとして、エージェントホストを説明しています。Agent Host Protocolは1.0に達し、クライアントが継続中のセッション状態へ接続するとしています。「動き続ける」の意味を評価するうえで有用な構成上の区別です。

ローカル ホストは引き続きローカル マシンに依存します。リモート ホストは、そのリモート マシンと接続構成に依存します。クラウド セッションには、個別にホストされる環境があります。クライアントが離れたときに何が利用可能な状態を維持する必要があるかに応じて、実行場所を選択します。

クライアントは、制御室にある窓のようなものです。別の窓から同じ仕事を見ることはできますが、裏側の機械まで移動するわけではありません。スマートフォンにセッションを表示しても、スリープ中のローカルPCが常時稼働のサーバーになるわけではありません。

私たちは、実行だけでなく、何のためのどの作業かという同一性も保たれて初めて、永続化が役立つと考えます。継続中のセッションでは、使っているリポジトリ、作成した変更、待っている判断が明確であるべきです。プロセスを生かしておくだけでは、それほど大きな成果ではありません。

VS CodeのUniverse概要を踏まえ、クライアントとホストの責任分界を独自に図示。ネットワーク構成図ではなく、計画のために簡略化したモデルです。

AHPは、各画面が見るセッション状態をそろえる

11月2日に確認した公式のAgent Host Protocolサイトは、AHPを双方向で状態を共有する表示用プロトコルと説明しています。クライアントは共通のセッション状態を扱い、ホストが操作を配信して競合を仲裁します。再接続時は欠けた操作や現在のスナップショットを受け取り、画面を最新にできます。

エージェントのセッションには、会話履歴以上のものがあるため重要です。承認待ちの操作、動いているターミナル、変更済みのファイルも含まれます。二つの画面が異なる状態を示せば、コード生成が正しくても、利用者が誤った判断をする可能性があります。

プロトコルの再接続例は、クライアントの保留中の操作をホストの状態と整合させる様子を示します。実用上は、以前の要求がどうなったかを含め、現在の仕事の状態を復元するということです。切断前に承認が届いたかを、推測する必要があってはいけません。

共通プロトコルは、クライアント間の相互運用の境界も作ります。クライアントには、セッション状態と表示する操作への理解が必要です。プロトコルが存在することは、全ツールが既に全提供元へ接続でき、全機能を同じように表示できることを意味しません。

画面を比較するチームは、業務で重要な判断を確認します。別クライアントで承認待ちを見られるか。変更したファイルと現在の状態が分かるか。エディターへ戻ったとき、新しい会話ではなく同じ仕事が残っているかを試します。

安定版の公開と、各機能のプレビューは区別する

VS Code の 1.144 ページでは、リリースが安定版として識別されていますが、Cloud Automations、イメージ生成、およびCopilot Connectorsはプレビュー ラベルを保持しています。コンピューター操作とワーキング セットの機能は実験的としてマークされています。クラウド セッション エクスペリエンスには有料の Copilot プランが必要であり、組織のポリシーの対象となります。 リリースと機能のステータス、10 月 28 日、11 月 2 日に確認。

拡張できるエディターでは珍しくない組み合わせです。安定版のアプリにも、成熟度の異なる機能が含まれます。導入は版番号だけでなく、使う機能と手順を基に判断します。

この表は運用上の比較であり、環境間で同一の動作を保証するものではありません。特定の拡張機能、モデル、ハーネスの要件は依然として重要です。チームが使用する予定の組み合わせをテストします。

実験的な機能には、別の元に戻せる課題を選びます。継続性の基本評価は、引き継ぎを確認できる最小の手順から始めます。複数の新機能を組み合わせると、想定外の結果がどこから生じたか分かりにくくなります。

三つの仕事で、継続性の使いどころを考える

開発者は範囲を限定した修正を任せ、後から確認できる

開発者が、リポジトリ内の失敗したパーサー テストを修正するようにクラウド セッションに依頼すると想像してください。この指示では、失敗、関連する動作、および予期される検証が指定されます。次に開発者は、レビューのためにエディタに戻る前に、別のサポートされているクライアントから進行状況を確認します。

受け入れ基準は通常の変更と同じです。動作を修復し、関連する確認に合格し、差分が適切であることです。ノートPCを閉じても続くと実行できる時間帯は変わりますが、それだけでマージできるとは判断できません。

引き継ぎでは、正確なコマンドとテスト結果を残すよう求めます。「テストに合格した」だけより、対象の版と検査名が結び付いている方が評価しやすくなります。確認担当者には、全会話を組み直さず理解できるだけの根拠が必要です。

承認待ちや必要なサービスの不足で進めない場合は、その状態を見せるべきです。動いていても進展できない仕事は、有用な処理をしている仕事と異なります。見えることで、介入、範囲変更、待機のどれを選ぶか判断できます。

保守担当者は、ファイルを混ぜずに別々の問題を調べられる

例示的なメンテナは、あるセッションにバグの再現を依頼し、別のセッションはドキュメントを調査するかもしれません。タスクに明確な境界がある場合、これにより待ち時間を有効に活用できます。また、各結果を独自のワークスペースに関連付けて保持し、コンテキストを確認する必要も生じます。

開始前に担当範囲を決めます。ファイルやサブシステム、ブランチや作業領域、各セッションの出力を明示します。同じ契約を二つの仕事が変更する必要があれば、適用前に両者の調整方法を決めます。

一つの結果を既知のリポジトリ状態と比較して確認します。そうしないと、テストの成功が、別セッションの未確認の変更に依存するかもしれません。作業領域の境界は、成功の根拠がどの状態にあるかを明らかにするため重要です。

得られるのは、単なる同時稼働エージェント数の増加ではなく、確認すべき変更が整理された状態です。範囲を適切に分けた二つの調査は不確かさを減らせますが、重なる編集が増えると逆に増幅しかねません。Agents画面は、どちらの状況になっているかを保守担当者が把握できるときに役立ちます。

定期的なクラウド処理も、任せる前に試す

例えば、要確認の文書リンクを見つける定期レビューを考えます。読み取り専用の報告と明確な出力から始め、人が確認した後で、変更作成へ広げます。

ここでは、Cloud Automations のプレビュー ステータスが重要になります。これは、定期的な作業によって別の運用責任が追加されるためです。一度許容範囲内に動作したタスクでも、スケジュールに従って実行する前に、レート制御、所有権、および失敗に対する明確な応答が必要な場合があります。これらの要件は、言語出力の品質とは別にテストしてください。

各実行がどこへリポジトリの版、検出事項、外部要求を記録するかを把握します。完了できなければ、未解決事項を記録するべきです。変化がない状態と、検査に失敗した状態を責任者が区別できてこそ、定期処理が役立ちます。

1 つのリポジトリと適度なスコープから始めます。チームが通常の実行、意図的にブロックされた実行、および結果として生じる成果物のレビューを観察した後にのみ拡張します。これらは、リリースの実地テストの主張ではなく、提案されたパイロット手順です。

未コミットの作業には、明示した引き継ぎが必要

1.144 リリース ノートには、クラウド セッションは別のワークスペースを使用し、ローカルのコミットされていない変更は自動的にコピーされないと記載されています。 [チャット] または [エージェント] ウィンドウから、ユーザーはクラウドを選択し、GitHub リポジトリを選択し、フォローアップし、承認に応答し、変更を確認できます。既存のセッションはセッション リストから再度開くことができます。 クラウドセッションの説明。

作業中の変更が多いチェックアウトを使う人にとって、クラウド側が別のワークスペースであることは重要です。必要なローカルファイルが、クラウドセッションから見えるリポジトリの状態には存在しない場合があります。引き継ぐ前に、基準とするリビジョンと、追加資料を提供してよい方法を特定してください。

画面の切り替えとファイル転送は区別します。同じ会話が続いても、全ローカルファイルやサービスが移った証拠にはなりません。仕事の意図を保ちつつ、実行資料へのアクセスを明示的に用意する必要があります。

例示的なバグ レポートの場合は、承認された再現可能な形式で失敗した入力を含めてください。エージェントがコミットされたフィクスチャを使用する必要があるか、新しく提供されたマテリアルを使用する必要があるかを述べます。これにより、セッションに具体的な開始点が与えられ、問題が含まれていなかったリポジトリの状態についての長い調査が回避されます。

最終確認では、同じ境界を逆向きに調べます。変更案がどこにあり、作業ブランチへどう取り込むかを確かめます。結果の確認と適用中も、進行中のローカル編集を保ちます。遠隔作業の利点のために、状態が不確かな手元の仕事を犠牲にするべきではありません。

継続的なコーディングタスクの独自に作成した受け入れ確認フロー。これは、文書化された クラウド ワークスペース境界 と通常のエンジニアリング レビューを組み合わせたものです。独立したテスト結果は報告されていません。

十分間の見学より、一つの作業を完了させる方が分かる

一覧にセッションが出る、再接続する、メッセージが届くといった見える継続性は、評価しやすいものです。有用な確認ですが、開発者の目標は、引き継いでも状態が残る、完成した成果物です。

確認できる成果物まで完了する小さな仕事を選びます。明確な確認方法があれば、テスト用データ、文書の訂正、限定した動作の修復などが候補です。最初から広げすぎず、作業領域の状態と権限を確かめられるだけの意味を持たせます。

1. インストールされているリリースを更新して確認します。 VS Code の更新の確認フローを使用して、バージョンを確認します。公式ノートで機能固有のラベルを確認してください。
2. 承認された実行環境を選択します。 リポジトリへのアクセス、プランの適格性、および組織のポリシーを確認します。タスクがローカル、リモート、またはクラウド ホストに属するかを決定します。
3. 開始状態を記録します。 リポジトリとリビジョンをメモします。ローカルの変更を保存し、選択したワークスペースに必要な入力を特定します。
4. 制限された指示を与えます。 必要な動作、範囲、および検証コマンドに名前を付けます。レビューする予定の成果物を定義します。
5. ハンドオフを実行します。 クライアントから離れ、利用可能なサポートされているインターフェイスを通じて再接続します。同じセッションのステータス、保留中の承認、新しい作業を確認します。
6. コードに戻ります。 差分と検証証拠を調べます。チェックがレビュー中のリビジョンに適用されることを確認します。
7. 結果と残りの制限を記録します。 成功した再接続、完了したタスク、および受け入れられた変更を分けます。これらは、異なる証拠を持つ関連するマイルストーンです。

テストが失敗した場合は、失敗した境界を診断します。リポジトリ フィクスチャが見つからない場合は、ワークスペースの修復が必要になります。ブロックされたツール呼び出しには、許可の決定が必要です。ホストが利用できない場合は、実行環境の決定が必要になります。同じプロンプトを繰り返しても、プロンプト以外の問題が解決されることはほとんどありません。

この最初の結果を具体的なものにしておきます。 「このタスクはこの環境で継続され、このレビューされた差分が生成されました」は、運用上の有益な結論です。何を繰り返すことができるのか、どこで条件が重要なのかを同僚に伝えます。

永続セッションは、責任の所在を追いやすくするべきだ

VS Code 1.144は、指示が実行に変わり、実行がレビュー可能な変更になる場所として、エージェントの工程を継続的なワークスペースへと広げています。AHPはクライアント間で状態を共有する方向性を示し、実行場所はデバイスの切断後も何を動かし続けられるかを決めます。

意味のある進歩とは、いったん離れて戻っても理解できる仕事です。元の状態、判断、検証をセッションが保てれば、ノートPCの蓋は仕事の境界ではなく、予定を組むうえでの小さな条件になります。

出典

• Visual Studio Code 1.144 リリース ノート、安定版リリース 2026 年 10 月 28 日。 2026 年 11 月 2 日に確認済み。
• VS Code Wrapped: GitHub Universe 2026、2026 年 10 月 28 日。
• Microsoft エージェント ホスト プロトコル、仕様 v1.0.0 および共有状態の概要、2026 年 11 月 2 日に確認。

判断の背景となる資料を残す

Telli.shは、利用を許可された資料を、確認済みのメモと一緒に残すための選択肢です。ノート用ワークスペースを作成する。