こんにちは、Copilot を並走させて画面ごと止めてしまったアーキテクトのやまぱん！です 😅
補足コメントや質問、いいね、拡散、ぜひお願いします 🥺！
間違っていたら 優しく 教えてください！
TL;DR
- この調査は進行中です。根本原因はまだ特定できていません。 続報が出たら追記または続編を書きます。
- 重い GitHub Copilot Agent 作業を 2 つの VS Code ウィンドウで並走させると、私の Windows 環境ではマウスやウィンドウ切り替えを含む画面描画が著しく重くなりました。
- ログから、OS 全体の CPU / RAM / disk、GPU / DWM、Scout、Git status 単体は主因として後退しました。優先調査対象は VS Code 内部の UI 処理経路と、その上で動く長い Chat・tool output の処理です。
-
chat.agent.maxRequests=1000は直接原因とする根拠が弱いです。現在は100にして、長い Agent ターンへ早めに続行確認を入れるガードレールとして様子を見ています。
読者が最初に試せる切り分けは、重い Agent 作業の並走を止め、1 本ずつ実行して症状が変わるか確認することです。この記事を根拠に、maxRequests、履歴要約、debug logging、watcher の除外設定を一括変更しないでください。WPR は私自身の次回調査計画であり、全読者への必須手順ではありません。
現時点の仮説と未確認範囲
chat.agent.maxRequests=1000 が原因だったとは言えません。現行実装では Agent の並列度、CPU 使用率、画面更新頻度を直接変えないためです。現在は 100 に下げていますが、原因への修正ではなく、長い Agent ターンへ早めに続行確認を入れる運用上のガードレールです。
WPR では Code main process の継続的な CPU 活動を観測しました。ただし、それが UI 遅延を引き起こしたか、UI thread・renderer・IPC のどこで待ちが発生したかは未確定です。次に stack 付きの記録で確認する優先調査対象として、VS Code 内部の UI 処理経路を残しています。
今回の調査では、GitHub Copilot CLI に切り分け案を考えさせ、PowerShell の収集スクリプトも作らせながらログを分析しました。最後に /share gist でセッション全体を GitHub Gist に保存し、その記録を検索・再読しながらこの記事を書いています。これは私自身が実行した手順です。Gist の URL と生ログは記事には載せず、公開できる観測結果だけに絞ります。
この記事の数値は、診断ワークスペースに保存した各 Run のログ、分析ノート、Copilot CLI のセッション記録を突き合わせた結果です。生の ETL や環境固有情報は公開していないため、第三者が同じ数値を再計算できる公開データではありません。そこで、測定区間・収集間隔・別 Run 間を直接比較できない点も本文に併記します。
起きたこと: 画面描画が止まるほど重い
別々の VS Code ウィンドウで、サブエージェントや PowerShell を使う重い GitHub Copilot Agent 作業を同時に進めていました。私の環境では、開始からおよそ 1 分を過ぎたあたりで次の症状が出ました。
- マウスポインターの移動が重い
- アクティブウィンドウの切り替えが遅い
- VS Code だけでなく、端末全体の操作がもたつく
この「約 1 分」は今回の条件での観測時刻です。すべてのワークスペース、モデル、Agent 作業に共通する閾値ではありません。
最初は「CPU かメモリが埋まったのかな」と思いました。ところが、ログを重ねるほど単純な資源不足では説明できなくなりました。
先に残った被疑箇所
詳細な調査過程へ入る前に、現時点の結論を並べます。設定値と実際に動いている処理は分けて評価しています。
| 疑い | 現在の強さ | 根拠と限界 |
|---|---|---|
| VS Code 内部の UI 処理経路 | 次に stack 付きで確認する対象 | WPR で main process の継続的な CPU 活動を観測。ただし、その活動が UI 遅延を起こしたか、renderer / IPC を含む具体的な詰まり箇所と hot stack は未確認 |
| 長い Chat 状態、tool output、terminal 取り込み | 中程度 | 類似 Issue があり、重い Agent 作業と条件が合う。今回と同じ stack は未確認 |
| Extension Host の context / token 処理 | 中程度 | profile 付きの類似 Issue がある。今回の Extension Host profile は未取得 |
| workspace 探索 / watcher / SCM | 弱い・一部反証あり | 大規模 workspace だが、持続する rg 高負荷や遅い Git status は未確認 |
| GPU / DWM 飽和 | 弱い・反証あり | 症状区間の対象 GPU は低く、GPU Hardware Queue の持続的な詰まりも未検出 |
| Defender / EDR / GSA | 未観測 | 原因にも無関係とも言えないが、今回のログでは相関を確認していない |
4 回の別 Run で後退した候補、次に stack 付きで確認する対象、maxRequests=100 の位置付けを 1 枚にまとめました。
GitHub Copilot CLI と一緒に診断環境を作った
今回、私が最初から PowerShell の診断スクリプトを書いたわけではありません。症状、再現条件、手元にあった診断資材を GitHub Copilot CLI へ渡し、まず「再現前に何を準備すべきか」を考えてもらいました。
最初に作ったのは、トラブルシューティング専用の作業フォルダーです。元の診断資材を変更せずに保管し、次のものを分けました。
- 原本を置く場所
- 実際に変更する診断ツールの作業コピー
- 再現手順と判断基準
- 取得したログ
- 分析結果と未確定事項
ログを取るだけなら、その場限りの PowerShell でもできます。しかし、再現を何度か試すうちに「どの試行のログか分からない」「症状が出た時刻と数字が結び付かない」「収集スクリプト自身が負荷を増やす」という問題が出ます。そこで Copilot CLI に、診断そのものを小さなプロジェクトとして管理させました。
最初のラバーダックで計画の穴が見つかった
初期計画をラバーダックでレビューすると、再現前に直すべき点が出てきました。
- Scout のプロセス名が収集対象に入っていない可能性がある
- 固定 10 分のトレースでは、発症前に収集が終わる可能性がある
- 実行 ID がなく、どの設定・症状・ログが同じ試行か追えない
- 本番の再現時にカウンター取得自体が失敗する恐れがある
この指摘を受けて、Copilot CLI にプリフライトと実行単位の識別を追加させました。再現前の短時間テストでは、システム行 2、Scout 関連行 8、収集失敗 0 を確認してから本番へ進んでいます。
最初から重い WPR を回さなかったのも、この計画で決めたことです。まず軽いカウンターで大きな資源枯渇を探し、それで説明できなければ取得範囲を狭める。それでも足りない場合だけ WPR を使う順番にしました。
対話しながらスクリプトを増やした
提供済みの診断資材を作業コピーへ分離したうえで、Copilot CLI に追加・改善させた主なスクリプトは次のとおりです。
| スクリプト | 役割 | 追加した理由 |
|---|---|---|
Start-ReproductionPreflight.ps1 |
短時間の snapshot と trace を実行し、収集可否を確認 | 本番再現後に「ログが取れていなかった」を避ける |
Start-ReproductionTrace.ps1 |
CPU、memory、disk、paging、関連プロセスを一定間隔で保存 | 最初に OS 全体の資源枯渇を確認する |
Start-UiResponsivenessCapture.ps1 |
Code、WebView、DWM、Scout の CPU / GPU を集中取得 | 全体負荷では説明できなかった UI 遅延を追う |
Mark-SymptomStart.ps1 / Mark-SymptomEnd.ps1
|
症状の開始・終了を 1 行の時刻として記録 | 体感とログを同じ時間軸へ載せる |
Capture-VSCodeRuntimeSummary.ps1 |
VS Code のプロセス種別ごとの CPU / memory を匿名化して集計 | 生のコマンドラインやワークスペース名を残さず、main / renderer / Extension Host を見る |
コードを生成して終わりにはせず、各スクリプトについて構文確認または対象に応じた短時間スモークテストと出力確認を Copilot CLI に実行させました。失敗したら、そのログを読ませて同じスクリプトを修正しています。
5 段階で切り分けた結果
ここまでの取得結果は、同じ 1 回の再現を段階的に測ったものではありません。公開用に実際の RunId を一般化すると、次の 4 試行です。
| 試行 | 症状マーカー | 収集方法 | 主な用途 |
|---|---|---|---|
| Run A | 後から体感時刻を確認 | 5 秒の待機を設定した軽量トレース | OS 全体の CPU / memory / disk と関連プロセスを見る |
| Run B | 症状なし | 初期版の UI/GPU キャプチャ | 無症状時との比較、収集ツール自身の負荷を発見する |
| Run C |
SymptomStart あり |
軽量化後の対象プロセス別 UI/GPU キャプチャ | 症状区間の Code / WebView / DWM / Scout を見る |
| Run D | 厳密なマーカー区間あり | WPR / ETW | Code のプロセス別 CPU、scheduler、GPU queue を見る |
試行をまたいだ数字は、そのまま性能差として比較していません。各試行で「その原因候補が症状全体を説明できるか」を確認しています。
1. 実効約 5.9 秒間隔の軽量トレース（Run A）
最初の再現では、6 分 41 秒にわたって 69 サンプルを取得しました。
- システム CPU: 平均 約 21%、最大 約 55%
- 空きメモリ: 最低でも 約 25 GB
- commit（仮想メモリの確保量）使用率: 約 48%
- disk I/O / paging: 持続的な飽和なし
- Scout: 持続的な高負荷なし
5 秒の待機を設定した収集ですが、取得処理を含む実効間隔は約 5.9 秒でした。これで「OS 全体の CPU や RAM が埋まり続けた」という見方は弱まりましたが、短いスパイクや UI スレッドの停止は見逃します。
このトレースには WebView2 の大きな単発スパイクもありました。私は一瞬「WebView が原因では？」と思いましたが、ラバーダックは、スパイクが症状開始より後であり、開始後ずっと続いた UI 遅延を 1 回のピークでは説明できないと指摘しました。system CPU と process CPU も収集タイミングが異なるため、同じ時刻の値を単純比較できません。
この指摘で、WebView2 を「主因」から「一時的に悪化させた可能性がある候補」へ戻しました。Copilot CLI で大きな数字を抽出し、別モデルのラバーダックに時系列と持続時間を反証させたことで、観測事実と推測を分けやすくなりました。
2. UI / GPU へ絞った再現（Run C）
次は症状開始後の約 71 秒、34 サンプルを取りました。
- システム CPU: 平均 約 23%
- Code / WebView の対象 GPU: 症状区間では 0%
- DWM GPU: 最大 約 3%
- Scout: 引き続き低負荷
DWM は Windows のデスクトップ描画を合成するプロセスです。この区間では GPU / DWM の飽和が見えず、描画の重さを GPU 使用率だけで説明するのは無理がありました。
Run C の「対象 GPU 0%」は、プロセスを絞り、1 秒の待機を設定したカウンター要約です。取得処理を含む実効間隔は約 2.15 秒で、その間の短い GPU スパイクは否定できません。後述する Run D の「GPU 実行率 0.46%」は ETW の GPU 実行イベントから求めた別の指標であり、同じ測定値の前後比較ではありません。
初回ログでは「開始から約 1 分後に重くなった」という記憶しかなく、6 分ぶんの数字から都合のよいピークを拾う危険がありました。そこで SymptomStart と SymptomEnd を markers.csv へ 1 行ずつ記録するスクリプトを追加しています。Run C では SymptomStart からキャプチャ終了までの約 71 秒を症状区間として扱いました。
このマーカーがあったことで、症状中の GPU 使用率が低いことと、症状なしでも CPU が高い Run B を別の条件として扱えました。
3. 症状なしでも CPU は高かった（Run B）
別の試行では、CPU が平均 約 48%、一時 100% まで上がったのに、画面は重くなりませんでした。このログは収集側の負荷も混ざっているため CPU 値の直接比較には使えませんが、少なくとも「CPU が高い = 今回の UI 遅延」とは言えません。
調べると、初期版は Windows の GPU Engine カウンターを毎回全件列挙していました。全件取得は 1,171 行で約 3.4 秒、対象となる 91 PID だけへ絞ると 218 行で約 1.2 秒でした。さらにプロセス単位の要約へ変更し、10 秒のスモークテストでは 6 サンプル、GPU 要約 96 行、全体約 74 KB に収めています。
性能調査では、収集処理自身の負荷も交絡要因になります。Copilot CLI にスクリプトを書かせるだけでなく、短時間のスモークテストと出力サイズ確認まで実行させ、観測方法を軽量化しました。
4. WPR では Code main process が継続して動いていた（Run D）
最後に Windows Performance Recorder（WPR）でトレースを取りました。ETL 全体は 101.30 秒、Trigger から SymptomEnd までが約 91 秒、厳密な症状マーカー区間は 20.36 秒です。WPR は Windows の CPU、スケジューラー、描画などを時系列で追うための公式ツールです。マーカー前も体感上は重い状態でした。
マーカー区間では Code の main process が約 0.90 論理コア分を継続使用し、renderer や描画関連プロセスも同時に動いていました。マーカー前の約 71 秒でも Code 全体の活動は続いており、最後の 20 秒だけの一時的な山ではありませんでした。一方で、根本原因になる関数 stack までは特定していません。
さらに既存の ETL を GPUView と DxgKrnl イベントで確認しました。GPUView では症状マーカーの 92% と重なる 20.64 秒の GPU 実行率が約 0.46% でした。DxgKrnl ではマーカー区間 20.36 秒全体の DMA lifecycle 315 件を集計し、送信から完了までが中央値 0.19 ms、p95 1.72 ms、最大 2.33 ms でした。この区間では、GPU Hardware Queue が持続的に詰まった形跡はありませんでした。
WPR で確認できたのは Code main process の継続的な CPU 活動です。その活動が UI 遅延を引き起こしたか、main process、各 window の renderer、Extension Host、プロセス間通信（IPC）のどこで待ち時間が増えたのかは未確定です。
5. ワークスペースと Git も確認した
2 つのワークスペースは、どちらも未コミット変更がある状態でした。大きい方は約 4.1 万ファイルあり、files.watcherExclude と search.exclude は未設定でした。
ただし、Git の状態取得はそれぞれ約 164 ms と約 91 ms、変更件数は 20 件と 29 件でした。少なくとも git status 単体が数秒間詰まっていたわけではありません。大きい ignored 領域の探索や watcher は短い増幅要因として残りますが、主因の疑いは下がっています。
匿名化した VS Code runtime summary では、ウィンドウごとの renderer、Extension Host、file watcher が動いている構成まで確認しました。ただし、自然再発した瞬間の stack ではないため、どのプロセスが UI を止めたかの特定には使っていません。
設定候補と maxRequests=1000
設定では次の 4 点が候補に残っています。ただし、どれも根本原因とする証拠はありません。複数の設定を同時に変えると比較できなくなるため、現在変更しているのは chat.agent.maxRequests だけです。
| 設定 | 疑い | 疑う理由 | 疑いが下がる条件 | 現在の扱い |
|---|---|---|---|---|
chat.agent.maxRequests=1000 |
弱い・間接的 | 1 ターン内で長い Agent 処理を続ける余地が大きい | 症状前に続行確認が出なければ、100 への変更はまだ作用していない |
100 にして単独で様子を見る |
github.copilot.chat.summarizeAgentConversationHistory.enabled=false |
弱い・未検証 | 長い Agent 履歴の処理量に影響する可能性がある | 履歴量や Extension Host profile と症状が相関しない | 今は変更しない |
| Agent debug のファイルログが有効 | 弱い・未検証 | 診断ログの書き込みが追加される | 症状区間で持続的な disk I/O 飽和は未観測。ただし有効・無効の比較は未実施で、短い書き込み待ちは否定できない | 今は変更しない |
files.watcherExclude / search.exclude が未設定 |
弱い・増幅要因候補 | 約 4.1 万ファイルの workspace を監視・探索する余地がある | 症状時の watcher trace や rg に持続負荷がない |
除外設定はまだ追加しない |
設定候補はいずれも原因としての確度が低く、変更を推奨できる段階ではありません。maxRequests は、今回の調査で私が観測目的に単独変更した項目です。現在の 100 は原因修正でも推奨値でもありません。
調査の途中で、VS Code のユーザー設定に次が入っていることを確認しました。
"chat.agent.maxRequests": 1000
chat.agent.maxRequests は、Agent が 1 ターンでユーザー確認を求めるまでに許す request 数の上限です。検証した VS Code 1.128.0 の公開ソースには、次の説明があります。
The maximum number of requests to allow per-turn when using an agent. When the limit is reached, will ask to confirm to continue.
同じ公開ソースでは、通常の VS Code ウィンドウは実験値が配布されていればその値、なければ 50、専用の agentsWindow では 1000 と定義されています。ここで重要なのは、1000 は CPU 使用率や Agent の並列数を直接指定する設定ではないことです。
| 値 | 直接変わるもの | 直接は変わらないもの |
|---|---|---|
chat.agent.maxRequests |
1 ターンで確認前に続けられる request 数 | 同時実行する Agent 数、ツール実行の並列度、CPU 使用率 |
調査時点では、通常の Agent 作業にも 1000 を明示設定していました。長い自律実行には便利ですが、ツール呼び出し、出力、Chat 履歴が 1 ターンに積み上がる余地も大きくなります。
そこで現在は 100 に下げています。100 request に達した時点で続行確認を入れ、そこで停止・整理できる機会を早めるためです。確認後に続行すれば同じターンは続くため、設定だけで処理量が必ず減るわけではありません。
100 は「最適値」でも「今回の UI 遅延を直す値」でもありません。100 request へ達する前に症状が出た場合、1000 と 100 はその発症時点まで同じ動作です。現時点では、続行確認を早める運用値として試しているだけです。
ほかの設定候補は、前の被疑表にまとめたとおりです。現時点では一度に変更せず、maxRequests=100 だけで自然再発の有無を見ます。
類似 Issue から切り分け軸を作る
類似する公開 Issue を探すと、「Copilot が重い」という 1 つの話ではありませんでした。Agent と Chat 状態、Agent が扱うツール出力、ワークスペース側の処理に分けて見ると、次の切り分け軸が見えてきます。
| 層 | 公開 Issue | 今回と重なる観測 | 今回では未確認の点 | 原因扱いしない理由 |
|---|---|---|---|---|
| request 上限 | #256088 | 上限で「Continue to iterate」を挟み、Agent の継続を利用者が制御する設計 | 性能改善との関係 | UI 性能 Issue ではなく、暴走防止と利用者制御の機能 |
| 長い Agent / Chat 状態 | #317319 | 長期 Agent セッション中に Copilot Chat が Extension Host の CPU profile に現れた利用者報告 | 同じ関数、トークン数、Extension Host profile | 最小再現と今回と同じ環境条件は未確認 |
| 長い Chat の描画 | #297349 | 会話が長くなるほどクリック、スクロール、入力が遅くなる利用者報告 | DOM 数、renderer profile、Chat 要素ツリー | DOM が原因という投稿者仮説だけでは足りない |
| Agent の tool output / renderer | #307723 | Autopilot mode の Agent が gh コマンドを実行した際に、VS Code が応答不能になった利用者報告 |
terminal 出力の量、renderer stack、shell integration | 追加情報を求める info-needed の後に close され、修正確認はない |
| Copilot Chat 利用中の UI freeze | #316183 | Copilot Chat 利用中に VS Code 全体が応答不能になった利用者報告 | Windows での同一再現、共有プロセスの挙動 | 追加情報を求める info-needed の後に close され、原因未確定 |
| workspace 探索 | #311736 | custom agent 探索に関連すると報告された rg の CPU スパイク |
症状時の rg、探索対象、実行時間 |
別 Issue の重複として終了し、今回は rg を未観測 |
| file watcher | #305923 | 大規模 repo で特定の watcher 除外パターン評価が遅くなった closed Issue | 現行版の watcher trace、イベント数 | 今回の除外未設定を補強する根拠ではなく、今回の環境との一致も未確認 |
これらは今回の原因を裏付ける証拠ではありません。次にどこを分けて観測するかの地図です。
古い microsoft/vscode-copilot-release の Issue も検索には出てきますが、このリポジトリは現在アーカイブ済みで read-only です。README はフィードバックを microsoft/vscode へ移すよう案内しています。旧 Issue は過去の事例を読むためだけに扱います。
現時点の原因考察
私のログだけで確定したことは「2 本の重い Agent 作業と UI 遅延が同時に起きた」ことです。まだ確定していない部分を含めると、調べる順番は次のようになります。
この図の矢印は原因を示していません。今回の再現で同時に活動し得る経路と、次回に分けて観測したい対象を整理したものです。
特に確認したいのは次の 4 つです。
- Extension Host: Chat 履歴、トークン集計、Agent の状態更新で CPU を使っていないか。
- main process / renderer: Chat の描画、入力、ウィンドウ切り替えが詰まっていないか。
- tool output: 大きい PowerShell、Git、検索、テスト結果を Chat に取り込むときに遅延が増えていないか。
- workspace 処理: 大きい生成物、ローカルプロファイル、Git 管理対象外の領域まで watcher や検索が広がっていないか。
VS Code 公式の Performance Issues ガイドも、Process Explorer、code --status、Extension Host CPU profile、renderer の DevTools profile、shared process profile を分けて採る流れを案内しています。CPU の総量だけで判断しないための、まっとうな診断順序ですね。
100 で様子を見るときの判定条件
設定だけ変えて「軽くなった気がする」で終わらせないため、意図的に何度も再現させるのではなく、普段の作業で自然に再発したときの条件を残します。
| 固定するもの | 見るもの |
|---|---|
| VS Code / GitHub Copilot のバージョン | 執筆時の VS Code は 1.128.0。版をまたいだ比較にしない |
| 2 つのワークスペースとファイル規模 | watcher や検索範囲を変えない |
| Agent の作業内容と同時開始の条件 | request 上限以外の負荷をなるべく揃える |
| UI の判定手順 | 入力、スクロール、ウィンドウ切り替え、マウス移動を同じ順で確認する |
| 採取時間と症状区間 | 遅延の開始・終了時刻と Code / renderer / Extension Host を照合する |
| 続行確認の表示 | 症状前に確認が出なければ、maxRequests=100 はまだ作用していない |
現在の 100 で自然に再現するかを見ます。単発なら「事例」、複数回同じ傾向が出て初めて「再現率」として扱います。
次に自然再発したときは、軽量ログを何種類も取り直しません。症状前から発症後 30〜60 秒まで、CPU stack とスケジューラーを含む WPR を 1 本だけ採り、Code main / renderer / Extension Host の hot stack を見る予定です。
今はやらないこと
原因がまだ VS Code のどの経路か分からない段階で、次の変更はしません。
- Microsoft Defender の除外設定
- GPU ドライバーの変更
- 大きな設定の一括変更
- 監視対象を増やすためだけの常時 ETW / WPR 収集
いずれも副作用が大きく、今のログは主要因として指していません。Defender、GPU driver、描画スタックに一貫した相関が見えてから、隔離した比較環境で検討します。
GitHub Copilot CLI を診断補助として使った
今回あらためて、GitHub Copilot CLI はトラブルシューティングと相性がよいと感じました。端末、ファイル、ログ、スクリプトを同じセッションで扱えるため、調査の流れを途中で切らずに進められます。
私が実際に頼んだ順番は、だいたい次のとおりです。
- 症状と再現条件を説明し、まだ原因を決めずに調査計画を作らせる
- 既存の診断資材を読ませ、原本を変更しない作業コピーを作らせる
- 本番前のプリフライトと短時間スモークテストを作らせる
- 再現時刻を残すマーカーと、必要最小限の収集スクリプトを作らせる
- 症状区間と無症状区間を比較させる
- 大きな数値を見つけても原因へ昇格させず、ラバーダックに反証させる
- 分かったこと、否定できたこと、未確認事項を Markdown へ残させる
最初の依頼では、次のように「原因をまだ決めない」と明示すると進めやすいです。
この症状を再現して原因を切り分けたいです。
いきなり設定変更や除外設定をせず、まず観測計画を作ってください。
収集処理自身の負荷と、ログに残る機密情報も確認してください。
分かったこと、反証されたこと、未確認事項を分けて記録してください。
ログを取った後は、数字を要約させるだけでなく、次の問いも入れると効きます。
このログで原因と言えることは何ですか。
症状の開始から終了までを説明できない単発スパイクは、主因にしないでください。
収集間隔で見逃すものと、収集ツール自身が与える負荷も挙げてください。
追加取得を提案する場合は、既存ログで代替できないか先に確認してください。
GitHub Copilot CLI に任せれば自動的に正しい原因へ到達する、という話ではありません。今回も途中で WebView2、GPU、Git、maxRequests がそれぞれ怪しく見えました。効いたのは、Copilot CLI に作業を続けさせながら、節目でラバーダックへ「この説明で症状の開始と持続を本当に説明できるか」と反証させたことです。
今回のように調査が長くなったら、Copilot CLI の /share gist でセッション全体を Gist に残しておくと、後から時系列を検索し、スクリプトを追加した理由や判断の変化を追えます。この記事も、その Gist を土台にして何度も仮説を修正した過程まで書き戻しました。
ただし、/share gist はセッション全体を共有します。実行前に、ユーザー名、パス、環境変数、トークン、プロンプト、ファイル内容、顧客・組織名、remote URL、ホスト名、コマンド出力を確認します。URL を知る人が閲覧できる Gist を、機密情報の保管場所とはみなしません。今回は Gist 自体を記事からリンクせず、公開可能な観測結果だけを本文へ持ち込みました。
GitHub Copilot CLI は原因を自動特定するものではなく、調査計画、スクリプト作成、ログ整理を補助する道具として使いました。生成されたコマンドは、変更対象、出力先、必要権限、外部送信の有無を人間が確認してから実行します。プリフライト、反証、収集負荷、機密情報確認まで含めて使うことが前提です。
まとめ
今回確認できたのは、重い GitHub Copilot Agent 作業を複数ウィンドウで並走していた際に、OS 全体の持続的な資源飽和を伴わない UI 遅延を観測したことです。並走が原因だったかは、まだ確定していません。
chat.agent.maxRequests を 1000 から 100 に下げたのは、根本原因を直したからではありません。続行確認のチェックポイントを早めるための設定変更です。しばらくこの値で使い、次に同じ症状が出たときは Code main / renderer / Extension Host の stack を 1 回で取りたいと思います。
まだ解決編ではありません。「これが原因だった」が分かったら、設定 100 の結果も含めて続編を書きます。