AIソフトウェア工場、速度偏重で不具合急増の罠

見えてきた弊害

不具合が開発者あたり54%増
インシデント比率242%増
AI採用安定性低下の相関
数カ月で生じるコード様式の乱立

勝つ工場の条件

道具寄せ集めでなく基盤整備
工程前段への品質管理組込み
再実行と追跡性の確保
標準化と安全策の徹底
詳細を読む

LLMの普及でコード生成の障壁が下がり、企業は開発を生産システムとして捉え始めています。VentureBeatに寄稿したデータ責任者のBenjamin Rogojan氏は2026年6月26日、AIで効率化した「ソフトウェア工場」の多くが、生産性向上ではなく不具合の量産に陥っていると警告しました。速さだけでは工場は機能しないという指摘です。

数字が問題を裏づけています。Faros AIの調査では開発者あたりのタスク処理量が33.7%、PRマージ率が16.2%伸びた一方、インシデント対PR比率は242.7%も上昇し、不具合は54%増えました。GoogleのDORA研究でも、AI活用の拡大がデリバリーの安定性悪化と関連づけられています。

現場では何が起きているのでしょうか。Rogojan氏が支援した複数の案件では、複数の技術者が速度を優先し標準が欠けた結果、AI生成のデータ基盤が時間とともに変質しました。従来は数年かかったコード様式の分裂が数カ月で5〜6通りに増え、技術者自身が中身を把握できなくなったといいます。

では機能する工場の条件は何か。氏は道具を端々に足すのではなく、生成・レビュー・テスト・追跡・改善を一つにつなぐプラットフォームが要だと説きます。あわせて、任意の処理をたどり再実行できる追跡性、ループより状態機械を使う設計も重視します。

品質管理の置き場所も鍵です。欠陥を最後に見つける旧来の製造業に対し、トヨタは異常時にラインを止める仕組みで不良の流出を防ぎました。ソフトウェアでも仕様の書き方から品質管理を組み込み、静的解析やテンプレートで早期に誤りを捉える必要があります。

結局のところ、出力速度の向上は下流の問題を抑えてこそ価値を持ちます。100マイルで壊れる車を量産しても生産的とは言えません。最も多くコードを書く工場ではなく、下流の欠陥が最も少ない工場が勝つ、と氏は結びます。