【Windows Server入門 第4回】Windows版Webサーバー「IIS」入門。Nginx使いが知るべき作法の違い

「Nginxでよくない？」と言わせない、IISの真の実力。

こんにちは！「LINUX工房」管理人の「リナックス先生」です。
前回は、ファイルサーバーの権限管理（NTFS/ReFS）について学びました。
WindowsならではのACL（アクセスコントロールリスト）の考え方は、セキュリティの基本となるのでしっかり復習しておいてください。

さて、今回はWebサーバーの話です。
Linuxエンジニアなら、Webサーバーといえば「Nginx」か「Apache」が定石ですよね。
しかし、Windows ServerにはOS標準の強力なWebサーバー「IIS（Internet Information Services）」が搭載されています。

本記事では、IISの独自のアーキテクチャ、設定ファイル web.config の読み方、リバースプロキシとしての利用法、そしてPowerShellを使ったCUI管理術までを解説します。

---

第1章：アーキテクチャ比較。Nginx vs IIS

まずは、Linuxエンジニアに馴染みのあるNginxと比較しながら、IISの構造を理解しましょう。

1. プロセスモデルの違い

• Nginx: イベント駆動型。1つのマスタープロセスと少数のワーカープロセスで、数万のリクエストを非同期に処理します。C10K問題に強い設計です。
• IIS: プロセス分離型。「アプリケーションプール」という単位でワーカープロセス（w3wp.exe）が起動します。リクエストはOSカーネルレベルのドライバ（http.sys）が受け取り、適切なプールへ振り分けます。

2. http.sys（カーネルモード）の衝撃

IISの最大の特徴は、HTTPリスナーがユーザーモード（アプリ層）ではなく、カーネルモード（OS層）にあることです。
http.sys というドライバがポート80/443を監視し、キャッシュにあるコンテンツなら、ユーザーモードのプロセス（IIS本体）すら通さずに即座にレスポンスを返します。
これにより、静的ファイルの配信においてはNginxと同等か、環境によってはそれ以上の速度が出ます。

3. 設定ファイルの構造

項目	Nginx	IIS
全体設定	nginx.conf	applicationHost.config (C:\Windows\System32\inetsrv\config\)
サイト個別設定	conf.d/*.conf	各ディレクトリ直下の web.config
フォーマット	独自フォーマット	XML
設定反映	systemctl reload nginx	即時反映 (ファイル変更を検知して自動リロード)

---

第2章：重要概念「アプリケーションプール」とは？

Linuxエンジニアが最も戸惑うのがこの「アプリケーションプール（App Pool）」です。
これは、PHP-FPMの「プール」に近い概念ですが、より強力な隔離機能を持っています。

なぜプールを分けるのか？

1つのIIS上で、サイトA（社内ポータル）とサイトB（公開Webサイト）を動かすとします。
もしサイトAのプログラムにバグがあり、メモリリークを起こしてクラッシュしたらどうなるでしょうか？

• プールが同じ場合： 道連れでサイトBも落ちます。
• プールを分けた場合： サイトAのプロセス（w3wp.exe）だけが落ちて自動再起動します。サイトBは無傷です。

【プロの鉄則】
Webサイトを作成する際は、必ず「サイトごとに専用のアプリケーションプール」を作成してください。
デフォルトの DefaultAppPool を使い回すのは、テスト環境だけにしておきましょう。

リサイクル設定

IISには「定期的にプロセスを再起動してメモリを浄化する」という機能（リサイクル）が標準で備わっています。
デフォルトでは「1740分（29時間）ごと」に設定されています。
「毎日決まった時間に一瞬重くなる」という現象があれば、このリサイクル設定を疑ってください。

---

第3章：設定ファイル `web.config` の読み書き

Nginxの .conf に相当するのが web.config です。
Apacheで言う .htaccess に近いですが、より権限が強く、IISのほぼ全ての設定を記述できます。

基本構造（XML）

XML形式なので、タグの閉じ忘れに注意が必要です。

<configuration>
  <system.webServer>
    <!-- ここにIISの設定を書く -->
    
    <!-- デフォルトドキュメントの設定 -->
    <defaultDocument>
      <files>
        <add value="index.php" />
      </files>
    </defaultDocument>

    <!-- ディレクトリ参照の禁止 -->
    <directoryBrowse enabled="false" />
    
  </system.webServer>
</configuration>

継承の仕組み

web.config は階層構造を持ちます。
ルートディレクトリの web.config の設定は、サブディレクトリにも自動的に適用されます。
サブディレクトリに別の web.config を置けば、設定を上書き（オーバーライド）できます。

---

第4章：権限設定の罠。「IIS AppPool\User」とは？

Webサーバーがファイルを読み書きするには、ファイルシステムの権限（NTFSアクセス許可）が必要です。
Nginxなら nginx ユーザーや www-data ユーザーに権限を与えますよね。
では、IISはどのユーザーで動いているのでしょうか？

仮想アカウントの正体

デフォルトでは、アプリケーションプールごとに「仮想アカウント」が自動生成されます。
ユーザー名は IIS AppPool\[プール名] です。
例えば、プール名が MyWebApp なら、ユーザー名は IIS AppPool\MyWebApp となります。

権限付与の手順

「セキュリティ」タブでユーザーを追加する際、場所を「ローカルコンピュータ」にし、以下の名前を入力して「名前の確認」を押します。

IIS AppPool\MyWebApp

これで、そのWebサイト専用のプロセスだけがアクセスできる権限設定が可能になります。
IUSR や Users グループに権限を与えがちですが、セキュリティ的には AppPoolIdentity（仮想アカウント） を使うのがベストプラクティスです。

---

第5章：実践！PowerShellでWebサーバー構築

GUIでポチポチするのはやめましょう。
PowerShellを使えば、IISのインストールからサイト作成まで一瞬で完了します。

1. IISのインストール

# 管理ツールを含めてWebサーバー機能をインストール
Install-WindowsFeature -Name Web-Server -IncludeManagementTools

2. デフォルトサイトの削除と新規サイト作成

ポート80を使う「Default Web Site」は邪魔なので停止・削除し、自分のサイトを作ります。

# デフォルトサイトの停止と削除
Stop-Website -Name "Default Web Site"
Remove-Website -Name "Default Web Site"

# アプリケーションプールの作成
New-WebAppPool -Name "MyPool"

# ドキュメントルートの作成
New-Item -Path "C:\inetpub\mysite" -ItemType Directory
Set-Content -Path "C:\inetpub\mysite\index.html" -Value "<h1>Hello IIS</h1>"

# サイトの作成（ポート80, 指定プールを使用）
New-Website -Name "MySite" -Port 80 -PhysicalPath "C:\inetpub\mysite" -ApplicationPool "MyPool"

3. web.config の操作

PowerShellの WebAdministration モジュールを使えば、XMLを直接編集せずに設定を変更できます。

# ディレクトリ参照を有効化する例
Set-WebConfigurationProperty -Filter /system.webServer/directoryBrowse -Name enabled -Value True -PSPath "IIS:\Sites\MySite"

これで、Ansible等を使ったIaC（Infrastructure as Code）への道が開けましたね。

---

第6章：リバースプロキシとしてのIIS（ARRとURL Rewrite）

最近のWindows開発では、ASP.NET Coreアプリ（Kestrelサーバー）の前段にIISを置く「リバースプロキシ構成」が一般的です。
Nginxの proxy_pass に相当する機能です。

必要なモジュール

標準機能ではありません。以下の2つを追加インストールする必要があります（Web Platform Installer等を使用）。

1. URL Rewrite Module: Nginxの rewrite や location に相当。
2. Application Request Routing (ARR): プロキシ機能本体。

web.config での設定例

localhost:5000 で動いているアプリへ転送する設定です。

<configuration>
  <system.webServer>
    <rewrite>
      <rules>
        <rule name="ReverseProxyInboundRule1" stopProcessing="true">
          <match url="(.*)" />
          <action type="Rewrite" url="http://localhost:5000/{R:1}" />
        </rule>
      </rules>
    </rewrite>
  </system.webServer>
</configuration>

これで、IISを入り口として、バックエンドのNode.jsやPython、ASP.NET Coreアプリにリクエストを流すことができます。

---

まとめ：IISは「見えないところ」が凄い

お疲れ様でした！
第4回は、Windows ServerのWebサーバー機能、IISについて解説しました。

今回の重要ポイント：

• IISはOSカーネル（http.sys）と統合されており、静的配信が爆速。
• アプリケーションプールを分けることで、障害の影響を局所化できる。
• 設定ファイルは web.config（XML）。階層構造で管理される。
• 権限設定は IIS AppPool\[プール名] という仮想アカウントを使う。
• ARRとURL Rewriteを使えば、Nginxのようなリバースプロキシも可能。

さて、ここまでは「純粋なWindows」の話をしてきましたが、実は最近のWindows Serverは「Linuxを取り込む」方向に進化しています。
Windowsの中でLinuxが動く……そんな夢のような技術が、本番環境でも使えるレベルになってきているのです。

次回、第5回は「WSL2とWindows Terminal。Windows上でLinuxを飼い慣らすハイブリッド開発環境」です。
単なるエミュレータではない、本物のLinuxカーネルをWindows上で動かす技術と、SSHクライアントとしても優秀なWindows Terminalの活用法を紹介します。お楽しみに！