こんにちは。人工知能研究所の福田貴三郎です。
富士通では企業における生成AIの活用促進に向けて、多様かつ変化する企業ニーズに柔軟に対応し、企業が持つ膨大なデータや法令への準拠を容易に実現する「エンタープライズ生成AIフレームワーク」を開発し、2024年7月よりAIサービス Fujitsu Kozuchi (R&D) のラインナップとして順次提供を開始いたしました。
本記事では、生成AIがもたらすシステム開発・運用の変革に焦点を当て、ソフトウェア設計書のレビューを自動化する 設計書レビュー支援 についてご紹介いたします。
生成AIが変革する企業システム開発運用プロセスと自動化技術
生成AIがソフトウェア開発の前提を塗り替えています。コード補完や自動テスト生成は入口にすぎず、要件定義から設計、実装、運用までの各工程で「AIを前提とした開発プロセス」へ移行が進みつつあります。大規模言語モデル（LLM）は社内文書やログを横断して知識を引き出し、仕様の草案づくりや影響範囲の推定、リリースノート作成までを高速化します。一方で、品質やセキュリティ、説明責任をどう担保するかなどの課題が取り組まれています。
特に企業システム開発は難易度が高い領域です。複雑な業務ドメイン、レガシー資産との連携、厳格な監査と可用性、頻繁な法改正への追随――これらは単純な自動生成では解けません。正確な要件の可視化・言語化、非機能要求の見える化、変更の波及を制御しながらアーキテクチャの一貫性を維持する仕組みなどが不可欠です。
富士通はこれらの課題を解決する先進的技術の研究開発に取り組んでいます。コアとなる技術は大量データを正確に参照・活用できるFujitsuナレッジグラフ拡張RAG技術です。この技術はさまざまなシーンで汎用的に活用できますが、本連載ではシステム開発・運用の自動化・効率化に焦点を当て、以下の7つの技術を紹介します。将来的には、AIが多様な開発・運用タスクで横断的にアクセスできる統合データベースとして機能させることで、要件定義から設計・実装・運用までを高信頼かつ適切に統制のとれた形で推進するマルチエージェントシステムの構築を目指します。
表1：技術が適用できるシステム開発・運用プロセス
| 要件定義 | 設計 | 実装 | テスト | 運用 | 保守 | |
|---|---|---|---|---|---|---|
| (1)システム仕様可視化 | 〇 | 〇 | ||||
| (2)設計書レビュー支援 | 〇 | |||||
| (3)設計書-コードチェック | 〇 | 〇 | ||||
| (4)テスト仕様書生成 | 〇 | 〇 | ||||
| (5)障害分析 | 〇 | 〇 | ||||
| (6)ログ分析 | 〇 | 〇 | ||||
| (7)QA自動化 | 〇 | 〇 | 〇 |
(1) システム仕様可視化 (ナレッジグラフ拡張RAG for Software Engineering 公開中)
本技術はソースコードをデータとして、ソースコードを理解するだけでなく上位の機能設計書や要約を生成、モダナイゼーションを可能にします。
(2) 設計書レビュー支援 (本記事)
複雑な構造のシステム設計書を生成AIが理解できるよう変換することで、システム設計書の曖昧性・整合性のチェックを自動化します。
(3) 設計書-コードチェック (Code Specification Consistency Analysis 公開中)
本技術は、ソースコードと設計書を比較して差分を検知、問題個所を特定することで、障害発生時の原因調査を短縮します。
(4) テスト仕様書生成 (10/27公開予定)
本技術は、既存の設計書とテスト仕様書からテストケースを洗い出すルールを抽出することで、プロジェクトの特性を考慮した抜け漏れのないテスト仕様書の生成を可能にします。
(5) 障害分析 (ナレッジグラフ拡張RAG for Root Cause Analysis 公開中)
本技術はシステムのログや障害事例のデータをもとに、障害発生時のレポートを作成し、類似する障害事例をヒントに対策案を提示いたします。
(6) ログ分析 (ナレッジグラフ拡張RAG for Log Analysis 公開中)
本技術はシステムログのファイルを自動で分析し、障害の原因特定や異常検知、予防保守に関する専門性の高い質問に回答することが可能な技術です。
(7) QA自動化 (ナレッジグラフ拡張RAG for Q&A 公開中)
本技術は製品マニュアルなどの膨大なドキュメントデータを対象に、全体を俯瞰した高度なQ&Aをおこなうことを実現します。
本記事では、(2) 設計書レビュー支援について詳しく紹介させていただきます。
設計書レビュー支援とは
ソフトウェア開発において、設計書レビューは品質の根幹をなす重要プロセスです。しかし、その多くは人手による目視確認に依存し、膨大な工数が費やされています。複雑な階層構造やプロジェクトごとに異なるフォーマットも、レビュー自動化を阻む大きな壁となっていました。 そこで私たちは、このような複雑な設計書を生成AIが読解可能な構造に変換することで、内容の曖昧性や整合性を自動でチェックする技術を開発しました。さらに、この技術の有効性を確かめるべく、実際の業務文書を対象とした実験も行っています。
この研究成果は、2025年3月にカナダ・モントリオールで開催されたソフトウェア解析分野のトップカンファレンスであるSANER 2025 (IEEE International Conference on Software Analysis, Evolution and Reengineering)にて発表しています。本記事では、その発表内容の概要を紹介します。
- 対象論文
- タイトル：Development of Automated Software Design Document Review Methods Using Large Language Models
- 著者：Takasaburo Fukuda, Takao Nakagawa, Keisuke Miyazaki, Susumu Tokumoto
- 論文リンク：https://arxiv.org/abs/2509.09975
SANER2025
プログラムとしては、Keynoteが4件、Research Trackが52件、Industrial Trackが10件 のほか、Short Paper、RENE（Reverse Engineering New Ideas）、Tool Demoなど複数のカテゴリで構成されていました。さらに、Tutorialが2件、Workshopが6件 開催され、恒例の MIP（Most Influential Paper）表彰も行われました。
発表論文の傾向としては、生成AI（Gen AI）およびエージェントベースシステム（Agent-Based Systems）が大きな傾向として強調されていました。具体的には、AI-driven Program Repair、Defect Prediction、Vulnerability Detection、Automated Testing、Intelligent Software Agents など、生成AIやエージェントを活用したプログラム理解・改善技術に関する研究が多く見られました。
発表内容
本研究では、ソフトウェア設計書レビューの自動化を目的として、大規模言語モデル（LLM）を活用したレビュー支援手法を検討しました。設計書レビューは品質保証の中核となる重要な作業ですが、担当者のスキルや時間的制約により品質のばらつきや見落としが生じやすいという課題があります。そこで、設計書間の整合性や記述上の問題点などをLLMが自動で検出できるようにすることを目指しました。
レビュー観点の整理
現在普及している汎用的なLLMには、設計書レビューに必要となる専門的な知識体系がまだ十分に備わっていないという課題があります。そこで本研究では、LLMが限られた知識の範囲でも適切にレビューを行えるようにするため、設計書レビューを体系的に整理し、11のレビュー観点（充足性、整合性、曖昧性、横ぐしチェックなど）を定義しました。さらに、それぞれの観点について必要な知識レベルと参照設計書数の観点から分類を行い、観点別にプロンプトを設計する方針としました。表1において担当者レベルの難易度とは、まだ専門知識を有していない若手やレビュー対象の設計書の開発元であるプロジェクト以外の第三者によるレビューが可能な難易度である事を指します。また、レビューにおいて複数のドキュメント参照が必要なものを複数設計書、必要でないものを単一設計書としています。そのため、表の右側に丸印が付くレビュー観点ほど難易度が上がり、それぞれ段階毎にレベル1～4を設定しています。そのうえで、現時点のLLMが対応可能と考えられる範囲を明確にし、曖昧性・整合性といった観点を中心に検証を進めました。
複雑な設計書の入力構造への対応
実務で扱うソフトウェア設計書の多くはExcelなどの表計算ソフトで作成されており、ヘッダー構造が階層的かつ複雑 であることが一般的です。そのため、各列の見出しと値の対応関係が曖昧になりやすく、CSV形式のままでは文脈や構造をLLMが正しく理解することが困難でした。特に、同一セル内に複数の意味要素が混在する場合や、行・列方向に情報の依存関係が存在するケースでは、LLMがどの項目が何を指しているのかを判断できないことが多く見られました。
この課題に対し、本研究では 設計書をLLMが見出し構造を理解しやすい形式に変換する手法を提案しました。具体的には、自然文と構造情報を両立できるMarkdown形式への変換を中心に採用し、見出しと値の対応関係を明示的に表現することで、LLMが設計情報をより正確に把握できるようにしました。これにより、CSV形式では捉えきれなかった文書構造を保ったまま、レビュー精度の大幅な向上が確認されました。なお、記号表現や項目定義が中心となる一部の設計書については、補助的にJSON形式を利用しています。
実験評価
提案手法の有効性を検証するために、整合性チェックを中心とした実験を実施しました。 実際の業務設計書をベースに、不整合（例：ID名の食い違いなど）を意図的に埋め込んだサンプルを複数作成し、各形式での検出性能を比較しました。使用モデルはGPT（gpt-35-turbo / gpt-4 / gpt-4o）で、Precision（誤検出が少ないかどうか）とRecall（見逃しが少ないかどうか）により性能を評価しました。
実験評価は大きく3つのRQ（Research Question）で行いましたが、本記事ではそのうちの二つのRQについて記述します。
- RQ1：Markdown形式に変換することで、レビュー性能が向上するか
- RQ2：自然文中心／記号中心の文書で変換効果が異なるかを比較
実験結果RQ1
以下表2はCSVのままレビューを行った結果と、提案手法による変換を行った場合における結果を示したものです。CSV形式のまま入力した場合は、LLMが表構造の見出し関係を正しく理解できず、誤りの検出率（Recall）は低水準にとどまりました。一方で、提案手法を用いて変換した場合は、見出しと値の関係が明示されることでレビュー性能が大幅に向上し、特に整合性チェックにおいて顕著な効果が確認されました。
Precision（正確性）は大きく変化しなかったものの、誤検出が増えることもなく、Recallの向上によって総合的なレビュー品質が改善しました。
実験結果RQ2
以下表3と表4は自然文による記述を中心とした設計書と、データベースの項目名などの記号表現が中心となっている設計書における精度比較を行った結果を示したものです。自然文を中心とする設計書では、提案手法によるMarkdown形式の変換が最も高い性能を示しました。文中の構造的な関係（処理名・条件・説明など）が見出しとして明確に整理されることで、LLMが文脈を追いやすくなり、不整合箇所を高い精度で指摘できるようになりました。一方、表構造やデータ項目などの記号表現が多い設計書では、Markdown形式よりも構造を明示的に保持できる形式のほうが効果的であることが分かりました。具体的には、セル内の識別子や数値の対応関係が明確である場合、LLMが誤って別の項目を関連付けるケースが減少し、誤検出率の低下につながりました。これらの結果から、設計書の特徴と使用モデルの特性の両方を踏まえて入力形式を柔軟に選択することが、レビュー性能の安定化に有効であることが示されました。
終わりに
現在、本研究で得られた知見をもとに、設計工程におけるレビュー支援の高度化をさらに進めています。これまでには、UMLなどの図表を対象としたマルチモーダルな設計書レビューにも取り組み、テキストと図を統合的に扱うAI技術の可能性を検証してきました。この取り組み*1は、ソフトウェアエンジニアリングシンポジウム2024にて発表し、企業ポスター賞を受賞しています。今後も、生成AIを活用したAIドリブンなソフトウェア開発プロセスの実現に向け、研究開発に邁進します。
*1:福田貴三郎, 徳本晋, 藤本博昭, 小田嶋成幸, 大規模言語モデルを活用したダイアグラムを含むソフトウェア設計書の自動レビュー手法の検討, ソフトウェアエンジニアリングシンポジウム2024論文集, 2024
