VS Code から Azure Functions をデプロイしようとしたときに、突然「Internal error: Expected value to be neither null nor undefined: newSiteName」というエラーだけが出て先へ進めなくなると、原因が見えずとても困ります。同じプロジェクトでも以前は成功していた、PC を変えても再現する――そんな状況を想定しながら、このエラーの意味と、現場で再現性の高かった具体的な対処手順をまとめます。
エラー「Internal error: Expected value to be neither null nor undefined: newSiteName」の概要
VS Code の Azure Functions 拡張機能から Function App をデプロイするときに、以下のようなメッセージだけが表示されて失敗するケースがあります。
Internal error: Expected value to be neither null nor undefined: newSiteName典型的な状況は次のとおりです。
- これまで同じ手順・同じ Function App に対して正常にデプロイできていた。
- ある日を境に、デプロイ時の同じタイミングで必ず上記エラーが出るようになった。
- プロジェクトを新規作成しても、同じアカウント／同じサブスクリプションで再現する。
- 別の PC、別の開発者環境でも再現し、ローカルのコード自体とは関係なさそうに見える。
このエラーは、Azure Functions 拡張機能が内部で使っている newSiteName（デプロイ先 Function App 名）を取得できず、null または undefined の状態で処理を続行してしまったことがトリガーです。つまり、「どの Function App にデプロイすべきか」という情報が、拡張機能側で解決できていない状態です。
なぜ newSiteName が取得できなくなるのか
VS Code から Azure Functions をデプロイする際、拡張機能は概ね次のような流れで情報を取得しています。
- サインイン中の Azure アカウント情報を取得。
- 選択中のテナント／サブスクリプションを元に、Function App の一覧を取得。
- ユーザーが選択した既存 Function App または新規作成する App の名前を
newSiteNameとして保持。 newSiteNameを使って Zip デプロイ等を実行。
どこかの段階で情報が欠落していると、newSiteName が null または undefined のまま扱われ、今回のような「Internal error」が発生します。よくあるパターンを整理すると、次のように分類できます。
| 原因の種類 | 典型的なパターン | newSiteName が取れない理由 |
|---|---|---|
| キャッシュの汚損 | VS Code を長期間アップデートしながら使っている／Insiders と安定版を行き来している | 古いスキーマのキャッシュが残っており、Function App 情報が正しく復元できない |
| サインイン情報の不整合 | アカウントを切り替えた／ゲストテナントに招待された | 有効なアクセストークンが取得できず、サブスクリプション・リソースが列挙できない |
| テナント・サブスクリプションの選択ミス | 下部ステータスバーのテナントが意図しないものになっている | 別のテナント側には対象 Function App が存在しないため、選択結果が空になる |
| 拡張機能のバグ | あるバージョン以降で急に再現し始めた／複数環境で一斉に発生 | 内部状態のチェック不足により、null のまま処理を進めてしまう |
実際の現場では、キャッシュの汚損とテナント・サブスクリプション周りの情報の食い違いが同時に起きているケースも多く、単に「サインインし直した」だけでは直らないことがあります。そのため、少し手間はかかりますが、キャッシュ削除・再インストール・テナントの明示選択まで含めて一気に対処するのが効果的です。
解決の優先度と全体フロー
「どこから手を付ければいいか」を整理するために、優先度の高い順に対処フローをまとめます。
| 優先度 | 対処内容 | 目的 | 実施時間の目安 |
|---|---|---|---|
| 1 | A. VS Code キャッシュの手動削除 | 壊れた状態のキャッシュや古い拡張機能の残骸を一掃する | 5〜10 分 |
| 2 | B. Azure Functions 拡張機能の再インストール | 拡張機能本体の破損や中途半端なアップデートを解消する | 5 分前後 |
| 3 | C. Azure への再サインイン | トークンの失効やアカウント切り替えによる不整合を解消する | 数分 |
| 4 | D. 「Accounts & Tenant」でテナントを明示選択 | 正しいテナント・サブスクリプションを VS Code に認識させる | 数分 |
| 5 | E. 拡張機能／CLI の最新化・Azure CLI でのデプロイ | 拡張機能固有のバグかどうかを切り分ける | 10〜20 分 |
以降では、それぞれの手順をより詳しく解説していきます。
A. VS Code キャッシュの手動削除
まず最初に試したいのが、VS Code のキャッシュ削除です。過去のバージョンでは Azure 拡張機能に「Azure: Clear Cache」というコマンドが用意されていましたが、現在のバージョンでは存在しないことが多く、手動でキャッシュフォルダーを削除する方法が最も確実です。
キャッシュ削除の基本手順
- VS Code をすべて終了する（バックグラウンドで残っていないことを確認）。
- OS ごとに対応する VS Code の設定フォルダーを開く。
- 以下のキャッシュ関連フォルダーを削除する。
- VS Code を再起動する。
OS 別の VS Code 設定フォルダー
| OS | 設定フォルダーのパス |
|---|---|
| Windows | C:\Users\<ユーザー名>\AppData\Roaming\Code |
| macOS | ~/Library/Application Support/Code |
| Linux | ~/.config/Code |
VS Code Insiders を使っている場合は、フォルダー名が Code - Insiders となっている場合があります。
削除対象となるキャッシュフォルダー
設定フォルダー以下にある、次のフォルダーを削除します（存在しないものはスキップして構いません）。
CachedDataCacheCode CacheGPUCache
これらは キャッシュ専用のフォルダーであり、削除しても拡張機能やユーザー設定そのものは消えません。初回起動時に再生成されます。
キャッシュ削除後に確認するポイント
- VS Code 再起動後、Azure 拡張機能が自動的に再読み込みされるまで数秒待つ。
- Azure パネルでアカウントが正しくサインインされているか確認する。
- Function App 一覧が正常に表示されるか確認する。
この段階でエラーが解消されれば、原因はほぼキャッシュ汚損だったと考えて良いでしょう。
B. Azure Functions 拡張機能の再インストール
キャッシュ削除でも改善しない場合は、Azure Functions 拡張機能自体が破損している可能性があります。VS Code の自動アップデート途中で中断された場合などに、拡張機能だけが中途半端な状態になることがあります。
拡張機能の再インストール手順
- 拡張機能ビューを開く（ショートカット：
Ctrl + Shift + X/ macOS はCmd + Shift + X）。 - 検索ボックスに
Azure Functionsと入力し、対象の拡張機能を見つける。 - 拡張機能を右クリックし、「アンインストール」を選択。
- VS Code の再起動を求められた場合は指示に従う。
- 再起動後、再度拡張機能ビューを開き、Azure Functions をインストール。
再インストール後に確認すべきこと
- Azure 拡張機能全体（Azure Account や Azure Resources など）も最新化されているか。
- Azure パネルからサインインが求められた場合は、指示に従って再サインインする。
- 以前設定していたデプロイ先 Function App が一覧に表示されているか。
拡張機能を入れ直すことで、内部で保持していた状態（選択済みの Function App など）がリセットされ、newSiteName の取得が正常に行われるようになるケースがあります。
C. Azure への再サインイン
Azure へのサインイン状態が中途半端なときも、Function App 情報の取得に失敗し、newSiteName が null になることがあります。特に、次のような状況では注意が必要です。
- ブラウザー側でアカウントを切り替えた。
- 組織テナントにゲストとして招待された／テナントが増えた。
- パスワード変更や多要素認証の再構成を行った。
サインアウトと再サインインの手順
- VS Code の左側アクティビティバーから Azure アイコンをクリック。
- Azure パネル内のアカウント名を右クリックし、「サインアウト」を選択。
- VS Code をいったん閉じて、再度起動する。
- Azure パネルで再びサインインを求められたら、デプロイに利用しているアカウントでログインする。
サインイン後、対象サブスクリプションや Function App が正しく見えるようになれば、トークンやテナントの問題だったと判断できます。
別アカウントに紐づく Function App に注意
企業環境などでは、開発用サブスクリプションと本番サブスクリプションを別テナント・別アカウントで運用していることもあります。この場合、
- ブラウザーは A アカウントでサインインしているが、
- VS Code では B アカウントで Azure にサインインしている、
という状態になると、Function App 一覧に目的のリソースが出てこず、newSiteName も空のままになります。必ず、Azure Portal でリソースを操作しているのと同じアカウントで VS Code にもサインインしているか確認しましょう。
D. Accounts & Tenant 拡張機能でテナントを明示的に選択
マルチテナント環境で開発している場合、サインインしているアカウントが複数のテナントに属していることがよくあります。たとえば、
- 自社テナント（開発・検証用リソース）
- 親会社テナント（共通サービス）
- 顧客テナント（ゲストとしてアクセス）
のような構成で、VS Code のステータスバー右下には現在選択中のテナント名が表示されます。ここが意図しないテナントになっていると、対象サブスクリプションや Function App が見つからず、結果的に newSiteName が取得できません。
テナントを明示的に選択する手順
- VS Code ウィンドウ右下のステータスバーに表示されているテナント名（またはアカウント情報）をクリック。
- 「Accounts」や「Tenant」関連のメニューから、対象サブスクリプションが含まれるテナントを選択。
- テナントを切り替えた後、Azure パネルのサブスクリプション一覧を更新する。
- 対象サブスクリプションにチェックが入っていることを確認する。
ここで重要なのは、「サインインしているアカウント」と「現在選択されているテナント／サブスクリプション」は別物だという点です。特にゲストテナントをまたいで作業している場合は、少しの操作ミスで見えているリソースが切り替わってしまいます。
マルチテナント環境でのおすすめ設定
- 日常的に使わないサブスクリプションにはチェックを入れないようにしておく。
- テナント切り替え後は、必ず「Function App 一覧に対象リソースが表示されているか」を確認する習慣をつける。
- チーム内で「どのテナント／サブスクリプションにどの Function App があるか」を一覧化しておく。
E. 拡張機能／CLI の最新化と Azure CLI での直接デプロイ
キャッシュ削除・拡張機能再インストール・再サインイン・テナント選択を一通り行っても解決しない場合、Azure Functions 拡張機能自体のバグが疑われます。この場合は、以下の 2 つの観点で切り分けを行うと、原因を追いやすくなります。
- VS Code・Azure 拡張機能を最新バージョンに更新する。
- Azure CLI を利用して、拡張機能を介さずに直接 Function App にデプロイしてみる。
VS Code・拡張機能の更新
- VS Code 本体の「更新の確認」を実行し、最新バージョンへ更新。
- 拡張機能ビューで Azure 関連拡張機能にアップデートがないか確認し、まとめて更新。
更新後は必ず VS Code を再起動してから、再度デプロイを試してください。
Azure CLI による config-zip デプロイの例
VS Code 側の問題かどうかを切り分けるには、Azure CLI を使ったデプロイが有効です。ここでは、Zip ファイルを使った config-zip デプロイの例を示します。
- デプロイ対象のアプリケーションを Zip に固める。
例：プロジェクトルートで以下のような Zip を作成myfunc.zipなど - ターミナル（またはコマンドプロンプト／PowerShell）を開き、次のようなコマンドを実行。
az login
az account set --subscription "<サブスクリプション名または ID>"
az functionapp deployment source config-zip ^
--resource-group <リソースグループ名> ^
--name <Function App 名> ^
--src <zip ファイルのパス>
（^ は Windows PowerShell の行継続記号です。macOS / Linux の場合は \ を使用してください。）
このコマンドでデプロイが正常に完了する場合、Azure 側のリソースやアクセス権限は問題ないと判断できます。つまり、VS Code の拡張機能側でのみ newSiteName が正しく扱われていない可能性が高くなります。
パターン別の切り分け結果と考え方
ここまでの手順を踏まえたとき、どのパターンに当てはまるかで原因を推定できます。
| 状況 | 想定される原因 | 次の一手 |
|---|---|---|
| CLI デプロイは成功するが、VS Code からのデプロイのみで newSiteName エラー | Azure Functions 拡張機能のバグまたは内部状態の不整合 | 拡張機能のバージョン情報を控え、アップデートを待つ／Issue 登録を検討 |
| CLI デプロイも失敗し、Function App 自体へのアクセスができない | Azure 側のアクセス権限・ネットワーク制限・Function App 設定の問題 | ポータル上のアクセス制限・権限（RBAC）・ファイアウォール設定を確認 |
| キャッシュ削除・再サインインであっさり解決 | キャッシュ汚損または期限切れトークンの残留 | 定期的なキャッシュクリアや VS Code 再起動を運用に取り入れる |
| テナント切り替えで Function App が突然一覧に現れる | 誤ったテナント・サブスクリプションを選択していた | チーム内でテナント・サブスクリプション対応表を共有し、ミスを減らす |
根本原因をもう一度整理する
ここまでの内容を、エラーの直接原因と背景要因に分けて整理します。
直接原因
- Azure Functions 拡張機能が、デプロイ先 Function App 名（
newSiteName）を取得・保持できていない。 newSiteNameがnullもしくはundefinedのまま内部処理に渡され、「Expected value to be neither null nor undefined」という内部エラーとして表面化している。
主な背景要因
- VS Code のキャッシュ汚損
長期間の利用やアップデートの繰り返しにより、古い形式のキャッシュが残り続け、最新の拡張機能と噛み合わなくなる。 - テナント・サブスクリプション情報のミスマッチ
マルチテナント環境やゲストテナント利用時に、意図しないテナントが選択されている。 - サインイン状態の不整合
トークンの失効やアカウント切り替えにより、VS Code が想定通りの権限で Azure にアクセスできていない。 - 一部バージョンの拡張機能のバグ
特定バージョンの Azure Functions 拡張機能において、newSiteNameの null チェックが不十分で、内部エラーとしてユーザーに露出している可能性がある。
ユーザー報告ベースでは、2024 年末〜 2025 年初にかけて同様の事象が増えているという声もあり、該当期間の拡張機能バージョンに不具合が含まれていた可能性も考えられます。いずれにせよ、キャッシュ削除やテナント選択の見直しで回避できるケースが多く、まずは本記事の対処フローを順番に試すのが現実的です。
チームで共有したいチェックリスト
複数の開発者・複数の PC で同じエラーが再現している場合、問題は個人の環境に閉じていません。チームとして共通のチェックリストを持っておくと、原因の切り分けがスムーズになります。
| 観点 | 確認すべき質問 | 確認方法 |
|---|---|---|
| アカウント | Azure Portal と VS Code は同じアカウントでログインしているか？ | Azure Portal 右上のアカウントと、VS Code Azure パネルのアカウントを見比べる |
| テナント | 対象 Function App が存在するテナントを VS Code で選択しているか？ | ステータスバーや Accounts & Tenant 拡張機能でテナント名を確認 |
| サブスクリプション | 目的のサブスクリプションにチェックが入っているか？ | Azure 拡張機能の「サブスクリプションの選択」から確認 |
| キャッシュ | 最近 VS Code のキャッシュ削除を行ったか？ | 本記事の手順に従い、CachedData 等のフォルダーを削除 |
| 拡張機能 | Azure Functions 拡張機能はチーム全員で同じバージョンか？ | 拡張機能ビューでバージョンを確認し、揃える |
| CLI デプロイ | Azure CLI からは正常にデプロイできるか？ | az functionapp deployment source config-zip をチームの代表環境で試す |
よくある質問（FAQ）
Q1. PC を変えても同じエラーが出るのですが、Azure 側の障害でしょうか？
A. 一時的な障害の可能性もゼロではありませんが、マルチテナント環境やアカウント設定の齟齬が原因であることが多いです。まずは、アカウント・テナント・サブスクリプションの組み合わせを全員で確認し、CLI デプロイも試してみると切り分けやすくなります。
Q2. Function App やリソースグループを作り直した方がよいですか？
A. ほとんどの場合、Azure 側のリソースを作り直す必要はありません。VS Code 側のキャッシュや拡張機能の状態が原因であることが多いため、本記事の A〜E の対処を一通り試したうえで、それでも解決しない場合にのみ新規リソースの作成を検討すると良いでしょう。
Q3. キャッシュフォルダーを削除すると、VS Code の設定や拡張機能は全部消えてしまいますか？
A. 本記事で削除対象としているのは キャッシュ専用のフォルダーであり、ユーザー設定やインストール済み拡張機能そのものは別の場所に保存されています。VS Code を再起動すると必要なキャッシュは自動的に再生成されます。ただし、カスタムスニペットや設定ファイルを独自に配置している場合は、念のためバックアップを取っておくと安心です。
Q4. Azure CLI でのデプロイには慣れていないのですが、必須ですか？
A. CLI デプロイは必須ではありませんが、「Azure 側のリソースや権限に問題がないか」を切り分ける強力な手段です。VS Code 側の問題か、Azure 側の問題かを明確にできるため、チームに一人は CLI デプロイを試せるメンバーがいると、トラブルシュート全体がスムーズになります。
Q5. 2024 年末〜 2025 年初にかけて発生例が増えているという話を聞きましたが、本当ですか？
A. ユーザーコミュニティ等ではそのような報告も見られますが、環境やバージョンによって再現状況は異なります。重要なのは、キャッシュ削除・拡張機能の再インストール・テナント／サブスクリプションの確認といった基本的な対処を押さえておくことです。バージョン固有の問題だったとしても、これらの手順で多くのケースを回避・軽減できます。
再発防止のためのベストプラクティス
最後に、同じトラブルで何度も悩まされないように、日常運用に組み込みやすい再発防止策をまとめます。
- 定期的な VS Code 再起動とキャッシュクリア
長時間 VS Code を起動しっぱなしにせず、アップデートのタイミングなどで再起動＆キャッシュ削除を行う。 - テナント・サブスクリプションの一覧化
「どのテナントのどのサブスクリプションに、どの Function App があるか」をチームで共有するドキュメントを用意する。 - アカウント運用ルールの明確化
開発用アカウント・本番用アカウントを分ける場合は、VS Code でどのアカウントを使うかを明文化し、混在させない。 - CLI デプロイ手順のチーム共有
Azure CLI での config-zip デプロイ手順を Wiki などにまとめ、「VS Code 以外の経路でもデプロイできる状態」を維持する。 - 拡張機能バージョンの統一
チーム内で Azure Functions 拡張機能のバージョンを揃え、「誰かだけ動いて誰かは動かない」といった状況を避ける。
まとめ
VS Code から Azure Functions をデプロイした際に表示される「Internal error: Expected value to be neither null nor undefined: newSiteName」というメッセージは、一見すると原因が分かりにくい内部エラーですが、実態としては 「デプロイ先 Function App 名が拡張機能側で解決できていない」ことを意味しています。
実務上の対処としては、次の流れでチェックするのがおすすめです。
- VS Code のキャッシュ削除 → 再起動（CachedData 等の削除）。
- Azure Functions 拡張機能の再インストールと、Azure 拡張機能全体の最新化。
- Azure への再サインインと、テナント／サブスクリプションの明示的な選択。
- 必要に応じて Azure CLI による直接デプロイを試し、VS Code 拡張機能固有の問題かを切り分ける。
これらを一通り実施することで、多くのケースでエラーを解消し、再び VS Code からスムーズに Azure Functions をデプロイできるはずです。同様のトラブルが再発した場合にも、本記事のチェックリストを参照しながら、原因を体系的に絞り込んでいってください。
コメント