こんにちは！日々の開発、本当にお疲れ様です。
PHPのプロジェクトを進める中で、`composer install` を実行した際、数千ファイルにも及ぶ膨大な `vendor/` ディレクトリの生成を待たされた経験はありませんか？「本番環境へのデプロイのたびに、何分も待たされる……」「CI/CDのパイプラインで毎回パッケージのダウンロードが発生して遅い……」そんなモヤモヤを抱えている方も多いはずです。
今回は、そんなデプロイのストレスを劇的に解消し、秒速の世界へと導いてくれるComposerの秘密兵器、`archive` コマンドについて徹底解説します。
これをマスターすれば、あなたのデプロイプロセスは見違えるほどスムーズになり、毎日のリリース作業が驚くほど楽になりますよ。さあ、一緒にエンジニアとしての引き出しを一つ増やしましょう！
—
1. なぜデプロイが遅いのか？Composerアーキテクチャの真実
まず、私たちが普段何気なく使っている `composer install` が、内部でどのように動いているのかを少しだけ深掘りしてみましょう。
ローカルやCI環境で `composer install` を実行すると、Composerは以下のステップを踏みます。
1. `composer.lock` を読み込み、必要なパッケージのメタデータをリモートから取得。
2. 数十〜数百に及ぶライブラリのソースコードを、1つずつGitHub等のリポジトリからZIP等でダウンロード。
3. それらをローカルの `vendor/` ディレクトリに展開し、オートローダー（`autoload.php`）を再構築。
このプロセス、開発環境では非常にスマートで優れていますが、本番デプロイやCI/CDのステージにおいては「百害あって一利なし」です。なぜなら、本番環境はコードを「動かす」場所であり、パッケージの「選定やダウンロード」をする場所ではないからです。
ここに何万ものファイル（特にGitの履歴やテストコードなどの余分なファイルを含む場合もある）が絡むと、ファイルI/Oのボトルネックでデプロイが致命的に遅くなります。
解決策：ビルド済みパッケージ（Archive）の概念
そこで登場するのが、「一度ビルドしたものを固めて、そのまま運ぶ」というアプローチです。
Composerの `archive` コマンドは、`composer.lock` に基づいて依存関係を完全に解決した状態の `vendor/` を含め、プロジェクト一式を1つのZIPやTARファイルにギュッと圧縮してくれる機能です。
- 開発環境・CI環境：「作る（ビルド）」
- 本番環境：「解凍して置くだけ（デプロイ）」
この役割分担を徹底することで、本番環境やデプロイ先でのComposerの実行を完全に排除し、転送時間と処理時間を劇的に短縮できます。
—
2. 【基礎編】Composer Archiveの基本とHelloWorld的な動作確認
それでは、実際に手を動かしてその威力を体感してみましょう。
今回は、シンプルなPHPプロジェクトを想定して、`composer archive` の基本的な使い方をステップバイステップで見ていきます。
ステップ1: 最小限のプロジェクト準備
まずは、適当なディレクトリを作成し、テスト用のプロジェクトを初期化します。ここでは例として、人気の軽量HTTPルーターである `nikic/fast-route` を依存関係に入れてみましょう。
プロジェクト用ディレクトリの作成
mkdir composer-archive-demo
cd composer-archive-demo
composer.jsonの初期化（対話をスキップしてデフォルト生成）
composer init –no-interaction –name=”expert/archive-demo” –description=”Demo project for composer archive”
依存関係としてfast-routeを追加
composer require nikic/fast-route
このコマンドを実行すると、プロジェクト内に `composer.json` と `composer.lock`、そして `vendor/` ディレクトリが生成されます。
ステップ2: 動作確認用スクリプトの作成
プロジェクトが正常に動作するか確認するため、簡単なエントリーポイント（`index.php`）を作成します。
addRoute(‘GET’, ‘/hello’, ‘say_hello_handler’);
});
echo “Composer Archive Demo is ready!\n”;
実行してみましょう。
php index.php
出力: Composer Archive Demo is ready!
無事に動作することが確認できました。
ステップ3: `composer archive` でパッケージを固める！
いよいよ本丸の登場です。以下のコマンドを実行してください。
composer archive –format=zip –dir=./dist
【コマンドの解説】
- `composer archive`: 依存関係を含めたプロジェクト全体をアーカイブ化するコマンド。
- `–format=zip`: 圧縮形式を指定（`tar`, `tar.gz`, `zip` が選べます。Windows環境との互換性を考慮して `zip` が無難です）。
- `–dir=./dist`: 生成されたアーカイブファイルを配置するディレクトリを指定。
実行すると、`dist/` ディレクトリの中に `expert-archive-demo-v1.0.0-xxxx.zip` のような名前で、vendorディレクトリや必要なソースコードがすべて含まれた完璧な単一のZIPファイルが生成されます。
このZIPファイルを本番サーバーに転送し、そこで解凍するだけで、`composer install` を一切実行することなく、そのままアプリケーションを稼働させることができるのです。これが「ビルド済みパッケージによるデプロイ」の正体です。
—
3. 【実践編】CI/CDパイプラインへの組み込みと爆速化の極意
基礎が分かったところで、これを実際のCI/CD（GitHub ActionsやGitLab CIなど）にどのように組み込み、最大の効果を発揮させるのかを解説します。
実務における理想的なCI/CDのフローは以下の通りです。
1. Build Job:
- コードをチェックアウトする。
- `composer install –no-dev –optimize-autoloader` を実行して本番用の依存関係を構築。
- `composer archive` でデプロイ用のZIPを生成。
- 生成したZIPをCIのアーティファクト（成果物）として保存。
2. Deploy Job:
- 保存されたZIPを本番サーバーへ転送。
- サーバー上で解凍して配置完了。
GitHub Actionsでの設定例
実務でそのまま使える、GitHub Actionsのワークフローファイルのサンプルを提示します。各行のコメントに注目してください。
name: Production Deploy Pipeline
on:
push:
branches:
- main # mainブランチへのプッシュをトリガーにする
jobs:
build:
name: Build Application Archive
runs-order: ubuntu-latest
steps:
# 1. リポジトリのコードをチェックアウト
- name: Checkout Repository
uses: actions/checkout@v4
# 2. PHP環境のセットアップ（必要な拡張機能も含める）
- name: Setup PHP
uses: shivammathur/setup-php@v2
with:
php-version: ‘8.2’
tools: composer:v2
# 3. 本番用に依存関係をインストール（開発用パッケージは除外）
- name: Install Composer Dependencies (Production)
run: composer install –no-dev –optimize-autoloader –no-interaction –prefer-dist
# 4. アーカイブの生成（distディレクトリに出力）
- name: Create Composer Archive
run: |
mkdir -p dist
composer archive –format=zip –dir=./dist –file=release
# 5. 生成したZIPファイルをアーティファクトとして保存（次のジョブへ受け渡す）
- name: Upload Build Artifact
uses: actions/upload-artifact@v4
with:
name: app-release
path: dist/release.zip
deploy:
name: Deploy to Production Server
needs: build # buildジョブが成功した後に実行
runs-on: ubuntu-latest
steps:
# 1. ビルド済みZIPアーティファクトをダウンロード
- name: Download Build Artifact
uses: actions/download-artifact@v4
with:
name: app-release
path: ./deploy-package
# 2. 本番サーバーへの転送とデプロイ処理（SSH経由の例）
- name: Deploy via SCP and SSH
env:
SSH_PRIVATE_KEY: ${{ secrets.PRODUCTION_SSH_KEY }}
HOST: ${{ secrets.PRODUCTION_HOST }}
USER: ${{ secrets.PRODUCTION_USER }}
run: |
echo “ここにSSH接続してZIPを転送・解凍するスクリプトを記述します”
# 例: scp ./deploy-package/release.zip $USER@$HOST:/var/www/html/
# 例: ssh $USER@$HOST “unzip -o /var/www/html/release.zip -d /var/www/html/ && rm /var/www/html/release.zip”
この設計がもたらす圧倒的なメリット
1. 本番サーバーにComposerが不要：本番環境のサーバーにPHPやComposerのバージョン依存を気にする必要がなくなります。PHPさえ動けば、ZIPを解凍するだけでアプリケーションが動きます。
2. ネットワーク負荷と障害リスクの軽減：本番環境からPackagist（外部リポジトリ）へアクセスしないため、「外部の障害でデプロイが失敗した」という最悪の事態を防げます。
3. デプロイ時間の劇的な短縮：何千ものファイルを1つずつ転送するのではなく、最適化された単一のZIPファイルを転送して一瞬で展開するため、デプロイ完了までの時間が数分単位で短縮されます。
—
最後に：先輩エンジニアからのエール
今回は、Composerの `archive` 機能を活用した、CI/CDの爆速化手法について解説しました。
最初は「わざわざアーカイブを固めるなんて一手間増えるのでは？」と感じるかもしれません。しかし、プロジェクトが大規模になり、チームメンバーが増え、デプロイの頻度が高まるにつれて、この「ビルドとデプロイの分離」がどれほど強固で美しいアーキテクチャであるかに気づくはずです。
これをマスターすれば、あなたの開発ライフは確実に一段上のステージへ引き上げられます。ぜひ、次のプロジェクトや現在のプロダクトのデプロイフローに導入してみてください。
あなたの毎日のコーディングとデプロイが、驚くほど快適で楽しいものになりますように！