🛰️
ソフトウェア依存関係を数式で定量化してAIコーディングの指標に活用してみる
はじめに
近年の AI によるコーディング支援技術の発展に伴い、設計の良し悪しを定量的な指標で示すことの重要性が増しています。
なんの指示や指標もなく、AIにコードをどんどん書かせていると気づいたら、そのコードは保守しにくく、改修もしにくいスパゲッティコードになっていることが多いです。
明確な指標があれば、AI はそれを頼りに、より保守しやすく拡張性の高いコードを生成したり、リファクタリングの提案精度を高めたりすることが可能になります。
この記事では、ソフトウェアの依存関係を、外部依存度を示すInstability (I)（0は完全に安定、1は完全に不安定）と、内部の抽象度を示すAbstraction (A)（0は具体クラスのみ、1は抽象インタフェースのみ）という2つの指標で数値化し、それらを組み合わせた Main Sequence との距離 D によって設計の健全性を評価する手法を解説します。
これにより、人間と AI が共通の尺度で設計を議論し、改善していくための道筋を示します。
TL;DR
- Instability (I)（外部依存度を示し、0は完全安定、1は完全不安定）を0〜1で測定
- Abstraction (A)（内部の抽象度を示し、0は具体クラスのみ、1は抽象インタフェースのみ）を0〜1で測定
- Main Sequence (A + I = 1) との距離 D を算出
- グラフ化すれば「保守しやすさ vs. 拡張しやすさ」を定量評価できる！
1. Instability — どれだけ"外"に依存？
| 記号 | 意味 | 数え方 |
|---|---|---|
Ca |
Afferent Couplings | 外から呼ばれる クラス数 |
Ce |
Efferent Couplings | 外へ呼びに行く クラス数 |
I |
Instability | I = Ce / (Ca + Ce) |
- I = 0 … 外部依存ゼロで「超安定」
- I = 1 … 外部に振り回される「超不安定」
💡 安定 = 善 とは限らない。末端の実装パッケージは I→1 の方が健全な場合も。
Instability の計算例
以下の例は、依存関係図の例です。
この図から、パッケージ Pc の
- Ca = 3 (
q → t,r → u,s → u) - Ce = 1 (
u → v)
よって
I = Ce / (Ca + Ce) = 1 / (3 + 1) ≒ 0.25
2. Abstraction — どれだけ差し替えやすい？
| 記号 | 意味 | 数え方 |
|---|---|---|
Nc |
パッケージ内クラス総数 | |
Na |
抽象クラス数 (インタフェース等) | |
A |
Abstraction | A = Na / Nc |
- A = 0 … 具体クラスのみ
- A = 1 … すべて抽象インタフェース
3. Main Sequence — 理想バランス線
A + I = 1
- 左上 (I≈0, A≈1) … 安定かつ抽象な"コア"
- 右下 (I≈1, A≈0) … 不安定かつ具体な"末端"
| Pkg | Ca | Ce | I | Nc | Na | A | D | メモ |
|---|---|---|---|---|---|---|---|---|
| core | 10 | 0 | 0.00 | 15 | 12 | 0.80 | 0.14 | ☀️ |
| infra | 1 | 8 | 0.89 | 20 | 2 | 0.10 | 0.06 | 🛰️ |
| util | 5 | 5 | 0.50 | 10 | 1 | 0.10 | 0.57 | 🚨 |
| api | 7 | 0 | 0.00 | 6 | 0 | 0.00 | 0.71 | 💥 |
| アイコン | 意味 |
|---|---|
| ☀️ | 安定かつ抽象 (コアモジュール) |
| 🛰️ | 不安定かつ抽象 (インフラ層) |
| 🚨 | 不安定かつ具体 (ユーティリティ層: バランス要注意) |
| 💥 | 安定かつ具体 (API層: 変更しづらい危険域) |
4. Main Sequence からの距離 D
D = |A + I - 1| / √2 (0 ≤ D ≤ 0.707)
D' = |A + I - 1| (正規化版 0 ≤ D' ≤ 1)
- D' ≈ 0 … 理想
- D' → 1 … 保守・変更しづらい危険域
5. ハンズオン：8 ステップで診断
| # | やること | ヒント |
|---|---|---|
| 1 | パッケージ列挙 |
com.example.<module> 単位など |
| 2 |
Ca/Ce 集計 |
静的解析ツールを活用 |
| 3 | Instability 計算 | I = Ce/(Ca+Ce) |
| 4 | 抽象クラス数カウント | grep or IDE 検索 |
| 5 | Abstraction 計算 | A = Na/Nc |
| 6 | D を算出 | 上式で距離を取得 |
| 7 | 可視化 | 散布図にプロット |
| 8 | 改善アクション | D が大のものをリファクタ対象に |
6. まとめ
- I/A/D で依存関係の健康診断が可能
- D < 0.2 を目安にバランスを保つ
- AIにコーディングさせるたびに自動レポート & アラート 🛡️
おまけ：AI コーディング用システムプロンプト
あなたはソフトウェア設計の健康度診断を行いながらコードを生成するAIアシスタントです。
以下の規約を必ず遵守してください。
1. 各パッケージ／モジュールに対し、
- Ca (Afferent Couplings): 外部から呼ばれるクラス数
- Ce (Efferent Couplings): 外部へ呼びに行くクラス数
- Nc (総クラス数)
- Na (抽象クラス数)
を収集してください。
2. 以下の数式で指標を計算してください。
I = Ce / (Ca + Ce)
A = Na / Nc
D′ = |A + I − 1|
3. D′ の閾値を 0.2 に設定し、
- 0 ≤ D′ ≤ 0.2：理想バランス
- D′ > 0.2：要注意（設計の偏りあり）
4. コード生成や変更を行うたびにステップ1～3を自動実行し、
- 各パッケージの Ca, Ce, I, Nc, Na, A, D′ の値
- 閾値（0.2）を超えた箇所への警告メッセージ
- 必要であればリファクタリング案（抽象化の追加や依存整理など）
をレポートとして出力してください。
5. 上記レポートを元に、設計の健全性を維持・向上させるようにコード構造を提案・修正してください。
これらの規約に従って、常にソフトウェア全体の設計健全度を意識しながら、
高品質なコードを生成してください。
Discussion