はじめに
私が開発しているOSS「Shortcut Expert」では、AI駆動開発を採用しています。自分は実現したい動作を指定し、内部の設計や実装は基本的にAIエージェントに任せてきました。
最初は順調でしたが、機能を追加するにつれて、期待する動作を実現するまでの手戻りが増えてきました。以前は1〜2回の修正で済んでいたものが、最近では5〜6回ほど修正を繰り返すこともあり、トークン消費の増加や開発速度の低下が気になり始めました。
原因を調べるためにコードを確認すると、設計上の問題が見つかりました。
Shortcut Expertでは、キー操作やマウス操作の検出ロジックが複雑化し、C#とTypeScriptの責務も曖昧になっていました。一つの機能を追加するために、多くの箇所を変更する必要がある状態です。
こうした設計上の問題も手戻りの増加に関係しているのではないかと考え、現在リファクタリングを進めています。
この経験から、アーキテクチャの設計やコードレビューは、ある程度自分で行う必要があると感じました。
それと同時に、コードの保守性が悪化していることを、もっと早い段階で検出できないかと考えました。
そこで今回はソフトウェアメトリクスに着目し、保守性の定義やAI開発に関する研究を調べたうえで、どの指標を測定すべきか考えます。
想定読者
- AIエージェントに実装を任せている方
- コードの保守性を客観的に評価したい方
- ソフトウェアメトリクスに興味がある方
そもそも保守性とは？
ソフトウェア品質の国際規格であるISO/IEC 25010:2023では、保守性を、ソフトウェアを効果的かつ効率的に変更できる能力として定義しています。
保守性は、次の5つの観点から構成されます。
| 観点 | 意味 |
|---|---|
| モジュール性 | 一部の変更が他の部分に影響しにくい |
| 再利用性 | 別の用途でもコードを利用できる |
| 解析性 | 問題や変更箇所、影響範囲を把握しやすい |
| 変更容易性 | 不具合を増やさず効率よく変更できる |
| テスト容易性 | 正しい動作を検証しやすい |
簡単に言えば、将来の機能追加や修正を、既存機能を壊さず、少ない労力で継続できるかということです。
AIが実装する時代、保守性にはどんな問題があるのか？
2025〜2026年に発表された研究を中心に、AI開発における保守性の問題を調べてみました。
1. 開発速度は上がっても、コードが複雑化する可能性がある
Speed at the Cost of Quality（MSR 2026）では、Cursorを導入したOSSプロジェクトと、類似する非導入プロジェクトを比較しています。
その結果、開発速度は一時的に向上した一方、コードの複雑度や静的解析の警告数は継続的に増加しました。また、これらの品質指標の悪化が、その後の開発速度低下に関係するという分析結果でした。
短期的には開発が速くなっても、長期的には保守負担が増える可能性があるということです。
私が個人開発で感じた問題にも、かなり近い結果でした。
2. AIは適切な設計を維持できるとは限らない
Understanding the Code and Architectural Smells Generated by LLMs and Autonomous Agents（ASE 2026）では、AI生成コードにも、コードの肥大化や強い結合といった設計上の問題が見られました。
また、CodeTaste（ICML 2026）では、具体的なリファクタリング方法を指示すると比較的うまく実装できる一方、適切な改善方針をAI自身に判断させるのは難しいことが報告されています。
もちろん、人間と異なる設計を選んだからといって、必ずしも間違いとは限りません。
ただ、AIが正しく実装できることと、適切な設計を自律的に選択できることは別だと考えられます。
3. AIが書いたコードは、後から変更しにくい可能性がある
Is Agent Code Less Maintainable Than Human Code?（EMNLP 2026）では、人間が書いたコードとAIが書いたコードを、それぞれAIに追加変更させる実験を行っています。
その結果、AIが書いたコードを変更する場合、タスク成功率が最大13.1%低下するケースがありました。
さらに興味深いのは、従来の保守性メトリクスでは、この差を十分に説明できなかったことです。
従来の指標だけでは、AIにとっての変更しやすさを十分に評価できない可能性があります。
4. AIが実装したコードは、十分にテストされているとは限らない
Test Coverage Analysis of Agentic Pull Requests（ICSME 2026）では、AIエージェントが生成した4,882件のPRを分析しています。
テスト対象のコードを変更したPRのうち、テストも変更していたのは49.6%でした。また、既存テストが変更箇所を十分に実行できていないケースも報告されています。
テストを追加していないことが、必ずしもテスト不足を意味するわけではありません。ただ、テストの有無だけでなく、変更箇所を十分に検証できているかも重要になりそうです。
5. ただし、AIが必ず保守性を悪化させるわけではない
Echoes of AI（Empirical Software Engineering, 2026）では、AI支援で作成したコードと人間が作成したコードを後から別の人間が変更したところ、修正時間やコード品質に統計的に有意な差は確認されませんでした。
この研究はAI支援による開発を対象としており、AIエージェントによる自律的な開発とは条件が異なります。
現時点では、AIが書いたコードは必ず保守性が低いとは言えないようです。
研究結果から考えられること
今回の研究を整理すると、AI開発では次のような問題に注意する必要がありそうです。
| 問題 | 関係する保守性 |
|---|---|
| コードの複雑化 | 解析性・変更容易性 |
| 設計上の問題の蓄積 | モジュール性・変更容易性 |
| 将来の変更の難しさ | 変更容易性 |
| テストの不足 | テスト容易性に関連する検証上の課題 |
これらはAIだけに発生する問題ではありませんが、AI主体の開発でも注意する必要があります。
特に私の個人開発では、設計の複雑化が機能追加の負担に関係していると考えているため、モジュール性と変更容易性を重視したいと思っています。
では、保守性を何で測るべきなのか？
ソフトウェアメトリクスとは？
ソフトウェアメトリクスとは、コードの規模や複雑さ、依存関係などを数値化する指標です。
代表的なものとして、サイクロマティック複雑度や認知的複雑度などがあります。
ただし、メトリクスの数値が良好だからといって、保守性が高いとは限りません。反対に、数値が悪いからといって、必ずリファクタリングが必要とも限りません。
メトリクスは、保守性に問題があるかもしれないコードを発見し、リファクタリングを検討するための判断材料と考えています。
保守性を測定する代表的なメトリクス
ISOの5分類に対応させると、次のような指標が候補になります。
| 保守性 | メトリクス | 発見したい問題 |
|---|---|---|
| モジュール性 | 結合度・循環依存・依存関係の伝播コスト | 変更の影響が広がりやすい構造 |
| 再利用性 | コード重複率 | 重複実装の増加 |
| 解析性 | 認知的複雑度・LOC | 複雑な処理やコードの肥大化 |
| 変更容易性 | Code Churn・同時変更ファイル数 | 変更の集中・変更範囲の拡大 |
| テスト容易性 | カバレッジ・Mutation Score | 変更の検証不足・テストの不具合検出能力 |
ただし、これらは各観点を直接測定できるとは限りません。例えば、コード重複率は再利用性そのものを表すわけではなく、カバレッジやMutation Scoreもテストのしやすさを直接測る指標ではありません。
あくまで、保守性に関連する問題を発見するための指標です。
個人開発で優先するメトリクス
今回調べた研究と自身の開発経験から、次の指標を優先して収集しようと思っています。
| 優先度 | メトリクス | 目的 |
|---|---|---|
| 1 | 依存関係・結合度 | 設計の複雑化を発見する |
| 2 | 変更頻度 × 複雑度 | 頻繁に変更される複雑なコードを発見する |
| 3 | 変更箇所のカバレッジ・Mutation Score | 変更を十分に検証できているか確認する |
| 4 | 認知的複雑度・LOC | 極端に複雑なコードを発見する |
特に注目しているのは、依存関係と結合度です。
Shortcut Expertでは、個々の処理だけでなく、C#とTypeScriptの責務が曖昧になり、変更箇所が増えていたことが問題でした。そのため、関数単位の複雑度だけでなく、モジュール間の依存関係も確認したいと考えています。
また、変更頻度と複雑度の組み合わせは、リファクタリング候補を探す「ホットスポット分析」に利用できます。
例えば、頻繁に変更され、なおかつ複雑度も高いファイルを特定することで、優先的に調査すべきコードを絞り込めます。
参考：CodeScene — Hotspot Analysis
おわりに
今回は、AIが実装したコードの保守性を評価するために、どのメトリクスを測定すべきか調べました。
AI開発では、コードの複雑化や設計上の問題、後続の変更の難しさなどに注意する必要がありそうです。
特に私の個人開発では、モジュール性と変更容易性を重視し、依存関係や変更履歴などを監視していこうと思います。
次回は、SonarQubeなどを使って、今回選んだメトリクスを実際に導入してみます。