AIコード生成が当たり前になった今、エンジニアの間で静かに広がる懸念がある。「AIが書いたコード、なんか大きくなってないか？」——この直感を、システムソフトウェアの世界で長年影響力を持つエンジニア、Bryan Cantrillが鮮やかに言語化した。

「怠惰の美徳」とは何か

Cantrillの主張の核心はこうだ。

LLMは本質的に「怠惰の美徳」を持っていない。LLMにとって作業にコストはかからない。LLMは自分自身（や他の誰か）の将来の時間を最適化しようとする必要を感じない。そのため、ゴミのレイヤーケーキにどんどん積み上げていく。 ここで言う「怠惰の美徳」とは、プログラマーが長年培ってきた知恵だ。人間は時間が有限であるがゆえに、クリーンな抽象化を追求する。「後で自分が苦労するのが嫌だから、今ちゃんと設計する」——この動機こそが、優れたソフトウェア設計の源泉だった。

ところがLLMにはこの動機がない。プロンプトに応答してコードを生成するコストはゼロに等しい。将来の保守性など考慮せず、とりあえず動くコードを重ねていく。その結果、システムは「大きく」はなっても「良く」はならない。

実際の現場で起きていること

これは抽象的な議論ではない。AIコード生成を日常的に使っているエンジニアなら、心当たりがあるはずだ。

パターン1: 重複コードの増殖 「似たような処理があるから共通化しよう」という発想がAIには薄い。プロンプトごとに独立した実装が生まれ、コードベースに類似した処理が散在していく。

パターン2: 過剰な実装 「念のため」の分岐や例外処理、使われないパラメータが積み重なる。人間なら「こんなケース来ないだろ」と切り捨てる部分も、AIは丁寧に実装してしまう。

パターン3: 抽象化の欠如 共通のパターンをインターフェースや基底クラスに抽出するのは、将来の自分への投資だ。しかしAIはこの「投資」をしない。今動けばいい、という生成を繰り返す。

実務での活用ポイント

この問題の解決策は「AIを使わない」ことではない。AIの特性を理解した上で、人間側がコントロールを手放さないことだ。

1. 生成後のリファクタリングを工程に組み込む AIが生成したコードをそのままマージするのではなく、「重複の除去」「抽象化の抽出」を必ず人間がレビューするステップを設ける。

2. プロンプトで抽象化を指示する 「既存の〇〇インターフェースを実装する形で書いて」「〇〇クラスを継承して」のように、設計の枠組みを先に人間が決め、AIにその中で実装させる。設計判断を委ねるな。

3. ファイルサイズ・関数数の上限を設ける コードレビューのルールとして「1ファイル400行以上はレビュー必須」などの閾値を設定すると、AIが生み出す肥大化を早期に検知できる。

4. 「なぜこの設計か」を説明させる コードだけでなく「なぜこの実装を選んだか」を同時に生成させると、設計判断の妥当性を評価しやすくなる。説明できない実装は疑う。

筆者の見解

Cantrillの指摘は本質を突いていると思う。そして同時に、これはAIを否定する話ではまったくない。

人間の「怠惰の美徳」がいかに重要か、AIが登場して初めて可視化されたとも言える。私たちが「めんどくさいからちゃんと設計する」という動機で積み重ねてきた抽象化の価値が、今まさに問われている。

重要なのは、AIとの役割分担の設計だ。AIは実装の速度と網羅性を担う。人間は設計の方向性と抽象化の判断を担う。この分担を意識せずにAIに全部投げ続けると、Cantrillの言う「ゴミの層」が積み上がっていく。

逆に言えば、抽象化やアーキテクチャ設計のスキルを持つエンジニアの価値は、AI時代においてむしろ高まる。「どう動かすか」をAIが担う分、「何を作るか・なぜそう設計するか」という上位の判断こそが人間の本質的な仕事になっていく。

AIエージェントが自律的にループで動き続ける時代が来るとしても、その「ループが向かう方向」を定義するのは人間だ。その羅針盤の精度こそが、エンジニアの真価を問う時代が始まっている。

出典: この記事は Quoting Bryan Cantrill の内容をもとに、筆者の見解を加えて独自に執筆したものです。