matkladのアーキテクチャ学習法 — 本ではなく大きなコードベース、そしてLLM時代に失われつつあるチャネル
matkladのアーキテクチャ学習法 — 本ではなく大きなコードベース、そしてLLM時代に失われつつあるチャネル
シニアエンジニアがアーキテクチャ直観を得た本当の経路は、本一冊ではなく、大きなコードベースを自ら運用してきた時間だった。ではコードをLLMが書く時代において、ジュニアはどのチャネルでその直観を得るのか — それとも直観そのものが消えていくのか。
導入 — 一人のシステムエンジニアが自分の学習を公開した
2026年5月12日、Aleksey Kladov(ハンドル名 matklad)が自身のブログに「Learning Software Architecture」という記事を投稿した。彼はどこかの企業を代表して書く立場の人間ではない。ただ彼が誰であったかを押さえておくと、文章の重みが変わる。彼はIntelliJ Rust初期のメンテナーであり、JetBrainsで rust-analyzer をゼロから設計し、現在はTigerBeetleという分散会計データベースのシステムエンジニアとして働いている。「Why an IDE?」「Notes on a Smaller Rust」「How to Test」など、システムプログラミング界隈で一度は話題になった文章の著者でもある。すなわち「大きなコードベースを最初から最後まで作り上げた人間」としての発言権を持つ人物である。
今回の記事は、その権威に似合わないほど短く、率直だ。ある物理学博士課程の学生から「ソフトウェアデザインをどう学べばよいか」と尋ねられたことが出発点だと書かれている。彼の答えを短く要約すればこうなる。本はほとんど役に立たなかった。学校のデザイン講義も同じだ。自分が本当に学んだのはIntelliJ Rust時代に、たまたま押し付けられたアーキテクチャ責任を通してであり、そのとき犯した失敗こそが本当の教科書だった。幸いなのは「ソフトウェアエンジニアリングは、好奇心ある頭さえあれば第一原理から自分で導けるくらい単純である(software engineering is simple enough that an inquisitive mind can figure it out from first principles)」ということだ。
この投稿は5月12日のHacker News一面に547点を集め、100件を超えるコメントを生んだ。人々が集まった理由は単純である。誰もが一度は見た光景だからだ。本棚には Clean Architecture、Domain-Driven Design、Designing Data-Intensive Applications、A Philosophy of Software Design が並んでいる。しかしいざ、どのPRをマージするか、どこにモジュール境界を引くか、どの依存を断つかを決める瞬間が来ると、本のどのページも開かれない。決定はいつも、誰かの「以前似たようなものをこう書いて爆発した」という傷跡から出てくる。matkladの記事は、その傷跡がどこで作られたのかを本人が回想として書いた文章である。
問題は、この回想を2026年の座標に置くと別の問いが浮かんでくることだ。matkladが傷跡を得たチャネル — 大きなコードベースを人間の手で読み、修正してきた数千時間 — は、いままさに急速に狭まっている。CursorとClaude Code、ChatGPT Codex がコードの最初の読者であり最初の書き手になっていく時代に、ジュニアが大きなコードベースを「噛み砕いて」傷跡を作る時間はどこへ消えるのか。本稿はこの二つを並べて見ようとする試みである。
本論 1 — 本ではなくコード: matkladが薦めた学習経路
まずはmatkladの文章を正確に追ってみよう。彼は学習資料を二つの層に分ける。第一は文章と講演である。彼が最も強く推すのは本ではない。Gary Bernhardtの講演「Boundaries」、Pieter HintjensのØMQガイド、Jamiiの「Reflections on a Decade of Coding」、Ted Kaminskiのブログ、そして自分自身の書いた「How to Test」だ。いずれも一人の具体的な経験と、それを一般化した短い文章ばかりである。
本は二番目に追いやられている。彼が挙げた二冊は Software Engineering at Google と John Ousterhout の A Philosophy of Software Design だが、後者については「皆が薦めるが自分には変化を与えなかった」とぬるい書き方をしている。つまり彼は「アーキテクチャ本」という産業全体に対してやや懐疑的だ。
では何が本当に彼を教えたのか。彼の自己診断は二つに収束する。一つは、IntelliJ Rust と rust-analyzer 時代に自ら責任者となって誤った決定を下した経験である。「私が本当に学んだのは、IntelliJ Rust において — 意図せずして — アーキテクチャ責任者の位置に挟み込まれ、そのために自分の手で失敗をする以外なかったからだ」。もう一つは、彼が考える学習のメタ原則、すなわち「ソフトウェアエンジニアリングは単純な領域であり、好奇心ある頭は第一原理から答えを導ける」という信念だ。
この二つを合わせると、彼の薦める学習経路の輪郭が浮かぶ。本 < 文章と講演 < 大きなコードベースを直接読み修正する時間 < 自分の手でシステムを最初から最後まで責任を負う経験。本は語彙を与える。文章と講演は良いメンタルモデルを一つ二つ加えてくれる。しかし本物の直観 — どのPRが危険で、どの依存が5年後に請求書になるか、どの抽象が爆発しないかについての直観 — は、自分で書いたものを自分で運用する中でのみ育つ。
この診断はmatkladだけのものではない。彼の記事についたコメントの中で最も多く支持されたのは、deepsunの次のような整理だった。「アーキテクチャを学ぶ最良の方法は次の二つだ。1) 十分に大きなプロジェクトを 維持 せよ。作る のではなく 支える のだ。2) 少なくとも二、三のプロジェクトについてそれをやれ(The best way to learn architecture is to: 1. Maintain a large enough project. Not create, but support. 2. Do it for at least couple or few projects.)」。彼はさらに付け足した。「Googleで特に顕著だが、新しく作った人は昇進し、維持した人は昇進しない。だから社内で最良のアーキテクト候補は、皆が逃げ出したプロジェクトを引き受けるために入ってきた外部コンサルタントであることが多い」。極めて皮肉だが、彼が指す現象は実際に見覚えのあるものだ。
別のコメントで miki123211 は Architecture of Open Source Applications という書籍シリーズを推した。「各章をそのプロジェクトのメンテナー自身が書いているため、アーキテクチャがどうなっているかだけでなく、そのアーキテクチャを形作った制約 — 通常は歴史と変化するビジョン — まで一緒に学べる」。このコメントはmatkladの主張に非常によく噛み合う。本から学べることがあるとすれば、それは抽象原則ではなく「特定のコードベースがなぜそういう形になったか」というメンテナーの自己陳述である。
CSMastermindというユーザーはさらに直截に「チートシートをやろう」として12個のルールを書き出した。良いデザインとは、ひとつのアイデアが一貫して染み渡っていることだ。さらに一般化すれば、目標は驚き(surprise)を最小化することだ。システムが許容すれば、人はそれをやる。「皆がただこうしてくれさえすればいい」で始まる解は解ではない。データを変換する部分と利用する部分を分離せよ。データモデルはコードより長く生きる。結合(coupling)が大半の悪の根源だ。バージョン管理は避けられない。状態を明示せよ。すべての情報には単一の真実源(single source of truth)が必要だ。命名にもっと時間を使え。テストが難しいなら、それはデザインが間違っている。文書化しなかった決定はすべて後悔する。コミュニケーションは税金であり、払う前に正当化せよ。
CSMastermindのリストを介して見ると、「本」が約束しているものが何かはっきりする。それは上のような格言を一冊に凝縮することだ。しかし格言は格言にすぎず、直観ではない。「テストが難しいならデザインが悪い」という文を読むことと、あるPRが入ってきたときに「これテスト書きづらいな、ここのモジュール境界の引き方が間違っているのか」と即座に疑念が湧くこととは、まったく異なる認知活動だ。両者の距離を詰めるのは — matkladの答えに従えば — 本ではなく時間である。
本論 2 — Conwayが勝つ: rust-analyzer が示したアーキテクチャの本体
matkladの文章には本の推薦よりはるかに興味深い一節がある。彼は「産業ソフトウェアと科学ソフトウェアの品質格差は知識の差ではなくインセンティブ構造の差から来ている」と述べる。博士課程の学生が「自分のPhDは三ヶ月以内に論文を出さねばならない」というプレッシャーの下で書くコードと、五年間ひとつのチームが同じコンパイラを維持するコードの差は、アルゴリズムやデザインパターンの知識の差ではない。誰の時間がどこに行くように作られているかの差である。
彼が引用した一文は辛辣だ。neugierigの表現を借りて彼はこう書いた。「我々はプログラミングをコードを書く仕事のように語るが、コードはアーキテクチャより重要ではなく、アーキテクチャは社会的問題より重要ではない(we talk about programming like writing code, but code matters less than architecture, and architecture matters less than social issues)」。これはConwayの法則の実用バージョンである。システムの形は結局、それを作る組織のコミュニケーション構造を反映する。したがって本当のアーキテクチャ問題はモジュール境界ではなく、誰がどんな時間を使うことになっているか、という問題だ。
この洞察の最も具体的な実例が、彼自身の作った rust-analyzer である。彼は rust-analyzer を意図的に二層の品質基準で設計したと書いている。コンパイラのコア — パーサ、型推論、名前解決 — は非常に高い品質基準、最小依存、速いテストスイートを要求するように作った。そうすることでコアを触れる人は限定され、リグレッションが入り込みにくくなる。一方「週末のボランティア」が入ってきて一つ二つの機能を追加できる場所、たとえば補助解析や追加のインテンション機能のような領域は、わざと隔離されたモジュールに置き、catch_unwind ガードで包んでクラッシュがコアに波及しないようにした。こちら側のモジュールには完璧主義を強制しない。壊れても隔離されるだけだ。
この決定が意味するのは単なるモジュール化ではない。それは「どんな種類の人間を集めるか」という社会学的決定である。コアの厳しい基準はフルタイムのシステムエンジニアたちを集め、隔離された周辺の緩い基準は週末コントリビュータを集める。二つの層は衝突せず、同じリポジトリで共存できる。結果として rust-analyzer は「JetBrainsのフルタイム社員に丸ごと教えなければならないプロジェクト」ではなく、「多様な人間が多様な時間単位で貢献可能なプロジェクト」になった。
matklad はこの決定に留保もつけている。「今日の問題を解くための実験的アーキテクチャが、明日の永続的な制約になることはよくある」。この一言は、彼が自分の決定を自慢しているのではなく、自分の持つ傷跡の一部として回顧していることを示している。二層設計が結果的に良い選択であったとしても、その決定自体は永続化し、次世代メンテナーの手を縛る。アーキテクチャはきれいな黒板の上に描く絵ではない。常に誰かが直前に引いた線の上に重ね描きされる。
ここが本ではうまく教えられない部分だ。Clean Architecture は「依存性は内側に向かうべきだ」と言う。しかし依存をどこで断つかを決める瞬間における本当の圧力は二つある。第一に、誰がこのモジュールを維持するのか。第二に、その人々はどんな報酬構造の中で生きているのか。本はこの二つの問いに答えられない。答えはいつもそのコードベースの歴史の中にある。
ah1508のコメントが似た筋を引き継いでいた。彼はジュニアたちに「clean code」や「beautiful code」のような形容詞ではなく、明確な目標リストを提示することを薦める。維持可能か、性能とスケーラビリティがあるか、効率的か、回復力があるか、観測可能か、テスト可能か、セキュアか、新しく入る開発者が読めるか。「各基準は互いにバランスし、基準を増やすほど迷ったときに良い選択をしやすくなる」。これもmatkladの診断とよく合う。良いアーキテクチャは格言には還元できない。それはトレードオフの名前を正確に呼べる能力のことだ。
CSMastermindの最後の一行はそのすべてを圧縮する。「どのレベルのエンジニアであれ、その仕事は情報が不完全な問題を解くために経験則(rules of thumb)を使うことだ(the job of an engineer at any level is to use rules of thumb to solve problems for which there is incomplete information)」。直観という単語は結局この意味だ。情報は常に不完全で、決定は常に今下さねばならない。その間の空白を埋めるのが経験である。本はその経験の圧縮であって代替ではない。
本論 3 — LLM時代の狭まったチャネル: ジュニアはどこで傷跡を得るのか
matkladの記事が2026年5月に一面まで上がった本当の理由は、一人のシステムエンジニアの学習回想が新しいからではない。その回想が指している学習チャネルが、いま急速に狭まりつつあるという事実のためだ。
整理し直そう。matkladが直観を得た経路は、大きなコードベースを自分で書き、自分で直し、自分で責任を負った時間である。ところが2025年12月以降、GitHubのトラフィックが30倍になった理由は、人間がコードを30倍多く書くようになったからではない。ChatGPT CodexやClaude Code、Cursorのようなコーディングエージェントが、人間の代わりにコードの一行目と一本目のPRを書くようになったからだ。すなわち、コードに最初に向き合う主体が人間からエージェントへと移行しつつある。この変化は「ジュニアが大きなコードベースを手で噛んで傷跡を得る時間」を、ちょうどそのぶん奪う。
これが単なるノスタルジーではないことは、コメント欄のramon156の率直な告白で確認できる。「自分が働くプロジェクトのメンタルモデルを得ることにもっと時間を使いたいが、プログラミング言語や、あるアーキテクチャの選択や、見るからに複雑すぎて割に合わなさそうな何かがあると、すぐにモチベーションを失ってしまう(I would like to spend my time more on gaining a mental model of the projects I work on, but I get very demotivated if I start disliking things)」。彼が付け足した一文がこの時代の感情をよく表している。「すでに週40時間を、想像しうる最も退屈なプロジェクトを眺めるのに使っている」。この感情は普遍的だ。大きなコードを噛むことは根本的に退屈である。それこそが傷跡の価値なのだが、人間は傷跡を進んで選ばない。
LLMはまさにこの退屈さを引き下げる。新しいモジュールを足すときにこのコードベース全体の構造を頭に入れる代わりに、「この関数を似たパターンで追加してくれ」と頼むことができる。結果はだいたい動く。動くからマージされる。マージされるから、次に似た仕事が来てもまた同じチャネルを使う。このサイクルが十分繰り返されると、コードベースをまるごと頭に入れずとも仕事が回るようになる。回っている間、直観は育たない。
このリスクを認識した人々が新しい学習チャネルを探している。一つの候補は「AIとのペア・コードレビュー」だ。人間がPRを開き、AIに「このPRがこのコードベースの既存規約とどこで食い違うか、5年後にどんな負担を生むかを分析してくれ」と頼む。モデルが答えている間、人間は自分の直観とモデルの答えを比較することになる。これがうまく回れば、傷跡の一部をモデルが代わりに見せてくれる効果がある。うまく回らなければ、モデルの答えを暗記する新しい種類の本学習に堕する。
もう一つの候補は「AIが書いたコードを義務的にリファクタリングする時間」だ。すなわち、本番に入るすべてのLLM生成コードについて、人間が一度まるごと読み直して書き直すステップを設ける、というポリシーを作る。これはLLMの生産性ゲインの一部を学習コストとして意図的に戻す行為である。しかし会社にとってこのポリシーはコストであり、社員にとっては退屈である。両者ともが自然に採用する可能性は高くない。
三つ目の候補は「AI時代以前に作られた大きなコードベースを意図的に選んで読むこと」だ。miki123211が薦めた Architecture of Open Source Applications がその一例である。matkladが作った rust-analyzer 自体がもう一例である。Linuxカーネル、PostgreSQL、SQLite、Redis、CPythonのような長く生きてきたプロジェクトたちは、LLMが登場するずっと前に下された決定の痕跡をそのまま持っており、その痕跡がいまも動いている。ジュニアが大きなコードベースの直観を得たいなら、自分が働く会社のコードベース以外に、意図的に一つ二つこの種のプロジェクトを選び、メンテナー視点で読む必要がある。matkladの記事が指す学習経路は結局、この種の自己強制である。
0xbadcafebee のコメントはこの全議論によい比喩を加える。「ソフトウェアアーキテクチャは配管設計のようなものだ。きわめて重要だが、我々は配管の中に住んでいるのではなく、配管が入った家の中に住んでいる。配管が家の他の部分を考慮していなければ、非常に高くつく修繕になる」。アーキテクチャはそれ自体が目的ではなく、家 — つまりビジネス、チーム、ユーザー — が暮らせるようにするための補助構造だ。LLMがこの比喩でやることは、配管をより速く敷くことであって、家の形を決めてくれることではない。家の形を決める直観を失ったまま配管だけ速く敷かれれば、5年後にとても高い修繕請求書が届く。
結論 — 本は語彙であり、コードベースは傷跡である
最初の問いに戻ろう。シニアエンジニアがアーキテクチャ直観を得た本当の経路は何で、LLM時代にジュニアはその直観をどこで得るのか。
matkladが5月12日に自分の文章で答えた前半は明確だ。本は語彙を与える。文章と講演は良いメンタルモデルを一つ二つ足してくれる。しかし直観 — どのPRが危険か、どの依存が請求書になるか、どんな社会的インセンティブがどんなモジュール境界を決めるかについての即時的な感覚 — は、大きなコードベースを直接責任を負って運用した時間の中でしか育たない。彼が示した道は、本 < 文章 < 大きなコードベースを読む < 自分のシステムを運用する、という順だ。Clean Architecture が約束するものが直観そのものだとすれば、matkladの診断はその約束が誇張だと言っている。本は傷跡を与えられない。傷跡は自分で切らねばできない。
後半は彼が直接答えていない部分であり、我々が答えなければならない部分だ。コードをLLMが書く時代、ジュニアの傷跡チャネルは狭まる。これは道徳の問題ではなく算数の問題である。同じ量のPRに対して人間が書く時間が減るほど、人間が傷跡を得る時間も減る。その結果は一世代後に届く。届いたときに高くつかないという保証はどこにもない。
可能な答えは結局、意図的な自己強制である。AIに最初から最後までやらせず、AIが書いたものをまるごと読み直し、大きなオープンソースのコードベースをメンテナー視点で選んで読み、自分の直観をモデルの答えと意識的にぶつけてみる時間を別枠で確保すること。matkladの文章は、その時間を擁護する最良のテキストの一つだ。「ソフトウェアエンジニアリングは、好奇心ある頭さえあれば第一原理から自分で導けるくらい単純である」。単純だという彼の言葉は慰めだが、その単純さを自分の頭で再導出する作業は、好奇心を持つ人間にしか起きない。LLMはその好奇心をより簡単に鈍らせる。この時代にアーキテクチャ直観を持ちたいなら、好奇心を意識的に保護せねばならない。本は語彙にすぎず、大きなコードベースは傷跡だ。傷跡を作る時間を自分のスケジュールに意図的に残しておくこと — それが2026年5月のmatkladが我々に残した本当の宿題である。