タグアーカイブ VS Code

GPT-5.5の応答を改善、VS Codeのプロンプトチューニング手法

GPT-5.5の応答が改善された技術的背景

GPT-5.5の応答が改善された技術的背景

VS Codeが提供するAIエージェント機能は、コード生成の裏側で「コーディングハーネス」と呼ばれる仕組みが動いている。これはモデルとツール、コンテキスト、指示、エージェントのループを繋ぐ層だ。モデルがコードを書くための土台となる部分といえる。

2026年7月、VS CodeチームはOpenAIと協力し、GPT-5.5向けのシステムプロンプトを改善する実験を実施した。焦点は「エージェントの探索を減らし、検証を早める」ことにある。この変更で応答速度とコストの両方を改善できるかどうかが検証された。

プロンプトチューニングの目的と仮説

GPT-5.5のリリース後、VS Codeチームはエージェントがトークンをどのように消費しているかを分析した。分析の結果、モデルが実際の編集に入る前に過剰な探索を行っているパターンが浮かび上がった。具体的には、ファイルの再読込や周辺コードの比較に多くのトークンが費やされていた。

この観察から1つの仮説が導かれた。それは「エージェントはさまよう努力を減らし、証拠、行動、検証という意図的なループに注力すべきである」というものだ。この仮説を検証するため、2種類のプロンプトが用意された。

従来のエージェント行動(Before)
エージェント 要求受信 広範な検索 ファイル再読込 比較 ようやく編集
※トークン消費が大きく、最初の編集までに時間がかかる
改善後のエージェント行動(After)
エージェント 要求受信 仮説形成 局所検索 検証可能な編集 即時検証
※探索を抑制し、最初の編集と検証を優先する

エージェントが編集前に「考えすぎる」状態を減らし、必要最小限の探索で行動に移すよう誘導する。この考え方は、トークン消費と応答時間の両方に直接影響を与える。

実験の中身と2つのアプローチ

実験の中身と2つのアプローチ

実験は2週間にわたって実施された。GPT-5.5のエージェントトラフィックを、対照群と2つの処置群に25%ずつ分割し、残りの25%はスコアカード外でデフォルトプロンプトが使用された。この設計により、同じ種類のユーザートラフィックで公平な比較が可能になる。

処置A「PRPT_SRCH」簡潔な探索と編集

処置Aは小規模で焦点を絞った変更だ。プロンプトに1つのコンパクトな指示を追加し、不必要な探索を減らすようモデルに促す。この指示は「economical_search_and_edit」セクションと呼ばれる。

具体的には、次の5つの行動指針が与えられた。最も具体的なアンカー(ファイル、シンボル、失敗している動作など)から開始すること。1つの仮説とそれを否定できる安価なチェックを選ぶために十分な周辺コンテキストだけを集めること。広範なリポジトリ探索より1回の対象検索を優先すること。最も安価な判別チェックがわかったら即座に行動すること。そして、新しい結果が関連性を示さない限り、変更されていないコンテキストを再読しないことだ。

economical_search_and_edit:
    - 最も具体的なアンカーから開始する
    - 1つの仮説とその反証チェックに十分なコンテキストだけを集める
    - 広範な探索より1回の対象検索を優先する
    - 最も安価な判別チェックがわかったら即行動する
    - 変更されていないコンテキストは再読しない

処置B「PRPT_LRG」大規模プロンプト再構成

処置Bは同じ仮説をより広範に展開したものだ。エージェントのワークフローを「Before_the_first_edit(最初の編集前)」と「After_the_first_edit(最初の編集後)」の2つの明示的なセクションに再編成する。

このアプローチの狙いは、検索ステップだけでなくループ全体を解決することにある。最初の編集前に局所的な仮説を形成し、広範な探索を避け、根拠のある最初の編集を行い、最初の実質的な編集後に即座に検証する。処置Aと異なり、プロンプト自体のサイズは大きくなるため、構造の追加が効率を改善できるかどうかが重要な論点だった。

処置A PRPT_SRCH(簡潔アプローチ)
変更量 小(1つのコンパクトな指示を追加)
構造 単一セクション
焦点 探索の抑制に特化
vs
処置B PRPT_LRG(大規模アプローチ)
変更量 大(編集前と編集後の2セクションに再構成)
構造 Before/After の2段階
焦点 探索抑制+編集後の検証まで含めたループ全体
処置A:簡潔な指示追加  処置B:ワークフロー全体の再構成

両処置の設計思想の違いは明確だ。処置Aは最小限の介入で探索を抑えるのに対し、処置Bはエージェントの行動全体を構造化して制御しようとする。この差が実際のパフォーマンスにどう現れるかが実験の焦点になった。

2週間のスコアカードが示した結果

2週間のスコアカードが示した結果

実験では品質、レイテンシ、効率の3つの次元で評価が行われた。品質は「コードが定着するか」、レイテンシは「最初の編集がどれだけ早く行われるか」、効率は「トークンとツール呼び出しの数」で測定される。

品質指標 10分生存率とコミット生存率

10分生存率は、AIが書いたコードのうち10分後もファイルに残っている割合を示す。コミット生存率は、さらに厳格にgitコミットまで生き残ったコードの割合だ。この2つが品質のガードレール指標となる。

結果として、コミット生存率は処置Bで+0.68%とわずかに上昇し、処置Aでは-0.48%とわずかに低下したが、いずれも統計的に有意ではなかった。10分生存率は両処置ともわずかに低下し、処置Bの-0.44%だけが統計的有意の閾値をわずかに超えた(p=0.0493)。VS Codeチームはこれを「実際のトレードオフとして考慮すべきだが、動きは小さく、他の品質ガードレールは後退しなかった」と評価している。

レイテンシ指標 初回編集までの時間

編集レイテンシでは処置Bが最も強い改善を示した。p50(中央値)の初回編集時間は-5.68%(3.9秒高速化、p=2e-5)、p95(下位5%の遅いケース)では-9.30%(38.8秒高速化、p=1e-10)といずれも高い統計的有意性を示した。

処置Aもp50で-2.88%(2.0秒高速化、p=0.0271)と改善したが、p95の改善は統計的に有意ではなかった。遅いケースでの差が特に顕著で、「なぜこれが遅いのか」というストレスを感じる場面での改善が大きかったことになる。

トークン効率とツール呼び出し回数

1ユーザーあたりの日次トークン消費量(p50)は両処置とも減少したが、統計的有意ではなかった。しかし、トークン消費の裾野(p95、特に重いリクエスト)では、処置Bが-7.64%(p=0.0003)、処置Aが-5.19%(p=0.0157)と明確な改善を示した。

平均ツール呼び出し回数も両処置で減少した。処置Bは-8.54%(1ターンあたり2.04回の呼び出し削減、p=1e-12)、処置Aは-3.19%(0.77回削減、p=0.0091)だ。処置Bの優位性は極めて高い統計的有意性で裏付けられた。

主要指標の改善度比較(処置B vs 処置A)
p50 初回編集時間 処置B -5.68% 処置A -2.88%
p95 初回編集時間 処置B -9.30% 処置A -1.93%
p95 トークン消費 処置B -7.64% 処置A -5.19%
ツール呼び出し削減 処置B -8.54% 処置A -3.19%
処置Bが顕著に優位  処置Aは部分的改善  統計的有意性なし/低下

処置Bは総合的に最も強いプロファイルを示した。レイテンシの明確な勝利、裾野トークンの有意な削減、ツール呼び出しの減少、そして品質ガードレールのほぼ安定。10分生存率のわずかな低下は軽微な有意性(p=0.0493)にとどまり、レイテンシやトークン、ツール呼び出しの改善ははるかに大きく堅牢だった。

プロンプトチューニングが示す開発体験の進化

プロンプトチューニングが示す開発体験の進化

この実験の成果は数字の変化だけではない。重要なのは、プロバイダからのフィードバックに基づく検証可能な仮説を、オフライン評価で事前検証し、2週間の本番環境で確認するという一連のループが機能したことだ。

モデルのリリースはチューニングループの終点ではない。VS Code上の実際の動作を観察し、焦点を絞った改善をテストし、より速く、信頼性が高く、効率的な体験を実現する新たな方法を見つける機会となる。このプロンプトチューニングは、その1つの具体的な実例だ。

使用量ベース課金におけるトークン効率の重要性

この改善が特に重要なのは、使用量ベースの課金モデルが前提にあるからだ。トークン効率は単なるインフラ指標ではない。エージェントが探索に費やすすべてのトークンは、ユーザーが支払い、待たされる対象だ。根拠のある編集に早く到達するエージェントは、より良い体験とより小さい請求額の両方をもたらす。

VS Codeチームはこの取り組みを継続する方針を示している。モデル、プロンプト、ツール、コーディングハーネス全体にわたって改善点を探し続け、エージェントの予算が必要な作業に集中できるよう最適化していくという。

プロンプトチューニングの改善ループ
STEP 1 VS Code上の実際のエージェント動作を観察し、トークン消費パターンを分析する
STEP 2 プロバイダ(OpenAI)のモデル専門知識と協力し、仮説を形成する
STEP 3 オフライン評価で仮説を事前検証し、有望なプロンプト案を絞り込む
STEP 4 本番トラフィックで2週間のA/Bテストを実施し、統計的有意性を確認する
結果 勝利した処置Bをデフォルトプロンプトとして出荷、次の改善サイクルへ

このループが示すのは、AI開発支援ツールの進化がモデルの性能向上だけに依存する段階から、プロンプト設計やツール連携の最適化を含む総合的な取り組みへと移行していることだ。モデルが高性能でも、使い方が適切でなければ本来の力を発揮できない。その橋渡しをするのがプロンプトチューニングの役割といえる。

この記事のポイント

  • GPT-5.5向けのプロンプトチューニングで、エージェントの探索を抑制し検証を早める改善が実施された
  • 処置B(大規模プロンプト再構成)が最も優れた結果を示し、p95の初回編集時間を9.30%短縮した
  • ツール呼び出し回数は8.54%削減され、トークン消費の裾野(重いリクエスト)でも7.64%の改善が確認された
  • 品質指標(コード定着率)はほぼ維持され、速度と効率の改善が品質を犠牲にしないことが実証された
  • 使用量ベース課金の文脈では、トークン効率の改善がユーザーのコスト削減に直結する重要性を持つ
VS Code 1.127リリース、エージェントブラウザツールがGAに

VS Code 1.127リリース、エージェントブラウザツールがGAに

VS Code 1.127が2026年7月1日に公開された。今回のアップデートの焦点は、エージェント機能向けの統合ブラウザツールがプレビューを経て一般提供(GA)になった点と、エージェントウィンドウのセッション管理が大幅に強化された点にある。

ブラウザツールによって、AIエージェントはVS Code内のブラウザでページを開き、スクリーンショットを取得し、クリック操作まで行えるようになる。セッション管理ではグループ化やドラッグ&ドロップ、チャット入力バナーによるCI/CD統合、マルチチャットの改善が含まれ、開発者の生産性を高める機能が多数追加された。

エージェント向けブラウザツールが一般提供に、サイトごとの権限制御も実装

エージェント向けブラウザツールが一般提供に、サイトごとの権限制御も実装

「ブラウザツール」の概要とGA化の意義

エージェント向けブラウザツールは、VS Codeの統合ブラウザ上でAIエージェントがWebアプリを開き、コンテンツの読み取り、コンソールエラーの取得、スクリーンショット撮影、さらにはクリックや入力といった操作を自律的に行えるようにする機能だ。これまでプレビューとして提供されていたが、1.127で一般提供へ移行し、デフォルトで有効化された。

このツールにより、エージェントは「Webアプリを構築して」という指示に対し、コード生成だけでなく実際のブラウザ上での表示確認やエラー検出、修正までをひとつのループで完結させられる。従来は開発者が逐一ブラウザで確認し、エージェントに修正を依頼する手間があったが、そのサイクルが自動化される。外部のMCPサーバーを用意する必要もない。

管理者はエンタープライズポリシーでブラウザツールの利用を制御できる。BrowserChatToolsポリシーで機能自体を無効化したり、エージェントネットワークフィルタリングによってアクセス可能なドメインを制限したりすることが可能だ。

STEP 1 開発者がエージェントにWebアプリの構築を指示
STEP 2 エージェントがコードを生成し、統合ブラウザでページを開く
STEP 3 エージェントがスクリーンショットを撮り、表示内容やコンソールエラーを検証
STEP 4 レイアウト崩れやエラーがあれば自動修正→再テストのループ
開発者指示  エージェント判断  ブラウザ検証

ブラウザツールを活用すると、エージェントが独力でビルドからテスト、修正までのサイクルを回せる。開発者が手動で行っていた確認作業の大部分が自動化され、より高次の設計やレビューに集中できるようになる。

カメラや位置情報などサイト単位の権限制御

統合ブラウザにサイト単位の権限設定が追加された。ページがカメラ、マイク、位置情報、加速度センサー、Bluetooth、USBなどのWeb APIを要求した際、通常のブラウザと同様に許可・拒否のプロンプトが表示される。許可した内容は「サイト権限」メニューから一括管理できる。

これにより、ビデオ会議やフィットネス系Webアプリのテストなど、従来は統合ブラウザでは動作が制限されていたシナリオでもエージェント検証が可能になる。エージェントがカメラ映像を解析する必要があるテストも、この権限制御のもとで安全に実施できる。

エージェントセッション管理が大幅強化、グループ化やマルチチャットで並行作業を効率化

エージェントセッション管理が大幅強化、グループ化やマルチチャットで並行作業を効率化

セッションをグループで整理し、ドラッグ&ドロップで並べ替え

エージェントウィンドウのセッションリストにグループ機能が追加された。複数のセッションを任意のグループにまとめられ、グループヘッダーを折りたたむことでリストを整理できる。各グループには「新しいセッションを開始」「グループ内の全セッションを完了としてマーク」といったクイックアクションも用意されている。

ドラッグ&ドロップにも新たに対応し、セッションの並べ替えやグループ間の移動、ピン留めが直感的に行える。複数セッションを選択してまとめて移動することも可能だ。

チャット入力バナーでプルリクエストのCI失敗やレビューコメントに即対応

エージェントがプルリクエストを作成しているセッションでは、チャット入力欄の真上にバナーが表示される。CIチェックが失敗した場合は「2 of 5 checks failed」といった件数とともに「チェックを修正」「詳細を表示」のアクションボタンが現れ、新たなレビューコメントが届いた際も同様に「コメントに対処」「コメントを表示」がワンクリックで実行できる。

従来はGitHubの画面を開いて状況を確認し、別途エージェントに指示を出す必要があった。このバナーにより、会話の流れを中断せずにエージェントへ修正を委ねられる。

従来のワークフロー(Before)
GitHubの別タブでCI失敗を確認し、手動でエージェントに修正指示を与える
VS Code 1.127のチャット入力バナー(After)
CIチェック失敗(2/5件) 要修正
チェックを修正 詳細を表示
バナー上のボタンひとつでエージェントに修正を開始させられる

チャット入力バナーにより、プルリクエストのCI失敗やレビューコメントが即座に可視化され、対応のリードタイムが短縮される。開発者がコンテキストを切り替える頻度も減るため、集中力を保ちやすい。

マルチチャットセッションの改善とエディタガターからのフィードバック

ひとつのエージェントホストセッション内で複数のチャットを走らせるマルチチャット機能にも改良が加わった。タブでチャットを切り替えられ、不要なチャットは閉じて非表示にし、後から「会話」ドロップダウンで再表示できる。完全に削除したい場合はタブのコンテキストメニューから「チャットを削除」を選択する。

進捗状況とファイル変更は全チャットで集約されるようになった。ひとつのチャットが作業中であればセッション全体が進行中と表示され、各タブにも個別の進捗が示される。セッションヘッダーの「Changes」ピルには、すべてのピアチャットの編集内容が合算されるため、並行して行われている変更の全容を把握しやすくなった。

会話のフォークも改善され、マルチチャットセッション内ではフォークが新たなピアチャットとして作成される。フォークしたチャットは分岐点までの会話を引き継ぎ、兄弟チャットとは独立して動作する。エディタのガターからは直接フィードバックを追加できるようになり、エージェントに修正してほしい行をホバー操作で即座に指摘できる。

チャットとターミナルの新機能、コスト管理の透明化

チャットとターミナルの新機能、コスト管理の透明化

/troubleshootコマンドでエージェントの動作を診断

エージェントの動作に問題がある場合に利用できる/troubleshootコマンドが拡張され、エージェントホストセッションも診断対象になった。チャット入力欄で/troubleshootを入力し、続けて#sessionで特定のセッションを選択し、質問や問題の説明を追加すると、チャットログを解析してエージェントの振る舞いに関するインサイトを提示する。カスタム指示が無視される理由や応答が遅い原因の調査に役立つ。

ターミナルコマンドのサンドボックス化(macOSとLinux)

エージェントが実行するターミナルコマンドを、ネットワークアクセスを遮断しファイルシステムへのアクセスを制限したサンドボックス内で動作させる機能がmacOSとLinux向けに展開された。コマンドをサンドボックス外で実行する必要がある場合にのみエージェントが承認を求める仕組みで、毎回のプロンプト表示頻度が大幅に減る。

この機能はデフォルトで有効だが、権限設定のドロップダウンからオフにすることも可能だ。サンドボックス化によってエージェントの自律性が高まり、定型作業中の中断が少なくなる。開発者の心理的負荷も軽減されるだろう。

サンドボックス化以前(Before)
エージェントがターミナルコマンドを実行するたびに「実行してよいか」の承認ダイアログが毎回表示される
npm install(承認待ち)→ テスト実行(承認待ち)→ …
サンドボックス化有効(After)
ネットワーク遮断・ファイルアクセス制限付きでコマンドが自動実行される。昇格が必要な場合のみ承認を求める
npm install(自動)→ テスト(自動)→ サーバー起動(昇格要求があれば承認)

ターミナルコマンドのサンドボックス化は、エージェントの自律性を大きく引き上げる。毎回の承認待ちがなくなることで、ビルドからテストまでのパイプラインをエージェントがほぼ自動で進められるようになり、開発者の介入は「昇格が必要な重大操作」に絞られる。

サブエージェントの消費クレジットをホバー表示

エージェントがサブエージェントに作業を委譲した際、どの程度のAIクレジットが消費されたかが分かりにくいという課題があった。今回のアップデートで、チャット応答内のサブエージェントセクションにマウスカーソルを合わせると、そのサブエージェントが使用したクレジット数が表示されるようになった。コストの透明性が向上し、エージェントの利用計画を立てやすくなる。

Ollama内蔵プロバイダーが非推奨に、公式拡張への移行を推奨

Ollama内蔵プロバイダーが非推奨に、公式拡張への移行を推奨

公式Ollama拡張の提供開始と内蔵プロバイダーの非推奨化

モデルプロバイダーを拡張機能として提供する方針が明確化され、Ollamaの公式VS Code拡張がマーケットプレイスで公開された。これに伴い、これまで内蔵されていたOllamaプロバイダーは非推奨となった。ローカルのOllamaモデルをチャットで利用するには、公式拡張をインストールする方法が推奨される。

Bring Your Own Key(BYOK)で内蔵プロバイダーを使っていたユーザーは、公式拡張をインストールした後に内蔵プロバイダーを削除することで、継続してモデルを利用できる。非推奨プロバイダーの削除手順は、VS Code Blogのリリースノート内の動画で確認できる。

旧来の方法(非推奨)
内蔵プロバイダー 設定ファイルでOllamaを指定
推奨される方法(After)
公式拡張 Ollama VS Code拡張をインストール
内蔵プロバイダーは削除して移行する

公式拡張への移行は、今後のOllamaモデルへの迅速な対応やセキュリティ更新を受け取るためにも重要だ。非推奨プロバイダーは近い将来削除されるため、早めの切り替えが望ましい。

エンタープライズ向け設定をファイル配信可能に、デバイス管理外でも適用

エンタープライズ向け設定をファイル配信可能に、デバイス管理外でも適用

managed-settings.jsonによるCopilot設定の配信

管理者がGitHub Copilotのポリシーを適用する手段として、JSONファイルをOS固有のパスに配置する方式が追加された。MDM(モバイルデバイス管理)に登録されていないマシンや、構成管理システムでファイルを配信する方が簡便な環境で役立つ。macOSでは/Library/Application Support/GitHubCopilot/managed-settings.json、Linuxでは/etc/github-copilot/managed-settings.json、Windowsでは%ProgramFiles%\GitHubCopilot\managed-settings.jsonにファイルを置く。

ファイルのスキーマはGitHub.com上で管理者が設定する場合と同一で、アクセス許可やプラグインの有効・無効を制御できる。このファイルは、MDMやアカウントベースのエンタープライズ設定が存在しない場合にのみ適用されるため、既存の管理手法と競合しない。

この記事のポイント

  • エージェント向けブラウザツールが一般提供開始、外部MCPサーバー不要でテスト自動化が可能に
  • セッション管理がグループ化・ドラッグ&ドロップ・マルチチャット強化で並行作業の効率が向上
  • チャット入力バナーでCI/CDフィードバックをその場で処理、ワークフローが途切れない
  • ターミナルコマンドのサンドボックス化でエージェントの自律性が高まり、承認回数が減少
  • Ollamaは公式拡張に移行し、内蔵プロバイダーは非推奨へ
  • エンタープライズ向けに設定ファイル配信が可能になり、管理対象外端末にもポリシーを適用
VS Code、TypeScript 7移行で型チェック7倍高速化 段階的アプローチの全貌

VS Code、TypeScript 7移行で型チェック7倍高速化 段階的アプローチの全貌

VS Codeチームは2026年2月、TypeScript 7をデフォルトの型チェッカーおよび言語サービスとして採用した。この移行により、VS Code本体の型チェック時間は36秒から5秒へと7倍以上高速化した。全ファイルのビルド時間も80秒から20秒に短縮され、開発者1人あたりの待ち時間が1日に数分単位で削減された。

この劇的な改善は、約6ヶ月にわたる段階的な導入プロセスによって実現した。一気に切り替えるのではなく、低リスクな領域から少しずつTypeScript 7の利用範囲を広げていくことで、バグの早期発見とTypeScriptチームへの継続的なフィードバックが可能になった。以下では、その具体的な戦略と得られた数値、TypeScriptチームとの協業の詳細を解説する。

段階的移行の全体像とメリット

段階的移行の全体像とメリット

リスクを最小化しながら早期フィードバックを得る

VS Codeチームは大規模な変更を行う際、常にインクリメンタル(段階的)なアプローチを選ぶ。その理由は主に2つある。1つはリスクの低減だ。各ステップが小さいため、何か問題が起きても原因の特定と差し戻しが非常に容易になる。2つ目は早期のフィードバックである。TypeScript 7がまだ開発中の段階から、実際の大規模コードベースでテストを始めることで、見過ごされがちなバグや改善点をTypeScriptチームに直接届けられた。

小さな改善を積み重ねるエンジニアリング文化

VS Codeチームは以前にも、コードベース全体にわたるstrict nullチェックの有効化や、リモート開発サポートの追加といった大規模な取り組みを、同じ段階的手法で成功させてきた。今回のTypeScript 7移行もその延長線上にある。一度に大きな変更を加えず、小さな改善をメインブランチに繰り返しマージしていくことで、気づけば一見不可能に思えた課題を克服している。この文化が、Goで書き直された高速なTypeScript 7の恩恵を早期に引き出す原動力となった。

6段階の移行フェーズ詳細

6段階の移行フェーズ詳細
VS CodeにおけるTypeScript 7導入ステップ
STEP 1 探索:プレビュー版で小規模テストとバグ報告
STEP 2 TypeScript 6導入:移行前の互換性確保と改善
STEP 3 TS 6と7の並行稼働:CI上で両方の型チェックを必須化
STEP 4 拡張機能の個別移行とビルドツールの簡素化
STEP 5 TS 7をデフォルト化:全開発者が日常的に利用

上図は約6ヶ月にわたる移行の大まかな流れだ。各ステップが小さく、問題が起きてもすぐに原因を特定できる設計だった。

探索フェーズ(2025年夏〜秋)

TypeScript 7は2025年3月に公開され、夏頃には初期テストが可能な状態にあった。この時点では型チェック機能の方がJavaScript生成(emit)よりも進んでいたため、VS Codeチームはまず --noEmit オプションを使って小規模な拡張機能の型チェックを手動でテストした。問題が見つかり次第、日次で更新されるプレビューパッケージを使って素早く修正を確認するというサイクルが回り始めた。

TypeScript 6による架け橋(2025年秋)

TypeScriptチームは、ユーザーが一足飛びにTS 7へ移行する負荷を軽減するため、TypeScript 6を「橋渡しバージョン」としてリリースした。TS 6では、それまでデフォルトでなかったstrict nullチェックの有効化や、ターゲットのESバージョン引き上げなど、TS 7への適合を容易にする変更が行われた。VS Codeにとっては、完全に書き直されたTS 7への移行に比べるとはるかに小さな一歩であり、わずかなコード修正で対応できた。このステップが、コードベースの健全性を高め、TS 7本番導入への自信を深める役割を果たした。

TS 6と7の並行稼働(2025年秋)

次の段階では、最もリスクの低い領域である「組み込み拡張機能の型チェック」にTypeScript 7の利用を開始した。同時に、CI(継続的インテグレーション)の設定を変更し、TS 6とTS 7の両方でビルドが成功することを必須化した。この並行稼働によって、両バージョンの型チェック結果の微妙な差異を検出し、TypeScriptチームへ報告することができた。

拡張機能の段階的切り替え(2026年1〜2月)

2026年初頭には、TypeScript 7の型チェックの信頼性が十分に高まり、emit機能も完成した。VS Codeチームは内蔵の拡張機能を1つずつTS 7へ移行し始めた。同時に、バンドルツールをwebpackからesbuildに切り替え、ビルド構成を簡素化した。この変更により、バンドル生成の時間も大幅に短縮された。移行は単純な拡張機能から始め、徐々に複雑なものへと広げていった。すでにTS 7でのテスト実績が豊富だったため、問題はほとんど起きなかった。

TS 7のデフォルト化(2026年2月)

最終段階として、通常の開発タスクで実行するウォッチャーやエディタ内で使用する言語サービスをTypeScript 7に切り替えた。コード変更自体は非常に軽微だった。VS Codeリポジトリでは今も旧バージョンへの切り戻しオプションが残されているが、実際に使われることは稀だ。ほとんどの開発者は、TS 7の圧倒的なパフォーマンスの前に戻る理由がない。

数値で見る劇的なパフォーマンス向上

数値で見る劇的なパフォーマンス向上
従来のTypeScript 6 (Before)
36秒 フル型チェック (tsc --noEmit)
VS Codeメインコードベースの型チェックに必要だった時間
TypeScript 7 (After)
5秒 フル型チェック (tsgo --noEmit)
約7倍の高速化を達成。瞬時に近いフィードバックが可能に

上記の比較は、同一のファイル群に対して同じ厳密さで型チェックを実行した結果だ。Goによるネイティブ再実装がこれほど大きな差を生み出した。

型チェック速度の比較

VS Codeのメインコードベースにおける型チェック時間は、TS 6では約36秒だった。TS 7に切り替えることで、同じ処理が5秒で完了する。実に7倍以上の高速化だ。この処理は開発中に何度も実行されるため、待ち時間の累積短縮効果は非常に大きい。

ビルド時間全体の短縮

npm run watch コマンドによるフルビルドと型チェックでは、TS 6利用時に約80秒かかっていた。TS 7移行後は約20秒にまで短縮され、約4分の1の時間で完了する。1回の再起動ごとに約1分が節約され、エージェント支援開発のイテレーション速度も大幅に向上した。

エディタ内言語サポートの起動時間

エディタでTypeScriptの補完やエラー表示を行うには、背後でプロジェクト全体の読み込みが必要になる。VS Codeのメインプロジェクトでは、TS 6時代に約1分を要していたこの処理が、TS 7では10秒ほどで完了する。開発者はエディタの再読み込みを1日に何度も行うため、この50秒の短縮が日々の生産性に直結する。

TypeScriptチームとの協業がもたらした相乗効果

TypeScriptチームとの協業がもたらした相乗効果

大規模コードベースが生きたテスト環境に

VS Codeの巨大で複雑なコードベースは、TypeScript 7の実地テスト環境として非常に優秀だった。新バージョンの開発中から実際の利用に近い形でテストを行い、バグを発見し、エディタツールの完成度を高めることに貢献した。VS Codeチームの開発者たちは、少しでも動作に違和感があれば旧バージョンに切り替え、その都度TypeScriptチームが修正の優先度を判断した。

フォーマット不一致が早期修正を促進

開発者が旧バージョンに戻る最も意外な理由は「コードフォーマットの不一致」だった。補完提案や定義ジャンプの不整合はある程度許容できても、フォーマットの差はPRのコミット前チェックやCIの検証を失敗させる。そのため、わずかな空白の違いまでもが高い優先度で修正された。このフィードバックループが、結果としてTS 7の言事語サポート全体の品質を引き上げた。

フィードバックループの構築

VS CodeチームはTypeScript 7のプレビュー版を試しやすい環境を整え、問題があればエディタから直接報告できる仕組みを作った。報告のハードルを下げることで、小さな違和感も即座にフィードバックとして蓄積された。こうした緊密な連携が、本番運用に耐えうる安定版の早期完成を支えた。

大規模移行プロジェクトから得られた教訓

大規模移行プロジェクトから得られた教訓

TypeScript 7への移行は、VS Codeチームにとって単なるツールのバージョンアップ以上の意味を持つ。段階的に取り組む文化、早期から本番に近い環境でテストする姿勢、そしてツール開発チームとの緊密なコラボレーションが、巨大なコードベースを迅速かつ安全にモダナイズする鍵だった。

VS Codeチームは、この経験が他のプロジェクトにおける大規模なエンジニアリング課題への取り組み方にも応用できると期待している。小さな一歩を積み重ね、フィードバックループを短く保ち、協業を恐れないこと。これらの価値観が、最終的にはより良いプロダクトをより早く届ける力になる。

この記事のポイント

  • VS Codeは約6ヶ月の段階的移行でTypeScript 7を導入。リスクを抑えつつ早期フィードバックを得られた
  • メインコードベースの型チェックが36秒→5秒に高速化。ビルド全体も80秒→20秒に短縮
  • エディタの言語サポート起動が約1分→10秒に短縮され、日々の開発効率が大幅に向上
  • 大規模コードベースがTypeScript 7の実地テスト環境として機能し、協業が相乗効果を生んだ
  • 段階的アプローチと密なフィードバックループが、大規模移行をスムーズに進める鍵となる
VS Code 1.124が公開、AIエージェントがさらに賢く進化しマルチチャット対応

VS Code 1.124が公開、AIエージェントがさらに賢く進化しマルチチャット対応

“`md — — title: “VS Code 1.124が公開。AIエージェントがさらに賢く進化しマルチチャット対応” meta_description: “VS Code 1.124が2026年6月に公開。Agentsウィンドウのマルチチャット対応やバックグラウンド送信、WSL連携の強化、統合ブラウザの改善点を詳しく解説。” tags: [“VS Code”, “アップデート”, “AI”, “開発支援”, “エージェント”, “統合ブラウザ”, “WSL”] slug: “vscode-1-124-release” scrape_method: “trafilatura” image_prompt: “Upper portion: a wide monitor screen showing the Visual Studio Code editor with the Agents window open, displaying multiple chat sessions in a grid layout, all interface text in English. The VS Code logo (an angular blue ribbon mark) prominently displayed in photorealistic 3D with subtle reflections. Lower portion: a sleek server rack with glowing blue and purple fiber optic cables in a dark data center. Composition: split-screen style with key visual elements positioned in the upper and lower portions of the frame, with a natural atmospheric transition in between, no horizontal bands or strips across the frame. 16:9 aspect ratio. If UI screens, dashboards, code editors, or admin panels appear, all text within them must be in English. If laptops or monitors appear, use ultra-thin bezel modern design. No visible year numbers on calendars, screens, or documents.” featured_text: “VS Code 1.124\nAIエージェント進化” — —

VS Code 1.124が2026年6月に公開された。今回のアップデートの中核は、AIエージェント機能「Agents」ウィンドウの大幅な機能強化だ。マルチチャットやバックグラウンド送信といったワークフローを加速させる機能が追加され、開発者の作業効率は一段と向上する。

このリリースでは、WSL環境とのシームレスな接続や、統合ブラウザのカスタマイズ性向上も同時に実現された。大規模なリファクタリングや新規開発の伴走者として、VS CodeのAI機能はより実用的な段階に入ったといえる。

本記事では、VS Code 1.124の主要な変更点を3つの観点から掘り下げ、実際の開発現場でどう役立つのかを具体的に解説する。

Agentsウィンドウのマルチチャット対応

Agentsウィンドウのマルチチャット対応

今回のアップデートで最も注目すべきは、Agentsウィンドウにおけるマルチチャット機能の正式な導入だ。これまで1つのセッション内で完結していた対話が、複数の並列セッションとして管理できるようになった。

具体的には、ローカルセッションにおいて複数のチャットを同時に立ち上げ、それぞれ異なるタスクを進行させられる。あるチャットでコードのリファクタリングを指示している間に、別のチャットで新しい機能の設計について相談する、といった使い方が可能だ。

従来のエージェント操作(Before)
開発者 リファクタリング依頼 エージェント 処理中
⚠️ セッションが一つしかないため、完了まで他の依頼ができない
1.124のマルチチャット(After)
セッション1 リファクタリング依頼 実行中
セッション2 新機能の設計相談 回答待ち
セッション3 テストコード生成 待機中

上の図のように、開発者はエージェントの応答を待つことなく次の指示を出せる。これにより、思考の分断が減り、作業スピードが格段に上がる。マルチタスクが前提の現代の開発フローに、AIがようやく追いついた形だ。

バックグラウンド送信で考える時間を確保

マルチチャットをさらに快適にするのが、バックグラウンド送信機能だ。新しいセッションを開始する際、Alt+Enter(macOSではCmd+Enter)を押すか、送信ボタンをAltキーを押しながらクリックすることで、そのセッションにすぐに移動せずに次のメッセージを入力できる。

これにより、複数の質問や指示を立て続けにエージェントへ送り、応答をバックグラウンドで処理させながら、自分は次のタスクの構想を練るという働き方が実現する。まさに「ながら作業」の効率を最大限に引き出す設計だ。

セッション管理のキーボード操作が充実

増えたセッションを素早く操作するためのショートカットも整備された。Ctrl+1からCtrl+9(macOSではCmd+1Cmd+9)で、グリッド表示されたセッションを位置で直接フォーカスできる。さらに、Ctrl+K Ctrl+W(macOSではCmd+K Cmd+W)で全セッションを一括クローズすることも可能だ。

チャット入力の履歴も、現在のセッション内にスコープが限定されるようになった。上下の矢印キーで過去のプロンプトを呼び出す際、他のセッションの履歴が混ざることがなくなり、誤操作が減る。

統合ブラウザの使い勝手が向上

統合ブラウザの使い勝手が向上

VS Codeに内蔵された統合ブラウザも、今回のリリースで実用性が高まった。ツールバーのアクションを個別に表示・非表示できるようになり、自分がよく使う機能だけを並べたミニマルなUIを構築できる。

統合ブラウザのツールバーカスタマイズ
変更前 戻る 進む 更新 URLバー 設定 他多数 固定表示
変更後 戻る URLバー 更新 必要なものだけ

コンテキストメニューから各アクションの表示を切り替えられるため、プレビュー用途ではナビゲーション系だけ、デバッグ用途では開発者ツール系だけ、といった使い分けが容易になった。

アドレスバーでのURL履歴ナビゲーション

統合ブラウザのアドレスバーでも、上下の矢印キーで過去に訪れたURLをたどれるようになった。これはデスクトップブラウザではおなじみの操作だが、VS Code内のブラウザでも同じ感覚で履歴を遡れるのは地味に大きい。ちょっとしたAPIドキュメントの巡回作業がよりスムーズになる。

エディタの細かな改良点

エディタの細かな改良点

AI機能やブラウザだけでなく、エディタの基礎的な部分にも手が入っている。シンプルファイルダイアログでは、新しくフォルダをその場で作成できるようになった。ファイルを保存する際、わざわざOSのファイラーを開かずとも、ダイアログ内でフォルダを作ってすぐに格納できる。

シンプルファイルダイアログでのフォルダ作成
📁 現在のフォルダ
📄 index.js
📄 style.css
新機能 📁 新しいフォルダを作成 ← ここで直接作れる

もう1つ、エディタのカスタマイズに関わる変更として、折りたたみマーカーのパターンに正規表現のフラグが使えるようになった。language-configuration.json{ pattern, flags }というオブジェクト形式を受け付けるようになり、大文字小文字を区別しないマッチングなどが可能になる。大規模な設定ファイルを管理する開発者には嬉しい拡張だ。

WSL環境との連携がさらに強化

WSL環境との連携がさらに強化

Windows Subsystem for Linux(WSL)を利用する開発者にとって、今回のアップデートは実用的な価値が大きい。AgentsウィンドウがWSL接続を正式にサポートしたことで、Windows上のVS CodeからLinux環境のコードベースに対して直接AIエージェントを操作できるようになった。

WSLとは、Windows上でLinuxの実行環境をネイティブに近い形で動かす仕組みだ。Web開発やデータサイエンスの分野では、Linuxネイティブのツールチェーンを使うためにWSLを利用するケースが増えている。今回の対応により、WSL内のプロジェクトに対しても、エージェントがコンテキストを理解した上でコード生成やリファクタリングを行える。

WSL連携の動作イメージ
VS Code(Windows) AIエージェント WSL環境
✅ エージェントがLinuxカーネルやツールチェーンを直接認識し、適切なコードを生成

これまでWSL上で作業する際、AI機能を使うためにWindows側へコードをコピーするといった一手間が必要だった。その手間がなくなるだけで、日々の開発効率は確実に改善される。

この記事のポイント

  • Agentsウィンドウがマルチチャットに対応し、複数のタスクを並行してエージェントに依頼できる
  • バックグラウンド送信でセッションを離れずに次の指示を入力可能。思考の連続性が保たれる
  • キーボードショートカットでセッションのフォーカス移動や一括クローズができるようになった
  • 統合ブラウザのツールバーがカスタマイズ可能になり、URL履歴の操作も改善
  • WSL環境との連携がエージェント機能にまで拡大し、クロスプラットフォーム開発がより快適に
VS Codeで始めるGitHub超入門!リポジトリ作成からAI活用まで

VS Codeで始めるGitHub超入門!リポジトリ作成からAI活用まで

VS CodeとGitを連携させれば、エディタから離れることなくGitHub上のバージョン管理が完結する。コードを書きながらコミット、ブランチの切り替え、プッシュまで行えるため、作業の中断が大幅に減る。

本記事では、フォルダの初期化から変更の追跡、ブランチのマージ、リモートへの公開、さらにMCP(Model Context Protocol)を使ったAI支援まで、実務で頻繁に使う一連の流れを手順を追って解説する。Gitの概念を簡単な言葉で補足しながら進めるので、バージョン管理が初めてでも迷わないはずだ。

VS Codeで始めるGitとGitHubの基本

VS Codeで始めるGitとGitHubの基本

GitとGitHubの役割

Gitはソースコードの変更履歴を管理するプログラムだ。GitHubはその履歴を保管するリモートの場所で、いわば「コードの倉庫」である。Gitでローカルに記録した履歴をGitHubにアップロードすることで、チームでの共有やバックアップが実現する。

VS Codeが開発効率を上げる理由

VS Code(Visual Studio Code)はMicrosoftが提供する無料のソースコードエディタだ。内部にGit機能が統合されており、GUI上でリポジトリの初期化やコミット、ブランチ操作を行える。ターミナルとエディタを行き来する手間を省き、エディタのサイドバーやコマンドパレットからほとんどのGit操作を実行できる。

リポジトリの初期化と最初のコミット

リポジトリの初期化と最初のコミット

まずはローカルのフォルダをGitリポジトリとして初期化し、ファイルを追跡してコミットする流れを確認しよう。

VS Codeを起動し、左側のアクティビティバーにあるExplorerアイコン(重なったファイルのような形)をクリックする。次に「Open Folder」ボタンから、GitHubに上げたいコードが入ったフォルダを開く。

続いて、アクティビティバーの上から3番目にあるSource Controlアイコンを選択する。すると「Initialize Repository」ボタンが表示されるので、これをクリックする。これでフォルダがGitリポジトリとして機能し始める。

初期化直後は、Source Controlパネル内のファイル名の横に「U」(Untracked)が表示される。ファイルを追跡対象にするには、ファイル名の隣のプラス記号をクリックする。全ファイルを一括でステージングしたい場合は「CHANGES」の右にあるプラスを押せばよい。ステージングされるとファイルの状態は「A」(Added)に変わる。

ステージングした変更を記録するには、Source Controlパネル上部のメッセージ入力欄にコミットメッセージを記入し、「Commit」ボタンを押す。ここでCopilotの提案機能を使えば、差分に合ったメッセージを自動生成することも可能だ。

ブランチの作成と切り替え

ブランチの作成と切り替え

コマンドパレットからのブランチ作成

デフォルトでは通常「main」ブランチが使われる。新機能の開発や修正作業は、別のブランチを切って進めるのが一般的だ。

Shift + Command + P(Mac)またはCtrl + Shift + P(Windows)でコマンドパレットを開き、「create branch」と入力する。候補から「Git: Create Branch…」を選び、任意のブランチ名(例「new-features」)を入力してEnterで確定する。すると新しいブランチが作成され、自動的にそのブランチに切り替わる。ウィンドウ左下のブランチ名表示で確認できる。

作業ブランチでの変更と確認

新しいブランチ上でコードを編集すると、後述するようにエディタの左側(ガター)に色付きのインジケータが現れる。この状態でファイルを保存し、Source Controlパネルから変更をステージングしてコミットする流れは先ほどと同じだ。

変更の追跡と差分の確認

変更の追跡と差分の確認

ガターに表示される変更インジケーター

VS Codeでファイルを編集すると、行番号の左側にあるガターと呼ばれる領域に色分けされた目印が表示される。新しく追加した行には緑色のバー、既存の行を修正した箇所には青色の模様付きバー、行を削除した場所には赤色の矢印が現れる。これによって、どの変更が未コミットなのかを瞬時に把握できる。

エディタ上の変更インジケーター(例)
1 function greet() {
2 const name = getParam();
3 alert(“Hello, ” + name);
4 console.log(“debug”);
5 }
追加行  変更行  削除行(ガターに三角で表示)

このように、エディタの左側にある「ガター」に色付きのインジケーターが表示され、どの行を追加・変更・削除したかが一目でわかる。

差分の表示(並列表示とインラインビュー)

変更内容を詳しく比較したいときは、Source Controlパネルでファイル名をクリックする。すると左右に分割された差分ビューが開き、変更前後のコードを横に並べて確認できる。分割ビューの右上にある三点リーダーから「Inline View」を選ぶと、ひとつの画面内に差分がインラインで表示される。このビュー上で直接編集を加えることも可能だ。

ブランチのマージとGitHubへの公開

ブランチのマージとGitHubへの公開

マージ手順

作業ブランチでの変更をmainブランチに取り込むには、まずmainブランチに切り替える。ウィンドウ左下のブランチ名をクリックし、表示される一覧から「main」を選択する。その後、Source Controlパネルの三点リーダーから「Branch」にカーソルを合わせ、「Merge…」をクリックする。マージ元として先ほどまで作業していたブランチを選べば、mainブランチに変更が統合される。

リポジトリのプッシュと公開

ローカルのリポジトリをGitHub上に公開するには、Source Controlパネルにある「Publish Branch」ボタンを押す。VS Codeが公開時の可視性(プライベートかパブリックか)を尋ねてくるので、目的に合わせて選択する。処理が完了すると、通知からそのままGitHub上のリポジトリを開ける。

リポジトリのクローン

リポジトリのクローン

既存のリポジトリを手元に複製して作業したい場合は、GitHubのリポジトリページで緑色の「<> Code」ボタンをクリックし、URLをコピーする。VS Codeのコマンドパレットを開き「clone」と入力して「Git: Clone」を選び、URLを貼り付ける。保存先フォルダを指定すると、クローンが開始される。完了後に「Open」を選択すれば、すぐにローカルで開発を始められる。

MCPでAIを活用する

MCPでAIを活用する

GitHub MCP拡張機能のインストール

MCP(Model Context Protocol)は、AIツールが安全に外部サービスと連携するためのプロトコルだ。VS CodeでGitHubのMCPを利用すると、Copilotチャットがリポジトリの情報を参照しながらコード生成やIssue作成を行えるようになる。

アクティビティバーのExtensionsアイコンを開き、「@mcp github」で検索する。該当するGitHub公式の拡張機能をインストールし、認証を許可すると、下部のパネルにMCPサーバーが追加される。これで準備は完了だ。

Copilotチャットとの連携

チャットウィンドウから自然言語で「フラッシュカードアプリに新機能を追加して」などと指示すると、Copilotが必要なツールを自動的に呼び出し、コードやIssueを生成する。手作業でファイルを開いて確認していた手順をAIに任せられるため、プロトタイピングの速度が格段に上がる。

この記事のポイント

  • VS Codeに統合されたGit機能を使えば、エディタだけでコミットやブランチ操作が完結する
  • リポジトリの初期化から最初のコミットまでは四つのステップで完了
  • ガターの色分けインジケーターで、追加・変更・削除を瞬時に識別できる
  • ブランチのマージやGitHubへの公開もボタンひとつで実行可能
  • MCP拡張機能を導入すると、Copilotがリポジトリの文脈を理解したAI支援を提供する
VS Code 1.123リリース、エージェント画面刷新とチャット機能の進化

VS Code 1.123リリース、エージェント画面刷新とチャット機能の進化

Visual Studio Codeのバージョン1.123が2026年5月末にリリースされた。このアップデートの中核は、AIエージェントとの対話体験を根本から再設計したことにある。エージェント画面のグリッド表示、スタンドアローン環境とのセッション受け渡し、そしてチャット機能の柔軟性向上が主な柱だ。

基盤となるElectronは42へとメジャーバージョンアップし、内部ブラウザのChromiumが148、ランタイムのNode.jsが22.xへと刷新された。これにより、VS Code全体の安定性とパフォーマンスが底上げされている。開発者はこの新バージョンにより、AIとの共同作業をより自然に、より強力に進められるようになる。

本記事では、今回のアップデートで開発現場に最もインパクトを与える4つの変更点を掘り下げ、その実務的な意味を解き明かす。

Electron 42基盤刷新がもたらす安定性とパフォーマンス

Electron 42基盤刷新がもたらす安定性とパフォーマンス

VS Code 1.123の最大の土台変更は、フレームワークの中枢であるElectronをバージョン42に引き上げたことだ。この一言で片付けるにはあまりに影響範囲が広い。Electronとは、ウェブ技術(HTML、CSS、JavaScript)でデスクトップアプリケーションを構築するためのプラットフォームである。VS CodeもこのElectronの上に成り立っている。

従来のVS Code 1.122(Before)
Electron 41 Chromium 144
レンダリングエンジンが旧バージョンのため、一部の新しいCSS機能やブラウザAPIに未対応
Node.js 20.x ランタイムで動作
VS Code 1.123(After)
Electron 42 Chromium 148
最新のブラウザAPIとCSS機能をサポート、統合ブラウザの互換性が向上
Node.js 22.x ランタイムで動作、JavaScriptエンジンが高速化

この変更は、VS Codeの内部ブラウザ機能や拡張機能の動作環境に直接影響する。

Chromium 148への移行で変わる統合ブラウザの実用性

VS Codeには簡易ウェブブラウザ機能が統合されており、フロントエンド開発者は別途ブラウザを立ち上げずにプレビューを確認できる。Chromium 148とは、Google Chromeの基盤部分のことだ。今回のアップデートでこの基盤がバージョン148へと刷新されたことで、最新のウェブ標準に準拠した表示が可能になった。

具体的には、新しいCSSプロパティやWeb APIが利用できるようになり、プレビュー表示の信頼性が向上する。また、ブラウザ関連の設定が設定エディタ内で独立したセクションにまとめられ、管理しやすくなった点も見逃せない。設定画面の見通しが良くなったことで、開発者は必要な項目に素早くアクセスできる。

Node.js 22.xによる拡張機能の実行速度向上

Node.jsとは、サーバーサイドでJavaScriptを動かす実行環境である。VS Codeの拡張機能やターミナル機能はこの上で動作している。ランタイムが20.xから22.xへと一段階飛び級でアップグレードされたことで、JavaScriptエンジン「V8」の最適化が進み、拡張機能の起動時間やターミナルでのコマンド実行が高速化される見込みだ。

さらに、BYOK(Bring Your Own Key)環境でOpenRouterやDeepSeekといった外部推論モデルを利用している場合、ツール呼び出し後にHTTP 400エラーが発生する不具合も今回のNode.js更新に伴い修正された。これにより、外部AIプロバイダーとの連携がより安定する。

エージェント画面の進化、グリッド表示とスレッド返信で管理性が向上

エージェント画面の進化、グリッド表示とスレッド返信で管理性が向上

VS CodeのAIエージェント機能は、コード編集やタスク実行を自律的に支援する存在だ。このエージェントとの対話履歴を確認する「エージェント画面」が、バージョン1.123で大幅に再設計された。最も目を引くのは、セッション一覧が従来のリスト形式からグリッド形式に変わった点である。

従来のセッション一覧(Before)
セッションA
セッションB
セッションC
縦並びのリスト形式、視認性が低く多数のセッション管理が難しい
新しいグリッド形式(After)
セッションA
セッションB
セッションC
セッションD
グリッド形式で多数のセッションを一覧、目的の会話を高速に発見できる

多数のエージェントセッションを並行して扱う開発者にとって、この変更は作業効率の大幅な改善につながる。

スレッド返信機能でフィードバックが対話的に

エージェント画面に追加されたもうひとつの重要な機能が、スレッド形式の返信だ。これまではエージェントの出力に対するフィードバックを一方向的に追加することしかできなかった。しかし今回のアップデートにより、特定のコメントに対して個別に返信できるようになった。

これは、チームでのコードレビューに近い体験をエージェントとの対話にもたらす。エージェントが生成したコードの特定の部分に対し「このロジックを修正してほしい」と指摘したり、複数の修正案を比較検討したりするコミュニケーションが、より構造化された形で可能になる。

チャットセッションを受け渡すハンドオフ機能

VS Codeの編集画面で進行中のチャットを、スタンドアローンのエージェント画面にそのまま移行できるハンドオフ機能も追加された。編集画面ではコードに集中したいが、エージェントとの対話は続けたい、という状況で役立つ。

また、エージェントホストセッション中に送信されたステアリングメッセージが、従来は実行中のターンに埋め込まれていたが、今回から独立したユーザーターンとしてチャット上に表示されるようになった。これにより、どの指示がどのタイミングで送られたのかが明確になり、対話の透明性が高まっている。

チャット機能が柔軟に、添付ファイルのみの送信やエリアスクリーンショットに対応

チャット機能が柔軟に、添付ファイルのみの送信やエリアスクリーンショットに対応

日々のコーディングで最も頻繁に使われるチャット機能にも、実用的な改善が施された。中でも画期的なのは、テキストメッセージなしで添付ファイルだけを送信できるようになった点である。

従来のチャット送信(Before)
必須のテキスト入力「この画像の内容を解析して」
添付画像 テキスト必須
VS Code 1.123のチャット送信(After)
添付ファイルのみで送信可能に
添付画像 単独で送信OK

この一見小さな変更が意味するところは大きい。エラー画面のスクリーンショットを撮ってそのまま投げ込むといったフローが、ワンアクションで完結するのだ。

統合ブラウザのエリアスクリーンショット機能

統合ブラウザ上で、ページ全体ではなく特定の領域だけを選択し、そのスクリーンショットをチャットのコンテキストとして追加できる機能も実装された。デザインの微調整をAIに依頼する場合や、特定のUI要素について質問する場合に、余計な情報を省いた的確なコミュニケーションが可能になる。

並列ターミナルコマンドの完了通知がバッチ化

エージェントモードが複数のターミナルコマンドを並列実行する際、これまではコマンドごとに個別のエージェントターンが作成され、チャット画面が完了通知で埋め尽くされる問題があった。今回のアップデートでは、これらの通知が1つのメッセージにまとめてバッチ化される。チャット画面がすっきりと整理され、本質的な対話に集中しやすくなった。

プロンプトファイルと外部環境連携の改善

プロンプトファイルと外部環境連携の改善

開発者がAIに与える指示をファイル化する「プロンプトファイル」の仕組みにも、いくつかの使い勝手の向上が図られた。

サブコマンド呼び出しの直感的な書式

プロンプトファイル内でサブコマンドを呼び出す際、従来はコロン区切りの形式(例、/chronicle:tips)が必須だった。この構文がスペース区切り(例、/chronicle tips)でも動作するようになった。この変更は表記法の微細な違いに過ぎないように見えるが、シェルコマンドや自然言語の記法に慣れ親しんだ開発者にとって、認知負荷を下げる効果がある。

外部AI推論モデルとの互換性修正

BYOK(Bring Your Own Key)モデルで、OpenRouterやDeepSeekといった推論特化型プロバイダーを利用する場合、ツール呼び出し後にHTTP 400エラーが発生する不具合があった。これはVS Codeが送信するリクエスト形式と、一部のプロバイダー側のパース処理の間に生じていた非互換が原因だ。今回の修正により、これらの外部モデルが安定して動作するようになった。

Cloudタスクの出力がローカルと同等の表現力に

GitHub CopilotのCloudタスク機能では、これまで実行結果の表示がテキスト主体で、ターミナル出力の表現力に限界があった。今回のアップデートで、CloudタスクもローカルのCopilot CLIセッションと同様に、ツールカードや編集差分、ターミナル出力をリッチにレンダリングできるようになった。リモート実行とローカル実行の間で、視覚的な体験が統一される。

細部に及ぶ品質改善と不具合修正

細部に及ぶ品質改善と不具合修正

メジャーな機能追加の裏で、開発者の日常業務にじわじわと効いてくる細かな修正も数多く含まれている。

/docコマンドのPython docstring配置修正

/doc コマンドを使ってPythonコードにドキュメント文字列を生成する際、docstringがデコレータの前に挿入されるという不具合があった。本来は関数本体の内部に配置されるべきものであり、修正により正しい位置に生成されるようになった。Python開発者にとっては、コードの可読性を保つ上で見過ごせない変更だ。

Zenモード時のインジケーター非表示

Zenモードは、余計なUI要素を排除してコードに没頭するための表示モードだ。しかしエージェントモードのインジケーターがタイトルバーに表示され続けることで、没入感が損なわれていた。今回の修正で、Zenモード時にはこれらのインジケーターが自動的に非表示になる。

Windows環境でのCLIフラグ問題を解消

Windows環境限定の問題として、--folder-uri--file-uri といったCLIフラグが特定の条件下で無視される不具合が解消された。引数の順序が最後でない場合や --wait フラグと併用した場合に発生していたこの問題は、VS Codeをスクリプトや外部ツールから起動するワークフローで特に支障をきたしていた。修正により、コマンドラインからの起動オプションが全プラットフォームで一貫して動作する。

この記事のポイント

  • VS Code 1.123の中核はエージェント画面のグリッド表示とスレッド返信だ、多数のAIセッションを並行管理する開発者の負荷が下がる
  • Electron 42への基盤刷新によりChromium 148とNode.js 22.xが導入され、統合ブラウザの互換性と拡張機能の実行速度が向上する
  • チャットに添付ファイルのみを送信できる新機能で、エラー共有や画像解析の依頼が1アクションで完結する
  • 外部AI推論モデルとの非互換やPython docstring生成位置の不具合など、現場の開発者が直面していた細かな問題が着実に修正されている
  • プロンプトファイルのサブコマンド記法が簡略化され、AIへの指示をより直感的に記述できるようになった
VS Code 1.121が公開、AIエージェントのターミナル連携とモデル管理が進化

VS Code 1.121が公開、AIエージェントのターミナル連携とモデル管理が進化

マイクロソフトは2026年5月20日、コードエディタ「Visual Studio Code」のバージョン1.121を公開した。今回のリリースでは、Copilot Chatが備えるエージェント機能とターミナルとの連携部分に多くの改良が加えられている。

具体的には、ツール呼び出しの表示が見やすくなり、特定のLLMモデルをピン留めして素早く選択できる仕組みが追加された。加えて、長いテストやビルドの出力を自動で圧縮する範囲が大幅に拡大され、エージェントが生成するコマンドの実行効率と可読性が一段と向上している。

開発者のワークフローに与える影響は小さくない。ターミナルに流れるログ情報が整理され、エージェントが勝手にバックグラウンド処理に移行するタイミングが賢くなったおかげで、より思考の流れを途切らせずに済むのだ。本記事ではこれらの改善点を実務的な視点で掘り下げていく。

エージェントホストの操作性向上

エージェントホストの操作性向上

まず目を引くのが、エージェントホスト内でのツール表示まわりの改善だ。Copilot Chatのエージェントモードでは、AIが「ファイルを読む」「ターミナルでコマンドを打つ」などのツールを自律的に呼び出す。今回のアップデートで、それらのツール名がより直感的な表示になった。

これまでは内部的で分かりにくかった呼称が、人間にとって理解しやすい「ファイル読み取り」「コマンド実行」といったラベルに置き換わっている。入力と出力のUIも再設計され、どのツールに何を渡し、何が返ってきたかが一目で追えるようになった。エージェントの行動をレビューしたり、デバッグしたりする局面で役立つ変更だ。

自動承認ピッカーとワークスペースの事前選択

もうひとつ、エージェントホスト接続時の「自動承認ピッカー」が追加された。外部のエージェントホストへ接続する際に、あらかじめ信頼できるものを選んでおける仕組みで、毎回承認操作を求められる煩わしさが減る。

また、VS Codeを既に特定のワークスペースで起動している場合、エージェントウィンドウを開くとそのワークスペースのフォルダが自動で事前選択される。手動でプロジェクトフォルダを指定し直す手間が不要になるため、作業開始時のリズムが良くなる。小さな改良だが、1日に何度も繰り返す操作だけに、開発効率への積み重ね効果は意外と大きい。

Before
ツール表示:run_in_terminal (何をするツールか直感的に分からない)
エージェント起動時:フォルダ未選択の状態 (手動で毎回選ぶ必要がある)
After
ツール表示:コマンド実行(ターミナル) (ツールの役割がラベルからすぐ分かる)
エージェント起動時:現在のワークスペースが自動選択 (操作を1ステップ省略できる)
変更前   変更後

上の図は、ツール表示とワークスペース選択の流れをビフォーアフターで示したものだ。変更前は開発者がエージェントの内部的な動きを読み解く必要があったが、変更後は視覚的に整理され、作業開始時の手数も減っている。

モデル管理の進化と「お気に入り」機能

モデル管理の進化と「お気に入り」機能

続いて、言語モデルピッカーに「ピン留め」機能が追加された。これは、よく使うモデルをお気に入り登録して、ドロップダウンリストの上部に固定する機能だ。

現在、VS CodeのCopilot Chatでは複数のAIモデルを切り替えて使える。コーディング向きのモデル、自然言語のやり取りに向いたモデル、軽量で反応が速いモデルなど、タスクに応じて選び分ける開発者も多い。ピン留め機能により、毎回リストをスクロールして探すストレスから解放される。

環境変数「VSCODE_AGENT」の追加とその効果

Copilot Chatがターミナルでコマンドを実行する際、専用の環境変数「VSCODE_AGENT」がセットされるようになった。この変数は、AIが起動したターミナルセッションであることを明示的に示すためのものだ。

実務では、シェルのプロンプト表示を変えたり、エージェント向けのログフォーマットを自動判別したりする用途に使える。たとえば、AI用のターミナルでは冗長なカラー表示をオフにして、パースしやすいテキスト出力に切り替える、といった使い方が考えられる。自分でシェル初期化ファイルをカスタマイズしている開発者にとっては、自動化の可能性が広がる嬉しい追加だ。

チャットと統合ブラウザの連携強化

チャットと統合ブラウザの連携強化

統合ブラウザ(Simple Browser)で表示中のWebページを、ワンクリックでCopilot Chatに共有できる「Add to Chat」オプションが右クリックメニューに追加された。

VS Codeの統合ブラウザは、エディタ内でドキュメントやAPIリファレンスを閲覧するのに使われる。今回の機能で、例えばReactの公式ドキュメントを開きながら「このセクションの内容を要約して」とAIに投げる操作が、ドラッグやコピーペーストなしで完結する。Web上の情報をコーディングの文脈にスムーズに取り込めるのは、エディタを離れずに作業を続けたい開発者にとって大きな利点だ。

また、チャットエージェントが内部的に生成したバックグラウンドターミナルは、コマンド完了後に自動で破棄されるようになった。これにより、使われないプロセスが蓄積してシステムリソースを圧迫するのを防げる。エージェントがテストの実行や依存関係のインストールなどを一括操作した後、きれいに後片付けされるイメージだ。

統合ブラウザ活用フロー
📄 ドキュメント閲覧 🖱️ 右クリックでAdd to Chat 💬 Copilot Chatに内容共有 📝 エディタでコード生成
バックグラウンドターミナルのライフサイクル
エージェントがコマンド実行 バックグラウンドターミナル生成 コマンド完了後に自動破棄 (不要なプロセスが残らない)

これらの改善は、AIアシスタントを「裏方」として使う際の体験を底上げする。情報収集からコード生成、実行、後始末まで、一連の流れに無駄がなくなっていく方向性だ。

ターミナルツールの出力処理が大幅に改善

ターミナルツールの出力処理が大幅に改善

今回のリリースで最も実務的なインパクトが大きいかもしれないのが、ターミナルツールの出力圧縮まわりの拡張だ。

エージェントがテストランナーやビルドツールを実行すると、膨大なログが出力され、チャット画面が埋め尽くされることがある。この問題に対応するため、出力圧縮(冗長な行を折りたたみ、重要な結果だけを強調表示する仕組み)の対象が一気に広がった。

圧縮対象が大幅に拡大されたコマンド群

新たに対象となったのは、以下のツール群だ。

  • テストランナー: pytestjestcargo test
  • ビルドツール: tsc(TypeScriptコンパイラ)、cargo buildmake
  • リンター類
  • Docker関連コマンド
  • パッケージマネージャ(npm、yarn、pipなど)

これらのツールが出力する長大なログから、本当に必要なエラー行やサマリーだけを抽出し、チャット画面上ではコンパクトに表示してくれる。テストが数千件走っても、失敗したケースだけに集中できるわけだ。

アイドルサイレンスタイマーで同期実行を自動バックグラウンド化

ターミナルツールには、同期コマンドが一定時間まったく出力を返さない場合に、自動的にバックグラウンド実行に切り替える「アイドルサイレンスタイマー」が導入された。設定した時間内に何の進捗も表示されなければ、AIエージェントはそのコマンドをバックグラウンドに回し、別のタスクに取り掛かれる。

従来は、長時間かかる処理が走っている間、エージェントの思考がブロックされがちだった。この機能は、CI/CDパイプラインや重いデータベースマイグレーションの待ち時間中に、エージェントが他の作業を並行して進められるようにするものだ。

従来の同期実行
$ pytest –long-suite
(数千行のログが流れる)
エージェントは完了まで他の操作ができない
1.121での改善
$ pytest –long-suite
出力が折りたたまれ、エラー行のみ表示
一定時間出力なし → 自動でバックグラウンド化
ブロックされていた時間   他の作業を並行実行できる

アイドルサイレンスタイマーは設定可能なため、プロジェクトの特性に合わせて閾値を調整できる。テストが沈黙するのはバグではなく重い処理の前触れ、というチームなら長めに取ればいい。

マルチラインコマンドの修正とConPTYの最新化

エージェントホストのターミナルツールでは、複数行にまたがるシェルコマンドの実行時に問題が発生することがあったが、今回のアップデートで修正された。bashやPowerShellでループや条件分岐を含むスクリプトを生成させるケースで、従来は行の継続が正しく解釈されないバグに遭遇することがあった。この修正によって、AIが生成した複数行スクリプトの信頼性が高まっている。

さらに、Windows環境向けに、擬似ターミナルAPIの基盤となるConPTY(conpty.dll)の新しいバージョンがVS Code本体に直接バンドルされるようになった。これまではシステム側のバージョンに依存しており、古いWindowsではターミナルの描画に問題が出ることがあった。バンドル化により、VS Code側で一貫したターミナル挙動を保証できるようになった。

SSH接続におけるキーボード対話認証のサポート

SSH接続におけるキーボード対話認証のサポート

最後に、エージェントホストがSSH接続する際に、キーボードインタラクティブ認証(パスワード入力やワンタイムパスコードの要求を含む対話形式の認証)がサポートされた。多要素認証が求められるサーバーや、接続時に追加の質問が表示される環境でも、エージェントホスト経由の自動接続が可能になったわけだ。

セキュリティ要件が厳しい本番環境や、企業ポリシーで対話認証を強制されているサーバーに対して、Copilot Chatのエージェントを遠隔操作するハードルが下がる。VS Code Remote Developmentの既存ユーザーにとっては、よりシームレスにAI支援を組み込めるようになる変更だ。

エージェントホストのSSH認証フロー
🔑 SSH接続試行 🔐 キーボード対話認証(OTP・質問応答) ✅ 接続確立
※従来はキーボード対話認証が未対応で、多要素認証が必要なサーバーではエージェントの遠隔接続に支障があった
認証試行   接続成功

この機能は、特にDevSecOpsの文脈で歓迎されそうだ。開発環境と本番環境を明確に分離しつつ、AIアシスタントの支援を安全に受けられる選択肢が増えたことを意味する。

この記事のポイント

  • VS Code 1.121ではAIエージェントのツール表示が見直され、入力と出力の可読性が向上した
  • モデルピッカーにお気に入りのピン留め機能が追加され、切り替え操作が高速化した
  • ターミナル出力の圧縮対象が拡大され、テストやビルドのログがコンパクトに表示される
  • アイドルサイレンスタイマーにより、長時間コマンドの自動バックグラウンド化が可能になった
  • SSHのキーボード対話認証サポートで、よりセキュアな環境へのエージェント接続が容易になった