こんにちは！チーム開発でPHPを触り始めると、必ずと言っていいほど耳にするのが 「Composer」 ですよね。
外部の便利なライブラリ（フレームワークやデータベース接続ツールなど）を魔法のように一発でインストールしてくれる非常に頼もしい相棒ですが、初心者の方が最初に必ず躓くポイントがあります。それが今回解説する `composer.json` と `composer.lock` の違い です。
「あれ、この2つのファイルって何が違うんだっけ？」
「Gitにはどっちをコミットすればいいの？」
「チームメンバーとライブラリのバージョンがズレてバグが出るんだけど……！」
こうした現場の悩みをすべて解消し、明日からチーム全員が同じ環境で気持ちよく開発できるようになるための知識を、優しく紐解いていきましょう。これをマスターすれば、あなたのチームのデプロイ事故は確実にゼロに近づきますよ！
—
1. そもそもComposerとは？（なぜ必要なのか）
昔のPHP開発では、使いたいライブラリ（例えばPDF生成ライブラリなど）の公式サイトからZIPファイルをダウンロードし、手動でプロジェクトフォルダに放り込んで読み込んでいました。ライブラリが別のライブラリに依存している（これを「依存の連鎖」と呼びます）と、バージョン整合性を手動で合わせる必要があり、地獄のような苦労がありました。
Composerは、このPHPの依存関係管理を完全に自動化してくれるモダンなパッケージ管理ツールです。
Composerの基本をサクッとセットアップ
まずは、Composerが手元の環境でどう動くのか、一番シンプルな「Hello World」的な動作確認をしてみましょう。任意のディレクトリで以下のコマンドを実行してみてください。
プロジェクト用の空ディレクトリを作成して移動
mkdir composer-tutorial
cd composer-tutorial
ログ出力用の便利な軽量ライブラリ「monolog/monolog」を要求（インストール）してみる
composer require monolog/monolog
このコマンドを実行した瞬間、あなたの手元のプロジェクトフォルダには何が起きたでしょうか？
裏側でComposerは、世界中のライブラリが登録されている巨大なデータベース（Packagist）にアクセスし、「monolog」とその依存関係にあるライブラリの最新バージョンを計算・取得し、プロジェクトに組み込みました。
このとき、あなたのプロジェクトディレクトリには2つの重要なファイルが生成されています。それが、`composer.json` と `composer.lock` です。
—
2. `composer.json` と `composer.lock` の決定的な違い
この2つのファイルの役割は、料理に例えると非常にわかりやすくなります。
- `composer.json`（レシピ）
- 「我が家のカレーには、カレールーと、タマネギと、ニンジンが必要だよ」という大まかな要望（要件）を書く設計図です。
- `composer.lock`（正確な買い出しレシート）
- 「実際にスーパーに行って、タマネギはA農園のものを3個、ニンジンはB農園のものを2本、カレールーはC社の甘口を1箱、正確にこのバージョン・この重さで買ってきました」という確定した事実の記録です。
① `composer.json` の中身を見てみよう
先ほどのコマンドで生成された `composer.json` を開いてみてください。以下のようなJSON構造になっているはずです。
{
“require”: {
// プロジェクトが動作するために最低限必要なパッケージと、その許容バージョン範囲を指定
“monolog/monolog”: “^3.5”
}
}
- ここがポイント: `^3.5` という書き方は、「バージョン3.5以上、かつ4.0未満（破壊的変更が入るバージョンを除いた安全な範囲）なら、自動的に最新のものを選んでいいよ」という「幅を持たせた願い」を表しています。
② `composer.lock` の中身を見てみよう
一方、同じ階層にある `composer.lock` を覗いてみると、数百行に及ぶ圧倒的な情報量が詰まっています。
{
“_readme”: [
“This file locks the dependencies of your project to a known state”,
“Read more about: https://about.composer.lock”
],
“packages”: [
{
“name”: “monolog/monolog”,
// composer.jsonでは「^3.5」とあいまいだったものが、「3.8.1」という完全な特定の値に固定される
“version”: “3.8.1”,
“source”: {
“type”: “git”,
“url”: “https://github.com/Seldaek/monolog.git”,
// どの瞬間のソースコードか特定するためのハッシュ値（SHA-1など）
“reference”: “a7efb9916725841108d822cef1a5d679724128f7”
},
“dist”: {
“type”: “zip”,
“url”: “https://api.github.com/repos/Seldaek/monolog/zipball/a7efb9916725841108d822cef1a5d679724128f7”,
“reference”: “a7efb9916725841108d822cef1a5d679724128f7”,
“shasum”: “”
}
}
// … 他の依存パッケージの正確な情報が延々と続く
]
}
- ここがポイント: `composer.lock` は、「世界中の誰が、いつ、どの環境でインストールしても、1ビットの狂いもなく全く同じバージョンのライブラリを再現する」ための完全な固定データ（スナップショット）です。
—
3. なぜ `lock` ファイルがチーム開発で絶対に不可欠なのか？
もし、世の中に `composer.lock` が存在せず、`composer.json` だけしかなかったらどうなるでしょうか？想像するだけで冷や汗が出ます。
1. 開発者Aさんが月曜日に `composer require` をして開発を始めた（当時のMonologの最新は `3.8.1`）。
2. ライブラリの作者が火曜日にバグ修正を含めた新しいバージョン `3.8.2` をリリースした。
3. 開発者Bさんが水曜日にプロジェクトに参加し、`composer install` を実行した。
4. Bさんの環境には、最新の `3.8.2` がインストールされた。
結果として、「Aさんの環境では動くのに、Bさんの環境では謎のバグで動かない（依存ライブラリの微妙な仕様変更のせい）」という、原因究明に何時間も溶かす「環境差異の呪い」が発動します。
`composer.lock` をGitで共有していれば、Bさんが水曜日に参加して `composer install` を叩いたとき、Composerは `composer.json` ではなく `composer.lock` を優先して読み込みます。 そのため、Bさんの手元にもAさんと全く同じ `3.8.1` が正確に再現され、環境差異による不具合を綺麗にシャットアウトできるのです。
—
4. チーム開発におけるGit管理のベストプラクティス
「じゃあ、Gitにはどのファイルをコミットすればいいの？」という疑問に対する答えは明確です。
アプリケーション開発（WebサイトやWebシステム）においては、`composer.json` も `composer.lock` も両方とも必ずGitの管理下に置いてください。
チーム開発の黄金ルール
- アプリケーション開発（Webアプリ等）
- `composer.json`： 【管理する】
- `composer.lock`： 【管理する】
- 理由：チームメンバー全員、および本番環境（サーバー）で「完全に同一のライブラリバージョン」を保証するため。
- ライブラリ開発（他の人に使ってもらうパッケージを作る場合）
- `composer.json`： 【管理する】
- `composer.lock`： 【管理しない（.gitignoreに入れる）】
- 理由：ライブラリ単体では動作せず、それを利用する側のアプリケーションが依存関係を解決するため、lockファイルを置くと逆に不都合が生じるため。
—
5. 日常のコーディングが劇的に楽になるコマンド運用フロー
最後に、チーム開発でComposerを扱う際の「正しいコマンドのルーティン」を覚えておきましょう。これを守るだけで、デプロイ時のトラブルが劇的に減ります。
① 新しいライブラリを追加したいとき
必ず `composer require` を使う（手動で composer.json を書き換えない）
composer require vendor/package-name
→ これにより、composer.json と composer.lock の両方が自動的に更新されるので、両方をGitにコミットする！
② チームメンバーがリモートリポジトリから最新の変更（コード）を取り込んだとき
他のメンバーが新しいライブラリを追加して `composer.lock` が更新されたコードを、あなたが `git pull` で持ってきたときの手順です。
単にファイルを引っ張ってきただけでは、PC内のライブラリ実体（vendorフォルダ）は古いまま。
必ず以下のコマンドを叩いて、lockファイル通りの正確な状態に同期する。
composer install
- ここが超重要: チーム開発でコードを引っ張ってきたら、「まずは `composer install` を叩く」を身体の反射神経レベルで覚えましょう。これだけで、「Class not found」といった初歩的なエラーを防げます。
③ ライブラリのバージョンを意図的に上げたいとき（アップデート）
composer.json の許容範囲内で、可能な限り最新のバージョンにアップデートし、lockファイルを再生成する
composer update
※注意：`composer update` はプロジェクト全体の依存関係を一気に書き換える可能性があるため、チームで合意を取らずに勝手に実行すると他のメンバーの環境を壊す原因になります。通常は特定のパッケージだけを指定してアップデート（`composer update vendor/package-name`）するか、慎重に行いましょう。
—
まとめ
いかがでしたでしょうか？
- `composer.json` は、「こういうライブラリがほしいな」という大まかな要望（設計図）。
- `composer.lock` は、「実際にこのバージョンを調達したよ」という正確な履歴（レシート）。
- アプリケーション開発では、両方のファイルを必ずGitで共有する。
- チームの変更を取り込んだら、真っ先に `composer install` を走らせる。
この本質さえ押さえておけば、Composerに振り回されることはもう二度とありません。
正確なバージョン管理のもとで、安心安全で快適なPHPライフをお楽しみください！毎日のコーディングが、きっともっと楽しく、劇的にスムーズになりますよ。