AI時代にSPL開発は不要なのか？構造の違いでAIの利用コストはどう変わるかを実験した

Q.AIがあれば、ソフトウェアアーキテクチャが適当でも開発は可能なのではないか？

A. 可能ですが、複数製品群の開発においては、製品のバリエーションが多いほど、変更が積み重なるほど、AIの利用コストが複利で大きく膨らみ続けます。

エクスモーションでは複数製品群開発をAIで効率的に行う上で欠かせない

• ソフトウェアアーキテクチャの整理
• AI駆動開発環境構築

を支援しています。

はじめに：AIがあれば、SPLは要らない？

SPL（ソフトウェアプロダクトライン）開発は、複数の製品群を開発・保守するコストを下げるための手法です。仕向け先や製品グレードごとにソフトウェアのバリエーションを用意する必要がある場合、共通機能を適切に管理しなければ開発コストはバリエーションの数に応じて膨れ上がります。そこで共通部分を「共通資産」としてまとめ、製品ごとの違いは「差分」として管理することで、製品が増えても開発コストが膨らまないようにするのがSPL開発です。

一方で、生成AIの進化は目覚ましく、コードの読解や修正はAIに任せられるようになってきました。そこで、こんな声を耳にするようになりました。

「AIを活用すれば、SPLなど導入しなくても複数製品群を開発できるのは？」

開発が可能か不可能かで言えば、答えは当然「可能」でしょう。AIは、構造が整っていないコードでも改修を力技でやり遂げます。問題は、そのときにかかるAIの利用コストです。ご存じの通りAIの利用料金は、AIが読み書きするトークンの量で決まります。もし、AIの利用コストが爆発してしまうのであれば、それは現実的な選択とは言えません。

そこで私たちは、同じ改造をAIに48回依頼し、SPL開発の構造の有無でAIの利用コストがどう変わるかを検証しました。

結論としては、構造の違いはAIの利用コストに大きな差を生みました。製品を横断する変更では、SPLの構造によってAIが読む量（＝利用コスト）が最大42%削減。モデル試算では、10年間の累積AIコストに約35倍の差がつきました。以下で、その中身をご紹介します。

実験の概要：3つの立場を、2つの方法で検証

「AIと構造」への向き合い方は、世の中で大きく3つの立場に分かれています。

どの立場が正しいのかを、次の2つの方法で検証しました。

1. シミュレーション：類似製品10種を10年間保守する場合の累積AIコストを、公開研究の係数を使って試算
2. 実測：本物のコードとAIを使い、同じ改造を計48回依頼して計測

まずはシミュレーションの結果から見ていきます。

シミュレーション結果：10年間の累積コストに約35倍の差

まず、構造の悪さがAIのコストを膨らませる仕組みを、変更1件あたりのAIコストとして次のような式でモデル化しました。

αは「AIが読む量の膨張」、γは「巻き添えで直す箇所の数」、βは「やり直し率」です。係数には結合度やLLMの精度に関する公開研究の値を使っています。この式で計算すると、構造が悪いコードではC≒13.1、整理されたコードではC≒2.9となり、同じ変更1件でも約4.5倍のコスト差が生まれます。

これをもとに、①何もしないでAIに任せる、②綺麗にしてからAIに任せる、③SPL化してからAIに任せるの3つのパターンで、10製品を10年間運用するケース（変更は年50件×製品、その7割が共通部分への変更、文書コスト込み）をシミュレーションしました。その結果、③の累積コストを1とすると、何もしないでAIに任せる①のコストは約35倍にまで達しました。

構造が悪いままだと、変更のたびに絡み合いが増え、次の変更がさらに高くつきます。コストは複利で膨らむのです。しかもAIは悲鳴を上げずに、汚れた構造の上に書き続けます。差に気づいたときには、すでに大きく開いているのです。

では、本物のコードとAIでも同じ傾向は見られるのでしょうか。ここからは実測の結果です。

実測の題材：構造だけが違う5つのコードベース

題材には、SPL研究の標準題材として知られる公開リポジトリ「Apo-Games」のJavaゲームアプリ2本を使いました。クローン（コピー）開発で派生した、まさに現場によくある構造のアプリです。機能は同じまま、構造だけを変えた5つのコードベースを用意しました。

この5つに「まったく同じ改造」をAIに依頼し、AIが読んだ量（トークン数）と書いた量（変更行数）を計測しました。AIの利用料金は主にトークンの量で決まるため、読んだ量はそのままAI利用コストの指標になります。依頼したタスクは次の6種類で、それぞれ3回ずつ繰り返しています。

• 小規模タスク（4種）：ポーズ機能の追加、セーブ／ロード機能の追加、バグ修正、文言の外部化
• 横断タスク（2種）：イベント通知の追加、ヘッドレス化（画面なしでも動くようにする）

小規模タスクは一部のコードだけを触る局所的な変更、横断タスクはアーキテクチャ全体にまたがる変更です。

結果① 小規模な変更では、構造による差は出ない

局所的な変更では、AIは構造の悪さを力技で乗り越えられます。小規模タスク4種の変更行数（中央値）は、どの構造でもほぼ同水準です。

つまり「AIだけで十分」という楽観論は、半分は正しいと言えます。ただし、それは小さな変更に限った話です。

結果② 横断的な変更では、構造が効く

構造の効果がはっきり現れたのは、アーキテクチャを横断する変更でした。イベント通知の追加では、AIが読んだ量（中央値）が何もしない版の13.1万トークンに対し、SPL改善2版は7.6万トークン。42%の削減です。

• もう一つの横断タスク（ヘッドレス化）でも、36%の削減でした
  
• 変更行数もSPL改善2版が最小の78行（何もしない版は136行）で、ばらつきも最小でした
  
• 条件間の差は統計的にも有意です（p=0.023／0.043、効果量W=0.94／0.82）

AIが読む量は、そのままAIの利用コストに直結します。構造を整えることが、AI利用の請求額を直接下げるわけです。

結果③ 依存整理だけでは、AIは「善意で」暴走する

興味深いのは、依存関係だけを整理したコード改善2版です。同じイベント通知の追加で、変更行数が5つの中で最大の252行に膨らみました。

AIは、綺麗に整えられたインターフェースを「拡張のご招待」と読み取り、頼んでいない基盤クラス群まで増築したのです。しかも3回の試行すべてで新しい基盤を作り、その構成・配置・名前は毎回違いました。結果として、アプリAとアプリBに「似ているが別物」の基盤のコピーが2つ生まれ、以後は別々に育っていくことになります。

一方、部品化と依存整理を両方行ったSPL改善2版は、78行に収まりました。新たに増えた「土台」はゼロで、既存の2ブロックを修正するだけで完結しています。部品の境界が「どこまで触っていいか」の壁として働き、AIの変更範囲を制約したのです。

これが10製品だったらどうでしょう。形の違う基盤のコピーが10個生まれ、それぞれを別々に保守することになります。個々の作りが綺麗でも、見るべき範囲は製品の数だけ増えていきます。「依存関係の整理」と「部品の境界」の両方が揃ったときに、構造はAIに最も効くのです。

補足：「依存関係の整理」で何をしたのか

元のコードでは、画面（Panel）とゲーム本体のロジックが互いを直接呼び合う「循環依存」になっていました。ボタンやセーブ機能も画面を直接知っており、画面は何でも抱えた「神クラス」状態です。1か所直すだけでも、AIは全部を読まされることになります。

そこで、間に「約束事」となるインターフェース（IGameContext）を1枚挟み、ロジックやボタン、セーブ機能はこの約束事だけを参照する一方通行の構造に変えました。これにより循環度は、Snakeで41.0%→35.0%、NotSoSimpleで33.3%→30.2%に下がっています。

投資回収：製品数が多いほど早く元が取れる

構造を整えるには投資が要ります。実測では、横断的な変更1回あたりのAIコストは何もしない版の$3.60に対し、SPL改善2版では$2.17でした。この差で、移行にかかる投資（28時間 × 開発者時給 $80 = $2,240）を何回の変更で回収できるかを試算しました（トークン単価 $33 / 100万トークンで計算）。

共通資産への変更は1回で全製品に効くため、製品群が大きい組織ほど回収は早まります。

考察：量はAIへ、質は人へ

実験から見えてきたのは、「AIに任せる場合も、SPL開発のエッセンスを入れた構造が優位である」ということです。局所的な変更ならAIは悪い構造でも力技で乗り切りますが、製品を横断する変更では構造の差が歴然と表れます。

では、AIが扱いやすい構造とはどんなものでしょうか。今回の結果からは、次の3つの要素が浮かび上がります。

• 責務が単一：1つの部品が1つの役割だけを持つ
  
• 規模が適切：部品が大きすぎず、読むべき範囲が絞られている
  
• 依存が少ない：部品同士が絡み合っていない

これは、人間にとってわかりやすい構造とまったく同じです。これまで大切にされてきた設計原則が、AI時代には「コスト削減」として複利で効いてくるのです。

ただし、結果③が示すように、依存関係を綺麗にするだけでは不十分です。何を共通にし、何を製品ごとの差分とするか。その境界を引くことで初めて、AIの「善意の暴走」を抑えられます。そしてこの境界を引く判断こそ、AIには任せられない人の仕事です。

SPL開発はこれまで、差分と成果物の紐付けといった膨大な管理作業に挫折する現場が少なくありませんでした。しかしそうした「量」の作業こそ、AIが最も得意とする領域です。量はAIへ、質は人へ――これがAI時代のSPL開発の基本形だと私たちは考えています。

エクスモーションのSPL×AI開発支援

SPL開発の必要性はわかっていても、導入に踏み切れない、あるいは途中で挫折してしまった――そんな現場は少なくありません。その大きな原因の一つが、差分と成果物の紐付けやトレーサビリティの維持といった膨大な管理作業、つまり「量の壁」でした。

この量の作業こそ、AIが最も得意とする領域です。エクスモーションでは、量的な作業はAIに任せ、人は「何を共通とし、何を可変とするか」という質の判断に集中する――「量はAIへ、質は人へ」の考え方で、SPLの導入を効率的に支援しています。従来は重すぎたSPL導入を、AIの力で現実的な負担で進められるようになっています。

「AIを使ってSPL開発を始めたい」「共通部品化に挫折したので助けてほしい」「自社のコードでAIの利用コストがどれだけ下がるか知りたい」――そんなときは、ぜひお気軽にエクスモーションにご相談ください。

関連ソリューション

SPL

ソリューション

SPL