「コーディングは解決済み」という主張への反論

最近、AIによるコード生成ツールの進化に伴い、「コーディングはAIによって解決された」「エンジニアリングはもはや趣味の領域だ」といった言説が一部で聞かれるようになりました。しかし、この主張には多くのソフトウェア開発者が異論を唱えています。特に、大規模なシステムを運用し、その複雑さを日々経験しているエンジニアからは、現実とはかけ離れた見方だという声が上がっています。

「LLMはまともなコードを書ける」と主張する人々は、コードがどのように機能するかを理解していないのです。（出典）

コードの生成コストは確かにAIの登場によって大幅に削減されました。しかし、ソフトウェアの総コストの大部分を占めるのは、メンテナンス、信頼性、セキュリティ、スケーラビリティといった非機能要件（NFR）の確保であり、これらはAIだけではまだ解決できていない問題です。

筆者のアレックス・エーワーロフ氏は、機能要件（コードが何をすべきか）ですら完全に解決された問題ではないと指摘しています。（出典）

AIが生成したコードのリスク許容度

AIが生成したコードが許容されるのは、特定の低リスクなシナリオに限られるという認識が重要です。筆者は、以下の4つのタイプのプロダクトを例に挙げています。（出典）

プロダクトの種類 リスク許容度 特徴
個人用ソフトウェア 高い 個人の自動化、DIYパッチなど、自分自身がリスクを許容できる範囲
POC（概念実証） 高い 技術的実現可能性や製品の潜在能力を示すための一時的なもの
使い捨ての自動化 高い 結果の検証のみを目的とし、長期的な運用を考慮しないもの
兵器化されたAI 特殊 リスクを認識し意図的に損害を与える目的。インターネットに接続されたエージェントの爆発範囲を考えると、厳密な管理が必要

これらに対し、医療、金融、自動車、防衛、発電所、航空、製造業など、エラーが金銭的損失、人命、法的責任に直結する分野では、リスク許容度が極めて低いため、AIが生成したコードの採用は慎重に行う必要があります。これらの分野では、説明責任（Accountability）が不可欠ですが、AIにはそれがありません。

AIは法的責任を負うことも、結果を苦しむこともなく、最悪の場合でも「プラグを抜かれるだけ」だからです。（出典）

なぜコーディングはAIにとって最後の領域なのか

「コーディングは解決済み」という主張が根拠に乏しいのは、コーディングの本質が「論理」にあるからです。コンピュータは、人間の思い込みや願望を一切考慮せず、論理的に正しくなければコンパイルも実行もできません。シンタックスが正しくてもランタイムエラーが発生することは多々あります。

コーディングは論理に関するものです。コンパイラエラーを経験したことがある人なら誰でも、コンピュータがあなたがどれほど正しいと思っているかなど気にしないことを知っています。（出典）

LLMがコード生成で成功しているように見えるのは、エラーをLLMにフィードバックし、エラーが解決されるか、あるいは隠されるまでループさせる「フィードバックループ」が存在するからに過ぎません。これは、まるで人間が手動でデバッグを行うプロセスをAIが模倣しているかのようです。

エンジニア目線で見ると：現実的なAIとの付き合い方

今回の記事は、AIがコードを生成する能力を過大評価する声に対して、現場のエンジニアが抱く率直な懸念を代弁していると感じます。特にNFRの重要性は、私のこれまでの開発経験と完全に一致します。スタートアップでの開発では、機能追加に目が行きがちですが、サービスの成長とともに運用コストや信頼性の問題が必ず浮上してきます。

GCPのCloud RunやBigQueryを日々使っていると、コードそのものだけでなく、インフラとの連携、モニタリング、障害発生時の対応といった非機能要件がいかに重要かを痛感します。AIは現状、これら運用フェーズの課題解決にはほとんど寄与しません。

個人的なプロダクト開発では、AIによるコード生成は非常に便利です。PoCやちょっとした自動化スクリプトであれば、Claude Codeのようなツールを使ってバイブコーディングを進められます。しかし、これをそのまま本番環境に投入するかと言えば、答えは「No」です。

生成されたコードの品質レビューはもちろん、依存関係の脆弱性、将来のメンテナンス性、そして何よりも「責任の所在」を明確にできない限り、重要なシステムでの利用は難しいでしょう。結局のところ、AIは強力な「ツール」であり、その出力の品質を判断し、責任を持って運用するのは人間のエンジニアであるという現実は、しばらく変わらないのではないでしょうか。