現実のエンジニアリングにとって最重要なのは、
「LLMを、今・実務としてどう活用すべきか？」
である。
この問いに対し、現代ソフトウェア工学の巨人と呼べる2人──Agile・リファクタリングの第一人者 Martin Fowler と、TDD（テスト駆動開発）の生みの親 Kent Beck ──へのインタビューが示唆に富む。
Martin Fowler：AIは“コード以前の世界”を変えてしまった
Agileマニフェスト作成者の一人で、ThoughtWorksのチーフサイエンティストであり、そして『リファクタリング』の著者でもあるMartin Fowlerは次のように述べている
https://youtu.be/aR20FWCCjAs
Fowler の指摘で最も重要なのは、AI は単にコーディングを自動化する道具ではなく、「設計前の思考プロセスそのものを変える技術である」 という点だ。
-
「どう書くか」から「何を作るか」へ
従来の開発は「問題理解 → 設計 → 実装」というプロセスが前提だった。しかし、LLM はここを破壊する。Fowler は次のように述べる。
「AI はエンジニアが“どうコードを書くか”ではなく、“何を作るべきか”に意識を向けさせる。」
コードを書くこと自体が中心作業ではなくなり、エンジニアの主戦場は 「意図の明確化」 へとシフトする。 -
「非決定論」という新たな前提
この記事の核心部分である。LLM は Non-deterministic（非決定論的） だ。同じプロンプトでも結果は変わる。
「ソフトウェア工学は長年、決定論を前提として成立してきた。しかし LLM は根本的に非決定性である。」
その結果、「仕様の固定点」が消え、「再現性」よりも 「ガバナンス（統制）」 が必要になる。Fowler は「だからこそ、従来の工学原則がこれまで以上に重要になる」と述べる。 -
アセンブリから高級言語への転換に匹敵する
Fowler は現在の変化を、かつての「アセンブリ言語から高級言語への転換」になぞらえる。 開発者は「より高レベルの意図」を扱い、コードは「仕様や制約の副産物」となる。つまり、Spec / Context / Workflow こそが価値の中心となる。 -
"Vibe Coding" の危険性
Fowler は、Andrej Karpathy が提唱した「Vibe Coding（詳細を気にせず、AIとノリで動くものを作るスタイル）」に対し、実務上の危険性を指摘する。 意図のない「なんとなく動くコード」は、一貫したアーキテクチャを欠き、デバッグ不能な振る舞いを埋め込む。「動いたからOK」は、AI時代では通用しない。 -
AI の真価は“探索”と“理解”
Fowler が挙げる AI の最適な用途は以下の3つだ。- レガシーコード解析（理解の補助）
- プロトタイプ探索（アイデアの壁打ち）
- リファクタリング方針の探索（構造改善の提案）
AI は構造を作る主体ではなく、構造を理解するための道具として機能する。
Kent Beck：AI 時代、TDD は“仕様の固定点”になる
Martin Fowler が AI によって「ソフトウェア工学の前提が書き換わった」と指摘したのに対し、Kent Beck はより実務的で具体的な視点から、AI 時代のプログラミングがどのように変わるのかを語っている。
その中心にあるテーマは、AI がコードを大量に生成する時代こそ、TDD（テスト駆動開発）が“仕様の固定点” として決定的に重要になるという思想である。
-
AI は「望んだもの」ではなく「要求したもの」を返す
― 設計責任は依然として人間に残るBeck は AI を “Genie（精霊）” に例えて説明する。
この比喩が意味するのは、AI は入力された指示を表面的に満たすだけで、背景にある意図や文脈までは理解しないという点である。AI はコードを生成できるが、次のような本質的な設計責任は担わない。
- システム全体の整合性をどう保つか
- どの境界を明確に分けるべきか
- 抽象化のレイヤーをどのように設計するか
- 依存関係をどう整理し、どこで切り離すべきか
AI が生成するのは「人が書く手間を省いた断片」であり、それを「ソフトウェアとして意味を持つ構造」に組み上げる責務は依然として人間の手に残っている。
-
AI 生成コードは「局所的に正しい」だけであり、全体整合性を壊しやすい
Beck が繰り返し示す重要な点は、AI の出力は局所最適であっても、システム全体との整合性は保証されないということである。
AI 生成コードには次の傾向がある：- 部分的には “もっともらしい”
- 単体では正しく動く
- 目的のタスクだけを見ると整合している
しかし、根本的問題がある。
システム全体の文脈における意味や一貫性が欠落しやすい。
そのため、AI を使えば使うほど「部分的には動くが全体では崩壊した設計」の危険性が高まる。これは Fowler の議論とも完全に合流するポイントである。
Beck が AI を「予測不能な精霊」に例えるのは、まさにこの状況を端的に表している。 -
TDD の価値は AI 時代にむしろ大きくなる
― テストこそが唯一の“動作の固定点”Beck の議論の中でもっとも本質的なのが、この「TDD の再評価」である。
AI が生成するコードは流動的で、出力は揺らぎを持つ。
しかしソフトウェアには 一貫した期待動作 が必要である。
Beck はそこで、テストこそが唯一の安定した基準点になる と述べている。TDD のリズム（Red → Green → Refactor）は、AI を導入しても変わらない。
むしろ次のような理由で、AI 時代にこそ適合している。- AI が生成したコードを迅速に検証できる
- テストが“仕様”として振る舞いを固定する
- AI の非決定性による回帰を即座に検出できる
- コード全体に一貫性を強制できる
つまり、AI がコードを大量に書くほど、テストが強制的に秩序を作り出す役割が強まるのである。
Beck が強調する「テストは動作を定義し、コードが揺れようと変わらない」という立場は、AI 時代の最重要原則と言える。
-
AI は“小さく刻む”ことで最も効果を発揮する
― TDD のステップと完全に同型
Beck は「AI は小さく刻んで使うほど効果が高まる」と繰り返し述べている。
これは TDD の基本思想と完全に一致している。- 小さな入力
- 小さな生成
- 小さな検証
- 小さな改善
大きなプロンプトを与えれば幻覚・破綻が増えるが、
小さく区切って AI に問い、小さく生成させると精度が劇的に向上する。
TDD と AI は、“小さく刻む”というリズムを共有している。
このリズムを守ることで、AI の非決定性を弱め、実務に耐えうる品質を確保できる。 -
AI エージェントの時代には「観測性」が必須インフラになる
AI が人間の指示を離れ、より主体的にコード生成やタスク遂行を行う「エージェント化」が進むほど、挙動を観測し、制御し、問題を検出する仕組みが必要となる。Beck は、エージェントの実行環境には次のような能力が必須になると指摘する。
- 振る舞いのログ
- 実行トレース
- 内部状態の可視化
- 失敗時の復旧ポイント
- 逸脱の検出と停止メカニズム
AI は内部過程を説明しないため、
観測性だけが唯一の“安全装置” になる。これは、Fowler の「非決定性の時代には観測性が重要になる」とする主張と強く符合している。
総括：AI × TDD が描く新しい開発パラダイム
まとめると、次のような新しい開発パラダイムが立ち上がる。
-
AI はコードを返すが、設計責任や構造化は担えない
-
AI の出力は局所的には正しいが、全体整合性を壊しやすい
-
TDD が動作を固定し、システム秩序を維持する唯一の基盤となる
-
AI は小さく刻んで使うことで最大の効果を発揮する
-
エージェント時代には観測性が不可欠な安全装置になる
Fowler が示した「工学原則への回帰」と、Beck が示した「TDD の再定義」は、
AI 時代におけるソフトウェア開発が “より抽象化される一方で、より強い構造的規律を必要とする” 方向へ進むことを示している。
AIがコードを書く時代だからこそ、人間は「構造」と「境界」と「仕様」と「観測性」を担う必要がある。