Cli | The .NET Blog

dotnet new WinUI: Visual Studio なしで Windows アプリを作成

Emiliano Montesdeoca — Wed, 27 May 2026 00:00:00 +0000

WinUI 開発にはかつて Visual Studio が必要でした。それが変わりつつあります: Microsoft が dotnet new で動作する WinUI 向けのオープンソースのプロジェクトテンプレートとアイテムテンプレートを公開し、Windows アプリ開発を標準的な CLI ワークフローに組み込んでいます。

3 つのコマンドで始める

# テンプレートをインストール
dotnet new install Microsoft.WindowsAppSDK.WinUI.CSharp.Templates

# NavigationView アプリを作成
dotnet new winui-navview -n MyApp

# 実行
cd MyApp
dotnet run

Visual Studio 不要、手動のプロジェクト設定も不要。アプリは dotnet run で実行できます。

含まれているもの

空のテンプレート (dotnet new winui) — Fluent タイトルバーがすでに設定されたモダンな出発点。.ico アセット付きの更新されたデフォルトアプリアイコン、適切なライト/ダークモードのデフォルト設定を含みます。自分で基本設定をしなければならなかった古い空のテンプレートより優れています。

NavigationView テンプレート (dotnet new winui-navview) — マスター-詳細ナビゲーションパターン。NavigationView、モダンなタイトルバー、マルチページナビゲーション構造が完全に設定されています。ナビゲーションベースのアプリに対する標準的な Windows アプリシルエットに従っています。サイドナビゲーションのあるものを作る場合はここから始めましょう。

両テンプレートは Windows アプリシルエット — レイアウト、ナビゲーション、視覚構造のためのモダンな Fluent Design パターン — にすぐに従います。

Visual Studio 以外の開発者にとって重要な理由

VS Code、Rider、またはコマンドラインツールを使用している WinUI 開発者は不遇に扱われてきました。既存の Visual Studio テンプレートは VS 外では使えず、プロジェクト構造を手動で再作成し、基本を設定し直す必要がありました。

これらのテンプレートはオープンソースです (WindowsAppSDK PR #6407 を参照)。コミュニティのフィードバックから開発され、今すぐ利用可能です。Visual Studio サポートも進行中 — これらの同じテンプレートはいずれそちらでも動作するようになります。

WinUI プロジェクトのセットアップをスクリプト化したい、CI に組み込みたい、または Visual Studio 以外のエディタを使いたいチームにとって、これは意味のある改善です。

元の記事: Introducing dotnet new WinUI templates

Cosmos DB Shell はパブリックプレビューに — そして MCP サーバーが内蔵されている

Emiliano Montesdeoca — Sun, 24 May 2026 00:00:00 +0000

1 つの Cosmos DB の質問に答えるだけのために、ポータルのタブ、SDK サンプル、そして書きかけのスクリプトを行き来した経験があるなら、このプロジェクトが解消しようとしている摩擦をすでに知っているでしょう。

Azure Cosmos DB Shell がパブリックプレビューに入りました。bash ライクな構文を持つオープンソース CLI であり、そして — これを面白くする部分 — 統合された MCP サーバーを備えています。

他のデータベース CLI との違い

CLI 自体は有用です：使い慣れたコマンド、スクリプトサポート、CI/CD 統合。この部分は開発者向けデータベースツールの最低限のものです。

興味深い部分は MCP サーバーの統合です。CLI が公開するすべてのコマンドが、AI エージェントが呼び出せる MCP ツールとして利用可能になります。カスタム API レイヤーはなく、書くべき統合コードもありません。エージェントは次のことができます：

cd、ls、pwd でデータベース階層を移動
query で SQL クエリを実行し、構造化された結果を取得
create item、update、rm でアイテムを作成・変更
mkdb、mkcon、rmdb、rmcon でデータベースとコンテナを管理
endpoint、pwd で現在のコンテキストを確認

重要な変化：エージェントは Cosmos DB API と話しているのではなく、あなたが使う同じシェルインターフェイスと話しています。コマンドは決定論的で監査可能であり、正確に何が起きているかを確認できるようオープンソースです。

オープンソースの基盤が重要

これはブラックボックスのマネージドサービスではありません。シェルはオープンソースであり、それが意味することは：

セキュリティチームが実装を監査できる
プラットフォームチームが特定の標準に合わせてフォークして拡張できる
開発者が全員のためになる改善を貢献できる

AI ツールを採用する企業チームにとって、「正確にどう動くか見られますか」はオプションの要件でなくなりつつあります。ここでのオープンソースは意味ある差別化要因です。

簡単になる 3 つのシナリオ

インテリジェントなデータ分析 — エージェントをシェルに接続し、自然言語で質問し、構造化されたクエリ結果を得る。クエリの構築はエージェントが担当し、実行はシェルが担当します。

自律的なデータ管理 — Cosmos DB でデータを作成、更新、削除する必要があるワークフローは、カスタム統合を必要とせず MCP ツールを通じて行えます。

リアルタイム監視とアラート — エージェントがコンテナを定期的にクエリし、結果を比較し、意味のある通知チャネルで異常を報告できます。

MCP インターフェイスにより、これらのシナリオは MCP を話す任意の AI プラットフォームと組み合わせ可能になります — Microsoft のツールだけでなく。

始め方

シェルはパブリックプレビュー中です。インストールし、Cosmos DB 接続を設定し、MCP サーバーを有効にします。そこから、MCP 互換の任意のエージェントホストがツールを発見して使用できます。

元の投稿：Announcing the Public Preview of Azure Cosmos DB Shell: Open-Source Power Meets AI-Driven Database Automation

Windows App Dev CLI v0.3: ターミナルからF5デバッグとエージェント向けUIオートメーション

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

この投稿は自動翻訳されました。元の記事はこちらをクリックしてください。

Visual StudioのF5体験は素晴らしいです。しかし、パッケージ化されたWindowsアプリを起動してデバッグするためだけにVSを開くのは、CIパイプライン、自動化ワークフロー、またはAIエージェントがテストを実行しているときには過剰です。

Windows App Development CLI v0.3がリリースされ、2つの主要機能でこれに直接対応します：winapp runとwinapp uiです。

winapp run: どこからでもF5

winapp runはアンパッケージのアプリフォルダーとマニフェストを受け取り、VSがデバッグ起動時に行うすべてを実行します：ルーズパッケージを登録し、アプリを起動し、再デプロイ間でLocalStateを保持します。

# アプリをビルドし、パッケージアプリとして実行
winapp run ./bin/Debug

WinUI、WPF、WinForms、コンソール、Avaloniaなどで動作します。各モードは開発者と自動化ワークフローの両方を想定しています：

--detach: 起動後すぐにターミナルに制御を返します。CI/自動化に最適です。
--unregister-on-exit: アプリ終了時に登録済みパッケージを削除します。
--debug-output: OutputDebugStringメッセージと例外をリアルタイムでキャプチャします。

新しいNuGetパッケージ: パッケージアプリ向けdotnet run

.NET開発者向けに新しいNuGetパッケージが登場しました：Microsoft.Windows.SDK.BuildTools.WinApp。インストール後は、dotnet runがインナーループ全体を処理します：ビルド、ルーズレイアウトパッケージの準備、Windowsへの登録、起動 — すべて1ステップで。

winapp init
# または
dotnet add package Microsoft.Windows.SDK.BuildTools.WinApp

winapp ui: コマンドラインからUIオートメーション

エージェント型シナリオを切り開くのがこの機能です。winapp uiはターミナルから、実行中のあらゆるWindowsアプリ（WPF、WinForms、Win32、Electron、WinUI3）への完全なUIオートメーションアクセスを提供します。

できること：

すべてのトップレベルウィンドウを一覧表示
ウィンドウの完全なUIオートメーションツリーをナビゲート
名前、タイプ、オートメーションIDで要素を検索
クリック、呼び出し、値の設定
スクリーンショットの取得
要素の表示を待機 — テスト同期に最適

winapp uiとwinapp runを組み合わせると、ターミナルから完全なビルド→起動→検証ワークフローが実現します。エージェントがアプリを実行し、UIの状態を検査し、プログラムで操作して結果を検証できます。

その他の新機能

winapp unregister: テスト終了後にサイドロードされたパッケージを削除します。
winapp manifest add-alias: ターミナルからアプリ名で起動できるエイリアスを追加します。
タブ補完: 1つのコマンドでPowerShell補完を設定します。

インストール方法

winget install Microsoft.WinAppCli
# または
npm install -g @microsoft/winappcli

CLIはパブリックプレビュー中です。完全なドキュメントはGitHubリポジトリを、すべての詳細は元のアナウンスをご覧ください。

ターミナルの見張り番はもう終わり：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を入手してください。

azd update — すべてのパッケージマネージャーを統べる一つのコマンド

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

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

数週間ごとに表示される「azdの新しいバージョンが利用可能です」というメッセージ、知っていますか？ azdをwingetでインストールしたのか、Homebrewなのか、それとも半年前に実行したcurlスクリプトなのか思い出せなくて、つい無視してしまうあのメッセージです。ついに解決しました。

Microsoftがazd updateをリリースしました — 元々のインストール方法に関係なく、Azure Developer CLIを最新バージョンにアップデートできる単一のコマンドです。Windows、macOS、Linux — 関係ありません。コマンド一つで完了です。

仕組み

azd update

これだけです。新機能に早くアクセスしたい場合は、デイリーのInsidersビルドに切り替えることもできます：

azd update --channel daily
azd update --channel stable

このコマンドは現在のインストール方法を自動検出し、裏側で適切なアップデートメカニズムを使用します。もう「この PC では winget を使ったっけ、choco だったっけ？」と悩む必要はありません。

一つだけ注意点

azd updateはバージョン1.23.x以降で利用可能です。それより古いバージョンを使っている場合は、元のインストール方法で最後の手動アップデートを行う必要があります。その後はazd updateがすべてのアップデートを引き受けてくれます。

azd versionで現在のバージョンを確認してください。新規インストールが必要な場合は、インストールドキュメントを参照してください。

なぜ重要なのか

これは小さなQOL改善ですが、AIエージェントやAspireアプリをAzureにデプロイするためにazdを毎日使っている私たちにとって、最新の状態を保つことは「そのバグは最新バージョンで修正済みでした」という場面を減らすことを意味します。考えることが一つ減るのです。

詳細は公式アナウンスとJon Gallantの詳しい解説をご覧ください。

.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リファレンスをチェックしてください。