テックリードの坂本です。

今回Algomaticでは体制変更をきっかけに、メンバーそれぞれが好きな技術を好きに語る 「技術での自己紹介」 を兼ねて、アドベントカレンダーを開催することにいたしました！本記事は、Algomatic 初夏のアドベントカレンダー1日目です 🙌

どんな人が、どんな技術に熱を持って働いているのか、その空気感を社外の方にも知っていただけたら嬉しいです！

1日目の今回は、AI 時代のアプリアーキテクチャについて、事例を交えて書いてみました。

クリーンアーキテクチャ、ヘキサゴナル、レイヤード、MVC。今までいくつものアーキテクチャを積み上げ、時代によって使い分けてきました。では、AI がコードを書く時代、これらはどうなるのでしょうか。要らなくなるのか、それとも姿を変えるのでしょうか。

そもそも、これらのアーキテクチャは手法も作られた年代もバラバラですが、共通している思想が存在します。それは「関心の分離(Separation of Concerns)」です。

この言葉を作ったのは、ダイクストラ法1で知られる計算機科学者のEdsger Dijkstraです。彼が語っていたのはコードの話ですらなく、「人間の頭は一度に全部を考えられない」という、もっと根本的な問題でした。

しかし、AI でのコーディングが当たり前になり、人間の頭ですべてを意識しなくてよくなった今、この考えはまだ必要なのでしょうか?

本記事の結論から言ってしまうと、私は AI がコードを書くようになっても、「どこで分けるか」を決める「関心の分離」の価値はむしろ上がっていくと考えています。なぜそう感じるのか、ソフトウェアの歴史と一緒に説明させていただきます。

この記事のサマリー

コードの設計手法は、「関心の分離」と共にあり続けている。MVC からクリーンアーキまで、名前も作られた時代も違うが、目的は人間の有限な認知をどう助けるかという一点だった
AI の登場で、「関心の分離」の意味が変わった。これまで思考者は人間ひとりだったが、コンテキストウィンドウという認知限界を持つ LLM が「二人目の思考者」として加わった
「AI 時代にアーキテクチャはどうあるべきか」はまだ議論されている。
揺らいでいるのは「関心の分離」に対する目的ではなく手段。層で切る「横割り」から、機能で切る「縦割り」(VSA)が注目されつつある
だが本当に大事なのは手段そのものではない。AIが人間とともに思考する時代だからこそ、「どこで分けるか」を決める設計の価値はむしろ上がる

そもそも「関心の分離」とは

関心の分離とは、ざっくり言えば「1つのコードに複数の役割を詰め込むな。役割ごとに分けて、各部分は1つのことだけに責任を持たせろ」という原則です。ここでの「関心(concern)」は、そのコードが気にしている事柄、つまり入力の検証や業務ルール、データ保存、画面表示などを指します。

言葉だけだとイメージしにくいので、具体例で見てみましょう。「ユーザー登録」を1つの関数に全部書くと、こうなります。

async function registerUser(req: Request): Promise<Response> {
  // ① 入力チェック：メール形式、パスワードは8文字以上か
  // ② 業務ルール：すでに同じメールが登録されていないか
  // ③ 保存：DBにINSERT
  // ④ 通知：ようこそメールを送信
}

極端な例ですが、4つの関心事が団子になっているので、メール送信の仕様が変わってもDBが変わってもバリデーションが変わっても、毎回この同じ関数を触ることになります。

テストも、DBや送信処理を巻き込まないと書けません。

これを近代的なアーキテクチャのように関心ごとに分けると、こうなります。

プレゼンテーション層：入力を受け取り、結果を返す(①)
ドメイン層：業務ルールを判断する(②)
インフラ層：DB保存やメール送信など外部とのやり取り(③④)

すると、変更の波及が局所で済み、テストしやすく、差し替えもしやすくなります。レイヤードも MVC もクリーンアーキも、根っこはこの「関心事で分ける」です。

そして、これらの嬉しさの大本をたどると、ある一点にたどり着きます。人間が一度に頭の中に置ける量には限界がある、ということだと私は考えています。層が分かれていないコードは、副作用まで含めてすべての影響を同時に認識しないといけませんが、分けてあれば1つの要素だけを考えれば済みますし、大胆な変更も関数を取り替えるだけで済みます。

ソフトウェア開発は、関心の分離とともにあった

「一度に一つの側面だけを見ろ」という原則は、ソフトウェア開発においても以下の歴史を辿ってきました。

年	出てきたもの	やってること
1967	オブジェクト / カプセル化	中身を隠して頭から降ろす
1972	情報隠蔽 (Parnas)	"変わりそうなもの"を隠す
1974	関心の分離 (Dijkstra)	一度に一つの側面だけ見る
1979	MVC	表示・入力・データを分ける
2005	ヘキサゴナル	業務ロジックを外界から切る
2012	クリーンアーキ	依存の矢印を全部"内側"に向ける

名前も時代もバラバラですが、クリーンアーキの提唱者 Robert C. Martin（通称 Uncle Bob）自身が 2012年に、「これらは細部こそ違うが、目的は全部同じ＝関心の分離だ」と話しています。

つまり50年間、目的(関心を分ける)は不変で、手段(どう割るか)が時代ごとに変わってきただけとも言えるでしょう。そして全部の根っこには、人間の認知は有限であるという制約がありました。

AIで、制約の正体が変わった

50年間、その「有限な認知」はコードを書くひとりひとりでした。ですが、もう一人の思考者が来ました。コンテキストウィンドウという認知限界を持つ LLM です。

これにより「AI が書く時代に、アーキテクチャはどうあるべきか」をめぐり、意見が割れています。

AI こそ綺麗な設計を要求する

雑なコードを AI に食わせると事故ります。ロジックを分離して一貫させておけば、AI は"真のチームメイト"になってくれます。だから規律は今まで以上に必要になる、という立場です。

人間に綺麗な設計は、AI には分かりにくい

従来のクリーンアーキは層ごとにディレクトリを切るので、1機能を直すのに controller / service / repository / domain と何箇所も見て回ることになります。LLM には特にキツくて、コンテキストに詰める情報が増えるほど焦点がぼやけるからです。だから「コンテキストの最小化」と「純粋関数の最大化」へ寄せるべきだ、という立場です。

では、どちらが正しいのでしょうか。結論から言うと、まだ答えは出ていません。

それを象徴するのが、開発者の生産性を測ったMETR の実験です。2025年前半、ベテラン OSS 開発者に AI を使わせたところ、むしろ 19% 遅くなりました。しかも本人たちは事前に「24% 速くなる」と予想し、終わった後も「20% 速かった」と感じていた。知覚と実測が真逆だったのです。(2026年2月の追試では一部で反転しており、まさに動いている最中の話です。)

ただ、どの設計が正解かは各自考えが違っても、「設計そのものの重要度が上がった」点では見解が揃っています。

それゆえに、揺らいでいるのは目的ではなく手段のほうです。これまでは人間の認知に合わせて「レイヤーで横に割る」のが基本でした。それが今、AI のコンテキスト局所性に合わせて、機能ごとに1箇所へ閉じる「縦割り」へと引き直されつつあります。

バーティカルスライスアーキテクチャという選択肢

この「縦割り」には名前があります。バーティカルスライスアーキテクチャ(VSA) と呼ばれています。提唱は Jimmy Bogard、2018年です(MediatR の作者でもあります)。ここでも歴史は繰り返していて、命名は2018年でも、彼は2015年には同じ趣旨を語っていました。

発想はシンプルで、技術的な役割(層)で切るのをやめて、機能(ユースケース)で切るというものです。先ほどの registerUser で考えてみましょう。層で切る(横に割る)とこうなります。

src/
├── presentation/userController.ts      ← 入口
├── application/registerUserService.ts  ← ロジック
├── domain/user.ts                      ← ルール
└── infrastructure/userRepository.ts    ← 保存

1機能を直すのに4フォルダを行き来します。VSA(縦に割る) だとこうです。

src/features/
├── registration/          ← 登録に必要なものが全部ここ
│   ├── registerUser.ts        （入口・ロジック・結線）
│   ├── registrationRules.ts   （純粋関数の業務ルール）
│   └── registration.test.ts   （この機能のテスト）
└── login/                 ← ログインは別スライス

1機能 = 1フォルダ。registration/ を開けば関わるものが全部そこにあります。

これが AI 時代に効くと考える理由は2つです。

ひとつはコンテキストの局所性。「登録まわりを直して」と頼むとき、渡すべき文脈が registration/ に閉じていて、4箇所に散らばっていません。LLM の認知限界に、フォルダ構造のほうを合わせにいく方向です。

もうひとつは構造が仕様になること。features/ の一覧が、そのままシステムができることの一覧になり、人間にも AI にも地図になります。

しかし、VSA は万能薬ではなく、私たちのチームもまだまだ移行できていません。トレードオフははっきりしていて、スライス間でコードが重複しやすく、エラー処理やログのような横断的関心事の一貫性には意識的な設計が要ります。

規範がゆるいぶん、ジュニア中心のチームでは「ControllerはServiceを呼ぶ」式のクリーンアーキのほうが秩序を保ちやすい、という指摘もあります。

「AI 時代だから縦割りが正解」と断言できるデータも、まだありません。海外でもクリーンアーキと VSA を同じ API で実装して比べる、といった検証がようやく 2026年に出始めた段階です。METR と同じで、これは動いている最中の問いです。

Algomatic は、より良い設計を日々試し続けています

Algomaticでは、AI というもう一人の思考者の制約に合わせて、「どこで切るか」をもう一度考え直す時期に来ていると考え、いままさに試しているところです。VSA のデメリットについても、横断的関心事のような繰り返し現れるパターンの設計を AI に任せられれば、弱点はむしろ「二人目の思考者」と分担できる領域になるかもしれません。そう考えながら、実際に手を動かして検証しています。

おわりに

縦割りが正解かどうかは、実のところ本質ではありません。この 50 年、設計の手法は何度も書き換えられてきましたが、「どこで関心を分けるか」を考える営みそのものは、一度も古びていません。むしろ、コードを書く作業を AI に手放せるようになったぶん、人間に残るのは「どこで分けるか」という関心の分離、その設計判断そのものです。

関心の分離は死なない。むしろ、これからは人間とAIのあいだにも引かれていくものだと思います。AI が書く時代にこそ、その価値は濃くなっていくはずです。