Netflixが教える“AI生成コードによる暴走”の食い止め方：重要なのは“理解する力”

生成AIによってソフトウェア開発の生産性が向上する一方で、「動くが内容を理解し切れないコード」は増加傾向だ。NetflixのAI開発ツール導入担当者が、同社で実践している対策を明らかにした。

[TechTargetジャパン]

　テストで通ったからそのまま本番環境にデプロイ――。生成AIの普及によって、ソフトウェア開発の速度は急激に向上している。だがその一方で、「動くが、誰も完全には理解していないコード」が企業システムへ入り込み始めている可能性がある。

　こうした中、NetflixでAI開発ツール導入を推進してきたジェイク・ネイションズ氏は、「AI生成コードによる暴走」を防ぐために実践している同社のアプローチを明かした。

第1段階：「既存システムを理解するための調査」

併せて読みたいお薦め記事

AIコーディングの関連記事

• AIコーディングで手間が増える――GoogleのSREが語る自動化の皮肉と生存戦略
• Claude Code生みの親は「コードを一行も自分で書いていない」――情シスはどう受け止めるべき？

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

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

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

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

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

概念	意味や特徴	AI時代にエンジニアが直面する変化や課題
単純（Simple）	コード同士が複雑に絡み合っておらず（もつれがない状態）、それぞれの役割に沿って独立している状態。人間はそのコードが「どのように、どのような役割で動いているか」を理解・把握しやすい。	「単純」なコードを獲得するには思考や設計、ひも解くなど、人間の手が必要 。AIを使っても自動的には得られない 。
簡単（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」を記事化したものです。