Frontier Teams — Amazon は AI で「開発のやり方」をどう変えたのか

AI コーディングツールを導入しても、効果が「書くコードの量」で止まっていませんか。Amazon 社内では、AI に合わせて開発の進め方そのものを作り直したチームを「Frontier team」と呼び、大きな成果を出しています。

本資料では、AWS が公開しているブログや資料をもとに、次の内容をまとめました。

・Amazon 社内の事例：Amazon Bedrock（6 人・76 日、最大 20 倍）、Prime Video（90 週 → 24 週）、Amazon Stores（やり方を変えたチームの中央値 4.5 倍）、AWS ProServe
・何が差を生んだのか、仕事の進め方はどう変わったのか
・Frontier team の 5 つの習慣と、小さく試して広げる始め方
・re:Invent 2026 のキーノートと、ブレイクアウトセッション DVT206「10x or bust: How Amazon’s Frontier teams ship with Kiro」のご案内
・Appendix：開発者のための 10 原則、AWS Emulator をエージェントだけで作った仕組み

各ページに出典のリンクを載せています。

Transcript

1. AI ネイティブ開発 ／ re:Invent 2026 プレビュー Frontier Teams Amazon は AI で「開発のやり方」をどう変えたのか 公開事例・成果・鍵・ベストプラクティス ＋ re:Invent 2026 キーノートと DVT206 のご紹介 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 1
2. AI で「書く速さ」は上がった。でも「届く速さ」は？ 多くの組織で、AI コーディングツールの効果がコードの量で止まっている AI 導入で増えたもの コミット数 CI/CD の実行回数 生成されるコードの量 思ったほど増えていないもの 本番に届く機能の数 顧客に価値が届くまでの速さ 社内でも、補完・チャット・バイブコーディングによる改善は 10〜20% にとどまった 本当の制約は 2 つ Amazon エージェントが、必要な知識に たどり着けるか チームが、仕事の進め方を 組み替える覚悟があるか 出典: How frontier teams are reinventing AI-native development ／ Frontier Development Hits 4.5x Gains at Amazon © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 2
3. Frontier team とは 組織名ではなく、AI に合わせて仕事の進め方を作り直したチームの呼び名。AI 導入を「ツール展開」ではなく「エンジニ アリング投資」として扱う 観点 まだ試行中のチーム Frontier team AI の使い方 補完・その場しのぎのプロンプト 構造化したコンテキスト＋自律エージェント 要件 口頭やチケットで伝える コードを書く前に意図を明文化 品質 レビューで後から見つける テスト・ドキュメントをコードと同時に生成 レガシーコード 避ける・手で直す AI が分析し、ガードレール付きで刷新 ガバナンス 開発者ごとにバラバラ 組織共通のステアリングとポリシー ※ re:Invent 2025 で発表された製品群「Frontier agents」とは別の概念です 出典: Frontier teams & spec-driven development (Kiro) © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 3
4. 成果：Amazon 社内チームの実測値 予測ではなく、社内の数百チームでの実験から得た数字 20x ~6x 4.5x 10x+ Amazon Bedrock Prime Video Amazon Stores Amazon Stores 個人の生産性（最大値） スループット 90 週 → 24 週 やり方を変えた チームの中央値 上位チーム 仕様から進めるチームでは、人が手で書くコードは わずか 1〜2%。 残りはエージェントが書く のチームがとった 3 つのアプローチ Pathfinder（p5） 10 日間スプリント（p6） 現場での実験（p7） 上級者だけで作り直す 条件をそろえて集中 普通のチームで試す 出典: How frontier teams are reinventing AI-native development ／ Frontier teams & spec-driven development (Kiro) Amazon © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 4
5. 事例 ① Pathfinder ： 人で推論エンジンを作り直す Amazon Bedrock 6 状況 上級エンジニア 6 人で Bedrock の推論エンジンを再構築。 当初見積もりは 30 人 × 12〜18 か月 変えたこと 最初の数週間を、AI 前提のワークフロー設計に投資 個別タスクではなく「ゴール」単位で任せる 複数のエージェントを並列で走らせる 業務時間外もエージェントが自律稼働 76日 で完了 → 2 40 コミット数／人・週 か月で過去 10 年分以上の高品 質コードを本番投入 ※ Distinguished Engineer 2 人を含むトップ層のチームだったため、そのまま再現するのは難しい「上限値」として紹介 されている 出典: How frontier teams are reinventing AI-native development ／ Frontier Development Hits 4.5x Gains at Amazon © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 5 5
6. 事例 ② 10 日間スプリント ： 年物の決済システム（本番 6 サービス）で Prime Video 10 どう進めたか スプリント前の 3 週間：シニア 1 人がタスクを分解し、詳細な要件を用意 10 日間のスプリント中：6 人が同じ部屋に集まり、オンコール・他案件・コンテ キストスイッチはゼロ、会議も最小限 進め方：複雑な機能は仕様駆動、要件が明確なものはエージェントに直接 仕組み：ガードレール・コンポーネント／性能テスト・フォーマッタを整え、レ ビューは設計に集中 556 コミット（通常 96） 24週 90 週の見積もりから 掛け算 3 つの要因が、それぞれ約 1.5 倍で掛け算に効く ── 1 つでも欠けると効果は崩れる ×1.5 低判断業務の 高速化 × ×1.5 高判断業務への 集中 × ×1.5 エージェントが 蓄えたドメイン知識 出典: How frontier teams are reinventing AI-native development ／ Frontier teams & spec-driven development (Kiro) © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 6
7. 事例 ③ 現場での実験 ：普通のチーム、普段のバックログで Amazon Stores 条件 以上のチームを調査 特別な条件なし・メンバー選抜なし Kiro ＋ 用途別の AI ツールを利用 結果 新しいツールと新しいやり方（5 つの習慣 → p11）の両方を 取り入れた 25 チームが、AI を既存フローに足しただけのチ ームを上回った ※ 指標：スプリントあたりのデプロイ機能数（過去実績で正 規化） 50 「大事なのはツールではなく、ワークフロー」 4.5x 3x 未満 Perfect Order Experience ：2 週間かかっていた やり方を変えた約 25 チームの中央値（上 位は 10x 超） 既存フローに AI を足 しただけのチーム 機能を午後だけで出荷 WW Grocery：設計書の作成が 5 日 → 数時間 今後：2026 年中に約 2,000 チームへ拡大予定 出典: How frontier teams are reinventing AI-native development ／ Frontier Development Hits 4.5x Gains at Amazon © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 7
8. 事例 ④ 社内から顧客へ ：まず自分たちが Frontier team に AWS ProServe チーム 社内で Pathfinder として開始 APEX Delivery Agent AI-DLC 6 の フェーズを分担 標準のやり方に 世界中の案件の標準手法へ の分担：人が意図を示し、AI が作り、人が検証する 6 フェーズを専門エージェントが担当。低リスクの判断は自律、高リスクは人が承認 Delivery Agent 顧客事例：LexisNexis（リージョン切り替えの整備） バックログ作成が数週間 → 数時間、コード提供が 60% 加速、全成果物で品質を一貫 「AI ツールの効果が積み上がるのは、ワークフローを AI ツール前提に作り直したときだけ」 Tools compound only when the workflow is redesigned around them. 出典: Built from the inside out: How AWS Professional Services became a frontier team first © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 8
9. 何が鍵だったか 差を生んだのは、ツールを持っているかではなく「仕事の進め方」 鍵1 鍵2 鍵3 割が Kiro を使っていた。差は、 やり方を変えたかどうか 上位チームは全員、最初の 2 週間 はコンテキスト作りで減速 コンテキスト・集中・意図の明確 化。1 つ欠けると効果がしぼむ ツールよりワークフロー 9 最初は遅くなるのが正しい 要因は掛け算で効く 伸びなかったチームの共通点：コンテキスト作りを省く／AI を人の代わりの部品として扱う／やり方を変えずに即効 性を期待する 「正しいツールを、間違ったワークフローで使っている」 次の壁 ① 上限を決めるのはリポジトリ 次の壁 ② 律速は意思決定へ テスト・型・ローカルのモックがないと、モデルが良 9〜12 か月の開発が 1〜2 か月に。今度はレビューや くても任せられる範囲が狭い ローンチ承認が待ち時間に 出典: How frontier teams are reinventing AI-native development ／ Frontier Development Hits 4.5x Gains at Amazon © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 9
10. 仕事の進め方は、具体的にこう変わった 観点 開発者の役割 任せる単位 エージェント 稼働時間 要件 テスト コードレビュー これまで コードを書く人（タイピスト） 個別のタスク 1 つを横で見守る 人の勤務時間だけ 口頭・チケット パイプラインで後から気づく スタイル・命名 Frontier team 意図を書き、結果を検証するアーキテクト ゴール（成果）単位でエージェントに任せる 複数を並列実行し、結果を非同期でレビュー 夜間や会議中もエージェントが進める コードの前に仕様で「完了」を定義 エージェントが手元で回して自己修正 インターフェース・アーキテクチャ 出典: How frontier teams are reinventing AI-native development ／ A practitioner's guide to frontier engineering (Kiro) © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 10
11. ベストプラクティス：Frontier team の 5 つの習慣 共通の考え方：エージェントがコンテキストにたどり着く壁を下げ、自力でできる範囲を広げる 規約・テスト方針をステアリングファイルに。Bedrock はモノレポ化し、 コンテキストに投資する 1 エージェントのコメントを記憶として残す LLM が読み解きやすいようにリポジトリを再構成。最初の 2 週間の減速は 遅くなって、速くなる 2 投資 見守らず、仕事を供給する 切り出したタスクのバックログを常に用意し、並列で走らせて非同期でレ 3 ビュー 4 コードの前に意図を明確に 仕様・要件・タスク分解で「完了」の定義を先に決める 5 テストを左へ寄せる 結合テストを手元で回せるようにし、パイプラインの前にエージェントが 自己修正 出典: How frontier teams are reinventing AI-native development © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 11
12. 始め方：小さく試し、型にしてから広げる 推奨されるパイロットの進め方 1 意欲のある小さなチームを 1 つ選ぶ 2 最初の数週間は、ステアリング・仕様テンプレート・モノレポの整備に充てる 3 ワークフローを組み替える権限を渡す 4 コミット速度・デプロイ頻度・解決時間・開発者満足度を計測 5 学びを組織全体のプレイブックにする 導入 1 チームで試す 実験 品質を比較する 拡大 正しさを測る 定着 型を広める ライフサイクル全体でこの進め方を回すための AWS の方法論が AI-DLC 出典: How frontier teams are reinventing AI-native development ／ Frontier teams & spec-driven development (Kiro) © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 12
13. キーノートで「AI 時代の作り方」を聴く re:Invent 2026 〜 11/30 12/4 ラスベガス。キーノートは無料登録でライブ配信を視聴できます ★ Developer Keynote 月 日本時間 〜 アイデアから数分で動くアプリへ／ちゃんと動くエージェント／AI が書いたコ ードを信頼する Clare Liguori・Marc Brooker・Neha Rungta・Eric Johnson 〜 エージェント時代を支える新発表 Matt Garman（AWS CEO） 11/30 ( ) 19:30–20:45 PT 12/1 ( ) 12:30 火 CEO Keynote 火 日本時間 12/1 ( ) 8:30–10:30 PT 12/2 ( ) 1:30 水 Data & AI Keynote 水 日本時間 12/2 ( ) 8:30–10:00 PT 12/3 ( ) 1:30 木 〜 エージェントをデモから本番へ Dr. Swami Sivasubramanian（Frontier teams ブログの著者）ほか 出典: AWS re:Invent 2026 Keynotes © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 13
14. re:Invent 2026 ｜ Developer Tools トラック ブレイクアウトセッションのご案内 DVT206 10x or bust: How Amazon's Frontier teams ship with Kiro の Frontier team は、ソフトウェアの作り方をどう考え直しているのか。 少しずつの改善から 10 倍へ進むには何が必要か。 Amazon こんな方におすすめ AI コーディングツールを入れたが効果が頭打ち ／ 開発プロセスを AI 前提に組み直したい ／ 社内展開の進 め方や計測方法を知りたい 日時・会場はセッションカタログで確認して、お気に入りに登録を 出典: Your Guide to the Developer Tools Track at AWS re:Invent 2026 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 14
15. あわせて聴きたい関連セッション Developer Tools トラック（全 46 セッション）から DVT206 10x or bust: How Amazon's Frontier teams ship with Kiro Amazon Frontier team DVT405 Trusted intent: How Kiro proves your specs before writing any code 400 DVT320 DVT204 DVT406 社内の の実践（本資料のテーマ） コードを書く前に仕様を検証する仕組み（ レベル） How Kiro learns: an AI coding agent that improves with every session 使うほど賢くなる、永続コンテキストの仕組み Beyond the pilot: How customers scaled Kiro and proved the value Kiro 顧客企業が を全社展開し、価値を測った方法 Make the agent code while you sleep（ワークショップ） Kiro CLI での自律開発を体験。入門は DVT207 出典: Your Guide to the Developer Tools Track at AWS re:Invent 2026 © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 15
16. 参考資料 （ ） How frontier teams are reinventing AI-native development 2026/6/10 aws.amazon.com/blogs/machine-learning/how-frontier-teams-are-reinventing-ai-native-development/ Built from the inside out: How AWS ProServe became a frontier team first aws.amazon.com/blogs/machine-learning/built-from-the-inside-out-… ／ （2026/6/12） Kiro: Frontier teams Frontier engineering kiro.dev/topics/frontier-teams kiro.dev/topics/frontier-engineering ・ Your Guide to the Developer Tools Track at AWS re:Invent 2026 aws.amazon.com/blogs/devops/your-guide-to-the-developer-tools-track-at-aws-reinvent-2026/ （ ： 氏の講演の記事。記 Frontier Development Hits 4.5x Gains at Amazon StartupHub.ai, 2026/8/28 Clare Liguori Claire La Gory startuphub.ai/ai-news/artificial-intelligence/2026/frontier-development-hits-4-5x-gains-at-amazon 事内の表記は re:Invent 2026 ） キーノート aws.amazon.com/events/reinvent/sessions/keynotes © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 16
17. Appendix 開発者のための 10 原則 ソフトウェアを直接作るのではなく、ソフトウェアを作るエージェントの環境を作る（各原則の日本語は要約訳） 1 タイピストではなく、アーキテクトになる 6 コードは使い捨てと考える 2 エージェントの稼働を最大に、関与は最小に 7 AI の成果物にも人と同じ基準を 3 コードベースをエージェント向けに作る 8 エージェントではなく「境界」を信頼する 4 エージェントに速いフィードバックループを 9 コード以外の仕事にもエージェントを使う 5 実行は安い。方向性がすべて 10 エージェント環境を継続的に調整する 出典: A practitioner's guide to frontier engineering (Kiro) © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 17
18. Appendix AWS ：エージェントだけで作り、品質を保証する仕組み AWS Emulator のローカルエミュレーター。人はコードを書かずレビューもせず、ガードレールと「開発の仕組み」を設計した テストを書く 本物の AWS で確かめて登録 問題を見つける 失敗を課題として登録 出発点：仕様と「正解」がある 仕様は AWS API Models、正解は本物の AWS。Kiro は SQS の最初の版を 15 分で作った 直す 課題ごとに根本原因を修正 規模 同時に数百のエージェント、1 日に数千件の課題を修 正、忠実度テストは数万件 マージの関門：4 つすべてを通らないと差し戻し ビルドが通る ／ 規約に沿ったエージェントレビュー ／ セキュリティチェック ／ 忠実度が下がらない 「この関門がなければ、エージェントが作るものを信頼できない」 Without this merge gate, we wouldn't trust what our agents are building. 出典: How we built the agents that built AWS Emulator © 2026, Amazon Web Services, Inc. or its affiliates. All rights reserved. 18