2026年6月17日、MicrosoftはAzure TechCommunityで「Accelerating AKS troubleshooting with the Azure Copilot Observability Agent」を公開しました。
結論から言えば、今回の中心はAKSのバージョンアップではありません。Azure MonitorのAzure Copilot Observability Agentが、Kubernetesイベント、メトリック、ログ、変更履歴、アプリケーションテレメトリを横断し、障害原因の候補と次の対応をまとめられるようになる点です。既存のAzure Monitorデータだけでも利用を始められますが、収集している監視データが多いほど調査結果は具体的になります。(TECHCOMMUNITY.MICROSOFT.COM)
AKSクラスターの必須移行や更新期限は案内されていません。一方、Observability Agentの課金は2026年7月1日に開始されるため、管理者はアクセス権、監視設定、利用ルール、予算への影響を事前に確認しておく必要があります。(Microsoft Learn)
Azure TechCommunityで明らかになった変更点
今回の公式記事は、AKSに破壊的変更を加えるリリースノートではありません。Azure Copilot Observability Agentを使い、AKS障害をアプリケーション層からインフラ層まで一つの調査として扱う方法を示したものです。
| 確認項目 | 要点 |
|---|---|
| 何が変わるか | AKS、Azure Monitor、Application Insightsの情報を横断し、原因候補、根拠、推奨対応をまとめて確認できる |
| 主な対象者 | AKS管理者、SRE、プラットフォーム担当者、アプリケーション運用担当者 |
| 必須設定 | すべての監視機能を有効にする必要はない。ただし、ログやメトリックが不足すると調査精度も下がる |
| AKSの更新 | 6月17日付記事では、AKSバージョンやノードイメージの必須更新は案内されていない |
| 移行作業 | クラスター側の必須移行手順や移行期限は案内されていない |
| 料金 | Azure Agent Creditによる従量課金。監視対象リソースが属するサブスクリプションに請求される |
| 期限 | Observability Agentの課金開始日は2026年7月1日 |
AKS運用で重要なのは、単にログを要約してもらえることではありません。アプリケーションのHTTP 5xx増加、Podの再起動、ノードのリソース逼迫、直前のデプロイ変更などを時系列で関連付けられる点が大きな変更です。(TECHCOMMUNITY.MICROSOFT.COM)
Azure Copilot Observability AgentがAKS障害を調査する流れ
Observability Agentは、次の流れでインシデントを分析します。
- 障害に関係しそうなAKSクラスター、Node Pool、Workload、依存リソースを絞り込む
- メトリック、ログ、トレース、変更履歴、アラート情報を収集する
- 通常時の傾向と比較し、異常なメトリックやログを検出する
- アプリケーションとインフラストラクチャの情報を関連付ける
- 必要に応じてリソース固有の診断処理を実行する
- 「何が起きたか」「なぜ起きたか」「次に何をすべきか」を整理する
従来は、Application Insights、Container Insights、Log Analytics、Managed Prometheus、AKSのイベント画面を行き来しながら、担当者が時刻やリソース名を照合する必要がありました。Observability Agentは、この相関作業を一つの調査内で進めます。最終的な変更判断は運用担当者が行いますが、調査開始時の仮説作りを短縮できます。(TECHCOMMUNITY.MICROSOFT.COM)
AKS調査で参照される監視データ
Observability Agentは、Azure Monitor内にすでに存在するデータを利用します。専用のAI向けログを別途作成しなければ利用できないわけではありません。
| データ | 主に確認できること |
|---|---|
| Kubernetesイベント、Podの状態 | Pending、CrashLoopBackOff、スケジューリング失敗、Probe失敗 |
| Container Insights、コンテナログ | 起動エラー、例外、設定不足、OOMに関連する情報 |
| Azure Managed Prometheus | ノードやPodのCPU、メモリ、リソース逼迫の傾向 |
| Application Insights | HTTP 5xx、レイテンシ、失敗した依存関係、例外、利用者への影響 |
| Azure Activity Log | Azureリソースに対して行われた設定変更や操作 |
| AKSコントロールプレーンログ | 診断設定で転送されたAPI Serverなどのログ |
| リソースメタデータ | クラスター、Node Pool、Workload、関連Azureリソースの関係 |
すべてのデータソースを有効にしなくても開始できます。ただし、「アプリのエラーは確認できるが、どのPodやNode Poolで起きたか分からない」といった状態では、原因の絞り込みが不完全になりやすくなります。(TECHCOMMUNITY.MICROSOFT.COM)
具体例で分かる調査結果の違い
新しいPodがPendingのまま起動しない場合
デプロイ後、置き換え用PodがPendingのままになっているケースを考えます。
Kubernetesイベントでスケジューリング失敗が繰り返され、同じ時間帯に対象Node PoolのCPUとメモリが上限近くまで使用されていれば、アプリケーションの起動失敗ではなく、配置可能なノード容量の不足が有力です。
この場合の対応候補は、次のいずれかです。
- 対象Node Poolをスケールアウトする
- Podのrequests設定を見直す
- 不要なWorkloadを停止する
- 空き容量を確保してからロールアウトを再実行する
コンテナイメージの調査だけを続けても解決しないため、スケジューリングイベントとノード側メトリックの組み合わせが判断材料になります。(TECHCOMMUNITY.MICROSOFT.COM)
デプロイ後にHTTP 5xxと遅延が増えた場合
Application InsightsでHTTP 5xxとレイテンシの増加が確認され、同じ時刻からPodがCrashLoopBackOffになったケースです。
対象Podのメモリ使用量が制限値に近づいている一方、ノード全体にはリソース逼迫がなく、直前にコンテナイメージや設定が変更されていれば、クラスター全体ではなくWorkload固有の問題と判断できます。
この場合は、Node Poolを増やすよりも、次の確認を優先します。
- 直前に変更したイメージや環境変数
- コンテナの起動ログと例外
- Liveness Probe、Readiness Probeの設定
- メモリrequestsとlimits
- 直前バージョンへのロールバック可否
Observability Agentの実務上の利点は、単に原因候補を表示することではなく、「ノードを増やすべき障害」と「アプリケーションを戻すべき障害」を分けるための根拠を集められる点です。(TECHCOMMUNITY.MICROSOFT.COM)
誰に影響するのか
AKS管理者とプラットフォーム担当者
Podの配置失敗、Node Poolの容量不足、ノードのリソース逼迫を調査する際に影響があります。Azure Monitorアラートから調査を開始し、クラスターとWorkloadの情報をまとめて確認できます。
SREと監視運用担当者
インシデント発生時に複数の監視画面を切り替える作業を減らせます。調査結果をAzure Monitor Issueとして保存すれば、チーム内で原因候補や調査経緯を共有できます。
アプリケーション開発・運用担当者
Application Insightsで確認した遅延やHTTPエラーを、Pod再起動、Kubernetesイベント、デプロイ変更まで追跡しやすくなります。アプリケーション側と基盤側のどちらが担当すべき障害かを判断する材料になります。
Azureテナント管理者
Azure Copilotの利用者、RBAC、ネットワーク接続、課金管理を確認する必要があります。AKSを利用していない一般ユーザーに、直接的な設定変更はありません。
利用前に確認する設定
Azure Copilotへのアクセスを確認する
Observability Agentの利用可否は、Azure Copilotのアクセス設定に連動します。テナントでAzure Copilotが制限されている場合、Observability Agentも利用できません。
Azure Copilotの利用者を限定している環境では、Azure Copilot admin centerのアクセス管理を確認し、必要なMicrosoft Entraユーザーまたはグループに「Copilot for Azure User」ロールを割り当てます。
また、Azure Copilotの利用には、組織のネットワークからhttps://directline.botframework.comへのWebSocket接続が必要です。ボタンを押しても接続できない場合は、プロキシやファイアウォールの設定も確認してください。 (Microsoft Learn)
実行ユーザーのRBACを確認する
Observability Agentは、調査を開始したユーザーのIDとAzure RBAC権限を使用します。ユーザーが閲覧できないリソースや監視データに、エージェントだけがアクセスすることはありません。(Microsoft Learn)
調査結果をAzure Monitor Issueとして保存する場合は、対象サブスクリプションとAzure Monitor Workspaceの関連付けも必要です。Issueの作成には、Azure Monitor Workspaceに対する次のいずれかのロールが必要です。
- Contributor
- Monitoring Contributor
- Issue Contributor
チャットは利用できるのにIssueを保存できない場合は、Azure Copilotの権限だけでなく、Azure Monitor Workspace側のロールを確認します。(Microsoft Learn)
監視データを優先順位順に確認する
最初からすべてのログを有効にすると、ログ取り込み量とコストが急増する可能性があります。まずは次の順序で、不足しているデータを確認するのが現実的です。
- KubernetesイベントとPodの状態を確認できるか
- Pod、コンテナのエラーログを取得できるか
- Node PoolとPodのCPU、メモリを比較できるか
- Application Insightsでrequests、dependencies、exceptionsを収集できるか
- Azure Activity Logやデプロイ変更を時刻で追跡できるか
- 必要なコントロールプレーンログを診断設定で転送しているか
監視データを増やす際は、「エージェントが使うかもしれないから全部収集する」のではなく、過去の障害で原因特定に不足したデータから追加します。
アプリとAKSを関連付ける情報を整える
Application InsightsやOpenTelemetryのデータにリソース情報が不足していると、アプリケーションエラーとAKSイベントを正しく関連付けられません。
OpenTelemetryを利用している場合は、次の属性が設定されているか確認します。
service.name
cloud.resource_id
k8s.cluster.nameサービスごとのCloud Role Nameも、実際のシステム構成が分かる名前に統一します。OperationIdやcloud_RoleNameなどの標準フィールドを独自用途で上書きすると、分散トレースや調査の相関が崩れるため注意が必要です。(Microsoft Learn)
Observability Agentの使い方
AKSでは、主に2つの方法で調査を開始できます。
アラートから深い調査を開始する
Azure MonitorのAKSリソース向けアラート、またはAKS上のアプリケーションを対象としたApplication Insightsアラートから調査を開始します。
アラートの対象リソース、発生時刻、条件を初期コンテキストとして利用できるため、実際のインシデント調査に適しています。調査結果は一時的なため、後から確認する必要がある場合はAzure Monitor Issueとして保存します。(Microsoft Learn)
AKSのMonitor画面からチャットする
AzureポータルでAKSリソースを開き、Monitor画面のObservability Agentボタンから自然言語で質問します。
現在は英語が正式な対応言語で、日本語などは限定的なサポートです。運用手順に組み込む場合は、次のような英語プロンプトを用意しておくと結果を安定させやすくなります。(Microsoft Learn)
Why are pods in namespace <namespace> stuck in Pending since <time>?
Correlate the HTTP 5xx increase with pod restarts and deployment changes.
Did node CPU or memory pressure contribute to this rollout failure?
Show the configuration changes made before the pods entered CrashLoopBackOff.質問には、namespace、Workload名、障害発生時刻、デプロイ時刻を含めるのがポイントです。「クラスターに問題はありますか」のような広すぎる質問より、調査範囲を絞り込みやすくなります。
AKSの更新や移行は必要か
2026年6月17日付の公式記事を確認した限り、次の作業は必須変更として案内されていません。
- AKSのKubernetesバージョン更新
- Node Poolやノードイメージの更新
- Kubernetesマニフェストの書き換え
- 既存クラスターから新クラスターへの移行
- 特定日までの構成移行
Observability AgentはAzure Monitorに存在する監視データを利用するため、既存のAKS環境でも段階的に試せます。ただし、Container InsightsやApplication Insightsを利用していない環境では、必要な監視データを収集するための設定追加が発生します。(TECHCOMMUNITY.MICROSOFT.COM)
また、Observability Agentは現在プレビューです。GA済み機能と同じ前提で本番障害対応を全面的に置き換えるのではなく、既存のRunbookやKQL調査を残した状態で評価するのが安全です。(Microsoft Learn)
料金と2026年7月1日の課金開始
6月17日のTechCommunity記事には、具体的な課金説明がありません。しかし、翌日の2026年6月18日に更新されたObservability Agent専用の課金資料では、2026年7月1日から課金を開始すると明記されています。(Microsoft Learn)
料金はAzure Agent Credit（AAC）による従量制です。
- 簡単な質問は、一般的に消費するAACが少ない
- 複数のエージェントやツールを呼び出す深い調査は、消費量が多くなる
- 1回の深い調査は最大500 AACに制限される
- 課金先は、監視対象リソースが属するAzureサブスクリプション
- AAC単価はAzure Monitorの料金ページと契約条件で確認する
Observability Agentの料金とは別に、Log Analyticsへのデータ取り込み、ログ保持、アラート、通知、各監視サービスの利用料金が発生する場合があります。実際の単価は契約、リージョン、通貨によって異なるため、Azure Monitorの料金ページと自社契約を基準に見積もってください。(Microsoft Azure)
2026年6月30日までに、少なくとも次の運用ルールを決めておくと安心です。
- 深い調査を実行できる担当者
- 本番環境で調査を開始する条件
- 検証環境での想定AAC消費量
- 課金先サブスクリプションの管理者
- Azure Monitorの既存監視コストを含めた確認方法
利用時の注意点
AIの結論をそのまま本番へ適用しない
Observability Agentの結果は、収集済みデータをもとに生成された提案です。Microsoftも、結果が常に正確または完全とは限らないため、変更前に評価、テスト、検証するよう案内しています。(Microsoft Learn)
たとえばNode Poolのスケールアウトが提案されても、対象Node Pool、Podのrequests、Cluster Autoscalerの状態、クォータ、コストへの影響を確認してから実行します。
会話と調査結果には保持上の制限がある
同じ会話は24時間を超えて継続できません。チャットや調査結果も一時的なため、障害記録として残す場合はAzure Monitor Issueや既存のインシデント管理システムへ保存します。
会話データはリージョン内で最大30日間保持される場合があります。会話データに対するカスタマー管理キーは現時点でサポートされず、Microsoft管理キーで暗号化されます。(Microsoft Learn)
日本リージョンでも利用できるが、最新状況を確認する
公式ドキュメントでは、Japan EastとJapan Westが対応リージョンに含まれています。ただしプレビュー機能のため、利用可能範囲や画面構成が変更される可能性があります。ボタンが表示されない場合は、リージョンだけでなく、Azure Copilotのアクセス制御、RBAC、ネットワーク接続を確認してください。(Microsoft Learn)
今すぐ確認すべきこと
今回の変更で、AKSそのものを急いで更新または移行する必要はありません。まずAzureポータルで対象AKSのMonitor画面を開き、Observability Agentが利用できるか確認します。
次に、Kubernetesイベント、Podログ、ノードメトリック、Application Insightsのテレメトリが関連付けられる状態かを確認してください。そのうえで、検証環境のアラートから調査を実行し、既存の手動調査と結果を比較します。
本番導入の判断では、調査精度だけでなく、2026年7月1日以降のAAC課金、監視データの追加コスト、AIの提案を誰が承認するかまで運用ルールに含めることが重要です。
コメント