開発者が押さえるべきVS Code v1.111の全体像と週次リリースへの転換背景

開発者が押さえるべきVS Code v1.111の全体像と週次リリースへの転換背景

Visual Studio Code v1.111は、2026年3月10日にリリースされた初の週次Stableビルドです。これまで月に1回のペースで提供されてきたVS Codeの安定版が、今回から毎週更新される体制に切り替わりました。本バージョンではエージェント権限の調整機能、エージェントスコープフック、デバッグイベントスナップショットなどAIコーディング体験を強化する機能が中心に据えられています。週次リリースへの移行は、AIモデルの急速な進化にエディタ側が追随する必要性から決断されたものであり、今後の開発ワークフローに大きな影響を与える転換点といえます。

月次から週次へ切り替えた3つの理由とAIモデル更新サイクルとの連動

Microsoftがリリース頻度を月次から週次に変更した背景には、AIコーディング領域の変化スピードがあります。2025年後半以降、Claude Opus 4.5やOpus 4.6、OpenAIのGPTシリーズなど主要な生成AIモデルが数週間単位で更新されており、これらの新機能をエディタ側で迅速にサポートする必要が生じていました。従来の月次リリースでは、モデル対応の準備が完了しても最大3〜4週間待たなければユーザーに届けられないという課題がありました。

週次化の理由は大きく3つに整理できます。第一に、AIモデルの新機能やMCPベースのツール連携をタイムリーに反映する必要性です。第二に、Google AntigravityなどAI特化型IDEとの競争が激化しており、機能提供の遅延が直接的なユーザー流出につながるリスクが高まっている点です。第三に、エンジニアリングプロセスの成熟により、品質を維持しながら高頻度リリースを実現できる体制が整ったことです。VS Codeチームはブログで「高品質な機能をより速いペースで提供するためにエンジニアリングプロセスの改善を続ける」と述べており、週次リリースは一時的な施策ではなく恒常的な運用方針であることがうかがえます。

v1.111が初回週次リリースとして2026年3月10日に公開された経緯

v1.111は、2026年3月4日にリリースされた月次版v1.110（February 2026リリース）に続く最初の週次Stableビルドとして位置づけられています。v1.110までは従来どおり前月の名称を冠した月次更新として提供されていましたが、v1.111からはバージョン番号が週単位で進む新方式に切り替わりました。GitHubのリリースページでも「Welcome to the 1.111 release of Visual Studio Code, the first of our weekly Stable releases!」と明記されており、公式にも初回週次版であることが強調されています。

リリース日の3月10日は月曜日であり、今後も週の初めにStable版が配信されるサイクルが想定されます。なおInsiders版は引き続き毎日更新されるため、週次Stable版はInsidersで十分に検証された機能を安定版へ反映する役割を担います。v1.110との間隔がわずか6日であることからも、今後の更新が従来より細かい粒度で届くことが実感できるでしょう。すでにVS Codeをインストール済みの場合はヘルプメニューの「更新の確認」から取得でき、自動更新が有効であれば特別な操作なく反映されます。

エージェント権限・フック・デバッグの3本柱で構成されるv1.111の機能全体像

v1.111の主要な新機能は、AIエージェント体験を強化する3つの柱で構成されています。1つ目はエージェント権限（Agent Permissions）で、チャットビュー内の権限ピッカーからセッションごとにエージェントの自律度を調整できるようになりました。2つ目はエージェントスコープフック（Agent-Scoped Hooks）で、特定のカスタムエージェントにのみ前処理・後処理ロジックを適用できるプレビュー機能です。3つ目はデバッグイベントスナップショット（Debug Events Snapshot）で、エージェントの挙動をリアルタイムに記録し、チャットコンテキストに添付してトラブルシュートに活用できます。

これらに加えて、チャットTipsの段階的オンボーディングへの刷新、AIターミナルプロファイルの専用グループ化、拡張機能開発者向けのローカライゼーション文字列IntelliSense強化など、細部の改善も含まれています。全体としてv1.111は「新機能の大量投入」よりも「AIエージェントの操作性と信頼性の精緻化」に重点を置いたリリースであり、v1.110で導入されたAgent PluginsやSession Memoryといった大型機能を実運用レベルで使いこなすための基盤整備という性格が強いバージョンです。

従来の月次リリースv1.110との提供スピードと機能粒度の違い

v1.110は2026年2月のリリースとして3月4日に公開されたバージョンであり、Agent Plugins、Agentic Browser Tools、Session Memory、Context Compaction、チャットセッションのフォーク、Agent Debugパネルなど多数の大型機能が一括で導入されました。これに対しv1.111は、エージェント権限やスコープフック、デバッグスナップショットなど比較的小規模で焦点の絞られた改善が中心です。

この違いはリリースサイクルの変化を如実に反映しています。月次リリースでは4週間分の開発成果がまとめて提供されるため、1回あたりの変更量が大きく、リリースノートも非常に長大になりがちでした。一方、週次リリースでは1週間分の変更のみが含まれるため、各バージョンの差分は小さく、ユーザーが把握すべき内容もコンパクトになります。開発者にとっては「月に1回の大きな変化に適応する負荷」が「週に1回の小さな変化に追従するリズム」に変わったといえます。ただし、1か月単位で見れば機能追加の総量は変わらないか増加する可能性があるため、更新頻度の増加が情報過多にならないよう注意が必要です。

週次リリース体制が個人開発者・チーム開発にもたらす恩恵と負荷の実態

個人開発者にとって週次リリースの最大のメリットは、待ち時間の短縮です。特定の機能やバグ修正がInsidersで検証された後、最短1週間でStable版に反映されるため、月次時代のように修正済みの不具合を3週間も抱えたまま作業する必要がなくなります。新しいAIモデルへの対応も素早くなるため、最新モデルの性能を業務に即座に活かしたい開発者には大きな恩恵があります。

一方で、チーム開発においては更新管理の負荷が増加する懸念もあります。全員が同じバージョンを使用する方針のチームでは、毎週の更新確認と動作検証のサイクルが発生します。拡張機能の互換性チェックや設定変更の周知もこれまでの4倍の頻度で必要になる可能性があるため、アップデートポリシーの見直しが求められます。実務的な対応策としては、週次更新を即座に適用するのではなく「2週間に1回」や「月初のみ」など組織独自のタイミングを設定し、リリースノートの差分を確認したうえで計画的に反映する運用が現実的です。自動更新を無効にして手動管理に切り替える場合は、update.mode設定をmanualに変更することで対応できます。

Autopilotとエージェント権限で変わるv1.111のAIコーディング操作体験

v1.111の目玉機能であるAutopilotとエージェント権限は、AIエージェントにどこまで作業を任せるかを開発者自身がセッション単位で制御できる仕組みです。従来はツール呼び出しのたびに確認ダイアログが表示されるか、すべて自動承認かの二択に近い状態でしたが、新しい権限ピッカーによって3段階の自律度を柔軟に選択できるようになりました。この変更はAIエージェントの利便性と安全性のバランスを開発者自身が主体的にコントロールするための重要な基盤です。

chat.autopilot.enabledで有効化するAutopilotプレビューの基本動作

Autopilotはchat.autopilot.enabled設定をオンにすることでStable版でも利用可能になるプレビュー機能です。有効化するとチャットビューの権限ピッカーにAutopilot（Preview）の選択肢が追加されます。Autopilotモードではエージェントがすべてのツール呼び出しを自動承認し、エラー発生時には自動的にリトライを行い、フォローアップの質問にも自動で応答します。エージェントはtask_completeシグナルが送信されるまで自律的に作業を継続するため、開発者が介入しなくてもタスクが完了するまで動き続けます。

この動作はInsiders版ではデフォルトで有効化されていましたが、Stable版ではオプトイン方式となっています。これは、Autopilotが設定済みの安全チェックを無視するため、意図しないファイル変更やターミナルコマンドの実行が発生するリスクがあるためです。初めてAutopilotを試す場合は、重要なプロジェクトではなくテスト用のワークスペースで動作を確認してから本番環境に適用することを強く推奨します。設定画面でchat.autopilot.enabledを検索し、チェックボックスをオンにするだけで有効化できます。

Default Approvals・Bypass Approvals・Autopilotの3段階権限の選び方

v1.111で導入された権限ピッカーでは、3つの権限レベルから選択できます。Default Approvalsは従来と同じ動作で、承認が必要なツール呼び出し時に確認ダイアログが表示されます。Bypass Approvalsは確認ダイアログを完全にスキップし、すべてのツール呼び出しを即座に実行します。Autopilot（Preview）はBypass Approvalsの動作に加えて、エラー時の自動リトライやフォローアップへの自動応答、タスク完了までの自律動作が追加されます。

選択の基準は「作業対象の重要度」と「エージェントへの信頼度」のバランスです。本番環境のコード変更にはDefault Approvals、繰り返しの定型タスクにはBypass Approvals、探索的なプロトタイピングにはAutopilotという使い分けが実務上合理的です。権限レベルはセッション中いつでも切り替えられるため、作業フェーズに応じた柔軟な運用が可能です。

Autopilot有効時にツール呼び出しが自動承認される仕組みと暴走リスク

Autopilotモードが有効な状態では、エージェントのツール呼び出しに対する承認ダイアログが完全に省略されます。通常であればファイルの編集やターミナルコマンドの実行前にユーザーの承認を求める安全機構が働きますが、Autopilotではこれらがすべて自動的に承認されます。さらにエラーが発生した場合も自動リトライが行われるため、誤ったコマンドが繰り返し実行される可能性があります。

具体的なリスクとしては、エージェントが意図しないファイルを削除・上書きするケース、ターミナルでデストラクティブなコマンドを実行するケース、外部APIを繰り返し呼び出してレート制限に抵触するケースなどが考えられます。ある開発者の報告では、Autopilotを誤って有効化した状態でエージェントがターミナルコマンドを確認なしに実行し始めたという事例も挙げられています。Autopilotの有効化時には警告ダイアログが表示されますが、この内容をよく読まずに承認してしまうと想定外の動作が発生する恐れがあります。重要なリポジトリではGitのブランチを切った状態で作業する、あるいはgit stashで変更を退避してからAutopilotを試すといった予防策が有効です。

セッション単位で権限レベルを切り替える実務的な運用フロー

v1.111の権限ピッカーはセッション単位で適用されるため、複数のチャットセッションを並行して使用する場合、セッションごとに異なる権限レベルを設定できます。たとえば本番コードの修正用セッションではDefault Approvalsを維持しつつ、別のセッションでプロトタイプのスキャフォールディングをAutopilotに任せるといった並行運用が可能です。

実務的な運用フローとしては、まずセッション開始時に作業内容のリスクレベルを判断し、適切な権限を選択する習慣をつけることが重要です。権限ピッカーはチャットビューの上部に常時表示されており、ドロップダウンから即座に変更できます。作業の途中でリスクの高い操作が必要になった場合はDefault Approvalsに戻し、安全な作業に戻ったらBypass Approvalsに切り替えるという動的な運用も現実的です。チーム開発では、権限レベルの推奨値をプロジェクトのREADMEや開発ガイドラインに明記しておくことで、メンバー間の認識のばらつきを防止できます。

安全確認ダイアログをスキップする際に見落としやすい5つの注意点

Bypass ApprovalsやAutopilotを利用する際には、安全確認ダイアログが省略されることによるリスクを正しく認識しておく必要があります。見落としやすいポイントを5つ整理します。

• ワークスペース信頼の前提：VS Codeのエージェント機能はWorkspace Trust（ワークスペース信頼）が有効であることを前提としており、信頼されていないフォルダでAutopilotを使用すると予期しない制限が発生する場合があります
• npmスクリプトの自動承認：chat.tools.terminal.autoApproveWorkspaceNpmScriptsが有効だと、package.json内のnpmスクリプトが確認なしに実行されるため、悪意のあるスクリプトが混入していた場合のリスクが増大します
• ターミナル履歴の非記録：シェル統合が有効な環境ではエージェントが実行したコマンドがシェル履歴に記録されないため、事後的な確認が困難になる場合があります
• コンテキストウィンドウの消費：Autopilotが自律的に動作を続けるとトークン消費量が急増し、コンテキストウィンドウの上限に到達して予期しない動作中断が起こる可能性があります
• プレミアムリクエストの消費：自動リトライや自動応答はプレミアムリクエストとしてカウントされるため、GitHub Copilotのサブスクリプション上限に影響する場合があります

これらのリスクを踏まえ、Bypass ApprovalsやAutopilotの使用前には必ず作業対象のワークスペースが信頼された状態であること、不要なスクリプトが含まれていないこと、Git上で変更の巻き戻しが可能な状態であることを確認してから運用を開始してください。

エージェントスコープフックとデバッグスナップショットによる開発効率の底上げ

v1.111では、エージェントのカスタマイズ性とトラブルシュートのしやすさが大幅に向上しました。エージェントスコープフックは特定のカスタムエージェントに限定して前処理・後処理ロジックを適用できるプレビュー機能で、複数エージェントを使い分ける現場での副作用の管理を容易にします。またデバッグイベントスナップショットは、エージェントの内部動作を時系列で記録しチャットに添付できる機能で、挙動の再現と原因分析を飛躍的に高速化します。

agent.mdのfrontmatterにhooksを定義するエージェントスコープフックの設定手順

エージェントスコープフックを利用するには、まずchat.useCustomAgentHooks設定をtrueに変更します。次に、対象のカスタムエージェント定義ファイル（.agent.md）のYAMLフロントマターにhooksフィールドを追加します。フックはイベント名をキーとし、実行するコマンドオブジェクトの配列を値として記述します。

1. VS Codeの設定画面を開き、chat.useCustomAgentHooksを検索して有効化する
2. プロジェクト内の.agent.mdファイルを開く（存在しない場合は新規作成）
3. YAMLフロントマターにhooksセクションを追加し、対象イベントとコマンドを定義する
4. フックで実行するシェルスクリプトやコマンドをプロジェクト内に配置する
5. チャットビューで対象のカスタムエージェントを選択し、フックが正常に発火するか確認する

たとえばコード編集後に自動フォーマットを実行するエージェントを定義する場合、PostToolUseイベントにフォーマットスクリプトを紐づけます。フロントマターの記述例として、hooks:の下にPostToolUse:を置き、- type: commandとcommand: "./scripts/format-changed-files.sh"を指定する形式です。この定義により、当該エージェントがツールを使用するたびにフォーマットスクリプトが自動実行されます。

chat.useCustomAgentHooksを有効化して前処理・後処理を分離する方法

chat.useCustomAgentHooksは、エージェントスコープフック機能を利用するために必須の設定項目です。この設定を有効化すると、.agent.mdファイルのフロントマターに定義されたフックがVS Codeに認識されるようになります。設定方法は、コマンドパレットから「Preferences: Open Settings (JSON)」を選択し、"chat.useCustomAgentHooks": trueを追記するか、設定UIで検索して切り替えます。

前処理と後処理の分離は、フックのイベントタイプを使い分けることで実現します。たとえばPreToolUseイベントで入力データのバリデーションを実行し、PostToolUseイベントで出力結果のフォーマットチェックを行うといった構成が可能です。さらにStopイベントを利用すれば、エージェントの作業完了時にテストスイートを自動実行し、失敗した場合はエージェントを停止させずに追加修正を促すことも実現できます。ワークスペースレベルのフックとエージェントスコープフックは併用可能で、同一イベントに対して両方が定義されている場合は双方が実行されます。優先順位としてはワークスペースフックがユーザーフックより優先されるため、チームで統一したいルールはワークスペースフックに、個人の好みはユーザーフックに定義するという使い分けが有効です。

runSubagent経由の呼び出し時だけフックが発火する仕組みと誤動作の回避策

エージェントスコープフックの重要な特性として、フックが発火する条件は「対象のカスタムエージェントがユーザーに選択されている場合」または「runSubagent経由でサブエージェントとして呼び出された場合」に限定されます。つまり、同じチャットセッション内であっても別のエージェントが選択されていればフックは発火せず、関連のない会話にフックの副作用が波及することはありません。

この設計により、コードフォーマット用エージェントのフックがドキュメント生成用エージェントの動作に影響を与えるといった誤動作を防止できます。ただし注意すべきケースとして、サブエージェント経由で呼び出された場合は親エージェントのフックとサブエージェントのフックが同時に実行される可能性がある点があります。この場合はSubagentStartやSubagentStopイベントのagent_idフィールドを確認し、意図したエージェントのフックのみが実行されるように条件分岐を設けることが推奨されます。フックの発火状況はAgent Debugパネルでリアルタイムに確認できるため、設定後は必ず実際の動作をデバッグパネルで検証してください。

debugEventsSnapshotをチャットに添付してエージェント挙動を即座に解析する手順

デバッグイベントスナップショットは、エージェントの動作ログをその時点の状態として切り出し、チャットコンテキストに添付できる機能です。使用方法はチャット入力欄で#debugEventsSnapshotと入力するか、Agent Debugパネルのスパークルアイコンをクリックするだけです。添付されたスナップショットは取得時点のタイムスタンプで自動的にフィルタリングされるため、関連するイベントだけを効率的に確認できます。

1. チャットセッションでエージェントにタスクを実行させる
2. 問題が発生した、または確認したい時点でAgent Debugパネルのスパークルアイコンをクリック
3. スナップショットが自動的にチャットコンテキストに添付される
4. チャットに「どのカスタマイゼーションが読み込まれているか」「トークン消費量はいくつか」などの質問を入力する
5. エージェントがスナップショットの内容を分析し、回答を返す

この機能は、v1.110で導入されたAgent Debugパネルと組み合わせることでさらに威力を発揮します。パネルではイベントのリアルタイムストリーミングが確認でき、スナップショットでは特定時点の状態を保存して後から分析できるため、リアルタイム監視と事後分析の両方をカバーできます。「エージェントがなぜこのツールを呼び出したのか」「どのプロンプトファイルが読み込まれているのか」といった疑問を即座に解決できる強力なトラブルシュートツールです。

フック未設定時とフック導入後でエージェント制御がどう変わるかの比較

フックを設定していない状態では、エージェントの動作はVS Codeの標準的なツール承認フローに従います。エージェントがツールを呼び出すたびにユーザーの承認を経て実行され、前処理や後処理の自動化は一切行われません。つまり、コード変更後のフォーマットチェックや自動テスト実行は開発者が手動で行う必要があります。

フック導入後は、繰り返し行っていた手動操作が自動化されるだけでなく、エージェントごとに異なるワークフローを定義できるようになるため、複数エージェントを活用するプロジェクトでの生産性が大きく向上します。特にCI/CDパイプラインの一部をエディタ内で模倣するような使い方に適しており、変更→フォーマット→テスト→レビューという一連のフローをエージェントに委任できます。

チャットTips刷新とEdit Mode廃止がもたらすv1.111移行時の注意点

v1.111ではAIチャットインターフェースの改善として、チャットTipsの段階的オンボーディングが導入されました。加えて、v1.110で公式に非推奨となったEdit ModeはV1.125での完全削除が予告されており、エージェントベース編集への移行が必須となります。これらの変更はAIコーディングの使い始めと使い方の両面に影響するため、既存ユーザー・新規ユーザーの双方にとって把握しておくべきポイントです。

構造化オンボーディングに変わったチャットTipsの表示順序と設計意図

v1.111ではチャットTipsの表示方式が大幅に刷新されました。従来は機能の紹介がランダムに近い順序で表示されていたため、AIコーディングに不慣れなユーザーにとっては何から始めればよいかわかりにくい状態でした。新しい構造化オンボーディングでは、VS Codeを初めて使い始めた段階では基礎的なTips（Planエージェントの使い方やカスタムエージェントの作成方法など）が優先的に表示されます。

基礎的なTipsが終了した後に、実験的な設定やMermaidダイアグラムの生成といった応用的なTipsが段階的に表示される仕組みです。この設計意図は、AIチャットインターフェースの急速な進化に伴い増加し続けるオプションを、ユーザーの習熟度に合わせて適切なタイミングで紹介することにあります。さらに、ユーザーがTipsを操作または非表示にした後はそのセッション内でそれ以上のTipsが表示されなくなる変更も加わっており、情報過多によるストレスの軽減が図られています。チャットTipsは単一セッションまたはウェルカムビュー表示時にのみ出現し、複数のチャットエディタが開かれているセッションでは表示されません。

Planエージェントやカスタムエージェント作成を優先表示する段階的Tipsの実例

新しいチャットTipsの最初のステップとして表示されるのは、Planエージェントの活用方法です。Planエージェントはタスクを実行する前に計画を立てて提示してくれるモードであり、AIがどのような手順で作業を進めるか事前に確認できるため、初心者が安心してAIコーディングを始めるための出発点として適しています。続いてカスタムエージェントの作成方法が案内され、.agent.mdファイルの基本構文やスキルの登録方法が紹介されます。

応用段階では、/initコマンドによるエージェントの初期設定、/forkコマンドによるセッション分岐、実験的な設定の紹介などが表示されます。たとえば/forkは既存のチャット履歴を引き継いだまま新しい独立セッションを作成できるコマンドで、異なるアプローチを並行して試す場面で役立ちます。Tips表示の順序はVS Code内部のユーザー行動トラッキングに基づいて調整されるため、すでにカスタムエージェントを使いこなしているユーザーには基礎的なTipsがスキップされる場合もあります。Tips自体は強制的なものではなく、不要と感じた場合は一度操作するだけでセッション内の表示を停止できます。

Edit Modeがv1.110で非推奨となりv1.125で完全削除されるスケジュール

Edit Modeは、v1.110（February 2026リリース）において公式に非推奨（deprecated）と宣言されました。Edit ModeはAIによるコード編集をファイル内のインライン操作として実行する従来型の編集方式で、エージェントベースの編集が主流になる以前から使われていた機能です。今後はv1.125でEdit Modeが完全に削除される予定であり、それ以降は設定による復活も不可能になります。

この移行スケジュールを整理すると、v1.110で非推奨化が宣言されたのが2026年3月4日、v1.111以降の週次リリースでも引き続き利用可能ですが、v1.125の時点で機能自体が完全に除去されます。週次リリースのペースを考慮すると、v1.111からv1.125までは約14週間の猶予がありますが、早い段階でエージェントベース編集に慣れておくことが移行の負荷を軽減する鍵です。Edit Modeに依存したワークフローを構築している場合は、この猶予期間内にエージェントモードへの切り替え手順を整備し、チームメンバーへの周知と研修を計画的に実施することが重要です。

chat.editMode.hiddenで一時復元する場合の制約と移行猶予期間の活用法

Edit Modeを一時的に復元するには、chat.editMode.hidden設定を使用します。この設定をfalseに変更することでEdit ModeのUIが再び表示されるようになりますが、この復元手段はv1.125まで限定のサポートとなっており、恒久的な解決策ではありません。復元したEdit Modeの動作自体は従来と同様ですが、今後のバージョンで新たに追加されるAI編集機能はエージェントモード専用として開発されるため、Edit Modeでは利用できない機能が増えていくことになります。

移行猶予期間を効果的に活用するためには、段階的なアプローチが有効です。まず第1週で既存のEdit Modeワークフローを棚卸しし、どの操作がエージェントモードで代替可能かを確認します。次の2〜3週間でエージェントモードへの置き換えを実施し、問題があればchat.editMode.hiddenでEdit Modeに一時的に戻して差分を比較します。最終的にすべてのワークフローがエージェントモードで問題なく動作することを確認した段階で、chat.editMode.hiddenの設定をデフォルトに戻してEdit Modeとの決別を完了します。この段階的な移行により、業務の中断を最小限に抑えつつ新しい編集体験に適応できます。

Edit Mode廃止後にエージェントベース編集へ移行する際の3つの失敗パターン

Edit Modeからエージェントベース編集への移行で多く見られる失敗パターンを3つ紹介します。第一に、移行準備なしの一括切り替えです。チーム全員が同時にEdit Modeを無効化し、エージェントモードの操作に不慣れなまま本番作業を開始すると、生産性が一時的に大幅に低下します。切り替え前に最低でも1〜2日間はテスト環境でエージェントモードの操作を練習する時間を確保すべきです。

第二の失敗パターンは、カスタムエージェント設定の未整備です。Edit Modeでは特別な設定なしにインライン編集が可能でしたが、エージェントモードではプロンプトファイルやスキルの設定が編集品質に大きく影響します。.github/instructions/ディレクトリにプロジェクト固有の指示ファイルを配置し、コーディング規約やアーキテクチャの方針をエージェントに伝えることで、Edit Mode時代と同等以上の編集精度を実現できます。第三の失敗パターンは、承認フローへの不適応です。エージェントモードではツール呼び出しの承認ダイアログが頻繁に表示されるため、これを煩わしく感じてBypass ApprovalsやAutopilotに即座に切り替えてしまい、意図しないコード変更が発生するケースがあります。まずはDefault Approvalsで運用し、エージェントの動作パターンを把握してから段階的に自律度を上げていくアプローチが安全です。

ターミナルUI改善から拡張機能APIまでv1.111で見落としやすい実務向け変更点

v1.111の変更点はエージェント関連機能が注目を集めがちですが、ターミナルの使い勝手や拡張機能開発者向けの改善、エディタ内部の細かな修正など実務に直結する変更も多数含まれています。これらは派手さこそないものの日常的な開発体験の質を着実に向上させるものであり、リリースノートの末尾に埋もれやすい変更点を見落とさないことが重要です。

AIターミナルプロファイルが専用グループに分離された背景と発見性の向上

v1.111では、AI CLIターミナルプロファイルがターミナルドロップダウン内で専用のグループとして表示されるようになりました。従来はAI関連のターミナルプロファイルが通常のプロファイル（bash、zsh、PowerShellなど）と混在して一覧表示されていたため、AI対応プロファイルを見つけにくい状態でした。この変更により、AIターミナルプロファイルが視覚的に分離され、ユーザーがAI機能付きのターミナルを素早く起動できるようになっています。

この改善の背景には、VS CodeがCopilot CLIやバックグラウンドエージェントなどAIを活用したターミナル操作の機能を拡充し続けていることがあります。v1.107以降、ターミナルでのAI補完（Terminal Suggest）がStable版全ユーザーに展開され、ターミナル内でのコマンド自動承認機能も追加されるなど、ターミナルとAIの統合が急速に進んでいます。専用グループへの分離は、こうした機能群を一箇所にまとめることで発見性を向上させると同時に、今後追加されるAIターミナル機能の受け皿を整備する狙いもあると考えられます。

ローカライゼーション文字列のIntelliSense強化が拡張機能開発者に与える影響

v1.111では拡張機能開発者向けの改善として、ローカライゼーションプレースホルダー文字列に対するIntelliSenseが強化されました。具体的には、package.json内でローカライゼーション用のプレースホルダー文字列（例：%config.settingName%）に対してGo to Definition機能が動作するようになり、対応するpackage.nls.jsonのエントリへ直接ジャンプできます。

この変更は、多言語対応の拡張機能を開発しているチームにとって作業効率の向上に直結します。従来はpackage.jsonとnlsファイルの間を手動で行き来する必要がありましたが、IntelliSenseによる自動ナビゲーションにより、翻訳キーの定義場所を即座に特定できるようになりました。拡張機能のローカライゼーションは国際展開において重要な作業であり、キーの不一致や未翻訳エントリの見落としがバグの原因となるケースも少なくありません。この改善によって翻訳関連のミスが早期に発見しやすくなり、品質向上とレビュー工数の削減の両方が期待できます。

instructionsファイルのサブディレクトリ再帰検索が有効になった変更の実務的意味

v1.111以前では、VS Codeが.github/instructions/ディレクトリ内の*.instructions.mdファイルを検出する対象はルートディレクトリ直下のファイルに限られていました。v1.111からはサブディレクトリの再帰検索が有効化され、.github/instructions/frontend/や.github/instructions/backend/のようなサブディレクトリに配置したインストラクションファイルも自動的に認識されるようになりました。

この変更は、Copilot CLIやGitHub上のCopilotエージェントの動作に合わせたもので、エディタ内外での挙動を統一する目的があります。実務的には、大規模プロジェクトにおいてフロントエンド・バックエンド・インフラなど領域別にインストラクションファイルを分類管理できるようになる点が大きなメリットです。モノレポ構成のプロジェクトでは各パッケージディレクトリにインストラクションファイルを配置することで、エージェントが作業対象のコンテキストに応じた適切な指示を自動的に読み込むようになります。インストラクションファイルの管理が複雑になる場合は、ファイル名に領域や目的を明記する命名規則（例：frontend-coding-guidelines.instructions.md）を採用すると可読性を維持できます。

ソース管理リポジトリビューでブランチ名やスタッシュ名をコピーできる新操作

v1.111では、ソース管理のリポジトリビューにおいてコンテキストメニューからブランチ名やスタッシュ名をコピーできる機能が追加されました。具体的には、リポジトリビューのアイテムを右クリックすると「Copy Branch Name」「Copy Stash Name」などの選択肢が表示され、ワンクリックでクリップボードにコピーできます。

この機能は一見地味ですが、日常的なGit操作の効率化に貢献します。たとえばチャットやSlackでブランチ名を共有する際、ターミナルでgit branchを実行して手動でコピーする手間が省けます。長いブランチ名（例：feature/JIRA-1234-implement-user-authentication-flow）の場合、タイプミスのリスクを回避できる点も実務上のメリットです。スタッシュ名のコピーも同様で、複数のスタッシュを管理する場面でスタッシュの識別が容易になります。ターミナルでのGit操作が中心のワークフローであっても、ブランチ名の確認と共有だけはGUIから行うという使い分けを取り入れることで、チームコミュニケーションの正確性が向上します。

CJK全角句読点の幅統一やfoldedLineカーソル移動など細部のエディタ改善一覧

v1.111にはエディタの内部動作に関する細かな改善も含まれています。まずCJK（中国語・日本語・韓国語）の全角句読点が一貫した幅でレンダリングされるようになりました。従来は一部の全角句読点が半角幅で表示されるケースがあり、日本語ドキュメントの表示崩れの原因となっていました。この修正により、日本語環境での表示品質が向上しています。

特にfoldedLine単位のカーソル移動は、Vimライクな操作を好む開発者にとって嬉しい改善です。折りたたまれたコード領域を1ステップとして扱うカーソル移動がcursorMoveコマンドで利用可能になったことで、大量のコードを折りたたんだ状態での効率的なナビゲーションが実現します。テーマのトークンカスタマイゼーションでフォントサイズやウェイトに相対値が指定できるようになった点も、テーマ開発者にとっては柔軟性の向上を意味します。

v1.110以前との機能差分とv1.111へのアップデート判断に必要な比較情報

v1.111が週次リリースの第1弾であることを踏まえると、直前のv1.110（February 2026）や、それ以前のv1.109（January 2026）、v1.108（December 2025）との機能差分を正確に把握しておくことが重要です。各バージョンで導入された主要機能を整理し、どの時点からアップデートするのが最も合理的かを判断するための比較情報をまとめます。

v1.110で導入されたAgent PluginsやSession Memoryとv1.111追加機能の関係

v1.110は2026年2月のリリースとして大型のアップデートが多数含まれたバージョンです。Agent Pluginsは拡張機能ビューからスキル・ツール・フックのバンドルをインストールできる機能で、エージェントのカスタマイズを簡便化しました。Session Memoryはチャットセッション内で計画やガイダンスをターン間で持続させる仕組みで、長時間のタスク遂行時にエージェントがコンテキストを忘れにくくなります。またContext Compactionは会話履歴を手動または自動で圧縮してコンテキストウィンドウの空きを確保する機能です。

v1.111のエージェント権限やスコープフックは、これらv1.110の大型機能を安全かつ効率的に運用するための制御機構として位置づけられます。たとえばAgent Pluginsで導入したカスタムスキルが想定外の動作をした場合にAutopilot権限を即座にDefault Approvalsに切り替えて安全を確保する、あるいはスコープフックでPlugin固有のバリデーションを自動実行するといった組み合わせが可能です。v1.110とv1.111はセットで導入することで最大の効果が得られる関係にあり、v1.110をスキップしてv1.111だけを適用するケースでも両バージョンの変更が同時に反映されるため問題はありません。

v1.109で搭載されたClaude互換やAgent Hooksとv1.111での拡張ポイントの違い

v1.109（January 2026リリース）では、Claude Agent SDKとの互換性が追加され、Claudeの設定ファイルをVS Code内で直接再利用できるようになりました。またAgent Hooks機能がv1.109.3で初めて導入され、エージェントのライフサイクルの各ポイントでカスタムシェルコマンドを実行できる基盤が整備されました。スキルをスラッシュコマンドとして呼び出す機能もこのバージョンで搭載されています。

v1.111ではこのAgent Hooksがさらに進化し、エージェントスコープフックとして特定のカスタムエージェント単位でフックを定義できるようになりました。v1.109のAgent Hooksがワークスペースまたはユーザーレベルのグローバルなフックであったのに対し、v1.111のスコープフックは.agent.mdのフロントマターに直接記述する形式で、フックの適用範囲をエージェント単位に限定できる点が最大の違いです。Claude互換機能はv1.109以降も継続的に拡張されており、v1.110ではClaude エージェントでのステアリングやキューイング機能が追加されました。v1.111ではClaude関連の新機能は含まれていませんが、エージェント権限やデバッグスナップショットはClaude エージェントを含むすべてのエージェントに適用されます。

v1.108〜v1.111の主要機能を時系列で整理したバージョン別比較表

直近4バージョンの主要機能をバージョン別に整理します。v1.108からv1.111にかけて、VS Codeのエージェント機能が急速に進化してきた流れを俯瞰できます。

この表からわかるとおり、v1.108でエージェントにスキルを教える仕組みが整い、v1.109で複数エージェントの協調基盤が確立し、v1.110で長時間タスクへの対応と可視化が進み、v1.111で制御性とデバッグ体験が磨き込まれるという段階的な進化の流れがあります。現在v1.108以前を使用しているユーザーはv1.111への一括アップデートにより、これらすべての改善が一度に適用されます。

アップデート前に確認すべき拡張機能互換性と設定引き継ぎの5項目チェックリスト

v1.111へのアップデート前に確認しておくべき項目を5つに整理します。特に複数バージョンを一気に飛ばしてアップデートする場合は、中間バージョンで導入された設定変更が蓄積しているため入念な確認が必要です。

• 拡張機能の互換性確認：使用中の主要な拡張機能がv1.111に対応しているか、Marketplaceの各拡張機能ページで確認する。特にAI関連の拡張機能はAPI変更の影響を受けやすいため注意が必要
• settings.jsonのバックアップ：アップデート前にユーザー設定とワークスペース設定の両方をバックアップする。v1.110以降で追加された新設定がデフォルト値で自動適用される場合があるため、既存の設定値との衝突を確認する
• Edit Mode関連設定の確認：chat.editMode.hiddenの状態を確認し、Edit Modeに依存するワークフローがある場合は移行計画を策定する
• フック設定ファイルの配置確認：.github/hooks/や.claude/settings.jsonにフック定義がある場合、v1.111でのスコープフック機能との整合性を確認する
• 自動更新設定の確認：週次リリースに移行するにあたり、update.mode設定が意図した更新方式になっているか確認する

これらの項目をチェックリストとして管理し、アップデート実施前にすべてクリアしていることを確認してから更新を適用してください。問題が発生した場合は、VS Codeの「設定の同期」機能を利用してアップデート前の状態に復元することも可能です。

週次リリースに追従する場合と月次単位で様子を見る場合の判断基準

週次リリースに毎回追従するか、月単位でまとめてアップデートするかは、開発環境の安定性要件とAI機能の活用度合いによって判断すべきです。毎週追従すべきケースとしては、Autopilotやエージェントフックなど最新のAI機能を積極的に活用しているプロジェクト、バグ修正の即時適用が重要なセキュリティ重視の環境、Insiders版の変更を追いかけてフィードバックを提出しているアクティブコントリビューターなどが挙げられます。

一方、月次単位で様子を見る方が適切なケースもあります。拡張機能の互換性が重要で、毎週のテストサイクルを回す余裕がないチームや、AI機能を限定的にしか使用せず従来の編集体験を重視する開発者は、月に1回程度のまとめて更新が合理的です。判断の基準としては、週次更新による機能改善が業務効率にどの程度寄与するかと、更新に伴うテスト・検証コストを天秤にかけることが重要です。中間的な選択肢としては、隔週で更新を確認し、リリースノートに自身の作業に影響する変更が含まれている場合のみ即座に更新するというアプローチも現実的です。

v1.111導入後に実践すべきエージェント設定の最適化と運用のコツ

v1.111へのアップデートが完了したら、新機能を最大限に活用するためのエージェント設定の最適化に取り組みましょう。Autopilot権限の安全な試し方、スコープフックの実務的な構成例、デバッグスナップショットの活用法、週次更新への備えなど、導入後すぐに実践できる具体的な運用のコツを紹介します。

Autopilotを安全に試すためにまず設定すべき権限レベルとワークスペース構成

Autopilotを安全に試すためには、本番プロジェクトとは分離されたテスト用ワークスペースを用意するのが最善です。新規ディレクトリを作成してVS Codeで開き、Workspace Trustを有効化した状態でchat.autopilot.enabledをオンにします。最初はBypass Approvalsから始めて、エージェントのツール呼び出しパターンを把握してからAutopilotに切り替えるのが安全なステップです。

テスト用ワークスペースでの動作確認が完了したら、本番プロジェクトへの適用を検討します。ただし本番プロジェクトでは常にDefault Approvalsを基本とし、定型的なリファクタリングやドキュメント生成など明確にリスクの低いタスクに限ってBypass Approvalsを使用するルールが推奨されます。Autopilotは本番プロジェクトで使用する場合でも、必ずGitブランチを切った状態で実行し、不要な変更があれば即座にブランチを破棄できる体制を整えてください。またchat.tools.terminal.enableAutoApprove設定が自動承認の範囲に影響するため、Autopilot有効時にターミナルコマンドがどこまで自動実行されるかを事前に確認しておくことも重要です。

エージェントスコープフックを使い分ける実務プロジェクトでの構成例

エージェントスコープフックを実務プロジェクトに導入する際の構成例を紹介します。たとえばフロントエンド開発とバックエンド開発で異なるカスタムエージェントを使い分けるプロジェクトでは、フロントエンド用エージェントの.agent.mdにESLintの自動実行フックを設定し、バックエンド用エージェントにはユニットテストの自動実行フックを設定するといった構成が有効です。

具体的なファイル構成としては、プロジェクトルートの.github/agents/ディレクトリにfrontend.agent.mdとbackend.agent.mdを配置します。フロントエンド用エージェントのフロントマターにはPostToolUseイベントでnpx eslint --fixを実行するフックを定義し、バックエンド用エージェントにはStopイベントでnpm testを実行するフックを定義します。この構成により、フロントエンドの編集作業ではコード変更のたびにリントが自動実行され、バックエンドのタスク完了時にはテストスイートが自動的に走ります。スコープフックによってフロントエンドのリントフックがバックエンドのセッションに影響することはなく、各エージェントが独立した品質保証フローを持つクリーンな構成が実現できます。

debugEventsSnapshotとAgent Debugパネルを組み合わせたトラブルシュート手順

エージェントの動作に問題が発生した際の効率的なトラブルシュート手順を紹介します。まずAgent Debugパネルをコマンドパレットから「Developer: Open Agent Debug Panel」で開きます。パネルではリアルタイムでエージェントのイベントストリーム（ツール呼び出し、プロンプトファイルの読み込み、フックの実行など）が確認できるため、問題が発生するまでの動作を目視で追跡します。

1. Agent Debugパネルを開いた状態で問題のあるタスクを再現させる
2. 問題が発生した時点でパネルのスパークルアイコンをクリックしスナップショットを取得する
3. チャット入力欄にトラブルシュートの質問（例：「この時点で読み込まれているカスタマイゼーションは何か」）を入力する
4. エージェントがスナップショットを分析し、原因の候補を提示する
5. 提示された原因に基づいて設定やフックの修正を行い、再度タスクを実行して問題が解消されたことを確認する

さらにv1.111で導入された/troubleshootスラッシュコマンドを使用すると、エージェントモードのイベントログをチャットコンテキストに直接注入できます。このコマンドはどのカスタマイゼーションが読み込まれているか、トークンの消費量はいくつかといった情報を簡単に確認できるため、スナップショットと組み合わせて活用することで問題の特定から解決までの時間を大幅に短縮できます。

週次アップデートに備えてsettings.jsonをバックアップする運用ルールの設計

週次リリースに移行したことで、設定ファイルの管理がこれまで以上に重要になります。毎週のアップデートで新しい設定項目が追加されたり、デフォルト値が変更される可能性があるため、settings.jsonのバックアップを定期的に取得する運用ルールの設計が推奨されます。

もっとも簡便な方法は、VS Codeの「設定の同期（Settings Sync）」機能を有効化しておくことです。GitHubアカウントまたはMicrosoftアカウントと連携することで、設定・拡張機能・キーバインドなどがクラウドに自動バックアップされます。ただし設定の同期は上書き型のため、バージョンごとの差分を管理したい場合はGitリポジトリによる管理が有効です。ユーザー設定ディレクトリ（macOSの場合は~/Library/Application Support/Code/User/、Windowsの場合は%APPDATA%\Code\User\）をGitリポジトリとして初期化し、アップデート前後でコミットを打つことで変更履歴を追跡できます。チーム開発では、推奨設定をリポジトリの.vscode/settings.jsonで管理し、個人の好み設定はユーザーレベルで上書きするという分離が週次更新への耐性を高めます。

v1.111の新機能を段階的に導入して開発チーム全体に展開する3ステップ

v1.111の新機能をチーム全体に展開する際は、段階的なアプローチが混乱を最小限に抑えます。推奨する3ステップの導入計画を紹介します。

第1ステップは「技術リードによる先行検証」です。チーム内の技術リードまたはアーキテクトが先にv1.111にアップデートし、Autopilot権限やスコープフックの動作を1〜2週間かけて検証します。プロジェクト固有の拡張機能やビルドツールとの互換性を確認し、問題があればIssueとして記録します。第2ステップは「パイロットグループへの展開」です。技術リードの検証を経て安定性が確認された段階で、チームの3〜4名に展開します。この段階では権限レベルの推奨値やスコープフックの標準構成をドキュメント化し、パイロットメンバーからのフィードバックをもとに運用ルールを調整します。第3ステップは「全体展開とガイドライン配布」です。パイロットグループでの運用が安定したら、チーム全体にアップデートを展開します。この際にv1.111の新機能の概要、推奨設定値、トラブルシュート手順をまとめた社内ガイドラインを配布し、30分程度のハンズオンセッションを実施することで移行の摩擦を最小化できます。あわせて、VSCode 1.118の新機能まとめについても解説しています。