先生と生徒の会話形式で理解しよう

生徒

「自社で開発したWebサービスを、顧客のAzure環境（仮想ネットワーク）からインターネットを通さずに直接使ってもらいたいのですが、良い方法はありますか？」

先生

「それなら『Azure Private Link Service（アジュール・プライベート・リンク・サービス）』を使うのが最適です。これを使えば、あなたのサービスを相手のネットワーク内に専用の入り口として公開できるんですよ。」

生徒

「インターネットに出ない『閉域網（へいきもう）』で通信できるということですね！セキュリティも安心そうです。設定は難しいのでしょうか？」

先生

「基本的な仕組みを理解すれば大丈夫です。ロードバランサーの設定から順を追って、構築の流れを一緒に見ていきましょう！」

1. Azure Private Link Serviceとは？

Azure Private Link Service（アジュール・プライベート・リンク・サービス）とは、自分が管理しているAzure上のサービス（プロバイダー側）を、他のAzure利用者の仮想ネットワーク（VNet：ブイネット）へ安全に提供するための仕組みです。

通常、サービスを外部に公開するにはパブリックIPアドレスを割り当ててインターネット経由でアクセスさせますが、これではセキュリティ上のリスクが伴います。Private Link（プライベート・リンク）を利用すると、インターネットを経由しない閉域網接続が実現します。顧客側からは、まるで自分のネットワーク内にそのサービスが存在しているかのように見えます。これを「サービスをプライベート化する」と表現することもあります。

2. 構築に不可欠なStandard Load Balancerの役割

Private Link Serviceを構築する際、その土台として必ず必要になるのが「Azure Standard Load Balancer（アジュール・スタンダード・ロード・バランサー）」です。このロードバランサーの背後に、実際のWebサーバーやアプリケーションサーバーを配置します。

なぜ「Standard」でなければならないかというと、Basic（ベーシック）プランのロードバランサーではPrivate Linkの機能に対応していないためです。ここで設定したフロントエンドIP構成が、Private Link Serviceの接続点となります。まずは、バックエンドに仮想マシンを紐付けたロードバランサーを準備しましょう。

例えば、バックエンドで動かすサーバーの死活監視をコマンドで確認する際は、以下のように疎通確認を行います。


curl -I http://10.0.0.4
HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 612

3. プライベートリンクサービスの作成手順

ロードバランサーが準備できたら、いよいよ「Private Link Service」を作成します。Azureポータルから「Private Link センター」を開き、「作成」を選択します。ここで重要なのは、先ほど作成したStandard Load Balancerを選択し、NAT（ナット：ネットワーク・アドレス変換）用のサブネットを指定することです。

NATサブネットは、顧客側から送られてきた通信の送信元IPアドレスを、プロバイダー側のネットワーク体系に変換するために使用されます。これにより、IPアドレスの重複（バッティング）を気にせずに通信が可能になります。接続承認を「自動」にするか「手動」にするかも選べますが、商用サービスであれば「手動」にして、承認した顧客だけを通すのが一般的です。

4. 顧客側でのプライベートエンドポイント作成

サービスを提供する準備ができたら、次は顧客（利用者）側の作業です。顧客は、プロバイダーから共有された「リソースID」または「エイリアス（識別名）」を使用して、自分のVNet内に「Private Endpoint（プライベート・エンドポイント）」を作成します。

エンドポイントが作成されると、顧客のネットワーク内に「プライベートIPアドレス」が割り当てられたネットワークインターフェースが出現します。顧客はこのIPアドレスに対してアクセスするだけで、裏側にあるプロバイダーのサービスへ到達できます。データの盗聴やDDoS攻撃のリスクを極限まで低減できるのが最大のメリットです。

接続状況をデータベースで管理している場合、以下のようなSQLで接続ログを確認するイメージになります。


id | customer_name | endpoint_ip  | status    | last_access
---+---------------+--------------+-----------+-------------------
1  | 株式会社A     | 192.168.1.10 | Connected | 2026-03-30 14:00
2  | サービスB     | 192.168.1.11 | Pending   | NULL
3  | クラウド商事   | 192.168.2.5  | Connected | 2026-03-30 14:15
4  | 開発チームC    | 10.1.0.50    | Disconnected| 2026-03-29 10:00


SELECT customer_name, endpoint_ip, status
FROM connection_logs
WHERE status = 'Connected';


customer_name | endpoint_ip  | status
--------------+--------------+-----------
株式会社A     | 192.168.1.10 | Connected
クラウド商事   | 192.168.2.5  | Connected

5. 通信を制御するネットワークセキュリティグループの設定

閉域網だからといって、セキュリティ設定を疎かにしてはいけません。NSG（Network Security Group：ネットワーク・セキュリティ・グループ）を適切に設定し、必要なポート番号（HTTPの80番やHTTPSの443番など）のみを許可するように制限しましょう。

特にPrivate Link経由の通信は、NATサブネットのIPアドレスから届くように見えるため、ロードバランサー配下のサーバーでは、NATサブネットからの通信を許可するルールを追加する必要があります。これを忘れると、接続は確立しているのにWebページが表示されない、といったトラブルに繋がります。設定の際は、優先順位（プライオリティ）にも注意してください。

6. 接続確認とトラブルシューティング

全ての構築が終わったら、実際に疎通確認を行います。顧客側のネットワークにある仮想マシン（VM）にログインし、割り当てられたプライベートIPアドレスに対してコマンドを実行します。名前解決（DNS）の設定が正しければ、ドメイン名でのアクセスも可能です。

もし繋がらない場合は、以下の3点を確認してください。

Private Link Serviceの接続ステータスが「Approved（承認済み）」になっているか
ロードバランサーのヘルスプローブ（生存確認）が正常か
NSGでNATサブネットからの通信をブロックしていないか

接続テスト用の簡単なC#プログラムを書いて、応答時間を計測することも有効です。


using System;
using System.Net.Http;
using System.Threading.Tasks;

class Program
{
    static async Task Main()
    {
        string url = "http://192.168.1.10"; // 顧客側のエンドポイントIP
        using (HttpClient client = new HttpClient())
        {
            try
            {
                var response = await client.GetAsync(url);
                Console.WriteLine($"接続結果: {response.StatusCode}");
            }
            catch (Exception ex)
            {
                Console.WriteLine($"エラー発生: {ex.Message}");
            }
        }
    }
}


接続結果: OK

7. Private Link Serviceのメリットと注意点

この構成のメリットは、プロバイダーと顧客のVNet間でIPアドレスの重複が許容される点です。従来のVNetピアリング（仮想ネットワーク同士の接続）では、互いのIPレンジが重なっていると接続できませんでしたが、Private Linkならその制約がありません。また、データがインターネットを一切通らないため、コンプライアンス要件が厳しい金融機関や公共機関へのサービス提供にも適しています。

一方で注意点としては、通信が「一方向（顧客からプロバイダーへ）」であることです。プロバイダー側から顧客側のネットワークへ自発的に通信を開始することはできません。あくまで顧客がサービスを利用するための「窓口」を作る機能であることを理解しておきましょう。

8. 応用：複数の顧客にサービスを展開する

一度Private Link Serviceを構築すれば、複数の顧客に対して同じエイリアスを提供し、それぞれに専用のエンドポイントを作ってもらうことができます。これは「マルチテナント」形式のSaaS（サース：Software as a Service）を提供する場合に非常に強力な武器となります。

各顧客の接続状況を管理する際、どのエンドポイントがどの顧客に関連付けられているかをリスト化して管理するのが一般的です。管理ツールなどでステータスを更新する処理の一例を挙げておきます。


public void UpdateConnectionStatus(string customerId, bool isActive)
{
    if (isActive)
    {
        Console.WriteLine($"顧客ID: {customerId} の接続を有効化しました。");
    }
    else
    {
        Console.WriteLine($"顧客ID: {customerId} の接続を停止しました。");
    }
}


顧客ID: CUST-001 の接続を有効化しました。

9. 名前解決とPrivate DNS Zoneの活用

IPアドレスでのアクセスは不便なため、通常は「Private DNS Zone（プライベート・ディーエヌエス・ゾーン）」を併用します。これにより、顧客側は `myservice.privatelink.azure.com` のようなドメイン名でアクセスできるようになります。

プライベートエンドポイント作成時に「プライベートDNSとの統合」を有効にすると、自動的にAレコード（IPアドレスと名前の対応付け）が登録されます。これにより、内部ネットワーク内でのみ有効なドメインによるスマートな運用が可能になります。複雑なネットワーク構造を意識させない、ユーザーフレンドリーな閉域網サービスの完成です。

まとめ

Azure Private Link Service（アジュール・プライベート・リンク・サービス）を利用した閉域網接続の構築について、その仕組みから具体的な設定手順、運用のポイントまでを詳しく解説してきました。本ガイドを通じて、自社サービスを安全かつ効率的に顧客へ提供するための基盤構築イメージが具体化されたのではないでしょうか。

主要な構成要素の再確認

セキュアな閉域網サービスを実現するためには、以下のコンポーネントが正しく連携している必要があります。

Standard Load Balancer： サービスの入り口となる高機能な負荷分散装置。
NATサブネット： 顧客のIPアドレスをサービス提供側の体系に変換する重要な領域。
Private Link Service： サービスをエイリアス（識別名）として公開する中心機能。
Private Endpoint： 顧客のネットワーク内に作成される、サービスへの専用入り口。

構築時のチェックリストと運用管理

実際の構築現場では、単に接続するだけでなく、管理の自動化やセキュリティの強化が求められます。特に、接続を承認するプロセスや、接続元を特定するためのログ管理は、商用環境において非常に重要です。

例えば、データベースを利用して接続リクエストのステータスを一括管理する場合のデータ構造と、承認処理をシミュレーションするSQLおよびC#コードを見てみましょう。

接続リクエスト管理テーブル（承認前）


id | tenant_id | alias_name          | request_date        | approval_status
---+-----------+---------------------+---------------------+-----------------
1  | TENANT-A  | svc-prod-east-01    | 2026-03-30 09:00:00 | Pending
2  | TENANT-B  | svc-prod-east-01    | 2026-03-30 09:15:00 | Approved
3  | TENANT-C  | svc-prod-east-01    | 2026-03-30 10:05:00 | Rejected
4  | TENANT-D  | svc-prod-east-01    | 2026-03-30 11:20:00 | Pending
5  | TENANT-E  | svc-prod-east-01    | 2026-03-30 13:45:00 | Pending

保留中のリクエスト（Pending）を抽出し、管理者が内容を確認して承認フラグを立てる際のSQL操作例です。


-- 保留中の接続リクエスト一覧を取得する
SELECT id, tenant_id, request_date
FROM connection_requests
WHERE approval_status = 'Pending'
ORDER BY request_date ASC;

-- 特定のテナント（TENANT-A）を承認済みに更新する
UPDATE connection_requests
SET approval_status = 'Approved'
WHERE tenant_id = 'TENANT-A';

更新後の管理テーブル


id | tenant_id | alias_name          | request_date        | approval_status
---+-----------+---------------------+---------------------+-----------------
1  | TENANT-A  | svc-prod-east-01    | 2026-03-30 09:00:00 | Approved
2  | TENANT-B  | svc-prod-east-01    | 2026-03-30 09:15:00 | Approved
3  | TENANT-C  | svc-prod-east-01    | 2026-03-30 10:05:00 | Rejected
4  | TENANT-D  | svc-prod-east-01    | 2026-03-30 11:20:00 | Pending
5  | TENANT-E  | svc-prod-east-01    | 2026-03-30 13:45:00 | Pending

プログラマブルな接続制御

管理コンソールからだけでなく、API経由で接続の状態を監視したり、アプリケーション層で特定の顧客からのアクセスを制御したりすることも可能です。以下は、接続ステータスを判定して処理を分岐させるC#のクラス設計イメージです。


using System;

namespace AzurePrivateLinkManager
{
    public class ConnectionManager
    {
        public string TenantId { get; set; }
        public string Status { get; set; }

        public void ProcessAccessRequest()
        {
            if (this.Status == "Approved")
            {
                Console.WriteLine($"テナント {this.TenantId} からのアクセスを許可しました。閉域網通信を開始します。");
            }
            else if (this.Status == "Pending")
            {
                Console.WriteLine($"テナント {this.TenantId} は現在承認待ちです。管理者の承認を確認してください。");
            }
            else
            {
                Console.WriteLine($"警告: テナント {this.TenantId} の接続は拒否されています。");
            }
        }
    }

    class Program
    {
        static void Main()
        {
            ConnectionManager client = new ConnectionManager();
            client.TenantId = "TENANT-A";
            client.Status = "Approved";
            client.ProcessAccessRequest();
        }
    }
}


テナント TENANT-A からのアクセスを許可しました。閉域網通信を開始します。

高度なネットワークトラブルシューティング

インフラの運用において、コマンドラインでの確認作業は欠かせません。疎通が取れない場合は、OSレベルでの経路確認や、名前解決の成否を段階的に切り分ける必要があります。Linux環境から、プライベートドメインの名前解決とルート確認を行う際の基本的なコマンド例を記載します。


nslookup myservice.privatelink.azure.com
Server:  127.0.0.53
Address: 127.0.0.53#53

Non-authoritative answer:
Name:    myservice.privatelink.azure.com
Address: 10.1.0.50


ping -c 3 10.1.0.50
PING 10.1.0.50 (10.1.0.50) 56(84) bytes of data.
64 bytes from 10.1.0.50: icmp_seq=1 ttl=64 time=0.852 ms
64 bytes from 10.1.0.50: icmp_seq=2 ttl=64 time=0.741 ms
64 bytes from 10.1.0.50: icmp_seq=3 ttl=64 time=0.765 ms

--- 10.1.0.50 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2028ms

最後に：セキュリティと利便性の両立

Azure Private Link Serviceは、単なる接続技術ではなく、エンタープライズ領域における「信頼」を構築するためのツールです。インターネットという公共の場を介さず、組織間の境界を超えてサービスを届けるこの仕組みは、今後のクラウドネイティブなシステム開発において標準的な選択肢となるでしょう。本記事で紹介したベストプラクティスを参考に、ぜひ安全で堅牢なサービス基盤を構築してください。

先生と生徒の振り返り会話

生徒

「先生、詳しい解説をありがとうございました！ Private Link Serviceを使うと、IPアドレスが重複していても接続できるという点が一番驚きでした。これなら、顧客のVNet設定を気にせずに済みますね。」

先生

「その通りです！ NATサブネットがうまく仲介役をしてくれるおかげですね。VNetピアリングで苦労していたネットワーク設計の制約が、Private Linkならスッキリ解決します。」

生徒

「構築のポイントとして、Standard Load Balancerが必須という点も忘れないようにします。もしBasicを使っていたら、いつまで経っても設定項目が出てこなくて悩むところでした。」

先生

「いいところに気づきましたね。Azureのサービスはプランによって機能制限があることが多いので、前提条件の確認は大切です。あと、NSG（ネットワークセキュリティグループ）の設定はどうでしたか？」

生徒

「はい！閉域網だからといって何でも通すのではなく、NATサブネットからの通信を適切に許可することが重要だと学びました。プログラムでの接続確認も、実運用では自動化して監視に組み込めそうですね。」

先生