1. はじめに
2026年6月25日・26日に開催された AWS Summit Japan 2026 では、AIを活用した開発手法として Kiro や AWS Blocks が紹介されていました。
セッションでは、要件定義から実装までをAIが支援し、AWS Blocksを利用してアプリケーションを効率よく開発する流れが紹介されており、「実際に自分でも試してみたい」と感じました。
そこで今回は、タスク管理システムを題材に、KiroとAWS Blocksを組み合わせた開発を体験しました。
さらに、「AWS Blocksを利用した場合とKiro単体で開発した場合では、どのような違いがあるのか」という点にも興味を持ち、同じ要件定義書（requirements.md）と設計書（design.md）を利用して、それぞれの方法でタスク管理システムを作成しました。
本記事では、環境構築からローカル実行までの流れを紹介するとともに、実際に試して感じた両者の特徴や、それぞれが活躍する場面についてまとめます。
2. KiroとAWS Blocksとは
Kiroとは
Kiroは、要件整理から設計書の作成、コード生成までをAIが支援する開発ツールです。
今回の検証では、requirements.mdやdesign.mdの作成だけでなく、タスク管理システムの実装までKiroを利用しました。
Kiroの詳細については、公式ドキュメントをご覧ください。
Kiro のご紹介 – プロトタイプからプロダクションまで、あなたと共に働く新しい Agentic IDE
AWS Blocksとは
AWS Blocksは、AWS上でアプリケーションを開発するためのフレームワークです。
AWSサービスとの親和性を考慮したプロジェクト構成や開発体験が用意されており、ローカル開発からAWSへの展開までをスムーズに進められることを目指しています。
今回の検証では、Kiroが作成した設計書をもとに、AWS Blocksプロジェクトへタスク管理システムを実装しました。
AWS Blocksの詳細については、公式ドキュメントをご覧ください。
※AWS Blocksは2026年6月時点でパブリックプレビュー中のサービスです。仕様や機能は今後変更される可能性があります。
3. 検証方法
今回は、同じ要件・同じ設計書を利用し、実装方法のみを変更するという条件で比較を行いました。
まずKiroを利用してrequirements.mdとdesign.mdを作成し、その後、同じ設計書を利用して
- Kiro × AWS Blocks
- Kiro単体
の2つの方法でタスク管理システムを実装しました。
要件や設計を統一することで、開発体験やローカル実行までの流れ、生成されるアプリケーションの違いを比較できるようにしています。
今回の比較では、次の観点を中心に確認しました。
- 開発の流れ
- ローカル実行までの手順
- 生成されたUI
- 開発時に必要となる知識
- AWSとの親和性
4. 実際にできあがったアプリケーション
どちらの方法でも、タスク管理システムをローカル環境で動作させることができました。
画面構成は共通してタスクの一覧表示や登録・編集など基本的な機能を備えていますが、UIや開発の進め方には違いが見られました。
ここでは完成したアプリケーションの一部を紹介します。
- Kiro × AWS Blocks版（スクリーンショット）
ログイン画面
タスクボード画面
タスク入力画面
- Kiro単体版（スクリーンショット）
ログイン画面
タスクボード画面
タスク入力画面
ステータスや優先度の表記言語、ログイン画面の構成などに違いが出ていますが、この点はrequirements.mdとdesign.mdでは定義されていませんでした。
AWS Blocksを利用した実装の場合、プロジェクト作成時に生成されるサンプルアプリケーションを参照して実装していることから、この違いは実装環境の違いによるものと考えられます。
※本記事ではrequirements.mdとdesign.mdの掲載は割愛させて頂きます。
5. 検証
5-1. requirements.mdとdesign.md作成
Kiroへ以下の依頼をしてrequirements.mdを作成します。
タスク管理システムを作ります。
Project
Task
User
を管理できるようにしてください。
requirements.mdを作成してください。
続いてdesign.mdの作成を依頼します。
requirements.mdを元に
design.md
を作成してください。
以下を含めてください。
・AWSアーキテクチャ
・ER図
・API仕様
・画面一覧
・非機能要件
・ADR
5-2. Kiro × AWS Blocksで開発
次にAWS Blocksのプロジェクトを作成し、その後、Kiroで作成したrequirements.mdとdesign.mdを利用してタスク管理システムの実装を行いました。
実装後はローカル環境でアプリケーションを起動し、ブラウザから動作確認を実施しました。
今回の検証では、大きな環境構築を行うことなく比較的スムーズにローカル実行まで進めることができました。
AWS Blocksには開発環境やプロジェクト構成があらかじめ用意されているため、「まず動かしてみる」という体験が非常にスムーズだったことが印象に残っています。
以下の通り、AWS Blocksでプロジェクトを作りローカル実行します。
この時点では目的のタスク管理システムは実装されていませんが、以下のようなTodo管理のサンプルアプリケーションが生成されました。
続いて、Kiroを使ってAWS Blocksプロジェクトにタスク管理システムを実装します。
Kiroのチャットには次のように依頼しました。
requirements.md と design.md を確認してください。
この設計に基づいて、現在の AWS Blocks プロジェクトへタスク管理システムを実装してください。
既存の AWS Blocks の構成に合わせて実装し、変更したファイルと実装方針も説明してください。
タスク管理システムが実装されました。以下はテストプロジェクトとテストタスク2つを入力した画面です。
5-3. Kiro単体で開発
続いて、AWS Blocksを利用せず、Kiroのみで同じタスク管理システムを実装しました。
Kiroのチャットには次のように依頼しました。
requirements.md と design.md を確認してください。
この設計に基づいて、AWS Blocksは使用せずに、タスク管理システムを作成してください。
ローカルで動作確認できるようにしてください。技術スタックは理由も含めて提案してください。
こちらも同じrequirements.mdとdesign.mdを利用し、バックエンド・フロントエンドを含めたアプリケーションを生成しています。
生成されたプロジェクトはReact、Express、Prisma、PostgreSQLなどWebアプリケーション構成となっており、実際の開発プロジェクトに近い印象を受けました。
一方で、ローカルで動作させるためには、依存ライブラリのインストールやPrisma Clientの生成、データベースのマイグレーションなど、いくつかの準備が必要でした。
環境構築後は、フロントエンドとバックエンドをそれぞれ起動し、タスク管理システムをローカルで動作させることができました。
比較のためテストプロジェクトとテストタスク2つを入力した画面を掲載します。
6. 結果
ここまでの検証結果を表にすると以下のようになります。
| 項目 | Kiro × AWS Blocks | Kiro単体 |
|---|---|---|
| 開発の流れ | ◎ | ○ 試行錯誤が必要 |
| ローカル実行 | ◎ | △ 環境構築が必要 |
| 生成されたUI | ○ | ◎ 高機能（今回の検証） |
| 必要な知識 | ○ 少ない | △ Node.js・Prismaなどが必要 |
| AWSとの親和性 | ◎ 高い | ○ |
7. AWS Blocksはどんなシステムに向いているか
今回の検証を通して、AWS BlocksはAWSマネージドサービスを活用したクラウドネイティブなアプリケーションと相性が良いと感じました。
例えば、API Gateway・Lambda・DynamoDBを組み合わせたCRUDアプリケーションや、EventBridge・Lambda・SNSを利用したイベント駆動型システムでは、AWS Blocksの考え方を活かしやすい構成になります。
具体的には、次のようなシステムが考えられます。
- タスク管理システム
- 顧客管理システム
- 障害通知システム
また、PoCや小規模開発、教育目的に利用しやすいと考えられます。
一方で、CloudFront・ALB・EKS・RDSを中心としたコンテナベースのシステムなどでは、DockerやKubernetes、IaCによるインフラ設計が重要になります。そのため、AWS Blocksだけで完結するというよりも、TerraformやAWS CDKなどと組み合わせて利用する方が適しているケースも多いと考えられます。
8. まとめ
今回、同じrequirements.mdとdesign.mdを利用し、Kiro × AWS BlocksとKiro単体という2つの方法でタスク管理システムを開発してみました。
比較してみると、Kiro × AWS Blocksでは、AWSアプリケーション開発を前提としたプロジェクト構成や開発環境があらかじめ用意されているため、比較的スムーズにローカル実行まで進めることができました。
一方、Kiro単体で生成したアプリケーションは画面構成やUIが充実しており、一般的なWebアプリケーションに近い構成となっていました。その一方で、実際に動作させるためにはNode.jsやPrismaなどの技術スタックを理解し、依存ライブラリのインストールやデータベースの初期化といった環境構築が必要でした。
今回の検証からは、Kiro × AWS Blocksは「AWSを前提とした開発体験を提供すること」に強みがあり、Kiro単体は「より完成度の高いアプリケーションを生成すること」に強みがある、というそれぞれの役割の違いを実感しました。
今回の比較を通して、両者は競合するツールというよりも、目的や開発スタイルに応じて使い分けることで、それぞれの強みを活かせると感じています。
今後試してみたいこと
今回の検証はローカル環境での開発・動作確認まででしたが、今後はAWS Blocksを利用して実際にAWS環境へデプロイするところまで試してみたいと考えています。
また、今回はタスク管理システムを題材にしましたが、AWS Blocksの特徴をより活かせるイベント駆動型のシステムや、API Gateway・Lambda・DynamoDBを組み合わせたサーバーレスアプリケーションでも検証を行い、開発体験や設計の違いを比較してみたいと思います。
さらに、AWS Summitで紹介されていたようなAIを活用した開発フローについても継続して検証し、実際の業務開発でどのように活用できるのかを今後も試していきたいと考えています。
