AI時代には、フル装備のフレームワークが大活躍するのではないか

はい、どうもこんにちは佐藤です！

最近、小さな案件で Django を提案する機会が何度かありました。バイブコーディング前提のプロジェクトでも Django を推したのですが、どちらも「うまくいった」という連絡をいただいたんです。

正直、これは少し意外でした。**Django や Laravel のような、サーバーもクライアントも同じ、ORM も認証も全部入りの「フル装備フレームワーク」**って、最近はあまり主流じゃない空気がありますよね？

API とフロントエンドを分離するのが当たり前になって、フル装備フレームワークは一世代前の選択肢、という印象を持っている方も多いと思います。

でも、AI がコードを書く時代になったいま、フル装備フレームワークがむしろ大活躍するのではないかと思っています。

その理由を書いていきますね！

Laravel には、正直良い思い出がなかった

まず、白状します。私は Laravel にあまり良い印象を持っていませんでした。

現場で見てきた Laravel のプロジェクトは、情報システム部の「ちょっとだけIT ができる子たち」が作ったようなものが多かったんです。ルールに従わず、好き勝手に作られている印象がありました。

具体的に言うと、View の <script> タグの中に、Blade の記法で PHP の値がそのまま埋め込まれているようなコードを何度も見てきました。フロントの JS を読んでいるつもりが、いつのまにか PHP のロジックを追わされているような感覚です。解読が本当に大変でした。

大した処理でもないのに、いきなりストアドプロシージャを呼んでロジックを動かしているプログラムも見てきました。ビジネスロジックが、コントローラーでもモデルでもなく、ビューや DB の中に散らばっている状態です。

こういう作りを何度も見てきたので、私はフル装備フレームワークに苦手意識を持つようになっていました。

でも、AI が書くようになると話が変わる

ただ、AI がコードを書くようになってから、この感覚が変わりつつあります。

なぜかというと、AI はフレームワークに対応した「お作法」に、人間よりずっと忠実に従ってくれる可能性が高いからです。

人間のエンジニアは、締め切りに追われたり、そのときの気分で「ちょっとくらいいいか」と型を破ります。View に直接ロジックを書いてしまうのも、多くはそういう妥協の積み重ねです。

AI はそこで妥協しません。学習したベストプラクティスの通りに、モデルはモデルらしく、コントローラーはコントローラーらしく書いてくれます。属人的な「その人の書き方」が入り込みにくいのです。

実際、Django で提案した案件がうまくいったのも、AI が Django の型に素直に従ってコードを生成してくれたからだと感じています。フル装備フレームワークの「型がしっかりしている」という特徴は、AI 時代にこそ活きるのではないでしょうか。

どこまでなら活躍するのか、線を引く

もちろん、なんでもフル装備フレームワークが正解というわけではありません。ここで線引きが必要です。

私は、次の 2 点をクリアするプロジェクトなら、フル装備フレームワークが強いと思っています。

サーバーとクライアントを分離する必要がない（複雑なフロントエンドを実装しなくていい）
アグリゲートを使う必要がない

1 つ目から見ていきます。複雑なフロントエンドが要らないなら、サーバー側のテンプレートで画面を返すだけで十分です。ここで無理にサーバー・クライアントを分離すると、逆に複雑さが増えます。

問題は、分離が必要なプロジェクトで、フル装備フレームワークのテンプレートを無理に使ってしまうことです。複雑な画面遷移や状態管理を Blade のようなテンプレートエンジンでやろうとすると、<script> の中に PHP を埋め込むような、あの読みにくい構造になりがちです。実はこれ、Laravel だけの話ではありません。Spring Boot の Thymeleaf でも、同じ問題に当たったことがあります。テンプレートにロジックを書き込める作りのフレームワーク全般で起きる話なんですよね。

アグリゲートが必要になったら、話は別

2 つ目のアグリゲートについても補足します。

以前、アグリゲートは 20 年前のカプセル化だったという記事で書いたのですが、アクティブレコードは原則ひとつのエンティティにしか対応できず、複数のエンティティをまとめて整合を守るアグリゲートには向いていません。

ここで正直に言っておきたいのですが、これは Laravel の Eloquent に限った話ではないんです。Django の ORM も、実はアクティブレコードパターンです。承認フローのような状態遷移を扱うシステムで、整合を塊として守りたくなったら、Django であっても Laravel であっても、同じように苦しくなります。

つまり、線引きの 2 つ目は「Laravel が弱い」ではなく、「アクティブレコード系のフル装備フレームワーク全般が、アグリゲートが要る場面では苦しい」というのが正確な言い方になります。ここを混同すると、Django に乗り換えれば解決するように見えてしまいますが、そうではありません。

まとめると、こういう線引きになる

整理すると、こうなります。

サーバー・クライアント分離が要らず、アグリゲートも要らない → フル装備フレームワークが強い
サーバー・クライアント分離が要る → テンプレートにロジックを埋め込む沼にはまりやすい
アグリゲートが要る → アクティブレコード系フレームワーク全般が苦しくなる

この 2 つの条件をクリアできる、比較的シンプルな業務システムは、意外と多いのではないでしょうか。そこにわざわざ API とフロントエンドを分離した構成を持ってくるのは、オーバーエンジニアリングかもしれません。

というわけで、AI 時代にはフル装備フレームワークが大活躍するのではないか、って話でした！

サーバー・クライアント分離が要らず、アグリゲートも要らない。そういうシンプルな要件なら、Django や Laravel のようなフル装備フレームワークを、もう一度見直してみる価値があります。

AI が型に忠実に書いてくれる時代だからこそ、昔敬遠していた選択肢が、実は最適解だったりするものです。ぜひみなさんも、フル装備フレームワークを見直してみてください！