LLM-based Automated Architecture View Generation: Where Are We Now?

論文要約：LLM によるソフトウェアアーキテクチャビューの自動生成

1. 研究の背景と課題 (Problem)

ソフトウェアアーキテクチャの視覚化（アーキテクチャビュー）は、複雑なシステムの設計とコミュニケーションに不可欠ですが、その作成は手作業であり、労力がかかります。さらに、システムが複雑化するにつれて、作成されたドキュメントはすぐに陳腐化し、75% のビューが作成後に更新されないという問題があります。
近年、大規模言語モデル（LLM）やエージェント型 AI の進歩により、ソースコードからの自動生成が期待されていますが、以下の課題が存在します。

• 抽象化の難しさ: LLM はコード生成には優れていますが、システム全体の関心（Concerns）を理解し、適切な抽象化レベルでアーキテクチャパターンを認識し、ステークホルダーのニーズに応じたビューを生成する能力は未検証でした。
• 既存研究の不足: 実装詳細からアーキテクチャビューへの橋渡しを行う LLM やエージェントの有効性について、体系的な実証研究が不足していました。

2. 研究方法 (Methodology)

本研究は、ソースコードから直接アーキテクチャビューを生成する LLM ベースのアプローチの能力と限界を実証的に評価することを目的としています。

• データセット:
  • 12,200 のオープンソースプロジェクトから抽出された 15,000 件のアーキテクチャビューのうち、詳細な注釈付きの 360 リポジトリを基に、最終的に340 のオープンソースリポジトリを分析対象としました。
  • 生成されたビューの総数は4,137 件です。
• 実験設定:
  • モデル: 3 つの LLM（DeepSeek V2.5, GPT-4o, Claude 3.5 Sonnet）と 2 つのアプローチ（汎用コーディングエージェント「Claude Code」、カスタム構築エージェント「ArchView」）を使用。
  • プロンプト戦略: ゼロショット、ワンショット、フューショット（Few-shot）の 3 種類。
  • 入力処理: ソースコードの要約（階層的要約）を行い、アーキテクチャ上の関心（Concerns）や品質属性を指定して生成を促しました。
  • 出力形式: PlantUML コードを生成し、視覚的な図に変換して評価しました。
• 評価手法:
  • 自動化評価: 「LLM-as-a-Judge」を用いて、明瞭性（Clarity）、完全性（Completeness）、一貫性（Consistency）の 3 点を評価。また、画像類似度指標（SSIM, PSNR など）を用いて生成図と正解図の視覚的類似性を測定しました。
  • 人間評価: 専門家による精度（Accuracy）と詳細度（Level of Detail）の評価（ブラインドテスト）。
  • 統計解析: フリードマン検定、ウィルコクソンの符号付きランク和検定、クラスケール・ウォリス検定などを用いて統計的有意性を確認しました。

3. 主要な貢献 (Key Contributions)

1. 大規模実証評価: 340 のリポジトリと 13 の実験構成を用いた、LLM ベースのアーキテクチャビュー生成に関する大規模な実証研究。
2. 性能分析: 特定のアーキテクチャ関心や品質属性におけるモデルの性能を分析し、どのアプローチがどのタスクに適しているかを示した。
3. 再現性パッケージ: データセット、プロンプト、スクリプトを含む完全な再現パッケージの公開。

4. 主要な結果 (Results)

• アプローチ間の比較:
  • カスタムエージェント (ArchView) が最優秀: 特定のドメイン知識（アーキテクチャ関心、ISO/IEC/IEEE 42010 に準拠した記述など）を統合したカスタムエージェント「ArchView」が、最も高い性能を示しました。特に「明瞭性」の失敗率が 22.6% と最も低く、「詳細度」の成功率が 50% でした。
  • 汎用エージェントの限界: 汎用コーディングエージェント（Claude Code）は、コードレベルの詳細に留まり、アーキテクチャ的な抽象化ができておらず、最も低い性能（明瞭性失敗率 71.8%）でした。
  • プロンプト戦略の効果: フューショットプロンプトはゼロショットに比べ明瞭性の失敗を 9.2% 減少させましたが、改善は限定的でした。
• 生成品質の特性:
  • 構造的妥当性 vs 意味的正確性: LLM は構造的に正しい（構文エラーがない）図を生成できますが、粒度の不一致が深刻です。コードレベルの詳細をそのまま出力し、アーキテクチャ的な抽象化が不足しています。
  • 記法と粒度の影響: 複雑な記法（ボックスと矢印、アイコンなど）の方が、単純なボックス記法よりも生成品質（SSIM）が高くなりました。一方、粒度（高・中・低）による統計的有意な差は確認されませんでした。
  • 関心ごとの性能: 「制御フロー」や「データフロー」のビュー生成は比較的高精度でしたが、「一般的なドキュメント」や「セキュリティ」関連の生成は困難でした。
• 人間評価との乖離: 自動化評価（SSIM や LLM による判定）と人間評価の間には乖離があり、特に視覚的な類似性が高くても、アーキテクチャ的な意味が間違っているケースがありました。

5. 意義と結論 (Significance & Conclusion)

• 結論: LLM とエージェントは、構文的に有効なアーキテクチャビューを生成する能力を持っていますが、自律的なアーキテクトとして機能する段階には至っていません。彼らは依然として「人間の専門家の支援ツール」として位置づけられます。
• 実務への示唆:
  • 支援ツールとしての活用: 完全な自動生成は困難ですが、レガシーシステムや未知のシステムの理解、依存関係のマップ作成、ドキュメント作成のブートストラップ（初期化）には有効です。
  • ドメイン知識の重要性: 汎用的なコーディング能力だけでなく、アーキテクチャ分野固有の知識や関心の指定を統合したカスタムエージェントが不可欠です。
  • 評価指標の必要性: ピクセルレベルの類似度（SSIM）だけでなく、抽象化の適切性やステークホルダーの理解度を測る、アーキテクチャ固有の評価指標の開発が必要です。
• 今後の課題: リポジトリ全体の要約技術の向上、RAG（検索拡張生成）による外部知識の統合、マルチエージェント協働の探求などが今後の研究課題として挙げられています。

この研究は、LLM を用いたソフトウェアアーキテクチャの自動生成が「可能」ではあるものの、実用的なレベルに達するには「ドメイン知識の統合」と「人間による監督」が依然として不可欠であることを実証的に示しました。