Architecture × Bottleneck
メインフレームからAI／LLMまで——
各時代の最適解は、その時代に最も高かった資源が決めていた。
振り子は一周して、また『計算』に戻ってきた。
ボトルネックは、
消えない。
移動するだけだ。
だから良い設計者の仕事は「ボトルネックを無くす」ことではなく、次にどこへ動くかを当てることにある——という話を、メインフレームから AI／LLM までの50年を一本の線にして書いていく。
この記事が答える問い
なぜ振り子は、メインフレームから出発し、
AI／LLM で「再び中央集権」へ戻ったのか？
結論を先に置く。各時代のアーキテクチャは、その時代に最も希少だった資源（＝ボトルネック）を節約する形に必ず寄っていく。資源が移動すれば、形も移動する。それだけだ。10の時代を、その補助線1本で歩き直してみる。
ざっくり言うと
家計の話とほぼ同じだ。給料が一番貴重なら出費を抑えるし、時間が貴重なら時短家電を買う。「一番高いもの」を節約する形に、暮らしのかたちは寄っていく。アーキテクチャもそれと変わらない。各時代に最も貴重だった資源——CPUか、ネットワークか、データベースか、人手か——を節約する形に、必ず寄っていく。それだけだ。
Chapter 01
ざっくり言うと——アーキテクチャの50年史は、「どこが詰まっていたか」で読み直すと、驚くほど一本の線で繋がる。その補助線をくれた一本のpostの話から始まる。
きっかけは一本の post だった。データベース設計の達人として知られる @copinemickmack 氏が、こんなことを書いていた——アーキテクチャはボトルネックが決める。ボトルネックが移動すれば、システムの形も移動すると。
読み流せる一文ではある。けれど、メモして手元で寝かせていたら、これが補助線として効きすぎることに気づいた。メインフレームから、クライアント／サーバ、Web、マイクロサービス、クラウド、エッジ、そして AI／LLM まで。50年のシステム設計史が、一本の線で読める。
並べてみるとパターンが見える。各時代に最適とされたアーキテクチャは、その時点で最も希少だった資源のまわりに形作られている。資源が移動すれば、当然、形も移動する。それだけのことだ。
この記事はその補助線を頼りに、10の時代を順に歩き直してみる試みになる。出発点は mick 氏のあの一文——その後の解釈と並びは自分の手で組んだので、誤読があれば全部こちらの責任、ということで。
Chapter 02
ざっくり言うと——どの時代も「一番高い資源」を節約する形にシステムは必ず寄る。経済の話に過ぎない。だから古いコードは「古い」のではなく、「当時の一番高い資源を節約する形のまま、地層に残っている」のだ。
補助線そのものは、ひどく単純な経済原則に過ぎない——高いものはケチる。安いものは贅沢に使う。アーキテクチャの選択も同じだ。各時代のシステムは、その時の「一番高い資源」を節約する形に必ず寄っていく。なぜなら、そこを節約しないと割に合わないからだ。
50年を一気に駆け抜けると、希少資源はこう動いてきた。
計算 → 配布・接続 → 単一DB → 人・組織 → 物理 → 再び計算
熱色＝集中側へ寄る時代 ／ 冷色＝分散側へ振れる時代
言い換えてもいい——いま自分が触っているアーキテクチャは、ほぼ全部が「過去のどこかでの希少資源を節約した形」が、そのまま石化したものだ。設計判断ではなく、化石。だからレガシーは「古い」のではなく、「古いボトルネックを節約する形のまま、地層に残っている」のだ。
この見方が効くのは、いま自分が書いている設計も同じ運命だと気づかせてくれるからだ。今日「これがベスト」と信じて選んだ構成は、十年後には「あのコスト比に賭けてた時代の遺物」として誰かに呆れられる側に回る。そう覚悟して書くか、信じて書くかで、設計の謙虚さがまったく変わる。
補助線を1本引いた。次の章で、まずはそれを使って描いた全体像を見ておきたい。
Chapter 03 — Figure
ざっくり言うと——下のグラフは、50年で「集中」と「分散」を行ったり来たりした振り子の軌跡。両端は同じ「計算が高い」場所で、メインフレームと今のAIが揃って立っている。
先に全体像を見ておこう。10の時代を、縦軸＝集中⇄分散、横軸＝時間で並べると、こうなる。線が上にあるほど「中央の一台に集めた」時代、下にあるほど「散らした」時代。色は熱いほど「計算が高い」、冷たいほど「計算が余っている」を表す。
縦軸は集中⇅分散、横軸は時間。線が熱い区間は「計算が希少」な集中の時代、冷たい区間は資源が余って分散できた時代。注目すべきは両端——メインフレームと AI が、同じ「計算が希少」の地点に立っている。振り子は一周して戻ってきた。
この図が示しているのは、技術の進化が直線でも上向きでもなく、資源コスト比という重力場の中でグラグラ揺れている振り子だということだ。次の章から、その振り子の各停留所を順に開けていく。
Chapter 04
ざっくり言うと——コンピュータの計算力が高かった時代は、中央の一台に集約された。やがてPCが普及して末端で計算が余り始め、ロジックが分散していく。「配布の手間」と「DBへの大量接続」という新しい詰まりが生まれた話。
最初の停留所は、身もふたもなくシンプルだ。マシン時間が人間の時間より圧倒的に高価だった。だから中央の高価な一台に計算を集約し、端末は表示だけの「ダム端末」にする。処理はバッチでキューに積み、CPU の遊休を1秒でも削ることが正義になる。
タイムシェアリングはこの貴重な一台を多人数で分割利用するための仕組みだった。ここで覚えておきたいのは、この「バッチ」と「タイムシェアリング」が、60年後にもう一度全く同じ形で蘇るということだ（その話は第7章で）。
PC が安くなり、計算力が末端で「余る」ようになった。ここでボトルネックが中央から移動する。ロジックは余った PC 側へ、データはサーバへ——2層構成だ。
この時代の象徴が PL/SQL ・ ストアドプロシージャ——簡単に言うと「データベースの中に直接プログラムを置く」仕掛けだ。「DB とアプリ間の往復は遅い」という前提のもと、ロジックをデータの近くに置いた。ネットワークが遅いから、ロジックを DB の近くに——この判断は、第2幕で見事に裏返ることになる。
代償は二つあった。数千台のクライアントへソフトを配り続ける配布地獄と、各クライアントが DB 接続を握りっぱなしにするコネクション枯渇。次の時代はこの二つを倒すために生まれる。
2層の代償を、間にアプリケーションサーバを一枚挟むことで解いた。コネクションプールで「N台＝N接続」問題を吸収し、ロジックを中間層に集約、クライアントは薄くする。配布も中央集約で片づく。
ここで初めて「プレゼンテーション／ロジック／データ」の三分割が、設計の常識として定着した。今でも我々が日常的に触っている Web システムの多くは、結局この三分割の末裔である。90年代の希少資源を節約するために生まれた形が、30年経った今も最大公約数として残っている——化石、というのはまさにこういうことだ。
Chapter 05
ざっくり言うと——ブラウザの普及で配布問題は消えたが、今度は「1台しかないデータベース」が詰まり始めた。キャッシュ（よく使うものを手前に置く）と、データ分割（NoSQL）で乗り切った時代の話。
ブラウザがゼロインストールの万能クライアントになり、配布問題そのものが消滅した。アプリ層は横にいくらでも増やせる（スケールアウト）。LAMP スタック——Linux ＋ Apache ＋ MySQL ＋ PHP の4点セット、2000年代Webの基本構成——がその象徴だ。
だがボトルネックは今度は「1台しかない DB」へ移る。皮肉なのは、かつてロジックを DB に寄せた設計が、ここで足枷になることだ。アプリは増やせても、DB は簡単には増やせない。前時代の最適解が、次の時代の負債になる——化石の不気味さがここで初めて表に出る。
REVERSE
PL/SQL時代：「ネットワークが遅いから、ロジックを DB の近くに」
キャッシュ時代：「ネットワークが速いから、遠くのキャッシュで済む」
ここで PL/SQL 時代の判断が真逆になる。memcached（2003）、Redis、リードレプリカ、CDN。RAM が安くなり、ネットワークが十分速くなった結果、「ネットワーク越しのキャッシュヒット」のほうが「DB のディスクシーク」より安くなった。
この反転は劇的だ。同じ「ネットワーク vs ディスク」のコスト比較で、判断が180度ひっくり返る。同じ資源の希少性が反転すると、最適な設計判断もまるごと反転する。これがこの記事の核心部分だと思う。設計判断は「絶対的に正しい」のではなく、その時の資源コスト比に賭けているにすぎない——それを一番きれいに見せてくれる例だ。
読み込み（read）はキャッシュで逃がせても、書き込み（write）とデータ量が一台の限界を超える。Google BigTable（2006）、Amazon Dynamo（2007）、そして両者を統合した Facebook の Cassandra。水平に分割する（シャーディング＝1つの大きなテーブルを「東京の客／大阪の客」のように何台にも切り分けて持つ）。代わりに、長年の常識だった「データの厳密な整合性」と「複数テーブルをまたいだ検索（JOIN）」は捨てる。
これを正当化するのが CAP 定理。超ざっくり言うと、「分散システムでは、データの整合性・常に使えること・通信が切れても動くこと、の3つを同時には満たせない」という原則だ（Brewer が2000年に予想、Gilbert-Lynch が2002年に証明）。サーバもストレージも安い。高いのは「複数台のあいだで足並みを揃えること（調整）」のほうだ。だから設計は、足並みを揃える作業を最小化する方向に倒れていった。捨てて軽くなる——この時代の合言葉である。
Chapter 06
ざっくり言うと——マイクロサービスを駆動したのは、技術じゃなく「人と組織」が詰まっていたから。技術の話だけ見ているとこの転換の理由は永久に取り違える、という盲点の話。
ここで一回、立ち止まる必要がある。これまでの停留所は全部「ハードや回線という技術資源のボトルネック」だった。けれど、次の停留所はそこから一歩離れる。
2010年代に入ると、モノリスのボトルネックは「計算」でも「データ」でもないことが、はっきりしてくる。200人が1リポジトリに同居することによる、マージ地獄・協調リリース・1つのバグでの全停止——これが本当のボトルネックだ。
だから独立して動かせる小さなサービスに割り、それぞれを小さなチームが所有する。背景には2つの有名な経験則がある：Conway の法則（システムの形は、それを作る組織の形をそのまま映す）と、Amazon の two-pizza team（チームはピザ2枚で足りる人数＝8人前後に保つ）。サービスごとに DB も分ける。「多数の小さなサービスを運用するコスト」が「多数の人間を1つのコードベースで調整するコスト」を下回ったから、これは成立した。動かしたのはハードではなく、組織の速度だった。
この50年の盲点
振り子の軸は実は2本ある。
(1) 技術資源の希少性
(2) 組織という非技術の資源（Conway）
多くの議論は (1) だけで (2) を抜く。マイクロサービスを技術トレンドとしてだけ語ろうとすると、何度説明しても「なぜそれが流行ったか」が説明しきれない。
逆に言うと、組織や複雑性に見合わないマイクロサービス化は、ボトルネックを取り違えた典型として知られている。ネットでも事例には事欠かない——Segment が一度マイクロサービスに分割した後、運用コストに耐えきれず単一サービスに戻した経緯を公開した記事「Goodbye Microservices」（2018年）や、Martin Fowler の 『MicroservicePremium』（2015年）など、「マイクロサービスにはプレミアム（追加コスト）があり、複雑性と運用に耐えられる段階で初めて選択肢になる」という議論はもう定着している。倒すべきボトルネックがそもそも違うのに、形だけ真似してしまうとこうなる、というケースだ。
Chapter 07
ざっくり言うと——「サーバを持つ」から「使った分だけ借りる」へ。次に「光速」という変えられない物理が出てきて、最後にAIで計算がまた高くなり、振り子が一周してメインフレームの形に戻る。
クラウドは、「サーバを買って数ヶ月待って置いておく」から「使った分だけ借りる」への転換だ。サービスが爆発すると、たくさんの小さなサーバを束ねて管理する仕組みが必要になり、Kubernetes——コンテナという軽いサーバの群れを束ねるオーケストレーターが標準になった。サーバレス は、それをさらに突き詰めて「使う瞬間だけ立ち上がり、待機中はお金がかからない」形にしたもの。代償はコールドスタート（最初の1発が遅い）とロックイン（そのクラウド固有の仕組みに縛られる）。要は「持つコスト」より「呼ぶコスト」が安くなったのだ。
このサイト自体もその恩恵を受けている側で、S3 → CloudFront + OAC に移行した話に書いたように、「自分で Web サーバを持つ」という選択肢を最初から外して設計した。これは2010年代の「持つコスト＞呼ぶコスト」というコスト比に思い切り賭けた結果であり、この比率が逆転したら、即・負債になる構成でもある。
中央リージョンまでの物理的なレイテンシ。ネットワークが再びボトルネックになるが、今度は削減不能な物理法則だ。Cloudflare Workers のように、計算をユーザーのすぐ近くへ運ぶしかない。
アルゴリズムでは光速に勝てない。勝てないなら、距離を縮める——それがエッジの発想だ。ここまで来ると、ボトルネックは「もうこれ以上どうしようもない物理」になる。技術がやれることが減って、配置で勝負することになる。
そしていま、振り子が戻りきった。GPU、すなわち計算が再び希少で高価になった。加えてメモリ帯域（memory wall：CPUは速くなったがメモリへのデータ転送が間に合わない、という壁）、AIに1回考えさせるコスト、エージェントではトークン（AIが扱う単語の最小単位）の出てくる速さも詰まる。
結果として現れる形は——
· 中央集権の GPU クラスタ
マシン時間より人間の時間が安いので、中央に集めて分割利用する
· 推論のバッチング
高価な計算の遊休を減らす ＝ メインフレームのバッチと同型
· API 経由のモデル利用
自分で持たず中央を呼ぶ ＝ タイムシェアリングの再来
希少資源が「計算」に戻ると、60年前のパターンがそのまま回帰する。自分が今書いている AI エージェントの記事——エージェントハーネスの内部 で「prompt caching」という仕組みを説明したが、これも要は「AIが直近で計算した内部状態を覚えておいて、毎回ゼロから計算し直さない」というだけの話で、メインフレーム時代の「高い計算の遊休を削る」と同じ動機だ。語彙が違うだけで、やっていることは1965年と変わらない。
Chapter 08
ざっくり言うと——いま自分が書いている設計が「どのコスト比に賭けているか」を言葉にできれば、それが古くなる条件まで先に見える。
10の停留所を歩き直した。最後に、ここから持ち帰れる芯を3つだけ。
計算が希少なら集中（メインフレーム／いまの GPU）、計算が安いなら分散（PC・C/S・エッジ）。アーキテクチャの流行は思想ではなく、その時代の資源コスト比が決めている。「思想」だと思って学ぶと、コスト比が動いた瞬間に追いつけない。
(1) 技術資源の希少性の振り子、(2) 組織（Conway）という非技術の軸。マイクロサービスを駆動したのは技術ではなく組織のボトルネックだった。技術軸だけ見ていると、この転換の理由を永久に取り違える——ここが盲点。
レガシーとは「古いボトルネックの化石」だ。PL/SQL 地獄＝低速ネットワーク時代の化石。設計判断は常に「その時の資源コスト比への賭け」であり、コスト比は動き続ける。自分の設計が"どのコスト比に賭けているか"を言語化できれば、それが陳腐化する条件まで先に見える。
ネット上の設計談義を覗いてみると、10年前のコスト比に賭けて積まれたコードに苦しむ話はそこら中にある。正規化しすぎて JOIN に詰まるサービス、逆に非正規化しすぎて整合性が崩れたサービス、モノリスに留まるべきだったマイクロサービス、その逆。どれも当時は正解だった。化石を笑うのは簡単だが、いま自分が書いているコードも、十年後の誰かにとっての化石になる。
コードの詩人 で「ちょうどいいを見極める」と書いたが、「ちょうどいい」は永遠ではない。今のちょうどいいは、今のコスト比に合っている、というだけだ。それを忘れずに設計できる人は、たぶん十年後に振り子が動いても、迷子にならない。
Coda
ボトルネックは、
消えない。
移動するだけだ。
だから良い設計者の仕事は「ボトルネックを無くす」ことではなく、
次にどこへ動くかを当てることにある。
この記事の出発点は、冒頭でも書いたとおり mick 氏の一文だった。並べる作業をするまで、自分のなかでも50年史はバラバラの教科書的事実の集合でしかなかったのに、補助線1本でこんなに繋がって見えるとは思わなかった。良い補助線は、線そのものではなく、線を引いた後に見える景色のほうに本体がある。@copinemickmack 氏に感謝。
Fact-check
主要な年号・出典は一次／準一次情報で確認済み：Conwayの法則（1967執筆・1968 Datamation 掲載、命名は Brooks『人月の神話』1975）／CAP 定理（Brewer PODC 2000 予想 ・ Gilbert-Lynch 2002 証明）／memcached（Fitzpatrick, LiveJournal, 2003）／BigTable（Google, OSDI 2006）・Dynamo（Amazon, SOSP 2007）・Cassandra（Facebook, Lakshman & Malik）／Segment「Goodbye Microservices」（2018）・Martin Fowler「MicroservicePremium」（2015）。