ソフトウェア業界では過去にも“危機”があった。1960年代後半から1970年代、コンピュータ性能の向上に対し、ソフトウェア開発が追い付かなくなった「ソフトウェア危機」が問題化した。その後、C言語、オブジェクト指向、アジャイル開発、DevOpsなど、複雑化へ対抗するための技術や方法論が生まれてきた。だが現在は、AIによって「コードを無限に生成できる」時代へ突入した。過去との違いは、複雑化の速度と規模が桁違いになった点だ。

　ネイションズ氏によれば、AIによって開発現場の生産性は劇的に向上している。従来は数日かかっていたバックログ対応が数時間になり、大規模なリファクタリングも進めやすくなったという。一方で同氏は、「動くが、十分に理解されていないコード」が大量に生まれ始めている点を危惧する。大規模システムは予想外の方法で障害を起こすため、「コードを理解していること」が以前にも増して重要になっているという。

AIは「簡単」を極限まで加速させる

　ネイションズ氏は、AI時代の開発現場では、「Easy」（簡単）と「Simple」（単純）が混同されていると指摘する。

　同氏は、プログラミング言語「Clojure」の作者であるリッチ・ヒッキー氏の定義を引用し、「単純」（Simple）と「簡単」（Easy）の意味と、AI時代にエンジニアが直面する変化や課題を以下の通り整理した。

　AIは、この「簡単」を極限まで加速させる。認証機能、API連携、データ処理コードなどを自然言語で指示するだけで、コードが瞬時に生成されるからだ。しかし、それは「理解しやすい設計」を意味しない。むしろ、場当たり的な修正や追加実装を積み重ねやすくし、コードベースを急速に複雑化させる危険がある。

　同氏は、「『簡単』を選ぶことは、現在のスピードと引き換えに、将来の複雑さを受け入れることだ」と説明する。AIとの長い対話を繰り返す中で、不要コード、古い設計、複数の実装パターン、暫定対応などが蓄積される。しかもAIは、それらを「悪い設計」とは認識しない。既存コード内の全てを「守るべきパターン」と見なし、技術的負債まで再利用・増殖させてしまうことがある。

　そのためNetflixでは、AIへ実装を依頼する前段階として、「既存システムを理解するための調査」を重視する。まず、設計書、アーキテクチャ図、主要インタフェース、「Slack」の議論履歴などを整理し、「今回の変更に必要な情報」だけをAIへ与える。AIには、「どのコンポーネントがどこへ依存しているか」「障害時に何が影響を受けるか」「キャッシュや認証はどう動くか」といった観点で分析させる。

　ただし、ここで重要なのは、人間側がAIの分析結果を何度も検証する点だ。同氏は、「AIの分析が間違っていれば修正し、不足している文脈があれば追加する」と説明する。AIを“自律的に正しい答えを出す存在”として扱うのではなく、人間が仮説検証を繰り返しながら理解を深める“調査支援ツール”として利用している。

　その成果として生成されるのが、「何が存在し、何がどこにつながり、変更がどこへ影響するか」をまとめたリサーチドキュメントだ。同氏は、「数時間かかるコード探索を、数分で読めるドキュメントへ圧縮できる」と説明する。

第2段階：「アプローチ設計の計画」

　ネイションズ氏は、ソフトウェアの複雑さには2種類あると説明する。これは、ノースカロライナ大学チャペルヒル校（University of North Carolina at Chapel Hill）コンピュータサイエンス学部創設者のフレデリック・ブルックス氏が1986年に発表した論文「No Silver Bullet」（銀の弾丸などない）で整理した考え方だ。

　1つは「本質的複雑さ」（Essential Complexity）だ。例えば、「ユーザーが決済する」「注文を処理する」といった、ビジネスそのものが持つ難しさを指す。

　もう1つが「偶発的複雑さ」（Accidental Complexity）だ。これは、過去の回避策、防御コード、古いフレームワーク、暫定対応など、人間が開発過程で積み上げてきた複雑さを意味する。

　問題は、AIがこの2つを区別できない点にある。Netflixで実際に進めていた認証システム刷新では、古い認証ロジックが業務処理へ深く入り込んでいた。権限チェックやデータモデル、認証呼び出しが数百ファイルへ散在し、AIエージェントは依存関係を整理できず、数ファイル変更した段階で処理が破綻したり、古い認証ロジックを新システム上へそのまま再生成したりする問題が起きたという。

　そのためNetflixでは、AIにコードを書かせる前に、人間側が詳細な実装計画を作成する。関数シグネチャ、型定義、データフロー、責務分離まで細かく設計し、「ジュニアエンジニアへ渡しても、その通りに実装すれば動くレベル」まで具体化する。

　ここで重要なのが、「どこまでが本質的なビジネスロジックで、どこからが過去の技術的負債なのか」を人間が先に整理する点だ。AIは既存コードの全てを“守るべき設計”として扱うため、人間が設計判断を与えなければ、古いアーキテクチャや不要な依存関係を再生成し続けてしまうという。

第3段階：「明確なコンテキストに基づく実装」

　そして最後の実装フェーズで、初めてAIへコード生成を依頼する。仕様が整理されているため、不要なコード生成や設計崩壊を防ぎやすい。人間は、「AIが計画通りに書いているか」を高速にレビューするだけで済む。

　特に興味深いのは、Netflixの認証システム刷新で、最終的に「一度AIを止めた」点だ。

　同氏によれば、最初は人間が手作業で1つの移行コードを書き、依存関係や隠れた制約を理解する必要があった。その過程で、「どの制約が本当に重要なのか」「どのサービスが壊れるのか」「どのデータが暗号化されているのか」といった、“コードを読むだけでは見えない制約”を把握したという。

　さらに、その手作業で作成したPull Request自体を、AIに参照させた。つまり、「正しい移行例」をAIへ学習させた上で、初めて残りの移行を自動化し始めた形だ。

　同氏は、「理解は手作業で勝ち取るものだ」と説明する。AI活用を成功させるには、最初の段階で人間が泥臭くシステムを理解しなければならないという。

AI時代に価値を持つのは「理解できる人」

　ネイションズ氏は、「AIに思考を委ね続けると、危険な設計を察知するエンジニアの直感が衰える」と懸念する。過去の障害対応や保守経験から生まれる感覚は、AIには存在しないからだ。

　同氏は、「ソフトウェア開発の本質は、コードを書くことではなく、何を構築すべきかを理解することだ」と語る。

　AI時代に求められるのは、「最も多くのコードを書ける人」ではない。システムを深く理解し、設計の境界線を見極め、「そもそも間違った問題を解いていないか」を判断できる人材こそが重要になる可能性がある。

本稿は、2025年12月21日に公開された「The infinite software crisis」を記事化したものです。