Uncle BobのAI開発実験：逐行レビューを減らしても、設計は人間の仕事

はじめに

AIエージェントは「誰がコードを書くのか」を変えつつある。しかし、「誰がシステム設計に責任を持つのか」という問題には、まだ決着がついていない。最近のポッドキャストで、ソフトウェア工学の実践者であるUncle Bob Martinは、AIエージェントに機能実装と検証ツールの実行を任せ、人間は逐行のコードレビューから少しずつ離れ、自動化された品質制約を整備する実験を紹介した。この考え方はGrady Boochらとの議論を呼び、コード生成から長期保守可能な開発へ移る難しさを浮き彫りにしている。

手作業の確認を品質ゲートへ

Uncle Bobの基本的な認識は、長いプロンプトだけではモデルを安定して制御できないというものだ。長いコンテキストの中央に置かれたルールは、情報量が増えるにつれて軽視されたり、無視されたりする可能性がある。一方、自動化ツールは同じ基準を比較的決定的に適用できる。彼のワークフローには、次のような検査が含まれる。

• 単体テスト、Gherkinによる受け入れテスト、QA手順による機能確認
• サイクロマティック複雑度、モジュール規模、依存関係の分析
• テストが実際に論理欠陥を検出できるかを見るカバレッジとミューテーションテスト
• 次の反復に進む前に、生成コードを整理・強化する工程

ミューテーションテストは、ソースコードの演算子などを意図的に変更し、その状態でもテストが失敗するかを調べる。変更後もテストが通るなら、テストスイートに重要な見落としがある。しかし、これらの指標が主に確認するのは、既存の要件とテストを満たしているかどうかである。要件自体の不足や、セキュリティ、性能、長期的な変更容易性を完全に証明するものではない。

マルチエージェントは有用だが万能ではない

想定される工程では、要件分析、実装、コード整理、強化、QAを別々のエージェントが担当する。各エージェントの仕事を狭く定義し、終了後にコンテキストを破棄することで、指示の混在や、ひとつの会話で形成された思い込みの持続を抑える。並列作業を進められる点も利点だ。一方で、起動、成果物の受け渡し、コンテキストの再構築にはコストがかかる。

この方法には、成熟したテスト基盤と高い開発規律が必要だ。カバレッジが低く依存関係が複雑なプロジェクトでエージェントを増やしても、コードが速く増えるだけで品質保証にはならない。制約の量にもバランスがある。少なすぎれば欠陥が蓄積し、多すぎれば反復速度が人間の開発を下回る可能性がある。

アーキテクチャは依然として弱点

Uncle Bob自身、AIはアーキテクチャ、モジュール境界、依存関係について問題のある案を出すことが多いと認めている。そのため、全体を一度に設計する重い事前計画よりも、小さな要件を実装し、人間が構造を振り返ってリファクタリングし、次の反復へ進む方法を重視している。

ここが議論の本質である。Boochは、カバレッジや複雑度だけでは、経験、業務コンテキスト、セキュリティや性能上の問題を見抜く力を代替できないとして、エージェントが生成したコードを全面的に確認する立場を取る。争点は単純な「信頼するか否か」ではなく、どの品質判断を実行可能な制約へ変換し、どの判断を人間に残すかという責任分担なのである。

開発者への示唆

AI時代には、コードを読むことが唯一の品質活動ではなくなるかもしれない。その一方で、テスト設計、アーキテクチャ判断、デバッグ、リスク評価の重要性は高まる。初心者はプロンプト作成だけでなく、自分でコードを書き、失敗を調査し、古典的なソフトウェア工学の考え方を学ぶ必要がある。

Uncle Bobの実験は、「コードをまったく読まない」方法が一般に安全だと証明したわけではない。それでも、反復的な実装はAIに、決定的な検査は機械に任せ、人間は要件、設計、指標で表しにくいリスクに集中するという提案には価値がある。成熟したAI開発とは、レビューをなくすことではなく、どこで、誰が、何をレビューするのかを再設計することなのだろう。

InfoQ 中文