今年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に実際の健康情報を含めるのではなく、匿名化（マスキング）した例や、代表的なダミーデータを用いましょう。