「三層構造はもう古い」は本当か。AI時代におけるバックエンドシステムのアーキテクチャ

はじめに

生成AIの普及により爆速なコード生成が可能になった一方で、現代のバックエンド開発は「AI時代のアーキテクチャはどうあるべきか」という激しい迷走の中にあります。

AIが人間の代わりに高精度なコードを書けるようになったことで、「どこまでをAIに任せ、どこを人間が守るべきか」という開発の境界線そのものが揺らいでいるからです。従来の「正解」とされてきた設計パターンがそのまま通用するのか、あるいはAIに合わせて変革すべきなのか。AIの利用領域の拡大や今後のシステム保守までを見据えたとき、これらの疑問や懸念は「いつか直面する未来」ではなく、まさに「今日考えるべき現実」となりました。

本連載では、この現代的な悩みに対して筆者が考える、AI時代においてバックエンドに求められる「変わらない価値」と「変わる価値」について解き明かしていきます。

具体的には、AIによって加速する「垂直分割」の合理性とそれが迎える限界を整理した上で、人間とAIがスムーズに分業するための「新・三層構造」を定義します。さらに、AI時代におけるマイクロサービスやデータ主権のあり方、そして最終的にはアーキテクトに求められる「言語表現能力」に至るまで、順を追って議論を深めていきます。

アーキテクチャに蔓延する「水平」と「垂直」の悩み

システム開発の歴史において幾度となく繰り返されてきた「水平か、垂直か」という構造の対立がありますが、AIという新たなテクノロジーの登場は、この根深い議論を再び現場の最前線へと押し出すことになりました。

システムにおける「水平」と「垂直」とは？

「三層構造（レイヤード）はもう古い」「AIには垂直分割の方が圧倒的に相性がいい」──モダンなWeb開発の現場から、このような声が急速に聞こえるようになってきました。

しかし、そもそも「水平」と「垂直」という言葉は抽象的で、現場や立場によって議論しているレイヤーがバラバラになりがちです。そこで本題に入る前に、まずは開発現場における「水平」と「垂直」の全体像を、筆者なりに整理すると、少なくとも以下の3つの視点（レベル）に分けて捉えることができると考えています。

• コード・フォルダ構成：レイヤードアーキテクチャ vs 機能別パッケージ
• リポジトリ構成：マルチリポジトリ vs モノリシックな垂直統合
• システム構成：マイクロサービス分割 vs モノリス

このように整理した上で改めて図を眺めてみると、興味深い事実に気づかされます。

垂直構造は、コード・リポジトリ・システムのどのレベルにおいても、「特定のドメイン」という単一の軸で閉じているため、構造や目的が一目で理解できます。上から下まで文脈（コンテキスト）が切れずに管理することが容易になります。

一方で水平構造になると、レベルごとに切り分ける「目的」そのものが変化するため、常にそれを意識する必要があります。同じ「水平」という言葉を使っていても、コードレベルの話（技術関心）をしているのか、リポジトリの話（チーム職掌）をしているのか、システムレベルの話（データ共通化）をしているのかという目的意識をチーム全体で共有できていないと、目の前のタスクを実行する際にも「どこに何を実装すべきか」で迷走が生じてしまうのです。

フォルダ構造から見る「水平」と「垂直」

言葉だけではイメージしづらいため、ここで具体的なディレクトリ構成の例を見てみましょう。例えば「ユーザー管理（Users）」と「注文管理（Orders）」という2つの機能を実装する場合、水平構造では以下のようになります。

水平管理でのコード例

src/
├── controllers/
│   ├── UserController.ts
│   └── OrderController.ts
├── services/
│   ├── UserService.ts
│   └── OrderService.ts
└── repositories/
    ├── UserRepository.ts
    └── OrderRepository.ts

この構造の場合、ユーザー機能を一部変更する場合、controllers/、services/、repositories/ といったフォルダを行き来しながらファイルを見ていく必要があります。

一方、垂直構造では先ほどのコードは以下のような構造になります。

垂直管理でのコード例

src/
├── users/
│   ├── UserController.ts
│   ├── UserService.ts
│   └── UserRepository.ts
└── orders/
    ├── OrderController.ts
    ├── OrderService.ts
    └── OrderRepository.ts

この場合、ユーザー機能に関する変更はすべてusers/フォルダで完結します。

特に画面機能では、データ構造の責務も画面内に閉じやすいため、機能単位で垂直にコードを書き進めるスタイルはメリットを感じやすいはずです。

システム全体・管理全般（ガバナンス）への波及

この「水平と垂直」という設計思想の選択は、開発が進みプロジェクトの規模が拡大するにつれ、手元のコードレベルにとどまらず、システム境界や組織設計といったより大きな管理構造（ガバナンス）へと必然的に波及していきます。

垂直構造のまま管理範囲をスケールさせることができれば、上から下までコンテキスト（文脈）を途切れさせずに保持できます。「AIは前提となる管理情報やコンテキストが増えれば増えるほど精度が上がる」という考えに基づけば、すべてを1つの垂直構造に閉じ込めるアプローチは極めて魅力的に映ります。

しかし、現実にはコンテキストの肥大化に伴うコストの増大や、トークン上限による情報の欠落、さらにはハルシネーションの発生といった技術的・経済的な課題が立ちはだかります。単に「何でもかんでもデータを詰め込んだ巨大な垂直構造」をつくることは、決して現実的な解とは言えないのです。

実際、この無制限な垂直分割の懸念は現実のものとなっています。プロジェクトごとに境界を引き、AIに指示を出して垂直に閉じられたコードやリポジトリを爆速で量産させていった結果、気づけば境界のあちこちに似て非なるデータベースクエリや重複したドメインロジックが乱立し、全体最適を失ったデータの不整合や管理不能なスパゲッティコードの闇が新たに生まれてしまっている現場も実際に出てきているからです。

また、AIの素晴らしさを耳にする一方で、自社ではAI導入すらできていないにもかかわらず、他社ではすでにAIの弊害がでてしまっています。この状況を知れば知るほど、手元のフォルダ設計からシステム境界に至るまで、AIがもたらす無制限な垂直分割の波にどう向き合うべきか、多くの開発現場やリーダーが今まさに頭を抱えてしまう現実があります。

組織運営が明かす「スピードの垂直」と「ガバナンスの水平」

実は、システム構造の対立は、経営や組織の現場で古くから議論されてきたテーマと酷似しています。

組織（集団）は「垂直」で生まれ、「水平」へ移行する

具体的には、「単一事業／事業部制（垂直型）」と「職能部制（水平型）」のトレードオフの議論です。

• 組織の垂直型（単一事業/事業部型）：特定の事業や目的ごとに、必要な機能をすべて完結して配置する構造。全員が上から下まで同じ文脈（コンテキスト）を共有して動くため、すばやい意思決定が可能な反面、重複や無秩序化が起きやすく全体最適が効きにくくなる。
• 組織の水平型（職能部型）：「つくる専門の人（開発）」「売る専門の人（営業）」「お金を管理する専門の人（財務）」といった機能ごとに組織を横切る構造。リソースの集約や技術・ナレッジの統一、ガバナンスが利く一方で、「つくる人」と「売る人」の間のコミュニケーションコストが増大し、事業全体の変化スピードが鈍化しやすい。

身近な例で考えてみましょう。子供同士でサッカーなどをするとき、最初からフォーメーションをきれいに組み、明確なポジションがつくれるでしょうか。最初はポジションなんて関係なく、全員でボールを追いかけます。

組織の原点もこれと全く同じです。創業期や新規事業の現場では、役割の境界線なく全員でプロダクトや顧客に密着し、成果を追う「垂直なスピード感」からスタートします。目的が明確で、全員が同じ立場だからこそ、すばやい立ち上げが実現できるのです。

しかし、チームが成熟していく過程で、相手に勝つための戦略として目標が細分化されます。「とにかく点を入れる」という単一の目的から、「守備を固める」「中盤でボールを拾う」といった役割ごとの目標へと分解され、ここで初めて「フォーメーション（水平な構造）」ができあがります。

本連載において筆者が提示したい「垂直」と「水平」の定義は、単なる組織図やフォルダの形の話でもなく、雰囲気でつくられる役割分担でもありません。「明確な境界線（インターフェース）がどこに存在するかどうか」という運用の本質にあります。

システム開発における「目的別の垂直分割」と「レイヤー別の水平分割」のトレードオフは、この2つの構造が抱えるメリット・デメリットの構図と驚くほど一致しています。

そして、どんな組織も最初は「垂直なスピード」を選択して立ち上がり、無秩序化という限界に達して初めて「水平なガバナンス」を選択します。ソフトウェア開発における「機能別の垂直分割」と「三層構造などの水平分割」の関係もこの流れと重なります。

システム設計への適用：組織構造が示す「型」とAIの共存

組織の道理が教える本質は、「垂直のスピード」と「水平のガバナンス」は対立するものではなく、強固な水平（型）という安全網があるからこそ、現場（垂直）がリスクを恐れず最速で挑戦できるという点です。

上の図も一見すると「目的別（垂直）」の方が目的に向かって一直線に進みそうに思えます。しかし、明確な境界線がない垂直構造では、現場の判断で柔軟に試行錯誤できる反面、やり方やデータ構造がチームごとにブレやすく、無秩序化しやすい側面があります（この垂直構造が抱える脆さと対応方法については、次回解説します）。

これは現代のシステム設計やAI活用にもそのまま当てはまります。認証や決済、セキュリティといった共通基盤（水平）が整っていれば、現場は車輪の再発明に時間を取られず、最小コストで新しい機能開発（垂直）に集中できます。

AI時代においても、「AIだから手元で完結する垂直分割だ」と極端に振り切るのではなく、強固な水平基盤（型）の上でAIを活用してこそ、スピードと品質の両立が実現するのです。

AI時代における「水平な基盤」の真価

これをAI時代のバックエンド開発に置き換えてみましょう。 水平管理によって共通基盤やテンプレート（型）が整っている状態とは、AIに対して「迷わせない・標準化されたコンテキスト（前提知識）」を提示しやすい環境を意味します。

例えば、AというプロジェクトとBというプロジェクトで水平な構造が共通化されていれば、Aで成功したAIの学習環境やプロンプト構成、コード生成ルールをそのままBにも横展開できます。 このように強固な水平基盤が存在して初めて、AIによる垂直なコード生成のスピードと自由度、そして高い品質が両立するのです。

なぜ「垂直」はAIによって正当な市民権を得たのか

ここまで読めば、結局のところ、適材適所を実行すればいいという話になってしまいます。しかし、この抽象的な話をどうやって現場の管理に落とし込めばいいのだろうかと思うはずです。そこで、経営レベルでの垂直、水平ではなく再度エンジニア目線に話を戻しましょう。

フレームワークの役割とは？

そもそも、なぜこれまでのソフトウェア開発において、「プレゼンテーション層／ビジネスロジック層／データアクセス層」のような三層構造をはじめとする「水平」なフレームワークが市民権を得てきたのでしょうか。大きな組織でもなく、また、スタートアップでのチャレンジングなプロジェクトでもフレームワークは積極的に使われてきました。

ここまでの話からすれば、小規模なプロジェクトでは水平分割など過剰なオーバーヘッド（過剰設計）であり、できるだけ少ないファイルに処理をまとめて書く垂直的なアプローチで十分だったはずです。

それにもかかわらず、業界全体がかたくなにフレームワーク（水平構造）を守ってきた背景には、技術的な合理性はもちろんのこと、開発組織やエコシステム全体として見ても、以下のような大きな利点・側面があったからだと考えられます。

1. リスクの回避：何らかの技術的瑕疵にぶつかっても誰かが助けてくれるというリスク回避の恩恵を普及しているフレームワークを使うことで得られます。
2. 品質の向上：みんなが使っているため、フレームワーク部分の品質が保たれていることもそうですが、それ以外にテストの手法、安全ガードなどの機能を利用することで品質が保たれます。
3. 知識の共有：フレームワーク自体の使い方から、それらを取り巻くコミュニティがもつ文化背景などフレームワークのソフトウェア以外の資産が多く得られます。

実はこれらの利点は、先ほどの「水平型組織」の利点と変わらないと気づくでしょう。つまり私たちは、たとえ少ない人数のプロジェクトであっても、フレームワークを使うことで「この水平組織がつくるメリットを外部から受ける」という方を選んでいたと言えるわけです。

さらに言えば、個人のスキルセットや採用市場における「共通指標」として機能してきた側面も無視できない要素でしょう。「流行りのフレームワークを採用しているか（世間で通用する経験と知識を持っているか）」はエンジニアの採用やモチベーション、評価基準に直結しており、人間を組織で管理・育成する上での強力なインセンティブとして機能しています。

AIにより「垂直」でもよいとされるわけ

では、なぜAIの普及によって「垂直」が許され、市民権を得るようになったのでしょうか。垂直構造を選んだことで、私たちはこれまでのフレームワークが提供してくれていた「リスク・品質・知識の共有」を捨ててしまっていいと思っているということでしょうか。答えは「ノー」です。捨てたのではなく、「AIがその役割（共有インフラ）を肩代わりしてくれるようになったから」です。

1. リスクの回避：問題にぶつかって詰まったときに検索やコミュニティで探さずとも、AIがその場でデバッグや代替案の提示を行ってくれます。
2. 品質の向上：厳格なフレームワークの型にはめなくても、AIに指示を出すことで一定水準のコードやバリデーションが一瞬で生成され、また簡単な人的ミスの介入を考慮しなくてよくなるので厳密さの重要性が下がります。
3. 知識の共有：フレームワーク特有のお作法（ドキュメント）を人間が学習しなくても、LLMのモデル内知識やリポジトリ内の文脈から、AIが意図を直接汲み取って書き上げてくれます。

もちろん、現時点でこれらがAIにより完全に代替されているとは言えない部分もあります。しかし、ハルシネーションのような品質面の課題についても、現在ではループエンジニアリングなどを通じて、現在進行形で改善が進んでいます。

つまり、人間が我慢して従っていた「水平なガードレール（共通言語）」をAIが補完してくれるため、エンジニアは手元の垂直構造へ踏み出せるようになったのです。また、「土台に既存フレームワークがある」という安心感がその暴走を心理的に支えている側面もあります。

最後に

AIが垂直構造によって開発スピードを加速させてくれる一方で、無原則な垂直化の先には、システム全体の整合性が失われる「システムの崩壊」が待ち受けています。

次回は、AIのスピードを活かしながら全体の堅牢性を保つため、人間とAIの主権を明確に分ける筆者独自の設計指針「新・三層構造」と、AIとの具体的な分業設計について解説します。