こんにちは。人工知能研究所の大浦です。
富士通では企業における生成AIの活用促進に向けて、多様かつ変化する企業ニーズに柔軟に対応し、企業が持つ膨大なデータや法令への準拠を容易に実現する「エンタープライズ生成AIフレームワーク」を開発し、2024年7月よりAIサービス Fujitsu Kozuchi (R&D) のラインナップとして順次提供を開始いたしました。
本記事では、生成AIがもたらすシステム開発・運用の変革に焦点を当て、プログラム障害の原因特定を自動化する Code Specification Consistency Analysis についてご紹介いたします。
生成AIが変革する企業システム開発運用プロセスと自動化技術
生成AIがソフトウェア開発の前提を塗り替えています。コード補完や自動テスト生成は入口にすぎず、要件定義から設計、実装、運用までの各工程で「AIを前提とした開発プロセス」へ移行が進みつつあります。大規模言語モデル（LLM）は社内文書やログを横断して知識を引き出し、仕様の草案づくりや影響範囲の推定、リリースノート作成までを高速化します。一方で、品質やセキュリティ、説明責任をどう担保するかなどの課題が取り組まれています。
特に企業システム開発は難易度が高い領域です。複雑な業務ドメイン、レガシー資産との連携、厳格な監査と可用性、頻繁な法改正への追随――これらは単純な自動生成では解けません。正確な要件の可視化・言語化、非機能要求の見える化、変更の波及を制御しながらアーキテクチャの一貫性を維持する仕組みなどが不可欠です。
富士通はこれらの課題を解決する先進的技術の研究開発に取り組んでいます。コアとなる技術は大量データを正確に参照・活用できるFujitsuナレッジグラフ拡張RAG技術です。この技術はさまざまなシーンで汎用的に活用できますが、本連載ではシステム開発・運用の自動化・効率化に焦点を当て、以下の7つの技術を紹介します。将来的には、AIが多様な開発・運用タスクで横断的にアクセスできる統合データベースとして機能させることで、要件定義から設計・実装・運用までを高信頼かつ適切に統制のとれた形で推進するマルチエージェントシステムの構築を目指します。
表：技術が適用できるシステム開発・運用プロセス
| 要件定義 | 設計 | 実装 | テスト | 運用 | 保守 | |
|---|---|---|---|---|---|---|
| (1)システム仕様可視化 | 〇 | 〇 | ||||
| (2)設計書レビュー支援 | 〇 | |||||
| (3)設計書-コードチェック | 〇 | 〇 | ||||
| (4)テスト仕様書生成 | 〇 | 〇 | ||||
| (5)障害分析 | 〇 | 〇 | ||||
| (6)ログ分析 | 〇 | 〇 | ||||
| (7)QA自動化 | 〇 | 〇 | 〇 |
(1) システム仕様可視化 (ナレッジグラフ拡張RAG for Software Engineering 公開中)
本技術はソースコードをデータとして、ソースコードを理解するだけでなく上位の機能設計書や要約を生成、モダナイゼーションを可能にします。
(2) 設計書レビュー支援 (公開中)
複雑な構造のシステム設計書を生成AIが理解できるよう変換することで、システム設計書の曖昧性・整合性のチェックを自動化します。
(3) 設計書-コードチェック (Code Specification Consistency Analysis 本記事)
本技術は、ソースコードと設計書を比較して差分を検知、問題個所を特定することで、障害発生時の原因調査を短縮します。
(4) テスト仕様書生成 (公開中)
本技術は、既存の設計書とテスト仕様書からテストケースを洗い出すルールを抽出することで、プロジェクトの特性を考慮した抜け漏れのないテスト仕様書の生成を可能にします。
(5) 障害分析 (ナレッジグラフ拡張RAG for Root Cause Analysis 公開中)
本技術はシステムのログや障害事例のデータをもとに、障害発生時のレポートを作成し、類似する障害事例をヒントに対策案を提示いたします。
(6) ログ分析 (ナレッジグラフ拡張RAG for Log Analysis 公開中)
本技術はシステムログのファイルを自動で分析し、障害の原因特定や異常検知、予防保守に関する専門性の高い質問に回答することが可能な技術です。
(7) QA自動化 (ナレッジグラフ拡張RAG for Q&A 公開中)
本技術は製品マニュアルなどの膨大なドキュメントデータを対象に、全体を俯瞰した高度なQ&Aをおこなうことを実現します。
本記事では、(3) 設計書-コードチェック (Code Specification Consistency Analysis) について詳しく紹介させていただきます。
Code Specification Consistency Analysis とは
Code Specification Consistency Analysis（以下 CSCA）は、設計書とソースコードを参照しながらシステム障害の原因分析を行うAIコアエンジンです。例えばシステム開発のテスト段階でエラーが発生した場合に、テスト実施者が自然言語でエラー内容を入力すると、AIが設計書とソースコードを自動で解析して問題箇所を特定することが可能です。複数コンポーネントにまたがる障害でも、自動で原因箇所を特定できるため、各コンポーネントの開発者に調査を依頼することなく、テスト実施者だけで短時間で原因を調査できます。
本記事では、CSCAの仕組みを技術的に掘り下げながら、その課題と今後の構想について紹介します。主なユースケースとしてシステムテストでの障害分析の例を扱いますが、開発者自身が実装時に使用することも可能です。
既存技術とその課題
システム開発における障害原因の特定を支援する取り組みとして、近年は大規模言語モデル（LLM） に設計書やソースコードを入力し、分析を行う手法が注目されています。代表的な手法の一つとして、ReAct（Reasoning + Acting）*1と呼ばれる技術があります。
ReActは、LLMに質問と利用可能なツールを提示し、LLM自身がツールを選択・実行しながら情報を段階的に収集・解析することで、最終的な回答を導きます。つまり、実際のユースケースに応じて「どのようなツールを用意するか」が鍵になります。例えば、以下のようなツールを用意したとします。
| No. | ツール名 | 目的・概要 |
|---|---|---|
| 1 | 設計書検索ツール | 事前に解析した設計書DBに対して検索を行い、関連する章や節を検索する |
| 2 | ソースコード検索ツール | ソースコードをキーワードで検索して、ヒットしたファイル名を出力する |
| 3 | ファイル読込ツール | 指定したファイルを読み込む |
ここで、一つのユースケースを例にReActを適用した場合について考えてみます。
あるWebサービスの開発が行われているとします。開発したプログラムをテストしていると特定のユーザだけがログインに失敗することが判明しました。そこで、テスト実施者がReActのメインプログラムに対して、「現在Webサービスを開発しております。テストを行っていると、特定のアカウントでのみサービスにログインできないという問題が発生しました。原因を特定してください。」という文章をインプットしました。そうするとReActはLLMと連携して、以下のようなステップでツールを実行して情報を集めていきます。
Step1：設計書検索
まず、認証関係で問題が発生していることから、「設計書検索ツール」を使って「認証ポリシー」を検索し、関連する章を抜粋します。 検索の結果、以下のような情報を入手します。
- ユーザー認証ではパスワードをSHA-256でハッシュ化して保存すること
- 当初はMD5を用いる予定であったが、途中でSHA-256を用いるように改版された
この時点で、MD5による暗号化を行う実装がどこかに残っているのではないかという仮説が立ちます。
Step2: ソースコード検索
次に、関連するソースコードを探すために「ソースコード検索ツール」を使って「md5/hash/crypto」といったキーワードで複数回検索を実行します。その結果、以下のようなファイル候補を入手します。
legacy_hash.py
crypto_utils.py
auth_handler.py
docs/CHANGELOG.md
tests/crypto/test_md5_compat.py
README_security.md
Step3: ソースコード確認
そして、検索結果から、関連しそうなファイルを順番に「ファイル読込ツール」を使って確認していきます。しかし、それぞれのファイルは数百行にわたり、これらを確認しているうちに、LLMが扱えるトークン数の上限に達し、これ以上処理を続けられなくなってしまいました。
legacy_hash.py（約800行）
crypto_utils.py（約1500行）
auth_handler.py（約500行）
仮にLLMのトークン数による上限に達しなかったとしても、余計な情報が多くなるほどLLMの認識精度は低下していき、本来の原因となる箇所を見逃してしまう可能性があります。
このように、ReActそのものは強力な枠組みを提供しますが、単純な検索ツールやファイル読込ツールを組み合わせただけでは、ソースコードを対象とする障害解析には不十分であり、新たな工夫が求められます。
CSCAの特長
従来手法の課題を踏まえ、私たちは Code Specification Consistency Analysis (CSCA) という技術を開発しました。CSCAは、ReActフレームワークに独自のソースコード検索ツール(No.2~No.4)を組み合わせることで、設計書とソースコードの両面から効率的に障害原因を特定することを目的としています。
| No. | ツール名 | 目的・概要 |
|---|---|---|
| 1 | 設計書検索ツール | 事前に解析した設計書DBに対して検索を行い、関連する章や節を検索する |
| 2 | ソースコード一覧表示ツール | プログラムファイルの一覧をディレクトリ名とともに取得する |
| 3 | ソースコード概要作成ツール | 指定したソースコードの関数名や主な動作を別のLLMが要約し、概要を作成する |
| 4 | ソースコード抜粋ツール | 指定したソースコードから特定の関数や処理を抜粋する |
先ほどのユースケースをCSCAで実行した場合は以下のように動作します。
Step1: 設計書検索
まず、認証関係で問題が発生していることから、「設計書検索ツール」を使って「認証ポリシー」を検索し、関連する章を抜粋します。(従来同様)
Step2: ソースコードのファイル名確認
「ソースコード一覧表示ツール」を実行してファイル名を確認し、「auth」「crypto」「hash」といったワードが含まれる以下のファイルに注目します。
legacy_hash.py
crypto_utils.py
auth_handler.py
Step3: ソースコードの概要確認
候補として挙がった3つのファイルに対して、「ソースコード概要作成ツール」を順番に実行して概要を取得します。それぞれ数十行程度の概要が作成され、以下のことがわかりました。
- auth_handler.py は
check_password()という関数の中で crypto_utils.py をインポートして暗号化関係の処理を実行している - crypto_utils.py の中に「SHA256Hashクラス」と「MD5Hash関数」が共存している
Step4: ソースコード確認
最後に「ソースコード抜粋ツール」で「auth_handler.py から check_password() を抜粋」と指定し、check_password()関数のみを確認します。すると、hashed = MD5Hash(password)というコードが残っていることが確認されました。これは、Step1で確認した設計書の記述と反しています。また、開発の初期に登録されたユーザのみがSHA256HashではなくMD5を使用するルートに分岐するような実装になっていることがわかりました。
ここまでの情報を使ってLLMは最終的に「auth_handler.pyの中で、特定の条件を満たしたユーザがMD5を使用するような実装になっています。これは設計書に書かれた内容に反しており、開発初期に実装した内容が残っているものと考えられます。すべてのユーザがSHA256Hashを使用するように修正してください。」といった回答を、根拠となる設計書の記載やソースコードと一緒に出力します。
以上のようにCSCAは、設計書とコードの両面から情報を収集・整理し、LLMが効率的かつ的確に障害解析を進められるように設計されています。単純な検索にとどまらず、段階的に情報を掘り下げていくことで、「トークン数の制約」、「ノイズによる精度低下」といった従来手法の課題を克服することができます。
CSCAの課題
CSCAは、富士通が研究開発した先端AI技術を迅速に試すことができるプラットフォーム Fujitsu Kozuchi において、コア技術単位のソフトウェア部品「AIコアエンジン」の一つという位置付けで、2024年7月に公開されました。実際に社内のプロジェクトやお客様に使用される中で、いくつか課題も挙がってきています。ここではそれらの課題の中でも主要なものを3つ紹介します。
- 網羅性の不足: システム障害の原因が複数のファイルに存在する場合でも、対象のファイルをいくつか見つけると早期に「これが原因だ」と判断してしまい、他の候補を十分に検証しないケースがあります。結果として障害原因箇所の特定が十分ではないことがあります。
- 大規模プロジェクトでのスケーラビリティ: 大量のファイル数を持つシステムでは、回答精度が低下する場合があることがわかっています。現状のCSCAではソースコードを探し出す際に、ファイル名やディレクトリ名から関連しそうなファイルを見つけ、ファイルの概要を把握して、関連箇所の詳細を確認する、という手順を踏むためファイル数が多い場合にこの一連の確認作業を何度も繰り返すことになります。その結果、ノイズとなる情報が多くなって回答精度に影響を与えてしまいます。
- 修正方法が不明確: もともとCSCAはテスト実施者が原因箇所を切り分けることを想定していますが、プログラムの修正方法も提示してほしいという声も上がっています。現状は障害原因を回答するものの、具体的にどのようにプログラムを修正すればいいかまでは回答できません。
今後のアップデート構想
上記課題を解決するために、現在技術開発に取り組んでいます。将来的には以下のようなアップデートを構想しています。
- ソースコード検索の網羅性向上: ソースコード間の依存関係などをもとに関連性を評価し、特定のソースコードを起点として、それに関連するソースコードを取得できるツールを用意し、より効率的かつ網羅的な検索を実現します。また、複数の観点を挙げて計画的に検索を実行したり、検索結果を精査する仕組みを導入していきます。
- マルチエージェント協調: 大規模なプロジェクトを解析するにあたって、シングルエージェントでは情報を集めるのに必要なステップが多くなったり、大量の情報を処理しきれなくなり、どうしても対応できる規模に限界があります。複数のエージェントを実行して作業を分担させて組織的に動作させることで、複数の観点で並列で設計書やソースコードを検索したり、あるエージェントが別のエージェントの出力を評価する、といったことも可能になります。どのように協調させていくと最も良い結果につながるかを研究し、大規模なプロジェクトでも効率よく必要な情報を収集して、精度よく回答できるようにしていきます。
- ソースコード修正案提示: 従来は障害原因分析が中心でしたが、将来的には具体的な修正案（パッチ候補）も提示できることを目指します。
まとめ
CSCAは、ソフトウェア障害分析を支援するために開発されたAIコアエンジンであり、ReActベースのマルチステップ推論と、コード検索技術を組み合わせた仕組みを備えています。一方で、網羅性や大規模対応といった課題も明らかになっており、それを解決するために、検索戦略の強化・マルチエージェント化・修正案提示といった観点から改善策の検討を進めています。
さらに今後は、弊社で開発しているKG拡張RAGシリーズなど、他の技術とも連携も視野に入れながら成長を続けていく予定です。
さいごに
この記事の技術は、以下のメンバーで開発を行いました。この場を借りて紹介させていただきます。
- 人工知能研究所: 大浦 淳貴, 和田 章宏, 菊月 達也, 小川 雅俊
- 宇宙データフロンティア研究センター: 中津川 恵一
*1:Shunyu Yao, et al. "React: Synergizing reasoning and acting in language models." International Conference on Learning Representations (ICLR). 2023.
