AIが生成したコードは、正常に動けば「良いコード」と言えるのでしょうか。
AIコーディングエージェントは、人間が目的を指示すると、計画、実行、検証、修正を繰り返しながらコードを仕上げます。人間が一行ずつ書いていたコードを、短時間で作れる場面が増えています。
ただ、動くコードと、あとから安全に変更できるコードは別のものです。機能を足そうとしたとき、複雑に絡み合った処理のせいで修正が難しくなることがあります。一方で、AIが何度でも書き直せるなら、将来の変更に備えた設計に、従来と同じ費用をかける必要があるのかという疑問も出てきます。
コードを作る費用が下がっても、その正しさを確かめる費用まで同じように下がるとは限りません。 動作の正しさは品質の一部にすぎず、あとから変更しやすいか（保守性）や、不正な入力への強さ（セキュリティ）のように、動かしただけでは見えない条件が残ります。
AI生成コードは正常に動けば十分なのか
十分とは言えません。正常に動くことはコードの品質の一部で、ソフトウェアにはほかにも、セキュリティ、処理性能、将来の変更のしやすさといった品質が求められます。
国際規格のISO/IEC 25010:2023は、ソフトウェアを含むICT（情報通信技術）製品の品質を9つの特性に分けて定めています。
この記事では、関連する品質を次の4つに分けて考えます。
| 品質 | 何を評価するのか | 動作確認だけでは見えない例 |
|---|---|---|
| 機能の正確性 | 要求どおりに動くか | AIが仕様を誤解してコードとテストの両方を作った場合、期待した機能と異なる実装でもテストに合格することがある |
| セキュリティ | 不正アクセスや情報漏えいに対処できているか | 通常の操作では問題なく動くが、悪意のある入力を受けたときに弱点が現れる |
| 保守性 | 理解、修正、検証がしやすいか | 機能は動くが、同じ情報が複数の場所にあり、仕様変更のたびに関係する箇所を探して直す必要がある |
| 性能効率 | 必要な処理速度と資源効率を満たすか | 少量のデータでは速いが、データが増えると処理時間が大きく伸びる |
右の列は、品質の違いを説明するために記事側で考えた例です。
AIによってコードの修正やテスト作成の費用が下がる可能性はあります。ただし、その効果は品質の種類や、何を確認する必要があるかによって変わります。
例えば、AIが大量のテストを生成しても、そのテストが検証すべき業務ルールを確認していなければ、不具合を見落とす場合があります。必要なのはテストの数だけでなく、何を確かめるべきかを正しく定めることです。
すべてのコードに高い保守性は必要なのか
必要な水準は、コードごとに違います。
保守性とは、ソフトウェアを修正したり、新しい要求に合わせたりしやすい性質です。
Markus Borgらの論文は、ISO/IEC 25010の2011年版に基づき、改善、修正、環境や要求の変化への適応のために、製品やシステムをどれだけ効果的かつ効率的に変更できるかを保守性としています。
保守性が低い状態は、例えば、同じ顧客情報を複数の場所で別々に管理しているシステムに現れます。データの構造を変えるたびに、関係する処理を探して直さなければなりません。顧客情報を一か所で一貫して扱う設計なら、変更の影響を把握しやすくなります。
Borgらの論文が引用する定義では、短期的には都合がよいものの、将来の変更をより高くつくものにしたり、不可能にしたりする設計や実装上の選択を「技術的負債」と呼びます。この定義はAvgeriouらの2016年の研究に基づいています。
将来の変更に備えた設計には、作る時点で費用がかかります。一度だけ実行して捨てるスクリプトに、長期運用するシステムと同じ設計をしても、その費用を回収できるとは限りません。
反対に、使う期間が短くても、仕様が頻繁に変わるなら、保守性への投資が合理的になる場合があります。長く使うシステムでも、ほとんど変更しないなら、追加の投資が正当化されるとは限りません。
保守性の経済的な価値は、使用期間だけでなく、将来の変更の頻度、変更の難しさ、失敗したときの影響、変更に必要な費用によって左右されます。
AI生成コードの保守性は、研究で何が分かっているのか
開発者を対象にした実験では、AI支援の有無による保守性の統計的に有意な差が検出されませんでした。一方、公開されたソフトウェアの変更履歴を調べた研究では、AIによる変更が持ち込んだ品質上の問題が、その後も残っていたことが報告されています。
統計的に有意な差とは、データに見られる差が、偶然のばらつきだけでは説明しにくいと判断できる差を指します。
2つの研究では測定したものが違うため、それぞれの結果を分けて読む必要があります。
151人が参加した保守性の実験（Borgら）
2026年6月、Markus Borgらは学術誌 Empirical Software Engineering に「Echoes of AI: Investigating the downstream effects of AI assistants on software maintainability」を発表しました。
研究全体には151人が参加し、その約95％がプロの開発者でした。実験は2段階に分かれています。最初の段階では、参加者がJavaのWebアプリケーションに新しい機能を追加しました。AIアシスタントを使う開発者と、使わない開発者がいます。次の段階では、別の開発者が最初の段階で作られたコードを引き継ぎ、AIを使わずにさらに変更しました。後続変更をする参加者は、AI支援で作られたコードを引き継ぐグループと、そうでないコードを引き継ぐグループに無作為に割り当てられました。
後続変更の課題を完了したのは75人で、作業完了時間の分析には72件のデータが使われています。研究チームは、変更にかかった時間と、コードの複雑さなどを評価するCodeHealthという指標を用いて保守性を調べました。CodeHealthは、コードの理解や変更を難しくする兆候を検出し、1から10までの点数で評価する指標です。こうした問題の兆候は「コードスメル」と呼ばれます。
その結果、AI支援で作られたコードと、そうでないコードの間で、後続変更の作業時間とコード品質に統計的に有意な差は検出されませんでした。 後続変更の作業時間の中央値（全員を短い順に並べたときの真ん中の値）は、AI支援で作られたコードを引き継いだグループが136分、そうでないコードを引き継いだグループが173分でした。数値だけを見ると前者のほうが短時間ですが、参加者によるばらつきが大きく、研究チームは統計的に有意な差とは判断していません。別の統計手法であるベイズ統計で分析しても、研究チームは、AI利用による改善があるとしても小さく、不確かだと報告しています。
一方、最初の実装段階では、AIを使わなかった参加者と比べて、AIを使った参加者の作業完了時間の中央値が30.7％短くなっていました。この30.7％は、AIを利用するかどうかを無作為に割り当てた結果ではなく、参加者の実際の利用状況に基づく観察結果です。そのため、短縮分のすべてがAI利用によって生じたとまでは断定できません。
実験には限界もあります。データ収集は2024年10月から2025年1月にかけて行われ、当時のAIコーディング支援ツールを対象としています。AIエージェントが開発課題全体を自律的に担当した例は観測されていません。また、対象は一つのJavaアプリケーションであり、研究チーム自身も、参加者数の制約によって小さな差や中程度の差を検出できなかった可能性を認めています。有意な差が見つからなかったことは、あらゆる状況でAI生成コードと人間が書いたコードの保守性が同じだと証明されたことを意味しません。
研究チームは今後の課題として、過剰なコード生成によるコードの肥大化や、開発者が思考の一部をAIに任せることで生じる「認知的負債」も挙げています。認知的負債は、AIに作業を任せることで、開発者自身がコードや設計を十分に理解できなくなる懸念に関係する概念です。
約30万件のコミットの分析（Liuら）
Yue Liuらは2026年3月に「Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild」を公開し、同年4月26日に改訂しました。
研究チームは、GitHub（開発者がコードを公開・共有するサービス）上の6,299のリポジトリから、AIが作成または共同作成したと確認できる約30万2,600件のコミットを集めています。リポジトリはコードや変更履歴を管理する場所、コミットはコードの変更を記録する単位です。対象には5種類のAIコーディングアシスタントが含まれます。
研究チームは、コードを実行せずに機械的に分析する静的解析を使い、AIによる変更の前後を比較しました。そして、その変更によって新たに持ち込まれた品質上の問題を調べています。
検出された問題は484,366件でした。その89.3％はコードスメルで、コードの構造や理解・変更のしやすさに関係する問題です。さらに、対象となったすべてのAIアシスタントで、15％を超えるコミットが少なくとも1件の問題を持ち込んでいました。追跡した問題の22.7％は、分析時点のリポジトリの最新版にも残っていました。
この研究からは、AIによる変更が持ち込んだ品質上の問題の一部が、その後の開発でも残存していることが分かります。
ただし、静的解析が検出した問題のすべてが、実際の障害を引き起こしたわけではありません。検出された問題の件数を、そのまま障害件数や保守費用へ読み替えることもできません。
また、この研究は、AIによる変更を追跡した観察研究（研究者が条件を割り当てず、既存の記録を分析する研究）です。人間が書いたコミットとの直接比較によって、AI生成コードのほうが問題を起こしやすいと証明したものではありません。AIが関与したコミットに、人間による編集が含まれる可能性もあります。
論文はarXivで公開された2026年4月26日改訂のプレプリントで、ここで紹介した数値はその版に基づいています。プレプリントとは、学術誌などでの正式な掲載に先立って公開される研究原稿です。
2つの研究が示す保守性の違い
変更作業の時間と、静的解析によって検出された問題の残存率は、異なる指標です。そのため、Borgらの研究で有意な差が見つからなかったことと、Liuらの研究で品質上の問題が残っていたことは、両立する結果です。
AIがコードを修正するなら、保守性の価値は変わるのか
AIがコードの理解や修正まで担当するなら、保守性への投資価値も変化する可能性があります。
従来の保守では、人間がコードを読み、設計を理解し、影響範囲を調べて変更してきました。AIがこうした作業の一部を担えば、人間がコードを理解するために費やす時間を減らせるかもしれません。
ただし、AIの修正が短時間で終わっても、その変更が既存機能に与える影響を調べるために多くの時間が必要になる場合があります。
AI生成コードの保守は、誰が担当しているのか
Shota Sawadaらの研究によると、調査対象となったAI生成ファイルの保守作業の約83％は、人間の開発者が行っています。
2026年5月、Sawadaらは「To What Extent Does Agent-generated Code Require Maintenance? An Empirical Study」を公開しました。
研究チームは、AIが作成したプルリクエストのデータセットとGitHubの変更履歴を利用し、人気の高い100のリポジトリから、1,000を超えるファイルと約3,200件の変更を分析しています。プルリクエストとは、作成したコードの変更をプロジェクトへ取り込むよう提案する仕組みです。
研究では、AI生成ファイルは人間が書いたファイルより更新頻度が低く、更新時に変更される範囲もファイルの一部にとどまる傾向が見られました。AI生成ファイルでは機能追加に関係する変更が最も多く、人間が書いたファイルでは不具合修正が中心でした。
研究チームは、この結果について、AIエージェントが生成するコードには一定の初期品質がある一方、継続的な保守には人間の関与が必要だと解釈しています。
ただし、AI生成ファイルの更新頻度が低い理由は、この数字だけでは決まりません。コードが安定している可能性もあれば、変更する機会が少なかった可能性もあります。更新頻度は、保守のしやすさを直接測定した指標ではありません。
この研究ではAI生成ファイルと人間が書いたファイルの変更履歴を比較していますが、AI利用の有無を無作為に割り当てた対照実験ではありません。
論文は2026年5月9日改訂のプレプリントとして公開され、ソフトウェア工学の国際会議EASE 2026のショートペーパー（短い論文の発表枠）として採択されています。
人間が読みやすいコードと、AIが変更しやすいコード
人間がコードを保守するとき、分かりやすい名前、役割ごとに整理された処理、見通しのよい依存関係が理解を助けます。依存関係とは、ある処理が別のどの処理に頼っているかという関係です。
AIが保守する場合にも、既存コードの構造を正しく把握できるかどうかが、変更の成否に関係すると考えられます。
例えば、ある機能の変更に多数のファイルを修正する必要があり、設計意図も記録されていないとします。AIは、複数の場所にある処理の関係を把握し、必要な箇所を変更しなければなりません。
この複雑さによって変更の失敗が増えるなら、設計を整理する価値はAIが修正する場合でも残ります。
一方、人間がコードを理解するために必要だった説明や整理の一部を、AIが別の方法で補えるなら、従来と同じ設計上の工夫に同じ費用をかける必要はなくなるかもしれません。
この記事で参照した研究だけでは、人間に読みやすいコードとAIが変更しやすいコードが、同じ構造を求めるのかどうかは判断できません。
その違いを確かめるには、設計の複雑さによってAIの変更成功率、修正時間、修正後の検証費用がどれだけ変わるかを測定する必要があります。
AIによる保守性への投資価値を考えるには、変更に成功するまでの費用と、その変更が正しいと確かめる費用の両方を見る必要があります。
AIでコードを作り直すほうが合理的になるのか
場合によります。AIがコードを安く生成できるなら、既存コードを修正し続ける代わりに、必要な機能を最初から作り直す（再生成する）という選択も現実的になります。
その判断には、AIによって実際にどの程度の作業時間を削減できるかという前提があります。
AIを使うと開発作業はどれくらい速くなるのか
作業時間への影響は、調べた開発者や課題、時期によって結果が異なり、どの程度速くなるかを一律には決められません。
AIの能力を評価する研究機関METRは、経験豊富なオープンソース（ソースコードが公開され、定められたライセンスのもとで利用・改変できるソフトウェア）の開発者を対象にした2025年前半の実験で、AIを使うと作業時間が平均19％増加したと報告しました。信頼区間は2％から39％の増加でした。
信頼区間とは、調査データから求めた推定値に、どの程度の不確かさがあるかを示す統計的な範囲です。
その後、METRは2026年2月24日に追跡研究の状況を公表しています。
2025年前半の実験にも参加した開発者については18％の時間短縮、新たに参加した開発者については4％の時間短縮という推定結果が出ました。それぞれの信頼区間は、前者が38％の短縮から9％の増加、後者が15％の短縮から9％の増加で、いずれも作業時間が増える場合を含んでいます。
また、AIなしでは働きたくない開発者が参加を避けるといった偏りがあり、METR自身も、速度向上の大きさについては非常に弱い証拠だと説明しています。
これらの研究は、特定の開発者と開発課題における作業時間の変化を調べたものです。ソフトウェアの長期的な保守費用や、コードを一から作り直す場合の総費用を直接測定した結果ではありません。
作り直しで残る確認作業
例えば、外部サービスから取得したデータを決まった形式に変換する小さなプログラムがあるとします。処理の仕様が明確で、入力と期待する出力が分かっているなら、複雑な既存コードを調べて修正するより、AIに新しく生成させたほうが早い場合があります。
一方、長く運用してきた業務システムには、表面上の機能からは分からない処理が含まれる場合があります。顧客情報の管理、外部サービスとの通信、過去の不具合に対応するために追加された例外処理などです。
作り直すときには、どの動作を残し、どの動作を変えるかを決めなければなりません。そのうえで、既存データを引き継ぎ、外部システムとの接続を確かめ、新旧の処理結果を比較する必要があります。
保守と作り直しに必要な作業を整理すると、次のようになります。
| 保守する場合 | 作り直す場合 |
|---|---|
| 既存コードの理解 | 既存の仕様や動作の把握 |
| 変更箇所の特定と修正 | 新しいコードの生成 |
| 修正の影響範囲の確認 | 旧コードとの動作の比較 |
| 既存機能が壊れていないかを確かめるテスト | 新しいコード全体の検証 |
| 今後の変更に伴う費用 | データ移行や外部連携の調整 |
既存機能が変更後も正しく動くかを確かめるテストは「回帰テスト」と呼ばれます。
実際には、保守と作り直しで共通する作業もあり、作り直す範囲によって費用は大きく変わります。
今回参照した研究には、保守と作り直しの費用を直接比較し、どちらが安いかを一般化できる結果はありません。
既存コードが仕様書の役割を果たしている場合
ソフトウェアの動作は、必ずしも仕様書に書き切られていません。
例えば、過去の障害を避けるために追加された条件分岐が、その意図を説明できる担当者がいないまま残っていることがあります。
新しいコードを作るとき、その条件分岐が現在も必要なのか、削除してよい古い処理なのかを判断しなければなりません。
既存の動作を十分に記録した仕様やテストがなければ、古いコードを調べる作業そのものが必要になります。
場合によっては、既存コードそのものが、仕様書に残されていない業務上の知識を保存していることがあります。
コードに含まれている業務上の知識を取り出し、正しく引き継ぐためには、その動作を確認し、必要なものを特定する作業が残ります。
作り直しを選ぶには、維持すべき動作がどこまで明確になっているか、新しい実装でそれを再現できたと確かめる手段があるかを検討する必要があります。
AI時代に良いコードをどう判断するのか
すべてのソフトウェアに同じ水準の保守性を求める必要はありません。コードが安く作れても、必要な品質は、そのソフトウェアの用途によって変わります。
品質への投資を考えるには、次の4つの問いが判断材料になります。
- 何のために使うのか：誤った結果が出た場合、処理をやり直せるのか。金銭的な損害や情報漏えいにつながるのか。
- どれだけ使われるのか：利用期間だけでなく、利用者の数や利用頻度も含めて考える。小さな不具合でも、多くの人に影響する場合がある。
- どんな変更が見込まれるのか：将来の変更頻度と、その変更の難しさを考える。
- 失敗したら何が起こるのか：誤動作を容易に元へ戻せるのか。一度の失敗が大量のデータや人の安全に影響するのか。
以下の3つは、4つの問いの使い方を説明するための例です。
一度だけ使うデータ変換プログラム
作り直しの節で挙げたデータ変換のように、使うのが一度きりで、将来の変更もほぼないとします。
入力の種類や重要な条件を把握でき、期待する出力も明確なら、保守するより作り直すほうが合理的な場合があります。変換結果を元データと照合でき、誤りが見つかったときに安全にやり直せることも、判断材料になります。
一度だけ使うプログラムでも、失ってはいけないデータを扱う場合や、変換結果を十分に確認できない場合には、追加の検証が必要です。
継続的に変更するECサイト
商品の管理、決済、顧客データ、外部サービスとの接続を扱い、多くの利用者が日常的に使うシステムです。
商品やキャンペーンの変更、決済サービスの仕様変更などに合わせて改修が続きます。決済や顧客データに関する誤りは、利用者の損害につながる場合があります。
このようなシステムでは、頻繁な変更に対応するため、保守性への投資が合理的になりやすい条件がそろっています。
一方で、コードを作り直すかどうかは、生成費用だけでは決められません。既存データを引き継げるか、外部サービスとの接続を再現できるか、過去の例外処理を維持できるかといった検証費用が判断を左右します。
安全性が求められる制御システム
機械や設備の動作を制御するシステムでは、誤動作が人の安全や設備の損害につながる場合があります。
このようなシステムでは、コードの生成費用よりも、要求された動作を満たすことや、その正しさを検証できることの比重が大きくなります。
AIによってコードの作成や修正が速くなっても、必要な安全性が確保されたと確認する手続きまで省略できるわけではありません。実際に必要となる検証は、対象となる設備や用途、想定される危険に応じて決める必要があります。
AIでコードを作り直す費用が下がるほど、何を作るべきかを示す仕様、正しさを確かめるテストや検証の仕組み、そして引き継ぐべきデータの価値は、相対的に大きくなると考えています。
これは研究で確かめられた結論ではなく、この記事の仮説です。
ただし、仕様書に残っていない業務ルールが既存コードに含まれているなら、そのコード自体にも守る価値があります。
何を重くみるかは、ソフトウェアごとに違います。3つの例のように、4つの問いに答えていくと、必要な品質と、そこにかける費用の見当がつきます。
AIがコードをいくらでも書ける時代に、私たちは何に価値を置いてソフトウェアを作るべきなのか。
FAQ
AI生成コードの品質は、何を基準に判断すればよいですか？
正常に動作するかどうかに加え、セキュリティ、保守性、性能などを評価します。どの品質をどの水準まで求めるかは、ソフトウェアの用途や、失敗した場合の影響によって変わります。
AIが生成したコードは、人間が書いたコードより品質が低いのですか？
一律には判断できません。AI支援で作られたコードと、そうでないコードを別の開発者が変更する実験では、作業時間とコード品質に統計的に有意な差は検出されませんでした。一方で、AIによる変更で持ち込まれた品質上の問題が残存する事例も報告されています。
テストに合格したAI生成コードは安全ですか？
テストに合格しても、テストの対象に含まれていない条件では不具合が残る場合があります。必要な業務ルールを正しくテストできているか、セキュリティ上の問題がないかも確認する必要があります。
AI生成コードをレビューする際の具体的な確認方法は、AIコード時代、コードレビューは誰のためにあるのかでも取り上げています。
AIでコードを作り直せば、技術的負債はなくなりますか？
複雑な実装を整理できる場合はありますが、既存コードに含まれる業務ルールや例外処理を失うおそれもあります。作り直したコードについても、正確性や既存データとの整合性を確認する作業が必要です。
AIが保守するなら、人間に読みやすいコードは不要ですか？
人間がレビューや障害対応を担当する場合、コードを理解しやすいことには価値があります。AIにとって変更しやすい構造が、人間向けの構造と同じかどうかは、この記事で参照した研究からは分かっていません。
参考・参照元
- ISO, ISO/IEC 25010:2023 — Systems and software engineering — Product quality model
- Markus Borg et al., Echoes of AI: Investigating the downstream effects of AI assistants on software maintainability, Empirical Software Engineering, 2026年6月9日
- Yue Liu et al., Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild, arXiv, 2026年4月26日改訂版
- Shota Sawada et al., To What Extent Does Agent-generated Code Require Maintenance? An Empirical Study, arXiv, 2026年5月9日改訂版
- EASE 2026, To What Extent Does Agent-generated Code Require Maintenance? An Empirical Study — Short Papers and Emerging Results
- METR, We are Changing our Developer Productivity Experiment Design, 2026年2月24日
