AI生成コードは保守しやすいのか？開発者31名への調査で判明した課題と現場の対処法 • vonxai blog

AIを用いたコーディングアシスタント（GitHub Copilotなど）は、開発作業をスピードアップさせる一方で、生成されたコードの品質や長期的な保守性に対する懸念も生じさせています。特に、人間の目で確認しきれないまま統合されたコードは、将来的に技術的負債となって開発チームを苦しめる可能性があります。

この記事では、スウェーデンのブレイキンゲ工科大学の研究者であるAbdallah Alhamad氏らが発表した調査論文「Developer Perceptions on the Maintainability of AI-generated Code: A Survey-based Study」に基づき、実務に携わる開発者がAI生成コードの保守性をどのように評価し、どのような問題に対処しているのかを客観的なデータと共に紹介します。

調査の全体像：どのような開発者が回答したのか

まずは本調査の前提となる、アンケート参加者の構成について確認しておきます。

本調査は、2026年4月6日から4月26日にかけて、プロのソフトウェア開発者を対象に、オンラインコミュニティや著者の人脈を通じて実施されました。

回答者のうち、プロの開発者としてスクリーニングされた31名の属性は以下の通りです。

開発経験年数	回答者数	割合
2年未満（ジュニア）	9名	29.0%
2〜5年（ミドルレベル）	7名	22.6%
6〜10年（シニア）	6名	19.4%
10年以上（リード/アーキテクト）	9名	29.0%

表1：回答者の開発経験年数（N=31）

また、回答者のうち80.6%（25名）がAIコーディングアシスタントを「毎日」使用しており、残りの19.4%（6名）が「毎週」使用していると回答しています。このように、本調査は日常的にAIツールを使い込んでいる実務経験豊かな開発者を対象としています。

AI生成コードの「保守性」に対する開発者の認識

AIが生成するコードに対し、開発者は一概に「完全に良い」とも「完全に悪い」とも判断していません。調査からは、高い実用性を感じつつも、本質的な信頼を寄せていないという複雑な関係性が浮かび上がっています。

高い依存度と低い信頼性のパラドックス

多くの開発者がAIツールへの依存を自覚しています。しかし、AIが生成したコードを手動でのレビューなしにそのままプロダクション環境へマージすることを信頼している回答者は、ほぼ皆無でした。

これは、AIが作成するコードの記述自体は一時的にスピードを上げるものの、そのコードが本当に組織の基準や将来的な変更に耐えうるかを判断するためには、人間の目による検証が不可欠であると考えられているからです。

最大の懸念である「理解の負担」

本論文において特に強調されているのが、AI生成コードがもたらす「理解の負担」です。これは、開発者が中身を深く理解しないままAIコードを統合してしまうことで、後からそのコードの不具合修正や仕様変更を行う際に、過大な認知コストがかかってしまう現象を指します。

ある開発者は「AIに頼ることで、システム全体の構造や理論的なつながりを深く考えなくなってしまい、認知の負債が溜まっていく」と回答しています。コード自体がその場で動作しても、開発者がシステム全体の挙動を脳内にモデル化できなくなることは、長期的な保守において大きな足枷となります。

開発者が直面するAI生成コード保守における3つの課題

本調査では、開発者が日常業務で感じている具体的な課題について、定量的および定性的の両面からアプローチしています。

本セクションで示す課題は、前述のスクリーニングされたプロ開発者31名からの回答データに基づいています。

アンケートで浮き彫りになった定量的課題

複数選択式のアンケートにおいて、開発者が実際に経験したと回答した保守性の課題は以下の通りです。

課題内容	回答者数	割合
既存コードベースとの統合の難しさ	18名	58.1%
長期的な技術的負債の蓄積	16名	51.6%
理解しにくい、整理されていないロジック	15名	48.4%
セキュリティ上の脆弱性	12名	38.7%
チームの誰も完全には理解していないブラックボックスコード	12名	38.7%
命名規則の不一致	11名	35.5%
ドキュメントの欠如または不足	9名	29.0%
不適切に構造化されたコードコメント	9名	29.0%

表2：開発者が経験した保守性の課題（複数選択、N=31）

「既存コードベースとの統合」が約6割で最も高く、次いで「技術的負債の蓄積」や「ロジックの不透明さ」が上位を占めています。

定性分析が示す3つの主な失敗パターン

フリーコメントのテキストデータを分析した結果、特に頻出していたトラブルのパターンが以下の3つです。

文脈の喪失とスコープの逸脱 AIは局所的には正しいコードを提案しますが、サービスを跨いだ依存関係や既存のモジュール間の設計思想を理解できません。結果として、ある箇所を直すために提案されたコードを適用すると、別のモジュールで予期せぬエラーを引き起こす現象（文脈の喪失）が発生します。
可読性と設計品質の低下 AIは動作するものの複雑すぎる、あるいはプロジェクトの習慣に沿わないコードを出力しがちです。一見すると正しく見えるものの、冗長なコードが大量に生成されることで、全体のコードベースが肥大化する問題が指摘されています。
ハルシネーションと非イディオマティックなコード 存在しないAPIや不要なデータベース接続設定をでっち上げる、あるいは既にプロジェクト内に定義されている共通ライブラリを無視して新しい処理を独自に再実装してしまう問題です。

AIコード保守のための対策

これらの課題に対し、実務開発者たちはいくつかの有効な対抗策を確立し始めています。単なるレビューだけでなく、プロアクティブ（能動的）なアプローチが目立ちます。

現場で行われている対策の全体像は、以下の回答データから読み取ることができます。

予防策：共通の指示ファイルによる「永続的なガードレール」

コードの品質低下を防ぐためのアプローチとして、多くの開発者が「プロンプトにその都度指示を書く」のではなく、プロジェクト固有の命名規則やアーキテクチャの基準を、リポジトリ内に配置した「共通の指示ファイル」としてあらかじめAIに読み込ませる手法をとっています。

これは、Cursorの .cursorrules や、GitHub Copilotのカスタム指示ファイル（copilot-instructions.md）などに相当する仕組みです。この「コンテキストエンジニアリング」により、AIの出力そのものの精度を高め、後からの修正コストを根本から削減することが可能になります。

検出策：「手動レビュー」と「AIによるAIコードのレビュー」

生成されたコードのチェック方法としては、伝統的な手動レビューが依然として基本となっています。

チェック手法	回答者数	割合
手動での1行ずつのレビュー	24名	77.4%
ピア（同僚）によるコードレビュー	18名	58.1%
自動テストの実行	18名	58.1%
静的解析ツールの実行（SonarQube、ESLintなど）	14名	45.2%

表3：AI生成コードに対して実施されているチェック手法（複数選択、N=31）

また、興味深いことに、フリーコメントからは「別のAIセッションを立ち上げ、生成されたコードのレビューやリファクタリング案の評価をAI自身に行わせる」という二重チェック体制を自主的に構築している開発者の姿も確認されました。

組織的課題：未整備なガバナンス

一方で、AIの利用を個人の裁量に依存している組織が少なくありません。チームとしての公式なガイドラインが存在すると答えたのは回答者のうちわずか19.4%（6名）にとどまり、45.2%（14名）は「ポリシーはなく、個人の判断に任されている」と答えました。個人レベルでの対処療法は進んでいるものの、組織としての管理体制にはまだ大きな遅れが見られます。

まとめ：AI支援開発における保守性管理のあり方

AIコーディングアシスタントは、開発作業を加速する強力な手段ですが、そのコードの保守性を一定に保つためには大きな手間がかかります。

開発者がAI生成コードを保守する上では、コードが動くかどうかだけでなく、将来的に他の開発者がそのロジックを迷わず変更できるかという「理解の容易さ」が極めて重要です。今後は、チーム全体で共有された指示ファイルの導入や、AI利用に関する明確なチームガイドラインの策定など、組織的なアプローチがより一層求められます。

参考資料:

生成AIの導入や活用にお困りですか？弊社のサービスは、開発チームが抱える課題を解決し、生産性と幸福度を向上させるための様々なソリューションを提供しています。ぜひお気軽にご相談ください！

Developer Perceptions on the Maintainability of AI-generated Code: A Survey-based Study