Azure Container Instances入門|VMを作らずにアプリを数分で動かすACIデプロイ手順

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)Azure > Azure Container Instances入門|VMを作らずにアプリを数分で動かすACIデプロイ手順
「VMを用意せずにコンテナアプリをAzureで動かしたい。でも、AKSやApp Serviceほど大げさな構成は要らない」
Azureを学び始めたエンジニアからよく聞かれる声です。仮想マシンを建てれば自由度は高いですが、OSのプロビジョニング・セキュリティパッチ・ネットワーク設定など、アプリ本体とは直接関係ない作業が積み重なります。

この記事では、Azure Container Instances(ACI)を使ってコンテナアプリを数分で起動する手順を解説します。azure container instancesの基本概念からVM・AKSとの使い分け、Azure CLIによるaz container createコマンド操作、環境変数・ポート公開の設定、ログ確認とアクセス方法、コスト管理と削除手順まで一通りカバーします。

動作確認環境:Azure CLI 2.61.0、Rocky Linux 9.4 / Ubuntu 24.04 LTS。

この記事のポイント

・az container createコマンド1本でVMなしにコンテナが数分で起動できる
・ACIはバッチ処理・検証・小規模APIで最もコスパが高いコンテナ実行の選択肢
・環境変数・ポート公開・DNSラベルはcreate時のオプションで一括設定する
・az container logsとaz container showで動作確認と障害調査ができる


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
図解60P/登録10秒/解除も3秒 / 詳細はこちら

Azure Container Instances(ACI)とは何か

Azure Container Instances(以下 ACI)は、Microsoftが提供するサーバーレスなコンテナ実行サービスです。仮想マシンもKubernetesクラスターも用意せずに、DockerイメージをAzure上で直接起動できます。

従来、Azureでコンテナアプリを動かすには次のような手順が必要でした。
・Azure VMを作成してLinux OSをセットアップする
・Dockerをインストール・設定する
・コンテナを起動して監視する

ACIではこの作業が大幅に省略されます。Azure CLIでaz container createコマンドを1行実行するだけで、数分以内にコンテナが稼働状態になります。OSの管理はAzure側が担うため、エンジニアはアプリとコンテナイメージに集中できます。

ACIが得意とするユースケースは次の通りです。
バッチ処理・定期ジョブ:実行時間だけ課金されるため、常時稼働のVMより安価
CI/CDパイプラインのビルドステップ:短命なコンテナを高速に起動・削除できる
検証・プロトタイプ:本番環境を用意せずに機能確認できる
小規模APIやWebhookエンドポイント:常時稼働が必要でもAKSほどの規模でない場合

ACIはAzureのコンテナサービス群の中でも最もシンプルで即起動な選択肢に位置付けられています。複雑なオーケストレーションは不要で、「とにかくコンテナを動かしたい」という局面に最適です。

ACIとVMの違い・使い分けポイント

「ACI・VM・AKS・App Service、どれを使えばいいのか」はAzure学習者が最初に迷うポイントです。以下の比較で整理しましょう。

比較項目 Azure VM(IaaS) ACI(サーバーレスコンテナ) AKS(Kubernetes)
OS管理 自分で実施 不要 不要(ノードは必要)
起動時間 数分(プロビジョニング込み) 数十秒から数分 クラスター構築に数分
スケール 手動またはVMSS コンテナグループ単位 Pod/Nodeの自動スケール
ステートフル対応 Azure Filesマウント等 Azure Files共有マウント可 PersistentVolume
コスト粒度 VM稼働時間単位 CPU/メモリの秒単位 ノード稼働時間単位
向いているケース OS細かく制御が必要 短命・バッチ・検証 本番マイクロサービス

判断の目安としては次のように考えるとシンプルです。
OSレベルの設定変更が必要 → VM
コンテナを手軽に動かして検証したい、バッチを回したい → ACI
マイクロサービスを本番で運用する → AKS
アプリコードだけデプロイしてOSを触りたくない → App Service

ACIは「VMを建てるには大げさすぎる」「AKSを運用する規模でもない」という中間的なニーズに的確にはまるサービスです。Dockerイメージさえ用意できれば、数分でAzure上に動作環境が整います。

Azure CLIのセットアップと事前準備

ACIを操作するにはAzure CLIが必要です。自分のLinux PCへのインストール手順は以下の通りです。

1. Azure CLIのインストール(Linux)

RHELやRocky Linux / AlmaLinuxの場合は以下のコマンドでインストールできます。

# add microsoft rpm repository and install azure-cli sudo rpm --import https://packages.microsoft.com/keys/microsoft.asc sudo dnf install -y https://packages.microsoft.com/config/rhel/9.0/packages-microsoft-prod.rpm sudo dnf install -y azure-cli

Ubuntuの場合は公式のaptリポジトリが提供されています。

# install azure-cli on ubuntu 22.04 / 24.04 LTS curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash

インストール後、バージョンを確認します。

az version # output example { "azure-cli": "2.61.0", "azure-cli-core": "2.61.0", "azure-cli-telemetry": "1.1.0" }

2. Azureアカウントへのログイン

# open browser and login to azure account az login

ブラウザが開き、Microsoftアカウントでの認証が求められます。認証が完了するとターミナルにサブスクリプション情報がJSON形式で表示されます。

3. リソースグループの作成

Azureリソースはすべてリソースグループにまとめてデプロイします。今回はハンズオン用のグループを作成します。

# create resource group in japan east region az group create \ --name aci-demo-rg \ --location japaneast # output: provisioningState should be "Succeeded" { "id": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/aci-demo-rg", "location": "japaneast", "name": "aci-demo-rg", "properties": { "provisioningState": "Succeeded" } }

ACIでコンテナを動かす基本手順(az container create)

環境が整ったら、実際にACIでコンテナを起動してみましょう。Microsoftが提供するサンプルイメージ(aci-helloworld)を使います。

1. コンテナの作成と起動

# create and start a container with public http access az container create \ --resource-group aci-demo-rg \ --name aci-helloworld \ --image mcr.microsoft.com/azuredocs/aci-helloworld \ --ports 80 \ --dns-name-label aci-demo-handson \ --location japaneast

各オプションの意味は次の通りです。
--resource-group:デプロイ先のリソースグループ名
--name:コンテナグループの名前
--image:使用するDockerイメージ(今回はMicrosoft Container Registryのサンプル)
--ports:公開するポート番号(80番)
--dns-name-label:パブリックIPに割り当てるDNSラベル(リージョン内で一意な名前が必要)

【注意】--dns-name-label同一リージョン内でユニークでなければなりません。すでに使われているラベルを指定するとエラーになります。日付や乱数を付与して重複を避けてください。

コマンド実行から1分から3分程度でコンテナが起動します。完了後にJSONが表示されるのでfqdnフィールドを確認してください。

2. 起動後の状態確認

Status: "Running" と表示されれば起動成功です。以下のコマンドでIPアドレスとFQDNを確認します。

# show container status, fqdn, and ip address az container show \ --resource-group aci-demo-rg \ --name aci-helloworld \ --query "{Status:instanceView.state, FQDN:ipAddress.fqdn, IP:ipAddress.ip}" # output example: running state with public ip { "FQDN": "aci-demo-handson.japaneast.azurecontainer.io", "IP": "20.89.xxx.xxx", "Status": "Running" }

ACIの実践スキルも、Linuxサーバー構築の「型」から体系的に理解できます

az container create でコンテナを起動できても、「どうネットワーク設計するか」「本番でどう運用するか」を説明できるかどうかで現場での信頼が変わります。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、Azureハンズオン学習コースでは実機を使った演習で即戦力スキルを習得できます。

「Linuxの基礎から体系的に学びたい」という方には、『Linuxサーバー構築入門マニュアル(図解60P)』を無料でプレゼントしています。こちらから無料ダウンロード

環境変数・ポート公開・リソースグループの設定

実際のアプリをデプロイする場面では、環境変数による設定値の受け渡しやポート番号のカスタマイズが必要になります。

1. 環境変数の設定

--environment-variablesオプションで環境変数を渡せます。

# pass environment variables to the container az container create \ --resource-group aci-demo-rg \ --name aci-myapp \ --image myregistry.azurecr.io/myapp:latest \ --ports 8080 \ --dns-name-label aci-myapp-demo \ --environment-variables \ APP_ENV=production \ LOG_LEVEL=info \ --location japaneast

データベースパスワードなど機密情報を渡す場合は--secure-environment-variablesを使います。こちらはAzure Portal・CLIのログ出力にも値が表示されないため安全です。

# use secure env vars for sensitive values (hidden from logs) az container create \ --resource-group aci-demo-rg \ --name aci-myapp \ --image myregistry.azurecr.io/myapp:latest \ --ports 8080 \ --dns-name-label aci-myapp-demo \ --environment-variables APP_ENV=production \ --secure-environment-variables DB_PASSWORD=your_secret_here \ --location japaneast

2. CPUとメモリのリソース指定

デフォルトではCPU 1コア・メモリ 1.5GBが割り当てられます。--cpu--memoryオプションで変更できます。

# create a batch job container: 2 cpu cores, 4GB ram, no restart az container create \ --resource-group aci-demo-rg \ --name aci-batch \ --image myregistry.azurecr.io/batch-job:latest \ --cpu 2 \ --memory 4 \ --restart-policy Never \ --location japaneast

バッチ処理の場合は--restart-policy Neverを指定することで、処理完了後にコンテナが再起動しないようにできます。

3. Azure Container Registry(ACR)のプライベートイメージを使う

自分のACRにプッシュしたプライベートイメージを使う場合は認証情報も合わせて指定します。

# check acr admin credentials before use az acr credential show --name myregistry --query "{user:username,pass:passwords[0].value}" # create container from private acr image with registry credentials az container create \ --resource-group aci-demo-rg \ --name aci-private \ --image myregistry.azurecr.io/myapp:latest \ --registry-login-server myregistry.azurecr.io \ --registry-username \ --registry-password \ --ports 8080 \ --dns-name-label aci-private-demo \ --location japaneast

【注意】認証情報をコマンドに直書きするのは検証目的のみにしてください。本番運用ではACIにマネージドIDを付与し、ACRへの認証情報を安全に受け渡す構成を推奨します。

ログ確認・コンテナへのアクセス方法

コンテナが起動したら、動作確認とトラブルシューティングに必要なログ確認の手順を覚えておきましょう。

1. ログを表示する(az container logs)

# show stdout/stderr logs from the container az container logs \ --resource-group aci-demo-rg \ --name aci-helloworld # output example: nginx access log entries listening on port 80 ::ffff:10.240.255.31 - - [18/Jul/2026:06:30:12 +0000] "GET / HTTP/1.1" 200 1663 "-" "Mozilla/5.0 ..." ::ffff:10.240.255.31 - - [18/Jul/2026:06:30:13 +0000] "GET /favicon.ico HTTP/1.1" 200 946 "-" "..."

リアルタイムにログを追いたい場合は--followオプションを付けます。

# tail logs in real time (press Ctrl+C to stop) az container logs \ --resource-group aci-demo-rg \ --name aci-helloworld \ --follow

2. コンテナ内でコマンドを実行する(az container exec)

実行中のコンテナ内でシェルコマンドを実行できます。ファイルの存在確認や環境変数の確認に役立ちます。

# open an interactive bash shell inside the running container az container exec \ --resource-group aci-demo-rg \ --name aci-helloworld \ --exec-command "/bin/bash"

3. コンテナの詳細状態を確認する(az container show)

コンテナの起動イベント履歴を確認するには--queryでイベント情報を絞り込みます。起動失敗時のトラブルシューティングに特に有効です。

# check container events to diagnose startup failures az container show \ --resource-group aci-demo-rg \ --name aci-helloworld \ --query "containers[0].instanceView.events[]" # output example: successful startup event sequence [ { "count": 1, "firstTimestamp": "2026-07-18T06:28:00+00:00", "lastTimestamp": "2026-07-18T06:28:00+00:00", "message": "pulling image ...", "name": "Pulling", "type": "Normal" }, { "count": 1, "firstTimestamp": "2026-07-18T06:28:45+00:00", "lastTimestamp": "2026-07-18T06:28:45+00:00", "message": "Started container", "name": "Started", "type": "Normal" } ]

Linuxサーバー側からACIへのネットワーク疎通を確認する際は、Linux ポート確認の全コマンドも参考にしてください。

ACIのコスト管理と削除手順

ACIの課金はコンテナが実際に動作している時間(秒単位)に対してのみ発生します。VMと違い、停止中は課金されません。

1. ACIの料金の考え方

ACIの課金は「vCPU秒」と「メモリGB秒」の2軸で計算されます。japaneastリージョンの目安は次の通りです(2026年7月時点・概算)。

リソース 単価目安
vCPU 約 0.0015円 / vCPU・秒
メモリ 約 0.00017円 / GB・秒

1コア・1.5GBで1時間(3,600秒)稼働させた場合、CPU代 0.0015円 × 3,600秒 = 5.4円、メモリ代 0.00017円 × 1.5GB × 3,600秒 = 0.9円で合計約6.3円です。バッチ処理で10分だけ使えば1円未満で済む計算になります。

2. コンテナの停止(課金停止)

# stop the container to halt billing (can restart later) az container stop \ --resource-group aci-demo-rg \ --name aci-helloworld

停止状態では課金が止まります。再度起動するにはaz container startを使います。

# restart a stopped container az container start \ --resource-group aci-demo-rg \ --name aci-helloworld

3. コンテナの削除

ハンズオン終了後は必ずコンテナを削除してください。

# delete a specific container (--yes skips confirmation prompt) az container delete \ --resource-group aci-demo-rg \ --name aci-helloworld \ --yes

4. リソースグループごと削除する

ハンズオン全体のリソースをまとめて削除するには、リソースグループごと削除します。

# delete the entire resource group and all its resources az group delete \ --name aci-demo-rg \ --yes \ --no-wait

--no-waitオプションを付けると削除完了を待たずにコマンドが返ります。削除状況はaz group show --name aci-demo-rgで確認できます。

よくあるエラーとトラブルシュート

ACIを初めて使う際にはまりやすいエラーと対処法を整理します。

1. イメージが見つからない・プルに失敗する

# check container events for image pull error az container show \ --resource-group aci-demo-rg \ --name aci-helloworld \ --query "containers[0].instanceView.events[]" # error example: image not found or wrong tag { "message": "Failed to pull image: mcr.microsoft.com/azuredocs/aci-helloworld:wrong-tag", "name": "Failed", "type": "Warning" }

対処法は次の通りです。
イメージ名とタグのタイポ:`docker pull` で手元のLinux PCから取得できるか確認する
プライベートACRへの認証失敗--registry-username--registry-password の指定を見直す
ACRへのネットワーク制限:ACRのファイアウォール設定でACI発のアクセスが許可されているか確認する

2. ポートにアクセスできない

コンテナがRunning状態でもブラウザからアクセスできない場合は次を確認してください。

--ports の指定漏れaz container create時に--ports 80を指定し忘れるとパブリックポートが開放されない
アプリのリッスンポートとの不一致:アプリが内部で8080番でリッスンしているのに--ports 80を指定している場合はアクセスできない
DNSラベル未指定--dns-name-label を指定しないとパブリックFQDNが割り当てられず、IPアドレス経由のみになる

3. 停止・再起動後にIPアドレスが変わった

【要注意】ACIはコンテナを停止・再起動するとパブリックIPアドレスが変わることがあります。固定IPが必要な場合はAzure Load BalancerやAPI Managementとの組み合わせを検討してください。DNSラベルを設定している場合はFQDNのほうが変化しにくいため、URLには常にFQDNを使う運用を推奨します。

Linuxのネットワーク疎通やDNS名前解決の確認方法はLinux DNS 設定の基本も参考にしてください。

まとめ・次のステップ

この記事ではAzure Container Instances(ACI)の基本から実践手順まで解説しました。要点をまとめます。

やりたいこと コマンド
コンテナを起動する az container create --resource-group RG --name NAME --image IMAGE --ports PORT
コンテナの状態を確認する az container show --resource-group RG --name NAME
ログを確認する az container logs --resource-group RG --name NAME
コンテナ内でコマンドを実行する az container exec --resource-group RG --name NAME --exec-command CMD
コンテナを停止する az container stop --resource-group RG --name NAME
コンテナを起動する(停止後) az container start --resource-group RG --name NAME
コンテナを削除する az container delete --resource-group RG --name NAME --yes
リソースグループごと削除する az group delete --name RG --yes

ACIはVMを建てず、Kubernetesを管理せずにコンテナをすぐ動かせる、Azureコンテナ入門として最適な出発点です。次のステップとしては以下を参考にしてください。

Azure App ServiceへのWebアプリ移行:常時稼働するWebアプリにはApp Serviceの方がコスト効率が良い場合があります
Azure Kubernetes Service(AKS):マルチコンテナの本番運用規模になったらAKSへの移行を検討する
Azure Container Registry(ACR)との連携:プライベートリポジトリからACIへのデプロイをCI/CDに組み込む

Azure Container Instancesの実践スキルも、Linuxサーバー構築の「型」から体系的に理解できます

コンテナを起動できても、「どう設計するか」「本番でどう運用管理するか」を説明できる力が現場では問われます。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、Azureハンズオン学習コースでは実機を使った演習で即戦力スキルを習得できます。

「Linuxの基礎から体系的に学びたい」という方には、『Linuxサーバー構築入門マニュアル(図解60P)』を無料でプレゼントしています。こちらから無料ダウンロード

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒/合わなければ解除3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。