Kiro開発責任者 Nathan Jones氏に聞く Spec駆動で変わる開発――Kiroの現在地とこれからのトップ画像

Kiro開発責任者 Nathan Jones氏に聞く Spec駆動で変わる開発――Kiroの現在地とこれから

投稿日時:
ファインディ編集部のアイコン

ファインディ編集部

今年7月にAmazonが発表したAIエージェント統合型IDE「Kiro」は、コーディングだけでなく、要件定義・設計・実装・統合までを支援することから、多くのエンジニアの注目を集めています。

イベントでは、実際にKiroを活用する6名が登壇し、現場での具体的な活用事例や開発体験など、ユーザー視点でのKiroの魅力が共有されました。そして、AWSでKiroの製品開発を主導するソフトウェアデベロップメントマネージャのNathan Jones 氏(@natejonesy)が急遽Q&Aセッションに参加し、AWS Japan パートナーセールスSAのKatz Ueno氏(@katzueno)が進行・通訳を担当しました。

Nathan氏へのQ&Aセッションでは、Kiroに関する70件近くの質問が寄せられ、大いに盛り上がりました。そこで本記事では、その質疑応答の様子をお届けします。6名の発表を含むイベント本編は、アーカイブ動画でも視聴できます。あわせてご覧ください。

質疑応答の様子

Kiroの現在地とこれから

Nathan氏:
私はAmazonでソフトウェア開発マネージャーを務めており、Kiroの開発チームを率いています。シアトルにいても、日本でのKiroの盛り上がりとコミュニティの拡大を耳にしていたので、実際に確かめ、皆さんの質問にお答えしたいと思い来日しました。

私の役割はエンジニアリングチームの立ち上げです。エンジニアが数名とPoCしかない段階で参画し、優秀なエンジニアの採用、プロダクトと技術の方向性の策定、そして今日のようなイベントを通じてコミュニティと関わり、顧客のフィードバックを集め、プロダクトの成長を後押ししてきました。

現在、Kiroチームでは、できるだけ多くの人にKiroを使ってもらうことに注力しています。リリース後の最初の数週間は、可用性の確保とサービスのスケールに注力し、クライアントやサービスを効率化して、可能な限り多くのユーザーに提供できる基盤を整えました。最良の体験を保つためにウェイトリストを導入し、順次、アクセス可能なユーザーを拡大するとともに、有料プランを追加してアクセス権のあるユーザーがより活用できるようにしています。体験向上と価値提供のため、構造的な変更について寄せられたフィードバックにも対応しています。

現時点のKiroは「実装」、つまり実際に作る段階に強くフォーカスしていますが、私たちはソフトウェア開発ライフサイクル全体を見据えています。すなわち、まだ何を作るか定まっていないアイデア段階から、プロダクトとアプローチの検討、実装、そして統合までを対象としています。コードはコードベースに統合され、デプロイされて初めて価値を持つと考えているからです。将来的には、このすべてのフェーズでAIツールを活用できるようにしていきたいと考えています。

Q&A

Q. Kiroは仕様(Spec)駆動開発に優れていると感じていますが、作成したSpecをKiro自身に実装させるか、Specを読み込ませて別のCLIエージェントに任せるか迷っています。実装におけるKiroの優れている点を教えてください。

A. この質問はよくいただきます。Kiroが生成した仕様(Spec)を使って他のツールで実装を進める方もいますが、その方法ではKiroの強みを多く失ってしまいます。Kiroは実装中の呼び出しパスを深く理解し、予測できます。これによりプロンプトを効果的にキャッシュでき、パフォーマンスと効率の向上につながります。

要件と設計をより深く理解しているからこそ、バリデーションも継続的に改善されます。実装の進行に合わせ、出力が元の要件を確実に満たすようエンジンを進化させていきます。現時点でも、Kiroで一貫して進めることでパフォーマンス面のメリットがあります。


Q. Kiroは仕様などの情報をMarkdownで記載する前提だと思いますが、必要に応じてセンシティブ(機微)な情報を含めたい場合はどう対応すべきでしょうか。

A. Spec自体に機微な情報を含めることはおすすめしません。機微性は「コードベースに含めてもよい」とあなたが許容できる範囲に限定すべきです。ソースコードやリポジトリへのアクセス保護があるとしても、ソースコードより機微な情報は含めないでください。

Specは本質的にエージェントへのプロンプトです。機能が実装されるまで一時的に扱うことはできますが、Specに機微情報を入れると、コードベース全体の機微性(取り扱いリスク)を引き上げてしまいます。

例えば、個人の健康記録を保存するシステムを設計している場合、Specに実際の健康情報を含めるのではなく、匿名化(マスキング)した例や、代表的なダミーデータを用いましょう。


Q. レガシーコードが多い開発環境の中で、Kiroをどのように活用すればよいでしょうか。

A. 理解が難しい大規模・レガシーコードベースを扱う際には、まず「Vibeモード」を使って質問・探索・デバッグを行い、コードベースの全体像を把握するのが有効です。コードベースの理解がある程度進んだら、「Specモード」に移行し、より大きな機能構築に取り組みます。

実装プロセスを、要件記述・設計・実装の3つのフェーズに切り分けて考えるのが有効です。まずは要件定義――レガシーコードを完全に理解していなくても、開発したい機能を記述できます。そして、エージェントの真価は「設計フェーズ」で発揮されます。パッケージやコンポーネントを探索し、記述された機能をどのように実装するかを決めるのに役立ちます。エージェントの探索能力を活用することで、提示した問題に対する最適なアーキテクチャを検討できます。

Q. Kiroをチームで使う場合、進め方やレビュー体制はどう設計するのが有効でしょうか。

A. チームでKiroをどのように活用するかは、私たちも非常に重視している点です。他のツールでは、エージェント型のツールを導入するとパワーユーザーが大量のコードを生み、残りのメンバーにレビューや統合の負担がのしかかる、という話をよく耳にします。こうした不均衡は、AIツールを使っていないエンジニアにしわ寄せが行きがちです。Kiroではこの偏りを避け、パワーユーザーとそれ以外のメンバーの体験の差が生まれないよう、チーム全体の体験を向上させることを意図して設計しています。

この記事のつづきを読もう
新規登録/ログインしたらできること
  • すべての記事を制限なく閲覧可能
  • 限定イベントに参加できます
  • GitHub連携でスキルを可視化
ログイン
アカウントをお持ちでない方はこちらから新規登録