Azureで本格的なWebアプリケーションを運用する際、ロードバランサーやセキュリティ対策として欠かせないのが「Azure Application Gateway（以下、AppGw）」です。
しかし、いざAzureポータルから作成しようとすると、
SKU（レベル）はどれを選べばいい？
お金とセキュリティ的に何を選んだらいいかわからない
HTTP/2やFIPSって有効にすべき？
そもそもどういう機能なのかわからない
といった、多くの設定項目や仕様の壁にぶつかりがちです。
そこで本記事では、2026年現在の最新のAzureポータル画面に対応した、AppGwの作成手順を画像付きで徹底解説します！
構築時に迷いやすい各パラメーターの意味（SKU、自動スケール、IPアドレスの種類など）もあわせて整理しているので、この記事通りに進めれば、初心者の方でも迷わずセキュアなインフラ環境を構築できます。
💡 AppGwの基本をおさらいしたい方へ
「Application Gatewayの概要や役割、仕組みがよくわからない。」という方は、
先にこちらをご覧ください。
1. Azure Application Gateway作成前の準備
Azure Application Gateway（以下、AppGw）は、単体ですぐに作成できるリソースではありません。
作成画面を進める前に、ネットワークや、通信の届け先となるリソースをあらかじめ用意しておくとスムーズにAppGWが作成できます。
手戻りなくスムーズに構築を完了させるために、以下の3つの準備を済ませておきましょう。
- ① 仮想ネットワーク（VNet）
- ② AppGw専用のサブネット
- ③ バックエンド（ターゲット）となるリソース
AppGwを作成する際に、①~③も一緒に作成することも可能です。
2. 【基本設定】SKU・自動スケール・各種機能の解説
準備が整ったら、Azureポータルから「アプリケーション ゲートウェイ」の作成画面に進みます。
最初の「基本」タブでは、AppGwの性能やセキュリティの根幹に関わる重要な項目を設定します。
レベル（SKU）の違いと選び方
「レベル」または「SKU（Stock Keeping Unit）」と呼ばれる項目で、AppGwのグレードを決定します。レベルは3種類用意されています。
| SKU（レベル） | 特徴・主な用途 | WAFの関連付け |
| Basic | コスト重視。 開発・検証環境や小規模な内部システム向け | × 不可 |
| Standard V2 | 本番環境の標準的なWebアプリ向け | × 不可 |
| WAF V2 | セキュリティ要件が高い本番システム向け | ○ 可能 |
外部に公開する一般的なWebサイトや、企業のセキュリティガバナンスが厳しいシステムでは「WAF V2」一択となります。
セキュリティ対策は別途前段（Front Door等）で行う、あるいはコストを抑えたい検証用途であれば「Standard V2」や「Basic」を選びましょう。
自動スケール（オートスケール）設定のオン/オフ
Standard V2およびWAF V2では、トラフィックの増減に応じて処理能力を自動で調整する「自動スケール」が利用できます。
- オン（推奨）：
- アクセス急増時にもサーバーがダウンしないよう、自動でインスタンスが増減します。「最小インスタンス数（最低限維持する台数）」と「最大インスタンス数（これ以上増やさない上限）」を設定します。
- アクセス急増時にもサーバーがダウンしないよう、自動でインスタンスが増減します。「最小インスタンス数（最低限維持する台数）」と「最大インスタンス数（これ以上増やさない上限）」を設定します。
- オフ（手動スケール）：
- インスタンス数を固定します。アクセス数が完全に予測できており、「想定外のスケールによるコスト変化を防ぎたい」という明確な理由がある場合のみオフ（手動）に設定します。
HTTP/2の有効化
「HTTP/2」は、従来のHTTP/1.1に比べてWebサイトの表示速度や通信効率を大幅に向上させるプロトコルです。
基本的には「有効」のままで問題ありません。
主要なWebブラウザはすべてHTTP/2に対応しているため、有効にすることでユーザーの体感速度向上につながります。
FIPS（連邦情報処理規格）とは？
「FIPS（Federal Information Processing Standards）」は、米国政府が策定した暗号化モジュールに関するセキュリティ基準です。
一般的な日本国内の商用Webサイトやブログであれば、「無効」（デフォルト）のままで問題ありません。
3. 【フロントエンドIP】パブリックとプライベートの選択
次の「フロントエンド」タブでは、AppGwがユーザーや他システムからのアクセスを待ち受けるためのIPアドレスを設定します。
フロントエンド IP の種類（3つのパターン）
設定画面では、IPアドレスの種類として以下の3つから選択できます。
- パブリック：
- インターネット経由のアクセスを待ち受けます（一般的なWebサイトや公開APIなど）。
- プライベート：
- 仮想ネットワーク（VNet）内や、VPN/ExpressRouteで接続された社内ネットワークからのアクセスのみを待ち受けます（社内システムなど）。
- 両方：
- インターネットと社内ネットワーク、両方からのアクセスを同時に待ち受けます。
💡 プライベート限定で運用したい場合の対策（回避策）
Standard_v2 および WAF_v2 のSKUでは、「プライベートIPのみ」の構成がサポートされていません。
社内専用として使いたい場合は、「両方」を選択し、ダミーのパブリックIPアドレスを強制的に1つ作成して紐付ける必要があります。
その上で、インターネットからの不要なアクセスを防ぐために、以下のどちらかの対策を行います。
- ネットワークセキュリティグループ（NSG）での制御
- ルーティング規則（リスナー）での制御を行いましょう。
このように、「内部向けに作りたくても、パブリックIPの作成と紐付けは必須になる」という仕様をあらかじめ理解しておきましょう。
4. 【バックエンドプール】ターゲットに指定できるリソース
続いて「バックエンド」タブの設定です。
「バックエンドプール」とは、フロントエンドIPで受け取ったWebトラフィックを、Application Gateway（以下、AppGw）が最終的にどこに転送（負荷分散）するかを指定するグループのことです。
バックエンドターゲットの種類と追加方法
設定画面で「バックエンドプールの追加」をクリックすると、ターゲットの種類（ターゲットタイプ）として以下の4つを選択できます。
① IP アドレス
概要： サーバーのIPアドレス（プライベートIPまたはパブリックIP）を直接指定します。
- 主な用途： VPNやExpressRouteで繋がっているオンプレミス環境の物理サーバー・移行途中の別クラウドにあるサーバーなどを宛先にしたい場合に便利です。
② FQDN（Fully Qualified Domain Name）
概要： 完全修飾ドメイン名（例：api.example.com）を指定します。
- 主な用途： 外部のサードパーティが提供しているWebサービスや、別リージョンにある公開APIなど、IPアドレスではなくドメイン名で通信先を管理したい場合に使用します。
③ 仮想マシン / 仮想マシンスケールセット（VMSS）
概要： Azure上の仮想マシン（VM）や、仮想マシンスケールセットをプールから直接選択して追加します。
④ App Service
概要： AzureのPaaS機能である「App Service（Web Apps）」をターゲットとして指定します。
- 主な用途： PaaS（Web Apps）の手前にAppGwを配置して、WAFによるセキュリティ保護をかけたり、独自のURLルーティングを行いたい場合に選択します。
💡 バックエンドプールは「空」でも作成可能
構築のタイミングでまだWebサーバー（VMなど）が完成していない場合は、ひとまず「ターゲットを持たない空のバックエンドプール」として作成を進めることも可能です。後からいつでもターゲットは追加・変更できます。
5. 【フロントエンド・構成】リスナーを設定する
次はAppGwが「どこで」「どのような通信を」待ち受けるかを設定する、フロントエンド（リスナー）の設定を行います。
ルーティング規則（リスナー）の追加
中央の「ルーティング規則の追加」をクリックすると、右側から詳細な設定画面が表示されます。ここがリスナーの設定画面です。
① リスナーの基本情報
- 規則名（例：
ait-appgw-route01）： このルーティングルール自体の名前です。 - 優先度（例：
100）：- 複数のルールがある場合に、どのルールを優先するかを決める数字です。
- 1〜20000の間で指定し、数字が小さいほど優先されます（通常は100刻みで設定します）。
② 通信を待ち受ける「条件」の設定
- リスナー名（例：
ait-appgw-listener01）： 通信を待ち受ける「リスナー」の名前です。 - フロントエンド IP： 先ほど「フロントエンド」タブで作成したIPアドレスを選択します。
- プロトコル：
HTTPまたはHTTPSを選択します。HTTP：ポート80で通常のWeb通信を受け付けます。HTTPS：ポート443で暗号化通信を受け付けます。（※HTTPS設定には証明書のアップロードが必要です）。
- ポート： プロトコルに合わせて自動で「80」や「443」が入ります。特殊なポートを使う場合はここで変更可能です。
- リスナーの種類：
- Basic： 1つのAppGwで1つのドメイン（サイト）を扱う場合に選びます。
- Multi site： 1つのAppGwで複数のドメイン（例：
a.comとb.com）を使い分けたい場合に選びます。
バックエンドターゲットの設定
「リスナー」の設定が終わったら、同じ画面の隣にある「バックエンドターゲット」タブに切り替えて、通信を届ける「バックエンドプール」と「バックエンド設定（HTTP設定）」を紐付ければ、ルーティング規則の完成です。
6. 作成完了後に変更・拡張できる主要な設定
App GWのリソース作成が完了したら、左のメニューから設定変更が可能です。
運用管理や設定変更の際によく使う主要な5つのメニューについて、それぞれ何ができるのかを簡潔に解説します。
H3：SSL 設定
HTTPS通信に必要なSSL/TLS証明書の管理や、暗号化のセキュリティポリシーを設定します。
Webサイトを常時HTTPS化する際に、証明書ファイルをアップロードしたり更新したりするために使用します。
H3：リスナー
AppGwに対して、「どのIPアドレスの、どのポート番号（HTTPの80番やHTTPSの443番など）に届いた通信を処理するか」を指定します。
NSGの受信規則でIPアドレスやポートの許可を行う設定と同じようなものです。
複数のドメインを1つのApplication Gatewayでまとめて待ち受けるマルチサイト設定や、新しいポートでの受付を追加したい場合に利用します。
H3：ルール（ルーティング規則）
リスナーが受け取った通信をどのバックエンドプールへ転送するかという、通信の経路を定義します。
URLのパスに応じて転送先のサーバーグループを切り替えるパスベースのルーティングなどを実現したい場合に設定します。
H3：書き換え（リライト）
クライアントとWebサーバーの間を通過するHTTPの要求ヘッダー、応答ヘッダー、またはURLの内容をリアルタイムに書き換える機能です。
セキュリティ対策として特定のヘッダー情報を隠したり追加したり、特定のURLアクセスを別のパスへ内部的にリダイレクトさせたりする場合に使用します。
H3：正常性プローブ（ヘルスプローブ）
バックエンドに配置されているWebサーバーが正常に動いているかどうかを定期的に監視するためのルールを設定します。
複数あるサーバーのうち1台がシステムダウンなどでエラーを返すようになった際、そのサーバーへの通信を自動的に遮断して正常なサーバー側だけに通信を振り分けるために不可欠な設定です。
7. 【おまけ】HTTPからHTTPSへ自動リダイレクトさせる設定手順
Webサイトのセキュリティ（SEO対策）として、http://〜 でアクセスしてきたユーザーを自動的に https://〜 へ転送（リダイレクト）させる設定は必須と言えます。
「設定メニューにある『書き換え』を使うのかな？」と思いがちですが、実は違います。Azure Application Gatewayでは、「2つのリスナー」と「ルーティング規則（ルール）」を組み合わせることで、簡単にHTTPからHTTPSへの自動リダイレクトを実装できます。
具体的な設定手順をステップ・バイ・ステップで解説します。
ステップ1：2つのリスナーを用意する
まずは、通信の入り口となる「リスナー」を2種類作成します。
- HTTPリスナー（ポート80）： 通常のHTTPアクセスを待ち受けるリスナーです（例：
listener-http-80）。 - HTTPSリスナー（ポート443）： 暗号化されたHTTPSアクセスを待ち受けるリスナーです（例：
listener-https-443）。※こちらにはSSL/TLS証明書を紐付けておきます。
ステップ2：HTTP用のルーティング規則（ルール）を設定する
ここが一番のポイントです。HTTP（ポート80）で受け取った通信を、バックエンドプールではなく「HTTPSリスナー」へと受け流すルールを作ります。
左メニューの「ルール」から新しく規則を追加し、以下のように設定します。
- 「リスナー」タブ：
- ターゲットとなるリスナーに、先ほど作った「HTTPリスナー（ポート80）」を選択します。
- 「バックエンドターゲット」タブ：
- ターゲットの種類： 通常は「バックエンドプール」を選びますが、ここでは「リダイレクト」を選択します。
- リダイレクトの種類： 恒久的な転送である「恒久 (301)」を選択します（SEO的にも301リダイレクトが推奨されます）。
- ターゲットリスナー： 先ほど作った「HTTPSリスナー（ポート443）」を指定します。
これで設定は完了です！
まとめ
今回は、Azureポータル画面に沿って、AppGwの構築手順と、作成後に重要となる各種設定について解説しました。
構築や運用の際は、NSGのようにポートを開ける「リスナー（入り口）」、通信をサーバーへマッピングする「ルール（案内板）」、ヘッダーなどの文字をいじる「書き換え（スタンプ）」の3つの違いを意識すると、設定で迷わなくなります。
一見すると設定項目が多く難解に見えるApplication Gatewayですが、それぞれの役割を正しく理解すれば、非常に柔軟で強力なWebインフラを構築することができます。
まずは本記事の手順通りに、HTTPでの基本的な疎通確認からチャレンジしてみてください！
