タグ: software-design

AWSの新AI IDE「Kiro」を試してみた──要件定義から設計支援に強み

はじめに

2025年7月、AWSは開発者向けの新たなAIツール「Kiro（キロ）」を発表しました。このツールは、自然言語によるプロンプトから要件定義、設計、実装計画を一貫して支援する“エージェント型AI IDE”として注目を集めています。

これまでのAIツールは、主にコーディング支援やコード補完を目的としたものが多く、設計段階から関与するタイプのものは限られていました。しかし、Kiroは「設計からはじめるAI開発支援」という新しいアプローチを取り入れており、ソフトウェア開発のプロセスそのものに踏み込んでくる存在といえます。

特に、自然言語からプロジェクトの全体構成を立案し、ファイル構造・責務分担・テスト方針に至るまでをマークダウン形式で出力してくれるという点は、多くの開発者にとって革新的な体験となるでしょう。また、その出力されたファイルを他のAIエージェントに渡すことで、設計と実装の分業という新しいワークフローが実現しつつあります。

筆者もこのKiroを実際に使用してみたところ、現時点でも設計フェーズにおいては非常に高いポテンシャルを感じました。一方で、まだプレビュー段階であることもあり、実運用には少々不安が残る部分もあるのが正直なところです。

この記事では、Kiroの特徴や使ってみた所感を詳しく紹介しながら、他のAIツールとの効果的な使い分けについても考察していきます。今後AI開発支援ツールを導入しようと考えている方や、既存のAIツールに不満を感じている方にとって、参考になる内容になれば幸いです。

Kiroとは何か？

Kiroは、AWSが開発したAIエージェント駆動型の開発支援環境（IDE）です。従来のAIツールのように「コード補完」や「バグ修正」といった局所的な支援にとどまらず、要件定義・設計・実装計画といった上流工程からAIが関与するという点で、まったく新しいアプローチを提示しています。

Kiroが提供する最大の価値は、開発プロセスの「起点」――つまり要件定義や設計といったフェーズを自然言語から構造化できる点にあります。ユーザーがプロンプトで要望を入力すると、それをもとにKiroはファイル構成、ドメインモデル、責務分担、テスト方針などを含む実装計画を導き出してくれます。

この情報はすべてマークダウン形式のファイルとして出力されるため、以下のような利点があります：

  • Gitでのバージョン管理がしやすい
  • ドキュメントとしてチームで共有できる
  • Claude CodeやGemini CLIなどファイルベースで入力を受け取れる他のAIツールと連携できる

つまり、Kiroを「設計書の起点」として活用し、その内容を他AIツールに渡してコードを生成させる、というAIエージェントの役割分担型ワークフローが実現できるのです。

またKiroは、近年注目されているModel Context Protocol（MCP）にも対応しています。MCPはAIエージェント間でコンテキスト（文脈）を共有するためのオープンなプロトコルのひとつで、Kiroはこの仕様に準拠することで複数のAIエージェントと連携しやすい設計を可能にしています。

さらに、Kiroはチャット形式のインターフェースを採用しており、開発者とAIエージェントが対話を通じて開発方針を擦り合わせていくことができます。単なる1回限りのプロンプトではなく、「この方針で問題ないか？」「もっと良い構成はないか？」といった設計意図の検証と改善提案まで含めて支援してくれるのが大きな特徴です。

現在はプレビュー段階での提供となっており、無料枠のほかに月額制のProプラン（$19/月）やPro+プラン（$39/月）が用意されています。将来的にはAmazon Bedrockの「AgentCore」や、AWS Marketplaceで展開されるエージェントカタログとの統合も視野に入っており、より実運用向けの基盤として発展していくことが期待されます。

マークダウン出力がもたらす連携性

Kiroの特徴のひとつが、要件定義・設計・実装計画がマークダウン形式で出力される点です。

各セッションで作成された情報は、.kiro/specs ディレクトリ配下にセッションごとのフォルダとして保存され、その中に以下のようなファイルが自動的に生成されます。

  • requirements.md（要件定義）
  • design.md（設計）
  • tasks.md（実装計画）

このように、開発における上流フェーズの成果物が構造化された文書ファイルとして明確に切り出されているため、Kiroは単なるチャットベースのAIアシスタントにとどまらず、成果物を他のAIやツールに引き継ぐための“ドキュメント生成エンジン”として機能します。

たとえば、ユーザーがKiroに対して「こういうWebアプリを作りたい」「認証とデータ一覧表示を含めて」といった要望を投げかけると、Kiroはその内容を解釈し、requirements.md に要件としてまとめ、次に design.md に設計方針を落とし込み、最後に tasks.md に具体的な実装ステップを提示します。この一連の流れは対話ベースで進行しますが、成果物はすべてマークダウンとして構造的に記述されたファイルに残るのが特徴です。

そしてここが最も重要な点ですが、このマークダウン形式の実装計画（tasks.md）は、Claude CodeやGemini CLI、Copilot CLIなど、ファイルを受け取って処理を行うAIツールにそのまま渡すことが可能です。つまり、Kiro自身がMCP（Model Context Protocol）といったエージェント間通信プロトコルに対応していなくても、出力されたマークダウンファイルを介して“別のAIエージェントに実装を委譲する”というワークフローが実現できるのです。

この仕組みにより、Kiroは次のような使い方を支援します：

  • requirements.md をチームでレビューして合意形成
  • design.md をもとに設計方針を検証・修正
  • tasks.md をコード生成AIに渡して実装を自動化

また、Kiroの出力するマークダウンは内容が明確かつ読みやすく、Gitリポジトリでバージョン管理するのにも適しています。.kiro/specs ディレクトリをそのまま docs/ や specs/ 配下に移し、PR時に設計文書をレビューしたり、要件変更に応じて再生成するというフローも容易に構築できます。

このように、Kiroの「マークダウン出力」は単なる便利機能ではなく、開発プロセス全体を分業・自動化するための接続点としての役割を担っています。とくに、異なるAIツールや人間チームとのインターフェースとして自然に機能する点は、Kiroをプロダクション開発に組み込むうえでの大きな強みです。

実際に使ってみた所感

筆者も試しにKiroでプロジェクトの設計を進めてみました。その印象は以下の通りです：

✅ 良かった点

  • 要件定義から設計・実装計画までの一貫性が取れる 　→ 単なるコード生成ではなく、「この機能はなぜ必要か」「どのような構成が最適か」を問い直しながら対話を進められるのが好印象でした。
  • マークダウン出力で他ツールとの連携が容易 　→ ClaudeやGeminiなどにそのまま渡せる形式で出力されるのは非常に便利です。
  • チャット形式で設計議論ができる 　→ 設計意図や代替案を確認しながら進められるため、プロンプト1発生成よりも信頼性が高いです。

⚠️ 気になった点

  • セッションが不安定で、エラーで落ちることがある 　→ プレビュー版ということもあり、ブラウザクラッシュなどが時折発生します。
  • コード生成の品質は今一つ 　→ 現時点では他のAIエージェントと比べると生成速度にやや難があるため、コード生成は他のAIエージェントに任せた方が効率的です。

まとめ

現時点ではKiroは「設計支援特化ツール」として割り切って使うのがベストだと感じています。

具体的には次のような使い分けが現実的です：

フェーズツール特徴
要件定義・設計Kiroタスク分解と構造化、ドキュメント出力に優れる
実装Claude Code / Gemini CLI / GitHub Copilotコード生成精度が高い

AWSの「Kiro」は、AIエージェントによって開発プロセスを構造的に捉え直す革新的なツールです。設計・仕様・実装計画をマークダウン形式で出力できることで、Claude CodeやGemini CLIのようなAIエージェントとの相性も抜群です。

現時点ではコード生成や動作安定性にやや難がありますが、これはプレビュー版であることによるものと考えられるため、正式リリース後にProやPro+プランを契約することで自然と解消していくものと考えられます。

使い方に関する記事が数多く出ているので、しばらくはKiro + Claude Codeでバイブコーディングを続けて知見を蓄えていこうと思います。

📚 参考文献

生成AIは本当に開発効率を上げるのか？──熟練エンジニアとAIの生産性ギャップから見えてくる未来

2025年7月10日、AI安全性に関する非営利団体METR（Model Evaluation and Testing for Reliability）は、注目すべき研究成果を発表しました。

研究名： Measuring the Impact of Early‑2025 AI on Experienced Open‑Source Developer Productivity

この研究では、16人の経験豊富なオープンソース開発者に対し、AI支援（Cursor Pro + Claude 3.5/3.7 Sonnet）を使う場合と使わない場合で、それぞれ2～4時間程度のタスクに取り組ませ、合計246件の作業データを分析するというランダム化対照試験が行われました。

結果：AIを使うと”19%遅くなる”

この結果は、AIの進化が目覚ましいとされる現在において、多くの人にとって意外なものでした。特に近年では、AIコード補助ツールが生産性向上の切り札として注目されてきた背景があるためです。研究では、AIを活用することで「簡単な作業がより速くなる」「面倒な手順が省略できる」といった定性的な利点があると考えられていましたが、実測ではそれが裏付けられませんでした。

被験者となった開発者たちは、平均してAIによって20％以上の効率化が期待できると予測していました。しかし実際には、AIを使用するグループの方が、課題の完了に平均して19％も長い時間を要しました。このギャップの主な原因とされるのは、AIから得られる提案の質と、提案を修正するコストです。

AIツールが出力するコードは一見正しく、スムーズに見えるものの、細かな仕様やプロジェクト特有の設計方針と合致していない場合が多く、その調整に多くの時間を取られる結果となりました。特に、ベテラン開発者ほど自身の頭の中に完成像を持っているため、その差異に気づくのが早く、「修正にかかる時間＞自分で最初から書く時間」となってしまうのです。

このように、AIの提案をそのまま受け入れられるケースが限定的であることが、結果として生産性の低下に直結したと考えられます。

開発者たちは事前に「AIを使えば20〜24％ほど生産性が上がるだろう」と予測していましたが、実際にはAIを使用したほうが平均で19％も時間がかかるという意外な結果が出ました。

この理由としては：

  • AIの提案が開発者の期待とずれるため、何度もやり直す必要があった
  • コードレビューや修正の手間が増えた
  • 大規模で成熟したコードベースにおいて、経験者の方がむしろ効率が良い

などが挙げられます。

私自身の実感と重なる部分

この研究結果には、私自身も非常に共感するところがあります。日々の開発業務の中で、生成AIを活用する場面は増えており、特に単純な構文や定型的な処理、あるいは初期ドラフトのコード作成においては、AIが非常に便利な支援をしてくれると感じています。ちょっとしたユーティリティ関数や、既知のライブラリの使用例など、検索よりも速く結果を得られることも多く、その点では間違いなく時間短縮になります。

しかしながら、AIの生成するコードが自分の期待に完全に沿っていることは稀であり、特に複雑な業務ロジックやプロジェクト特有の設計方針が絡む場面では、「自分の期待通りに作ってくれない」ということが多々あります。その結果、何度もやり直しや修正を重ねる必要が生じ、最終的には「それなら最初から自分で書いた方が早い」と思ってしまうのです。

また、私自身が長年使い慣れているエディタやIDEには、補完機能・リファクタリング支援・構文チェック・プロジェクト内検索など、豊富な機能が揃っており、これらを駆使することで非常に効率よく開発が進められます。AIを使わずとも、そうしたツール群を十分に使いこなすことで、AIと同等、あるいはそれ以上の生産性を実現できる場面も少なくありません。

特に新しいプロジェクトを立ち上げる際には、何の構造もないところからAIに任せてコードを作ってもらうよりも、自分の手である程度の骨組みや基本設計を作り上げてから、それをベースにAIにコード生成を任せた方が、生産性も品質も高くなると感じています。このプロセスにおいては、自分自身の理解と設計意図が反映された構造を前提にしているため、AIに任せる部分もブレが少なく、修正コストが下がるというメリットがあります。

総じて、AIツールは便利であることに間違いはないものの、それを活用するには開発者側の明確な目的意識と設計力が不可欠であり、状況によっては手動での実装の方が遥かにスムーズであるという点を、私は日々の経験から強く実感しています。

AIへの指示（プロンプト）も”設計”が必要

AIツールをうまく使いこなすためには、単に指示を出すだけでなく、その指示（プロンプト）自体がよく設計されたものである必要があります。たとえば「こういうコードを書いてほしい」と伝える場合でも、AIが期待通りのコードを出力するためには、その背景にある仕様や目的、設計方針を明確に示すことが不可欠です。

この点で特に重要だと感じるのは、まず自分である程度プログラミングをして、基本的な設計ルールやプロジェクトのガイドラインを構築しておくことです。自分自身の手でコードを書きながら、どのような責務分離が適切か、どのような命名規則や設計思想を持たせるかを整理しておくと、その知見をベースにAIへの指示も具体的で効果的なものになります。

逆に、設計ルールが曖昧なままAIに「任せる」形でコードを生成させると、出力されたコードの粒度や抽象度、設計方針にバラつきが出やすくなり、結果的に後から修正や再設計に手間がかかってしまうケースも少なくありません。

つまり、プロンプトは”設計ドキュメントの一部”とも言える存在であり、AIとの協働においては設計力と記述力が密接に結びついているのです。

プロンプト設計を正確に行うには、まず自分で問題を構造化し、設計方針を定義する経験を積むことが前提であり、その経験があるからこそAIに対しても適切な期待値を持ったアウトプットを引き出すことが可能になります。

このように、AI時代における開発者の役割は、単なるコーディングから、より高いレベルの構造化・設計・説明へとシフトしていると言えます。そしてそれは、最初からAIに頼るのではなく、自分の手で構築するプロセスを経て初めて実現可能になるものです。

AIツールをうまく使いこなすためには、適切なルール設計が不可欠です。しかし、良いルールは、やはり自分でコーディングして初めて見えてくる部分が多く、ルール設計と実装は切り離せないというのが私の立場です。

新人と熟練者のギャップは広がる？

今後、AIの進化によりその性能がさらに向上し、より高度な文脈理解や仕様対応が可能になることで、AIそのものの生産性も確実に高まっていくと考えられます。しかし、それと同時に、AIを使用することで得られる生産性の向上には、ユーザー側のスキルレベルに依存する部分があるという点が重要です。

特に注目すべきは、AIを使うことによる生産性の上昇効果が、新人ほど大きく、熟練者ほど小さい傾向にあるという点です。熟練者はすでに高い生産性を持っているため、AIが支援する余地が少ないのに対し、新人は未知の技術や構文に直面する際にAIの助けを大きく受けられるため、相対的に効果が大きくなります。

この差は今後さらに広がる可能性があります。AIの性能が向上すればするほど、新人でも一定レベルの成果物を短時間で作れるようになります。しかしその反面、新人が自力で設計やコーディングを行う機会が減少し、思考力や設計力、問題解決能力といったソフトウェアエンジニアとしての基礎的なスキルの向上が鈍化する懸念があります。

その結果として、短期的には”AIに強く依存した新人”が増えるものの、数年後には”自力で開発できる中堅〜上級者”が育っていないという状況に陥る可能性も否定できません。これはソフトウェア開発の現場における品質や持続可能性に直接関わる重要な課題です。

したがって、教育や人材育成の観点では、AIを活用しつつも、自ら考え、設計し、試行錯誤する経験を十分に積めるような環境設計がますます重要になると考えられます。AIはあくまで支援ツールであり、開発者自身がコアスキルを持っていることが、最終的な品質と信頼性に繋がるという意識を共有する必要があるでしょう。

今後、AIの進化によりこの生産性ギャップが縮まることはあると思いますが、一方で、新人開発者と熟練者との間にある”AIによる支援の恩恵”の差はむしろ拡大していくのではないかと予想します。

AIが新人の生産性を大幅に底上げする一方で、そのAIに頼りきりになると、学習速度やスキルの定着が遅れるという問題も無視できません。もしも新人がAIにすべてを任せきりにしてしまえば、時間とともに熟練者層が薄くなり、ソフトウェア開発の質全体が低下する危険すらあります。

今後どう変わるか？

将来的にAI開発支援ツールがどのように進化し、開発現場にどのような変化をもたらすかについては、いくつかの重要なトレンドが予想されます。

まずひとつ目は、バイブコーディング（AIとの対話を通じてコードを書くスタイル）の比率が確実に増加していくということです。従来はコーディング＝手を動かして書く作業でしたが、将来はプロンプトやチャットベースで仕様や目的を伝え、AIがそれをコードに変換するというスタイルが主流になるでしょう。これにより、コーディングの手段としてのテキストエディタの役割は徐々に縮小し、自然言語での設計表現力が開発スキルの中心になっていくと考えられます。

次に、複数のAIエージェントを並列で動かして作業を進めるマルチエージェント開発の普及です。たとえば、UI設計用のエージェント、API実装用のエージェント、テスト生成用のエージェントなどを同時に走らせ、それぞれが独立して成果物を生み出し、それを統合・検証するというワークフローが一般化していくでしょう。開発者はその管理者・調整者として、各エージェントのパラメータを設定し、連携の整合性を保つ役割を担うことになります。

さらに、長期的には人間が介在しない形でAIが自律的に開発を完遂するケースが現実のものになると予想されます。指定された要求やユースケースに基づき、AI同士がタスクを分担し合い、設計・実装・テスト・デプロイまですべてを実行する完全自動化開発の実現です。これはまさに「AIがエンジニアとなる」世界であり、特に単純で定型的なシステムや繰り返しの多い処理においては早期に導入が進むと考えられます。

こうした未来において、人間が担うべきタスクは大きく変化します。コーディングそのものから離れ、AIに対して設計意図や制約、期待する品質を的確に伝えることが主な業務となり、AIが生成した成果物をレビュー・承認する立場へとシフトしていくのです。このプロセスにおいては、設計・アーキテクチャ・セキュリティ・ユーザビリティといった、抽象度の高い判断力がより重視されるようになるでしょう。

したがって、今後求められるスキルは単なるプログラミング能力ではなく、「AIに適切な指示を与える力」と「AIのアウトプットを正しく評価する力」へと進化していくことになります。

将来的には、以下のような変化が予測されます：

  • AIの理解力・文脈把握能力の向上：現在の課題である「期待とズレる出力」が解消される可能性
  • ドメイン特化型AIの進化：プロジェクト特化型や業界特化型のAIによって生産性が大きく向上
  • 人間のスキルとAI支援の最適分担：ペアプロのように、人間とAIが役割分担する開発スタイルの確立

また、教育現場や新人研修では、AIを補助的に使いながらも、基礎スキルの自力習得を重視する設計が求められていくでしょう。

まとめ

現在の生成AIは、コード生成やリファクタリングなどで一定の成果を挙げている一方で、その効果は開発者の経験やタスクの性質によって大きく左右されます。特に経験豊富な開発者にとっては、AIが期待通りに動作しないことによる試行錯誤が生産性を下げる要因となるケースもあり、現時点では必ずしも万能な支援とは言えません。

しかし今後は、バイブコーディングのような対話型開発手法が一般化し、複数のAIエージェントが並列に連携して開発を進めるようなマルチエージェント環境の普及、さらにはAIのみで開発工程を完了する完全自動化が現実のものとなることが予想されます。それに伴い、開発者の役割も大きく変化し、設計意図をAIに伝える能力や、AIが生成した成果物をレビュー・承認する能力が重視されるようになります。

一方で、こうした変化が進むことで、AIに頼りきった新人開発者の自律的なスキル向上が停滞する可能性もあり、将来的な熟練エンジニアの不足という課題にもつながりかねません。したがって、AIを効果的に活用するためには、人間が主導して設計ルールやプロジェクトの基盤を作り、その上でAIを適切に運用するリテラシーと姿勢が求められます。

今後、開発の主軸が「人間がコードを書く」から「AIに設計を伝え、成果を導く」へと移っていく中で、開発者自身の役割を再定義し、育成方針を見直すことが重要になるでしょう。

AIは決して万能ではありません。少なくとも、現時点では経験豊富な開発者がAIに頼らないほうが速く、品質の高いコードを書く場面も多く存在します。AIは私たちの手を助けるツールであって、思考を代替するものではありません。

経験豊富な開発者こそがAIの本当の可能性を引き出す鍵であり、今後の開発環境・教育設計・AIツールの進化には、この点を中心に据えるべきだと私は考えます。

参考文献

モバイルバージョンを終了