SHIFTは、ITの総合ソリューション企業としてさまざまなサービスを提供しています。

そのなかでも、生成AIによる独自のリバースエンジニアリングツールを用いた新たなマイグレーション支援サービスが「AIドキュメントリバース」です。

ソースコードから詳細設計書レベルのドキュメントを生成できるという本サービス。

「サービス単体でも成果を上げていることはもちろん、SHIFTのほかのサービスと組み合わせることで、幅広いDX課題を解決する起爆剤になっています」

このように話すのは、AIドキュメントリバースのPdMを務める三枝と、ドキュメントの品質チェックを担う恩田です。

AIドキュメントリバースとはどのようなものか、2名の話を通じて「技術のSHIFT」としての最新の取り組みをお伝えします。

ブラックボックス状態のソースコードを可視化するサービス

――まずは、AIドキュメントリバースのサービス概要を教えてください。

三枝：端的にお伝えすると、お客様から受領したソースコードをAIにインプットすると、設計資料がアウトプットされるというものです。

31種類（※2024年12月時点）のプログラミング言語に対応しており、CRUD図やシーケンス図、クラス図、フローチャートなど、詳細設計書のレイヤーのドキュメントを生成することができるようになっています。

――どのようなニーズから生まれたサービスなのでしょうか？

三枝：基本的には、マイグレーション／モダナイゼーションの現場で生じている課題を解決するために生まれたものです。

レガシーなシステムを運用されているお客様が開発に伴うエビデンスをしっかりと残されている場合はよいのですが、実際のプロジェクトに入っていくとそうではなく、例えば基本設計書からプログラムをいきなり書いたり、設計書そのものがないプログラムを継ぎ足して機能追加していったりしているようなケースが多い状況です。

そうなると、以下にあげるさまざまな課題が発生し、DX推進の妨げになってしまいます。

三枝：ブラックボックス状態のソースコードを可視化することで、高いプロジェクト品質を維持しながら、高度なマイグレーション／モダナイゼーションに取り組むことが可能になります。

そのためのツールとして、AIドキュメントリバースの開発・提供を進めています。

恩田：まずはお客様からコードの一部をいただき、サンプルドキュメントを作成。アウトプットの調整などを行ったうえで、実際のソースコードでドキュメントを作成し、レビューを経て納品という流れになります。

基本的には追加開発なしで、必要なアウトプットを出力できるようにしています。

可能な限り生成AIに「推論」させないことで、アウトプットを安定化させている

――追加開発なしでアウトプットできるのはすばらしいですね！

三枝：まだ完全なテックタッチ※というわけではなく、言語ごとのプロンプト対応を行っている状況ではありますが、インプットされるプログラミング言語と、アウトプットされるドキュメントの形式を別々に学習しているからこそ、ほぼ追加開発なしで、任意の組み合わせでのドキュメントリバースができるようになっています。

※テックタッチ…ツールやサービスの活用支援施策。

――生成AIを活用するメリットはどんな点にあるのでしょうか？

三枝：やはり、ツールとしての制約が大幅に緩和されることだと思います。

一般的なプログラムだと出力が固定的になるので、かなりの量のアウトプットを事前に想定して機能を盛り込む必要がありますし、それであってもお客様ごとにカスタマイズしないと実用的とはなかなかいえないことが多いと思います。

対して生成AIは、一般的なプログラムよりも人に近いような柔軟な動き方をしてくれ、かつ作業内容によっては人以上の正確性でアウトプットしてくれます。

だからこそ、私たちは「生成AIは人だ」と思って、プロンプトを通じて接するようにしています。

――生成AIは、アウトプットに“ゆらぎ”があると思うのですが、そのあたりはどう対応しているのでしょうか？

三枝：出力の統一化にはまだ課題がある一方、言語ごとのプロンプトを工夫することである程度のクオリティを実現できています。

一般的なAIの能力として「推論」と「要約」と「翻訳」があげられると思いますが、このなかでも特に推論がハルシネーションの要因になると考えているので、AIドキュメントリバースではできるだけ推論をさせないようなプロンプトにしています。

また、ドキュメント作成の本質は翻訳だと思うので、翻訳タスクを行わせるような工夫もプロンプトに組み込んでいます。

その結果、クラス図兼モジュール構成図のような、複数のモジュール間の依存関係を表すアウトプットもできるようになっています。

品質を段階的に上げていくのが、遠回りなようで一番の近道

――生成AIを使ったツールは柔軟性が高いということですが、品質保証が大変そうな印象です。

恩田：基本的な流れとしては、各作成ドキュメントに対してQAチェックの要否を人が判断したら、コマンドプロンプト上でのQAチェックと、HTML形式およびSVG形式でのQAチェックを生成AIがそれぞれ実行したうえで、ドキュメント作成を進めていくことになります。

この自動QAチェックでは、例えば以下にあげたような観点についてそれぞれ10点満点で評価し、レポートを作成する流れにしています。

三枝：「何が正しいか」は人が見ないとわからないですし、実際に答えをジャッジできるのはお客様だと思います。

いくらこちらが“仕様上”正しいといっても、最終的な判断はお客様が下すもの。そういう意味で、全自動QAはまだまだむずかしく、人の手がどうしても必要です。

ただし、だからといってすべての工程を手動で行うとなると莫大な工数やコストがかかるので、現状ではいくつかの観点をAIに与えて、それに沿ってQAを実行するという考え方で進めるようにしています。

恩田：私がこの辺りのチェックを担当しているのですが、品質を段階的に上げていくのが、遠回りなようで一番の近道だと考えています。

例えば先ほどあげた3つの観点について、長いソースコードで実行しようとすると、トークン制限に引っかかってソースの途中までしか実行されません。

自動QAチェックを評価するにあたっては、まずは「ソースに書かれていないことを書いていないか」などアウトプットの「正確性」を担保し、そこに対してある程度評価が高くなってから、「記載内容が詳細／具体的か」などの「網羅性」を見ていく形で、品質を上げていく必要があると考えています。

AIドキュメントリバースを起点に、お客様のDXを推し進める

――今後の取り組みについて教えてください。

三枝：繰り返しになりますが、QAチェック含む処理の自動化はまだまだ道半ばなので、まずはそのチューニングをつづけていきたいと思います。

そのうえで、詳細設計書レベルに限らず、基本設計書や画面設計書、画面遷移図なども自動的に取得できるように実装を進めていきたいと考えています。

また、ファームウェアバージョンアップやプログラミング言語移植など、ソースコードからソースコードへの自動変換にも挑戦したいですね。

最終的には、マイグレーション／モダナイゼーションの100%自動化を目指していきます。

恩田：提供形態という観点ですと、サービスのSaaS化も目指していきたいところです。

現状はお客様から私たちがソースコードをお預かりして対応していますが、そこをお客様自身で進めることができるようになれば、デリバリースピードという観点でも非常に喜んでいただけるだろうなと思っています。

――SHIFTだからこそ実現できていると感じるポイントも教えてください。

三枝：2024年9月にAnthropicが、AIが嘘をつかないための工夫について記事を発表していましたが、SHIFTではここに書かれているような内容を約半年前からすでに実装していました。

そのうえで、先ほどお伝えしたような「AIに推論させない」ためのプロンプトを書くという技術的知見も溜まってきています。

このような先見的な取り組みをベースにシステムをつくり込み、アウトプットとして反映できている点は、SHIFTならではのポイントだと感じています。

恩田：技術的な観点以外ですと、AIドキュメントリバース単体ではなく、SHIFT全体で任せていただけると、他の多様なサービス部隊と連携してお客様のDXをスムーズに進めることができると考えています。

アウトプットしたドキュメントを使ってテストを実施したり、マイグレーションを進めたりといったことも可能です。

AIドキュメントリバースがほかのサービスの呼び水になって、結果としてお客様の価値向上につなげることができる点が、SHIFTならではの強みであり特徴だと考えています。

――本日はお忙しいなか、ありがとうございました！

※本記事の内容および取材対象者の所属は、取材当時のものです