今年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ではこの偏りを避け、パワーユーザーとそれ以外のメンバーの体験の差が生まれないよう、チーム全体の体験を向上させることを意図して設計しています。
また、個人の学びをみんなの利益に還元しやすくしたいとも考えています。エージェントをうまく扱えるようになるまでの学習曲線が急であるため、私たちが仕様駆動開発のワークフローを用意している理由のひとつはそこにあります。
Specは、良い結果を生み出すワークフローに対して構造とガイダンスを提供します。効果的に使う方法を学ぶにつれて、その知見をリポジトリに保存されるSteeringファイルやエージェントフックを通じて共有でき、ワークフローをさらに効果的にできます。つまり、誰かがKiroをより上手に使えるようになるほど、チーム全体が恩恵を受けられます。
最後にTipsをいくつか紹介します。エージェントとの新しいセッションを開始するたびに、Git（またはお使いのソースコード管理）で新しいブランチを作成することをおすすめします。エージェントのアクションごとにコミットし、コミットメッセージに使用したプロンプトを含めるとよいです。
作業が完了したらプルリクエストを作成し、Specの内容をGitのプルリクエスト形式で要約させるようエージェントに依頼することも可能です。これによりチームに情報が共有され、コミット履歴を通じてどのプロンプトが使用されたかを確認できるため、エージェントとの協働方法に関する学びを共有しやすくなります。
Q. 私はセキュリティエンジニアです。社員がKiroを活用するにあたって気をつける点はありますか。
A. Kiroをセキュリティの観点から利用する際は、プロンプトや追加のコンテキストとして提供する情報が、信頼できるソースからのものであることを確認してください。
セキュリティ上の考慮点や信頼境界（トラストバウンダリ）については公式Webサイトで案内しています。たとえば、信頼できるワークスペースの確保、有効化するMCPツールの精査、追加コマンドを信頼するかどうかの判断などが掲載されています。
Q. 以前、Q Developer IDEがKiroに統合されるという話を聞きました。Q Developer IDEの扱い・使い分けや、Kiroとの棲み分けについて考えがあれば教えてください。
A. Q DeveloperとKiroのチームは、組織的に密接に連携しています。Q Developerには長い歴史があり、特にQ CLIなど、多くのユーザーに愛用されている機能がたくさんあります。これら2つの製品を統合し、ひとつのまとまりのあるポートフォリオのように感じられる方法を検討しています。
正確なアプローチについてはまだ多くの検討が必要なため、現時点で具体的な答えはありませんが、頻繁に議論を重ねている課題のひとつです。
Q. AWS Organizationsに紐づけて支払い、利用できるようなプランはありますか。
A. 現在、料金プランの選択肢と課金・請求関連の機能を拡充すべく取り組んでいます。個人ライセンスは中小企業（SMB）やエンタープライズには適していないため、より大規模なチームでも柔軟に使える形にしたいと考えています。
Q. 「コーディングエージェント戦争」の時代に、AWSがコーディングエージェントを作る理由を教えてください。
A. 私たちの目標は、エージェントツールをより簡単に活用できるようにすることで、ソフトウェアの作り方そのものを変えることです。私のキャリアにおいて、持続可能なソフトウェアの秘訣は、数年後に初めてそのアプリケーションを見るエンジニアにも、意思決定の理由を「機械が理解できる言語」で明確に伝えることだと考えています。私たちは、直感的な体験と、ソフトウェアがどのように構築されたかの理由を説明する、長く残る成果物を提供したいと考えています。
Vibeコーディングで見られた現象として、私たちの専門分野の多くの「基礎」が後退してしまった点があります。ひとりが単独で、「何」を作るか、「なぜ」作るかについて深く考えることなく多くの小さな判断を独断で積み重ね、協働がほとんどない状態です。Kiroでは、エージェントツールが登場する以前に行われていた、協調的で効果的な作業モデルを取り戻したいと考えています。
Q. AWS内でKiroはどの程度使われていますか。どの職種が主に使っていますか。
A. 社内ではさまざまな職種のメンバーがKiroを使っていますが、主な対象はエンジニアやソフトウェア開発に関わる人たちです。Kiroチームは、Kiroの開発にKiroのみを使用しています。リリース前に自分たちのチームがKiroを使うことで、これまで不可能だった機能を実際に構築できるようになることを確認したかったのです。
将来的には、コード記述にとどまらずソフトウェア開発ライフサイクル全体を見据えているため、さらに多くの人がKiroを使うようになるでしょう。要件定義にはエンジニアだけでなく、プロダクトマネージャー、デザイナー、ビジネスリーダーも関与すべきです。ソフトウェアづくりのあらゆる側面でのコラボレーションをKiroが支える存在にしたいと考えています。
Q. Kiroのウェイトリストはいつ頃解消されますか。
A. “Soon.”（もうすぐです）
アーカイブ動画
イベント本編は、アーカイブ動画を公開しています。あわせてご覧ください。
▼動画はこちら
※動画の視聴にはFindyへのログインが必要です。