日本企業の65.6％が「未テストコード」を本番投入、AI開発で何が起きているのか

生成AIやエージェント型AIの普及によって、ソフトウェア開発はかつてない速度で進むようになりました。しかし、コードを速く生成できることと、そのコードを事業に安全に実装できることは同義ではありません。AIへの投資をDXの成果につなげるためには、開発生産性だけでなく、信頼できるソフトウェアを継続的に提供できるかという観点から、品質保証の在り方を見直す必要があります。

AIで開発は高速化、品質保証は追いついているか

生成AIは、コードのたたき台の作成、既存コードの修正、ドキュメント作成、テストケースの生成といった作業を効率化しています。さらにAIエージェントは、与えられた目的に基づいて複数のツールを横断し、計画から実行までを担うようになりつつあります。

こうした技術は、開発者が定型作業に費やす時間を減らし、より多くの機能や改善を短期間で提供する可能性を広げます。一方で、AIが作成したコードにも、従来のコードと同様に、要件との不整合、セキュリティ上の問題、性能低下、既存システムとの連携不良が含まれる可能性があります。

つまり、AIが変えたのは、コードを作る能力だけではありません。開発組織が一定期間に扱う変更の量も増加させています。開発工程の処理能力が高まる一方、テスト、レビュー、承認、リリース判断が従来の運用のままであれば、その間に滞留が生じます。

企業が確認すべきは、AIツールを導入したかどうかではなく、AIによって増えた変更を、安全に本番環境へ届ける仕組みまで整備できているかです。開発工程だけの局所的な効率化ではなく、ソフトウェアデリバリー全体の実効性を見なければ、AI投資の本当の成果は測れません。

日本企業の65.6％が「未テストコード」を本番投入

Tricentisの「クオリティ・トランスフォーメーション・レポート2026」では、グローバル企業の60％、日本企業の65.6％が、未テストのコードを含むソフトウェアを本番環境へ展開していると回答しました。

その背景として挙げられているのが、リリース速度を優先するよう求められるプレッシャーと、AI生成コードの量が多すぎて、チームが十分にテストしきれないという問題です。

未テストコードはなぜ生まれる？ AIで変わるリスクの構造

注目すべきは、未テストコードが本番環境に投入されること自体は、AIの普及によって初めて生じた問題ではないという点です。2025年の同調査でも、グローバル企業の63％、日本企業の62％が、十分なテストを行わずにコードを出荷していました。

一方、その背景には変化が見られます。2025年の日本企業では、テストによるリリースサイクルの遅延を避けることや、偶発的に未テストコードが含まれることが主な理由として挙げられていました。これに対して2026年は、リリース速度を求めるプレッシャーに加え、AI生成コードの増加によって十分にテストしきれないという課題が表面化しています。

未テストコードという問題そのものは以前から存在していましたが、AIによってコード生成や変更の速度が上がったことで、品質保証側の処理能力とのギャップがより重要な課題になっていると考えられます。

未テストコードが本番環境へ到達する状況を、個々の開発者やテスト担当者の不注意だけで説明することはできません。開発側から供給される変更の量と、組織がそれを検証できる能力との間に差が生じているためです。

特に企業システムは、一つのアプリケーションだけで完結するものではありません。認証、決済、API、データベース、外部サービス、業務システムなどが相互に接続されています。そのため、一見小さなコード変更でも、依存する機能や業務プロセスへ影響が広がる可能性があります。

問題は、テスト担当者の人数が足りないことだけではなく、どの変更がどのシステムに影響し、どの検証を優先すべきかを判断する仕組みが十分に整っていないことです。未テストコードの本番投入は、AIによる開発量の増加に対して、品質保証の運用モデルが適応できていないことを示す指標と捉える必要があります。

AI活用の期待と、現場負荷のギャップ

経営層は、AIによる開発期間の短縮、生産性向上、デジタルサービスの迅速な市場投入に期待しています。Tricentisの調査でも、CEOの約5人に4人がAI主導のシステムやツールに高い信頼を示した一方、QAやDevOps担当者では、その割合が相対的に低いことが示されています。

この差は、AIに対する姿勢の違いというより、見ている対象の違いから生じます。経営層は、開発速度や投資効果といった成果を捉えます。一方、現場では、生成されたコードの確認、複数のAI・自動化ツールの管理、既存環境との統合、問題発生時の原因分析など、新たな作業が発生しています。

また、部門やプロジェクトごとに異なるAIツールを導入すれば、局所的には作業が速くなっても、組織全体ではワークフローやデータが分断される可能性があります。開発、QA、DevOpsの間で品質情報が共有されなければ、どのリスクが解消され、何が残っているのかを、リリース判断の時点で確認できません。

AI導入を現場のツール選定だけに委ねるのではなく、プロセス、責任、品質指標を含む運用モデルとして設計する必要があります。経営層が問うべきなのは、AIによってどれだけ多くのコードを作ったかではなく、現場が増加した変更を統制可能な状態にあるかという点です。

品質低下は「開発コスト」ではなく「事業リスク」

ソフトウェア品質の問題は、バグ修正や再テストに要する開発費用だけにとどまりません。顧客向けサービスが停止すれば、販売機会の損失や問い合わせ対応が発生します。基幹業務に影響すれば、受発注、生産、決済などのプロセスが止まる可能性があります。脆弱性やデータ処理の不備であれば、セキュリティやコンプライアンス上の問題にも発展します。

Tricentisの調査では、企業の5社に1社が、ソフトウェア品質の低下によって年間100万ドルを超える損失を被っていると回答しています。品質問題が発生した後には、修正作業だけでなく、復旧、原因調査、顧客対応、再発防止、監査対応など、複数部門にまたがるコストが発生します。

この観点に立つと、品質保証は開発部門の付随的な費用ではありません。システム停止や顧客信頼の低下を防ぎ、デジタル事業を継続するためのリスク管理です。

では、開発速度を落とすことなく、こうしたリスクを抑えるには、企業はどこに「品質投資」を行うべきなのでしょうか。後編では、その具体策として、継続的テスト、AI生成コードのレビュー責任、品質指標、品質ガバナンスの設計を取り上げます。