AI時代にコード品質はまだ重要か？それは一つのことにかかっている

シニアソフトウェアエンジニアに何か質問すると、ほぼ確実に彼らのお気に入りの二語の答えが返ってくる：「場合による。」

AIコーディングツールと「vibe coding」の時代に、コード品質がまだ重要かどうかの議論はソーシャルメディアで熱を帯びている。AI Engineerチャンネルのプレゼンテーションで、Max Kanat-Alexander（Capital One）は「はい」か「いいえ」の二項対立を超えて、エンジニアリングの厳格さがいつ重要か——いつ窓から投げ捨てていいか——についての具体的な枠組みを提供する。

基礎：コードがそもそも存在する理由

コード品質が重要かどうかを決める前に、ソフトウェアエンジニアリングの実践が実際に何を達成しようとしているかを確立しなければならない。Kanat-Alexanderによると、ソフトウェアの一部で達成したいすべてのこと——モデルの調整、システムのスケーリング、採用の推進——は二つの要因に帰着する：

システムを理解すること。
その理解に基づいて実行すること。

デバッガ、可観測性ツール、評価、テストは真空中に存在するわけではない。それらはシステムへの理解と、それに基づいて行動する能力を向上させるためだけに存在する。ソフトウェアエンジニアにとって、これは二つの重要な問いに帰着する：

システムの実際の、具体的な振る舞いは何か？（ドキュメントが主張することだけではなく。）
その振る舞いを正しく安全にどう変更するか？

単純な「Hello World」プログラムは全体を把握しやすいが、現実世界のシステム——例えば巨大なオープンソースChromiumコードベース——は本質的に無限の可能な相互作用を持つ。人間はChromiumの全体の振る舞いを頭に入れておくことはできない。代わりに、私たちはURLパーサのような特定のコンポーネントの理解に頼る。

これがコードが存在する理由だ：構造のため。過去、エンジニアは「可読性」や「テスト容易性」といった概念について話したが、それらは純粋に人間の関心事のように聞こえる。下層で常に最も重要だったのは、認識可能で理解可能な構造だ。

変更リスクの悪循環

構造はシステムを変更する必要があるときに最も重要になる。すべての変更は二つのリスクを伴う：

即座の問題を導入する： これは単なるバグではない——締め切りの遅れ、予算超過、システム理解の難しさによるユーザー行動のずれかもしれない。
将来の変更をより難しくする： 構造を劣化させることで、次回システムを理解するのが難しくなる。

リスク#2はリスク#1に直接フィードバックし、複合的で非線形なサイクルを形成する。時間とともに、巨大なコードベースはあらゆる単一の変更が組織的摩擦、タイムラインの遅延、または本番インシデントを引き起こす状態に達し得る。

大きな分かれ目：耐久ソフトウェア vs 使い捨てソフトウェア

人々が将来のAIモデルが最終的に巨大な複雑さを解く無限の能力を持つかどうかを議論している間に、AIは今すでに別のことをしている：使い捨てソフトウェアを10万倍一般的にしている。

歴史的に、エンジニアは時間のほとんどを耐久ソフトウェアの構築と維持に費やしてきた——何年も生き、何千または何百万のユーザーに仕え、失敗すれば壊滅的なビジネス結果をもたらすシステム。耐久ソフトウェアは消えない。実際、AIツールはより多くの耐久ソフトウェアが構築されることにつながるだろう。

しかし、AIエージェントは次のようなソフトウェアを立ち上げることも可能にする：

失敗の結果が最小または存在しない。
少数の人（そして他の本番システムなし）が依存する。
置換コストがほぼゼロ（数時間で再構築可能）。
メンテナンスコストが本質的にゼロ。

OSの電卓が気に入らない？エージェントにカスタムのものを作らせる。子供の誕生日パーティーを計画中？ワンオフのパーティープランナーアプリを立ち上げて月曜に捨てる。使い捨てソフトウェアの世界では、コード品質は全く重要ではない。なぜなら将来の変更の複合リスクが単に存在しないからだ。

評価要因	使い捨てソフトウェア	耐久ソフトウェア
失敗の結果	最小からなし	高 / ビジネス重要
依存	孤立；一人または少数が使用	何千/何百万または他のシステムが依存
置換コスト	ほぼゼロ（数時間/日で置換可能）	極めて高い
メンテナンスコスト	重要でないかほぼ無料	巨大な継続投資
必要なエンジニアリング厳格さ	なし	最大

現代エンジニアリングの二つの新しい規律

使い捨てと耐久はスペクトル上に存在するため、現代のソフトウェアチームは引っ張れる二つの戦略的レバーを持つ。

1. 使い捨てのためにエンジニアリングする

すべてに重いプロセスを適用する代わりに、組織はソフトウェアを意図的に捨てやすくする環境をアーキテクトできる：

隔離環境： 個々のユーザーのデータにのみアクセスし、顧客データやPIIへのアクセスがゼロのサンドボックスを作成する。
強制された独立性： 他の本番システムからのインバウンドAPI呼び出しをブロックし、使い捨てツールに偶然依存するものがないようにする。
耐久的冗長性： 信頼できるが「不格好な」レガシーシステムをバックアップとして保ちつつ、従業員が自分のワークフローのために速いカスタムフロントエンドを「vibe code」できるようにする。カスタムフロントエンドが壊れたら、単に耐久システムに戻る。
厳格なスコープ制限： ツールを単一のユーザーまたは単一のイベントに超集中させる。

2. 厳格さのコストを下げる

経験豊富なエンジニアは、「一時的な」プロトタイプが永久的な本番システムになる習慣があることを知っている。プロジェクトがスペクトル上のどこにあるかを誤判断したり、後で考えを変えたりした場合、使い捨てから耐久への移行をできるだけ痛みなくしたい。エンジニアリングの厳格さを安くて努力なしにすることでこれを達成する：

徹底的な標準化： 言語、フレームワーク、RPCプロトコルの標準化は官僚主義ではない；可能性を排除することだ。フレームワークが少ないほど、維持しなければならないlinter、セキュリティパッチ、カスタムエージェントツールが少なくなる。
ワークフロー内ツール： バックグラウンドで自動的に動く品質チェックを構築する。ツールが速く、信頼性が高く、偽陽性が少なく、開発者の意識的努力がゼロのとき、それは無料に感じる——つまり使い捨てプロジェクトにも適用できる。
摩擦のないテストインフラ： すべての開発者をテストの専門家にすることを要求しない。テストを最初から速く決定論的にするインフラに投資する——例えば、コーディングエージェントを使ってサービスのインメモリ偽バージョンを自動生成・維持する。
初日からの最大厳格さ： すべてのlintルールと厳格さ設定を初日から最大にする。終わりのないチーム議論を排除し、百万行のコードベースでlinterを遡及的に有効にする悪夢を防ぐ。

評決

では、コード品質はまだ重要か？Kanat-Alexanderは三つの明確な答えを残す：

使い捨てソフトウェアに対して？ いいえ。
耐久ソフトウェアに対して？ はい。
厳格さは高くつく必要があるか？ いいえ。
Max Kanat-AlexanderのAI Engineer向けトークに基づく。*