Copilot「Language model unavailable」の原因をログで見分けて直す

VS Code の Copilot Chat に出る「Language model unavailable」は、VS Code が Copilot の既定モデル（モデル選択の「Auto」など）を1つも取得できなかったときの表示です。VS Code のソースコードでは翻訳されない固定の英語として書かれているため、日本語 UI でも英語のまま出ます。原因は1つではなく、GitHub 側の障害、社内ネットワークによる Copilot ドメインの遮断、トライアルやライセンスの状態、古い VS Code のどれかであることがほとんどです。

まず GitHub Status で Copilot に障害が出ていないかを見てから、出力パネルの「GitHub Copilot Chat」で Failed to fetch models から始まる行を探し、コマンドパレットで「Chat Diagnostics」を実行してください。この3か所の表示で、待つべきか、ネットワークを直すべきか、GitHub のプランと請求を確認すべきか、VS Code を更新すべきかが決まります。

自分では直せないケースもあります。GitHub 側の障害と、会社のネットワークが個人プラン用の *.individual.githubcopilot.com を意図的に止めている場合です。前者は復旧を待ち、後者は IT 部門に相談するか会社のシートのアカウントでサインインし直します。その間も作業を止めたくなければ、自分の API キーを登録する BYOK（Bring Your Own Key）のモデルでチャットだけは続けられます。

「Language model unavailable」はどんなときに出るのか

モデル選択で何も指定せずにチャットを送ると、VS Code は Copilot の既定モデルを探し、見つからなければこのエラーを返します。2026年11月4日時点の VS Code のソース（microsoft/vscode の extHostLanguageModels.ts）では、この文字列は翻訳処理を通らない英語の固定文字列です。エラー自体は「Copilot のモデルが1つも登録されていない」という結果を伝えているだけで、なぜそうなったかは Copilot Chat 拡張のログに残ります。

モデル選択の一覧が「Auto」だけ、または空になっているのも同じ状態です。2026年11月4日時点の Copilot Chat 拡張のソース（microsoft/vscode の extensions/copilot）では、Auto モードは使えるエンドポイントがないと No auto mode endpoints provided. を出します。2026年1月の VS Code の issue では、開発者ツールにこの行が出てモデル選択に Auto しか残っていない例が報告されています。同じソースによれば、Copilot 拡張はモデル一覧を最短でも10分に1回しか取り直さず、ウィンドウが前面にないあいだは更新しません。ネットワークやプランを直したあとは待たずに、F1 から「Developer: Reload Window」を実行してください。

似たメッセージに「The selected model '…' is not available. Select a different model and try again.」があります。こちらは自分で選んだ特定のモデルが見つからないときのもので、2026年10月7日リリースの VS Code 1.141.0 から出るようになりました（VS Code の PR #339307）。それ以前は、選んだモデルが消えると黙って Auto に切り替わっていました。このメッセージは翻訳の対象なので日本語で表示されることがあり、Copilot 全体ではなくそのモデルだけの問題なので、モデル選択で別のモデルを選び直せば済みます。

原因の見分け方：ログと症状の対照表

原因を見分ける材料は、出力パネルの「GitHub Copilot Chat」のログ、Chat Diagnostics のレポート、そして「どこでなら動くか」という症状の3つです。VS Code のメンテナーは2024〜2025年の報告をもとに企業ネットワークによる遮断を最も多い原因としていますが、2026年の報告には GitHub 側の障害、Pro トライアルの停止、ライセンス、古い VS Code も多く含まれます（VS Code の issue #253137「Meta: Language Model Unavailable」）。思い当たる対処から試すより、先にログを見たほうが早く絞れます。

ログとレポートは、VS Code の公式ドキュメントの手順で次のように出せます。

1. コマンドパレットで「Developer: Set Log Level」を実行し、GitHub Copilot と GitHub Copilot Chat を Trace にする
2. 「Output: Show Output Channels」から「GitHub Copilot Chat」を選ぶ
3. チャットをもう一度送ってエラーを再現し、出力された行を確かめる
4. コマンドパレットで「Chat Diagnostics」を検索して実行し、レポートの失敗項目を見る
5. 終わったらログレベルを元に戻す

Chat Diagnostics のコマンドは、版によって「GitHub Copilot: Chat Diagnostics」「Developer: GitHub Copilot Chat Diagnostics」のように前に付く語が変わるため、「Chat Diagnostics」で検索するのが確実です。ログとレポートにはコードやプロンプトが含まれることがあるので、issue などに貼る前に機密部分を消してください。

同じアカウントで Copilot CLI や github.com 上の Copilot は動くのに VS Code だけが失敗するなら、GitHub の障害やプランよりも、VS Code 側のアカウント、版、設定ファイルを先に疑います。逆にどの端末、どのアプリでも失敗するなら、障害かライセンスの可能性が高くなります。

Copilot のエンドポイントに届いているかを curl で確かめる

ネットワークが原因かどうかは、認証なしで Copilot のエンドポイントに curl でつないだときの応答で判断できます。届いていれば、認証がないことを理由に 401 や 400 が返ってきます。タイムアウトや接続拒否になる、あるいは証明書の発行者が会社のプロキシ製品の名前になっているなら、途中のネットワークで止められています。

2026年11月4日に、ローカルのプロキシアプリを経由する Mac 1台（curl 8.7.1）で次のコマンドを実行しました。個人プランは individual のまま、Business は business、Enterprise は enterprise に置き換えてください。Windows の PowerShell では curl の代わりに curl.exe と入力します。

curl -sS -w "\n%{http_code}\n" https://api.github.com/copilot_internal/v2/token
curl -sS -w "\n%{http_code}\n" https://api.individual.githubcopilot.com/_ping
curl -sS -w "\n%{http_code}\n" https://api.individual.githubcopilot.com/models
curl -sS -w "\n%{http_code}\n" https://copilot-proxy.githubusercontent.com/_ping

届いているときの結果は次のとおりで、どれも1秒前後（0.84〜1.13秒）で返りました。プロキシの環境変数を無視する --noproxy '*' を付けて token、/_ping、copilot-proxy の3つを試した結果も同じステータスでしたが、この Mac では名前解決の段階からプロキシアプリの TUN を通っていたため、プロキシを経由しない経路は試せていません。401 と 400 はエラーに見えますが、サーバーまで届いて「認証がない」と返事をもらえた証拠なので正常です。

止められているときは、curl: (28) のタイムアウト、curl: (7) の接続失敗、curl: (60) の証明書エラーになるか、会社のプロキシが返すブロックページの HTML が返ってきます。api.github.com は通るのに githubcopilot.com のドメインだけが失敗するなら、ファイアウォールや透過プロキシがそのドメインだけを止めているとみてよく、VS Code のメンテナーも ENETUNREACH が githubcopilot.com にだけ出た例をそう診断しています。

証明書の発行者は次のコマンドで見られます。2026年11月4日の結果は issuer=C=GB, O=Sectigo Limited, CN=Sectigo Public Server Authentication CA DV R36 でした。発行者にセキュリティ製品や会社の名前が出るなら、プロキシが通信を復号して証明書を差し替えています。

echo | openssl s_client -connect api.individual.githubcopilot.com:443 -servername api.individual.githubcopilot.com 2>/dev/null | openssl x509 -noout -issuer

この結果は1台、1つのネットワーク、1時点のものです。また curl が通っても、VS Code が同じ経路を使っているとは限りません。Chat Diagnostics のレポートには Copilot が実際に使った経路の結果が出るので、curl と食い違うときはそちらを優先します。issue #253137 に貼られた失敗例では、DNS は引けているのに通信方式がすべてタイムアウトしており、ネットワークで止められている典型的な形です。

Connecting to https://api.individual.githubcopilot.com/_ping:
- DNS ipv4 Lookup: 140.82.113.21 (34 ms)
- DNS ipv6 Lookup: Error: getaddrinfo ENOTFOUND api.individual.githubcopilot.com
- Electron Fetcher (configured): timed out after 10 seconds
- Node Fetcher: timed out after 10 seconds
- Helix Fetcher: timed out after 10 seconds

現在の版のレポートでは、各行が Proxy URL、Electron fetch (configured)、Node.js https、Node.js fetch という名前になり、正常なら HTTP 200 が並びます。Proxy URL の行には Copilot が実際に取得したプロキシが出るので、プロキシを使っているはずなのに None になっていないかも確かめてください。

社内プロキシ・VPN・証明書が原因なら IT 部門に頼むこと

会社のネットワークで起きているなら、原因は PC ではなくネットワーク側の設定にあることが多く、IT 部門に具体的なドメインを伝えて許可を頼むのが近道です。GitHub の Copilot 許可リストのリファレンスによれば、Copilot には github.com/login/*、api.github.com/user、api.github.com/copilot_internal/*、copilot-proxy.githubusercontent.com、origin-tracker.githubusercontent.com、copilot-telemetry.githubusercontent.com/telemetry、default.exp-tas.com に加え、プランごとのドメインへの通信が必要です。プラン別のドメインは、個人プランが *.individual.githubcopilot.com、Business が *.business.githubcopilot.com、Enterprise が *.enterprise.githubcopilot.com です。

注意したいのは、GitHub のサブスクリプション単位のネットワークルーティングを使う会社が、自社プランのドメインだけを許可して社員の個人 Copilot をわざと止めていることです（GitHub Changelog の2024年11月4日の告知）。個人アカウントで会社の回線だと失敗し、テザリングに切り替えると動くなら、このルールに当たっている可能性が高いと考えられます。この場合は個人プランのドメインを開けてもらうより、会社が用意したシートのアカウントでサインインし直すほうが社内ルールに沿った解決になります。

プロキシが HTTPS を復号して証明書を差し替えている場合、VS Code の公式ドキュメントが勧めるのは、そのプロキシのルート証明書を OS の信頼ストアに追加することです。Linux ではさらに NSS にも certutil -A -n "ProxyCA" -t "CT,," -i 証明書ファイル -d sql:$HOME/.pki/nssdb で追加します。http.proxyStrictSSL を false にする、--ignore-certificate-errors を付けて起動するといった証明書の検証そのものを切る方法は、通信の安全性を下げるので使わないでください。VS Code のドキュメントも後者を "dangerous and not recommended" としています。

VS Code は Chromium のネットワーク機能を使っており、OS のプロキシ設定を自動で読み込みます。起動オプションの --proxy-server= や --proxy-pac-url= で指定することもでき、設定の http.proxy は主に新しいプロキシ対応に移行していない拡張機能や CLI のために残されています。PC でプロキシアプリを使っている人は、システムプロキシと TUN のどちらのモードかによって VS Code とターミナルの curl で通る経路が変わることがあるため、Chat Diagnostics レポートの Proxy URL 行で実際の値を確かめてください。WSL2 では既定の NAT モードで IPv6 が原因になった例があり、VS Code のメンテナーは mirrored ネットワークへの切り替えか IPv6 の無効化を案内しています。

トライアル・プラン・「not licensed」はどこで確認するか

ログに 403 や not licensed to use Copilot が出ている場合は、ネットワークではなく GitHub アカウント側の問題です。2026年9月27日の VS Code の issue #338271 では、Pro+ を契約している利用者にこのエラーと 403「not licensed to use Copilot」が同時に出て、モデル選択が「Local」から動かなくなりました。支払いの承認失敗を疑う報告（#333427）や、会社が Business から Enterprise に移行した直後に出た報告もあり、原因は1つに絞れません。

トライアルの人は時期にも注意が必要です。GitHub は2026年4月10日に新規の Copilot Pro トライアルを一時停止し、4月13日には進行中のトライアルも含めて停止すると更新しました（GitHub Changelog のトライアル一時停止の告知）。直後の issue #309766 にはトライアル利用者から同じエラーの報告が集まり、請求画面で「Start paid subscription」を押して直った人もいれば、変わらなかった人もいます。この告知ページは現在「Retired」と表示されていますが、トライアルが再開したかどうかはそこからは読み取れません。

確認は次の順で進めます。

1. VS Code 左下の Accounts アイコンで、サインインしている GitHub アカウント名を確かめる
2. github.com に同じアカウントでログインし、Settings の Copilot と Billing の画面で、プラン（Free、Pro、Pro+、Max、Business など）と支払い状態を見る
3. 会社のシートなら、管理者にシートが自分に割り当てられているかを確認してもらう

有料の Pro なのに期限切れのトライアルとして扱われていた人が、いったん解約して再契約したら直り、二重請求もなかったという報告（#253137、2026年4月15日）もあります。ただし1件だけの事例なので、請求に関わる操作は GitHub サポートに相談してからのほうが安全です。

VS Code と Copilot Chat は更新すべきか

更新すべきです。GitHub の公式ドキュメント（Troubleshooting common issues with GitHub Copilot）は、Copilot Chat の新しいバージョンは最新リリースの VS Code としか互換性がなく、古いクライアントは Copilot のサーバーと通信できないと明記しています。VS Code はほぼ毎週リリースされ、2026年11月4日時点の最新の安定版は同日リリースの 1.145.0 です。2026年8〜11月にこのエラーで立てられた issue には、1.106〜1.109 という2025年11月〜2026年2月の版を使い続けていた例が繰り返し見られます。

更新は Help メニュー（macOS では Code メニュー）の「Check for Updates」から行い、拡張機能ビューで GitHub Copilot Chat も最新になっているか確かめます。2台のマシンを手動で更新したら直ったという報告（2026年8月30日）がある一方、1.107.1 に戻したら直ったという逆向きの報告（2026年5月5日）もあります。ただしダウングレードは公式の互換ルールに反するため、長く使える対処にはなりません。

Copilot からサインアウトして再サインインする手順

サインインしているアカウントの取り違えや認証状態の不整合が疑わしいときは、GitHub の公式手順どおりにサインアウトし、ウィンドウを再読み込みしてからサインインし直します。

1. VS Code 左下の Accounts アイコンをクリックし、GitHub のユーザー名にカーソルを合わせる
2. 「Sign out」を選ぶ
3. F1 で「Developer: Reload Window」を実行する
4. Copilot Chat を開き、使いたいプランのアカウントでサインインする

2026年3月には、VS Code が気づかないうちに会社のアカウントでサインインしていて、サインアウトしたら直ったという報告があります。モデルの管理画面（Manage Models）の一覧が空になっていて、モデルを追加し直したら戻った例（2026年1月13日）もあるので、サインインし直しても変わらなければ一覧も見てください。

settings.json の debug 設定やスキルフォルダが原因のとき

ログに ERR_CONNECTION_REFUSED や TypeError: e is not iterable が出ている場合は、ネットワークでもアカウントでもなく、手元の設定やファイルが原因の可能性があります。どちらも1件ずつの報告なので、ログの行が一致するときに限って試してください。

1つ目は settings.json に残った Copilot の debug 設定です。github.copilot.advanced.debug.overrideProxyUrl と github.copilot.advanced.debug.overrideCapiUrl はユーザー設定にだけ置ける項目で、Copilot の通信先を指定したアドレスに書き換えます。中継ツールを試したあとにこの2つがローカルのアドレスとポートを指したまま残り、そこで何も動いていなかった例（2026年9月25日、issue #337927）では、net::ERR_CONNECTION_REFUSED と 401 unauthorized: unable to validate HMAC for the given Copilot-Integration-ID が出ていました。2つの設定を消して Reload Window したら直っています。

2つ目は、Claude Code など別の AI ツールのスキルフォルダです。2026年3月9日の GitHub Community の報告（discussion #188977）では、VS Code 1.110.1 の Copilot Chat が起動時に ~/.claude/skills と ~/.agents/skills を読み込み、名前の重複や対応していない形式のファイルで TypeError: e is not iterable になっていました。Copilot CLI は動くのに VS Code だけが失敗し、2つのフォルダの名前を変えたら直っています。その後の版で修正されたかは公開情報からは分からないので、試すときはフォルダを削除せず、名前の変更で済ませてください。

直るまでの間は BYOK のモデルでチャットを続ける

Copilot 側が直らないあいだも、自分の API キーでモデルを登録する BYOK を使えば VS Code のチャットは続けられます。VS Code ドキュメントの言語モデルの解説（vscode-docs リポジトリ）によれば、ローカル（Local）セッションの BYOK モデルは GitHub アカウントへのサインインも Copilot のプランも必要ありません。ただしコード補完、セマンティック検索、埋め込みを使う機能は引き続き GitHub アカウントが必要で、Business や Enterprise では管理者がポリシーで BYOK を止めていることがあります。BYOK は Copilot を無料にする方法でも Copilot のアカウント問題を直す方法でもなく、自分のキーで別のモデルを呼ぶ仕組みです。

最小の設定は、Language Models エディターで「Add Models」から「Custom Endpoint」を選び、API の形式（Chat Completions、Responses、Anthropic Messages のいずれか）、ベース URL、API キー、モデル名を入れるだけです。設定は chatLanguageModels.json に vendor: "customendpoint" として保存され、以前の OpenAI Compatible プロバイダーと github.copilot.chat.customOAIModels は非推奨になりました。サインインせずに使う場合は内蔵のユーティリティモデルも使えないため、chat.utilityModel と chat.utilitySmallModel に BYOK のモデルを指定します。

登録するのは、自分の OpenAI や Anthropic のキーでも、Ollama で動かすローカルモデル（現在は内蔵プロバイダーではなく Ollama 公式の拡張機能を使います）でも、OpenAI 互換の中継サービスでも構いません。中継サービスの一例の laozhang.ai はベース URL が https://api.laozhang.ai/v1 で、2026年11月4日に Chat Completions 形式でストリーミングとツール定義付きのリクエストを送ったところ、read_file のツール呼び出しと引数を正しく返し、[DONE] で終わりました。VS Code の Custom Endpoint に登録しての動作は試していません。API の選び方は「無料AI APIのおすすめ：上限・学習利用・カード要否で選ぶ」で比べています。

注記：laozhang.ai は当ブログ運営チームの自社サービスです。その料金は中立的な比較ではなく、自社の提示価格です。

Copilot「Language model unavailable」のよくある質問

使用量の上限に達すると「Language model unavailable」になりますか

通常はなりません。2026年11月4日時点の GitHub のドキュメントでは、使用量の上限は「You've hit a rate limit」という別のエラーとして扱われ、リセットを待つかプランを上げるよう案内されます。Copilot 拡張のソースでも、レート制限（429）を受けたときに取得済みのモデル一覧があれば警告を記録するだけです。一覧をまだ持っていない状態で 429 を受けた場合はモデル取得の失敗になるので、ログの Failed to fetch models の行に 429 が出ていないかを見てください。残りの AI クレジットは、ステータスバーの Copilot 表示から確認できます。

Ollama などのローカルモデルも使えなくなりますか

サインイン不要な BYOK のローカルモデルは、本来 Copilot のプランに依存しません。ただし2026年2月10日の issue #253137 への投稿では、オフラインや Copilot の経路が止められた環境でローカルモデルも使えなかったと報告されています。Copilot が提供する端末内のモデル（MAI Code 1.1 Flash、ダウンロード52.8GB）は GitHub へのサインインが必要で、Business や Enterprise では管理者が Editor Preview Features を有効にしていないと使えません。

Claude Code の拡張機能が VS Code で動かない場合も同じ対処ですか

別の問題です。Anthropic の Claude Code 拡張は Copilot のモデル一覧を使わないため、「Language model unavailable」の対処は当てはまりません。Claude Code 側の切り分けは「Claude Code が VS Code で動かない時は、まず失敗している面を分ける」にまとめています。