MENU

Azure App Serviceカスタムコンテナーの2026年4月更新ポイント｜Quickstartの変更点と実務チェック

Azure

Azure App Serviceでカスタムコンテナーを動かす場合、2026年4月更新の「Quickstart: Run a Custom Container on App Service」で最も見るべきポイントは、派手な新機能ではなく、手順の正確性と実務でつまずきやすい箇所の整理です。特に、Windows/Linuxの選択、Azure Container Registryとの接続、ポート設定、起動ログ、マネージドIDによるイメージ取得は、検証段階から確認しておくべきです。

Microsoft Learnの対象ページは、Azure App Serviceでカスタムコンテナーを実行する方法を説明するクイックスタートです。公式リポジトリ上のメタデータでは ms.date が2026年4月20日、GitHub履歴では2026年4月21日の「Refresh article」コミットが確認できます。2026年4月24日付の更新情報として社内共有する場合でも、一次情報としては「2026年4月下旬更新」または「Microsoft Learn上の更新表示は2026年4月20日」と併記すると安全です。(GitHub)

目次

Azureの最新動向: Quickstart: Run a Custom Container on App Serviceで何が変わったか

今回の更新は、Azure App Serviceのカスタムコンテナー利用を「初回検証から本番準備へつなげやすくする」ための整備と見るのが実務的です。対象ページは、Azure Container RegistryからAzure App Serviceへコンテナーイメージをデプロイする手順を中心に、Windows、Linux、Visual Studio、Visual Studio Code、Azure Portal、PowerShell、Azure CLIの複数ルートを扱っています。(Microsoft Learn)

観点2026年4月更新で確認すべきポイント実務への影響
更新範囲GitHub上では10ファイルの変更、47行追加・52行削除の「Refresh article」として記録されています。(GitHub)大規模な機能追加というより、既存手順の誤解や古い表記を減らす更新と捉えるべきです。
WindowsコンテナーのPortal手順Windows向け手順で、OS選択がLinuxではなくWindows、イメージ選択が dotnetcore-docs-hello-world-windows へ修正されています。(GitHub)IT管理者が検証環境を作る際、OSとイメージの不一致による起動失敗を避けやすくなります。
Visual Studio手順前提条件の表記がDocker Desktop for Windowsへ明確化され、Azure Container Registryのイメージ指定ではDocker HubではなくOther container registriesを選ぶ形に修正されています。(GitHub)古いUIや旧称に引っ張られず、現在のAzure Portal/開発環境に合わせて操作できます。
CLI/PowerShell手順Webアプリ名の例が固定名ではなく <your-container-app> のようなプレースホルダーに整理され、コピーペースト時の名前重複を避けやすくなっています。(GitHub)自社の命名規則に合わせて、検証用スクリプトを本番向けIaCや運用スクリプトへ展開しやすくなります。
運用関連リンクAzure Monitor、App Serviceの監視、Private Endpointなど、関連コンテンツのリンクが更新されています。(GitHub)「デプロイできた」で終わらせず、監視・ネットワーク・認証まで確認する導線が明確になります。

Azure App Serviceでカスタムコンテナーを使う意味

Azure App Serviceのカスタムコンテナーは、通常の組み込みランタイムでは足りないWebアプリやAPIを、独自のDockerイメージで動かしたいときに有効です。App Service on Linuxには.NET、Java、Node.js、PHPなどの定義済みスタックがありますが、定義済みスタックにない構成でもカスタムDockerイメージを使えば実行できます。Windowsコンテナーでは、事前構成されたスタックでは制限される低レベルなOS機能へのアクセスが必要なケースにも対応しやすくなります。(Microsoft Learn)

実務では、次のような場面で検討価値があります。

使うべきケース具体例
既存Webアプリを大きく作り替えずにAzureへ移したい.NET Framework/IISベースのアプリをWindowsコンテナー化して段階的に移行する
標準ランタイムでは不足する依存関係がある特定のOSパッケージ、独自ライブラリ、社内標準のミドルウェアを含めたい
Kubernetesほどの運用負荷は必要ない単体のWebアプリ、管理画面、APIをPaaS寄りに運用したい
開発チームの成果物をイメージ単位で統一したいローカル、検証、本番で同じコンテナーイメージを使い、差分を減らしたい

一方で、マイクロサービスをサーバーレス寄りに動かしたい場合はAzure Container Apps、Kubernetes前提の高度なオーケストレーションが必要な場合はAKSも候補になります。Azure Container Appsはマイクロサービスやコンテナー化アプリをサーバーレス基盤で実行するサービスとして説明されており、AKSはコンテナー化アプリのデプロイと管理に使うマネージドKubernetesサービスです。(Microsoft Learn)

まず決めるべき設計ポイント

LinuxコンテナーかWindowsコンテナーか

新規のWebアプリやOSS系スタックなら、まずLinuxコンテナーを検討するのが自然です。軽量に始めやすく、Node.js、Python、Java、.NETなどの一般的なWebアプリと相性が良いからです。

一方、.NET Framework、IIS、Windows固有API、既存Windowsサーバー資産を前提にしている場合は、Windowsコンテナーが候補になります。Microsoftの構成ドキュメントでも、.NET FrameworkアプリにはWindows Server Long-Term Servicing Channelベースの親イメージを使う考え方が示されています。(Microsoft Learn)

注意したいのは起動時間です。Windowsコンテナーはイメージサイズや親イメージの状態によって起動に時間がかかることがあります。Quickstartでも、Windowsコンテナーの起動状況を確認するために https://<app_name>.scm.azurewebsites.net/api/logstream のログストリームを見る手順が紹介されています。(Microsoft Learn)

レジストリはAzure Container Registryを基本にする

QuickstartではAzure Container Registryを使う流れが中心です。検証では手順を簡単にするため、レジストリのAdmin Userを有効化する説明が出てくる場合がありますが、本番運用ではマネージドIDでApp ServiceからACRへPullする構成を優先して検討すべきです。Microsoftの構成ドキュメントでは、WindowsコンテナーのイメージPull認証でサービスプリンシパルはサポートされなくなっており、Windows/Linuxの両方でマネージドIDの利用が推奨されています。(Microsoft Learn)

最小限の考え方は次の通りです。

環境認証方式の考え方
個人検証・短期デモQuickstart通りに進めてもよい。ただし終了後はリソースを削除する
社内PoCACR、App Service、マネージドID、AcrPullロールをセットで確認する
本番管理者ユーザーや固定パスワードに依存せず、マネージドIDとRBACを基本にする

ポート番号はデプロイ前に確認する

App Serviceは、既定ではカスタムコンテナーがポート80で待ち受ける前提で扱います。アプリが8080や8000など別のポートで待ち受ける場合は、WEBSITES_PORT をApp Serviceのアプリ設定に入れる必要があります。また、App ServiceのカスタムコンテナーではHTTPリクエスト用に公開できるポートは1つです。(Microsoft Learn)

az webapp config appsettings set \
  --resource-group <group-name> \
  --name <app-name> \
  --settings WEBSITES_PORT=8080

「ローカルでは動いたのにAzureでは応答しない」という失敗は、ポート設定の不一致が原因になりやすいです。Dockerfileの EXPOSE、アプリ側の待ち受けポート、App Serviceの WEBSITES_PORT を同じ設計として確認しましょう。

ログ確認を最初から手順に入れる

App ServiceではDockerホスト側のログは既定で有効ですが、コンテナー内アプリケーションのログやWebサーバーログは手動で有効化が必要です。ログはAzure Portal、Kudu、Kudu API、Azure Monitorなどから確認できます。(Microsoft Learn)

CLIで確認する場合は、次の流れを検証手順に入れておくとトラブル対応が速くなります。

az webapp log config \
  --name <app-name> \
  --resource-group <resource-group-name> \
  --docker-container-logging filesystem

az webapp log tail \
  --name <app-name> \
  --resource-group <resource-group-name>

コンテナーのPullに失敗しているのか、起動はしたがHTTPヘルスチェックに応答していないのか、アプリ内部で例外が出ているのかを切り分けるには、ログを見ずにPortalの状態表示だけで判断しないことが重要です。

IT管理者・プロダクトオーナーが見るべき判断基準

IT管理者は「動くか」より「運用できるか」を見る

IT管理者がAzure App Serviceのカスタムコンテナーを評価する場合、初回デプロイの成功だけで判断しない方がよいです。次の項目を検証環境で確認してから、社内標準の手順に落とし込みましょう。

確認項目見るべきポイント
認証App ServiceのマネージドIDにACRのAcrPull権限を付与できているか
ネットワークPrivate Endpoint付きACRやVNet統合が必要か
ログ起動ログ、アプリログ、Azure Monitor連携を確認できるか
更新新しいイメージをPushした後、再起動やデプロイフローで反映できるか
削除検証用リソースグループを安全に削除できるか

ネットワークで保護されたレジストリからイメージをPullする場合、App ServiceのVNet統合やDNS解決、vnetImagePullEnabled の設定も検討が必要です。(Microsoft Learn)

プロダクトオーナーは「AKSが必要か」を先に決める

プロダクトオーナー視点では、最初からAKSを選ぶべきか、App Serviceで十分かを判断することが重要です。単一のWebアプリやAPIを早く公開し、インフラ運用を軽くしたいならApp Serviceのカスタムコンテナーは有力です。複数サービス間の細かな通信制御、Kubernetesネイティブな運用、プラットフォームチームによる標準化が必要ならAKSを検討します。

選択肢向いている用途避けたい使い方
App Service カスタムコンテナーWebアプリ、API、管理画面、既存アプリ移行複雑なコンテナーオーケストレーションを無理に載せる
Azure Container Appsサーバーレス寄りのコンテナー化アプリ、マイクロサービスApp Service前提の既存Web運用をそのまま移すだけのケース
AKSKubernetes標準の運用、複数サービス、高度なスケーリングやDevOps連携Kubernetes運用体制がない小規模Webアプリ

この判断を誤ると、技術的には動いても、運用コストやリリース速度で損をします。まずは「必要な自由度」と「運用できる体制」のバランスで選びましょう。

Quickstartを実務で使う手順

Quickstartは学習用の手順ですが、そのまま本番環境へコピーするものではありません。社内で使う場合は、次の順序で実務向けに変換すると失敗が少なくなります。

手順実施内容実務での注意点
検証ルートを選ぶPortal、VS Code、Visual Studio、CLI、PowerShellのどれで試すか決める本番に近い運用を見たいならCLI/PowerShellも確認する
リソースグループを作るQuickstartでは myResourceGroup などの例が使われる本番では命名規則、タグ、権限境界を決める
イメージを作るDockerfileからイメージをビルドするlatest だけに頼らず、日付やビルド番号のタグを使う
ACRへPushするAzure Container Registryへイメージを登録するPull権限をマネージドIDに寄せる
App ServiceへデプロイするOS、レジストリ、イメージ、タグを指定するWindows/Linuxとイメージ名の整合性を確認する
ログとポートを確認する起動ログ、WEBSITES_PORT、アプリログを確認する「起動中」のままならログを先に見る
更新手順を試す新しいイメージをPushし、App Serviceを再起動して反映を確認するApp Serviceは起動時にレジストリからイメージをPullします。更新をすぐ反映したい場合は再起動が必要です。(Microsoft Learn)
クリーンアップする不要なリソースグループを削除する検証環境の放置はコストとセキュリティリスクになります

失敗しやすいポイントと対策

失敗例原因対策
Windowsコンテナーが起動しないOS選択がLinux、またはLinux用イメージを選んでいるPortalのOS、ACR上のイメージ名、タグを確認する
ACRからPullできない認証情報、権限、ネットワーク設定が不足しているマネージドIDにAcrPullを付与し、Private Endpoint利用時はVNet統合も確認する
ブラウザーで応答しないコンテナーの待ち受けポートとApp Service設定が違うWEBSITES_PORT を設定し、アプリ側の待ち受けポートと合わせる
新しいイメージが反映されないPush後にApp Serviceが古いイメージを使い続けているタグ運用を見直し、必要に応じてApp Serviceを再起動する
ログが見えず原因が分からないアプリケーションログが有効化されていないaz webapp log config と az webapp log tail を検証手順に入れる
Docker Compose前提で設計しているApp ServiceのDocker Compose機能には将来的な変更がある公式ドキュメントではDocker Compose機能が2027年3月31日に廃止予定で、Sidecarへの移行が案内されています。(Microsoft Learn)

本番前チェックリスト

公開前には、少なくとも次の項目を確認してください。

  • コンテナーイメージのタグは、リリース単位で追跡できる形式になっている
  • App ServiceのOS設定とコンテナーイメージのOSが一致している
  • ACR PullはマネージドIDとRBACで制御している
  • WEBSITES_PORT がアプリの待ち受けポートと一致している
  • 起動ログとアプリログを確認できる
  • アプリ設定や接続文字列にシークレットを直書きしていない
  • Private EndpointやVNet統合が必要な場合、名前解決まで検証している
  • 不要な検証用リソースを削除できる手順がある
  • 障害時に、前のイメージタグへ戻す手順がある
  • App Service、Container Apps、AKSのどれを選ぶべきか、プロダクト要件に照らして説明できる

まとめ: 2026年4月更新は「手順の精度」を見直すタイミング

Azure App Serviceのカスタムコンテナーは、既存Webアプリの移行や標準ランタイムでは足りない構成に対して、Kubernetesほど重くない選択肢を提供します。2026年4月更新のQuickstartは、新機能の追加というより、Windows/Linuxの選択ミス、レジストリ指定、CLI/PowerShellのコピーしやすさ、監視・ネットワーク関連リンクの整理によって、実務での失敗を減らす更新と捉えるべきです。

次に取るべき行動は明確です。まず検証環境でQuickstartを1回通し、次にACR、マネージドID、ログ、ポート、更新手順を自社標準に置き換えてください。最後に、App Serviceで十分か、Container AppsやAKSが必要かを判断すれば、プロダクトの規模と運用体制に合ったAzureコンテナー基盤を選びやすくなります。

Azure
Azure Azure App Service カスタムコンテナー Azure Container Registry

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次