How frontier teams are reinventing AI-native development｜フロンティアチームが再構築する 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](https://kiro.dev) や目的別に構築された 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（サポート終了）アップグレードへの対応、ソフトウェアエンジニアリングに伴う無数の差別化できないタスクの解決など、ソフトウェア開発ライフサイクルのすべての側面を支援したいと考えています。次回のブログでは、これらにどのように取り組んでいるかを紹介する予定です。 [フロンティアチームについてさらに詳しく >](https://kiro.dev/topics/frontier-teams/) AI ネイティブな開発については、[AWS Summit New York City](https://aws.amazon.com/events/summits/new-york/) で引き続きご覧ください。** ## 著者について ![image](https://d2908q01vomqb2.cloudfront.net/f1f836cb4ea6efb2a0b1b99f41ad8b103eff4b59/2026/06/10/swami.png) スワミ・シバスブラマニアン氏は、Amazon Web Services (AWS) のアジェンティック AI 担当バイスプレジデントです。AWS では、Swami 氏が Amazon DynamoDB、Amazon SageMaker、Amazon Bedrock、および Amazon Q といった主要な AI サービスの開発と成長を主導してきました。彼のチームの使命は、顧客やパートナーがアジェンティック AI を自信を持って活用し、強力かつ効率的であるだけでなく、信頼性が高く責任あるエージェントを構築できるよう、必要な規模、柔軟性、価値を提供することです。Swami 氏はまた、2022 年 5 月から 2025 年 5 月まで、米国大統領および国家 AI イニシアチブオフィスに対して国家 AI イニシアチブに関連するトピックについて助言を行う任務を負う「国家人工知能諮問委員会」の委員を務めました。

フロンティアチームが再構築する AI ネイティブな開発手法

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト