トップ > Agent Toolkit for AWS > 新しくリリースされた Agent Toolkit for AWS のスキルとプラグインを試してみた

新しくリリースされた Agent Toolkit for AWS のスキルとプラグインを試してみた

Agent Toolkit for AWS
記事タイトルとURLをコピーする

はじめに

2026年5月6日、AWS は Agent Toolkit for AWS をリリースしました。AI コーディングエージェントが AWS 上でより正確に、より安全に構築できるようにする本番環境対応のツールスイートです。

同日に GA となった AWS MCP Server については 前回の記事 で紹介しました。Agent Toolkit for AWS は、その MCP Server に加えて エージェントスキル と プラグイン を統合した上位パッケージという位置づけです。

実はこの「エージェントスキル」という概念は AWS だけのものではありません。GitHub が Agent Skills 仕様 をオープンスタンダードとして策定しており、Microsoft（Azure Skills Plugin）や HashiCorp（hashicorp/agent-skills）なども同じ仕様でスキルを公開しています。業界全体で「エージェントにベストプラクティスを教える」仕組みが標準化されつつある中で、AWS もその流れに乗った形です。

前回の記事で AWS MCP Server を設定して使えるようになったので、今回はその上に乗る「スキル」と「プラグイン」を試してみます。

AWS の公式ブログでは、エージェントが「必要以上に広い IAM ポリシーを生成する」「デモでは動くが本番品質ではないインフラを作る」と指摘されています。スキルはこうした問題を、検証済みの手順で補正する仕組みです。

本当にそうなのか、実際に検証してみます。

Agent Toolkit for AWS の全体像

前回の記事では AWS MCP Server を中心に紹介しましたが、Agent Toolkit for AWS は3つのコンポーネントで構成されています。

  • AWS MCP Server = 問いに対する直接の答えを返す（API 実行、ドキュメント検索）
  • エージェントスキル = 周辺知識を補完する（ベストプラクティス、設計パターン、よくあるミスの回避）
  • プラグイン = AWS MCP Server とエージェントスキルの両方をワンインストールで提供するセット

MCP Server が「S3 バケットを作って」に応えるのに対し、スキルは「S3 バケットを作るなら暗号化はこう設定して、ライフサイクルポリシーはこう組むのが正解」という文脈を補います。前回の記事は MCP Server の話で、今回はスキルとプラグインの話です。

エージェントスキルとは

「動くこと」と「本番品質」のギャップ

AI コーディングエージェントは膨大な知識を持っていますが、AWS 上で本番品質のコードを書くには3つの壁があります。AWS 公式ブログでは以下のように指摘されています。

壁1: 知識が古い

agents rely on training data that may be months out of date and may not know about services like Amazon S3 Vectors, Amazon Aurora DSQL, or Amazon Bedrock AgentCore

モデルには学習カットオフがあるため、それ以降にリリースされたサービスを知りません。例えば「ベクトル検索を S3 でやりたい」と聞いても、S3 Vectors の存在を知らない場合は的外れな回答が返ってきます。

壁2: セキュリティなどの非機能面を担保しきれない

they produce IAM policies that are far broader than necessary The result is infrastructure that works in a demo but is not production-ready

エージェントは「動くコード」を書くのは得意ですが、本番環境で求められる品質には届かないことが多いです。IAM 権限が最小限になっていないといったことです。

壁3: サービスの組み合わせ方を知らない

agents that struggle with complex multi-service workflows

個々の API ドキュメントは読めても、「Lambda + API Gateway + DynamoDB をこう組み合わせるのがベストプラクティス」という複数サービスを組み合わせた構成は、学習データに十分含まれていないことがあります。

要するに、ユーザーがエージェントとしっかりラリーをして考慮事項を伝えないと、「Lambda で A をやりたい」と言ったらその最低限のコードが出てくるだけです。システム要件やアーキテクチャのベストプラクティスは、こちらから明示しない限り反映されません。スキルは、この「明示する」部分のうち事前に決まっているもの（AWS のベストプラクティスや設計パターン）を自動的に補完する仕組みです。

ただし、ここは強調しておきたい点です。スキルが補完するのはあくまで AWS 側のベストプラクティスであり、システム固有の要件や考慮事項、実装後のバグに責任を持つのはユーザー自身です。スキルがあるからといって、エージェントに丸投げして良いわけではありません。エージェントとのラリーで要件を伝えること、生成されたコードを確認すること、これらは引き続き必要です。

スキル = エージェント向けの「社内Wiki」

Skills bridge the gap between what AI models know from their training data and what is needed to work effectively with AWS — Skills ドキュメント

スキルは、これらの壁を越えるために AWS サービスチームが作成・メンテナンスしている検証済みの手順書です。人間の世界で言えば「社内Wiki」や「チームのベストプラクティス集」に相当します。新人エンジニアが入社したとき、「まずこの Wiki を読んで」と渡すあれです。エージェントにとってのスキルも同じ役割を果たします。

スキルの構造

Agent Skills 仕様では、スキルは SKILL.md を必須とし、オプションで scripts/、references/、assets/ ディレクトリを持つと定められています。

実際に AWS MCP Server の retrieve_skill ツールを使って aws-serverless スキルを取得し、構造を確認してみました。retrieve_skill はスキルそのものではなく、AWS MCP Server が提供するツールの1つで、指定したスキルの内容をサーバーから取得してエージェントのコンテキストに読み込む機能です。

aws-serverless/
├── SKILL.md                # メインの手順書（エージェントが最初に読む）
├── references/
│   ├── architecture.md     # パターン選定、リファレンスアーキテクチャ
│   ├── lambda.md           # ランタイム、メモリ、コールドスタート、SnapStart
│   ├── api-gateway.md      # REST vs HTTP API、認証、スロットリング
│   ├── event-sources.md    # SQS、DDB Streams、SNS、S3 トリガー
│   ├── orchestration.md    # Step Functions、EventBridge
│   ├── concurrency.md      # Reserved vs Provisioned、スケーリング
│   ├── deployment.md       # SAM/CDK リソースタイプ
│   ├── production.md       # 本番チェックリスト、アンチパターン
│   └── troubleshooting.md  # エラー → 原因 → 修正
└── assets/
    └── powertools-handler.py  # Powertools テンプレート
  • SKILL.md がメインのガイドです。タスクの手順、呼ぶべき API、避けるべきミス、検証方法が書かれています。大文字なのは README.md や LICENSE と同じ OSS の慣習で、Agent Skills 仕様でエントリーポイントのファイル名として定められています
  • references/ 配下には、必要に応じて参照する詳細ガイドが入っています。エージェントはタスクに応じて必要なファイルだけを追加ロードします
  • assets/ にはテンプレートコードが入っています
  • 1スキルあたり数千トークン程度で、ドキュメント全文を読み込むより圧倒的に軽量です

ローカルにインストールした場合、これらはプロジェクト直下の .agents/skills/ に配置されます（Agent Skills 仕様に準拠）。

GitHub の公式ドキュメントによると、スキルの配置には2つのスコープがあります。

  • Project scope（リポジトリ内の .agents/skills/）: リポジトリに commit して管理。スキルの自動参照やバージョン固定が必要な場合に使います
  • User scope（ホームディレクトリの ~/.agents/skills/）: 個人用。全プロジェクトで使えます

AWS のスキルは MCP Server 経由で誰でもアクセスできるため、チームで利用する場合は各メンバーが MCP Server に接続していれば同じスキルを参照できます。ローカルに commit する必要があるのは、スキルの自動参照を確実にしたい場合やバージョンを固定したい場合です。なお、ローカル配置による共有は Agent Skills 仕様と GitHub のドキュメントに基づくもので、AWS が公式に推奨しているわけではありません。

隠しディレクトリ（ドットファイル）なので、エクスプローラーやターミナルで ls しただけでは見えませんが、ls -a で確認できます。ランタイム検出の場合はローカルにファイルは存在せず、AWS MCP Server から動的に取得されます。

# ローカルインストール時の配置例
my-project/
└── .agents/
    └── skills/
        ├── aws-serverless/
        │   └── SKILL.md
        ├── aws-cdk/
        │   └── SKILL.md
        └── ...

スキルの種類

Skills ドキュメントおよび製品ページによると、スキルは大きく4種類あります。

種類 役割 具体例
サービス決定ガイド (Service decision guides) 「何を使うべきか」を判断する DB選定（DynamoDB vs Aurora vs DSQL）
ステップバイステップ手順 (Step-by-step procedures) 「どう作るか」を導く S3 Tables作成、Glue ETLパイプライン
トラブルシューティングガイド (Troubleshooting guides) 「壊れたときどうするか」を教える CloudFormationデプロイ失敗の診断
SDK使用ガイド (SDK usage guides) 「言語ごとのハマりどころ」を防ぐ DynamoDBマーシャリング（JS）

スキルの3つの入手方法

Skills ドキュメントでは、スキルをエージェントに届ける方法として以下の3つが紹介されています。

  • Bundled with a plugin — Each plugin includes a curated set of skills that are available to the agent immediately after installation.
  • Installed locally — You can download individual skills from the Agent Toolkit for AWS repository on GitHub and add them to your agent's skills directory.
  • Discovered at runtime via the AWS MCP Server — Agents can search for and retrieve skills on demand through the AWS MCP Server, without any local installation.

1. プラグインにバンドル（一番手軽）

プラグインをインストールすると、そのドメインに必要なスキルがローカルに配置されます。ネットワーク呼び出し不要で即座に参照できるので、レスポンスが速いです。

2. ローカルインストール

GitHub からスキルをダウンロードしてプロジェクトに配置します。スキルの自動参照を確実にしたい場合や、バージョンを固定したい場合に使います。

npx skills add aws/agent-toolkit-for-aws/skills

3. ランタイム検出（何もインストールしなくてOK）

AWS MCP Server に接続さえしていれば、エージェントが必要に応じてスキルを動的に取得します。インストール不要で始められますが、取得のたびにネットワーク呼び出しが発生するぶん少しだけ遅くなります。Kiro や Cursor などプラグイン非対応のクライアントでも、MCP Server に接続していればこの方法でスキルを利用できます。

スキルの使われ方

エージェントがスキルを使う流れは、入手方法によって異なります。

ローカルにスキルがある場合（プラグイン or ローカルインストール）：

sequenceDiagram
    participant User as ユーザー
    participant Agent as エージェント
    participant Local as ローカルスキル

    User->>Agent: 「サーバーレスAPIをCDKで作って」
    Agent->>Local: ローカルのスキルを参照
    Local-->>Agent: ベストプラクティス手順
    Agent->>Agent: スキルを参考にコードを生成
    Agent->>User: CDKコードを生成

ローカルにスキルがあるので、ネットワーク呼び出しなしで即座に参照できます。

ローカルにスキルがない場合（ランタイム検出）：

sequenceDiagram
    participant User as ユーザー
    participant Agent as エージェント
    participant MCP as AWS MCP Server

    User->>Agent: 「サーバーレスAPIをCDKで作って」
    Agent->>MCP: スキルを検索
    MCP-->>Agent: aws-serverless スキルが見つかった
    Agent->>MCP: スキルを取得
    MCP-->>Agent: ベストプラクティス手順を返却
    Agent->>Agent: スキルを参考にコードを生成
    Agent->>User: CDKコードを生成
    Note over Agent: 完了後、スキルをコンテキストから解放

MCP Server に検索・取得のリクエストを送るため、数秒のオーバーヘッドがあります。ただしインストール不要で使えるのがメリットです。

必要なスキルだけを必要なときに読み込む（プログレッシブディスクロージャー）

Agent Skills 仕様では、スキルの読み込み方を プログレッシブディスクロージャー（段階的開示）と呼んでいます。必要な情報を必要なタイミングで段階的に読み込む設計のことです。

Agents load skills progressively, pulling in more detail only as a task calls for it. — Agent Skills 仕様

具体的には以下の3段階で読み込まれます（ローカルにスキルがある場合）。

  1. メタデータ（約100トークン）: スキルの名前と説明だけを最初に読み込む。全スキル分
  2. 本体（5000トークン以下推奨）: タスクに関連するスキルが見つかったら SKILL.md を読み込む
  3. 参照ファイル（必要に応じて）: references/ や assets/ のファイルは、さらに詳細が必要なときだけ読み込む

ランタイム検出の場合は流れが異なります。

  1. 検索: エージェントが search_documentation で関連スキルを探す
  2. 取得: 見つかったら retrieve_skill でスキル本体を取得する
  3. 参照ファイル（必要に応じて）: retrieve_skill に参照ファイルのパスを指定して追加取得する

ローカルの場合はメタデータが事前に読み込まれているので、エージェントは「どのスキルが使えるか」を最初から把握しています。ランタイム検出の場合はその事前把握がないため、エージェントが「スキルを探しに行く」判断をするかどうかはタスクの内容次第です。

全スキル（40以上）を常にロードしていたら、コンテキストウィンドウ（エージェントが一度に扱える情報量）がパンクします。そうではなく、今のタスクに必要なスキルだけをその場で取得し、終わったら解放します。図書館で必要な本だけ借りて、読み終わったら返すイメージです。

コンテキストウィンドウの消費が少ないということは、トークンコスト（AI の利用料金）の節約にも直結します。AWS 公式も「fewer tokens」をスキルのメリットとして挙げています。

ローカル vs ランタイム検出、どちらを使うべきか（筆者の所感）

観点 ローカル（プラグイン / インストール） ランタイム検出（MCP Server 経由）
速度 速い（ネットワーク不要） 数秒のオーバーヘッドあり
セットアップ インストールが必要 MCP Server 接続だけでOK
常に最新か 手動更新 or クライアント更新時 常に最新
オフライン利用 可能 不可
トークンコスト 同じ（どちらも必要なスキルだけロード） 同じ

おすすめの使い分けとしては、Claude Code や Codex を使っているならプラグインを入れるのが一番手軽です。スキルが自動参照されるので、指示しなくてもベストプラクティスが反映されます。

Kiro や Cursor などプラグイン非対応のクライアントなら、まずはランタイム検出で始めるのが良いでしょう。MCP Server に接続するだけで使えます。ただしランタイム検出では、明示的に指示しないとスキルが使われないケースがあるため、「retrieve_skill を使って」と伝える習慣をつけると効果的です（後述の検証で確認しています）。

チームで開発品質を統一したい場合は、全員が同じスキルにアクセスできる状態を作ることが重要です。Claude Code や Codex を使っているチームなら、全員がプラグインをインストールすることでスキルが自動参照されます。Kiro や Cursor などプラグイン非対応のクライアントを使っているチームなら、各メンバーが MCP Server に接続していれば同じスキルにアクセスできます。スキルの自動参照を確実にしたい場合は、ローカルインストール（.agents/skills/ に配置）も選択肢です。

プラグインとは（Claude Code / Codex 向け）

MCP Server とスキルのワンインストールセット

前述の通り、プラグインは AWS MCP Server の接続設定とエージェントスキルの両方をワンインストールで提供するパッケージです。

個別に「MCP Server を設定して、スキルをダウンロードして、パスを通して…」とやる必要がなく、1コマンドで全部揃います。

3つのプラグイン

  • aws-core（全AWS開発者向け）

    • サービス選定、IaC（CDK/CFn）、サーバーレス、コンテナ、ストレージ、オブザーバビリティ

  • aws-agents（AIエージェント開発者向け）

    • API Gateway と Bedrock AgentCore を使った AI エージェント構築

  • aws-data-analytics（データエンジニア向け）

    • S3 Tables、Glue、Athena

まずは aws-core を入れておけば大半のユースケースはカバーできます。専門的な作業をするなら、追加で aws-agents や aws-data-analytics を足す形です。

プラグインの中身と共有方法

Plugins ドキュメントによると、各プラグインには以下が含まれます。

plugin/
├── .claude-plugin/          # Claude Code の場合（Codex は .codex-plugin/）
│   └── plugin.json          # メタデータ（名前、バージョン等）
├── .mcp.json                # AWS MCP Server の接続設定
└── skills/
    ├── aws-serverless/
    ├── aws-cdk/
    ├── aws-containers/
    └── ...

プラグインはクライアントのプラグインシステムが管理する場所にインストールされるため、ユーザーが配置先を意識する必要はありません。

チームでの共有方法はクライアントによって異なります。

Claude Code の場合:

Claude Code のプラグインドキュメントでは、チームでの共有方法について以下のように説明されています。

Use plugins when: You want to share functionality with your team or community You need the same skills/agents across multiple projects

（プラグインを使うべき場面: チームやコミュニティと機能を共有したいとき、複数プロジェクトで同じスキルやエージェントを使いたいとき）

チームでプラグインを共有するには marketplace（プラグインのカタログを定義した Git リポジトリ）を作成し、メンバーが /plugin marketplace add で追加する形になります。プライベートリポジトリでの運用も可能です。詳細は Claude Code の marketplace ドキュメントを参照してください。

Standalone (.claude/ directory): Personal workflows, project-specific customizations, quick experiments Plugins: Sharing with teammates, distributing to community, versioned releases, reusable across projects

（スタンドアロン設定: 個人のワークフロー、プロジェクト固有のカスタマイズ、ちょっとした実験向け） （プラグイン: チームメイトとの共有、コミュニティへの配布、バージョン管理されたリリース、プロジェクト横断での再利用向け）

Codex の場合:

Claude Code と同様にプラグイン機能を持っており、codex plugin marketplace add で marketplace を追加できます。

Kiro / Cursor など（プラグイン非対応）の場合:

プラグイン機能がないため、MCP Server の設定は各メンバーが手動で行う必要があります。スキルについてはランタイム検出（MCP Server 経由の動的取得）でも利用できるので、まずはそれで始めるのが手軽です。ただしランタイム検出ではスキルが自動参照されないケースがあるため（後述の検証で確認しています）、確実にスキルを使いたい場合はローカルインストール（.agents/skills/ に配置してリポジトリに commit）を検討してください。

インストール方法

クイックスタートに記載されている手順です。

Claude Code:

/plugin marketplace add aws/agent-toolkit-for-aws
/plugin install aws-core@agent-toolkit-for-aws
/reload-plugins

これだけで MCP Server の接続設定とスキルが全部入ります。claude mcp add-json による手動設定は不要です。

Codex:

codex plugin marketplace add aws/agent-toolkit-for-aws

Kiro:

MCP Server は ~/.kiro/settings/mcp.json で設定（前回記事参照）します。これだけでランタイム検出によるスキル利用が可能です。プラグイン機能はないため、スキルの自動参照はされません。

ローカルにスキルをインストールしたい場合は、別途以下を実行します。

npx skills add aws/agent-toolkit-for-aws/skills

デフォルトではカレントディレクトリ（プロジェクト）の .agents/skills/ に配置されます。-g オプションを付けるとグローバル（~/.agents/skills/）にインストールされ、全プロジェクトで共通して使えるようになります。

ターミナルにて。

【検証】スキルの効果を試してみる

検証の前に：エージェントはスキルを使わないこともある

検証を始める前に、1つ重要な発見がありました。

「DynamoDB をバックエンドにした REST API を CDK で作って」と頼んだところ、エージェントはスキルを参照せずに自分の知識だけで実装しました。理由を聞くと「CDK + DynamoDB + API Gateway は定番パターンなので、手持ちの知識で十分と判断した」とのこと。

つまりランタイム検出は「エージェントが必要だと判断したら取りに行く」仕組みなので、定番パターンではスキルが使われないことがあります。スキルの真価が発揮されるのは、複雑な構成やセキュリティ要件がある場合、あるいは新しいサービスを使う場合です。

そこで検証では、明示的に「スキルを使って / 使わないで」と指示して比較しました。なお、実際にリソースを作成するとコストがかかるため、今回はコード生成のみ（デプロイなし）で品質を比較します。

ランタイム検出で試す（Kiro）

Kiro では AWS MCP Server 経由のランタイム検出でスキルを取得します。スキルなしの場合は「あなたの知識だけで答えて」、スキルありの場合は「AWS MCP Server の retrieve_skill を使ってスキルを使用して調べて」と指示しました。

検証1: Lambda コールドスタート対策

お題: 「Lambda のコールドスタートを減らしたい。どんな方法がある？」

使用されたスキル: aws-serverless（コールドスタートに関する情報を持っていると判断して取得）

スキルなし（retrieve_skill を使わないよう指示）

Lambda のコールドスタートを減らしたい。どんな方法がある？

スキルあり（retrieve_skill を使うよう指示）

Lambda のコールドスタートを減らしたい。どんな方法がある？AWS MCP Server の retrieve_skill 使ってスキルを使用して調べて。

比較結果
観点 スキルなし スキルあり
SnapStart の対応ランタイム Java のみと記載 Java 11+、Python 3.12+、.NET 8+ と正確
SnapStart の制約 言及なし 5つの制約を具体的に列挙（Provisioned Concurrency と併用不可、EFS 不可、等）
CDK コード例 なし Python と TypeScript の2例あり
Graviton の効果 「若干速い」程度 「最大34%の価格性能比改善」と具体的な数値
パッケージ最小化の具体策 一般論 uv でのインストール例まで記載
Init フェーズ最適化 「SDK の遅延読み込み」と一言 コード例付きで OK/NG パターンを提示
Power Tuning ツール 言及なし 言及あり
戦略の選び方 2ステップの推奨 シナリオ別の表 + 3ステップの推奨
所感

特に大きかったのは SnapStart の対応ランタイムの正確さ です。スキルなしでは「Java 向け」としか書かれていませんでしたが、実際には Python 3.12+ と .NET 8+ にも対応済みです。SnapStart は 2022年11月に Java 向けとして登場し、2024年11月に Python と .NET にも拡大、さらに 2025年6月に23リージョンに追加展開されています。スキルなしの回答はこれらの拡大を反映できておらず、スキルが最新知識を補完している好例です。

また、スキルありの方は CDK のコード例や具体的な数値（34%改善、512MB 制限等）が含まれており、そのまま実装に使える実用性の高い回答になっていました。

一方で、結論（推奨アプローチ）自体は大きく変わりませんでした。「パッケージ最小化 → SnapStart → Provisioned Concurrency」という優先順位はどちらも同じです。スキルの効果は「結論を変える」というよりも「回答の正確さと具体性を上げる」ところに出ると感じました。

検証2: CloudFormation トラブルシューティング

お題: 「CloudFormation スタックが UPDATE_ROLLBACK_FAILED になった。どうすればいい？」

使用されたスキル: aws-cloudformation（直接該当するスキルが見つかり取得）

スキルなし：

CloudFormation スタックが UPDATE_ROLLBACK_FAILED になった。どうすればいい？あなたの知識だけで答えて。

スキルあり：

CloudFormation スタックが UPDATE_ROLLBACK_FAILED になった。どうすればいい？AWS MCP Server の retrieve_skill を使ってスキルを使用して調べて。

比較結果
観点 スキルなし スキルあり
失敗原因の確認コマンド describe-stack-events describe-events --filters FailedEvents=true（より適切）
よくある失敗パターン 4つの原因を箇条書き 7つのエラーメッセージと原因の対応表
CloudTrail での追加調査 なし 具体的なコマンドとコンソールリンク付き
修正の分類 なし テンプレートレベル vs 環境レベルの2分類
ネストスタックへの言及 なし 子スタックの再帰的確認を推奨
復旧後のアクション なし cfn-lint、cfn-guard、Change Set、ドリフト検出
注意点の深さ 3点 5点（一方通行の操作、ドリフト状態等）
所感

この検証ではスキルの効果が顕著に出ました。スキルなしの回答は「continue-update-rollback を実行する」という結論自体は正しいものの、そこに至るまでの診断フローが薄いです。

スキルありの方は、失敗パターンをエラーメッセージ別に分類し、CloudTrail での追加調査手順を示し、修正を「テンプレートレベル」と「環境レベル」に分類するなど、実務で使える体系的な診断フローになっていました。復旧後に cfn-lint や cfn-guard で検証する、ドリフト検出を実行するといった「次のアクション」まで含まれている点も実用的です。

トラブルシューティングのように「手順が決まっている」タスクほど、スキルの効果が大きいと言えそうです。

検証3: DynamoDB テーブル設計

お題: 「ECサイトの注文履歴をDynamoDBで設計したい。ユーザーIDで検索、注文日で範囲検索、注文ステータスでフィルタしたい。テーブル設計を教えて。」

使用されたスキル: スキルを取得したが「テーブル設計向けではない」と判断。ドキュメント検索（search_documentation）の知識をベースに回答

スキルなし：

ECサイトの注文履歴をDynamoDBで設計したい。ユーザーIDで検索、注文日で範囲検索、注文ステータスでフィルタしたい。テーブル設計を教えて。あなたの知識だけで答えて。

スキルあり：

ECサイトの注文履歴をDynamoDBで設計したい。ユーザーIDで検索、注文日で範囲検索、注文ステータスでフィルタしたい。テーブル設計を教えて。AWS MCP Server の retrieve_skill を使ってスキルを使用して調べて。

比較結果
観点 スキルなし スキルあり
CloudFormation テンプレート例 なし YAML テンプレート付き（GSI含む）
課金モデルの言及 なし PAY_PER_REQUEST を推奨（理由付き）
PointInTimeRecovery なし 有効化済み
設計判断の表 テキストで4点 表形式で5点（理由列付き）
参考リンク なし AWS 公式ブログ・ドキュメント4件
ステータス検索の方法 FilterExpression → 頻繁なら GSI 方法A/B として明確に分類し、メリット・デメリットを記載
注意事項 GSI のトレードオフに軽く言及 パーティションサイズ、RCU、GSI 書き込みコストの3点
所感

テーブル設計の核（PK=userId、SK=orderDate#orderId、GSI=userId#status+orderDate）は両方とも同じでした。DynamoDB のキー設計パターンとしては定番なので、スキルなしでも正しい結論に到達しています。

差が出たのは「そのまま実装に使えるか」という点です。スキルありの方は CloudFormation テンプレートがそのまま付いてきますし、課金モデル（PAY_PER_REQUEST）や PointInTimeRecovery の設定も含まれています。スキルなしの回答をそのまま実装しようとすると、これらを自分で調べて追加する必要があります。

検証4: S3 Tables の作成（新しいサービス）

お題: 「S3 Tables を使ってデータレイクのテーブルを作成したい。手順を教えて。」

使用されたスキル: creating-data-lake-table。S3 Tables は 2024年12月に GA になった比較的新しいサービスのため、スキル/ドキュメント検索の効果が顕著に出ました。

スキルなし：

S3 Tables を使ってデータレイクのテーブルを作成したい。手順を教えて。あなたの知識だけで答えて。

スキルあり：

S3 Tables を使ってデータレイクのテーブルを作成したい。手順を教えて。AWS MCP Server の retrieve_skill を使ってスキルを使用して調べて。

比較結果
観点 スキルなし スキルあり
Glue Data Catalog 統合 「カタログとして登録」と一言 glue create-catalog の具体的なコマンドとJSON付き
IAM 権限 「s3tables:* を許可する必要がある」 バケットポリシー側とIAMポリシー側を分けて具体的なアクション名を列挙
テーブル作成時のスキーマ定義 --format ICEBERG のみ --metadata でスキーマとパーティション定義まで含む
パーティション設計 言及なし partitionSpec で月単位パーティションの例
作成確認手順 なし get-table と Athena からの確認コマンド
よくあるエラー なし 2つのエラーパターンと対処法
s3:* と s3tables:* の違い 軽く言及 エラー例として明示（ハマりポイント）
LOCATION 句の注意 なし 「不要」と明記 + エラー時の対処
所感

4つの検証の中で最も差が大きかったのがこの S3 Tables です。スキルなしの方も基本的な手順（テーブルバケット作成 → ネームスペース作成 → テーブル作成）は正しいのですが、スキルありは「実際にやったらハマるポイント」まで網羅しています。

特に以下の3点は、知らないと確実にハマります。

  1. s3:* ではなく s3tables:*: 通常の S3 の IAM アクションとは別の名前空間を使う
  2. LOCATION 句は不要: 通常の Iceberg テーブルと違い、S3 Tables がストレージを自動管理する
  3. Glue Data Catalog 統合: s3tablescatalog を事前に作成しないと Athena からクエリできない

新しいサービスほど「モデルの知識だけでは足りない」ケースが多く、スキルやドキュメント検索の効果が大きいと言えます。

ランタイム検出での検証まとめ

なお、各検証で実際に使用されたスキルは以下の通りです。

検証 使用されたスキル 備考
Lambda コールドスタート aws-serverless コールドスタートに関する情報を持っていると判断して取得
CloudFormation トラブルシューティング aws-cloudformation 直接該当するスキルが見つかり取得
DynamoDB テーブル設計 スキルを取得したが「テーブル設計向けではない」と判断 ドキュメント検索（search_documentation）の知識をベースに回答
S3 Tables 作成 creating-data-lake-table 新しいサービスのためスキル/ドキュメント検索の効果が顕著
  • 結論自体は大きく変わらない: どの検証でも、スキルなしの回答が「間違い」というわけではありませんでした。方向性は正しい
  • 正確さと具体性が上がる: スキルありの方が最新情報（SnapStart の対応ランタイム等）を反映し、具体的な数値やコード例が含まれる
  • 実装までの距離が縮まる: CloudFormation テンプレート、CDK コード例、具体的なコマンドなど、そのまま使える成果物が出てくる
  • トラブルシューティングで最も差が出る: 手順が体系化されているタスクほどスキルの効果が大きい
  • スキルが該当しない場合はドキュメント検索が補完する: DynamoDB のテーブル設計のように、ぴったりのスキルがない場合でも、ドキュメント検索によって品質が上がるケースがある
  • 定番パターンでは差が小さい: DynamoDB のキー設計のように広く知られたパターンでは、結論に差が出にくい

プラグインで試す（Claude Code）

Claude Code に aws-core プラグインをインストールした状態で、同じお題を試しました。

検証1: Lambda コールドスタート対策

お題: 「Lambda のコールドスタートを減らしたい。どんな方法がある？」

使用されたスキル: aws-serverless

ランタイム検出のときと違い、「retrieve_skill を使って」とは指示せず、普通に質問しただけです。

「skill 使わないで答えてみて」

結果

プラグインの場合、指示しなくてもスキルが自動で参照されました。ログに Skill(aws-core:aws-serverless) Successfully loaded skill と表示され、エージェントが自発的にスキルを読み込んでいます。

これはランタイム検出との大きな違いです。Kiro でのランタイム検出では「retrieve_skill を使って」と明示的に指示しないとスキルが使われませんでしたが、プラグイン（ローカル）ではメタデータが事前に読み込まれているため、エージェントが「このタスクにはこのスキルが使える」と自発的に判断してくれます。

一方で興味深かったのは、「skill 使わないで答えて」と指示した場合でも SnapStart の対応ランタイム（Java 11+、Python 3.12+、.NET 8+）が正しく回答されたことです。Kiro でのスキルなし検証では「Java のみ」と回答されていたので、これはモデルやクライアントの違いによるものと考えられます。

ランタイム検出との比較
観点 ランタイム検出（Kiro） プラグイン（Claude Code）
スキルの自動参照 明示的に指示が必要 指示なしで自動参照
スキルなし時の SnapStart 情報 Java のみ（不正確） Java/Python/.NET（正確）
セットアップ MCP Server 接続のみ プラグインインストール

プラグインの最大のメリットは「指示しなくてもスキルが使われる」点です。ランタイム検出だとエージェントが「スキルを探しに行く」判断をしないケースがありましたが、プラグインならその心配がありません。

ユースケース別おすすめ構成（筆者の所感）

「結局どう使えばいいの？」という方向けに、ユースケース別のおすすめ構成をまとめます。

ケース1: 個人開発者がサクッと試したい

構成: Claude Code / Codex ならプラグイン、Kiro / Cursor なら AWS MCP Server のみ（ランタイム検出）

一番シンプルな構成です。Claude Code / Codex ならプラグインを1コマンドで入れるだけ。Kiro / Cursor なら MCP Server に接続するだけで、スキルは必要なときに動的に取得されます。

ケース2: チームで開発品質を統一したい

構成: Claude Code / Codex なら aws-core プラグイン + チーム共通の IAM ポリシー。Kiro / Cursor なら MCP Server + IAM ポリシー。

Claude Code / Codex ならプラグインをインストールするとスキルが自動参照されます（検証で確認済み）。Kiro / Cursor の場合は各メンバーが MCP Server に接続していれば同じスキルにアクセスできます。

どちらの場合も、IAM コンテキストキーでエージェントの操作範囲を制限すれば、「エージェントが本番環境のリソースを消してしまった」という事故を防げます。たとえば以下のポリシーを付与すると、エージェント経由での削除系操作をすべて拒否できます。

{
    "Effect": "Deny",
    "Action": [
        "s3:DeleteBucket",
        "s3:DeleteObject",
        "ec2:TerminateInstances",
        "rds:DeleteDBInstance"
    ],
    "Resource": "*",
    "Condition": {
        "Bool": {
            "aws:ViaAWSMCPService": "true"
        }
    }
}

人間が直接コンソールや CLI で操作する場合はこの条件に該当しないので、通常業務には影響しません。

ケース3: データ基盤を構築したい

構成: Claude Code / Codex なら aws-core + aws-data-analytics プラグイン。Kiro / Cursor なら MCP Server（ランタイム検出でデータ系スキルにアクセス可能）。

S3 Tables、Glue、Athena のベストプラクティスをエージェントが参照してくれます。ETL パイプラインの設計パターンや、パーティション戦略のガイダンスが含まれています。

ケース4: AI エージェントを開発したい

構成: Claude Code / Codex なら aws-core + aws-agents プラグイン。Kiro / Cursor なら MCP Server（ランタイム検出でエージェント系スキルにアクセス可能）。

Bedrock AgentCore や API Gateway を使ったエージェント構築のスキルが利用できます。ツール定義やオーケストレーションのパターンなど、エージェント開発特有のノウハウが含まれています。

ケース5: エンタープライズでガバナンスを効かせたい

構成: プラグインまたは MCP Server + SCP + IAM 条件キー + CloudTrail

エージェント経由の操作を IAM 条件キー（aws:ViaAWSMCPService）で制限し、CloudTrail で全操作を監査します。SCP で Organization 全体にポリシーを適用すれば、「エージェントは使わせたいけど野放しにはしたくない」という要件に応えられます。

AWS MCP Server のセキュリティドキュメントでは、MCP Server 経由のリクエストに適用されるポリシータイプとして SCP（Service Control Policies）が明記されています。MCP Server は既存の IAM 認可の仕組みをそのまま使うため、条件キーを SCP に書けば Organization 全体でエージェントの操作を制限できます。

制約事項・注意点

AWS MCP Server の制約（前回記事の再掲）

Quotas ドキュメントおよびセットアップガイドより。

制約 値 備考
エンドポイント us-east-1, eu-central-1 のみ 東京リージョンなし。操作対象は任意リージョン指定可
スロットリング 3 req/s/アカウント/リージョン 調整不可。チーム利用時は注意
同時接続数 27/アカウント/リージョン 調整不可
FIPS 非対応 規制要件がある環境では注意

エンドポイントが東京リージョンにないのは気になるところですが、エンドポイントのリージョンと操作対象のリージョンは別です。たとえば us-east-1 のエンドポイントに接続しつつ、ap-northeast-1 のリソースを操作することは可能です。実用上はレイテンシが少し増える程度で、大きな問題にはなりません。

スロットリングの 3 req/s は、個人利用なら十分ですが、同一アカウントで複数の開発者が同時に使う場合はボトルネックになる可能性があります。チームで利用する場合は、開発者ごとに異なる AWS アカウント（またはプロファイル）を使うことで回避できます。

同時接続数 27 も同様で、個人なら問題になりませんが、大規模チームでは上限に達する可能性があります。こちらは調整不可なので、事前に把握しておく必要があります。

スキル・プラグイン固有の注意点

  • プラグインが使えるクライアントは限定的

    • 現時点で対応しているのは Claude Code と Codex のみです。Kiro や Cursor では手動設定が必要です。（Plugins ドキュメント）

  • スキルはまだ発展途上

    • GA 時点で 40 以上のスキルがリリースされていますが、データベース、ネットワーキング、IAM のスキルは「今後数週間で追加予定」とされています。（AWS News Blog）

  • スキルの更新タイミングに注意

    • プラグイン経由でインストールした場合は、クライアントが marketplace のデータを更新するタイミングで自動的に最新版に更新されます（Plugins ドキュメント: "Plugins update automatically when your agent client refreshes its marketplace data"）。一方、npx skills add でローカルインストールした場合は自動更新されないため、新しいスキルが追加されたときは手動で再実行する必要があります。

  • ランタイム検出は少し遅い（筆者の所感）

    • ローカルにスキルがない場合、retrieve_skill のたびにネットワーク呼び出しが発生します。体感で数秒の差ですが、頻繁にスキルを参照するタスクでは気になるかもしれません。

AWS Labs との関係

「AWS Labs の MCP サーバーはどうなるの？」という疑問に答えておきます。

AWS News Blog では以下のように説明されています。

Agent Toolkit for AWS is the successor to the MCP servers, plugins, and skills available on AWS Labs. MCP servers, skills, and plugins available on AWS Labs will continue to be available, and over time the best of AWS Labs will be migrated into Agent Toolkit for AWS.

（Agent Toolkit for AWS は AWS Labs で提供されていた MCP サーバー、プラグイン、スキルの後継です。AWS Labs のツールは引き続き利用可能で、時間の経過とともにベストなものが Agent Toolkit に統合されていきます。）

新規で始めるなら Agent Toolkit for AWS を使うのが正解です。既存の Labs サーバーを使っている場合は急いで移行する必要はありませんが、徐々に Agent Toolkit に寄せていくのが良いでしょう。

まとめ

Agent Toolkit for AWS の全体像を、前回記事と合わせて整理します。

前回の記事では AWS MCP Server を紹介しました。これは AWS への直接アクセスを提供するもので、API 実行やドキュメント検索など「問いに対する答え」を返す役割です。

今回の記事ではスキルとプラグインを紹介しました。スキルはその答えの品質を上げるもので、「こう作るのが正解」「このミスを避けろ」という周辺知識を補完する役割です。プラグインは Claude Code / Codex 向けに、AWS MCP Server とエージェントスキルの両方をワンインストールで提供するセットです。

検証を通じてわかったのは以下の点です。

  • スキルを使うと、回答の正確さと具体性が上がる。特にトラブルシューティングや新しいサービスで効果が大きい
  • Claude Code / Codex ならプラグインを入れるだけでスキルが自動参照される
  • Kiro / Cursor なら MCP Server に接続するだけでランタイム検出が使える。ただし「retrieve_skill を使って」と指示する習慣をつけると効果的
  • スキルが補完するのは AWS のベストプラクティスであり、システム固有の要件やバグの責任はユーザーにある

追加コストなしで導入できる点、セットアップが簡単な点を考えると、試してみる価値はあると感じています。今後スキルの種類が増えていけば、さらに活用の幅が広がるはずです。

前回の記事と合わせて読んでいただくと、Agent Toolkit for AWS の全体像が掴めると思います。

参考リンク

余談

たまにはのんびり山を歩きたいような気持ちです。（トレイルランニングばっかりしています。）

山本 哲也 (記事一覧)

多分インフラエンジニアです。データ分析に興味あります。

山を走るのが趣味です。今年は 100 マイルレース完走します。