■ 1. AI時代のバックエンド設計という論点
- 設計の境界線が揺らぐ現状:
- 生成AIによる爆速なコード生成が可能になり、バックエンド開発は「AI時代のアーキテクチャはどうあるべきか」という迷走の中にある
- AIが高精度なコードを書けるため、どこまでAIに任せどこを人間が守るかという境界線そのものが揺らいでいる
- 今日考えるべき現実:
- 従来の「正解」とされた設計パターンが通用するのか、AIに合わせて変革すべきかという疑問は、いつか直面する未来ではなく今日の現実である
- 本連載で扱う射程:
- AIによって加速する垂直分割の合理性とその限界を整理する
- 人間とAIがスムーズに分業するための「新・三層構造」を定義する
- AI時代のマイクロサービスやデータ主権のあり方、アーキテクトに求められる言語表現能力までを順に議論する
■ 2. 水平と垂直の3つのレベル
- 議論が噛み合わない原因:
- 「三層構造はもう古い」「AIには垂直分割の方が相性がいい」という声が現場から急速に聞こえるようになった
- 水平と垂直という言葉は抽象的で、現場や立場によって議論しているレイヤーがバラバラになりがちである
- 整理すべき3視点:
- コード・フォルダ構成: レイヤードアーキテクチャ対機能別パッケージ
- リポジトリ構成: マルチリポジトリ対モノリシックな垂直統合
- システム構成: マイクロサービス分割対モノリス
- 垂直構造の特性:
- どのレベルでも「特定のドメイン」という単一の軸で閉じるため、構造や目的が一目で理解できる
- 上から下まで文脈が切れずに管理できる
- 水平構造の特性:
- レベルごとに切り分ける目的そのものが変化するため、常にその目的を意識する必要がある
- コードレベルは技術関心、リポジトリレベルはチーム職掌、システムレベルはデータ共通化と目的が異なる
- 目的意識をチームで共有できないと、どこに何を実装すべきかで迷走が生じる
■ 3. フォルダ構造による具体例
- 水平管理の構成:
- controllers/、services/、repositories/ の下にUserとOrderのファイルを配置する形になる
- ユーザー機能を一部変更する場合、複数のフォルダを行き来しながらファイルを見る必要がある
- 垂直管理の構成:
- users/、orders/ の下にController、Service、Repositoryをまとめて配置する形になる
- ユーザー機能に関する変更はすべてusers/フォルダで完結する
- 画面機能との相性:
- 画面機能ではデータ構造の責務も画面内に閉じやすく、機能単位で垂直に書き進めるスタイルはメリットを感じやすい
■ 4. 無制限な垂直分割の限界
- ガバナンスへの波及:
- 水平と垂直の選択は、規模拡大に伴いコードレベルにとどまらずシステム境界や組織設計という管理構造へ必然的に波及する
- 垂直に閉じ込める発想の魅力:
- AIは前提となる管理情報やコンテキストが増えるほど精度が上がるという考えに基づけば、すべてを1つの垂直構造に閉じる方法は極めて魅力的に映る
- 現実に立ちはだかる課題:
- コンテキストの肥大化に伴うコスト増大、トークン上限による情報の欠落、ハルシネーションの発生が立ちはだかる
- 何でもデータを詰め込んだ巨大な垂直構造をつくることは現実的な解ではない
- すでに顕在化した弊害:
- AIに指示して垂直に閉じたコードやリポジトリを爆速で量産した結果、似て非なるDBクエリや重複したドメインロジックが乱立する現場が出ている
- 全体最適を失ったデータ不整合や管理不能なスパゲッティコードの闇が新たに生まれている
- 現場が抱える板挟み:
- 自社ではAI導入すらできていない一方、他社ではすでにAIの弊害が出ているという状況に多くの開発現場やリーダーが頭を抱えている
■ 5. 組織論に見る垂直と水平
- 構造の対立は組織論と酷似する:
- システム構造の対立は、単一事業／事業部制（垂直型）と職能部制（水平型）のトレードオフとして経営や組織の現場で古くから議論されてきた
- 組織の垂直型:
- 特定の事業や目的ごとに必要な機能をすべて完結して配置する構造である
- 全員が同じ文脈を共有して動くためすばやい意思決定が可能である
- 重複や無秩序化が起きやすく全体最適が効きにくい
- 組織の水平型:
- 開発、営業、財務といった機能ごとに組織を横切る構造である
- リソースの集約、技術・ナレッジの統一、ガバナンスが利く
- つくる人と売る人の間のコミュニケーションコストが増大し、事業全体の変化スピードが鈍化しやすい
- 子供のサッカーという比喩:
- 最初はポジションに関係なく全員でボールを追いかけ、成熟の過程で目標が細分化されフォーメーションができあがる
- 創業期や新規事業も役割の境界線なく全員が成果を追う垂直なスピード感から始まる
- 垂直と水平を分けるもの:
- 本連載での定義は組織図やフォルダの形の話でも雰囲気の役割分担でもない
- 明確な境界線（インターフェース）がどこに存在するかという運用の本質にある
- 構造の移行則:
- どんな組織も最初は垂直なスピードを選んで立ち上がり、無秩序化という限界に達して初めて水平なガバナンスを選択する
- 機能別の垂直分割と三層構造などの水平分割の関係もこの流れと重なる
■ 6. 水平基盤がスピードを支える
- 対立ではなく補完:
- 垂直のスピードと水平のガバナンスは対立するものではない
- 強固な水平という安全網があるからこそ、現場（垂直）はリスクを恐れず最速で挑戦できる
- 境界線なき垂直の脆さ:
- 明確な境界線がない垂直構造は、柔軟に試行錯誤できる反面、やり方やデータ構造がチームごとにブレて無秩序化しやすい
- 共通基盤の効果:
- 認証、決済、セキュリティといった共通基盤が整っていれば、現場は車輪の再発明に時間を取られず最小コストで新機能開発に集中できる
- AI時代の結論:
- AIだから垂直分割だと極端に振り切るのではなく、強固な水平基盤の上でAIを活用してこそスピードと品質が両立する
- 水平基盤がAIに与える価値:
- 共通基盤やテンプレートが整った状態は、AIに迷わせない標準化されたコンテキストを提示しやすい環境を意味する
- プロジェクト間で水平構造が共通化されていれば、成功したAIの学習環境やプロンプト構成、コード生成ルールを横展開できる
■ 7. フレームワークが水平を守ってきた理由
- 小規模でも水平を選んできた事実:
- 本来、小規模プロジェクトでは水平分割は過剰設計であり、少ないファイルにまとめる垂直的なアプローチで十分だったはずである
- それにもかかわらず業界全体はかたくなにフレームワークという水平構造を守ってきた
- リスクの回避:
- 普及したフレームワークを使えば、技術的瑕疵にぶつかっても誰かが助けてくれるという恩恵を得られる
- 品質の向上:
- 多くの利用者によりフレームワーク部分の品質が保たれる
- テスト手法や安全ガードなどの機能を利用することで品質が保たれる
- 知識の共有:
- 使い方だけでなく、コミュニティがもつ文化背景などソフトウェア以外の資産が多く得られる
- 水平型組織と同じ利点:
- これらの利点は水平型組織の利点と変わらず、少人数でも水平組織のメリットを外部から受けることを選んでいたと言える
- 採用市場での共通指標:
- 流行りのフレームワークを採用しているかは採用やモチベーション、評価基準に直結する
- 人間を組織で管理・育成する上での強力なインセンティブとして機能してきた
■ 8. AIが垂直に市民権を与えた理由
- 捨てたのではなく肩代わりされた:
- 垂直を選ぶことでリスク・品質・知識の共有を捨ててよいと考えているわけではない
- AIがその共有インフラの役割を肩代わりするようになったから垂直が許された
- リスクの回避の代替:
- 詰まったときに検索やコミュニティで探さずとも、AIがその場でデバッグや代替案の提示を行う
- 品質の向上の代替:
- 厳格なフレームワークの型にはめなくても、AIへの指示で一定水準のコードやバリデーションが一瞬で生成される
- 簡単な人的ミスの介入を考慮しなくてよくなるため厳密さの重要性が下がる
- 知識の共有の代替:
- フレームワーク特有のお作法を人間が学習しなくても、LLMのモデル内知識やリポジトリ内の文脈からAIが意図を汲み取って書き上げる
- 現時点での留保:
- これらが完全に代替されているとは言えない部分もある
- ハルシネーションのような品質面の課題もループエンジニアリングなどを通じて現在進行形で改善が進んでいる
- 垂直へ踏み出せた構図:
- 人間が我慢して従っていた水平なガードレールをAIが補完するため、エンジニアは手元の垂直構造へ踏み出せるようになった
- 土台に既存フレームワークがあるという安心感がその暴走を心理的に支えている側面もある
■ 9. 次回への接続
- 無原則な垂直化の先には、システム全体の整合性が失われる「システムの崩壊」が待ち受けている
- 次回は人間とAIの主権を明確に分ける設計指針「新・三層構造」と、AIとの具体的な分業設計を解説する