composer installとupdateの違いを現場目線で整理

composer installとcomposer updateの違いを一言で言うと

composer install と composer update の違いは、「依存関係を“再現”したいのか、“更新”したいのか」にあります。
install は composer.lock に書かれた内容をそのまま再現するコマンドで、update は依存関係のバージョンを再計算し、composer.lock 自体を書き換えるコマンドです。

この違いを曖昧にしたまま使っていると、「自分の環境では動くのに、他の人や本番では動かない」といったトラブルが起きやすくなります。特にチーム開発や長期運用では、この2つをどう使い分けるかが安定性を大きく左右します。

composerの基本構造を軽くおさらい

composer.jsonとcomposer.lockの役割

composerを理解するうえで、まず押さえておきたいのが composer.json と composer.lock の関係です。

• composer.json

プロジェクトが「どんなライブラリを、どの範囲のバージョンで使いたいか」を宣言するファイルです。

• composer.lock

実際にインストールされたライブラリの正確なバージョンを固定するファイルです。

composer.json は「希望」、composer.lock は「確定結果」と考えるとイメージしやすいでしょう。

composer installの挙動を具体的に見る

composer installは何をしているのか

composer install を実行すると、基本的には次のような流れになります。

• composer.lock が存在する場合

composer.lock に書かれたバージョンをそのままインストールします。

• composer.lock が存在しない場合

composer.json をもとに依存関係を解決し、その結果を composer.lock に書き出します。

つまり、通常の開発現場では「composer.lock がある状態で install する」ことが前提になります。

実際にやるとこうなる例

$ composer install

このとき、composer.json に「^1.2」と書かれていても、composer.lock に 1.2.3 が記録されていれば、1.2.3 がインストールされます。
1.2.9 が存在していても、勝手に更新されることはありません。

composer installが向いている場面

• チームメンバーが同じ環境を再現したいとき
• CI環境や本番サーバーで依存関係を揃えたいとき
• 「昨日動いていた状態」をそのまま再現したいとき

再現性が何より大事な場面では、composer install が基本になります。

composer updateの挙動を具体的に見る

composer updateは何をしているのか

composer update は、composer.json に書かれた条件をもとに、依存関係を再計算します。その結果として、composer.lock が更新されます。

• 新しいバージョンが条件内にあれば取得する
• 依存関係全体を見直して組み合わせを変えることもある

install とは違い、「現時点での最新構成」を作り直すイメージです。

実際にやるとこうなる例

$ composer update

これを実行すると、composer.lock の中身が変わり、インストールされるライブラリのバージョンも更新されます。

特定のパッケージだけ更新する場合

$ composer update monolog/monolog

このようにパッケージを指定すると、影響範囲をある程度限定できます。ただし、依存関係の都合で他のパッケージも更新される可能性はあります。

installとupdateを混同すると起きがちな失敗

「とりあえずupdate」が招く事故

初心者だけでなく、慣れている人でもやりがちな失敗が「環境構築時に composer update を実行する」ことです。

• 自分の環境だけ最新版になる
• composer.lock が意図せず書き換わる
• チーム内で差分が生まれる

この状態でコミットすると、他のメンバーの環境まで変わってしまいます。

本番サーバーでupdateしてしまうリスク

本番環境で composer update を実行すると、以下のようなリスクがあります。

• ライブラリの仕様変更で突然エラーが出る
• PHPのバージョン差異で依存解決に失敗する
• ロールバックが難しくなる

本番では、原則として composer install のみを使う方が安全です。

チーム開発でのおすすめ運用

基本ルールを決める

多くの現場では、次のようなルールが採用されています。

• 通常の環境構築：composer install
• ライブラリ更新作業：composer update
• composer.lock は必ずリポジトリに含める

このルールを共有しておくだけで、トラブルはかなり減ります。

updateするタイミングを意識する

composer update は、次のようなタイミングで実行するのが現実的です。

• 脆弱性対応でアップデートが必要なとき
• フレームワークのマイナーバージョンを上げたいとき
• 影響範囲を把握したうえで更新したいとき

「なんとなく最新にしたいから」という理由での update は避けた方が無難です。

それでも迷ったときの判断軸

install と update で迷ったときは、次の質問を自分に投げてみてください。

• 今やりたいのは「同じ状態を再現すること」か
• それとも「新しい状態に進めること」か

前者なら composer install、後者なら composer update です。
この判断軸を持っているだけで、コマンド選択に迷いにくくなります。

まとめ：コマンドではなく「意図」で選ぶ

composer install と composer update の違いは、コマンドの仕様というより「使う人の意図」の違いと言えます。
環境を固定したいのに update を使ったり、更新したいのに install だけで済ませたりすると、どこかで歪みが出ます。

「今は再現フェーズなのか、更新フェーズなのか」を一度立ち止まって考える。
それだけで composer との付き合い方は、かなり楽になるはずです。