閉域ネットワーク環境へのAIアプリデプロイ完全ガイド｜Bastion経由VM操作・ACRイメージ管理・3フェーズダウンタイム最小化・5つの落とし穴と対策【2026年版】

閉域ネットワーク環境へのAIアプリデプロイは「通常のデプロイとは別物」

金融機関、官公庁、製造業の基幹システム——これらの環境では、インターネットに接続できない閉域ネットワークでのデプロイが求められます。通常のCI/CDパイプラインが使えず、Docker Hubからのイメージpullもできず、外部APIへのアクセスも制限されます。

本記事では、Azure VM＋Bastion＋ACR構成での閉域環境デプロイを、実際のプロジェクトで運用されている手順に基づいて解説します。

閉域環境デプロイのアーキテクチャ

開発者のローカルPC
  │
  │ docker build → docker push
  ↓
Azure Container Registry（ACR）
  │
  │ docker pull（VM→ACR間はAzureプライベートネットワーク）
  ↓
Azure VM（閉域ネットワーク内）
  ├ app（FE: Next.js, port 3000）
  ├ fastapi（BE: FastAPI, port 8000）
  ├ mysql（port 3307）
  ├ redis（port 6379）
  └ fortran-runner（コンパイル用）
  │
  │ az network bastion tunnel（唯一のアクセス経路）
  ↓
開発者のブラウザ（localhost経由でトンネル接続）

デプロイの3フェーズ設計

フェーズ1：イメージ反映（ダウンタイムなし）

新しいイメージをビルドしてACR経由でVMに届けます。この間、旧コンテナは稼働中のままです。

ステップ	実行場所	操作
1	ローカル	イメージビルド（--platform linux/amd64必須）
2	ローカル	ACR認証＋push（latest + git SHAタグ）
3	VM	不要イメージ削除（空き容量10GB以上確保）
4	VM	新イメージをpull（旧コンテナ稼働中のまま）

フェーズ2：コンテナ切替（ダウンタイム開始→終了）

ステップ	操作	影響
5前半	旧appコンテナを停止・削除	FEダウンタイム開始
5後半	新コンテナを起動	FEダウンタイム終了

事前pullによりダウンタイムは「停止→起動」の数十秒に短縮できます。

フェーズ3：検証（ダウンタイム終了後）

ステップ	操作	確認事項
6	起動確認	docker compose psでUp確認、ログにReady in XXXms
7	API疎通テスト	FE(200) / BE(healthy) / FE→BE(200)の3系統
8	ブラウザ確認	Bastionトンネル経由で画面表示

閉域環境特有の落とし穴と対策

落とし穴1：DNS解決の失敗

VMからAzure OpenAIエンドポイントへのDNS解決が失敗する場合があります。

原因：プライベートリンクが設定されているが、VMのVNetにプライベートDNSゾーンがリンクされていない

暫定対策：VMの/etc/hostsにIPを追記してテスト実施（テスト後に削除）

恒久対策：プライベートDNSゾーンのVNetリンク設定を追加

落とし穴2：ディスク容量不足

旧ACRの不要イメージが蓄積し、新イメージのpullが失敗します。

実例：旧イメージ4つ（約29GB）が残存し、ディスク使用率87%（残り8.5GB）でpull不可

対策：pull前に不要イメージを削除し、空き容量10GB以上を確認してから実行

落とし穴3：Apple Silicon環境のビルド

M1/M2/M3 Macでビルドしたイメージは、--platform linux/amd64を指定しないとLinux VMで動作しません。pullは成功するが起動時にエラーという、発見しにくい障害になります。

落とし穴4：az vm run-commandの同時実行制限

az vm run-command invokeは同時に1つしか実行できない。各ステップは前のコマンドの完了を待ってから実行する必要があります。並列実行するとコマンドが失敗またはキューイングされます。

落とし穴5：.env.dockerの管理

VM上の.env.dockerはGit管理外で直接管理されています。イメージの差し替えでは変更されませんが、誤って削除するとFE→BE接続が切れます（BACKEND_URL設定が消失）。

Bastionトンネルの運用

基本操作

# FE確認用トンネル
az network bastion tunnel \
  --name bastion-name \
  --resource-group rg-name \
  --target-resource-id /subscriptions/.../vm-name \
  --resource-port 3000 \
  --port 3000

# BE確認用トンネル（別ターミナル）
az network bastion tunnel \
  ... \
  --resource-port 8000 \
  --port 8000

Bastionトンネルの注意事項

• トンネルを開いたターミナルは閉じないこと。閉じると接続が切れる
• FE（3000）とBE（8000）を同時に確認する場合は別ターミナルで2本のトンネルを開く
• Tunnel is ready, connect on port XXXXと表示されたら、http://localhost:XXXXでアクセス可能

コンテナイメージのタグ戦略

閉域環境では「どのコミットが今動いているか」の追跡性が特に重要です。

GIT_SHA=$(git rev-parse --short HEAD)
docker build --platform linux/amd64 \
  -t registry/app:latest \
  -t registry/app:${GIT_SHA} .

latestに加えてgit SHAタグを付与することで、ロールバック時に「どのバージョンに戻すか」を明確に指定できます。

マイグレーション実行のタイミング

閉域環境でのDBマイグレーションは、コンテナ起動とは分離して手動実行が推奨です。

1. マイグレーション前に必ずDBバックアップを取得（mysqldump）
2. コンテナ起動完了を確認してからマイグレーション実行（起動直後はDB接続初期化中で失敗する場合がある）
3. マイグレーション結果を確認してからサービス公開

ロールバック手順

問題発生時のロールバック手順を事前に文書化しておきます。

1. VMでコンテナを停止
2. DBバックアップから復元（マイグレーション失敗時のみ）
3. ローカルで前のcommit SHAからイメージを再ビルド
4. ACRにpush→VMでpull→コンテナ再作成

まとめ：閉域環境デプロイチェックリスト

フェーズ	チェック項目
ビルド	--platform linux/amd64指定済みか
ビルド	latest + git SHAの二重タグを付与したか
push	ACR認証が有効か（docker login）
VM準備	不要イメージ削除→空き容量10GB以上確認
pull	旧コンテナ稼働中にpull実行（ダウンタイム最小化）
切替	旧コンテナ停止→新コンテナ起動→旧イメージprune
DB	バックアップ取得→マイグレーション→結果確認
検証	FE/BE/FE→BEの3系統疎通テスト
検証	Bastionトンネル経由のブラウザ確認
管理	.env.dockerが保全されているか
管理	ロールバック手順が文書化されているか

閉域環境デプロイは通常のCI/CDと全く異なるスキルセットが必要です。3フェーズ設計、5つの落とし穴への対策、ロールバック手順の事前準備——この3つを押さえることで、閉域環境でも安全・確実なデプロイが可能になります。

あわせて読みたい

• 5Sとは｜整理・整頓・清掃・清潔・しつけの意味・目的・進め方を解説
• AIリードスコアリング実装ガイド【2026年版】— 4要素スコアリング×テリトリー管理×ステータス倍率の本番アーキテクチャ
• AIカスタマーサポート完全ガイド【2026年版】— RAG・チャットボット・有人連携の実装パターンとツール比較

関連記事

• デプロイ障害の6ステージ切り分け
• 作業方針書テンプレート
• ポストモーテム設計
• 納品前セキュリティ検品

開発プロセスの改善はrenueにご相談ください。