以下の内容はhttps://rheb.hatenablog.com/entry/2025/09/18/210740より取得しました。


生成AI × MTAが切り拓くアーキテクチャレビューの新展開

こんにちは。Red Hatコンサルティングチームの木嶋です。

生成AIの活用が広がっていますね。 私たちも日々「どこまで効率化や高度化に役立てられるのか」検証を進めています。

私自身はエンタープライズアーキテクチャ (EA) やマイクロサービスアーキテクチャといった全体設計レビューを担当することが多いのですが、この領域を担える人材が不足している組織も少なくありません。

弊社が持っているツールの一つにMigration Toolkit for Applications (MTA) があります。

これは例えばJBoss EAPからSpring Bootなど、異なるミドルウェアやランタイムに移行するときに実行するコードアセスメントツールです。 ただし実はこのツールのアウトプットには、リポジトリ全体に対して実行した場合、システム全体の構造を把握するのに役立つ情報が多く含まれています。

そこで今回は、このMTAのアウトプットを活用してどこまで理想に迫れるのか、試してみました。

まずは結果から

結論から言うと、さすがにシステムを長年お守りしている熟練アーキテクトほどではないかもしれませんが、そこそこのレビュー結果を出すことができます。

今回お見せしてもいいように、トレーニングに利用している環境の結果をサンプルとして利用しています。

C4アーキテクチャ図

案外これ更新できていないシステムが多いですよね。 サンプルはL2のコンテナ図ですが、L1のシステム図も生成できます。

コンテナ図

拡大してご覧になりたい場合は、GitHubに格納してあります。

技術スタックの一覧

トレーニングの環境なので塩漬けにしているのがバレバレですね。

Service Spring Boot Parent Version
Bill 2.6.4
Employee 2.6.7
Menu 2.6.4
Payment 2.6.4
Private 2.6.7
Transaction 2.6.4
UserProfile 2.6.7

AIによるレビューコメント

現在の構成のメリットとリスクを聞いてみました。 もちろん見えている範囲ではありますが、内容は悪くないです。

AIによるレビュー

実行手順 (MTA CLI)

これを実際に実行する手順をご紹介します。

なおMTA部分を避けて生成AI部分だけ試したい方に向けて、GitHubにサンプルに使ったMTAの実行結果ファイル (output.yaml) を格納しております。ご利用ください。

ここから先は自分のリポジトリに対して実行してみたい方向けです。

1. リポジトリをローカルにクローン

参照してみたいリポジトリをローカルにクローンします。

2. MTA CLIを入手

これだけのために入手する方にはCLIがおすすめです。 以下からダウンロードできます。

developers.redhat.com

3. MTAを実行

MTA CLI を実行します。 例として私の環境はmacOS、MTAは7.3.2を使用しています。

./darwin-mta-cli analyze \
  --input <ローカルリポジトリのパス> \
  --output <アウトプットファイルの出力先> \
  --overwrite 

今回はtarget オプションなしとしましたが、実行に数分かかります。 気になる方は何らかの移行先を指定してください。

なおバージョンにより引数が変わることがあります。詳しくはヘルプをご参照いただくか、ヘルプの内容を生成AIに渡してコマンドを解説、生成してもらってください。

4. 生成AIに分析依頼

output.yaml を生成AIに渡してください。 今回の検証レベルでよければ、プロンプトは以下のようなもので十分です。

ローカルリポジトリに対してMigration Toolkit for Applications (MTA) を実行した結果を共有します。
この環境のC4アーキテクチャ図のコンテナ図を生成してください。
エンタープライズアーキテクトとして、この環境に対する洞察を教えてください。特に以下の点が気になります。
- 開発生産性に対するメリット
- 長期的なリスク

まとめ

MTAの実行結果に含まれる情報は限定的ですが、生成AIに短いプロンプトを与えることでここまで可視化できます。

CIに組み込むことで、開発のたびに差分をレビューし、実装のアーキテクチャ適合性や潜在的リスクを継続的に計測することも視野に入ります。

もちろん品質を上げるためにはコンテキスト情報は必要ですし、他のツールと組み合わせたり、自作する部分もあるでしょう。例えば:

  • アーキテクチャビジョンやアーキテクチャ原則
  • 別ツールのアウトプット
  • コード解析を補助するAIエージェント

この実験で分かったのは、現在アーキテクチャレビューの生成AIとの協業が夢ではなく現実になったことと、それからもうすでに「できるかどうか」ではなく「どう作るか」の時代だということです。

よくある質問

MTA CLI の詳しい情報

以下の製品マニュアルをご参照ください。

docs.redhat.com

リポジトリを丸ごと生成AIに読ませては?

当然そのほうが品質が上がります。 Cursorで試した結果、もっと深い洞察を得られました。

しかし残念ながら現実的ではありません。 なぜならトークン上限にすぐに引っかかるからです。

この記事の段階ではMTAを活用した定型レビューで課題箇所をあぶり出し、必要に応じて個別に深掘りするのが現実的と思われます。

これで人間のアーキテクトは必要なくなるのか?

生成AIは強力ですが、万能ではありません。

特に人間のアーキテクト不在のレビューは危険です。理由は以下の通りです。

  • 生成AIのハルシネーション対策は不可欠
  • 生成AIの出力を検証し、品質を高めるにはアーキテクトの判断が必要
  • ビジネスドメインの知識や組織固有の制約を踏まえた判断は代替できない

生成AIは“相棒”にはなれても、アーキテクトの代わりにはなりません。 生成AIの進化は、アーキテクトを不要にするのではなく、アーキテクトの本質的な役割をより鮮明にするものだと考えています。




以上の内容はhttps://rheb.hatenablog.com/entry/2025/09/18/210740より取得しました。
このページはhttp://font.textar.tv/のウェブフォントを使用してます

不具合報告/要望等はこちらへお願いします。
モバイルやる夫Viewer Ver0.14