AWS DevOps Agent のマネージドスキル 4 つの仕様と用途を調べてみた

こんにちは、製造ビジネステクノロジー部の若槻です。

AWS DevOps Agent の Operator Web App でスキルの一覧を開くと、自分で作ったカスタムスキルの下にマネージドスキルというセクションがあり、作った覚えのないスキルが並んでいます。

赤枠がマネージドスキルのセクション。その上はカスタムスキル。4 つのうち生成済みは 2 つ

セクションの説明には「DevOps エージェントによって作成されたスキル。これらはチャットを介して更新できます。」とあります。エージェントが自分で書いたスキルということです。

とはいえ、一覧を眺めただけでは、それぞれが何を書いたものなのか、いつ生成されるのか、どこで使われているのかが分かりません。そこで、4 つのマネージドスキルについて中身・生成条件・用途を一通り調べてみました。

結論

• マネージドスキルは 4 つです。understanding-agent-space / understanding-pipeline-topology / tool-use-best-practices / chat-tool-use-best-practices
• understanding-agent-space はトポロジー画面とサマリーレポートの実体です。スキルの references/critical-paths/ が、そのままトポロジー画面の表示切り替えメニューになっていました
• 生成の契機はスキルごとに違います。understanding-agent-space だけ Agent Space の作成直後に自動で走り、tool-use-best-practices は完了済み調査 10 件、chat-tool-use-best-practices はチャットセッション 10 件がしきい値です
• マネージドスキルは削除できません。無効化のみです。直接編集もできず、更新は「チャットで編集する」か「再生成」を経由します
• 実体はマネージドメモリストアから作られた出力物でした。CLI で見るとメモリの数とスキルのファイル数が一致します。学習の本体はメモリ側にあります
• CLI（aws-cli v2 の 2.34.64 以降）から list-assets で見ると、UI に無い skill_type（USER / LEARNED）が確認できます。未生成のマネージドスキルはアセットとして存在せず、UI 上のプレースホルダーでした
• スキルの中身は接続している capability の数で解像度が変わります。AWS アカウントしか繋いでいない Agent Space では critical-paths/ が作られませんでした
• ドキュメントに載っている understanding-code-dependencies は存在せず、逆に chat-tool-use-best-practices はドキュメントに載っていません

マネージドスキルとは

DevOps Agent のスキルには 2 種類あります。

カスタムスキルが「エージェントに教えること」だとすれば、マネージドスキルは「エージェントが自分で覚えたこと」です。

ドキュメント上の名称は「Learned Skills」で、UI の「マネージドスキル」とは呼び方が揃っていませんが、同じものを指しています。

マネージドスキルの一覧

Operator Web App の ナレッジ ページの スキル タブに並ぶのは次の 4 つです。

ここから 1 つずつ見ていきます。

understanding-agent-space

4 つのうち、もっとも実用に直結しているのがこれでした。

中身

詳細画面を開くと、SKILL.md と 2 階層の references/ という構成でした。

understanding-agent-space/
├── SKILL.md
└── references/
    ├── critical-paths/     # 3 ファイル
    └── components/         # 17 ファイル

詳細画面のファイルツリー。critical-paths と components に分かれて全 20 ファイルが並ぶ

SKILL.md には環境の全体像が入ります。手元の Agent Space では、リージョンごとにリソース数と役割が分類され、コンテナ単位のアーキテクチャ図まで書かれていました。

components/ は論理コンポーネントごとの内訳、critical-paths/ はリクエストの流れです。ファイル名はアカウント内のワークロードに対応しており、こちらが何も指示していないのにこの粒度まで環境が整理されていました。

実際の中身

3 種類のファイルがそれぞれどう書かれているのか、代表を 1 つずつ見てみます。以下の抜粋では、アカウント ID・ARN・メールアドレスを伏せ字にしています。

SKILL.md

frontmatter に続いて、生成時刻のコメントと環境の概要が入ります。

---
name: understanding-agent-space
description: AWS DevOpsエージェントスペースのクラウドリソース、アーキテクチャ、環境構成の理解。インシデント調査、リソース関係の分析、環境境界の特定に使用します。
metadata:
  alt-name: agent-space-understanding
---
<!-- Generated: 2026-07-30T12:38:10.494531+00:00 -->

# Security Infrastructure Management System

AWS環境のセキュリティインフラストラクチャを統合的に管理するシステムです。GuardDuty、Security Hub、Macie、Inspector、Detective、AWS Configなどの複数のセキュリティサービスを統合的に有効化し、セキュリティベストプラクティスを強制します。（後略）

このスキルは、AWSアカウント<account-id>における3つのリージョン（ap-northeast-1、us-east-1、ap-northeast-3）のクラウドインフラストラクチャトポロジを記録します。

見出し構成は次のようになっていました。

# Security Infrastructure Management System
## Concepts
## Environments
### Environment Classification
## Architecture
### Key Components
## Critical Paths
## Code Repositories

Concepts が個人的にいちばん面白いところで、この環境固有の用語をエージェントが自分で定義しています。

## Concepts

- **Security Hub Aggregator Region**: Security Hubの検出結果を集約する中心リージョン（本環境では東京リージョン）。他のリージョン（バージニア）からの検出結果を統合します。
- **CDK Qualifier**: CDK Bootstrapスタックを識別するための文字列（デフォルト: `hnb659fds`）。CDKアセットバケットやロールARNの命名に使用されます。
- **OIDC Provider (OpenID Connect Provider)**: GitHub ActionsなどのCI/CDプラットフォームがAWSリソースに一時的な認証情報を使ってアクセスするための信頼関係。

Environments では、リージョンを本番と判定した根拠まで書かれていました。「スタック名に dev / test / staging が含まれない」「東京に 461 リソースあるので主系」といった推論です。

references/critical-paths/ の例

security-finding-notification.md を見てみます。Security Hub の検出結果がメール通知に届くまでの経路です。

冒頭に経路の要約があり、続いて graph という独自記法のコードブロックが入ります。トポロジー画面の図はこれを描画したものです。

# Security Finding Notification

Security Hubで検出された重大度の高いセキュリティイベント（MEDIUM、HIGH、CRITICAL）をEventBridgeでキャプチャし、Lambda関数を介してSNS経由で運用者にメール通知します。これにより、セキュリティインシデントへの迅速な対応が可能になります。

## Flow

```graph
<components>
<id icon="shield" description="AWS環境のセキュリティベストプラクティス（CIS、AWS Foundational）をスキャンし、非準拠項目を検出結果として生成">{C1} - Security Hub Standards</id>
<id icon="zap" description="Security Hubからの検出結果イベント（重大度MEDIUM以上、ステータスNEW/NOTIFIED/RESOLVED）をフィルタリング">{C6} - EventBridge Rule</id>
<id icon="function" description="イベントから検出結果の詳細（リソースID、アカウント、リージョン、重大度、説明）を抽出してSNSメッセージを構築">{C7} - Notification Lambda</id>
<id icon="bell" description="KMS暗号化されたトピックで通知メッセージを配信">{C8} - SNS Topic</id>
</components>

<connections>
<con>{C1} -> {C6} (description="publishes findings as events" sequence="2")</con>
<con>{C6} -> {C7} (description="triggers on MEDIUM+ severity" sequence="3")</con>
<con>{C7} -> {C8} (description="publishes formatted message" sequence="4")</con>
</connections>
```

さらに Observability セクションがあり、ソースコードの行番号付きでログ出力箇所まで押さえていました。GitHub 連携があるとここまで書けるということです。

### Log Patterns

| Pattern | Purpose | Location |
|:--------|:--------|:---------|
| `console.log(JSON.stringify(event, null, 2))` | Security Hub検出結果イベントの全体ログ | Notification Lambda: lib/constructs/security-hub/notification/function.ts:28 |
| `console.log("Successfully published to SNS:", response)` | SNS通知成功ログ | Notification Lambda: lib/constructs/security-hub/notification/function.ts:71 |
| `console.error("Error publishing to SNS:", error)` | SNS通知エラーログ | Notification Lambda: lib/constructs/security-hub/notification/function.ts:76 |

この下には Monitoring として EventBridge ルールの ARN や KMS キー ID も列挙されていました。調査に必要な識別子がそのまま入るので、スキルの中身を共有する際は扱いに注意が要ります。

references/components/ の例

devops-agent.md は短いので全文を載せます。コンポーネント 1 つだけの構成ですが、ファイルの型はよく分かります。

# DevOps Agent

DevOpsワークフローを自動化するエージェントのランタイム環境。エージェントの実行環境とリソース管理を提供します。

## Component Diagram

```graph
<components>
<id icon="cpu" description="エージェントの実行環境とリソース管理を提供">{C1} - Agent Runtime Infrastructure</id>
</components>

<connections>
</connections>
```

## Components

| Component | Type | Purpose | Sample Resources |
|:----------|:-----|:--------|:-----------------|
| Agent Runtime Infrastructure | CloudFormation Stack | エージェントの実行環境とリソース管理 | ap-northeast-1: DevOpsAgentStack |

## Observability

### CloudFormation Stack
- **ap-northeast-1**: DevOpsAgentStack (arn:aws:cloudformation:ap-northeast-1:<account-id>:stack/DevOpsAgentStack/...)

### Logs
エージェントのログはObservabilityコンテナのCloudWatch Logsに送信されます。

## CloudFormation Stacks

- **ap-northeast-1**: DevOpsAgentStack

## Usage

DevOpsAgentStackは、AWS DevOpsエージェントの運用環境をプロビジョニングします。エージェントはこのスタックで定義されたリソースを使用して、インシデント調査やインフラストラクチャの管理タスクを実行します。

components/ 側は「このコンポーネントは何で、どのスタックに属し、ログはどこに出るか」という定型で揃っていました。critical-paths/ が経路を追うのに対し、こちらは部品カタログという位置づけです。

これらのファイルは、後述の CLI からも get-asset-file で取得できます。

aws devops-agent get-asset-file \
  --agent-space-id <agent-space-id> \
  --asset-id <asset-id> \
  --path references/components/devops-agent.md \
  --region ap-northeast-1

用途: トポロジー画面の実体

このスキルは「エージェントが読むもの」だけでは終わりません。Operator Web App の トポロジー ページは、このスキルを可視化したものです。

決め手は表示切り替えのメニューでした。学習済み / クリティカルパス / その他 の 3 グループに分かれているのですが、クリティカルパスグループの項目が、スキルの references/critical-paths/ 配下のファイルと 1 対 1 で一致します。

赤枠の「クリティカルパス」グループの 3 項目が、スキルの references/critical-paths/ 配下のファイルと一致する

画面下部にある再生成ボタンも、押すとこのスキルが作り直されます。その隣に出ている最終生成日時が、スキルアセットの作成時刻と秒まで一致していました。

画面下部の再生成ボタンと最終生成日時。この日時がスキルアセットの作成時刻と一致する

つまり「トポロジーを更新する」と「このスキルを再生成する」は同じ操作です。

用途: サマリーレポート

もう 1 つ、アーティファクト ページの Agent Space Summary Report もこのスキル由来です。エージェントが環境をどう理解しているかを読み物として確認できます。

サマリーレポート。SKILL.md の Environments と Environment Classification がそのまま読み物として整形されている（アカウント ID は黒塗り）

中身は SKILL.md の内容が読みやすく整形されたものでした。前掲の Environments や Environment Classification がそのまま並んでおり、「東京は 461 リソースで us-east-1 は 141、大阪は 33 なので東京が主系」といった判定の根拠まで読めます。スキルの生ファイルを開かなくても、エージェントの環境理解をレビューできる導線になっています。

右上にはコピーとダウンロードがあり、編集はできません。ドキュメントによれば、管理コンソール側の Agent Space 詳細ページの 概要レポート タブからも同じものが参照でき、バージョン管理されるため過去の版と比較もできるとのことです。

生成と更新のタイミング

このスキルだけ、生成の挙動が特殊です。更新の条件は Learned Skills のドキュメントの「Managing Learned Skills」に書かれています。

The Agent Space Understanding skill is generated by the learning agent, which runs whenever you add, update, or remove an Agent Space capability or integration. It is also periodically refreshed every 3 days for active Agent Spaces. An Agent Space counts as active if it has had at least one investigation in the last 6 days. If your Agent Space has no investigations for 6 days, skill refresh pauses automatically. It resumes when a new investigation starts.

まとめると次のとおりです。

手動更新の導線もドキュメントに明記されています。

To regenerate learned skills manually, choose the Regenerate button on the Topology page in the operator app, or chat with the agent and ask it to update the learned skills.

「capability を足したら作り直される」という挙動は、後述の解像度の話と直結します。

understanding-pipeline-topology

パイプラインを端から端までマッピングし、本番と非本番の区別やリリースの進行状況をエージェントが把握できるようにするスキルです。

ただし、手元の環境では生成できませんでした。詳細は後述の「その他に気付いたこと」に書きます。

tool-use-best-practices

過去の調査を分析して、ツールの使い方を学習するスキルです。完了済み調査が 10 件必要で、手元の Agent Space は 2 件だったため未生成でした。

手元では中身を見られなかったので、以下は Learned Skills のドキュメントからの引用です。メインファイルがツールごとの参照ファイルへのルーティング索引になっていて、各参照ファイルは次の 3 セクションで構成されます。

生成後の更新頻度も同ドキュメントに記載があり、調査 30 件ごととされています。

The DevOps Agent generates an updated Tool Use Best Practices skill every 30 investigations.

同ドキュメントによれば、ライブなインフラにアクセスできる場合は、抽出したパターンを実環境に照らして検証したうえで採否を決めるとされています。裏が取れたものは断定的に、取れなかったものは慎重な言い回しで書かれ、否定されたものは除外されるという作りです。

When live infrastructure access is available, the skill validates patterns against your environment before including them. Confirmed patterns are stated with confidence, unconfirmed patterns use cautious language, and disproved patterns are excluded. This keeps the skill aligned with the current state of your infrastructure.

chat-tool-use-best-practices の中身を見たかぎりでは、実際にこの書き分けがされているかまでは判別できませんでした。

chat-tool-use-best-practices

tool-use-best-practices のチャットセッション版です。チャットセッション 10 件がしきい値で、手元の Agent Space ではこれだけが生成済みでした。

中身

SKILL.md と references/ 配下の 4 ファイルという構成です。目を引いたのはファイル名でした。

chat-tool-use-best-practices/
├── SKILL.md
└── references/
    ├── lambda_troubleshooting_with_pr.md
    ├── s3_bucket_configuration_management.md
    ├── s3_bucket_deletion.md
    └── mcp_documentation_search.md

参照ファイル名が、過去にこの Agent Space で実行した調査に対応している

SKILL.md はルーティングの目次になっていて、「今のタスクに近いカテゴリを開いて、使っているツール名を引く」という構造です。カテゴリの説明を読むと、過去に自分がこの Agent Space でやったことがそのまま項目になっていることが分かります。

lambda_troubleshooting_with_pr
Sessions investigating Lambda function issues (timeouts, errors) by analyzing CloudWatch Logs, examining source code in GitHub repositories, and creating pull requests to fix the root cause.

これは以前 DevOps Agent に Lambda のタイムアウトを調査させて修正プルリクエストまで作らせた検証そのものです。

参照ファイルの中身はさらに具体的で、そのときに実際に踏んだエラーが対策付きで残っていました。

Branch already exists (422 Reference already exists)
Generate unique branch names with timestamp or UUID suffix to avoid conflicts. Example: fix/lambda-timeout-{timestamp} or fix/lambda-timeout-{uuid}

ブランチ名の衝突エラーと、その回避策が残されている

一度ブランチ名が衝突して失敗したことを覚えていて、次からはタイムスタンプを付けろ、と自分宛てに書き残しているわけです。汎用的なベストプラクティス集ではなく、この Agent Space の実際の失敗から書き起こされたものでした。

マネージドスキルで使えるメニュー

一覧と詳細画面から使える操作を、カスタムスキルと並べて整理します。

押さえておきたいのは次の 3 点です。

削除できません。 カスタムスキルにはあるゴミ箱アイコンが、マネージドスキルには表示されません。不要なら無効化して使わせないようにします。無効化しても中身は保持され、いつでも戻せます。

直接編集もできません。 詳細画面には「読み取り専用」バッジが付き、次のように案内されます。

学習したスキルを直接編集することはできませんが、これはチャットで更新することができます。

内容を変えたい場合は「チャットで編集する」から会話で指示するか、「再生成」で作り直します。トポロジー画面の再生成ボタンや、チャットでの依頼からも手動更新できます。

ボタンのラベルが状態で変わります。 未生成なら「生成」、生成済みなら「再生成」、生成に失敗した状態なら「再試行」です。

なお、生成に失敗しても直前に生成できていた内容は残ります。手元のスペースでは understanding-agent-space が再生成に失敗した表示になっていましたが、詳細画面を開くと以前生成された内容がそのまま参照できました。

CLI で見るとマネージドスキルの正体が分かる

ここまでは Operator Web App の画面を見てきましたが、アセット管理の API を使うと画面に出ていない情報まで取れます。

まず CLI の更新が必要

前回のスキル記事を書いた時点では aws devops-agent にアセット系のサブコマンドが無かったのですが、これは単に CLI が古かったためでした。変更履歴を見ると aws-cli v2 の 2.34.64 で Asset API が追加されています。

api-change:devops-agent: Add Asset APIs for managing versioned assets and asset files in AWS DevOps Agent agent spaces.

手元は 2.34.35 だったので、2.36.24 に更新したところ list-assets / get-asset / list-asset-files などが使えるようになりました。

なお、aws-cli v1 系（1.44.87 / botocore 1.42.97）には現時点でも Asset API が入っていません。devops-agent の API が 44 個のままで、更新前の v2 2.34.35 と同一でした。v2 を使う必要があります。

扱えるアセットの種類

list-asset-types で一覧できます。

aws devops-agent list-asset-types --region ap-northeast-1

skill_type で USER と LEARNED が区別されている

スキルを一覧すると、UI には出てこない skill_type というメタデータが見えます。

aws devops-agent list-assets \
  --agent-space-id <agent-space-id> \
  --asset-type skill \
  --region ap-northeast-1

手元の Agent Space の結果を整理すると次のとおりです。

UI の「カスタムスキル / マネージドスキル」という区分の実体は、この skill_type でした。ドキュメントが「Learned Skills」と呼んでいるのも、API の値がそのまま LEARNED だからだと思われます。

未生成のマネージドスキルは実体が無い

注目したいのは、この一覧に tool-use-best-practices と understanding-pipeline-topology が出てこないことです。

UI では 4 つ並んで見えますが、アセットとして存在するのは生成済みの 2 つだけでした。未生成の 2 つは画面上のプレースホルダーで、実体はまだ作られていないことになります。「生成」ボタンはアセットの新規作成をトリガーするもの、と捉えると腑に落ちます。

サンプルスキルは Agent Space 作成と同時に投入される

sample-skip-scheduled-maintenance の createdAt も確認できました。

秒単位で一致しているので、Agent Space の作成処理の一部として投入されていることがはっきりしました。skill_type が LEARNED ではなく USER なのも面白いところで、AWS が入れたものでありながら扱いは通常のカスタムスキルです。実際、削除ボタンも有効になっています。

マネージドスキルはメモリストアから作られている

memory_store と memory を一覧すると、マネージドスキルがどう作られているかが見えてきます。

先に断っておくと、ここで出てくるメモリストアは画面には出てきません。ナレッジページの メモリ タブにも「マネージドメモリストア」という区分はあるのですが、並んでいるのはモニターとディレクティブの 2 つだけです。

メモリタブに並ぶのはモニターとディレクティブのみ。マネージドスキルの裏にあるメモリストアは表示されない

以降の内容は CLI からしか確認できないものです。

aws devops-agent list-assets \
  --agent-space-id <agent-space-id> \
  --asset-type memory_store \
  --region ap-northeast-1

既存スペースには memory_store が 2 つあり、名前はマネージドスキルと同名でした。

そして memory は 26 件あり、内訳がスキルのファイル構成と一致します。

21 件と 5 件で合計 26 件、スキル側のファイル数とぴったり合います。

時系列も筋が通っています。chat-tool-use-best-practices のメモリストアは 8/5 に作られてから 8/15 までに version 4 まで育ち、その最終更新が 02:45:11、スキルアセットの作成が 02:47:01 でした。メモリに学習内容を溜めて、そこからスキルを固めるという流れです。

ドキュメントに「マネージドスキルを無効化しても、対応するマネージドメモリストアは別枠で無効化する必要がある」と書かれている理由も、この構造なら納得できます。スキルは出力物にすぎず、学習の本体はメモリ側にあるためです。

補足: 新規 Agent Space と並べてみる

ここまで見たのは 7 月末に作って使い続けている Agent Space です。この顔ぶれや中身が最初からこうだったのかを確かめるため、AWS CDK で Agent Space をもう 1 つ作って並べてみました。

AWS CDK の実装

実装は以前 Agent Space の作成から GitHub 連携までを CDK で実装した記事のコンストラクトを流用し、比較に不要な GitHub 連携を外した最小構成にしました。

エントリポイントとなるコンストラクトです。Agent Space と、監視対象の AWS アカウントの関連付けだけを作ります。

import { Construct } from "constructs";

import { AgentSpaceConstruct } from "./agent-space";
import { AwsAssociationConstruct } from "./aws-association";

interface DevOpsAgentConstructProps {
  agentSpaceName: string; // Agent Space 名
}

/**
 * DevOps Agent リソース実装
 * @see https://github.com/aws-samples/sample-aws-devops-agent-cdk/blob/main/lib/devops-agent-stack.ts
 */
export class DevOpsAgentConstruct extends Construct {
  constructor(scope: Construct, id: string, props: DevOpsAgentConstructProps) {
    super(scope, id);

    const { agentSpaceName } = props;

    const agentSpaceConstruct = new AgentSpaceConstruct(this, "AgentSpace", {
      agentSpaceName,
    });

    const awsAssociation = new AwsAssociationConstruct(this, "AwsAssociation", {
      agentSpace: agentSpaceConstruct.agentSpace,
    });
    awsAssociation.association.addResourceDependency(
      agentSpaceConstruct.agentSpace,
    );
  }
}

Agent Space 本体です。オペレーター用ロールを作り、operatorApp に紐付けます。

import * as devopsagent from "aws-cdk-lib/aws-devopsagent";
import { Construct } from "constructs";

import { OperatorRoleConstruct } from "./operator-role";

interface AgentSpaceConstructProps {
  agentSpaceName: string; // Agent Space 名
}

/**
 * Agent Space とオペレーターロールの実装
 * @see https://github.com/aws-samples/sample-aws-devops-agent-cdk/blob/main/lib/devops-agent-stack.ts
 */
export class AgentSpaceConstruct extends Construct {
  public readonly agentSpace: devopsagent.CfnAgentSpace;

  constructor(scope: Construct, id: string, props: AgentSpaceConstructProps) {
    super(scope, id);

    const { agentSpaceName } = props;

    const operatorRole = new OperatorRoleConstruct(this, "OperatorRole");

    this.agentSpace = new devopsagent.CfnAgentSpace(this, "Resource", {
      name: agentSpaceName,
      locale: "ja-JP", // エージェントの応答言語
      operatorApp: {
        iam: {
          operatorAppRoleArn: operatorRole.role.roleArn,
        },
      },
    });
  }
}

デプロイすると 30 秒ほどで Agent Space が作成されました。

ラインナップは同じで、違うのは生成状態だけ

作成直後の Agent Space でマネージドスキルの一覧を開くと、顔ぶれは既存スペースとまったく同じ 4 つでした。サービス側の更新でラインナップが入れ替わっている、ということはありません。

作成直後の Agent Space。顔ぶれは同じで、未生成のものにはしきい値が表示される

違ったのは生成状態です。

既存スペースは完了済み調査が 2 件しかないのに、チャット版だけ生成済みでした。つまり調査（インシデント調査）とチャットセッションは別物として数えられており、2 つのしきい値は独立していることになります。

生成にかかった時間は 22 分

生成された understanding-agent-space の SKILL.md を開くと、先頭に時刻がコメントで埋め込まれていました。

<!-- Generated: 2026-08-15T03:25:13+00:00 -->

JST に直すと 12:25 で、CDK のデプロイ完了が 12:22 だったため、最初は 3 分で終わったのかと思いました。しかし後述の CLI でアセットの作成時刻を確認すると 2026-08-15T12:44:14+09:00 でした。

Generated コメントは環境をスキャンした時点を指しているだけで、スキルが実際に登録されたのは 22 分後でした。一覧の表示が「スキルの生成 — 最大 30 分かかる場合があります。」のまま長く残っていたのは、表示が遅れていたのではなく単に生成中だったということです。「最大 30 分」は妥当な表示でした。

SKILL.md の中の時刻だけを見て判断すると誤読するので、完了を確かめたいならアセットの作成時刻を見るのが確実です。

出力の解像度は capability の数で変わる

同じ AWS アカウントを見ているのに、生成された understanding-agent-space の中身は既存スペースと構造が違いました。

AWS アカウントのみを接続した状態。critical-paths がなく components も 6 ファイル

理由はスキル自身が本文で説明していました。

This agent space has no code-repository associations. Without linked repositories, there are no deployment pipelines, build artifacts, or application source code to trace. The critical paths below represent infrastructure-level operations only.

リポジトリをつないでいないのでパイプラインもビルド成果物も追えず、インフラレベルの経路しか書けない、と断ったうえで、セキュリティアラートの流れ・CloudTrail の監査証跡・CDK のデプロイフローの 3 つを SKILL.md に直接書いていました。既存スペースのように critical-paths/ を独立したディレクトリに切り出すほどの材料がなかった、ということだと思います。

一方、AWS アカウント側の情報はしっかり集めていて、リージョンごとにリソース数と役割を分類し、コンテナ単位のアーキテクチャ図まで作っていました。ここは capability が 1 つでも初回から出力されます。

understanding-agent-space は capability の増減で再生成されるので、連携を足すほどトポロジー画面の解像度も上がっていく、という関係になります。

ドキュメントとのズレ

Learned Skills のドキュメントには、ローンチ時点で 4 つ利用できると書かれています。

At launch, four learned skills are available: Agent Space Understanding, Understanding Code Dependencies, Understanding Pipeline Topology, and Tool Use Best Practices.

しかし UI に並んでいるものと突き合わせると、一致しません。

understanding-code-dependencies は存在せず、代わりにドキュメント未記載の chat-tool-use-best-practices があります。新規に作った Agent Space でも同じだったので、古いスペースに反映されていないという話ではありません。

その他に気付いたこと

understanding-pipeline-topology は「生成」を押しても動かなかった

4 つのうち understanding-pipeline-topology だけは、既存・新規のどちらのスペースでも「まだ生成されていません」のままでした。

既存スペースは GitHub 連携済みなので生成できそうだと思い、「生成」ボタンを押してみました。しかし、押した直後も翌日に確認したときも、表示は「まだ生成されていません」のままで、状態は変わりませんでした。エラーメッセージも出ません。

パイプラインのトポロジーを作るには CI/CD パイプラインの実行履歴のような材料が要るはずなので、リポジトリをつないだだけでは足りないのだと思います。ただ、生成の条件はドキュメントに明記されていません。tool-use-best-practices のように「あと何件必要か」が表示されるわけでもないため、押しても動かないときに何が足りないのかを知る手段が現状ないのが困りどころです。

メモリストアは別枠で無効化する必要がある

ドキュメントによれば、マネージドスキルを無効化しても、対応するマネージドメモリストアは別枠で無効化する必要があります。前述のとおりスキルはメモリから作られる出力物なので、スキルだけ止めてもメモリ側の学習は続く、という理解になります。

ただ、前述のとおりメモリタブにはマネージドスキルの裏にあるメモリストアが表示されません。画面に出ているモニターとディレクティブは別物なので、「スキルを無効化したからメモリも止めよう」と思っても、UI からは対象を見つけられないのが現状です。

サンプルのカスタムスキルの中身

新規 Agent Space に最初から入っている sample-skip-scheduled-maintenance は、メンテナンスウィンドウ中の MEDIUM / LOW のアラームを調査対象から除外するスキルです。ドキュメントに「Example: Incident filtering skill」として載っているサンプルそのものでした。

ステータスは無効なので、そのままでは動作に影響しません。

おわりに

AWS DevOps Agent のマネージドスキル 4 つについて、中身・生成条件・用途を調べてみました。

いちばんの収穫は、understanding-agent-space がトポロジー画面とサマリーレポートの実体だと分かったことです。スキル一覧では「エージェントが読む何か」に見えますが、実際にはこちらが日常的に見ている画面の裏側そのものでした。トポロジーの表示が薄いと感じたら、それはこのスキルの生成結果が薄いということになります。

もう 1 つは、chat-tool-use-best-practices の中身が想像よりずっと具体的だったことです。過去に自分がやらせた調査の名前がファイル名になり、そのとき踏んだエラーが対策付きで残っていました。汎用テンプレートではなく、この Agent Space の履歴から書き起こされたものです。

そして CLI を使ってみたことで、マネージドスキルがメモリストアから作られた出力物だと分かったのも大きい収穫でした。画面上は 4 つ並んでいても未生成のものはアセットとして存在しませんし、無効化してもメモリ側の学習は別枠で続きます。画面だけ見ていると「スキルが本体」に見えますが、実際は逆でした。

まとめると、マネージドスキルは使えば使うほど、そして接続する capability が多いほど成長する仕組みのようです。調査やチャットの回数がしきい値に達して初めて生成され、その後も件数を重ねるたびに更新されます。capability を増やせば、そのたびに再生成がかかったうえで環境理解の解像度そのものが上がります。

逆に言えば、作った直後のスペースを見て「大したことが書かれていない」と判断するのは早計です。リポジトリや MCP サーバーをつないだうえで調査を回していけば、放っておいても中身が濃くなっていきます。

削除できず無効化のみ、という点も運用前に把握しておくとよさそうです。合わないマネージドスキルがあれば消すのではなく、無効化して使わせない、という判断になります。

以上