Aspire | The .NET Blog

プライベート Endpoints、VNet、NSG — Aspire がネットワークを管理するように

Emiliano Montesdeoca — Tue, 19 May 2026 00:00:00 +0000

このシナリオを何度も見てきました。アプリは完成しています。デモは素晴らしい。そしてセキュリティチェックリストが現れます: ストレージをパブリックインターネットから外す、VNet 内で実行する、パートナーのアローリスト用に送信 IP を提供する、正しいサブネットだけが正しいサービスと通信することを証明する。

この時点でアプリケーションモデルとインフラストラクチャモデルが乖離し始め、維持するのが辛くなります。

Aspire の新しい Azure エンタープライズネットワーキングサポートはこれに直接対処します。ネットワークの形状を AppHost 内で、それを使用するリソースの隣に記述します。

構成要素

各 Azure ネットワーキングの概念が何のためのものかを、要約してまとめます:

機能	使用するとき	重要な理由
仮想ネットワーク	プライベートアドレス空間が必要なとき	サブネット、プライベートエンドポイント、ルーティングのためのネットワーク境界
サブネット	VNet 内でワークロードを分離する必要があるとき	システムの各部分が独自のアドレス範囲とポリシーサーフェスを取得
委任サブネット	プラットフォームサービス（ACA など）がサブネットを管理する必要があるとき	サービスが管理されたインフラを VNet に安全に配置できる
NAT ゲートウェイ	予測可能な送信パブリック IP が必要なとき	アローリストと監査のための安定したアドレス
プライベートエンドポイント	PaaS リソースをプライベートにアクセスしたいとき	そのサービスのプライベート IP を VNet 内に配置し、公開露出を除去
NSG	サブネットレベルのトラフィックルールが必要なとき	サブネットごとの受信・送信トラフィックの明示的な許可/拒否

AppHost での記述

ここでの重要な変化は、ネットワークを使用するリソースの隣にモデル化していることです。時間の経過とともにアプリモデルから離れていく別の Bicep ファイルではありません。

AppHost から以下が可能です:

AddVirtualNetwork() と AddSubnet() で VNet とサブネットを作成
安定した送信 IP のためにサブネットに NAT ゲートウェイを付加
ストレージ、Key Vault、SQL、その他の PaaS サービスのプライベートエンドポイントを作成
受信・送信セキュリティルールで NSG を定義
クロスリソースポリシーのためのネットワークセキュリティ境界を構成

結果として azd up を実行すると、インフラストラクチャはアプリモデルが必要と言っているものと一致します。手動で維持されたテンプレートが言うものではありません。

実際のアプリケーションにとって重要な理由

Aspire でネットワークをモデル化すると大幅に楽になるいくつかのこと:

Key Vault とストレージのプライベートエンドポイント — これらのリソースに WithPrivateEndpoint() を記述すると、Aspire が DNS ゾーン設定とエンドポイントの接続を処理します。アプリは変更されません。

一貫した送信 IP — 関連するサブネットに NAT ゲートウェイを追加すると、アプリからのすべての送信リクエストが既知の安定した IP を通過します。パートナーはアローリストに登録できます。監査担当者は追跡できます。

コードからの NSG ルール — ポータルをクリックしたり Bicep スニペットを維持したりする代わりに、セキュリティルールは保護するリソースの隣に AppHost に存在します。

これは、デモを興奮させるものではありませんが、プロダクションシステムを保守可能にする種類の統合です。

まとめ

プロジェクトのライフサイクルの後半にネットワークセキュリティが現れるのは、最初からアプリと一緒にモデル化すれば解決済みの問題です。Aspire のエンタープライズネットワーキングサポートは、別のインフラストラクチャトラックを必要とせずにそれを可能にします。

完全な詳細は元の投稿で: Securing Azure apps with Aspire enterprise networking

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

Aspire 13.2: Bun サポート、コンテナ改善、デバッグの摩擦軽減

Emiliano Montesdeoca — Fri, 24 Apr 2026 00:00:00 +0000

この投稿は自動翻訳されています。オリジナル版はこちらをクリックしてください。

.NETバックエンドとJavaScriptフロントエンドをAspireで構築しているなら、13.2は静かにあなたの一日を良くする種類のアップデートです。

Bunがファーストクラスになりました

await builder
 .addViteApp("frontend", "./frontend")
 .withBun();

チームがすでにBunを使用している場合、Aspireはもはや逆流を強いません。

Yarnの信頼性向上

withYarn()とaddViteApp()での謎のエラーが減少します。

コンテナの改善

ImagePullPolicy.Neverでレジストリに行かずにローカルイメージを使用。PostgreSQL 18+のデータボリュームが正しく動作するようになりました。

デバッグの改善

コアタイプへのDebuggerDisplayAttribute、WaitForの改善されたエラーメッセージ、適切なタイミングで発火するBeforeResourceStartedEvent。

オリジナルポスト（David Pine著）: Aspire 13.2: Bun Support and Container Enhancements。

Global Azure Spain 2026

Sat, 18 Apr 2026 00:00:00 +0000

Global Azure Spain 2026 は 2026年4月18日 にマドリード、Alcobendas の Kinépolis Diversia で開催されます。スペイン最大のコミュニティ主導のAzureイベントで、AIエージェント、Azureネットワーク、Cosmos DB、Fabric、IoT、セキュリティなどをカバーする3つの並行トラックに38名のスピーカーが登壇します。

イベントは 08:30 から 18:30 まで開催され、キーノート、コーヒーブレイク、ランチ、クロージングQ&Aセッションを含みます。

アジェンダのハイライト

Domando Agentes de IA: Azure AI FoundryとAzure API Managementによるガバナンス、ツール、API
Construyendo agentes con LibreChat en Azure
How Can I Steal Your Data with Azure Private Endpoints
Stop Building APIs. Forge Agents with Azure
Agentic DevOps Meets IoT: Real-Time Systems with Fabric and GitHub Copilot
El regreso de los tamagotchis!: マルチエージェントシステムの実践
Foundry Control Plane como plataforma de Agentes global
Rompiendo el perímetro: Zero Trust aplicado en Azure

チケット

登録は象徴的な寄付です — チケット代金は全額 Plan International に寄付され、世界中の子どもの権利と平等を支援します。定員に限りがありますので、お早めにお申し込みください。

Azure Tour 2026

マドリード以外にも、Global Azure Tour 2026 は サラゴサ、テネリフェ、セビリア でも開催されます。

ターミナルの見張り番はもう終わり：Aspireのデタッチモードがワークフローを変える

Emiliano Montesdeoca — Fri, 17 Apr 2026 00:00:00 +0000

この記事は自動翻訳されています。原文はこちらをご覧ください。

AspireのAppHostを実行するたびに、ターミナルが奪われます。ロックされて、Ctrl+Cを押すまで占有されたまま。ちょっとしたコマンドを実行したい？別のタブを開く。ログを確認したい？もう一つタブを開く。小さなストレスですが、積み重なると大きくなります。

Aspire 13.2がこれを解決します。James Newton-Kingが詳細を書いていますが、正直なところ、これは使い始めた瞬間にワークフローが変わる機能の一つです。

デタッチモード：コマンド一つでターミナルが戻る

aspire start

これはaspire run --detachのショートカットです。AppHostがバックグラウンドで起動し、ターミナルがすぐに戻ってきます。余計なタブは不要。ターミナルマルチプレクサも不要。プロンプトがそのまま使える状態です。

実行中のプロセスを管理する

ポイントはこうです — バックグラウンド実行は、実行中のものを管理できて初めて意味があります。Aspire 13.2はまさにそのためのCLIコマンド一式を提供します：

# List all running AppHosts
aspire ps

# Inspect the state of a specific AppHost
aspire describe

# Stream logs from a running AppHost
aspire logs

# Stop a specific AppHost
aspire stop

これによりAspire CLIが本格的なプロセスマネージャーになります。複数のAppHostを起動し、ステータスを確認し、ログを追跡し、シャットダウンできます — すべて一つのターミナルセッションから。

分離モードと組み合わせる

デタッチモードは分離モードと自然に組み合わせられます。同じプロジェクトの2つのインスタンスをポート競合なしにバックグラウンドで実行したい場合は？

aspire start --isolated
aspire start --isolated

それぞれがランダムなポート、個別のシークレット、独自のライフサイクルを持ちます。aspire psで両方を確認し、aspire stopで不要な方を停止できます。

コーディングエージェントにとってなぜこれが重要か

ここからが本当に面白いところです。ターミナルで作業するコーディングエージェントが以下のことをできるようになります：

aspire startでアプリを起動
aspire describeで状態を確認
aspire logsでログをチェックして問題を診断
完了したらaspire stopで停止

すべてターミナルセッションを失うことなく実行できます。デタッチモード以前は、AppHostを実行したエージェントは自分自身のターミナルをロックしてしまいました。今では起動、観察、反復、クリーンアップが可能です — 自律エージェントに期待する動作そのものです。

Aspireチームはこれに本気で取り組みました。aspire agent initを実行すると、エージェントにこれらのコマンドを教えるAspireスキルファイルが設定されます。これにより、CopilotのコーディングエージェントなどのツールがすぐにAspireワークロードを管理できます。

まとめ

デタッチモードはシンプルなフラグに見せかけたワークフローのアップグレードです。ターミナル間のコンテキスト切り替えがなくなり、エージェントが自分自身をブロックしなくなり、新しいCLIコマンドで実行中のものをリアルに把握できます。実用的で、クリーンで、日々の開発サイクルが明らかにスムーズになります。

完全な記事で詳細を確認し、aspire update --selfでAspire 13.2を入手してください。

.NET Aspire 13.2はあなたのAIエージェントの親友になりたがっている

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

この記事は自動翻訳されました。原文はこちらをご覧ください。

AIコーディングエージェントがしっかりしたコードを書いて興奮した後、実際にそれを実行しようとした途端に全てが崩壊する瞬間、知っていますか？ポート競合、ゴーストプロセス、間違った環境変数 — 突然エージェントが機能を構築する代わりに起動トラブルシューティングにトークンを消費し始めます。

Aspireチームがまさにこの問題について非常によく考えられた記事を公開しました。彼らの答えは説得力があります：Aspire 13.2は人間だけでなく、AIエージェントのためにも設計されています。

問題は現実のもの

AIエージェントはコードを書くのに驚異的です。しかし、動作するフルスタックアプリを出荷するには、ファイルを生成する以上のことが必要です。正しい順序でサービスを起動し、ポートを管理し、環境変数を設定し、データベースを接続し、何かが壊れた時にフィードバックを得る必要があります。現在、ほとんどのエージェントはこれらすべてを試行錯誤で処理しています — コマンドを実行し、エラー出力を読み、再試行します。

Markdownの指示、カスタムスキル、プロンプトを重ねてガイドしようとしますが、それらは予測不可能で、コンパイルできず、パースするだけでトークンがかかります。Aspireチームは本質的な洞察を突きました：エージェントにはコンパイラと構造化されたAPIが必要であり、もっとMarkdownではありません。

エージェントインフラとしてのAspire

Aspire 13.2がエージェンティック開発にもたらすもの：

スタック全体を型付きコードで。 AppHostがアプリの完全なトポロジー — API、フロントエンド、データベース、キャッシュ — をコンパイル可能なTypeScriptまたはC#で定義します：

import { createBuilder } from './.modules/aspire.js';

const builder = await createBuilder();

const postgres = await builder.addPostgres("pg").addDatabase("catalog");
const cache = await builder.addRedis("cache");

const api = await builder
 .addNodeApp("api", "./api", "src/index.ts")
 .withHttpEndpoint({ env: "PORT" })
 .withReference(postgres)
 .withReference(cache);

await builder
 .addViteApp("frontend", "./frontend")
 .withReference(api)
 .waitFor(api);

await builder.build().run();

エージェントはこれを読んでアプリのトポロジーを理解し、リソースを追加し、接続を配線し、検証のためにビルドできます。コンパイラが何か間違っていればすぐに教えてくれます。推測不要、設定ファイルでの試行錯誤不要です。

すべてを支配する一つのコマンド。 エージェントがdocker compose up、npm run dev、データベース起動スクリプトをジャグリングする代わりに、すべてがaspire startだけ。すべてのリソースが正しい順序で、正しいポートで、正しい設定で起動します。長時間実行プロセスもエージェントをハングさせません — Aspireが管理します。

並列エージェント用の分離モード。 --isolatedを使えば、各Aspire実行が独自のランダムポートと分離されたユーザーシークレットを取得します。複数のエージェントがgit worktreeで作業している？衝突しません。これはVS Codeのバックグラウンドエージェントのような並列環境を立ち上げるツールにとって非常に重要です。

テレメトリによるエージェントの目。 ここが本当に強力になるところです。Aspire CLIは開発中に完全なOpenTelemetryデータを公開します — トレース、メトリクス、構造化ログ。エージェントはコンソール出力を読んで最善を祈るだけではありません。サービス間で失敗したリクエストをトレースし、遅いエンドポイントをプロファイリングし、問題の正確な箇所を特定できます。開発ループにプロダクショングレードの可観測性があるのです。

ボウリングのバンパーの例え

Aspireチームは素晴らしい例えを使っています：AspireをAIエージェントのためのボウリングレーンのバンパーだと思ってください。エージェントが完璧でない場合（そして完璧にはなりません）、バンパーがガーターに落ちるのを防ぎます。スタック定義が誤設定を防ぎ、コンパイラがエラーをキャッチし、CLIがプロセス管理を行い、テレメトリがフィードバックループを提供します。

これをPlaywright CLIのようなものと組み合わせれば、エージェントは実際にアプリを使うことができます — フローをクリックし、DOMをチェックし、テレメトリで壊れた箇所を見つけ、コードを修正し、再起動してテストし直す。ビルド、実行、観察、修正。これが私たちが追い求めてきた自律的な開発ループです。

始め方

Aspire初心者？get.aspire.devからCLIをインストールし、入門ガイドに従ってください。

すでにAspireを使っている？aspire update --selfで13.2を取得し、お気に入りのコーディングエージェントをリポジトリに向けてください。Aspireのガードレールがあることで、エージェントがどれだけ先まで進めるか驚くかもしれません。

まとめ

Aspire 13.2はもはや単なる分散アプリフレームワークではありません — 不可欠なエージェントインフラになりつつあります。構造化されたスタック定義、ワンコマンド起動、分離された並列実行、リアルタイムテレメトリが、AIエージェントにコードを書くことからアプリを出荷することへ移行するために必要なものを提供します。

Aspireチームの完全な記事ですべての詳細とデモ動画をご覧ください。

Aspireの分離モードが並列開発のポート競合の悪夢を解決する

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

この記事は自動翻訳されました。原文はこちらをご覧ください。

同じプロジェクトの2つのインスタンスを同時に実行しようとしたことがあるなら、あの苦痛を知っているでしょう。ポート8080は既に使用中。ポート17370は取られている。何かをkillして、再起動して、環境変数をジャグリングする — 生産性のキラーです。

この問題は改善ではなく悪化しています。AIエージェントは独立して作業するためにgit worktreeを作成します。バックグラウンドエージェントは別々の環境を立ち上げます。開発者はフィーチャーブランチのために同じリポジトリを2回チェックアウトします。これらのシナリオはすべて同じ壁にぶつかります：同じアプリの2つのインスタンスが同じポートを奪い合うのです。

Aspire 13.2はたった一つのフラグでこれを解決します。AspireチームのJames Newton-Kingが詳細を書いています。「なぜこれがもっと早くなかったの？」という機能の一つです。

解決策：`--isolated`

aspire run --isolated

これだけです。各実行は以下を取得します：

ランダムポート — インスタンス間のコリジョンなし
分離されたユーザーシークレット — 接続文字列とAPIキーがインスタンスごとに分離

手動のポート再割り当ては不要。環境変数のジャグリングも不要。各実行は自動的にクリーンでコリジョンフリーの環境を取得します。

これが輝く実際のシナリオ

複数チェックアウト。 あるディレクトリにフィーチャーブランチ、別のディレクトリにバグフィックスがある場合：

# Terminal 1
cd ~/projects/my-app-feature
aspire run --isolated

# Terminal 2
cd ~/projects/my-app-bugfix
aspire run --isolated

両方とも競合なしで実行されます。ダッシュボードで何がどこで実行されているか確認できます。

VS Codeのバックグラウンドエージェント。 Copilot Chatのバックグラウンドエージェントがコードに独立して作業するためにgit worktreeを作成する場合、Aspire AppHostを実行する必要があるかもしれません。--isolatedなしでは、プライマリworktreeとのポート競合が発生します。これがあれば、両方のインスタンスが問題なく動作します。

aspire agent initに付属するAspireスキルは、worktreeで作業する際に--isolatedを使うようエージェントに自動的に指示します。そのため、Copilotのバックグラウンドエージェントはこれをネイティブに処理するはずです。

開発と並行した統合テスト。 機能の構築を続けながらライブのAppHostに対してテストを実行する必要がありますか？分離モードは各コンテキストに独自のポートと設定を提供します。

内部の仕組み

--isolatedを渡すと、CLIはその実行のためにユニークなインスタンスIDを生成します。これにより2つの動作が駆動されます：

ポートのランダム化 — AppHost設定で定義された予測可能なポートにバインドする代わりに、分離モードはすべてに対して利用可能なランダムポートを選択します — ダッシュボード、サービスエンドポイント、すべて。サービスディスカバリが自動的に調整されるため、どのポートに割り当てられても、サービスは互いを見つけることができます。
シークレットの分離 — 各分離実行はインスタンスIDでキー付けされた独自のユーザーシークレットストアを取得します。ある実行の接続文字列やAPIキーが別の実行に漏れることはありません。

コードの変更は不要です。Aspireのサービスディスカバリがランタイムでエンドポイントを解決するため、ポートの割り当てに関係なくすべてが正しく接続されます。

いつ使うべきか

同じAppHostの複数インスタンスを同時に実行する場合に--isolatedを使用してください — 並列開発、自動テスト、AIエージェント、git worktreeのいずれの場合でも。予測可能なポートを好む単一インスタンス開発では、通常のaspire runで問題ありません。

まとめ

分離モードは、現実の、ますます一般的になる問題を解決する小さな機能です。AI支援開発がより多くの並列ワークフロー — 複数のエージェント、複数のworktree、複数のコンテキスト — に向かって推し進める中、ポートを奪い合うことなく別のインスタンスを立ち上げる能力は不可欠です。

完全な記事ですべての技術的詳細を確認し、aspire update --selfで13.2を試してみてください。

Aspire 13.2にドキュメントCLIが搭載 — AIエージェントも使えます

Emiliano Montesdeoca — Sat, 04 Apr 2026 00:00:00 +0000

この記事は自動翻訳されています。原文はこちらをご覧ください。

Aspire AppHostの奥深くでインテグレーションを接続していて、Redisインテグレーションが正確にどのパラメータを期待しているかを確認する必要がある、あの瞬間を知っていますか？ブラウザにAlt-Tabして、aspire.devを探し回り、APIドキュメントに目を細め、エディタに戻る。コンテキストが失われて、フローが途切れる。

Aspire 13.2がまさにその解決策をリリースしました。aspire docs CLIを使えば、ターミナルから直接Aspireの公式ドキュメントを検索、閲覧、そして読むことができます。そして再利用可能なサービスに支えられているため、AIエージェントやスキルも同じコマンドを使ってドキュメントを参照できます。存在しないAPIを幻覚する代わりに。

これが本当に解決する問題

David Pineがオリジナルの記事で的確に指摘しています：AIエージェントはAspireアプリの構築を支援する点でひどいものでした。aspire runの代わりにdotnet runを推奨し、aspire.devにあるドキュメントに対してlearn.microsoft.comを参照し、古いNuGetパッケージを提案し、そして——個人的に一番のお気に入り——存在しないAPIを幻覚していました。

なぜか？Aspireがポリグロットになるよりもはるかに長い間.NET専用だったからです。そしてLLMは最新機能よりも前のトレーニングデータで動作しています。AIエージェントに現在のドキュメントを実際に検索する能力を与えると、推測をやめて役に立つようになります。

3つのコマンド、ブラウザタブはゼロ

CLIは爽快なほどシンプルです：

すべてのドキュメントを一覧表示

aspire docs list

aspire.devで利用可能なすべてのドキュメントページを返します。マシンリーダブルな出力が必要ですか？--format Jsonを追加してください。

トピックを検索

aspire docs search "redis"

タイトルとコンテンツの両方を重み付けされた関連性スコアリングで検索します。内部的にドキュメントツールを支えているのと同じ検索エンジンです。タイトル、スラグ、関連性スコアを含むランク付けされた結果が得られます。

ページ全体を読む（またはセクションだけ）

aspire docs get redis-integration

ページ全体をマークダウンとしてターミナルにストリーミングします。セクションだけ必要ですか？

aspire docs get redis-integration --section "Add Redis resource"

外科的精度。500行をスクロールする必要はありません。必要な部分だけ。

AIエージェントの視点

ここからがAIツールで開発している私たち開発者にとって面白くなるところです。同じaspire docsコマンドが、スキル、MCPサーバー、またはシンプルなCLIラッパーを通じて、AIエージェントのツールとして機能します。

あなたのAIアシスタントが古いトレーニングデータに基づいてAspire APIを捏造する代わりに、aspire docs search "postgres"を呼び出して、公式のインテグレーションドキュメントを見つけ、正しいページを読み、ドキュメントに記載されたアプローチを提供できます。リアルタイムで最新のドキュメント——モデルが6ヶ月前に記憶したものではありません。

この背後のアーキテクチャは意図的なものです。Aspireチームは一回限りのインテグレーションではなく、再利用可能なサービス（IDocsIndexService、IDocsSearchService、IDocsFetcher、IDocsCache）を構築しました。つまり、同じ検索エンジンがターミナルの人間、エディタのAIエージェント、CIパイプラインの自動化のために機能します。

実世界のシナリオ

ターミナルでの素早い検索： 3ファイルの深さに入っていて、Redisの設定パラメータが必要。2つのコマンド、90秒、仕事に戻る：

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

AI支援開発： VS CodeスキルがCLIコマンドをラップします。「AppHostにPostgreSQLデータベースを追加して」と聞くと、エージェントが回答する前に実際のドキュメントを参照します。幻覚なし。

CI/CDバリデーション： パイプラインがAppHost設定を公式ドキュメントに対してプログラム的に検証します。--format Jsonの出力はjqやその他のツールにきれいにパイプできます。

カスタムナレッジベース： 独自のAIツールを構築していますか？構造化されたJSON出力をナレッジベースに直接パイプ：

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

Webスクレイピングなし。APIキーなし。内部的にドキュメントツールが使用しているのと同じ構造化データ。

ドキュメントは常に最新

これが私が最も評価している部分です。CLIはスナップショットをダウンロードしません——ETagベースのキャッシュでaspire.devにクエリを実行します。ドキュメントが更新された瞬間、あなたのCLIとその上に構築されたすべてのスキルがそれを反映します。古いコピーも、「でもwikiには書いてあった…」という瞬間もありません。

まとめ

aspire docsは、実際の問題をきれいに解決する、そんな小さな機能の一つです。人間はターミナルネイティブなドキュメントアクセスを得ます。AIエージェントは推測をやめて実際のドキュメントを参照する方法を得ます。そしてすべてが同じ信頼の源に支えられています。

.NET Aspireで構築していてまだCLIを試していないなら、aspire docs search "あなたのトピック" を実行して、どう感じるか確かめてください。そして、使っているAIスキルや自動化セットアップにそれらのコマンドをラップすることを検討してください——あなたのエージェントが感謝するでしょう。

ドキュメントツールがどのように構築されたかについてのDavid Pineの詳細記事と、すべての詳細が記載された公式CLIリファレンスをチェックしてください。

Aspire 13.2のダッシュボードにテレメトリAPIが搭載 — これで全てが変わる

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

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

.NET Aspireで分散アプリケーションを構築しているなら、ダッシュボードが体験全体の中で最高のものだと既に知っているでしょう。すべてのトレース、ログ、メトリクスが一箇所に — 外部のJaegerも不要、Seqのセットアップも不要、「別のターミナルを確認させて」という瞬間もなし。

Aspire 13.2で大幅に改善されました。James Newton-Kingがアップデートを発表しましたが、正直なところ、テレメトリエクスポートとAPI機能だけでアップグレードの価値があります。

テレメトリをまともにエクスポートする

誰もが経験したシナリオ：分散問題をデバッグしていて、20分のセットアップの後にようやく再現でき、チームに何が起きたかを共有する必要がある。以前は？スクリーンショット。トレースIDのコピペ。いつもの混乱。

Aspire 13.2はログとテレメトリの管理ダイアログを追加しました：

すべてのテレメトリをクリア（再現前に便利）
選択したテレメトリを標準OTLP/JSON形式のZIPファイルにエクスポート
そのZIPを後で任意のAspireダッシュボードに再インポート

最後のポイントがキラー機能です。バグを再現し、テレメトリをエクスポートし、ワークアイテムに添付すれば、チームメイトが自分のダッシュボードにインポートして、あなたが見たものと全く同じものを見ることができます。「あなたのマシンで再現できる？」はもう不要です。

個々のトレース、スパン、ログにもコンテキストメニューに「Export JSON」オプションがあります。特定のトレースを共有する必要がある？右クリック、JSONをコピー、PRの説明に貼り付け。完了。

テレメトリAPIが本当のゲームチェンジャー

最もワクワクしているのがこれです。ダッシュボードが/api/telemetry配下でHTTP APIを公開し、テレメトリデータをプログラマティックにクエリできるようになりました。利用可能なエンドポイント：

GET /api/telemetry/resources — テレメトリ付きリソースの一覧
GET /api/telemetry/spans — フィルター付きスパンのクエリ
GET /api/telemetry/logs — フィルター付きログのクエリ
GET /api/telemetry/traces — トレースの一覧
GET /api/telemetry/traces/{traceId} — 特定トレースの全スパン取得

すべてOTLP JSON形式で返されます。これは新しいCLIコマンドaspire agent mcpとaspire otelを駆動しますが、本当の意味はもっと大きい：アプリのテレメトリを直接クエリするツーリング、スクリプト、AIエージェント統合を構築できるようになりました。

デバッグ中に実際の分散トレースを見ることができるAIコーディングエージェントを想像してください。それはもう仮説ではありません — このAPIが可能にするものです。

GenAIテレメトリが実用的に

Semantic KernelやMicrosoft.Extensions.AIでAI搭載アプリを構築しているなら、改善されたGenAIテレメトリビジュアライザーを評価するでしょう。Aspire 13.2の追加機能：

AIツールの説明がMarkdownでレンダリング
トレースページに専用のGenAIボタンで素早いアクセス
切り詰められた、または非標準のGenAI JSONに対するエラー処理の改善
ツール定義間のクリックでハイライトするナビゲーション

ブログ記事では、VS Code Copilot chat、Copilot CLI、OpenCodeのすべてがOTEL_EXPORTER_OTLP_ENDPOINTの設定をサポートしていると言及されています。Aspireダッシュボードに向ければ、テレメトリを通じてAIエージェントがリアルタイムで考えている様子を文字通り見ることができます。他では見つけられないデバッグ体験です。

まとめ

Aspire 13.2はダッシュボードを「便利なデバッグUI」から「プログラマブルなオブザーバビリティプラットフォーム」に変えます。エクスポート/インポートワークフローだけで分散デバッグの実際の時間を節約し、テレメトリAPIはAI支援診断への扉を開きます。

既にAspireを使っているなら、アップグレードしましょう。まだなら — aspire.devを試してみる良い理由です。