AWS DevOps Agentのスキル機能を試してみた - カスタムスキルと学習済みスキルで調査精度を上げる

はじめに

こんにちは、サーバーワークスの多田です。

前回の記事では、AWS DevOps Agentのプレビュー版を使ってCloudWatch Alarmと連携した自動インシデント対応を試しました。2026年3月末、AWS DevOps AgentがGA（一般提供）となり、多くの新機能が追加されています。

中でも注目したいのがスキル機能です。プレビュー版にもRunbooksという運用手順書を読み込ませる機能がありましたが、GA版ではこれが「カスタムスキル（Skills）」として大幅に強化されました。さらに、DevOps Agentが環境や過去の調査から自動的に知識を蓄積する「学習済みスキル（Learned Skills）」が新たに追加されています。

本記事では、以下の2種類のスキルを実際に作成・確認し、調査品質がどう変わるかを検証します。

カスタムスキル（Skills）: プレビュー版のRunbooks（手順書の読み込み）を基盤に、自社特有のツールの使い方や独自の調査ロジックをAgentの能力として追加できるよう拡張されたもの
学習済みスキル（Learned Skills）: DevOps Agentが環境データや過去の調査から自動生成するスキル

以下目次に沿って検証していきます。

はじめに
スキル機能の概要
検証するためのデモ環境の準備
- 前回記事でのセットアップ内容
- デモ環境の更新
【実践1】カスタムスキルを作成する
【実践2】スキル適用前後の調査結果を比較する
【実践3】学習済みスキル（Learned Skills）を確認する
スキル設計のベストプラクティス
まとめ
参考リンク
- AWS公式ドキュメント
- 関連記事

スキル機能の概要

DevOps Agentにおけるスキルとは

スキルは、AWS DevOps Agentに専門的な知識や調査手順を追加するためのモジュール式の指示セットです。Markdownで記述し、Agent Spaceに登録します。

スキルと言った場合、一般的にはAnthoropic社などが提唱するAgent Skillsを指しますが、本書ではDevOps Agentのスキルを指すこととします。

スキルはAgent Skills仕様というオープンスタンダードのサブセットに基づいています。現時点ではMarkdown、PDF、画像、データファイルのみサポートされ、スクリプト実行は非対応です。

プレビュー版では「Runbooks」として、既存の運用手順書（ドキュメント）をDevOps Agentに読み込ませ、インシデント調査の参考にさせる機能が提供されていました。GA版ではこのRunbooksの機能を基盤として残しつつ、「カスタムスキル（Skills）」としてより構造化・高機能な形に拡張されました。既存のRunbooksは自動的にSkillsに移行されます。

Runbooks → カスタムスキルの主な強化ポイント:

強化ポイント	説明
スキルの自動選択	フロントマター（`name`/`description`）により、Agentが関連タスク時に適切なスキルを自動ロード
エージェントタイプ別ターゲティング	RCA（Root Cause Analysis: 根本原因分析）時のみ、トリアージ時のみ等、用途を限定可能
カスタムツール連携	MCPサーバーのカスタムツールの使い方をスキルでガイドできる
構造化されたファイル管理	ディレクトリ構造（`SKILL.md` + `references/` + `assets/`）で参照資料やアーキテクチャ図を添付可能
有効/無効の切り替え	削除せずにスキルを一時停止・再開できる

プレビュー版のRunbooksが「人間用の手順書をAIが読んで解釈する」機能だったのに対し、GA版のカスタムスキルは「自社特有のツールの使い方」や「独自のシステム構成に対する最適化された調査ロジック」をAgentの能力として追加できる、よりプログラム的な仕組みになっています。

3層のスキル階層

GA版では、DevOps Agentのナレッジが以下の3層構造として体系化されました（AWS DevOps Blogより）。

層	名称	説明
1	AWS提供スキル（AWS-provided skills）	AWSのエンジニア・サイエンティストが開発した組み込みの調査能力。内部で継続的にメンテナンスされる
2	カスタムスキル（User-defined skills）	ユーザーが自社の調査手順やドメイン知識を定義するスキル。旧Runbooksから大幅に強化
3	学習済みスキル（Learned skills）	DevOps Agentが環境データや過去の調査から自動生成するスキル

プレビュー版でも「過去のインシデント調査を分析して継続的に学習する（Continuously improving investigations）」という振る舞い自体は存在していましたが、GA版でこの3層のスキル階層として明確に体系化・機能強化されました。

本記事では、ユーザーが直接操作できるカスタムスキルと学習済みスキルにフォーカスします。

	カスタムスキル	学習済みスキル
作成者	ユーザーが手動で作成	DevOps Agentが自動生成
内容	調査手順、ドメイン知識、ツール設定	環境理解、ツール使用パターン
更新	手動で編集・再アップロード	イベントや調査回数に応じて自動更新
種類	自由に作成可能	2種類のみ（後述）

スキルの仕組み

DevOps Agentがタスクを実行する際、SKILL.mdのフロントマター（nameとdescription）を評価し、関連するスキルを自動的にロードします。つまり、descriptionの書き方がスキル活用の鍵です。

検証するためのデモ環境の準備

前回記事でのセットアップ内容

前回記事で作成した環境をベースに、下記の内容を追加でセットアップすることで、スキルの有無によって挙動がどのように変わるか試してみます。

デモ環境の更新

前回記事でデプロイしたLambda関数は、3種類のエラーメッセージからランダムに1つを選ぶだけのシンプルな構成でした。本記事では、スキルの効果を比較しやすくするため、scenario パラメータで3種類のエラーシナリオを切り替えられるよう改良した新しいテンプレートを使用します。

更新後のLambda関数は、シナリオごとに異なるエラークラス名・エラーメッセージ・ログ出力を生成します。これにより、DevOps Agentのトリアージ機能が別インシデントとして認識しやすくなり、スキルなし/ありの比較テストがスムーズに行えます。

更新後のLambda関数のソースコード:

import json
import random
import time
from datetime import datetime

SCENARIOS = {
    "db-timeout": {
        "error_class": "DatabaseConnectionError",
        "message": "Connection to RDS instance db-main-01 timed out after 30s "
                   "(host=db-main-01.abc123.us-east-1.rds.amazonaws.com, port=5432)",
        "logs": [
            "Attempting database connection to db-main-01...",
            "Connection pool exhausted: 50/50 connections in use",
            "Retry 1/3 failed: socket timeout",
            "Retry 2/3 failed: socket timeout",
            "Retry 3/3 failed: socket timeout",
        ],
    },
    "api-throttle": {
        "error_class": "APIThrottlingError",
        "message": "Rate limit exceeded for external API "
                   "https://api.example.com/v2/orders "
                   "(429 Too Many Requests, retry-after=60s)",
        "logs": [
            "Calling external API: GET /v2/orders",
            "Response: 429 Too Many Requests",
            "X-RateLimit-Remaining: 0, X-RateLimit-Reset: 60",
            "Circuit breaker OPEN: 5 consecutive failures in 120s",
        ],
    },
    "validation": {
        "error_class": "PayloadValidationError",
        "message": "Required field 'customer_id' missing in request payload "
                   "(schema=v2, source=API Gateway event)",
        "logs": [
            "Parsing incoming event from API Gateway...",
            "Schema validation failed: 'customer_id' is required",
            "Received keys: ['order_id', 'items', 'timestamp']",
        ],
    },
}

def lambda_handler(event, context):
    scenario_key = event.get("scenario", random.choice(list(SCENARIOS.keys())))
    scenario = SCENARIOS.get(scenario_key)
    if not scenario:
        raise ValueError(
            f"Unknown scenario '{scenario_key}'. Available: {list(SCENARIOS.keys())}"
        )

    print(f"[{datetime.utcnow().isoformat()}Z] Processing request")
    print(f"[{datetime.utcnow().isoformat()}Z] Configuration: scenario={scenario_key}")
    for line in scenario["logs"]:
        print(f"[{datetime.utcnow().isoformat()}Z] {line}")
        time.sleep(0.1)

    error_cls = type(scenario["error_class"], (Exception,), {})
    raise error_cls(scenario["message"])

Lambda関数の変更点は以下の通りです:

シナリオ切り替え: event の scenario パラメータで特定のエラーパターンを指定可能（省略時はランダム）
リアルなログ出力: 各シナリオがタイムスタンプ付きの段階的なログを出力し、DevOps Agentのログ分析で調査精度の差が出やすい構成
個別のエラークラス: シナリオごとに異なるエラークラス名（DatabaseConnectionError、APIThrottlingError等）を使用し、トリアージで別インシデントとして認識されやすい

CloudFormationスタックを更新します:

aws cloudformation update-stack \
  --stack-name devops-agent-test \
  --template-body file://DevOpsAgent.yml \
  --capabilities CAPABILITY_NAMED_IAM \
  --region us-east-1

更新完了を確認します:

aws cloudformation describe-stacks \
  --stack-name devops-agent-test \
  --region us-east-1 \
  --query 'Stacks[0].StackStatus' \
  --output text

UPDATE_COMPLETE と表示されれば更新成功です。

動作確認:

# シナリオを指定して実行
aws lambda invoke \
  --function-name AWS-DevOpsAgent-test-lambda \
  --cli-binary-format raw-in-base64-out \
  --payload '{"scenario":"db-timeout"}' \
  response.json \
  --region us-east-1

利用可能なシナリオは db-timeout、api-throttle、validation の3種類です。scenario を省略するとランダムに選択されます。それぞれスキルのカテゴリA〜Cに対応しています。

【実践1】カスタムスキルを作成する

UIから作成する方法

最もシンプルな方法は、Operator AppのUIから直接作成する方法です。

Step 1: AWSコンソールからエージェントスペースを開く

AWSマネジメントコンソールで AWS DevOps エージェント を開き、目的のエージェントスペースの 詳細を表示 をクリックします。

Step 2: オペレーターアクセスを開く

エージェントスペースの詳細画面で、右上の オペレーターアクセス をクリックします。Operator App（AWS DevOps Agent）が別タブで開きます。

Step 3: スキル画面を開く

Operator Appの画面左ペインで スキル を選択します。

Step 4: スキル一覧を確認する

「エージェントスペースのスキル」画面が表示されます。上部にカスタムスキル、下部の「コアスキル」セクションに学習済みスキル（understanding-agent-space、ツール使用のベストプラクティス）が表示されています。右上の スキルを追加 をクリックします。

Step 5: 「スキルを作成」を選択する

「スキルを追加」モーダルが表示されます。スキルを作成 を選択します（ZIPアップロードの場合は「スキルをアップロード」を選択）。

Step 6: スキルの情報を入力する

「スキルを作成」フォームが表示されます。以下の情報を入力します。

名前: lambda-error-investigation(小文字、数字、ハイフンのみ。最大64文字)
説明: 後述の内容を入力(100文字以上推奨。入力内容がより具体的であるほど、エージェントはこのスキルを適用すべき場合をより正確に判断できます)
ステータス: アクティブ
エージェントタイプ: 一般(すべてのエージェントタイプで使用する場合)または用途に応じて選択
手順: 後述のMarkdownを入力(エージェント向けのステップバイステップの指示)

Step 7: スキルを作成する すべての入力が完了したら、画面下部の スキルを作成 ボタンをクリックします。

作成するスキルの内容

デモ環境（Lambda関数のエラー）に特化した調査スキルを作成します。

注意: 2026年4月時点で、スキルの説明（Description）や手順（Instructions）は英語での記述が推奨されています。日本語を入力するとエラーになる場合があるため、以下では設定用の英語版と、解説用の日本語訳を併記します。

Description（説明）:

設定用（英語）:

Investigation procedures for Lambda function "AWS-DevOpsAgent-test-lambda"
errors in the devops-agent-test stack. Covers DatabaseConnectionError (RDS
connection pool exhaustion), APIThrottlingError (HTTP 429 with circuit
breaker), and PayloadValidationError (missing required fields). Use when
CloudWatch Alarm "AWS-DevOpsAgent-Lambda-Error-Test" enters ALARM state.
Provides Logs Insights query templates and error classification logic.

日本語訳（参考）

devops-agent-test CloudFormationスタックにおけるAWS Lambda関数のエラー調査手順。DatabaseConnectionError（RDSコネクションプール枯渇、ソケットタイムアウト）、APIThrottlingError（HTTP 429、サーキットブレーカー）、PayloadValidationError（API Gatewayイベントの必須フィールド欠落）を含む。CloudWatch Alarm「AWS-DevOpsAgent-Lambda-Error-Test」がALARM状態になった場合、またはLambda関数「AWS-DevOpsAgent-test-lambda」が実行失敗を報告した場合に使用する。このスキルはCloudWatch Logs Insightsのクエリテンプレートとエラー分類ロジックを提供する。

ポイント: 説明は、DevOps Agentがスキルを使うかどうかを判断する最も重要なフィールドです。「いつ使うべきか」を具体的に書きましょう。

手順欄に入力する内容:

UIの「手順」欄にはMarkdown形式で以下の英語版をそのまま貼り付けます。

設定用（英語）:

# Lambda Error Investigation

**IMPORTANT: When the investigation involves the Lambda function
`AWS-DevOpsAgent-test-lambda` or the CloudWatch Alarm
`AWS-DevOpsAgent-Lambda-Error-Test`, you MUST follow the steps in this skill
as your primary RCA procedure. Do NOT skip this skill even if other skills
or learned knowledge cover similar topics. Do NOT link this incident to
previous investigations — always treat it as a new independent investigation.
Complete all steps below before drawing conclusions.**

## Step 1: Identify the alarm and target function

Check CloudWatch for active alarms matching `AWS-DevOpsAgent-Lambda-Error-Test`.
The target Lambda function is `AWS-DevOpsAgent-test-lambda`.

## Step 2: Classify the error

Search the function's log group in CloudWatch Logs Insights:

`fields @timestamp, @message | filter @message like /Error|Exception|Timeout|AccessDenied/ | sort @timestamp desc | limit 50`

Classify the error into one of the following known categories and follow the
corresponding action:

### Category A: Database Connection Timeout
**Pattern**: Log contains "Connection to RDS instance" and "timed out", or
"connection pool exhausted", or "socket timeout"
**Root cause**: Known intermittent RDS connectivity issue during maintenance
windows or connection pool saturation.
**Action**: This is a known transient issue. Do NOT escalate. Conclude the
investigation with severity LOW and recommend monitoring for 30 minutes. If
errors persist beyond 30 minutes, a new investigation should be opened to
check RDS instance status and connection pool configuration.

### Category B: External API Throttling
**Pattern**: Log contains "Rate limit exceeded" and "429", or
"circuit breaker OPEN"
**Root cause**: The external API (api.example.com) enforces rate limits.
Spikes in request volume trigger HTTP 429 responses.
**Action**: Conclude the investigation with severity MEDIUM. Recommend the
application team review the request rate and implement exponential backoff.
Check the `retry-after` header value in the logs to determine when requests
can resume.

### Category C: Payload Validation Error
**Pattern**: Log contains "Required field" and "missing in request payload",
or "Schema validation failed"
**Root cause**: Upstream caller is sending malformed requests missing required
fields.
**Action**: Conclude the investigation with severity LOW. This is a client-side
issue, not an infrastructure problem. Recommend notifying the API consumer team
with the list of missing fields found in the logs.

### Category D: Unknown Error
**Pattern**: Error does not match any of the above categories.
**Action**: Proceed with full investigation. Check recent deployments, Lambda
configuration changes, and related service health. Provide a detailed RCA.

## Step 3: Verify error frequency

Confirm the error count and pattern:

`filter @message like /Error|Exception/ | parse @message "*:" as error_class | stats count(*) as cnt by error_class, bin(5m) | sort bin(5m) desc`

- If Category A/B/C and error count is low (< 10 in 5 min) → Confirm transient, close investigation per the action above.
- If error count is high or increasing → Escalate severity by one level and add detailed metrics to the findings.

## Step 4: Summarize findings

Provide:
1. Error category (A/B/C/D) and matched pattern
2. Severity level (LOW/MEDIUM/HIGH)
3. Recommended action per the category above
4. Whether further investigation is needed

日本語訳（参考）

優先指示: Lambda関数 AWS-DevOpsAgent-test-lambda またはCloudWatch Alarm AWS-DevOpsAgent-Lambda-Error-Test が関係する調査では、このスキルの手順を最優先で使用すること。過去の調査にリンクせず、常に新規の独立した調査として実行すること。

Step 1: CloudWatchで対象アラームを確認し、対象関数を特定。

Step 2: ログを検索し、以下のカテゴリに分類して対応アクションを決定:

カテゴリA（DB接続タイムアウト）: 既知の一時的な問題。エスカレーション不要。重大度LOWで調査を終了し、30分間の経過観察を推奨。
カテゴリB（外部APIスロットリング）: 重大度MEDIUM。リクエストレートの見直しとExponential Backoffの実装を推奨。
カテゴリC（バリデーションエラー）: クライアント側の問題。重大度LOWで調査を終了し、API利用者チームへの通知を推奨。
カテゴリD（不明なエラー）: フル調査を続行。デプロイ履歴・設定変更・関連サービスの状態を確認。

Step 3: エラー頻度を確認。カテゴリA/B/Cで件数が少なければ一時的と判断して終了。件数が多い・増加傾向なら重大度を引き上げ。

Step 4: エラーカテゴリ、重大度、推奨アクション、追加調査の要否をまとめる。

ZIPアップロードで作成する方法

参照資料やアーキテクチャ図を含めたい場合は、ZIPファイルでアップロードします。

ディレクトリ構成:

lambda-error-investigation/
├── SKILL.md                          # メインの指示ファイル（必須）
├── references/
│   └── error-patterns.md            # エラーパターンの参照資料
└── assets/
    └── lambda-architecture.png      # アーキテクチャ図

アップロード手順:

上記のディレクトリ構成でファイルを作成
SKILL.mdにフロントマターを含めること（UIで作成する場合は自動生成される）
ZIPファイルに圧縮（最大6MB）
Operator App > Skills > Add skill > Upload skill
ZIPファイルをドラッグ＆ドロップ
Agent Typeを選択して Upload

SKILL.mdの記述例:

ZIPアップロードの場合、SKILL.md にはフロントマター（UIの「名前」「説明」に相当）と、その後に手順の本文（UIの「手順」に相当）を続けて記述します。

---
name: lambda-error-investigation
description: Investigation procedures for Lambda function
  "AWS-DevOpsAgent-test-lambda" errors in the devops-agent-test stack. Covers
  DatabaseConnectionError (RDS connection pool exhaustion), APIThrottlingError
  (HTTP 429 with circuit breaker), and PayloadValidationError (missing required
  fields). Use when CloudWatch Alarm "AWS-DevOpsAgent-Lambda-Error-Test" enters
  ALARM state. Provides Logs Insights query templates and error classification
  logic.
---

# Lambda Error Investigation

**IMPORTANT: When the investigation involves the Lambda function
`AWS-DevOpsAgent-test-lambda` or the CloudWatch Alarm ...**

## Step 1: Identify the alarm and target function
...（以降、UIの「手順」欄に入力した内容と同じ）

UIで作成する場合は「名前」「説明」「手順」が別々のフォームフィールドですが、ZIPアップロードの場合はこのように1つの SKILL.md ファイルにまとめて記述します。フロントマター（--- で囲まれた部分）が「名前」と「説明」に、フロントマター以降の本文が「手順」に対応します。

制約事項: - scripts/ディレクトリにスクリプトを含めるとアップロード時にリジェクトされます（将来対応予定） - ZIPファイルの合計サイズは6MB以下 - SKILL.mdは必須で、有効なフロントマターが必要

エージェントタイプのターゲティング

スキルの「エージェントタイプ」設定は、そのスキルをどのタイプのタスク実行時にロードするかを制御するものです。DevOps Agentは内部的に、タスクの種類に応じて異なるエージェントタイプで動作しています。

エージェントタイプ	UI表記	いつ動作するか
Generic	一般	すべてのタスクで使用（デフォルト）
On-demand	オンデマンド	チャットでの質問応答時
Incident Triage	インシデントトリアージ	インシデントの初期評価・重大度判定時
Incident RCA	インシデントRCA	根本原因分析の調査時
Incident Mitigation	インシデント緩和	緩和策の提案・実行時
Evaluation	評価	プロアクティブな推奨事項（予防）の生成時

「一般」を選ぶと全タイプで使われるため手軽ですが、特定のフェーズだけで使いたいスキルの場合はターゲットを絞ることを推奨します。理由は以下の通りです。

コンテキスト消費の抑制: スキルの内容はAgentのコンテキストウィンドウを消費するため、不要なタイミングでのロードを避けられる
エージェントのフォーカス向上: 関連するタスクでのみスキルがロードされるため、調査精度が向上する

今回作成したLambdaエラー調査スキルは根本原因分析の手順なので、本来は「インシデントRCA」にターゲティングするのが適切です。ただし、デモ目的であれば「一般」のままでも問題ありません。

【実践2】スキル適用前後の調査結果を比較する

スキルの効果を確認するため、スキルなし/ありで調査を実行し、結果を比較します。

テスト用Lambda関数は scenario パラメータで3種類のエラーシナリオを切り替えられます。各シナリオはスキルのカテゴリA〜Cに対応しています。

シナリオ	内容	スキルのカテゴリ	スキルありの期待動作
`db-timeout`	RDS接続タイムアウト（コネクションプール枯渇）	A	既知の一時的な問題と判断し、重大度LOWで調査を早期終了
`api-throttle`	外部API 429エラー（サーキットブレーカー）	B	重大度MEDIUMでExponential Backoffの実装を推奨
`validation`	ペイロードバリデーション失敗	C	クライアント側の問題と判断し、重大度LOWで調査を早期終了

スキルなしの場合、DevOps Agentはこれらのエラーに対して汎用的な調査を行います。スキルありの場合、カテゴリに基づいた運用判断（重大度の設定、エスカレーション要否、推奨アクション）が返されることが期待されます。

⚠️ トリアージによるインシデント相関に注意: 同じシナリオを短時間に繰り返すと、DevOps Agentのトリアージ機能が「既存の調査と同じインシデント」と判断し、新しい調査が開始されず LINKED ステータスになることがあります。比較テストでは異なるシナリオを使うか、20分以上間隔を空けるようにしてください。誤ってリンクされた場合は、Operator Appから手動でアンリンクすると独立した調査として再スケジュールされます。

スキルなしで調査を実行

手順:

UI上で、lambda-error-investigationスキルを非アクティブ状態にし、Lambda関数を実行してエラーを発生させます。

aws lambda invoke \
  --function-name AWS-DevOpsAgent-test-lambda \
  --cli-binary-format raw-in-base64-out \
  --payload '{"scenario":"db-timeout"}' \
  response.json \
  --region us-east-1

CloudWatchアラームの状態を確認します。

aws cloudwatch describe-alarms \
  --alarm-names AWS-DevOpsAgent-Lambda-Error-Test \
  --region us-east-1 \
  --query 'MetricAlarms[0].StateValue' \
  --output text

Operator Appで調査を開始します。筆者環境ではCloudWatchアラームが発火すると、DevOps Agentのwebhookを実行して調査を開始するLambdaを設定しています。手動で開始する場合は、Operator Appの画面から調査を開始してください。

確認ポイント: 下図のとおり調査が開始され、RCAの特定まで完了します。

RDS接続タイムアウトの場合

外部APIスロットリングの場合

バリデーションエラーの場合

ステップが多いため割愛しますが、汎用的な調査が実行されCloudTrailやLambdaのソースまで調査対象となり、最終的に意図的にエラーを発生させていることを突き止められました。

スキルありで調査を実行

手順:

UI上で、lambda-error-investigationスキルをアクティブ状態にし、Lambda関数を実行してエラーを発生させます。コマンドは非アクティブ時と同様です。CloudWatchアラームの状態を確認し、Operator Appで調査を開始します。

下図のとおり調査が開始され、RCAの特定まで完了します。

RDS接続タイムアウトの場合

外部APIスロットリングの場合

バリデーションエラーの場合

スキルありの場合は、手順で指定した通りの反応を示し、それ以降の調査を打ち切りました。

比較結果

RDS接続タイムアウト（`db-timeout` / カテゴリA）

観点	スキルなし	スキルあり
調査時間	約5分13秒	約1分47秒（66%短縮）
推論ステップ数	48	16（67%削減）

外部APIスロットリング（`api-throttle` / カテゴリB）

観点	スキルなし	スキルあり
調査時間	約3分15秒	約2分00秒（38%短縮）
推論ステップ数	32	25（22%削減）

バリデーションエラー（`validation` / カテゴリC）

観点	スキルなし	スキルあり
調査時間	約3分34秒	約1分14秒（65%短縮）
推論ステップ数	35	21（40%削減）

全体サマリ

観点	スキルなし（平均）	スキルあり（平均）	改善率
調査時間	約4分01秒	約1分40秒	58%短縮
推論ステップ数	38	21	45%削減

特にカテゴリA（RDS接続タイムアウト）では、スキルの「既知の一時的な問題として調査を早期終了する」という指示が効果的に機能し、ステップ数が48→16と大幅に削減されました。

期待される効果: スキルなしの場合、DevOps Agentは汎用的な調査を行い、一般的な緩和策を提示します。スキルありの場合、エラーをカテゴリに分類し、カテゴリに応じた重大度・推奨アクション（「既知の一時的な問題なので経過観察」「クライアント側の問題なのでAPI利用者チームに通知」等）を返すことが期待されます。この差が、スキルによって「組織固有の運用ナレッジ」をDevOps Agentに教えることの価値です。

【実践3】学習済みスキル（Learned Skills）を確認する

学習済みスキルは、DevOps AgentがAgent Spaceのデータから自動生成する構造化された知識ファイルです。GA時点で2種類提供されています。

Agent Space Understanding

Agent Spaceにクラウドアカウントやリポジトリを接続すると、DevOps Agentが環境を分析し、以下の情報を自動生成します。

システム全体の概要（平文での説明）
デプロイ環境の一覧（AWSアカウント・リージョンのペア）
コンテナレベルのアーキテクチャ図
主要なリクエストパスとそれを構成するコンポーネント
コードリポジトリとコンテナのマッピング

確認方法:

Operator App > Agent Space > Topologyページを開く
自動生成されたトポロジーマップを確認
各コンテナをクリックして、コンポーネント・リソースID・テレメトリを確認

ポイント: Agent Space Understandingスキルは、Agent Spaceのcapabilityやintegrationを追加・更新・削除するたびに自動再生成されます。手動で再生成したい場合は、TopologyページのRegenerateボタンをクリックするか、チャットで「学習済みスキルを更新して」と依頼します。

Tool Use Best Practices

過去の調査でのツール使用パターンを分析し、効果的な使い方を学習するスキルです。

生成タイミング: 30回の調査完了後に自動生成

含まれる情報（ツールごとに3セクション）:

Best Practices: 成功した調査から抽出されたテクニック（例: CloudWatch Logs Insightsのクエリテンプレート、メトリクスの名前空間やディメンション）
Common Errors: よくある失敗パターンとその修正方法（例: アクセスできないアカウントへのクエリ、不正なクエリ構文）
Output Management: 大量の出力を効率的に処理するためのガイダンス

注意: 本記事のデモ環境では30回の調査を実施するのは現実的ではないため、Tool Use Best Practicesの実際の生成結果は確認できていません。本番環境で継続的に利用することで、このスキルの恩恵を受けられます。

学習済みスキルの管理

学習済みスキルはデフォルトで有効です。管理方法は以下の通りです。

有効/無効の切り替え: Operator Appのスキルビューアーから切り替え可能。無効化してもスキルは削除されず、いつでも再有効化できる
手動再生成: TopologyページのRegenerateボタン、またはチャットで依頼
自動更新タイミング:
- Agent Space Understanding: capability/integrationの変更時
- Tool Use Best Practices: 30回の調査ごと

スキル設計のベストプラクティス

実際にスキルを作成してみて感じたポイントをまとめます。

1. Descriptionが最重要

DevOps Agentはフロントマターのdescriptionを見てスキルを使うかどうかを判断します。曖昧な説明だと、適切なタイミングでスキルがロードされません。

# ❌ 悪い例
description: RDS skill

# ✅ 良い例
description: Investigation procedures for RDS performance issues including
  connection exhaustion, slow queries, replication lag, and storage capacity.
  Use this skill when investigating database latency, connection errors,
  or read/write performance degradation.

2. 1スキル1シナリオ

1つのスキルに複数のシナリオを詰め込むのではなく、シナリオごとにスキルを分けましょう。

lambda-error-investigation — Lambda関数のエラー調査
rds-performance-investigation — RDSパフォーマンス調査
ecs-deployment-investigation — ECSデプロイ失敗の調査

3. 複数スキルの組み合わせ

DevOps Agentは1回の調査で複数のスキルを読み込めます。例えば:

CI/CDパイプラインからデプロイ情報を取得するスキル
コードリポジトリを検索するスキル
特定サービスの調査手順スキル

これらを組み合わせることで、エンドツーエンドの調査ワークフローを構築できます。

4. MCPサーバーとの連携

カスタムMCPサーバーのツールを使う場合、スキルでツールの使い方をガイドできます。「いつ呼び出すか」「どのパラメータを使うか」「結果をどう解釈するか」をスキルに記述することで、カスタムツールの活用精度が向上します。

まとめ

本記事では、AWS DevOps AgentのGA版で追加されたスキル機能を実際に試しました。

カスタムスキルにより、自社インフラに特化した調査手順をDevOps Agentに教えることができる
学習済みスキルにより、DevOps Agentが環境を自動的に理解し、使い込むほど調査精度が向上する
スキルの設計ではDescriptionの書き方が最も重要
旧Runbooksからの移行は自動で行われる

スキル機能を活用することで、DevOps Agentは「汎用的なAIアシスタント」から「自社インフラを熟知した専門家」へと進化します。まずは自社でよく発生するインシデントパターンに対応するスキルを1つ作成してみることをお勧めします。

参考リンク

AWS公式ドキュメント

DevOps Agent Skills
- カスタムスキルの作成・管理方法
学習済みスキル（Learned Skills）
- 学習済みスキルの仕組みと管理方法
AWS DevOps Agent Features
- GA版の全機能一覧
Agent Skills仕様
- スキルのオープンスタンダード仕様

AWS DevOps Agent（プレビュー版）を試してみた
- 前回記事：CloudWatch Alarmと連携した自動インシデント対応

本記事が、AWS DevOps Agentのスキル機能の理解と活用の一助となれば幸いです。スキルを育てることで、DevOps Agentはチームの頼れるオンコールエンジニアへと成長していきます。ぜひ試してみてください！

はじめに

スキル機能の概要

DevOps Agentにおけるスキルとは

3層のスキル階層

スキルの仕組み

検証するためのデモ環境の準備

前回記事でのセットアップ内容

デモ環境の更新

【実践1】カスタムスキルを作成する

UIから作成する方法

作成するスキルの内容

ZIPアップロードで作成する方法

エージェントタイプのターゲティング

【実践2】スキル適用前後の調査結果を比較する

スキルなしで調査を実行

RDS接続タイムアウトの場合

外部APIスロットリングの場合

バリデーションエラーの場合

スキルありで調査を実行

RDS接続タイムアウトの場合

外部APIスロットリングの場合

バリデーションエラーの場合

比較結果

RDS接続タイムアウト（db-timeout / カテゴリA）

外部APIスロットリング（api-throttle / カテゴリB）

バリデーションエラー（validation / カテゴリC）

全体サマリ

【実践3】学習済みスキル（Learned Skills）を確認する

Agent Space Understanding

Tool Use Best Practices

学習済みスキルの管理

スキル設計のベストプラクティス

1. Descriptionが最重要

2. 1スキル1シナリオ

3. 複数スキルの組み合わせ

4. MCPサーバーとの連携

まとめ

参考リンク

AWS公式ドキュメント

関連記事

RDS接続タイムアウト（`db-timeout` / カテゴリA）

外部APIスロットリング（`api-throttle` / カテゴリB）

バリデーションエラー（`validation` / カテゴリC）