VSCode 1.118リリース日と6つの主要アップデートの全体像

VSCode 1.118リリース日と6つの主要アップデートの全体像

VSCode 1.118は、Copilotエージェント機能の大幅な拡張とトークン効率化施策を中心に据えた重要なリリースです。Microsoftが採用する週次リリースサイクルの中で、本バージョンは2026年4月29日に正式公開されました。本章ではリリース日の背景、主要ハイライト6項目の整理、Stable版とInsiders版の差分、各OS向けダウンロード経路、そして月次から週次への移行が運用面に及ぼす変化までを段階的に整理していきます。

2026年4月29日リリースと週次リリースサイクル定着の経緯

VSCode 1.118は2026年4月29日に正式リリースされ、翌4月30日には軽微な不具合を修正したバージョン1.118.1が配信されました。Microsoftは2026年に入ってから月次から週次へのリリースサイクルへ切り替えを進めており、本バージョンはその新運用が定着しつつあるタイミングで公開されています。週次リリースに移行した背景には、Copilotエージェント関連の機能改善を市場へ素早く届けたいという開発側の意図があり、毎週のように小幅な改善が積み重なる形へ変わりました。

利用者から見ると、リリース内容を逐次キャッチアップする負荷は増えるものの、機能がまとまって投入されるまで待つ必要がなくなり、必要な改善を速やかに享受できる利点が生まれています。なお1.118.1ではGitHub Copilot CLIがVS Codeから動作しないという既知不具合が修正されており、本バージョン適用時は1.118.1を選ぶ方針が無難でしょう。週次サイクルは2026年3月以降に本格化しており、現在では主要機能の段階的ロールアウトが標準的な運用となっています。

主要ハイライト6項目の概要と現場開発者への実務的なインパクト

VSCode 1.118の公式リリースノートには、開発者にとって重要な変更を6つのハイライトとして整理しています。これらは従来までの単なる機能追加にとどまらず、Copilotエージェントを軸とした開発体験の再設計を反映している点が特徴的です。

• リモート制御:GitHub.comやモバイルからCopilot CLIセッションを遠隔操作可能
• コードベース検索:全ワークスペースでセマンティック検索とリポ横断のテキスト検索が利用可能
• スキル専用context:サブエージェント文脈での隔離実行による回答品質の維持
• チャットセッション分析:履歴をstandupレポートやヒントへ自動変換
• 企業向け統制:承認済みGitHub組織にAI機能利用を制限する設定
• トークン効率化:1リクエストあたりの利用トークン量を削減

これら6項目は、Copilotが2026年6月1日から従量課金へ切り替わるという直前の課金変更とも密接に関係しており、現場開発者にとってはコスト管理と生産性確保の双方に直結する内容です。とりわけリモート制御とトークン効率化は、6月の課金変更を見据えた実務対応の中核となるでしょう。

Stable版とInsiders版の機能差分とAgentsアプリの位置づけ

VSCode 1.118ではStable版とInsiders版で利用可能な機能に明確な違いがあります。特にVS Code Agentsアプリは現時点でプレビュー段階に位置し、Insiders版でのみ提供されている点に注意が必要です。Insiders版を利用しない限り、AgentsアプリやAgents Web Clientといった本リリースで強調された新機能の一部は体験できません。

このように、本バージョンの先進機能を試したい場合はInsiders版の併用導入が前提となります。Stable版は従来通り業務利用が想定された安定版であり、エージェント関連の最新機能を一足先に体験したい場合に限ってInsiders版を選ぶ判断が現実的でしょう。

各OS向けダウンロード経路と1.118.1ホットフィックスの内容

VSCode 1.118はWindows、macOS、Linuxの主要3プラットフォーム向けに提供されており、各OS向けにアーキテクチャ別のインストーラが用意されています。Microsoftの公式ダウンロードページから入手可能で、現在配信されている実体は1.118.1という修正版です。Windows向けにはx64とArm64の2系統、macOS向けにはUniversal、Intel、Apple Siliconの3系統、Linux向けにはdeb、rpm、tarball、Arm、snapといった複数形式が揃っています。

1.118.1で修正された内容はGitHub Copilot CLIがVS Codeから起動できないという特定不具合への対処であり、CLIを業務利用しているチームにとって重要な修正でしょう。新規にインストールする場合も、既存環境を更新する場合も、自動的に1.118.1が適用されるため、利用者側で意識的にバージョンを選ぶ必要はありません。ただしオフライン環境でインストーラを事前準備する場合は、配布物が1.118.1相当であるかをファイル名で確認しておくと安全です。

月次から週次への移行が利用者の更新運用に及ぼす3つの主要変化

Microsoftが2026年から進めている週次リリースサイクル移行は、VS Codeの運用面に複数の変化をもたらしています。本リリースを境に、企業導入を行うチームは更新運用を再設計する必要が出始めました。具体的には次の3点が代表的な変化として挙げられます。

1. 更新検証サイクルの短縮:従来の月次検証では追いつかず、週次で互換性確認を行うか自動更新を許容するかの選択が迫られます
2. 機能投入タイミングの分散:大型機能が一度にまとまらず、週次で少しずつ反映されるため、社内告知や教育の進め方の見直しが必要となります
3. 不具合修正の即時反映:1.118.1のような修正版が短期で出るため、ホットフィックスの取り込み方針を明文化することが重要です

これら3点を踏まえると、特に大規模組織においては自動更新を許容する範囲と、管理者がコントロールする範囲をポリシーで線引きする運用が現実的でしょう。情報システム部門が主導してアップデート方針を文書化し、開発チームと共有する流れが定着しつつあります。

Copilotエージェント機能の刷新と開発ワークフロー全体への波及

本リリースの中核的なテーマは、Copilotエージェント機能を中心とした開発体験の再設計です。Visual Studio Code Agentsという独立アプリの拡張、複数エージェントの並行利用、Web経由でのアクセスといった機能が加わり、単一エディタ内で完結していた従来のワークフローは大きく姿を変えています。本章では各機能の概要と実務での活用観点を整理します。

Visual Studio Code AgentsアプリのInsiders限定提供条件

Visual Studio Code AgentsアプリはVS Code Insidersと並行してインストールされる独立コンパニオンアプリで、エージェント主導の開発に特化した実行環境を提供します。本アプリは1.115で初めて導入され、1.118ではさらに利用者からのフィードバックを反映した改良が加わりました。重要な前提として、Agentsアプリは現時点でプレビュー段階にあり、VS Code Insidersをインストールしないと利用できません。

Stable版を業務で使い続けながらAgentsアプリを試したい場合は、Insiders版を別途インストールして共存させる構成が選ばれます。Insiders版は安定版とは独立した実行環境として提供されるため、既存のStable版の設定や拡張機能に影響を与えずに最新機能だけを検証できる利点があります。なおAgentsアプリの公式ドキュメントも合わせて公開されているため、初めて触れる開発者でも基本的な使い方を順を追って学習できる環境が整いました。プレビュー期間中は不具合や挙動変更が発生する可能性があるため、本番業務での全面採用は避け、検証用途での利用が無難でしょう。

タイトルバーからAgentsアプリへ遷移する新導線の操作方法

1.118ではVS Code Insidersのタイトルバーから直接Agentsアプリへ遷移する新しい導線が追加されました。従来はAgentsアプリを開くためにメニュー操作や別途のショートカットが必要でしたが、本リリースではタイトルバー上のOpen in Agentsを選ぶだけでエージェント中心の作業環境にすぐ移行できるよう改善されています。同様にAgents側からも、タイトルバー上のOpen in VS CodeでInsidersエディタへ戻る逆方向の遷移が用意されており、双方向のシームレスな切替が実現しました。

この導線の整備により、コーディング中にエージェントを使った並行タスクを走らせる際の心理的なハードルが下がり、ちょっと別のタスクをエージェントに任せるという運用が日常化しやすくなります。タイトルバーのアイコンは状況に応じて動的に変化し、利用中のアプリを示すため、視覚的にも切替が明確でしょう。実務上は、調査系の長時間タスクをAgents側に任せ、即時編集はVS Code側で行うといった分担運用が現実的な選択肢となります。

Claude AgentやCopilot Cloud等の複数エージェント並行利用例

AgentsアプリではCopilot CLIやCopilot Cloudと並んでClaude Agentが利用可能となりました。これにより、用途に応じて異なる特性のエージェントを使い分ける運用が可能となります。例えば、コードリファクタリングなど推論能力が要求されるタスクはClaudeに、CI/CDの自動化など定型作業はCopilot CLIに、というように複数エージェントを並行で動かす設計が現実的になりました。

Agentsアプリは複数のセッションを並行管理できる構造になっているため、リポジトリ間をまたいだマルチタスクが従来よりも容易です。複数のエージェントを併用する場合、それぞれの認証情報やAPI呼び出しコストを意識しながら使い分ける必要がありますが、生産性を最大化するうえでは強力な選択肢となるでしょう。なおAgentsアプリではVS Code Insidersとの間で認証状態やワークスペース信頼設定が共有されるため、エージェントごとの再ログインといった煩雑な手間が発生しにくい設計となっています。実務では、専門性の高い作業を異なるエージェントに振り分けるワークフローを、チーム内で標準化していく動きが広がりつつあります。

Web版Agentsへのブラウザアクセスとtunnel経由接続の手順

1.118ではAgentsアプリのWebクライアントが用意され、ブラウザからinsiders.vscode.dev/agentsへアクセスする運用が可能になりました。Webクライアントを使うには、まずVS Code Insidersをインストールしたマシン上でDev Tunnelを起動しておく必要があります。具体的にはターミナルでcode-insiders tunnelを実行することでトンネルが開設され、ブラウザ側からそのトンネル経由で接続できる状態が整います。

この仕組みにより、VS Code本体がインストールされていない端末からでもAgents機能を利用できるため、リモートワーク中に手元の端末で軽量にチェックを行うといった使い方が可能となります。たとえば外出先でiPadや別のPCを使っているときに、自宅やオフィスのマシンで動いているエージェントセッションへ接続して進捗を確認する運用が現実的な選択肢です。Webクライアントは同じセッション状態をデスクトップ版と共有するため、どこからアクセスしても作業の連続性が損なわれない点が大きな利点でしょう。なおDev Tunnelの設定はGitHub認証を経て行うため、初回接続時には認証手順を踏む必要があります。

認証や信頼設定をVS Codeと共有するAgents共通状態の範囲

AgentsアプリはVS Code Insidersとの間で複数の状態情報を共有する設計になっており、両方のアプリ間を行き来する際の摩擦を減らす仕組みが整備されています。共有される状態には、Windows環境での認証情報、AIカスタマイズ設定、ワークスペース信頼の判断結果、最近開いたフォルダの履歴、キーボードショートカット設定などが含まれます。これにより、Agentsアプリで作業を始めたあとにVS Code Insidersへ戻ったとき、同じプロジェクトを再選択したり認証をやり直したりする手間が発生しません。

特にチーム単位で複数リポジトリを扱う開発スタイルでは、最近開いたフォルダの共有によって素早く目的のプロジェクトへ戻れる利点が大きく、日常的な切替負荷を顕著に下げてくれるでしょう。一方でAgents固有の設定はVS Code側に影響を与えない設計となっているため、Agents用に試行錯誤した設定変更が本体の安定運用へ波及する心配はありません。共有範囲は今後のリリースでさらに拡大していく可能性があり、両アプリ間の境界はますます意識せずに済む方向へ進化しています。

差分表示レイアウト切替機能とバックグラウンドブラウザ常駐の実装

エージェントが行ったコード変更を確認する場面では、差分の見せ方を柔軟に切り替えられるかどうかが作業効率に直結します。1.118ではAgentsアプリの差分表示にレイアウト切替機能が加わり、Chatビューと並べて表示するか、モーダルウィンドウで全画面に開くかを選べる設計に変わりました。差分ビューのツールバーに用意されたレイアウトコントロールから即座に表示モードを変更できるため、確認の粒度に応じた最適な表示が選択できます。

さらに統合ブラウザがバックグラウンドで状態を維持するように改良された点も実務的な利点です。従来はセッションを離れて戻ると統合ブラウザが再読み込みされていたため、プレビュー作業中に意図しないリロードが発生していましたが、1.118ではセッション間でブラウザ状態が保持されるようになりました。これにより、エージェントがコードを更新しているあいだにブラウザでプレビューを開いておき、戻ってきても変更前後の見た目をそのまま比較できる運用が現実的です。Webアプリ開発のように頻繁にプレビュー確認を行うシーンでは、この改善が体感の作業速度を大きく向上させてくれます。

Copilot CLIリモート制御機能の実務活用条件と注意点

Copilot CLIリモート制御は、本リリースで実験的に提供された目玉機能のひとつです。これまで、Copilot CLIセッションを開始したマシンを離れると進行が止まってしまう課題がありましたが、本機能によって場所に縛られない開発スタイルが可能になりつつあります。本章では設定方法から運用判断まで段階的に整理します。

Copilot CLIリモート制御の有効化に必要な設定とコマンド入力

Copilot CLIリモート制御を利用するには、まず該当機能を有効化する設定変更が必要となります。具体的にはgithub.copilot.chat.cli.remote.enabledという設定をtrueに切り替えることで機能が利用可能となります。設定を変更したのち、Copilot CLIチャット内で/remote onと入力するとリモート制御が開始され、/remote offで停止する仕様です。さらに/remoteのみを入力すると、現在のリモート制御状態を確認できます。

これらのコマンドはセッション単位で適用されるため、複数のCLIセッションを並行している場合は、それぞれのセッションで個別に有効化する必要があります。設定変更はワークスペース単位やユーザー単位で管理できるため、特定プロジェクトでのみリモート制御を許可するといった運用も現実的です。実験的機能であるため、本番環境への一律適用はリスクを伴いますが、まずは検証ワークスペースで挙動を確認したうえで段階的に展開する手順が安全でしょう。設定の有無は通常のVS Codeの設定UIから検索することで確認できます。

GitHub.comとGitHubモバイルアプリからの遠隔操作の実例

リモート制御を有効化したCopilot CLIセッションは、GitHub.comのWebインターフェースまたはGitHubモバイルアプリから操作できます。具体的には、自宅のPCでCLIセッションを起動した状態で外出した場合、外出先からスマートフォン上のGitHubモバイルアプリへログインし、進行中セッションの状態を確認したり、エージェントが提示した承認待ちプロンプトに対して応答したりすることが可能となります。これにより、長時間動作するタスクをCopilot CLIに任せたまま物理的にマシンから離れる運用が現実味を帯びました。

たとえば、リファクタリング中のテスト実行で承認が必要になった場面でも、移動中の電車内でモバイルアプリから進めてよいと判断するだけで作業が止まらず継続します。Webインターフェース側ではより詳細なログや変更内容の確認が可能で、デスクトップに戻る前に状況を把握しておけるため、戻ってからの判断時間を短縮できるでしょう。実務シーンでは、夜間に長時間タスクを走らせ、翌朝モバイルから状況確認するといった運用が定着しつつあります。

離席中の承認待ちセッションを継続できることによる作業停滞解消の効果

従来のCopilot CLIでは、エージェントが何らかの判断を必要とする場面で人間の応答待ちとなり、その時点で作業が停止していました。たとえば、テストの再実行を行うか確認するプロンプトや、ファイル削除の許可を求めるプロンプトが出ると、開発者がマシンの前にいない限り作業は前に進みません。リモート制御の導入により、こうした承認待ちで停滞する時間が大幅に削減されます。

離席中であっても、エージェントが提示した質問へモバイルから即座に応答できれば、本来であれば数時間止まっていた作業が中断なく完了するケースが増えるでしょう。これは特に、CIの完了待ちやコードベース全体の検査といった長時間タスクで顕著な効果を発揮します。実務的には、夜間や週末など物理的にデスクから離れる時間帯にエージェントへ重い処理を任せ、必要な判断だけリモートで行うという働き方が現実味を帯びてきました。停滞時間の削減は単なる作業効率の改善にとどまらず、エージェント主導の開発における稼働率を向上させる重要な要素となります。

/remote on と/remote offによるリモート制御の切替操作

リモート制御の有効・無効を切り替える操作はCopilot CLIチャット内で完結します。チャット入力欄に/remote onと入力すると当該セッションでリモート制御が有効化され、外部端末からの監視と操作が許可されます。逆に/remote offを入力するとリモート制御は停止し、それ以降は元のローカル操作のみに戻る挙動です。

切替操作は即座に反映されるため、必要なときだけ有効化するという使い方も可能となります。たとえば長時間のビルドタスクを開始する直前に有効化しておき、ビルド完了後に停止する運用が現実的でしょう。状態確認は/remoteのみを入力することで行え、現在のセッションが外部端末から制御できる状態かどうかを把握できます。これらのコマンドは記憶しておくべきものが少ないため、コマンドラインに慣れた開発者であれば運用負荷はほぼ発生しません。なお切替操作のログはセッション内に残るため、いつ有効化・無効化したかをあとから振り返ることも容易です。

セッションタイトル同期によるチャットUI間の表示一貫性の確保策

Copilot CLIセッションのタイトルは、チャットセッション一覧、チャットエディタタブ、エディタヘッダー、Copilot CLIターミナル画面など、複数のUI上で表示されます。1.118より前のバージョンでは、これらの表示がそれぞれ独立して管理されていたため、たとえばターミナル側でセッション名を変更してもエディタタブには古い名前が残り続けるといった不整合が発生していました。本リリースではCopilot SDKのセッションタイトルAPIを正式な情報源として採用し、すべてのUIで単一のタイトルリゾルバを経由するよう改修されました。

これにより、どこでセッション名を変更しても他のUIへ即座に反映され、表示が一貫します。さらに、ターミナル側でcopilot --resumeを使ってセッションを再開した場合も、変更後のタイトルが正しく引き継がれる仕様となりました。一見地味な改善に見えますが、複数セッションを並行して走らせる開発者にとってはセッション識別の混乱を防ぐ重要な改善であり、日常作業の認知負荷を着実に下げる効果があります。

実験的機能ゆえの制限事項と本番運用での展開可否を分ける判断基準

リモート制御は1.118でも実験的機能として位置付けられており、すべての利用者に対して常時安定動作することが保証されているわけではありません。本番運用への適用を検討する際には、いくつかの判断基準を踏まえる必要があります。第一に、実験的機能はバージョンアップに伴って仕様が変更される可能性があり、運用手順を文書化しても短期で陳腐化するリスクが存在します。

第二に、リモート操作中の認証や権限管理は基本的にGitHubアカウントベースで行われるため、組織のセキュリティポリシーと齟齬が生じないか事前に確認すべきでしょう。第三に、長時間動作するエージェントの結果を遠隔から判断する場合、誤った承認操作が混入するリスクがあるため、重要な判断は対面確認に戻すルールを設けるなどの運用補強が望まれます。これらの観点から、まずは個人の検証段階で挙動を見極め、その後チーム単位での試験運用に展開していく段階的アプローチが現実的です。本番運用の全面展開は、本機能が安定版として正式に位置付けられるまで待つほうが安全でしょう。

コードベース検索強化による全ワークスペースでの精度向上と速度改善

本リリースではコードベース検索機能が大きく強化され、Copilotが対象コードを正確に把握する能力が向上しました。セマンティック検索の対象拡大、リポ横断のテキスト検索、スキル専用コンテキストの導入など、検索体験を再構築する複数の改善が同時に投入されています。本章で各機能を整理します。

非GitHubリポジトリへのセマンティックインデックス展開の経緯

セマンティックインデックスは、文字どおりの単語一致ではなく意味に基づいてコードを検索する機能で、たとえば「authentication」と質問した際にlogin、signIn、verifyCredentialsといった関連語を含むファイルを正しく拾い上げます。これまでこの機能はGitHubおよびAzure DevOpsリポジトリでホストされたワークスペースに限定されていましたが、1.118ですべてのワークスペースで利用可能になりました。

具体的には、ローカルのみで管理しているプライベートリポジトリや、自社独自のVCS上にあるコードベースでもセマンティック検索が機能するようになっています。GitHubやADOのリポジトリでは即座にインデックスが利用可能ですが、それ以外のワークスペースでは初回利用時にインデックス構築が走り、規模によっては数分の準備時間が必要となります。事前に明示的にインデックスを構築したい場合は、コマンドパレットからBuild Codebase semantic indexを実行することで、利用前に準備を整えておけるでしょう。これにより、Copilotが提示する回答や編集提案の精度がリポジトリの所属に関係なく安定する環境が整いました。

文字列一致検索とセマンティック検索の使い分けに関する具体的な判断基準

コードベース検索には複数の方式があり、それぞれ得意分野が異なります。文字列一致検索は特定のAPI名やエラーメッセージを正確に探すのに適しており、検索対象の文字列が事前に明確な場合に高い効果を発揮するでしょう。一方でセマンティック検索は、概念や意図に基づいて関連コードを発見するのに有効で、検索対象の正確な単語がわからない場合や、関連する複数の表現を横断的に拾いたい場合に向いています。

これらは排他関係ではなく、Copilot自身が状況に応じて最適なツールを選択します。利用者が明示的に切り替える必要はないものの、各方式の特性を理解しておくと、エージェントの挙動を読み解きやすくなるでしょう。

githubTextSearchツール導入によるリポ横断のgrep検索実現

githubTextSearchはCopilotに新しく組み込まれたエージェントツールで、現在開いているワークスペースの外側にあるGitHubリポジトリや組織全体を対象にgrepスタイルの精密な文字列検索を行います。たとえば社内に複数のリポジトリがあり、特定のクラス名がどのリポジトリで使われているかを横断的に確認したい場面で力を発揮するでしょう。既存のgithubRepoツールはリポジトリ内をセマンティックに検索する用途でしたが、githubTextSearchはあくまで厳密な文字列一致を求める検索に特化しており、両者を補完的に利用する設計です。

これにより、エージェントが現在のワークスペース外にある参考実装や類似処理を効率的に探し出し、回答や編集提案の根拠として活用できる範囲が広がりました。たとえば他のリポジトリではこの関数をどう書いているかといった質問へ、より自信を持った回答が返ってくるようになります。なお、より高度なGitHub連携機能、たとえばIssueやPRの管理を行いたい場合は、別途GitHub MCPサーバの導入が推奨されており、用途に応じてツールを使い分ける運用が現実的でしょう。

Build Codebase semantic indexコマンドの活用シナリオ

Build Codebase semantic indexは、ワークスペースのセマンティックインデックスを明示的に構築するコマンドです。GitHubやADO以外のリポジトリでは初回検索時に自動でインデックスが構築されますが、規模の大きいコードベースでは数分かかる場合があるため、本コマンドを使って事前に構築を済ませておく運用が有効となります。

具体的な活用シーンとしては、新しいプロジェクトをVS Codeで開いたタイミングや、リポジトリのファイル構成が大きく変化したあとに手動でコマンドを実行することで、エージェントの初回利用時にスムーズな検索体験を提供できます。コマンドはコマンドパレット(Ctrl+Shift+PまたはCmd+Shift+P)からBuild Codebase semantic indexと入力することで実行可能です。インデックス構築中も他の作業を継続できますが、メモリ消費が一時的に上がる可能性があるため、軽量タスクと並行させる運用が無難でしょう。なお既存のインデックスは自動でメンテナンスされるため、定期的な再構築は通常必要ありません。

スキル専用サブエージェントcontext: forkの実装手順

スキルは複数のツール呼び出しや大量の参考資料を扱う場面があり、その中間出力がメインのチャットコンテキストを圧迫すると、後続の応答品質が低下する問題があります。1.118ではこの問題に対処するため、スキル実行時に独立したサブエージェントコンテキストへ処理を切り出すcontext: fork機能が導入されました。有効化するにはスキルのSKILL.mdのフロントマターにcontext: forkを追加します。

具体的には、nameとdescriptionに加えてcontext: forkを記述する形式となります。さらにgithub.copilot.chat.skillTool.enabled設定をtrueにする必要があります。本機能は実験的提供のため、本格運用前にスキルごとの動作を検証することが望ましいでしょう。サブエージェントへ切り出すことで、スキル特有の長大な参照情報がメインの会話履歴を埋め尽くす状況を回避でき、メイン会話側の回答精度が安定します。複雑なスキルを多用する開発者にとって、コンテキストが汚染されにくくなる点は大きな利点です。

ワークスペース.mcp.jsonによるMCPサーバ重複統制の方法

1.118ではワークスペース単位のMCPサーバ宣言を行う.mcp.jsonファイルがサポートされ、Copilot CLIをはじめとする他ツールとの整合が取れました。これにより、プロジェクトごとに必要なMCPサーバ設定をリポジトリに同梱し、チーム全員で同じMCP環境を再現する運用が容易になっています。さらに同名のMCPサーバが複数定義されていた場合の重複統制が新たに導入されました。

デフォルトでは最も特定範囲の狭い宣言が優先され、有効化されたサーバと同名のサーバは自動的に無効化される仕組みです。これにより、ユーザー設定とワークスペース設定の双方で同じ名前のサーバを定義していても、衝突によるトラブルが回避されます。どのMCPサーバが現在有効化されているかを確認したい場合は、拡張機能ビューで@mcp @installedと検索するか、Chat: Open Customizationsからカスタマイズ画面を開いて確認できるでしょう。チーム開発では、設定の食い違いによるサーバ動作不良の調査が時間を浪費しやすいため、本仕組みは運用負荷の軽減に直結します。

トークン効率化93%キャッシュ再利用と従量課金時代のコスト対策

1.118の中核テーマのひとつがトークン効率化です。Copilotが2026年6月1日から従量課金へ切り替わるという課金変更を控え、Microsoftはトークン消費量を抑えながら品質を維持するための複数の施策を本リリースに盛り込みました。本章で各施策の内容と実務的な意味を整理します。

6月1日開始のCopilot従量課金移行と1.118施策の連動関係性

GitHubは2026年4月27日、Copilotを6月1日から従量課金制へ移行すると発表しました。本発表からわずか2日後に公開された1.118には、トークン効率を大幅に改善する複数の機能が同梱されており、課金変更前にコストを抑制する基盤を整える狙いが明確に表れています。リリースノート上でもMicrosoftはプランから最大の価値を引き出せるよう、エージェントの品質を損なわずにトークン効率を改善する取り組みを進めていると説明しており、両者の関係性を直接的に認めた形となりました。

利用者側からすれば、6月1日以降は同じ作業でもトークン消費量がコストに直結するため、1.118で投入された各種改善は無視できない影響をもたらします。実際、開発者コミュニティでは課金変更の発表後、関連スレッドのコメント数が3日で70件から237件、回答が319件に増えるなど反応の大きさが顕著で、1.118の効率化施策はこの反発に対する技術的回答とも位置付けられるでしょう。本リリースを適切に取り込むことが、6月以降のCopilot運用コストを左右する重要な判断材料です。

93%キャッシュ再利用率を実現する4つのキャッシュ最適化施策

1.118では、エージェントセッション中のリクエストの93%以上がキャッシュから再利用されるレベルまでプロンプトキャッシュ効率が改善されました。これは複数の最適化施策の積み重ねによって達成された数値です。

1. キャッシュブレイクポイントの戦略的配置:システムプロンプト末尾、ツール定義末尾、最新ツールターン末尾、会話ターン境界という4つの安定境界に配置
2. システムプロンプトとツールリストのキャッシュ安定化:言語拡張のロード状況によらず一定のバイト列を維持するよう調整
3. キャッシュフレンドリーな背景圧縮:長い会話の古いターンを背景で要約しつつ、メインのキャッシュコンテキストを再利用
4. 直近2メッセージのブレイクポイント戦略:長時間セッションでもシステムプロンプト・ツールリスト・直近2メッセージにアンカーを配置

これらの組み合わせにより、Anthropicのモデルでは繰り返しコンテキストが新規入力比で約10分の1のトークンレートで課金されるようになりました。長時間の多段階エージェントワークフローでは特にコスト削減効果が顕著で、毎ターンのリクエスト全体のうち93%超がキャッシュ再利用となるため、利用者にとって課金負担の体感差は大きくなります。

約30個の常時利用ツールに絞るtool_searchの仕組み

tool_searchはエージェントのツールセットを2階層に分割することで、リクエストサイズを軽量化する仕組みです。常時利用可能な約30個のコアツールが全ツール呼び出しの約88%をカバーし、残りのツールは遅延読込として宣言されます。エージェントが遅延ツールの機能を必要としたときだけ、tool_searchを呼び出して埋め込みベースのセマンティック検索でクライアント側で関連ツールを取得する設計となります。

これにより毎ターンのプロンプト前置部が安定し、キャッシュが効きやすくなると同時に、1ターンあたりに送信されるツールスキーマのサイズが大幅に縮小しました。AnthropicのClaude Sonnet 4.5以降およびOpus 4.5以降ではtool_searchがすでにデフォルト有効化されており、最大20%のトークン削減が観測されています。1.118ではこの仕組みがOpenAI GPT-5.4とGPT-5.5にも展開され、Responses API経由で同等以上のトークン削減効果が確認されました。GPTモデルでtool_searchを使うにはgithub.copilot.chat.responsesApi.toolSearchTool.enabledを有効化する必要があります。

最大20%のトークン削減を生む新agentic searchツールの設計

agentic searchツールはコードベース探索とコンテキスト取得を専用に担う新しいツールで、ファインチューニングされた小型言語モデルによって駆動されます。メインのエージェントが必要なコンテキストを自然言語で記述すると、agentic searchツールが独立プロセスでgrep、ファイル検索、セマンティック検索、ファイル読込を組み合わせて並列に実行し、最も関連度の高い結果のみを返却する設計です。

専用の小型モデルは多数の検索を最小ターン数で並列実行するように訓練されており、メインモデルが直接検索作業に取り組むよりもレイテンシとコストが大幅に抑えられます。Microsoftは1か月以上のフライト試験を経て、後述するagentic executionツールと組み合わせた両ツール合計で最大20%のトークン削減という結果を確認したと報告しており、本リリースから順次全Copilot Chatユーザーへ展開される予定でしょう。利用者側で特別な設定は不要で、ロールアウトが進めば自動的にこの最適化の恩恵を受けられます。検索品質は維持されたまま、メインモデルの負荷だけが軽減されるため、長時間の調査タスクでとくにコスト効果が高くなる傾向が見えています。

ターミナル10回上限のagentic executionツールの動作仕様

agentic executionツールはターミナルコマンド実行を専用に担当するツールで、agentic searchと同様に小型モデルで駆動される設計です。テスト実行やビルド確認など、ターミナル操作が必要な場面でメインエージェントから処理を引き継ぎ、コマンドを実行して結果を要約して返します。本ツールにはターミナル呼び出し回数を1呼び出しあたり10回までに制限する仕様が組み込まれており、無限ループや過剰な再試行を防ぐ仕組みが内蔵されました。

ターミナル出力は冗長で長くなりがちですが、agentic executionツールは出力をフィルタリングし、コーディングエージェントが本当に必要とする部分だけをメインモデルへ返却します。これにより、テスト実行などで発生する大量のログがメインのトークン消費を圧迫する問題が解消されました。実務的には、テストや小規模ビルドを伴うエージェントタスクにおけるトークン消費量が体感できるレベルで減少し、長時間の検証作業でも従来よりコスト負担が抑えられる効果があります。本ツールも順次ロールアウトが進められており、特別な設定なく恩恵を享受できる仕様です。

GPT-5.4とGPT-5.5でのResponses API経由のツール検索適用

OpenAIモデルにおいてtool_searchはGPT-5.4およびGPT-5.5で利用可能となり、Responses APIを介して呼び出されます。これらのモデルは2026年4月時点のCopilot対応モデル群の中でも最新世代に位置づけられており、Responses APIを使うことで会話状態をサーバ側に保持できる仕組みも併用できます。tool_searchをGPTモデルで有効化するにはgithub.copilot.chat.responsesApi.toolSearchTool.enabledを設定で有効化する必要があり、本リリースではデフォルト無効ですが、Insiders環境での早期テストではAnthropicモデルと同等以上のトークン削減効果が確認されました。

さらにOpenAIモデル全般においては、対応モデルでチャットリクエストがWebSocketモードを使用するように切り替わり、毎ターンHTTPリクエストを新規に開く代わりに永続的なWebSocket接続を維持して新しい入力アイテムだけ送信する設計に変わっています。これによりリクエストサイズと応答待ち時間が削減され、Microsoftの計測ではOpenAIモデルが約12%高速化したという結果が報告されました。

企業向けセキュリティ強化と承認組織ポリシー導入の実装ポイント

企業導入を進めるチームにとって、AI機能の利用統制とサンドボックス強化は重要な関心事です。1.118では承認組織ポリシーやサンドボックスのデフォルト挙動変更など、組織レベルの統制を支援する仕組みが拡充されました。本章では運用判断に必要な観点を整理します。

ChatApprovedAccountOrganizationsポリシーの設定要件

ChatApprovedAccountOrganizationsは1.118で新たに追加されたデバイスポリシーで、AI機能の有効化を承認済みのGitHub組織への所属確認に基づいて制御します。本ポリシーが適用された環境では、ユーザーが承認された組織に所属するGitHubアカウントでサインインし、かつアカウントベースのポリシー解決が完了するまで、チャット機能をはじめとするAI機能は有効化されません。これは、フェイルクローズ型の挙動を採用しており、判定が完了しない限りデフォルトで機能が無効のままになる設計です。

企業のIT管理者が組織のセキュリティ要件に合わせてGitHub.com側でアカウントベースポリシーを設定している場合、本機能を併用することで承認外のアカウントでAI機能が利用される事故を防げます。設定はデバイスポリシーとして配布されるため、MDMなどの仕組みを通じて全社一括で適用することが可能でしょう。本機能の詳細はVS Codeのenterprise policiesドキュメントに記載されており、導入を検討する組織は事前に対象ポリシーの設定方法と挙動を把握しておくことが推奨されます。

フェイルクローズ動作によるチャット機能アクセス統制の具体的仕組み

ChatApprovedAccountOrganizationsポリシーの中核となるのがフェイルクローズ動作です。フェイルクローズとは、判定がまだ完了していない状態や判定に失敗した状態では、対象機能を無効のまま維持する設計を意味します。これにより、ネットワークトラブルやポリシー解決遅延が発生した際にも、承認外のアカウントでAI機能が誤って有効化されるリスクを排除できるでしょう。

具体的には、チャット機能の起動エントリポイント全般にこの仕組みが適用されるため、コマンドパレットやエディタ内のチャットビュー、エージェント関連UIなど、AI機能を呼び出す入口でアクセスが一律にブロックされる挙動です。利用者にとっては、自分のGitHubアカウントが承認組織に所属していない場合や、ポリシー判定が遅延している場合にチャットが使えないという形で表れますが、これは設計どおりの動作となります。一方で本機能を有効化していない通常利用者には影響がなく、企業環境特有のセキュリティ要件に合わせた選択的な有効化が可能です。フェイルクローズの考え方は情報セキュリティ全般で広く採用されている設計原則であり、信頼性の高い統制を実現する基盤となっています。

$HOMEディレクトリの自動読取無効化とサンドボックス分離強化策

1.118ではサンドボックス機能のデフォルト読取権限が見直されました。従来は$HOMEディレクトリ配下のすべてのパスに対して自動的に読取権限が付与されていましたが、本リリース以降はこの自動付与が廃止されました。サンドボックス内でコマンドが実行される際には、その実行コマンドが明示的に必要とするパスのみに読取権限が付与され、それ以外の$HOMEディレクトリ配下のパスへの読取アクセスはすべて拒否される仕様です。

これにより、悪意あるスクリプトや想定外のコマンドが家のディレクトリ全体を勝手に読み取るリスクが大幅に軽減されました。一方で、ワークスペースフォルダとサンドボックスの一時設定ディレクトリには自動で読取権限が付与されるため、通常の開発作業に必要なファイルアクセスは確保されています。本変更はセキュリティ強化に直結する重要な改善ですが、特定のスクリプトやツールが従来の挙動を前提に設計されていた場合、想定通り動作しない事象が発生する可能性があるでしょう。導入後は、自社で利用しているサンドボックス対応コマンドが正しく動作するかを検証し、必要に応じて読取権限の明示指定を追加する対応が望まれます。

GitコミットへのCopilot共著者自動追加機能と無効化設定の選択

1.118からGitのAI共著者機能がデフォルトで有効になりました。Copilotがファイル変更を行ったコミットには、Copilotが自動的に共著者として記録されます。これは、AIが関与した変更を明示的に履歴へ残し、レビューやコンプライアンスの観点で透明性を高める目的があります。共著者として追加される情報はGitコミットメッセージのトレーラーに記録され、後から履歴を辿る際にどのコミットでCopilotが関与したかを判別できる仕組みです。

一方で、社内ポリシーの都合や個人の好みでこの機能を無効化したい場合は、git.addAICoAuthor設定をfalseに変更することで挙動を制御できるでしょう。組織レベルで一律に無効化する場合は、デフォルト設定をリポジトリの設定ファイルや組織共有のVS Code設定で上書きする方法が現実的です。導入の判断は、コミット履歴の透明性をどの程度重視するか、そしてレビュー時にAI関与を区別する必要があるかどうかという観点で行うとよいでしょう。実務では、オープンソース貢献を行うチームほど共著者明示を歓迎する傾向があります。

承認組織への所属未確認時の機能無効化フローと典型的トラブル例

承認組織ポリシーが有効化された環境では、利用者のGitHubアカウントが承認組織に属しているかどうかが確認できるまでチャット機能が無効化されます。このフローで発生する典型的なトラブルとして、最初に挙げられるのがサインインしているのにチャットが起動しないという症状でしょう。原因の多くは、サインイン中のGitHubアカウントが承認対象の組織に属していない、または属していてもポリシー解決が遅延しているケースに分類されます。

次によく発生するのが、ネットワーク制限環境でGitHubのポリシー解決エンドポイントに到達できないケースで、この場合もフェイルクローズの設計によりチャットは利用できません。三つめのパターンは、複数のGitHubアカウントを使い分けているユーザーが、承認組織に属さない別アカウントで自動サインインしているケースです。これらのトラブルに対処するには、現在のサインインアカウントを確認し、承認組織に属するアカウントへ切り替えること、必要に応じてネットワーク管理者へGitHub.comとの通信許可状況を確認することが基本的な対応となります。組織導入時には事前にサポート手順を文書化しておくと、運用開始後の問い合わせ対応がスムーズです。

TypeScript 7対応による型チェック高速化の実測値と移行判断

1.118ではTypeScript 7のサポートが進み、VS Code自身の開発でもTypeScript 7が型チェックに採用されました。ネイティブコードへの全面書換によって型チェック性能が大幅に向上しており、大規模プロジェクトを抱える開発者にとって移行判断が現実的なテーマとなりつつあります。本章で導入手順と判断基準を整理します。

TypeScript 6から7へのネイティブコード書換による高速化原理

TypeScript 7はコンパイラとリンタを含むコア部分がネイティブコードへ全面的に書き換えられた版で、JavaScript実装で動作していたTypeScript 6.0と比較して劇的な性能向上が実現されています。TypeScriptは大規模プロジェクトになるほど型チェックの負荷が増加する性質があり、JS実装ではどうしても型推論や差分解析に時間がかかる課題がありました。ネイティブ実装への移行はこの課題に対する根本的な対策として位置付けられるでしょう。

具体的には、メモリ管理や並列処理の効率化、起動時間の短縮といった改善が積み重なり、結果として全体のビルド時間が大幅に削減されています。TypeScript 7は依然としてベータ段階ではあるものの、開発に伴うストレスを大きく軽減する基盤となる存在です。なお、互換性についてはTypeScript 6で動作していたコードベースが基本的にそのまま動作する設計となっており、移行時の追加修正は限定的に抑えられています。安定版が出るまでの間は、TS 6.0と並行して試用していく運用が現実的でしょう。

VS Code内部での60秒から10秒への型チェック時間短縮実例

VS Code自身の開発ビルドでは、約6,000ファイルを抱えるメインプロジェクトの型チェックに従来60秒程度を要していました。1.118から開発のwatchタスクでTypeScript 7を使うようになり、フルビルドの型チェック時間が約10秒へ短縮されたと報告されています。さらにwatchタスクの起動からVS Code本体と組み込み拡張機能のビルドおよび型チェックが完了するまでの時間も、現在は約30秒で全体ビルドが完了する水準に達しています。

この実測値は、TypeScript 7の性能改善が単なる理論上のものではなく、Microsoftが日々の開発で実際に体感している効果であることを示しています。同様の規模のTypeScriptプロジェクトを抱えるチームであれば、移行による体感速度の改善は十分に期待できるでしょう。特に開発者が頻繁にファイルを保存するスタイルで作業している場合、watchビルドの待ち時間短縮は1日のトータル作業時間に直結する重要な変化となります。なお実測値はあくまで参考値であり、各プロジェクトの構成や使用ライブラリによって差異が生じます。

TypeScript Native preview拡張機能による試用導入手順

VS CodeでTypeScript 7を試用するには、TypeScript Native preview拡張機能をインストールするだけで済みます。複雑な設定変更や別バイナリのインストールは不要で、拡張機能マーケットプレイスから対象拡張を導入すれば、現在開いているTypeScriptプロジェクトを直ちにTS 7.0で型チェックできるようになるでしょう。導入後はTypeScriptバージョンを切り替えるVS Codeのコマンドを使って、TS 6.0安定版とTS 7.0ベータ版を簡単に行き来できる設計となっています。

これにより、TS 7.0で正常にビルドが通るかを試したあとに、すぐ安定版へ戻して本番作業を続ける運用が可能となりました。試用段階では、自社プロジェクトのテストスイートをTS 7.0で実行し、想定通りの結果になるかを確認していく流れが推奨されます。なお、TS 7.0に固有の警告や挙動変更が出る場合もあるため、本番採用前に十分な検証期間を設けることが望まれるでしょう。安定版のリリースを待たずに先行調査を進めたいチームにとって、本拡張機能は大きな助けとなります。

TS 6.0安定版とTS 7.0betaを切替可能にする運用面の利点

TS 6.0安定版とTS 7.0ベータ版を簡単に切り替えられる仕組みは、移行期における運用面での大きな利点を提供します。具体的には、本番開発はTS 6.0で継続しつつ、検証用ブランチや特定の作業セッションだけTS 7.0で動作確認を行う柔軟な運用が可能となるでしょう。これにより、安定版のリリースを待たずにベータ版の評価を進められ、自社コードベースに対するTS 7.0の影響を早期に把握できます。

切替操作はVS Codeのコマンドパレットから行えるため、ターミナル操作やpackage.jsonの変更といった手間が発生しません。チーム内で複数の開発者が並行して試用する場合も、各自が独立してバージョン切替できる構造となっています。なお切替を頻繁に行うと拡張機能が再起動されるため、検証中に別の作業を並行する場合は注意が必要です。実務的には、移行候補のプロジェクトをいくつか選び、TS 7.0で問題が出ないか確認したうえでチーム全体に展開する段階的アプローチが安全でしょう。

大規模TypeScriptプロジェクトでの導入判断と互換性確認の論点

大規模TypeScriptプロジェクトにおけるTS 7.0導入は、性能向上のメリットと互換性リスクの両面から判断する必要があります。メリット面では、6,000ファイル規模で60秒から10秒への型チェック短縮が示すように、開発体験の劇的な改善が期待できます。一方、互換性面では、TS 7.0がベータ段階であるため、特殊なコンパイラオプションや古い型定義に依存しているコードで挙動差が出る可能性があるでしょう。

具体的な検証ポイントとしては、自社が依存している型定義ライブラリ(@typesパッケージ)がTS 7.0で正しく解釈されるか、CI環境で使っているTypeScriptビルドツール群がTS 7.0と互換であるか、既存のtsconfig.json設定がTS 7.0で意図通り機能するかといった項目が挙げられます。これらを事前に検証することで、いざ移行する段階でのトラブルを抑えられます。中規模以上のプロジェクトでは、TS 7.0安定版のリリース後に正式移行する判断が現実的で、それまでは性能評価のために試用する位置付けが妥当でしょう。

Webview最適化やDev Containerロックファイル等の周辺改善

本リリースでは主要トピック以外にも、Webviewのリソース読込最適化やDev Containerのロックファイル機能、Chronicleと呼ばれる新しい履歴機能など、開発体験を底上げする周辺改善が多数導入されました。本章ではこれらの周辺機能を整理し、実務上どのように活かせるかを示します。

ストリーミング転送によるWebview大容量リソースの読込改善

Webviewを使う拡張機能やカスタムエディタで大容量リソースを扱う場合、従来はファイル全体をいったんバッファに読み込んでからWebviewのサービスワーカーへ送信する仕組みが取られていました。この方式は小さなJavaScriptファイルや画像であれば問題ありませんが、数十から数百MB規模の動画ファイルを20本扱うようなケースでは、メモリ消費量が膨大になり応答性も低下するという課題があったでしょう。

1.118ではこの仕組みが見直され、ファイル内容をチャンク単位でストリーミング転送する方式に変わりました。これにより、応答性が向上すると同時にVS Code側で蓄積するデータ量が大幅に削減され、ブラウザエンジンへ手渡す前の処理がより軽量化されています。組み込みのノートブックレンダリングなど、VS Codeが内部で利用している機能も本改善の恩恵を受けるため、利用者から見て体感の動作速度が向上したと感じられる場面が増える見込みです。Webviewを使った重いコンテンツを扱う拡張機能の開発者にとっても、自然な性能向上が得られます。

transferable streams導入によるpostMessage削減の効果

Webview最適化のさらに踏み込んだ改善として、transferable streamsの採用が挙げられます。これは、メインのVS Codeレンダラプロセスで作成されたファイルストリームを、Webview内部のサービスワーカーが直接new Response(...)で消費できるようにする仕組みです。従来は複数階層のpostMessage呼び出しを経由する必要があり、各階層でデータを引き渡すたびにオーバーヘッドが発生していました。

transferable streamsはWeb標準として定義された仕組みで、ストリームオブジェクトを所有権ごと転送することで、不要なコピーや再シリアライズを排除します。1.118はこの標準を実装に取り入れ、結果としてWebview経由のリソース読込パスが短縮され、CPU使用率と応答時間の双方が改善されました。本改善は拡張機能開発者から見て透過的に作用するため、追加の対応コードを書かずとも自動的に恩恵を受けられる点も実務面の魅力でしょう。大容量データの扱いを多用する用途、たとえば医用画像ビューアや動画編集系の拡張機能では、効果が体感できるレベルとなります。

devcontainer-lock.jsonデフォルト有効化と供給網攻撃対策

Dev Containerでは、Featureと呼ばれる再利用可能な機能パーツを宣言してコンテナ環境に組み込みます。1.118より前のバージョンでは、Featureのバージョン固定はオプション扱いでしたが、本リリースからdevcontainer-lock.jsonのロックファイルがデフォルトで有効になりました。ロックファイルはFeatureを初めてインストールしたときのバージョンとチェックサムを記録し、以降は同じバージョンに固定する役割を果たします。

これは供給網攻撃(サプライチェーン攻撃)への対策として重要な意味を持ちます。攻撃者が同じバージョン番号で異なる内容のFeatureを公開し直した場合でも、ロックファイルに記録されたチェックサムと一致しないため、自動的に拒否される仕組みとなるでしょう。さらにdevcontainer.jsonファイル上では、Code LensによってFeatureに新しいバージョンが存在するかどうかが示されるため、開発者は更新すべきかどうかを意識的に判断できます。組織のセキュリティポリシーで再現性と完全性を求められる現場では、本機能のデフォルト有効化は歓迎すべき変更です。

Dependabot連携によるDev Container Featureのバージョン管理

Dev Containerのロックファイルが有効化されたことで、Dependabotとの連携によるバージョン管理が現実的な選択肢となりました。具体的には、リポジトリにロックファイルが含まれている状態でDependabotを有効化しておくと、Featureに新しいバージョンが公開された際に、自動的にロックファイルを更新するプルリクエストが作成されます。これにより、Featureの更新作業を手動で行う負荷が大幅に削減されるでしょう。

セキュリティアップデートの観点でも、Dependabotがロックファイルを監視することで、既知の脆弱性を含むバージョンに長期間留まり続けるリスクを抑制できます。プルリクエストにはバージョン差分情報や変更内容が記載されるため、レビューワーが内容を確認したうえでマージするか判断できる仕様です。Featureの提供元側でもセマンティックバージョニングを意識した更新が広がりつつあり、Dependabot連携はその恩恵を最大限に活用する仕組みとして機能します。継続的なセキュリティ運用を実現するうえで、本連携は重要な構成要素のひとつとなりました。

WebSocket通信によるOpenAIモデルでの12%応答速度向上

1.118ではOpenAIモデルとの通信方式が見直され、対応モデルではWebSocketモードがデフォルトで使用されるようになりました。従来は毎ターンごとに新しいHTTPリクエストを開く設計でしたが、WebSocketモードでは持続的な接続を保ったまま新しい入力アイテムだけを送信し、サーバ側で会話状態を保持する仕組みへ変わっています。これによりリクエストサイズが縮小し、応答時間も短縮される効果が生まれました。

Microsoftの計測結果では、WebSocketモードを使うことでOpenAIモデルが約12%高速化されたと報告されています。エージェントワークフローのようにツール呼び出しと応答が頻繁にやり取りされる場面では、この速度向上が体感の作業効率に直結するでしょう。WebSocketモードは選択モデルが対応している場合のみ自動的に使用される仕組みで、利用者が手動で設定する必要はありません。Responses APIと組み合わせることでさらに効率化が進む構造となっており、対応モデルを選んでいる利用者は何もしなくても恩恵を受けられる設計となっています。

Chronicle機能による標準化されたstandupレポート自動生成

Chronicleは1.118で実験的に導入された新機能で、Copilotとのチャット履歴をローカルのSQLiteデータベースに記録し、過去のセッションを横断的に検索・要約できる仕組みです。記録される情報にはセッションメタデータ(ブランチ、リポ、タイムスタンプ)、会話ターン、ツール呼び出しによって変更されたファイル、参照されたPRやIssueなどが含まれます。これにより、過去の作業内容をスクロールして探し回る手間が大幅に削減されるでしょう。

具体的なコマンドとしては、/chronicle:standupが直近24時間のコーディングセッションからstandupレポートを自動生成し、機能やブランチごとにまとめた要約とPRリンクを提示します。/chronicle:tipsは7日間の利用パターンを分析してプロンプティングやツール使用のパーソナライズドなヒントを返し、/chronicle [query]では昨日編集したファイルは何かといった自由形式の質問に答えます。本機能を使うにはgithub.copilot.chat.localIndex.enabled設定を有効化する必要があり、データはローカルに保管されるためプライバシー面でも安心して試せる設計です。

VSCode 1.118への更新手順と1.118.1修正対応の進め方

VSCode 1.118への更新は、自動アップデートを利用すれば数分で完了する単純な作業ですが、企業環境や検証要件のあるチームでは、計画的な手順を踏むことが望まれます。本章では更新手順、ホットフィックスの扱い、設定見直しの観点、そしてロールバック手順まで実務に必要な情報を整理します。

自動アップデートの受信タイミングと手動更新を実行する5つの手順

VS Codeはデフォルトで自動アップデートが有効化されており、新しいバージョンが公開されると数日以内に通知が表示されます。即座にアップデートを適用したい場合や、自動更新を待ちたくない場面では、以下の手順で手動更新が可能です。

1. VS Codeのヘルプメニューから「更新の確認」(Check for Updates)を選択する
2. 新しいバージョンが検出されたら、ダウンロードを開始する選択肢を選ぶ
3. ダウンロード完了後、再起動を促す通知が表示されたら、保存していない作業をすべて保存する
4. VS Codeを再起動し、新バージョンの適用を完了させる
5. 再起動後、ヘルプメニューのVS Code情報からバージョンが1.118.1になっているか確認する

自動更新を無効化している環境では、Microsoftの公式ダウンロードページからインストーラを取得し直して上書きインストールする方法もあります。企業環境ではIT管理者が更新ポリシーを設定している場合があるため、手動更新が許可されているかを事前に確認しておくと安全でしょう。

1.118.1ホットフィックスのCLI不具合修正内容と適用要否

1.118.1は2026年4月30日に配信されたホットフィックスで、GitHub Copilot CLIがVS Codeから正しく起動できないという既知不具合が修正されています。1.118を使い始めた直後にCopilot CLIを起動しようとして反応がない、あるいはエラーが出るという症状を経験したユーザーは、本ホットフィックスで解決します。Copilot CLIを業務の中心的なツールとして使っているチームにとっては適用が必須です。

適用要否を判断する基準としては、Copilot CLIの利用頻度がもっとも重要な要素となります。日常的にCLIを使っているチームでは1.118.1へ即座に更新すべきで、CLIを使わずチャット中心の運用を行っているチームは緊急性が低いものの、安定性向上のために更新が推奨されるでしょう。なお、現時点で配信されているのは1.118.1のため、新規インストールでは自動的にこのバージョンが適用されます。既存の1.118から1.118.1へは自動更新で移行するのが通常の流れで、手動操作は基本的に不要です。

アップデート前のバックアップ取得と拡張機能互換性確認の具体手順

業務利用しているVS Codeをアップデートする前には、設定や拡張機能のバックアップを取っておくと安心です。具体的には、設定はVS Codeの「Settings Sync」機能を有効化することで自動的にクラウドへ同期されます。あるいはsettings.jsonを直接コピーして手元に保管する方法も簡単な代替策となるでしょう。拡張機能については、ユーザーがインストール済みの拡張一覧をエクスポートできるコマンドが用意されており、不測の事態に備えて記録を取っておけます。

互換性確認の観点では、自社で利用している主要拡張機能が1.118に対応しているかを事前にチェックすることが重要です。多くの拡張機能はVS Codeのバージョンアップに追従していますが、開発が止まっている拡張機能では動作しなくなる可能性があります。アップデート直後に動作確認を行い、問題のある拡張機能があれば代替を検討する流れが望まれるでしょう。組織でアップデートを展開する場合は、検証ユーザーに先行アップデートを行ってもらい、問題が発見されなければ全体展開に進む段階的アプローチが安全です。

github.copilot.chat関連設定の見直しと必要な追加設定

1.118では新たにいくつかのCopilot Chat関連設定が追加されており、機能を最大限活用するには設定見直しが推奨されます。代表的なものとしてgithub.copilot.chat.cli.remote.enabled(リモート制御)、github.copilot.chat.skillTool.enabled(スキル専用context)、github.copilot.chat.responsesApi.toolSearchTool.enabled(GPTモデルでのtool_search)、github.copilot.chat.localIndex.enabled(Chronicle)などが挙げられるでしょう。

これらの設定はいずれも実験的機能や段階的展開の途上にある機能を制御するもので、デフォルトでは無効化されています。利用したい機能に応じて個別に有効化していく流れとなります。設定の有効化はVS Codeの設定UIで該当キーを検索することで簡単に行え、ワークスペース単位とユーザー単位で独立に管理可能です。組織導入時には、どの設定を全社展開するかをポリシーとして定めておくと、利用者ごとの環境差異を抑えられます。設定の追加はsettings.jsonにkey-valueを書き込む方法でも可能なため、管理者主導で配布することもできるでしょう。

更新後の動作確認チェック項目とロールバックを実施する具体手順

更新が完了したら、最初に動作確認を行うことが推奨されます。確認すべき項目としては、主要拡張機能が正常に起動するか、コーディング作業で利用するキーボードショートカットが従来通り機能するか、Copilot Chatが正常に応答するか、ターミナルが想定通り動作するかといった基本的な点が挙げられます。これらに問題がなければ、新機能の試用に進める判断ができるでしょう。

万一問題が発生した場合のロールバックは、Microsoftが提供する以前のバージョン用ダウンロードリンクから1.117などの旧バージョンインストーラを取得し、上書きインストールすることで実施できます。ただし設定ファイルのフォーマットが新バージョンに依存している場合、ロールバック後に一部の設定が失われる可能性があるため、事前のバックアップが重要です。組織でロールバックポリシーを定めておくと、トラブル発生時の対応が迅速になります。なおInsiders版を併用している場合は、Stable版のロールバックで Insiders側の機能には影響しないため、検証用にInsidersを残しておく運用も現実的でしょう。

旧バージョン1.117との主要差分とEdit Mode廃止の影響範囲

本リリースの内容を判断するうえで、直前の1.117と比較してどの機能が追加・削除されたかを把握することは重要です。さらに1.110で正式に非推奨化されたEdit Modeが、今後どのタイミングで完全に削除されるかは、特定の作業フローを利用してきた開発者にとって重要な検討事項となります。

1.117と1.118間の機能追加項目および削除項目の差分一覧整理

1.117から1.118への差分を整理すると、機能追加が中心で、削除や非推奨化は限定的です。主要な追加項目を整理すると次の通りとなるでしょう。

削除項目はほぼなく、Edit Modeの非推奨化(1.110で実施済み)に関する追加情報がアナウンスされた程度です。1.117で安定運用していたチームは、本リリースでは新機能の追加が中心となるため、互換性破壊リスクは比較的低いと判断できます。

Edit Mode廃止の経緯と1.125での完全削除までの猶予期間

Edit ModeはVS Code 1.110で正式に非推奨化されたチャット利用形態のひとつで、Agent Modeへの統合を背景に役割を終えることが決まっています。本リリース時点では引き続き暫定的に利用可能な状態が維持されていますが、1.125をもって完全に削除されることが公式にアナウンスされました。1.118から1.125までの間は猶予期間として扱われ、利用者はその間にAgent Modeへの移行を進めることが期待されています。

猶予期間が設けられている理由は、Edit Modeを業務フローに組み込んでいたチームに移行のための時間を確保することにあるでしょう。1.118を含む間のリリースでも、Edit Modeを再有効化する設定が暫定的に提供されているため、突然使えなくなるという事態は避けられます。ただし1.125以降はその設定自体が無効となり、回避策が消える点に注意が必要です。組織で計画的に移行する場合、1.120前後を目安にAgent Modeへの切替検証を進めておくと、1.125での切替時に慌てずに済みます。

chat.editMode.hidden設定によるEdit Mode暫定再有効化

1.118においてEdit Modeを引き続き利用したい場合は、chat.editMode.hidden設定を変更することで暫定的に再有効化できます。本設定は1.110での非推奨化以降、ユーザーが移行に必要な期間を確保できるよう用意されたもので、1.125までは引き続き利用可能な状態を維持します。設定はVS Codeの設定UIから検索して切り替える形で操作可能です。

ただし本設定は組織レベルで管理されている場合があり、IT管理者が一律に強制している環境では個人での変更ができない可能性があります。その場合は管理者へ問い合わせて方針を確認する必要があるでしょう。組織レベルで再有効化を許可する判断を下すケースとしては、業務クリティカルなフローがEdit Modeに依存しており、移行のための代替手段がまだ整っていない状況が考えられます。再有効化はあくまで一時的な措置と位置付け、Agent Modeへの本格移行を計画的に進めることが望まれます。1.125以降は設定そのものが廃止されるため、その時点で完全な切替が必要となる点を組織内で共有しておくべきです。

Agent Modeへの移行で発生する3つの典型的なつまずきパターン

Edit ModeからAgent Modeへの移行を進める際に、利用者が遭遇しやすい典型的なつまずきパターンを整理しておくと、移行計画の精度が上がります。代表的な3つのパターンは次の通りです。

• 操作フローの違い:Edit ModeとAgent Modeでは編集を確定するタイミングや差分確認の流れが異なり、慣れたフローを変更する必要が生じます
• 承認ステップの追加:Agent Modeはエージェントが自律的に動作するため、ファイル変更時に承認確認が挟まることが多くなり、リズムの違和感を感じやすい点が特徴です
• コンテキストの扱い差:Edit Modeでは編集対象が明示的でしたが、Agent Modeでは複数ファイルにまたがる変更や周辺ファイルの参照が暗黙的に行われ、想定外の変更が生じる可能性があります

これらのパターンに対しては、事前にチームで研修やハンズオンセッションを実施し、Agent Modeのフローに慣れる時間を確保することが効果的でしょう。移行初期は意図しない変更が混入するリスクがあるため、コードレビューを通常より丁寧に行う運用も推奨されます。

1.117に留まる選択肢と1.118へ移行する判断基準の比較

1.117に留まり続ける選択肢と、1.118へ移行する選択肢を比較すると、それぞれにメリットとデメリットが存在します。1.117に留まるメリットは、安定性が確認されたバージョンで業務を継続できる点と、新機能のキャッチアップ負荷が発生しない点でしょう。一方デメリットとして、1.118で導入されたトークン効率化施策の恩恵を受けられないため、6月1日以降のCopilot従量課金時代にコスト面で不利な状況に置かれます。

1.118へ移行するメリットは、トークン効率化、リモート制御、コードベース検索強化、TypeScript 7対応など、業務の生産性向上に直結する複数の機能を一気に取り込める点となります。デメリットとしては、新機能の検証や運用ルールの再整備が必要であり、移行直後に若干の混乱が起こる可能性が挙げられるでしょう。判断基準としては、Copilotを業務で多用しているチームは1.118への早期移行が合理的で、Copilot利用が限定的なチームは1.117で様子見しても影響が小さいと整理できます。組織のコスト管理方針と作業の性質を踏まえた選択が求められます。