AI生成コードを平均点で見ない——言語・テスト・プロンプト・本番監視の四つの合格線

AIコーディングの導入判断では、「どのモデルが最も賢いか」「何％速く書けるか」という平均値が目立ちます。しかし、実際の開発現場で困るのは平均的な一問一答ではありません。Javaの既存基幹システム、Pythonの分析処理、TypeScriptのWeb画面、複雑なテスト、脆弱性修正、本番の障害対応では、失敗の見つかり方も、直し方も、影響範囲も違います。

AWSがAIコーディングエージェント「Kiro」の約150万件の会話を分析した報告では、静的解析を実行した範囲に限ると、Javaファイルのエラー率はPythonの約6.7倍でした。ただし、これは「JavaよりPythonなら正しいコードが出る」という単純な順位ではありません。型の厳しさや解析ツールが見つけられる範囲が違うためです。さらに、Googleは粗いAIコードスキャンでは真陽性率が7％を下回る場合があるとして、脆弱性を隔離環境で再現するMantisを公開しました。

数字が違うのは、製品の優劣だけでなく、何を失敗として数え、どこで検査し、誰が合格を決めるかが違うからです。本稿では、AI生成コードを一つの点数で認定せず、「生成時」「安全性」「プロンプト更新」「本番運用」の四つの合格線へ分けます。日本企業が既存資産を守りながらAI開発を広げるための、実務的な品質設計です。

Javaの26.7％とPythonの4.0％は、そのまま優劣表にできません

AWSの分析対象は、2026年1月から6月までにKiro IDEで交わされた約150万件の会話です。ここでいう会話には、人、モデル、ツールのやり取りが含まれます。その中から約40万6000件の静的解析ツール呼び出しを抽出し、Claude Opus 4.5から4.8、Claude Sonnet 4から4.6の複数モデルと言語を比較しました。

Opus 4.6で静的解析されたファイルを見ると、Javaのエラー率は26.7％、TypeScriptは8.6％、Pythonは4.0％、JavaScriptは1.6％でした。JavaはPythonの約6.7倍です。最も多いエラー群には、解決できないimport、未定義シンボル、構文エラー、存在しない参照などが含まれました。

ここでJavaを避ければ解決すると読むのは危険です。Javaは型、import、ジェネリクス、検査例外など、編集時に発見できる条件が多い言語です。反対に、素のJavaScriptや動的型付けのPythonは、同じ静的解析で見える範囲が狭くなります。低い静的エラー率は、実行時の正しさ、業務ロジック、性能、権限、データ品質まで保証しません。

比較すべきなのは、異なる言語の一つの割合ではなく、同じ言語、同じリポジトリ、同じ検査構成での変化です。Javaのチームなら、AI導入前後でコンパイルエラー、静的解析違反、テスト失敗、レビュー差し戻し、本番流出を追います。Pythonのチームなら、型検査を使う範囲、実行時例外、データ境界、数値結果の許容差を決めます。TypeScriptなら、型検査に加えてブラウザー挙動やAPI契約の試験が必要です。

日本企業では、長年動くJava資産と、新しいPythonやTypeScriptのサービスが同じ案件に混在しがちです。全社で「AI生成コードのエラー率」を一つにすると、検査が厳しいチームほど悪く見え、検査していない領域ほど良く見える逆転が起きます。品質表は会社一枚ではなく、言語とシステム境界ごとに作るべきです。

AIは解析ツールを置いただけでは、毎回使ってくれません

AWSの報告で重要なのは、エラーの件数だけではありません。AIエージェントが生成途中に自らdiagnosticsを一度以上呼び出した会話は、最も高いモデルでも22.26％、低いモデルでは2.74％でした。解析ツールへ接続できることと、完了前に必ず検査することは別です。

任意の道具としてリンターや言語サーバーを置き、「必要ならAIが使うだろう」と期待するだけでは抜けます。生成速度を優先したり、完了したと誤認したり、別の修正を続けたりするからです。そこで生成時の合格線は、モデルの自発性ではなく、外側のパイプラインへ置きます。

たとえば次の順序を固定します。

1. 対象ファイルを変更します
2. 言語サーバーとリンターを実行します
3. コンパイルまたは型検査を通します
4. 変更箇所に対応する単体テストを実行します
5. 関連する回帰テストを実行します
6. 差分と検査結果を一つの記録へまとめます
7. 未解決項目があれば完了扱いにしません

この流れでは、AIが検査を思い出したかどうかを品質条件にしません。生成した主体が人でもAIでも、同じ門を通します。検査コマンドを実行できない場合は、緑の合格ではなく「未実行」として止めます。

ただし、静的解析が通ったから安全とは限りません。AWS自身も、実行時エラー、ロジックの不具合、性能劣化は静的解析だけでは見えず、diagnosticsがきれいでもコードが正しいとは限らないと説明しています。以前の記事で整理した成果を別担当・別データ・別現場へ移せる再現条件と同じく、合格は一つの検査ではなく、対象と環境を明示して再現する必要があります。

テストコードは付録ではなく、別の製品として扱います

AWSの分析では、テストファイル当たりの平均エラー数は、ソースファイルの3倍から4倍でした。あるモデルではソースファイル当たり2.26件に対し、テストファイルは9.13件でした。テストにはモック、アサーション、初期化、外部サービスの代替、テスト対象コードの理解が同時に必要だからです。

この差は、AIにテストを書かせない理由ではありません。むしろ、テスト生成を「数を増やす仕事」から「判定条件を実装する仕事」へ変える理由です。AIが百件のテストを作っても、誤った期待値を百回確認していれば安心は増えません。実装とテストを同じ会話で一気に作ると、同じ誤解が両方へ複製されることもあります。

実務では、次の三つを分けます。

対象	AIへ任せやすい部分	人が先に定義する部分
実装	既存パターンに沿う変更、定型変換	業務目的、変更禁止領域、性能上限
テスト	ケース展開、境界値の候補、実行補助	正しい期待値、失敗時の意味、必須ケース
判定	結果集計、差分表示、再試行	合格条件、例外承認、公開可否

とくに金額、権限、在庫、医療、個人情報に関わる処理では、人が具体例から期待値を固定してからAIへ渡します。実装を書いたAIとは別の手順でテストを見直し、最低一つは意図的に壊した入力で失敗することを確認します。通るテストだけでなく、止まるべきときに止まるテストが必要です。

脆弱性は「見つけた」ではなく、隔離環境で再現して初めて候補になります

Googleが公開したMantisは、脆弱性の発見、優先順位付け、修正を支援するオープンソースのハーネスです。Googleは、作りが粗いAIコードスキャンでは存在しない不具合を報告し、真陽性率が7％未満になることも多いと説明しています。警告を大量に出すだけでは、防御側の仕事を減らせません。

Mantisは、批評やレビューを担うエージェントと、脆弱性を隔離した環境で再現する仕組みを組み合わせます。リポジトリの履歴や過去の修正も参照し、ファイル、ディレクトリ、全体という階層でセキュリティ要約を作ります。Googleの説明では、この階層要約により、大規模リポジトリの構造的な文脈を保ちながらトークン負荷を85％超削減したとしています。

85％という数字はGoogleの環境と手法に基づく公表値であり、どの企業でも同じ節約になる保証ではありません。より重要なのは、脆弱性候補を文章の説得力で採用せず、再現条件へ落とすことです。

安全性の合格線には、少なくとも次の項目を含めます。

• 影響を受ける版と構成
• 攻撃に必要な権限、入力、ネットワーク条件
• 隔離環境で再現した手順と証拠
• 誤検知と判断した理由
• 修正前に失敗し、修正後に通る回帰試験
• 修正が別機能を壊していない証拠
• 公開、通知、優先順位を決めた担当者

AIが「重大」と書いたことは、重大性の証拠ではありません。反対に、再現できなかった候補も即座に無価値とは限りません。環境差、権限不足、情報不足を分け、保留として再現条件を残します。警告件数を成果指標にすると、誤検知を増やすほど評価が上がってしまいます。測るべきは、再現できた問題、正しく棄却した候補、修正後に再発しなかった問題です。

システムプロンプトも、更新されるソフトウェアです

AIコーディングの品質はモデルだけで決まりません。システムプロンプト、利用できるツール、リポジトリの規約、実行環境、利用者の依頼が組み合わさって挙動になります。モデルを新しくしても、古いモデル向けに積み上げた指示が残れば、過剰な制約や矛盾になる場合があります。

AWSはKiroのシステムプロンプトを、ベンチマークだけでなく、社内開発者による数千件の実会話で継続評価しています。会話を15の挙動品質で採点し、コードを読まずに結論を出す、既存パターンを無視する、仕事を終える前に停止するといった問題を分類します。ある試行では、安全性、検証、文章の調子、挙動にまたがる27個の変更候補を比較し、悪化を示す候補を除外しました。

AWSが紹介した初期比較では、Kiro CLIで明示的な不満が5％、挙動品質の問題が32％、タスク完遂の問題が10.6％減りました。Kiro IDEでは未完了の返答が21％、失敗する方法の反復が36％、スタイル不一致が54％減ったとしています。一方、新しい高性能モデルへ替えた後は、同じプロンプト変更による改善幅が4％に縮まり、古い指示が新モデルの能力を妨げる例も確認されました。

これらはAWS社内のKiro利用を対象とした結果です。別の会社、別のモデル、別の作業へそのまま移せません。それでも、プロンプトを秘密の呪文ではなく、版管理し、比較し、戻せる構成として扱う考え方は移せます。

プロンプト更新の合格線は、次の四段階にします。

1. 変更理由と改善したい失敗を一つに絞ります
2. 固定した過去事例と、最近の実会話の両方で比較します
3. 改善項目だけでなく、悪化してはいけない項目を測ります
4. 対象モデル、ツール、日付を記録し、すぐ戻せるようにします

モデル更新とプロンプト更新を同じ日に本番投入すると、原因を分けられません。可能なら片方ずつ替えます。難しい場合でも、旧構成と新構成へ同じ案件を流し、差分を保存します。プロンプトの行数を増やしたことを改善とせず、不要になった回避策を削ることも変更として扱います。

本番では「正答率」だけでなく、費用と復旧時間も監視します

Dynatraceが大企業のSRE、プラットフォームエンジニア、IT運用の管理職919人を対象に実施した調査では、SREの67％がAIモデル監視を重要な用途に挙げ、58％がモデル性能や精度の監視機能を利用していると回答しました。従来のSLOを一部以上のチームで使う回答は89％でした。

一方、AIは信頼性や開発者生産性ではおおむね期待に応えているものの、費用削減や平均修復時間の短縮では期待を下回ったと報告されています。プラットフォームエンジニアの37％は既存ツールとの統合を最大の課題に挙げ、開発から本番まで全段階へ可観測性を組み込んでいる回答は40％でした。半数近くは、データ源と指標が多すぎて有効なSLOを定義しにくいと答えています。

この調査はDynatraceの委託で実施され、年間売上高5億ドル以上の企業を対象にしています。日本の中小企業へ割合を直接一般化はできません。ただし、「AI指標を増やせば監視できる」のではなく、利用者の完了と復旧へ結び付く少数の指標が必要だという課題は共通します。

本番運用では、CPU、メモリー、応答時間だけでなく、次の指標を案件単位でつなぎます。

• 合格した成果物の割合
• 人が修正した行数ではなく、差し戻し理由の分布
• 静的解析、テスト、脆弱性再現の未実行率
• 同じ入力で結論が変わった割合
• モデル、プロンプト、ツール更新後の悪化率
• 完了一件当たりの推論費、待ち時間、人の確認時間
• 問題発見から停止、切り戻し、再開までの時間

指標は多いほど良いわけではありません。担当者が変えられない数字は、監視画面を埋めても改善につながりません。たとえばトークン数が増えたとき、再試行、不要な長文、巨大な入力、古いプロンプトのどれを直すのかまで結びます。正答率が下がったときも、入力分布、モデル版、言語、テストの不足へ分解します。

AIの利用時間や実行回数を価値と混同しない健全利用率で整理したように、活動量には必ず出口を対にします。AIコードの生成行数を増やすことではなく、合格した変更を安全に本番へ送り、問題時に戻せることが出口です。

日本企業向けの「四関門リリース票」を作ります

四つの合格線を、一枚のリリース票へまとめます。AIとの会話履歴とは別に、チケット、プルリクエスト、CIの成果物として保存します。

関門	必須記録	合格条件	戻す先
生成時	言語、対象版、変更差分、解析・型検査・テスト結果	必須検査が実行済みで未解決がない	変更前ブランチ
安全性	脆弱性候補、再現環境、影響範囲、修正後試験	重大候補を再現または説明付きで保留	隔離環境と修正前版
プロンプト更新	モデル版、プロンプト版、比較対象、守る指標	改善と回帰防止を同じ母集団で確認	旧モデル・旧プロンプト
本番運用	完了一件費、失敗分類、停止・復旧時刻	SLO内で完了し、異常時に切り戻せる	人の手順または安定版

この票で大切なのは、四関門を一つの総合点に戻さないことです。生成時の検査が100点でも、安全性を再現していなければ公開しません。セキュリティ警告が少なくても、本番費用が上限を超え続けるなら拡大しません。プロンプト評価が改善しても、Javaの基幹処理とPythonの社内ツールを同じ条件で認定しません。

また、すべてを人が目視する設計にも戻しません。解析、テスト、再現、比較、監視は機械へ任せられます。人は、合格条件、例外、業務影響、公開、切り戻しを決めます。「人が確認」という曖昧な欄ではなく、誰が何を見て、どの条件なら承認できるかを書きます。

30日で平均点から案件別の合格へ移します

最初の一週間は、AIコーディングを使っている一つのリポジトリを選びます。過去十件の変更から、言語、テスト種別、差し戻し、本番問題を集めます。全社平均は作らず、同じリポジトリで比較できる基準線を作ります。

二週目は、完了前の必須検査をCIへ固定します。AIが自主的にツールを呼んだかではなく、静的解析、型検査、単体テスト、回帰試験が必ず実行されたかを記録します。テストを一つ意図的に壊し、失敗時に完了扱いにならないことも確かめます。

三週目は、脆弱性候補を一件選び、隔離環境で再現します。警告文だけで優先順位を決めず、影響する版、入力、権限をそろえます。同時に、現在のシステムプロンプトへ版番号を付け、変更候補を一つだけ比較します。

四週目は、本番指標と切り戻しをつなぎます。費用上限、待ち時間、差し戻し、再試行、復旧時間を案件番号で追います。モデルを停止し、前の安定版または人の手順で一件を完了できるか試します。AIへ渡す専用の作業場所と復旧経路も併用すれば、コード品質だけでなく、権限と原本の境界も守れます。

30日後は、次の七項目を見ます。

1. 必須検査を実行せず完了した変更がゼロか
2. 言語別の検査結果が改善したか
3. テストが壊れたとき確実に停止したか
4. 脆弱性候補を再現、棄却、保留へ分類できたか
5. プロンプト変更の改善と悪化を同時に比較したか
6. 完了一件当たりの費用と人の確認時間が見えるか
7. AI停止後に安定版へ戻して一件を完了できたか

主な出典

• ＠IT「AIが書くコード『エラー率はJavaがPythonの6.7倍』」（2026年9月15日、AWSのKiro利用分析を紹介）
• Google Cloud「Getting started with Mantis」（2026年9月2日、Mantisの設計と社内利用に関するGoogleの説明）
• AWS「継続的なプロンプト評価」（2026年8月25日、Kiro社内評価の手法と結果）
• Dynatrace「The State of SRE and Platform Engineering 2026」（2026年8月25日、大企業の実務者919人を対象とした委託調査）
• ＠IT「実運用へ広がるAI活用、『SRE』にも変化」（2026年10月1日、Dynatrace調査の日本語解説）

結論——AIコードの品質は、モデル名ではなく通過した関門で説明します

AI生成コードのJavaエラー率がPythonより高いという数字は、現場へ有用な警告を与えます。しかし、言語の順位表として使えば、検査で見える範囲の違いを品質差と取り違えます。静的解析が通っても、テストの期待値、脆弱性の再現、プロンプト更新の回帰、本番の費用と復旧は残ります。

これから日本企業が持つべきなのは、「最新モデルを導入済み」という一行の説明ではありません。どの言語と版で、どの検査を通し、どの脆弱性を再現し、どのプロンプト構成で比較し、本番で何を監視し、どこへ戻せるかという一件の記録です。

あなたの会社で次にAIが書いた変更を受け入れるとき、聞くのは「どのモデルが書いたか」でしょうか。それとも、「生成時、安全性、プロンプト更新、本番運用の四関門を、どの証拠で通ったか」でしょうか。