序章 整理という発明
コードを書くことは、かつて「動けばよい」という実験の連続でした。
小さなスクリプトを積み上げ、壊れたら直し、また足す。十分に動いていれば、それで役割を果たしていたのです。
しかしWebが生活に浸透し、チームでの開発が当たり前になり、機能が重層化する中で「動く」だけでは足りない現実が露わになりました。
読みにくいコードは修正時に壊れ、再利用できないコードは開発速度を奪い、理解できない構造はチームを分断しました。
そこで求められたのが「整理する」という技術です。
ファイルを分け、責務を定義し、再利用できる単位に整形する。効率化であると同時に、理解のコストを下げるための発明でした。
本稿は、Perl CGIの混沌から始まり、Rails、サーバーレス、そしてPost-Serverlessへと続く旅路を「整理」という視点で追います。
この歴史は、私たちがソフトウェアの複雑さとどう向き合ってきたか、その探求の記録でもあります。
第1章 混沌の誕生 ― Perl CGIという原始時代
時代背景
ブラウザがまだ静的な閲覧装置だった1990年代後半、Webページは「テキストを読むだけ」の静的なものでした。
そこに登場したのがPerl CGIです。次の一行がWebを動的にしました。
print "Content-type: text/html\n\n";
当時のファイル構造
/cgi-bin/ ├── index.cgi # メイン画面 ├── post.cgi # 投稿処理 ├── view.cgi # 閲覧機能 ├── delete.cgi # 削除処理 └── lib/ ├── db.pl # データベース処理 └── html.pl # HTML生成処理
スクリプトはFTPで直接アップロードされ、HTMLとロジックが同じファイルで混ざり合っていました。
とにかく動けば良く、保守するという概念も無かったため、ルールも構造も存在しなかったのです。
自由と引き換えの混沌
Perl CGIはとにかく自由でした。フォームの入力を受け、ファイルに保存し、print文で100行以上のHTMLを出力する。開発者は“Web職人”として手作業でサイトを作り上げていきました。
しかし、自由は無秩序と表裏一体です。巨大化したスクリプトは読めず、手を入れるたびに関係ない箇所が壊れました。「維持する」という発想は、まだ産声を上げていなかったのです。
アイデアを思いついたら作り、また新たなアイデアを思いついたら作り直すだけ。
当時はそれで良かったのです。
インターネットという可能性を手にして、世界はアイデア合戦に明け暮れていました。
整理への最初の芽生え
混沌の中にも規律が生まれます。lib/ディレクトリに共通処理を切り出す試みが現れ、複数のCGIから同じ関数を呼び出せるようになりました。
それでも「どこに何を書くか」は人それぞれで、再利用性は芽生えたものの、秩序は個人に依存したままでした。
当時のトピックス
- Yahoo!ディレクトリやジオシティーズ全盛期。個人ホームページが「ネットの主役」
- ２ちゃんねる（現・5ちゃんねる）の登場
- CGI掲示板やアクセスカウンターが「動くサイト」の象徴
- スニペット集サイトや技術書からコピー＆ペーストで機能を追加
- FTPで直接上書きする手作業の更新フロー
第2章 再利用という夢 ― CMSとフレームワークの台頭
時代背景
Webが商業化し、「更新し続けるサイト」が求められた2000年代初頭。
Perl CGIの混沌を経験した開発者たちは「同じものを何度も作らなくてよい世界」を志し、CMSや初期PHPフレームワークへと向かいます。
当時のファイル構造
public_html/ ├── index.php ├── wp-content/ │ ├── themes/ │ └── plugins/ └── app/ ├── controllers/ ├── models/ └── views/
WordPressとテンプレート文化
2003年に登場した WordPress は、ブログエンジンから汎用CMSへと進化します。
wp-content/themes/ と wp-content/plugins/ で見た目と機能を分離し、ファイル配置が役割を示す構造が普及しました。
職人技だったWeb制作が、テンプレートを基盤とした産業へと姿を変えていきます。
CakePHPとMVCの夜明け
さらにCakePHPなどのフレームワークが登場し、MVC（Model/View/Controller）が急速に普及しました。
app/
controllers/
models/
views/
規約に従えば誰でも同じ構造で開発できるようになり、再利用と保守性が大幅に向上します。
新しい課題
標準化は安心をもたらす一方で、プラグインやテンプレートが乱立しました。
また、この頃のCakeなどのフレームワークは画面生成に特化した部分があり、例えばログイン画面の生成コマンドを叩くとCakeによってデザインされたログインフォームと共に認証バックエンドが生成されました。
この生成されるデザインの癖が強く、常に一度生成してから顧客に合わせて書き直す必要がありました。
またこの頃に覇権となったのが WordPress で、確かにエンジニア目線でも癖の強くない部類であったため多くのプロジェクトに採用されていきました。
そして、顧客のアイデアが WordPress というブログエンジンの想定範囲を遥かに超えた注文ばかりになり、エンジニアが WordPress の魔改造に日常的に手を染めるような地獄の風景に変わるのに大した時間はかかりませんでした...
この頃までがエンジニアが「Web職人」であった最後の時代だった気がします。
当時のトピックス
- Movable Type、WordPress、XOOPSなどのCMSが次々と登場
- PHP 4からPHP 5への移行でオブジェクト指向が普及
- Apache＋MySQL＋PHPのLAMP構成が既定路線に
- DreamweaverやFrontPageなどGUIエディタによる制作が一般化
第3章 規約という秩序 ― RailsとLaravelの黄金時代
時代背景
2004年に登場したRuby on Railsは、単なるフレームワークではなく「設定より規約（Convention over Configuration）」という思想そのものでした。
後にLaravelがこの体験をPHPへと持ち込み、Web開発は大規模量産の時代へと突入します。
当時のファイル構造
app/ ├── Http/ │ └── Controllers/ └── Models/ resources/ └── views/ routes/ └── web.php
MVCの完成形
RailsやLaravelはMVCを制度化し、ルーティングやデータアクセス、テンプレートまでを一体のルールとして提供しました。
生成コマンドを叩くとスキャフォールディングで最小構成されたテンプレートファイルが自動生成され、チーム開発でも迷いが減り、世界中の企業がこの秩序を採用しました。
充実した生成コマンド、最強のORM、オールインワンでパッケージされたLaravelはおそらく現在でも最速のバックエンド構築速度を誇ります。
REST APIとリソース・コントローラーという革命
これらのMVCフレームワークは REST API という規則的でステートレスなAPIの完成系をも提示してくれました。
私がこれを初めて見た時は「数学の最も美しい方程式」を見せつけられたような洗練された印象を受けました。
これまで各ページのボタン毎に postPageNameActionName() のような関数定義が数えきれない程作成されるのが普通でしが、REST APIは下図のような規則的なパスの規則で CRUD（Create / Read / Update / Delete）操作 を行えばほとんどの用途をカバーできるよという革新的な気づきを与えてくれたのです。
| HTTP Method | URI | Action |
|---|---|---|
| GET | /photos | index |
| GET | /photos/create | create |
| POST | /photos | store |
| GET | /photos/{photo} | show |
| GET | /photos/{photo}/edit | edit |
| PUT/PATCH | /photos/{photo} | update |
| DELETE | /photos/{photo} | destroy |
＊photos は各種テーブル名（複数形）で置き換えます。
私含め、ここまで見せつけられてLaravelを信仰せずにいられた人は居なかったはずです。
更に初学者にも分かるよう教科書のようにまとまめられたドキュメントはまさに「聖書」と言えるものでした。
秩序が抱えた矛盾
効率が上がるほど、設計を深く理解しなくてもアプリが作れてしまいます。
コードは均質化し、モノリシックな巨大アプリが生まれ、1つの変更が全体に影響する課題が顕在化しました。
ORMは便利ですが、DB設計やSQLの理解を覆い隠し、性能チューニングや責務分割を難しくしました。
また、最大限の隠匿と密結合の果てにスピードと簡単さを提供していました。
そして何より、テストが面倒過ぎて誰もテストを作っていませんでした；
次の変化への助走
完成された秩序は、軽さと柔軟さを求める開発者の欲求を満たせませんでした。
「もっと小さく、疎結合な構造を」という願いが、フロントエンドとバックエンドの分離へとつながっていきます。
当時のトピックス
- Googleマップ（2005）がAjax体験を一般に示す
- GitHub（2008）の登場でソーシャル開発が加速
- Railsの「15分でブログを作る」デモが世界を席巻
- Composer普及とともにLaravelが爆発的に成長
- MVCが教育現場のスタンダードとして定着
第4章 疎結合という革命 ― SPAの登場
時代背景
RailsやLaravelがサーバー側に秩序をもたらす一方で、フロントエンドはテンプレートエンジンに閉じ込められていました。
2010年代初頭、**SPA（Single Page Application）**という発想が彗星の如く現れ、フロントエンドは独立したアプリケーションへと進化します。
状態を持つフロントエンド
SPAは初回ロードでアプリ全体を配信し、以降はAPI通信だけで完結します。
ブラウザが状態（データ）を保持し、描画をリアルタイムで更新することで、バックエンドはHTML生成から解放されました。
API駆動の疎結合
REST APIとJSONが標準化され、サーバーは「必要なデータだけを返すだけでいい存在」となります。
Vue.js、React、Angularといったフレームワークが登場し、バックエンドはデータとロジック、フロントエンドは体験と表現を担う明確な分業が確立しました。
疎結合な分離はテスト容易性を高め、サーバーレスやマイクロサービスの土台となっていきます。
MVCフレームワークの岐路
SPA単独で制作され、そのままホスティングされたフロントエンドはとても身軽で、バックエンドはAPIしか必要としていませんでした。
しかしMVCを厳守するとView部分をバックエンドで管理する思想なため、SPAの半分をバックエンド側に密結合させる構造になりSPA本来の身軽さが失われます。
それでもLaravelはその問題を解決するためのInatiaやLivewireなどの更に密結合な機構を追加で注入して何としてでもMVCを厳守する路線を歩み続けて行きます...
当時のトピックス
- Backbone.js、AngularJSなど初期SPAフレームワークが登場
- 2013年にReact、2014年にVue.jsがリリース
- REST APIがデータ提供の既定形となる
- JSONが事実上の標準フォーマットとして定着
第5章 分解と分散 ― サーバーレスという革命
時代背景
2014年、AWS Lambdaが登場します。アプリ一式ではなく、単一関数をアップロードするだけで世界に公開できる新時代の幕開けでした。
秩序立てられたモノリスから、極限まで分解された関数群へ――自由が再び戻ってきた瞬間です。
1関数＝1責務という合理主義
アプリケーションは複数のLambda関数の集合体になり、スケールやコストが関数単位で最適化されました。
しかし関数が増えるほど文脈が失われ、全体像を掴むことが困難になります。
共通処理をLambda Layersに切り出す必要が生まれ、ローカル実行や結合テストの難度が一気に高まりました。
設定という新たなスパゲッティ
serverless.ymlやCloudFormationテンプレートは数百行に膨れ上がり、YAMLがコードより複雑になる現象が起きました。
設定を整理するツールが乱立し、秩序を求める動きが再燃します。
テストの難しい Lambda Layers
レイヤーは共通関数の管理に一見便利そうに思えました。
しかしローカル実行時にレイヤーに実装されたスクリプトは存在しないため動作しないのです...
やはり 複数アクション + 共通関数 のディレクトリ構造が正解だったのです。
再統合への欲求
自由は得られたものの、文脈を失った関数群を扱い続けるのは困難でした。
そこでAWS SAMなどのIaCツールが登場し、関数を論理的なまとまりで管理する構造が再評価されます。
サーバーレスは、秩序から自由へ、その後再び秩序を求めるという振り子運動を体現したのです。
当時のトピックス
- AWS Lambda（2014）リリースでFaaS時代が到来
- API GatewayやCloudWatchなどマネージドサービスとの連携が加速
- JAMstack（SSG）が「静的＋API」という新しい構成として注目
- NetlifyやVercelなどデプロイ自動化サービスが普及
第6章 再統合の始まり ― Post-Serverless構造の夜明け
時代背景
小さな関数が乱立した結果、開発者は再び「適切なまとまり」を求めるようになります。
キーワードは 単純関数 / 共通モジュール / テスト容易性。サーバーレスで分解した粒度を、開発しやすい単位へ再構成する動きが始まりました。
ディレクトリという秩序の再定義
答えは極端な分解を少し戻し、意味のあるディレクトリ構造にまとめ直すことでした。
Expressなどの軽量ルーターでさえも必要な場合のみ選択するようになり、最終的にはテストが容易かつカスタムしやすい単純な関数の組み合わせでフルスクラッチする流れになります。
service-gateway-function/
src/
index.js # 関数ルーター
actions/ # アクション群
user-index.js # 実行ファイル
user-show.js
user-create.js
user-update.js
user-delete.js
utils/ # 共通関数
package.json
template.yaml # ビルドテンプレート
ルーターはアクション名とペイロードを受け取るシンプルな関数とし、アクション自体も必要な引数だけを取る純粋な関数として実装します。
API Gatewayに接続しない場合、Lambdaの入力は関数入力と変わらずシンプルになるためこれで十分なのです。
これによりテストが容易になり、構造化された再利用性が復活しました。
例として私が業務で使用しているマイクロサービステンプレートを紹介しておきます。
下の③④の部分のテンプレートリポジトリです。[①APP - ②API] <--> [③Service SDK - ④Service Gateway]
整理の昇華
Perlは混沌を、Railsは秩序を、サーバーレスは分解を、Post-Serverlessは整理の昇華を象徴します。
アーキテクチャとは、コードを整理するための技術であり、人が複雑さに勝つための試行錯誤そのものです。
現在のトピックス
- GitHub ActionsやAWS SAMを活用したCI/CD統合が一般化
- Firebase、Amplifyなどフルスタッククラウドフレームワークが普及
- Next.jsやRemixなど、フロントとバックエンドを再統合するフレームワークが主流へ
- CopilotやChatGPTなどAIコード生成の普及で、人の設計力が再注目される
終章 整理の未来
整理の歴史は、混沌と秩序の振り子運動です。
極端に揺れた先で、新しい整理のアプローチが生まれ、やがて常識になります。
これからもアーキテクチャは変わり続けますが、根底にある課題は変わりません。
「動かすだけ」から「理解し続ける」へ――整理の技術は、未来のWeb開発を支える基盤であり続けるでしょう。
© 2025 コード整理の歴史（草稿版）