AI コード生成時代のフレームワークとの付き合い方 ── 「省力」から「制約」へ
最終更新日:2026/08/08 公開日:2026/07/06
はじめに ── これは「弊社の立ち位置」としての記事です
この記事は、AIコード生成時代のフレームワークとの付き合い方と銘打っていますので、最初に記事の前提条件を共有します。
この記事ではフレームワークの使い方をやや否定するように見える表現がありますが、フレームワークを否定する意図は一切ありません。 「使えるものは使うべきだ」と考えていますし、この記事の結論はむしろ「フレームワークを使え」に近いものです。
そのうえで強調しておきたいのは、これは弊社の案件の性質を前提にした立ち位置の話だということです。具体的には、小〜中規模で、CRUD が要件の中心で、ビジネス要件に応じた独自の UI 実装が一定の頻度で求められる受託案件を念頭に置いています。 また、今回は管理機能の話をするため、それ以外のフレームワークについては直接的に言及はしません（ただし、考え方としては同様になると思います）。
逆に、要件が完全に定型に収まり、既製品の枠とそのまま一致するのであれば、Backpack for Laravel や WordPress のようなプロダクトのフルセットがそのまま価値を発揮できるはずです。
その上で、本記事では AI でコードがいくらでも書けるようになった今、フレームワークに何を求めるべきか を論じます。 具体的には、管理機能を Backpack for Laravel のような高機能パッケージに乗せて作るべきか、それとも素の Laravel に薄い自前の規約を足した「Laravel + α」で作るか、という選択を通して、それを考えていきます。
発端は「UI をある程度合わせる」という、ごく普通の要求でした
きっかけは、管理機能の作り方を変えざるを得なくなったことでした。それまで管理画面には Laravel Admin を使っていたのですが、これが使えなくなり、代替として Backpack for Laravel を採用しました（この経緯は過去の記事も参照ください）。
採用を決めたため、実際に Backpack for Laravel を使って案件を開始しました。 その案件はリニューアル案件であり、元々の管理機能・画面は特にライブラリやフレームワークを使わず、フルスクラッチで書かれていました。 また、当然の要件として、リニューアル後も既存の管理画面の UI をある程度これまでの形に合わせる必要がありました。
この「ごく普通の要求」に、Backpack では非常に苦労しました。Backpack には Backpack の哲学に沿った UI の枠があり、そこから外れた見た目や挙動に合わせようとすると、内部を読み解き、どうすれば良いかを調査し、テンプレートを上書きし……という作業が続きます。本来なら一番楽ができるはずの「管理画面の UI」のところで、かなり消耗したわけです。
そこで次の案件では Backpack をやめ、Laravel + α （※AIの活用あり）で管理機能を組んでみました。すると、これが新規作成・リニューアルのどちらでもうまくいきました。なぜうまくいったのか。それを掘り下げると、フレームワークに求めるものが変わったことが見えてきました。
AI で変わるコスト・変わらないコスト
フレームワークやパッケージには「ここから外れた要求は対応が難しい」という枠が必ずあります。その枠外に出るには、内部を読み解き、フックを探し、設定をひねり、テンプレートを上書きする ── こうした、フレームワークが本来想定していない方法で無理に要求を通す実装を、この記事ではハックと呼びます。ハックは今も昔も、それなりのコストがかかる作業です。
ではなぜ、そのコストを払ってまでフレームワークに乗ってきたのか。理由の一つは、総コード量でした。一部の例外をハックで押し通してでも、大半を既製品に任せてしまえば、自分で書くコードは少なく済み、早く作れる。「ごく一部の例外のためにハックする痛み」より「全体を手書きする手間」の方がずっと大きかったからこそ、ハックしてでも既製品に寄せる判断が合理的だったのです。
ところが AI は、この損得の前提を崩します。標準的な機能であれば、AI は標準的なコードを自動生成してくれます。「既製品に乗らなければ大量のコードを手書きする羽目になる」という、省力化を目的にフレームワークを採用するという最大の動機そのものが弱まったのです。手書きのコストが下がった以上、その回避のためにハックを受け入れる、という取引はもう割に合わなくなって来ています。
ハックの階層構造
ここで、ひとくちに「ハック」と言っても実際には階層があることを示しておく必要があります。
枠外への対応は、フレームワークからの距離でいくつかの段階に分かれます。
- フレームワークが用意した拡張点（設定、フックポイント、公式に許されたビューやテンプレートの差し替え）を使う。Laravel 系なら resources/views/vendor 以下にファイルを置いてビューを上書きするのも、公式の仕組みなのでここに入ります
- フレームワークが素直に対応してくれないため、既存の共通の仕組みに個別の事情を無理に持ち込み始める。たとえば、共通のテンプレートに「特定のページから読まれたときだけ」といった条件分岐を埋め込む、といった実装です。内部にはまだ踏み込んでいませんが、コードに歪みが出はじめます
- vendor で提供されるクラスを継承して自前の拡張点を作ったり、内部実装まで踏み込んで上書き・パッチしたりする
- 「フレームワークでは実現できない」と見切って、その部分だけフレームワークの外で実装する
厄介なのは、AI はこの 4 段階のどこでも書けてしまうことです。AI がコードを読み、拡張点では足りないと判断し、内部を上書きし、あるいはフレームワーク外で実装して、動かす ── ここまでやれてしまう。「AI が書けるか」では、浅いハックと深いハックの区別がつかないのです。区別をつけるのは、それが制約からどれだけ離れているか、のほうです。
各段階で失われるものを、対応づけて整理しておきます。
段階 1 は問題ありません。 フレームワークが想定した素直な拡張であって、統一感も安定性もほとんど損なわれません。
段階 2〜3 で失われるのは、安定性です。 ここまで踏み込んだ実装は、その場では動いても フレームワークの制約の外にあり、不安定な状態です。動いてはいるけれど、その挙動を支えているのは「たまたま今のバージョンで通っている上書き」であって、フレームワークが保証してくれる構造ではありません。
ここで、当然の反論が出るはずです。「バージョンアップで壊れたら、また AI に直させればいい。保守のコストも AI が溶かすのではないか」と。 実際、直すだけであればその通りです。
しかし、本当の問題はそこではありません。壊れたことに気づけるか、そして壊れるタイミングを選べるか、の方が重要です。 段階 2〜3 のハックは、フレームワークの保証の外で動いているため、バージョンアップなどでサイレントに壊れることがあります。エラーで止まってくれるならまだ良いほうで、「一見動いているが挙動が微妙に変わっている」形で壊れることも珍しくありません。AI に直させるには、まず「壊れている」ことを検知しなければならず、その検知は都合のいいタイミングで行えるとは限りません。
段階 4 では、それに加えて統一感が失われます。 フレームワークを使わない UI を枠外に足した瞬間、そのフレームワークで作った成果物（管理画面）の統一感が崩れます。Backpack を使う理由は、統一された UI と作法を安く手に入れることでした。その枠を外れて自前で実装すれば、画面ごとに見た目も作法もばらつき、Backpack を使っている意味そのものが弱まります。
ここで問題の輪郭がはっきりします。リニューアルで「UI を既存に合わせる」ような要求は、Backpack の素直な拡張点（段階 1）では収まりきらず、段階 2 の歪んだ実装や、しばしば段階 3・4 まで踏み込むことを強います。枠外要求が頻繁に段階 2 以降を強いるなら、そのフレームワークはもはや制約として機能しておらず、選択があまり良くなかった、ということになります。
フレームワークの価値は「省力」から「制約」へ
ここまでの話を並べると、一つの非対称が見えてきます。AI が溶かしてくれるのは「その場のコスト」── 手間、枠外対応、ハックの実装 ── だけであり、「その場」を超えたコスト ── サイレントに壊れ得る不安定さと、統一感の喪失 ── は溶かしてくれない、ということです。
この非対称から結論が出ます。AI が局所的に何でも書けてしまう時代だからこそ、フレームワークに求める価値は「省力」ではなく「制約」に移る、ということです。
フレームワークの本質的な価値は、コードを書く手間を減らすことだと思われがちです。しかし、その手間は AI の利用で肩代わりできるようになりました。今も変わらずに残っているのは、成果物を制約で縛り、構造・安全・統一を保証するという役割のほうです。
AI は適切な命令を与えれば「その場で動くもの」をいくらでも生成します。だからこそ、その出力を一定の形に収める制約がある方が、成果物がより統一感を持ち、安定します。今の AI が進化するほど、制約の価値は下がるのではなく、上がるのです。
この「制約」という一本の軸で見ると、選択肢がきれいに並びます。
- 生の PHP：制約がゼロ。構造もレイヤー化もセキュリティの定石も、すべて自前です。AI は大量にコードを吐きますが、寄りかかる規約がないので出力は毎回バラバラになり、安全性の抜けが各所に散ります。制約がないので、AI の成果物が無秩序になる。
- Backpack を深い段階までハック：制約はあるが、それを自分で押し破っている状態。素直な拡張点（段階 1）で収まればよいのですが、UI を合わせるような要求はしばしば段階 2 の歪んだ実装や段階 3・4 を強います。そこまで踏み込んだ部分は制約の外にあり、サイレントに壊れ得るうえ、段階 4 では統一感まで崩れます。制約を破ることで、使う意味そのものを弱めてしまう。
- Laravel + α：Laravel という広く知られた制約の内側に、薄い自前の規約を足す。制約を破らずに済む形を、最初から選んでいる。
「Laravel + α」とは、薄い自社フレームワーク化のことです
「フルスクラッチは保守が地獄になる」という定説はもっともですが、ここで言う Laravel + α は、無構造な自由 ── つまり生の PHP ── とは違います。
Laravel という広く知られた共通基盤の上に、薄い自前の規約を敷くことをこう呼んでいます。
実態としては「自社フレームワーク化」に近い。ただし、α に何でも入れるわけではありません。
α を薄く保てる理由
ここが、AI 時代ならではのポイントです。Laravel は、世界中の学習データの中で最も踏み固められた道の一つです。Model / Migration / ルーティング / 認可といった標準の仕組みに沿った要求であれば、AI は集合知に寄りかかって、放っておいても標準的なコードを書いてきます。CRUD のコントローラ実装などはその典型で、規約でがちがちに縛らなくても、Laravel の流儀という重力が AI の出力を勝手に収束させてくれる。逆説的ですが、AI に書かせるからこそ「変にならない」のです。
これは Backpack ハックとの対比で言えば、こうなります。Backpack の内部を上書きするような領域は、学習データの踏み固めが薄い。だから同じ AI に書かせても、出力は収束せず、案件ごと・箇所ごとにバラバラの上書きが生まれます。「広く知られた流儀や制約」は、人間だけでなく AI の出力をも安定させる制約として働く ── これが、制約の価値が AI 時代に上がる、具体的なメカニズムです。
したがって α の中身は、Laravel が標準では決めてくれないことの穴埋めに限定されます。ビジネス上の制約、認可の通し方、共通の UI コンポーネント、画面の型、共通の基底クラス ── その程度です。Laravel が決めてくれることは Laravel と AI に任せる。だから α は薄いままでいられるし、薄いままでいられるからこそ破綻しづらくなります。
属人化についても、同じメカニズムが効きます
「自社フレームワーク化は属人化の温床では」という懸念にも、同じ軸で答えられます。ポイントは「AI がコードを読めるから属人化しない」ではありません。AI はどんなコードでも読めます ── Backpack の深いハックも、生の PHP も。問題は読めるかではなく、どれだけ正確に読めるかです。
AI の分析と修正の精度が特に高いのは、コードが広く知られた規約の上に載っているときです。Laravel + α は、コードベースを「AI が正確に分析できる形」に制約によって保っている、と言い換えられます。担当者が抜けたとき、後任は AI にコードベースを分析させながらキャッチアップできますが、その分析が信頼できるのは足場がよく知られた方式で記述されているためです。 属人化は完全には消えませんが、その残りを AI で吸収しやすい形を保てる ── これも制約の効用の一つです。
ただし、Laravel も既存の自社フレームワーク製のPHPのソースコードも、AI（Claude Code）で実践した限り、「読む」「理解する」ことについては現時点でも非常に強い力を発揮します。 そのため、この点については「コンテキストをより多く消費する（＝AIを多く稼働させられる）」程度の違いで収まって行くのかもしれません。
結論 ── 「書けるか」ではなく「破らずに済む制約か」で選ぶ
AI コード生成時代のフレームワークとの付き合い方を、一言でまとめるとこうなります。
「楽に書けるか（省力）」でフレームワークを選ぶのをやめて、「素直に書けるか（制約）」で選ぶ。
AI によって記述量の多少の差異は、フレームワーク利用の基準にはならなくなりました。 また、フレームワークはその目的を達成するために大小の差異こそあれ制約を持っていますが、利用に際して、これらの制約を破らないフレームワークを選ぶことで、より素直で、長期的に安定するシステムを構築することができます。
管理機能に関して言えば、Backpack の枠を頻繁に破らざるを得ない案件では、その枠は制約として機能していません。だったら最初から、Laravel という広く・薄く・よく知られた制約の上で、それらの制約を破らずに済む薄い規約を敷く ── それが、AI に大量のコードを書かせる前提での、素直な付き合い方だと考えています。
