2026.07.29 インフラ

IISとは？Windows標準Webサーバーの構造・設定とApache・nginxとの使い分けを実装者向けに解説

Adureを利用したインフラ構築

IIS（Internet Information Services）は、Windowsに同梱されているMicrosoft製のWebサーバーソフトウェアです。別途インストーラを取得するのではなく、OSの役割として有効化して使う点が他のWebサーバーと異なります。この記事では、IISの定義と現行バージョンの前提、HTTP.sysからワーカープロセスに至る要求処理の経路、アプリケーションプールの分離設計、ASP.NET Coreのホスティング構成、Apacheやnginxとの使い分けまでを、サーバーを構築・運用する立場から整理しました。

まとめ：IISを採用する条件とApache・nginxとの使い分けの結論

IISを選ぶ判断は、性能比較ではなく「載せるアプリケーションとID基盤がWindowsに寄っているか」で決まります。ASP.NETやASP.NET Coreのアプリを動かし、社内のActive Directoryで認証を通し、運用チームがWindows Serverを見ているなら、IISが素直な選択です。この3つが揃っていない環境で、あえてWindowsライセンスを抱えてIISを立てる理由はほとんどありません。

逆に、静的配信やリバースプロキシが主な役割で、コンテナ前提のCI/CDに載せたいなら、nginxかApacheを選んだほうが運用は軽くなります。IISのコンテナイメージはWindowsコンテナに限られ、Linuxのノードプールでは動かせないためです。好みではなく構造的な制約になります。

判断の順番は、①アプリの実行基盤（.NET系か否か）→ ②認証方式（統合Windows認証の要否）→ ③配置先（Windowsコンテナを含むか）→ ④ライセンスとCALを含む総額、の4段階です。この順で潰せば候補は1つに絞れます。

IISの定義とWindows Serverにおける標準搭載という位置づけ

IISは、HTTP要求を受け取ってコンテンツを返すサーバーソフトウェアであると同時に、FTP・SMTP・WebDAVなどの機能を役割サービスとして束ねたパッケージでもあります。サーバーの役割と種類の分類の中では、HTTPを扱う実装のひとつという位置に収まります。

Internet Information Servicesという正式名称と読み方の整理

正式名称はInternet Information Servicesで、日本語では「アイアイエス」と読まれます。当初はInternet Information Serverという単数形の名称で登場し、後に複数のサービス群を束ねる呼称へ変わりました。設定ファイルやログには「W3SVC」「inetsrv」といった旧称由来の識別子が今も現れます。

Windows Serverの役割として提供される標準機能という前提条件

IISはWindows Serverの「役割」として提供され、サーバーマネージャーまたはPowerShellで有効化します。クライアント版のWindows 10・11にも「Windowsの機能の有効化または無効化」から追加できますが、同時接続数に制限があり本番の公開用途には向きません。

OS付属という性質はパッチ適用の経路にも影響します。IIS本体の修正はWindows Updateで配布されるため、Webサーバー単体でバージョンを上げ下げできません。OSとアプリケーションの間に位置するソフトウェア層の更新計画は、OSの保守計画と一体で組むことになります。

IIS 10.0系がWindows Server 2016以降で共通している事情

現行のメジャーバージョンは10.0系です。Windows Server 2016で10.0が登場して以降、2019・2022・2025のいずれも10.0系という表記が続いており、OSビルドに応じてリビジョン部分だけが変わります。バージョン番号だけを見て「同じ機能」と判断すると誤ります。HTTP/3の扱いのように、OS世代ごとに実装状況が違う機能があるためです。

調達時に確認すべきはIISの数字ではなくOSのサポート期限のほうでしょう。Windows Server 2016の延長サポートは2027年1月12日で終了する予定（Microsoftライフサイクル・2026年7月時点）であり、新規構築で2016を選ぶ余地はもうありません。

IISのアーキテクチャとHTTP.sysからワーカープロセスまでの処理経路

IISは単一のプロセスで完結せず、カーネルモードのドライバと複数のユーザーモードサービスが分業する構造です。トラブルを切り分けるには、要求がどの層を通るかを把握しておく必要があります。

カーネルモードで動くHTTP.sysと要求キューが担う処理の役割

クライアントからの接続を最初に受けるのはHTTP.sysというカーネルモードのドライバです。ここで接続の受け付け、TLSの終端、要求のパース、応答のカーネルキャッシュ、そしてアプリケーションプール単位の要求キューへの振り分けまでを担います。ユーザーモードのプロセスが落ちていても、HTTP.sysは要求をキューに溜められるため、プロセス再起動中の接続が即座にエラーにならない仕組みです。

この構造を知っていると障害時の見方が変わります。IISマネージャー上でサイトが起動していてもエラーが返る場合、キュー溢れ（HTTP 503）やTLSバインドの不整合など、HTTP.sys側で処理が止まっている可能性を先に疑えるでしょう。記録はアクセスログではなくHTTPERRログに残ります。

WASとW3SVCがワーカープロセスを起動するまでの流れの整理

要求がキューに入ると、WAS（Windows Process Activation Service）がアプリケーションプールの設定を読み、対応するワーカープロセスを起動します。W3SVCはHTTP固有の待ち受けとログ記録を担い、WASと連携してプロセスの生死を監視する役割です。異常終了しても、WASが自動的に再起動をかけます。

w3wp.exeの中でモジュールパイプラインが動く仕組みの解説

実際にコンテンツを生成するのはw3wp.exeというワーカープロセスです。この中では、認証・要求フィルタリング・圧縮・静的ファイル配信・マネージドハンドラといったモジュールが順に呼ばれます。モジュールはネイティブ（C++）とマネージド（.NET）の両方を登録でき、統合パイプラインモードならマネージドモジュールが静的ファイルの要求にも介入できる構造です。

どのワーカープロセスがどのプールに対応しているかはコマンドで確認できます。プロセスIDとプール名の対応が取れれば、メモリ使用量やCPU占有を特定のアプリまで追い込めます。

appcmd list wp
Get-Counter -Counter "\Web Service(_Total)\Current Connections"

アプリケーションプールの分離設計とリサイクル設定の実務的な勘所

IISの運用品質は、アプリケーションプールをどう切るかでほぼ決まります。ここを既定のまま複数アプリを同居させると、1本のアプリのメモリリークが全サイトを巻き込む構成になります。

アプリケーションプールを単位に障害を切り分ける分離設計の考え方

アプリケーションプールは、ワーカープロセスの実行単位であり、障害とセキュリティの境界でもあります。原則は業務システム1本につき1プールです。同居させてよいのは、同じチームが保守し、同じ資格情報でリソースへ接続し、同時に停止してよいアプリだけになります。

ApplicationPoolIdentityと権限設計で押さえる最小権限の原則

プールの既定の実行アカウントはApplicationPoolIdentityで、プールごとに固有の仮想アカウントが割り当てられます。この状態であれば、あるプールの侵害が他プールのファイルに直接波及しません。ドメインの共有フォルダやSQL Serverへ統合認証で接続する要件が出たときだけ、専用のドメインサービスアカウントへ切り替える判断が入ります。

切り替える際は、コンテンツフォルダの読み取り、ログ出力先の書き込み、一時ファイル領域の権限を個別に付与します。Administrators権限を渡す運用は監査で必ず指摘されます。

定期リサイクルとメモリ上限の設定がアプリ挙動に与える影響の整理

既定では一定時間ごとにワーカープロセスが再起動します。メモリリークを抱えたレガシーアプリを延命する仕組みとして機能する一方、インメモリのセッションを持つアプリではリサイクルのたびにログイン状態が失われます。セッションをSQL ServerやRedisへ逃がしていない構成では、この設定の見直しが先です。

設定項目 既定の考え方 見直す場面
定期リサイクル間隔 時間基準で自動再起動 インメモリセッション利用時
プライベートメモリ上限 未設定 リーク疑いのある既存資産
アイドルタイムアウト 無通信で停止 初回応答を短縮したい場合
オーバーラップリサイクル 新旧プロセス併存 排他ロックを使うアプリ

アイドルタイムアウトは、利用頻度が低い社内システムで初回応答の体感を悪くする代表的な設定です。停止させない運用に寄せるなら、アプリケーション初期化の機能でウォームアップ要求を投げる構成にします。

IISのインストールから公開までの手順と構成ファイルの階層構造

導入手順そのものは短時間で終わります。時間を取られるのは、その後の権限・証明書・構成管理のほうです。

役割と機能の追加とPowerShellによるインストールの実行手順

サーバーマネージャーのGUIからも導入できますが、同一構成を複数台へ展開するならPowerShellで揃えます。役割サービスは必要なものを最初に列挙しておくと再起動の回数を減らせます。

Install-WindowsFeature -Name Web-Server -IncludeManagementTools
Install-WindowsFeature -Name Web-Windows-Auth, Web-Dyn-Compression, Web-Http-Redirect

サイトとバインド設定でホスト名・ポート・証明書を割り当てる手順

サイトの作成では、物理パス・ポート・ホスト名・使用する証明書を指定します。1台で複数ドメインをHTTPS公開する場合はSNIを有効にし、証明書を各バインドへ結び付けます。台数が増えるなら、中央証明書ストアへ集約する方式が保守しやすいでしょう。

Import-Module IISAdministration
New-IISSite -Name "corp-app" -PhysicalPath "C:\inetpub\corp-app" -BindingInformation "*:443:app.example.co.jp" -Protocol https
Get-IISAppPool | Select-Object Name, State, ManagedRuntimeVersion

applicationHost.configとweb.configの階層と上書き関係

IISの構成はXMLファイルの階層で管理されます。サーバー全体の設定はapplicationHost.configに、サイトやアプリケーション単位の設定は各フォルダのweb.configに置かれ、下位が上位を上書きする仕組みです。開発者がアプリのリポジトリに含めたweb.configの内容が、そのまま本番の挙動を変える点は運用上の注意点になります。

上書きの可否はセクション単位でロックできます。要求フィルタリングなどアプリ側に触らせたくない項目はサーバー側でロックし、リライトルールだけ委譲する切り分けが実務的です。

ASP.NET CoreをIISでホストする場合のモジュール構成と設定

現行の.NET系アプリをIISに載せる場合、旧来のASP.NETとは仕組みが変わります。

ASP.NET Coreモジュールが担う要求転送とプロセス管理の役割

ASP.NET Core Module（ANCM）は、IISが受けた要求をASP.NET Coreアプリへ渡し、プロセスを起動・監視するネイティブモジュールです。サーバー側にはWindows向けのHosting Bundleを導入します。これが入っていない環境で発行物だけを配置しても、HTTP 500.19や500.31といったエラーで止まります。

インプロセス構成とアウトオブプロセス構成の違いと選択時の制約条件

ASP.NET Core 3.0以降、既定はインプロセスホスティングです。IIS内部のサーバー実装（IISHttpServer）がw3wp.exeの中で直接要求を処理するため、Kestrelへループバック経由で転送するアウトオブプロセス構成より応答が速くなります。一方で制約もあります。アプリプールの共有ができないこと、アプリと実行環境のビット数（x64かx86か）をプール設定と一致させること、単一ファイル発行の実行ファイルは読み込めないこと。この3点は事前に押さえておく必要があります。

アウトオブプロセスを選ぶのは、Kestrel前提の挙動をそのまま再現したい場合や、単一ファイル発行を維持したい場合に限られます。既定を外す理由は明文化しておくと引き継ぎで揉めません。

.NET Frameworkの既存資産とASP.NET Coreの共存を考える視点

1台のIISで、.NET Framework 4.x系のアプリとASP.NET Coreのアプリを同居させる構成は成立します。プールのマネージドランタイムを、前者は4.0系、後者は「マネージドコードなし」に設定して分けるだけです。

ただし恒久構成として残すと、OSの更新とランタイムの更新が二重にかかります。ランタイムの保守期限は.NET 10（LTS）のサポート期限と移行の考え方を基準に置き、同居期間の終わりを先に決めておくのが安全でしょう。統合Windows認証で社内ユーザーを識別している場合は、Microsoft Entra IDとActive Directoryの関係を踏まえて、認証方式の移行計画も同時に引く必要があります。

ApacheとnginxとIISの違いを運用管理の観点から比較する判断材料

機能の重なりは大きく、静的配信・リバースプロキシ・TLS終端はどれでもこなせます。差が出るのは、構成管理の方法と、動かす基盤の前提です。

観点 IIS nginx・Apache
動作OS Windowsのみ Linux中心・Windows可
構成管理 GUIとXML構成 テキスト設定ファイル
得意な実行環境 ASP.NET系 PHP・Java・Node.js系
統合Windows認証 標準で対応 追加モジュールが必要
コンテナ Windowsコンテナ限定 Linuxコンテナで軽量
ライセンス費 OS費用に含む ソフトは無償

構成管理がGUI中心か設定ファイル中心かで分かれる運用上の論点

IISはGUIで設定できる範囲が広く、少人数の運用では導入が早く進みます。半面、GUIでの変更は差分がレビューに乗らず、サーバーごとの設定ずれが起きやすい構成です。構成をコード管理したいなら、web.configやPowerShellスクリプトをリポジトリに置き、GUI操作は障害調査時の閲覧に限定します。

静的配信性能とリバースプロキシ用途から見たnginxとの比較軸

大量の同時接続を静的配信でさばく用途では、nginxのイベント駆動モデルが有利とされてきました。もっとも、IISもHTTP.sysのカーネルキャッシュを効かせれば応答は速く、差が問題になるのは高い負荷帯です。リバースプロキシの仕組みと導入判断で扱った振り分けや負荷分散の役割も、IISではApplication Request RoutingとURL Rewriteを追加すれば同様に構成できます。

分かれ目は性能値ではなく、前段をどのチームが運用するかにあります。ネットワーク側の担当がLinuxベースのプロキシを標準としているなら、前段はnginx、背後の業務アプリはIISという二層構成のほうが摩擦は少ないでしょう。

WindowsライセンスとCALを含めた総保有コストの見積り方法

IIS自体に追加費用はかからず、費用はWindows Serverのライセンスに集約されます。物理コア数に応じたライセンスに加え、社内利用ではユーザー数またはデバイス数に応じたCALが必要になるのが基本です。匿名の一般公開Webサイトの扱いは契約形態によって条件が異なるため、見積り段階でライセンス条項を調達担当と突き合わせてください。

IISを採用すべき条件と見送るべき場面を分ける実務上の判断基準

ここまでの内容を判断基準に落とします。

IISを選ぶ判断が成立する3つの前提条件と具体的な適用場面の例

次の3条件がすべて揃うなら、IISで進めて差し支えありません。第1に、載せるアプリがASP.NETまたはASP.NET Coreであること。第2に、Active Directoryの統合Windows認証を使う、あるいはSQL Serverへ統合認証で接続する要件があること。第3に、運用チームがWindows Serverの保守を既に回していることです。

典型的な適用場面は、社内向けの基幹系Webシステム、Windows端末からのみ触る管理画面、業務パッケージが前提とするWebフロントの3つでしょう。

IISを見送りLinux構成へ寄せるべき案件の条件と移行の進め方

反対に、次のいずれかに当たるならIISは選びません。アプリがPHP・Node.js・Java・Pythonで書かれている案件。Kubernetesを含むLinuxコンテナ基盤への配置が決まっている案件。そして、外部公開のみでActive Directoryの認証を使わず、サーバー台数が10台を超えてライセンス費が効いてくる案件です。

既存のIIS資産をLinuxへ寄せる場合、アプリを.NET 8以降へ移行できるかが最初の関門になります。移行できるならKestrel単体かnginxの背後で動かす構成に置き換えられるでしょう。移行できない.NET Framework資産は、Windows上に残すか、Windowsコンテナで包んで段階的に切り離す判断です。

クラウド移行でIISをそのまま持ち込む場合の構成上の注意点の整理

オンプレミスのIISをクラウドのVMへ持ち込むリフト移行は成立するものの、そのまま運ぶと3つの問題が残ります。1つ目はセッションのインメモリ保持で、複数台へ分散した瞬間にログイン状態が切れる点。2つ目はローカルディスクへの書き込み依存で、スケールアウト時にファイルの実体が分かれます。3つ目は証明書の手作業更新で、台数が増えるほど更新漏れが起きやすくなるでしょう。

先に手を入れるべきはセッションの外部化と、ファイル出力先の共有ストレージ化です。この2点を片付けないと可用性を上げる構成に進めません。Windows Serverを含むシステムのクラウド移行や移行後の運用設計はAWS・Azure・Google Cloudのインフラ構築支援で、現行構成の棚卸しから対応しています。既存資産をどこまで残すかの切り分けからご相談ください。

よくある質問

IISの検討でよく聞かれる質問を、判断に直結する形で5つ挙げます。

IISとApacheはどちらを選ぶべきですか？

載せるアプリの実行環境で決めます。ASP.NETやASP.NET CoreならIIS、PHPやJavaが主体ならApacheかnginxが素直です。性能差を理由に選ぶ場面はほとんどありません。判断で効くのは、統合Windows認証を使うか、Linuxコンテナに載せるか、運用チームがどちらのOSを見ているかの3点でしょう。

IISは無償で使えますか？

IIS単体の追加ライセンス費は発生せず、費用はWindows Serverのライセンスに含まれます。ただし社内利用ではユーザー数またはデバイス数に応じたCALが別途必要になるのが基本です。一般公開のWebサイト用途は条件が異なる場合があるため、契約形態ごとに条項をご確認ください。

IIS 10.0のバージョンはWindows Serverごとに違いますか？

メジャーバージョンは10.0で共通ですが、リビジョンはOSビルドごとに異なります。Windows Server 2016で10.0が登場し、2019・2022・2025も10.0系という表記が続いている状態です（2026年7月時点）。同じ10.0でも機能差はあり、HTTP/3は2022で実験的サポート、2025でHTTP.sysに統合されました。

IISでPHPやNode.jsは動きますか？

動きます。PHPはFastCGIモジュール経由、Node.jsなどのプロセスはHttpPlatformHandlerやApplication Request Routingを介した転送で動作します。とはいえ、これらの言語の運用ノウハウはLinux前提のものが大半です。既にWindows環境で運用している事情がないかぎり、無理にIISへ寄せる利点は小さいでしょう。

IISのログとエラーはどこを見ればよいですか？

アクセスログは既定でinetpub配下のLogFilesに、HTTP.sysレベルのエラーはHTTPERRログに出力されます。アプリ側の例外はイベントログとアプリ固有のログのほうに残るでしょう。500系が返るのに手掛かりがない場合は、失敗した要求トレース（FREB）を有効化すると、どのモジュールで止まったかまで追えます。切り分けはHTTPERR、アクセスログ、FREB、アプリログの順が効率的です。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る