生成AIの進化により、コーディング環境は劇的に変化しました。「この関数を書いて」と頼めば、数秒でコードが生成される体験は、多くのエンジニアにとって日常のものとなりつつあります。しかし、現場で手を動かしている人間にとっては、一つの疑問が拭えません。「で、そのAIは、複雑に絡み合ったスパゲッティコード(レガシーシステム)の前でも同じように魔法を使えるのか?」という問いです。

12月2日、興味深い論文が公開されました。AmazonでAIエンジニアリングの責任者を務めていたKrishna Kumaar Sharma氏が発表した「Beyond Greenfield: The D³ Framework for AI-Driven Productivity in Brownfield Engineering(グリーンフィールドを超えて:ブラウンフィールドエンジニアリングにおけるAI駆動型生産性のためのD³フレームワーク)」です。

この論文は、多くのAIツールが想定する「グリーンフィールド(新規開発)」ではなく、技術的負債や複雑な依存関係に満ちた「ブラウンフィールド(既存のレガシー環境)」に焦点を当てています。Sharma氏は、単なる自動化ではなく、構造化されたワークフローによってエンジニアの認知負荷を下げる「D³フレームワーク」を提唱しており、52名のエンジニアを対象とした実証実験の結果も公開しています。今回は、この論文を紐解きながら、AIと人間の現実的な協働のあり方について考えていきます。

D³フレームワークは発見・定義・提供の3段階でAIを活用します

なぜAIは「泥臭い現場」で役に立たないのか

まず、多くの企業が直面している「生産性のパラドックス」について触れる必要があります。2025年のDORAレポートでは90%がAIを利用していると回答し、マッキンゼーの調査でも生成AIによる大幅な速度向上が示されています。しかし、数百万行に及ぶコードベースや、設計理由を知るエンジニアが既に退職してしまったような「ブラウンフィールド」の環境では、その効果は一貫性がなく、しばしば期待外れに終わります。

論文では、この原因として「知識の断片化」や「ドキュメントの欠如・陳腐化」、そして「依存関係の複雑さ」といったボトルネックを挙げています。例えば、あるユーティリティを変更しようとした際、それが数百箇所に影響を及ぼす可能性がある場合、エンジニアは影響範囲の特定や、壊さないための調整に膨大な時間を費やします。こうした状況下で、AIに単純に「コードを書いて」と指示しても、AIは隠れた依存関係やビジネス上の制約を知り得ないため、動くけれどもシステムを破壊するコードを生成してしまうのです。

さらに衝撃的なデータもあります。ランダム化比較試験では、複雑なタスクにおいて、AIツールを使用した熟練開発者は使用しなかった開発者に比べて19%も作業が遅くなったという結果が出ています。これは、AIが生成した微妙なエラーを修正したり、文脈を理解させるための認知負荷が原因です。

つまり、単純な自動化ツールとしてAIを使うだけでは、複雑な現場の課題は解決しないどころか、かえって生産性を下げるリスクさえあるという現実を、私たちは直視しなければなりません。Sharma氏の調査でも、構造化された手法を用いない「アドホック(その場しのぎ)」なAI利用では、約68%の回答者が「役に立たない」または「わずかに役立つ程度」と回答しており、手放しで喜べる状況ではないことがわかります。

アドホックなAI利用では約68%が効果を実感できませんでした。画像は論文より

「発見・定義・提供」の3段階でAIを統制する

そこで提案されているのが「D³フレームワーク」です。これは「Discover(発見)」「Define(定義)」「Deliver(提供)」の3つのフェーズで構成され、熟練したチームが自然に行っている複雑な作業プロセスを模倣しつつ、AIによって各段階を拡張するアプローチです。このフレームワークの核心は、AIを単一のツールとしてではなく、「Builder(構築者)」と「Reviewer(批評家)」という2つの異なる役割を持つエージェントとして扱う「デュアルエージェント・アーキテクチャ」です。

最初のフェーズである「Discover」では、エンジニアとBuilder LLMが協力してコードベースを調査し、「Research.md」というファイルを作成します。ここでは、単にコードを読むだけでなく、リポジトリの特定や依存関係のマッピング、現在のアーキテクチャの文書化、そしてリスクの特定を行います。

ユニークなのが、この調査結果に対してReviewer LLMが「批評」を行う点です。「依存関係の調査漏れはないか?」「波及的な影響を考慮したか?」といった意地悪なツッコミを入れることで、人間が計画に着手する前に情報の精度を高めます。

次に「Define」フェーズへと進みます。ここではDiscoverで得た知識を基に、実装戦略やタスク計画、テスト方針を策定し、「Plan.md」を作成します。Builder LLMに3つの異なるアプローチを提案させ、それぞれのメリット・デメリットを比較検討させる手法などが紹介されています。

ここでもReviewer LLMが登場し、計画に対して「隠れた結合はないか」「ロールバックは可能か」といった観点でストレステストを行います。重要なのは、これらのフェーズの間に必ず「Human Gate(人間の承認)」が存在することです。AIが勝手に進めるのではなく、人間が最終的な意思決定権を持つことで、AIのハルシネーションや文脈の誤解によるリスクを排除する仕組みになっています。

各フェーズでBuilderとReviewerが対話し、人間が承認するD³フレームワークの流れです

「手戻りが減った」8割超が実感したその効果

最後の「Deliver」フェーズでは、実際にコードを書き、レビューし、検証を行います。ここでもデュアルエージェントの仕組みが活かされます。エンジニアはBuilder LLMを使ってタスクごとのコードを生成しますが、人間のレビューに回す前に、Reviewer LLMによる「プレビュー」を実施します。Reviewer LLMは、一般的なバグやスタイル違反、テストの欠落などを指摘し、人間がより高次元のアーキテクチャやセキュリティのレビューに集中できるようサポートします。

この冗長にも見えるプロセスは、実際に効果があるのでしょうか。論文では、52名のソフトウェア専門家を対象とした探索的調査の結果が示されています。驚くべきことに、D³フレームワークを適用した参加者は、加重平均で約26.9%の生産性向上を報告しました。さらに注目すべきは、参加者の約77%が「認知負荷が軽減された」と感じている点です。複雑なレガシーコードを読み解くという、最も精神力を削られる作業をAIが肩代わりしてくれたおかげでしょう。

また、品質面での貢献も見逃せません。参加者の83%が、AIと共に事前の計画(Defineフェーズ)を綿密に行ったことで、コーディング時の手戻りや書き直しが減ったと回答しています。これは、いきなりコードを書き始めるのではなく、AIを使って設計の妥当性を検証するプロセスが功を奏したと言えます。

アドホックな利用と比較して、D³フレームワークを用いた場合の有用性は「非常に高い」と評価されており、75%の回答者がその価値を認めています。ただし、これらは自己申告に基づくデータであり、厳密な対照実験ではない点には注意が必要ですが、現場の感覚値としては非常に説得力のある数字です。

D³フレームワーク導入による生産性向上率。平均約27%の改善が見られます

ベテランほど恩恵を受け、若手は苦戦する「経験のパラドックス」

若手には残酷な事実も浮かび上がりました。それは「経験のパラドックス」と呼ばれる現象です。一般的にAIツールは、経験の浅いジュニアエンジニアの能力を底上げする「力の増幅器」になると考えられがちです。しかし、現場の観察からは逆の傾向が見えてきました。つまり、シニアエンジニアの方が、ジュニアエンジニアよりもAI生成コードから多くの恩恵を受けているのです。

その理由は「検証能力」の差にあります。シニアエンジニアは、AIが出力したコードが構文的に正しくてもアーキテクチャ的に問題がある場合、それを直感的に見抜くパターン認識能力を持っています。彼らは適切な質問を投げかけ、エッジケースを指摘し、AIを使いこなすことができます。

一方で、深い経験を持たないジュニアエンジニアは、AIの出力を批判的に評価することができません。その結果、一見動くものの微妙なバグを含んだコードを無批判に受け入れたり、理解できないコードのデバッグに不釣り合いな時間を費やしたりすることになります。AIへの早期の過度な依存が、本来身につけるべき基礎的なスキル習得を阻害する「スキル萎縮」を引き起こしてしまうためです。

論文では、ジュニアエンジニアに対しては、あえてAIを使わずに問題を解決する時間を20〜30%設けることや、シニアとのペアプログラミングを通じてメンターシップを強化することを推奨しています。AIは強力なパートナーですが、それはあくまで「判断力のある人間」にとっての話であり、教育や育成の観点では慎重な設計が求められるのです。

アドホック利用と比較し、D³フレームワークの方が有用と答えた割合は圧倒的でした

AIは魔法ではなく、規律あるパートナーである

今回紹介したD³フレームワークは、AIを魔法の杖としてではなく、エンジニアの認知能力を拡張する「規律あるパートナー」として位置付けています。レガシーシステムという、一見AIが苦手とする領域であっても、発見(Discover)、定義(Define)、提供(Deliver)という構造化されたプロセスを経ることで、その真価を発揮できることが示されました。

特に、BuilderとReviewerという2つの役割をAIに与え、人間が最終的なゲートキーパーとなる考え方は、AI時代の開発プロセスのスタンダードになる可能性を秘めています。しかし同時に、それが若手エンジニアの成長を阻害しないよう、組織的なケアが必要であるという警鐘も鳴らされています。単にツールを導入するだけでなく、どうプロセスに組み込むか。その泥臭い試行錯誤こそが、生産性向上の鍵を握っているのです。