powered by TechFeed
表示モード
Deep Dive

AIがコードを書いても開発コストが下がらない理由 — 節約分は「レビュー」「統合」「メンテナンス」に移転しているだけだった

10月22日、Harsh(dev.to、ユーザー名:harsh2644)が「AI Made Coding Cheaper. So Why Is Building Software Still So Expensive?」と題した記事を公開した。この記事では、AIがコード生成を劇的に高速化したにもかかわらず、ソフトウェア開発全体のコストが下がらない逆説の構造と、その真因について詳しく論じられている。「30秒のPull Request」が引き起こしたこと著者は、AIツール(Cursorなど)を使えば認証フロー・DBスキーマ・APIルート・ユニットテストを30秒以内に生成できると語る。しかし、そうして生成した「美しいコード」でPull Requestを出したその後が問題だった。

10月22日、Harsh(dev.to、ユーザー名:harsh2644)が「AI Made Coding Cheaper. So Why Is Building Software Still So Expensive?」と題した記事を公開した。この記事では、AIがコード生成を劇的に高速化したにもかかわらず、ソフトウェア開発全体のコストが下がらない逆説の構造と、その真因について詳しく論じられている。

「30秒のPull Request」が引き起こしたこと

著者は、AIツール(Cursorなど)を使えば認証フロー・DBスキーマ・APIルート・ユニットテストを30秒以内に生成できると語る。しかし、そうして生成した「美しいコード」でPull Requestを出したその後が問題だった。

  • レビューに2日かかった(コードが誤っていたからではなく、キャッシュロジックにAIが埋め込んだ微妙なエッジケースを理解するのに時間がかかったため)
  • デプロイ後、AIが知る由もなかったレガシーシステムが壊れた
  • 結果として、翌週まるごとデバッグ・ロールバック・書き直しに費やした

この経験が、著者に一つの確信をもたらした。

「コードを書くことは、最初から最も安い工程だった」

ジェヴォンズのパラドックスがソフトウェア開発に起きている

著者が持ち出すのが、経済学の概念「**ジェヴォンズのパラドックス**」だ。これは「技術進歩によってリソースの利用効率が上がると、そのリソースの総消費量はむしろ増える」という逆説を指す。19世紀に石炭の効率利用が石炭消費量の増大をもたらした現象から名付けられた。

AIがコード生成を安くした結果、何が起きたか。著者の観察によれば、より多くのコードを要求されるようになった。

1週間かけて1機能を作っていたチームが、今では「1時間でコードが書けるなら、1週間で5機能出せるはず」とマネジメントから言われる。しかしソフトウェア開発のボトルネックは、タイピング速度でも構文の難しさでもない。問題は常にコンテキストという認知負荷にある。

AIは、3年前のアーキテクチャ上の意思決定を知らない。なぜあのマイクロサービスが壊れやすいかを知らない。2年前に退職した開発者の頭の中にあったビジネスロジックを知らない。

※編集部の考察:なお、このパラドックスがソフトウェア開発に当てはまるかどうかは議論の余地もある。需要増が市場原理ではなくマネジメント側の圧力から生じているケースでは、ジェヴォンズ的なメカニズムというよりも、単純な「生産性への過剰期待」として分析すべきという見方もある。著者の枠組みは示唆に富むが、適用範囲には注意が必要だ。

コストはどこに移ったか——3つの"隠れた請求書"

AIによってコード生成コストが下がった分、費用は以下の3つに移転した、と著者は主張する。

1. レビューと信頼のコスト(Review and Trust Tax)

コードを読むことは、書くことよりはるかに難しい。人間が書いたコードなら「なぜこう書いた?」と聞ける。AIが生成したコードは、信頼するためにロジックを逆算して理解しなければならない。レビューに費やす時間が、かつてコードを書いていた時間を上回り始めている。

2. コンテキスト負債(Context Debt)

AIは優れたスプリンターだが、アーキテクトとしては機能しない。関数を完璧に実装できても、その関数がリポジトリの他の5万行にどう影響するかを理解していない。AIコードの「統合コスト」は非常に高い。

3. メンテナンスの請求書(Maintenance Bill)

コードの生成は安い。しかし、そのコードの維持は高くつく。AIは技術的には正しいが慣用的に奇妙なコードを書きがちで、人間には直感的でない抽象化を生み出す。6ヶ月後、誰かがそれを読まなければならない。

では、どう対処するか

著者は、AIが安価になった今こそ「タイピング速度」ではなく「意思決定」にリソースを最適化すべきだと主張し、3つの方針を示す。

1. ボトルネックを設計フェーズに移す
AIに「この機能を作れ」とプロンプトするのではなく、「3つのアーキテクチャ案を提示しろ」とプロンプトする。浮いた時間を、自分たちのコンテキストに合った選択の判断に使う。

2. シニアエンジニアのレビュー時間を確保する
AIが1,000行生成した場合、それを本番に送り出す前に立ちはだかるのはシニアエンジニアの判断力だけだ。その時間を削ってはならない。

3. 「書く」より「消す」にAIを使う
著者個人の見解として、AIの最善の使い道は新しいコードの追加ではなく古いコードの削除だと述べている。レガシーシステムのリファクタリング、欠落したテストの補完、技術的負債の解消にこそ速度を使うべきだ、というのが著者の立場だ。この主張は反論もあり得る観点だが、生成AIの速度特性をコスト圧縮ではなく品質改善に向けるという考え方として注目に値する。

結論:コードは商品になった

著者の最後のメッセージは明快だ。

「AIはソフトウェアエンジニアリングを簡単にしたのではない。仕事を『コードを書く』から『コードを編集する』に変えただけだ。そして編集は、書くよりも深いシステム理解を要求する」

AIが生成したコードを理解していなければ、そのコードはあなたのものではない。コードがあなたを支配している。そして積み上がった負債はいつか返済を迫ってくる、というわけだ。

コードを速く書ける人材よりも、何を作るべきか、それがシステム全体にどう収まるかを考えられるシステムシンカーこそが、次世代の「10x開発者」像だと著者は示唆している。

詳細はAI Made Coding Cheaper. So Why Is Building Software Still So Expensive?を参照していただきたい。