現場でこの依頼が出てくるきっかけは、だいたい次のどれかです。
情報漏えい対策として「社員がどのサイトを見ているか記録できるようにしたい」と経営層から言われた。テレワークが増えて「VPN をつながなくても申請システムを使えるようにしてほしい」と業務部門から要望が来た。あるいは、前任者が作ったらしい古いサーバーが保守期限を迎えていて、同じものを作り直すべきか判断がつかない。
きっかけは違っても、どれも「プロキシ」という言葉に行き着きます。しかし、この 3 つは技術的にはまったく別の話です。
端末側の設定：Windows 端末に「この経路を通れ」と指定する作業。すでにあるプロキシを使うための設定であって、構築ではありません
出口プロキシ ( フォワードプロキシ )：社内から外部へ抜けていく通信を中継し、フィルタリングやログ取得を行う仕組み
リバースプロキシ：外部から社内の Web システムへのアクセスを、いったん受け止めて橋渡しする仕組み
どれが必要かは、最初のきっかけによって変わります。ログを取りたいのなら 2 番目、社外から使わせたいのなら 3 番目です。まずは自社の依頼がどれに当たるのかを言語化するところから始めることをおすすめします。ここが曖昧なまま手を動かすと、作ったあとで「求めていたものと違う」となりかねません。
先に、いちばん引っかかりやすい部分を書いておきます。
Windows Server には、社内から外部への通信を中継する出口プロキシの標準機能がありません。
Microsoft の公式ドキュメントで「Windows でプロキシ サーバーの設定を構成する」という記事を見つけると、これが構築の手順書に見えます。ただし内容は、WPAD による自動検出、グループポリシーでの配布、PAC ファイルの指定といった、プロキシを「使う側」の設定です。同じ記事の中でプロキシ製品として挙げられているのは Microsoft Forefront Threat Management Gateway ( TMG ) ですが、これはクライアントソフトウエアの説明として登場するもので、現行の Windows Server で新規に立てられる役割ではありません。
では、Windows 環境で出口プロキシが必要になったらどうするか。現実的には次のいずれかです。
ただし、1 番目には注意点があります。Squid の Windows 版を紹介している記事でも、クライアント OS 上でこうしたサーバーサービスを常用するのは、利用者が数名程度の小規模環境にとどめるべきだと書かれています。検証環境で動いたからといって、そのまま全社の通信を通す前提にはしにくい、ということです。
出口対策としてのプロキシをどう扱うか ── 作るのか、UTM に寄せるのか ── については、機能単位での代替可否を別記事で整理しています。出口制御が主目的の方は、そちらもあわせてご覧いただくと判断が進みます。
本記事では以降、Windows Server で構築対象になり得る「社内 Web の外部公開」、つまりリバースプロキシ用途を中心に扱います。
社内ポータル、申請システム、勤怠管理、取引先向けサイト。こうした Web システムを社外から使わせたい、というのが、Windows で構築を検討する最も一般的な場面です。選択肢は大きく 3 つあります。
Windows Server のリモートアクセス役割サービスとして提供される、リバースプロキシ機能です。企業ネットワークの外部にいる利用者が、内部サーバー上の Web アプリケーションへ安全にアクセスできるようにします。Windows Server 2025 まで継続して提供されており、HTTP から HTTPS へのリダイレクト、ワイルドカードドメインでの発行、リモートデスクトップゲートウェイの発行などにも対応します。
問題は前提条件の重さです。WAP は Active Directory フェデレーションサービス ( AD FS ) と統合して事前認証を提供する設計で、AD FS 4.0 以降のファームが必要になります。加えて、WAP サーバー自体はドメインに参加させず DMZ に配置する構成が前提で、AD FS のサービス名と公開するすべてのアプリケーションのホスト名をカバーする SSL 証明書も要ります。
すでに AD FS を運用している企業なら自然な選択ですが、AD FS を持っていない企業が WAP のためだけに AD FS を新設するのは、構築も運用も相応の重さになります。ここは正直に見積もっておきたい部分です。
IIS 自体にはリバースプロキシ機能がないため、Application Request Routing と URL Rewrite の 2 つのモジュールを追加インストールして実現します。設定は IIS マネージャーの GUI から行え、受信規則に転送先のサーバー名か IP アドレスを入力すれば、基本的な転送は成立します。負荷分散やディスクキャッシュ、複数バックエンドへの振り分けも扱えます。
WAP と比べて前提が軽い一方で、認証を前段で行う機能は持ちません。誰でもアクセスできる状態で公開するわけにはいかないため、アプリケーション側の認証に依存するか、別の仕組みを重ねる必要があります。また、URL の書き換えパターンや SSL の扱いで想定外の挙動が出やすく、実務では検証に時間がかかったという報告も見られます。設定が担当者の頭の中にだけ残りやすい構成でもあります。
オンプレミスのアプリケーションへのアクセスをクラウド経由で提供する仕組みで、Microsoft の公式ドキュメントでも WAP の説明ページから案内されています。社内側に配置したコネクター経由で中継するため、外部から社内へ向けた受け口を開けずに済み、Entra ID の多要素認証や条件付きアクセスを Web アプリの入口に乗せられる点が特徴です。
ただし、こちらも万能ではありません。Web アプリケーションを対象とした仕組みであり、VPN を全面的に置き換えるものではないという点は押さえておく必要があります。主用途がリモートデスクトップ接続やファイルサーバー共有、あるいは非 Web のアプリケーション中心であれば、守備範囲の外です。
ここまでの内容を、目的単位で整理します。
凡例：⭕ 標準機能で対応可 / 🔺 追加コンポーネントや条件付きで対応可 / ❌ 標準機能では対応困難
|
# |
やりたいこと |
Windows Server 標準 |
現実的な手段 |
先に決めておくこと |
|
1 |
端末へのプロキシ設定配布 |
⭕ |
グループポリシー、WPAD、PAC ファイル |
配布対象の範囲、例外にする社内サイト |
|
2 |
出口の Web フィルタリング |
❌ |
サードパーティー製プロキシ、UTM、クラウド SWG |
カテゴリー制御か URL 個別かの運用方針 |
|
3 |
出口の通信ログ取得 |
❌ |
同上 |
保存期間、閲覧権限、労務面の整理 |
|
4 |
社内 Web の外部公開 |
🔺 |
WAP、IIS + ARR |
公開対象を業務上必要なものに絞れるか |
|
5 |
公開アプリの事前認証 |
🔺 |
WAP + AD FS |
AD FS を新設するのか、Entra 側に寄せるのか |
|
6 |
SSL 終端・証明書集約 |
🔺 |
WAP、IIS + ARR |
証明書の種類、有効期限、更新の担当者 |
|
7 |
キャッシュによる帯域節約 |
❌ |
プロキシ製品固有の機能 |
そもそも HTTPS 化で効きにくくなっている前提 |
|
8 |
拠点・在宅勤務者への適用 |
❌ |
クラウド側で適用する仕組み |
本社集約型で足りるかどうか |
2 番と 3 番だけが目的なら、Windows Server で作る話ではありません。出口対策として UTM や SWG を比較対象に加えたほうが、判断を誤らずに済みます
4 番と 5 番はセットで考えてください。認証なしで公開する構成は、実質的に選べません。5 番をどう満たすかで、WAP か Entra 側かが分かれます
6 番の「更新の担当者」が空欄のまま進む案件が、いちばん多いように感じます。後述しますが、ここが事故の起点になります
8 番が要件に入っている場合、Windows Server 側で完結させる構成は難しくなります
なお、この表で決めきれない領域も残ります。たとえば「公開したい業務システムが 1 つだけ」なのか「今後 5 つ、10 つと増える見込み」なのかで、初期構築の重さをどこまで許容するかは変わります。表は出発点であって、答えそのものではないとお考えください。
WAP や IIS + ARR で社内 Web を公開する場合の流れを、判断ポイントを軸に整理します。コマンドやウィザードの詳細は公式ドキュメントに委ね、ここでは迷いやすい部分を扱います。
どの業務システムを社外から使わせるかを決めます。全社共通の情報系なのか、経理や人事といった特定部門の申請系なのか、取引先を含む社外の相手が触るものなのか ── 利用者の性質によって、必要な認証の強さも変わります。対象を 1 つ増やすたびに、公開ルールが 1 本、証明書の管理対象が 1 つ、そして障害時の確認手順が 1 項目ずつ積み上がる、と考えておくとよいでしょう。
迷いやすいポイント：「とりあえず全部公開しておいて、後で絞る」という進め方は、実際には絞られません。業務上の必要性を部門ごとに確認し、最小限から始めるほうが、後の運用が軽くなります。
外部から内部のサーバーへ直接パケットが届かない位置に置く、というのが基本の考え方です。WAP を選ぶ場合、サーバーをドメインに参加させず DMZ に置く前提がある点に注意してください。周辺との関係も同時に確認が要ります。手前にファイアウォールや負荷分散装置がある構成なら通過ルールの調整が、公開名を新しく切るなら DNS レコードの手当てが、それぞれ発生します。
迷いやすいポイント：内部側のファイアウォールで、公開サーバーから AD FS へ届く経路を開ける必要があります。ネットワーク担当と情シスが分かれている組織では、ここの調整が想定より時間を要します。
外部から社内システムへアクセスさせる以上、本人確認の仕組みは避けて通れません。WAP であれば AD FS と連携した事前認証、Entra 側に寄せるなら条件付きアクセス、というように、選んだ手段によって設計が変わります。あわせて、HTTPS で通信するための SSL / TLS 証明書が必要です。
迷いやすいポイント：証明書は「取得すること」より「更新し続けること」のほうが難しい項目です。公開 URL、有効期限、更新の担当者、更新作業の手順 ── この 4 点を、構築時に文書として残しておくことをおすすめします。
ここで決めるのは、社外から見える名前と、社内で動いている実体との対応関係です。利用者がブラウザーに入力するアドレスに対して、どのサーバーのどのパスを返すのか。1 対 1 で素直に対応させるのか、パスの一部を書き換えて渡すのか。あわせて、そのルールに認証を挟むのか、特定の部署だけに開くのかも、この段階で線を引いておきます。
迷いやすいポイント：IIS + ARR の場合、URL の書き換えパターンを正規表現で記述するため、想定外のパスまで転送されるケースがあります。パターンのテスト機能を使って、意図した URL だけが対象になっているかを確認してから公開へ進んでください。
社外ネットワークからアクセスし、認証、画面表示、転送先、エラー表示を確認します。ここで「つながった」だけで終わらせないことが大切です。
正常系に加えて、次の 3 つの異常系を組で確認しておくと、後の障害対応が楽になります。
権限のない利用者がアクセスしたとき、意図したとおりに拒否されるか
内部の Web サーバーが停止しているとき、どんな画面が表示されるか
証明書の期限が切れた状態を模擬したとき、利用者に何が見えるか
3 番目は面倒に感じるかもしれませんが、実際に起きたときに「利用者から何と言われるか」を事前に知っておく価値はあります。
構築が終わってから効いてくる論点を、時系列で並べてみます。
稼働直後は、たいてい快調です。 社外から社内システムが使える。VPN をつながなくてよくなった。業務部門からの評判もよい。ここまでは想定どおりです。
半年ほど経つと、公開申請が増え始めます。 「あのシステムも外から使えるようにしてほしい」という依頼が、部門ごとにやってきます。申請フォーム、承認者、反映タイミングを決めていないと、依頼はメールで届き、担当者の受信箱の中で管理されることになります。
1 年後、証明書の更新期限が来ます。 ここが最も事故が起きやすい場所です。更新担当が明確でない、更新手順が前任者の記憶の中にある、そもそも期限をカレンダーに入れていない ── どれか 1 つでも当てはまると、期限切れの当日まで気づきません。しかも、この種の期限は不思議と金曜の夜や連休の前に設定されていることが多いものです。
同じころ、AD FS への依存が問題として浮上します。 WAP は AD FS ファームの存在が前提で、AD FS 自体にも更新とサポート期限があります。WAP を維持するために AD FS を維持する、という構造になっていることを、構築時点で意識しているケースは多くありません。
そして、公開の入口は単一障害点になります。 外部からのアクセスをすべて 1 台で受けている構成では、その 1 台が止まった瞬間に、社外からの利用が一斉に止まります。冗長化を検討するかどうかは規模次第ですが、「止まったら何が起きるか」を業務部門と共有しておくことは、規模を問わず必要です。
もう 1 つ、端末側の配布についても触れておきます。グループポリシーでプロキシ設定を配ろうとしたものの、Internet Explorer のメンテナンス拡張機能が非推奨になった影響で、従来の方法では設定が意図どおりに反映されないケースが報告されています。「昔のやり方が今も効く」とは限らないため、検証環境での確認を挟むことをおすすめします。
これらは、担当者の準備不足というより、少人数で運用する構造上、後回しになりやすい項目です。だからこそ、構築の判断段階で織り込んでおく意味があります。
ここまで構築側の話を書いてきましたが、逆側からも見ておきます。
Microsoft Entra アプリケーションプロキシに寄せる：社内側にコネクターを置く方式のため、外部へ向けた受け口を開けずに済みます。既存の社内 Web を活かしながら、対象アプリケーション単位で始められる点も現実的です
UTM に集約する：出口の Web フィルタリングと悪性サイト遮断が主目的なら、機器を集約して運用対象を減らす方向があります
クラウド型 SWG に寄せる：拠点や在宅勤務者が多い場合、本社集約型より適合するケースがあります
VPN を継続する：ファイルサーバー共有やリモートデスクトップが主用途なら、そもそも VPN のほうが自然です
何も整理しないまま時間が過ぎると、次のような状態が残ります。
業務システムをファイアウォールのポート開放で直接公開したまま、攻撃対象を広げた状態が続く
VPN の到達範囲が社内ネットワーク全体のまま、誰がどこまで届くのかを誰も説明できない
退職者や外部協力会社の VPN アカウントが Excel 台帳の中でだけ管理され、失効が漏れる
誰がいつ社内システムにアクセスしたかのログが、どこにも残っていない
これらは、プロキシを作るか作らないかとは別に、整理が必要な項目です。「Windows で作らない」を選ぶ場合も、どの手段で同じ課題に手当てするのかは決めておく必要があります。逆に言えば、ここが決まっていれば、Windows Server で作らないという判断も十分に成り立ちます。
どちらの側にも、コストと手間はあります。楽なほうを選ぶ話ではなく、自社で回せるほうを選ぶ話だとお考えください。
最後に、プロキシを単体ではなく、社内 IT 全体の中で見てみます。役割で分けると、次のような整理になります。
認証基盤 ( Active Directory、Entra ID、RADIUS など )：誰が入るかの統制
入口・出口対策 ( ファイアウォール、UTM、プロキシ )：何が通るかの統制
内部対策 ( ネットワーク分離、セグメンテーション )：入られたあと、どこまで広がるかの統制
社内 Web の公開は、このうち認証基盤と入口対策にまたがるテーマです。WAP + AD FS の構成が「認証」と「公開」の両方を扱っているのは、そのためです。
そして、どの層を整えてもツールでは決まらない部分が残ります。
公開申請を誰が承認するのか
退職時に、何日以内にアクセス権を止めるのか
証明書の更新を、いつ、誰が、どの手順で行うのか
障害時に、どの順番で切り分けるのか
これらは運用ルールの話であり、製品を導入しても自動的には決まりません。逆に、ここが決まっていれば、選んだ手段が WAP でも Entra でも、運用は回りやすくなります。
プロキシを「点」で作るのではなく、認証・入口・内部の 3 層のどこが手薄かを一度棚卸ししてから位置づける ── 遠回りに見えて、結果的には早い進め方だと考えています。
用途によります。社内 Web を社外から使わせるリバースプロキシであれば、Web Application Proxy や IIS + ARR という手段があります。一方、社内から外部への通信を制御する出口プロキシについては、Windows Server の標準機能では対応していません。サードパーティー製ソフトウエアを載せるか、UTM やクラウド型のサービスに寄せるかを検討することになります。まずは「どちらの用途か」を切り分けるところから始めるとよいでしょう。
Web Application Proxy は AD FS と統合して事前認証を提供する設計になっており、AD FS 4.0 以降のファームが前提として案内されています。パススルー認証のシナリオにも対応しますが、その場合は認証を前段で行わない構成になるため、アプリケーション側の認証に依存します。AD FS を現在運用していない場合は、そのために新設する重さと、Microsoft Entra 側に寄せる選択肢を並べて比較することをおすすめします。
大まかには、認証を前段で行いたいかどうかが分かれ目になります。IIS + ARR は追加モジュールを入れれば比較的手軽に転送を構成できますが、事前認証の機能は持ちません。WAP は前提条件が重い代わりに、認証済みの利用者だけを内部アプリケーションへ通す構成が組めます。社内向けの負荷分散やパス単位の振り分けが主目的なら IIS + ARR、社外公開で認証を必須にしたいなら WAP、という整理が出発点になります。
用途によって使い分ける話だと考えています。ファイルサーバー共有やリモートデスクトップ接続、複数の非 Web システムをまとめて使いたい場合は、VPN のほうが自然です。一方、ブラウザーで使う業務アプリケーションだけを社外から使わせたいのであれば、アプリケーション単位で公開できる仕組みのほうがシンプルになる場合があります。どちらか一方に寄せるのではなく、用途ごとに分けて考えるほうが現実的です。
「同じ構成で更新する」「Windows Server で作り直す」「Entra 側に寄せる」「UTM やクラウド型に集約する」を並べて比較するのが出発点になります。判断材料は、現在のプロキシで実際に使っている機能 ( 出口制御か、公開用途か、認証を含むか )、拠点構成、在宅勤務の比率、そして社内で運用を継続できるかどうかです。保守期限は、単なる置き換えではなく、公開のあり方を見直す機会として捉えると、長期的な負荷を下げやすくなります。
Windows でプロキシサーバーを構築するという話は、実際には「端末に設定を配る」「出口を制御する」「社内 Web を公開する」の 3 つに分かれます。このうち出口制御については、Windows Server の標準機能では対応していないという前提を、最初に押さえておく必要があります。
社内 Web の公開であれば、Web Application Proxy、IIS + ARR、Microsoft Entra アプリケーションプロキシという選択肢があります。ただし、それぞれに前提条件と守備範囲があり、どれも万能ではありません。判断は、次の 3 点を並べたときに見えてきます。
目的の分解：自社が解決したいのは、出口制御か、外部公開か、端末配布か
前提条件の確認：AD FS を持っているか、証明書を誰が更新するか、公開対象は増える見込みか
運用の見立て：作ったあと 3 年、5 年を、誰がどう回すのか
そのうえで、「Windows で作る」「Entra に寄せる」「UTM に集約する」を並べて比較する ── この順序で進めると、後戻りが減ります。
横河レンタ・リース株式会社では、ITインフラの設計・構築から運用支援、保守期限への対応まで、企業の環境に合わせたご相談を承っています。「Windows Server で作るべきか、そもそも作らない選択肢があるか」といった要件整理の壁打ちからでも構いませんので、必要に応じてお声がけください。