エンタープライズ規模でのエージェント型コーディングには仕様駆動開発が不可欠

VentureBeat / 2026/4/14

💬 オピニオンDeveloper Stack & InfrastructureSignals & Early TrendsIdeas & Deep Analysis

要点

  • この記事は、エージェント型コーディングをエンタープライズで安全にスケールさせるには、自律的なソフトウェア生成のための「信頼モデル」として、チームが仕様駆動開発を採用する必要があると主張している。
  • それは、エージェントは、事後に生成されたドキュメントに頼る従来のアプローチとは異なり、正しい振る舞いを定義する、構造化され文脈に富んだ仕様に対して推論し、その後にコードを書くべきだと説明している。
  • 本文では、Kiroおよび複数のAmazon/AWSチームの事例を引用し、仕様駆動のエージェント型ワークフローを統合することで、主要な機能提供のリードタイムが大幅に短縮されたことを示している。
  • さらに、仕様は、プロパティベースのテストやニューロシンボリック手法によって、仕様から大規模なテストスイートを導出し、エッジケースを検出することで、自動化された正しさのエンジンとして機能し得ると述べている。
  • 全体として、仕様駆動で検証可能なテストが、試作レベルのAIコーディング(いわゆる「slop」)から、本番レベルの信頼性へ移行するために必要な下流側の主要な変化だと位置づけている。

AWSがお届けします


自律エージェントによって、ソフトウェアの提供(デリバリー)にかかる期間が「数週間」から「数日」へと圧縮されています。安全にエージェントを拡張できる企業は、仕様駆動型開発(spec-driven development)を土台に構築する企業です。

技術の転換には、早期導入者が「例外」ではなくなり、「標準」になっていく瞬間があります。私たちは今まさにソフトウェア開発のその瞬間にいて、多くのチームはまだそれに気づいていません。

1年前、コード感(vibe)での開発がバズりました。開発者以外やジュニア開発者が、AIによって自分の能力を超えて作れることを発見したのです。参入のハードルが下がりました。プロトタイピングが飛躍的に速くなりましたが、同時に「雑な量産(slop)」も増えました。業界がその後必要としていたのは、天井を引き上げるもの——つまり、コード品質を改善し、最も熟練した開発者のやり方に近い形で機能するものです。仕様駆動型開発がそれを実現しました。信頼できる自律的なコーディング・エージェントのための土台を築いたのです。

仕様(Specs)は、自律開発のための信頼モデルである

AIが生成したコードについての議論の多くは、「AIがコードを書けるかどうか」に焦点が当たっています。より難しい問いは、それを「信頼できるかどうか」です。その答えは、そのまま仕様(spec)を通って導かれます。

仕様駆動型開発は、一見すると簡単なアイデアから始まります。AIエージェントが1行のコードも書く前に、エージェントは、システムが何をすべきか、どのような特性(properties)を持つべきか、そして「正しい(correct)」とは実際には何を意味するのかを定義した、構造化され文脈に富んだ仕様をもとに作業を行うのです。この仕様は、開発プロセス全体を通じてエージェントが推論の対象にする成果物であり、後からドキュメントを書かせるというような、エージェント以前のAIアプローチとは本質的に異なります。

エンタープライズのチームはこの土台の上に構築しています。Kiro IDEチームは、Kiroを使ってKiro IDE——ネイティブの仕様駆動型開発を備えたエージェント型コーディング環境——を開発し、機能開発を「2週間から2日」へと削減しました。AWSのエンジニアリングチームは、当初30人で見積もられていた18か月の再設計(rearchitecture)プロジェクトを、6人で76日間、Kiroを使って完了しました。Amazon.comのエンジニアリングチームは、「Add to Delivery(配送に追加)」——購入手続き(checkout)後に商品を追加できる機能——を、Kiroと仕様駆動型開発を用いることで、予定より2か月早くロールアウトしました。Alexa+、Amazon Finance、Amazon Stores、AWS、Fire TV、Last Mile Delivery、Prime Videoなども、構築アプローチの一部として仕様駆動型開発を統合しています。

この転換は、下流のすべてを変えます。

検証可能なテストこそが、自律エージェントを安全に実行できる理由だ

仕様は、自動化された正しさ(correctness)のエンジンになります。開発者がAI支援で週150件のチェックインを生成している場合、人間がそのコード量を手作業でレビューすることはできません。代わりに、具体的な仕様に基づいて作られたコードは、性質(プロパティ)ベースのテストやニューロシンボリックAIの技術によって検証できます。これらは、仕様から直接導かれる数百件のテストケースを自動で生成し、人間が手書きで書こうとは思わないようなエッジケースを調べます。これらのテストは、コードが仕様で定義された特性を満たしていることを証明し、手作業のテストスイートをはるかに超えて、検証可能な正しい挙動(provably correct behavior)を実現します。

検証可能なテストによって、「単発のプログラミング」から「継続的な自律開発」への移行が可能になります。従来のAI支援開発は単発です。つまり、仕様をエージェントに渡し、エージェントが出力を生成してプロセスが終わります。今のエージェントは、継続的に自分自身を修正します。ビルドやテストの失敗を自分の推論へフィードバックし、自分の出力をさらに深く探るための追加テストを生成し、機能していて、かつ検証可能なものが得られるまで反復を続けます。このループがずれてしまわないように、仕様が「錨(アンカー)」になります。エージェントが正しい判断をしているかを開発者が絶えず確認する代わりに、エージェントは仕様に照らして自分で確認し、正しい道を進んでいることを確実にできるのです。

未来の自律エージェントは、自分自身の仕様を書きます。自己修正の仕組み、検証の仕組みとして仕様を用い、生成するものがシステムの意図した挙動と一致していることを保証します。

マルチエージェント、自律、そして今まさに稼働中

今日ペースを作っている開発者たちは、根本的に異なるやり方で進めています。開発者は、仕様を作り込むのにかなりの時間を使います。また、エージェントが何を、どのように構築すべきかを理解できるように、仕様が使うステアリングファイル(指示ファイル)を書くのにも時間をかけます。実際にソフトウェアを構築するためにエージェントが使う時間よりも、そうした作業に時間がかかることさえあります。さらに開発者は、複数のエージェントを並行して走らせ、異なる観点から問題を批評(レビュー)させます。また、システムの別々のコンポーネント用にそれぞれ書かれた複数の仕様も実行します。エージェントを何時間も、時には何日も走らせます。出力がそれだけの価値を正当化するので、数千件のKiroクレジットを使います。

1年前は、エージェントは文脈を失い、20分で崩れてしまっていました。今は、毎週その週の前より長く実行できます。エージェントの能力はここ6か月で大幅に向上しており、本当に複雑な問題でも取り扱えるようになってきました。新しいLLMは前世代よりもトークン効率が高いため、同じ支出でも劇的に多くのことが進められます。

ただし、これをうまくやるには高度な専門性が必要です。ツール、手法、インフラは存在しますが、それらをオーケストレーション(統合制御)するのは難しい。Kiroの目標は、これらの能力を、理解して使いこなせている上位1%の開発者だけでなく、すべての開発者に深い専門知識とともに届けることです。

インフラは、野心に追いつきつつある

エージェントは1年以内に、能力が10倍になるでしょう。私たちが週次で見ているのも、そのような改善率です。

そのレベルの能力を支えるためのインフラも、同時に収束(整備)しています。エージェントは今、ローカルではなくクラウド上で動き、エージェント同士のシステム間にはセキュアで信頼性の高い通信を用いて、大規模に並列実行されます。組織は、エンタープライズグレードの分散システムを運用するのと同じように、自律的なワークロードを回せるようになりました。つまり、真剣なソフトウェアが求めるガバナンス、コスト管理、信頼性保証を備えています。仕様駆動型開発は、明日の自律システムのアーキテクチャです。

開発者は、問題をどう解決したいかという点において制約されなくなります。この世界で成果を出す開発者は、まさに今その基盤を作っている人たちです。仕様駆動型開発を使い、最初からテスト可能性と検証性を優先し、エージェントを協働者として扱い、文法(シンタックス)ではなくシステムとして考えるのです。

Deepak Singhは、AWSにおけるKiroのVPです。


スポンサー記事は、投稿に対して支払いを行っている会社、またはVentureBeatとビジネス上の関係がある会社によって制作されるコンテンツであり、常に明確に表示されています。詳細は sales@venturebeat.comまでお問い合わせください。