フロンティアチームが再構築する AI ネイティブな開発手法
AWS は、AI を単なるコーディング支援ツールではなく開発基盤と捉える「フロンティアチーム」の事例を公開し、生産性が最大 10 倍以上向上する具体的な実装戦略と 3 つの実践パスを提示した。
キーポイント
AI ネイティブ開発への転換
AI をコード作成のショートカットとして扱うのではなく、ソフトウェア構築の基盤として再設計するアプローチが、最大 10 倍を超える生産性向上をもたらしている。
ボトルネックは知識と組織変革
コミット数は急増しているものの、本番環境へのリリースペースが上がらない要因は AI エージェントの出力能力ではなく、意思決定に必要な知識へのアクセス権限と、それに対応する業務再構築にある。
3 つの実践パス
Amazon では、専門家が課題に挑む「パスマインダー・イニシアチブ」、明確な計画に基づく構造的スプリント、既存手法と AI 適応型ワークフローを比較する現場実験という 3 つの導入経路を特定している。
具体的な成果事例
Amazon Bedrock の推論エンジン再構築プロジェクトにおいて、6 名のエンジニアが 76 日間で完了し、これは本来 30 名で 12〜18 か月かかる規模の成果を達成した。
影響分析・編集コメントを表示
影響分析
この記事は、AI を単なる生産性向上ツールとして扱う段階を超え、組織構造や開発プロセスそのものを再定義する「AI ネイティブ」な開発への転換点を示唆しています。特に、技術的なコード生成能力よりも、知識の統合と業務フローの再設計がボトルネックとなっているという洞察は、多くの企業が直面している課題に対する具体的な解決策を提供します。
編集コメント
AI ツールの導入効果に飽き足らず、組織のあり方そのものを変える必要性を説く貴重な洞察です。単なるツール導入ではなく、業務プロセスの根本的な再設計が成功の鍵であることを示しています。
*Frontier teams are not just using AI to code faster. They're redesigning how software gets built. The result is 4.5x productivity gains, in some cases more than 10x.*
フロンティアチームは、単に AI を使ってコーディングを速くするだけではありません。彼らはソフトウェアがどのように構築されるかその仕組み自体を再設計しています。その結果、生産性は最大で 4.5 倍向上し、場合によっては 10 倍以上の成果を上げています。
エンジニア 6 名。76 日間。本来なら 30 名の開発者が 12 か月から 18 ヶ月をかけて行うはずだったプロジェクトが、四半期で完了しました。これは架空の話ではありません。Amazon Bedrock のチームが AI をコーディングの近道として扱うのをやめ、仕事の基盤として捉え直した際に実際に起きた出来事です。そのチームは、過去 10 年間で出した生産コードよりも、5 ヶ月間でより多くの本番環境向けコードをリリースしました。
このようなチームと他のチームとの間の格差は急速に広がっています。AI コーディングエージェントはソフトウェアが書かれる速度を根本的に変えましたが、それが顧客に届く速度を変えたわけではありません。コミット数は急増し、CI/CD パイプライン(継続的インテグレーション・継続的デリバリーパイプライン)はかつてないほど混雑しています。しかし、本番環境へリリースされる機能のペースはそれに追いついていません。ボトルネックとなっているのは、エージェントが出力を生成する能力ではありません。それは、良い意思決定を行うために必要な知識へのアクセス権限と、その現実を踏まえて業務体制を再構築しようとするチームの意欲です。
私たちはこの課題を解決したチームを「フロンティアチーム」と呼んでいます。彼らはエリート研究所に限定された存在ではありません。業界や企業の規模を超えて存在し、共通する規律を持っています:AI の導入をツールの展開ではなく、エンジニアリングへの投資として捉えている点です。あらゆるエンジニアリングチームがフロンティアチームになることができます。その方法をお見せしましょう。
Amazon における AI ネイティブ開発への三つの道
AI ネイティブなソフトウェア開発では、AI がソフトウェア構築の基盤とみなされ、人間のエキスパートによって指揮される能力の高いエージェントが活用されます。これらのエージェントをどのように指揮するかが成果を決定します。Amazon において開発分野で AI を推進する主な動機は、ドキュメント作成、調整、運用といったコーディング以外のタスクに開発者が費やす時間を短縮し、技術的負債を解消し、数千もの小規模な「2 ピザチーム」間でのコーディングの不整合を最小限に抑えることにあります。私たちは数百のエンジニアリングチームで実験を重ねており、少なくとも三つの道を見出しました。一つはエキスパートが課題に取り組む「パスマインダー(先導者)イニシアチブ」、二つ目は明確に定義された計画を実行するための構造化されたスプリント、三つ目は既存のアプローチと AI 適応型ワークフローの間にチームを半分に分ける現場での実験です。これらの道は構造は異なりますが、同じ洞察に収束します。
パシオンダー・イニシアチブは統制された実験でした。6 人のシニアエンジニアに単一の命令が下されました:Amazon Bedrock の推論エンジンを再構築することです。このプロジェクトは当初、30 名の開発者が 12 か月から 18 ヶ月かけて行うと見積もられていました。人員を増やすのではなく、チームは最初の数週間で AI に焦点を当てたワークフローの再設計に注力し、個別のタスクから目標指向の結果へと移行し、複数のエージェントを並列で実行し、オフタイム中に AI が独立して作業できるシステムを構築しました。プロジェクトは 76 日で完了しました。正規化されたコミット速度(開発者あたりの週あたりのコミット数で、リポジトリの複雑さとチーム規模で調整した指標)で測定すると、個々の開発者の生産性は約 20 倍向上しました。コミット数は週あたり 2 件から 40 件に増加し、本番環境へのデプロイ行数を基準とした場合、このチームは過去 10 年間のプロジェクトよりも 5 ヶ月間でより多くの高品質なコードを提供しました。
構造化されたスプリントは異なるアプローチを採用しました。Prime Video Financial Systems チームは、パソファインダーモデルに触発され、10 日間の実験を実施しました。6 人のエンジニアが一つの部屋に集まり、コンテキストの切り替えゼロ、オンコール業務なし、他のプロジェクトなし、会議も最小限という環境でした。シニアエンジニアが事前に 3 週間かけて複雑さを分解し、詳細な要件を持つ適切にスコープされたタスクへと整理しました。チームは複雑な機能開発には仕様駆動型開発を、要件がすでに明確なタスクには直接エージェント支援型開発を採用しました。10 日間で、ベースラインの 96 コミットに対して 556 コミットを生成し、90 週間と見積もられていたプロジェクト期間を 24 週間に短縮しました。これはほぼ 6 倍のスループット向上と 4 倍の加速を意味します。彼らは AI による成果向上が以下の 3 つの要因が掛け合わされた結果であると説明しています:判断の少ない作業の加速(1.5 倍)、コンテキスト切り替えなしで判断が必要な作業への集中度向上(1.5 倍)、エージェントによってキャプチャされたドメイン専門知識への即時アクセス(1.5 倍)。この 3 つの要因のうちどれか一つでも欠けると、成果は崩壊してしまいます。現在チームは、ドメイン知識を内包した詳細な製品仕様書と、集中時間を確保するための自律型エージェントを活用し、通常の運用においてこれら 3 つの要因を最適化することを目指しています。
「現地実験」において調査された50チーム以上の中で、新しいツールと新しい実践の両方を実装した25チームは、既存のワークフローにAIを追加しただけのチームよりも優れた成果を上げました。Amazon Storesでは、通常のバックログを抱えた開発チームが特別条件なしで、選ばれたエンジニアも用いず、Kiro や目的別に構築された AI ツールを使用して構造化されたパイロットを実施しました。その結果、生産性の中央値は4.5倍となり、一部のチームでは正規化されたデプロイ速度(スプリントあたりに展開される機能の数で、歴史的なベースラインに対して正規化)において10倍以上の改善を達成しました。Perfect Order Experience では、現在では機能を2週間ではなく午後には出荷できるようになりました。WW Grocery では設計ドキュメントの作成時間を5日から数時間に短縮しました。
異なる道筋ですが、同じ教訓です。重要なのはツールそのものではなく、ワークフローです。
フロンティアチームになるための5つのステップ
3つのすべての道において、最も高いパフォーマンスを発揮するチームは、共通の論理を持つ5つの実践を共有しています。それは、エージェントへの文脈への障壁を減らし、それが独立して行える作業の範囲(表面積)を増やすことです。
ここがフロンティアチームが過去の習慣と分岐する点です。歴史的なアプローチは、個々のコード生成の速度を最適化することに焦点を当てていました。一方、フロンティアチームが最適化するのは全く異なるもの:正しく、本番環境で即使用可能なソフトウェアが顧客に届くまでの速度です。この区別が、以下のすべての実践を駆動しています。
- エージェントの文脈に投資する。最も先進的なチームは、エージェントがプロジェクトや知識を容易に消費できるようにするために、エージェント・ステアリングファイルやチームの慣習、コーディング標準、テスト、コードベースのナビゲーションに関するガイダンスに多額の投資を行っています。Bedrock インフラストラクチャチームは、すべてのコードとドキュメントをモノレポ(単一リポジトリ)に配置し、AI エージェントが生成したインラインコメントを永続的なメモリとして扱い続けました。このステップをスキップするチームは、なぜ自分のエージェントが同じミスを繰り返すのか不思議に思っています。
- 速くなるために一旦遅くする。上記のプラクティスには時間がかかり、チームには忍耐が必要です。パフォーマンスの高いすべてのチームが報告しているのは、モデルを学ぶ過程では最初は物事が一時的に遅くなるということです。彼らはクロスファンクションな専門知識をエージェント向けの再利用可能なステアリングドキュメントにエンコードし、LLM(大規模言語モデル)が推論できるようにリポジトリを再構築し、AI が消費しやすいようにコメントを追加してコードのスプリットを再設計しました。その学習曲線を乗り越え、まず期待される成果を定義したチームは、複利効果による加速を実感しました。一方、ワークフローを変更せずに即座の成果を期待していたチームは失望しました。最初の 2 週間は遅く感じるものだと予想してください。その後の数週間は劇的に速くなるはずです。2 週目で挫折したチームは、この複利効果を決して体験することはありません。
- エージェントを世話するのではなく、餌を与えること。フロンティア(最先端)のチームは、明確な成果を持つ範囲が限定されたタスクのバックログを常に維持し、複数のエージェントを並列で実行して非同期で出力を検証しています。ビルダーたちは、主要機能を短いバーストで完了させると報告しており、エージェントがタスクを完了するのを待っている間にさえも作業は進行します。あるシニアエンジニアは、コードレビューや運用サポート、会議の間を移動している間もエージェントが作業していたため、「連続した数時間」の時間しかかけずに完全な変更をリリースしました。
- コードを書き始める前に意図を明確にする。構造化された仕様書、詳細な要件ドキュメント、あるいは範囲が限定されたタスク分解を通じて、フロンティアのチームはエージェントがコード生成を開始する前に「完了」の状態について明確な文脈を持っていることを保証しています。このアプローチを採用している一部のチームでは、コードの手書き比率がわずか 1〜2% に抑えられつつ、以前よりも 1 人あたりの週コミット数が大幅に増加していると報告されています。
- 「テストを左へシフトする」。フロンティアのチームは、エージェントがコードがパイプラインに到達する前にローカルですべての統合テストを実行し、自己修正できるようにするためのツールを開発しています。Prime Video チームは、早期に問題を検出できる自動ガードレール、コンポーネントテスト、パフォーマンステスト、フォーマッターへの投資を行いました。コードレビューの焦点は、コードスタイルや命名規則から、インターフェース定義とアーキテクチャ上の意思決定へとシフトしました。
今日、技術リーダーにできること
すべてのチームがこの結果を達成できるわけではありません。文脈構築フェーズをスキップしたり、AI を単なる差し替えツールとして扱ったり、業務方法の再編成なしに即座の成果を期待したりするチームは、一貫して期待通りの成果を出せません。業界全体で開発者は AI コーディングツールを採用していますが、全員が生産性向上を実感しているわけではありません。彼らが間違っているのはツールではありません。正しいツールを間違ったワークフローの中で使用しているのです。
主なポイントは以下の通りです:
- AI が最大限の効果を発揮できるよう、働き方を変えましょう。
- 成果を生み出すには3 つの要素が掛け合われます:AI が低判断業務を処理する x 高判断業務に中断なく集中する x ドメイン専門知識への即時アクセス。
- まずパイロットを実施し、その後拡大しましょう。
実践的な出発点は広範な導入ではなく、意図的なパイロットです。まず、生産コードを書く前に最初の数週間をかけてエージェントの文脈(ステアリングファイル、仕様テンプレート、モノレポなど)を構築する意志のある小規模チームから始めます。チームにはワークフローの再編成を行う権限を与え、コミット速度、デプロイ頻度、解決までの時間、そして開発者の満足度スコアを測定します。その後、彼らが得た知見を活用して、組織全体のためのプレイブックを構築します。
生産性が 4.5 倍から 10 倍以上向上したチームは、単により優れた技術を採用しただけではありません。その技術をどう活用して働き方を変えるかを見出したのです。この決断は、今日のあらゆるエンジニアリング組織が下すことができます。もちろん、コードコミットの速度は物語の一部に過ぎません。リリース管理、運用、セキュリティ運用の合理化や、EOL(サポート終了)アップグレードへの対応、ソフトウェアエンジニアリングに伴う無数の差別化できないタスクの解決など、ソフトウェア開発ライフサイクルのすべての側面を支援したいと考えています。次回のブログでは、これらにどのように取り組んでいるかを紹介する予定です。
AI ネイティブな開発については、AWS Summit New York City で引き続きご覧ください。**
著者について
image スワミ・シバスブラマニアン氏は、Amazon Web Services (AWS) のアジェンティック AI 担当バイスプレジデントです。AWS では、Swami 氏が Amazon DynamoDB、Amazon SageMaker、Amazon Bedrock、および Amazon Q といった主要な AI サービスの開発と成長を主導してきました。彼のチームの使命は、顧客やパートナーがアジェンティック AI を自信を持って活用し、強力かつ効率的であるだけでなく、信頼性が高く責任あるエージェントを構築できるよう、必要な規模、柔軟性、価値を提供することです。Swami 氏はまた、2022 年 5 月から 2025 年 5 月まで、米国大統領および国家 AI イニシアチブオフィスに対して国家 AI イニシアチブに関連するトピックについて助言を行う任務を負う「国家人工知能諮問委員会」の委員を務めました。
原文を表示
*Frontier teams are not just using AI to code faster. They’re redesigning how software gets built. The result is 4.5x productivity gains, in some cases more than 10x.*
Six engineers. Seventy-six days. A project scoped for 30 developers over 12 to 18 months, delivered within a quarter. That is not hypothetical. It’s what happened when an Amazon Bedrock team stopped treating AI as a coding shortcut and started treating it as the foundation of how they work. The team shipped more production code in five months than in the previous ten years.
The gap between teams like this and everyone else is widening fast. AI coding agents have fundamentally changed the rate at which software gets written, but not the rate at which it reaches customers. Commits are surging, and CI/CD pipelines are busier than ever. Yet, features shipped to production have not kept the same pace. The bottleneck is not the agent’s ability to generate output. It is the agent’s access to the knowledge it needs to make good decisions, and the team’s willingness to restructure work around that reality.
We call the teams that have figured this out “frontier teams.” They are not confined to elite labs. They exist across industries and company sizes, and they share a common discipline: they treat AI adoption as an engineering investment, not a tool rollout. Any engineering team can become a frontier team; we can show you how to get there.
Three paths to AI-native development at Amazon
AI-native software development treats AI as the foundation of how software is built, with increasingly capable agents directed by human experts. How teams direct those agents determines outcomes. At Amazon, the primary drivers for AI in development were to reduce the time developers spent on non-coding tasks such as documentation, coordination, and operations, retire technical debt, and minimize coding inconsistencies across thousands of small “two-pizza” teams of developers. We have been experimenting across hundreds of engineering teams and have identified at least three paths: a pathfinder initiative with experts tackling a challenge, a structured sprint to execute on a well-defined plan, and an in-situ experiment splitting teams in half between existing approaches and AI-adapted workflows. The paths differ in structure but converge on the same insight.
The pathfinder initiative was a controlled experiment. Six senior engineers received a single mandate: rebuild the Amazon Bedrock inference engine, a project originally estimated at 30 developers working 12 to 18 months. Rather than adding headcount, the team spent its first weeks redesigning workflows around AI, shifting from discrete tasks to goal-driven outcomes, running multiple agents in parallel, and setting up systems for AI to work independently during off-hours. The project was delivered in 76 days. Individual developer productivity increased approximately 20x as measured by normalized commit velocity (the number of commits per developer per week, adjusted for repository complexity and team size). Commits went from 2 per week to 40. The team shipped more high-quality code in five months than it did on projects over the previous ten years, as measured by lines deployed to production.
The structured sprint took a different approach. The Prime Video Financial Systems team ran a 10-day experiment inspired by the pathfinder model. Six engineers, one room, zero context switching, no on-call duties, no other projects, limited meetings. A senior engineer spent three weeks beforehand breaking complexity into well-scoped tasks with detailed requirements. The team used spec-driven development for complex feature work and direct agent-assisted development for tasks where requirements were already clear. Over 10 days, they produced 556 commits against a baseline of 96 and reduced a 90-week project estimate to 24 weeks. That translates to nearly 6x throughput and 4x acceleration. They attributed the AI-enabled gain to three factors multiplying together: acceleration of low-judgment work (1.5x), higher focus on high-judgment work with no context-switching (1.5x), and instant access to agent-captured domain expertise (1.5x). Remove any one factor and the gains collapse. The team is now looking to optimize these three factors in normal operations using detailed product specs that encapsulate domain knowledge and autonomous agents that free up focus time.
In the in-situ experiment, of the 50-plus teams studied, the 25 teams that implemented both new tools and new practices outperformed those that simply added AI to existing workflows. Amazon Stores ran structured pilots with typical development teams working against their regular backlogs, using Kiro and purpose-built AI tools with no special conditions and no handpicked engineers. The median productivity gain was 4.5x, with some teams reaching more than 10x improvement in normalized deployment velocity (features deployed per sprint, normalized against historical baselines). Perfect Order Experience now ships features in an afternoon instead of two weeks. WW Grocery cut design document creation from five days to a few hours.
Different paths, same lesson. The workflow matters, not just the tool.
Five steps to becoming a frontier team
Across all three paths, the highest-performing teams share five practices with a common logic. Reduce the barriers to context for the agent and increase the surface area of work it can do independently.
This is where frontier teams diverge from prior habits. The historical approach optimized for the speed of individual code generation. Frontier teams optimize for something different: the rate at which correct, production-ready software reaches customers. That distinction drives every practice below.
- Invest in agent context. The most advanced teams invest heavily in making projects and knowledge easier for agents to consume through agent steering files and guidance on team conventions, coding standards, testing, and codebase navigation. The Bedrock infrastructure team placed all code and documentation into a monorepo and kept the inline commentary that AI agents generated, treating it as persistent memory. Teams that skip this step wonder why their agents keep making the same mistakes.
- Slow down to speed up. The above-mentioned practice takes time and requires teams to be patient. Every high-performing team reported that things initially slowed down as they learned the models. They encoded cross-functional expertise into reusable steering docs for agents, restructured repositories so LLMs could reason over them, and added comments and re-architected code splits for AI consumption. The teams that pushed through that learning curve and defined the expected outcomes first experienced compounding acceleration. The teams that expected immediate gains without changing their workflows were disappointed. Expect the first two weeks to feel slower. Expect the weeks after to feel dramatically faster. The teams that quit in week two never see the compounding.
- Feed agents instead of babysitting them. Frontier teams maintain a steady backlog of well-scoped tasks with clear outcomes, running multiple agents in parallel and reviewing output asynchronously. Builders report finishing major features in short bursts, with work advancing even when they are not actively waiting for the agent to complete a task. One principal engineer shipped a complete change with only ‘a couple of hours of contiguous time’ because the agent worked while the engineer moved between code reviews, operational support, and meetings.
- Make intent explicit before code gets written. Whether through structured specifications, detailed requirements documents, or well-scoped task decomposition, frontier teams ensure agents have clear context about what ‘done’ looks like before they start generating code. Some teams using this approach report handwriting only 1–2% of their code while pushing significantly more commits per person per week than before.
- “Shift testing left.” Frontier teams build tooling so agents can run all integration tests locally and self-correct before code ever reaches the pipeline. The Prime Video team invested in automated guardrails, component tests, performance tests, and formatters that caught issues early. Code reviews shifted focus to interface definitions and architectural decisions rather than code style and naming conventions.
What technology leaders can do today
Not every team achieves these results. Teams that skip the context-building phase, treat AI as a drop-in replacement, or expect immediate gains without restructuring how they work consistently underperform. Developers across the industry have adopted AI coding tools. Not all of them are seeing production gains. They are not using the wrong tools. They’re using the right tools inside the wrong workflows.
The key takeaways are:
- Change how you work to make AI work at its best.
- Three factors multiply to deliver outcomes: AI handling low-judgment work x uninterrupted focus on high-judgment work x instant access to domain expertise.
- Pilot first, then scale.
The practical starting point is not a broad rollout. It is a deliberate pilot. Start with a small team willing to spend the first weeks building agent context (steering files, spec templates, monorepos) before writing production code. Give the team a mandate to restructure workflows. Measure commit velocity, deployment frequency, and time-to-resolution, along with developer satisfaction scores. Then use what they learn to build the playbook for the rest of the organization.
The teams achieving 4.5x to more than 10x productivity gains have not just adopted better technology. They’ve figured out how to work differently with it. That decision is available to every engineering organization today. Of course, code commit velocity is only part of the story. We want to help with all aspects of the software development lifecycle, whether that is streamlining release management, operations, and security operations, or tackling EOL upgrades and the countless undifferentiated tasks that come with software engineering. Stay tuned for the next blog, where I will walk through how we are approaching these.
Learn more about frontier teams >
Tune in to AWS Summit New York City for more on AI-native development.**
About the author

Swami Sivasubramanian** is Vice President for Agentic AI at Amazon Web Services (AWS). At AWS, Swami has led the development and growth of leading AI services like Amazon DynamoDB, Amazon SageMaker, Amazon Bedrock, and Amazon Q. His team’s mission is to provide the scale, flexibility, and value that customers and partners require to innovate using agentic AI with confidence and build agents that are not only powerful and efficient, but also trustworthy and responsible. Swami also served from May 2022 through May 2025 as a member of the National Artificial Intelligence Advisory Committee, which was tasked with advising the President of the United States and the National AI Initiative Office on topics related to the National AI Initiative.
関連記事
Agent-EvalKit で AI エージェントを体系的に評価する
AWS は、AI エージェントが自律的にツールを選択・実行する際の挙動を出力レベルのテストだけでは評価できないとして、事実捏造や空結果への対応を検証できる「Agent-EvalKit」を発表した。
エンドバが AI エージェントを中心にソフトウェアデリバリーを再設計する方法
企業 IT サービス企業の Endava が、AI エージェントを活用してソフトウェアの提供プロセスを再構築する取り組みを開始した。
AI エージェントに適切なサンドボックスを選ぶ方法
LangChain は、AI エージェントの安全性と効率を確保するために、利用目的やリスクに応じて最適なサンドボックス環境を選択する基準を解説している。
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み