株式会社renue
renueについて
renueは、AIで業務を実装する会社です
AIコンサルティングから図面AI・広告運用エージェント・コールセンターAIまで、実際に動いているサービスをご覧いただけます。renueが何をしている会社か、まずはサービス一覧からご確認ください。
閉域ネットワーク環境へのAIアプリデプロイは「通常のデプロイとは別物」
金融機関、官公庁、製造業の基幹システム——これらの環境では、外部接続を制限した閉域ネットワークでのデプロイが求められる場合があります。外部のCI/CDから対象へ到達できない構成では、そのままデプロイできず、Docker Hubからの直接pullや外部API利用も許可された通信経路に左右されます。一方、対象のプライベートエンドポイントへ到達できるセルフホスト型エージェントなどを使えば、CI/CDを構成できます。
本記事では、Azure VM＋Bastion＋ACR構成での閉域環境デプロイを、一般的な構成例として解説します。例ではx64のLinux VM、Premium SKUのACRのプライベートエンドポイントとDNS設定、Standard以上でネイティブクライアント接続を有効にしたBastionを使用します。開発端末からのACRへのpushにも、VPNなどの到達経路と認証が必要です。Run Commandを使う場合は、VM Agentに必要なAzureへの送信通信も許可する前提です。
閉域環境デプロイのアーキテクチャ
開発者のローカルPC │ │ docker build → docker push ↓ Azure Container Registry（ACR） │ │ docker pull（VM→ACRのプライベートエンドポイント経由） ↓ Azure VM（閉域ネットワーク内） ├ フロントエンド（Webアプリ） ├ バックエンド（APIサーバー） ├ mysql（port 3306） ├ redis（port 6379） └ build-runner（ビルド用） │ │ az network bastion tunnelでSSH接続 → SSHのローカルポート転送 ↓ 開発者のブラウザ（SSHで転送したlocalhostのポートへ接続）
デプロイの3フェーズ設計
フェーズ1：イメージ反映（ダウンタイムなし）
新しいイメージをビルドしてACR経由でVMに届けます。この間、旧コンテナは稼働中のままです。
| ステップ | 実行場所 | 操作 |
|---|---|---|
| 1 | ローカル | イメージビルド（このx64 VM向けに--platform linux/amd64を指定） |
| 2 | ローカル | ACR認証＋push（latest + git SHAタグ。配備するdigestも記録） |
| 3 | VM | VM上の不要イメージ削除（ディスク空き容量10GB以上確保。復帰用イメージは保持） |
| 4 | VM | 新イメージをpull（旧コンテナ稼働中のまま） |
フェーズ2：コンテナ切替（ダウンタイム開始）
| ステップ | 操作 | 影響 |
|---|---|---|
| 5前半 | 旧appコンテナを停止・削除 | FEダウンタイム開始 |
| 5後半 | 新コンテナを起動 | 検証可能な状態へ。利用者への公開はDB変更・疎通確認後 |
事前pullでイメージ取得を停止時間の外へ移せます。停止時間は、旧コンテナ停止から必要なDB変更・疎通確認を終えて公開を再開するまでを計測します。Composeは通常、コンテナの実行開始だけでは処理準備完了まで待たないため、起動ログだけで終了と判定しません。
フェーズ3：検証（公開再開前の確認と再開後の監視）
| ステップ | 操作 | 確認事項 |
|---|---|---|
| 6 | 起動確認 | docker compose psの状態とReady in XXXms等のログを確認し、ヘルスチェックで処理準備完了を確かめる |
| 7 | API疎通テスト | FE(200) / BE(healthy) / FE→BE(200)の3系統と必要なDB処理を確認。結果が正常なら公開再開し、その後も監視 |
| 8 | ブラウザ確認 | Bastion経由のSSH接続とローカルポート転送で画面表示 |
閉域環境特有の落とし穴と対策
落とし穴1：DNS解決の失敗
VMからAzure OpenAIエンドポイントへのDNS解決が失敗する場合があります。
原因：プライベートリンクが設定されているが、VMの名前解決でプライベートDNSゾーンを参照できていない（VNetリンク漏れやDNS転送設定など）
暫定対策：VMの/etc/hostsにIPを追記してテスト実施（テスト後に削除）
恒久対策：名前解決の構成に応じてプライベートDNSゾーンのVNetリンクやDNS転送設定を修正
落とし穴2：ディスク容量不足
VM上で過去にpullしたイメージやビルドキャッシュがディスク容量を圧迫すると、新イメージのpullが失敗します。Dockerの未使用オブジェクトは自動では削除されないため、VM側で確認します。ACR側のレジストリ容量とは別の問題です。
対策：pull前に不要イメージを削除し、空き容量10GB以上を確認してから実行
落とし穴3：Apple Silicon環境のビルド
Apple SiliconのMacでビルドする際は、対象VMとイメージのCPUアーキテクチャを合わせます。このx64 VMの例では--platform linux/amd64を指定します。AzureにはArm64のVMもあり、そちらには対応するArm64イメージが必要です。マルチプラットフォームのイメージも選択肢です。対応しない単一アーキテクチャのイメージを使うと、pullは成功しても起動できないという発見しにくい障害につながります。
落とし穴4：az vm run-commandの同時実行制限
az vm run-command invokeはAction Run Commandで、1台のVMでは同時に1つしか実行できないという制限があります。各ステップは完了と終了結果を確認してから順番に実行します。自動でキューに入る前提にはしません。Managed Run Commandは並列・順次実行を扱える別方式なので、混同しないようにします。
落とし穴5：環境変数ファイルの管理
環境変数ファイルはVM上で直接管理される構成が一般的です。イメージの差し替えでは変更されませんが、誤って削除すると接続設定が失われる場合があります。
Bastionトンネルの運用
基本操作
# ターミナル1：VMのSSHポートへ接続（Standard以上・Native Client Support有効） az network bastion tunnel \ --name bastion-name \ --resource-group rg-name \ --target-resource-id /subscriptions/.../vm-name \ --resource-port 22 \ --port 2222 # ターミナル2：VMへSSH認証し、FE/BEをローカルへ転送 # vm-userは実際のVMユーザー名。VMでSSH転送が許可されていること ssh -N -o ExitOnForwardFailure=yes -p 2222 \ -L 127.0.0.1:3000:127.0.0.1:3000 \ -L 127.0.0.1:8000:127.0.0.1:8000 \ vm-user@127.0.0.1
Bastionトンネルの注意事項
- トンネルを開いたターミナルは閉じないこと。閉じると接続が切れる
- FE（3000）とBE（8000）は、上の例ではBastion接続用とSSH転送用の2つのターミナルで確認する。VM側の認証・転送許可と、VMから両ポートへ到達できることが必要
Tunnel is ready, connect on port XXXXはBastion側の接続準備完了。さらにSSH認証とポート転送を確立し、上の例ではhttp://localhost:3000でFEを確認する（BEは8000）。Bastion単体はWebサーバーを中継しないため、SSHのローカル転送を使用する
コンテナイメージのタグ戦略
閉域環境では「どのコミットが今動いているか」の追跡性が特に重要です。
GIT_SHA=$(git rev-parse --short HEAD)
docker build --platform linux/amd64 \
-t registry/app:latest \
-t registry/app:${GIT_SHA} .
latestに加えてgit SHAタグを付与し、対応するイメージのdigestを記録します。タグ自体は付け替えられるため、復帰用イメージをACRに保持し、戻す内容をdigestで特定します。同じソースからの再ビルドでも、ベースイメージや依存物が変われば同じ成果物にはなりません。
マイグレーション実行のタイミング
本記事の手順では、DBマイグレーションをコンテナ起動とは分離して実行・結果確認します。手動か自動かは運用設計で決めます。状態を持つDBの変更と復帰方法を事前に検証し、新旧アプリと新旧スキーマの組み合わせごとに互換性を確認します。
- マイグレーション前に必ずDBバックアップを取得（
mysqldump） - DBの接続準備完了とスキーマ互換性を確認してマイグレーション実行。新アプリを先に起動する順序は、旧スキーマでも動作できる場合に限る。非互換な変更では利用者とバックグラウンド処理の書き込みを止め、移行を完了させてから新アプリを起動する
- マイグレーション結果を確認し、アプリのヘルスチェックと必要なDB操作の疎通確認後にサービス公開
ロールバック手順
問題発生時のロールバック手順を事前に文書化しておきます。
- 復帰先の既存イメージのdigestと取得可否、DB互換性を確認し、利用者とバックグラウンド処理の書き込みを止めて対象コンテナを停止
- DBは互換性に応じて復元の要否を判断。復元前に現状を保全し、バックアップ以降の更新を必要な時点まで回復する手順と許容されるデータ欠損範囲を確認する。バックアップを戻すだけでは、その後の書き込みは失われる
- 記録したdigestの既存イメージを選択。既存成果物が取得できない場合は、依存物を固定した再ビルドを代替案として検証し、同じcommit SHAだから同一内容とは扱わない
- 必要な場合はACRからdigest指定でpullし、コンテナを再作成。DBとの互換性・疎通を確認して公開と書き込みを再開
まとめ：閉域環境デプロイチェックリスト
| フェーズ | チェック項目 |
|---|---|
| ビルド | --platform linux/amd64など、対象VMのCPUに合うイメージか |
| ビルド | latest + git SHAの二重タグを付与し、配備するdigestを記録したか |
| push | ACR認証が有効か（docker login） |
| VM準備 | VM上の不要イメージ削除→空き容量10GB以上確認（復帰用イメージは保持） |
| pull | 旧コンテナ稼働中にpull実行（ダウンタイム最小化） |
| 切替 | 旧コンテナ停止→新コンテナ起動→検証。復帰用イメージを確保したうえで不要物だけ削除（prune -aは未使用のタグ付きイメージも対象） |
| DB | バックアップ取得→マイグレーション→結果確認 |
| 検証 | FE/BE/FE→BEの3系統疎通テスト |
| 検証 | Bastion経由のSSH接続・ローカル転送によるブラウザ確認 |
| 管理 | 環境変数ファイルが保全されているか |
| 管理 | ロールバック手順が文書化されているか |
閉域環境では、CI/CDも含めて許可された通信経路と認証方法を確認し、デプロイ手順を設計する必要があります。3フェーズ設計、5つの落とし穴への対策、ロールバック手順の事前準備——この3つを押さえることで、閉域環境でも安全・確実なデプロイが可能になります。
あわせて読みたい
- 5Sとは｜整理・整頓・清掃・清潔・しつけの意味・目的・進め方を解説
- AIリードスコアリング実装ガイド【2026年版】— 4要素スコアリング×テリトリー管理×ステータス倍率の本番アーキテクチャ
- AIカスタマーサポート完全ガイド【2026年版】— RAG・チャットボット・有人連携の実装パターンとツール比較
関連記事
開発プロセスの改善はrenueにご相談ください。
