AIコーディングを見直す企業が増えている — 「コード生成」と「ソフトウェアエンジニアリング」は別物だという現実

8月18日、SD Timesが「Why Some Companies Are Pulling Back on AI Coding」と題した記事を公開した。この記事では、一部の企業がAIコーディングツールの利用を制限・禁止し始めている背景と、その技術的根拠について詳しく紹介されている。

「コード生成」と「ソフトウェアエンジニアリング」は別物だ

AIコーディングツールへの反動を理解するには、この区別が核心になる。

LLMは構文的に正しいコードを書く能力を急速に高めている。関数の実装、テストの生成、APIの説明——こうした局所的なタスクでは、熟練エンジニアに匹敵する速度で動作する。

しかしソフトウェアエンジニアリングは、本質的には状態管理の問題だ。実世界のシステムは、数百万行のコード、依存関係のチェーン、インフラ層、セキュリティ境界、コンプライアンス要件、そして何年もかけて積み上げられた文書化されていないアーキテクチャ上の意思決定から成り立っている。

記事はこれを具体的なコード例で示している。

# LLMが生成した顧客削除コード
def delete_customer(customer_id):
    db.execute("DELETE FROM customers WHERE id = ?", customer_id)

高性能なLLMなら、次のような追加処理も思いつけるかもしれない：

✓ APIキーの無効化
✓ アクティブなサブスクリプションのキャンセル
✓ IAMパーミッションの削除
✓ キャッシュセッションの削除

だが、過去の請求書をアーカイブすること——多くの国で法的義務——は考慮しない可能性が高い。さらに、CRM（Salesforceなど）を含む8つの下流サービスへ「CustomerDeleted」イベントをパブリッシュすることも抜け落ちる。LLMはそれらシステムにアクセスできないからだ。

LLMはコードベースを解析できる。しかしアーキテクチャ、ビジネスの意図、長期的なシステム挙動に関する理解をコンテキストウィンドウをまたいで保持することはできない。孤立したコーディングタスクではこの制約は許容範囲だが、エンタープライズ規模のエンジニアリングでは危険になる。

企業がLLMを禁止する4つの理由

記事が整理した、企業がAIコーディングを制限する具体的なリスクは以下の4点だ。

1. 正確性の問題
LLMはコードを確率的に生成する。レースコンディション、エッジケースの失敗、セキュリティ脆弱性、パフォーマンス劣化——これらは初期レビューをすり抜けて本番環境で顕在化する可能性がある。

2. 保守性の問題
AI生成コードはアーキテクチャ的な一貫性を欠きやすい。同じ問題を別の関数が別のアプローチで解くことで、コードベースは断片化し、技術的負債を減らすどころか増やすことになる。

3. セキュリティの問題
ソースコードの漏洩、プロンプトインジェクション（LLMへの入力を操作して意図しない動作を引き起こす攻撃手法）、脆弱な依存関係の推薦、クレデンシャルの露出——金融・医療・防衛などの規制産業ではこれらのリスクが短期的な生産性向上を上回りうる。

4. 説明責任の問題
本番システムで障害が発生したとき、人間のエンジニアは設計判断の理由を説明できる。AIにはそれができない。意図も記憶も責任も持たないコードが混入することで、根本原因分析が困難になる。

「完全に信頼できる自律的ソフトウェアエンジニアリング」まで20〜40%

元記事の試算によれば、現時点では完全に信頼できる自律的ソフトウェアエンジニアリングの実現に向けて、到達しているのは20〜40%に過ぎない（この数字は元記事筆者による定性的な推計であり、特定の第三者調査に基づくものではない）。

残るギャップとして挙げられているのは次の4点だ：

長期的推論の限界：ローカルのコンテキストは理解できても、数ヶ月・数年にわたるアーキテクチャ上の推論を維持できない
検証の弱さ：並行性、コンプライアンス、パフォーマンスに関する隠れた前提を破りながら、見た目には正しいコードを生成しうる
タスク分解の不安定さ：大規模なエンジニアリングでは相互依存する数百〜数千のタスクを統括する必要があり、現状は狭いスコープ内でしか機能しない
永続的メモリの未成熟：過去の意思決定を保持する仕組みがなければ、ソフトウェアエンジニアリングの基盤である「継続性」が失われる

それでもAIコーディングが止まらない理由

こうしたリスクがあっても、AI支援の開発が失速しないのは経済合理性があるからだ。記事が「信頼できる用途」として挙げるのは以下のタスクだ：

ボイラープレート生成：定型的な繰り返しコードはLLMが最も得意とする領域で、人間のレビューコストも低い
ユニットテスト作成：テストの入出力パターンは局所的に完結するため、システム全体の文脈依存度が低い
ドキュメント生成：既存コードの説明文生成は、誤りが混入しても影響範囲が限定される
マイグレーション作業：パターンが明確なコード変換は自動化との相性がよい
API統合：仕様書から実装コードを生成するタスクはLLMの得意パターンに合致する
コードレビュー準備：チェックリスト的な指摘出しは確率的生成の弱点が出にくい
内部ツール開発：本番リスクが低く、障害の影響範囲が限定される環境での利用に向く
高速プロトタイピング：使い捨てを前提とした検証用コードは保守性の問題が顕在化しない

いずれも共通しているのは、「スコープが局所的に完結しており、システム全体のアーキテクチャ知識を必要としない」という点だ。LLMの制約を踏まえた上でタスクを選べば、生産性向上の恩恵は十分に享受できる。

エコシステムも進化しつつある。エージェント型ワークフローによりモデルが自身のコードを書いて実行・テスト・改善するループが回り始め、RAG（検索拡張生成）がハルシネーションを抑制し、実行時バリデーションがデプロイ前の欠陥を捕捉しつつある。

記事が描く将来像は、「スーパーモデル1つがエンジニアを置き換える」ではなく、推論モデル・永続メモリ・自動テスト・形式検証・実行時観測・専門エージェントが人間の監督下で連携する統合エンジニアリングシステムだ。

結論として記事はこう述べている——AIコーディングを制限している企業は、「生産性は享受しながら、信頼の外部委託を拒否する」という、現時点では最も合理的な判断をしているのかもしれない。ソフトウェアエンジニアリングにおいて、信頼を自動化することは依然として最も難しい問題だ、と。

詳細はWhy Some Companies Are Pulling Back on AI Codingを参照していただきたい。