AIは実装は得意、設計は苦手
AIに設計を任せると高確率で破綻します。
理由は単純で、AIはプログラムを書く能力と、システムを成立させる能力が別物だからです。
AIは「どう書くか」には強いです。
しかし「なぜそうするか」には弱いです。
設計とはコードの配置ではありません。
責任の分け方を決める作業です。
ところがAIは、この「責任」という概念を持ちません。
そのため、見た目が整った設計を作るのに、長期運用で必ず歪みます。
典型例：レイヤードアーキテクチャの崩壊
AIに「Webアプリの設計をして」と依頼すると、ほぼ確実に次の構造を提案します。
- Controller
- Service
- Repository
- Model
一見、理想的な設計に見えます。
実際、多くの技術書も同じ構成を紹介しています。
しかし問題は、その「中身」です。
AIは役割の境界を本当に理解しているわけではありません。
そのため、次のようなコードが発生します。
public class UserService { public void register(UserDto dto){ validate(dto); userRepository.save(dto.toEntity()); emailService.send(dto.getMail()); pointService.addWelcomePoint(dto.getId()); couponService.issue(dto.getId()); } } || これは一見きれいです。しかし設計としては危険です。 なぜなら、このクラスは次の責任を同時に持っています。 - 登録処理 - メール通知 - ポイント管理 - クーポン発行 つまり<strong>ビジネスルールの集積所</strong>になっています。 AIは「整理された見た目」を作りますが、「変更に耐える構造」は作りません。 設計が破綻するのはここからです。 * なぜ破綻するのか：変更を想定していない 設計が必要になる理由は1つです。 変更が発生するからです。 ところがAIは、基本的に「1回完成するシステム」を前提に構築します。 現実のシステムは違います。 - 仕様は増える - 例外が増える - 外部連携が増える - 運用ルールが増える 例えば後から次の要件が追加されたとします。 - 仮登録ユーザーにはポイントを付与しない - 管理者登録はメール送信しない - 外部認証ユーザーはクーポン不要 すると先ほどのServiceはすぐにこうなります。 >|java| if(!dto.isTemporary()){ pointService.addWelcomePoint(dto.getId()); } if(!dto.isAdmin()){ emailService.send(dto.getMail()); } if(dto.isLocalUser()){ couponService.issue(dto.getId()); } || 条件分岐が増え続け、やがて修正不能になります。 これが「AIに設計させたシステムが数ヶ月で壊れる」典型的な流れです。 * 設計に必要なのは知識ではなく判断 AIはデザインパターンを知っています。 DDDの用語も知っています。 SOLID原則も説明できます。 しかし設計とは、知識量ではありません。 設計とは、 <strong>どこを固定し、どこを変えられるようにするかを決めること</strong>です。 たとえば次の判断は知識では解けません。 - DB中心にするかイベント中心にするか - 同期処理にするか非同期にするか - 強整合にするか結果整合にするか - 業務を分割するか統合するか これは正解のある問題ではなく、トレードオフの選択です。 AIはトレードオフを持ちません。常に平均的な解を出します。 平均的な設計は、小規模では成立し、中規模で破綻します。 * AI設計のもう一つの問題「境界の曖昧さ」 設計の本質はモジュールの分割です。 どこからどこまでを一つの責務にするかを決めます。 しかしAIは境界を明確にできません。 その結果、次のような構造が生まれます。 - Entityにロジックが入る - ServiceにSQLが入る - Controllerにビジネスルールが入る - Utilityクラスが巨大化する 一見整理されているのに、修正箇所が分散します。 そして誰も影響範囲を把握できなくなります。 設計が破綻するとは、エラーが出ることではありません。 <strong>変更が怖くなること</strong>です。 * ではAIは設計に使えないのか 使えます。ただし役割を逆にします。 AIに設計を「作らせる」と破綻します。 AIに設計を「批評させる」と強力です。 例えば次のように使います。 > この設計で将来問題になりそうな点を列挙して するとAIは想定外の観点を出してきます。 - 単一障害点 - スケーリング問題 - トランザクション競合 - 依存関係の循環 AIは設計者ではなく、レビューアとして使うと非常に優秀です。 * 注意点：AI設計は初期ほど良く見える 特に危険なのはプロトタイプです。 AIに設計させると、初期開発は爆発的に速くなります。 - 画面がすぐ動く - APIが揃う - 機能が一通り完成する ここで「設計がうまくいった」と錯覚します。 しかし本当の問題は運用開始後に出ます。 - 仕様追加が困難 - 修正の副作用が読めない - テストが壊れる - 担当者しか触れない 設計の良し悪しは完成時ではなく、変更時に現れます。 * 結局どうすればいいのか AIは設計を自動化する道具ではありません。 設計を考える材料を増やす道具です。 設計そのものを任せると、責任の所在が消えます。 しかし設計の検証に使うと、思考の盲点を補います。 AIの価値は「答えを出すこと」ではありません。 <strong>自分の設計に疑問を持たせてくること</strong>にあります。 設計はAIにやらせる作業ではなく、AIを相手に議論する作業に変わりつつあります。
