스크립트
00:00:00クレア・リグーリ：クレア・リグーリと申します。AWSでシニアプリンシパルエンジニアを務めています。
00:00:17普段はエージェント型コーディング支援ツールであるKiroを中心に扱っていますが、本日は
00:00:23Amazon社内のチームで見られるようになった取り組みについてお話ししたいと思います。
00:00:28ここでは、これまでAIで見てきたものとは次元の違う、非常にエキサイティングな生産性向上の成果が出ています。
00:00:35私は3年以上エージェント型AIに携わっており、AIによるコーディング支援を巡る業界の進化を見守ってきました。
00:00:48まず、次の行や次の関数を書くのを手伝ってくれるインラインのコード補完が登場しました。
00:00:55次に、コードについて質問するチャットへと移行しました。昨年あたりから誰もが
00:01:02バイブコーディング（感覚的なコーディング）を始めましたが、現在では「フロンティア開発」と呼んでいる手法の
00:01:08アーリーアダプターの段階が見え始めています。個人的な経験から言うと、
00:01:14これまでに登場したどの段階においても、生産性はせいぜい10%から20%ほどしか向上した実感はありませんでした。
00:01:20しかし現在、Amazon社内のさまざまなチームでパイロット運用を実施したところ、
00:01:27中央値で4.5倍、時には10倍以上の生産性向上が見られています。つまり、
00:01:34生産性の劇的な向上が見られる今、何かが確実に変化したのです。
00:01:40Amazon社内で「フロンティア開発者」と呼んでいる人たちを、私は3つの行動特性で定義しています。
00:01:471つ目は「ハンズオフ・コーディング」です。フロンティア開発者が自分で書くコードは、生み出す全体のせいぜい
00:01:541〜2%程度で、残りはすべてエージェントが作成します。2つ目は、エージェントとのやり取りの頻度が少ない点です。
00:02:01人間が介入することなく、コーディングアシスタントを一度に何時間も稼働させ続けることを目指します。
00:02:083つ目は、アイドル時間を最小限に抑えることです。こうしたフロンティア開発者は、
00:02:15複数のエージェントを並行して稼働させ、タスクのバックログを次々と消化していきます。私が初めて
00:02:24フロンティア開発チームを目撃したのは、Bedrock Mantleチームでした。Bedrockは当社のモデルホスティングサービスであり、ClaudeやGPTなどのLLMをホストしています。
00:02:34昨年のある時期、Bedrockチームは新しい推論データプレーンを構築する必要があることを把握していました。
00:02:43しかし、当初の見積もりでは30人のエンジニアで18ヶ月かかるという大規模なものでした。非常に巨大なサービスであり、
00:02:52新システムの構築や、顧客およびモデルの移行には時間がかかると見られていました。
00:02:58そこで彼らは一度立ち止まり、6人のメンバーでKiroを用いて76日間でそれを構築しました。
00:03:06これは大変な偉業であり、Amazon社内でこうした成果を目にしたのはそれが初めてでした。
00:03:12最大20倍の効率向上が可能であることを証明した、まさに先駆的なチームだったのです。彼らはコミット数を検証しましたが、
00:03:21生産性向上を測定する方法については他にもいくつか後でお話しします。
00:03:27ただ、この話には1つ問題がありました。確かに6人で構築されたものの、
00:03:34そのメンバーは2人のディスティングイッシュドエンジニア（特別技術顧問）を含め、社内でも文字通りトップクラスのエンジニアたちでした。
00:03:40つまり、どこにでもある6人のチームではなく、分散システムやLLMのアーキテクチャに精通した専門家集団だったのです。
00:03:49そのため、この素晴らしいエピソードはAmazon中に野火のように広がりましたが、
00:03:57多くのチームにとっては到底真似できないものでもありました。「他のチームで本当に再現できるのか？」という疑問が多く寄せられました。
00:04:03そこで、もう1つご紹介したいのが、プライムビデオ組織で実施された実験的なスプリントです。
00:04:1010日間のスプリントを設け、やはり6人のエンジニアを部屋に集めてKiroを心ゆくまで使わせる実験を行いました。
00:04:19その結果、プロジェクトの納期見積もりを、当初予定されていた90週間から
00:04:2924週間にまで短縮することができました。この10日間のスプリントで大きな進捗を生み出せたからです。
00:04:36彼らは過去のコミット履歴を振り返り、この10日間のスプリント前にはどのような作業をしていて、
00:04:42この10日間だけでどれだけのコミットを生み出したのかを調査しました。
00:04:49このスプリントにより、Bedrock Mantleチームが達成した成果に匹敵する、あるいはそれに近い成果が
00:04:58別のエンジニアチームでも実現可能であることが証明されました。しかし、ここにもやはり課題がありました。
00:05:05部屋にこもった6人のエンジニアにはオンコール業務がなく、会議も制限され、気が散る要素がほとんどありませんでした。
00:05:12これらはエンジニアの日常業務ではお馴染みのものですが、それらが排除されていたのです。さらに、チームのシニアエンジニアは、
00:05:20その前の3週間をかけて、6人のエンジニアが2週間で一気に進められるよう、詳細な要件を備えた小さく明確にスコープされたタスクを
00:05:28事前に作成していました。つまり、これも必ずしも「現実の日常」とは言えません。
00:05:35特定の時点において成果を上げた、構造化されたスプリントでした。
00:05:41では、現実のチームが日々の業務においてこれを達成できるのかという疑問が生じます。そこで、Amazonの小売部門（Amazon.comをはじめとするすべてのリテールサイトや実店舗を網羅する組織）では、
00:05:59より構造化されたパイロット運用を実施しました。若手から中堅、シニアエンジニアまでが正規分布の割合で含まれる
00:06:07ごく一般的な50チームを対象に観察を行いました。Mantleチームのようなゼロからの新規開発（グリーンフィールド）ではなく、
00:06:14既存のコードベースを持つ既存システムを対象としました。昨年の大半を通じてこれらのチームを観察し、
00:06:21非常に興味深い事実を発見しました。チームの半分と残りの半分とで、
00:06:28得られた生産性向上の度合いに大きな差があることが分かったのです。
00:06:34このケースでは、単なるコミット数ではなく、本番環境へのデプロイ速度を生産性の指標として用い、
00:06:41どれだけ素早く変更を顧客に届けられているか、どれだけ迅速にリリースできているかを測定しました。
00:06:48その結果、半数のチームでは生産性の向上が3倍未満にとどまりました。
00:06:563倍未満にとどまるチームと、中央値で4.5倍（場合によっては10倍以上）の向上を達成したチームとの違いは何だったのかというと、
00:07:01それは「ツールの使い方」でした。これらのチームの90%がKiroやその他の社内ツールを使用していたにもかかわらずです。
00:07:11分かったのは、ツールそのものではなく、その「働き方」に違いがあるということでした。
00:07:18劇的な改善を成し遂げたチームは、自分たちの働き方を意識的に変えており、
00:07:26そうでないチームは、従来のやり方の上にKiroなどのツールをただ付け焼き刃的に取り入れていただけでした。
00:07:31少なくとも私にとって、これは非常に大きな「なるほど」の瞬間でした。AIが約束してくれていたような圧倒的な
00:07:39生産性の向上をこれまで実感できなかったのは、私たちの働き方自体を変える必要があったからなのだと気づいたのです。
00:07:47そこでこのパイロット期間中、参加チームや、Bedrock Mantleチーム、プライムビデオなどのチームに対してインタビューを実施し、
00:07:55共通する「5つの習慣」を発見しました。あえて「習慣」という言葉を使うのには理由があります。
00:08:03一時的なスプリントではなく、日々の業務の中で継続して実践することが重要だからです。
00:08:09これらのチームへのインタビューを通じて判明したのは、日々の業務の中で身につけなければならない
00:08:15確かな習慣が存在するということでした。働き方を変えるのは簡単ではなく、その習慣を築くには時間がかかります。
00:08:22それでは、1つずつ見ていきましょう。1つ目の習慣は「エージェントのコンテキストへの投資」です。
00:08:30私たちは頭の中に多くの情報を抱えており、Slackでの会話や新メンバーのオンボードメンターなどを通して、
00:08:35その頭の中にある情報を他の人に伝えようとします。同様に、コードレビュー、
00:08:42スタンドアップ、スプリントプランニングなどを通じて伝えている情報を、すべて書き留める必要があったのです。
00:08:50彼らが身につけた習慣は、エージェントがミスを犯したり、自分が望まないやり方で処理をしたりするたびに、
00:08:55「スキルファイルに何が足りなかったのか？」「エージェントが必要としていたどのような指示ファイルが欠けていたのか？」と自問することでした。
00:09:01しかしご存知の通り、昨年を通じてモデルの能力や挙動は飛躍的な進化を遂げました。
00:09:09昨年中頃のSonnet 3.7には多くの癖があり、指示ファイルに多くの「禁止事項（do not）」を記載する必要がありました。
00:09:16しかし、昨年11月に登場したOpus 4.5以降では、そこまで細かく指定する必要はなくなりました。そしてそれ以降、
00:09:23新バージョンのモデルが次々とリリースされ、6ヶ月以上にわたる改良が重ねられてきました。
00:09:29そこで新たな習慣として問われるのは、「果たしてこの内容はまだ指示ファイルに必要なのか、それとも単にコンテキストを肥大化させているだけではないか」ということです。
00:09:352つ目は「スピードを上げるために、あえてスローダウンする」ことです。
00:09:41インタビューに応じたほぼすべてのチームが、新しい働き方を意図的に取り入れ始めた当初は、
00:09:48むしろ生産性が低下したと報告しています。一見すると直感に反するように思えるかもしれません。
00:09:53生産性のホッケースティック曲線（急上昇カーブ）を描くためには、その前に意図的なエンジニアリング作業が必要になるのです。
00:09:59特に既存のコードベース（ブラウンフィールド）においては、エージェントを成功させるために、
00:10:05まず自分たちのコードベースで地道な作業を行う必要がありました。そのため彼らはエージェントのコンテキストを構築し、
00:10:11エラーが発生した際にモデルが状況を把握できるよう既存ツールのエラーメッセージを改善し、
00:10:17モデルに必要な作業を実際に完了させるための新しいツールや新しいMCPサーバーを構築しました。
00:10:24多くのチームが、エージェントがより容易にコードベース内をナビゲートできるように構造の見直しを行いました。
00:10:29さらには、コードベースのプログラミング言語自体を変更するといったドラスティックな変更さえ目にしました。
00:10:36PythonやJavaScriptは型付けされていない言語であるため、チームが苦戦する場面をよく見かけます。
00:10:43テストが難しく、コンパイルエラーも存在しません。そのため、モデルは推測に頼って結果を返してきます。
00:10:50そこでTypeScriptへの移行を進めるチームが見られます。また、Amazon社内ではRustも非常に人気を集めています。
00:10:56優れたエラーメッセージをコンパイラが返してくれるため、そうした苦労がありません。生産性を向上させるために、
00:11:03多くのチームがこうした意図的な変更を行っているのを目の当たりにしてきました。
00:11:093つ目の習慣は「エージェントの世話を焼くのではなく、餌（情報）を与えること」です。私にとってこれが、
00:11:16なぜ生産性に次元の違う改善が見られるのかを理解する「なるほど」の瞬間でした。もしあなたがバイブコーディングを行い、
00:11:23一日中エージェントと細かいキャッチボールを繰り返しているとしたら、4〜5倍の生産性向上など望めるはずがありません。
00:11:30なぜなら、ずっとループの中に縛られているからです。おそらく30秒から1分ほど画面の前でコードの生成を待ち、
00:11:36レビューすべきコードが返ってくるのをじっと待っている状態でしょう。
00:11:42そのように待ち続けているようでは、他の作業を進めることができません。
00:11:48stuff. It's really difficult to run agents in parallel. It's very difficult to get to to clone yourself
00:11:55into multiple agents. And so if your conversations look a bit like this on the left, then you're
00:12:01babysitting that agent as opposed to the right side where you're feeding it what it needs to do and how
00:12:08it can self-validate. And that's really the key so that agents can self-correct and only come back to you
00:12:14when it meets a certain quality bar, when it when it actually runs and compiles and passes tests, when
00:12:20it's testable, when it actually has high coverage. And of course, the next level is put all of this
00:12:26content into your steering file. So it does it every time without you having to prompt it.
00:12:33The fourth habit is to make intent explicit. At Amazon, we practice a lot of spectrum and development.
00:12:40We've built that into the Kiro product. And so it's very natural for Amazon engineers to adopt it
00:12:46in Kiro. What what I've typically seen with vibe coding as opposed to frontier engineering is giving
00:12:54a very high level prompt, letting the agent generate a ton of code, and then having a back and forth
00:13:02conversation saying, Oh, that's not really what I meant. That you haven't you haven't exactly gotten the requirements right.
00:13:10No, I didn't actually want to build it that way. Here's a technical design. And it is less I find less productive
00:13:17to iterate with the agent on code when the intent itself was incorrect. So often we'll have while see Amazon
00:13:26engineers go through this process for ambiguous, complex features of writing the specification.
00:13:34And in Kiro, of course, you don't have to write this whole specification, you can have the model generate
00:13:39it. But it's a lot easier to iterate with the model in kind of a back and forth conversation about a
00:13:46document than it is about code that's code changes that are spread across a code base. The fifth one is shift testing
00:13:56left. One of the keys here is to give the agent that fast feedback loop, because that's what lets it go off for hours
00:14:04at a time and self correct. The agent is going to make mistakes, and that's fine. But if you give it the right signals, it can
00:14:12self correct and it can spend a while doing that. So I've seen teams adding linters, adding unit tests,
00:14:20integration tests, performance tests, security tests. These are all things we all know we should have
00:14:24been doing all along. This is good engineering hygiene and practices. But now the ROI is, I think, finally
00:14:32high enough for us to actually invest in it. One thing that I've been seeing a lot of teams do is mock out
00:14:40services. Often with integration tests, we would test kind of end to end an entire system, including live
00:14:46services. But we've been investing a lot in mock services that run entirely locally with deterministic
00:14:52responses, because it lets the agent do everything locally. Doing everything on your laptop without
00:15:01having to spin up a bunch of other services and connect to cloud services makes everything a lot faster.
00:15:07Because the more that your agent can get fast feedback means the more loops that it can
00:15:14can do and the more productive your own agent can be. So across all of these, these are some of the
00:15:21habits we've seen. But of course, I would be remiss if I would tell you if you adopt all of these habits,
00:15:28you will achieve nirvana, you will be the most productive engineering organization the world has
00:15:35ever seen. Things are still hard. We are still very much in an early adopter phase and teams are still
00:15:42figuring it out. So one thing that we've been seeing across our teams just organizationally is the risk of
00:15:48burnout. I did not coin this term, I forget who did at what conference, but FOMAT is real. We've been seeing
00:15:56engineers staying up late, late at night, trying to get that perfect prompt that's going to make their
00:16:03agent run for hours overnight so that they wake up in the morning with a code change ready. The cognitive load
00:16:09increases as you run these multiple agents in parallel, you're constantly shifting between
00:16:15terminal tabs. And then we do see that reviewing AI output is often harder for some than than actually
00:16:22writing it, especially early in career. Senior engineers have have already spent a large portion of their
00:16:29career reviewing others code. But early career engineers don't have that muscle yet. And so reviewing
00:16:37it can can feel like a lot more cognitive load than they're used to in actually writing it. The other
00:16:44one is organizational change. So it's already hard to change the way we work as engineers. The way that we
00:16:52spend our entire day completely changes when we're frontier engineers. But also organizations have to
00:16:58change to enable frontier engineering teams. One that I've seen very commonly is accepting slowing down
00:17:07to speed up. And I've been guilty of this myself. My fellow leaders have been guilty of this of saying,
00:17:14well, you have the AI tools now and the models are so amazing now. Why are you not going faster?
00:17:22And that's because you have to take those two months to invest in your code base to figure out the best
00:17:29best practices for your team to make hard habit changes on your team. And if you're constantly expecting
00:17:38shipping features every month, because now we have these amazing models, and we're seeing
00:17:44all of these companies on X saying how they're shipping 20 PRs a day, we have to slow down to speed up.
00:17:54The second one is actually going too broad in the organization too fast. I think that if we had
00:18:01expected all teams in massive organizations to be frontier teams immediately, we would not have had
00:18:08the learnings that we had from the pathfinder, from the from the sprint experiment, from the pilot
00:18:16teams within Amazon. And now the challenge for us is how do we scale it out? And that's what 2026 is about.
00:18:22For Amazon is how do we scale this out to more and more teams to the next 2000 teams instead of 50 teams.
00:18:31And so I think that when you roll it out too quickly, you have a lot of teams who don't know what they're
00:18:37doing. You haven't had time to find the best practices for your own organizations, the the context
00:18:43that your organization needs. And the last one is that you're going to find new bottlenecks.
00:18:49Previously code writing code manually was the bottleneck. I find that within Amazon, we've found
00:18:58the speed of decision making becomes a new bottleneck. The more that you spend reviewing the decision to
00:19:05actually build a new product, the slower it is to build the product now because the code only takes one to two months to write.
00:19:12All of the review processes associated with the launch of a product become the bottleneck.
00:19:20When it used to take nine to 12 months to build a new product, it didn't matter so much in the in the overall
00:19:27wash of things. If it took two months to make the decision to build the product and then two months to
00:19:33approve the launch. But now those are the bottlenecks. Those are the long pole. And so you find all of
00:19:40these all of these things that slow you down. Often I find that frontier engineering teams spend more time
00:19:48making decisions than they do writing code. And so the more that you can make fast decisions, especially ones
00:19:54that are easy to be reversed, the better. So my one big takeaway for for everyone here is that frontier
00:20:03engineering is about intentionally changing the way that you work. And that is difficult. That takes time.
00:20:10It is forming new habits and a new way of working. And that goes across any engineering team as well as your
00:20:18organization. So I encourage you to think about how you're interacting with AI tools and how that can
00:20:27change to free yourself up from being in the loop. Thanks. I'll hang out a little bit if anyone has
00:20:34questions in the back. But thanks for the time today.