VS Code 1.133がAI開発体験にもたらした3つの変化

Visual Studio Code 1.133は2026-08-12に公開されたリリースで、AIエージェントやチャット体験まわりの改善が中心にまとまっています。ClaudeやGitHub Copilotなど複数のAIコーディングツールを併用している開発リーダーにとって、今回の更新は単なる機能追加にとどまらず、AIと人間が交互にコードやHTMLを編集していくワークフローそのものを見直す契機になります。

本記事で取り上げる変化は大きく3つあります。1つ目は長いチャットセッションでも指示を見失わないための固定スクロール、2つ目は内蔵ブラウザでローカルHTMLファイルを自動リロードする仕組み、3つ目はClaudeとCopilotをターン単位で混在利用できるようになったプロバイダ切り替えです。いずれもエージェント駆動開発を快適にする文脈で設計されており、相互に噛み合ってAI時代の開発ループを短縮する狙いが読み取れます。設定IDはそれぞれchat.stickyScroll.enabledとworkbench.browser.autoReloadOnFileChangeで、プロバイダ混在の土台にはエージェントの実行基盤をエディタ本体から切り離すアーキテクチャ変更が入っています。

固定スクロールとローカルHTML自動リロードの技術的背景と使い所

まず固定スクロールについて整理します。VS Codeのエディタ本体には、コードをスクロールしても現在のスコープにあたる関数やクラスの見出しを画面上部に固定表示する機能が以前から存在していました。1.133はこのUXパターンをチャットビューに転用したものです。エージェントとの対話は1セッションが長大化しやすく、応答をスクロールで追ううちに、いま読んでいる出力がどの指示に対応するのかを見失いがちでした。chat.stickyScroll.enabledを有効にすると、通り過ぎたユーザープロンプトがチャット欄の上部にピン留めされ続け、クリックすると当該プロンプトの位置へジャンプできます。隣接するプロンプトへ前後に移動するナビゲーションも備わり、指示単位での確認やり直しが格段にやりやすくなります。

使い所として想定されるのは、リファクタリングや段階的な仕様追加のように、AIエージェントへ複数の指示を連続して出す長時間セッションです。指示の文脈が常時可視化され、どのプロンプトの結果を今レビューしているのかを素早く辿れます。なお、プロンプトが全体の何番目かを示す番号表示の有無といった細部は公式の記述からは断定できないため、プロンプト間を移動できるナビゲーション機能として捉えるのが安全です。

ローカルHTML自動リロードが縮める確認ループ

次にローカルHTMLファイルの自動リロードです。VS Codeの内蔵ブラウザでローカルのHTMLファイルを開いている際、そのファイルがディスク上で変更されると自動でリロードし、編集結果を即座に表示します。リロードのオンオフはブラウザタブごとにトグルできます。従来この種の体験はLive Preview拡張やライブサーバ系のツールで実現するのが一般的でした。1.133は自動更新を内蔵ブラウザに統合し、外部拡張への依存を減らしています。

この機能が効くのは、AIエージェントに静的なHTMLやCSSを編集させ、その変更をリアルタイムでプレビュー確認するワークフローです。workbench.browser.autoReloadOnFileChangeを有効にしておけば、エージェントがHTMLを書き換えるたびに手動でリロードする手間が消え、書き換えと目視確認のループが短くなります。ただし、これは状態を保持するホットリロードではなくフルリロードであると考えられ、対象もローカルHTMLファイルが前提です。サーバ経由の動的ページまで同じ体験が保証されるわけではない点は、過度に一般化せず押さえておきましょう。

ClaudeとCopilotをターン単位で混在させる仕組みと課金の考え方

3つ目の変化が、ClaudeとCopilotの混在利用です。1.133ではモデルピッカーにAnthropicのグループとCopilotのグループの両方が表示され、会話のターンごとにプロバイダを切り替えられるようになりました。従来は1つのClaudeセッションがCopilotサブスクリプション経由か既存のAPIキー設定経由かのどちらか一方で動作し、切り替えには実行基盤の再設定が必要でした。ターン単位での切り替えは、この手間を大きく削減します。

課金の考え方はプロバイダごとに分かれます。AnthropicグループのモデルはAPIキーに対して従量で課金され、CopilotグループのモデルはCopilotサブスクリプションを利用します。つまり同じ会話の中で、コストの発生源を意識的に振り分けられます。どのモデルがどちらのグループに現れるかや切り替え粒度の細部は出典によって表現に差があるため、具体的なモデル名や価格を断定するのは避けます。

プロバイダ混在を支えるAgent Host分離

この柔軟な切り替えの土台になっているのが、Agent Host分離と呼ばれるアーキテクチャ変更です。1.133ではエージェントの実行基盤であるAgent Hostを独立したプロセスに切り出し、Agent Host Protocolに基づいてエージェントハーネスをエディタから分離しました。CopilotのエージェントはCopilot SDKを用います。この分離によって複数プロバイダのハーネスを共通の枠組みで扱えるようになり、プロバイダをまたいだ切り替えが現実的になりました。

関連して、実験的な設定chat.agentHost.allowSignedOutWhenUsableも追加されました。これを有効にすると、GitHubにサインインしていなくてもAgentsウィンドウを開けます。現状は既存のAPIキー設定があるClaudeのみが対象で、CopilotやCodexは将来の対応が見込まれています。github.comへ到達しにくい環境や、GitHubアカウントを前提にしたくない利用者にとって、可用性を確保する経路になります。

複数AIアシスタント併用の実務メリットと注意点

ここからは、1.133が提供するプロバイダ混在や実行基盤の分離を前提に、複数のAIコーディングアシスタントを併用する実務観点を整理します。個別のベンチマークや価格には踏み込まず、現場で効く判断軸に絞ります。

併用がもたらすメリット

第一のメリットはタスクの適材適所です。推論の重い設計やリファクタは高性能なモデルに任せ、定型的な補完は軽量なモデルへ回すといった振り分けを、ターン単位で行えます。第二にコスト分散が挙げられます。従量課金のAPIキーと定額のサブスクリプションを併用すれば、用途に応じてコスト配分を最適化できます。第三が可用性と冗長性です。一方のプロバイダが不調や制限中でも、もう一方へ切り替えて作業を継続できます。GitHub未サインインでもClaudeを使える実験的な経路は、アクセス制約のある環境の可用性を高めます。

見落としやすい注意点

一方で注意すべき点も少なくありません。まず拡張機能の共存です。Claude系の拡張とGitHub Copilotの拡張を同時に導入すると、インライン補完やチャットUIの機能が重複しがちなので、どちらを主役にするかを決め、他方は該当機能を無効化しておくと実務が安定します。次にキーバインドの衝突があります。チャット起動、補完の受諾、エージェント実行のショートカットは競合しやすいため、Keyboard Shortcutsでエージェントごとに整理する前提が欠かせません。

コンテキストと機密の分離も重要です。ターンごとにプロバイダが変わると、同一会話の文脈が異なるプロバイダへ渡るため、どのモデルにどのファイルやシークレットを渡すのかを意識し、機密情報の取り扱いポリシーを明確にしておく必要があります。課金の可視性も見過ごせません。ターン切り替えで意図せず従量課金側を多用しないよう、既定モデルや上限の運用ルールを定めます。レビュー観点では、モデルをまたぐと出力のスタイルや前提が変わりうるため、AI生成差分は人間のレビューを必須とし、どのモデルが生成したかを追える運用が望まれます。最後に、実行基盤のプロセス分離は挙動を変えうるので、既存の拡張や自動化との互換性を早い段階で検証しておくと安全です。

開発ワークフローへの取り込み方とチーム展開の観点

まず個人の導入ステップです。はじめにVS Codeを1.133以降へ更新します。続いてchat.stickyScroll.enabledを有効化し、長いセッションで指示の追跡を改善します。さらに内蔵ブラウザでローカルHTMLを開き、workbench.browser.autoReloadOnFileChangeをタブ単位で有効化して、フロント編集から即プレビューまでのループを確立します。そのうえでモデルピッカーで両グループを確認し、タスクに応じたターン切り替えの運用ルールを決めます。GitHub未サインイン環境でClaudeを使いたい場合に限り、実験的設定chat.agentHost.allowSignedOutWhenUsableを評価します。

チーム展開で押さえる5つの観点

チームへ広げる際は、まず設定の標準化が起点になります。上記の設定IDをワークスペースやリポジトリ単位のsettings.jsonで共有し、メンバー間で体験を揃えます。実験的な設定はオプトインにとどめるのが無難です。次に課金ガバナンスとして、APIキーの従量とサブスクリプションの定額をどう使い分けるかの基準と上限を明文化し、誰のキーで課金されるのかを曖昧にしないことが重要です。

セキュリティとコンプライアンスの観点では、どのプロバイダにコードや機密が送られるのか、混在利用時のデータフローをレビューします。ゼロデータ保持や送信禁止データのポリシーがあれば、それらと整合させて整備しておきます。レビュー文化の面では、AI生成差分のレビュー必須化に加え、モデル併用による出力のばらつきを前提としたチェックリストを用意すると効果的です。そして段階展開です。アーキテクチャ変更を含むため、まずはパイロットチームで互換性と安定性を確認し、その知見をもとに全社へ広げるのが堅実です。VS Code 1.133の価値は、こうした運用設計と組み合わせて初めて開発ワークフロー全体の生産性へ結実します。