2026年5月5日付の .NET documentation update で確認すべきポイントは、aspire agent init のスキル選択が「より安全な初期状態」に寄せられたことです。非.NET AppHost、たとえばTypeScript AppHostでは dotnet-inspect が候補に出にくくなり、Playwright CLIも最初から選択済みにならず、必要な人が明示的に選ぶ挙動へ変わります。AIコーディングエージェント向けにAspireを設定しているチームは、aspire agent init の再実行時に「どのスキルが表示され、どれが選択済みか」を確認するのが最優先です。関連PRは2026年4月2日にmainへマージされ、Aspire 13.3の変更ログにも aspire agent init のスキル事前選択修正として反映されています。(GitHub)
.NET documentation updateで変わったこと
今回の更新は、.NET AspireのAIエージェント連携を初期化する aspire agent init に関する修正です。aspire agent init は、AIコーディングエージェント向けのスキルファイルとMCPサーバー設定をワークスペースへ作成・更新するコマンドです。公式リファレンスでは、スキルのインストール先、利用するスキル、MCPサーバー構成などを対話的に設定するコマンドとして説明されています。(Aspire)
特に重要なのは、次の3点です。
| 変更点 | 以前の問題 | 変更後の見方 | 確認すべき人 |
|---|---|---|---|
dotnet-inspect の表示条件 | TypeScriptなど非.NET AppHostでも候補に出ることがあった | C#/.NET AppHost向けのスキルとして扱われ、非.NET AppHostでは表示対象から外れる | TypeScript AppHost、Python/Javaなどポリグロット構成の利用者 |
| Playwright CLIの初期選択 | ユーザーが不要でも選択済みになり、手動で外す必要があった | デフォルトでは選択されず、必要な場合に明示的に選ぶ | E2Eテストやブラウザ自動化を使うチーム |
| 言語検出の共通化 | 呼び出し元ごとに検出ロジックが分散し、結果のばらつきが起きやすかった | LanguageInfo などの共通ヘルパーに寄せられ、再帰的なAppHost検出も整理 | モノレポ、深いディレクトリ構成、CIで利用するチーム |
PRの説明では、dotnet-inspect は applicableLanguages: [KnownLanguageId.CSharp] を持つスキルとして扱われ、ワークスペースに.NET AppHostがある場合だけ提示されるようになっています。また、Playwright CLIと dotnet-inspect は isDefault: false へ変更され、ユーザーが明示的に選ぶ「オプトイン」の扱いになりました。(GitHub)
aspire agent initとは何を設定するコマンドか
aspire agent init は、AspireプロジェクトをAIコーディングエージェントで扱いやすくするための初期化コマンドです。GitHub Copilot、Claude Code、OpenCodeなどの環境に対して、Aspireの操作ルールを教えるスキルファイルや、実行中のAspireアプリケーションへ接続するMCP設定を作成します。(Aspire)
たとえば、AIエージェントが次のような作業をしやすくなります。
aspire startやaspire describeを使ってアプリケーションの状態を確認する- リソース一覧、ログ、分散トレースを参照して不具合の原因を探す
- Aspireのホスティング統合やドキュメントを検索する
- 必要に応じてブラウザ自動化や.NET API調査を補助する
MCPサーバーは aspire agent mcp コマンドを通じて起動され、AIエージェントがリソース状態、コンソールログ、構造化ログ、トレース、ドキュメント検索などへアクセスできる仕組みです。公式ドキュメントでは、list_resources、list_console_logs、list_traces、search_docs などのツールが提供されると説明されています。(Aspire)
変更点：非.NET AppHostではdotnet-inspectが表示されにくくなる
今回の修正で最も分かりやすい影響は、非.NET AppHostで dotnet-inspect が候補に出ないようになった点です。
dotnet-inspect は、.NETライブラリやNuGetパッケージのメタデータ、API、依存関係、バージョン差分などを調査するCLIツールです。READMEでは、.NET向けに docker inspect や kubectl describe のような確認を行うツールとして説明されています。(GitHub)
つまり、TypeScript AppHostやPython AppHostのプロジェクトで dotnet-inspect が最初から提示されると、次のような混乱が起きます。
| 起きやすい混乱 | 実務上の影響 |
|---|---|
| TypeScript中心のプロジェクトなのに.NET API調査スキルが出る | 初心者が「このスキルも必要なのか」と誤解しやすい |
| 不要なスキルファイルがリポジトリに追加される | レビュー時に「なぜ入ったのか」が分かりにくい |
| AIエージェントが関係の薄い調査方法を選ぶ | デバッグや調査の方向がずれる可能性がある |
| CIやセットアップ手順に不要な依存が増える | 初期化手順が複雑になる |
今回の修正では、SkillDefinition に ApplicableLanguages が追加され、言語に依存するスキルは検出されたAppHost言語に応じて候補へ出すかどうかが判断されます。言語が検出できない場合、言語制限のあるスキルは除外される設計です。(GitHub)
対応が必要なケース
TypeScript AppHostを使っているチームは、aspire agent init を再実行したときに dotnet-inspect が不要な候補として表示されないかを確認してください。すでに過去の実行で .agents/skills/dotnet-inspect/ や .github/skills/dotnet-inspect/ などが追加されている場合は、チームの方針に合わせて残すか削除するかを判断します。
判断基準はシンプルです。
| プロジェクト構成 | dotnet-inspect の扱い |
|---|---|
| C# AppHostで、.NET APIやNuGetパッケージ調査をAIに任せたい | 有効化を検討する |
| TypeScript AppHostのみ | 原則として不要 |
| TypeScript AppHostだが、配下に.NETサービスが多い | AppHost言語だけでなく、調査対象の.NETコードがあるかで判断する |
| 非.NET中心で、.NET SDKも標準導入していない | 入れないほうが運用が簡単 |
変更点：Playwright CLIはデフォルト選択されない
もう一つの重要な変更は、Playwright CLIが初期状態で選択済みにならない点です。PRの差分では、Playwright CLIの isDefault が true から false に変更されています。E2Eテスト側のコメントにも、Playwrightと dotnet-inspect は事前選択されなくなり、デフォルトではAspireスキルのみが選択されることが示されています。(GitHub)
これは小さなUI変更に見えますが、実務では意味があります。Playwright CLIはブラウザ自動化やWebリソースのテストに役立つ一方、すべてのAspireプロジェクトで必要とは限りません。不要なプロジェクトで最初から選ばれていると、依存関係の追加、セットアップ時間、CIでの失敗要因が増えます。
Playwright CLIを選ぶべきケース
Playwright CLIは、次のようなプロジェクトでは有効化を検討できます。
| 利用シーン | 選ぶ理由 |
|---|---|
| フロントエンド付きのWebアプリをAspireで動かしている | AIエージェントに画面操作や確認を任せやすい |
| E2EテストをすでにPlaywrightで運用している | 既存のテスト資産と相性がよい |
| ログだけでは再現しにくいUI不具合を調査したい | ブラウザ操作を含む検証に向いている |
| 開発環境でブラウザ自動化を許可している | チームのセキュリティ・運用ルールに合う |
反対に、API中心のバックエンド、バッチ処理、社内ツールの初期検証段階では、最初は選ばずに進めても問題ありません。必要になった時点で aspire agent init を再実行し、Playwright CLIを追加するほうが設定を小さく保てます。
変更点：言語検出ロジックが共通化された
今回の修正では、スキル選択だけでなく、AppHost言語を検出するための内部処理も整理されています。PRでは、LanguageInfo に MatchesFile、FindInDirectory、MatchesPattern などの共通ヘルパーが追加され、DefaultLanguageDiscovery、TestLanguageDiscovery、DotNetSdkCheck が同じコードパスを使うようになったと説明されています。(GitHub)
また、言語検出には2種類の使い分けがあります。
| 検出方法 | 探す範囲 | 向いている用途 |
|---|---|---|
DetectLanguageAsync | 直下ディレクトリのみ | 既存の挙動を保ちたい軽量な検出 |
DetectLanguageRecursiveAsync | 最大5階層まで再帰的に検索 | AppHostが src/MyAppHost/MyAppHost.csproj のように下位フォルダにある構成 |
実務で重要なのは、aspire agent init が workspaceRoot を基準にAppHost言語を検出する点です。PRでは、作業ディレクトリではなく workspaceRoot に対して再帰的な検出を行うことが説明されています。モノレポや src/ 配下にAppHostを置く構成では、この修正によって候補スキルの判定がより自然になります。(GitHub)
ただし、再帰検索には深さの上限があります。差分では DetectionRecurseLimit が5階層として定義されています。AppHostを極端に深い階層へ置いている場合は、--workspace-root をAppHostに近い場所へ指定するほうが安全です。(GitHub)
影響範囲：誰が確認すべきか
今回の変更は破壊的変更というより、初期設定の誤選択を減らす修正です。ただし、AIエージェント用の設定ファイルはリポジトリに残るため、過去に生成済みのファイルがあるチームは確認が必要です。
| 対象者・チーム | 影響 | 推奨アクション |
|---|---|---|
| TypeScript AppHost利用者 | dotnet-inspect が不要候補として出にくくなる | 再実行後のスキル一覧と既存ファイルを確認 |
| C# AppHost利用者 | dotnet-inspect は候補になり得るが、デフォルト選択ではない | 必要なら明示的に選択 |
| Playwrightを使うWeb開発チーム | Playwright CLIが自動選択されない | 初期化時に明示的に選ぶ |
CIで aspire agent init を実行するチーム | 事前選択の前提が変わる | --skills などで明示指定する |
| モノレポ利用者 | AppHost検出結果がスキル候補に影響する | --workspace-root の指定を見直す |
| 既存のAIエージェント設定を持つチーム | 古いスキルファイルが残っている可能性 | .agents/skills/ などを棚卸しする |
特に注意したいのは、「以前は何も考えずEnterで進めればPlaywrightや dotnet-inspect も入っていた」という運用です。今後は、必要なスキルを選ぶ前提で手順書やオンボーディング資料を更新してください。
移行・設定確認の手順
以下の順番で確認すると、不要なスキルを残さず、安全に更新できます。
| 手順 | コマンド・確認内容 | 目的 |
|---|---|---|
| 1 | aspire --version | 利用しているAspire CLIのバージョンを確認する |
| 2 | aspire agent init --workspace-root . | ワークスペースルートを明示して初期化する |
| 3 | 表示されるスキル候補を確認 | AppHost言語に合わない候補が出ていないか確認する |
| 4 | .agents/skills/、.github/skills/、.claude/skills/ を確認 | 不要な古いスキルファイルが残っていないか見る |
| 5 | CIやセットアップ手順を確認 | --skills all のような指定が不要なスキルを入れていないか確認する |
公式リファレンスでは、--workspace-root、--skill-locations、--skills、--non-interactive などのオプションが説明されています。対話式に頼らず再現性を高めたい場合は、これらのオプションで明示的に設定するのが実務向きです。(Aspire)
例：標準のスキル配置だけを設定する
aspire agent init --skill-locations standard標準の .agents/skills/ を中心に運用したい場合の例です。複数のAIエージェントを使っていないチームでは、最初からすべての配置先を選ぶより、標準の配置に寄せたほうがレビューしやすくなります。
例：C# AppHostでdotnet-inspectを明示的に有効化する
aspire agent init --skills aspire,dotnet-inspect.NET APIやNuGetパッケージの調査をAIエージェントに任せたいC# AppHostでは、dotnet-inspect を明示的に選びます。非.NET AppHostでは候補や指定可否が実際のCLIバージョンによって異なる可能性があるため、コマンドのヘルプと実行結果を確認してください。
例：Web UI検証のためにPlaywright CLIを追加する
aspire agent init --skills aspire,playwright-cliフロントエンド付きのAspireアプリで、AIエージェントにブラウザ操作やE2Eテスト支援をさせたい場合の例です。Playwright CLIは今後「必要なときに選ぶ」扱いになるため、手順書にはこの明示指定を入れておくと迷いにくくなります。
既存リポジトリで見るべきファイル
aspire agent init を過去に実行している場合、以下のようなファイルやディレクトリがリポジトリに存在することがあります。
| 場所 | 確認ポイント |
|---|---|
.agents/skills/aspire/ | Aspireスキルの標準配置。基本的には残してよい |
.agents/skills/dotnet-inspect/ | 非.NET AppHostで不要なら削除候補 |
.github/skills/aspire/ | GitHub Copilot向けに使っているか確認 |
.claude/skills/aspire/ | Claude Codeを使っている場合に必要 |
.opencode/skill/aspire/ | OpenCodeを使っている場合に必要 |
.vscode/mcp.json | VS Code向けMCP設定。チームで共有するか判断 |
.mcp.json | Claude Codeなどで使うMCP設定。共有範囲に注意 |
公式ドキュメントでは、aspire agent init が検出したAI開発環境向けに .vscode/mcp.json、.mcp.json、~/.copilot/mcp-config.json、opencode.jsonc などを作成または更新する例が示されています。MCP設定はAIエージェントがローカルのAspire CLIを起動するための設定なので、リポジトリに含めるファイルと個人環境に置くファイルを分けて考える必要があります。(Aspire)
CI・非対話モードでの注意点
CIやセットアップスクリプトで aspire agent init を使う場合、対話式の「その場で選ぶ」前提を避けてください。今回の変更により、デフォルト選択の内容が以前と変わるため、Enter任せの操作を自動化していると期待したスキルが入らない可能性があります。
確認すべきポイントは3つです。
| 確認項目 | 失敗しやすい例 | 対策 |
|---|---|---|
| スキル指定 | Playwright CLIが入る前提で後続処理を書いている | --skills aspire,playwright-cli のように明示する |
| ワークスペースルート | CIの作業ディレクトリがリポジトリ直下ではない | --workspace-root を指定する |
| AppHostの階層 | AppHostが深い階層にあり検出されない | AppHostに近いディレクトリをルートにする |
また、--skills all は便利ですが、最小構成を保ちたいチームでは慎重に使うべきです。特に非.NET AppHostやUIテストを使わないプロジェクトでは、all よりも必要なスキルを列挙するほうが、将来の変更にも強くなります。
よくある疑問
TypeScript AppHostではdotnet-inspectを完全に使えないのか
必ずしも「使えない」という意味ではありません。今回の変更は、AppHost言語に合わないスキルを初期候補として出さないためのものです。TypeScript AppHostでも、配下にC#サービスや.NETライブラリがあり、AIエージェントにAPI調査をさせたい場合は、プロジェクト構成やCLIの実際の挙動を見て判断します。
ただし、標準のオンボーディングでは、TypeScript AppHostに dotnet-inspect を入れる必要性は低いでしょう。初心者向けの手順では「C# AppHostまたは.NET API調査が必要な場合のみ追加」と書くのが安全です。
Playwright CLIを選ばないとAIエージェントは使えないのか
使えます。Playwright CLIはブラウザ自動化やWeb UI検証を支援するための追加スキルです。Aspire自体の操作、リソース確認、ログ調査、トレース確認にはAspireスキルやMCPサーバーが中心になります。MCPサーバーは、実行中のAspireアプリケーションの状態、ログ、トレース、コマンド実行などをAIエージェントへ提供します。(Aspire)
既存のdotnet-inspectスキルファイルは自動で消えるのか
aspire agent init は、選択から外したスキル配置を整理する仕組みを持っていますが、既存ファイルの扱いは実行時の選択、配置先、CLIバージョンに依存します。更新後は、コマンドを再実行したうえで、Gitの差分とスキルディレクトリを目視確認してください。
実務では、次のように判断すると安全です。
| 状況 | 判断 |
|---|---|
| C# AppHostで.NET API調査に使う | 残す |
| TypeScript AppHostで使っていない | 削除候補 |
| どのエージェントも参照していない | 削除候補 |
| チームの手順書に用途が書かれていない | 用途を確認してから整理 |
公式ドキュメントと実際のCLI表示が違う場合はどうするか
更新直後は、リファレンス、ヘルプ、変更ログ、実際のCLI挙動に一時的なズレが残ることがあります。今回のようにスキルのデフォルト選択が変わる更新では、最終的には実際に使っているAspire CLIで aspire agent init --help と aspire agent init の表示を確認してください。公式リファレンスはコマンドの概要とオプション確認に使い、スキルの初期選択は利用中バージョンの実行結果で判断するのが確実です。(Aspire)
チームで更新するときの実務チェックリスト
今回の変更は、コード修正よりも「開発環境の初期化手順」に影響します。以下をチーム内で確認しておくと、オンボーディングやCIでのつまずきを減らせます。
| チェック項目 | 確認内容 |
|---|---|
| AppHost言語 | C#、TypeScript、Python、Javaなど、どのAppHostを使っているか |
| 必要なスキル | Aspireのみでよいか、Playwright CLIや dotnet-inspect も必要か |
| スキル配置先 | .agents/skills/ を標準にするか、.github/skills/ や .claude/skills/ も使うか |
| MCP設定 | .vscode/mcp.json や .mcp.json を共有するか |
| CI設定 | --skills と --workspace-root を明示しているか |
| 古いファイル | 不要な dotnet-inspect スキルが残っていないか |
| 手順書 | 「Playwrightは必要な場合に選ぶ」と書かれているか |
まず取るべき行動
この更新で最初にやるべきことは、aspire agent init を最新のAspire CLIで再実行し、表示されるスキル候補と初期選択を確認することです。C# AppHostなら dotnet-inspect を使うかどうか、Web UI検証が必要ならPlaywright CLIを入れるかどうかを判断します。TypeScriptなど非.NET AppHostでは、不要な dotnet-inspect がリポジトリに残っていないかを確認してください。
設定を小さく保つなら、基本はAspireスキルとMCP設定から始め、Playwright CLIや dotnet-inspect は目的が明確になってから追加するのがおすすめです。今回の .NET documentation update は、AIエージェント連携を「全部入り」ではなく「プロジェクトに合う最小構成」で始めるための修正と捉えると、移行判断がしやすくなります。
コメント