Aks | The .NET Blog

Aspire 13.3: Kubernetes サポート、ブラウザログ、Aspireify スキル

Emiliano Montesdeoca — Mon, 18 May 2026 00:00:00 +0000

5週間はリリースとしては短い期間ですが、Aspire 13.3 はそのようには感じません。主要な項目は重要なものです: Helm による Kubernetes および AKS のファーストクラスデプロイ、Aspireify というエージェント支援のオンボーディングスキル、ダッシュボードへのブラウザログキャプチャ直接統合、構造化されたコマンド結果。さらに、45の新機能、134の改善、93のバグ修正も含まれています。

ハイライトを見ていきましょう。

Aspireify: エージェント支援のオンボーディング

Aspire を既存のプロジェクトに追加するのは簡単に聞こえます — AppHost を追加すれば完了。しかし実際には多くの調査が必要です: どのポートが重要か、どの環境変数が実際の依存関係か、どの Docker Compose サービスが Aspire のインテグレーションにマッピングされるべきか。

新しい Aspireify スキル は、コーディングエージェントにまさにそのためのガイド付きワークフローを提供します。aspire init がスケルトン AppHost を作成するとき、Aspireify スキルはエージェントがリポジトリを調査し、どのように動作しているかを理解し、アプリに合わせて AppHost を接続するのを助けます — その逆ではありません。

デフォルトのスタンスは「コードへの変更を最小化する」です。アプリがすでに DATABASE_URL を読み取っている場合、エージェントは設定を書き直すように求めるのではなく、WithEnvironment() でそれをマップします。ポートがハードコードされている場合、スキルはエージェントにそれを保持するタイミングを伝えます。

これは、レビューのための作業を増やすのではなく、実際に時間を節約する AI ツールの一例です。

ファーストクラスの Kubernetes と AKS デプロイ

これはウィッシュリストにしばらくありました。Aspire 13.3 では Helm を使用した Kubernetes と AKS のファーストクラスデプロイサポート が提供されます。Aspire ツールから直接 AKS をデプロイターゲットとして指定できるようになりました。

AKS で本番ワークロードをすでに実行しているチームにとって、これは重要なギャップを埋めます。Aspire のアプリモデルは、手動で Helm チャートを書く必要なく、ローカル開発から Kubernetes へのクリーンなパスを持つようになりました。

ダッシュボードのブラウザログ

これはフロントエンドの問題をデバッグするまでは小さく見える機能の一つです。

新しい WithBrowserLogs() API は、エンドポイント対応のリソースに追跡されたブラウザリソースを添付します。Aspire はプライベート CDP パイプを使用して Chromium を起動し、コンソールログ、ネットワークリクエスト、エラーをリソースのログストリームに直接ストリーミングします:

var frontend = builder.AddViteApp("frontend", "../frontend")
 .WithHttpEndpoint(port: 3000)
 .WithBrowserLogs();

TypeScript AppHost も同様にサポートしています:

const frontend = await builder.addViteApp("frontend", "../frontend")
 .withHttpEndpoint({ port: 3000 })
 .withBrowserLogs();

コンソールエラー、失敗したネットワークリクエスト、クライアントサイドの例外 — すべて、すでにトレースとメトリクスを監視しているのと同じダッシュボードで可視化できます。基本的なことのためにブラウザ DevTools にタブを切り替える必要はもうありません。

構造化されたコマンド結果

リソースコマンドが大幅にアップグレードされました。これまで、コマンドは成功/失敗を返していました。今では構造化された結果を返します: モデル、ダッシュボード UI、CLI、MCP ツールを流れるテキスト、JSON、または Markdown です。

ダッシュボードはこれをヘッダーの新しい通知センターでまとめています。コマンド結果は Markdown レンダリングと「応答を表示」アクションを持つタイムスタンプ付き通知として表示されます。

これにより、リソースコマンドが真に組み合わせ可能になります。インテグレーションは、単にどこかの状態を変更するのではなく、トンネル URL などの意味のある出力を返すコマンドを公開できるようになりました。

まとめ

Aspire 13.3 は Kubernetes サポートだけでもアップデートする価値があります。ブラウザログと構造化されたコマンド結果は、日常の開発ワークフローで素早く積み重なる生活の質向上の改善の一種です。

完全なリリースノート: What’s New in Aspire 13.3

AzureでAIエージェントをどこにホストすべき？実践的な判断ガイド

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

この記事は自動翻訳されています。オリジナル版はこちらをご覧ください。

今.NETでAIエージェントを構築しているなら、おそらく気づいていることがあるでしょう：Azureでホストする方法がたくさんあるということです。Container Apps、AKS、Functions、App Service、Foundry Agents、Foundry Hosted Agents — どれも合理的に聞こえますが、実際に選ぶ段階になると困ります。MicrosoftがAzureでのAIエージェントホスティングに関する包括的なガイドを公開しました。これを.NET開発者の実践的な視点から整理します。

6つのオプション早見表

オプション	最適な用途	管理するもの
Container Apps	K8sの複雑さなしにコンテナを完全制御	オブザーバビリティ、状態、ライフサイクル
AKS	エンタープライズコンプライアンス、マルチクラスター、カスタムネットワーキング	すべて（それがポイント）
Azure Functions	イベント駆動の短時間エージェントタスク	ほぼなし — 真のサーバーレス
App Service	シンプルなHTTPエージェント、予測可能なトラフィック	デプロイ、スケーリング設定
Foundry Agents	ポータル/SDKによるコード不要エージェント	ほぼなし
Foundry Hosted Agents	マネージドインフラでカスタムフレームワークエージェント	エージェントコードのみ

最初の4つは汎用コンピュートです — エージェントを動かすことはできますが、そのために設計されたものではありません。最後の2つはエージェントネイティブで、会話、ツール呼び出し、エージェントのライフサイクルをファーストクラスの概念として理解しています。

Foundry Hosted Agents — .NETエージェント開発者にとってのスイートスポット

注目すべきはこれです。Foundry Hosted Agentsはちょうど中間に位置しています：自分のコード（Semantic Kernel、Agent Framework、LangGraph — 何でも）を実行する柔軟性がありながら、プラットフォームがインフラ、オブザーバビリティ、会話管理を処理します。

キーピースはHosting Adapterです — エージェントフレームワークをFoundryプラットフォームに接続する薄い抽象化レイヤーです。Microsoft Agent Frameworkの場合：

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

これがホスティングの全体像です。アダプターがプロトコル変換、server-sent eventsによるストリーミング、会話履歴、OpenTelemetryトレーシングを自動的に処理します。カスタムミドルウェアも手動の配管作業も不要です。

デプロイは本当にシンプル

以前Container Appsにエージェントをデプロイしたことがありますが、状態管理やオブザーバビリティのためのグルーコードをたくさん書くことになります。Hosted Agentsとazdなら：

# AIエージェント拡張機能をインストール
azd ext install azure.ai.agents

# テンプレートから初期化
azd ai agent init

# ビルド、プッシュ、デプロイ — 完了
azd up

この1つのazd upがコンテナをビルドし、ACRにプッシュし、Foundryプロジェクトをプロビジョニングし、モデルエンドポイントをデプロイし、エージェントを起動します。5つのステップが1つのコマンドに凝縮されています。

組み込みの会話管理

本番で最も時間を節約するのはここです。独自の会話ステートストアを構築する代わりに、Hosted Agentsがネイティブに処理します：

# 永続的な会話を作成
conversation = openai_client.conversations.create()

# 最初のターン
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# 2回目のターン — コンテキストが保持される
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

Redisなし。Cosmos DBセッションストアなし。メッセージシリアライゼーション用のカスタムミドルウェアなし。プラットフォームがすべて処理します。

私の判断フレームワーク

6つすべてのオプションを検討した結果、私のクイックメンタルモデルはこうです：

インフラゼロが必要？ → Foundry Agents（ポータル/SDK、コンテナなし）
カスタムエージェントコードがあるがマネージドホスティングが欲しい？ → Foundry Hosted Agents
イベント駆動の短期エージェントタスクが必要？ → Azure Functions
K8sなしで最大限のコンテナ制御が必要？ → Container Apps
厳格なコンプライアンスとマルチクラスターが必要？ → AKS
予測可能なトラフィックのシンプルなHTTPエージェント？ → App Service

Semantic KernelやMicrosoft Agent Frameworkで構築しているほとんどの.NET開発者にとって、Hosted Agentsが適切なスタート地点でしょう。scale-to-zero、組み込みOpenTelemetry、会話管理、フレームワークの柔軟性が得られます — Kubernetesの管理やオブザーバビリティスタックの構築なしに。

まとめ

AzureのエージェントホスティングランドスケープはFastに成熟しています。今日新しいAIエージェントプロジェクトを始めるなら、習慣でContainer AppsやAKSに手を伸ばす前に、Foundry Hosted Agentsを真剣に検討することをお勧めします。マネージドインフラは実際の時間を節約し、hosting adapterパターンでフレームワークの選択を維持できます。

Microsoftの完全ガイドとFoundry Samplesリポジトリで動作するサンプルを確認してください。

KubeCon Europe 2026：.NET開発者が本当に知るべきこと

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

この記事は自動翻訳されました。オリジナル版はこちらをご覧ください。

巨大なアナウンス記事が出て、スクロールしながら「クール、でも実際に自分にとって何が変わるの？」と思うあの感覚、分かりますよね？毎回KubeConシーズンになると私はそうなります。

MicrosoftがKubeCon Europe 2026の完全なまとめを公開しました。Brendan Burns自身が執筆しています。正直に言うと、ここには本物の中身があります。機能のチェックリストだけでなく、本番環境での運用方法を変える運用面の改善です。

.NET開発者として本当に重要なことを整理しましょう。

サービスメッシュ税なしのmTLS

サービスメッシュの問題点：全員がセキュリティの保証を求めるけど、運用オーバーヘッドは誰も望まない。AKSがついにこのギャップを埋めています。

Azure Kubernetes Application Networkは、相互TLS、アプリケーション認識型の認可、トラフィックテレメトリを提供します。サイドカーの重いフルメッシュをデプロイする必要はありません。Advanced Container Networking ServicesのCilium mTLSと組み合わせれば、X.509証明書とSPIREによるID管理を使った暗号化されたpod間通信が実現します。

実際にはどういうことか：ASP.NET Core APIがバックグラウンドワーカーと通信する、gRPCサービスが相互に呼び出す — すべてがネットワークレベルで暗号化・ID検証され、アプリケーションコードの変更はゼロ。これは大きいです。

ingress-nginxから移行しているチームには、Meshless IstioによるApplication Routingもあり、Kubernetes Gateway APIの完全サポート付きです。サイドカーなし。標準ベース。段階的な移行のためのingress2gatewayツールも提供されています。

後付けではないGPUオブザーバビリティ

.NETサービスと並行してAI推論を実行している場合（正直、誰が始めていないでしょうか？）、GPUモニタリングの盲点に遭遇したことがあるでしょう。CPU/メモリのダッシュボードは素晴らしかったのに、GPUについては手動のエクスポーター設定なしでは何もなかった。

AKSはGPUメトリクスをネイティブにマネージドPrometheusとGrafanaに表示するようになりました。同じスタック、同じダッシュボード、同じアラートパイプライン。カスタムエクスポーターもサードパーティエージェントも不要。

ネットワーク側では、HTTP、gRPC、Kafkaトラフィックのフローごとの可視性がワンクリックAzure Monitor体験で追加されました。IP、ポート、ワークロード、フロー方向、ポリシー判定 — すべてが組み込みダッシュボードに。

そして二度見させられたもの：agentic container networkingは、クラスターのネットワーク状態について自然言語で質問できるWeb UIを追加します。「ポッドXがサービスYに到達できないのはなぜ？」→ ライブテレメトリからの読み取り専用診断。午前2時に本当に役立ちます。

博士号不要のクロスクラスターネットワーキング

マルチクラスターKubernetesは歴史的に「自分でネットワークの接着剤を持ってくる」体験でした。Azure Kubernetes Fleet Managerが、マネージドCiliumクラスターメッシュによるクロスクラスターネットワーキングを提供するようになりました：

AKSクラスター間の統一された接続性
クロスクラスター検出のためのグローバルサービスレジストリ
クラスターごとに繰り返すのではなく中央で管理される設定

レジリエンスやコンプライアンスのために複数リージョンで.NETマイクロサービスを実行しているなら、多くの脆弱なカスタムの接着剤が置き換えられます。West EuropeのサービスAがメッシュを通じてEast USのサービスBを発見して呼び出せます。一貫したルーティングとセキュリティポリシーが適用されます。

勇気を必要としないアップグレード

正直に言いましょう — 本番環境のKubernetesアップグレードはストレスフルです。「アップグレードして祈る」があまりにも多くのチームのデファクト戦略であり、クラスターがバージョンに遅れる主な理由です。

2つの新機能がこれを変えます：

Blue-greenエージェントプールアップグレードは新しい設定でパラレルなノードプールを作成します。動作を検証し、トラフィックを段階的に移動し、クリーンなロールバックパスを維持します。本番ノードでのインプレース変更はもう不要。

エージェントプールロールバックにより、アップグレードがうまくいかなかった場合、クラスターを再構築することなく、ノードプールを以前のKubernetesバージョンとノードイメージに戻せます。

組み合わせることで、オペレーターにアップグレードのライフサイクルに対する本当のコントロールを提供します。.NETチームにとっては、プラットフォームの速度が新しいランタイム、セキュリティパッチ、ネットワーク機能をどれだけ早く採用できるかを直接制御するため重要です。

AIワークロードがKubernetesのファーストクラス市民に

アップストリームのオープンソース作業も同様に重要です。Dynamic Resource Allocation (DRA)がKubernetes 1.36でGAになり、GPUスケジューリングがワークアラウンドではなく本物のファーストクラス機能になりました。

注目すべきプロジェクト：

プロジェクト	内容
AI Runway	推論のための共通Kubernetes API — K8sを知らなくてもモデルをデプロイ、HuggingFace検出とコスト見積もり付き
HolmesGPT	クラウドネイティブ向けのエージェント型トラブルシューティング — CNCF Sandboxプロジェクトに
Dalec	SBOM生成付きの宣言的コンテナイメージビルド — ビルド段階でのCVE削減

方向性は明確：あなたの.NET API、Semantic Kernelのオーケストレーション層、推論ワークロードはすべて一貫したプラットフォームモデル上で実行されるべきです。そこに向かっています。

今週から始めるなら

チームでこれらの変更を評価しているなら、私の正直な優先順位リスト：

まずオブザーバビリティ — 非本番クラスターでGPUメトリクスとネットワークフローログを有効にする。見逃していたものを確認する。
Blue-greenアップグレードを試す — 次の本番クラスターアップグレード前にロールバックワークフローをテストする。プロセスへの信頼を構築する。
ID認識型ネットワーキングをパイロット — 内部サービスパスを1つ選んでCiliumでmTLSを有効にする。オーバーヘッドを測定する（ネタバレ：最小限）。
Fleet Managerを評価 — 2つ以上のクラスターを運用しているなら、クロスクラスターネットワーキングはカスタムの接着剤削減だけで元が取れる。

小さな実験、素早いフィードバック。それが常に正しい手。

まとめ

KubeConのアナウンスは圧倒的になりがちですが、今回のバッチはAKS上の.NETチームにとって本当に針を動かします。メッシュオーバーヘッドなしのより良いネットワークセキュリティ、本物のGPUオブザーバビリティ、より安全なアップグレード、そしてより強力なAIインフラストラクチャの基盤。

すでにAKSを使っているなら、運用ベースラインを強化する絶好のタイミングです。.NETワークロードをKubernetesに移行する予定なら — プラットフォームは大幅にプロダクションレディになりました。