Azure OpenAI ServiceをVNet内に閉鎖するためのPrivate Endpoint構成

Azure OpenAI閉域化をAIで最短構築!Private Endpoint実装プロンプト集【Terraform/Bicep対応】

この記事は急速に進化する技術について解説しています。最新情報は公式ドキュメントをご確認ください。

約9分で読めます
文字サイズ:
Azure OpenAI閉域化をAIで最短構築!Private Endpoint実装プロンプト集【Terraform/Bicep対応】
目次

この記事の要点

  • Azure OpenAI ServiceのVNet内からのセキュアなアクセスを実現
  • Private Endpointを利用し、パブリックインターネットからのアクセスを遮断
  • 機密データのセキュリティとコンプライアンスを大幅に強化

Azure OpenAIの導入プロジェクト、順調に進んでいますか?

AI駆動開発やプロジェクトマネジメントの現場では、ここ最近「PoC(概念実証)は終わったから、本番環境向けにセキュアな構成を作りたい」というニーズが急増しています。プロジェクトマネージャーの視点から見ても、多くの現場エンジニアが直面する巨大な壁、それが「ネットワークの閉域化」です。

「APIキーさえあれば使える」のがSaaSの魅力ですが、エンタープライズ利用ではそうはいきません。「インターネット経由のアクセスは禁止」「社内ネットワーク(VNet)からのみ接続許可」といったセキュリティ要件は必須事項です。

しかし、AzureにおけるPrivate EndpointPrivate DNS Zoneの組み合わせは、ベテランのインフラエンジニアでも設定漏れや名前解決のトラブルに見舞われやすい難所です。「Terraformで記述したもののDNSレコードが登録されない」「オンプレミスから名前解決できない」といった、現場からの悲鳴が上がることも決して珍しくありません。

そこで今回は、この複雑な構築作業を、まさにその「AI(ChatGPTやCopilot)」にサポートさせるという実践的なアプローチをご紹介します。

実務の現場で有効性が確認されている、AIに正確なIaCコード(Terraform/Bicep)を生成させるための「プロンプトテンプレート」を公開します。これを使えば、ドキュメントと睨めっこする時間を大幅に短縮し、ミスのない閉域環境を構築できるはずです。

本記事の活用法:AIをAzureネットワーク構築の「相棒」にする

まず前提として、なぜネットワーク構築にAI(LLM)を使うべきなのでしょうか? それは、Azureのネットワークリソース定義が「定型文の塊」でありながら「依存関係が複雑」だからです。

人間がゼロからHCL(Terraform)やBicepファイルを書くと、括弧の閉じ忘れやリソースIDの参照ミスといった些細なエラーで時間を浪費します。しかし、AIは構文エラーを起こしません。かつてAIが苦手としていた「文脈(コンテキスト)の理解」も、最新のモデルや機能によって劇的に改善されています。

Private Endpoint構築でハマりやすい「DNSの罠」とは

特にAzure OpenAIの閉域化でハマるのがDNSです。パブリックエンドポイントを無効化しても、クライアントは your-resource.openai.azure.com というFQDNでアクセスしようとします。これをプライベートIPに解決させるためには、以下の手順が必要です。

  1. Private Endpointを作成する。
  2. privatelink.openai.azure.com というPrivate DNS Zoneを作成する。
  3. Private DNS ZoneをVNetにリンクする。
  4. Endpoint作成時に払い出されたプライベートIPをAレコードとして登録する。

これらを手動や個別のスクリプトで管理すると、整合性が取れなくなります。IaCで一元管理するのが正解ですが、コード記述量は膨大になります。ここでAIの出番です。

本テンプレート集の使い方

本記事で紹介するプロンプトは、ChatGPT(最新モデル)Claudeの最新モデルGitHub Copilotに入力して使用することを想定しています。

現在のAIツールは、単なるコード生成だけでなく、プロジェクト全体の文脈を理解する「開発パートナー」へと進化しています。以下のポイントを意識して活用してください。

  • ChatGPT / Claude: 最新の推論モデルを使用してください。特にChatGPTの「Canvas」のような共同編集UIを利用すると、生成されたコードの一部をピンポイントで修正したり、ドキュメントとコードを行き来しながら構成を練り上げたりすることが可能です。
  • GitHub Copilot: エディタ上で使用する場合は、@workspace コマンドを活用することをお勧めします。これにより、既存のTerraform/Bicepファイルの構造をAIに認識させた上で、整合性の取れた追加コードを提案させることができます。

各テンプレートには [ ] で囲まれたプレースホルダーがあります。ここをご自身の環境に合わせて書き換えてから、AIに投げてください。AIはあなたの指示を理解し、複雑な依存関係を解決したコードを提示する「優秀なインフラ担当アシスタント」として機能し始めます。

Step 1:ネットワーク前提条件をAIに正確に伝える「コンテキスト定義プロンプト」

AIにいきなり「Azure OpenAIのTerraformコードを書いて」と頼むのはNGです。AIはあなたのVNetのアドレス空間も、リソースグループ名も知りません。まずは「前提条件(コンテキスト)」を定義して、AIにインプットします。

以下のプロンプトは、ネットワークトポロジーを構造化データとしてAIに理解させるためのものです。

VNet・Subnet設計情報の構造化テンプレート

このプロンプトを最初に実行し、AIに「記憶」させます。

# 命令書: Azureネットワーク構成のコンテキスト定義

あなたはAzureインフラ構築の専門家です。以下の要件定義(Context)に基づき、後続の指示に従ってIaCコードを生成するための準備をしてください。
まだコードは生成しなくて構いません。「コンテキストを理解しました」とだけ返答してください。

## Context (前提環境)

![Step 1:ネットワーク前提条件をAIに正確に伝える「コンテキスト定義プロンプト」 - Section Image](/ai-knowledge-flow/api/content-images/00b4f877-6734-49d4-9664-5f2ed3a60955/leadImage1)

- 使用言語: [Terraform (azurerm provider) / Bicep]
- リージョン: [Japan East]
- リソースグループ名: [rg-ai-platform-prod]

## Network Topology
1. Virtual Network (VNet)
   - Name: [vnet-ai-core]
   - Address Space: [10.10.0.0/16]

2. Subnets
   - AppSubnet: 
     - Name: [snet-app]
     - CIDR: [10.10.1.0/24]
     - 用途: アプリケーションホスティング(App Service/AKS)
   - PrivateLinkSubnet: 
     - Name: [snet-privatelink]
     - CIDR: [10.10.2.0/24]
     - 用途: Private Endpoint専用
     - Policy: Private Endpoint Network Policies = Disabled (またはEnabled)

## Naming Convention

![Step 3:最難関「Private DNS Zone」を攻略する「名前解決設定プロンプト」 - Section Image](/ai-knowledge-flow/api/content-images/00b4f877-6734-49d4-9664-5f2ed3a60955/leadImage2)

- リソース名の接頭辞: [prj-prod-]
- タグ付け: { Environment = "Production", Owner = "AI-Team" }

なぜこの工程が必要なのか?

この工程を挟むことで、AIは「snet-privatelink というサブネットIDを使ってPrivate Endpointを作ればいいんだな」と文脈を理解します。これにより、後続のステップで生成されるコードの整合性が飛躍的に向上します。


Step 2:IaCコードを一発生成する「構築実装プロンプト」【Terraform/Bicep対応】

コンテキストが共有できたら、いよいよリソース作成の指示を出します。ここでは、単にリソースを作るだけでなく、「セキュリティ設定を強制する」ことが重要です。

Azure OpenAIはデフォルトでパブリックアクセスが許可されている場合があります。これを確実に塞ぐ指示を含めます。

Azure OpenAIリソースとPrivate Endpointを同時作成するプロンプト

# 命令書: Azure OpenAIとPrivate Endpointの構築コード生成

定義済みのContextに基づき、以下の仕様でAzure OpenAIおよび関連するネットワークリソースを構築するコードを作成してください。

## リソース仕様
1. Azure OpenAI
   - Name: [openai-instance-01]
   - SKU: [S0]
   - 重要: `publicNetworkAccess` (または相当するプロパティ) は必ず `Disabled` に設定し、インターネットからのアクセスを完全に遮断すること。
   - Identity: System Assigned Managed Identityを有効化。

2. Private Endpoint
   - Name: [pe-openai]
   - Target Resource: 上記で作成したOpenAI Service
   - Subnet: Contextで定義した [PrivateLinkSubnet]
   - Subresource Name: `account` (Cognitive Servicesの指定)

## 出力要件
- 変数定義 (variables/parameters) も含めること。
- リソースIDの参照はハードコーディングせず、動的な参照を使用すること。
- コードには日本語で簡潔なコメントを付与すること。

専門家の視点:publicNetworkAccessの罠

多くのサンプルコードでは public_network_access_enabled = true のままだったり、設定自体が省略されていたりします。AIに対して「重要」と明記し、明示的に Disabled を指定させることで、デプロイ直後からセキュアな状態を担保できます。これはセキュリティ監査においても非常に重要なポイントです。


Step 3:最難関「Private DNS Zone」を攻略する「名前解決設定プロンプト」

Private Endpointを作っただけでは、アプリケーションは接続できません。VNet内のリソースが *.openai.azure.com をプライベートIPとして解決できるようにする必要があります。

ここでは、IaCツール(Terraform/Bicep)の機能を使って、Private DNS ZoneとVNetのリンク、そしてレコードの登録を自動化させます。

privatelink.openai.azure.comのゾーンリンク設定指示

# 命令書: Private DNS Zoneによる名前解決の実装

作成したPrivate Endpointに対して、適切なDNS解決を提供するコードを追加してください。

## DNS構成要件
1. Private DNS Zone
   - Zone Name: `privatelink.openai.azure.com` (Azure OpenAIの必須仕様)
   - Resource Group: Contextのリソースグループと同じ

2. Virtual Network Link
   - 作成したPrivate DNS Zoneを、Contextの [vnet-ai-core] にリンクさせる。
   - `RegistrationEnabled` (自動登録) は `false` とする(Private Endpointのレコード管理と競合を防ぐため)。

3. Private DNS Zone Group (重要)
   - Private Endpointリソース内に `private_dns_zone_group` ブロックを定義し、上記DNSゾーンとEndpointを統合する。
   - これにより、Endpoint作成時に自動的にAレコードがDNSゾーンに追加される構成にすること。

## 期待する挙動
- VNet内のVMやApp Serviceが `your-openai.openai.azure.com` をルックアップした際、Private EndpointのプライベートIPが返されること。

構築のポイント

ここで重要なのは、Aレコードを個別にリソース定義するのではなく、Private DNS Zone Group という機能を使って、EndpointとDNSゾーンを「紐付ける」ことです。こうすると、EndpointのIPが変わったり再作成されたりしても、Azure側が自動的にDNSレコードを追従させてくれます。このベストプラクティスをAIに指示することで、運用負荷の低いコードが生成されます。


Step 4:接続テストとトラブルシューティング用「検証・デバッグプロンプト」

命令書: Private DNS Zoneによる名前解決の実装 - Section Image 3

構築が終わったら、正しく閉域化されているかを確認します。ポータル画面で「成功」と出ていても、実際には疎通できないことはよくあります。

AIに検証用のスクリプトや、トラブル時のチェックリストを作らせましょう。

nslookup / curl による疎通確認スクリプトの生成

# 命令書: 接続検証用スクリプトの生成

構築した環境の検証を行うため、VNet内のLinux VM(踏み台サーバー)から実行する検証コマンドセットを作成してください。

## 検証項目
1. 名前解決の確認
   - `nslookup` または `dig` を使用。
   - 対象: [openai-instance-01].openai.azure.com
   - 期待値: パブリックIPではなく、Private EndpointのプライベートIP (10.10.2.x) が返ってくること。

2. API疎通確認
   - `curl` を使用したREST API呼び出し。
   - エンドポイント: https://[openai-instance-01].openai.azure.com/openai/deployments/[model-name]/completions?api-version=2023-05-15
   - Header: `api-key` (プレースホルダーで可)
   - 期待値: HTTP 200 OK または 401 Unauthorized (ネットワーク到達性はOKで認証エラーの場合)。Time outや403 Forbiddenにならないこと。

## 出力形式
- そのままターミナルに貼り付け可能なシェルスクリプト形式。
- 実行結果の読み方(成功/失敗の判断基準)をコメントで追記。

「403 Forbidden」エラーが出た場合の対処

もし検証で 403 Forbidden が返ってきた場合、ネットワーク的には到達していますが、ファイアウォールやアクセス制限で弾かれている可能性があります。その際は、以下のプロンプトでAIに原因分析を手伝ってもらいます。

「Azure OpenAIへのアクセスで403エラーが発生しました。Private Endpoint経由です。publicNetworkAccessはDisabledです。考えられる原因と、Azure PortalまたはCLIで確認すべき設定項目をリストアップしてください。」

多くの場合、VNet統合の設定漏れや、呼び出し元のIPが許可リストに含まれていない(Private Endpointの場合は関係ありませんが、混同しやすい点です)などの原因をAIが提示してくれます。


まとめ:AIでインフラ構築の「時間」を買う

今回ご紹介したプロンプトテンプレートを使えば、複雑なAzure OpenAIの閉域ネットワーク構成を、TerraformやBicepのコードとして短時間で出力できます。

重要なのは、「人間が論理構成(トポロジーとセキュリティ要件)を考え、AIが実装(コーディング)を担当する」という役割分担です。AIはあくまで手段であり、ビジネス課題を解決するための設計図を描くのは、私たちエンジニアやプロジェクトマネージャーの役割です。

今回のポイント振り返り

  1. コンテキスト定義: ネットワーク構成情報を最初にAIにインプットする。
  2. セキュリティ強制: publicNetworkAccess: Disabled を明示的に指示する。
  3. DNS自動化: Private DNS Zone Group を利用してレコード管理を自動化させる。
  4. 検証のコード化: テストコマンドもAIに生成させ、品質を担保する。

これからのインフラエンジニアには、すべてのパラメータを暗記する能力よりも、「AIに対して的確な仕様を伝え、出力されたコードをレビューする能力」が求められます。

ぜひ、今回のテンプレートをカスタマイズして、プロジェクト専用の「最強の構築アシスタント」を育ててみてください。単純作業から解放され、より本質的なアーキテクチャ設計やROI最大化に向けた活動に時間を使えるようになるはずです。

実践的なAI活用ノウハウをチーム内で共有し、プロジェクト全体の生産性向上に役立てていくことをお勧めします。

Azure OpenAI閉域化をAIで最短構築!Private Endpoint実装プロンプト集【Terraform/Bicep対応】 - Conclusion Image

コメント

コメントは1週間で消えます
コメントを読み込み中...