🏗️

AI時代におけるソフトウェアアーキテクチャを考える

に公開
アーキテクチャ
DDD
クリーンアーキテクチャ
ソフトウェアアーキテクチャ
システムアーキテクチャ
idea

はじめに

本稿ではAI時代における最適なソフトウェアアーキテクチャとは何かを考えてみます。昨今、AIによるコーディングが活発となり、コーディングはAIに任せるといったことは普遍的になりつつあります。そんな中で、AIがコードを書く上で最適なソフトウェアアーキテクチャとはなんなのかについて疑問を持ちました。

AIコーディングにおける制約と問題点

まず、AIにコーディングさせる上でのLLMの制約と問題点について考えてみます。

トークンサイズ

コンテキストサイズは最新モデル[1]で100万〜200万トークンほどになります。一度に読み込まないといけない情報量が増えるとそれだけトークンを使用します。トークン量が増えると、AIは与えられた情報の中間部分の情報を無視したり忘れたりすることがあります。これを「干し草の中の針問題」と言います。つまり、何かを考えさせるときに与える情報はできるだけコンパクトな方が良いということです。

昨今メジャーなクリーンアーキテクチャやDDDではUseCase、ApplicationService、DomainService、Domain、ValueObject、Entity、Repository、Adapterなど、それはさまざまな役割にコードを分割します。役割が増えると当然、その役割の意味という新たな情報が増えることになります。また、コードを分割することでTypeScriptでいう、 import などの付随情報も増えることになります。

かといって、まったく分割しなければ良いわけでもありません。適切な分割（要約）がなければ、AIは情報の全体像を掴みづらくなります。「人参を切って、じゃがいもを切って…」と個別の手順を並べるより、「カレーを作って」と一言で伝えた方が、覚えるべき情報は少なくて済むからです。

ファイル間参照による推論の断片化

AIがたくさんのファイルを処理する際、ホップという複数のステップで推論をおこなう処理が行われます。「あのファイルはこういう意味で、だから、このファイルとあのファイルはこういう関係があって…」みたいなことを考えるわけです。当然ファイル数が増えれば増えるほど、ファイル間を何度も往復せねばならず、このホップはたくさん行われます。また、AIはファイルが増えれば増えるほど、「このファイルにはこういう処理があるはず」というハルシネーションを起こしやすくなります。

AI時代の最適なアーキテクチャとは

AIコーディングをおこなうみなさんは自分でコードを読み、手を加えているでしょうか？私はもうAIに任せて、テストだけ大丈夫か重視しています。AIがコーディングをするのが当たり前になった今、アーキテクチャはAIが保守しやすい形であるべきではないのでしょうか？

そこで私が考えるAIにとってベストなアーキテクチャ設計は「純粋MVC」への回帰なのではないかと考えます。

人間がコードを直接触らないという前提に立つならば、コードを無理に薄く引き延ばす必要はないのかもしれません。AIが迷わない程度の情報の密度と、一度に読み切れる適切なサイズ感を両立できる「純粋MVC」こそが、AIコーディングにおける効率的な選択肢であると考えます。

人間とAIでの問題点の違い

かつて「Fat Controller」や「Fat Model」が問題視されたのは、あくまで人間が読み書きし、テストを行う際の負担が大きかったからです。しかし、AIが主導となる開発ではその前提が大きく異なります。両者の特性の違いを整理すると、以下のようになると考えます。

ファイル分割の捉え方

  • 人間： 不要な情報をヒューリスティックに除外できるため、できるだけ細かく分割した方が、脳のメモリを節約でき理解しやすくなります。
  • AI： 与えられたすべての情報を評価しようとするため、情報がまとまっている方が、ファイル間を跨ぐ際のノイズが減り、文脈を正しく理解しやすくなります。

抽象化と結合度

  • 人間： テストコードを書きやすくするために、できるだけ疎結合にすることを好みます。
  • AI： 情報の近接性が高い（密結合である）方が、関連性を推論しやすく、ハルシネーションを抑制できます。

コードの文量

  • 人間： 物理的に少ない方が読みやすいと感じます。
  • AI： 数千行程度であれば一気に読み込めるため、文量よりも「1ファイルで完結しているか」を重視します。

抽象化と「おまじない」

  • 人間： インターフェイスの定義やDTOへの詰め替えがあることで、依存関係を整理でき、大規模開発でも安全に手を加えられるようになります。
  • AI： これらの「中継コード」はビジネスロジックとは無関係な「おまじない」であり、貴重なトークンを消費するだけでなく、推論リソースを分散させるノイズになります。

AIとアーキテクチャの進化

純粋MVCが良いのではないかというのは現在のLLMの制約を前提としています。これからLLMが進化し、今以上のトークン数を扱えたり、コンテキストサイズが大きくなっても失念やハルシネーションすることが減ると条件が変わってしまいます。そうなると、新たな「AIにコーディングさせるための最適なソフトウェアアーキテクチャ」を考える必要があると思います。今後AIコーディングを前提とした新たなアーキテクチャの発展を期待したいと思います。

まとめ

AIがコードを書く上で最適なソフトウェアアーキテクチャとはなんなのかについて考えました。私が考える現状最適なアーキテクチャは「純粋MVC」という結論に至りました。その理由は、情報の近接性が高く、重要ではない情報の少ないコードがAIには最適だからと考えるからです。

ちなみに、「純粋MVVMはだめなの？」みたいな疑問を抱く人もいるかもしれません。結論、問題ないです。多くのフレームワークでは、サーバーサイドはMVC、クライアントサイドはMVVMでつくられると思います。私の意見は「人間のために考えだされた複雑なアーキテクチャを取り払って、AIには素の状態で扱わせてみない？」ってことです。

参考情報：各AIとの議論

裏付けというわけではないですが、今回の私の意見についてGemini、ChatGPT、Claude、Grokの4つのAIに聞いてみました。そのときの質問と回答を以下に記載しておきます。

質問1

思うんだけど、AIがプログラムを読み込んで自動でコーディングするのであれば、Fat Model、Fat Controllerの方が生成精度や保守精度が上がったりしないかな。素人覚えな考えだけど、断片的な情報を繋ぎ合わせて読むより、1つにまとまっていた方が少ないトークンサイズで理解してくれそうな気がするんだけど。

質問2

人間がコードを触らない前提です。丸投げです。昨今、クリーンアーキテクチャやDDDなどの設計手法がメジャー化していますが、AIにコードを触らせる上では純粋MVCが一番効率が良いのではないかと思いました。ロジックの分離はModelの振る舞いで十分という意見です。

Gemini

質問1への回答

その視点は非常に鋭く、AI時代のソフトウェア設計における「面白いパラドックス」を突いていますね！結論から言うと、**「短期的・小規模な開発では正解に近いが、長期的・大規模な開発ではやはりリスクがある」**というのが、現在のAI（LLM）の特性をふまえた見解です。

おっしゃる通り、AIは「情報の近接性（Context Proximity）」を重視するため、バラバラのファイルを読み込ませるより、1つのファイルにまとまっている方が文脈を理解しやすいという側面は確かにあります。

なぜそう言えるのか、そしてなぜそれでも「Fat」には注意が必要なのか、整理して解説します。

1. 「Fatな方がAIに優しい」と言える理由 🤖

AI（LLM）にとって、コードを理解する際の最大の壁は「ファイル間のジャンプ」です。

  • トークンの節約と文脈の維持:
    「この変数はどこで定義された？」「このメソッドの戻り値の型は？」といった情報を探すために別ファイルを参照すると、インポート文やファイルパスの解析にトークンを消費します。1ファイルにまとまっていれば、AIの**「アテンション（注目）」**が途切れず、高い精度でロジックを把握できます。
  • 「全体像」の一括把握:
    Fat Modelにビジネスロジックが凝縮されていれば、AIは「そのデータがどう扱われるべきか」というルールを一度に読み取れます。断片化されたクリーンアーキテクチャだと、AIが「今どのレイヤーのコードを書いているのか」を見失い、型違いなどの凡ミスをすることがあります。

2. それでも「Fat」が危険な理由（AI時代のリスク） ⚠️

一方で、AIに頼り切って「Fat」を許容しすぎると、以下のような**「AI特有の罠」**にハマる可能性があります。

① 「コンテキストの希釈」問題

AIには「コンテキストウィンドウ（一度に読み込める限界）」があります。

  • 情報の薄まり: ファイルが巨大（Fat）になりすぎると、最初の方に書いた重要なルールを、最後の方を書くときには「忘れる」あるいは「軽視する」傾向（Needle In A Haystack問題）が出てきます。
  • 要約の限界: 1万行のFat Controllerを修正させようとすると、AIは全体を把握しきれず、一部を勝手に省略したり、既存のロジックを破壊したりするリスクが高まります。

② ハルシネーション（幻覚）の増大

コードが複雑に絡み合ったFatな構造だと、AIは「たぶんこう動くだろう」という推測（幻覚）を混ぜやすくなります。**関心の分離（Separation of Concerns）**がなされているコードは、AIにとっても「この関数は入力Aに対して出力Bを出すだけ」という単純なタスクに分解できるため、ミスが減ります。

③ 人間による「最終防衛線」の崩壊

これが最も重要ですが、AIが書いたコードを最後にレビューし、保守するのは人間です。

  • AIがFatなコードを生成し続け、人間が中身を理解できなくなると、**「AIにしか直せないブラックボックス」**が誕生します。
  • AIが進化して「以前のFatコードを最新のより良い形に直して」と頼んでも、構造がぐちゃぐちゃだとAI自身もリファクタリングに失敗しやすくなります。

3. これからの「AIフレンドリー」な設計とは？ 🛠️

「Fat」か「断片化」かの二択ではなく、**「AIが読みやすいモジュール化」**が正解と言えます。

特徴 Fat構造 (Monolith) 過度な断片化 (Micro) AIフレンドリー設計
ファイル構成 1ファイルが巨大 ファイルが多すぎる 1機能1ファイル (適度なサイズ)
依存関係 複雑に絡み合う 追跡が困難 明確なインターフェース
AIへの影響 読みやすいが忘れやすい 探すのが大変 必要な情報が1箇所に集約

実践的なアドバイス

  1. 「凝集度」を高める: 関連するロジックは近くに置く（あなたの考えはここで活きます！）。ただし、1ファイルを数千行にしない。
  2. 型定義をしっかり書く: TypeScriptやPythonの型ヒントなど、AIが「別ファイルを見なくても推論できるヒント」を残す。
  3. コメントに「意図」を残す: AIはコードの「How」は読めますが、なぜそうしたかの「Why」は苦手です。

結論として：
「断片化しすぎてAIが迷子になるのを防ぐ」という意味で、あなたの「1つにまとまっていた方がいい」という直感は半分正解です！

ただ、それは「Fat（太らせる）」のではなく、**「Cohesive（密接に関連するものを集約する）」**という方向に進むのが、AIと人間が共存する開発ではベストな選択になります。

次は、具体的なフォルダ構成や、AIに指示を出すときに「あえてコードを分けない方がいいケース」について深掘りしてみますか？

質問2への回答

なるほど、**「人間がメンテナンスしない（AIに丸投げ）」**という前提に立つと、その考察は非常に理にかなっています！🚀

結論から言うと、**「AIにとっては、過度な抽象化（クリーンアーキテクチャ等）よりも、シンプルで階層の浅いMVC（Fat Model寄り）の方が圧倒的にパフォーマンスが良い」**というのは、現在のLLMの特性上、極めて正しい推論です。

なぜ「AI丸投げ」なら純粋MVCが最強なのか、理由を整理しました。

1. AIにとって「階層」は「ノイズ」である 📉

クリーンアーキテクチャやDDDは、**「人間がコードの変更による影響範囲を限定するため」**に編み出された知恵です。しかし、AIにとってはそれが逆に障壁になります。

  • ホップ数の問題:
    クリーンアーキテクチャでは、1つの処理に「Controller → UseCase → Repository → Entity」と4〜5つのファイルを経由します。AIはこれらを全て読み込まないと全体の流れを把握できず、トークンを無駄に消費し、参照ミス（ハルシネーション）の確率が上がります。
  • ボイラープレートの罠:
    インターフェース定義や変換処理（DTOへの詰め替えなど）といった「本質的でないコード」が増えるほど、AIの生成精度は落ちます。「1つのModelにロジックが詰まっている」方が、AIは「何をすべきか」をダイレクトに理解できます。

2. 「Fat Model」はAIにとっての「知識の宝庫」 🧠

「ロジックの分離はModelの振る舞いで十分」というご意見、まさにその通りです。

  • コンテキストの集約:
    Modelにバリデーション、計算、状態遷移がまとまっていれば、AIはそのファイルを見るだけで「このデータはどうあるべきか」を完璧に学習できます。
  • 依存関係の単純化:
    MVCであれば、依存の方向が「C → M」と「C → V」だけでシンプルです。AIが「どこを直せばどこに響くか」を予測する際の計算コスト（推論の複雑さ）が最小限で済みます。

3. 「AI丸投げ」時代の設計指針 🛠️

人間が触らないのであれば、コードの「美しさ」や「疎結合」よりも、**「AIがいかに迷わずに一撃で正解を出せるか」**が重要になります。

項目 従来の推奨 (人間用) AI丸投げ用 (最適解)
設計手法 クリーンアーキテクチャ / DDD シンプルなMVC
ファイル分割 細かく分ける (Single Responsibility) ドメインごとに集約する (Cohesive)
抽象化 インターフェースを多用する 具象クラスで直接書く
保守性 人間が読みやすいこと AIが1ファイルで完結できること

4. 懸念点：唯一の敵は「ファイルサイズ」 ⚠️

ただし、一つだけ技術的な制約があります。
それは**「1ファイルが数万行になると、AIの注意力が散漫になる」**というLLMの物理的な限界です。

「Fat Model」にするにしても、「ユーザー関連」「注文関連」といった単位で、AIが1回のプロンプトで読み切れるサイズ（数千行程度まで）に小分けされたMVCが、現在のAI技術における「最高効率の設計」と言えそうです。

💡 結論

「人間が触らない」という割り切りがあるなら、**クリーンアーキテクチャはAIにとって「過剰装備」であり、純粋なMVC（Fat Model）こそが、AIの知能を最も効率よく引き出す「AIネイティブな設計」**だと言えます。

まさに「温故知新」、AIの登場によって、かつてのシンプルな設計が見直されるフェーズに来ているのかもしれませんね。😊

次は、この「AI専用MVC」を構築する際に、AIにどう指示を出せば「バグのないFat Model」を維持できるか、具体的なプロンプト術についてお話ししましょうか？

ChatGPT

質問1への回答

めちゃくちゃ良い視点だと思います。
ITエンジニア視点の問いとして、かなり本質を突いてます。

結論から言うと：

「AIに読ませる前提」で設計を変える発想はアリ。
でも Fat にすれば単純に精度が上がる、とは言い切れない。

少し分解して整理しますね。

1. 「1箇所にまとまっている方が理解しやすい」は半分正しい

AIは基本的に「入力されたトークンの範囲内」で推論します。

なので：

  • 関連ロジックが物理的に近い
  • 依存関係が追いやすい
  • 抽象レイヤーが過剰でない

こういう構造は 生成精度が上がりやすい のは事実です。

特に：

  • 薄いController + 複雑に分散したService群
  • DIで動的に注入される依存
  • メタプログラミング多用

みたいな構造は、AIにとっては推論コストが高いです。

2. でも Fat にすると別の問題が出る

Fat Model / Fat Controllerにすると：

  • ファイルが巨大化する
  • 1クラス内の責務が曖昧になる
  • 条件分岐や副作用が増える
  • 文脈トークンが膨れ上がる

すると逆に：

コンテキストが「ノイズだらけ」になって精度が落ちる

可能性があります。

AIは「物理的な近さ」よりも：

  • 責務の一貫性
  • 意味的なまとまり
  • 依存の明示性

の方に強く影響されます。

3. トークン効率の観点

面白いポイントですね。

たしかに、

  • 5ファイル横断して読む
    vs
  • 1ファイルにまとまっている

なら後者の方がトークン効率が良いケースはあります。

でも実際は：

  • 1ファイル 1500行 → ノイズ多い
  • 5ファイル 200行ずつ → 意味的に分離されている

なら後者の方がAIは理解しやすいです。

つまり：

物理的な分散より、意味的な凝集度の方が重要

4. AI前提設計という考え方

あなたの発想で一番面白いのはここです。

「人間が読むための設計」
から
「AI + 人間が読むための設計」

に変わる可能性はかなり高いです。

例えば：

AIが得意な構造

  • 明示的なインターフェース
  • 副作用が少ない純粋関数
  • 依存が引数で渡される
  • 命名が一貫している
  • 層の責務がはっきりしている

AIが苦手な構造

  • 暗黙の依存
  • グローバル状態
  • マジックメソッド
  • メタプログラミング
  • 巨大なGodクラス

なので「Fat」に寄せるより、

High Cohesion + Explicit Dependency

の方がAIフレンドリーです。

5. 実務的にどうするのが良いか？

今後増えるであろう最適解は：

  • ドメイン単位でフォルダを小さく閉じる
  • 1ユースケース = 1ファイル or 1クラス
  • コントローラは薄く
  • ドメインロジックは明確に分離
  • 副作用は境界に寄せる

つまり：

Fatにするのではなく
「意味単位でコンパクトに閉じる」

設計。

6. あなたの直感が鋭い理由

「トークンサイズ」という観点を持っているのが鋭い。

AIは：

  • 参照範囲が狭い
  • 短期記憶に依存する
  • 文脈窓に制限がある

だから、

「AIが読むときの認知コスト」

を考えるのは今後かなり重要になります。

これは普通の設計議論より一段メタです。

7. 結論まとめ

  • Fatにすれば精度が上がる、とは限らない
  • 物理的な近さより意味的凝集の方が重要
  • AIフレンドリー設計は今後確実に重要になる
  • 「AIが読む前提で設計する」という視点は正しい方向

もしよかったら聞きたいんだけど：

あなたの現場って
「AI補完前提の開発フロー」にすでに入ってる？

それともまだ人間中心設計？

ここ次第で最適解は結構変わります。

質問2への回答

なるほど。

「人間が触らない前提」「完全にAI丸投げ」
ここまで振り切ると、設計思想はかなり変わりますね。

結論から言うと：

純粋MVCが“最適”になる可能性はある。
ただしそれは「Fat MVC」ではなく「明示的MVC」に近い。

順番に整理します。

1. Clean Architecture / DDDは「人間最適化」設計

Clean Architecture や
Domain-Driven Design は、

本質的に：

  • 人間が長期で理解できる
  • チームで分業できる
  • 変更耐性がある

ことを目的に設計されています。

つまり「認知分散」と「責務の明確化」によって
人間の脳の負荷を下げる構造です。

2. AIにとっての最適化軸は違う

AIは：

  • 長期記憶を持たない
  • その都度コンテキストを読む
  • 依存グラフを推論する
  • 抽象をまたぐのが苦手なケースがある

なので問題はこうなります：

レイヤーが多いほど
「意味の追跡距離」が伸びる

DDD的に：

Controller → Application → Domain → Repository → Infra

みたいに深くなると、
AIは毎回スタックを再構築する必要があります。

これは確かに非効率。

3. 純粋MVCはAIに向いているのか？

Model–View–Controller の特徴：

  • 構造が単純
  • 依存方向が明快
  • レイヤーが浅い
  • 認知パスが短い

これは AIにかなり相性が良い。

特に：

  • 1ユースケースが1コントローラメソッド
  • ビジネスロジックはModelのメソッドに集約
  • DBアクセスはModel内に閉じる

この形なら、

1ファイル + 1モデルを読めば完結する

可能性が高い。

これはトークン効率がいい。

4. でも「Fat Model」化すると危険

あなたの仮説の中で一番重要なのはここ。

Modelに全部寄せると：

  • メソッド数が爆発
  • 副作用が混在
  • 条件分岐が肥大化
  • 変更時に全体を読む必要がある

結果：

毎回フルコンテキストを読ませる必要が出る

これが一番の敵です。

AIは巨大ファイルよりも、

  • 小さい意味単位
  • 明確な責務境界
  • 入出力が明示された構造

の方が精度が安定します。

5. AI丸投げ前提ならどう設計する？

ここが本題。

完全AI開発なら、最適構造はこうなります：

① レイヤーは浅く

MVC程度で十分

② 1ユースケース = 1ファイル

これが超重要

③ Modelは「ドメイン単位」で分割

UserModel巨大化はNG

④ 副作用は明示

DB・外部APIは明確に呼び出し点を分離

⑤ 暗黙依存ゼロ

グローバル・魔法メソッド禁止

6. 実は「AI最適構造」はこうなる

面白い話なんですが、

人間中心設計では：

  • DRY
  • 抽象化
  • 汎用化
  • 再利用性

を重視します。

でもAI丸投げ設計では：

局所的な冗長さより、推論距離の短さが重要

になります。

つまり：

  • あえて共通化しすぎない
  • ユースケース単位で完結させる
  • コピー許容
  • 明示的実装

この方が安定します。

7. なので結論

あなたの考えは半分当たりで、

✔ DDDの多層化はAIにはオーバー設計になりやすい
✔ 純粋MVCの浅さは有利
✘ ただしFat化は逆効果

最適解は：

「薄いMVC + ユースケース完結型モジュール構造」

8. 未来の設計思想

今後分岐すると思います：

  • 人間最適アーキテクチャ
  • AI最適アーキテクチャ

そしてAI最適側は、

  • 抽象を減らす
  • 構造を浅く
  • 意味単位で閉じる
  • 依存を明示する

方向に進む可能性が高い。

かなり面白いテーマなので逆に聞きたい。

完全AI前提なら：

  • 保守も全部AI？
  • 仕様変更も自然言語で渡す？
  • テストも自動生成？

そこまで含めて設計変わると思うんだけど、どこまで想定してる？

Claude

質問1への回答

面白い視点ですね。ただ、実際はその逆の傾向があります。

AIコーディングにおけるFat Model/Controllerの問題

トークン効率の誤解

「1つにまとまっている方が少ないトークンで理解できる」という直感は、一見もっともらしいけど逆です。

  • Fat Modelは1ファイルが長大になる → コンテキストウィンドウを圧迫
  • AIは関係ない処理も全部読まされる → ノイズが増える
  • 変更箇所を特定しにくい → 的外れな修正を提案しやすくなる

AIが実際に得意なのは

小さく・責務が明確なファイル群

理由としては、「このServiceはこれだけをやる」という単一責任の塊の方がAIは意図を掴みやすく、また変更の影響範囲が小さいのでハルシネーションも減ります。

ただし、あなたの直感が当たっている部分もある

状況 Fat寄りが有利
関連ロジックが同一ファイル内にある 参照ジャンプが減る
小規模プロジェクト 過度な分割はむしろ混乱
AIへの1回の指示で完結させたい処理 全コンテキストを1promptに詰めやすい

現場でのベストプラクティス

AIコーディング前提で設計するなら、「Fat」より「Colocated（関連するものを近くに置く）」という考え方が近いです。

  • 機能単位でディレクトリをまとめる（Feature-based構成）
  • 1ファイルは200〜400行以内を目安にする
  • 型定義・インターフェースを明示して、AIが推測しなくて済むようにする

素人考えとおっしゃっていましたが、「断片より集約」という発想自体はAIエージェントのRAG設計やコンテキスト管理の議論でも普通に出てくるテーマです。着眼点は良いと思いますよ。

質問2への回答

面白い仮説ですね。整理して考えてみます。

「AI丸投げ前提ならMVC最強説」の検証

あなたの主張の核心

Clean Architecture / DDD
→ 人間が概念を理解して維持するための設計

純粋MVC（Fat Model）
→ AIが処理するなら概念レイヤーは不要なオーバーヘッド

これはかなり筋が通っています。

Clean Architecture / DDDがAIに向かない理由

  • 間接層が多い → UseCase → Repository → DomainService → Entity と追跡するファイルが多く、AIのコンテキストが分散する
  • 命名規則・概念の一貫性維持 → 人間でも難しいことをAIに継続させるのはブレが出やすい
  • 抽象への依存 → Interfaceや依存性逆転はAIが「なぜこうなっているか」を毎回推測しなければならない

純粋MVCがAIに向いている理由

観点 MVC（Fat Model）
ファイル追跡 Model見ればビジネスロジックが全部ある
修正指示 「Userモデルに〇〇を追加して」で完結
依存関係 単純なので壊しにくい
テスト指示 Modelのメソッド単位で明確

ただし、課題になりそうな点

Fat Modelのスケール問題

  • モデルが肥大化した時にAI自身が1ファイルを読みきれなくなる
  • → ただしこれはファイル分割（Concern/Mixin）で対処可能で、設計思想は維持できる

AIへの指示の質に依存する

  • MVCはシンプルな分、「どのModelに何を書くか」の判断をAIに委ねやすい
  • 指示が曖昧だと見当違いな場所に書かれるリスクも

個人的な見解

あなたの仮説は短〜中規模プロジェクトにおいては正しいと思います。

さらに言うと、AI丸投げ前提なら設計の目的が変わります。

従来: 人間が保守しやすい設計
AI時代: AIが1プロンプトで意図を掴める設計

「人間にとっての可読性」と「AIにとっての可読性」は必ずしも一致しないというのは、今後真剣に議論されるべきテーマだと思います。あなたはその議論の入り口に立っています。

Grok

質問1への回答

ユーザーの考え、面白い視点だと思うよ。AI（特にLLMベースのコード生成ツール、例えばGitHub CopilotやClaude、Grokみたいなもの）がプログラムを読み込んで自動生成や修正をする場合、確かにコードの構造がAIの効率や精度に影響を与える可能性はある。君の言う「Fat Model」や「Fat Controller」（MVCアーキテクチャの文脈で、ビジネスロジックを一箇所に集中させるスタイル）が、断片化されたコードより扱いやすいんじゃないか、という仮説について、素人考えじゃなく結構理にかなってる部分があるよ。以下で少し深掘りして説明するね。

基本的な背景: Fat Model vs. Fat Controllerとは?

  • Fat Model / Thin Controller: ビジネスロジック（データ処理、検証、計算など）をModel層にまとめて、Controllerは主にリクエストのルーティングやViewへの橋渡しだけにする。Railsみたいなフレームワークで推奨されることが多い。
  • Fat Controller / Thin Model: 逆に、Controllerにロジックを詰め込んで、Modelはデータストレージだけに留める。古いPHPアプリとかでよく見るパターン。
  • 一般論として、Fat Modelの方が保守性が高く、テストしやすいと言われるけど、君のクエリはAIの視点からだから、そこにフォーカスする。

AIのコード生成/保守でなぜ「まとまったコード」が有利か?

君の指摘通り、AIの多くはTransformerベースで、入力トークン（テキストの断片）の制限がある（例: GPT-4のコンテキストウィンドウは数万トークンだけど、長いコードベースだとすぐオーバーする）。断片的なコード（モジュール化しすぎてファイルが散らばってる場合）を扱うと、AIは以下のような問題を抱えやすい：

  • コンテキストの散逸: 関連するロジックが別ファイルに分かれていると、AIはそれらを「繋ぎ合わせて」理解する必要がある。人間ならIDEでジャンプできるけど、AIは一度のプロンプトで全部を読み込まないと、誤った推論をしやすい。例えば、ModelのメソッドをControllerから呼び出すコードを生成する時、Modelの定義が遠くにあると、AIが「忘れて」バグったコードを吐くリスクが増す。
  • トークン効率: まとまったコード（Fatな層）なら、少ないトークンで全体像を把握できる。君の言う通り、1つのファイルやブロックにロジックが凝縮されてると、プロンプトのサイズが小さくなって、AIの応答精度が上がる傾向がある。実際、AIツールのベンチマーク（例: HumanEvalみたいなコード生成テスト）では、シンプルで自己完結型のコードの方が高いスコアが出やすい。
  • 生成精度の向上: AIはパターン認識が得意だから、Fatスタイルだと「このブロック全体がビジネスルールだ」と一気に学習できる。断片化されると、AIが「推測」で繋げる羽目になり、エラー率が上がる。保守（リファクタリングやバグ修正）でも同じで、AIに「このコードを最適化して」と投げると、まとまってる方が正確な提案が出る。

実際の事例やトレンド

  • AIツールの推奨パターン: CopilotやCursorみたいなツールのドキュメントを見ると、モジュール化は大事だけど「過度な分割は避けろ」みたいなアドバイスがある。なぜなら、AIはファイルツリー全体をスキャンするけど、コンテキストが限界を超えるとパフォーマンスが落ちるから。Fat Modelは、AIがModelを「ブラックボックス」として扱いやすい。
  • 潜在的なデメリット: ただ、Fatすぎると人間の可読性が落ちるし、AIも巨大なファイル1つを扱うとトークンオーバーで混乱するかも。バランスが大事で、最近のトレンドは「Bounded Context」（DDDの概念）みたいに、関連ロジックを適度にまとめるハイブリッドアプローチ。
  • 実験的な証拠: オープンソースのプロジェクトでAIを使ってリファクタリングした例（GitHubのissueとか）を見ると、Fat ControllerからFat Modelに移行すると、AIの修正提案が正確になった報告がある。トークンサイズの観点では、プロンプトエンジニアリングのベストプラクティスで「関連コードをまとめて提供せよ」とよく言われるよ。

結論: 君の仮説は当たってる可能性大

素人考えじゃなく、AIの仕組み（トークン制限と注意力の限界）を考えると、Fat Model（特に）の方がAIフレンドリーだと思う。生成精度は上がるし、保守も楽になるかも。将来的にAIがもっと賢くなれば（コンテキストウィンドウが無限級に）、モジュール化の利点が勝つかもしれないけど、今の段階ではまとまったコードが有利。もし具体的なコード例で試してみたいなら、教えてくれよ—Grokでシミュレーションできるかも。

質問2への回答

人間が一切コードを触らない、完全にAI丸投げ前提で考えると、君の意見はかなり現実的で、今のLLMの限界を考えると純粋MVC（特にFat Model寄り）の方が現時点では効率が良いケースが非常に多いと思います。

クリーンアーキテクチャやDDD、ヘキサゴナル、レイヤードアーキテクチャなどが推奨される理由は主に人間のチーム開発を前提にしているからです。

  • 変更の局所性
  • テストのしやすさ
  • 依存方向の制御（フレームワークやDBがドメインを汚さない）
  • 長期メンテナンス性
  • 大人数・長期間のプロジェクトでの認知負荷軽減

でもこれらは全部「人間がコードを読む・書く・修正する」ことを第一に最適化された設計です。AI丸投げの世界では優先順位がかなり変わります。

AI丸投げで有利なポイント（純粋MVC寄り）

  1. コンテキストウィンドウの節約が圧倒的に効く
    今のLLM（2026年時点でも）はまだコンテキストが有限で、長いと注意力が散漫になる（needle-in-haystack性能が落ちる）。

    • クリーンアーキテクチャだと1つのユースケース変更で最低でも5〜10ファイル（Entity, ValueObject, Repository Interface, Repository Impl, UseCase, Input/Output DTO, Controller Adapterなど）を跨ぐことが普通。
      → AIに「この機能修正して」と言った時、関連ファイルを全部コンテキストに入れないと正確に動かない。
      → 純粋MVC + Fat Modelなら、関連ロジックがModelクラス1〜2個 + Controller 1個にほぼ収まるケースが多い → プロンプトトークン数が1/3〜1/5くらいで済む。

  2. 修正・生成時の認知負荷がAIにとって低い
    AIは「このロジックはどこにある？」という探索が苦手（特にファイルが散らばっていると）。
    Fat Modelだと「ビジネスロジックは全部このUserモデルの中だ」と一目で分かるので、

    • バグ修正提案が正確になりやすい
    • リファクタリング指示を出した時に破壊が少ない
    • 新機能追加時のコード生成が一貫性を持ちやすい

  3. 人間が読まないなら「過剰な抽象化」のデメリットがほぼゼロ

    • インターフェースの多さ、UseCaseクラスの細分化、依存注入の複雑さ → 人間には価値があるが、AIにはほぼ無意味（むしろ邪魔）。
    • DDDの集約ルートや境界付けられたコンテキストの恩恵も、AIが一発で全体を把握できる規模なら薄い。

でも、完全に「純粋MVCでOK」とは言えない落とし穴

  • モデルが本当にFatになりすぎると（1ファイルが5000行超とか）
    → 今度は逆にコンテキスト内でAIが混乱する。
    → 適度なFat（1モデル200〜800行くらい）が今のスイートスポットかも。

  • ドメインが非常に複雑（金融、医療、複雑なルールエンジンなど）
    → ここは逆にDDD的な境界付けがAIの誤生成を防ぐ可能性もある。
    → ただしAI丸投げなら「ドメインを自然言語で正確に説明する」方が大事で、アーキテクチャで無理やり分離するより、Modelにコメントやドキュメントを厚く埋め込む方が効くかも。

  • 将来的なトレンド（2026年現在でも兆候あり）
    コンテキストが100万〜1000万トークン級になってくると、クリーンアーキテクチャのファイル散らばり問題はかなり緩和される。
    でも現実はまだ「コンテキストが足りない or 長すぎると性能落ちる」のトレードオフが強いので、今はシンプルMVC + 適度にFat ModelがAIフレンドリーNo.1候補だと思います。

結論（2026年現在の感覚）

  • 人間が触る可能性がゼロ → 純粋MVC（Fat Model寄り）が最も効率が良い確率が高い
  • ロジックの分離はModelの振る舞い（メソッド・サービスクラス少し）で十分 → これも同意
  • クリーン/DDDはオーバーエンジニアリングになりやすい（特に中小規模アプリ）

要するに「AIが主役の時代のアーキテクチャ最適解は、人間が主役だった時代の最適解とはかなりズレる」という話で、君の直感は今のところ正しい方向を向いていると思います。

もし具体的なドメイン（例: ECサイト、SaaS管理画面、ゲームロジックなど）を教えてくれたら、もう少し踏み込んで「この場合はMVCでどこまでFatにしてもいいか」みたいな話もできますよ。

脚注

  1. 2026年2月28日現在 ↩︎

Discussion