Beyond Functional Correctness: Design Issues in AI IDE-Generated Large-Scale Projects

本論文は、FD-HITL フレームワークを用いて AI IDE（Cursor）で生成された大規模プロジェクトが機能的には高い正しさを示す一方で、コード重複や複雑性の高まりなど設計上の問題が多数存在し、長期的な保守性や拡張性にリスクをもたらすことを実証的に明らかにしたものである。

要約

この論文は、**「AI によるプログラミングが、本当に大規模なシステムを一人で作れるのか？そして、その結果は『使える』だけで『良いもの』なのか？」**という問いに答えた研究です。

まるで**「AI という天才的な見習い職人」に、「複雑なビル（大規模プロジェクト）」**を一人で建てさせてみた実験のようなものです。

以下に、専門用語を排し、日常の例え話を使って分かりやすく解説します。

---

🏗️ 実験の舞台：AI 職人「Cursor」と「設計図」

研究者たちは、最新の AI 搭載 IDE（開発環境）の一つである**「Cursor」**というツールを使いました。これは、単にコードの断片を提案するだけでなく、プロジェクト全体を把握して、ファイルを読み書きし、計画を立ててコードを書くことができる「エージェント（自律的な助手）」です。

しかし、いきなり「ビルを建てて」と言っても、AI は混乱して失敗したり、粗末な小屋しか作れなかったりします。そこで研究者たちは、**「FD-HITL（機能駆動型・人間と AI の協働）」という新しい「建設マニュアル」**を開発しました。

• 従来のやり方（Vibe Coding）： 「適当に作って！」と AI に任せる。→ 結果：バラバラで、後から直すのが大変な「粗末な小屋」になる。
• 今回のやり方（FD-HITL）：
  1. 設計図を一緒に描く： 「何を作るか」「どんな技術を使うか」を人間が明確に指示する。
  2. 小分けにする： 大きなビルを「1 階の壁」「2 階の階段」など、小さくてテストしやすい部品に分解する。
  3. 一つずつ確認する： 部品ごとに AI に作らせ、人間が「OK？」とチェックしてから次に進む。

この「丁寧なマニュアル」を使って、**10 個の大規模プロジェクト（Web アプリ、スマホアプリ、ツールなど）**を AI に作らせました。

---

📊 結果：「機能は動く」が「設計はボロボロ」

1. 機能は素晴らしい（91% 成功！）

AI は、このマニュアルに従えば、約 1 万 7000 行ものコード（人間のプログラマーが数週間かかる量）を生成し、91% の確率で「要求された機能」を正しく動かすことができました。

• 例え： 「レストランを開いて」と頼むと、AI は「メニューは完璧、料理は美味しい、客は満足して帰る」素晴らしいお店を作ってくれました。

2. しかし、裏側は「危険な状態」だった

機能は動くけれど、「設計（内装や構造）」に深刻な問題が大量に見つかりました。静的解析ツール（コードの健康診断機）を使ってチェックしたところ、**4,000 以上もの「欠陥」**が見つかりました。

主な問題は以下の通りです：

• 📝 コードの「コピペ」過多（DRY 原則違反）
  • 例え： 同じ料理のレシピを、メニューの各ページに手書きで全部書き写している状態。
  • 問題： 「塩の量を 1g 増やして」と言われた時、10 箇所すべてを修正しなきゃいけなくなります。メンテナンスが地獄です。
• 🧠 複雑すぎる関数（SRP 原則違反）
  • 例え： 一人の料理人が「包丁を握り、火加減を調整し、皿を洗い、客の注文を取り、会計まで行う」状態。
  • 問題： 役割が混雑しすぎて、誰が何をしているか分からず、バグを見つけにくい。
• 🚧 巨大なメソッド（Large Methods）
  • 例え： 1 つのレシピが 200 行も続く、読めない長い文章になっている。
  • 問題： 修正しようとしても、どこをいじったらいいか分からない。
• ♿ アクセシビリティの欠如
  • 例え： 車椅子の人が入れない入り口や、点字ブロックがない道。
  • 問題： 視覚障害者やキーボード操作しかできない人が使えない。

---

💡 重要な発見：AI は「職人」ではなく「見習い」

この研究から得られた最大の教訓は以下の通りです。

1. AI は「設計」を任せられない：
   AI は「指示された通りに実行する」のは得意ですが、「どうすれば良い設計になるか」を自分で考えたり、長期的なメンテナンス性を考慮したりするのは苦手です。
2. 人間の役割は「監督」から「設計者」へ：
   以前は「AI がコードを書くから、人間はチェックするだけ」でしたが、これからは**「人間が設計図（要件定義）を完璧に作り、AI に細工（実装）を任せる」**という役割分担が必要です。
3. 「動くこと」だけがゴールではない：
   機能は動いても、中身がボロボロだと、後から「直そう」とするとコストが膨らみます。AI が作ったコードは、**「プロの職人が徹底的にリファクタリング（設計の整理）をしない限り、本格的な製品には使えない」**という結論です。

---

🎯 私たちへのメッセージ

AI 開発ツールは魔法の杖ではありません。それは**「非常に速く、正確に作業できる見習い職人」**です。

• 魔法の杖だと思って「適当に作って」と頼むと： 見た目は立派でも、中身がぐちゃぐちゃの「危ない家」ができます。
• 熟練の監督者として「設計図を渡して、一つずつ確認する」： 高品質で、長く使える「立派なビル」を建てることができます。

結論：
AI には「実装」を任せ、「設計」「要件定義」「品質チェック」は人間がしっかり行う。この**「人間と AI のタッグ」**が、未来のソフトウェア開発の正解です。

技術概要

論文要約：Beyond Functional Correctness: Design Issues in AI IDE-Generated Large-Scale Projects

（機能の正しさを超えて：AI IDE 生成の大規模プロジェクトにおける設計上の課題）

1. 研究の背景と問題提起

近年、大規模言語モデル（LLM）を活用した AI コーディングツール（GitHub Copilot など）は、コードスニペットの生成において高い生産性を示しています。しかし、これらは主に断片的なコード生成に留まり、開発環境の文脈を十分に理解してプロジェクト全体を構築する能力には限界がありました。

最近登場したAI 搭載 IDE（AI IDE）（例：Cursor）は、エージェント機能を持ち、プロジェクト全体のコンテキストを読み込み、計画を立て、コードを生成・実行できるため、大規模なソフトウェアシステムの生成が可能になると期待されています。

しかし、以下の研究ギャップが存在します：

1. 大規模プロジェクト生成の検証不足: 既存研究の多くは、単純で小規模なプロジェクト生成に焦点を当てており、産業レベルの複雑さを持つ大規模プロジェクト（8,000 行以上のコードなど）の生成能力に関する実証データが不足している。
2. 設計品質の評価欠如: 生成されたコードの「機能的正しさ（Functional Correctness）」は評価されつつあるが、大規模プロジェクトにおいて生じる**設計上の課題（Design Issues）**や保守性・進化性へのリスクを体系的に評価した研究は少ない。

本研究は、AI IDE（Cursor）を用いて大規模プロジェクトを生成し、その設計品質を評価することを目的としています。

2. 研究方法論

本研究は、Cursor を用いた 10 の大規模プロジェクトの生成と、生成されたプロジェクトの設計評価の 2 つのフェーズで構成されています。

2.1 提案フレームワーク：FD-HITL

AI IDE の効果的な利用のために、Feature-Driven Human-In-The-Loop (FD-HITL) フレームワークを提案しました。これは、従来の「Vibe Coding（意図を深く理解せず速やかにコード生成する手法）」の非構造化なアプローチの問題点を解決するため、機能駆動開発（FDD）の原則を適用したものです。

フレームワークの主要なステップ：

1. プロジェクト初期化: 高レベルなプロジェクト記述と技術スタックの決定。
2. 要件定義と設計: 要件文書（requirements.md）と、独立してテスト可能な機能ごとのタスクリスト（tasklist.md）の作成。人間によるレビューと修正。
3. 実装フェーズ:
   • プロジェクトの構造化（スキャフォールディング）。
   • 機能駆動開発サイクル: 1 つの機能（機能ごとの DB、バックエンド、フロントエンド）を完了させ、テストとバグ修正を繰り返してから次の機能へ進む。
   • 人間による継続的なフィードバックとデバッグ支援。
4. システム全体レビュー: 全機能完了後のシステムレベルのテストと改善。

2.2 データセットの生成

• 対象: Web アプリケーション、モバイルアプリ、ユーティリティツールの 3 つのドメイン。
• 規模: 10 の大規模プロジェクトを生成。
• 技術スタック: React, Spring Boot, Django, React Native, PHP (WordPress) など多様な技術を採用。
• 評価基準: 8,000 行以上のコード（LoC）、3 以上の技術スタック、複数のアーキテクチャコンポーネントを含むプロジェクトを「大規模」と定義。

2.3 評価手法

1. 機能的正しさの評価: 手動による実行と要件（requirements.md）との照合。
2. 設計課題の検出: 2 つの静的解析ツールを使用。
   • CodeScene: コードの複雑さ、重複、設計原則違反などを検出。
   • SonarQube: コードスモー、セキュリティ、ベストプラクティス違反などを検出（誤検知の除去のため手動フィルタリングを実施）。

3. 主要な結果

3.1 大規模プロジェクトの生成能力（RQ1）

FD-HITL フレームワークを用いることで、Cursor は機能的に動作する大規模プロジェクトを生成できました。

• 平均規模: 1 プロジェクトあたり約 16,965 行のコード、114 ファイル。
• 機能的正しさ: 手動評価の結果、平均 91% の要件を満たしていました（最高 96%、最低 85%）。
• 結論: 構造化された人間との対話（FD-HITL）があれば、Cursor は産業レベルに近い規模のプロジェクトを生成可能です。

3.2 設計上の課題（RQ2）

機能的に動作する一方で、重大な設計上の課題が多数発見されました。これらは長期的な保守性や進化性にリスクをもたらします。

• 検出された課題数:

  • CodeScene: 1,305 件（9 分類）
  • SonarQube: 3,193 件（11 分類、誤検知除去後）
  • 両者の重複: 133 件（すべて重要度が高いと判定）。

• 主要な設計課題の分類と具体例:

  1. コードの重複 (Code Duplication): 最も頻出する課題（CodeScene 検出の 28.4%）。DRY（Don't Repeat Yourself）原則の違反。
  2. 複雑なメソッド (Complex Method) & 長大なメソッド (Large Method): 1 メソッドあたりの行数が 100〜200 行を超えるものや、サイクロマティック複雑度が 15 を超えるものが多数。SRP（単一責任の原則）違反。
  3. フレームワークのベストプラクティス違反: React の Props 検証不足、Spring Boot の依存性注入の不適切な使用など。
  4. 例外処理の問題: 汎用的な例外（RuntimeException）の乱用や、空のキャッチブロック。
  5. アクセシビリティの問題: フォームラベルの欠落、キーボード操作のサポート不足など。
  6. 設計原則違反: 単一責任の原則（SRP）、関心の分離（SoC）、DRY、KISS（シンプルに）などの原則が頻繁に侵害されていました。

• 技術固有の課題: 生成された課題の 59% は特定の技術スタック（JavaScript/React/Node.js が大半）に固有のものでした。

4. 主要な貢献

1. FD-HITL フレームワークの提案: AI IDE を用いて大規模プロジェクトを構造的に生成するための新しい手法。
2. 設計品質の実証的評価: AI 生成の大規模プロジェクトにおける設計課題の定量的・定性的分析。
3. 公開データセット (DIinAGP): 10 のプロジェクト記述、生成されたコード（合計約 17 万行）、および検出された設計課題を含むデータセットを公開。
4. 実践者への提言: AI IDE を効果的に活用し、設計品質を維持するための具体的なガイドライン。

5. 意義と示唆

本研究は、AI IDE が「動くコード」を生成できるだけでなく、「産業レベルの規模」を扱えることを示しましたが、同時に**「設計の質」が人間の熟練開発者の監督なしには維持できない**ことを明らかにしました。

• 人間と AI の役割分担: 要件定義、アーキテクチャ設計、機能分解などの高レベルなタスクは人間が担い、実装などの低レベルなタスクを AI に任せるという「人間主導・AI 実行」のアプローチが有効である。
• 設計品質の監視: 機能的正しさだけでなく、静的解析ツールを用いた設計品質の継続的な監視が不可欠。
• アクセシビリティの明示: AI 生成コードはアクセシビリティ要件を無視しがちであるため、仕様書で明示的に要求する必要がある。

結論として、現在の AI IDE は熟練した開発者のエンジニアリングスキル（特に高レベルな設計判断）を即座に代替するものではなく、生成された大規模プロジェクトは経験豊富な開発者による厳格なコードレビューと設計改善が必須であることが示されました。