はじめに
本記事は「Context Engineering 完全入門」シリーズの補章 A です。
VS Code 1.109 では、本編シリーズで扱ってきた Context Engineering の概念が、Microsoft の公式実装として多数リリースされました。Memory tool の正式 preview、/plan コマンド、runSubagent 並列実行など、重要な機能追加が行われています。
本補章の目的は、これらの機能を単に紹介することではなく、「本編で扱った設計パターンが実際の業界標準ツールでどのように実装されているか」を検証すること です。VS Code Copilot Chat は個人利用のコーディング支援ツールですが、その設計判断には業務系エージェント開発者が学ぶべき知見が多く含まれています。本記事では各機能の概要と、本編記事との対応関係、そして業務系システムへの適用時の考慮点について解説します。
前回：第 8 回 Skills & AGENTS.md
次回：補章 B Claude Code Task Tools V2 移行の教訓📌 補章 A:2026 年 2 月にリリースされた VS Code 1.109 で正式追加された機能の網羅的解析です。本編記事の知見を踏まえて、最新機能の意味と実装上の注意点を解説します。
🗺️ 単独でも読めます:本編未読でも、VS Code 1.109 のアップデートサマリとして読めます。
📝 本記事は、生成 AI で作成した草案をベースに、筆者が加筆・修正し、技術的な正確性を確認した上で公開しています。
📝 本記事の要点
- 問題: 2026/2 リリースの VS Code 1.109 で何が変わったか、本編記事の知見はどう活きるかを体系的に把握したい
- 解決: Memory tool、/plan、runSubagent 並列実行、manage_todo_list など 8 つの新機能 を本編記事と対応付けて解析
- 業務系への示唆: VS Code 1.109 の各機能 → 本編どの記事に対応するか、業務系エージェントで何を参考にすべきか / 何をそのまま使うべきでないかをマトリクスで提示
VS Code Copilot Chat の最新動向をキャッチアップしたい方は本補章だけでも実用価値があります。
🎯 本記事の対象者
- VS Code 1.109 の Memory tool が「正式 preview」になったと聞いた
-
/planコマンドやrunSubagent並列実行を試したい - 本編記事の知見が最新機能でどう活きるか知りたい
- 業界標準ツールの実装から業務系エージェント設計への示唆を得たい
- VS Code Copilot Chat の最新動向を体系的に把握したい
1. リリース概要
なぜ VS Code 1.109 が Context Engineering として重要か
VS Code 1.109 は、本編シリーズで解説してきた 「動的性と統制性のバランス」 という設計哲学が、業界標準ツールとして実装された代表的なリリースです。特に:
- Memory tool の正式 preview: 第 6 回で扱った 3 スコープ設計が業界標準として公式化
-
/planコマンド +plan.md自動書き出し: 第 7 回の Plan Persistence 対策の一種 -
runSubagent並列実行: 第 5 回のサブエージェント設計が並列処理まで進化
これらは、Anthropic Claude Code や OpenAI Codex CLI の設計を Microsoft が独自にアレンジして実装したものです。本編で解説した設計パターンが「特定ベンダーの主張」ではなく業界標準であることが、この 1.109 リリースでほぼ確定しました。
VS Code 1.109(2026 年 2 月 4 日リリース)の主要追加
本編記事との対応
以下の表は、VS Code 1.109 の各機能が本編のどの記事に対応するかを示しています。この対応関係は、「本編の知見が実際の業界標準ツールでどう実装されているか」を確認する手がかり となります。
| VS Code 1.109 機能 | 対応する本編記事 | 業務系での適用可否 |
|---|---|---|
manage_todo_list ツール |
第 7 回(TODO ツール) | ○(要拡張) |
| Memory tool(3 スコープ) | 第 6 回(Memory + 自己更新) | ○(要テナント分離) |
/plan コマンド + plan.md
|
第 6 回(Session Memory) | △(監査要件で不足) |
runSubagent 並列実行 |
第 5 回(サブエージェント分離) | ◎ |
| Chat Debug View | 第 2 回(ツール定義の確認) | ◎ |
grep_search 最適化 |
第 2 回(ツール設計) | ◎ |
| MCP truncation バグ | 第 3 回(結果ハンドリング) | ⚠️(参考事例) |
| モデル能力検出 Compaction | 第 4 回(履歴圧縮) | ◎ |
「業務系での適用可否」列は、そのまま使えるか、拡張が必要か、参考程度に留めるべきかを示しています。詳細は各節で解説します。
2. Memory tool 正式 preview
本節の位置付け
本編第 6 回では、VS Code 1.109 の Memory tool を参考にして ScopedMemoryProvider を C# / Microsoft Agent Framework (MAF) で実装しました。本節では、その参考元である VS Code Memory tool の実装詳細 を解説し、業務系エージェントで再現する際の注意点を示します。
設定で有効化
// settings.json
{
"github.copilot.chat.tools.memory.enabled": true
}
デフォルト有効。明示的な opt-out が必要です。業務系 SaaS でこの機能を組み込む場合は、テナントごとに有効/無効を制御する必要があります(第 6 回のマルチテナント設計を参照)。
3 スコープの詳細
| スコープ | パス | 永続性 | 自動ロード |
|---|---|---|---|
| User | ~/memories/ |
永続(全 workspace 共有) | 先頭 200 行 |
| Repository | ~/memories/repo/<workspace-id>/ |
永続(workspace 限定) | 全文 |
| Session | ~/memories/session/<session-id>/ |
会話終了で削除 | 全文 |
第 6 回で解説した 共有性・永続性・分離性の 3 軸評価 に照らすと、この設計は業界最先端のバランスを実現しています。個人のコーディング支援ではそのまま使えますが、業務系では以下の拡張が必要です:
-
User Memory: 顧客テナント別に分離(
~/memories/tenant/<tenant-id>/user/) - Repository Memory: 監査ログ + PII マスキング
- Session Memory: TTL による自動削除(GDPR / 個人情報保護法対応)
Chat: Show Memory Files コマンド
Cmd+Shift+P から Chat: Show Memory Files を実行すると、Memory ファイルの一覧を確認・編集できます。エージェントが書いた内容を人間がレビューする運用が可能で、これは第 6 回で扱った 「提案ファイル方式」の思想と一致 しています。
業務系エージェントでも、エージェントの学習内容を人間がレビューできる導線を用意すること が、統制性を担保する上で重要です。VS Code 1.109 のこの機能は、そのままの形で業務系 SaaS に取り入れられます。
Microsoft Agent Framework (MAF) への移植観点
本編第 6 回で示した ScopedMemoryProvider は VS Code 1.109 の Memory tool 仕様を C# / MAF で再現したものです。
// User Memory(先頭 200 行 — VS Code 流)
var userContent = ReadMemoryFile(userMemPath, _userHeadLines);
// Repository Memory(全文)
var repoContent = ReadMemoryFile(repoMemPath);
// Session Memory(plan.md など)
foreach (var sf in Directory.GetFiles(_sessionDir, "*.md"))
{
var content = ReadMemoryFile(sf);
}
業務系ではこの実装をそのまま使うのではなく、Cosmos DB / Blob Storage への永続化と、テナント認証・認可の仕組みを追加する必要があります(補章 C で詳述予定)。
3. /plan コマンドと Plan agent
本節の位置付け
本節では、VS Code 1.109 で追加された /plan コマンドが 第 7 回の Plan Persistence 対策の一種 として位置付けられることを解説します。ただし、Session Memory として破棄される設計判断には、業務系での適用時に注意が必要な点があります。
動作仕様
VS Code 公式ドキュメント「Planning with agents in VS Code」より(訳):
"Plan agent は自身の実装計画を、セッションメモリファイル(
/memories/session/plan.md)へ自動的に保存します。"
plan.md の典型例
# Implementation Plan: User Authentication
## Goal
Implement OAuth 2.0 / OIDC authentication using Microsoft Entra ID.
## Steps
### Phase 1: Backend Setup
- [ ] Add Microsoft.Identity.Web NuGet package
- [ ] Configure Entra ID app registration
- [ ] Add JWT validation middleware
### Phase 2: Frontend Integration
- [ ] Add MSAL.js to React app
- [ ] Implement login/logout flow
## Risks
- Entra ID テナント設定の権限
- 既存セッション管理との衝突
重要:Session Memory として破棄される
会話終了で plan.md も削除されます。これは第 6 回で解説した Session Memory の仕様通りですが、業務系エージェントでは注意が必要です。
個人利用のコーディング支援では、次の対話で新しい計画を立て直すため破棄が合理的です。しかし 業務系では以下の要件で問題 となります:
- 監査要件: 「エージェントがどのような計画を立てて実行したか」を記録する必要がある
- 長時間タスク: 複数セッションにまたがる作業では計画の再作成コストが高い
- チーム共有: エージェントの計画をチームメンバーに共有したい場合
永続的な進捗管理には PROGRESS.md(Git 管理)を別途用意 することが必要です。第 6 回で示した 4 分類(AGENTS.md / PROGRESS.md / Session Memory / TODO)の役割分担を参照してください。
業務系エージェントでは、/plan コマンドの思想は取り入れつつ、「計画は Session Memory + PROGRESS.md の 2 箇所に書き出す」 という拡張が推奨されます。
4. manage_todo_list ツール組み込み
本節の位置付け
本節では、VS Code Copilot Chat の manage_todo_list が なぜ意図的にシンプルなのか を解説し、Claude Code V2 の 4 ツール構成との設計思想の違いを対比します。この違いは、業務系エージェントで TODO ツールを設計する際の判断軸となります。
仕様概要
microsoft/vscode-copilot-chat の manageTodoListTool.tsx は わずか 31 行 / 1.42 KB のシンプルな実装です。
-
read操作で現在の TODO 一覧取得 -
write操作で 完全置換(部分更新不可) - セッション内のみ保持(永続化なし)
Claude Code V2 との比較
| VS Code Copilot Chat | Claude Code V2 | |
|---|---|---|
| ツール数 | 1(manage_todo_list) |
4(TaskCreate/Update/Get/List) |
| 操作 | 完全置換のみ | 個別更新可能 |
| 永続性 | セッション内 | ファイル永続化 |
| 想定用途 | シンプルなタスク管理 | 長時間タスクの詳細管理 |
設計思想の対比
VS Code Copilot Chat の manage_todo_list は意図的にシンプルです。「コア機能は薄く、エコシステムで拡張」という Microsoft の思想と整合しています。一方、Claude Code V2 は「エージェント自身が細かい進捗管理を行う」という思想で、4 ツール + ファイル永続化という充実した機能を提供しています。
業務系エージェントではどちらを参考にすべきか は、要件によって判断が必要です:
- シンプルなタスク管理で十分: VS Code 流(1 ツール + 完全置換)
- 長時間タスクや複数セッションにまたがる作業: Claude Code V2 流(4 ツール + 永続化)
- Plan Persistence 問題への完全対応: 第 7 回で提示した MAF 実装(4 ツール + Recitation)
詳細は 補章 B で扱いますが、業務系では「タスクの複雑度に応じた選択的利用」という第 7 回の教訓に従うことが重要です。
5. runSubagent 並列実行
本節の位置付け
本節では、2026 年 1 月のアップデートで追加された runSubagent の並列実行機能が、第 5 回のサブエージェント設計を実務レベルで加速する重要な進化 であることを解説します。業務系エージェントでも、独立性の高いタスクは並列化することで大幅なコスト削減とレイテンシ改善が可能です。
2026 年 1 月のアップデート
複数のサブエージェント呼び出しを 並列処理 できるようになりました。独立したリサーチタスクを並列実行すれば、約 3 倍の高速化 が見込めます(3 つのサブエージェントを並列実行した場合の理論値)。
業務系での適用時の注意
第 5 回でも触れましたが、並列実行できるのは「独立性の高いタスク」に限られます。以下のケースでは直列実行が必要です:
- A の結果を B が使う場合: 依存関係があるタスクは並列化できない
- 同じリソースを操作する場合: DB 更新や外部 API 呼び出しで競合が発生する可能性
- 監査要件がある場合: 実行順序を明確に記録する必要がある業務では直列が推奨
Microsoft Agent Framework (MAF) での再現(第 5 回より)
第 5 回で示した RunSubAgentsParallelAsync は、この VS Code の並列実行機能を C# の慣用パターン(Task.WhenAll)で再現したものです。
public async Task<string> RunSubAgentsParallelAsync(
SubAgentCall[] calls,
CancellationToken cancellationToken = default)
{
var tasks = calls.Select(c => _runner.RunSubAgentV3Async(
c.AgentName, c.TaskPrompt, c.ReturnSpec, c.AdditionalTools, null, cancellationToken
)).ToArray();
var results = await Task.WhenAll(tasks);
// ...
}
業務系での実装では、並列度の上限管理(同時実行数を制限してリソース枯渇を防ぐ)や、エラーハンドリング(1 つのサブエージェントが失敗した場合の全体の扱い)を追加する必要があります。
6. モデル能力検出による Compaction 分岐
本節の位置付け
本節では、VS Code Copilot Chat が採用している モデルごとに最適な Compaction 手法を選ぶハイブリッド設計 が、第 4 回で解説した設計思想と完全に一致していることを確認します。この設計は、業務系エージェントでのマルチベンダー対応の参考になります。
VS Code の実装アプローチ
VS Code Copilot Chat は モデルごとに最適な Compaction 手法を選ぶハイブリッド設計 を採用しています。第 4 回で詳述した通り、chatModelCapabilities.ts で supported_endpoints を検出し、以下のように分岐します:
- Responses API 対応(GPT-5 系): OpenAI ネイティブ Compaction(パターン A)
- Messages API 対応(Claude 系): Anthropic ネイティブ Compaction(パターン A)
- ChatCompletions のみ(レガシー): 自前要約(パターン C)
設定による制御
github.copilot.chat.summarizeAgentConversationHistory.enabled 設定は パターン C(自前要約)の有効/無効を制御 するもので、ベンダー API ネイティブが使えるモデルでは影響が限定的です。
業務系への適用
業務系エージェントでも、「利用可能なモデルに応じて最適な Compaction 手法を選ぶ」 という設計は有効です。第 4 回で示した MAF 実装(ModelCapabilityDetector)は、この VS Code の設計思想を C# / MAF で再現したものです。特にマルチベンダー環境や、顧客が指定したモデルを利用する業務系 SaaS では、この分岐設計が長期運用の鍵となります。
7. Chat Debug View 拡張
本節の位置付け
本節では、VS Code 1.109 で拡張された Chat: Show Chat Debug View が、業務系エージェント開発者にとって「隠れた至宝」とも言える重要機能 であることを解説します。ツールの description が LLM にどう見えているかを確認できる仕組みは、実装時の試行錯誤を大幅に削減します。
Chat: Show Chat Debug View コマンド
LLM への実際のリクエスト/レスポンスを表示します。確認できる情報:
なぜ業務系開発者にとって重要か
ツールの description が LLM にどう見えているかを確認できる貴重な手段です。第 2 回で「description は LLM への手紙」と表現した内容を、実際の現場で確認できます。
業務系エージェント開発では、以下の場面で特に有用です:
- ツール選択の精度向上: LLM がなぜ意図したツールを呼ばなかったかを分析
-
プロンプトインジェクション対策の検証: 第 5 回の
immutable_constraintsが正しく末尾に連結されているかを確認 - トークン消費の実測: どの System Prompt / Skill / Tool 定義が context を占めているかを可視化
- プロンプトキャッシング効果の確認: 第 2 回で扱った固定プレフィックスが実際にキャッシュヒットしているかを検証
MAF で業務系エージェントを開発する際も、同等の Debug View を独自実装することを強く推奨 します。第 2 回・第 5 回で扱った設計判断の効果を、実装後に定量的に検証できるためです。
8. 既知の問題と対処
本節の位置付け
本節では、VS Code 1.109 で確認されている 3 つの Issue を紹介します。これらは 業務系エージェント開発の「反面教師」として非常に価値のある事例 です。特に Issue #311068 と #309747 は、本編で扱った設計原則を守らないと本番運用でどのような問題が発生するかを具体的に示しています。
Issue #311068:MCP truncation の復元 URI バグ
GitHub MCP の get_file_contents で 50KB–999KB ファイルを取得した場合、復元 URI を read_file に渡すと 「File is outside of the workspace」エラー になり、LLM が無限ループに陥ります。
対処法(第 3 回参照):動かない復元手段を提示しない。代わりに ページネーション or 専用検索ツール を使います。
業務系開発者への教訓: 復元 URI などの回復パスを提供する場合は、必ずリリース前に E2E テストで動作確認する ことが必須です。「設計思想は正しいが実装が追いついていない」典型例であり、我々が独自実装する際に絶対に避けるべきアンチパターンです。
Issue #309747:read_file メタデータ削除リグレッション
2026 年 2 月のコミット 7dc4b8e で削除されたメタデータヘッダにより、Anthropic 系モデルが「200 行で読み切った」と誤認するリグレッションが発生しました。
対処法(第 2 回参照):独自実装では 必ずメタデータを返す。
業務系開発者への教訓: 第 2 回のベストプラクティス 2「メタデータの完全性」が なぜ最重要と位置付けられるか をこの事案が実証しました。業界最先端のツールでも、メタデータを削除すると重大なリグレッションが発生します。業務系エージェントの read_file 相当機能では、部分読み込み時のメタデータヘッダを絶対に省略してはいけません。
Issue #322773:grep_search 最適化(解決済み)
本番 A/B テストで -55% トークン削減 を実証。第 2 回で扱った最大剰余法による比例配分が実際に効果を出した事例です。
業務系開発者への教訓: 第 2 回のベストプラクティス 4「件数キャップ時の選択基準」は、本番運用でこれだけ大きなコスト削減効果がある ことをこの事案が実証しました。業務系エージェントで検索系ツールを実装する際は、単純な FIFO ではなく最大剰余法による比例配分を採用することで、大幅なトークン削減が期待できます。
9. VS Code 1.109 から学ぶ 5 つの教訓
本節では、VS Code 1.109 の実装から抽出した 業務系エージェント設計への 5 つの教訓 を整理します。いずれも本編で解説した設計原則を、業界標準ツールの実例で裏付けるものです。
| # | 教訓 | 業務系エージェントへの適用示唆 |
|---|---|---|
| 1 | シンプルなツールは強い |
manage_todo_list の 31 行実装が示すように、コア機能を薄く保つ。業務系でも「機能の詰め込み」を避け、責務を明確に分離することで長期保守性が向上する |
| 2 | 本番テレメトリが設計を駆動する |
grep_search 最適化(-55% 削減)のように、本番ユーザーの行動データから設計を改善する。業務系でも A/B テスト用の計測基盤を最初から組み込むことが重要 |
| 3 | モデルごとに最適化を分岐させる | 「単一実装で全モデル対応」は時代遅れ。第 4 回のハイブリッド設計のように、モデル能力に応じた分岐を実装レベルで用意する |
| 4 | 既知バグも公開して直す | Issue #311068 のような動かない機能を公開する誠実さ。業務系でも「不具合の透明性」がユーザー信頼を高める重要要素 |
| 5 | 宣言的設定を充実させる | ユーザーが細かく挙動を制御できることが重要。業務系でも、テナントごとに .enabled フラグや閾値を設定できる設計が長期運用の鍵 |
おわりに
本補章では VS Code 1.109 の主要機能を概観し、本編シリーズとの対応関係を整理しました。VS Code Copilot Chat はコーディング Agent 向けの「製品」ですが、その設計思想を業務系 Agent に持ち込む際のブループリントとして大変参考になります。
特に重要な発見は、本編で解説した設計パターンが、Microsoft の業界標準ツールで実際に採用されている ことです。第 6 回の 3 スコープ Memory、第 5 回のサブエージェント並列実行、第 4 回のモデル能力検出による分岐など、いずれも VS Code 1.109 で実装が確認できます。
一方で、そのまま業務系に転用できない部分 もあります(Session Memory の破棄、テナント分離の欠如、マルチテナント対応の不足など)。これらは補章 C「業界研究の業務系翻訳ガイド」で、業務系エージェントへの適用戦略として整理します。
次の補章 B では、Claude Code の V1 → V2 大改修の経緯と教訓について解説します。VS Code Copilot Chat の manage_todo_list(1 ツール、完全置換)と対照的な設計判断が、Claude Code の 4 ツール構成 + ファイル永続化にどう反映されているかを、V1 の課題と V2 の解決策の両面から詳しく解説します。
参考文献
VS Code 1.109 公式情報
- VS Code Updates「January 2026 (version 1.109)」(リリース日 2026/2/4、最新 1.109.5)
- VS Code Docs「Memory in VS Code agents」
- VS Code Docs「Planning with agents in VS Code」
- VS Code Docs「Debug chat interactions」
-
VS Code Docs「Custom agents in VS Code」
- 補足: サブエージェント関連は VS Code Docs「Subagents in Visual Studio Code」 も参照。
ソース解析
- microsoft/vscode-copilot-chat リポジトリ(2026/5/20 にアーカイブ、現在は
microsoft/vscodeのextensions/copilot/に統合) manageTodoListTool.tsx(31 行 / 1.42KB の最小実装)chatModelCapabilities.ts(モデル能力検出)- DeepWiki「microsoft/vscode-copilot-chat」
VS Code Issue Tracker
- VS Code Issue #311068「MCP tool results for large files are silently truncated…」
- VS Code Issue #309747「read_file tool regression: removing line count metadata…」
- VS Code Issue #322773「[AHP/CLI:COGS] Grep Search Tool Output Optimization」
- VS Code Issue #270381「Raise or make configurable the hard 200-result cap in Copilot's grep_search」
Microsoft 公式 Blog
- Visual Studio Blog「Copilot Memories」(Jessie Houghton, 2026/1/15)
-
VS Code Blog「Your Home for Multi-Agent Development」(VS Code Team, 2026/2/5)
- 補足: VS Code チームの最新ブログ一覧は Microsoft DevBlogs「VS Code Blog」 を参照。
日本語コミュニティ
-
のぶ3「『会話履歴を要約しています』を即解決!VS Code の GitHub Copilot の
summarizeAgentConversationHistoryを無効化すればOK」(note.com, 2025/11/29) - shinkawa「VS Code + GitHub Copilot で並列タスクが快適になったので、やり方を整理する」(Zenn, 2026/3/2)