こんにちは！開発環境アーキテクトの私です。
毎日の開発でPHPのパッケージ管理、お世話になっていますよね。「`composer install` を実行したら、なんだか毎回ダウンロードが始まって終わらないな…」「CI/CDのビルド時間がやたら長くてイライラする…」そんな小さなストレスを抱えていませんか？
今回は、PHP開発の心臓部である Composer、その中でも「キャッシュの裏側」にスポットを当てます。これをマスターすれば、毎日のコーディングやCI/CDの待ち時間が劇的に短くなり、開発効率が跳ね上がりますよ。
難しそうに聞こえるかもしれませんが、一歩ずつ優しく紐解いていきますので、ぜひ最後までついてきてくださいね。
—
1. Composerのキャッシュって、裏側でどう動いているの？
まずは、Composerが普段裏側で何をしているのか、その「記憶の仕組み」を覗いてみましょう。
私たちが `composer require` や `composer install` を実行すると、Composerは必要なライブラリ（ZIPファイルなど）をインターネット上のリポジトリ（Packagistなど）からダウンロードします。
もしキャッシュの仕組みがなかったらどうなるでしょう？
プロジェクトを新しく作るたび、あるいは別のブランチに切り替えるたびに、何十メガバイトもあるパッケージを毎回世界中のサーバーからダウンロードし直すことになります。これでは時間も通信量も大食いですよね。
グローバルキャッシュの正体
Composerは、ダウンロードしたZIPファイルやメタデータを、あなたのマシンの「グローバルキャッシュディレクトリ」という特別な場所に大切に保管しています。
デフォルトでは、OSごとに次のような場所に保存されます。
- Linux / macOS: `~/.cache/composer` （または `~/.composer`）
- Windows: `%LOCALAPPDATA%\Composer`
一度このキャッシュに入れば、2回目以降はインターネットに繋ぎに行かず、ローカルのキャッシュから一瞬でZIPを取り出してプロジェクトに配置します。これが、Composerが爆速で動作する秘密の裏側です。
—
2. インストールと、絶対に外せない基礎セットアップ
すでにComposerを使っている方も多いと思いますが、ここでおさらいを兼ねて、最もクリーンで効率的な環境構築の基礎を見ておきましょう。
Composerのインストール（公式推奨のワンライナー）
プロジェクトごとではなく、システム全体で使えるようにグローバルにインストールします。
公式インストーラーを安全にダウンロードして実行する
php -r “copy(‘https://getcomposer.org/installer’, ‘composer-setup.php’);”
ダウンロードしたインストーラーのハッシュ値（SHA-384）を検証して安全性を担保
HASH=”$(wget -q -O – https://composer.github.io/installer.sig || curl -s https://composer.github.io/installer.sig)”
php -r “if (hash_file(‘sha384’, ‘composer-setup.php’) === ‘$HASH’) { echo ‘Installer verified’; } else { echo ‘Installer corrupt’; unlink(‘composer-setup.php’); } echo PHP_EOL;”
composer.phar を /usr/local/bin/composer に配置して、どこからでも叩けるようにする
sudo php composer-setup.php –install-dir=/usr/local/bin –filename=composer
後片付けとしてインストーラーを削除
php -r “unlink(‘composer-setup.php’);”
最初にやるべき重要設定：パラレルダウンロードの有効化
標準のComposerでも十分速いですが、もしお使いの環境に `hirak/prestissimo` のようなプラグインの知識があるなら、現代のComposer 2系では最初から並列ダウンロードがデフォルトで有効になっています。
念のため、Composerが正しく動作するか確認する「Hello World」的な動作確認をしてみましょう。
—
3. 実践！キャッシュを体感するHello World的動作確認
百聞は一見にしかず。実際にキャッシュがどう効いているのか、簡単なプロジェクトを作って実験してみましょう。
ステップ1: テスト用ディレクトリの作成と初期化
ターミナルを開き、次のコマンドを順番に実行してください。
作業用のディレクトリを作成して移動
mkdir composer-cache-test && cd composer-cache-test
空のcomposer.jsonを対話なしで作成
composer init –no-interaction
ステップ2: あえて重めのライブラリを入れてみる
世界中でよく使われているロギングライブラリ `monolog/monolog` をインストールしてみます。
Monologをインストール（初回はネットワークからダウンロードされる）
composer require monolog/monolog
実行ログのイメージ:
Using version ^3.5 for monolog/monolog
./composer.json has been updated
Running composer update monolog/monolog
Loading composer repositories with package information
Info from https://repo.packagist.org: # パックのメタデータを取得中
Analyzing dependencies…
Lock file operations: 2 installs, 0 updates, 0 removals
- Downloading monolog/monolog (3.5.0) # <--- ここでネットからZIPをダウンロード！
- Downloading psr/log (3.0.0)
Writing lock file
Installing dependencies from lock file
…
ここでダウンロードされたZIPファイルは、しっかりとあなたのPCのグローバルキャッシュディレクトリ (`~/.cache/composer/files/…`) に保存されました。
ステップ3: キャッシュの効果を検証する
一度プロジェクトのファイルをすべて消去して、もう一度同じものをインストールしてみましょう。
いま作ったものを全部消す
rm -rf vendor composer.lock composer.json
もう一度最初からやり直す
composer init –no-interaction
composer require monolog/monolog
2回目の実行ログのイメージ:
Using version ^3.5 for monolog/monolog
./composer.json has been updated
Running composer update monolog/monolog
Loading composer repositories with package information
Info from https://repo.packagist.org
Analyzing dependencies…
Lock file operations: 2 installs, 0 updates, 0 removals
- Installing monolog/monolog (3.5.0): Extracting archive # <--- ネットに行かず「抽出」している！
- Installing psr/log (3.0.0): Extracting archive
お気づきでしょうか？ `Downloading` ではなく `Extracting archive` に変わっていますね。これがキャッシュの力です。インターネット回線を一切使わず、ローカルのキャッシュから一瞬でファイルを展開しています。
—
4. 現場で役立つ！DockerとCI/CDでの共有キャッシュ戦略
ここからが本題、シニア・アーキテクトの腕の見せ所です。
ローカルPCではこれで快適ですが、Dockerコンテナ環境や、GitHub ActionsなどのCI/CDサーバーでは話が変わってきます。
Dockerはコンテナを破棄すると中身が消えますし、GitHub Actionsもデフォルトではビルドごとにまっさらな環境から始まります。つまり、「毎回キャッシュが消えて、毎回全ダウンロードが発生する地獄」が生まれるのです。
これを解決するのが、「グローバルキャッシュディレクトリの永続化と共有」です。
A. Docker環境での最適化（マルチステージビルド ＆ ボリュームマウント）
開発コンテナ（Docker Composeなど）でComposerを使う場合、コンテナ内のキャッシュをホストマシン（あなたのPC）と共有させます。
`docker-compose.yml` の設定例を見てください。
version: ‘3.8’
services:
php-app:
build:
context: .
dockerfile: Dockerfile
volumes:
- .:/var/www/html
# ▼ ここがキモ！Composerのキャッシュディレクトリをホストと共有する
- composer-cache:/root/.cache/composer
volumes:
composer-cache:
# ホスト側のDockerボリュームにキャッシュを永続化し、コンテナを作り直しても消えないようにする
これを行うことで、Dockerイメージを再ビルドしたりコンテナを `down` させたりしても、宝物であるComposerキャッシュはDockerのボリューム内に保持され続けます。次回からの `composer install` が常に爆速になります。
B. CI/CD（GitHub Actions）でのキャッシュ最適化
CI/CDでビルド時間を最小化するためには、公式が提供している `actions/cache` アクションを使い、`composer.lock` のハッシュをキーにしてキャッシュを保存・復元します。
実際の `.github/workflows/ci.yml` の設定例です。
name: PHP Composer CI
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: プレコードのチェックアウト
uses: actions/checkout@v4
- name: PHPのセットアップ
uses: shivammathur/setup-php@v2
with:
php-version: ‘8.2’
# PHPの拡張機能などを設定…
# ▼ Composerのキャッシュディレクトリのパスをあらかじめ取得して変数に入れておく
- name: Composerキャッシュディレクトリの取得
id: composer-cache
run: |
echo “dir=$(composer config cache-files-dir)” >> $GITHUB_OUTPUT
# ▼ キャッシュの復元（composer.lockが変化していなければ、キャッシュから一発復元）
- name: キャッシュの復元
uses: actions/cache@v3
with:
path: ${{ steps.composer-cache.outputs.dir }}
key: ${{ runner.os }}-composer-${–hash files(‘composer.lock’) }}
restore-keys: |
${{ runner.os }}-composer-
# ▼ 依存関係のインストール（キャッシュがあればネットワーク通信が最小限になる）
- name: 依存関係のインストール
run: composer install –prefer-dist –no-progress –no-interaction
この設定を導入するだけで、CIのビルド時間が数分単位で短縮されるケースが多々あります。「テストが遅くて開発がテンポよく進まない」というボトルネックを綺麗に解消できます。
—
5. ⚠️ 注意！不要なキャッシュのクリーンアップとトラブルシューティング
キャッシュは便利ですが、永続化しすぎるとデメリットもあります。
長期間放置された古いバージョンのパッケージや、もう使わなくなったライブラリのZIPが肥大化し、ギガ単位でディスクを圧迫する原因になります。
定期的に、あるいはディスクがパンクしそうなときは、次のコマンドでキャッシュの整理を行いましょう。
キャッシュの確認と削除コマンド
現在、キャッシュがどれくらいの容量を食っているか確認する
composer clear-cache –help
（※正確には以下のコマンドでキャッシュディレクトリ自体のサイズや中身を確認できます）
du -sh $(composer config cache-dir)
古いキャッシュをクリアする（Composer 2系以降）
composer clear-cache
ここで実務で絶対に知っておくべき注意点があります。
CI/CDやDockerでキャッシュを永続化している場合、「あまりに頻繁に `clear-cache` を自動実行しないこと」です。キャッシュを消してしまうと、次のビルドで再び全ダウンロードが必要になり、かえってビルド時間が悪化します。
ディスク容量とビルド速度のバランスを見て、例えば「GitHub Actionsのキャッシュは1週間で自動有効期限切れにする」などの適切なライフサイクルポリシーを設定するのがプロの技です。
—
まとめ
今回は、Composerのグローバルキャッシュの裏側から、DockerやCI/CDにおける共有・永続化戦略までをディープに解説しました。
- Composerは、ダウンロードしたパッケージをグローバルキャッシュに保存し、2回目以降は「展開(Extract)」だけで高速化している。
- DockerやCI/CDでは、キャッシュディレクトリ（`composer config cache-files-dir`）をボリュームや外部キャッシュとして永続化・共有するのが鉄則。
- ディスク肥大化を防ぐために、適度に `composer clear-cache` でお掃除することも忘れずに。
これをマスターすれば、日々のローカル開発でのイライラが消え、CI/CDの待ち時間という無駄な時間をエンジニアの創造的な時間に置き換えることができます。
あなたの開発ライフが、今日からさらに快適でエキサイティングなものになりますように！