Visual Studio Code で AKS へのデプロイを自動化したい場合、今回確認すべきポイントは「新しい移行作業が必要か」ではなく、AKS 拡張機能で生成される GitHub Workflow を、組織の権限設計・ACR・namespace・認証方式に合わせて安全に運用できるかです。Microsoft Learn の対象記事は、Visual Studio Code の Azure Kubernetes Service（AKS）拡張から GitHub Workflow を作成し、アプリのビルド、テスト、AKS へのデプロイを CI/CD として扱う手順を説明しています。(Microsoft Learn)
なお、2026年7月3日更新として確認できる実体は、MicrosoftDocs の GitHub 履歴上では日本時間換算で2026年7月3日に反映されたドキュメントメタデータ更新です。対象ファイルには ms.subservice: aks-developer が追加されており、コミット説明でも「front-matter only; no article body content changed」と明記されています。つまり、本文手順そのものに大きな変更が入ったわけではなく、現時点で強制的な設定変更や移行期限が追加された更新ではありません。(GitHub)
Visual Studio Code の AKS 拡張で GitHub Workflow を作成する機能とは
この機能は、Visual Studio Code 上の Azure Kubernetes Service 拡張機能から、AKS 向けの GitHub Actions ワークフロー作成を支援するものです。対象は「Visual Studio IDE」ではなく、Visual Studio Code の AKS 拡張機能です。混同しやすい点ですが、Visual Studio の発行機能ではなく、VS Code の Kubernetes/Azure 操作画面から AKS クラスターを選び、GitHub Workflow の作成に進む流れです。(Microsoft Learn)
GitHub Workflow は、コードのビルド、テスト、コンテナーイメージの作成、Azure Container Registry（ACR）への push、AKS クラスターへのデプロイを自動化するための仕組みです。Microsoft Learn では、GitHub Actions を使うことで ACR から AKS へコンテナーをデプロイでき、AKS 向けのアクションとして azure/aks-set-context、azure/k8s-deploy、azure/k8s-bake、azure/setup-kubectl などが利用できると説明されています。(Microsoft Learn)
実務上の価値は、単に YAML ファイルを作ることではありません。開発者が VS Code から AKS クラスター、ACR、Dockerfile、namespace を選び、デプロイのひな形を短時間で作れるため、初期構築のばらつきを減らせます。一方で、生成されたワークフローをそのまま本番環境に適用すると、権限過多、誤った namespace へのデプロイ、意図しないブランチからの自動反映といった問題が起きやすくなります。
2026年7月3日更新ポイントで見るべきこと
今回の更新ポイントは、機能追加や破壊的変更ではなく、AKS ドキュメントの分類・所有情報の整理と見るのが妥当です。公開ページ側では対象記事の本文が GitHub Workflow 作成手順を説明しており、MicrosoftDocs のコミットでは対象ファイルに ms.subservice: aks-developer が追加されています。(Microsoft Learn)
| 確認項目 | 公式情報から読み取れる内容 | 実務への影響 |
|---|---|---|
| 対象機能 | VS Code の AKS 拡張から GitHub Workflow を作成する手順 | AKS 向け CI/CD の初期作成を支援 |
| 2026年7月3日相当の更新 | ms.subservice: aks-developer の追加 | ドキュメント分類・検索性・管理情報の整理が中心 |
| 本文手順の変更 | コミット説明上は本文変更なし | 既存ワークフローの即時修正は原則不要 |
| 設定変更 | 強制変更は確認できない | ただし生成済み YAML の棚卸しは推奨 |
| 移行期限 | 対象情報内では移行期限の追加は確認できない | 期限対応ではなく運用品質の見直しとして扱う |
| 管理者の確認点 | 認証、ACR、AKS RBAC、namespace、ブランチ保護 | 本番適用前のレビューが重要 |
特に管理者が押さえるべきなのは、「更新されたから何かを移行する」のではなく、「この機能で作ったワークフローが、現在の社内標準に合っているか」を確認することです。たとえば、OIDC を使う設計にするのか、サービスプリンシパルの client secret を使うのか、GitHub Environment の承認を必須にするのか、といった点は、生成ツール任せにせず明示的に決める必要があります。
作成前に必要な前提条件
公式手順では、Visual Studio Code でコードを含むフォルダーを開いていること、現在の workspace が有効な git リポジトリであること、Azure Kubernetes Service 拡張機能がインストールされていることが前提として示されています。(Microsoft Learn)
| 準備するもの | 確認ポイント | よくある失敗 |
|---|---|---|
| Visual Studio Code | 対象プロジェクトのフォルダーを開いている | 空フォルダーや別プロジェクトで作業してしまう |
| git リポジトリ | git status で正常に確認できる | GitHub に push していないローカルだけの状態で進める |
| AKS 拡張機能 | VS Code に Azure Kubernetes Service 拡張をインストール | Kubernetes 拡張だけ入れて AKS メニューが見つからない |
| GitHub リポジトリ | workflow を保存するリポジトリを選べる | 個人リポジトリと組織リポジトリを取り違える |
| Azure サブスクリプション | AKS と ACR が存在する subscription を選ぶ | 検証用 subscription に本番 workflow を作る |
| Dockerfile | ビルド対象の Dockerfile を特定する | Dockerfile の階層と build context が合っていない |
| ACR | push 先の Container Registry を選ぶ | AKS が pull できない ACR を選ぶ |
| AKS クラスター | cluster resource group と cluster を正しく選ぶ | 同名クラスターや別リージョンのクラスターを選ぶ |
| namespace | デプロイ先 namespace を明示する | default に本番アプリを置いてしまう |
前提条件の中で特に事故が多いのは、Dockerfile と build context の組み合わせです。たとえば、リポジトリ直下に Dockerfile があり、アプリ本体が src/app にある構成なのに build context を誤ると、ローカルでは動くのに GitHub Actions 上では依存ファイルが見つからない、という失敗が起きます。
GitHub Workflow の作成手順
公式手順では、GitHub Workflow 作成画面に入る方法として、コマンドパレット経由と Kubernetes view 経由の2通りが示されています。コマンドパレットの場合は Ctrl+Shift+P を開き、必要項目を入力して Create を選びます。Kubernetes view の場合は、Clouds > Azure > サブスクリプション > Automated Deployments 配下で対象クラスターを右クリックし、Create a GitHub Workflow を選択します。(Microsoft Learn)
コマンドパレットから作成する流れ
- Visual Studio Code で対象プロジェクトを開く
Ctrl+Shift+Pでコマンドパレットを開く- AKS 拡張機能の GitHub Workflow 作成コマンドを選ぶ
- Workflow name を入力する
- GitHub repository を選ぶ
- Azure subscription を選ぶ
- Dockerfile と build context を指定する
- ACR Resource Group、Container Registry、ACR image を指定する
- Cluster Resource Group、Cluster、Namespace を指定する
- Deployment option の Type を選び、
Createを実行する
Kubernetes view から作成する流れ
Kubernetes view から進める方法は、AKS クラスターを見ながら操作できるため、複数クラスターを管理している環境で使いやすい方法です。特に、開発・ステージング・本番でサブスクリプションや resource group が分かれている場合は、Kubernetes view で対象クラスターを確認してから作成するほうが誤選択を防ぎやすくなります。
ただし、Kubernetes view から始めても、最終的に確認すべき項目は同じです。Workflow name、GitHub repository、subscription、Dockerfile、build context、ACR、AKS cluster、namespace、deployment type は必ず確認します。公式手順でも、これらの入力項目が作成時に必要な情報として示されています。(Microsoft Learn)
生成された workflow で必ず確認する項目
Automated Deployments では、構成を確認してデプロイすると、選択したコードリポジトリに対して pull request が生成されます。PR を merge すると、GitHub Actions workflow が実行され、アプリケーションをコンテナーイメージにビルドし、ACR に格納し、AKS クラスターへデプロイする流れになります。(Microsoft Learn)
生成された workflow は、作成直後に次の観点でレビューしてください。
| 確認項目 | 見るべきポイント | 本番運用での判断基準 |
|---|---|---|
| トリガー | push、pull_request、対象ブランチ | 本番 deploy は main merge だけ、または environment 承認後に限定 |
| 認証方式 | OIDC か client secret か | 可能なら OIDC を優先し、長期 secret を減らす |
| 権限 | Azure RBAC、AKS RBAC、ACR 権限 | subscription 全体ではなく必要最小スコープ |
| イメージタグ | latest 依存になっていないか | commit SHA、build number、digest などで追跡可能にする |
| namespace | デプロイ先が明示されているか | アプリ単位・環境単位で namespace を分ける |
| manifest | replicas、resources、probe、service 設定 | readiness/liveness probe と resource requests を確認 |
| secret | workflow や manifest に平文がないか | GitHub Secrets、Azure Key Vault、Kubernetes Secret などで管理 |
| rollback | 失敗時に戻せるか | 直前イメージ、Helm release、manifest 履歴を確認 |
| 監視 | デプロイ後に状態を見られるか | Pod、Deployment、Service、Ingress、ログ、メトリックを確認 |
特に重要なのは認証方式です。Microsoft Learn では、GitHub Actions から Azure へ OpenID Connect（OIDC）で認証する場合、Microsoft Entra アプリケーションまたはユーザー割り当てマネージド ID に federated identity credential を構成し、AZURE_CLIENT_ID、AZURE_TENANT_ID、AZURE_SUBSCRIPTION_ID などを GitHub Secrets に登録する流れが説明されています。また、OIDC トークン取得には workflow 側で id-token: write 権限が必要です。(Microsoft Learn)
client secret を使う方式もありますが、長期 secret の漏えいリスクがあるため、公開リポジトリや複数チームで運用するリポジトリでは特に注意が必要です。Microsoft Learn でも、client secret は慎重に扱い、安全に保管し、権限のあるユーザーにのみ共有するよう警告されています。(Microsoft Learn)
影響範囲：開発者、DevOps、管理者で見るポイントが違う
Visual Studio Code の AKS 拡張による GitHub Workflow 作成は、開発者には便利な自動化機能ですが、組織全体では CI/CD 標準、クラウド権限、コンテナーセキュリティに影響します。AKS 拡張自体は、AKS クラスターの表示・管理、診断、AKS Periscope、Azure Service Operator、クラスターの start/stop、GitHub Workflow 作成など複数の操作を VS Code から扱える機能として説明されています。(Microsoft Learn)
開発者への影響
開発者は、AKS 向けの GitHub Actions YAML をゼロから書かなくても、基本形を作成できます。これにより、コンテナー化や Kubernetes デプロイに慣れていないチームでも、最初の CI/CD を構築しやすくなります。
ただし、生成された workflow は「完成品」ではなく「たたき台」と考えるべきです。テスト、脆弱性スキャン、静的解析、承認フロー、環境別変数、リリースノート作成などは、プロジェクトの運用ルールに合わせて追加する必要があります。
DevOps・SRE への影響
DevOps や SRE は、生成された workflow が社内の標準パターンに合っているかを確認します。たとえば、次のような観点です。
- build と deploy が同じ job に詰め込まれていないか
- staging と production の environment が分かれているか
- 本番 deploy に reviewer approval が設定されているか
- 失敗時の通知先が明確か
- deployment の結果を監視基盤で追跡できるか
- Kubernetes manifest に resource requests、limits、probe が設定されているか
GitHub Actions の初期作成が簡単になるほど、レビューなしで本番環境へ反映される危険も増えます。特に main ブランチへの push だけで本番 deploy される設計は、少人数の検証環境では便利でも、チーム開発やグローバル運用では事故につながりやすい構成です。
Azure 管理者への影響
Azure 管理者は、GitHub Actions から Azure に入る ID の権限を確認します。ACR に push する権限、AKS へ deploy する権限、対象 resource group の範囲、namespace 単位の Kubernetes RBAC などを整理します。
グローバル企業では、サブスクリプション、テナント、リージョン、クラウド環境が分かれることがあります。Azure Login action の OIDC 設定では、public cloud 以外の環境では audience などの値を環境に合わせて調整する必要があるため、Azure Government などの非パブリッククラウドでは生成された workflow の認証設定をそのまま使わず確認してください。(Microsoft Learn)
設定変更と移行期限はあるのか
今回確認できる公式情報の範囲では、既存ユーザーに対する強制的な設定変更や移行期限は示されていません。MicrosoftDocs の該当コミットは front matter の更新であり、対象記事では ms.subservice: aks-developer が追加されたのみです。本文手順の変更、非推奨化、期限付き移行、既存 GitHub Workflow の破壊的変更は確認できません。(GitHub)
ただし、移行期限がないからといって放置してよいわけではありません。次の条件に当てはまる環境では、生成済み workflow の見直しをおすすめします。
| 見直すべき状態 | 理由 | 推奨対応 |
|---|---|---|
| client secret で Azure にログインしている | secret 漏えい時の影響が大きい | OIDC 化を検討 |
| subscription 全体に Contributor を付与している | 権限過多になりやすい | resource group または必要操作に絞る |
| 本番 deploy が push だけで実行される | 誤操作がそのまま反映される | environment 承認や branch protection を追加 |
latest タグで deploy している | どのコードが動いているか追跡しにくい | commit SHA や digest を使う |
default namespace に配置している | 権限分離・監視・削除時に混乱しやすい | アプリ・環境ごとに namespace を分ける |
| Dockerfile と build context が曖昧 | CI 上でビルド失敗しやすい | workflow 上でパスを明示 |
| private AKS cluster を使っている | runner から API server に到達できない場合がある | self-hosted runner やネットワーク経路を確認 |
private cluster の場合、AKS へのアクセスには cluster VNet、peering されたネットワーク、private endpoint などからの接続が必要になると Microsoft Learn で説明されています。GitHub-hosted runner から直接到達できない構成では、workflow の deploy ステップだけ失敗することがあるため、ネットワーク到達性の確認が重要です。(Microsoft Learn)
Automated Deployments と Draft の関係
AKS の Automated Deployments は、アプリケーションを Kubernetes へ載せるための作業を支援する機能です。Microsoft Learn では、Dockerfile がない場合に Automated Deployments が生成できること、構成確認後に pull request が作成され、merge によって GitHub Actions workflow が実行される流れが説明されています。(Microsoft Learn)
また、AKS には Draft という関連機能もあります。Draft は、Dockerfile、Kubernetes manifest、Helm chart、Kustomize 構成、GitHub Actions workflow などの生成を支援する open-source プロジェクトとして説明されており、draft setup-gh、draft generate-workflow、draft up などのコマンドが用意されています。(Microsoft Learn)
使い分けの目安は次のとおりです。
| 目的 | 向いている方法 | 判断基準 |
|---|---|---|
| VS Code から対話的に作成したい | AKS 拡張の Automated Deployments | GUI 操作でクラスターや ACR を選びたい |
| CLI で再現可能にしたい | Draft / Azure CLI | チーム標準や自動化スクリプトに組み込みたい |
| 既存の GitHub Actions を拡張したい | 手動で YAML 編集 | すでに CI/CD 標準がある |
| 本番 GitOps を運用している | Flux、Argo CD などと併用検討 | deploy を GitHub Actions 直実行にしない方針がある |
| 検証環境をすばやく作りたい | AKS 拡張の生成機能 | 最短で build・push・deploy を試したい |
ポイントは、Automated Deployments を「本番標準の完成形」として扱わないことです。最初の workflow 作成には便利ですが、複数環境、承認フロー、セキュリティスキャン、SBOM、署名、ポリシー適用まで含める場合は、生成後に必ず組織標準へ合わせ込みます。
管理者が確認すべきチェックリスト
本番または共有環境で Visual Studio Code の AKS 拡張から GitHub Workflow を作成する場合、管理者は次の順番で確認すると抜け漏れを防げます。
GitHub 側の確認
| 項目 | 確認内容 |
|---|---|
| リポジトリ | 個人所有ではなく、適切な organization 管理下にあるか |
| branch protection | main への直接 push を禁止しているか |
| pull request review | 本番反映前にレビューが必須か |
| GitHub Environment | staging、production などが分かれているか |
| environment protection | production に reviewer approval があるか |
| Secrets | 不要な長期 secret が残っていないか |
| workflow permissions | contents: read、id-token: write など必要最小限か |
| runner | private cluster や閉域環境に到達できる runner か |
Azure 側の確認
| 項目 | 確認内容 |
|---|---|
| Microsoft Entra ID | GitHub Actions 用の ID が明確に分かれているか |
| Federated credentials | OIDC の subject が対象 repo・branch・environment に絞られているか |
| Azure RBAC | subscription 全体の Contributor になっていないか |
| ACR 権限 | push する ID と pull する AKS 側 ID の権限が整理されているか |
| AKS RBAC | デプロイに必要な namespace だけ操作できるか |
| Network | private cluster の API server に runner から到達できるか |
| Logs | デプロイ失敗時に GitHub Actions と AKS の両方から追跡できるか |
Kubernetes 側の確認
| 項目 | 確認内容 |
|---|---|
| namespace | アプリ・環境ごとに分離されているか |
| Deployment | replicas、rolling update、resources が適切か |
| probes | readiness/liveness/startup probe が設定されているか |
| Service | type、port、selector が意図どおりか |
| Ingress | TLS、host、ingress class が正しいか |
| Secret | manifest に平文の機密情報が入っていないか |
| ConfigMap | 環境差分がコードと分離されているか |
| Policy | Azure Policy、OPA、Gatekeeper などの制約に違反しないか |
よくある失敗と対策
Visual Studio と Visual Studio Code を混同する
今回の対象は Visual Studio Code の AKS 拡張機能です。Visual Studio IDE の発行ウィザードや、Azure Portal のデプロイ機能とは操作場所が異なります。社内手順書では「Visual Studio」ではなく「Visual Studio Code の AKS extension」と明記したほうが混乱を防げます。
GitHub repository の選択を誤る
組織アカウントのリポジトリに入れるべき workflow を、個人アカウントの fork や検証用 repository に作ってしまうケースがあります。作成前に repository owner、branch、Actions の有効化状態、Secrets の登録場所を確認してください。
Dockerfile と build context がずれる
monorepo では特に起きやすい問題です。たとえば services/api/Dockerfile を使うのに build context をリポジトリ直下にするのか、services/api にするのかで、COPY できるファイルが変わります。ローカル docker build と GitHub Actions の build が同じ条件になるように、workflow 上で明示します。
ACR と AKS の関係を確認していない
workflow が ACR へ push できても、AKS がそのイメージを pull できなければ Pod は起動しません。AKS 側の kubelet identity または managed identity に ACR pull 権限があるか、対象 ACR が正しいかを確認してください。
namespace を安易に default にする
検証では動いても、本番運用では default namespace に複数アプリが混在し、権限分離や削除作業が難しくなります。アプリ名と環境名を含めた namespace を用意し、workflow 側でも明示的に指定するのが安全です。
生成された workflow をレビューせず merge する
Automated Deployments では PR が生成され、merge すると workflow が走ります。つまり、PR レビューを省略すると、生成された設定がそのまま CI/CD として動きます。PR の Files changed で YAML、manifest、Dockerfile、環境変数、対象 cluster を必ず確認してください。(Microsoft Learn)
導入判断：使うべきケースと慎重に扱うべきケース
Visual Studio Code の AKS 拡張による GitHub Workflow 作成は、すべての AKS 運用に最適な方法ではありません。導入判断では、チームの成熟度と本番環境の制約を見ます。
| 状況 | 推奨度 | 理由 |
|---|---|---|
| 初めて AKS 向け CI/CD を作る | 高い | ひな形を短時間で作れる |
| 開発環境・検証環境に deploy したい | 高い | GUI で対象リソースを選びやすい |
| 小規模チームで標準化を始めたい | 中〜高 | 生成後にテンプレート化しやすい |
| 本番環境へ直接 deploy したい | 中 | 承認、権限、監査を追加すれば有効 |
| 金融・医療・公共など厳格な統制環境 | 低〜中 | 生成物をそのまま使わず、統制要件に合わせる必要がある |
| GitOps で Argo CD / Flux を使っている | 低〜中 | GitHub Actions から直接 deploy する設計と衝突する場合がある |
| 複数リージョン・複数テナント運用 | 中 | workflow の分岐、認証、承認設計を追加する必要がある |
おすすめは、まず開発環境で生成された workflow を確認し、それを社内標準の GitHub Actions テンプレートに落とし込む進め方です。いきなり本番 repository に作成するより、検証用 repository で YAML の構造、必要な Secrets、Azure RBAC、ACR push、AKS deploy の流れを確認したほうが安全です。
次に取るべき行動
今回の更新では、本文手順の大きな変更や移行期限は確認できません。したがって、管理者がすぐに行うべきことは移行作業ではなく、既存または今後作成する AKS 向け GitHub Workflow の運用レビューです。具体的には、Visual Studio Code の AKS 拡張で workflow を作成し、PR の差分を確認し、OIDC 認証、最小権限、ACR と AKS の権限、namespace、branch protection、environment approval を整備します。
特に本番利用では、「作成できること」と「安全に運用できること」を分けて考える必要があります。AKS 拡張機能は CI/CD の出発点を作るには便利ですが、最終的な品質は workflow のレビュー、権限設計、デプロイ後の監視、ロールバック手順で決まります。まずは検証環境で生成された YAML を確認し、自社の標準テンプレートとして使える形に整えることから始めてください。
コメント