GitHub Copilotが思うように動かないときの確認点

GitHub Copilotが期待どおりに動かないときは、modelを変更する前に「全体障害」「login・license」「特定file」「promptやinstruction」「network・usage」のどこで止まっているかを切り分けます。まずstatusを見てから、再現するsurfaceと症状を一つずつ記録してください。以下の手順なら原因を決めつけず、設定を壊さずに次の調査先を絞れます。

まず症状を分ける

表は横にスクロールできます

症状	最初に確認する場所	次の一手
IDEもGitHub.comも同時に失敗	GitHub Status、利用中model providerのstatus	障害があれば設定を変えず復旧を待つ
Copilot機能が全部使えない	GitHub account、seat/license、sign-in、organization policy	正しいaccountとCopilot entitlementを確認
特定IDEだけ使えない	extension、IDE version、network/proxy、supported feature	更新後に同じpromptを別surfaceで比較
特定fileだけ候補が出ない	file type、language、Content Exclusion、organization policy	同じdirectoryの非機密fileで差を確認
回答は出るが修正がずれる	context、instruction競合、taskの範囲	対象file・期待結果・testを一つのpromptに書く
途中で止まる・遅い	service status、network、logs、usage制限	error codeと発生時刻を記録してadminへ渡す

1. service全体の障害か確認

突然複数端末でCopilotが使えなくなった場合は、まずGitHub Statusを開き、Copilotと関連model serviceのincidentを確認します。状態がInvestigating / Degraded / Operationalのどれか、開始時刻が自分の症状と重なるかを記録します。障害が出ている間にextensionを再installしたり、account設定をresetしたりすると、復旧後も別の問題を増やします。statusが正常でも、特定model providerだけの障害や地域別network問題は残るので、症状が続けば次の手順へ進みます。

2. 使っているaccountとCopilot seatを確認

Copilot Chatが開かない、inline completionが急に止まった場合、login中のGitHub accountやorganization seatを確認します。会社の複数accountを使う人は、IDEに表示されるavatarとGitHub web側のaccountが一致しているか見ます。organization側でseatが外れた、feature policyがoff、modelが許可されていないケースもあります。

切り分け時は、個人契約と会社seatを切り替えて何度も試すのではなく、管理者が割り当てた利用条件を先に確認します。billing情報やorganization policyは利用者側で変更しないでください。正しいaccountでも動かなければ、次にextensionとsurfaceを特定します。

3. extension・IDE・feature対応を確認

VS Code、Visual Studio、JetBrains等でCopilotを使う場合、IDE本体とCopilot extensionのversion、login状態を記録します。更新後にだけ失敗したか、別IDEでは動くかも手がかりです。すべてのCopilot featureがすべてのIDEで同じように使えるとは限らないため、利用機能の対応表を確認します。

小さな確認は非機密の新規fileで行います。例えば短い関数commentから補完が出るか、Copilot Chatで公開可能な説明文に応答するかを別々に試します。completionが出ないことからChatも使えないと結論づけたり、その逆にChat成功からAgent modeも正常と決めたりしないでください。

4. 一部fileだけ反応しない場合

「別のfileでは動くが、このdirectoryだけ応答がない」場合は、まずfile type、language、repository設定、organizationのContent Exclusionを確認します。GitHub DocsではBusiness / EnterpriseのContent Exclusionによって特定fileをCopilot contextから外せます。一方、対応surfaceやmodeに制約があり、IDEが間接的に渡す情報まで完全に排除できるとは限らない旨も説明されています。

安全な切り分け：

1. 管理者に対象pathがexclude対象か確認する。

2. 同じIDEで、機密でない別fileに同じ種類の操作を行う。

3. 同じ対象fileを別surfaceで試す前に、そのsurfaceのpolicyとdata handlingを確認する。

4. 診断目的で機密fileを別repositoryへcopyしない。

5. 結果を「file種別」「surface」「error」「時刻」に分けて記録する。

これで動く場合はfeature対応かpolicy差が候補になります。Exclude policyの変更は管理者判断です。

まずは使ってみる

記事の文脈に合うToolへ進めます。報酬の有無で見た目は変えていません。

• 

  GitHub Copilot

  公式サイトを見るTool詳細を見る

5. 回答がずれるならcontextを小さくする

応答自体は返るのに修正対象が広がる場合は、modelを変える前にpromptの入力を整理します。最低限、対象file、現在の症状、期待する動作、実行してよいtest、変更範囲を明記します。

例：

曖昧な依頼：「ログインが壊れているので直して」

診断可能な依頼：「src/auth/session.tsで、ページ再読み込み後にsessionがundefinedになる。まず原因候補と確認方法だけ列挙し、auth providerとmiddleware以外は変更しない。再現testを提案してから修正する。」

この入力例はscopeを絞る例で、Copilotの性能を比較した実測結果ではありません。顧客dataやsecretを含む実logは貼らず、再現可能な最小例へ置き換えます。

6. instructionの競合を切り分ける

.github/copilot-instructions.md、path-specific instruction、AGENTS.md、personal / organization instructionsが同時にあると、rule同士の競合が回答へ影響する場合があります。期待と異なる修正が出たら、どのinstructionが対象fileに適用されているか確認し、重複・矛盾・古いcommandを見直します。

診断では一度に全部削除せず、該当pathへ適用されるinstructionだけを短く読み、同じ非機密taskを再現します。instructionへcredential、private URL、customer dataを書き込まないでください。instructionは回答の方向づけであり、毎回必ず従う保証ではありません。

7. network / proxy / certificateを確認

IDEのCopilotだけtimeoutする場合、VPN、HTTP proxy、TLS inspection、custom certificate、firewall、organization allowlistを確認します。GitHubのnetwork troubleshootingではETIMEDOUT、ECONNRESET、certificate error等を例示しています。会社networkだけ失敗するなら、個人端末の設定を無理に変更する前に、発生時刻、IDE、error code、VPN状態をnetwork管理者へ渡します。

browserで通常のWebが開けても、Copilot API endpointやmodel providerだけ遮断されている可能性があります。certificate検証をoffにする、TLS保護を弱める、proxyを迂回する対処はしないでください。

8. logs・rate limit・usageを確認

原因が画面から分からない場合は、IDEのOutput / LogsからCopilot関連のerror code、発生時刻、request IDを取得します。個人tokenやAuthorization headerは共有せず、必要なら機密を除いて管理者へ渡します。2026年はCopilot plan・model・featureにより利用上限やAI Creditsの条件が変わるため、account画面と現在のplan documentationでusage状態を確認します。inline completion、chat、agentの制限を同じquotaだとみなさないでください。

9. できることとできないことを判断する

Copilotはcompletion、Chat、Agentなどでcode作成を支援しますが、repository全体を常に完全理解する、organization ruleへ決定論的に従う、security bugを自動で完全排除することは保証されません。具体的に期待したfeatureが現在のplan、IDE、policyで使えるかを先に確かめます。動作不良と能力限界が混ざっている場合、error切り分け後に対象taskを明確にして再試行します。

最小の再現記録

調査を続けるときは、次のメモを1件だけ作ると別の人へ渡しやすくなります。

• 発生時刻とtimezone

• IDE / extension version

• login account種別とplan（secretは記録しない）

• surface（completion / chat / agent / GitHub.com）

• 対象が一部fileか全体か

• 表示されたerror code

• Status pageの状態

• 試した非機密の最小例と結果

AIものさしの判断

Copilotが反応しないときは、Status → account / seat → IDE / feature → file policy → context / instructions → network → logs / usageの順に調べます。この順なら原因が特定される前の再installやadmin policy変更を避けられます。一部fileだけならExclusion、応答はあるがずれるならcontextとinstruction、全体停止ならservice・account・networkを優先します。安全に原因を再現できない場合は、機密dataを使って診断せず、error情報を整えて管理者へ渡します。