Kiro IDE の「Build AWS infrastructure with CDK and CloudFormation」Power を使ってAWS環境を構築してみた

こんにちは、なおにしです。

Kiro IDE で「Build AWS infrastructure with CDK and CloudFormation」Power を使用したAWS環境の構築を試してみましたのでご紹介します。

はじめに

2025年11月にKiroが一般提供(GA)されました。

https://aws.amazon.com/jp/blogs/news/general-availability/

GA と併せて、Amazon Q Developer CLI が Kiro CLI に統合されました。AWS マネジメントコンソール上でも、Amazon Q Developer と Kiro は同じ画面を共有するようになっています。

https://aws.amazon.com/jp/blogs/news/introducing-kiro-cli/

このため料金の請求についても、公式ドキュメントの料金ページにはクレジットカードの利用しか記載がありませんが、実際には Q Developer と同様にAWS アカウントでの支払いが可能になっています。

以下、「Kiro 導入ガイド：始める前に知っておくべきすべてのこと」からの引用です。

Q Developer を利用されていた方は料金周りの面でもスムーズに Kiro への移行ができるようになっています。私の場合は Q Developer を手動でアップグレードするのではなく、Kiro 用に準備された別の IAM Identity Center による組織に移行したので、本記事の末尾に補足としてQ Developer の使用を停止した際の操作をまとめました。

というわけで Kiro を使って何か試そうとしていたところ、先日開催された AWS re:Invent 2025 で Kiro Powers が発表されました。

https://aws.amazon.com/jp/blogs/news/introducing-powers/

Kiro Powers については以下の弊社記事でも紹介されていますので併せてご参照ください。

https://dev.classmethod.jp/articles/kiro-powers-introduction/

本記事の公開時点で利用可能な Kiro Powers を眺めていると、Build AWS infrastructure with CDK and CloudFormation というAWSが提供する Power がありました。今回はこちらを実際に使ってみようと思います。

最新のドキュメント、ベストプラクティス、コードサンプルを活用し、CDK で Well-Architected な AWS インフラストラクチャを構築します。CloudFormation テンプレートの検証、リソース設定のセキュリティコンプライアンスの確認、デプロイメントのトラブルシューティングを行います。

「Build AWS infrastructure with CDK and CloudFormation」Power の中身

上記のDetailsから Github リポジトリにリンクが貼られているのですが、中身は以下の2ファイルのみです。

• POWER.md
• mcp.json

それぞれの役割については先述の Powers 自体の説明記事をご参照ください。実際にmcp.jsonを見ると以下のとおりでした。

{
  "mcpServers": {
    "awslabs.aws-iac-mcp-server": {
      "command": "uvx",
      "args": ["awslabs.aws-iac-mcp-server@latest"],
      "env": {
        "AWS_PROFILE": "your-named-profile",
        "FASTMCP_LOG_LEVEL": "ERROR"
      },
      "disabled": false,
      "autoApprove": [
        "read_iac_documentation_page",
        "search_cdk_documentation",
        "search_cdk_samples_and_constructs",
        "cdk_best_practices",
        "search_cloudformation_documentation"
      ]
    }
  }
}

aws-iac-mcp-serverについては知らなかったのですが、2025年11月末に追加された新しい MCP サーバのようでした。

https://aws.amazon.com/jp/blogs/devops/introducing-the-aws-infrastructure-as-code-mcp-server-ai-powered-cdk-and-cloudformation-assistance/

https://awslabs.github.io/mcp/servers/aws-iac-mcp-server

以前からCloudFormation MCP サーバ はあったのですが、AWS IaC MCP サーバはリソースを作成するためというよりもベストプラクティスやコンプライアンスに基づいた CDK/CloudFormation のコードを作成するための用途になっているようです。

AWS CDK MCP サーバ というものもあったようですが、こちらが以下のとおり非推奨になってAWS IaC MCP サーバが後継のようです。

⚠️ DEPRECATION NOTICE: This server is deprecated and will be removed in a future release. Please use the AWS IaC MCP Server instead, which provides all CDK functionality along with additional Infrastructure as Code capabilities.

上記記事に記載のとおり、AWS IaC MCP サーバでは以下のような9つのツール群が提供されています。

1. search_cdk_documentation
   AWS CDK ナレッジベースで API、概念、実装ガイダンスを検索します。
2. search_cdk_samples_and_constructs
   AWS Construct ライブラリから、事前に構築された AWS CDK コンストラクトとパターンを見つけます。
3. search_cloudformation_documentation
   リソースタイプ、プロパティ、および組み込み関数について CloudFormation ドキュメントをクエリします。
4. read_iac_documentation_page
   検索または提供された URL から返された CloudFormation および CDK の完全なドキュメント ページを取得して読み取ります。
5. cdk_best_practices
   AWS CDK のベストプラクティスと設計原則の厳選されたコレクションにアクセスします。
6. validate_cloudformation_template
   cfn-lint を使用して構文とスキーマの検証を実行し、デプロイメント前にエラーをキャッチします。
7. check_cloudformation_template_compliance
   AWS Guard ルールと cfn-guard を使用して、テンプレートに対してセキュリティとコンプライアンスのチェックを実行します。
8. troubleshoot_cloudformation_deployment
   統合された CloudTrail イベント分析機能を使用して、CloudFormation スタックのデプロイ失敗を分析します。このツールは、AWS 認証情報を使用してスタックのステータスを分析します。
9. get_cloudformation_pre_deploy_validation_instructions
   変更セットの作成中にテンプレートを検証する、CloudFormation のデプロイ前検証機能の指示を返します。

それぞれのツールを柔軟に使いこなせるとすごいのですが、実際に活用するのであればCDKによる開発でのベストプラクティスと併せてそれぞれのツールの使い所を定義する必要があるかと思います。

その定義をしているのが POWER.md になります。したがって、「Build AWS infrastructure with CDK and CloudFormation」Power は AWS IaC MCP サーバとその最適な使い方をセットにしたものであると言えそうです。

というわけで、実際に「Build AWS infrastructure with CDK and CloudFormation」Power を Kiro IDE に追加して環境を構築してみます。

今回構築する環境は、こちらの記事と同じく以下の構成図を基に作成してみます。

やってみた

事前準備

グローバルステアリングファイルの作成

すぐに検証を始めたいところですが、Kiro IDE をインストールしてログインまでが完了した状態であれば、ステアリングファイルも特に設定していない状態かと思います。ステアリングファイルについては様々な記事で言及されているかと思うので説明は割愛しますが、公式ドキュメントは以下になります。

https://kiro.dev/docs/steering/

前述の状態で操作を始めると、Vibe モードで軽くチャットするくらいなら問題無いのですが、例えば Spec モードで作成されるドキュメントが英語になったり、Kiro IDE の特定のボタンを押下してプロンプトが実行された場合のチャット内容も英語になったりと、英語力のある方向けの仕様になります。

そこで、グローバルステアリングファイルを使って最初から日本語化しておきます。（Claude Code でいうところの CLAUDE.md に相当するファイルなので、英語で記載した方が処理効率が良いとか諸説あるかと思いますが、今回は日本語フレンドリー優先ということで）

ドキュメントに記載のとおり、グローバルステアリングファイルは全てのワークスペースに適用されます。格納場所は~/.kiro/steering/ですので、以下のとおりファイルを配置します。

---
inclusion: always
---

# グローバル言語設定

## 基本方針
- **すべての応答とコミュニケーションを日本語で行う**
- **コード生成時のコメントは日本語で記述**
- **エラーメッセージや説明も日本語で提供**
- ✅のような絵文字は使用不可

## 適用範囲
- チャット応答
- コード内コメント
- ドキュメント生成
- エラー説明
- リファクタリング提案
- デバッグ情報

## コード品質
- 変数名や関数名は英語（国際的な慣習に従う）
- コメントは日本語で詳細に説明
- README等のドキュメントは日本語で作成

## 例外
- 外部ライブラリのAPI呼び出し
- 標準的な技術用語（必要に応じて日本語で補足説明）
- 国際的なコーディング規約に従う部分

冒頭の---で囲まれた部分は Inclusion モードに関する記載です。alwaysを指定した場合は、Kiro との全てのやり取りで自動的に読み込まれます。なお、alwaysがデフォルトなので今回のケースであれば実際のところ明記する必要はないのですが、ドキュメントに記載のとおりfileMatchを指定することで特定のパターンに一致するファイルを扱う場合にのみ読み込ませる、といった制御も可能ですので、あえて明記しておく方が分かりやすいかと思います。

一般的なステアリングファイル戦略やベストプラクティスについてもドキュメントに記載があるので、併せてご参照ください。

日本語化については上記のファイルで対応しましたが、ついでに昨今では npm の実行が何かと不安なので、ステアリングファイル戦略に則ってsecurity-policies.mdを作成して雑ですが以下のように記述しておきます。

---
inclusion: always
---

# グローバルセキュリティ設定
- npm ではなくpnpm を使用する
- npx ではなくpnpx を使用する

Powers を追加する

Kiro IDE の左ペインからPowersを選択し、「Build AWS infrastructure with CDK and CloudFormation」をインストールします。

インストールはすぐに完了します。追加されたMCPサーバの設定はOpen powers configから確認可能です。

mcp.jsonが開かれて、該当箇所は以下のとおりです。AWS_PROFILEについては任意に設定します。

  "powers": {
    "mcpServers": {
      "power-aws-infrastructure-as-code-awslabs.aws-iac-mcp-server": {
        "command": "uvx",
        "args": [
          "awslabs.aws-iac-mcp-server@latest"
        ],
        "env": {
          "AWS_PROFILE": "your-named-profile",
          "FASTMCP_LOG_LEVEL": "ERROR"
        },
        "disabled": false
      }
    }
  }

UI からも Power による MCP サーバが追加されていることが分かります。また、事前に作成したステアリングファイルも読み込まれています。なお、今回は既に登録していたその他の MCP サーバについては Disable にしています。

Hooks を追加する

せっかく CDK/CloudFormation で環境を構築するので、出来上がったテンプレートに基づいたパラメータシートを作成するように Hooks を設定してみます。

https://kiro.dev/docs/hooks/

以下のプロンプトを実行しました。

エージェントがタスクを終えて、CDK/CloudFormationのコードが出力されたら、コードに基づいてインフラストラクチャパラメータシート（docs/parameters-sheet.md）を更新してください。
パラメータシートは以下の形式で保存してください：
1. リソースごとにMarkdownの表形式で整理
2. 各リソースの表には以下の列を含める：
   - パラメータ名
   - 値
   - 説明
   - ステータス（実装済み/未実装）
3. リソースカテゴリ別にセクション分け（VPC、EC2、RDS等）
4. 実装状況と完了済みコンポーネントの情報を最新の状態に同期

すると自動で以下のとおり Hook が作成されました。

Event にはAgent Stopが選択されています。このフックトリガーは2025年12月18日のアップデートで追加されたばかりの機能なので、併せて挙動を確認しようと思います。

https://kiro.dev/changelog/web-tools-subagents-contextual-hooks-and-per-file-code-review/

Power のオンボーディングを実行する

Power のTry Powerボタンを押すことで、Power で定義されたオンボーディングを実行することができます。

ボタンを押下すると、以下のようにプロンプトが実行されます。プロンプトが英語のため、前述のステアリングファイルで日本語設定を行っていないと、以降の応答や成果物が全て英語になります。

CDKでS3バケットを作成するデモが開始されました。Power がきちんと使用されています。

色々と試行錯誤しながら進めていってくれています。security-policies.mdも読み込んでいるため、最初からnpmではなくpnpmを使ってくれているのも良いですね。

完走しました。自動でセキュリティとコンプライアンスのチェックもしてくれています。

エージェントの応答が完了後、先ほど設定していた Hook が自動的に実行されました。

作成されたパラメータシートは以下のとおりです。本記事自体の章立てと干渉するようなので見出し(#)は削除しています。

オンボーディングだけで期待どおりの動作を確認できたので検証は止めようかと思いましたが、せっかくなので続けます。

構成図を基にしたタスクリストの作成

オンボーディングを実行するとデモで使ったファイル群が残ってしまうので、作成されたファイル群は削除した上で続けます。まず、Spec モードで先述の構成図を読み込ませて指示を出します。

正確に構成図の内容を読み取ってくれました。スペック(要件定義書)の名前のサジェストもしてくれているので、aws-web-infrastructureで進めることにします。

作成された要件定義書の内容については割愛して設計フェーズに進みます。

必要に応じてベストプラクティスを Web サーチツールで調査しつつ、設計書が作成されました。特にプロンプトで指示をしてはいませんでしたが、設計書の冒頭に CDK(TypeScript)を使用することが明記されています。このままタスク作成のフェーズに進みます。

ちなみに設計書内に記載されていたMermaidによる図は以下のとおりです。さすがに改善の余地がありますが、それらしい構成図にはなっています。

タスクリストが作成されました。今回はオプションタスクを維持（高速MVP）を選択します。

構成図を適当に渡しただけで、ここまで整理してくれました。

なお、改めて全体を確認すると EC2 に Auto Scaling Group が適用されていたので、そこだけ不要という形でプロンプトを実行して修正しました。

タスクの実行（CDK作成）

それでは、タスクリストのStart taskを実行して実装を開始します。

タスク2を実行している様子を眺めていたのですが、どうやら Power が呼び出されていませんでした。

Power はコンテキストから必要に応じて呼び出されるということになっており、VPC関連のCDKを作成しているタイミングで呼び出されないのはどういう理由なのか分かりませんが、今回は Power を積極的に活用したいので、ステアリングファイルimplementation.mdを作成して以下のように Power を活用するように定義します。ついでに、先ほどのオンボーディングでのデモで改善点として Node.js の古いバージョンを使用していることが挙げられていましたので、基本的に新しいバージョンを使用するように明記します。

---
inclusion: always
---

# グローバル実装設定

## 基本方針
- AWS、CDK、CloudFormation、インフラ関連のタスクでは必ずaws-infrastructure-as-code Powerを活用してください
- Lambda等で使用するNode.jsのバージョンは`22.x`とする。古いバージョン`18.x`等は使用不可

タスク2を実行する前にバックアップを取っていたので、改めて上記のステアリングファイルが存在する状態で再度タスク2を実行します。

最初から Power を使うようになりました。詳細な出力内容は割愛しますが、Power を使う方がスムーズに実装できていました。ただ、タスク完了後にパラメータシートを作成する Hook が実行されませんでした。なぜだろう...　とりあえず残りのタスクリストを進めました。

そしてここからが長くて、各タスクでテストが実行されるので1つのタスクで5分〜10分近くかかり、途中テストがクリアできなくなったので一度テストを最初からするようにプロンプトで促したりして、結局2時間近く格闘していました。。

ですが最終的にはデプロイまで完了し、Vibe モードで改めてコードとデプロイ結果を確認するようにプロンプトを実行したタイミングで Hook も実行されました。挙動だけを見ると、Spec モードでは呼び出されず、Vibe モードであれば呼び出されるようです。この挙動どおりであれば、Spec モードで実装が完了した後、Vibe モードでデプロイを指示するという流れが良さそうです。

ALB経由でのEC2アクセスも問題なさそうです。

EC2 からのDBアクセスも可能でした。

出力されたパラメータシートは以下のとおりです。本記事自体の章立てと干渉するようなので見出し(#)は削除しています。

補足：Q Developer Pro のアンサブスクライブ

こちらの方法で設定していた IAM Identity Center 経由のQ Developer Pro をアンサブスクライブします。

ログイン状況の確認とログアウト

Kiro CLI のUIから確認およびログアウトする場合はPreferencesで操作します。

なお、コマンドでも以下のように確認できます。

$ kiro-cli user whoami
Logged in with IAM Identity Center (https://d-1234567890.awsapps.com/start)

Profile:
QDevProfile-us-east-1-cm-naonishi
arn:aws:codewhisperer:us-east-1:123456789012:profile/XXXXXXXXXX12

サブスクリプションの解除

AWS マネジメントコンソールから Q Developer を選択し(既に Kiro と統合されているので表示は Kiroになる)、サブスクリプションを解除します。

ステータスがキャンセル済みに変わります。

続いて、IAM Identity Center を開き、念のため既存のセッションを終了しておきます。

アプリケーションの割り当てを表示すると、先ほどサブスクリプションのステータスはキャンセル済みに変わりましたがまだ登録が残っていることが分かります。

Kiro の画面に戻り、セッティングからプロフィールを削除します。

なお、KiroのタブとQ Developerのタブがあり、それぞれの設定を確認できます。Q Developer ではログの記録を有効化していたので、後ほど S3 バケット に格納されているプロンプトのログ等が、プロフィール削除によって消えないかも確認してみます。

IAM Identity Center の画面に戻ると、アプリケーションから表示が消えました。

設定していた各種ログは S3 バケットに問題なく残っていました。

まとめ

Power のオンボーディングでは感動しましたが、実際にWeb3層アーキテクチャくらいのシステムを作成しようとすると、考慮事項やテスト内容も増えてなかなかスムーズにはいきませんでした。
こちらの記事でも教訓として記載されていますが、本来は「何を作りたいか」を定義した上で、仕様をレビューしながら進めていくものなので、今回のように薄いステアリングファイルだけ準備して仕様のレビューもせずに進めていれば当たり前の結果なのかもしれません。

一方で、Powers によって特にプロンプトで指示しなくてもベストプラクティスに沿った設計&テストを実行してくれるので、あまり経験の無いサービスを用いてシステムを構築するような際にも活用できそうです。例えば、従来どおりパラメータシートを作ってから実装するやり方ではなく、対象サービスを絞った上でまず Kiro にざっくり実装とパラメータシート作成をしてもらう方法です。その後、任意のパラメータに再設計して再実装するというやり方も、慣れれば効率的にできるかもしれないと思いました。

本記事がどなたかのお役に立てれば幸いです。