7月31日、SiliconAngleが「AI-native software development reshapes engineering」と題した記事を公開した。AIツールの導入だけでは不十分であり、エンジニアリング組織全体のワークフローをAI前提で再設計することが生産性の鍵だという議論を、AWS・Amazonの開発責任者へのインタビューをもとに詳しく掘り下げた内容だ。

同じツールでも生産性に最大10倍超の差が生まれる理由

AWSのDeveloper Agents & Experiences担当VPであるDeepak Singhは、自社内外の調査をもとに次の事実を示した。

「一部のチームは生産性が15〜30%向上している。一方で、3〜10倍、あるいはそれ以上向上しているチームもいる。使っているツールはまったく同じなのに。」

この差を生んでいるのはモデルの性能でもIDEの違いでもない。高成績チームに共通するのは、AIをワークフローに"後付け"するのではなく、計画・仕様・レビュー・引き継ぎといった開発プロセス全体をAIエージェントが能動的に参加できる形に再設計していることだ。

現状、約65%の組織でエンジニアが新規開発に充てられる時間は全体の0〜20%にとどまる。残りの大半はメンテナンス、マイグレーション、コードレビュー、運用作業、コンテキストスイッチに消えている。問題はAIツールへのアクセスではなく、組織の構造そのものだ。

コンテキストが「新しいソースコード」になる

記事で特に力点が置かれているのが、コンテキストの重要性だ。

Amazonのソフトウェア開発ディレクターSteve Tarczaはこう語る。

「AIが知らないのは、あなたたちがどう働くかだ。アーキテクチャ、コーディング規約、運用慣行、ビジネス上の優先事項——それを書き下ろすことに注力したチームが、エージェントにより多くの仕事を任せられるようになっている。」

ここで言う「書き下ろす」とは、ステアリングファイル、仕様書、ドキュメントの整備を指す。ステアリングファイルとは、AIエージェントの振る舞いを制御するためにリポジトリやプロジェクトに配置するコンテキストファイルのことで、コーディング規約・アーキテクチャ方針・禁止事項などを自然言語で記述し、AIが参照する"組織のルールブック"として機能する。Amazon Q DeveloperなどのAIコーディングアシスタントでもこうしたコンテキスト注入の仕組みが活用されている。

プロンプト単体では本番品質のソフトウェア開発には不十分であり、構造化された組織知識がAIエージェントの出力品質を決定的に左右する。この知識資産が、今後のエンジニアリング組織における戦略的資産になるという見立てだ。

信頼なくして自律エージェントは動かない

もう一つの核心テーマは信頼だ。

Tarczaはこう断言する。

「信頼はAI採用の通貨だ。エージェントを信頼できなければ、誰も使わない。」

AWSがこの問題に対応するアプローチは、仕様駆動開発（specification-driven development）、構造化されたエンジニアリングコンテキスト、そしてコード生成前に曖昧さを検出する自動推論技術の組み合わせだ。速く生成することよりも、エンジニアが自信を持って本番デプロイできるコードを生成することを優先している。

仕様駆動開発とは、実装に先立って自然言語や形式的な仕様をAIと協調して整備し、その仕様を根拠としてコード生成・検証を行う開発手法を指す。曖昧な要件のままコードを生成し後から修正するループを減らすことで、品質と速度を両立させるアプローチだ。

コーディング支援から「エンジニアリング全体」へ

記事が示す最も大きな変化は、AIの役割がコード生成を超えて広がっている点だ。

Amazon社内では、AIエージェントがすでに以下の業務を担っている：

• 作業の優先度付け
• Slackの会話サマリー生成
• チケット分析
• 仕様書の自動生成
• 日常的なエンジニアリング業務の一部自動化

具体的な成果として、Amazonのリテール機能「Add to Order」が、仕様駆動開発への移行後に当初予定より2ヶ月早くリリースされた事例が紹介されている。AIを計画・実行・実装の中心に置いた結果だ。

整理すると

AIツールを既存ワークフローに重ねるだけの組織は、せいぜい漸進的な改善しか得られない。仕様、信頼されたコンテキスト、自律エージェント、AI前提のプロセスを中心にエンジニアリング組織を再設計する組織との差は、今後さらに開く可能性がある。

詳細はAI-native software development reshapes engineeringを参照していただきたい。