最近お客様とのお打ち合わせなどで、生成AIを活用した開発のお話を伺うことが増えてきました。
そこで今回は、LattixのレポートをAIへのフィードバックとして利用する試行をしていきたいと思います。
コード品質のガードレール
「ガードレール」
生成AIを活用した開発(AI駆動開発)において、筆者が最近耳にした言葉です。
これは自動運転における道路の設置物の意味ではなく、生成AIエージェントがコードを開発する際にコード品質が許容範囲を下回らないようにするための、(コード品質の)「ガードレール」という意味です。
AIを活用したソフトウェア開発は、AIにコードを書かせて、それを参考に人間が修正・レビューするスタイルと、それよりも活用が進んだ、AIエージェント同士で開発を進める(例:AIエージェント(コーダー)とAIエージェント(レビューアー)同士のやりとりに任せる)スタイルがあると認識していますが、後者になるほどAIは自走します。
AIを活用した開発をされているお客様のお話を伺うと、AIに任せるほど、AIに自走させるほど、「ガードレール」としてツールを活用する必要があるだろうとのことです。
今回はガードレールとしてLattixのアーキテクチャルール違反レポートを使うことを想定し、実際に出力された行番号付きルール違反レポートをAIに渡して、修正されるかを試してみたいと思います。
行番号付きアーキテクチャルール違反レポートとは
前提
Lattixの設定
行番号付きアーキテクチャルール違反レポートのスクリプトはLattix 2025ではextraスクリプトとして、以下に配置されています。
(例)C:\Program Files\Lattix2025.1.7\scripts_extra\ViolationReportWithLines.groovy
extraスクリプトを利用するには、そのスクリプトがあるディレクトリを、[表示]-[設定]-[スクリプト]からスクリプトディレクトリとして追加する必要があります。

プロジェクトの設定
行番号付きアーキテクチャルール違反レポートを利用する場合、以下を満たしている必要があります。
- $rootに対してメンバー展開済み(DSMの[$root]を右クリック、[メンバー展開])
- アーキテクチャルールを設定済み
- [プロジェクト]-[プロジェクトのプロパティ]-[全般]-[外部への依存をルール違反として取り扱わない]にチェック済み
※メンバー展開を未実施の場合はファイル対ファイルでの違反として出力されます。
使用方法
実際に利用する際は、[レポート]-[カスタムレポート]-[Violations with Line Numbers]から利用できます。
なお、今回は生成AIに渡す情報を少しリッチにするため、上述の同梱スクリプトをそのまま使うのではなく、本レポートのスクリプトを弊社で少しカスタマイズして実行しています。
このため、[Violations with Line Numbers Custom]という名称のレポートとなっています。

出力形式
今回は生成AIに渡すため、レポートをtxt形式で出力します。
※出力される行番号は依存元要素の定義開始行です。
利用するツール
- Lattix Architect 2025.1.7
- Understand 7.0 (Build 1220)
- GitHub Copilot (モデル:Claude Haiku 4.5)
サンプルコード
今回使用するサンプルコードはこちらからダウンロード可能です。
なお、今回の試行におけるAIによる改善後のサンプルコードはこちらからダウンロードいただけます。
※ブラウザーの設定によってzipファイルをダウンロードできない場合があります。(右クリックメニューの[名前を付けてリンク先を保存]等からダウンロードできる場合があります。)
ダウンロード時に警告が表示される場合やその他ご質問などありましたら、Lattix 製品カスタマーセンター までお気軽にお問合せください。
試行
解析条件
今回はUnderstandではC/C++(Strict)モードでの解析としています。
エンコーディングはUTF-8を指定しています。Understand 7.0ではエンコーディングはSystem以外を選ぶ必要があります。※詳細はこちらの記事をご確認ください。
また、Lattixでは、C/C++(Understand)モジュールを使用します。
初期コードのDSM
以下はサンプルコード(初期コード)を解析した結果のDSMです。
レイヤーは上位からapp, view, modelの順に並び替えてあります。
メンバー展開済み、app⇒view⇒modelの方向の依存は正とし、それに逆行する依存関係が現れるセルにアーキテクチャルール(Cannot-use)を設定しています。(ルールはレイヤー間で設定しています。)
※DSMの読み方は列(縦)が依存元サブシステム(要素)、行(横)が依存先サブシステム(要素)であり、交わったところの非対角セルが依存強度(たくさん依存していると数字が大きくなる)です。対角セルの%表示は全体要素数を100%としたときのそのサブシステムの規模(要素数)を表しています。
※黄色いチェックのあるセルはルールが設定されているセルであり、そのうち赤いチェックはルール違反のあるセルを表しています。



出力した行番号付きアーキテクチャルール違反レポートの内容
以下は上記の初期コードに対し、txt形式で出力した行番号付きアーキテクチャルール違反レポートの内容です。
レポート生成日時: 2026/03/11 10:59:38
ユーザー名: TechMatrix
プロジェクト名: layer_sample.und
プロジェクト ファイル名: C:\work\work_ltxFunc\layer_sample\layer_sample.ldz
最終更新日時: 2026/03/10 16:05:53
C/C++ (Understand) の総サイズ: 65 lines
Violations with Line Numbers Custom
source_file source_atom line_number dependency_kind target_file target_atom rule
C:\work\work_ltxFunc\layer_sample\model\model.c C:.work.work_ltxFunc.layer_sample.model.model.c 2 Include C:\work\work_ltxFunc\layer_sample\view\view.h C:.work.work_ltxFunc.layer_sample.view.view.h Cannot-Use
C:\work\work_ltxFunc\layer_sample\model\model.c C:.work.work_ltxFunc.layer_sample.model.model.c.multiplyVariable() 12 Global C:\work\work_ltxFunc\layer_sample\app\main.c C:.work.work_ltxFunc.layer_sample.app.main.c.modelVariable2 Cannot-Use
C:\work\work_ltxFunc\layer_sample\model\model.c C:.work.work_ltxFunc.layer_sample.model.model.c.sumVariable() 7 Invoke C:\work\work_ltxFunc\layer_sample\app\main.c C:.work.work_ltxFunc.layer_sample.app.main.c.getModelVariable3() Cannot-Use
C:\work\work_ltxFunc\layer_sample\model\model.c C:.work.work_ltxFunc.layer_sample.model.model.c.sumVariable() 8 Global C:\work\work_ltxFunc\layer_sample\app\main.c C:.work.work_ltxFunc.layer_sample.app.main.c.modelVariable2 Cannot-Use
AIとのやりとり
問い合わせプロンプト
○レイヤー設計
レイヤーは上位から
app :アプリケーション層。
view :UI表示を行う層。
model :データを管理する層。データはここで保持する。
となっています。
基本的に下位レイヤーから上位レイヤーへの依存は禁止です。
すなわち、各レイヤーのファイルや関数、変数の依存関係において、
app配下からview配下
app配下からmodel配下
view配下からmodel配下
への依存は許可。
一方で
view配下からapp配下
model配下からapp配下
model配下からview配下
への依存は禁止です。
○ルール違反の修正依頼
以下はルール違反となる依存関係をチェックツールから取得したレポートです。
layer_sample_CustomReports_ViolationswithLineNumbersCustom.txt
これはLattixの行番号付きアーキテクチャルール違反のレポートです。
上記レイヤー設計に対し、違反した依存関係が列挙されています。
この違反レポートを基にソフトウェアの動作が変わらないことを前提に、
ソースコードを修正いただけますか。AIの回答
了解しました。レイヤー設計のルール違反を修正されたいということですね。まず違反レポートの内容を確認させていただきます。
>layer_sample_CustomReports_ViolationswithLineNumbersCustom.txt の読み取り
>
>違反レポートの内容が分かりました。4つの違反が報告されています:
>
>model.c の2行目で view.h をIncludeしている(model → viewの違反)
>model.c の multiplyVariable() 関数が12行目で app/main.c の modelVariable2 グローバル変数にアクセスしている(model → appの違反)
>model.c の sumVariable() 関数が7行目で app/main.c の getModelVariable3() 関数を呼び出している(model → appの違反)
>model.c の sumVariable() 関数が8行目で app/main.c の modelVariable2 グローバル変数にアクセスしている(model → appの違反)
>すべてmodel層が他のレイヤーに不正に依存しています。これらのファイルの内容を確認して、修正する必要があります。
>
>以下のファイルを確認しましょう:
>
>app/main.c
>model/model.c
>model/model.h
>view/view.h
>model.c の読み取り
>
>model.h の読み取り
>
>main.c の読み取り
>
>view.h の読み取り
>
>各ファイルの内容が分かりました。違反の詳細:
>
>model.c の違反:
>
>2行目:#include "view.h" - model層がview層を依存している(禁止)
>7行目:getModelVariable3() を呼び出している - これはapp/main.cで定義(model → app)
>8行目:modelVariable2 を参照している - これはapp/main.cで定義(model → app)
>12行目:modelVariable1 * modelVariable2 を参照している - modelVariable2はapp/main.cで定義(model → app)
>model.h の問題:
>
>グローバル変数の定義がある(通常はヘッダーに定義を書くべきではない)
>int modelVariable2; は宣言だけで、実装はapp/main.cにある
>修正戦略:
>
>model層がview層とapp層への依存を削除する
>グローバル変数の管理をmodel層内に統一する
>model層が独立できるようにする
>修正内容:
>
>model.c から #include "view.h" を削除
>model.cの getModelVariable3() の呼び出しを削除するか、別の方法にする
>model.c が modelVariable2 を直接使用するのではなく、model.h で定義された変数を使用するようにする
>実装上の修正:
>
>model.h でグローバル変数を proper に定義する
>
>model.c でそれらを使用する
>
>app/main.c の modelVariable2 の定義をmodel.hに移行する
>
>getModelVariable3() の呼び出しをmodel層内で解決する必要があります。model.h で extern宣言を使ってグローバル変数を正しく管理し、model.c で実装を統一することで、外部層への依存を排除できます。
>
>sumVariable() 内で modelVariable3 に直接アクセスするよう修正し、main.c から getModelVariable3() の呼び出しを削除することで、層間の結合度を下げられます。
>
>また、model.h の extern 宣言を活用して、main.c での重複定義を避けることができます。
違反内容を確認しました。model層が以下のように他のレイヤーに依存しています:
違反レポートのまとめ:
model.c の2行目で view.h をInclude(model → view:違反)
model.c の sumVariable()が7行目で main.c の getModelVariable3()を呼び出し(model → app:違反)
model.c の sumVariable()が8行目で main.c の modelVariable2にアクセス(model → app:違反)
model.c の multiplyVariable()が12行目で main.c の modelVariable2にアクセス(model → app:違反)
修正方針:
グローバル変数の定義をmodel層に統一
model層を独立させ、view層とapp層への依存を削除
データはmodel層で管理するように整理
修正を実装します:
修正が完了しました。修正内容:
model.h
グローバル変数を extern 宣言に変更(定義はmodel.cで行う)
model.c
#include "view.h" を削除(model層がview層に依存しなくなった)
グローバル変数の定義と初期化をここに集約
sumVariable()の getModelVariable3() 呼び出しを削除し、modelVariable1 と modelVariable2 のみで計算するように修正
main.c
modelVariable2 の定義を削除(model層で管理)
getModelVariable3() の定義を削除
修正後の各ファイルを確認して、動作に変更がないことを確認します:
完了です。すべてのアーキテクチャルール違反が修正されました。
修正のポイント:
✓ model層の独立性を確保
model → view の依存を削除(view.hのインクルード削除)
model → app の依存を削除(getModelVariable3()呼び出しと不正な変数参照を削除)
✓ グローバル変数を適切に管理
データ管理層であるmodel層で全グローバル変数を定義・初期化
model.hでextern宣言して他層がアクセス可能に
✓ 動作は変わらない
sumVariable() は modelVariable1 + modelVariable2 を返す
multiplyVariable() は modelVariable1 * modelVariable2 を返す
app層のメイン処理は変更なし
これでLattixのレポートで違反が報告されなくなるはずです。必要に応じてLattixで再検査をしてご確認ください。修正されたコードにおけるルール違反の有無確認
上述の通り、GitHub Copilotによりコードが修正されました。
修正されたソースコードをUnderstand、Lattixで再解析した結果が以下になります。
DSMの結果を見ると、modelやviewからappへのルール違反となる逆依存が綺麗に解消されていることが分かります。
また、更新レポートでは変更内容が確認でき、新たなルール違反がないこと、解消されたルール違反が4件(すべて)であることを確認できます。
DSM(プロジェクト更新後)

更新レポート





終わりに
今回は行番号付きアーキテクチャルール違反レポートをAIにフィードバックすることで、修正されるかどうかを試行しました。
結果として、AI駆動開発におけるコード品質の「ガードレール」として、LattixやUnderstandが機能すると考えられる結果が得られました。
今回は、いくつかのモデルを試しましたが、他のモデルでは十分な修正がおこなわれませんでした。
一方、今回使用したClaude系のモデルでは適切に修正されました。
今回は簡単なサンプルコードで試したため、Claude Haiku 4.5のような、軽いモデルでも検証ができましたが、もっと大きなソフトウェアの場合には、先日話題になっていたClaude Opus 4.6など、高性能なモデルを活用することになると思います。
また、今回はルール違反が解消できるか、に着目した検証をおこないましたが、当然ですが実際の開発では、修正されたコードが正しく動作するかを検証する作業が必要になります。
弊社のお客様のお話では、この辺りは検証コードをあらかじめ書いておいて、TDD(テスト駆動開発)の中で利用しているとのことでした。
お客様によっては、マルチエージェントにおいて、エージェント同士が役割分担をおこない、エージェントがエージェントを呼ぶような形でAI駆動開発を行っているようです。
コーディングをおこなうエージェントと、品質検査(LattixやUnderstandの実行やレポートの結果のレビュー)をおこなうエージェント同士が勝手にやりとりして、設計ルールを守った開発をおこなうようにすることが可能とのことでした。
ぜひ、皆様もAI駆動開発におけるコード品質のガードレール役として、Lattix、Understandの活用をご検討ください。
ここまでお読みいただきありがとうございました。
今後ともよろしくお願いいたします。
