IT技術の歴史は繰り返す——名前を変えて戻ってくる「本質」を見抜く目を養え

「また同じことをやっている」という既視感

20年以上この業界に関わっていると、ある感覚が繰り返し訪れます。「これ、前にも見たことがある」という既視感です。新しいバズワードが登場して業界が盛り上がり、数年後に「あれは何だったのか」という反省期が来て、また別の名前を冠した似たものが登場する。そのサイクルがあまりに規則的なので、ある時期から私は技術トレンドを「名前を変えた再演」として眺めるようになりました。

これは皮肉を言いたいのではありません。むしろ逆です。歴史が繰り返すということは、そこに普遍的な問題と普遍的なトレードオフがあるということです。名前が変わっても、根っこにある課題が変わらないなら、過去の解決策と失敗から学べるはずです。「新しい技術だから歴史は参考にならない」という思い込みを手放したとき、技術の見え方が大きく変わります。

集中と分散——50年間同じ振り子

IT技術の歴史を一言で表すなら、「集中と分散の振り子運動」です。この振り子は、コンピューターが生まれた瞬間から今日まで、止まることなく行ったり来たりしています。

1960〜70年代、コンピューターといえばメインフレームでした。巨大で高価なマシンを1台据え置き、多くのユーザーがターミナルからその演算能力を共有する。これは極端な集中モデルです。やがてその高コストと硬直性が問題になり、1980〜90年代にはパーソナルコンピューターとクライアント・サーバーアーキテクチャが台頭しました。演算を各端末に分散させる、分散モデルへの揺り戻しです。

しかし今度は、分散したサーバーの管理コストと複雑性が問題になりました。2000年代後半に登場したクラウドコンピューティングは、再びリソースをデータセンターに集中させる発想です。AWSやGCPに演算能力を預け、自分たちはAPIを叩くだけでいい。その構造は、メインフレームとターミナルの関係に驚くほど似ています。

そして今、エッジコンピューティングやIoTの文脈で「処理をデバイス側に持たせよう」という議論が活発になっています。これはまた分散への振り子です。端末に処理能力を持たせ、クラウドへの依存を減らす——これはクライアント・サーバー時代の発想の再来に他なりません。

この表を見るだけで、振り子が規則的に揺れていることがわかります。そして毎回、揺れる理由は同じです。集中すれば管理は楽になるがコストと依存が問題になり、分散すれば柔軟性は増すが複雑性と運用負荷が問題になる。どちらかが「完全な解」にならないから、振り子は止まらないのです。

モノリスとマイクロサービス——SOAという前例

2010年代後半からエンジニアの世界を席巻したマイクロサービスアーキテクチャ。「モノリスは悪で、マイクロサービスが正義」という空気がしばらく続きました。しかし2020年代に入ると、マイクロサービスの複雑性に疲弊した企業が「モジュラーモノリス」や「モノリスへの回帰」を選ぶ事例が増えています。

実はこの議論、かつてSOA（サービス指向アーキテクチャ）として全く同じ形で起きていました。2000年代初頭、SOAはあらゆるシステムを独立したサービスとして設計するアーキテクチャとして盛んに提唱されました。しかし実装の複雑さとオーバーヘッドにより多くのプロジェクトが失敗し、やがて下火になりました。

マイクロサービスはSOAの反省を踏まえつつ、コンテナ技術とDevOpsの文化を取り込んで洗練されたものです。確かに進化はしています。しかし「大きなシステムを小さな単位に分割すると、分割の恩恵と引き換えに連携コストが発生する」という本質的なトレードオフは、SOAの時代から一ミリも変わっていません。

新しいバズワードで包まれていても、解くべき問題は同じ。だから、SOAが当時なぜ失敗したかを知っているエンジニアは、マイクロサービスの落とし穴を先回りして見抜けました。歴史を知ることは、未来のリスクを読む能力に直結するのです。

仮想化——メインフレームが40年前に解いた問題

「仮想化は新しいテクノロジではありません。IBMのメインフレームSystem/360の時代からあった概念です」——これは業界の古参エンジニアがよく口にする言葉です。

1970年代、IBMのメインフレームはすでにVM（仮想マシン）機能を実装していました。高価な1台のハードウェアを複数のユーザーが安全に共有するために、論理的に分離された仮想環境を提供するという発想です。その後、ハードウェアの低廉化とともに「1台に1OS」が当たり前になり、仮想化の発想は一時的に縮小しました。

そして2000年代、VMwareが企業向けに仮想化を再び普及させ、さらにDockerによるコンテナ技術が登場します。Kubernetesが複数コンテナのオーケストレーションを担うようになった姿は、メインフレームが巨大な演算資源を論理的に分割して多数のワークロードを動かしていた姿と、構造的に瓜二つです。マルチテナント、リソース分離、ワークロードのスケジューリング——これらはすべて1960年代のメインフレームが解いた問題でした。

サーバーレスとタイムシェアリング

AWSのLambdaに代表されるサーバーレスコンピューティングは、「コードを書いてデプロイするだけ、サーバー管理は不要」という形で2010年代後半に急速に普及しました。インフラを意識せず、使った分だけ課金される。これは革命的な発想に見えました。

しかし1960〜70年代には「タイムシェアリングシステム」という概念がありました。大型コンピューターの演算時間を多数のユーザーで分け合い、使った時間分だけ料金を払うというビジネスモデルです。IBMやGEがこのサービスを提供しており、利用者はコンピューターを「所有」しなくても計算能力を「消費」できました。

サーバーレスの本質——「コンピューターリソースを所有せず、必要な分だけ従量課金で使う」——は、50年前のタイムシェアリングが目指したものと同じです。ハードウェアがクラウドに置き換わり、料金体系がより細粒度になっただけで、根底の発想は変わっていません。

AIエージェントとメインフレームのバッチ処理

2026年現在、AIエージェントが大きな注目を集めています。自然言語で指示を出すと、AIが自律的にタスクを分解し、ツールを呼び出し、結果を返す。エンジニアは「コードを書く」から「AIに指示を出す」へとシフトしていると言われています。

これは確かに新しいUXです。しかし構造を少し抽象化すると、「処理したい内容を記述して投入し、システムが自律的に実行して結果を返す」というパターンは、メインフレーム時代のバッチ処理やJCL（Job Control Language）と本質的に同じです。人間がすべてをステップ実行するのではなく、ジョブを定義して機械に任せる。AIエージェントが「何をするかを自然言語で記述」するなら、JCLは「何をするかを機械語に近い形式で記述」していました。表現形式は50年で劇的に変わりましたが、「人間が意図を記述し、機械が自律的に実行する」という本質は変わっていません。

ノーコード・ローコード——エンドユーザーコンピューティングの再来

現在のノーコード・ローコードプラットフォームは、「プログラミングを知らなくてもアプリが作れる」として注目されています。しかし1980〜90年代にも「エンドユーザーコンピューティング」という概念が盛んに議論されていました。ビジネスサイドのユーザーが自分でスプレッドシートやデータベースツールを使ってシステムを組む、という発想です。

ExcelマクロやAccessを使った「野良システム」が組織の至るところに生まれ、それがガバナンスの問題を引き起こした歴史を、古参のITエンジニアはよく覚えています。ノーコードが普及した先に何が起きるか——その答えは、エンドユーザーコンピューティングが歩んだ歴史の中にすでにあります。

歴史から何を学ぶべきか

ここまで見てきた「繰り返し」のパターンから、次のことが言えます。

まず、すべての技術はトレードオフの解の一つに過ぎないということです。集中か分散か、モノリスかマイクロサービスか——どちらが「正解」ではなく、その時のコスト・組織・規模・技術水準によってどちらに振れるかが決まります。振り子が戻るということは、「今の解が完璧でない」ことを歴史が証明しているのです。

次に、新しい技術が「革命的」に見えるとき、その本質に立ち返ることが重要だということです。名前が新しくても、解こうとしている問題が古ければ、過去の失敗から学べます。逆に本質が変わっているなら、それは本当に新しいものです。この見極めこそが、エンジニアの技術判断力の核心です。

歴史を知るエンジニアの強さ

「愚者は経験に学び、賢者は歴史に学ぶ」という言葉があります。自分が直接経験していなくても、過去に何が起きたかを知ることで、今の判断の精度を上げられる。これはエンジニアリングにおいても同じです。

新しいバズワードが登場したとき、「これは何の再来か」と問うてみてください。完全に同じことはありませんが、構造的に類似した問題を過去の技術が解こうとしていたなら、そのときの教訓は今も有効なはずです。

技術の表層は目まぐるしく変わります。しかし根底にある問題——スケール、コスト、複雑性、依存、トレードオフ——は半世紀変わっていません。その本質を掴んでいるエンジニアは、次のトレンドが来たとき、誰よりも早く「これは知っている」と言えるのです。