はじめに
こんにちは！足立です！
この記事ではKiro Powers について、Skills との違いを中心に深堀りしていきます。
私が Kiro を使い始めたのは、Powers がまだない頃です。昨年 12 月の re:Invent で発表されたこの機能を見て、最初に気になったのは Skills との違いでした。
Skills はイメージしやすいです。Claude Code や Cursor を使っていると、「必要な文脈を段階的に読ませる仕組み」としてすぐ理解できます。一方で Powers は、何が追加で違うのかが最初は見えませんでした。
先に結論を書くと、Powers は Skills の上位互換でも下位互換でもありません。MCP の接続設定・運用ガイド・Steering をまとめて配るためのパッケージとして、明確に切り分けられています。この記事では、公開されている AWS SAM Power を読みながら、その設計意図を確認します。
検証環境
- 検証日: 2026-03-29
- OS: Ubuntu 24.04 LTS（WSL2）
- AWS CLI: 2.32.26
- SAM CLI: 1.157.1
Kiro IDE の正確なビルド番号は手元に残していません。この記事は 2026-03-29 時点の公式ドキュメント・公開リポジトリ・実機検証を基準にしています。
Powers はどこから手に入るか
Powers の入口は、大きく分けて次の4つです。
- Kiro IDE の Powers パネルから curated なものを入れる。
- kiro.dev/powers をブラウザで開き、Add to Kiro から Kiro IDE 側のインストールに進む。
- Powers パネルから Add power from GitHub で、公開 GitHub リポジトリの URL を指定する。
- Add power from Local Path で、手元のディレクトリを指定する。
手順の一次情報は Install powers にまとまっています。
IDE から入れる場合の流れは、同ドキュメントのとおりです。Powers パネルを開き、稲妻付きのゴーストのアイコンから一覧へ進み、対象の Power を選んで Install を押して確定します。ブラウザ側では kiro.dev/powers で Power を選び Install を押すと、Kiro IDE が開いて同じくインストールを完了できます。
MCP を含む Power を入れると、~/.kiro/settings/mcp.json へ自動で MCP サーバーが登録されます。
カスタム Power を GitHub やローカルから追加することも可能です。
この記事の以降では、カタログの画面操作よりも 配布パッケージの中身 を追うため、公開リポジトリ kirodotdev/powers を開いてファイルを読みます。
Power の実体は 3 つのファイル
aws-sam ディレクトリ を開くと、次の 3 つが入っています。
aws-sam/
├── POWER.md
├── mcp.json
└── steering/
└── cloudformation.md
| 層 | ファイル | 役割 |
|---|---|---|
| ワークフロー定義 | POWER.md |
エージェントに何をどう進めさせるかを決める |
| ツール接続 | mcp.json |
MCP サーバーの起動方法と登録内容を持つ |
| 常時ルール | steering/*.md |
会話の最初から載せたい制約や作法を書く |
Skill との違いはここにあります。Kiro の公式ドキュメントでも「MCP integration では Power の方が通常は適している」と案内されています。Skill は手順の再利用、Power は手順とツール接続の同梱、という切り分けです。
最初は「Power は豪華な Skill なのでは」と思っていましたが、同梱するもののセット（配布パッケージの中身） が違います。
| 比較軸 | Skills | Powers |
|---|---|---|
| 同梱できるもの | 手順・スクリプト・テンプレート | POWER.md・mcp.json・steering・hooks |
| ロード方式 | 関連時に段階的ロード（progressive loading） | Steering Always は常時ロード |
| MCP 接続 | 持てない | mcp.json でパッケージに含められる |
| 標準化 | open Agent Skills standard 準拠（他ツールと共有可） | Kiro 独自（open standard ではない） |
| 向いているケース | 再利用可能なワークフローの共有 | ツール接続 + ガイダンスの統合配布 |
| 導入方法 |
.kiro/skills/ に配置 |
Kiro IDE または kiro.dev から install (CLIでは使えない) |
steering/ に複数の .md を置くこともできます。例えば、AWS Observability Power では、log-analysis.md（ログ分析）や incident-response.md（インシデント対応）、performance-monitoring.md（性能監視）、security-auditing.md（セキュリティ監査）のように、用途ごとにファイルが分かれています。
POWER.md は指示の密度が高い
aws-sam の POWER.md は、「SAM を使う」という一文の紹介で終わりません。
sam init のあとに動かすパス、template.yaml の直し方、API 追加時に新規に作るリソースの切り方まで、作業単位で書かれています。
新規 SAM アプリを作るとき、sam_init のあとにファイル再構成まで含めて進めるよう書かれています。
Create the proper infrastructure directory: mkdir -p infrastructure/lambda
Move the generated function folder to the infrastructure directory
Update CodeUri paths in template.yaml
Rebuild the application to verify structure with the sam_build tool
（要約）適切な `infrastructure/lambda` を用意し、生成した関数フォルダをそこへ移し、`template.yaml` の CodeUri を更新し、`sam_build` で構成を検証する。
単に初期生成するだけでなく、どう直すかまで誘導しています。API 追加時のルールも同じです。
ALWAYS create a new AWS::Serverless::Function for each API or logical grouping of endpoints
NEVER modify existing Lambda functions when asked to add a new API
（要約）API または論理的なエンドポイントのまとまりごとに、新しい `AWS::Serverless::Function` を作る。新しい API の追加依頼で、既存の Lambda を変更しない。
「既存関数に雑に足すな」「API ごとに Lambda を分けろ」という設計判断まで渡しています。Lambda Powertools も例外ではありません。
ALWAYS use the Powertools for AWS Lambda library
Use Lambda Layers for Powertools, NEVER add Powertools to your dependency file
（要約）Powertools for AWS Lambda を必ず使う。Powertools は Lambda Layer で渡し、依存ファイルに直接足さない。
今回エージェントがほとんど迷わず進んだのも、こういった指示の粒度が理由だと思います。自由度が高いから動いたのではなく、迷う余地が少ないから動いた、というほうが正確です。
ただし、これらはあくまで自然言語の指示です。ALWAYS と書いてあっても構造的な強制ではなく、従う確率を上げる設計だと捉えるべきです。
Steering は「いつ読まれるか」が Skills と違う
Kiro の Steering docs を見ると、Steering は inclusion mode（ルールをいつ読ませるかの規則） を持ちます。Always・fileMatch・Manual・Auto の 4 種類です。
Kiro ではフロントマターなしの場合、Always がデフォルトとなります。例えば、cloudformation.md にはフロントマターがありません。このファイルは 毎回のやり取りに自動で読みこまれる前提になります。
中身はこういったルールが並んでいます。
ALWAYS enable encryption at rest for all data stores
ALWAYS block public access with PublicAccessBlockConfiguration
ALWAYS enable X-Ray tracing for Lambda functions
（要約）データストアは保存時暗号化を有効にする。パブリックアクセスは `PublicAccessBlockConfiguration` でブロックする。Lambda には X-Ray トレースを有効にする。
ここで Skills との差が出ます。Kiro の Skills は段階的にロードされます。まず name と description が評価され、必要だと判断されたときに全文が読み込まれます。Skill に同じ CloudFormation のガイドを書いても、毎回最初から必ず読まれるとは限りません。
この差は、強制力の差というよりロードタイミングの差です。
- Skill: 関連しそうなときに段階的に読む
- Steering（Always）: 最初から毎回読む
Always 以外は、同じドキュメントにあるとおり、毎回の先頭から読む挙動にはなりません。
-
fileMatch: パターンに合うファイルを扱うとき -
Auto:descriptionが依頼内容に合うと判断されたとき（Skills に近い） -
Manual:#steering名やスラッシュコマンドで取り込むとき
私は最初、「Power は Skill よりルールで強く縛る仕組み」だと思っていました。docs とリポジトリを読んだ後の理解は少し違います。より正確には、必要な文脈を、どのタイミングで、どの粒度で読ませるかを設計しやすい仕組みでした。
mcp.json があると、Power は Skill 単体と別物になる
aws-sam の mcp.json には、AWS SAM 用の MCP と fetch が定義されています。
{
"mcpServers": {
"awslabs.aws-serverless-mcp-server": {
"command": "uvx",
"args": [
"awslabs.aws-serverless-mcp-server@latest"
],
"disabled": false,
"autoApprove": []
},
"fetch": {
"command": "uvx",
"args": ["mcp-server-fetch"],
"env": {},
"disabled": false
}
}
}
Skill でも補助スクリプトや参照ドキュメントは持てます。ただし、MCP サーバーの設定をパッケージとして配って、自動登録まで含める体験は Power 側の強みです。
この差は地味ですが、実務では積み重なります。各自が JSON を手で書かなくてよい、起動コマンドの差分をチームで揃えやすい、環境差異の切り分け場所が減る。こうした効果が重なります。
一方で、AWS には AWS Serverless MCP Server などもあり、SAM を使うだけなら、IDE 側で MCP を別途用意する手間は比較的小さく、mcp.json を Power に同梱するメリットは相対的に薄く感じます。特にSAMならCLIもあるので、Power がなくとも十分に開発を進められます。
ただし、自社でホストする MCP や、起動コマンド・認証をチームで揃えて配りたいときは、mcp.json をパッケージに含める価値が出やすいと思います。mcp.json を設定できるおかげで、「接続設定ごと配る単位」として見ることができます。
個人開発なら Skill で足りる場面は多い
ここは正直に書きます。AWS SAM に慣れている個人開発者なら、Power はほぼ不要と考えています。
sam init・sam build・sam deploy の流れを自分で把握していて、Lambda や CloudFormation の基本的な作法が頭に入っているなら、CLI や MCP に Skill の組み合わせでも十分でしょう。今回触ってみたところでは、「Power でないと絶対に無理」という感触は持ちませんでした。
Power が効いてくるのは、チーム全体で同じ初期設定や運用ルールを共有したいとき、ベストプラクティスを毎回プロンプトで説明したくないとき、MCP 設定の面倒を利用者ごとに背負わせたくないときです。
また、外部ツール（Figma、Datadogなど）との接続が必要な場合もPowersは候補に入ると思います。
一言でまとめるなら、個人の習熟で吸収するか、配布物として先に揃えるかという違いです。
Hooks は公開 Powers ではまだ使われていない
Kiro の公式ドキュメントでは、Power は steering と hooks をまとめて配布できると説明されています。Hooks は IDE のイベントに応じて、あらかじめ定義したプロンプトやシェルコマンドを実行する仕組みで、自動トリガーにすると、Steering の Always モードよりも挙動を予測しやすくできます。
ただし、今回見た aws-sam ディレクトリ には Hooks が入っていません。Powers リポジトリ自体は .kiro/hooks/update-readme.kiro.hook を持っていますが、これはリポジトリの README 管理用で、手動トリガー（userTriggered）で AI エージェントに更新を委ねる形です。
少なくとも現時点の公開 Powers の多くは、Hooks よりPOWER.md（ワークフロー定義）とsteering/（常時ルール）を中心に組まれています。ただし、自分で Power を作る場合は、カスタム Power の作成（Create powers） に記載の導入手順などに沿って Hooks を同梱できます。
まとめ
今回の確認で、Skills と Powers の違いはかなり整理できました。
- Power は
POWER.md・mcp.json・steering/をまとめて配る単位 - Skill は手順や補助資材の再利用に強く、Power はツール接続まで含めた配布に強い
- Steering の Always モードにより、CloudFormation のルールは全セッションに載る。Skill の段階的ロードとはここが違う（
fileMatchなど別モードでは毎回ではない） -
POWER.mdの細かい ALWAYS/NEVER が、エージェントが迷わず進む理由になっていた - ただし自然言語である以上、完全な強制ではない
Power は誰にでも必須ではありません。 チームで同じ手順・Steering・必要なら MCP までを一つのパッケージにまとめて配りたいとき、Skill とは役割が違う配布単位です。
AWS SAM に限れば、個人で慣れているなら MCP + Skill でも十分だと思います。「毎回同じ前提を自分で積み直すのが面倒だ」と感じたら、Power の出番です。
aws-sam Power のリポジトリ を開いて、自分が普段使っている Skill と見比べてみてください。POWER.md・mcp.json・steering/ のどれが自分の運用に足りていないかを見ると、SAM まわりで Power を足すかどうか、判断がしやすくなると思います。
参考リンク
- Kiro: Powers（Powers, Steeringなど関連トピックへの導線あり）
-
kirodotdev/powers（公開 Powers。
aws-samやaws-observabilityなどはリポジトリ内の各ディレクトリ）
次回予告
第 2 回では、Claude Code や Cursor ユーザーの選択肢として Agent Plugin for AWS と比較します。Powers と Agent Plugin がどこまで重なり、どこから違うのかを、他エージェントユーザーの視点で整理する予定です。