re:Invent 2025: KiroによるAIエージェント活用のソフトウェア開発変革とspec-driven development
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖re:Invent 2025: AWS re:Invent 2025 - Reinventing software development with AI agents (INV205)
この動画では、AWSのDeepak SinghがKiroを中心としたAI駆動のソフトウェア開発の変革について解説しています。Kiroはspec-driven developmentを採用し、自然言語のプロンプトから要件、設計、テストを自動生成します。property-based testingにより数百のテストケースを自動生成し、コードの正確性を検証します。Kiro CLIはターミナルでのエージェント活用を可能にし、カスタムエージェントによる並列処理で開発を加速します。Kiro Powersは各種ツールとの統合を簡素化し、Kiro autonomous agentは常時稼働してバックグラウンドでタスクを自律的に処理します。AWSのBedrockチームは6人で76日間、当初30人で12-18ヶ月の見積もりだったプロジェクトを完了し、20倍の生産性向上を達成しました。Deltaの事例では、開発時間の短縮だけでなく、プロダクトデリバリーライフサイクル全体の最適化に取り組んでいます。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
Kiroがもたらした開発体験の変革：ユーザーの声
Kiroを使う前は、構文の細部にとらわれてしまったり、異なるコードリポジトリ間でプログラミング言語を切り替えたりすることに苦労していました。変数の宣言方法といった基本的なことでつまずいていたのですが、Kiroが代わりにやってくれるんです。私たちは今、これまでにない方法で、コードやビジネス、要件を理解し、対話し、定義できるようになりました。小さな隠れたセミコロンを探すために何時間もデバッグに費やす日々は終わりました。Kiroはプロセス全体を通して私を助けてくれます。
私は10代前半からコーディングを始めましたが、初めてコードを書いて無事に実行できたとき、大きな喜びを感じました。Kiroはその輝きを取り戻してくれると感じています。ゼロからコードを構築するという通常のやり方では何週間もかかっていたでしょうが、Kiroを使えば、わずか3日間でゼロからヒーローになることができました。Kiroはプロセス全体を通して私と一緒にいるパートナーです。質問を投げかけ、開発を始め、仕様を作成し、Kiroを使いながら学んでいます。
私はこの大規模なシステムに新しい機能を追加しようと取り組んできました。Kiroは最初から最後まで、アイデア出しから、実際の要件、タスク、実行に至るまで、私を助けてくれています。最も退屈な部分、つまりキーストロークのタイピングなしに、アイデアを現実にすることができます。異なる視点を与えてくれて、正直なところ、思いついたことは何でもできるようにしてくれます。私はKiroの最大のファンだと確信しています。
AI駆動開発の新時代：Deepak Singhによる基調講演の幕開け
それでは、AWSのVice President of Developer Agents and ExperiencesであるDeepak Singhをステージにお迎えしましょう。おはようございます。本日はご参加いただきありがとうございます。私の名前はDeepakで、AWSのDeveloper Agents and Experiences Organizationを統括しています。今ご覧いただいたように、そしてこのカンファレンス全体を通じてお聞きになったと思いますが、開発者にとって、そして人工知能を扱う者にとって、今は信じられないほどエキサイティングな時代です。
ここ数年、私たちはソフトウェアの構築方法における大きな変革を目の当たりにしてきました。コーディングアシスタントを使ったシンプルな自動補完から、一度に完全なアプリケーション、複数ファイルのアプリケーションを書くことができる高度なAIエージェントへと進化しました。それらは推論し、計画を立てる手助けをし、ソフトウェアを実装してくれます。そして通常、必要なのはシンプルな自然言語のプロンプトや1、2枚の図だけです。
かつては数日かかっていたリファクタリングプロジェクトが、今では数時間で完了するようになりました。デバッグセッションも、先ほどの例でご覧いただいたように、数分で済ませることができます。以前は数ヶ月かかっていたプロジェクトが数週間で完了し、数週間かかっていた機能が今では週末一回で実装できるようになっています。私たちは急速に、agentic AIが単にコードを速く書けるようにするだけでなく、実際に協働するアシスタントとなる世界へと移行しています。
エージェントと一緒に作業することで、これまでとは違う種類のフロー状態を実現できるようになります。作業を続けながら、まるで第二のアシスタントが隣に座っているかのように、強力な頭脳があなたをサポートし、はるかに速く前進できるようになるのです。この頭脳は、目にするコード一行一行から学習します。パターンや改善の機会を認識し、インタラクション、コミット、デプロイメントのたびに賢くなっていきます。
これが今日のエージェントが私たちに提供してくれるものです。ソフトウェアを提供する新しい方法を可能にするスーパーパワーと呼んでもいいでしょう。イノベーションを大幅に加速させます。私たちはこれを毎日目の当たりにしています、Amazonでも、お客様のところでも、特にスピードと差別化が絶対的に重要な世界においてです。この変革は非常に目覚ましいものでしたが、それでもまだ初期段階のように感じられます。
EC2ローンチの記憶：クラウドがもたらしたエンパワーメント
振り返ってみると、2006年8月のことを思い出します。挙手をお願いします、2006年8月に何が起こったか覚えている方はいらっしゃいますか？ それはEC2がローンチされた時です。EC2は2006年8月にベータ版として登場しました。当時私はAmazonにはいませんでした。バイオインフォマティクス企業でバイオインフォマティシャンをしていて、数ヶ月前にS3が出た時に設定したS3アカウントをすでに持っていました。そして私は最初のEC2インスタンスを起動しました。
その数日後のある晩、ふと思い立って、当時の上限だった20個のEC2インスタンスを立ち上げ、タンパク質の二次構造アルゴリズム、シンプルな単層フィードフォワードニューラルネットワークを実行して、いくつかのタンパク質配列の二次構造を予測しました、ただやってみたかったからです。 それは本当に魔法のように感じられました。それまで感じたことのないような力を与えられた気がしました。そしてその2年後には、その体験があまりにも素晴らしかったので、私はAWSに入社しました。
このようなエンパワーメントは、私の周りのビルダーたちが毎日体験していることであり、ソフトウェア開発者として得られるエンパワーメントは、おそらく15年から20年に一度のものです。
開発者の役割の進化：ビジョンと実行の間の摩擦を取り除く
開発者であることは、非常に特別な役割です。意味のあるソリューションを構築し、技術的な境界を押し広げ、最先端のクラウドテクノロジーを活用してお客様を支援する優れたソフトウェアを作ることができます。しかし、それは同時に非常に困難でもあります。皆さんは、すべての人のために機能を構築し続けたい、イノベーションや情熱、充実感を刺激することをしたいと思っていますが、退屈で単調な作業に行き詰まることもよくあります。それらは悪いことではなく、重要なことですが、やらなければならないのです。
AWSでは、私たちのミッションはAIの力を活用して開発者をエンパワーすることであり、私たちがやりたいことは、ビジョンと実行の間の摩擦を取り除くことです。皆さんには思考のスピードで創造してほしいのです。かつては想像もできなかったような、あるいは他のことで忙しくて常に後回しにしているようなブレークスルーを達成してほしいのです。開発者の環境は急速に進化しており、私たちの目標は、この変革をナビゲートするお手伝いをすることです。
非常に長い間、構築する唯一の方法は、ほとんどの作業を自分で処理することでした。皆さんの中には、すべてのコード行を書き、問題をデバッグし、ドキュメントを更新し、依存関係を管理し、そしてデプロイメントを進めなければならなかった時代を覚えている方もいるでしょう。今日、AIエージェントは2つの方法で支援してくれます。重要なことに効果的に時間を使えるよう支援してくれるのです。退屈なタスクをオフロードしてくれます。つまり、やらなければならないことがたくさんあるけれど、他のことで忙しい場合、それらをAIに任せることができます。あるいは、先ほど申し上げたように、AIと協力して、本当に気にかけていることを加速させることができます。つまり、自分自身で注意を払いたいことです。最終的には、自分にとって重要なこと、理想的には革新的なアイデアを実現することに集中できるのです。
この人間とエージェントの協働の台頭により、過去数年間でいくつかの非常に重要なパターンが明らかになりました。私たちは、AIがコードの塊を生成することから始めました。最初は一度に1行か2行だけでしたが、複数行、複数ファイルへと進化しました。今日では、エージェントと人間が協力でき、そしてますますエージェント同士がより大規模で複雑なタスクで協力するようになっています。ですから、皆さんの役割は、エージェントに適切なコンテキスト、適切なツールセット、適切なインプットを与え、皆さんだけができる人間の判断とガイダンスを提供することなのです。
開発者には、最初の計画段階からテスト、デプロイメントに至るまで、ワークフロー全体にこれらのAI機能が組み込まれている必要があります。おそらく私たちが得た最も重要な洞察は、ソフトウェア開発を真に変革するためには、エージェントにアクセスできるだけでは不十分だということです。AIが最初から最後までどのように組み込まれるかを考える必要があります。つまり、コーディングだけでなく、アーキテクチャの決定をどのように形作るか、エッジケースをどのように特定するか、フロー全体を通じてベストプラクティスをどのように維持するか、ということです。
これらの教訓は刺激的で、私たちが働いている場所でチームを見たり、お客様を見たりすることで得られます。これらは、開発者ツールの未来について私たちがどう考えるかを刺激してくれます。統合されたAIソリューションと統合されたAI開発体験を構築するための私たちのビジョンを形作っているのです。これは未来のトレンドではありません。今まさに起こっていることです。6ヶ月前は未来のように感じられましたが、AIとエージェントの世界における6ヶ月は、ほぼ6年のようなものです。最も成功している開発者たちはすでにそれを受け入れています。
生産性の格差を生む要因：マインドセットのシフトとソフトウェア開発の再定義
私はよく、彼らは救命具なしでオリンピックプールに飛び込んで、これを解決してみせると言っているようなものだと言っています。そして実際に解決しているんです。これらの開発者と話す中で、私たちは非常に興味深いことに気づきました。これらのツールを使い始めて10%、15%、20%の生産性向上を見ている開発者もいます。一方で、5倍、10倍もの生産性向上を達成している開発者もいます。彼らは同じツールを使っているんです。では、何が違うのでしょうか?
その違いはますます明確になってきています。それは単にAIツールを使うことではありません。それはただのツールです。ツールをどう使うか、どのように自分自身をより速く動かすかということなんです。ソフトウェア開発へのアプローチを根本的に変えることで、そこに到達できます。最も成功しているソフトウェア開発者たち、そして私たちは彼らが実際に活動しているのをよく見る機会があるのですが、彼らはプロセス全体を再考し、ソフトウェア開発のプロセスについてチームがどう考えるかを再考し、AIエージェントを協力者として使い、常に彼らと協力してこのような驚くべき結果を達成しているのです。これはマインドセットのシフトですが、そのレベルの改善を得るためには、それが必要なのです。
私はEC2について話しました。クラウドコンピューティングは、インフラストラクチャについての考え方を変革しました。もはやハードウェアをラックに積み上げる方法について考える必要はなくなりました。Agentic AIは、このコードファーストの開発から私たちを解放しています。コードファーストで考えることは悪いことではありませんが、コードの開発方法が変わっているのです。私は自由時間にミュージシャンをやっています、ひどいものですが、Ableton Liveというソフトウェアがあります。使ったことがある方なら、
これは非線形な開発方法を持っており、従来の他のソフトウェアが行っていた標準的な左から右へのテープトラック方式でソフトウェアや音楽を構築する方法から離れることができます。これはソフトウェアと音楽、そして音楽の作り方を完全に革命化しました。AIエージェントはソフトウェアに対して同じことをしています。私たちは非常に、非常に急速に、自然言語による意図や画像、図、疑似コードといった意図が動作するソフトウェアになる世界に向かって進んでいます。それはソフトウェアを構築するために必要なツールがかなり異なって見える世界です。
私が考えるに、必要なのはコードエディタではなく、より会話的なコンテキスト管理システム、つまりエージェントが必要とするものを駆動し書き留め、目的地に到達するためにその動作を駆動するのを助けるものです。ほとんどプログラミング言語でキーボードをタイピングするよりも、AIエージェントの作業を監督し、管理し、レビューすることに多くの時間を費やすようになります。これについて考える別の方法は、初期のコーディングアシスタントは単なるツールだったということです。エージェントは単なるツールではありません。コードベース全体をリファクタリングし、複数ファイルの変更を管理できます。開発者としてのあなたの役割はもはやタイピングだけではありません。これらのエージェントをオーケストレーションしているのです。そしてそれはすぐに起こることではありません。学ぶ必要があります。
エージェント、ソフトウェアエンジニアリングの技術は進化しています。ソフトウェアエンジニアリングは実践することで学ぶ技術です。はい、大学のコース、学校のコースがそれを教えてくれます。言語を学ぶでしょう。しかし本当に優れた開発者になるには、長期間それを実践しなければなりません。私たちは多くの人々がこれを学び、この技術を再学習し、ソフトウェア開発者として、システム思考者として学んだことを取り入れ、それをエージェント的なソフトウェア開発に適用しているのを見ています。これはソフトウェアの構築方法の計算における変化です。
ですから考えてみてください、チームの規模、チームの構造、開発速度、技術的負債についての考え方。これらすべてが今後数ヶ月、数年とさえ言いません、数ヶ月で再形成されるでしょう。そしてそれが再形成されるのは、ソフトウェアを異なる方法で構築するようになるからです。チームとチームがソフトウェアを構築する方法へのアプローチが変わるため、変化するのです。そして何が可能かについての考え方が変わります。あるいは二日前のMatt Garmanの言葉を言い換えれば、why notです。では、この変化が実際に何を意味するのか説明させてください、数秒前に言ったように。
Spec-driven developmentの誕生：Kiroが実現する構造化されたAI開発
ソフトウェア開発者は職人です。極端に言えば、多くの人々はコードの一行一行を細心の注意を払って書くこと、コードの構造、画面上での見え方、これらのツールをどのようにオーケストレーションし開発のあらゆる側面を自分で管理するかに誇りを持っています。しかしそれには課題が伴います。コードを書いているとき、ソフトウェアを構築しているとき、重要な決定、戦略的、アーキテクチャ的、ビジネス的な決定が後になって出てくることがあり、戻ってコストのかかる変更を行わなければならないことがあります。
このAI agenticパラダイムは、ある意味これを逆転させるものです。開発者として、こうした高価値な戦略的アーキテクチャやビジネス上の意思決定、そしてデザインチームやプロダクトチームと行うかもしれない議論を、前倒しで行うことができます。そしてAIエージェントと協力して、その影響がどうなり得るかを探索していくわけです。トレードオフを本当に素早く検討できます。なぜなら、プロトタイプを非常に速く構築できるからです。コードを一行も書く前にでもできますし、自分のメンタルモデルを正しく理解するため、考えが正しいか確認するために、簡単なアプリケーションを書くこともできます。この一部は、すべての実行がエージェント自身によって処理されているということです。
これは単に抽象化のレベルを上げたということではありません。ソフトウェアの世界では数年ごとに新しい抽象化レイヤーを考え出そうとしますよね。そうではなく、開発者がシステム全体を総合的に考え抜き、実装の詳細があなたのビジョンと整合していることを確実にできるようにすることなんです。頭の中にあるものを、一定期間メンテナンス可能な実行可能なアプリケーションにどう変換するか。私たちが見てきたこと、観察してきたことは、こうした豊かな技術的会話、なぜそもそもやりたいことをやるのかという会話が、前もって行われるということです。
そして目標は、エージェントを駆動して望む場所に到達させる方法になります。そこで5倍、10倍の開発者生産性の向上が得られるわけです。これは単にコードの書き方を変えるということではありません。ソフトウェアの作り方を変えるということで、開発者は好きなポイントから参加できます。コンセプトを書くところから始めることもできます。プロダクトマネージャーやデザイナーがコンセプトを考え出して、プロトタイプと一緒にあなたのところに持ってくることもできます。そうすると、あなたの仕事は、親しみやすいご近所のエージェントの助けを借りて、それを動作するソリューションにどう変換するかになります。
その代わりに、ご存知のように、AWSでも歴史的にはproduct press releasesとFAQsを使って機能を開発してきましたが、新しいソフトウェアが構築される方法として非常によくあるのは、誰かが数時間離れて作業することです。プロダクトマネージャーかもしれないし、開発者かもしれないし、数年コードを書いていないdev managerかもしれません。
そして彼らが素早く仕様、設計、プロトタイプを作り上げ、それから皆でレビューして、ええ、これなら今後数日で構築できるとわかるわけです。これが常に起きているのを目にしています。これはかなりの変化です。簡単ではありません。技術的な変化ではないんです。結局のところ、ソフトウェアを構築していることに変わりはありません。そのソフトウェアをどう構築するか、それを構築するためにどう組織するか、何に慣れるか。そういったすべてが変わり、アイデアから実装までの前例のないスピードが得られます。今日はその例をいくつかご覧いただけると思います。
このAIコーディングワークフローの流れは本当に素晴らしいですね。非常に素早く始めることができます。私は息子に太陽系の仕組みやマクスウェル方程式のような科学的なことの例を見せるためだけに作ったアプリケーションの数を数えるのをやめました。なぜかは聞かないでください。しかし、これらのタスクがより複雑で曖昧になってくると、エージェントとどのように対話するかだけでは限界があります。システムレベルで考え始める必要があるのです。多くの場合、システム思考はシニアエンジニアになって初めて行われます。私は、ジュニアエンジニアであっても、特定のソフトウェアを書いている、コードを書いているという側面からではなく、自分のシステムがどのように動作するのか、なぜこれを構築しているのか、どのようなコンポーネントが必要なのかという観点から考え始める必要があると主張します。そして、エージェントと協力して目的地に到達するのです。もはや実際のコーディングプロセスの細かい部分について考える必要はなく、それは一部の人々にとって大きな変化なのです。
また、特にこの6ヶ月から9ヶ月の間に発見したことですが、人々がAIエージェントを使い始めると、かなり快適に感じるようになりました。エージェントと話し始めたり、彼らが呼ぶところのバイビングをしたりするようになったのです。バイビングという言葉、私たちはTikTok世代に生きていますからね。バイビングはほぼ流行遅れになったと思います。なぜ出てきて消えたのかわかりませんが。しかし、同時にますます明確になってきたのは、私のお気に入りの例は、アプリを構築して10日後には、そのアプリがなぜそのような動作をしているのか、どんなプロンプトを書いたのか全く覚えていないということです。そして、それを他の誰かに渡すと、すべてのコンテキストが完全に失われてしまいます。ですから、書き留めた設計決定からドキュメンテーションやテストに至るまで、常に監視が必要だったのです。
そして私たちが自問したのは、このプロセス全体をはるかに簡単にするために使える、より構造化されたフレームワークはないだろうか、6ヶ月後に思い出すのに役立つ成果物や、別のチームに引き継ぐときに、なぜそうしたのかを理解してもらい、コードを見るだけでなくそこから続けていけるようにできないだろうかということでした。AIを使って保守可能なソフトウェアを構築するために、非常に成熟したソフトウェアエンジニアリングの実践からどのように教訓を得られるだろうか。そして、それが私たちがKiroを構築した理由であり、spec-driven developmentと呼ぶものを構築した理由です。Kiroのアイデアは、spec-driven developmentのアイデアとコンセプトを用いて、成熟したソフトウェアエンジニアリングの実践をAI駆動のコーディングにもたらすことで、開発者とチームが最高の仕事をできるよう支援することです。では、それは何でしょうか？
Kiroの仕組み：プロンプトから動作するアプリケーションへ
その方法は、アイデアから機能するアプリケーションに移行したいわけですが、そのアプリケーションはそこから進化していくことも分かっています。別のチームに移るかもしれません。コンポーネントを追加するかもしれません。エンタープライズグレードの管理を必要とする会社の一部かもしれません。私たちは、個人の開発者から大企業の非常に大きなチームまで、これらすべての人々がこれらのコンセプトを使用でき、AIを使って構築できるようにしたかったのです。
Kiroの動作方法は、シンプルな一連のプロンプトから始めることができます。これらのプロンプトを明確な要件と構造化された設計のセットに変換できます。プロンプトは自然言語である必要はありません。画像でも構いません。図でも構いません。疑似コードでも構いません。あなたの頭の中にあるもの、それをどう表現するか。プロダクトマネージャーが行うこともできます。デザイナーが行うこともできます。ソフトウェア開発者が行うこともできます。そしてKiroはあなたと協力して、これらの仕様を動作するコード、動作するドキュメンテーション、動作するテストに変換します。
Kiroにはagent hooksという機能があります。あまり話題にしていない機能ですが、Kiroの最も便利な機能の一つです。Agent hooksはバックグラウンドで日常的なタスクを自動化します。そしてagent hooksで何ができるかというと、開発のベストプラクティスを自動的に適用することができます。そしてKiroは基本的にマルチモーダルです。スマートなコンテキスト管理があり、皆さんが望む方法で作業を続けられるようサポートします。そしてClaude Sonnet 4.5、Opus 4.5といったフロンティアモデルにアクセスできるので、選択することができます。品質が欲しいかもしれませんし、スピード、コスト、これらすべてが開発者である皆さんが考慮する要素です。
では最終的に何が得られるかというと、かつてvibe codingと呼んでいたものの親しみやすさと楽しさが得られます。エージェントと話すだけでいいんです。
非常に素早く始められますが、より強力でメンテナンス可能なコードと、それを実現する開発者体験が得られるので、プロジェクトの規模や複雑さに関係なく、どんなプロジェクトにも取り組むことができます。このspec-drivenアプローチは多くの開発者の心に響きました。Kiroをプレビューでローンチしたとき、最初の5日間だけで10万人以上の開発者が集まり、それ以来、Amazon外部の数十万人の開発者がKiroを使い続けています。このカンファレンスを通じて素晴らしい例をご覧いただきました。
spec-driven developmentは何がそんなに便利で強力なのでしょうか？Kiroがプロンプトで構築する成果物の一つが要件ドキュメントです。ES記法で書かれています。ESに馴染みのある方なら、markdownベースの構造化された要件の書き方だとわかるでしょう。Kiroはそれらの要件からプロパティを抽出できます。これが私がspecを愛する理由です。これらのプロパティから、論理的にテストする必要があるものを判断し、コードをチェックするために数十万のランダムなテストケースを生成します。一連のプロンプトで表現した意図がspecに変換され、最終的に出てくるアプリケーションとコードで実際に望んだ通りに動作しているかどうかを把握するのに役立ちます。
例を見てみましょう。車の販売アプリを構築しているとします。従来のユニットテストアプローチでは、ユーザーが車番号5をお気に入りに追加し、車番号5がリストに表示される、というユニットテストを行うでしょう。もう少しユニットテストを追加するかもしれません。このproperty-based testingアプローチでは、Kiroの動作方法として、要件を書きます。それは「任意のユーザーと任意の車のリストに対して、車がお気に入りに追加されたとき、お気に入りリストにその車を表示する」といったものになります。それがESがサポートする特定の言語でESに変換されます。そしてKiroが行うのは、一連のテストを抽出して構築することです。ユーザーAが車番号1を追加、ユーザーBが車番号500を追加、ユーザーCが5台の車を追加、ユーザーDのユーザー名に特殊文字が含まれる、といったものです。様々なステータスの車があるかもしれません。新車、中古車、認定中古車など、これらすべて、エッジケースをキャッチするのに役立つ数百、数千のより多くの組み合わせです。これらは自動的に生成され、自動的にテストされ、皆さんが行っているのは、最終的に出てくるコードとソフトウェアが頭の中にある意図と一致しているかを検証することです。
これは非常に強力な機能で、ソフトウェア検証に向けた最初のステップに過ぎません。昨日、Swamiの基調講演をご覧になった方は、昨日だったと思いますが、re:Inventは本当にあっという間ですね、Byron CookがステージでneurosymbolicなAIについて話していたのを聞かれたと思います。specに構造があるため、neurosymbolicな手法を適用し始めることができ、それによってコードが意図した通りに動作していることを確認できるようになります。そしてそれこそが、AIエージェントに対する信頼を構築する方法なのです。それが光の速さで進める方法です。
Kiro CLIの登場：ターミナルで実現する高度なエージェント機能
開発者は気難しいものです。IDEが好きな人もいれば、ターミナルが好きな人もいます。私たちはKiroをIDEとして多くの時間を費やして説明してきましたが、シェルに座ってトラブルシューティングやソフトウェアを書いている皆さんのために、このエージェントをターミナルに配置することもできます。それは非常に自然な場所ですので、それがKiro CLIで得られるものです。お気に入りのターミナルでKiroエージェントのパワーを手に入れることができます。どのターミナルにも配置でき、複数で使用することもできます。Kiro CLIは、IDEからコンテキスト、ステアリングファイル、MCP設定を引き継ぎます。ターミナル内でプロンプトからデプロイメントまで正確にシフトするのを助け、ターミナルのシンプルさとエレガンスを手に入れることができます。ライトセーバーではないことは保証しますが、そうだったらいいのにと思いますけどね。
ターミナルは、私が一緒に仕事をしてきた最も成功している開発者の中で、AIを使用する際に好んで使う環境であり、Kiro CLIは彼らにそこに到達するパワーを与えます。Kiro CLIはコードベース全体の情報を使用します。複雑なコードベースで機能を構築するのを助けます。数秒でワークフローを自動化し、エラーを分析し、バグを追跡し、修正を調整することができます。そしてターミナルで行っていることは、バックエンドでこの高度にインタラクティブなループを駆動しています。エージェントがあり、Kiroエージェントはたまたまストランドで書かれているので、このエージェンティックなループを駆動し、CLIはそれを行うための非常に簡単な場所なのです。
CLIにいるので、自動化スクリプトを使用できます。これらすべてを自動化できます。適切なコンテキストでCLIを呼び出すシェルコマンドを自動化して、プロンプトを自動的に実行できるので、本番環境の障害をトラブルシューティングしたり、プルリクエストを生成して公開したりしたい場合、タスクがフローに戻る必要があるときは、ターミナルにすぐに戻ることができ、Kiroはリアルタイムでフィードバックに適応します。また、エージェンティックなタスクを非常に迅速に並列化するのにも役立ちます。5つの問題、10個の問題がある場合、それらを解決しようとする多数のエージェントを送り込むことができます。
また、カスタムエージェントと呼ばれるものを使用してプロジェクトを管理することもできます。特定のタスクに合わせたエージェントを作成できるので、カスタムプロンプトのセット、コンテキストファイル、ツールの権限をすべてまとめて、カスタムエージェントを作成できます。例えば、バックエンドのコーディングが大好きなエージェントを作り、別のカスタムエージェントはフロントエンドの作業を行うことができます。ここで並列化が本当にクールになります。これらを3つ並列で実行でき、1つはフロントエンドの作業を行い、1つはバックエンドの作業を行い、もう1つは他の問題を解決するための他のヘルパータスクを行うことができます。
これらのカスタムエージェントによって、Kiroは特定の分野のエキスパートになることができます。レピュテーションは必要ありません。コンテキストの劣化のリスクもありません。そしてどんなスケールでも作業できます。シンプルなbashコマンドから、本当に複雑なワークフロー、あるいは20個のエージェントを一晩中並列で実行することまで可能です。つまり、超高速でとてもパワフルなんです。
Brooke Jamiesonによるライブデモ：eコマースストアの本番環境対応化
Las Vegasは本当に乾燥していますね。私は長く話しすぎました。そろそろこれらすべてを実際に動かしてお見せする時間です。皆さんもきっと見たいですよね。そしてお見せするのに最適な人物がいます、Brooke Jamiesonです。ようこそ、Brooke。 ありがとうございます。私はこのサーバーレスのeコマースストアをAWS上に構築しました。DynamoDB、Lambda、API Gateway、一通り揃っています。でも今はプレースホルダーの商品が入っているだけです。私はストアに入れたいKiroのグッズの実際の商品写真と説明を持っていて、これをプロダクション対応にする必要があります。
Kiroはあなたの働き方に合わせて動作します。 IDEでもターミナルでも、両方お見せしましょう。まず、IDEでVibeを使ってアーキテクチャを可視化します。Kiroはインフラストラクチャファイルを読み取り、AWS diagrams MCPサーバーを使ってクラウドアーキテクチャ図を生成しています。Lambda関数、DynamoDB、S3、そしてCloudFrontがありますね。
さて、商品説明が必要です。このリポジトリにいくつかの曖昧な説明とスタイルガイドを入れておきました。Kiroは今、私のスタイルガイドを読み、利用可能な写真をチェックして、ストア用のブランドに沿った商品説明を生成しています。次はこれらの商品画像を最適化する時間です。皆さんの中にはターミナルを好む方もいるでしょうから、こちらがKiro CLIです。似た機能ですが、インターフェースが異なります。ウェブサイト用にすべての商品写真をリサイズするよう依頼します。比率を保ち、グリッドを一貫させ、高速読み込み用に最適化します。
KiroはSharpを使ったNodeスクリプトを作成し、依存関係をインストールして、38枚の画像を2つのサイズのWebPに処理しています。フル解像度とサムネイルです。同じインテリジェントなアシスタンス機能が、ターミナルで使えるんです。さて、完了しました。すべての画像が最適化されました。次は複雑な作業です。すべてのプレースホルダー商品を実際のグッズに置き換えます。これはバックエンドのデータレイヤー、seedスクリプト、 そしてフロントエンドコンポーネントに影響します。
このような構造化された開発には、Opus 4.5に切り替えて、IDEでspecモードを使います。必要なものを伝えます。実際の商品をストアに入れます。写真と説明は準備できています。本番環境の準備をしましょう。Specモードは要件の生成から始まり、何が必要かを分解していきます。複数の商品画像を処理するためのバックエンドの更新、実際のデータを使用するためのシードスクリプトの修正、そして新しい商品構造に対応するフロントエンドコンポーネントの更新です。
次に技術設計を作成しています。これがspecモードの強力なところです。8つの正確性プロパティを定義します。単に動作するかどうかだけでなく、例えば、どんな商品設定でもシードスクリプトが同一の結果を生成するとか、すべてのS3オブジェクトが正しいメタデータヘッダーを持たなければならないといった形式的なプロパティです。これらはそれぞれ、後でプロパティベーステストになります。
次に実装計画です。10個のタスクがサブタスクに分かれています。各タスクは要件と設計に対応しています。包括的に構築できるよう、すべてのタスクを必須にします。では動作を見ていきましょう。タスク1から始まります。これは商品設定ファイルの作成です。Specモードは私の商品説明を読み取り、最適化された画像フォルダから画像パスをマッピングし、価格を設定し、すべてを検証して、JSON設定を作成します。タスク完了です。では次はタスク2です。
これは商品ごとに複数の画像を処理するためにデータアクセス層を更新します。そしてここが重要な部分です。プロパティベーステストを書きます。このテストは1つの商品だけをチェックするのではなく、異なるID、カテゴリ、データ構造を持つ100個のランダムに生成されたシナリオ全体で、すべての必須フィールドが存在することを検証します。では、重要なところをお見せするために先に進みます。タスク9、最終検証です。タスク9では2つの重要なプロパティベーステストを書きます。プロパティ7はシードの再現性をテストします。
データベースをリセットして再シードした場合、毎回同一の結果が得られることを検証します。プロパティ8は設定駆動型の価格設定をテストします。設定ファイルで価格を変更したとき、それらの変更がシードされた商品に正しく反映されることを検証します。これらは単に1つのシナリオをテストしているだけではありません。各プロパティテストはランダムに生成されたデータで100回の反復を実行します。このタスクだけで200のテストケースがあり、システムがあらゆる条件下で正しく動作することを検証しているのです。
最終的には、すべてをカバーする8つのプロパティベーステストができました。そして今、すべてのタスクが完了し、すべてのテストが通っています。こちらがライブストアです。実際の商品があり、新しいカテゴリーと最適化された画像、複数の画像とサムネイル検証があります。でも待ってください、この画像が少し切れているので、Vibeに戻って素早く修正しましょう。Kiroが私が貼り付けたスクリーンショットを分析し、コンポーネントを見つけ、問題を特定しました。それは間違ったCSSといくつかのパースが必要な箇条書きでした。今は修正されました。ですから、あなたの働き方で作業してください。探索とクイックフィックスにはIDE内のVibe、ターミナルで作業するならCLI、そして構造化された開発とプロパティベーステストにはSpecモード。アーキテクチャ図から本番環境対応のストアまで、それがKiroです。
Amazon Bedrockチームの成功事例：6人で76日間の驚異的な開発
Deepak、お返しします。ありがとう、Brooke。私は注目すべきストーリーを共有したいと思います。今週何度か聞いたことがあるかもしれませんが、とにかくもう一度共有します。AWSのチームの一つがKiro CLIを使って開発プロセスを完全に変革した話です。AWSのdistinguished engineerであるAnthony Liguriが、Amazon Bedrockの推論エンジンを再構築するよう依頼されたとき、当初の見積もりでは、30人の開発者のチームがこのBedrockの非常に重要なコンポーネントを構築するのに12から18ヶ月かかるというものでした。チームは12から18ヶ月では十分に速くないことを知っていました。彼らはもっともっと速くやりたかったのです。そして、開発者を増やしても全く役に立たないこと、収穫逓減の法則があることも知っていたので、この問題を解決する別の方法を考えたかったのです。彼らはこれが非常に重要なコンポーネントであるため、システムの品質や信頼性を損なうことなくそれを実現したかったのです。
そこで彼らは開発を支援するためにKiro CLIを使いました。そして結果は本当に驚くべきものでした。わずか6人のチームが76日で当初30人が12から18ヶ月かかると見積もられていたものを提供できたのです。そのチームの開発者の個人生産性は20倍に跳ね上がりました。週次のコードコミット数は、従来のアプローチでやっていたときは開発者あたり2回のチェックインだったのが、開発者あたり40回以上のチェックインになりました。平均でそうで、チームにはさらに多くやっている人もいました。そしてそれは数字だけの話ではなく、彼らの協力の仕方、構築の仕方、彼らが作り上げた手法は素晴らしく、そして全員が楽しんでやっていました。チームの仕事満足度の評価は例外的に高かったのです。なぜなら彼らはAIにルーチンタスクを処理させることができ、開発者はKiro CLIと協力して最も複雑で難しく戦略的な問題を解決することができたからです。
しかし、それは一夜にして起こったわけではありません。最初は多くの人がAIエージェントを使うのと同じように、非常に個別のタスクで使っていました。ただ、エージェントと作業して、いくつかの仕事を与えて、何が起こるか見て、それに戻ってくる、という感じです。本当のブレークスルーは、AI機能を既存のワークフローに持ち込むのではなく、AI機能を中心に構築されたワークフローを根本的に再設計したときに訪れました。彼らは指数関数的な改善をもたらす3つの重要なパターンを発見しました。1つ目は、タスクごとの監督から目標駆動の指示に移行したことです。彼らの仕事は、達成したい目標をエージェントに与え、そしてすべてのサポート情報、ステアリングファイル、支援、彼らが何をすべきか、エージェントがそれを実行できるようにするためのより良いプロンプトを提供することでした。
次に、速度を上げるために多数の並行AIタスクにスケールアウトしました。カスタムエージェントについては先ほど話しましたが、彼らはこれらの問題を解決するために、しばしば一晩中カスタムエージェントの群れを解き放ち、朝戻ってきたときに、起こった変更をレビューしていました。そして最後に、彼らはこのAIをコーディングだけでなく、お互いにどう話すか、どう協力するか、どう協働するかから、ソフトウェア配信プロセスのあらゆる部分まで、彼らがやったことのあらゆる側面に拡張することができました。そしてそれが、私たちが話していたレベルの生産性を達成することを可能にしたのです。彼らは慎重な実験から始めて大きな成果を見始めました。そしてこれは私たちがこのチームだけでなく見てきたことです。
しかし、これらの教訓を学んだ他の多くのチームでも同様です。彼らがこれらのパターンを習得するにつれて、開発速度は基本的に、先ほどお話しした10〜15%から、このチームが現在得ている5倍、10倍、20倍へと向上しました。これまで何度かお話ししてきましたが、このレベルの成果を得られるのは、エージェントを適用して今やっている作業に追加させるのではなく、エージェントを中心に構築方法を変えた場合のみです。
Kiro Powersの発表：ドメイン特化型の専門機能を提供する新機能
小規模なチームでも従来のアプローチを劇的に上回るパフォーマンスを発揮できるため、開発者ははるかに多くのことができるようになります。実際に、たった1週間で済むのに時間がないという理由で過去10年間脇に置いていたようなことも、実行できるようになります。今ではそれを進めることができ、そのような例を毎日目にしています。Kiroは、開発者が強力なエージェントにアクセスできるときに何が可能になるかを実証しています。しかし、この基盤があっても、エージェントは自動的にあらゆるツールの使い方を知っているわけではありません。すべてのツールを正しく使う方法を知っているわけではありません。例えば、デザインを実装に変換したり、セキュリティパターンを処理したり、デプロイメントを管理したりする際に、MCPサーバーとどのように正確に連携するかを知っているわけではなく、人間の継続的なガイダンスなしでは効果が低くなってしまいます。これらはすべて学ばなければならない教訓です。
そこで私たちは自問し始めました。どうすれば助けられるだろうか？何ができるだろうか？人々、ドキュメント、wiki、どこかのブログ投稿、どこかのYouTube動画に散らばっていることが多いこの知識とベストプラクティスをどのように捉えることができるだろうか？これにより、AIエージェントが適切なコンテキストを得るために関連情報にアクセスすることが難しくなっています。MCPは開発ツールへの接続性を提供しますが、追加の設定が必要です。本当に優れたspecファイルを書く必要があることがよくあります。適切なレベルと品質のコードを最終的に得られるように、フックを書く必要があります。そうしないと、大規模なリファクタリングが必要になります。
そのため、開発者は自分たちが毎日使用するツールとエージェントが連携する必要があります。そして私たちは、どうすれば助けられるか、コンテキストを過負荷にすることなく、これらのツール接続を本当に機能させる方法について考え始めました。開発者に試行錯誤で適切なコンテキストを見つけさせるのではなく、私たちはKiro Powersというアイデアを思いつきました。そして私たちが行ったのは、独自のpowersを構築できるシステムを考案することです。しかし、私たちはまた、多くのトップテクノロジープロバイダーやツール作成者と協力して、昨日ローンチしたKiro Powersの最初のバージョンを構築しました。すぐに使い始めることができます。
これらは、最初にお話ししたように、開発者がAIに構造をもたらすことを可能にすることで、Kiroの中核的な目的を拡張します。しかし今では、ソフトウェアスタック全体にわたって、必要に応じてオンデマンドでKiroエージェントに専門的な機能やpowersを与えることができます。では、powerとは何でしょうか？それは、この特定のケースでは一連のツールベンダーによって作成されたアーティファクトのパッケージセットですが、独自のアーティファクト、MCPサーバー、specファイル、フックを作成することもできます。これらは通常、バックエンド開発、UI、オブザーバビリティ、API設計などの特定のドメインを中心にバンドルされています。
そして私たちは、汎用的なエージェントに頼ってドキュメントを過剰に読み込ませる代わりに、コンテキストと正確なツールアクセスを動的にロードする方法でこれを実現しました。そのため、クレジットやトークンの消費もはるかに効率的になっています。これは現在IDE内で利用可能です。まもなくCLIにも導入される予定で、さらに皆さんが使用している任意のIDEやCLIで利用できるようにする方法にも取り組んでいます。Kiro Powersを使うのに、必ずしもKiroだけを使う必要はありません。
それぞれのpowerは、一連のドメインおよびツールプロバイダーとのコラボレーションで設計されています。ここに一連の名前があります。 HashiCorpも含まれており、これらはFigmaを使ったUIデザイン、Supabaseを使ったバックエンドのデプロイメントや開発といった領域向けです。Stripe用のpowerもあります。これらのpowerを使って、完全なアプリケーションを最初から最後まで構築できます。各powerを組織の要件に合わせてカスタマイズできます。実際に中に入って修正を加えることができます。複数のpowerを組み合わせて、強化された機能を作成することもできます。
例えば、StripeのpowerをDatadogのpowerやDynatraceと組み合わせて、パフォーマンスとセキュリティの可観測性を備えた新しい決済アプリケーションを構築できます。新しいpowerを作成して他の人と共有することもできます。昨日からTwitterを見ているだけでも、すでに多くの人が使えるpowerを作成して、コミュニティの他のメンバーと共有しているのを目にしています。では実際に動作を見てみましょう。DatadogのKiro powerを使用します。 フロントエンドアプリケーションにテレメトリーを設定して、リアルタイムユーザーモニタリング、彼らが呼ぶところのRUMを実現します。
このpowerがインストールされたら、 新しいセッションでpowerをアクティベートします。そして起動して実行できるようになったら、これらのRUMメトリクスの追跡を開始するために、アプリケーションにクライアントサイドのロジックを追加するようKiroに依頼します。 私のセットアップでは、アプリケーションに一連の環境変数を提供するための環境も用意する必要があります。 これが設定されると、誰かがボタンをクリックしたり、カートに新しい商品を追加したりするたびに、Datadogがイベントを生成します。
でも、どうでしょう？いくつかのエラーが出始めています。 それがDatadogが表示するはずのものです。確認してみると、カートに追加するページがエラーを引き起こしていることがわかるので、この問題を素早く解決したいと思います。 KiroにエラーのあるこれらのRUMイベントを取得して、修正を提案するよう依頼します。Kiroはエラーをレビューして、エラーが外部画像に必要なホスト名の設定によるものだと判断します。 修正を適用し、カートに追加するページの問題を解決して、出来上がりです。 Kiro powerを使ってページが修正されました。
私たちは実際にKiroを使ってKiroを構築しています。そうしているんです。初日からずっとそうしてきました。Kiro powersはその一例です。Kiro powers全体がKiroチームによってspecsを使って構築されました。システム通知やエラーハンドリングといったコア機能は、すべて純粋にspecsを通じて開発され、多くの場合1週間以内に完成しました。ごく最近の例としては、Kiroを使って独自のキャッシングシステムを構築した方法があります。Kiroを使って特化した分析ツールを構築し、トリアージ時間を2時間から数分に短縮しました。最も重要なのは、このキャッシングシステムを構築したことで、インフラコストを72パーセント削減できたことです。そしてこれらすべてが週末の間に完了しました。
この種の迅速で目的に特化したソリューション開発は、spec駆動開発の力を実際に示すものです。KiroでKiroを構築することは、私たちにとって、どのような変革が可能かについての洞察を得る方法でした。そして今後も、Kiro agentがあなたのやりたいことに対してより効果的になるよう、Kiro powersのような機能を追加し続けていきます。これらの教訓は非常に重要です。AI agentsは急速なペースで変化しています。新しいモデルが登場します。新しいサイエンスが登場します。より多くの推論ができるようになるため、ますます強力になっています。より良いコンテキストウィンドウとより良いツールハンドリングにより、著しく複雑な作業を自律的に処理できるようになっています。そしてagentsは常にコードを分析しています。パフォーマンスを最適化し、問題をフラグ付けしています。Bedrockチームが行っていた並列実行の例をご覧になりましたね。しかし、agentsは開発者とリアルタイムで積極的にコラボレーションもしています。
Frontier agentsの紹介：自律的に動作するKiro autonomous agent
つまり、AI agentsのこの流動性があるわけです。1日の始まりは、ターミナルの前やIDEの前でagentと作業することから始まり、自分がやりたいタスクでAIと作業しながら、バックグラウンドでAIにタスクを割り当て始めます。バックグラウンドタスクは、セキュリティスキャンや依存関係の更新から、アーキテクチャや実装まで、何でもあり得ます。私たちは、多くの開発者が手作業で学び始めているこれらのプラクティスの一部を捉えて、Kiro内の製品として実装したいと考えました。そこで今週初めに、私たちの信念では、AI駆動開発における大きな飛躍を表す3つの新しいfrontier agentsを発表しました。
では、frontier agentとは何でしょうか？これらはAWSが提供する新しいクラスのAI agentsです。いくつかの特徴的な特性があります。1つ目は、自律的であることです。目標に向けて指示を出せば、常にプロンプトを出し続ける必要なく、どのように達成するかを自分で考え出します。何をする必要があるのかさえも自分で把握できる必要があります。大規模にスケーラブルです。Bedrockチームが学んだ重要な教訓の1つがスケーラビリティであることについてお話ししました。そのような機能をどうやってすべての人に利用可能にできるでしょうか？自律的なagentsがそれを可能にします。複数の並行タスクを実行し、agents間で作業を自動的に分散できます。そして、時には数時間から数日間、介入なしで独立して動作します。これが重要な機能です。
主にKiro autonomous agentについてお話しします。これはソフトウェア開発向けのものだからです。より多くの製品をより迅速に出荷し、最も価値の高いタスクに集中できるよう支援します。そのため、すべてのリファクタリングタスクやP3タスクをそれに割り当てることができます。security agentは、常にコードをスキャンするアプリケーションセキュリティagentです。ペネトレーションテストも行っています。DevOps agentはインシデント対応を行います。将来のインシデントを防止し、安全に実行・運用できるよう、既存のアプリケーションに適用する必要がある新しい教訓がある場合に備えて、常にコードをスキャンしています。
これらのフロンティアエージェントを使えば、もはや開発者が常に座って共同作業をするだけではありません。完全な成果物を提供できるようになります。チームの拡張として追加することができます。基本的には、チームとして、あるいは個人として、より速く前進するのを助けてくれるチームメイトがいるという、新しい働き方で運用することになります。それでは、Kiro autonomous agentについてさらに深く掘り下げていきましょう。このエージェントは開発者やチームと協働します。開発作業を自律的に処理します。最初に行うことの一つは、常に稼働しているということです。常に稼働し続けて、コードベースとパターンの包括的な理解を構築し、コードレビューから学習して、タスクごとに改善していきます。
つまり、autonomous agentとのすべてのやり取りが、エージェントをより賢く、より有能にしていくのです。通常、AIアシスタント、今日お話ししたものも含めて、皆さんは積極的にコンテキストを管理しています。それが学習であり、習得しなければならない技術なのです。
自分の好みやパターンを常に再説明しなければなりません。リポジトリ間でコンテキストを表示し共有するシステムを構築する必要があります。そして、ほぼ常にセッションベースです。セッションを閉じると、エージェントはすべてを忘れてしまい、次にセッションを開始するときには、記憶する必要があります。
Kiro Autonomous agentはセッションベースではありません。常に利用可能です。すべての作業にわたってコンテキストを維持します。皆さんとチームのワークフローに沿って稼働しているので、常にコンテキストを維持し、開発タスクを自動化します。そのため、何かを伝えるために立ち止まって速度を落とす必要がありません。常に動き続けています。幅広い活動に取り組むことができるので、新機能の開発に使用できます。バグのトリアージに使用してコードカバレッジを改善できます。そして、これらすべてがバックグラウンドで行われます。課題のバックログを指定していくつかのタスクを与えれば、皆さんは必要なことを続けることができ、autonomous agentはバックグラウンドで依頼されたことを実行します。
すでに使用しているツール、Jira、GitHub、チーム版ではSlack、個人版ではGitHubに接続して、作業の共通理解を構築します。チームの一員であれば、実際にSlackから学習しています。GitHubのやり取りから学習しています。バックログから学習しています。そして最もクールなことの一つは、これがおそらく私がautonomous agentで一番気に入っている部分だと思うのですが、30日目には1日目よりも効果的になっているということです。60日目には30日目よりも効果的になります。なぜなら、コード、プロダクト、そしてチームが従う基準についての理解を深め続けるからです。
では、実際に動いているところを見てみましょう。先ほどKiro Swagストアをご覧いただきました。ストアが成長してきて、お気に入りのアイテムを保存するシンプルな方法が欲しいとします。そこでウィッシュリスト機能を追加したいと考えます。GitHubで必要なのは、issueにKiroラベルを追加して、これを引き渡すだけです。そしてそれを行った瞬間に、Kiroに引き渡され、エージェントが引き継ぎます。すぐにタスクを作成し、issue全体のコンテキストを取得し、サンドボックスの準備を開始します。すべての作業はサンドボックス内で実行されます。そして簡単な分析の後、明確なプランとこのタスクの内訳を提案します。何も指示する必要はありません。この変更がスタック全体にどのように組み込まれるべきかをすでに理解しています。なぜなら、その理解を構築してきたからです。
そしてエージェントはプランを検証しに行きます。リポジトリを分析します。進めるのに十分なコンテキストがあることを確認し、そうでなければ助けを求めてきます。次にプロジェクトを探索します。バックエンドをマッピングし、フロントエンドをマッピングします。ハンドラーを調べます。API設定、データモデルを調べ、システムがどのように構築されたかを知っているアプローチに沿って自分自身を調整します。つまり、システムが構築された方法に合わせてアプローチを調整するのです。そして変更をエンドツーエンドで実行します。
ウィッシュリストのデータアクセスを更新します。それを製品ページに組み込みます。UIとバックエンドのロジックを、すでに使用しているパターンと一貫性を保ちます。テストを実行し、動作を検証し、型安全性をチェックします。エージェントが適切かつクリーンに統合されることを保証します。そして、クリーンなプルリクエストが得られます。差分と何が変更されたかの明確なサマリーが得られます。そしてエージェントはセッションベースではないため、忘れることがありません。つまり、1つのプルリクエストにフィードバックを与えると、その学習を次の10個に自動的に適用します。
ストアに戻ると、ウィッシュリストができています。ユーザーはハートをタップできるようになりました。お気に入りのアイテムを保存でき、各製品を何人が気に入っているかを追跡します。そしてさらに速く進めることができます。これらすべてを並列化できます。実際、エージェント自体がこれらすべてを並列化する方法を見つけ出し、それぞれが独自のコンテキストを持ちます。例えば、新しいウィッシュリスト機能を実装しているとしましょう。Kiroは同時に、昨夜見つけたバグをこちらで修正したり、別のところでリファクタリングを行ったりすることもできます。
これらすべてが、AI開発の次のフェーズだと私たちは信じています。個人やチームが完了できる作業の速度と範囲を向上させるのです。私たちは、この数年間、お客様がAIアシスタンスをどのように使用してきたかを見てきました。パイロットから本番環境へと移行し、AIが開発ライフサイクル全体にわたってチームの働き方を根本的に変える方法を発見してきました。そして、私たちが幸運にもこれを一緒に見てきた方の一人が、DeltaのチーフアーキテクトであるBrittany Doncasterです。彼女が変革のストーリーを共有するためにここに来ています。ようこそ、Brittany。
Deltaの変革ストーリー：Brittany Doncasterが語るエンタープライズでのGen AI活用
ありがとうございます。Deepak、ありがとうございます。ここに来られてとても興奮していますし、Deltaがソフトウェア開発プラクティスにGen AIを取り入れてきた旅路を皆さんと共有できることにさらに興奮しています。 Gen AIが私たちのソフトウェアの構築方法と提供方法をどのように変革しているか、私たちは皆知っていますし、そしてそれをより速く行いたいと思っています。 Deltaでは、お客様が喜びを体験することに喜びを感じており、お客様を喜ばせるソフトウェアを構築したいと考えています。そして、Gen AIを使ってそれをより迅速に行うための旅を続けてきました。しかし、コーディングアシスタントを導入するだけでは十分ではありません。
その理由を見てみると、誰もが開発者だけに焦点を当ててきました。 開発者にコーディング支援やgenerative AIコーディングツール、agentic コーディングツール、そしてこれらすべてのものを提供することに。しかし結局のところ、開発者はパズルの一片に過ぎず、業界全体の多くの開発者は実際に開発に費やす時間は約30%程度なのです。ですから、その30%を最適化するのは素晴らしいことですが、ライフサイクル全体にわたるエンドツーエンドの改善は見られないでしょう。
そこで私たちは、ツールを超えてプロセスに目を向け始めました。ここDeltaでは、デュアルパスアプローチを採用しています。最初のパスでは、 既存のプロダクト開発ライフサイクル、つまり私たちがPDLCと呼んでいるものを取り上げ、そのPDLCプロセスにAIを注入しています。私たちは、今日すでに行っている活動全体で、人々にとって自然な方法でそれを行おうとしています。ですから、できるだけ変更を少なくして、移行をスムーズにし、意思決定を行う際により良いデータを持てるように支援し、今日存在するプロセスを自動化しようとしています。
しかし、それだけでは限界があることも分かっています。本当に次のレベルのスピードを得るためには、そのPDLCを取り上げて、窓の外に放り投げて、今日私たちが自由に使えるツール、AWSから活用してきたKiroやKiro CLIを考慮して、PDLCがどのようなものになり得るかを再構想するつもりです。そして、プロダクトデリバリーについて私たちが知っていると思っていることを忘れたときに何が起こるかを見ていきます。私たちがそうしてきた理由は、エンタープライズにとって変化は困難であり、変更管理は難しいからです。ですから、私たちは変化を 非常に体系的な方法で導入しなければならないことを知っています。
では、最初のパスについてもう少し深く掘り下げて、既存のプロダクト開発ライフサイクルにどのように変化を導入し始めたかについてお話ししましょう。最初に知っていたことは、採用率を上げなければならないということでした。そして、人々が実際にツールを活用しなければ、何の変化も違いも見られないことを知っていました。ですから、私たちは採用に焦点を当てました。ローンチイベントを開催し、ワークショップを開催し、わずか4ヶ月強でユーザーベースの6%から120%以上に増やしました。
さて、皆さんの中には「彼女の計算が合ってないぞ、どうやってユーザーの100%を超えるんだ?」と思っている方もいらっしゃるでしょう。お答えしましょう。ユーザーの100%を超える理由は、当初、開発者だけがこのツールを利用すると想定していたからです。なぜなら、Q Developerというツールをロールアウトする時、開発者だけが利用するものだと考えていたからです。しかし、これらのトレーニングやワークショップ、そしてすべてのイネーブルメントセッションを開始すると、テクニカルプロダクトオーナーやビジネスアナリスト、つまり開発者の周りにいるすべての人々も、Kiro CLIへのアクセスを望んでいることがわかりました。
彼らもまた、ソフトウェア構築をサポートするプロセスの中でそれを使いたいと考えていました。そこで私たちは実際にAWSと提携し、トレーニングを分岐させました。AWSと共に非開発者向けの特別なトレーニングを作成し、開発者が利用しているのと同じツールを非開発者も利用できるようにしました。なぜなら、結局のところ、Kiro CLIとKiroの多くは、コンテキストに関するものだからです。そして、開発者の周りにいる人々に開発者が持っているのと同じコンテキストを与えると、追加のコスト削減と改善を引き出すことができるのです。
しかし、私たちはすぐに採用からインパクトへとピボットする必要がありました。ユーザーがいるというだけでなく、彼らが日々、週次でこのツールを積極的に使用していることがわかり始めると、私たちはこのツールが私たちのメトリクスに与えるインパクトを見始めました。他のすべての企業と同様に、私たちには開発者の生産性に関する多くの異なるメトリクスがあり、その1つがサイクルタイムです。しかし、私たちはそのサイクルタイムを開発時間とデリバリー時間に分解しています。そして、開発時間をブランチ作成からブランチマージまでと定義し、デリバリー時間はブランチマージから本番環境へのコード投入までと定義しています。
そして、私たちが最終的に見たのは、QとKiro CLIの採用が増加し、開発者全体で日次および週次の使用となるにつれて、開発時間が減少したということです。しかし、デリバリー時間は減少せず、デプロイ頻度も上がりませんでした。そのため、データとメトリクスを通じて、私たちはコーディングは速くなっているが、デリバリーは速くなっていないことがわかりました。そこで、私たちは開発を超えて進む必要があることを知りました。そして、それを実行しました。
まず、開発の右側に進み、デリバリー時間に特に注目し始めました。なぜなら、メトリクスから、それが私たちのボトルネックであることがわかったからです。そこが投資し、最適化する必要がある場所でした。私たちは、そこに存在するプロセスを最適化し自動化するために、Kiro CLIをどのように使用できるかを検討しました。テスト自動化、統合テスト、そして開発者に「それぞれのコード変更をデリバリーする代わりに、まとめてバッチ処理しよう」と言わせてしまうような、プロセスが最適でないために生じる小さな痛みを改善するために、どのように活用できるかを探求しました。そこで、私たちはそれをより最適にする方法に取り組み始めました。
同時に、私たちは開発者の声に耳を傾けました。そして、プロダクトオーナーからフィーチャーやストーリーを受け取る際に、時には十分に明確に表現されていなかったり、何を求めているのかが明確でなかったりすることがあると聞きました。そこで私たちは、フィーチャーやストーリーに何を含めるべきか、どのように表現すべきかを標準化するために、これらのツールを使い始めました。そして、プロダクトオーナーとエンジニアリングの間で何度もやり取りを繰り返す無駄を減らすために、より明確性を高めることにも役立てています。
しかし、本当にゲームチェンジを起こすためには、2つ目の道を進む必要があることを私たちは理解しています。だからこそ、私たちは2つ目の道、2つ目のジャーニーを始めたのです。私たちのアプローチは、パイロットワークショップを実施し、プロダクトデリバリーに関わる従来のチームの壁を取り払うというものです。プロダクトオーナーとエンジニアリングをワークショップに集めています。最近、私たちのビジネスユニットの1つで、プロダクトオーナーとシニアデベロッパーを集めてこれを実施しました。そのプロダクトオーナーからのフィードバックは、通常であれば数ヶ月かかっていたであろう作業が、数日で、実際には1日半のワークショップで完了したというものでした。
このような時間の節約とスピードを目の当たりにすると、これは本当に変革的であり、異なる種類のプロセス、異なる種類のチーム構造について考える必要が出てきます。将来のプロダクト開発はどのようなものになるのでしょうか？まだ完全には分かりませんが、実験を続けること、コラボレーションを続けること、そしてKiroをこれら両方の実現手段として活用していくことは分かっています。
では、なぜこれが重要なのでしょうか？Deltaにとって、私たちは本当にできるだけ早くお客様に製品をお届けしたいと考えています。そのため、左側に示されている今日うまくいっていることをより拡張可能にし、最適化していますが、同時にイノベーションも行っています。これは、皆様が愛する製品をより速くお届けし、よりスピードを上げるために行っているのです。しかし、これは単なるテクノロジーの話ではありません。これはDeltaを長期的な成功に向けて位置づけるためのものです。私たちのロードマップは明確です。今日を改善し、明日のために実験し、うまくいったものをスケールさせていきます。ありがとうございました。それでは、Deepakを再びステージにお迎えしたいと思います。
ソフトウェア開発の未来：マルチエージェントシステムとコミュニティの力
ありがとうございます、Brittany。Deltaは、エージェントがいかに迅速にビジネスの成長と繁栄を支援できるかを示す素晴らしい例です。これは単に開発者がより速く構築するのを助けるだけでなく、Deltaの構築者たちが開発サイクル全体にわたってまったく新しい働き方を考え抜くのを助けています。そして彼らは進化を続けていくでしょう。これを可能にしているのは、人間とエージェントがシームレスに協働できるこの能力なのです。
では、これらすべてはどこに向かっているのでしょうか？可能性の例を見てきましたが、同時にいくつかの課題も見てきました。エージェントと協働する人間は、今日皆さんができるよりも10倍速くコードを出荷できるようになりますが、これはいくつかの変化によってさらに加速していくでしょう。複数のエージェントを連携させ、マルチエージェントシステムが私たちのソフトウェアの大部分を書いて運用する世界に向けて、これまでのソフトウェアデリバリープロセスをゼロから再設計できれば、です。
私たちがよく自問する質問の一つは、人間がエージェントと協働し、エージェントがコード分析や記述のほとんどを行う世界において、成果物としてのコードの価値とは何か、ということです。エキスパートなプランニングエージェントが正確にコンテキストを管理し、機能を実装するエージェント、コードをレビューしてデプロイするエージェント、パフォーマンスとコストを最適化するエージェント、そして運用を管理するエージェントを立ち上げる様子を想像するのは容易です。ループ内の人間は引き続き重要であり続けます。人間は他の誰にも提供できないレベルの判断と意図を提供します。何を構築したいかを知っているのは、皆さんだけなのです。
しかし、彼らが行うこと、彼らが働くプロセス、彼らが使うツール、私たち全員が使うツールは、今日私たちが行っていることとは全く異なるものになるでしょう。私は、IDEはコンテキスト管理とエージェントオーケストレーションシステムへと進化すると信じています。SDLCは今日よりもはるかに反復的で迅速なものになるでしょう。
そしてこれらすべてが起こる中で、私たちには多くの未解決の問題があります。どうすればより速く意思決定を行い、伝達できるのか？人間はまだ関与しています。どうすれば意図が出力と一致していることを検証できるのか？どうすれば出力が検証可能であることを確認できるのか？どうすればその信頼を構築できるのか？物事は壊れ続けるわけですから、どうすればこれらすべての変更の影響範囲を減らせるのか？
解決策は、個々の楽器を演奏するというよりも、オーケストラを指揮することに近いものになります。あるいは私のような人間にとっては、良いバンドですね。良い音楽がどのようなものかを理解する必要はありますし、バンドとして全体的なアウトプットに責任を持ちますが、個々の楽器をすべて自分で演奏する必要はありません。そしてこの変革は理論的なものではありません。今まさに起こっているのです。このカンファレンスを通じて、その例をご覧いただきました。今後12ヶ月で、これは劇的に進化していきます。そして私たちは、この進化を通じて皆さんのパートナーであり続けることをお約束します。
この急速に変化する環境で成功するには、単にツールだけでは不十分です。サポートが必要ですし、継続的な学習活動が必要です。そして学習というのは、単に正式なトレーニングだけではなく、コミュニティとつながりについてなのです。この会場にいる人々から学んでください。他のセッションで実際に自分たちが話していることを実践している人々、BrittanyやDeltaのような人々から学んでください。だからこそ私たちは、テクノロジー業界で最も活気があり、サポート体制の整った開発者エコシステムの一つを構築してきました。
Kiroの場合、14,000人以上の開発者がいるDiscordコミュニティがあり、あらゆるバックグラウンドとスキルセットを持つ開発者が参加しています。Discord内のローカルグループに参加することもできます。質問をしたり、アイデアを交換したり、地域のコミュニティ主導の集まりを通じてベストプラクティスについて学んだりできます。ぜひAWSコミュニティ、Kiroコミュニティに参加して、地域のユーザーグループに参加し、コミュニティビルダーとつながり、共に学び、成長し、イノベーションを起こす新しい方法を発見してください。
この1時間で、私たちが何か特別なものの夜明けにいることをお見せできたと思います。これは恐れるべきものではなく、受け入れるべきものです。私たちが探求してきた可能性は、段階的なものではありません。それらは、私たち全員がソフトウェアを想像し、作成し、デプロイする方法における根本的な変化を表しています。そして私たちは、この旅を通じて皆さんと共にあります。テクノロジー、リソース、そしてサポートを提供していきます。そして私は、展開されつつある未来と、私たちが共に達成することについて、本当にワクワクしています。
皆さんが始めるのをお手伝いするために、すべてのre:Invent参加者に1,000 Kiroクレジットを提供しています。そして、この会場にいるスタートアップの皆さんには、年末まで、最大100シート分のKiro Pro Plusティアを最大1年分、クレジットとして提供しています。Kiro.devで申し込むことができます。そして、ありがとうございます、今日ここにいてくださってありがとうございます。私と同じように、ソフトウェアの未来にワクワクしていただけることを願っています。そして、皆さんが何を作るのか、楽しみにしています。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion