Visual Studio 2022でASP.NET Coreをローカル実行できない？IIS Expressが起動しない／Dockerが起動する原因と対処法

Visual Studio 2022でASP.NET CoreをF5実行したいのに、IIS Expressが起動せずDocker Desktopが立ち上がってブラウザも開かない…。多くは起動プロファイルがコンテナー実行に切り替わっているだけです。原因の見分け方と最短の戻し方、再発防止までまとめます。

起きている現象を整理する：IIS Expressが起動しないように見えるパターン

まずは「何が起動しようとしているのか」を切り分けると、解決までが一気に短くなります。今回のケースは、IIS Expressが壊れたというよりも、そもそもIIS Expressを起動する設定になっていないことが原因になりがちです。

見えている症状	裏で起きがちなこと	まず確認すべき場所
F5してもIIS Expressのトレイアイコンが出ない	起動ターゲットがDocker/ContainerになっていてIIS Expressを呼んでいない	Visual Studio上部ツールバーの起動プロファイル
Docker Desktopが起動する／「ビルド中…」で止まる	コンテナー用ビルド（DockerfileやContainer Tools）を実行しようとしている	起動プロファイル、Solution内のDocker関連プロジェクト
ブラウザが開かない	起動に失敗している／起動はしているが「launchBrowser」が無効	出力（Output）ウィンドウ、launchSettings.json

「Dockerが動き出す」「IIS Expressが起動しない」「ブラウザが開かない」がセットで起きている場合は、最初に起動プロファイル（起動ターゲット／Debug Target）を疑うのが最短ルートです。

結論：起動プロファイルが「IIS Express」ではなく「Container（.NET SDK）／Docker」になっている

Visual Studio 2022のASP.NET Coreプロジェクトは、F5（デバッグ開始）時に選択されている起動プロファイルに従って起動方法が変わります。

起動プロファイルがIIS Expressなら、IIS Expressを起動してローカルのURL（例：https://localhost:443xx/）を開きます。一方、起動プロファイルがContainer (.NET SDK)やDockerのようなコンテナー実行になっていると、Visual StudioはDocker Desktopやコンテナー関連の仕組みを使って起動しようとします。

つまり、今回のように「チュートリアルどおりにローカル実行したいだけ」なのにDockerが前面に出てくるのは、Visual Studioが“コンテナーで起動する”設定を選んでいるのが原因です。Dockerの準備（Docker Desktop起動、Linux/Windowsコンテナー切替、イメージビルド、ポート公開など）が整っていないと、起動に失敗し、結果としてIIS Expressもブラウザ起動も行われないように見えます。

最短で直す：起動ターゲットを「IIS Express」に戻す手順

解決手順はシンプルです。Visual Studioの上部にある緑の再生ボタン（実行）付近のドロップダウンで、起動プロファイルをIIS Expressに戻します。

Visual Studio 2022で対象のソリューション／プロジェクトを開く
上部ツールバーの実行ボタン左側にある起動ターゲット（起動プロファイル）のドロップダウンを開く
現在の選択が Container (.NET SDK) / Docker / docker-compose などになっていたら、IIS Express（またはプロジェクト名のプロファイル）に切り替える
F5（デバッグ開始）で実行し、IIS Expressが起動してブラウザが開くことを確認する

ここで「IIS Express」と「プロジェクト名（例：MyWebApp）」の2つが並んでいることがあります。どちらでもローカル起動はできますが、チュートリアルで“F5でブラウザが開く”前提なら、まずはIIS Expressを選ぶと説明と一致しやすいです。

もし起動プロファイルを切り替えたのにブラウザが開かない場合でも、まずはIIS Expressが起動しているかを確認してください。IIS Express自体は起動していて、ブラウザ起動だけが抑止されているケースもあります（後述）。

ログで確定させる：出力（Output）ウィンドウで起動方式を見分ける

「今どれで起動しようとしたのか」は、Visual Studioの出力（Output）ウィンドウを見ると確実です。メニューの「表示」→「出力」から開き、右上の出力元を「デバッグ」に切り替えて確認します。

起動方式	出力ウィンドウで出やすいサイン	補足
IIS Express	IIS Expressの起動に関するメッセージ、localhostのhttps/http URL	トレイにIIS Expressのアイコンが出ることが多い
プロジェクト名（Kestrel）	dotnet実行・ASP.NET Coreの起動ログ、Listening on: http(s)://localhost:xxxx	コンソールが開く場合がある。ブラウザ起動は設定次第
Docker / Container	Docker Desktop、イメージのビルド、コンテナー起動、ポートマッピングに関するログ	Dockerが動いていないとここで止まりやすい

出力にDocker関連のログが出ているなら、原因はほぼ起動プロファイルの選択です。逆にIIS Expressのログが出ているのにブラウザが開かない場合は、別の原因（ブラウザ起動設定、HTTPS証明書、ポート競合など）を疑います。

なぜDockerが勝手に選ばれるのか：よくあるきっかけ

「自分ではDockerを使うつもりがないのにContainerになっている」状況には、いくつか典型パターンがあります。原因を知っておくと再発防止ができます。

プロジェクト作成時にDockerを有効化した（テンプレートのオプション、チェックボックスなど）
途中で「Add Docker Support」系の機能を試した（Dockerfileやdocker-composeが追加される）
一度Containerで起動してから、その選択が保存された（Visual Studioは前回の起動プロファイルを覚える）
ソリューションにdocker-composeプロジェクトが含まれている（起動候補に出やすい）
チュートリアルや記事の手順を混ぜてしまった（コンテナー前提の手順が紛れ込む）

ポイントは、Visual Studioが“自動で正しい起動方式を推測してくれる”というよりも、最後に選んだ起動プロファイルで起動し続ける、という挙動になっていることです。慣れていないと、起動ボタンの表示がいつの間にか「Container (.NET SDK)」になっていて気づきにくいです。

再発防止：コンテナーで動かす予定がないなら、Docker関連を整理する

起動プロファイルをIIS Expressに戻すだけで当面は解決しますが、チュートリアル学習中などで混乱を減らしたいなら、不要なDocker関連を整理しておくと安全です。

ソリューション内にDocker関連プロジェクトがあるか確認する

ソリューションエクスプローラーにdocker-composeのようなプロジェクトがある場合、起動候補として前面に出やすくなります。学習用途で不要なら、いったんソリューションから外す（削除）ことで、誤選択を減らせます。

Dockerfileが追加されているか確認する

Webプロジェクト直下にDockerfileがある場合、Visual Studioがコンテナー起動を候補に出します。コンテナーを使わない期間は、Dockerfileを削除または退避しておくと、起動プロファイルがシンプルになります（チーム開発で利用している場合は方針に従ってください）。

「起動プロファイル＝正解」ではないことを覚えておく

Visual Studio 2022の起動プロファイルは、状況により複数が共存します。どれが正解かは目的次第です。ローカルでASP.NET Coreを確認したいだけなら、基本はIIS Expressまたはプロジェクト名（Kestrel）で十分です。

目的	おすすめ起動プロファイル	理由
チュートリアルどおりにローカルで動作確認	IIS Express	Visual Studioの説明と揃いやすく、F5でブラウザが開きやすい
実運用に近いKestrelでシンプルに動かす	プロジェクト名（Kestrel）	.NETの標準ホストで動き、IIS Expressに依存しない
Linux環境やコンテナー前提で検証したい	Docker / Container	環境差分を減らせるが、Docker Desktop等の準備が必要

それでもIIS Expressが起動しない場合の追加チェック

起動プロファイルをIIS Expressに戻しても動かない場合は、次の順番で確認すると詰まりにくいです。いきなり再インストールに走るより、原因を絞り込むのが近道です。

ビルドが通っているか（最優先）

ASP.NET Coreに限らず、ビルドエラーがあるとデバッグ起動できません。まずは「ビルド」→「ソリューションのビルド」でエラーがゼロになることを確認してください。警告は動く場合もありますが、起動時例外の原因になることがあります。

起動プロジェクトが正しいか

ソリューションに複数プロジェクトがある場合、起動対象が別プロジェクトになっていると、期待したWebアプリが起動しません。ソリューションエクスプローラーで対象Webプロジェクトを右クリックし、「スタートアッププロジェクトに設定」を選びます。

IIS Expressの設定が壊れていないか（よくある）

IIS Expressはユーザーごとに設定ファイルを持ちます。環境移行やテンプレートの切替を繰り返すと、ポート設定が衝突して起動できないことがあります。典型的には「Unable to connect to web server ‘IIS Express’」のようなエラーが出ます。

まず試しやすい対処は次の2つです。

Visual Studioを終了してから、ソリューション直下の.vsフォルダを削除（再生成されます）
ユーザープロファイル配下のIIS Express設定（applicationhost.config）をリセットする

上記は“元に戻せる範囲で安全にやり直す”操作です。削除前にフォルダをコピーしてバックアップしておくと安心です。

HTTPS（開発証明書）まわりを疑う

最近のASP.NET CoreテンプレートはHTTPSがデフォルトです。証明書が壊れていたり、ブラウザ側で強くブロックされていると、起動自体はしているのにアクセスできないことがあります。

確認のポイント：

出力ウィンドウにhttps://localhost:xxxxのURLが出ているか
ブラウザで証明書警告が出ていないか（別タブや別ウィンドウで止まっていないか）
HTTPのURL（http://localhost:xxxx）でも開けるか

開発証明書の再生成が必要な場合は、ターミナルで次のコマンドを実行してリセットする方法があります。

dotnet dev-certs https --clean
dotnet dev-certs https --trust

※組織のポリシーや権限によっては信頼設定ができない場合があります。その場合はHTTPでの検証や、管理者権限での実行を検討します。

ポート競合・プロセス残りを確認する

「前回のデバッグが落ち切っていない」「別アプリが同じポートを使っている」などで、IIS Expressが起動できないことがあります。タスクマネージャーでiisexpress.exeが残っていないか確認し、残っている場合は終了してから再実行します。

Visual Studioのワークロード／コンポーネントを確認する

ASP.NET Coreを扱うには、Visual Studio InstallerでASP.NET と Web 開発ワークロードが入っている必要があります。環境を軽量化している場合や、途中でコンポーネントを外した場合に、IIS Express関連が不完全になることがあります。疑わしい場合は、Installerからワークロードを確認し、必要なら修復（Repair）を実行します。

コンテナー起動が混ざっている場合の典型エラーと対処

Container (.NET SDK) が選ばれていると、IIS Express以前にDockerの準備で失敗します。メッセージは環境で変わりますが、次のような状況なら「まずIIS Expressに戻す」が正解です。

状況	ありがちな原因	対処
Docker Desktopが起動していない／起動に時間がかかる	Dockerを使う前提のプロファイルになっている	起動プロファイルをIIS Expressへ切替
Linux/Windowsコンテナーの切替が合わない	ターゲットOSとDocker設定が不一致	コンテナー利用時のみ設定を合わせる（不要ならIIS Expressへ）
イメージビルドで失敗する	Dockerfile・SDK・プロキシなど環境依存	学習段階ではコンテナー起動をやめ、ローカル実行で検証

補足：IIS Expressではなく「プロジェクト名（Kestrel）」で起動するのも有効

チュートリアルや社内手順がIIS Express前提でない場合、起動プロファイルをプロジェクト名（Kestrel）にして動かすのも堅実です。IIS Expressに依存しないため、環境差分によるトラブルが減ることがあります。

プロジェクト名プロファイルでブラウザが開かない場合は、launchSettings.jsonの設定を確認します。代表的には次の項目がポイントです。

{
  "profiles": {
    "MyWebApp": {
      "commandName": "Project",
      "launchBrowser": true,
      "applicationUrl": "https://localhost:5001;http://localhost:5000",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    },
    "IIS Express": {
      "commandName": "IISExpress",
      "launchBrowser": true,
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    }
  }
}

launchBrowserがfalseになっていると、起動してもブラウザが自動で開きません。プロジェクト名プロファイルで「起動しているのに何も起きない」と感じる場合は、ここが原因のことがあります。

よくある質問：IIS ExpressとDocker、結局どっちを使えばいい？

結論は「目的次第」です。ただし、今回のようにローカルでビルド／テスト／起動して画面を確認することが目的なら、無理にDockerを絡めない方がスムーズです。

IIS Express：Visual Studioに統合されていて手軽。学習やUI確認の速度重視に向く。
Kestrel（プロジェクト名）：.NETの標準で動く。IIS Expressに依存せず、挙動も分かりやすい。
Docker/Container：本番同等環境の再現や、OS差分の吸収、複数サービス連携に強い。ただし準備と運用コストが増える。

「チュートリアルの範囲ではDockerは基本的に不要」というのは、Dockerが悪いのではなく、学習の目的に対して設定項目が増えすぎるのが理由です。まずはIIS ExpressまたはKestrelで動く状態を作り、必要になった段階でコンテナー化するのが失敗しにくい順番です。

最後に：迷ったら「起動プロファイル」と「出力ログ」で即断する

Dockerが動き出すなら、まず起動プロファイルがContainer/Dockerになっていないかを見る
直す最短手順は、上部ツールバーのドロップダウンでIIS Expressへ切り替えてF5
うまくいかないときは、出力（Output）ウィンドウで何を起動しようとしているかを確定させる
IIS Expressで詰まる場合は、.vs削除、HTTPS証明書、ポート競合の順で潰す

起動方式が意図どおりになれば、Visual Studio 2022でもASP.NET Coreをローカルでビルド・テストし、IIS Expressからブラウザで動作確認する流れに戻せます。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。