AWS DevOps Agent Skills を作成するためのベストプラクティス

深夜 2 時にインシデントが発生したとき、オンコール担当者がどれだけ的確に対応できるかは、そのシステムについてどのような知識を持っているかに左右されます。最初に見るべきメトリクスはどれか、このサービスの「平常時」はどんな状態か、デプロイ履歴はどこを見ればわかるのか。こうした知識は、ランブックや社内 Wiki、そしてシステムを作ったシニアエンジニアの頭の中にあることが少なくありません。そのため、調査の質は「誰が呼び出されたか」で変わってしまいます。サービスを作った本人が対応すれば、根本原因の分析にかかる時間は大幅に短くなります。そうでなければ、同じ調査に何時間もかかったり、根本原因にたどり着けないまま終わったりします。

AWS DevOps Agent の Skills は、このギャップを埋める仕組みです。チームの優れた調査手順を、再利用しやすい単位に分けた一連の指示としてまとめておくと、エージェントがインシデント対応中に必要なものを自動で読み込みます。オンコール担当者が正しい手順を知っているかどうかに頼る必要はありません。Skills は、そのノウハウを 24 時間 365 日エージェントが使える状態にします。誰が呼び出されても変わらず、一貫して繰り返せる調査になります。

うまく書けた Skill は属人的なノウハウを再利用可能な調査プレイブックに変えますが、書き方が悪い Skill はまったく使われません。この記事では、確実に起動し、構造化された調査フローに沿って動き、他の Skills と組み合わさって MTTR（平均解決時間）を短縮できる Skill の書き方を紹介します。

私たちが支援した、グローバルに事業を展開するある金融サービス企業では、チームの調査ノウハウを Skills に落とし込んだ結果、エージェントの位置づけが「面白いデモ」から「P1 インシデントの一次対応者」に変わりました。エージェントは、根本原因の候補を提示するようになったのです。これまでは、その候補を見つけるために、シニアエンジニアが多くのログを手作業で突き合わせる必要がありました。この企業が得た結論は、私たちの考えと一致していました。Skills の品質が、調査の品質を決めます。

背景：Skill とは何か

Skill は、必須の SKILL.md と任意の参考資料（アーキテクチャ図、メトリクスのしきい値表、トラブルシューティングのフローチャートなど）をまとめた、自己完結型のディレクトリです。オープンな Agent Skills specification のサブセットに準拠しており、Markdown、PDF、画像、データファイルといった、実行を伴わない文書を扱えます。

SKILL.md の先頭には、フロントマター（メタデータブロック）として name と description を書く必要があります。エージェントは description を見て、その Skill が今の作業に関係するかどうかを判断します。ファイルの残りの部分が、調査手順そのものです。

my-skill/
├── SKILL.md       # 必須: フロントマター + 調査手順
├── references/    # 任意: メトリクス表、エラーコード対応表など
└── assets/        # 任意: 図、フローチャート、データファイル

AWS DevOps Agent を本番環境にデプロイするためのベストプラクティス に沿って Agent Space を導入済みであれば、Skills はその次のステップです。Skills を使うと、Agent Space 内でエージェントの振る舞いを特定の用途に合わせられます。

Skills がなくても、エージェントは AWS サービスに関する一般的な知識を使って調査できます。メトリクスを照会したり、ログやデプロイを確認したりすることもできます。しかし、チーム固有の調査のコツ、環境固有のしきい値、そのサービスで本当に重要なメトリクスは知りません。Skills はその差を埋めます。確認すべき項目を確認すべき順番で直接示すことで、調査の立ち上がりが速くなり、エージェントは汎用的な調査にありがちな試行錯誤を省けます。

Skill とエージェント指示の使い分け

エージェントの振る舞いを変える手段は、Skills だけではありません。もう一つの手段がエージェント指示です。AGENTS.md というファイルに保存し、Operator Web App の Knowledge ページで設定します。この 2 つは解決する問題が異なります。正しく使い分けると、エージェントは目の前の作業に集中でき、限られた作業メモリ（コンテキストウィンドウ）も効率よく使えます。

違いは「いつ読み込まれるか」です。

• エージェント指示：常に有効。エージェントが何を扱っていても、セッション開始時にシステムプロンプトへ必ず組み込まれる
• Skills：必要なときだけ有効。description が目の前のタスクに合致したときにだけ読み込まれる

つまり、エージェント指示はすべてのセッションでの振る舞いを決め、Skill は特定の状況向けの専門的なプレイブックを与えます。この違いから、判断基準はシンプルになります。

すべての調査に適用する必要がある内容は、エージェント指示に書きます。たとえば、回答のフォーマット、「シークレットを平文で表示しない」といったセキュリティポリシー、「根本原因を提示する前に必ず直近のデプロイを確認する」といったチームのルールです。エージェント指示に書けば、これらが毎回読み込まれることを保証できます。一方、特定のシナリオだけで使う手順は、Skill に書きます。たとえば、RDS のコネクション枯渇や ECS のクラッシュループを調べる手順です。Skill は必要なときだけ読み込まれ、それ以外のときはコンテキストウィンドウを使いません。

実務上の違いを整理すると、次のとおりです。

見分け方のコツ：エージェントが「何を調査するのか」を知る前から目の前に置いておきたい内容ならエージェント指示です。「RDS のレイテンシ問題だ」とわかって初めて意味を持つ内容なら Skill です。

サイズには注意が必要です。エージェント指示は毎セッション読み込まれるため、その分、ユーザーの質問やログ、エージェント自身の推論に使える作業メモリが少なくなります。サービス側のガイダンスでも、エージェント指示は短く保ち、専門的な手順は Skills に移すことが推奨されています。あらゆる調査手順を詰め込んで肥大化した AGENTS.md はアンチパターンです。その内容は、テーマを絞った Skills に分割しましょう。

なお、エージェントを拡張する手段は他にもあります。カスタムエージェントを使うと、システムプロンプト・ツール・Skills を 1 つにまとめて、「定期ヘルスレポート」のような専用のワークフローを作れます。MCP サーバーを使うと、独自の診断ツールを追加できます。オープンソースの AWS DevOps Agent Tools リポジトリには、Skills、カスタムエージェント、MCP サーバーのすぐに使えるサンプルがあり、そのまま取り込むことも、自分用に作り変える出発点にすることもできます。

確実に起動する description を書く

フロントマターの description が、Skill を読み込むかどうかを決めます。ここが最も効果の大きいポイントです。description があいまいだと、中の手順がどれほど優れていても、エージェントは Skill を読み飛ばします。

description は「エージェントの視点」で書きます。その Skill を使うべきサービス、エラーの種類、症状、シナリオを具体的に書いてください。

あいまいすぎる例：

---
name: database-skill
description: データベースの問題に対応する。
---

具体的で実用的な例：

---
name: rds-connection-exhaustion
description: Amazon RDS および Amazon Aurora のコネクション枯渇に関する調査手順。
  max_connections の上限到達、コネクションプールの設定ミス、アイドルコネクションの
  蓄積を扱う。DatabaseConnections アラーム、接続タイムアウトエラー、
  "too many connections" というアプリケーションエラーを調査するときに使用する。
---

インシデントの最中にオンコール担当者が検索しそうな言葉を考えてみてください。アラーム名、エラーメッセージ、症状などです。こうした言葉こそ description に入れるべきものです。

セルフチェック：description を読んで、「インシデントのトリアージ中だったら、この説明だけでこの Skill が当てはまるかどうか判断できるか？」と自問してください。答えが「いいえ」なら、説明をさらに具体的にしてください。

私たちも、これを実際に経験しました。db-health という Skill に「データベースの健全性を監視する」という意味の description を付けていたところ、本番の RDS インスタンスが午前 3 時に max_connections の上限に達しても、エージェントはこの Skill を読み込みませんでした。インシデントで発火していたアラーム RDS-DatabaseConnections-Critical と、「データベースの健全性を監視する」という説明に、一致する言葉がなかったからです。

そこで description を「RDS のコネクション枯渇、max_connections の超過、DatabaseConnections アラームの急増に関する調査手順」という内容に書き換えました。Skill も中の手順も、まったく同じままです。それでも、以後はそのアラームが発火するたびに、エージェントが必ずこの Skill を読み込むようになりました。

指示を調査ステップとして構成する

Skill は、事実を並べたリストではなく、シニアエンジニアの調査プレイブックのように読めるものにします。各ステップでは、何を確認し、何に注目し、結果に応じて次に何をするかをエージェントに伝えます。

機能する Skill と機能しない Skill の差は、多くの場合、判断ロジックが入っているかどうかです。まず、うまく機能しない例を示し、続いてうまく機能する例を示します。

うまく機能しない例 — あいまいで、受動的で、判断ロジックがない：

---
name: ecs-skill
description: ECS の問題の調査を支援する。
---

# ECS の調査

ECS タスクの状態を確認する。CPU とメモリのメトリクスを見る。
直近のデプロイを確認する。ロードバランサーを確認する。
何かおかしければ、さらに調べる。

この例には 2 つの問題があります。1 つ目は、description が広すぎるため、Skill が安定して起動しないことです。「ECS の問題」はあらゆる状況に当てはまるようで、実際にはどれにも当てはまりません。2 つ目は、指示が調査ワークフローではなく、確認対象を並べたチェックリストになっていることです。順序もしきい値もなく、「おかしい」とは何か、次に何をすべきかを示す判断ポイントもありません。

うまく機能する Skill には、具体的な起動条件、構造化されたロジック、判断に応じた明確な分岐があります。

---
name: ecs-task-crash-loop
description: ECS タスクがクラッシュループ（0 以外の終了コードで STOPPED を
  繰り返す状態）に陥った場合の調査手順。OOM kill（メモリ不足による強制終了）、
  ヘルスチェックの失敗、コンテナ間の依存関係の問題を扱う。
  ECS-TaskFailure アラームが発火したとき、またはタスクが PENDING と STOPPED を
  繰り返しているときに使用する。
---

# Step 1: 障害のパターンを特定する

対象サービスで停止したタスクを過去 2 時間分照会する。停止理由ごとに次のように分類する。
- 終了コード 137 → OOM kill。Step 2 へ進む。
- 終了コード 1 かつ "essential container exited" → 依存関係の障害。Step 3 へ進む。
- 終了コードなし + "health check failed" → コンテナは稼働しているが応答がない。
  Step 4 へ進む。

# Step 2: メモリ不足を調査する

対象のタスク定義について、CloudWatch Container Insights のメモリ使用率を取得し、
タスクのハードメモリ上限と比較する。障害が起きる前の 30 分間、使用率が上限の
90% を継続して超えていた場合は、メモリ割り当ての増加を推奨する。あわせて、
メモリ使用量に影響する変更が含まれていないか、直近のデプロイを優先的な
調査対象として挙げる。

# Step 3: 依存関係の障害を調査する

タスクの状態が変化したタイムスタンプを比較して、最初に終了したコンテナを特定する。
そのコンテナのログで起動時のエラーを確認する。よくある原因は、環境変数の不足、
依存先サービスのヘルスチェック失敗、レジストリ障害によるイメージ取得の失敗である。

# Step 4: ヘルスチェックのタイムアウトを調査する

ヘルスチェックの設定（interval、timeout、retries）を、コンテナが実際に起動するまでの
時間と比較する。ヘルスチェックが許容する時間よりも初期化に時間がかかる場合、
コンテナは正常になる前に停止させられる。直近のデプロイで起動時間が延びていないか
（新しい依存関係の追加、読み込むモデルの大型化、起動時のデータベースマイグレーションなど）
を確認する。

パターンに注目してください。各ステップには、明確なアクション、注目すべき具体的なポイント、そして次のステップを決める判断ポイントがあります。エージェントはこれを、ただ読むだけの一覧としてではなくフローチャートのようにたどります。

事実やメトリクスを並べるだけで、それを使って何をするかを書かない Skill は避けてください。Amazon CloudWatch のメトリクスのしきい値表は参考ファイルとしては役立ちますが、SKILL.md 本体には、そのしきい値を使う調査ロジックを書きます。

適切なエージェントタイプに絞る

すべての Skills が、調査のすべてのフェーズに関係するわけではありません。AWS DevOps Agent には複数のエージェントタイプがあり、Skill を作成・アップロードするときの Agent Type 設定で、どのエージェントタイプに使わせるかを指定できます。

デフォルトは Generic で、すべてのエージェントタイプがその Skill を使えます。使い始めはこれが適切な選択です。その他のエージェントタイプは、調査や対応のライフサイクルの各フェーズに対応しています。

Skill は読み込まれるたびにコンテキストを消費します。最初のトリアージの段階で詳細な対処プレイブックを読み込むと、まだ必要のない指示にコンテキストを使ってしまいます。エージェントタイプを絞ると、この無駄が減り、エージェントは今のフェーズに集中できます。

実践的な進め方として、まずはすべての Skills を Generic で作成します。何回か調査を実行したら、各 Skill がどのフェーズで最も役立ったかを振り返り、対象を絞り込みます。デプロイのロールバック手順は Incident Mitigation に適しています。トリアージ中に読み込んでも、エージェントはまだその手順を実行できず、コンテキストを無駄にするだけです。オブザーバビリティギャップ分析は Evaluation に適しています。これはインシデント対応ではなく、事前に行う作業です。重大度の分類ガイドは Incident Triage に適しています。アラームの発火直後に使う必要があり、エージェントが 20 分調査したあとでは遅すぎます。

On-demand と Generic の違いは重要です。On-demand の Skill は、誰かがチャットでエージェントに明示的に質問したときにだけ起動します。その場の問い合わせに答えるためにチームのアーキテクチャをまとめた Skill は、On-demand に置きます。インシデント中に自動で起動してほしい Skill は、インシデント系のタイプか Generic に置きます。

AWS DevOps Agent が Directed actions に対応したことで、Incident Mitigation 向けの Skills は見直す価値が出てきました。Directed actions とは、接続済みのサービスや AWS アカウントに対して、エージェントに明示的に実行を依頼する操作のことです。

読み取り専用のアクションはデフォルトで利用できます。リソースを作成・変更するアクションはデフォルトで無効になっており、使うには明示的に有効化する必要があります。承認の操作と、承認後に実行されたアクションは、どのオペレーターが承認したかがわかる形で AWS CloudTrail に記録されます。

Directed actions を有効にすると、Incident Mitigation の Skill は「対処方法を説明する」だけでなく、「承認された対処を実行するまでエージェントを導く」ことができるようになります。こうした Skills も、他の Skills と同じ規律で書いてください。明確な前提条件、はっきりした停止ポイント、そして実行する前にプランを示して承認を求める指示を入れます。

私たちが Skills を特定のエージェントタイプに絞り込んだところ、エージェントの調査結果は焦点がはっきりしたものになりました。トリアージの回答は、根本原因を早まって推測するのではなく、簡潔な重大度の評価になりました。RCA のフェーズでは、まだ必要のない対処手順にコンテキストウィンドウを使わずに済むぶん、より深く調査できるようになりました。

参考資料を含める

Skill に参考ファイルを添えておくと、エージェントが調査中に推論の材料として使える構造化データを渡せます。SKILL.md には調査ロジックを、参考ファイルにはそのロジックが使うドメイン知識を置きます。

メトリクスのしきい値表は、その環境における「正常」と「要注意」の基準を定めます。エージェントは調査中、現在のメトリクスをこの基準と比較できます。

# references/rds-metrics-reference.md

| メトリクス          | 正常な範囲                  | 調査を始めるしきい値      |
|---------------------|-----------------------------|---------------------------|
| DatabaseConnections | max_connections の 70% 未満 | max_connections の 80% 超 |
| ReadLatency         | 5 ms 未満                   | 20 ms 超                  |
| WriteLatency        | 5 ms 未満                   | 20 ms 超                  |
| FreeStorageSpace    | ストレージ全体の 30% 超     | ストレージ全体の 20% 未満 |
| CPUUtilization      | 70% 未満                    | 85% 超                    |

エラーコードの対応表は、わかりにくいエラーコードを調査の進め方に結び付けます。たとえば、ORA-12519 の意味をエージェントに推測させる代わりに、「リスナーの接続数の上限に到達。コネクションプールの設定を確認する」と直接対応付けられます。

アーキテクチャの情報には、その環境固有のサービス間の依存関係、データの流れ、障害ドメインを記録します。インフラ構成を見ただけでは障害の影響範囲がわかりにくいマイクロサービス構成で、特に役立ちます。

エスカレーション手順は、他のチームを巻き込むべきタイミングと方法をエージェントに伝えます。正式なドキュメントにはほとんど残っていないものの、インシデント対応では欠かせない運用知識です。

参考資料を含む Skill のディレクトリ構成は、次のようになります。

ecs-deployment-investigation/
├── SKILL.md
├── references/
│   ├── ecs-error-codes.md
│   ├── deployment-strategies.md
│   └── healthy-thresholds.md
└── assets/
    └── ecs-investigation-flow.png

Skills を組み合わせてエンドツーエンドのワークフローを作る

個々の Skill は単独でも役立ちますが、本当の価値は Skills を組み合わせたときに生まれます。AWS DevOps Agent は 1 回の調査で複数の Skills を読み込むため、内容が重複せず、互いを補完するように Skills を設計できます。

たとえば、デプロイ後に Amazon ECS のサービスが失敗し始めたケースを考えます。この場合、3 つの Skills を連携させられます。1 つ目は CI/CD システムから直近のデプロイを取得する Skill、2 つ目はコードリポジトリから関連する変更を探す Skill、3 つ目は ECS タスクの失敗とスケーリングの挙動を調査する Skill です。

エージェントはこの 3 つをすべて読み込み、デプロイのタイミングとコードの変更、サービスの健全性を突き合わせます。シニアエンジニアが行うのと同じワークフローを、自動で実行するわけです。

設計の原則はシンプルです。各 Skill は単独でも役立ち、かつ他の Skills と組み合わせられるようにします。たとえば CI/CD パイプラインの Skill は、コードリポジトリの Skill も読み込まれていることを前提にしてはいけません。単独でも意味のある調査結果を出し、他の Skills の結果と組み合わさるとさらに価値が高まる、という形にします。

これは、調査全体を 1 つで網羅しようとする巨大な Skill を作るべきではない、ということでもあります。「ECS に関するすべて」を扱う Skill は、description を十分に具体的にできないため安定して起動せず、サイズも大きすぎて効率よく読み込めません。「ECS のデプロイの問題」「ECS のスケーリングの問題」「ECS のネットワークの問題」のようにテーマを絞った Skills に分け、必要に応じてエージェントに組み合わせさせましょう。

カスタム MCP ツールの使い方をエージェントに示す

AWS DevOps Agent にカスタムの MCP サーバーを接続している場合、そのツールを効果的に使う方法を Skill に書いておけます。Skill がないと、エージェントはツールがあることはわかっていても、その環境に合ったパラメーターや結果の読み解き方まではわからない場合があります。

---
name: custom-deployment-tracker-investigation
description: 社内のデプロイ追跡用 MCP 連携を使って、直近のデプロイに関連する
  インシデントを調査する手順。インシデントが、サービスのデプロイや CI/CD
  パイプライン経由の設定変更と関連していそうなときに使用する。
---

# デプロイとの関連を調べる

直近のデプロイが関係していそうなインシデントを調査するときは、次の手順に従う。

## Step 1: 直近のデプロイを照会する

`deployment-tracker-get-changes` ツールを、次のパラメーターで使う。
- `environment`: 影響を受けている環境に合わせる（production、staging）
- `timeRange`: インシデント開始時刻の 4 時間前を指定する
- `service`: 影響を受けているサービスの識別子

## Step 2: デプロイとインシデントの時系列を突き合わせる

デプロイの時刻とインシデントの開始時刻を比較する。インシデント開始の直前 30 分間に
行われたデプロイは、疑わしい候補として優先的に調べる。そのデプロイに設定変更や
依存関係の更新が含まれていたかを確認する。これらは、デプロイ後にトラフィックが
増えてから表面化するレイテンシ関連のインシデントでよくある原因である。

このパターンでは、いつツールを使うか、シナリオごとにどのパラメーターを使うか、結果をどう読み解くかを書いています。これによってエージェントは、「デプロイ追跡ツールにアクセスできる」状態から、「この環境でデプロイ起因のインシデントを調査するとき、このツールをどう使えばよいかわかっている」状態になります。

Skills とメモリは補い合う

Skills は、ユーザーが書く指示です。一方、メモリは、エージェントが蓄積し、ユーザーが整理して活用できる運用知識です。AWS DevOps Agent は、環境のトポロジー、コードの依存関係、パイプラインの構成、ツールの使い方のパターンなど、学習した知識をメモリとして保持するようになりました。また、チーム、サービス、繰り返し発生する問題ごとに運用知識をまとめる独自のメモリストアも作成できます。この 2 つは互いに補い合います。Skill は調査のワークフローを記述し、メモリストアはそのワークフローが参照する環境固有の事実を保持します。

実践的な分担としては、長く使える再利用可能な手順は Skill に書き、変化の速い環境固有の事実はメモリに置きます。メモリは Skill を編集せずに更新できます。こうすると Skills が安定し、次のセクションで説明する「Skill の陳腐化」も起きにくくなります。変わりやすい情報を、あらかじめメモリに移しているからです。

見落としやすい失敗パターン

具体的な description を書く、判断の分岐を入れる、巨大な Skill を作らない、といった基本はここまでで説明しました。以下の失敗はもっとわかりにくく、本番で Skills を数週間から数か月運用したあとに表面化します。

組み合わせると矛盾する Skills。 2 つの Skills が同時に読み込まれ、相反する指示を出す場合があります。たとえば「データベースのコネクション数を増やす」Skill と「コネクションプールのサイズを減らす」Skill が同じ RDS のインシデントで両方起動すると、エージェントは矛盾する推奨を受け取ることになります。新しい Skill を公開する前に、同じアラームや症状を対象にしている既存の Skills を確認しましょう。同時に読み込まれる可能性がある場合は、判断の境界をはっきり書いてください。たとえば「コネクション数が多くても CPU 使用率が正常なら、コネクションプールのリークと判断してコネクション数を減らす。コネクション数が多く、CPU 使用率も上限に張り付いているなら、データベースの容量を増やす」のように書きます。

インフラの変化に追いつかず、陳腐化する Skills。 半年前に ECS クラスター向けに書いた Skill は、すでに存在しないタスク定義、サービス名、メトリクスのしきい値を参照しているかもしれません。コードと違い、Skills が古いインフラを参照しても、その問題は明確なエラーとして表れません。エージェントは古い手順にそのまま従い、的外れな調査結果を出してしまいます。Skills はランブックと同じように扱い、四半期ごとに見直して、変更管理のプロセスに組み込みましょう。SKILL.md には last_verified のコメントを入れて、調査手順を実際のインフラで最後に検証した時期がレビュー担当者にわかるようにしてください。しきい値、リソース名、依存関係の図など、変わりやすい情報はメモリストアに移し、Skill とは別に更新できるようにすることも検討しましょう。

エージェントが臨機応変に動けない、厳格すぎる手順。 「メトリクス X を確認し、次に Y、次に Z を確認する」と厳密な順序を決めた Skill は、実際のインシデントが想定したパターンと違ったときに、エージェントを一本道に閉じ込めてしまいかねません。抜け道がないと、エージェントは全ステップを律儀にこなして「問題なし」と報告します。その間も、本当の根本原因は、Skill が一度も触れていないシステムに潜んだままです。抜け道となる分岐を用意してください。Step 1 の結果が正常だったときに備えて、「Step 4 に進む」や「この Skill は当てはまらない可能性がある。ここまでの結果を報告し、一般的な調査に任せる」といった指示を入れておきます。

意図せず対象範囲が重複する Skills。 時間がたつと、別々のメンバーが書いた Skills の対象範囲が重なってきます。たとえば「API レイテンシの調査」Skill と「サービスのタイムアウトの調査」Skill が、同じ CloudWatch メトリクスを確認し、同じ呼び出し経路をたどっている、といったケースです。エージェントは両方を読み込んで同じ作業を繰り返し、重複した調査結果にコンテキストを使ってしまいます。Skills の一覧表を管理しましょう。Skills と、それが対象とするアラームやサービスを対応付けた簡単なスプレッドシートでも構いません。新しい Skill を追加するときに、重複がないかを確認してください。

はじめ方

まずは、直近の四半期のインシデントのカテゴリーから上位 3 つを選んでください。これらは、Skill の効果を最も早く実感できるシナリオです。

それぞれについて、普段その種類のインシデントに対応しているシニアエンジニアに話を聞きます。「このインシデントで呼び出されたら、最初に何を確認しますか？」と尋ねてください。その答えが、Skill の Step 1 になります。続けて「次に何を確認しますか？ X と Y のどちらなのかは、何で見分けますか？」と尋ねれば、調査のワークフローができあがります。

明確で具体的な手順を書いた 20 行の SKILL.md は、あいまいな内容の 200 行のドキュメントよりも効果があります。シンプルに始めて実際に調査を実行し、エージェントがうまくできたところ、つまずいたところをもとに改善していきましょう。Skills が増えてきたら、Skills やその他のアセットを Infrastructure as Code として宣言的に管理し、他のインフラと同じようにパイプラインを通じて複数の Agent Space にデプロイできるようになります。

ゼロから書き始めたくない場合は、オープンソースの AWS DevOps Agent Tools リポジトリに、コミュニティが作成した Skills、カスタムエージェント、MCP サーバーがあります。そのまま取り込むことも、手を加えて使うこともできます。

Skill の構成と作成方法の詳細は AWS DevOps Agent Skills のドキュメント を、Agent Space のセットアップについては AWS DevOps Agent を本番環境にデプロイするためのベストプラクティス を参照してください。

Skills は、エンジニアがチームを異動しても、組織の知識が失われないようにする仕組みです。チームがうまく調査できたインシデントは、どれも「まだ書かれていない Skill」です。

最初の Skill は、チームで最も経験豊富なエンジニアが、普段ほとんど意識せずに行っている調査から始めましょう。どのダッシュボードを開き、どのロググループを検索し、どのメトリクスがどのしきい値を超えたら「すぐにロールバック」なのかを、その人はすでに知っています。それを書き出せば、深夜 2 時に誰が呼び出されても、その専門知識が活かされるようになります。

本ブログは 2026 年 9 月 30 日に公開された Best practices for writing AWS DevOps Agent Skills の日本語訳です。翻訳はテクニカルアカウントマネージャーの日平が行いました。