生成AIで「設計書からコード生成」が実用段階へ、富士通研究所が開発現場で検証した精度と課題

生成AIを用いたソフトウェア開発の自動化が、実験段階から実務導入へと移りつつある。富士通研究所は9月17日、大規模言語モデル（LLM）を活用して設計書からソースコードを自動生成する社内システムの検証結果を公開した。同システムは要件定義書や基本設計書を入力として、JavaやPythonなどの実装コードを出力する。検証では約2万行規模の業務アプリケーション開発に適用し、コード生成の正答率が85%に達したことが確認された。

設計書駆動でコード生成、従来のプロンプト方式と一線

富士通研究所の取り組みは、チャット形式で指示を与える従来の「プロンプト駆動」とは異なり、設計書という構造化されたドキュメントを直接読み込ませる点に特徴がある。同研究所の発表によると、設計書には画面遷移図、ER図、API仕様書、バッチ処理フローなどが含まれ、これらをマルチモーダル対応のLLMが解析してコード骨格を生成する。生成されたコードは人間のエンジニアがレビューし、修正をフィードバックして再学習させるループを回す。

「設計書そのものを正として扱えるため、仕様変更時の影響範囲特定やトレーサビリティ確保が容易になる」と同研究所は説明する。従来のプロンプト方式では仕様変更のたびに指示を書き直す必要があったが、設計書を更新すれば自動的にコード側へ反映される仕組みだ。

検証で見えた「85%」の内訳と残る壁

検証対象は、金融機関向けの勘定系システム一部機能約2万行。生成されたコードを単体テストにかけたところ、コンパイルエラー0件、ロジックエラー約15%という結果だった。ロジックエラーの多くは、業務固有の例外処理や暗黙知に基づく判定分岐、レガシー資産とのインターフェース周りに集中した。

「LLMが学習データに含まれない社内固有のルールや、ドキュメント化されていない慣習までは拾いきれない」と同研究所は話す。対策として、設計書にメタデータとして業務ルールを明示的に記述するテンプレートを整備し、プロンプトエンジニアリングではなく「設計書エンジニアリング」へシフトさせている。

開発プロセスそのものを再設計、レビュー工程を前倒し

同システム導入に合わせ、富士通研究所は開発プロセスも見直した。従来は詳細設計→コーディング→単体テスト→結合テストという流れだったが、設計書完成時点でコード生成・レビューを並行させ、詳細設計工程を事実上吸収させる形に変えた。これにより工数全体で約30%の削減効果が見込まれるという。

レビュー観点も変化した。これまではコーディング規約準拠や命名規則といった形式面が中心だったが、生成コードに対しては「設計書との整合性」「業務ロジックの正しさ」「セキュリティ要件の充足」といった本質的な検証にリソースを振り向けられるようになった。

社内展開から社外提供へ、ナレッジ共有基盤も整備

富士通研究所ではこの仕組みをグループ全体約18万人のエンジニア向けに順次展開する方針だ。すでに一部のプロジェクトでパイロット運用を開始しており、年内には全開発プロジェクトへの適用を目指す。同時に、生成コードの品質メトリクスやレビュー知見を蓄積する社内ナレッジ基盤も構築中だ。

「将来的にはこの基盤を社外のSIerやユーザー企業にも開放し、設計書資産を持つ顧客が自社でコード生成を回せるエコシステムを作りたい」と同研究所は語る。設計書という日本のSI業界特有の資産を、生成AI時代の競争力に転換する狙いがある。

国内SI大手の動きが示す「次のフェーズ」

富士通に限らず、NECやNTTデータ、日立製作所など国内主要SIerでも同様の取り組みが水面下で進んでいる。共通しているのは、チャットボット的な利用から「ドキュメント駆動の自動生成パイプライン」へシフトし、品質保証プロセスごと再設計している点だ。

ある大手SIerのAI推進責任者は「PoCで終わりにせず、本番運用を見据えてレビュー体制・テスト自動化・ナレッジ循環までセットで整えるところが勝ち残る」と指摘する。生成AI活用が「道具の導入」から「開発プロセスの再発明」へ移行する中、設計書資産をどうデジタル化し、AIと人間の分業ラインをどこに引くかが、国内ソフトウェア産業の次の競争軸になりつつある。