Azure Container Instances（ACI）入門｜仮想マシン不要でコンテナをAzureで素早く動かす実践ガイド

オンプレのVMware環境でDockerに触れたことのあるインフラエンジニアほど、「Azureでコンテナを動かすにはAKSしかないのか」と思いがちです。Kubernetesは強力ですが、学習コストも運用負荷も決して小さくない。ちょっとしたバッチ処理や開発環境用のコンテナを動かすためだけにクラスターを立てるのは、オーバーエンジニアリングというものです。

そんなユースケースに刺さるのが、Azure Container Instances（ACI）です。VMもKubernetesも不要。Dockerイメージを指定するだけで、Azureのマネージドインフラ上にコンテナが数十秒で起動します。

この記事では、ACIの仕組みと基本操作、料金体系、AKSとの使い分け方、よくあるトラブルへの対処法まで、オンプレ経験者の視点でまとめます。

なぜAzure Container Instancesなのか？（VMとの決定的な違い）

オンプレでコンテナを動かすときの典型的な手順を思い出してください。物理サーバー（または仮想マシン）を用意し、OSをインストールし、Docker Engineをセットアップして、ようやくコンテナが起動できる。この「インフラの準備」に要する時間は、短くても数時間、場合によっては数日かかることもあります。

ACIはこのインフラ準備作業を丸ごとAzureに任せます。開発者は「どのDockerイメージを使うか」「CPUとメモリをどれだけ割り当てるか」「外部に公開するポートは何か」を指定するだけ。Azure CLIを使えば、コマンド1本でコンテナが起動します。

オンプレ運用との比較

コンテナとVMの本質的な違いについては、「コンテナ vs 仮想マシン（VM）の違いとは？」で詳しく解説しています。

ACIの基本概念：コンテナグループとは

ACI固有の概念として「コンテナグループ（Container Group）」があります。Kubernetesのポッドに近い概念で、同じホスト上で動作する1つ以上のコンテナをまとめた論理単位です。

コンテナグループ内のコンテナは以下を共有します。
・ライフサイクル: グループ単位で起動・停止する
・ネットワーク: グループ内のコンテナはlocalhostで相互通信できる
・ストレージ（ボリューム）: Azure Filesマウントなどを共有できる
・IPアドレス: グループに1つのパブリックIPが割り当てられる

シンプルなユースケースでは、コンテナグループに1つのコンテナを配置する構成が大半です。サイドカーパターン（ログ収集コンテナを添えるなど）の場合に複数コンテナをグループ化します。

基本的な使い方（Azure CLIでコンテナを起動する）

1. 事前準備：Azure CLIとリソースグループの作成

Azure CLIがインストール済みであることを前提にします。まずAzureにログインし、リソースグループを作成します。

# Azureにログイン
az login

# リソースグループを作成（Japan Eastリージョン：東京リージョン）
az group create \
  --name rg-aci-demo \
  --location japaneast

Japan East（東京リージョン、ap-northeast-1相当）はAzureの日本主要リージョンであり、国内ユーザーには最も低レイテンシで到達できます。

2. NGINXコンテナを起動する

最もシンプルなACI起動コマンドです。Docker HubのNGINXイメージを使ってWebサーバーを即時起動します。

# Azure CLIでコンテナインスタンスを作成
az container create \
  --resource-group rg-aci-demo \
  --name nginx-demo \
  --image nginx:latest \
  --dns-name-label nginx-demo-aci-mycompany \
  --ports 80 \
  --cpu 1 \
  --memory 1.5

# 起動状態を確認（FQDN と状態を取得）
az container show \
  --resource-group rg-aci-demo \
  --name nginx-demo \
  --query "{FQDN:ipAddress.fqdn, Status:instanceView.state}" \
  --output table

`–dns-name-label` に指定した値が `<指定値>.japaneast.azurecontainer.io` という形でパブリックFQDNになります。ブラウザやcurlでアクセスして動作を確認できます。

# コンテナのログを確認
az container logs \
  --resource-group rg-aci-demo \
  --name nginx-demo

# 使い終わったらコンテナを削除（課金停止）
az container delete \
  --resource-group rg-aci-demo \
  --name nginx-demo \
  --yes

重要な点が1つあります。ACIは「起動している間だけ課金される」仕組みのため、使い終わったコンテナはすぐに削除するのが基本です。停止（Stop）状態でも一部リソースが予約されたままになるケースがあるため、「削除」を習慣にしてください（詳細は料金セクションで解説します）。

3. 環境変数とシークレットをコンテナに渡す

本番に近い用途では、DBの接続文字列やAPIキーをコンテナに渡す必要があります。ACIには通常の環境変数と、ログに表示されないセキュア環境変数の2種類があります。

# 環境変数を渡す
# --environment-variables : ログに表示される通常の環境変数
# --secure-environment-variables : ログに出力されない機密情報用
az container create \
  --resource-group rg-aci-demo \
  --name myapp \
  --image myregistry.azurecr.io/myapp:latest \
  --environment-variables APP_ENV=production APP_PORT=8080 \
  --secure-environment-variables DB_PASSWORD=mysecretpassword \
  --ports 8080

`–secure-environment-variables` で指定した値はAzureポータル上のログ表示にも出力されないため、パスワード類はこちらを使います。さらに厳格に管理したい場合はAzure Key Vaultと組み合わせる構成が現場では一般的です。

4. プライベートレジストリのイメージを使う

Docker Hubのパブリックイメージだけでなく、Azure Container Registry（ACR）に格納した自社イメージも利用できます。

# ACR認証情報をACI起動時に指定する
az container create \
  --resource-group rg-aci-demo \
  --name myapp-private \
  --image myregistry.azurecr.io/myapp:v1.2 \
  --registry-login-server myregistry.azurecr.io \
  --registry-username  \
  --registry-password  \
  --ports 8080

ACRをマネージドIDで使う構成にすると、パスワードをコマンドに埋め込まずに済みます。本番環境では積極的に活用してください。

LinuxサーバーでのDockerの基本操作については、姉妹サイトLinuxMaster.JPで解説しています。

料金の仕組み（コスト感覚）

ACIの料金は「コンテナが実際に稼働している時間」に対して発生します。オンプレのように「サーバーを立てっぱなし」でコストがかかる構造ではありません。

料金の2軸（2026年7月時点、Japan Eastリージョン・概算）

【重要】毎月の無料枠

ACIには毎月以下の無料枠があります（2026年7月時点）。
・vCPU: 180,000秒/月（50時間相当）
・メモリ: 20GB・秒/月相当

バッチ処理など、短時間の処理を月数十回程度動かすだけなら、無料枠内に収まる場合があります。

コスト試算例：夜間バッチ処理のケース

毎日0時に起動し、30分で処理完了するバッチコンテナ（1vCPU、2GBメモリ）の場合、
・1日のvCPU料金: 1,800秒 × $0.0000125 = $0.0225
・1日のメモリ料金: 1,800秒 × 2GB × $0.0000013 = $0.00468
・1か月の合計: 約$0.81（無料枠適用前）

同じ処理をAzure VMで24時間稼働させると、最小構成でも月$15～$30かかります。ACIを使うことで、コストを95%以上削減できる計算です。

【コスト注意点】停止状態でも課金が続くケースがある

ACIは「削除（delete）」しない限り、停止（stop）状態でもリソースが予約されているため、一部の課金が継続するケースがあります。使い終わったコンテナは「停止」ではなく「削除」を基本の運用にしてください。

応用・実務Tips

【実務Tips 1】AKSとの使い分け基準

「ACI」と「AKS（Azure Kubernetes Service）」はどちらも「AzureでコンテナをマネージドSDで動かすサービス」ですが、用途が根本的に異なります。

「本番の常時稼働Webアプリ」はAKS、「月数回の定期バッチ」「CI/CDのビルドランナー」「開発環境の使い捨てコンテナ」はACIが適しています。AKSの詳細は「Azure Kubernetes Service（AKS）入門」を参照してください。

【実務Tips 2】Virtual Nodesを使ってAKSとACIを連携させる

AKSにはVirtual Nodesという機能があります。AKSクラスターの「仮想ノード」としてACIを接続し、Podをすばやく追加できる仕組みです。

通常のAKSオートスケーリングはノード（VM）を追加するため数分かかります。Virtual Nodesを使うと、急激なトラフィック増大時に数十秒でコンテナを追加できます。ただしVirtual NodesはDaemonSet非対応などの機能制限があるため、本番での利用は慎重に設計する必要があります。

【実務Tips 3】Azure Filesをボリュームとしてマウントする

ACIコンテナ自体はステートレスです。コンテナを再起動するとファイルは消えます。永続化が必要なデータはAzure Files（SMBプロトコルのマネージドファイルストレージ）をマウントして扱います。

# Azure Filesをボリュームとしてマウントする
az container create \
  --resource-group rg-aci-demo \
  --name myapp-persistent \
  --image myapp:latest \
  --azure-file-volume-account-name mystorageaccount \
  --azure-file-volume-account-key <ストレージアカウントのアクセスキー> \
  --azure-file-volume-share-name myfileshare \
  --azure-file-volume-mount-path /data \
  --ports 8080

バッチ処理で入力ファイルを読み込んで結果を書き出す、というパターンでよく活用されます。

【実務Tips 4】再起動ポリシーを正しく設定する

ACIには3種類の再起動ポリシーがあります。

# バッチ処理コンテナには --restart-policy Never を指定する
# Neverを忘れると、バッチ完了後も無限再起動してコストが積み上がる
az container create \
  --resource-group rg-aci-demo \
  --name batch-job \
  --image mybatch:latest \
  --restart-policy Never

よくあるトラブルと対処法

トラブル1: コンテナが起動せず「Waiting」状態が続く

最もよくある原因は、イメージのプルに時間がかかっているか、イメージが存在しないケースです。

# イベントログで原因を確認する
az container show \
  --resource-group rg-aci-demo \
  --name nginx-demo \
  --query "containers[0].instanceView.events" \
  --output table

イメージ名のタグが間違っている（latest以外なのにlatestを指定）、プライベートレジストリの認証情報が誤っている、といったケースが多いです。イベントログのメッセージを確認することで原因が特定できます。

トラブル2: バッチコンテナが終了後に無限再起動してコストが膨らむ

バッチ処理のようにプロセスが正常終了するコンテナに、デフォルトの `Always`（常に再起動）ポリシーが設定されていると、終了→再起動→終了→再起動を繰り返します。1か月後の請求書を見て驚くことになります。

バッチ系コンテナには必ず `–restart-policy Never` または `OnFailure` を指定してください。

トラブル3: VNet内のリソースにコンテナからアクセスできない

ACIをVirtual Networkに接続するには、デプロイ時に `–vnet` と `–subnet` オプションでVNetを指定する必要があります。起動後にVNet構成を変更することはできないため、最初の設計が重要です。

# VNet内のサブネットに接続するコンテナを起動
az container create \
  --resource-group rg-aci-demo \
  --name myapp-vnet \
  --image myapp:latest \
  --vnet myVNet \
  --subnet myAciSubnet \
  --ports 8080

VNet接続はサブネットをACIに委任（Delegation）する設定が必要です。既存のサブネットをそのまま使おうとするとエラーになるケースがあります。`Microsoft.ContainerInstance/containerGroups` へのサブネット委任を事前に設定してください。

トラブル4: DNS名ラベルの競合エラー

`–dns-name-label` に指定するラベルは、リージョン内でグローバルにユニークである必要があります。`nginx-demo` や `myapp` のような一般的な名前はすでに他のユーザーが使っている可能性があります。社名・プロジェクト名・ランダム文字列などを組み合わせてユニークな名前を指定しましょう。

本記事のまとめ

Azure Container Instances（ACI）は、VMもKubernetesクラスターも不要でDockerコンテナをAzure上で動かせるマネージドサービスです。

本記事のポイントをまとめます。
・コンテナグループ: ACI固有の概念で、Kubernetesのポッドに近い。複数コンテナを同一ホストにまとめられる
・起動速度: Azure CLIのコマンド1本で数十秒以内にコンテナが起動する
・料金: vCPU秒＋GBメモリ秒の従量課金。バッチ処理では常時稼働VMと比べてコストを大幅削減できる
・AKSとの使い分け: 短命タスク・バッチ・開発環境はACI、常時稼働・本番マイクロサービスはAKS
・注意点: 再起動ポリシーの設定ミスとコンテナ削除忘れがコスト膨張の主要因

オンプレでDockerを使い始めた方が、最初にクラウドでコンテナを動かす入口として、ACIは最適な選択肢のひとつです。まず小さなバッチ処理や開発用コンテナをACIで動かし、スケールが必要になった段階でAKSへ移行するという段階的なアプローチが、現場での現実的な進め方です。