Amazon Web Services ブログ

Kiro powers は Agent Plugins のサポートを開始します

本記事は 2026 年 8 月 7 日に公開された Clare Liguori、Dan Kiuna による “Kiro powers now support Agent Plugins” を翻訳したものです。

あなたは良いものを作りました。チームが実際にデプロイする手順を落とし込んだスキルと、社内サービスと通信する MCP サーバーです。ちゃんと動きます。そこで、チームが使っているクライアント向けにパッケージ化し、次に隣のチームが使っているクライアント向けに再びパッケージ化し、さらにオープンソースのコントリビューターが好むクライアント向けにもう一度パッケージ化します。同じ知識、同じツールなのに、3 組のドキュメントと、同期を取り続けなければならない 3 つのパッケージができあがります。

拡張機能の作者は、エージェントが拡張機能を受け入れるようになって以来、この「税金」を払い続けてきました。開発者はそのもう半分を負担しています。まさに必要としていたプラグインを見つけたのに、いま使っているツールでは読み込めない、というものです。

Kiro powers を発表したとき、私たちが訴えたのは、エージェントは最初からすべてを知っている必要はない、ということでした。MCP サーバーを、それを正しく使うためのフレームワークの専門知識とバンドルし、関連するときにだけ読み込むことで、ベースラインのコンテキストコストを最小限に保てます。

このモデルは機能します。制約となっていたのは供給でした。power は Kiro で動かすために Kiro 向けに作らなければならなかったからです。

2026 年 8 月 7 日、Kiro powers は、エージェント拡張をパッケージ化するためのオープンかつベンダーニュートラルな仕様である Agent Plugins 1.0.0 のサポートを順次展開します。AWS は、Cursor、Microsoft、OpenAI、Vercel と並ぶ Agent Plugins Technical Steering Committee の設立メンバーです。実際のところ、これは、この標準に準拠して公開されたプラグインが、Kiro で power としてインストールできることを意味します。

Agent Plugins とは

Agent Plugins は、AI エージェントを拡張する再利用可能なコンポーネントについて、相互運用性の最低限の土台を定義する、オープンかつベンダーニュートラルな仕様 (v1.0) です。Agent Skills と MCP サーバー のパッケージ化の方法を標準化し、互換性のある任意のクライアントが一貫した形でそれらを検出・読み込みできるようにします。

my-plugin/ 
├── plugin.json          # Identifies the plugin + the Agent Plugins version it targets
├── skills/              # Agent Skills in the standard format 
│   └── summarize/ 
│       ├── SKILL.md
│       ├── scripts/ 
│       └── references/ 
└── mcp.json             # stdio, Streamable HTTP, or HTTP+SSE MCP servers
my-power/ 
├── POWER.md             # Identifies the power and contains onboarding steps
├── steering/            # Agent steering in the standard format
│   └── summarize.md    
└── mcp.json             # stdio, Streamable HTTP, or HTTP+SSE MCP servers

Agent Plugin は本質的に、マニフェストと、固定された場所に配置されたコンポーネントを持つディレクトリです。

なぜ標準で協働するのか

私たちは、このパターンが繰り返されるのを、見分けがつくほど何度も見てきました。package.json が登場する前、JavaScript ライブラリのインストールとは、手作業でスクリプトをダウンロードし、コピー&ペーストで依存関係を管理することを意味していました。フォーマットが 1 つに収束すると、npm、yarn、pnpm のいずれもが同じパッケージをインストールできるようになりました。Open Container Initiative (OCI) が登場する前、コンテナイメージは Docker の成果物でした。登場後は、同じビルドが containerd、Podman、あるいは仕様に準拠するその他のもので動作します。

エージェント拡張は、まさに同じ地点にあります。コンポーネントは優れているのに、時間が費やされているのはパッケージングの部分なのです。

Agent Plugins は、長く続く標準がたどるのと同じ道のりでここまで来ました。Vercel が最初のドラフトを公開し、その後、それぞれが独自にこの問題を解決してきた各社によるワーキンググループを招集しました。AWS、Cursor、Microsoft、OpenAI、Vercel は共同で仕様を洗練させ、1 社のロードマップがフォーマットの方向性を左右しないようにガバナンスを整備しました。Technical Steering Committee には 5 社すべてからコアメンテナーが参加しており、コントリビューションプロセスと技術的な意思決定は公開されています。power を作成する人にとって、これは実際的な保証となります。仕様が進化すれば power もそれとともに進化し、プロプライエタリな移行を待つ必要はありません。

Skills が Kiro powers の第一級の構成要素に

標準を採用することで、power が何であるかも広がります。Kiro は以前からスキルをサポートしてきましたが、それらを power の中で配布する手段はありませんでした。これまで power は、POWER.md ファイル、目的に応じてパッケージ化された任意の steering ファイル、そして mcp.json から構成されていました。Agent Plugins は、Agent Skills をネイティブなコンポーネントとして取り込みます。power は今や、skills/ 配下に 1 つ以上の構造化されたスキルを持つことができ、それぞれが独自の SKILL.md と、補助的な scripts/、references/ を備えられます。

開発者にとって、これは次のことを意味します。

  • 読むだけでなく、実行される専門知識。 スキルは、その手順とあわせて実行可能なスクリプトや参考資料をバンドルでき、それらは power の一部として実行されます。
  • 1 つの長大なファイルではなく、組み合わせ。 すべてが 1 つのファイルの中で場所を奪い合うのではなく、複数のスキルを 1 つの power にまとめ、それぞれが自分のワークフローに応じて有効化されます。
  • 関心ごとに定められた置き場所。 ツールは mcp.json に、知識は skills/ に、クライアント固有の挙動は名前空間の下に置かれます。構造が前提として決まっていれば、power の作成・読解・拡張のいずれもが容易になります。

今日から何が変わるのか

power をインストールする側にとって、カタログはもはや Kiro 向けに作られたものだけに限られません。

  • あるチームが自社の内部 API 向けに Agent Plugin を公開します。そのチームのユーザーは、Kiro 固有のパッケージングなしに、それを Kiro にインストールできます。
  • あるベンダーが、自社サービス向けのプラグインをすでに保守しています。Kiro ユーザーは、移植を待つことなくそれをインストールできます。
  • コミュニティが作成したプラグインは、最初にどこで公開されたものであっても、powers パネルの候補になります。

power を作成する側にとっては、公開されたスキーマを持つ 1 つの文書化されたフォーマットに対して書けばよく、公開したものは 1 つのクライアントではなく、互換性のあるすべてのクライアント上の開発者に届きます。

既存の power はそのまま動作します

インストール済みのものが壊れることはなく、公開済みのものが動作しなくなることもありません。従来の方法で作られた power は、これまでどおり読み込まれ続けます。ただし、Agent Plugins のレイアウトへの移行は、遅らせるよりも早めに行うことをおすすめします。新しい機能はまずそこに実装されますし、それがあなたの成果物をポータブルにするものだからです。

powers は、プラグインを取り巻く Kiro ならではの体験であり続けます。そして、その部分こそ私たちが引き続き作り込んでいるところです。キュレーション、IDE や kiro.dev からのワンクリックインストール、初回利用時の認証情報の入力プロンプト、そしてキーワード駆動の有効化です。これにより、複数の power をインストールしていても、特定のタスクで必要になったときにだけ一部が有効化されるまでは、利用にかかるコストは実質ゼロで済みます。

ビジョンは変わりません

当初の主張は今も有効です。エージェントが賢くなるのは、最初からすべてを知っているからではなく、必要なときにちょうど適切な専門知識を読み込むからです。今日変わるのは、その専門知識がどこから来られるか、という点です。エコシステムがすでに生み出しているスキルやサーバーが、今やあなたのエージェントが取り込める power になり、そのコレクションは標準が広がるのと同じ速さで増えていきます。

仕様は agent-plugins.org でご確認いただけます。最初の powers ローンチの記事を読み返し、powers パネルを開いて、すでにインストールできるものを確かめてみてください。そして、あなた自身の何かをパッケージ化し、何を作ったのかをぜひ教えてください。