RubyGemsとComposerを比べて見えるPHPの歴史

PHP Composer Ruby RubyGems パッケージ管理

RubyGemsとComposerは「似ているようで違う進化」をした

RubyGemsとComposerはどちらも言語のエコシステムを支えるパッケージ管理の中心です。
そのため「PHPはRubyの後追い」と語られることがあります。

しかし実際には、同じ方向に進化したのではありません。
結論から言うと、RubyGemsは「言語がアプリケーション開発に向かった結果」、Composerは「Web運用文化に適応した結果」として生まれました。

この違いを知ると、PHPの歴史の特徴がかなりはっきり見えてきます。

Rubyは最初から「アプリケーション言語」だった

Rubyの前提：ローカルで開発してデプロイする

Rubyは最初から、開発者が自分の環境でアプリケーションを構築することを前提にしていました。
特にRailsの登場以降は顕著です。

  • ローカル開発
  • テスト実行
  • サーバーへデプロイ

この流れが標準でした。

そのためRubyGemsは、開発者のマシンにライブラリを入れる形で自然に成立しました。

gem install rails

この時点でアプリケーションの土台が整います。
つまりRubyGemsは「開発環境を作るツール」として発展しました。

Bundlerの登場

ただしRubyGems単体では問題がありました。
バージョン衝突です。

そこで登場したのがBundlerです。

source "https://rubygems.org"

gem "rails", "~> 7.0"

Bundlerは、アプリケーション単位で依存関係を固定しました。
ここで初めて「プロジェクトごとの依存分離」が成立します。

重要なのは、Rubyでは

> RubyGems → Bundler

という二段階進化だった点です。

PHPはまったく違う出発点だった

PHPは「サーバー上で直接動かす」文化

PHPは、最初からアプリケーションフレームワーク中心の言語ではありませんでした。
HTMLに埋め込んで動かすスクリプト言語です。

  • FTPでアップロード
  • サーバー上で実行
  • ローカル開発が前提ではない

つまり、開発環境を構築する必要がありませんでした。

ここがRubyとの決定的な差です。

Rubyは「開発者が使う言語」、
PHPは「運用者も触る言語」でした。

その結果：ライブラリ共有が困難

RubyGemsはグローバルインストールでも成立しました。
開発者が自分の環境を管理できたからです。

しかしPHPでは問題になります。

  • 共用サーバー
  • 権限制限
  • 複数サイト同居

1つのライブラリ更新で他サイトが壊れる可能性があります。
この時点で、RubyGems型の仕組みはPHPに適合しませんでした。

ComposerはBundlerの役割を最初から持っていた

ここが重要です。

Rubyは

  • RubyGems（配布）
  • Bundler（依存固定）

の2つで成立しています。

一方、Composerは1つで両方を行います。

composer install

このコマンドだけで、

  • パッケージ取得
  • 依存解決
  • バージョン固定
  • オートロード

すべてが成立します。

つまりComposerは、Rubyが10年以上かけて整えた構造を、一度に実装した存在です。

autoloadが示すPHPの方向転換

PHPには長い間、標準のコード構造がありませんでした。
典型的なコードはこうです。

require_once 'config.php';
require_once 'db.php';
require_once 'user.php';

ファイル数が増えるほど管理不能になります。

Composerはこれを変えました。

require __DIR__.'/vendor/autoload.php';

そしてPSR-4規約が導入されました。

  • クラス名
  • 名前空間
  • ディレクトリ構造

これらが対応するようになります。
つまりComposerはパッケージ管理だけでなく、PHPの設計標準を提供しました。

RubyはRailsが設計を決め、
PHPはComposerが設計を揃えたとも言えます。

なぜ「PHPは古い」と言われ続けたのか

この歴史が評価の差を生みました。

RubyはRailsの完成度によって早期に近代的開発環境を持ちました。
一方PHPは、長い間ファイル配置中心の開発が続きました。

結果として

  • 構造がバラバラ
  • 依存関係管理が弱い
  • 再現性が低い

という印象が残りました。

実際には、Composer登場以降は状況が大きく変わっています。
ただし評価は過去の印象を引きずります。

注意点：Composerがあっても設計は自動では良くならない

ここは重要です。
Composerを入れただけでは、プロジェクトは綺麗になりません。

起きがちなこと：

  • 名前空間を使わない
  • autoloadを設定しない
  • vendor直編集

これでは昔のPHPと変わりません。
Composerはあくまで「構造を守れる環境」を提供するだけです。

まとめ：ComposerはPHPの歴史の転換点

RubyGemsはRubyの自然な延長でした。
ComposerはPHPの方向転換でした。

  • 運用中心 → 開発中心
  • ファイル配置 → 構造設計
  • 手動管理 → 依存管理

この変化によって、PHPは大規模アプリケーションを扱える言語になりました。

Rubyが最初から開発者向けに進化したのに対し、
PHPは現場の実用性を保ちながら進化しました。

その分、変化は遅く見えましたが、
Composerの登場は単なるツール追加ではありませんでした。

PHPが「スクリプト言語」から「アプリケーション言語」に近づいた瞬間だったと言えます。