開発チームのテックリードとして、日々CI/CDパイプラインやローカル環境でのビルド速度と戦っているあなたなら、一度はこう思ったことがあるはずだ。
「なぜ、たった数個のパッケージを追加・更新するだけで、Composerの依存関係解決とダウンロードに何分も待たされるのか？」
かつては `hirak/prestissimo` がこの苦悩を救ってくれた。並列ダウンロードによってComposerの挙動を劇的に高速化していたあの神プラグインだ。しかし、Composer 2の登場に伴いprestissimoは役割を終え、非推奨となった。Composer 2本体に強力な並列ダウンロード機構がネイティブ統合されたからだ。
だが、デフォルトのまま使っていないだろうか？ Composer 2であっても、適切なチューニングを施さなければ、その真のポテンシャルは発揮されない。ネットワークのボトルネック、非効率なキャッシュ戦略、そしてPHPランタイム自体の設定不良が、あなたの開発スピードを日々確実に削り取っている。
今回は、Composerのインストール速度を極限まで引き上げ、チーム全体の開発サイクルを加速させる「5つの実践的テクニック」を、アーキテクトの視点から徹底的に解説する。
—
テクニック1：ネイティブ並列ダウンロードの限界を引き出すチューニング
Composer 2は標準で並列ダウンロードを行うが、その挙動を支えているのはPHPの拡張機能である。ここを最適化しなければ、どれだけ回線が速くても宝の持ち腐れとなる。
1. `ext-curl` の強制とHTTP/2の有効化
ComposerはデフォルトでPHPのストリームラッパーを使用することがあるが、これはパフォーマンス面で不利だ。必ず `ext-curl` を有効にし、さらに可能であればHTTP/2をサポートしたlibcurlを使用させよ。これにより、同一ホスト（Packagist等）に対する多重通信のオーバヘッドが劇的に削減される。
2. 並列処理数の最適化（環境変数による制御）
Composer 2はデフォルトで最大12個の並列接続を行う。しかし、CI環境や高スペックなローカルマシンでは、この上限を引き上げることでスループットが向上する。
一時的に並列数を20に引き上げて実行する場合
COMPOSER_MAX_PARALLEL=20 composer install –no-dev –optimize-autoloader
これをシェルプロファイル（`.zshrc` や `.bashrc`）にグローバル環境変数として定義しておくことが、チーム全体の暗黙の高速化につながる。
—
テクニック2：ディープキャッシュ戦略と `COMPOSER_CACHE_DIR` の共有
Composerの速度低下の最大の要因は、メタデータの取得とZipファイルの「再ダウンロード」である。これを根絶するのがキャッシュの最適化だ。
1. キャッシュのヒット率を最大化する設計
Composerはデフォルトで `~/.cache/composer`（Linux/macOS）にパッケージのZipやリポジトリのメタデータを保持する。しかし、Dockerコンテナを用いた開発や、CI/CD環境（GitHub Actions, GitLab CIなど）では、ビルドごとにこのキャッシュが消去され、毎回スクラッチからダウンロードが発生しているケースが後を絶たない。
CI環境では、必ずComposerのキャッシュディレクトリを永続化（キャッシュ）するワークフローを組むべきだ。
2. 実践：GitHub Actionsでのキャッシュ最適化設定
以下は、チームのCIパイプラインで絶対に実装すべきキャッシュ設定のベストプラクティスである。
.github/workflows/ci.yml の抜粋
name: Backend CI
on: [push]
jobs:
build:
runs-name: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
# 1. Composerのキャッシュディレクトリパスを動的に取得して変数に格納
- name: Get Composer Cache Directory
id: composer-cache
run: |
echo “dir=$(composer config cache-files-dir)” >> $GITHUB_OUTPUT
# 2. キャッシュアクションの設定（composer.json のハッシュをキーにする）
- name: Cache Composer Dependencies
uses: actions/cache@v4
with:
path: ${{ steps.composer-cache.outputs.dir }}
key: ${{ runner.os }}-composer-${{ hashFiles(‘/composer.lock’) }}
restore-keys: |
${{ runner.os }}-composer-
- name: Setup PHP
uses: shivammathur/setup-php@v2
with:
php-version: ‘8.3’
tools: composer:v2
# 3. キャッシュが効いているため、ネットワーク転送量が最小限になる
- name: Install Dependencies
run: composer install –prefer-dist –no-progress –no-interaction
—
テクニック3：PHPバージョン管理とJITコンパイルの恩恵
Composer自体はPHPで書かれたアプリケーションである。したがって、「Composerを実行するPHPランタイムの速度」が、そのままインストールの速度に直結する。
古いPHP 7.4や初期のPHP 8.0環境でComposerを動かしているなら、今すぐそれを改めるべきだ。
1. 最新のPHPランタイムでComposerを駆動する
ローカルのプロジェクトがPHP 8.1で動いていたとしても、Composerの実行には（互換性が許す限り）常に最新安定版（例: PHP 8.3以降）を使用せよ。JIT（Just-In-Time）コンパイラとオプティマイザの進化により、依存関係の解決（Dependency Resolution）におけるアルゴリズムの演算速度が体感で30%以上向上する。
2. OPcacheのCLI有効化
意外と見落としがちだが、`php.ini` の `opcache.enable_cli` がオフになっていないか確認してほしい。Composerのように数千ファイルのPHPスクリプトを読み込んで実行するツールにおいて、CLI環境でのOPcache有効化は、ファイルI/Oの負荷を劇的に軽減する。
; php.ini (CLI用設定の推奨例)
[opcache]
; CLI環境でもOPcacheを有効化し、Composerの起動速度を跳ね上げる
opcache.enable_cli=1
; 共有メモリの割り当て（Composerのような巨大スクリプト用に十分なサイズを確保）
opcache.memory_consumption=256
; 文字列の内部インターン化を有効化
opcache.interned_strings_buffer=16
—
テクニック4：プロキシとミラーリングによるネットワーク効率化
社内ネットワークや特定の地域（中国や一部のセキュリティが厳格な環境など）では、Packagist.orgへの名前解決やHTTPSハンドシェイク自体がボトルネックになることがある。
1. Composerミラーの活用
中国国内や特定の閉域網で開発を行っている場合、公式Packagistの代わりに高速なミラーサーバ（例: 阿里云 Composer 镜像など）を指定することで、DNS遅延やルーティングの非効率性を回避できる。
グローバルにComposerのミラーを設定する場合
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
※日本国内の標準的な環境であれば、デフォルトの `repo.packagist.org` が最も最適化されているため、無理に変更する必要はない。CDNのキャッシュヒット率が非常に高いためである。
2. `–prefer-dist` の強制と不要なソース管理情報の排除
開発者がやりがちなミスとして、デバッグ目的で `–prefer-source` を常用しているケースがある。これはGitリポジトリをそのままクローンするため、ディスクI/Oとダウンロードサイズが膨れ上がる。
本番・ローカル問わず、原則としてZIPアーカイブをダウンロードする `–prefer-dist` をデフォルトに設定すべきだ。
—
テクニック5：チーム開発で絶対に共有すべき `composer.json` のベストプラクティス設定
ここまでのテクニックをチームメンバー全員に強制するのは難しい。だからこそ、プロジェクトの `composer.json` に設定をコードとして埋め込み、自動化・標準化しなければならない。
以下に、実務の現場で即座に採用できる、パフォーマンスと安全性を極限まで高めた `composer.json` の構成例を提示する。
実用的な `composer.json` 設定例
{
“name”: “enterprise/core-service”,
“description”: “High-performance enterprise backend service”,
“type”: “project”,
“require”: {
“php”: “^8.3”,
“ext-curl”: “”,
“ext-mbstring”: “”,
“laravel/framework”: “^11.0”
},
“require-dev”: {
“phpunit/phpunit”: “^10.5”,
“friendsofphp/php-cs-fixer”: “^3.0”
},
“config”: {
/ パッケージのインストール時に常にディストリビューション（ZIP）を優先し、速度を最大化する /
“preferred-install”: “dist”,
/ プラットフォーム要件（PHPバージョンや拡張機能）を厳格にエミュレートし、開発環境差異によるミスを防ぐ /
“platform”: {
“php”: “8.3.0”
},
/ 自動検出をバイパスして処理速度を上げるための設定 /
“sort-packages”: true,
/ 信頼できるパブリッシャー以外からのプラグイン実行をブロックし、セキュリティとパフォーマンスを担保 /
“allow-plugins”: {
“pestphp/pest-plugin”: true,
“php-http/discovery”: true
}
},
“scripts”: {
/
チーム開発で高速かつ安全に環境構築を行うためのカスタムスクリプト。
–no-dev を外しつつ、オートローダーの最適化を同時に行う実用的なコマンド。
/
“setup”: [
“composer install –prefer-dist –no-progress”,
“@php artisan key:generate –ansi”
],
/ CIや本番デプロイメント専用の超高速インストールパイプライン /
“deploy-install”: [
“composer install –no-dev –prefer-dist –no-progress –optimize-autoloader”
]
}
}
この `composer.json` をリポジトリにコミットし、チームメンバー全員が `composer setup` または `composer deploy-install` を叩く文化を作る。これだけで、属人化しがちだった環境構築の速度と品質が完璧に同期される。
—
テックリードからの総括
ツールのパフォーマンスチューニングとは、単に「待ち時間が数秒減る」というレベルの話ではない。「開発者のフロー状態（Flow State）を途切れさせない」という、極めて重要なエンジニアリング文化の構築そのものだ。
- Composer 2のネイティブ並列性能を信じ、
- CIとローカルで強固なキャッシュ戦略を回し、
- 実行基盤であるPHPのランタイムを最新化し、
- 設定をコード（`composer.json`）としてチームに強制する。
これらのピースが噛み合った瞬間、あなたのチームのビルドパイプラインは見違えるほどの速度を手に入れるだろう。今日からさっそく、ローカルのキャッシュ設定と `composer.json` の見直しに着手してほしい。